매일 배포하는 팀이 되는 여정(2) — Feature Toggle 활용하기 (2023-04)

배포와 기능 공개 시점의 충돌

main에 병합한 기능을 개발 환경에서 검증하는 동안 동료가 배포하면, 검증 중인 코드도 사용자에게 나갑니다. 티켓마다 배포 시점이 다르거나 서버 간 배포 순서를 지켜야 할 때도 배포를 기다려 달라고 하거나 코드를 revert해야 합니다. Git Flow와 GitHub Flow 어느 쪽을 쓰든, 이런 조율이 필요하면 매일 배포하기 어렵습니다.

저자는 Boolean 하드코딩과 YAML·Spring profile로 기능을 구분했던 것 같다고 회고했습니다. 기능을 켜려면 설정을 바꿔 다시 배포해야 했고, 배포가 오래 걸리면 이 방식도 불편했습니다.

어노테이션과 동적 설정으로 구현

팀은 Martin Fowler의 Feature Toggles 글을 참고해 다섯 가지 설계 원칙을 세웠습니다.

• 켜진 토글은 새 기능을, 꺼진 토글은 기존 기능을 실행한다.
• 토글 포인트(분기 지점)와 토글 라우터(분기 결정 수단)를 분리한다.
• 토글 설정이 특정 저장소에 의존하지 않게 한다.
• 코드 배포 없이 토글 설정을 동적으로 변경한다.
• 사용하지 않는 토글은 즉시 제거한다.

처음 시도한 Proxy 패턴은 기능마다 라우터 클래스를 만들어야 해 번거로웠습니다. 구현에는 Resilience4j Starter의 어노테이션과 AOP 방식을 참고했습니다. 신규 로직에 @FeatureToggle, 기존 로직에 @FeatureToggleFallback을 붙이는 방식입니다.

설정은 FeatureToggleProvider 인터페이스로 주입받습니다. 처음에는 DB에 저장했고, 팀에 Central Dogma가 갖춰진 뒤 저장소를 옮겼습니다. @Scheduled로 설정을 주기적으로 읽으므로 값을 바꾸면 서버 배포 없이 반영됩니다.

설정값은 ON/OFF에서 JSON으로 확장했습니다. Fowler 글의 토글 유형 가운데 권한 토글과 카나리 토글만 가져다 씁니다. 권한 토글은 지정한 사용자 ID에 기능을 열고, 카나리 토글은 사용자 ID를 100으로 나눈 나머지가 percentage 안에 들면 적용합니다. 라우터는 권한 토글, 카나리 토글, 전체 적용 순으로 검사합니다. 전체 적용부터 검사하면 앞의 조건들이 의미를 잃기 때문입니다.

적용 범위와 효과

팀은 모든 변경에 토글을 쓰지는 않습니다. 부작용을 가늠하기 어려운 변경, 마이크로서비스 간 배포 순서를 독립시켜야 하는 경우, 특정 시점에 공개해야 하는 기능에 사용합니다. 직원에게만 프로모션을 먼저 노출할 때 권한 토글을 쓸 수 있다는 예도 들었습니다.

저자는 안정적인 테스트에 안전장치가 더해져 핵심 모듈을 수정할 때 부담이 줄었다고 평가했습니다.

토글 포인트와 제거 시점

토글 포인트는 코드 곳곳에 퍼지기 쉽습니다. 저자가 원칙 2번으로 분기 지점과 결정 수단을 나눈 이유입니다. 팀은 용도가 끝난 토글을 바로 지우기로 약속했고, 권한 토글은 예외적으로 오래 남을 수 있다고 덧붙였습니다. 앞 글의 브랜치 전략은 매일 배포하는 팀이 되는 여정(1)에서 다룹니다.