웹 애플리케이션 배포 방법

1. 프론트 엔드와 백 엔드의 분리

React, Vue, Angular 등은 JavaScript 라이브러리 혹은 프레임워크이다. 즉, 이것들은 클라이언트의 브라우저 단에서 실행되는 JavaScript를 멋지게 코딩할 수 있도록 도와주는 수단일 뿐이다. 특히 React나 Vue의 경우 JavaScript 코드를 작성할 때 필요한 만큼만 적재적소에 사용할 수 있기 때문에 이것들을 사용한다고 해서 프론트 엔드와 백 엔드가 구분되는 것은 절대 아니다. 다만 이것들을 활용하면 프론트 엔드와 백 엔드를 완전히 구분하여 두 기능을 독립적으로 개발할 수 있게 된다. 그렇다면 그것이 어떻게 가능한 것인지, 그 동작 원리를 한 번 살펴보도록 하자. 

개발자가 React 라이브러리를 활용하여 클라이언트에게 제공할 JavaScript 파일들을 ES6 + JSX 문법으로 코딩하면, Babel 등의 컴파일러가 그것들을 모든 브라우저에서 호환이 가능한 문법(ES5)의 코드로 변환해준다. 또한 Webpack 등의 모듈 번들러가 HTML, CSS, JavaScript 파일들을 효율적인 방식으로 적절히 번들링 하여 준비해둔다. create-react-app으로 생성한 React 프로젝트의 개발 환경에서는 "npm start"로 실행되는 개발 서버(webpack-dev-server)가 파일이 수정될 때마다 이러한 변환 작업들을 자동으로 수행해준다. 그리고 실제 배포 시에는 번들링 한 파일들을 프론트 엔드 서버의 다큐먼트 루트에 미리 준비해두고 웹 서버가 그 파일들을 제공할 수 있도록 설정해야 한다. 이후 클라이언트가 요청을 보내면 프론트 엔드 서버는 미리 준비해둔 HTML, CSS, JavaScript 파일들을 클라이언트에게 제공한다. 그러면 클라이언트의 브라우저는 전달받은 JavaScript 파일을 실행하여 페이지에 렌더링을 시작한다. 즉 앞서 React 라이브러리를 활용하여 코딩했던 JavaScript 코드는 동적으로 DOM에 렌더링을 해주기 위한 코드였던 것이다. 만약 렌더링 과정에서 DB 데이터가 필요한 경우에는 백 엔드 서버에게 API 요청을 보내서 필요한 데이터를 요청한다. 이러한 맥락에서 백 엔드 서버를 API 서버라고 부르기도 한다. 필요한 데이터를 전달해주는 역할만 수행할 뿐, 페이지 렌더링에 필요한 정적 리소스들을 제공해주는 것이 아니기 때문이다.

이후, 페이지를 리로드 하지 않고 부분적으로만 리렌더링이 필요해지는 경우에는 사용자의 버튼 클릭과 같은 액션을 감지하여 JavaScript가 마찬가지 방식으로 백 엔드 서버에게 API 요청을 보내게 된다. 이때는 딱 해당 부분의 리렌더링에 필요한 데이터만 요청하게 된다. 그러면 JavaScript가 그 응답 데이터를 가지고 필요한 부분만 리렌더링을 해주게 된다. 이것 또한 개발자가 React 라이브러리를 활용하여 미리 코딩해둔 JavaScript 코드의 역할인 것이다.

이러한 맥락에서 React, Vue, Angular 등을 SPA(Single Page Application)라고 부른다. 기본적인 HTML, CSS, JavaScript 파일들만 제공받은 다음에 렌더링이 필요한 부분에 대해서만 직접 백 엔드 서버에게 API 요청을 보내서 리렌더링을 하는 방식이기 때문이다. 한 번 받은 페이지를 깜빡 거리는 일 없이 동적으로 제어가 가능해진다.

※ 이와는 다르게 백 엔드 서버의 기능과 프론트 엔드 서버의 기능을 하나의 서버에서 서비스하도록 할 수도 있다. 즉 웹 서버, 웹 어플리케이션 서버, 웹 어플리케이션을 하나의 서버에 두는 것이다. 이 경우, 웹 서버가 웹 어플리케이션 서버에 대한 프록시 서버로 동작하도록 함으로써 API 요청을 처리할 수 있다. 그러나 이는 해당 서버가 마비되면 백 엔드 서버의 기능과 프론트 엔드 서버의 기능이 모두 마비된다는 문제점 때문에 최근에는 많이 사용하지 않는 듯하다.

