2화.전체적인 개발 프로세스 정의하기

전체적인 개발 프로세스 정의하기

개발 문화가 정립된 조직이라면 누구나 자연스럽게 코드를 작성하고 저장소에 반영하는 일련의 과정을 겪게 된다. 어느 개발 조직이든 비슷하게, 기능이 개발 완료되면 소스는 Git Repository에 푸시되며, 이후 병합 및 배포 등의 단계로 이어진다.

브랜치 전략이나 Git Flow, trunk based 개발 등 이미 정착된 방식이 있다면, 해당 룰은 개발 문화 문서 내에 함께 명시되는 것이 바람직하다. 이처럼 규칙이 문서화되면 신규 입사자나 외부 협력 인력이 들어왔을 때도 빠르게 적응할 수 있으며, 말로 설명하지 않아도 공유된 기준을 통해 일관성 있게 업무를 수행할 수 있다.

이러한 전략은 구성원들과의 합의 아래 정해져야 가장 이상적이다. 그래야만 모두가 자발적으로 문화를 따르고 조직 전체의 생산성을 높일 수 있기 때문이다. 반면, 협업보다 독단적인 방식에 익숙한 구성원이 있다면 이는 ‘조직의 썩은 사과’가 될 가능성이 높아, 주기적인 관찰과 피드백이 필요하다고 본다.

일반적인 개발 프로세스의 흐름

대부분의 조직은 다음과 같은 순서를 통해 개발을 진행한다. 단, 서비스의 성격과 조직 규모에 따라 이 프로세스는 유연하게 조정되어야 하며, 중간에 스펙 변경이나 일정 조정이 발생할 수 있기 때문에 이러한 변수에 대비한 개발 버퍼를 확보해 두는 것이 중요하다.

1. 기획 및 이슈 등록

개발자는 직접 또는 기획자와 협업하여 Jira 페이지에 기능(FEATURE), 버그, 개선안 등을 등록한다.
이슈는 피처 단위로 등록되며, 담당 개발자에게 할당되어 작업이 시작된다.
조직이 크고 부서가 나뉘어 있다면 Jira 클론 기능을 활용하여 부서 간 스펙을 연결하고 참고 문서를 링크하는 방식이 효율적이다.

2. 개발 진행

개발자는 가독성 좋은 코드, 품질 높은 구조를 지향하며 개발을 진행한다.
테스트 가능한 단위로 분리하고, 나중에 리뷰와 테스트가 용이하도록 구조화한다.

3. 코드 리뷰

GitLab의 MR(Merge Request) 혹은 GitHub의 PR(Pull Request)을 통해 작업 내용을 공유한다.
영향도, 테스트 기기, 수정 내역 등을 상세히 기술하며, 이를 위해 .github 폴더 내 템플릿을 활용하는 것이 좋다.
리뷰어는 3인 이상 지정하고, 필요한 경우 관련자도 태그한다.
리뷰 중 이슈가 발견되면 수정 후 다시 푸시하여 리뷰를 반복한다.

4. Push 및 Merge

코드를 푸시하면 GitLab CI/CD나 기타 자동화 시스템이 동작하여 코드 정적 분석 및 테스트를 수행한다.
품질 기준에 위배될 경우 병합은 Fail되며, 개발자가 수정을 거쳐 다시 푸시해야 한다.
리뷰어가 Approve하면 기능이 Git Repository에 머지된다.

이 단계에서 사용하는 정적 분석 도구로는 SonarQube를 예로 들 수 있다. 꼭 필수는 아니지만, 코드 일관성과 정량적 품질을 보여줄 수 있는 유의미한 지표로 기능하기 때문에 도입을 고려할 수 있다.

이슈 토론 및 영향도 조율

기능 하나라도 영향도가 크거나 스펙 변경이 예상된다면 초기 토론 및 일정 조율이 반드시 필요하다. 프로토타입 단계에서는 단순해 보였던 기능이 실제 구현 시 많은 코드 수정이 필요한 경우도 많기 때문이다.

이런 상황에서 개발자가 판단한 영향도에 따라 독단적으로 작업을 진행하는 것은 위험하다. 일정 지연은 물론, 코드 품질과 유지 보수성 모두에 악영향을 미칠 수 있기 때문이다.

이럴 때는 기획자, 리더, 개발자 등이 빠르게 논의 테이블에 모여 토론을 통해 방향을 정리해야 한다. 이를 통해 불확실성을 줄이고, 구성원 간 신뢰와 협업 문화를 동시에 높일 수 있다.

따라서, 개발 일정 산정 시 이슈 정리 및 회의 시간을 포함한 버퍼 확보가 좋은 습관이며, 조직의 생산성을 높이는 지름길이 된다.

마치며

개발 프로세스를 정의하고 문서화하는 일은 개발 문화를 정립하는 가장 기본적인 단계다. 모두가 같은 방식으로 일하고 있다는 믿음은 팀 전체의 신뢰를 높이고, 결과적으로 더 나은 성과를 만드는 기반이 된다.

조직마다 다른 개발 방식과 툴 체계를 가지고 있을 수 있지만, 그 속에서도 공통된 문화와 기준을 세우는 노력이 반드시 필요하다.

다음 편 예고

개발 문화 정립 시리즈 - 3화 : 개발 업무와 관련된 문화 정립하기

일정과 기능만 잘 관리한다고 팀이 잘 굴러가는 것은 아니다.

슬랙, Jira, Notion, 회의 운영 방식 등 개발 업무를 둘러싼 문화는 팀의 속도와 품질을 결정짓는 중요한 요소다.

다음 편에서는 일상적인 개발 협업 환경에서의 커뮤니케이션과 업무 도구 활용 문화를 정리해보려 한다.