정산 로직을 새 버전으로 갈아끼우는 데 3주가 걸리는데, 그동안 팀원들은 매일 main에 기능을 머지하고 있다. 미완성 코드를 어디에 두고 작업할지 정해야 하는 상황.
언제: 거의 항상 기본값. 신구 코드가 if문 하나로 갈라질 수 있고 꺼진 상태로 배포해도 안전할 때. 완성 전에도 내부 트래픽 1%로 켜서 미리 검증할 수 있다.
비용: 플래그를 안 지우면 부채가 쌓인다. 켜짐/꺼짐 조합만큼 테스트 경우의 수가 늘고, 미완성 코드가 운영 바이너리에 같이 실려 나간다. 지우는 티켓까지가 한 세트다.
언제: 신구 코드가 한 프로세스에 공존할 수 없을 때만. 예: DB 스키마 전면 교체, 프레임워크 메이저 업그레이드, 통째로 버릴 수도 있는 실험 스파이크.
비용: 오래 둘수록 머지 충돌이 기하급수로 커지고 CI가 통합을 검증하지 못한다. 마지막에 빅뱅 머지 리스크. 매일 main을 리베이스해도 비용이 0이 되지는 않는다.
기본은 플래그 걸고 main에 매일 작게 머지한다. 별도 브랜치는 스키마 교체나 메이저 업그레이드처럼 신구 코드가 한 바이너리에 공존할 수 없을 때만 쓰고, 그때도 매일 리베이스하면서 수명을 1~2주로 못 박는다. 브랜치가 2주를 넘기면 브랜치를 더 키우는 게 아니라 작업을 잘게 쪼개는 방법을 다시 찾는다.
- 플래그 분기가 한 기능 때문에 파일 15개 이상으로 퍼짐 — if문이 아니라 사실상 모듈 복제가 되고 있다는 신호
- 6개월 넘게 안 지운 플래그가 20개 이상 쌓여서 운영이 정확히 어떤 조합으로 도는지 아무도 즉답 못 함
- '스테이징에선 되는데 운영에선 안 돼요'의 원인이 플래그 조합 차이인 경우가 주 1회 이상 반복
- 원격 플래그 조회가 hot path에 들어가 p99가 50ms 이상 늘어남
🔧LaunchDarkly / Unleash (또는 환경변수 기반 자체 플래그)GitHub merge queuegit rebase (브랜치를 쓸 땐 매일)죽은 플래그 grep 스크립트 + 정리 티켓 자동 생성
“I default to flags and daily merges to main; I'd only branch long-lived if old and new code truly can't coexist.”
checking microphone…