[Deployment] React App을 배포하기 전에

아니 배포가 이렇게 쉬운거였나?

 

오늘은 스트레스 받던걸 해결했다. 사실 해결한 내용 진짜 많은데 하나하나 쓰려니 Back단 내용도 많아서 이론적으로 설명이 어렵길래 걍 냅뒀는데 오늘은 하면서도 좀 재밌었기 때문에 들고와봤다. 

 

이직을 하고 와서보니 회사에서 기존에 운영하고 있던 시스템과 내가 주로 개발하고 있는 시스템 간의 기술 괴리가 커서 도움을 구하거나 할 수 있는 곳이 없다. 그러다보니 개발도 내가 하고, 당연히 전반적인 인프라 영역은 다른 분들이 해주시지만 데브옵스 영역도 내가 하고 이렇게 되어버렸는데 해보고나니 어려움은 그냥 배포라는 이름에서 오는 두려움 뿐이라 그냥 간단하게 개념적인 이해를 돕고자 작성해본다. 

 

1. 배포에 필요한 개념들

기본적으로 배포가 왜 어렵게 느껴지냐면 어플리케이션을 구성하는 모든 것에 대한 이해가 필요하기 때문이다. 일단 배포라는 프로세스 자체가 엔드 유저들에게 내가 만든 프로그램을 전달하고자 할 때 하는 과정인건데 이 과정 안에 빌드도 해야하고, 도커로 이미지도 말아야하고,  뭐 웹서버 혹은 WAS 세팅도 해줘야하는 식으로 해줘야할게 너무너무 많다는 것 + 생각보다 이해해야하는 개념들이 많다는 것, 이 두 가지가 배포를 어려운 것으로 만들어버린다. 특히 배포 하면 AWS 를 떠올리게 될만큼 클라우드 컴퓨팅이 당연시 된 세상이다보니 뭐 AWS를 공부해야하나? 라고 생각하는데 아마존은 클라우트 컴퓨팅 서비스를 제공하는 회사고, 이걸 사용할 수 있도록 만들어놓은 도구가 AWS 세계관이기 때문에 걍 클라우드에 배포하려면 써야하는 툴 이런 개념이니 기본 개념이나 우선적으로 잘 다지도록 하자. 기업에서 일하다보면 클라우드 아니고 온프레미스 환경에서 배포해야할 일도 상당히 많다.

 

1) 빌드, 패키징, 번들링(build, packaging, bundling)

뭐 따지고 보면 셋다 같은 말이다. 빌드라는건 내가 개발한 어플리케이션을 예쁘게 포장하는 과정이다. 클릭 딸깍 하면 실행할 수 있는 상태로 만들어주는 모든게 준비가 완료된 상태로 만드는 과정이라는 뜻이다. 근데 그걸 하는데 필요한 도구가 있다. 필요한 의존성을 받아오고, 걔네를 포함해서 포장까지 해주는 도구들이 있는데 그 도구들이 기능이 상당히 많아서 그것들도 알아야한다는 거임. 그 도구가 뭐냐면 빌드툴이다. 백엔드라면 gradle, maven 이런애들이고, 프론트엔드라면 webpack, vite 이런 애들임. 얘네를 세팅을 어떻게 하냐에 따라서 빌드 결과물 모양새가 다르고 그렇기 때문에 사용법에 대한 숙지만 하고 있다면 일단 빌드 레벨에선 두려울게 없어진다.

그리고 전통적인 배포방식에선 이렇게 빌드하고 냅다 그냥 배포용 컴퓨터에 들고가서 빌드 결과물을 실행시켜주거나 요청했을때 그걸 리턴해주도록 세팅해주기만 하면 되는거였기때문에 빌드 결과물만 나온다면 일단 배포는 할 수 있게 된다. 

 

2) 이미지 빌드(Image Build)

