코드스테이츠 Final project 회고

Sean park·2020년 7월 8일
5
post-thumbnail

코드스테이츠 Immersive를 시작한 지 얼마 안 된 것 같은데 벌써 코스의 마지막 단계인 final project를 마무리했습니다. 저번 주에 수료를 하고 일주일이 지난 지금 final project를 진행하면서 느꼈던 점에 대해 정리해 볼까 합니다.
이번에 진행한 프로젝트 모두런는 한 달 동안 진행됐으며 인원은 똑같이 4명이서 진행됐습니다.

발전한 나! 발전해야 될 나!

이번 프로젝트는 기간도 이전 프로젝트보다 길고, 프로젝트를 한번 경험해서 그런지 확실히 조금 더 수월하게 진행할 수 있었고, 프로젝트 진행 전보다 발전한 제 모습을 발견할 수 있었습니다. 처음 프로젝트를 진행할 때는 막막한 감정이 들었습니다. 어디서 어떻게 코드를 써야 하고 어떤 구조로 짜면 좋을지 전혀 감이 오지 않았습니다. 그래서 스프린트를 진행할 때의 자료를 참고하며 개발을 시작했었습니다.
하지만 이번 프로젝트는 기획단계부터 큰 틀을 세우고 세세하게 채워나가는 방식으로 진행했습니다. 무엇을 어떻게 해야 할지가 명확했고, 삽질하는 시간의 낭비가 적었습니다. 프로젝트가 이전보다는 체계적으로 진행되니 스스로 뿌듯하고 자랑스러웠습니다.

하. 지. 만!

기획을 마무리하고 각자의 파트로 가서 코드를 짜기 시작했습니다. 저번 프로젝트보다 사이즈도 크고, 이전에 경험해보지 못한 새로운 기술을 사용해야 했습니다. 제가 맡은 부분에서는 웹소켓을 이용한 실시간 채팅과 소셜 로그인 기능이 있었습니다. 처음에는 '음 뭔진 잘 모르겠지만 공식문서 보고 따라 하면 어떻게 되지 않을까?' 하고 생각했습니다.

그냥 가져다 쓰면 될 것 같다라... 어림도 없지!

한 예로 Socket.io를 이용해 실시간 채팅을 구현하려고 했었습니다. 구글링을 했을 때 실시간 채팅을 구현하는 데 있어서 대부분이 Socket.io를 이용하여 실시간 채팅을 구현하길래, 나도 비슷하게 만들면 되지 않을까? 하는 안일한 생각을 했습니다.
문제는 예제를 로컬에서 테스트하고 실제로 배포서버에 올렸을 때 발생했습니다. 로컬에서 테스트할 때는 로컬 내부에서만 작동하기 때문에 예제 코드가 별 이상 없이 작동한 것 같지만, 실제 배포서버에서는 채팅은커녕 클라이언트와 연결조차 되지 않았습니다. 찾아보니 클라이언트와 서버에서 서로 다른 방식(polling, websocket)으로 송, 수신을 하고 있었고 웹소켓에 대해 기본적인 지식을 익히고 나서야 문제점을 파악해서 디버깅할 수 있었습니다.

순조로운듯한 시작에서 절반도 채 지나지 않아 저의 부족한 점이 쏟아져 나왔습니다. 개발자는 자신감 있는 동시에 항상 겸손하는 태도를 가져야할 것 같습니다. 알고 있다고 생각해도 항상 겸손한 태도로 탐구하고, 개발할 때는 무엇이든 만들 수 있다는 자신감을 가지고 개발을 하면 언젠가 또 발전한 제 모습을 발견할 수 있지 않을까 하는 기대를 해봅니다.

소통은 아무리 많이 해도 지나치지 않다!

문서화를 잘하자!

팀 단위로 프로젝트를 하면 가장 중요한 것 중 하나가 소통이라는 것은 누구나 공감하실만한 내용이라고 생각합니다. 각자의 포지션과 역할이 정해져 있고, 우리는 여러 명이서 공동된 목표를 가지고 하나의 프로덕트를 완성해야 합니다. 각자가 다른 역할을 가지고 그것을 조합해서 하나의 프로덕트를 만들려면 모든 것이 맞물려 돌아가야 합니다.

