백엔드와 프론트엔드에서의 배포

제가 저번시간에 설명해준 내용에서

프로젝트 당시 초기세팅 이전에 정해야 할 목록중에 배포를 어떻게 실행할 것인지 ! 라는 항목이 있었잖아요 !
국내 IT 기업들! 특히 규모가 큰 기업들은 백엔드와 프론트엔드 배포를 한 번에 처리하는 경우도 있지만, 일반적으로 분리된 배포 전략을 채택하는 것이 더 흔한데요!

이를 분리하는 이유는 여러 가지가 있지만, 주된 이유는 다음과 같아요.

1. 배포 주기 및 독립성

• 백엔드와 프론트엔드의 개발 및 배포 주기가 다를 수 있음: 백엔드 서비스는 데이터베이스 스키마 변경, API 수정 등 상대적으로 더 복잡한 변경이 많고, 신중한 테스트와 배포가 필요해요. 반면, 프론트엔드는 UI/UX 개선이나 마이너 업데이트가 더 자주 발생할 수 있죠.
• 독립적인 배포의 필요성: 프론트엔드와 백엔드를 독립적으로 배포할 수 있으면, 각 팀이 더 빠르고 유연하게 작업할 수 있어요. 이는 개발 속도를 높이고, 각각의 서비스가 필요한 시점에 맞춰 배포될 수 있도록 해요.

2. 마이크로서비스 아키텍처

• 많은 대형 IT 기업들은 마이크로서비스 아키텍처를 채택하고 있어요. 이 아키텍처에서는 서비스들이 각각 독립적으로 개발, 배포, 운영될 수 있도록 구성됩니다.
• 프론트엔드와 백엔드 서비스가 여러 마이크로서비스에 걸쳐 있을 경우, 각 서비스가 독립적으로 배포될 수 있도록 구성되며, 이를 통해 변경이 다른 서비스에 영향을 미치지 않게 돼요.

3. CI/CD 파이프라인

• 프론트엔드와 백엔드 각각에 최적화된 CI/CD 파이프라인을 구축하여, 독립적으로 빌드, 테스트, 배포가 가능하도록 설정하는 것이 일반적이에요.
• 예를 들어, 프론트엔드는 Vercel, Netlify와 같은 툴을 사용해 자동화된 배포 파이프라인을 구축할 수 있으며, 백엔드는 Jenkins, GitHub Actions 등을 사용해 독립적으로 배포 관리가 이루어질 수 있어요.

4. 복잡성 관리

• 프론트엔드와 백엔드를 한 번에 배포하려면 배포 과정의 복잡성이 증가할 수 있어요. 특히 대규모 시스템에서는 이런 복잡성이 문제를 일으킬 수 있기 때문에, 각각의 서비스가 독립적으로 문제를 해결하고 배포할 수 있도록 설계하는 것이 일반적이에요.

5. 실제 사례

• 네이버, 카카오, 쿠팡, 배달의민족 등 대형 IT 기업들은 일반적으로 백엔드와 프론트엔드를 별도의 배포 파이프라인에서 관리해. 이는 대규모 서비스 운영 시 배포 과정에서 발생할 수 있는 위험을 줄이고, 더 유연한 배포 전략을 진행해요.

백엔드와 프론트엔드를 한 번에 배포하는 경우도 없지는 않지만, 대부분의 경우 각각의 서비스가 독립적으로 배포되는 방식이 더 일반적이에요.

이는 서비스의 안정성을 높이고, 개발 주기의 차이를 효율적으로 관리할 수 있게 하기 때문이죠! 특히 대규모 IT 기업에서는 이런 분리된 배포 전략을 통해 서비스 운영의 유연성과 효율성을 극대화하는 것이 중요합니다.

보통 토이프로젝트를 진행할때 백엔드가 한번에 코드를 올려서 배포하는 경우가 많은데, 그런 경우는 그저 코드량이 적거나 지속적인 배포를 하지 않는 경우(프론트 리펙토링 사항이 많이 없을경우)에만 종종 그런답니다.

그래서 백엔드와 프론트가 애용하는 배포툴이 정해져 있는 느낌인데요!

저희는 백엔드는 AWS EC2 를 사용했고 프론트는 Vercel을 사용해서 구분지어서 배포를 진행했죠!

실제 이거보다 더 다양한 플랫폼이 있는데, 그 종류를 알아보고 우리나라 IT 기업이 사용하는 사례에 대해서 알아보아요!

다양한 플랫폼 & 실제 사용 사례

다양한 배포 플랫폼 종류

1. AWS EC2 (Amazon Web Services Elastic Compute Cloud)