모던한 배포방식, 클라우드 배포방식을 하게 되면서 사용하지 않고선 손해가 되어버리는게 도커, 컨테이너 개념인데 얘는 한대의 컴퓨터로 여러가지 어플리케이션을 배포하려고 하다보니 사용하게 되는 애다. 뭐 조금 더 세부적인 설명은 이전 글에 있음. 어쨌든 이 이미지라는게 내 어플리케이션과 환경세팅을 모두 합쳐서 컨테이너를 띄울 수 있게 만들어둔 패키지? 라고 해야할까? 그런거기 때문에  뭐 굳이 내가 컨테이너로 띄우지 않아도 될 것 같다. 이런 상태라면 굳이굳이 이미지 빌드는 하지 않아도 문제는 없다. 하지만 이미지를 빌드하는 것을 통해 얻을 수 있는 혜택이 많다보니 기왕이면 써보는게 좋다는 생각이다. 

2023.08.02 - [Dev/Deployment] - [Docker] Docker

[Docker] Docker

 

 

3) 웹 서버 / 웹 어플리케이션 서버

실질적으로 배포할 때 없어서는 안되는 요소 두 가지다. 정적 리소스만 배포하는 경우엔 (ex. SPA, 정적 웹페이지 등) 웹서버를 사용하게 되고, DB를 사용하며 동적인 프로세스를 이뤄내는 경우엔 (ex. API 서버, SSR을 사용하는 Next 등) 웹어플리케이션 서버를 사용해야한다. 웹서버의 대표적인 예시에는 Nginx, 아파치 같은게 있고 웹 어플리케이션 서버는 학원에서도 사용하는 톰캣이 대표적이다. 얘네가 하는 일은 말 그대로 요청이 오는걸 기다리고 있다가 요청이 오면 요청에 따라서 필요로 하는 자원들을 제공하는 것인데, 이런 기본적인 역할 말고도 얘네가 로드밸런싱, 프록시 등의 역할을 해주기 때문에 최근 어플리케이션 개발에서는 거의 사용하지 않을 수가 없다. 요즘 프론트 프로젝트 같은 경우는 Nginx 가 담긴 Docker 이미지가 있기 때문에 이 Nginx이미지 위에 내가 개발한 APP을 통합해서 컨테이너를 실행하는 방식으로 한 서버 PC위에 다수의 App들을 배포하는 방식으로 경제성을 갖춘다.

 

2. 배포 파이프 라인?

최근 배포얘기를 하면 빼놓을 수 없는게 파이프라인을 만든다는 얘기가 있는데, 어렵게 생각할게 전혀 없다. 그냥 내가 로컬에서 빌드하고 이미지 말고, 포트지정해서 앱 실행시키는거마냥 원격에 있는 애도 그렇게 할 수 있게끔 미리 그 흐름에 맞춰서 스크립트를 작성해둔다고 보면 되겠다. 또 고급스럽게 하는 말로 CI / CD라는 말이 있는데, 이거도 별게 없다. 개발한 내용을 지속적으로 통합(이미 개발되어있던 어플리케이션에 새로이 개발하는 것들을 합쳐주기) 지속적으로 배포(통합한 내용을 배포) 한다는 뜻이다. 이런 것들을 해주는 도구가 있는데 대표적인게 Jenkins, GitLab-CI 같은 애들이 그런 애들이다. 얘네가 위에서 말한 미리 스크립트를 작성해서 적힌대로 일을 대신해주는 애들임.

거의 단계를 미리 정해놓고, 이 단계별로 순차적으로 실행시켜야하는 명령어들을 적어둔 다음에 GitHub, GitLab, AWS CodeCommit 등의 Master Branch에  Merge / Push를 하면 이걸 트리거로 미리 정해둔 단계를 알아서 실행하는 거임.

 

3. 마치면서

'배포는 어렵다.' 처음 개발을 시작했을 땐 이런 생각을 상당히 많이 했었는데, 생각보다 그렇진 않았다. 오히려 배경지식만 잘 갖춰져있다면 더 간단하고 이해가 쉬운 내용이 배포라고 생각된다. 개발은 모를 때 가장 어렵다. 그러니 모르지 않도록 꾸준히 모르는 내용을 찾아보자..