[코드 스테이츠 / Epilogue] "Final-Project 회고 - 힘들었던 점"

Final-Project 발표 최종 영상 보러 가기 (Youtube)

 

 

  에필로그에서는 코드 스테이츠를 진행하면서 따로 블로깅하지 못했던 내용들을 적어보고자 한다. 가장 첫 번째로, Final-Project 회고를 진행하고자 한다. 저번에 Final-Project 끝나고 나서 너무 진이 빠진 바람에 블로깅을 제대로 작성하지 못했는데 더 늦으면 기억이 가물가물할 것 같아서 최대한 빨리 작성하려고 한다.

 

---

[ 오늘의 TODO ]

1. 크리스마스에도 공부는 지속된다
   (이제 코드 스테이츠도 끝났겠다 서식도 조금씩 바꿔야할 거 같다)

---

[ 프로젝트 하며 힘들었던 점 ]

1. 기능과 페이지 구상까지 끝마친 아이디어 백지화

   처음부터 우리를 멘붕에 빠트리게 만든 주범. 이때, 팀 분위기가 말 그대로 박살이 났었다. 

 

  우리가 초기에 계획했던 아이디어는 출근 메이트였다. 밑의 스크린샷들을 보면 알겠지만, 출근 메이트는 팀원 만장일치로 채택된 아이디어라서 구현하고 싶은 기능들이 마구마구 쏟아졌다. 앱의 성격도 좋았고, 이것과 비슷한 성격의 웹 서비스가 없었기에 더 좋았다. 

   

아이디어와 어떤 기능을 구현할지 모두 구상까지 완료했었다

 

크루님께서 답해주신 내용

 

  그런데 갑자기 의문이 하나 들기 시작했다. 내가 든 의문이긴 했는데, "이거 웹이 아니라 모바일 서비스 아닌가요...?" 였다. 출근하는 사람들이 컴퓨터를 켜고 웹 상에서 서비스를 이용한다? 이 앱의 성격은 웹이 아닌 앱에 맞춰져 있다. 그런데 우리가 구현하고자 하는 서비스는 앱이 아닌 웹이었기 때문에 갑자기 막막해지기 시작했다. 코드 스테이츠 크루에게 의견을 물어봤는데 크루의 답변은 React 가 아닌 React Native 를 사용하는 것이 맞을 것 같고 배포와 관련해서도 반드시 신경 쓸 것은 권장했다. 우리 팀원 중에서는 React Native를  본 경험이 있는 사람이 없었다. 그러면 새로운 기술을 도입해서 한 번 써보자! 라고 생각한 사람이 나를 포함한 2명이었고, 아니다 이건 배포까지 신경 쓰게 된다면 너무 막막하다고 생각한 사람이 2명이었다. 의견 비율이 2:2 라서 바로 결정하기도 애매한 상황이었다. 저번 2주차 프로젝트를 진행했을 때, 아이디어 기획보다 SR(REST API, 데이터 스키마 디자인, 목업 디자인, 워크 플로우 등등) 이 더 중요하다는 것을 알고 있기에 팀장으로서 빠르게 결정을 해야만 했다. 

 

   지금 생각해도 많이 아찔했던 상황이다. 저렇게까지 시간과 정성을 들여가며 기획을 거의 다 완벽하게 했는데 이걸 백지화해야 한다는 건, 허무함과 더불어서 다시 새롭게 아이디어를 생각하고 다시 추가 기능들을 짜야한다는 것이기에 백지화가 결코 쉬운 결정은 아니었다. 하지만, 그 결단을 빠르게 내리게 했던 원인은 서비스의 완성도였다. 2주 프로젝트에서 4주 프로젝트로 넘어올 때 반성하고 중요 사항으로 둔 것은 웹 페이지의 완성도를 더 높이자는 것이 있었다. 그런데 만약 이 아이디어로 밀고 나간다면 완성도를 우리가 원했던 만큼 더 높일 수 없다는 판단이 들어 백지화를 결정했다.   

 

  그 결정하고 나서 아이디어 회의를 시작하려고 하니, 팀원 모두의 분위기가 다운됐다. 진짜 그 때의 삭막한 분위기가 생생하게 기억난다. 모든 팀원이 힘이 빠지고, 의욕이 많이 꺾였다는 것이 느껴졌다. 이 분위기를 해결하기 위해 팀장으로서 했던 첫 번째 일은 먼저 좀 쉴 시간을 갖도록 한 것이다. 아이디어 회의를 이후에 바로 진행하는 것이 아니라 하루 정도의 유예를 두고, 각자 한 번 더 아이디어를 생각해 오기로 했다. 시간에 쫓길 거 같았지만, 그럼에도 그 판단이 틀리진 않았다. 그다음 날, 그나마 더 나은 상태로 아이디어 회의를 진행할 수 있었다. 두 번째로 했던 일은 내가 먼저 밝은 톤으로 말하는 것이었다. 아무래도 회의 중에 가장 말 많이 하는 사람은 나다 보니 내가 처져 있으면 팀 분위기를 더 다운시킬 것 같아서 톤을 일부로 좀더 높여서 말했다. 세 번째는 부정적인 말을 하지 않은 것이다. 아이디어 회의 중에는 "그거 안 될 거 같아요", "음... 별로인 거 같은데..", "이건 좀.." 이런 류의 말들은 전혀 하지 않았다. 최대한 "오 괜찮은데요?", "아하, 확실히 그 기능을 추가하면 유저가 더 편하겠네요" 등 최대한 긍정적인 말들을 많이 사용했다. 팀 분위기가 이전처럼 확 좋아지지는 않았어도, 초반에 침체된 분위기에 비하면 많이 나아지기는 했던 것 같다. 

 

  그 때도 생각했지만 진짜 저 아이디어 너무 아깝다. 다음에 React Native 공부해서 구현해보고 싶다.

 

 

