서비스 코드를 갈아엎으면서 어떻게 최적화할지도 같이 고민을 좀 해봤습니다. 기존에는 EC2를 VPC처럼 이용하던 PHP 기반 서비스였는데, 이를 Frontend-backend 구조로 분리해서 API 지원, 앱 개발 등 추후 다양한 확장을 할 수 있도록 설계를 했었습니다.

물론, 그건 설계의 이야기고 현실은 시ㄱ...

어쨌던, React단 코드와 Express 코드가 한 repo 폴더 안에 담겨있는 흔히 보는 구조가 나왔습니다. 이제 이걸 어떻게 배포해야할까요?

1. 하던대로 서버에 빌드를 올려서 돌린다
2. CI/CD를 빡세게 만들어서 매주 새 빌드를 받고 로그 분석하고..
3. 아니면 다른 방법이...?

개발론적으로는 CI/CD를 빡세게 잡는게 맞겠죠. 하지만 현실은 프로그래밍도 잘 모르는 새내기 두명 앉혀다가 관리를 맡겨야 하는데, 그런 애들에게 개발 프로세스를 전부 설명해줄 여력이 없다는 겁니다.

그리고 개발 과정 동안 개발팀을 지켜본 결과, 사람은 편한 길로 간다는 교훈을 얻을 수 있었습니다.

뭔 말이냐고요? 아무리 CI/CD를 빡세게 만들어 물리 서버에 자동 배포되게 해도, 결국엔 서버에서 수정을 해서 다 꼬이게 만든다는 겁니다. 그게 편하니까요.

그래서 Serverless Deployment로 가기로 했습니다. 일단 Frontend만이라도요(Backend를 서버에서 건드릴 일이 없길 빕니다). 기존에 Serverless 백엔드를 구성해 본 적이 있었기에, 상당히 편할거라고 기대를 했었죠.

물론 일반적 환경이라면 그랬을 겁니다.

Amplify도 다른 서비스처럼 원격 저장소의 내용이 변하면 가져와서 빌드 후 배포하는 과정을 거치게 됩니다. 특히, 개발 중인 브랜치를 테스트할 수 있다는 기능이 있다는 것은 마음에 들었어요. 인증서를 만들어준다는 것도 좋았고.

근데 인증서를 만들어 줘야’만’ 한답니다. 즉, 인증이 잘 안되거나 해서 발급이 안되면 바로 에러를 뿜습니다.

Chapter 1. The Certificate

이론적으로는 인증이 굉장히 쉽습니다.

서버로 향하는 CNAME에 하나 더 추가하면 그 정보로 인증을 하겠다.

하지만 이 인증 과정이 문제가 **많습니다(물론 Route 53을 쓰면 되긴 하지만, 저희가 서브도메인을 받아오는 입장이라 쉽지 않습니다). 예를 들자면, 서버 CNAME 기록 추가시 오타가 났다고 합시다.

그러면 “서버 CNAME 기록이 일치하지 않습니다” 라고 해줍니다. 참 친절하기도 해라. 그래서 수정을 해주면... 타임아웃이 나서 다시 인증을 시도합니다.

근데... 어라? 인증용 CNAME 기록이 바뀌었네요? 그래서 다시 바꾸러 가줍니다. 그러면 “인증용 CNAME 기록이 기존과 충돌합니다.” 라는 에러로 바뀌어 있더라고요. 자세히 보니, 서버 CNAME 기록도 바뀌었어요.

삭제하고 다시 만들면 편할겁니다. 근데 전 이번에 도메인을 받아서 했어요. 서브도메인을. 새 서브도메인을 만드는 것은 별 문제가 없는데, 기존 서브도메인은 사람이 승인을 해줘야 변경처리가 됩니다.

이 관료주의적 시스템과 실패하면 재시작해야하는 인증 시스템이 합쳐지면 고구마가 탄생합니다.

Chapter 2. Lost in Documents

CORS 관련 보안이 최근 몇년 사이 상당히 강화되었죠. 그래서 reverse proxy를 이용해서 다른 서버지만 같은 도메인으로 콘텐츠를 제공하시는 분들이 많을겁니다.

이 기능을 지원하기 때문에 ‘오, 좋다’, 이러면서 바로 implement 했었는데... 생각보다 문제가 많더라고요?

일단, React가 기본적으로 SPA라는 것을 이해해야 합니다. 근데 hard link를 잘 걸어놓는 웹사이트 특성상 그 링크를 타고 들어가면 바로 콘텐츠가 나와야죠.

이걸 지원하기 위해 기본으로 redirect rule이 하나 설정되어 있습니다. 그리고 index.html용 리다이렉트가 하나 더 있고요.

근데 왜 이게 있는지 설명하는 문서가 하나도 없습니다. 왜 있는지 모르니, 일단 삭제해 봅시다. 그러니 앱이 안돌아갑니다. 빈 화면만 나오더라고요.

대체 왜 그런가 3시간을 찾아 헤메니 그 줄을 다시 추가하게 됐습니다.

고마워요, AWS. 당신의 유명한 지원 정책 덕분에 한 줄로 해소될 문제를 3시간동안 돌아왔네요.

이거 말고도 리다이렉트 관련 문제가 몇가지 더 있었지만, 나중에 이야기할거리인 것 같네요.

Chapter 3. Verdict

만약 여러분 목적이 scalable frontend deployment라면 굳이 Amplify를 쓸 필요가 없어 보입니다. 애초에 그 정도로 신경쓰셔야 한다면 좀 더 전문적인 서비스가 나아 보이고요.

그리고 react를 막 배워 배포할 생각인데, AWS free tier라서 쓰실 분도 추천하진 않습니다. 지원이 많이 부족하거든요.

저는 개인적으로 3~5인의 개발팀으로 구성된 작은 단체가 쓸만하다고 생각됩니다. 데이터 비용은 그렇게 싸지 않지만, CI/CD 환경에 상당히 잘 맞아 떨어지고 설정 후 이용에 큰 지식이 필요 없다고 느꼈습니다.

여러분의 배포가 평탄하길 빌며,