By Sohyun Lim — Mar 16, 2025

작은 회사의 개발 프로세스 만들어가기

현재 재직 중인 회사에 다닌 지 이제 1년 9개월이 되어 가고 있다.

돌이켜보면 작년 1분기만 해도 코드 리뷰, 테스팅, 배포 후 클린업 등 여러 프로세스가 제대로 정립되지 않았던 것 같다. 어떤 티켓들은 너무 사소해 보여서 이런 것도 리뷰 요청을 해야 하나 싶기도 했고, 개발 과정 중 임시로 테스트용으로 만든 데이터 테이블을 프로젝트가 끝난 후 정리하지 않아 리소스가 낭비되는 일도 종종 있었다.

하지만 팀이 조금씩 커지면서 개발 프로세스와 문서화 포맷이 점차 개선되었고, 여전히 개선의 여지는 있지만 확실히 개발 과정에서 많은 부분이 더 효율적이고 안정적으로 진행되고 있다고 느끼고 있다. 이에 대해 어떤 개발 프로세스와 규칙을 갖고 있는지 공유하고자 한다.

Jira Ticket을 기준으로 보는 개발 프로세스

Design First Approach

'디자인 우선'은 개발 팀의 핵심 원칙 중 하나로, 불필요한 재작업을 방지하고 좋은 의사결정과 커뮤니케이션을 촉진한다. 코드를 작성하기 전에 다음을 고려해야 한다:

end-to-end를 고려하기
기존 코드와 프로세스를 검토하여 어떻게 개발하는 것이 적합할지 확인한다
개발자는 생각을 단계적으로 정리하면서 불확실한 점이나 의문을 해결할 수 있도록 한다. 개발 전 디자인 관련해서 필요한 모든 질문들을 리스트업 하고, 작은 부분이라도 명확하지 않은 부분이 있다면 또한 리스트업해서 PM과 clarify해야 한다.
팀원들과 디자인 리뷰를 진행한다
원본 Jira 티켓을 업데이트하여 추가사항이나 변경사항을 반영한다.

작은 작업의 경우에는 3-4단계가 필요하지 않을 수 있다. 이는 담당하는 개발자 및 PM이나 Mid/Senior 개발자가 가 판단하여 결정할 수 있다.

디자인 리뷰

Jira에 티켓이 할당되면 1) 담당할 개발자 2) Mid/Senior 개발자 3) 티켓을 생성한 사람 (대개 PM)은 디자인 리뷰 세션을 갖는다. 이 미팅은 어레인지하는 건 개발을 담당할 개발자의 책임이다.

개발자는 스토리 및 티켓 내용을 패러프레이즈하여 PM의 요구사항을 정확히 이해했는지 확인한다. 디자인의 유효성을 검토하고 구현을 위해 해결해야 할 부분을 파악한다. (예를 들어 현재 회사에서 사용하는 라이브러리나 디자인 시스템에서 지원 가능한지 등)

티켓 관리

모든 작업은 Jira 티켓을 통해 관리되며, 티켓이 할당되면 작업을 진행한다. 티켓은 항상 최신 상태로 유지되며, 디자인 결정 사항이 변경되면 해당 사항을 업데이트한다. 이를 통해 테스트 단계에서도 최신 요구사항을 반영한 테스트가 가능하도록 한다.

Sub-task

규모가 큰 티켓은 서브태스크로 나눌 수 있으며, 서브태스크는 명확한 목표(결과물)이 있고 테스트가 가능한 단위여야 한다. 개발자가 작업하기 적절한 사이즈로 태스크를 쪼개는 것도 이에 해당하며, 서브태스크에는 Data Discovery나 기술적인 스파이크도 포함될 수 있다.

(agile dictionary에 따르면, 기술적 스파이크는 Deliverable한 제품을 생산하는 것이 아니라 질문에 답하거나 정보를 수집하는 것을 목표로 하는 작업이다. 개발팀이 기술적 질문이나 디자인 문제를 해결하기 위해 실제 작업을 수행할 때까지는 잘 추정할 수 없는 부분을 탐색하는 작업이기도 하다)

코드 리뷰

