팀 프로젝트 - 기본 설계, API 명세서 제작

팀 프로젝트를 주도하고 처음 계획을 짜며 가장 신경 쓴 부분 중 하나는 애자일 개발이다.

애자일 개발

빠르게 진행되는 프로젝트 주기를 반영하는 적응형 프로젝트 관리 시스템

애자일 vs 워터폴

특성	애자일	워터폴
접근 방식	반복적, 증분적	순차적, 선형적
유연성	높음	낮음
고객 참여	지속적	주로 초기와 말기
요구사항 변경	수용적	제한적
제품 전달	주기적 배포	프로젝트 종료 시
테스팅	각 반복마다	개발 후 단계
문서화	간소화	상세함

처음부터 모든 명세가 변하지 않고, 오로지 구현만 남았다면 워터 폴 방식도 유용할 것이다. 그러나 주니어 단계의 팀 프로젝트에서는 사실상 어려운 방식이다. 요구사항의 변경을 수용적으로 다룰 수 있고, 프로젝트의 배포가 주기적으로 이루어지는 방식을 선호할 수밖에 없다.
애자일 개발의 기본은 계획 → 설계 → 개발 → 테스트 → 검토 의 반복이다. 이러한 반복 속에서, 프로젝트는 완성을 거듭한다.
실제로 실무에서도 애자일 방법론을 다루었으므로, 이번 주니어 개발자들끼리의 팀 프로젝트 또한 애자일하게 진행하고자 한다.

UI 시안 제작

처음부터 바로 피그마로 작업을 진행하려 했으나, 백엔드 측에서 바로 최소한의 UI만 보고 API부터 만든 뒤 작업을 진행하자는 팀원의 제안이 들어왔다. 합리적이고 애자일한 제안이었다. 간단하게 그림을 그리고, 프론트엔드 팀원과 함께 헤더 추가, 버튼 위치 등의 수정 과정을 거쳐서 시안을 제작했다.

UI는 트리플, 스레드, 무신사 등 여러 레퍼런스를 참고해, 가장 프로젝트와 적합한 디자인을 선별하고자 하였다.

API 명세서 제작

기본적인 문서 제작부터 시작한 이유는, 기준점이 있어야 프론트와 백이 유연하게 협동할 수 있기 때문이다. 알고리즘 문제에서 코드 완성 전 단계에서 기획을 먼저 하는 것과 같은 원리이다.

첫번째 애자일 사이클을 로그인과 게시판 CRUD의 완성으로 잡았으므로, API 명세서 또한 최저한의 API만 다루고 있다.

API 명세서 문서를 제작하며, request body와 request parameter, path value를 구분하여 작업을 진행했다. 처음부터 해당 부분의 기틀을 잡아놓는다면, 추후 프론트와 백 양쪽에서 유용하게 쓰일 것이다.

response를 작성할 때에는 추후 추가하고 싶은 최적화 기능인 무한 스크롤을 염두해두고, postIndex와 postId를 추가하였다. 모든 기능을 추가할 필요는 없지만, 기본적인 틀을 갖춰둔다면 바로 다음 단계에 돌입하기 쉬워진다.

후기

성실하고 착실하며 열의 넘치는 팀원들과 빠르게 일을 진행할 수 있어 좋았다. 설계를 마쳤으니 개발 단계에 돌입할 때에도 충분히 잘 진행할 수 있을 것이다.