안녕하세요. 이번 글에서는 월급쟁이부자들 기술 조직의 일하는 방식에 대해 설명드리고자 합니다.
<TOC>
스타일가이드
월급쟁이부자들의 주요 개발 스펙입니다.
•
백엔드: Java/Kotlin, Spring Boot
•
프론트엔드: React, Typescript
스타일 가이드는 각 언어 별로 많이 사용하고 있는 코드 컨벤션을 통해 시작 됩니다. 네이밍 방식과 폴더 구조를 포함한 코딩 스타일의 규칙을 정의하고, 월부 팀이 사용하는 방식에 맞춘 업데이트 과정을 거칩니다. 각 스타일 가이드 문서별 담당자는 오너십을 가지고 있지만 업데이트는 모두 함께 진행합니다. 또한 공통적으로 사용하는 패턴과 구조를 논의하고 정의하는 방식으로 확장하여 서로가 학습하고 합의하면서, 월부만의 고유한 스타일 가이드를 진화 시킵니다.
이는 궁극적으로 모든 월부 구성원이 (합의된 그리고) 일관된 코드 스타일을 가지도록 만들어줍니다. 일관된 코드 스타일을 통해 우리는 코드 리뷰를 포함해 신속한 협업을 진행할 수 있습니다.
코드 리뷰
월급쟁이부자들 개발팀의 코드 리뷰 방식 중 가장 중요한 원칙은 동료의 시간을 소중하게 여기는 부분입니다. 따라서 요청자는 반드시 모든 Pull Request에 대해 충분히 설명을 진행하며, 모든 Pull Request에는 반드시 코드 리뷰어를 1명 이상 지정하게 됩니다.
다음은 PR에 반드시 포함되어야 하는 부분입니다.
•
Title : 타이틀에는 PR의 목적이 드러나야 합니다. 여기에는 기능, 버그, 핫픽스 등이 해당 됩니다.
•
Description : 어떤 이슈와 연관 되었는지 링크가 추가되며, 어떤 로직을 추가 혹은 수정했는지 묘사하게 됩니다.
•
Pn룰 활용 : P1부터 P5까지로 구성되는데, P1에서는 반드시 반영되어야 하는 사항을, P5는 사소하지만 공유가 필요한 부분들이 담기게 됩니다.
또한 하나의 PR은 하나의 기능 혹은 이슈를 담고 있어야 합니다. 이처럼 코드리뷰를 진행하며 우리는 코드의 일관성을 달성하는 동시에, 생산성을 해치지 않는 방향을 찾아 극도의 협업을 만들어갑니다.
배포 전략
배포는 Main branch에 푸시할 때 CI/cd를 통해 자동으로 진행됩니다. dev에서 branch를 따서 작업을 한 다음 dev → staging branch 순으로 병합합니다. dev branch는 dev 서버에 자동으로 배포되며 개발자가 테스트를 하게 됩니다. staging에 푸쉬를 하면 staging 서버에서 자동으로 배포가 되고 QA가 테스트를 진행하게 되는데 그 전에 코드 리뷰를 통해 병합 유무를 판단합니다.
이후 완료된 모든 커밋은 main branch에 배포 일정에 맞춰 반영됩니다. 배포 과정은 github action 스크립트가 실행되며 lint 체크가 자동으로 진행된 후 ECS로 배포가 됩니다.
문서화
월부에서는 극도의 협업을 달성하기 위해 공유라는 가치를 매우 중요하게 생각합니다. 또한 공유가 가장 광범위하고 빠르게 이루어질 수 있는 방법 중 하나가 문서라고 생각합니다.
스프린트 내 프로젝트 중 공유가 필요한 모든 문서는 컨플루언스에서 관리됩니다. 예를 들어 앞서 얘기된 스타일 가이드, 리뷰/배포 전략 등을 포함한 각종 SOP(Standard Operating Procedure)들이 공유되어 온보딩 과정에 있는 구성원이 쉽게 문화를 이해할 수 있도록 합니다.
더불어 모든 회의록, A/B 테스트 회고, 스프린트 회고 등 회고 자료들도 공유되어 히스토리로 관리해 업무 상 흐름을 이해할 수 있도록 합니다. 마지막으로 행동양식, 업무 노하우, 개발 지식 등의 성장을 위한 공유로 인해 관심 있는 모든 구성원이 빠르게 지식을 습득할 수 있도록 돕습니다.
지금까지 설명드린 저희 프로덕트 본부의 일하는 방식은 지금도 더 나은 방향성으로 진화하고 있습니다. 시간이 지나며 변화하는 부분 또한 다시 공유 드리겠습니다.
아티클 작성에 참여해주신 분들
•
CTO, Product Division 성주엽
•
Frontend Engineer, Platform team 황태식
•
Backend Engineer, Platform team 정준기