코드 리뷰는 merge 전에 Mid/Senior 개발자와 함께 진행해야 한다. 이상적으로는 초기 디자인 리뷰에 참여한 Mid/Senior 개발자가 리뷰를 진행하는 것이 좋다.

Pull Request

코드가 준비되었을 때 새로운 Pull Request(PR)를 만든다. PR은 협업을 촉진하고 피드백을 받을 수 있으며 그 자체로 프로젝트에 통합되는 기능에 대한 기록 역할을 한다. 그렇기에 PR또한 하나의 문서라 생각하고 다른 문서와 마찬가지로 규칙을 따라야 한다.

제목: 간결하지만 이 PR에 포함된 기능을 알 수 있도록 충분히 설명적인 제목을 작성한다. 예: "World Clocks", "Routing Bug Fix"
설명: 접근 방식, 리뷰어를 위한 고려 사항을 간략히 설명한다. 만약 관련해서 작성한 문서가 있다면 링크를 포함한다. (티켓 번호가 브랜치/커밋에 포함되면 PR에 자동으로 티켓이 연결되도록 설정해뒀기 때문에 티켓 링크는 명시적으로 포함시키지 않아도 된다)
자체 리뷰 : PR을 올리기 전 코드를 작성한 개발자가 자체적으로 리뷰하는 시간을 가져야 한다. 가능하면 개발 후 잠시 시간을 두고 리뷰한다. (차 한 잔 마시고 오든지... 살짝 머리를 식히고 나서 내가 코드를 다시 본다) 이전 리뷰에서 지적된 실수나 silly mistakes를 줄이고, 앞서 언급한 규칙들이 지켜지도록 하기 위한 단계이기도 하다.
리뷰어 할당 : 코드 리뷰를 받을 준비가 되었을 때 리뷰어를 지정한다. 마지막으로 Jira에서 티켓을 'Ready for Code Review'로 이동시키고 주요 리뷰어에게 할당한다.

코드 리뷰 완료 후

코드 리뷰가 완료되면 Mid/Senior 개발자가 머지 및 배포를 진행하고 티켓을 'Ready for Test'로 이동시키고 테스트할 사람 (대개 PM)에게 할당한다.

테스트 인수인계

티켓이 'Ready for Test'로 이동되면 PM에게 할당된다. PM과 테스트에 대해 논의하고, 테스트에 필요한 사항(예: 문제, 제한 사항, 테스트 방법)이 있다면 공유한다.

Cleanup

기능이 프로덕션에 배포되면 PM이 이를 'Clean Up'으로 이동시키고 원래 개발자에게 다시 할당한다. 이는 티켓을 'Done'으로 설정하기 전 마지막 단계로, 이후 발생할 수도 있는 문제나 이로 인한 불필요한 작업을 줄이는 데 도움을 준다. 진행해야 할 단계는 다음과 같다 :

더 이상 사용하지 않는 데이터셋 삭제(삭제 전 테스트/개발/프로덕션/문서에서 사용되지 않는지 확인하기)
dd/dev 파이프라인 끄기 - 불필요하게 데이터가 계속 ingest되지 않도록 한다
더 이상 사용하지 않거나 유효하지 않은 오래된 appConfig가 있다면 삭제
관련된 문서를 정리하고 적절한 폴더에 옮기기
개발 지원 문서(support notebook) 에 관련 정보/새로운 기능에 대한 내용 추가
- 모든 프로젝트는 프로젝트를 개발하는 데 필요한 중요한 정보를 전달하는 support notebook을 가져야 한다.
관련 팀원들과 회고 어레인지 (모든 티켓에 대해 진행할 필요는 없고 티켓 크기에 따라 PM, Delivery Lead와 필요 여부를 정하고 진행한다)
필요시 와이어프레임이나 기획 문서 업데이트 (개발 과정에서 변동된 부분이 있다면)

전체적인 흐름도는 다음과 같다.

개발 프로세스가 정립되는 중이지만 여전히 이런저런 시행착오를 겪고 있다. 아직 support notebook에 대한 포맷이 없기에 앞으로 이 부분을 만들어가는데 조금 기여해볼 수 있지 않을까 하고 호시탐탐 기회를 보고 있다.

다음에는 좀 더 구체적인 개발/문서화 관련 컨벤션에 대한 이야기를 다뤄보려 한다.