배포 자동화 프로세스 전환기

Serverless framework에서 AWS Amplify로 전환하게 된 계기와 과정에 대해 알아봅니다.

다른 분야도 마찬가지겠지만, 특히 프론트엔드 분야는 새로운 기술의 도입과 트렌드 변화가 빈번하게 발생합니다. 그리고 그 과정에서 속도와 최적화 등의 이슈로 기존에 사용되던 기술들이 더이상 사용되지 않게 되기도 합니다. 물론 지금 여전히 가장 높은 점유율을 기록하고 있는 라이브러리지만 현재는 사장된 jQuery가 대표적인 예시입니다. 그에 따라 기존의 작업물이 레거시가 되지 않게 하기 위해서는 새로운, 혹은 업데이트된 기술과 호환성을 유지하는 방향으로 작업해야 합니다. 당장에 문제 없으니까, 태스크 처리가 우선이기 때문에 미뤄둔다면 기술 부채의 크기는 겉잡을 수 없이 커져 결국 큰 규모의 프로젝트에서는 다시 만들지 않고서는 처리할 수 없는 결과를 낳을 수 있습니다.

배포 자동화 프로세스 전환 작업은 이러한 문제의식에서 출발했습니다.

처음에 입사 후 투입된 프로젝트에서는 serverless-next.js를 사용하여 배포를 진행하고 있었습니다. 처음 투입되었을 당시에 이미 이를 사용하고 있었고, 그 당시에는 주어진 태스크를 처리하기에도 시간과 역량이 부족하여 이러한 기술적인 고민을 하지 못했습니다. 시간이 지나고 Next.js 13이 등장한 뒤에, Turbopack(비록 현재 stable하지 않기 때문에 사용하고 있지 않지만)을 비롯한 다양한 개선점을 프로젝트에 적용하고 눈으로 확인하고자 Next의 버전을 13으로 올리고, 새로 서버를 파서 배포를 진행했더니 오류가 발생했습니다.

오류의 원인은 Next.js가 13으로 버전업 되면서 서버리스 배포를 위한 설정이 내장되게 되었고, 이 과정에서 서버리스 배포를 위해 next.config.js에 추가해야 했던 target 옵션을 더이상 지원하지 않게 되었기 때문이었습니다. serverless-nextjs에서는 여전히 target: serverless 옵션을 필수로 요구합니다. 정확히는 이미 Next.js 13이 릴리즈 되기 한참 전부터 어떠한 작업도 레포지토리에 반영되지 않았습니다. 그러니 Next.js를 13으로 올린다면 더이상 serverless-next.js는 사용하지 못하게 되는 것이었습니다.

이미 코어 개발자들의 손에서 떠난 프로젝트이기에, 더이상의 업데이트는 기대할 수 없었습니다. 이러한 이유로, 새로운 배포 자동화 프로세스를 찾기 시작했습니다. 후보군은 Vercel과 AWS Amplify가 있었습니다. 여기서 Amplify를 선택한 이유는, 기존 서비스와의 통합된 관리의 용이성 때문이었습니다.

사내 모든 서비스는 CloudFront와 S3, Lambda를 중심으로 한 AWS의 기능들을 사용하고 있습니다. 따라서 Vercel보다는 Amplify를 선택함으로써 기존 AWS 인프라와의 일관성을 유지할 수 있으며, AWS 생태계에서 제공되는 다양한 기능과의 통합을 활용할 수 있다고 판단했습니다. 이는 관리 및 운영 프로세스를 단순화하고, 사내 다른 서비스들과 동시에 관리할 수 있기에, 일관된 품질을 제공할 수 있다는 점에서 장점을 갖고 있습니다.

Amplify는 Git Provider로 Azure DevOps를 지원하지 않기 때문에, AWS CodeCommit으로 push를 한 뒤에, 이 CodeCommit 내 레포지토리를 Amplify와 연결하여 특정 브랜치에 푸시되었을 때 Amplify로의 배포가 진행되도록 설정했습니다.

dev 환경과 , stg 환경에의 마이그레이션을 차례대로 진행하고 난 뒤에, 활성 이용자가 제일 적은 새벽 2시에 운영 환경에 Amplify를 성공적으로 적용했습니다. 기존에 Serverless를 사용하여 배포되어 있던 CloudFront의 대체 도메인을 변경하고, 직후에 Amplify의 도메인에 기존에 사용하던 운영 도메인을 연결해주는 형태로 진행했으며, 실제로 1분 미만의 다운타임이 발생했지만 큰 무리 없이 마쳤습니다.

이번 배포 자동화 프로세스를 주도하면서 느꼈던 점은, 오픈 소스는 언제든 코어 개발자 몇 명의 판단으로 중단될 수 있으며 이는 기술 부채로 이어질 수 있기 때문에 끊임없이 현재 사용하고 있는 기술보다 더 나은 대체재는 없는가를 고민해야 된다는 것이었습니다. 모든 오픈소스 개발자는 본인이 해당 프로젝트를 진행해야 할 동기(예를 들면 번아웃, 좋은 프로그램에 대한 합당한 보상의 부재 등이 있겠습니다.)가 더이상 없어질 경우 언제든 개발을 중단할 수 있습니다. 그렇기에 특정 기술을 도입할 때에는 GitHub의 Star 뿐만 아니라 해당 기술의 최근 Release, Issue 등을 면밀히 파악하고 결정해야 될 것이며, 해당 프로젝트는 언제든 중단될 수 있기 때문에 예의주시하면서 특정 상황에 적용할 더 나은, 더 활발하게 개발중인 프로젝트는 없는지를 찾아봐야 될 것입니다.