Next.js + Docker + CodePipeline을 이용한 CI/CD 구축 실패기

김선태
Dooda
Published in
6 min readMar 8, 2021

목적

사내 프론트엔드에 다음의 이유로 적절한 배포 파이프라인을 구상하고 있었다.

  1. 빠른 배포 및 테스트 주기 (Ci/CD..)
  2. 저렴한 유지 비용
  3. 높은 가용성 및 트래픽 처리 ( Auto scaling....)

기존에는 Create-Razzle-App을 기반으로 하는 프로젝트를 Docker+CodePipeline을 통해 배포하고 있었다.

최근 ISMS를 위해 Git 을 기업용으로 교체하고. Onelogin SSO를 적용하였고. Next.js로 프론트 프레임워크를 업데이트 하면서 그에 맞게 배포 파이프라인도 업데이트를 시도했고. 그 과정 중 봉착한 여러 문제를 서술하고자 한다.

CI/CD 변천사

저자가 시도한 플랫폼은 다음과 같은 순서였다. (각각 뼈 아픈 문제가 발생하여 결국엔 원상태로 돌아갔다..)

Code Pipeline -> Vercel -> Amplify -> Codestar -> Code Pipeline

각 플랫폼마다 발생한 문제는 다음과 같았는데..

AWS CodePipeline

AWS CodePipeline. 다 좋다. 최고다. 근데 세팅이 너무 복잡하고 어렵다 + 서버리스에 비해 기본 비용이 많이 든다.

브랜치별 배포 기능이 없고. Vercel이라는 너무 좋은 대안이 있어서 Vercel로 갈아타기로 결정! (헛된 희망이었다. SSO git+Next.js 쓸거면 Code Pipeline이 최고다. 싫으면 Circle CI나 Jenkins를 써라... 제발..)

Vercel.com

Vercel 화면. Next.js 를 관리하는 명실상부 ‘최고’의 플랫폼이다. 당신의 기업이 ISMS 대상이 아니라면..

다 좋은데.. SSO(우리는 ISMS 준비를 위해 깃헙에 Onelogin SSO를 적용하여 2FA+IP인증을 요구 중이다.) 설정된 Git Repository 에 접근을 할 수 없었다. 무슨 짓을 해도 안된다..
더 큰 문제는 Vercel은 배포 파이프라인인 만큼 접근 통제가 중요한데. IP Whitelist + SSO 설정을 하기 위해 Enterprise를 구매하려면 월 1600달러를 지불해야한다. 비용 낮추려고 온갖 고민을 하고 있는데. 이건 정말 아니다 싶어서 스킵.
일단 돈 문제를 떠나서 깃 레포에 접근이 안되는게 너무 치명타였다.

그냥 AWS에서 해결할 수 없을까? 하다가 AWS Amplify라는 서비스를 발견. 약간 Firebase랑 비슷한 느낌인데. 역시나 Firebase의 포지션을 공략하기 위해 나온 서비스였다.

AWS Amplify

세팅을 완료하는데 1시간이 채 안걸렸다. 매우 간단하게 브랜치별 배포까지 설정됐고. 서버리스 기반에 비용도 매우 저렴해서 “이거다!” 싶었다. ‘그 문제’를 접하기 전까진.

브랜치별 자동 배포도 되고. 슬랙에 연동해서 알림도 가고. 배포 현황도 한눈에 보이고. 비용도 저렴하고. 이해하기도 쉽고. 모든게 완벽했다.

모든게 완벽했다.. ^^

처음에는 잘 돌아가는 듯 싶었는데. 배포만 하면 Mobile-detect 모듈이 작동을 안했다..프론트 팀에서는 밤을 샐 정도로 바쁜 와중에 해당 문제 디버깅에만 며칠을 쏟았다 (고통 받은 치호님…)
문제는 프론트 코드가 아닌 Static build였다. (3일 동안 헛디버깅 한 분노에 차오른 치호님한테 맞아 죽을 뻔 했다)

사실 Amplify를 선택한 이유는 다음과 같았다.

  1. AWS Amplify는 static 파일을 호스팅하는 ‘정적 호스팅’서비스이다.
  2. Next.js 는 next export 명령어를 통해 S3나 cafe24 등 ‘어디에든 배포 가능한’ 프레임워크를 표방한다.

고로 나는 Amplify를 이용한 next.js 배포가 ‘적절하다’고 판단하여 진행했으나. 내 잘못된 선택으로 인해 프론트팀이 조져졌다.

알고보니 SSR(Server-Side-Rendering)은. 유저의 요청마다 페이지를 렌더링해서 주는게 아니라. 빌드 할 때 렌더링 한 뒤 해당 페이지를 Serve하는거였다. 추가로 이것을 static file로 export하는 경우. 유저 요청마다 재렌더링을 시도하는 mobile-detect 모듈의 생애주기가 꼬여서 제대로 작동하지 않는 것이었다.

즉 이것을 해결하기 위해서는 정적 호스팅이 아닌 동적 호스팅을 사용해야 하고. 그러려면 EC2+Node.js / Docker+Node.js 환경 혹은 Vercel과 같은 Node.js 호스팅 플랫폼을 사용해야 해결이 가능한 문제였다.

좀 더 쉽게 할 수 없을까? 고민하던 차에 AWS Codestar라는 서비스를 발견했다!! (발견하지 말았어야 한다!!)

AWS Codestar

Go 공부할 겸 Go 프로젝트를 만들어 봤다. Lambda기반 서버리스 백엔드와 Ci/CD를 구축할 때는 정말 좋은 대안이 될 것 같다.

코드스타를 이용하면. 프로젝트를 생성함과 동시에 생애주기가 동일한 EB혹은 Lamda에 배포되는 파이프라인과, git 레포를 동시에 만들고 관리할 수 있다. 또한 해당 레포에 접근 가능한 Web기반 IDE인 AWS Cloud9 세팅까지 손쉽게 가능하다. 프로젝트 모니터링 및 이슈 트래킹까지 지원한다. 매우 좋다.

그런데 Next.js 배포가 안된다.. 정확한 원인 파악은 못했지만. 일단 배포된 Elastic Beanstalk에 Load Balancer를 세팅하는게 복잡하고. 까딱하면 오류가 터진다. 시간이 부족한 관계로 익숙한 플랫폼으로 돌아가기로 했다.

결국 다시 Code Pipeline으로…...🤣

다음 글

Next.js + Docker + CodePipeline을 이용한 Ci/CD 배포

--

--

김선태
Dooda
Editor for

삶을 즐기는 사람들과 대화하는게 즐거운 사람입니다. 과거엔 화이트 해커 지금은 글 쓰고 기획 하는 개발자입니다