트렁크 기반 개발이란 무엇인가

트렁크 기반 개발이란 팀의 모든 개발자가 매일 하나의 공유 브랜치(트렁크, 보통 main이라고 부릅니다)에 코드를 커밋하는 방식입니다. 오래 살아있는 피처 브랜치는 없습니다. 브랜치는 몇 시간 안에 머지하고 바로 삭제합니다. 코드베이스는 항상 배포 가능한 상태를 유지합니다. Google은 3만 5천 명의 개발자를 이 방식으로 운영합니다. 작동 방식, 맞는 상황과 맞지 않는 상황을 모두 살펴봅니다.

"report_v2_FINAL_use_this_one.xlsx" 문제, 이번엔 코드에서

공유 폴더를 열었을 때 report_v1.xlsx, report_v2_FINAL.xlsx, report_USE_THIS_ONE_greg_edits.xlsx가 나란히 있던 경험이 있으시죠? 트렁크 기반 개발이 해결하려는 문제가 바로 이겁니다.

장기 피처 브랜치를 사용하는 팀에서 코드베이스에 똑같은 상황이 벌어집니다. 누군가 1주차에 피처 개발을 시작합니다. 나머지 팀원들은 계속 코드를 배포합니다. 3주가 지나면 그 브랜치는 main보다 수십 커밋 뒤처집니다. 머지는 아무도 하고 싶지 않은 주말 프로젝트가 됩니다. 충돌이 쌓입니다. 코드를 작성한 개발자조차 왜 그 코드의 절반이 있는지 잊어버립니다. 이게 바로 "머지 지옥"입니다.

가장 널리 가르치는 대안인 Gitflow는 별도의 구조로 이 문제를 해결하려 합니다. 피처, 릴리즈, 핫픽스 브랜치를 분리하고 각각에 정해진 수명을 줍니다. 구조는 종이에서 깔끔해 보입니다. 실제로는 브랜치가 공유 드라이브의 스프레드시트 버전처럼 쌓이고, 통합 날은 통합 주간이 됩니다.

트렁크 기반 개발은 반대 입장을 취합니다. 통합 부채를 쌓지 마세요. 오늘 main에 커밋하세요.

모두가 매일 main에 커밋한다, 이것이 전부다

핵심 규칙은 단순합니다. 모든 개발자는 24시간마다 한 번 이상 공유 트렁크에 변경 사항을 푸시합니다. "아직 안 끝났어요"는 예외가 되지 않습니다. 가진 것을 커밋하되, 그것이 빌드를 깨지 않도록 해야 합니다.

이것이 안전한 이유를 이해하면 불안감이 사라집니다.

• 단기 브랜치: 브랜치는 여전히 사용할 수 있지만, 몇 주가 아닌 몇 시간 단위로 유지합니다. 이틀 이상 지속되는 브랜치는 조사할 가치가 있는 경고 신호입니다.

• 모든 커밋에 자동화 테스트: CI 파이프라인이 즉시 테스트 스위트를 실행합니다. 뭔가 깨지면 스프린트 말이 아닌 몇 분 안에 알게 됩니다.

• 피처 플래그: 반쯤 만들어진 피처는 준비될 때까지 토글 뒤에 숨어있습니다. 사용자는 미완성 작업을 볼 수 없습니다. 이미 프로덕션 코드에 있어도 말이죠.

결과는 항상 배포 가능한 코드베이스입니다. "피처 브랜치 머지하고 일주일 QA 하면 배포 가능"이 아니라, 지금 당장 필요하다면 배포할 수 있는 상태입니다. 이것이 근본적인 약속입니다.

단기 브랜치는 주 단위가 아닌 시간 단위로 측정한다

트렁크 기반 개발에서는 브랜치가 금지된 것이 아닙니다. 긴 브랜치가 금지된 겁니다.

오전 9시에 열고, 오전 내내 작업하고, 점심 후 코드 리뷰를 받고, 오후 5시 전에 main에 머지하는 브랜치가 딱 맞는 종류입니다. 팀원들이 작업이 트렁크에 합류하기 전에 리뷰할 기회를 줍니다. 충분히 작아서 한 번 읽으면 이해가 됩니다. 충돌이 있어도 몇 분 안에 해결됩니다.

한 개발자가 3주 동안 전체 인증 시스템을 격리해서 개발하는 브랜치가 문제입니다. 머지할 때가 되면 팀이 피처를 개발하는 데 들인 시간보다 충돌 해결에 더 많은 시간을 씁니다.