2. 팀원 간의 의견 마찰

  이전 프로젝트에서는 없었는데 4주 프로젝트를 진행하는 동안에는 의견 마찰이 꽤 심했다. 나는 이번에 모든 팀원에게 각자 한 번씩은 단호하게 말한 것 같다. 분석해보면 팀원 간에 발생한 마찰은 몇 가지 카테고리로 나눌 수 있다.

1. 개인이 원하는 바와 팀의 목적 사이의 균열
   (문제) 여러 상황이 있었는데 그중에 하나를 뽑아보자면, 한 분이 페이지 7개를 세 명이서 맡는 걸 기준으로 분류하셨는데, 1개 / 2개 / 2개 / 2개로 페이지를 분류하셨다. 그런데 여기서 본인이 원하는 건 1 페이지만 구현하는 것이었다. 그 이유는 완성도를 높이고 싶다는 것이었다. 그리고 세 명이 나눠 갖고 남는 2개의 페이지는 각자가 맡은 페이지를 빨리 구현하고 먼저 끝난 사람이 남은 페이지를 구현하는 것으로 하자고 말씀하셨다. 그 2개의 페이지는 생각보다 쉽게 끝날 수 있는 페이지니 그렇게 말씀하신 것 같지만, 팀장으로서 이렇게 애매하게 빨리 끝난 사람이 남은 페이지 구현하는 건 옳지 않고 빨리 끝나는 기능이니 그 1개의 페이지에 두 개 더해서 3/2/2 로 가는 게 맞을 거 같다고 말씀드렸다. 그러나 팀원 분은 다른 페이지들을 추가로 맡게 되면 부담감이 생겨 완성도 높게 페이지를 구현 못할 거 같다고 말씀을 하셨다. 
   
   (해결) 이건 내가 단호하게 페이지를 분담시켰다. 만약 페이지 분류를 3/2/2 로 하지 않는다면 내가 그 두 페이지 더 추가해서 3 페이지로 구현하겠다고 말했다. 이 말을 한 후 10분 쉬는 시간을 갖도록 했다. 쉬고 오니 그분께서 본인이 그냥 3페이지 맡겠다고 하셨다. 그 팀원 분께서 이때 조금 마음이 상하셨던 거 같지만, 그럼에도 이 부분은 단호하게 간 게 맞았다고 생각한다(결국 그 페이지 중 하나인  관리자 페이지는 내가 프로젝트 막바지에 하루 밤새면서 만들었다.)
   
   