• 특징:
  • 유연성: 사용자가 직접 서버의 인스턴스 타입, 운영체제, 네트워크 설정 등을 선택할 수 있습니다.
  • 확장성: 자동 스케일링 기능을 통해 트래픽 증가에 따라 인스턴스를 자동으로 확장할 수 있습니다.
  • 다양한 서비스 통합: RDS, S3, CloudFront 등 AWS의 다양한 서비스와 쉽게 통합할 수 있습니다.
• 장점:
  • 강력한 커스터마이징: 서버 환경을 세밀하게 제어할 수 있어 다양한 요구사항을 충족할 수 있습니다.
  • 글로벌 인프라: AWS는 전 세계에 데이터 센터를 보유하고 있어 글로벌 서비스를 쉽게 배포할 수 있습니다.
  • 유료로 사용한 만큼만 비용 청구: 시간당 비용 지불 방식으로 사용량에 따라 유연한 비용 관리가 가능합니다.
• 단점:
  • 복잡한 관리: 서버 관리와 인프라 설정이 복잡하여 경험이 없는 사용자는 어려움을 겪을 수 있습니다.
  • 비용 관리 어려움: 초기 설정이 잘못되면 비용이 급증할 수 있으며, 이를 모니터링하고 관리하는 데 신경 써야 합니다.

2. Google Cloud Platform (GCP)

• 특징:
  • AI/ML 서비스 통합: Google의 강력한 AI/ML 서비스와 통합이 용이합니다.
  • Kubernetes 엔진 제공: Google Kubernetes Engine(GKE)은 Kubernetes 기반의 애플리케이션 관리에 최적화되어 있습니다.
  • 높은 보안 및 네트워크 성능: Google의 글로벌 네트워크 인프라를 통해 높은 보안성과 빠른 네트워크 성능을 제공합니다.
• 장점:
  • 데이터 분석 및 머신러닝에 최적화: Google의 빅데이터 및 머신러닝 도구와의 통합이 강력합니다.
  • 빠른 네트워크 속도: Google의 전 세계적인 네트워크 인프라를 통해 빠른 콘텐츠 제공이 가능합니다.
  • Kubernetes의 최적화: GKE를 통해 컨테이너화된 애플리케이션의 배포 및 관리가 용이합니다.
• 단점:
  • 가격이 비교적 비쌈: AWS와 비슷하게, 복잡한 가격 구조와 높은 비용이 단점이 될 수 있습니다.
  • 지원되는 서비스의 지역적 제한: 특정 서비스는 특정 지역에서만 지원될 수 있습니다.

3. Microsoft Azure

• 특징:
  • Windows 및 .NET 통합: Microsoft 제품군과의 강력한 통합을 제공합니다.
  • 하이브리드 클라우드: 온프레미스 데이터센터와 클라우드 환경을 통합 관리할 수 있습니다.
  • 엔터프라이즈 지원: 기업 고객을 위한 강력한 보안, 규제 준수, 지원 옵션을 제공합니다.
• 장점:
  • Microsoft 제품과의 호환성: 특히 Windows Server, Active Directory 등 Microsoft 환경에서 작업하는 기업에 적합합니다.
  • 하이브리드 환경 지원: 온프레미스와 클라우드 간의 통합 관리가 용이합니다.
  • 광범위한 데이터센터: 전 세계적으로 분포된 데이터센터를 통해 글로벌 서비스 제공이 가능합니다.
• 단점:
  • 비용 관리 어려움: 다른 클라우드 플랫폼과 마찬가지로, 복잡한 비용 구조를 가지고 있으며, 잘못 관리할 경우 비용이 급증할 수 있습니다.
  • Microsoft 중심: Microsoft 환경에 최적화되어 있어, 다른 환경에서의 유연성은 떨어질 수 있습니다.

4. Vercel

• 특징:
  • 프론트엔드에 최적화: 특히 Next.js 프로젝트에 최적화된 배포 플랫폼입니다.
  • 자동화된 CI/CD: GitHub, GitLab과 통합하여 자동으로 배포 파이프라인을 구성할 수 있습니다.
  • 서버리스 기능 제공: 서버리스 함수(Netlify Functions)를 통해 동적 기능을 쉽게 구현할 수 있습니다.
• 장점:
  • 간편한 배포: 개발자 친화적인 인터페이스로, 복잡한 설정 없이 쉽게 배포할 수 있습니다.
  • 빠른 글로벌 배포: 전 세계적으로 분산된 CDN을 통해 빠른 콘텐츠 제공이 가능합니다.
  • 자동 확장: 트래픽 증가에 따라 자동으로 리소스를 확장하여 처리할 수 있습니다.
• 단점:
  • 제한된 커스터마이징: 서버에 대한 직접 접근이 불가능하며, 복잡한 백엔드 애플리케이션 배포에는 부적합할 수 있습니다.
  • 비용: 대규모 프로젝트나 트래픽이 많은 서비스의 경우 비용이 빠르게 증가할 수 있습니다.