대부분의 트렁크 기반 팀이 사용하는 실용적인 기준은 이렇습니다. 브랜치가 이틀 안에 머지되지 않으면 무언가 바꿔야 합니다. 피처가 너무 커서 더 작게 나눠야 하거나, 부분 작업이 안전하게 배포될 수 있도록 피처 플래그가 필요합니다.

작업을 더 작은 단위로 나누는 것이 트렁크 기반 개발이 실제로 키우는 핵심 규율입니다. "전체 대시보드 만들기" 대신 "데이터 레이어 추가", 그 다음 "첫 번째 차트 추가", 그 다음 "필터 연결"을 배포합니다. 각 단계가 트렁크에 머지되고, 테스트되고, 독립적으로 배포됩니다. 전체 피처는 여러 커밋에 걸쳐 점진적으로 완성됩니다.

더 느릴 것 같지만 실제로는 더 빠릅니다. 맥락이 여전히 신선하고 범위가 작을 때 문제를 발견하기 때문입니다.

피처 플래그로 미완성 작업을 안전하게 배포하는 방법

피처 플래그(피처 토글이라고도 합니다)는 단기 브랜치 하나로 피처를 완성할 수 없을 때 트렁크 기반 개발을 실용적으로 만들어주는 메커니즘입니다.

개념은 단순합니다. 특정 플래그가 켜졌을 때만 활성화되는 조건으로 새 기능을 감쌉니다.

if (featureFlags.newReportingDashboard) {
  renderNewDashboard();
} else {
  renderOldDashboard();
}

새 코드는 프로덕션에 배포됩니다. 토글을 켜기 전까지 사용자에게는 실행되지 않을 뿐입니다. 이것이 의미하는 바는 다음과 같습니다.

• 개발자는 진행 중인 작업을 누구에게도 영향 주지 않고 트렁크에 커밋할 수 있습니다.

• QA는 특정 사용자나 환경에서 플래그를 활성화해 프로덕션에서 피처를 테스트할 수 있습니다.

• 출시는 배포 이벤트가 아닌 구성 변경이 됩니다.

• 뭔가 깨지면 롤백이나 핫픽스 브랜치 없이 플래그를 끄면 됩니다.

피처 플래그 인프라는 시작 시 확인하는 단순한 환경 변수부터 전용 플랫폼까지 확장됩니다. 막 시작하는 팀에게는 설정 파일이나 환경별 변수로도 충분합니다. 중요한 것은 도구의 복잡성이 아니라 이 능력 자체입니다.

트렁크 기반 개발이 맞지 않는 경우

직접 말하는 것이 좋겠습니다. 트렁크 기반 개발이 보편적으로 더 나은 것은 아닙니다. 특정 맥락에 맞습니다.

다음에 해당한다면 다른 방식을 고려하세요.

CI/CD 파이프라인이 준비되지 않았다. 모든 커밋에 자동화 테스트 없이 하는 트렁크 기반 개발은 브랜칭 전략이 아닙니다. 빠르게 쌓이는 망가진 코드베이스입니다. 브랜칭 모델이 작동하려면 테스트 인프라가 먼저 갖춰져야 합니다.

팀의 성격상 자주 커밋할 수 없다. 시간대를 넘어 비동기로 일하는 분산 팀이나, 기여자들이 가끔 배치로 제출하는 오픈소스 프로젝트는 매일 커밋하는 리듬에 어려움을 겪을 것입니다.

외부 승인이 필요한 규제 환경이다. 일부 산업에서는 외부 검수, 긴 QA 사이클, 릴리즈 브랜치별 공식 감사 추적이 요구됩니다. Gitflow의 구조화된 릴리즈 브랜치가 이런 워크플로우에 더 잘 맞습니다.

팀의 규율이 아직 갖춰지지 않았다. 트렁크 기반 개발은 main에 대한 모든 커밋이 테스트를 통과하거나 즉시 수정되어야 합니다. 팀이 깨진 빌드를 용인한다면, 공유 트렁크는 모두의 공유된 문제가 됩니다.

Gitflow는 분기별 릴리즈 일정을 가진 팀, 별도 팀이 동시에 여러 피처를 개발하는 경우, 컴플라이언스 요건이 있는 경우에 합리적인 선택입니다. 원칙적으로 어느 쪽이 이기느냐가 아니라, 솔직한 적합성 판단의 문제입니다.

