AWS Amplify Console을 이용하여 프론트엔드 개발 환경 개선하기

안녕하세요. 화해팀 프론트엔드 개발자, 박찬민입니다.

 

저는 올해 초 화해팀에 입사를 했는데요. 어느 정도 적응기를 지나면서 프론트엔드 개발 환경에 대한 불편한 점을 인식하고, 이를 AWS Amplify Console을 이용해서 개선한 경험을 공유해보려 합니다.

 

 

 

 

 

 

화해팀에는 ‘밴드’라고 부르는 Cross-functional Team이 있는데요. 제가 속한 밴드에는 프론트엔드 개발자가 저를 포함하여 2명이 있었고, 이 2명이 밴드에서 해야 할 프론트엔드 관련 개발 업무들을 나눠서 수행했습니다. 2명이 같은 프로젝트를 담당하기 때문에 업무량을 나눌 수 있다는 장점이 있었지만, 한편으로는 2명이기 때문에 개발 과정의 비효율을 만들어 내기도 했습니다.

 

가장 큰 비효율적인 상황은 테스트 서버의 공유였습니다. 처음에는 테스트 서버를 한 개를 사용하고 있었는데, 2명의 개발자가 각각의 작업물을 관련 팀에 공유하기 위해서는 서로 테스트 서버를 사용하는 시간을 논의하고 정해진 시간에 사용하는 약속을 해야만 했습니다. 그래서 사용 시간에 대한 약속을 하지 않으면 관련 팀에게 정확한 테스트 시간을 전달하는 데 어려움이 있었습니다. 또한, 테스트 서버의 작업물이 언제든지 바뀔 수 있기 때문에 테스트를 하는 관련 팀의 입장에서도 테스트를 하고 싶을 때 하기가 어려운 상황이었습니다.

 

처음에는 테스트 서버를 작업자 별로 가지는 방법도 생각했지만, 한 작업자가 여러 과제를 담당하고 비슷한 시기에 테스트를 해야 하는 경우가 있었기 때문에 근본적인 해결책이 될 수는 없었습니다.

 

테스트 서버의 공유 이외에 또 한가지 불편한 점이 있었습니다. 배포 자동화 시스템의 부재입니다. 한 번의 배포만 생각한다면 배포를 수동으로 하더라도 업무에 큰 지장은 없었습니다. 하지만 밴드의 임무 수행과 과제 달성을 위해서는 잦고 빠른 배포가 필요했습니다. 그러다 보니, 배포를 수동으로 작업하는 것에 생각보다 업무 시간을 많이 소비하고 있었습니다.

 

정리하자면, 제가 느낀 주요한 불편한 점은, 테스트 환경이 제한된 것과 배포 과정에서 개발자의 리소스가 비효율적으로 활용되는 것이었습니다.

 

 

 

우선, 프론트엔드 플랫폼 구성원 전체에 도움이 될 수 있는 배포 자동화에 대한 스터디를 해보았습니다. CI/CD가 무엇인지 정의와 개념부터 다시 알아보고 어떤 절차가 수행되는 것인지, 어떤 도구들을 이용할 수 있는지 공동학습으로 알아보았습니다.

 

그러던 중에, Amplify Console이라는 AWS의 서비스를 알게 되었습니다. 처음에는 간단하게 배포자동화 시스템을 구축할 수 있는 서비스로 인지했지만 알아볼수록 여러 매력적인 기능들이 있었고, 우리가 당면한 불편한 점을 쉽고 빠르게 해결할 수 있을 것 같다고 생각했습니다.

 

 

 

Amplify Console은 Git 기반 워크플로를 통해 풀 스택 서버리스 웹 애플리케이션을 배포 및 호스팅 할 수 있는 AWS 서비스입니다. 즉, Git repository와 연동시킨 뒤, Git에 소스코드를 Push하는 것만으로 프로젝트가 빌드되고 그 결과물을 호스팅까지 해주는 서비스입니다.

 

주요한 특징들을 살펴보자면 아래와 같습니다.

 

(1) Amplify Console App을 생성하는 절차가 무척 간단합니다.

Amplify Console에서는 App이라는 개념으로 프로젝트들을 관리합니다. 이 App을 생성하면 배포 자동화 시스템을 구축할 수 있는데, 이 과정이 무척 간단합니다.

 

[Git repository 연결 -> Branch 선택 -> 빌드 스펙 설정] 이렇게 크게 세 단계만으로 App 생성이 완료 됩니다.

 

 

 

 

(2) 배포 절차를 자동화하여 절차가 간단해집니다.

Amplify Console 자체가 자동화된 지속적 배포 서비스이기 때문에, 당연하게 배포 과정이 매우 간단해집니다. 연결된 Git repository의 branch에 변경이 발생하면 자동으로 이를 감지하여, 빌드와 배포를 알아서 해줍니다.

 

 

 

 