※ CORS 및 쿠키 문제
백 엔드 서버와 프론트 엔드 서버가 서로 다른 도메인을 가지는 경우, 다음과 같은 두 가지 문제점이 발생한다. 첫째, 기본적인 CORS 정책은 다른 오리진의 자원에 접근하는 것을 막는다는 문제이다. 따라서 백 엔드 서버에게 API 요청을 보내면 CORS 정책에 의해 요청이 거부당할 것이다. 이를 해결하려면 백 엔드 서버 쪽에서 CORS를 허용하기 위한 별도의 설정을 해줘야 한다. 다음으로, 서버는 기본적으로 다른 오리진으로부터 온 요청에 대해서는 쿠키를 설정 및 응답해주지 않는다는 문제이다. 즉 백 엔드 서버에게 API 요청을 보내더라도 쿠키가 설정되지 않기 때문에 로그인 등의 기능을 구현하는 것이 어려워진다. 이를 해결하려면 백 엔드 서버에게 API 요청을 보낼 때 JavaScript 단에서 특정 설정(XMLHttpRequest.withCredentials 옵션을 true로 설정하거나, fetch API라면 credentials 옵션을 include로 설정)을 해줘야 하며, 백 엔드 서버 쪽에도 응답의 헤더에서 Access-Control-Allow-Credentials 옵션을 true로 설정해줘야 한다.

출처: https://it-eldorado.tistory.com/85

[React] 프론트 엔드와 백 엔드 분리 시 동작 원리 (vs 풀 스택)

 

2. 정적 웹사이트 배포 

2-1. SURGE

정적 웹사이트 및 애플리케이션을 배포하고 호스팅하기 위한 서비스. 이를 사용하여 개츠비, 지킬, js, html, css로 빌드된 프로젝트를 호스팅할 수 있다. 무료 서비스이지만 프리미엄 버전을 통해 무제한 전문 프로젝트 생성, 사용자 지정 SSL, https 보안 웹사이트를 만들 수 있으며 리소스 공유, 사이트 내 리디렉션, 암호 보호 등의 기능도 사용 가능하다. 

2-2. Github Pages 

Surge와 유사한 또 다른 인기있는 대체 정적 호스팅 서비스는 Github 페이지. 이 무료 서비스를 통해 사용자는 개인 정적 사이트 프로젝트를 Github 저장소에 호스팅 할 수 있다. Github Pages는 가장 높은 순위의 정적 호스팅 서비스 중 하나로서 모든 수준의 웹 개발자들 사이에서 매우 잘 알려진 명성을 자랑한다. 두 가지 유형의 페이지를 만들 수 있는데, 여기엔 github.io 도메인에서 만들 수있는 "프로젝트 페이지 또는 사용자 및 조직 페이지"가 포함된다. 물론 사용자 지정 도메인도 자유롭게 사용할 수 있다. Github는 상업적 목적을 달성하기위한 프로젝트는 호스팅 서비스를 사용하여 게시하지 말 것을 명시 적으로 권장한다. 따라서 대규모 웹 사이트를 수용 할 수는 없지만 Github 페이지는 비상업적 또는 개인적인 용도로 적합하다.

Github Pages는 의심 할 여지없이 강력한 도구이지만 Surge는 Github Pages에도없는 몇 가지 이점을 제공한다. 이러한 이점 중 하나는 클라이언트 측 라우팅이다. Surge 프로젝트 내에서 존재하지 않는 경로를 요청하는 경우 클라이언트를 "백업"HTML 파일 (200.html)로 리디렉션 할 수 있다. 

Surge의 또 다른 주목할만한 이점은 사용자가 몇 초 만에 사이트에 새로운 변경 사항을 배포 할 수 있다는 것이다. 위에서 언급했듯이 단순히 명령 줄에 서지 명령을 입력하면 변경 사항을 온라인에서 즉시 볼 수 있다. 테스트 실험 중에 특히 유용하며 사용자 웹 사이트에 대한 간단한 편집이 관리하기 더 쉽습니다. 웹 페이지를 즉시 새로 고치는 옵션으로 인해 웹 브라우저의 변경 사항이 더 눈에 띄게 나타난다. 또는 Github Page 사용자는 온라인 인터페이스에 대한 변경 사항을 계속 푸시하고 커밋하며 더 길고 지루한 프로세스로 어려움을 겪는다.