Gitflow에서 트렁크 기반 개발로 위기 없이 전환하는 방법

팀이 Gitflow를 사용하고 있고 트렁크 기반 개발을 시도하고 싶다면, 완전한 전환이 한 번에 이뤄질 필요는 없습니다.

새로운 장기 브랜치 생성을 중단하는 것부터 시작하세요. 결정 이후에 시작되는 피처는 단기 브랜치를 사용합니다. 이미 장기 브랜치에서 진행 중인 피처는 이전 모델에서 완료합니다. 두 방식은 일시적으로 공존합니다.

미완성 작업을 트렁크에 커밋하기 전에 피처 플래그를 먼저 갖춰야 합니다. 기본적인 피처 플래그 시스템을 구축하는 것이 다른 모든 것의 전제조건입니다. 없으면 트렁크 기반 개발은 미완성 UI를 프로덕션 사용자에게 배포하는 것을 의미합니다.

그런 다음 main 브랜치에서 CI를 강제하세요. 모든 푸시에 자동화 테스트가 실행되고, 실패한 테스트는 머지를 막고, 빌드가 통과하지 않으면 아무도 머지하지 않습니다. 이것은 협상 불가능한 부분입니다.

마지막으로 이틀 규칙을 명시적으로 정의하세요. 이틀이 넘은 브랜치는 어떻게 할지 대화를 나눕니다. 피처를 더 작게 나누거나, 플래그를 추가하거나, 이미 완성된 것을 배포합니다. 이것을 풀 리퀘스트 프로세스에서 가시적으로 만드세요.

대부분의 팀이 직면하는 불편한 조정은 "부분적으로 완성됨"이 플래그 뒤에 숨어 있고 기존 테스트를 깨지 않는 한 커밋하기에 유효하다는 것을 받아들이는 것입니다.

DORA 보고서 데이터가 배포 속도에 대해 말하는 것

DevOps Research and Assessment(DORA) 보고서는 소프트웨어 개발 팀 관행에 대한 대규모 실증 연구에 가장 근접한 자료입니다. 2021년 DORA 보고서는 엘리트 성과 팀이 하위 성과 팀보다 트렁크 기반 개발을 사용할 확률이 2.3배 높다는 것을 발견했습니다.

DORA 프레임워크의 엘리트 성과자는 하루에 여러 번 배포하며, 커밋에서 프로덕션까지 리드타임이 주 단위가 아닌 시간 단위로 측정됩니다. 트렁크 기반 개발은 일관되게 이러한 결과와 상관관계가 있습니다.

중요한 주의사항은 상관관계가 인과관계가 아니라는 점입니다. 고성과 팀이 트렁크 기반 개발을 채택하는 것은 이미 자동화 테스트, 견고한 CI/CD 인프라, 작고 집중된 변경을 작성하는 엔지니어라는 기본 규율에 투자했기 때문입니다. 그 기반이 먼저 옵니다. 트렁크 기반 개발은 그 맥락에 맞는 브랜칭 모델이지, 그것을 만들어내는 것이 아닙니다.

Biscuit이 이것을 금방 깨닫습니다. 좋은 리트리버는 공 세 개를 한 번에 물고 오려 하지 않습니다. 하나의 커밋, 하나의 리뷰, 하나의 머지. Good boy.

전환할 가치가 있는가

팀이 스프린트마다 머지 충돌에 상당한 시간을 쓰거나, "피처 브랜치가 아직 준비 안 됐어요" 때문에 릴리즈가 지연되거나, 브랜치가 얼마나 오래됐는지 아무도 기억 못 할 정도로 방치된다면, 트렁크 기반 개발은 진지하게 평가할 가치가 있습니다.

매일 커밋하는 리듬은 요구가 많습니다. 피처 플래그 인프라는 설정 시간이 필요합니다. 문화적 전환에는 몇 주가 걸립니다. 하지만 결과, 즉 항상 배포 가능한 코드베이스, 파일 단위가 아닌 라인 단위로 측정되는 머지 충돌, 위기가 아닌 일상이 된 릴리즈는 팀이 일하는 방식의 의미 있는 개선입니다.

작게 시작하세요. 팀 하나, 스프린트 하나, 모든 푸시에서 실행되는 CI, 갖춰진 피처 플래그. 4주 후에 무엇이 달라졌는지 보세요.