(3) 새로운 빌드가 준비되면 바로 배포되고 적용됩니다.

Amplify Console은 프론트엔드 프로젝트를 배포할 때, 내부적으로 S3와 CloudFront를 이용하여 호스팅합니다. 자동 빌드가 완료되면 파일이 S3에 업로드되며, 이는 즉시 CloudFront까지 업로드됩니다. 그리고 새로운 빌드가 진행되어 이전과 같은 파일 이름으로 S3에 업로드 할 때는 버저닝을 하고, CloudFront는 새로운 버전이 확인되면 즉시 CloudFront에 새로 업로드하여 소스코드가 변경되면 바로바로 배포됩니다.

 

 

 

 

(4) 서버에 대한 관리가 없으면서도, 높은 가용성을 보장합니다.

위에서 Amplify Console을 소개할 때 ‘서버리스 웹 애플리케이션을 배포 및 호스팅’이라고 소개해 드렸습니다. ‘서버리스’라는 단어가 붙은 것처럼, Amplify Console에서 호스팅 하는 웹어플리케이션은 사용자가 관리할 서버가 없고 서버에 대한 관리는 AWS에 담당하며 가용성을 보장해줍니다. 또한, S3와 CloudFront을 이용하기 때문에 그 장점을 그대로 가지고 있고, 당연히 가장 큰 장점인 가용성 99.99%를 제공합니다.

 

 

(5) SSL 인증서 적용과 Custom Domain 설정이 간편합니다.

보통 CloudFront에서 SSL 인증서를 사용하려면 ACM 서비스에서 인증서를 생성하고 직접 CloudFront에 적용해주어야 합니다. Domain도 마찬가지로 Route53에서 직접 생성하고 CloudFront에 별도로 적용해주어야 합니다.

 

하지만 Amplify Console에서는 관리 메뉴에서 필요한 정보들만 입력하면 자동으로 SSL 인증서와 Domain의 Record set이 생성되고 적용됩니다.

 

 

(6) 지정한 Branch에 Pull Request를 생성하면 해당 Pull Request에 대한 독립적인 호스팅 환경이 만들어집니다.

Amplify Console에는 Preview라는 기능이 있습니다. 이 기능은 지정한 Branch에 Pull Request가 생성되면 해당 Pull Request 소스코드로 빌드 및 배포가 진행되어 별도로 분리된 호스팅 환경이 만들어집니다. 물론, 별도의 URL이 할당됩니다.

 

이 기능을 이용하여 다수의 작업자가 각각 여러 과제를 수행하더라도 각 과제에 대한 분리된 호스팅 환경이 만들어지기 때문에 동시에 여러 과제에 대한 테스트가 가능해집니다.

 

 

 

앞서 언급했듯이, 제가 느낀 주요한 불편한 점은 테스트 환경이 제한되어 있다는 것과 배포 과정에서 개발자의 리소스가 비효율적으로 활용되는 것이었습니다. 그리고 이 두 가지는 Amplify Console를 이용하면 개선될 수 있었습니다.

 

우선, 배포 과정에서 개발자의 리소스가 비효율적으로 활용되는 점은 Amplify Console의 자동 배포 기능으로 개선되었습니다. Git repository의 release branch를 Amplify Console에 연결하고 Custom Domain 연결까지 해두어서, release branch에 코드를 병합시키는 것만으로 자동으로 빌드 및 배포가 됩니다. 이전에 수동으로 모든 절차를 밟았던 것에 비하면 개발자의 리소스 효율이 아주 많이 높아졌습니다. release branch 뿐만 아니라 develop, stage branch 등 필요한 만큼 연결하여 목적에 맞게 편리하게 사용하고 있습니다.

 

두 번째 불편한 점이었던 제한된 테스트 환경은 Amplify Console의 Preview 기능으로 개선되었습니다.

 

저희는 과제를 수행할 때, feature branch에 작업하고 develop branch에 Pull Request를 생성해서 작업물들을 병합합니다. 그래서 Preview 기능에서 develop branch를 지정해두어서 Pull Request를 생성할 때마다 독립적인 테스트 URL을 가질 수 있고, 작업별로 관련 팀에게 각각의 테스트 URL을 전달하여 동시에 여러 과제의 테스트를 할 수 있게 되었습니다.

 

또한, Pull Request에서 바로 Amplify Console의 빌드 상태 빌드 상태를 확인할 수 있고, 배포가 완료되면 바로 URL을 확인할 수 있어서 편리하게 이용하고 있습니다.

 

 

 

 

 

 

