프론트엔드 개발자를 준비하면서 개인적인 개발 프로젝트에 몰두하게 될 때는 많다. 그 과정에서 당연하게도 기능의 구현과 코드 작성에 집중하게 된다. '어떤 기능을 추가해야 할까?', '이 기능을 구현하는 최적의 방법은 무엇일까?', '내가 작성한 코드는 효율적인가?' 이러한 질문들이 머릿속에 가득차게 된다. 그런데 사실 이런 의문보다 더 중요한 문제가 하나 존재한다.

'이 모든 것을 어떻게 다른 사람들에게 보여줄 수 있을까?'

아무리 훌륭한 기능이나 완벽한 코드를 작성했다고 해도, 이를 제대로 배포하지 못한다면 그 가치는 반감될 수 밖에 없다. 과거에 개인 프로젝트를 진행하면서 가장 간과했던 것은 바로 이런 배포 과정이었다. 내가 뭘 만들던지 실제 사용자들이 접근하고, 경험할 수 있도록 만드는 것이야말로 개발한 서비스의 진정한 완성이라 할 수 있다. 이번 글에서는 프로젝트 배포와 관련하여 내가 고민하고 결론내렸던 과정들을 되돌아보려 한다.

1. 어떻게 하지?

프론트엔드 개발자라고 해도 오롯이 프론트엔드 파트만을 다룰 수는 없다. 내가 어떤 회사에서 어떤 역할을 맡을지 모르는데다, 프론트엔드 개발도 백엔드와 데이터베이스가 돌아가는 것을 알고는 있어야 순탄하게 진행할 수 있기 때문이다.

이번 개인 프로젝트를 진행하면서 나는 React.js의 프론트엔드, Express.js의 백엔드, MySQL의 데이터베이스를 사용할 것을 기획했다. 본격적인 개발에 앞서 가장 먼저 시작한 것이 배포 방법에 대한 고민이다.

프론트엔드 배포:

이쪽은 정적 파일이기 때문에 배포가 상대적으로 쉽고 간단하다. 이전에 많이 해보기도 해서 이 부분은 큰 고민이 없었다.

Netlify, Vercel, AWS S3, GitHub Pages...

Github와 연동까지 잘 되어있어서 프론트엔드 파일을 빌드해서 Git에 올려두기만 하면, 해당 서비스에서 알아서 배포 및 도메인 할당까지 진행해준다.

백엔드 배포:

여기부터가 상당히 골때리는 문제였다. 백엔드는 정적 파일에 속하지 않기 때문에 프론트엔드 배포보다 더 복잡하고 어려운 단계를 거쳐야하기 때문이다.

이전에는 Heroku를 이용해서 프론트엔드와 백엔드를 같이 배포했던 적이 있었는데, Heroku가 유료화되기도 했고 기존에 내가 했던 방법들을 까먹기도 했다. 실제 서비스에서 가장 대중적으로 사용되는 것이 AWS인 만큼, 이번에는 이 방법을 선택해보기로 했다.

Heroku, AWS EC2, Azure, DigitalOcean...

데이터베이스 배포:

이전 프로젝트에서는 Google Firebase의 Firestore Database를 사용해본 적이 있었다. 쉽고 간단하게 사용할 수 있는 장점이 있었지만 RDBMS 특유의 쿼리문을 이용한 더 상세한 데이터 다루기가 안되는 단점도 있어, 이번에는 MySQL을 쓰기로 했기에 다른 방법을 찾아야 했다.

AWS RDS, Google Cloud SQL, DigitalOcean Managed Databases

2. 복잡하지만, 간단한 방법이 있다.

문제는 백엔드와 데이터베이스의 배포 방법이었다. 그런데 여러 방법들을 나열하고 보니 프론트엔드, 백엔드, 데이터베이스를 모두 배포할 수 있는 서비스가 하나 존재했다.

AWS!

AWS(Amazon Web Services)는 단순히 하나의 서비스만을 제공하는 시스템이 아니다. 정적 파일 배포, 데이터베이스 배포, SSL 인증서 발급, 도메인 생성 등등등.. 웹에서 필요한 대부분의 서비스들을 제공해주고 있다.

무료가 아니고 사용 방법이나 설정 등이 매우 복잡한 것이 단점이지만, AWS는 일단 IT 업체들에서 가장 대중적으로 사용되는 서비스인 만큼 이번 기회에 알아둘 필요도 있었고. 프론트엔드, 백엔드, 데이터베이스의 배포를 모두 한 곳에서 관리할 수 있다는 점이 매력적이었다. 따라서 프론트엔드를 포함한 프로젝트의 배포 방법은 모두 AWS를 사용하기로 했다.

프리티어!!

인터넷 등지에서는 AWS 사건사고에서 과금과 관련된 문제들을 흔히 볼 수 있다. 서비스를 잘못 사용했더니 돈을 왕창 물더라, 서비스를 켜놓고 잊어버리고 있었더니 요금이 무진장 발생했더라.. 주머니 사정이 좋지도 않은데 몇 만원도 아니고 몇십 만원의 지불을 요구받는 것 만큼 두려운 일이 없지만, 다행스럽게도 AWS에서는 신규 계정에 한하여 12개월 동안 '프리티어' 사용권한을 부여해주고 있다.

프리티어란 간단하게 말하자면 AWS의 일부 서비스에 한하여 제한적인 상황에서 무료 사용량을 제공해주는 것이다. 나의 경우 S3, EC2, RDS를 사용해야 하는데 다행스럽게도 3개 서비스 모두 프리티어 사용량이 제공되고 있었다.