사실 소통에 대한 중요성은 이전부터 느껴왔습니다. 하지만 프로젝트 기간이 길어지고, 규모가 커질수록 각자의 진행 상황이나, 의견에 대한 공유가 점점 중요해졌습니다. 코드를 짤수록 각자 자기만 아는 파트가 많아지기 마련인데, 각자 작성한 코드가 서로 소통해야 하기 때문에 우리는 매일 코드 리뷰를 했습니다. 어떻게 보면 코드 리뷰는 굉장히 귀찮은 일입니다. '각자 맡은 부분이 작동만 잘해서 잘 돌아가면 된 거 아닌가?' 하는 생각이 들 수도 있지만, 각자의 코드가 어떻게 돌아가는지 코드를 작성한 본인만 알고 있다면 예기치 않은 문제가 발생할 수 있습니다. 단순한 예를 들자면, 어려움을 겪어 팀원에게 도움을 청해도 코드가 어떻게 돌아가는지 모르고, 어디가 어디서부터 잘못됐는지 알 방법이 없기 때문에 도와주고 싶어도 도와주기 어려운 상황이 됩니다.
그렇기 때문에 우리는 프로젝트를 진행하면서 끊임없이 소통해야 합니다. 우리의 프로젝트가 마치 한 사람이 작성한 코드처럼 짜여있다면, 잘 알아볼 수 있게 코드를 작성했다는 가정하에 누가 코드를 보더라도 전체적인 작동 방식을 그리는데 큰 어려움은 없을 것입니다.

비록 수강생 4명이서 한 달간 진행한 프로젝트가 프로덕트 레벨의 서비스에서 보면 정말 별것 아닐 수 있지만, 저희가 진행한 프로젝트의 규모에서조차 가장 중요한 요소는 소통일 정도로 정말 소통의 중요성을 다시 한번 체감할 수 있었습니다.
그리고 소통을 아무리 자주 하지만 놓치는 부분이 있을 수 있어 계속해서 체킹 하는 것이 필수입니다. 프로젝트를 진행하면서 백엔드 개발자로서 실수했던 부분이 있었습니다.

저기... API 문서대로 작성했는데 제대로 작동이 안 되는데요?

저 말을 듣자마자 '아! 깜빡하고 API 문서 수정 안 했구나!' 하고 생각이 들었습니다. API에 수정사항이 생기면 API 문서를 수정해줘야 하는데 문서에 대해 크게 생각하지 않고 있어서 프론트엔드를 맡은 팀원이 코드를 수정하는 일이 있었습니다. 프론트엔드는 API 문서만 보고 코드를 작성하는데 제대로 작동 안 하면 정말 난감합니다... 문서가 잘못된 건지 서버 코드가 잘못된건지 알 방법이 없습니다.
그다음부터는 계속해서 문서화에 신경 쓴다고 했지만 몇 번 더 이런 일이 발생했습니다.

앞으로 백엔드 개발자로서 개발을 진행할 때는 API 개발 루틴을 짜고 체크리스트를 통해 수정한 내용이 모두 반영됐는지 확인을 해야 할 것 같습니다.

문서는 팀원 전체가 공유하는 소통의 창구로써, 중요도에 맞는 신뢰도 있는 문서를 만드는 것이 원활하게 팀 프로젝트를 진행하는 첫걸음이 아닐까 생각해봅니다.





길다면 길고 짧다면 짧은 한 달의 기간이 쏜살같이 지나가고, 지금 현재는 수료생으로써 회고하는 글을 써보았습니다. 프로젝트를 진행하며 스트레스도 많이 받았지만, 그 이상으로 정말 많은 것을 배우고 또 재미있게 진행했던 것 같습니다. 회사가 될지, 또 다른 팀이 생길지는 모르겠지만 앞으로 다시 만나게 될 팀 프로젝트가 기대됩니다.

profile
제 코드가 세상에 보탬이 되면 좋겠습니다.

0개의 댓글