041. TBD 심화: CI/CD 통합 및 코드 리뷰 (Trunk-Based Development Advanced)

핵심 인사이트

TBD(Trunk-Based Development) 고도화 핵심은 피처 플래그(Feature Flag)/피처 토글(Feature Toggle)을 활용하여 "미완성 코드도 메인 브랜치에 병합"이 가능한 상태를 유지하는 것으로, 이를 통해 장기 브랜치의 "통합 지옥(Integration Hell)"을 원천 방지한다.

TBD와 CI/CD의 결합은 "코드가 메인에 병합되는 즉시 자동으로 프로덕션에 배포 가능한 상태"를 목표로 하며, DORA 지표에서 Elite 수행 팀의 배포 빈도(Daily/On-demand) 달성의 기반이 된다.

소규모 PR(Pull Request) 문화는 TBD의 실천적 핵심으로, PR당 변경 라인 200줄 이하 권고, 24시간 이내 리뷰 완료 목표는 코드 리뷰 부담을 낮추고 통합 위험을 분산시키는 동시에 팀 전체의 코드 이해도를 높인다.

Ⅰ. TBD 고도화 핵심: 피처 플래그

피처 플래그 (Feature Flag / Feature Toggle):

기본 개념:
  코드는 메인에 병합 완료
  기능 ON/OFF는 런타임 설정으로 제어

장점:
  - 미완성 코드도 안전하게 메인 병합
  - 사용자별/비율별 점진적 롤아웃
  - 문제 발생 시 즉시 롤백 (재배포 불필요)
  - A/B 테스트 용이

구현 패턴:

단순 Boolean:
  if (featureFlag.isEnabled("new-checkout")):
    showNewCheckout()
  else:
    showOldCheckout()

사용자 비율 롤아웃:
  if (featureFlag.getVariant("new-ui", userId) == "B"):
    showNewUI()

피처 플래그 수명주기:
  생성 → 개발 중 OFF → 테스트 ON →
  카나리 (1%~10%) → 전체 롤아웃 → 플래그 제거

경고: "플래그 부채(Flag Debt)"
  삭제되지 않은 플래그 누적 = 기술 부채
  분기 폭발, 가독성 저하

도구: LaunchDarkly, Unleash, Flagsmith
     AWS AppConfig, Azure App Configuration

📢 섹션 요약 비유: 피처 플래그는 TV 채널 리모컨 — 방송(코드)은 전송 완료, 시청자(사용자)별로 채널을 켜고 끄는 것은 리모컨(플래그)으로 제어.

Ⅱ. 소규모 PR과 코드 리뷰

TBD 코드 리뷰 원칙:

소규모 PR 권고:
  변경 라인: 200줄 이하 (이상적: 50~100줄)
  하나의 논리적 변경만 포함
  리뷰 완료 시간: 24시간 이내

큰 PR의 문제:
  - 리뷰어 집중력 한계 (400줄 이상 = 위험 증가)
  - 통합 충돌 가능성 ↑
  - 리뷰 지연 → 장기 브랜치 전락

PR 분할 전략:
  Stacked PR: PR A → PR B → PR C (순서)
  독립 PR: 기능별 독립 분할
  
코드 리뷰 Good Practices:
  X 재작성 요구 (아이디어 강요)
  O 개선 제안 + 근거
  X "이건 왜 이렇게 했어요?" (공격적)
  O "이 부분이 X 이유로 Y 방식이 좋을 것 같아요"
  O 코드 + 아이디어 분리: "Nit:" 접두어

리뷰 체크리스트:
  기능 정확성 (버그 없음)
  테스트 커버리지 (핵심 케이스 포함)
  성능 (불필요한 N+1 쿼리 등)
  보안 (입력 검증, 권한 확인)
  가독성 (복잡한 로직 설명 있음)

📢 섹션 요약 비유: 소규모 PR은 숙제 나눠내기 — 한 번에 100장 제출보다 10장씩 10번 제출이 선생님(리뷰어)도 집중해서 검토 가능.

Ⅲ. TBD + CI/CD 파이프라인 통합

TBD 기반 CI/CD 파이프라인:

Trunk 브랜치 보호 정책:
  - 직접 push 금지
  - PR + 1인 이상 리뷰 필수
  - CI 통과 필수 (테스트 그린)
  - 합의 후 Squash or Rebase 병합

CI 파이프라인 (2~5분 내 완료 목표):
  코드 빌드 (Build)
  단위 테스트 (Unit Test)
  정적 분석 (Lint / SAST)
  취약점 스캔 (SCA)
  도커 이미지 빌드
  이미지 스캔

CD 파이프라인:
  스테이징 자동 배포 (Continuous Delivery)
  통합 테스트 / E2E 테스트
  프로덕션 배포 (승인 또는 자동)

TBD + GitOps:
  Trunk → ArgoCD/Flux → 쿠버네티스 클러스터
  코드 리포지토리 = 인프라 소스 오브 트루스
  
배포 전략 연계:
  카나리 배포 + 피처 플래그 조합
  블루/그린 배포 + TBD
  롤링 업데이트

