서버에 묶인 광고 화면을 프론트엔드 배포로 옮기기

광고 참여 화면의 문구를 고쳐도 광고 서버의 리뷰·테스트·배포를 거쳐야 했습니다. 화면이 서버 HTML 템플릿에 있어 FE 컴포넌트를 재사용하기도 어려웠습니다. 저는 화면 변경을 FE에서 검사하고 배포할 수 있는 경로를 일부 상품부터 만드는 일을 맡았습니다.

2023년 12월부터 팀과 분리 방향을 논의했고 2024년 1월 초기 FE 앱을 배포했습니다. 기존 상품은 유지하고 일부 참여 화면만 옮겼습니다. 이 선택의 이유는 구현 뒤인 5월 RFC에 정리했습니다.

새 앱을 만들되 새 렌더링 서버는 두지 않았다

동료들의 경험을 듣고 기존 프론트엔드 저장소와 공용 코드를 쓰는 방향을 논의했습니다. Next.js 앱을 만들되 요청마다 화면을 만드는 서버는 새로 운영하지 않았습니다. 빌드할 때 미리 만든 정적 파일을 인프라 담당자의 협업을 받아 기존 S3 저장소와 CloudFront CDN으로 전달했습니다.

당시 광고 유입 화면의 검색 노출 필요는 낮았고, 별도 렌더링 서버는 작은 FE 인력의 운영 부담을 늘렸습니다. 서버 배포 의존성을 줄이되 새 서버 운영은 추가하지 않는 것이 정적 출력을 고른 기준이었습니다. 이는 모든 화면에 정적 렌더링이 적합하다는 결론이 아니며, 이후 서버 렌더링 필요는 다시 판단할 여지를 두었습니다.

빌드된 파일이 실제 전달되도록 연결했다

앱을 저장소에 추가하는 것만으로 배포 경계가 바뀌지는 않습니다. 앱과 공용 코드의 변경을 검사하고, 빌드한 파일을 기존 저장소에 동기화한 뒤 CDN 캐시를 갱신하는 자동 배포 작업까지 연결했습니다.

FE 변경 → 검사 → 정적 빌드 → 기존 저장소에 산출물 동기화 → CDN 갱신

파일 동기화가 끝나도 CDN 갱신에 실패하면 사용자가 새 화면을 받는다고 말할 수 없습니다. 그래서 마지막 갱신 실패도 배포 실패로 남겼습니다. 다만 이 경로가 실패 때 모든 단계를 한꺼번에 되돌리는 시스템은 아닙니다. 제가 맡은 것은 프론트엔드 검사부터 마지막 전달 단계까지 성공·실패를 한 작업 흐름에서 확인하게 하는 것이었습니다. 로컬 실행과 배포 방법도 문서화했습니다.

일부 화면으로 시작해 다음 개발의 경로가 됐다

일부 시험 상품만 새 앱으로 옮기고 나머지는 기존 경로를 유지했습니다. 전환 중 어느 상품이 어느 경로를 쓰는지 안내하는 비용은 있었지만, 기존 상품 전체의 전달 방식을 한 번에 바꾸지 않을 수 있었습니다. 이후 리워드 표시·계측·CTA와 후속 상품 개발이 이 FE 경로에서 이어졌습니다.

초기 리뷰에서는 상품 동작과 환경 설정을 별도 PR로 나눠 달라는 피드백도 받았습니다. 실행 가능한 변경과 검토하기 쉬운 변경은 다르다는 점을 반영했습니다. 정적 파일 배포 기반은 인프라 담당자의 기존 작업이었고, 저는 FE 앱과 산출물을 그 기반에 연결했습니다.

확인된 결과는 일부 참여 화면이 FE 앱의 검사·빌드·전달 경로를 사용했고, 이후 기능도 같은 기반에서 개발된 것입니다. 모든 상품의 이전이나 배포 리드타임·장애율 개선은 확인된 결과로 쓰지 않았습니다. 이 사례가 보여주는 제 판단은 화면 코드만 분리하지 않고, 검사한 파일이 사용자에게 전달되는 마지막 단계까지 FE 작업의 종료 조건으로 정의한 것입니다.