Amazon S3, EC2, RDS

무료 사용량: AWS 무료 계층에서는 매달 5GB의 표준 저장 용량, 20,000개의 GET 요청, 2,000개의 PUT 요청을 제공합니다.

Amazon EC2

무료 사용량: t2.micro 또는 t3.micro 인스턴스 유형을 월별 750시간까지 무료로 사용할 수 있습니다. 이는 매달 하나의 인스턴스를 계속 실행할 수 있음을 의미합니다.

Amazon RDS

무료 사용량: 무료 계층은 표준 db.t2.micro DB 인스턴스 750시간, 20GB의 데이터베이스 스토리지, 20GB의 백업 스토리지를 매달 제공합니다.
데이터베이스 엔진: MySQL, PostgreSQL, MariaDB, Oracle BYOL(자체 라이선스 사용), SQL Server Express Edition 등을 사용할 수 있습니다.

프리티어에서 제공하는 무료 사용량은 제한적이고, 인스턴스의 성능도 떨어지는 편이다. 그러나 내가 지금 하려는 것이 다수의 실제 사용자들이 움직이는 서비스가 아니라, 내 개인 포트폴리오에 들어가는 용도와 공부 목적의 프로젝트이기에 이런 제약은 아무 문제가 되지 않았다.

3. Amazon S3, EC2, RDS

여기저기 알아보며 프로젝트 배포와 관련하여 대략 이런 결정을 내릴 수 있었다.

프론트엔드 배포:

Amazon S3 (Simple Storage Service)

정적 웹 콘텐츠(HTML, CSS, JavaScript 파일 등)의 저장 및 배포에 사용되는 정적 파일 호스팅 서비스.

백엔드 배포:

Amazon EC2 (Elastic Compute Cloud) 또는 AWS Elastic Beanstalk

동적인 웹 애플리케이션 서버를 호스팅 하는데 사용되는 서비스. 가상 서버 인스턴스를 통해 서버 사이드 애플리케이션을 실행할 수 있다.

데이터베이스 배포:

Amazon RDS (Relational Database Service)

관계형 데이터베이스 서버를 운영하는데 사용되는 서비스, MySQL을 포함한 다수의 데이터베이스 엔진을 제공하며 이들을 관리하는 서비스를 제공한다.

기타 등등..

보안: AWS Identity and Access Management (IAM)을 사용하여 리소스에 대한 액세스를 제어할 수 있다.
도메인과 SSL: AWS Route 53을 사용하여 도메인을 관리하고, AWS Certificate Manager로 SSL 인증서를 쉽게 적용할 수 있다.
모니터링과 로깅: Amazon CloudWatch를 사용하여 어플리케이션의 성능을 모니터링하고 로그를 관리할 수 있다.
CI/CD 파이프라인: AWS CodePipeline, CodeBuild, CodeDeploy를 사용하여 CI/CD 파이프라인을 설정할 수 있다.

이번 프로젝트의 배포 방법은 Amazon S3, EC2, RDS로 결정하였다. 기타 항목들의 서비스는 프로젝트를 구현하면서 필요에 따라 적용을 생각해보기로 하였다.

4. EC2에 프론트엔드를?

사실 EC2에는 백엔드 파일만 배포할 필요는 없다. 프론트엔드도 EC2로 배포가 가능하다.

프론트엔드 / 백엔드를 EC2에서 함께 배포하는 방법

장점:

일관된 환경: 프론트엔드와 백엔드가 같은 서버 환경에서 작동하므로 환경 설정이 일관됩니다.

통합 관리: 단일 인스턴스에서 모든 애플리케이션 구성 요소를 관리할 수 있어 관리가 편리합니다.

단점:

자원 분할: 하나의 서버에서 두 애플리케이션을 실행하므로 자원(메모리, CPU)을 공유해야 합니다.

보안 리스크: 프론트엔드와 백엔드가 같은 환경에 있을 때 발생할 수 있는 보안상의 위험이 증가할 수 있습니다.

프론트엔드는 S3, 백엔드는 EC2로 배포하는 방법

장점:

성능 및 확장성: S3는 정적 웹 호스팅에 최적화되어 있어 빠른 콘텐츠 전달과 높은 가용성을 제공합니다.

비용 효율: S3는 정적 파일 호스팅에 대해 낮은 비용을 제공합니다.

보안 및 격리: 애플리케이션의 프론트엔드와 백엔드가 분리되어 있어 서로 영향을 덜 받습니다.

단점:

관리 복잡성: 두 개의 서비스(EC2 및 S3)를 따로 관리해야 하므로 관리가 복잡해질 수 있습니다.

구성 및 설정: S3와 EC2 간의 연동 및 네트워크 구성이 필요합니다.

5. 결론

어떤 방법을 선택하더라도 장점과 단점이 공존한다. 결국 요구사항에 맞춰 가장 적절한 방법을 선택하는게 최선. 통합 관리의 유용함, 분리 관리의 효율성, 발생할 트래픽은 어느 정도 수준인가, 애플리케이션의 보안 수준, 각 서비스의 관리 및 운영 능력 등등.. 자신에게 맞는 방법을 선택해야한다.

나의 경우 프로젝트 규모가 워낙 소규모이기 때문에 어느 방법을 써도 문제는 없었다. 다만 AWS를 처음 써보는지라, 학습의 목적도 존재하는 프로젝트였기에 프론트엔드는 S3 서비스를 이용해서 독립적으로 배포하기로 결정하였다.