기획을 막 끝냈을 때는 기능 구현 정도는 3주만에 끝나고 2주동안 문서화랑 발표준비하면 되겠구나라고 생각했지만 예상과는 달리 전편에서 얘기했듯이 프론트 인력난으로 인해 대부분의 팀원들이 프론트로 투입되면서 정신없이 진행되었다.
시간안에 끝내지 못하면 남은 기능들만이라도 완벽하게 끝내자였지만, 처음 기획해둔 것을 끝내고 싶은 욕심 덕분에 모처럼 밤을 새어가며 프로젝트를 진행되었다.
처음 포지션은 백엔드였지만 다행히 백엔드 쪽에 든든하게 받혀주고 계신 팀원분 덕분에 인력난이었던 프론트 파트를 적극적으로 도울 수 있었던 거 같다.
나름 결과물은 최선이었다 생각하지만 너무 아쉬웠던 건 나의 발표 .. 마지막까지 뒤늦게 발견된 에러들과 놓친 기능들을 작업한다고 발표 준비를 늦게 시작하였다.
발표 시작 전까지 발표 내용을 정리하고 나니 막상 연습 시간이 30분 정도 밖에 남지않았고, 오랜만의 발표 탓인지 내 발표는 더듬더듬 거리며 끝이났다. ( 팀원들 미안해유...🥲 )
저번 프로젝트와는 달리 사람으로 인해 받는 스트레스는 없었고, 혼자 모른다고 숨어버리는 팀원없이 다들 각자의 어려움과 상황을 자주 공유하고 매일 아침 스크럼을 통해 진행현황을 공유한 덕에 답답함 없이 나름 순조롭게(?) 마무리된 프로젝트라고 생각한다.
백엔드를 희망하지만 프론트 포지션을 함께하면서 오히려 백엔드 입장에서 프론트와 어떤 식으로 협업을 하면 좋을지를 깨닫게 되었고 다음 프로젝트를 할 때 기획단계에서 다른 포지션을 위해 어떤 식으로 문서화를 하면 좋을지에 대해 다시 생각하게 되었다.
API 명세서를 만드는 것은 최소한 데이터를 어떻게 주고 받을 것인지 기획단계에서 정할 수 있는 소통 문서라는 생각이 들었다. 기본적인 틀을 백엔드에서 만들어서 프론트 측에 보여주고 빠르게 피드백을 받기위한 최소한의 소통 문서가 API기획안인 것이다. Readme에도 vm상에 문제가 있을 경우 프론트측에서 개발 진행에 어려움 없이 로컬에서 진행될 수 있도록 꼼꼼하게 기록해두자.
이번 프로젝트에서 아쉬웠던 부분은 백엔드에서 새로운 라이브러리나 최적화와 같은 서버 개발에 대해서 충분한 고민을 하지 못한 점이다.
어찌되었건 프로젝트의 목적 자체가 원활한 협업을 통해 기획단계에서 잡았던 목표를 기간안에 잘 끝내는 것이라 생각하기 때문에 프로젝트는 성공적이었다. (발표빼고)
하지만 개인으로서의 성장은 많이 아쉽다는 생각이들어 추후 토이프로젝트를 통해 익혀나갈 참이다!