2. 공부해서 배운 방식이 다르기에 발생하는 문제
   (문제) 이런 카테고리의 문제는 초기 코드 작성 룰을 짤 때 많이 겪었다. 그 문제들 중 하나가 Redux 다. Redux 의 경우 어떻게 폴더를 구성할지, 어떤 방식으로 파일들을 나눌지에 대해 얘기하는데 각자가 공부하고 작성해온 코드 방법이 달라 본인이 편한 방식이 제각각이었다. 물론, 방법만 다를 뿐 Redux 사용에는 문제가 없었지만, 그럼에도 본인이 사용하기 편한 방식을 사용하고 싶기에 약간의 마찰이 있었다
   
   (해결) 본인이 편한 방식으로 구현하지 않기로 결정됐다면, 그분께 이번 기회에 새로운 코드 작성 방법을 익히고 배운다는 걸로 독려했다. 이건 나도 포함된다. 실제 다른 분들의 코드 작성 규칙을 따라 적으면서 이런 방식으로도 코드를 작성할 수 있다는 것을 깨닫고 좀 더 효율적인 방법을 생각해보고 사용할 수 있게 되었다.

 

  비록, 팀원들 간의 마찰은 있었지만 그래도 마지막엔 다같이 웃으면서 끝낼 수 있었다. 그리고 이런 마찰들이 있었기에 더욱 퀄리티 높은 서비스들을 만들 수 있었다고 생각한다. 

 

3. Socket.io 를 도입하면서 마주한 에러들

  이건 내가 개인 기술 발표 영상을 만들면서도 얘기했던 내용들이다. 실시간 채팅 기능을 구현하기 위해 많은 노력을 기울였고, 결국에는 의도했던 안정적인 기능 구현에 성공했다. 하지만 그 결과에 이르기까지 너무나 많은 에러와 마주해야만 했다. 그 모든 에러를 블로깅에 담을 수는 없었지만, 오래 고민하게 만들고 많은 시간을 투자하게 했던 것들만 담아냈다.

  이게 진짜 에러의 하이라이트. 내가 겪은 100개의 에러는 이것 때문에 생기는 문제였다. 에러 해결을 위해 2~3일 정도 걸렸다.

  진짜 저 위의 에러. socket 이 계속 연결되는 저 문제를 해결하기 위해서 많은 고민을 했다. 쉽게 해결할 방법이 있었는데(useEffect clean-up 함수로 disconnect 를 걸어주는 것) 그걸 생각해내지 못했던 것이 아쉽다. 해결한 에러의 대부분은 해결하고 나서 보면 내가 알고 있는 내용이고 쉽게 해결할 수 있는 게 대부분이었다. 그런데 왜 그때는 이게 바로 생각나지 못했을까 하는 반성을 하게 만들었다. 

  아래의 스크린샷들은 실시간 채팅 서비스 구현 한정으로 에러를 발생시키거나 그 에러들을 해결하기 위해 수정된 화면, 코드들이다. 물론, 저것보다 훨씬 많은 에러들이 발견되었으나 Error log 를 작성하기 위해서, 팀원들에게 에러를 공유하기 위해서 스크린샷, gif로 찍은 것들이다. 

 

₩

 

  확실히, 새로운 스택을 사용하는 건 어려운 일이었다. 새로운 것을 실제 프로젝트로 녹여내기 위해서 공부해야할 것들도 많았고, 알지 못하는 에러들이 발생한 것도 있기 때문이다. 

 

  이 에러들이 발생한 원인은 다음 세 가지로 나눌 수 있다. 

 

1. 기존 무상태성을 지닌 http 프로토콜에 익숙해서 새로운 통신 프로토콜(ws)에 대한 유연한 사고가 부족했다는 점
   : 공부를 한다고 했지만, 아무래도 아무것도 없는 상태에서 내가 스스로 환경을 세팅하고 스택의 옵션들을 응용해서 서비스를 구현한다는 게 쉬운 일은 아니었다. 특히나 내가 기본적으로 알고 사용했던 개념이 아니었기 때문에 에러가 났을 때 유연하게 사고하고 대처를 했어야 했는데 기존 http 에 익숙한 나머지 디버깅을 위한 콘솔을 클라이언트에 적었어야 했는데 서버에 찍어보는 등 사용하는 스택과 맞지 않은 생각에 빠져 시간을 지체했던 것 같다.
   
   
