배포되기 전까지 개발은 끝나지 않는다

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

코드를 작성했다고 기능 개발이 끝나는 것은 아니다. 운영 브랜치에 머지했다고 끝나는 것도 아니다. 라이브 서비스에 배포하고 그곳에서 제대로 동작하는지 확인해야 비로소 끝난다. 이 단계 사이에서 작업을 오래 묵힐수록 무엇이 유효하고, 무엇을 안전하게 내보낼 수 있으며, 결과를 누가 책임지는지 알기 어려워진다.

그래서 오래 열린 PR, 방치된 브랜치, 개발 환경과 운영 환경 사이에 쌓인 큰 차이는 단순히 저장소가 지저분하다는 문제가 아니다. 회사의 자산인 프로젝트가 제대로 관리되지 않고 있다는 신호다.

진행 중인 작업만 활성 상태로 남겨라

PR을 오래 열어 두어야 할 타당한 이유는 있을 수 있다. 특정 시기에 배포해야 하거나 아직 완료할 일이 아니라면 그 상태를 명확히 드러내야 한다. 일반적인 리뷰 요청을 몇 주씩 방치하지 말고 드래프트로 표시하는 등 지연의 이유를 알 수 있게 관리한다.

작성자가 다른 팀으로 옮겼는데도 남아 있는 오래된 PR은 성격이 다르다. 사실상 죽은 작업이지만, 저장소를 보는 사람마다 아직 필요한지 다시 판단하게 만든다. 머지한 브랜치를 지우지 않고 미사용 브랜치까지 계속 쌓이면 모호함은 더 커진다. 수십 개의 브랜치와 1년 된 PR이 남은 저장소에서는 팀이 실제로 배포할 수 있는 작업을 직관적으로 파악하기 어렵다.

활성 브랜치와 PR을 주기적으로 살펴야 한다. 중단된 작업은 닫고 브랜치도 함께 지운다. 팀의 절차에 맞는다면 머지 후 브랜치를 자동으로 삭제하는 저장소 설정도 활용할 수 있다. 이런 정리는 외관을 꾸미는 일이 아니다. 새 작업을 더하기 전에 프로젝트의 현재 상태를 다시 믿을 수 있게 만드는 일이다.

배포하지 못할 커밋이 뒤의 작업을 붙잡게 하지 마라

더 심각한 문제는 개발 브랜치가 운영 브랜치보다 지나치게 앞서 나갈 때 생긴다. 수십 개의 커밋이 기다리고 있으면 다음 배포에는 성격이 다른 많은 변경이 한꺼번에 들어간다. 누구도 선뜻 배포하고 싶지 않은 상태가 되고, 그 불안 때문에 배포가 다시 늦어진다.

릴리스 전략에 따라 예외는 있다. 별도의 릴리스 브랜치를 만들어 내보내는 팀도 있을 수 있다. 그러나 개발 브랜치에서 운영 브랜치로 바로 배포하는 흐름이라면, 아직 나가면 안 되는 코드를 그 경로에 넣지 않는 편이 맞다. 다음 주에 배포할 변경 하나가 오늘 내보낼 수 있는 뒤의 커밋을 전부 막을 수 있다. 마침내 배포할 때는 버그나 장애가 미칠 범위조차 예측하기 어려워진다.

이런 팀에는 명시적인 배포 리듬이 필요하다. 모두 대응할 수 있는 주초에 정기적으로 배포할 수도 있고, 합의한 만큼의 작은 변경이 쌓이면 배포한다는 규칙을 둘 수도 있다. 정확한 개수는 변경의 크기에 따라 달라진다. 중요한 것은 팀이 이해하고 운영할 수 있을 만큼 배포 묶음을 작게 유지하는 것이다.

큰 배포 묶음은 진단과 롤백 비용을 키운다

100개 파일을 바꾸는 리팩터링을 생각해 보자. 작성자는 기능을 바꾸지 않았다고 확신해 배포를 미룬다. 그 위로 다른 개발자들의 기능 작업이 이어진다. 누군가 실제 배포를 시도할 때는 변경 파일이 160개가량으로 늘어나 있다.

그 배포 뒤 로그인이 되지 않거나 고객의 로그인이 모두 풀린다고 해 보자. 같은 영역을 리팩터링과 후속 기능이 연달아 수정했기 때문에 원인을 찾기 어렵다. 뒤에 포함된 기능이 당일 고객에게 제공하기로 약속한 것이거나 외부 사용자가 꼭 써야 하는 기능이라면 전체 롤백도 부담스럽다. 이전 운영 버전으로 돌아간 뒤 급한 기능만 체리픽하려 해도, 그 기능이 대규모 리팩터링 위에서 작성돼 충돌할 수 있다.

더 안전한 방법은 리팩터링을 별도 변경으로 내보내고 작성자가 관찰하며 대응하는 것이다. 그렇다고 아무 때나 무책임하게 배포하라는 뜻은 아니다. 작성자가 다음 날 자리를 비운다면 동료에게 모니터링을 부탁하거나, 대응 시간을 충분히 남기고 일찍 배포하거나, 직접 책임질 수 있을 때까지 기다려야 한다. 무슨 요일인지보다 결과를 지켜보고 조치할 사람이 있는지가 중요하다.

배포도 개발의 일부다

운영 브랜치에 머지한 코드를 2주 동안 배포하지 않았다면 완료한 것이 아니다. 라이브 서비스에는 아직 그 기능이 없기 때문이다. 작은 변경도 대체로 곧바로 배포하고 검증해야 한다. 사소한 변경이라는 사실은 다음 큰 배포에 숨겨 둘 이유가 아니라 빠르게 확인할 수 있는 이유다.

배포를 미루는 마음 아래에는 불안이 자리한 경우가 많다. 테스트와 지속적 통합이 예상 가능한 동작을 확인해 주면 그 불안을 줄일 수 있다. 물론 운영 모니터링까지 대신해 주지는 않는다. 운영까지의 경로가 짧을수록 결과를 관찰하기 쉽고, 실패 지점을 찾기 쉬우며, 롤백의 영향도 판단하기 쉽다.

실천할 일은 단순하다. 의미 있는 브랜치만 활성 상태로 유지하고, 묵은 PR은 처리하거나 제거하며, 변경을 적절한 시점에 머지한 뒤 배포까지 가져간다. 눈에 보이는 저장소의 상태와 실제 운영 상태가 일치하고 모든 변경이 서비스까지 이어지는 분명한 경로를 가질 때 프로젝트는 회사의 자산으로 계속 쓸 수 있다.