BE 개발자로서 FE와 첫 협업 프로젝트
3주간의 주특기(node.js) 학습을 끝내고, 이번주에는 드디어 처음으로 FE와 BE로 역할을 명확히 구분해서 프로젝트를 진행하게 되었다. FE와 BE로 역할이 명확히 구분해서 프로젝트를 진행한다는 것 자체에서, 내가 점점 더 한명의 BE 개발자가 되어가고 있음을 느낄 수 있어서 매우 뿌듯했었다.
1주일 간 진행된 프로젝트에서는 BE 관점에서 달리 새로운 기술, 스택을 적용해보지는 않았다. 왜냐하면, FE와 BE로 역할이 구분된 상황에서 한 명의 BE 개발자로서 FE와 소통하는 방식, 함께 문제를 해결해나가는 방식, FE의 요청을 적용해서 디버깅을 하는 방식 등 FE와의 협업 방식을 배우고 고민하는 것 자체만으로 많은 시간이 할애될 것이라 생각했기 때문이다. 프로젝트를 진행하면서, FE와 효율적인 협업을 위해 우리 팀이 도입했던 방식은 다음과 같다.
1) API 명세서 꼼꼼하게 작성하기.
프로젝트의 주제와 와이어프레임을 결정한 이후에는, 각 와이어프레임마다 필요한 기능들을 분류하고, 각 기능들을 다시 API로 정리해서 API의 method, request, response를 꼼꼼하게 분석하고 정리했다. 서버를 개발하는 과정에서 request나 response가 추가/삭제되는 내용들이 있었는데, 그때마다 API 명세서를 수정해서 FE 측에 공유해주었다.
2) 합의된 API 명세서를 기준으로 API 개발.
한 명의 BE 팀원으로서 프로젝트에서 협업하는 대상은 비단 FE뿐만이 아니라, 함께 서버를 개발하는 BE 팀원도 해당했다. 이 전까지는 나 혼자 BE, FE를 모두 개발하는 것만 경험했기 때문에, 개발 과정에서 변수명이나 API URI를 자율적으로 변경했었다. 하지만 협업 프로젝트는 혼자서 진행하는 것이 아니기 때문에, 개발 과정에서 세세한 변경 사항들을 변경 이유와 함께 팀원들에게 즉각적으로 공유하도록 노력했다. 팀원들이 내가 변경한 사항을 인지하고 있지 못하면, 각자 개발한 API들을 합쳤을 때, 엄청난 양의 버그가 발생할 수 있기 때문이다.
아직 미숙해서 그런지, BE 서버를 배포한 이후에도 코드를 변경해야하는 상황이 빈번하게 발생했다. 그럴 때에는 BE 팀원들과 직접 EC2 instance 서버에서 vi 편집기를 이용해서 변경해야할 내용을 살펴보고, 즉각적으로 FE의 요구사항에 맞춰서 코드를 변경하는 방식을 채택했다.
3) 기능별 branch에 git push, pull request는 함께
BE 팀원들 간에 API 구현 전에 협업 rule을 정했다.
- 먼저, 기능에 따라서 API를 카테고리화 해서, 카테고리를 기준으로 각자가 구현해야하는 API를 분담했다. 게시판 사이트를 예로 들자면, 회원가입/로그인 - 게시물 CRUD - 댓글 CRUD와 같이 역할을 분담한 것이다.
- 각자 기능 개발이 완료된 이후에는 프로젝트 BE repository에 각자 API 카테고리명의 branch로 소스코드를 업로드하였다. 이를 통해, 각 기능의 개발이 어디까지 이루어졌는지를 한눈에 확인할 수 있었다.
- 모든 API가 구현된 이후에는 팀원들이 함께 모여 Pull request를 진행했다. 각자가 구현한 API를 합치는 과정에서 사소한 오류, 오타 하나라도 간과한다면 매우 큰 문제가 발생할 수 있기 때문이다.
이러한 기본 rule을 정하고 API 구현에 착수했기 때문에, 서버 개발은 정말 순조롭게 할 수 있었다.
3) 배포 후에는 FE에 swagger로 최종 API 명세서 전달
위에서 언급한 것처럼, BE 서버를 배포한 이후에도 코드를 변경해야하는 상황이 빈번하게 발생했지만, 우리 팀은 BE 서버를 배포한 이후에는 swagger라는 서비스를 이용해서 최종적인 API 명세서를 전달드렸다. 기존 API 명세서는 서버 개발 이전에 notion 작성한 것이기 때문에, 배포 이후 API의 내용과 조금이라도 내용이 다를 가능성이 있었기 때문이다.(물론 그래서는 안되지만)
swagger는 swagger-autogen이라는 라이브러리와 함께 이용하면, 현재 작성된 모든 API 코드를 참조해서 매우 깔끔한 API 명세서를 자동으로 제작해주기 때문에, 사람이 직접 손으로 API URI, request, response를 작성한 API 명세서보다 더 정확하고 가독성이 높다고 생각한다.
4) 아쉬웠던 점
Commit은 되도록 자주하는 것이 좋다.라는 말을 얼핏얼핏 들어왔는데, 그 말의 의미를 느낄 수 있었다. Commit을 자주할수록 좀 더 세부적인 단위로 프로젝트 버전관리를 할 수 있기 때문이다.
다음 프로젝트부터는 팀원들과 한 기능을 구현할 때마다 Commit을 하도록 제안해야겠다는 생각이 들었다.- API 명세서 작성과 관련해서, notion보다는 swagger를 이용하는 것이 더 효율적이라는 것을 경험할 수 있었다. 그래서 API 소스가 작성되지 않은 시점에서 swagger를 어떻게 사용해야 API 명세서를 작성할 수 있을지를 공부해야 할 필요성을 느꼈다. 이를 깨닫기만 한다면, 좀 더 document를 중심으로 FE와 효율적으로 소통할 수 있을 것이란 생각이 들었다.
