이슈 상황
클라 팀에서는 API의 Request와 Response 타입을 프론트엔드와 백엔드 팀원이 각각 다르게 작성하고 있었습니다. 업무는 다음과 같은 방식으로 진행되었습니다:
- 백엔드에서 API를 완성한 후 Postman을 통해 프론트엔드에 공유합니다.
- 프론트엔드는 Postman의 example을 통해 타입을 확인하고 필요 시 추가 필드나 적절한 타입을 구두나 Slack을 통해 공유합니다.
이와 같은 방식으로 타입이 관리됬을 때, 다음과 같은 문제가 발생하였습니다:
- 특정 API의 Request와 Response 타입이 서로 상이한 경우가 생깁니다.
- 프론트엔드와 백엔드에서 공통적으로 사용할 수 있음에도 불구하고 각각 타입 작업을 진행하면서 작업 비효율이 발생합니다.
- API의 Request와 Response 타입이 수정될 경우, 프론트엔드와 백엔드 모두 수정이 필요하며, 한 곳에서 타입이 변경되지 않아 이를 디버깅하는 데 시간이 소요되는 경우가 발생합니다.
Git Submodule 도입
이전 팀에서 Git Submodule을 사용해 공통 타입을 관리한 경험이 있었습니다. 이를 통해 프론트엔드 개발자와의 커뮤니케이션과 작업 효율성이 크게 향상된 것을 느꼈기 때문에, Git Submodule 도입을 추진하였습니다.
Git Submodule을 활용한 깃허브 협업 플로우
📚 게시글 작성 API 구현 예시 (이해를 돕기 위한 예시입니다.)
백엔드 개발자
-
서브모듈의 main 브랜치를 최신화하고 feature 브랜치를 생성합니다.
-
게시글 작성 기능 구현을 위해 필요한 타입 작업을 완료한 후, PR을 생성하고 코드 리뷰를 진행합니다.
-
해당 타입을 사용하여 기능을 구현합니다.
프론트엔드 개발자
-
백엔드 개발자가 요청한 코드 리뷰를 진행합니다.
- 코드 리뷰 시, 게시글 작성 기능을 위한 request, response 타입이 올바르게 개발되었는지 확인합니다.
-
타입 관련 PR이 머지된 후, 해당 타입을 사용하여 기능을 구현합니다.
Git Submodule 도입을 통해 얻은 이점
-
모든 팀원이 동일한 타입 정의를 사용하므로, API의 Request와 Response 타입을 일관되게 관리할 수 있게 되었습니다.
-
타입 변경이나 추가가 필요한 경우 PR을 통해 명확하게 커뮤니케이션할 수 있게 되었고, 코드 리뷰 과정에서 타입 정의에 대한 피드백을 주고받을 수 있어 실수를 방지하고 코드 품질을 높일 수 있었습니다.
- 프론트엔드와 백엔드 개발자가 동일한 타입 정의를 공유하므로, 중복 작업을 줄일 수 있게 되었습니다다. 백엔드에서 타입 정의가 변경되면, 프론트엔드에서는 이를 바로 적용할 수 있어 작업 효율성이 높아졌습니다.
- 타입 정의 변경 내역을 PR로 관리하여, 언제, 왜, 누가 변경했는지를 명확하게 추적할 수 있게 되었습니다. 이는 변경 사항을 이해하고, 문제가 발생했을 때 빠르게 원인을 파악하는 데 도움이 되었습니다.
백엔드 개발자