메트릭:
  리드 타임: 코드 커밋 → 프로덕션 배포
  배포 빈도: Elite 팀 = 주 1회 이상 (DORA)
  MTTR: 장애 복구 시간 1시간 이하 (Elite)

📢 섹션 요약 비유: TBD + CI/CD는 자동 조립 라인 — 코드 커밋(재료 투입) → 자동 테스트(품질 검사) → 자동 배포(출고) 사이클이 하루에도 여러 번.

Ⅳ. TBD 안티패턴과 해결

TBD 안티패턴:

1. 대형 PR 허용:
   증상: PR이 수백~수천 줄
   원인: 기능 완성 후 한 번에 병합 시도
   해결: TDD + 점진적 개발 훈련, PR 크기 규정

2. 오래된 단기 브랜치:
   증상: "임시" 브랜치가 2주 이상 생존
   원인: 피처 플래그 미사용, 배포 두려움
   해결: 피처 플래그 도입, 배포 자동화

3. 테스트 없는 병합:
   증상: 테스트 커버리지 낮음, 잦은 장애
   원인: CI 없거나 테스트 느려 우회
   해결: 테스트 속도 개선, CI 의무화

4. 피처 플래그 부채:
   증상: 플래그 수 100개 이상, 관리 불가
   원인: 사용 완료 후 삭제 안 함
   해결: 플래그 TTL 정책, 정기 정리

5. 단일 CI 슬로우다운:
   증상: CI 20분 이상 → 개발자 우회
   원인: 테스트 병렬화 부족
   해결: 테스트 병렬 실행, 스테이지 최적화

TBD 성숙도 지표:
  Lv1: 브랜치 수명 < 1일
  Lv2: 피처 플래그 50%+ 사용
  Lv3: CI < 5분, 배포 일 1회 이상
  Lv4: 자동화 롤백, 카오스 엔지니어링

📢 섹션 요약 비유: TBD 안티패턴은 고속도로 끼어들기 — 한꺼번에 너무 많은 차(코드)가 들어오면 전체 정체(통합 지옥) 발생.

Ⅴ. 실무 시나리오 — 배포 빈도 개선

스타트업 D사 TBD 도입 사례:

Before (Git Flow):
  배포 빈도: 월 2회
  리드 타임: 2~4주
  브랜치 수: 상시 15~20개
  머지 충돌: 배포마다 2~8시간 해소
  장애 복구: 평균 4시간

TBD 전환 계획 (3개월):

Month 1:
  CI 파이프라인 구축 (5분 이내)
  단위 테스트 커버리지 60% 달성
  브랜치 수명 < 3일 정책 도입

Month 2:
  피처 플래그 시스템 도입 (LaunchDarkly)
  카나리 배포 자동화
  PR 크기 200줄 이하 가이드

Month 3:
  일일 배포 자동화 (CD 구축)
  스테이징 자동화
  DORA 메트릭 대시보드 구축

After (TBD):
  배포 빈도: 일 3~5회
  리드 타임: 4~6시간
  브랜치 수: 상시 2~3개
  머지 충돌: 거의 없음 (<30분)
  MTTR: 45분 (피처 플래그 즉시 OFF)

팀 반응:
  "더 이상 배포가 두렵지 않다"
  "개발에만 집중할 수 있다"

📢 섹션 요약 비유: TBD 도입은 편의점 배송 체계 전환 — 월 2회 대형 배송 트럭(Git Flow)에서 매일 소량 배달(TBD)로 바꾸니 재고 문제가 줄고 신선도 유지.

📌 관련 개념 맵

TBD 심화
+-- 피처 플래그
|   +-- LaunchDarkly, Unleash
|   +-- 플래그 부채 관리
+-- 소규모 PR
|   +-- 200줄 이하, 24시간 리뷰
|   +-- Stacked PR
+-- CI/CD 통합
|   +-- 보호 브랜치, 자동 배포
|   +-- GitOps (ArgoCD)
+-- 성숙도
    +-- DORA 지표 (배포빈도, 리드타임)
    +-- 안티패턴 해결

📈 관련 키워드 및 발전 흐름도

[Trunk-Based Development 기원 (Google 내부)]
단일 트렁크, 지속적 통합 실천
      |
      v
[피처 토글 패턴 정립 (Fowler, 2010s)]
미완성 코드 안전 병합 가능
      |
      v
[DORA 연구 (2014~)]
고성능팀 특성: TBD + CI/CD 상관관계 증명
      |
      v
[GitOps (Weaveworks, 2017)]
Git = 인프라 진실의 원천
ArgoCD, Flux 생태계
      |
      v
[현재: Platform Engineering]
Internal Developer Platform
TBD + 셀프서비스 배포 플랫폼

👶 어린이를 위한 3줄 비유 설명

TBD 고수들은 피처 플래그를 써서 아직 완성 안 된 기능도 메인 코드에 넣어두고, 버튼 하나로 켜고 끌 수 있어요!
작은 PR 200줄 = 숙제 10페이지씩 나눠 제출 — 선생님(리뷰어)이 꼼꼼히 봐주고, 틀린 것도 빨리 발견해요.
TBD + CI/CD는 매일 조금씩 배포하는 것 — Google·Netflix는 하루에도 수천 번 배포해요!