프론트엔드 배포 시스템의 진화 (1) - 결제 SDK에 카나리 배포 적용하기

결제 SDK를 모든 가맹점에 한 번에 배포하면 실제 환경에서 발생하는 문제의 영향이 커지고, 개발자도 배포와 모니터링에 부담을 느꼈다. 처음에는 Lambda@Edge에서 요청마다 난수로 stable/canary를 선택했지만, 캐시를 켜면 일부 버전이 캐시에 고정되고 끄면 비용과 로딩 지연이 커지는 한계가 있었다. 이를 해결하기 위해 JA3 지문을 0~9의 코호트로 변환해 CloudFront 캐시 키에 반영하고, Lambda@Edge가 설정된 카나리 비율에 따라 버전을 선택하도록 설계했다. 쿠키로 사용자별 버전 일관성을 보조하면서 캐싱, 비율 조정, 신속한 롤백을 함께 지원하는 구조를 만들었으며, 쿠키는 필수 기능이 아니므로 없어도 동작해야 한다는 점을 강조한다.

• 정적 리소스에 요청별 난수 기반 카나리를 적용하면 캐시가 버전 선택을 고정하거나, 캐시를 끌 경우 엣지 함수 비용과 지연이 커질 수 있다.
• JA3 지문을 소수의 코호트 값으로 변환하면 사용자 환경을 폭넓게 나누면서 캐시 키의 종류를 제한할 수 있다.
• CloudFront 캐시 키에 코호트 헤더를 포함하고 Lambda@Edge에서 배포 비율에 따라 버전을 선택하면 캐싱과 가중치 조정을 함께 지원할 수 있다.
• 쿠키는 사용자에게 버전을 일관되게 제공하는 보조 수단으로만 쓰고, 쿠키가 없어도 서비스가 정상 동작하도록 설계해야 한다.