팀 프로젝트를 하며 느낀 점들

그동안 디자인이나 기획 직군과 같이 일해본 적이 없어서 팀 프로젝트 경험을 해보고 싶었다. 그러던 중 스위프라는 사이드 프로젝트 플랫폼을 통해 몇 주간 팀 프로젝트를 해볼 수 있었다. 프로젝트 종료 후 복기하면서 공유하고 싶은 경험을 정리했다.

API는 프론트쪽과 공유해야할 것만 만들자

• 프론트 쪽에서 호출할 필요 없다고 결론내렸지만 컨트롤러 레이어까지 구현한 API가 몇 개 있었다
• 당시엔 API를 호출하는 방식을 제외하곤 엔드포인트부터 DB까지 모든 레이어를 통과하는 경우를 확인할 방법이 마땅히 떠오르지 않았기 때문이다
• 팀원과 논의할 때 이야기한 부분이었지만, 제대로 전달이 되지 않았는지 다른 백엔드 팀원이 작업한 API 중에 프론트에서 (내가 어설프게 만들어놓은) API를 호출해야 하는 것이 생겼다
• 프론트 쪽에선 어설픈 API 구현체를 쓰게 되었고, 구현 당시에는 생각하지 못했던 조건 처리가 제대로 안되어 있어서 프론트와 연결 작업이 제대로 되지 않기도 했다
• 만약 해당 API를 커밋하지 않았거나, 적어도 PR이 끝나기 전에 삭제했다면 이런 일은 일어나지 않았을 것이다
• 바깥에 내보일 API가 아니라면 애초에 내보이지 말았어야 했다

작업에 연관된 사람과 그 작업에 얽힌 작업이 많을수록 추후 수정이 어렵다

• API 일부를 RESTful하게 설계하지 않았다는 걸 뒤늦게 발견했다
• 고치려고 보니 이미 프론트 쪽에서 해당 API 연결 작업을 해놓은 상태였다
• API를 수정하게 되면 프론트 쪽 코드도 바뀌어야 했고, 그건 다른 작업이 더 뒤로 미뤄진다는 걸 뜻했다
• 우리의 작업 우선순위를 따져봤을 때, API 수정보다 먼저 해야 할 작업이 있었고, 결국 API를 RESTful하게 수정하는 건 더 뒤로 미뤄졌다
• 끝내는 백엔드 팀 내에서 API 수정 논의*만 이뤄진 채 프로젝트가 종료되었다
• 뒤늦게 뭔가를 바꿔야 한다는 걸 발견했을 때, 그 변경에는 나뿐만 아니라 다른 직군의 작업까지 포함된다는 걸 염두하고 있어야 했다

문화 도입은 도입만으로는 부족하다

• 프로젝트를 시작하면서 나는 코드 리뷰 문화 도입을 제안했다
• 대부분 온라인에서 비동기로 논의했기 때문에 의견을 나누고 요청한 변경 사항을 반영하는 데 오랜 시간이 걸렸다
• 코드 리뷰는 결과적으로 좋은 경험이기도 했지만, 그만큼 내 시간을 많이 써야 해서 나중에 가서는 체력적으로 지쳤다
• 내가 담당하는 기능을 구현하는 시간에 다른 사람 코드를 보는 시간도 써야 했기 때문이다
• 문화를 도입하는 건 좋았지만, 그걸 지속하려면 그 문화를 지켜나가기 수월하게 할 방법을 같이 생각해볼 필요가 있었다

제한된 자원 내에서 작업을 끝낼 수 있는 방안을 고민하자

• 두 가지 리소스 각각에 대한 CRUD API를 구현해야 했다
• 리소스별 API 중 다른 리소스에 대한, 아직 구현하지 않은 서비스 로직을 써야 하는 것이 예상되었다
• 한 사람이 모든 API를 맡아 구현하는 의견이 있었지만, 팀원의 개발 속도와 일정을 고려했을 때, 작업을 분배해야 했다
• 그래서 다음과 같은 아이디어를 냈고, 작업을 분배해서 구현했다**
• API 구현에 필요한 모든 서비스 로직의 인터페이스를 먼저 논의했다
• 작업하면서 다른 리소스의 서비스 로직이 필요할 경우, 미리 정의한 인터페이스를 기준으로 작업했다
• 작업을 합치기 전까지 해당 서비스 로직의 반환값은 픽스쳐 데이터로 대신하고, 작업을 합친 후 실제 서비스 로직을 호출하도록 바꿨다
• 비록 제한된 자원 내에서 작업을 잘 마무리했지만, 병목이 생기고 있다는 걸 미리 알아차리고 대응했다면 굳이 고민할 필요 없는 문제였다

참고자료

• * RESTful API 수정 논의
• ** 분배한 작업 중 내가 맡은 부분