출처: https://sunlightmedia.org/ko/%EC%A0%95%EC%A0%81-%EC%82%AC%EC%9D%B4%ED%8A%B8-%EB%B0%B0%ED%8F%AC%EC%97%90-%EC%84%9C%EC%A7%80%EB%A5%BC-%EC%82%AC%EC%9A%A9/

Surge를 사용하여 정적 사이트 배포 (2020 업데이트)

2-3. Netlify

Netlity는 GitHub, GitLab 등과 계정 연동 및 쉬운 호스팅을 제공하며, CDN, Continuous Deployment(지속적 배포), One-Click HTTPS 제공 등 고성능 사이트 / 웹 응용 프로그램을 제작하는데 필요한 쉽고 빠른 다양한 서비스들을 제공한다.

배포 방법: https://heropy.blog/2018/01/10/netlify/

GitHub와 Netlify를 이용한 쉽고 빠른 HTTPS 무료 호스팅

2-4. AWS Amplify

AWS Amplify는 전세계 수백 개의 상호 접속 위치(POP)가 포함된 Amazon의 안정적인 콘텐츠 전송 네트워크와 애플리케이션 릴리스 주기를 가속화하는 기본 제공 CI/CD 워크플로를 통해 정적 웹 애플리케이션의 글로벌 배포 및 호스팅을 지원하는 완전관리형 서비스다. 단순히 Amplify 콘솔에서 애플리케이션의 코드 리포지토리를 연결하기만 하면 코드를 커밋할 때마다 프런트엔드와 백엔드의 변경 사항이 단일 워크플로로 배포된다.

출처: https://aws.amazon.com/ko/amplify/hosting/

AWS Amplify - 정적 웹 호스팅 - Amazon Web Services

Q: Amplify 라이브러리, CLI 및 관리 UI를 사용하여 무엇을 할 수 있습니까?

Amplify 라이브러리를 사용하면 코드 몇 줄만 작성하고도 오프라인 데이터, 멀티 팩터 인증, 분석 등의 기능을 애플리케이션에 빠르게 추가할 수 있습니다. 직관적인 안내 워크플로를 사용하여 AWS AppSync, Amazon Cognito, Amazon Pinpoint, AWS Lambda, Amazon S3, Amazon Lex 같은 기본 클라우드 서비스를 Amplify CLI 또는 관리 UI에서 직접 구성 및 통합할 수 있으므로 백엔드 서비스를 설정하고 관리하는 데 필요한 시간을 최소화할 수 있습니다.

Q: Amplify 라이브러리는 어떤 언어와 플랫폼을 지원합니까?

Amplify 라이브러리는 iOS, Android, Web, Flutter, React Native 앱을 지원합니다. Web 앱의 경우 React, Ionic, Angular 및 Vue.js와 긴밀히 통합됩니다.

Q: CLI를 사용하지 않더라도 Amplify 라이브러리를 사용할 수 있습니까?

예. Amplify CLI 없이 생성한 백엔드 리소스에 액세스하는 데 라이브러리를 사용할 수 있습니다.

Q: Amplify 관리 UI란 무엇입니까?

Amplify 관리 UI는 AWS 콘솔 외부에서 앱 백엔드를 구성하고 유지 관리하기 위한 시각적 인터페이스입니다. 앱을 시작하면, 관리 UI를 통해 개발자와 비개발자가 앱 콘텐츠와 사용자를 관리할 수도 있습니다.

Q: Amplify 콘솔은 무엇이며 관리 UI와 어떻게 다릅니까?

Amplify 콘솔은 AWS 관리 콘솔 내의 앱 제어 센터입니다. AWS Amplify 콘솔은 앱의 모든 프런트엔드 환경과 백엔드 환경을 표시하는 반면, 관리 UI에는 각 개별 백엔드 환경에 연결된 고유한 인스턴스가 있습니다.

Q: AWS Amplify 정적 웹 호스팅을 시작하려면 어떻게 해야 합니까?