5. Netlify

• 특징:
  • 정적 웹사이트 배포에 최적화: Jamstack 아키텍처를 위한 플랫폼으로, 정적 사이트와 서버리스 기능을 지원합니다.
  • Git 통합: GitHub, GitLab, Bitbucket과 통합하여 자동화된 배포 파이프라인을 제공합니다.
  • 서버리스 함수: 정적 사이트 외에도 간단한 서버리스 백엔드를 구현할 수 있습니다.
• 장점:
  • 손쉬운 사용: 매우 간단한 설정으로 정적 사이트를 빠르게 배포할 수 있습니다.
  • 무료 SSL 제공: 자동으로 SSL 인증서를 설정하여 HTTPS를 지원합니다.
  • 자동화된 빌드 및 배포: 코드 푸시만으로도 자동으로 빌드 및 배포가 이루어집니다.
• 단점:
  • 복잡한 애플리케이션에 제한적: 정적 웹사이트나 간단한 애플리케이션에는 적합하지만, 복잡한 서버 기반 애플리케이션에는 제한이 있을 수 있습니다.
  • 서버리스 기능의 제한: 제한된 서버리스 기능만을 제공하여, 복잡한 API 백엔드를 구축하기에는 부적합할 수 있습니다.

6. Heroku

• 특징:
  • PaaS 서비스: 다양한 프로그래밍 언어를 지원하며, 앱을 쉽게 배포하고 관리할 수 있습니다.
  • 자동화된 배포: Git을 통해 코드를 푸시하면, 자동으로 빌드되고 배포됩니다.
  • 애드온: 데이터베이스, 캐싱, 모니터링 등 다양한 서드파티 애드온을 쉽게 추가할 수 있습니다.
• 장점:
  • 쉬운 배포 및 관리: 인프라 관리에 대한 부담 없이 애플리케이션 코드에 집중할 수 있습니다.
  • 확장 가능성: 트래픽 증가에 따라 쉽게 확장할 수 있습니다.
  • 무료 티어: 초기 단계의 프로젝트를 위한 무료 플랜 제공.
• 단점:
  • 비용 증가: 확장에 따라 비용이 급격히 증가할 수 있습니다.
  • 제한된 커스터마이징: 더 복잡한 인프라 설정이나 고급 기능을 원할 경우, Heroku는 적합하지 않을 수 있습니다.

7. AWS Amplify

• 특징:
  • 풀스택 애플리케이션 지원: 프론트엔드 및 백엔드 모두 쉽게 관리하고 배포할 수 있습니다.
  • 서버리스 아키텍처: 서버 관리를 하지 않고 서버리스 방식으로 애플리케이션을 구축하고 배포할 수 있습니다.
  • 모바일 및 웹 앱에 최적화: React, Angular, Vue.js와 같은 프레임워크를 지원하며, 모바일 앱과의 연동도 용이합니다.
• 장점:
  • 통합된 AWS 서비스: S3, Lambda, DynamoDB 등과 쉽게 통합할 수 있습니다.
  • 자동화된 CI/CD: 코드 푸시 시 자동으로 빌드, 테스트, 배포가 이루어집니다.
  • 서버리스 기능: 인프라 관리 부담 없이 서버리스 애플리케이션을 구축할 수 있습니다.
• 단점:
  • AWS 종속성: AWS 환경에 종속되어, 특정 클라우드 환경에서 벗어나기 어렵습니다.
  • 복잡한 비용 구조: 사용한 AWS 리소스에 따라 비용이 복잡하게 산정될 수 있습니다.

대형 IT 기업들의 배포 플랫폼 선택

대형 IT 기업들은 다양한 요인에 따라 여러 배포 플랫폼을 사용하거나 자체적으로 구축한 솔루션을 사용해요. 몇 가지 예를 들어볼게요 !!

1. 네이버 & 카카오:
   • 사용 플랫폼: 주로 자체 데이터센터와 온프레미스 환경을 많이 사용하지만, 최근에는 클라우드 서비스를 적극 활용하고 있습니다. 카카오는 AWS와 Azure를 사용하기도 하며, 네이버는 네이버 클라우드 플랫폼을 사용합니다.
   • 이유: 개인정보 보호 및 높은 트래픽 처리, 높은 가용성 요구사항 때문입니다.
2. 구글:
   • 사용 플랫폼: Google은 자사의 Google Cloud Platform(GCP)을 적극적으로 사용합니다.
   • 이유: 자사 제품군과의 강력한 통합, AI/ML 등 고급 기능 활용.
