Preview Deployment: 베타 환경 멀티버스 체험기 #우아콘2023 #우아한형제들

'인프라가 부족하면 늘리면 되지 않나' 싶지만 두 가지 주의점이 있다. '필요한 만큼'을 파악하기 어렵고, 새 환경을 만들고 CI/CD를 연결하는 작업을 매번 반복해야 한다. 그래서 배포 인프라를 필요할 때만 늘리고 불필요해지면 정리하되 최소한의 노력으로 하는 것이 목표였고, 그 답이 프리뷰 디플로이먼트 멀티버스다. 필요한 시점에 동적으로 늘리고 끝나면 자동 정리해 리소스 낭비를 줄이며, 기존 환경을 활용하고 프로젝트당 한 번만 설정하면 된다.

URL은 `프로젝트_브랜치.front-preview-beta.baemin` 형태로 설계해 접속하면 S3의 `프로젝트/브랜치/index.html`로 연결된다. 더 깔끔한 `브랜치.프로젝트.베타민`을 못 쓴 것은 SSL 인증서 범위 한계 때문이다. `*.a.com` 인증서는 `b.a.com`은 포함해도 한 레벨 더 깊은 `c.b.a.com`은 포함하지 못한다. 이미 여러 팀이 쓰는 `*.베타민` 인증서를 수정하기 어려웠기에, `*.front-preview-beta.baemin` 인증서를 하나 발급받아 한 레벨 주소를 쓰기로 했다.

이 주소로 접속했을 때 올바른 버전에 연결하기 위해 프론트 정적 배포에 널리 쓰는 S3와 CloudFront 위에 AWS의 Lambda@Edge를 써서 URL을 변경하고, 자동화에는 GitLab CI를 쓴다. 기본 배포는 사용자→CloudFront→S3→응답 구조인데, 사용자-CloudFront 사이의 뷰어 영역과 CloudFront-S3 사이의 오리진 영역에 람다 함수를 추가한다. 각 영역에 리퀘스트·리스폰스 함수를 둘 수 있어 총 네 개가 가능한데 뷰어 리스폰스를 제외한 세 개를 쓴다.

뷰어 리퀘스트 함수는 URL 정보를 오리진 리퀘스트로 전달한다. 오리진 리퀘스트는 뷰어 정보를 직접 못 보므로 서브도메인과 URI를 헤더에 추가해야 하기 때문이다. 오리진 리퀘스트 함수는 전달받은 서브도메인·URI로 어느 디렉토리의 어느 파일로 보낼지 결정하는데, CSR은 모든 라우트를 동일 index.html로, SSG는 경로별 index.html이 생성되므로 라우트명 디렉토리 하위 index.html로 보낸다. 마지막 오리진 리스폰스 함수는 존재하지 않는 리소스 접근 등 S3 응답 오류 시 미리 마련한 에러 페이지로 리디렉션한다.

실제 배포할 CI 스크립트는 두 케이스에 트리거된다. 직접 배포는 원하는 시점에 브랜치·태그 기준으로 배포하며 주로 QA용으로 쓰고 사용 후 수동으로 리소스를 정리한다. 자동 배포는 루틴한 이벤트에 트리거되어, MR(Merge Request) 생성 시 그 버전으로 배포해 리뷰를 돕고 MR이 머지·클로즈되면 자동으로 리소스를 정리한다. GitLab 리뷰 앱(Review Apps) 기능을 쓰면 환경 변수 두 개만 추가해 'View App' 버튼으로 바로 접속하고 멈춤 버튼으로 정리할 수 있다.

멀티버스가 가져온 변화는 분명하다. 이제 각각 별도 프리뷰 환경에 배포해 무한히 많은 버전을 만들 수 있어, 큰 프로젝트 둘·작은 프로젝트 하나를 병렬 진행하면 QA가 35 워킹데이에서 15 워킹데이로 줄어 57% 감소, 배포 횟수는 9번에서 5번으로 44% 감소, 리베이스는 이론적으로 전혀 필요 없게 됐다. 개발자 경험도 MR로 서로의 작업을 보며 피드백하고 '지금 배포해도 되나' 소통 비용이 사라졌다. 다만 더 확산하려면 배포마다 URL이 바뀌는 인증·인가를 인증 BFF로 넘기는 것과, 정적 배포 한정을 넘어 쿠버네티스(EKS)로 SSR 지원을 확대하는 두 과제가 남아 있다.