작년 12월 21일부터 올해 1월 5일까지, 약 2주간 First Project를 진행했습니다.
First Project 회고를 통해, Final Project에 대한 준비를 하려 합니다.
저는 첫 회의 때 First Project에 대한 의의를 먼저 생각해 보았습니다.
왜냐하면 부트캠프 과정에 First Project(2주), Final Project(4주) 총 2번의 프로젝트가 있는데,
한 번에 합쳐서 6주 짜리 Final Project를 할 수도 있지 않나 생각이 들었기 때문입니다.
시간으로만 보면 가장 높은 퀄리티의 결과물을 뽑아 낼 수 있지 않나 생각이 들기도 했기 때문입니다.
그럼에도 First와 Final이 분리되어 있는 이유가 있을텐데, 과연 첫 번쨰 프로젝트에서 2주라는 시간 동안 무엇을 경험하고 배우는 게 값질 것인가 고민했습니다.
저의 결론은 "실수를 통해 Final Project에서 같은 실수를 반복하지 않도록 한다." 라는 것이였습니다.
첫 번째 프로젝트는 2주던 6주던 기간에 상관없이 분명 많은 실수가 있을 것으로 예상했습니다.
그러한 실수로 인해 계획에 차질이 클 것이라고 생각했습니다.
그렇다면 First와 Final이 분리되어 있는 점을 이용해서, First Project에서 기획부터 배포까지 모든 단계를 경험하고, 각 단계별로 겪을 수 있는 문제와 문제 해결에 대한 과정을 기록한다면, 실수는 자산이 될 것이라고 생각했습니다.
그렇다면 Final Project에서 같은 실수를 반복하지 않으니 시간을 아낄 수 있고, 프로젝트의 모든 단계를 2번을 경험하니 가장 효율적인 공부가 될 것이라고 생각했습니다.
이러한 결론 덕분에 프로젝트의 모든 과정을 경험할 수 있도록 First Project를 기획할 수 있었습니다.
그럼 First Project 과정에서 실수,그리고 덕분에 배우고 느낀 점들을 작성해보겠습니다.
문제 1. 기획 단계로 거슬러 올라가 수정을 해야 했습니다.
2주의 기간동안 3일의 시간을 기획 단계로 정했습니다.
포지셔닝, 기능 리스트업, 서비스 페이지 기획, 와이어 프레임 제작, 기능 플로우, 스키마 작성, API 작성, 태스크 카드 작성, 팀 룰..
기획 단계를 3일로 한정했다는 것이 First Project의 가장 큰 실수였습니다.
해결 방법 : 소프트웨어 개발 방법론을 찾아 보았습니다.
선배 개발자들도 처음 프로젝트를 했을 때, 비슷한 경험을 하지 않으셨을까 생각이 들었습니다.
과연 어떤 방법을 통해 해결할 수 있었을지 검색을 해 보았습니다.
그렇게 소프트웨어 개발 방법론을 알게 되었고, 전통적으로 사용되는 '폭포수 모델(Waterfall Model)'을 찾게 되었습니다.
가장 핵심적인 단계는 업무 분석과 시스템 설계라는 점과 이 두 단계의 비율을 자꾸 줄일수록 프로젝트가 실패할 확룔이 높아진다는 말씀이 와닿았습니다.
저희는 규모가 작은 프로젝트를 진행하였기 때문에 금방 돌아가 수정하고 다시 진행할 수 있었지만, 아마 Final Project에서 같은 경험을 한다면 프로젝트가 실패로 돌아갔을 것이라고 생각했습니다.
미리 이러한 실수를 해서 참 다행이다라고 생각했고, 프로젝트 첫 회의에서는 소프트웨어 개발 모델을 먼저 선택하고 분석과 설계 단계에 대한 비중을 최소 50%이상 할당하기로 결심했습니다.
문제 2. 말의 힘을 맹신했다.
서로의 의견을 주고 받을 때, 말의 힘을 너무 맹신했습니다.
기획 단계로 거슬러 올라가야 했던 이유 중 하나이기도 합니다.
기획 단계 때 더 구체적으로 UI를 그려서 서로의 생각을 일치해야 했지만, 어느 정도 일치한 후에는 대화로만 주고 받으며 확인 했던 것이 문제가 되기도 했습니다.
해결 방법 : 협업 툴을 적극적으로 사용한다.
이런 경험을 하며 생활코딩 수업에서 이고잉님이 하셨던 말씀이 기억이 났습니다.
"말의 힘을 불신 하십시오. 말의 진의를 불신하라는 것이 아니라, 말의 기능을 불신하라는 말입니다.
말을 불신할 수록 말의 신뢰성이 높아집니다."
서로의 생각을 일치하기 위해선 함께 UI를 그려보는 것이 좋은 방법임을 다시 한 번 상기하며, UI를 같이 그려보며 서로의 생각을 일치하였습니다.
그리고 코딩 실력 뿐만 아니라 프로젝트에 사용되는 툴을 다루는 실력 또한 커뮤니케이션으로 연결됨을 깨닫고 툴을 다루는 방법을 공부했습니다.
문제 3. 구글링을 해도 제가 현재 겪고 있는 문제를 경험한 사람을 찾기 어려웠습니다.
처음 해보는 배포에서 클라이언트-서버 간에 세션을 주고 받지 못하는 문제를 겪었습니다.
세션을 주고 받지 못하는 대표적인 케이스에 대한 사례를 보았으나, 전부 해당하지 않았습니다.
구글링을 하고 코드스테이츠에서 운영하는 help desk와 Stack Overflow에도 질문을 올렸지만 큰 도움을 받지 못했습니다.
해결 방법 : 전세계 사람들이 흔히 겪지 못한 문제라면 오타를 검출하는 작업을 먼저 해본다.
세션 문제를 해결하지 못하여, 세션으로 주고 받을 값을 body를 통해 주고받는 방식으로 대체하였습니다.
백엔드를 담당했지만 테스트를 위해 클라이언트 코드도 직접 수정하며 코드정리를 하고 테스트를 하였는데 세션이 정상 작동 되는 것을 확인했습니다.
문제 해결의 가능성을 본 저희 팀은 모두 모여 코드를 살펴보기 시작했고, 결국 오타를 발견했습니다.
평소에 제가 겪는 문제는 선배들이 이미 경험했을 확률이 높다고 생각했기에, 제가 겪고 있는 문제에 대해 언급이 거의 없다는 게 이상하다고 생각했었습니다.
그럼에도 "오타가 있진 않을까?"라는 기본적인 에러 핸들링 단계를 생각하지 못했습니다.
앞으로는 구글링에서 지금 겪고 있는 에러와 비슷한 사례를 찾기 힘들면 우선 순위로 오타 검출부터 차근차근 단계를 밟아 나가는 것이 순서임을 알게 되었습니다.
문제 4. 클라이언트-서버 간의 소통이 부족했습니다.
첫 프로젝트이다 보니 코드를 작성하는데 급급했습니다.
매일 오전 미팅을 가졌지만 포지셔닝에 따라 같은 사이드에 있지 않은 팀원과는 소통하는 시간이 적었습니다.
같이 백엔드를 담당했던 동료와는 많은 시간 함께하며 프로젝트를 진행했지만,
클라이언트 담당 동료와는 소통이 부족했습니다.
부족한 시간 속에서 어떻게 하면 소통을 잘할 수 있을지 고민했습니다.
해결 방법 : 자신의 상황에 대해 적극적으로 알린다.
전 날 겪고 있는 문제를 미팅에서 모두 적극적인 피드백을 주고 받으며 해결하는 경우도 있었습니다.
적극적인 피드백을 주고 받을 수 있었던 자신의 상황에 대해 적극적으로 알린 덕분이라고 생각했습니다.
그래서 저 또한 저의 상황을 적극적으로 알리기 위해 수시로 슬랙 단체방을 통해 저의 상황을 전달했습니다.
항상 소통을 강조하는 부트캠프에서 매 스프린트마다 페어 프로그래밍을 경험하며, 코딩을 잘 하는 사람이라고 꼭 같이 할 때 좋은 것만은 아님을 알았지만, 이번 First Project를 경험하면서는 이전과는 한 차원 다르게 소통에 대한 중요성을 더 깊이 느꼈습니다.
스프린트의 규모는 작은 편이였기에 서로에 대한 배려심이 충분하다면 원할하게 진행되었지만,
프로젝트에서는 조금 다름을 느꼈습니다.
팀원 모두가 서로에 대한 배려가 깊었고, 의견 합의도 원만하게 진행되었지만 소통이 배려심만으로 또 해결되지 않음을 알게 되었습니다.
서로에 대한 배려는 기본이고 그 위에 소통에 대한 실력도 필요하다고 느꼈습니다.
'겪은 문제 2번'처럼 툴을 사용하여 소통하는 방법도 하나의 실력이고, 효율적인 회의가 진행 될 수 있도록 팀만의 규칙을 정하는 것도 필요하다고 생각했습니다.
회의 시간은 한정되어 있는데 누군가 계속 말을 하거나, 다른 사람의 말을 중간에 끊어 버린다면 정상적인 회의가 진행되지 않을 것이기 때문입니다.
정말 기본이라고 생각되는 것들도 저를 포함하여 모두가 놓칠 수 있기 때문에 확실하게 정하고 가는 것이 효율적이라고 느꼈습니다.
Final Project에서는 이번 실수를 통해 한층 더 성숙해진 과정을 만들 수 있도록 노력해야겠습니다.