3. 쿠팡:
   • 사용 플랫폼: 주로 AWS를 사용합니다. 쿠팡은 AWS의 다양한 서비스(S3, EC2, RDS 등)를 적극 활용하여 글로벌 서비스를 운영하고 있습니다.
   • 이유: 빠른 확장성, 글로벌 인프라 제공, 다양한 AWS 서비스와의 통합성.
4. 배달의민족:
   • 사용 플랫폼: AWS와 같은 클라우드 서비스를 많이 사용합니다.
   • 이유: 대규모 트래픽 처리, 확장성, 빠른 배포 요구.
5. 당근마켓:
   • 사용 플랫폼: 주로 AWS를 사용합니다. 당근마켓은 모바일 애플리케이션에 최적화된 인프라를 위해 AWS의 다양한 서비스를 사용합니다.
   • 이유: 유연한 확장성, 글로벌 확장 가능성, 서버리스 아키텍처 활용.
6. 토스:
   • 사용 플랫폼: AWS를 기반으로 하여, 금융 보안 및 규제 요구를 충족하면서도 확장성과 안정성을 제공합니다.
   • 이유: 높은 보안성 요구, 금융 데이터 관리, 높은 가용성.

이처럼 각 기업은 서비스의 성격, 규모, 보안 요구사항, 기술적 요구에 따라 적합한 배포 플랫폼을 선택하곤해요. 예를 들어, 클라우드의 확장성이나 글로벌 인프라가 중요한 경우 AWS나 GCP를, 보안과 프라이버시가 중요한 경우 자체 데이터센터나 하이브리드 클라우드를 선택하는 경우가 많아요.

이렇게 배포 플랫폼을 선정할 때에도 꼭 이유를 명확하게 가지고 결정해야하는 부분이 많죠!

저희가 프론트 배포를 Vercel로 하게 된 이유도 사용법이 간단하고 엄청나게 큰 코드가 아니어 트래픽이 거창하지 않았고 github 와의 연동이 편리하여 선택하기도 했죠!!

그래서 이렇게 다양한 배포 플랫폼을 선택할때 다양한 장단점을 비교하고 이유를 명확하게 가지고 배포 툴을 선택해야합니다 !

위에 종류를 조금 더 살펴보면 저희 프론트 배포에서 AWS Amplify 도 유용하게 쓰였겠네요.

Vercel 로 내 프로젝트 배포하기

토이프로젝트 진행시에 프론트 엔드 개발자들이 주로 서버리스 배포를 진행할때 Vercel을 활용하곤 하는데, Vercel 사용방법이 위에서 설명한대로 매우 간편하기 때문이에요.

그럼 간단하게 프로젝트 배포하는 법에 대해서 소개해보도록 할게요!

1. 먼저 Vercel에 로그인하여 Add New 버튼을 클릭해 Project를 선택한다.
   

2. 그렇게 하면 이렇게 깃허브에서 내가 원하는 organization 과 repository를 선택할 수 있는데 배포를 원하는 레포지토리를 불러온다. (물론 미리 배포 하고 싶은 레포가 있어야 겠죠!)
   
   만약 위 사진처럼 보여지지 않는다면, +Add Github Acount를 눌러서 추가하도록 한다.

3. import 버튼을 누르면 configure Project 페이지가 나타나는데, Project Name과 Framework를 선택하고 root directory를 어디로 할것인지 레포 내부의 폴더를 선택하여 준 후 deploy 버튼을 누른다.
   

4. Vercel 내부 CD가 동작하며 빌드가 다 마무리 되면, 이렇게 배포가 완료된다 !
   저기 Domains가 바로 배포된 url이다!
   

5. 추가적으로 내가 작업한 환경변수를 설정해주고 싶다면, Settings에 들어가서 Environment Variables 탭에서 key값을 설정해주면 된다.
   
   배포 모드면 production으로 개발 모드면 development로!

6. 그외에도 Vercel 내부에서 도메인 이름을 바꾼다던지, 유저 데이터 분석을 해준다던지 다양한 기능들이 존재하기에 내가 필요한 기능들을 유용하게 사용하면 된다!
   빌드 오류가 뜬다면 deployments에서 확인가능 !!

---

이렇게 프론트 Vercel 배포 툴까지 사용해보았는데, 사실 현재 기업이 가장 많이 사용하고 있는 배포 툴은 AWS EC2 Redis S3 이에요.
저도 AWS 배포를 직접 해보았지만, 블로그로 내용을 담기엔 너무 길어지고 프론트엔드 초심자 개발자가 AWS EC2 배포할일이 적겠다 라는 판단이 들어 해당 내용은 담지 않았어요!

앞으로 다양한 배포 플랫폼에 대해서 공부하며 사용할 수 있는 플랫폼이 많아졌으면 좋겠다는 생각을 합니다!