Amplify Console을 이용해서 불편한 개발 환경을 아주 만족스럽게 개선할 수 있었습니다. 하지만 그 과정에서 몇 가지 Troubleshooting이 있었고, 간과할 수 없는 중요한 것들이라서 공유드리려 합니다.

 

(1) SPA를 호스팅 할 때는 Rewrite 설정을 해야 합니다.

앞서 언급했듯이, Amplify Console을 S3와 CloudFront를 이용해서 호스팅합니다. 즉, 정적 웹호스팅을 지원한다는 것입니다. 그래서 각각의 웹 페이지마다 html 파일을 만들지 않는 SPA(Single Page Application)에서는 웹사이트의 하위 path에 직접 접근(예를 들면, 새로고침)하면 S3에서 해당 path의 html 파일을 찾을 수 없어서 404 Not found 에러가 발생하게 됩니다.

 

그래서 SPA를 호스팅 할 때는 ‘Rewrites and redirects settings’ 메뉴에서 정적 파일들 이외의 path에 대한 Rewrite 설정을 해주어야 합니다. 자세한 방법은 AWS 공식 문서를 참고했습니다.

 

이때, Rule이 실제로 반영되는 데에는 약간의 시간이 걸리는 것 같습니다. 제 경험으로는 즉시 반영될 때도 있었고, 약 10분 정도 후에 반영되는 경우도 있었습니다.

 

 

(2) Rewrite Rule을 초기화하는 기능이 없습니다.

Rewrite Rule에 대해서 잘 몰랐을 때, 몇 번 실수로 Rule을 등록한 적이 있었습니다. 그런데, Rule을 정상적으로 돌린 뒤에도 이미 Rule이 적용되었던 파일에 대해서는 수정한 Rule이 반영되지 않는 경험을 하였습니다. 제 경우에는 SPA의 번들 파일이 이 문제를 겪어서 몇 분간 웹사이트 이용에 불편을 느끼게 되었습니다.

 

만약 Rewrite Rule을 초기화하는 기능이 있었다면, 해당 문제는 바로 해결할 수 있었을 테지만, 애석하게도 Rule을 초기화하는 기능은 없습니다.

 

이 문제를 해결하기 위해서 저는 번들 파일에 timestamp를 추가했습니다. Rule이 잘못 적용되어서 기존의 파일에 대해서는 잘못된 Rule이 계속 적용될 때, 새로 빌드를 진행하여 번들 파일의 이름이 빌드 할 때마다 변경되도록 한 것입니다.

 

 

(3) Rewrite Rule에 정규표현식으로 등록했다면 제대로 작동하는지 확인이 필요합니다.

Amplify Console 서비스 자체의 버그인지 정규표현식으로 등록한 Rule이 적용되지 않는 파일이 있었습니다. 그런 경우에는 해당 파일의 path 전체를 직접 등록하면 Rule을 제대로 적용 시킬 수 있었습니다.

 

 

(4) HTTPS 프로토콜이 필수적으로 적용되므로, 내부적으로 사용하는 모든 HTTP 요청은 HTTPS URL만 사용 가능합니다.

Amplify Console은 호스팅을 할 때 기본 Domain이든 Custom Domain이든 무조건 HTTPS 프로토콜만 지원합니다. 그래서 내부적으로 HTTP 프로토콜을 사용하는 URL을 사용하면, 브라우저에서 Mixed Content 이슈로 해당 요청을 막아버립니다. 즉, 이미지 파일이라면 다운로드를 못 할 것이고 API 요청이면 응답을 받을 수 없게 됩니다.

 

이 경우에 2가지 해결방법이 있었습니다. 첫 번째는 임시적으로 브라우저 설정에서 HTTP 프로토콜을 허용하는 것이고, 두 번째는 내부적으로 사용하는 HTTP 요청을 반드시 HTTPS 프로토콜이 적용된 URL만 사용하는 것입니다.

 

저희는 모든 HTTP 요청을 HTTPS URL을 사용할 수 있도록 변경하였습니다. 현재 대부분의 브라우저가 HTTPS  웹사이트에서 HTTP 프로토콜 사용을 기본적으로 막고 있어서, HTTPS URL을 사용하는 것이 옳다고 생각했습니다.

 

 

 

저는 이번 경험을 통해서 Amplify Console이라는 서비스에 대해서도 많이 배울 수 있었습니다. 그리고 또 한가지 배운 점이 있습니다. 화해팀에서는 불편함을 개선하려는 도전과 노력을 적극적으로 지지하고, 그런 노력이 가능한 환경을 만들기 위해 노력한다는 것입니다.

 

이런 좋은 개발 문화 속에서 다음에는 어떤 도전들을 할 수 있을지 기대되며, 앞으로도 이렇게 좋은 경험을 지속적으로 공유할 수 있기를 기대합니다.