시작하려면 AWS 콘솔에서 AWS Amplify로 이동하여 소스 리포지토리에 연결합니다. AWS Amplify는 사용된 프런트엔드 프레임워크를 자동으로 파악한 다음, 앱을 빌드하고 전 세계에서 사용 가능한 콘텐츠 전송 네트워크(CDN)에 배포합니다. Amplify는 Amplify CLI 또는 관리 UI를 사용하여 추가된 백엔드 기능을 감지하고, 프런트엔드와 동일한 배포에서 필요한 AWS 리소스를 배포할 수 있습니다. AWS Amplify는 웹 앱을 신속하게 빌드 및 배포하고 편리한 URL(예: https://master.appname.amplifyapp.com)로 전 세계에서 사용 가능한 콘텐츠 전송 네트워크(CDN)에 웹 앱을 호스팅합니다. 시작하려면 AWS 콘솔에서 AWS Amplify로 이동하세요.

출처: https://aws.amazon.com/ko/amplify/faqs/

AWS Amplify FAQs | 프런트 엔드 웹 및 모바일 | Amazon Web Services

세팅 과정: https://aws.amazon.com/ko/getting-started/hands-on/deploy-react-app-cicd-amplify/

CI/CD로 AWS에 React 앱 배포

Amplify flutter: https://aws.amazon.com/ko/blogs/korea/amplify-flutter-is-now-generally-available-build-beautiful-cross-platform-apps/

AWS Amplify Flutter 정식 출시 – 멀티 플랫폼 앱 개발 도구 | Amazon Web Services

2-5. Vercel

Vercel은 Next.js 개발 팀에서 만든 호스팅 사이트다. Vercel은 사용자의 Work flow에 완벽하게 맞는 정적 사이트 및 서버리스 기능을 위한 클라우트 플랫폼이다. 개발자들은 Configuration, Supervision 없이 즉시 배포할 수 있고 자동으로 확장하며 웹 사이트 및 웹 서비스를 호스팅할 수 있다.

Github, GitLab, Bitbucket 저장소와 연결하여 매번 push를 진행할 때 마다 배포할 수 있습니다.

2-6. AWS S3

3. 백엔드 호스팅

3-1. Heroku and AWS EC2

heroku 서비스는 플랫폼으로서의 서비스(Paas)이고, EC2는 인프라로서의 서비스(Iaas)에 속한다. 오늘날의 기업은 더 많은 워크로드를 클라우드에 마이그레이션하면서 IaaS와 PaaS 솔루션의 이점을 비교한다. IaaS(Infrastructure as a Service) 솔루션은 클라우드 인프라스트럭처에 더욱 뛰어난 유연성과 제어력을 제공하지만 관리 및 최적화하기에는 더 복잡하다. PaaS(Platform as a Service) 솔루션은 구축을 촉진하는 데 필요한 툴과 인프라스트럭처를 제공하지만 보안, 통합 및 공급업체 종속 문제가 있다. 여기서 인프라는 곧 서버를 뜻한다. EC2는 서버를 제공해주고 설정은 사용자가 알아서 해야된다. 

여기서 고려해야 할 요소가 3가지가 있다. 첫째 가격, 둘째 시간, 셋째 컨트롤. EC2는 컨트롤 범위가 넓은 대신 설정이 귀찮다. 헤로쿠는 그 반대. 당연히 헤로쿠는 시간이 적게 들고 EC2는 그 반대. 헤로쿠는 AWS 위에서 작동하므로 절대 EC2보다 헤로쿠가 쌀 수는 없다. 

헤로쿠 배포 방법: https://donghunee.github.io/study/2019/11/15/heroku/

[Heroku]express서버 Heroku에 배포하기

 

3-2. AWS EB(Elastic Beanstalk)

Pass로서 헤로쿠의 직접적 경쟁상대. 그러나 헤로쿠가 더 빠르고 사용하기 쉽다고 함. 그러나 가격은 AWS EB가 조금 더 저렴하다.  

3-3. 구글 클라우드: https://cloud.google.com/solutions/web-hosting?hl=ko 

웹 호스팅 | Google Cloud

글로벌 CDN에 정적 웹사이트 배포 가능. 동적 웹사이트 또한 Iaas, Paas 모두 지원. 

3-4. azure

3-5. Hostinger

영국의 호스팅 회사이다. 호스팅어 그룹 소속이며, 이 그룹은 호스팅어 이외에도 유호스팅[1]이나 000webhost 등의 계열사가 있다. 전세계 여러 나라에 진출해 있으며, 한국에도 진출해 있다. 

링크: https://www.hostinger.kr/?ppc_campaign=google_search_brand&bidkw=%EC%9B%B9%20%ED%98%B8%EC%8A%A4%ED%8C%85&gclid=CjwKCAjwmK6IBhBqEiwAocMc8hyfZApOOyt9TK523Z_wXNK3sUVGjr65hFbrWAWwtpTbqOFzKgnM_hoC9ScQAvD_BwE 

당신을 위한 호스팅 플랫폼, 호스팅어와 온라인으로 진출하세요