2. Socket.io 옵션에 대한 이해가 부족했다는 점
   : Socket.io 에는 많은 옵션들이 존재하다. on으로 듣고 emit 으로 발생시킨다는 기본적인 것들, 그러니까 강의에서 들은 것들만 제대로 사용할 줄 알고 내가 새롭게 찾아서 써야 하는 것들, disconnect 라는 옵션이라던가 socket.to 가 아닌 io.to 등 다른 옵션들에 대한 이해도는 낮았던 것 같다. 그리고 그 옵션들을 많이 세세하게 찾아보려 하지 않았기 때문에 에러들을 해결하는데 시간이 많이 소요된 것 같다. 
   
   다음부터는 새로운 스택을 도입할 때 공식 문서에 있는 내용들을 읽어 보고 내가 써볼 수 있는 옵션이다 싶으면 한 번씩 다 toy 프로젝트나 아니면 손 코딩으로 글을 써보는 연습을 해야할 것 같다. 그
   
   
   
3. 어떤 것들을 상태 관리하고 어떻게 업데이트할 것인지 세부화하지 못했다는 점
   : 어떤 것들을 상태 데이터로 정하고, 그 데이터들을 어떻게 사용할지에 대한 것을 초기에 잡아 놓지 않으니 기능을 구현하기 위해 상태를 만들고, 그러다 내가 원하는 만큼의 기능이 구현되지 않거나 에러가 나니까 기존에 있던 상태를 업데이트하는 등의 일들이 많이 발생했다. 확실히 초반에 상태에 대한 계획을 구체적으로 정해놓지 않으니 기능 구현에 시간이 많이 걸렸다.
   
   이건 socket.io 뿐만 아니라 기능을 추가하고자 할 때, 어떤 것들을 상태로 관리할 것인지를 구체화 하는 노력이 필요할 것 같다. 
     
4. 새로운 스택을 사용한다고 지레짐작 겁을 먹어서 이미 알고 있던 것도 제대로 활용하지 못했다는 점
   : 이게 가장 큰 문제였다. 새로운 스택을 사용하니까 괜히 긴장을 해갖고 원래 잘하던 것도 잘하지 못하는 문제가 발생했다. 첫 번째 문제와도 연관이 되는데 이건 그 새로운 프로토콜과 관련해서 유연한 사고를 하지 못했다는 것이 아니라 그냥 코드를 작성할 때 사고가 경직됐다는 문제였다. 무슨 에러가 나면 먼저 socket.io 부터 의심하다 보니 오타가 나더라도 오타를 찾는 것이 아니라 socket.io 와 관련된 로직에서 문제가 발생한 것은 아닌가, 그런 방면으로만 에러난 원인을 찾아보려고 하는 등의 비효율적인 일처리를 하게 됐다.  
   
   예를 들면 그 에러, 처음 채팅 페이지에 진입했을 때 유저가 속한 모든 방에 바로 Join 하는 로직을 썼더니 A유저와의 채팅방에서 B가 보낸 문자를 받는다고 하는 그 에러가 대표적이다. 이거 해결하는 방법은 그냥 client 에서 내가 지금 보고 있는 채팅방의 아이디를currentRoom 상태에 저장하고 그 룸에서 받은 문자면 화면에 띄우고, 그 이외의 room에서 받은 문자라면 안 띄우는 방식으로 진행하는 것이다. 그런데 내가 이걸 Socket 의 문제라고 생각해 첫 진입 때 모든 방에 join 하는 로직을 지웠다. 이렇게 로직을 수정하다 보니 advanced 를 진행하는데 차질이 생겼다. 바로 이런 문제. 새로운 스택을 사용하면서 사고가 경직되어 문제가 발생되면 새로운 스택에서 발생할 거라는 편견과 내가 지금 알고 있는 것은 제대로 로직을 작성했을 것이라는 나의 오만이 문제다. (오만과 편견 ver.개발자)
   
   다음부터는 새로운 스택을 사용한다고 하면, 일단 마음을 편안하게 먹고 정말 Back to the basic 해서 "컴퓨팅적 사고" 로 기능 구현에 접근해야 할 것 같다. 그리고 문제의 원인은 꼭 그 새로운 스택에만 있을 거라는 고정관념을 버리고 내가 당연하게 될 거라고 생각한 그 코드들도 한 번씩은 검토를 해야겠다는 마인드를 지녀야겠다. 

 

여기까지가 지금 생각나는 힘든 점들이다. 다음 시간에는 내가 프로젝트를 하면서 배운 점들을 적고자 한다.