[Backend] 배포란 무엇인가?

배포가 왜 중요할까?

 요리를 다 만들었는데, 손님 테이블에서 내놓지 않았다면?

 

개발에서 배포(Deployment)는 바로 그 마지막 단계입니다.

아무리 멋진 기능을 만들어도, 실제로 사용자들이 쓸 수 있는 환경에 올려야 진짜 서비스가 됩니다.

이 과정이 바로 배포입니다.

단순히 코드를 서버에 옮기는 것을 넘어 안정적으로, 반복 가능하게, 자동으로 이루어지도록 만드는 것이 핵심이죠.

 

---

 

 

배포의 기본 개념

 

개발 프로세스를 간단히 나누면 이렇게 됩니다.

개발 (Development) → 빌드 (Build) → 배포 (Deployment)

 

조금 자세히 설명하자면,

 

• 개발: 로컬 환경(내 PC)에서 코드 작성
• 빌드: 코드를 실행 가능한 형태(JAR, WAR, Executable 등)로 변환
• 배포: 빌드 결과물을 서버에 올리고, 사용자들이 접근할 수 있게 만드는 과정

또한 여기서 포인트는

로컬에서 실행된다고 배포 완료가 아닙니다.

전 세계, 또는 특정 네트워크에서 접근이 가능해야 진짜 배포라고 할 수 있습니다.

 

 

---

 

 

배포 방식의 종류

 

배포 방식에는 여러 종류가 존재합니다.

가장 큰 갈래는 수동/자동이라고 개인적으로 생각합니다.

저 또한 수동에 대해선 이해도가 낮기에 자동을 좀 더 자세히 작성하겠습니다.

자동에는 너무나 많은 방식이 있기에 가장 대표적이라고 소문난 방식들을 설명하겠습니다.

(1) 수동 배포

• FTP/SCP 등을 이용해 서버에 직접 파일을 올림
• 장점: 단순, 빠른 시작 가능
• 단점: 사람이 직접 해야 하므로 실수 가능성 높음, 자동화 어려움

(2) 자동 배포 (CI/CD)

• CI(Continuous Integration): 코드를 통합하고 자동으로 테스트/빌드
• CD(Continuous Deployment/Delivery): 빌드된 코드를 자동으로 서버에 배포
• GitHub Actions, Jenkins, GitLab CI/CD 등이 대표적
• 장점: 반복 가능한 안정적 배포, 에러 감소
• 단점: 초기에 세팅이 필요

아래 사진은 AI로 만든 사진인데 보고 이해를 도왔으면 좋겠습니다.

 

(3) 배포 전략

이 부분은 배포 입문 단계에선 중요도가 조금 떨어지지만, 입문 단계를 벗어나면 중요하게 생각하게 되는 것 같습니다.

• 롤링 배포: 일부 서버씩 순차적으로 업데이트
• 블루그린 배포: 기존 버전(Blue)과 신규 버전(Green) 서버를 동시에 준비, 전환 시점에만 바꿈
• 카나리 배포: 일부 사용자에게만 먼저 배포해 테스트

 

 

---

 

배포  과정 단계별 예시 (Spring Boot + AWS 기준)

 

 

1, 코드 작성

• 로컬 환경에서 기능 구현

2, 빌드

• build/libs 폴더에 *.jar 파일 생성

3, 서버 준비

• AWS EC2 인스턴스 생성 (Ubuntu)
• 보안 그룹에서 HTTP/HTTPS 포트 열기

4, 환경 변수 & DB 연결

• application.yml에 DB 정보, API Key 설정
• AWS RDS(MySQL) 연동

5, 배포 실행

• SSH로 서버 접속 후 JAR 실행
• 또는 Docker 컨테이너 실행

6, 웹 서버 설정

• Nginx Reverse Proxy
• HTTPS 인증서(Let’s Encrypt, Certbot)

7, 서비스 접근

• https://내도메인주소 로 접속

---

 

 

첫 배포 시 자주 겪는 문제와 해결 팁

 

 

사실 이건 지금 말하는 게 맞을지 모르겠습니다.

이 글을 읽는 사람들이 배포 유 경험자일까? 아니면 무 경험자일까를 생각했을 때, 무 경험자일 확률이 높을 것입니다.

 

그래서 실제 여러 배포 때마다 생기는 문제보단

저 또한 저만의 배포 파이프라인이 있기 때문에 그 파이프라인을 만들기 전까지의 시행착오 부분에서의 문제를 말씀드리고자 합니다.

 

배포를 언제 해야할까?

 

참 어려운 주제입니다. 첫 개발 프로젝트나 헤커톤을 들어가면 서버 담당자를 누가 할지, 배포를 어떻게 할지와 언제 할지 등 다양하고 동시에 생소한 논의 사항들을 마주할 것입니다.

 

저는 개인적으로 상황에 따라 다르다고 생각을 합니다.

기본적으로 자동 배포 파이프라인을 구축한 후에 개발을 진행하면서 꾸준히 업데이트하는 것이 맞다는 주의이지만,

2,3일 만에 해야 하는 단기 프로젝트이다? 그럼 그냥 순서 의미 없이 하기도 하고,

헤커톤에서 주최 측에서 제공하는 무료 서버가 있다면 그 라인에 맞춰도 됩니다.

또한  실력이 뛰어나서 배포 상황에 영향을 받지 않는다면, 배포를 마지막으로 미뤄도 괜찮다고 생각합니다.

 

특히 프론트엔드의 경우 배포가 그렇게 난이도 있는 작업이 아니라 배포를 마지막에 한 번에 머지에서 하는 경우가 많다고 합니다.

하지만 전 백엔드의 입장에서 말씀을 드리기 때문에, 이걸 보는 초심자라면 배포를 맨 처음에 시도하길 추천합니다.

단, 깃허브를 거의 써보지 않은 사람이라면 배포를 먼저 시도하기보단 개발 후 브런치 협업부터 잘 마무리한 후에 하시길 바랍니다.

 

어느 정도 깃허브 브런치 활용에 익숙하거나 경험이 있다면 메인에서 문제가 생기지 않지만, 그렇지 않다고 가정하면 자동 배포란 메인으로의 푸시가 계속 도커 허브를 통해 컨테이너에서 실행되는지라 서버 측에 문제가 생길 수 있습니다.

 

초보자의 가장 흔한 실수 TOP 3

음 저는 환경변수 누락, cors 오류, 포트 충돌 같습니다.

 

저도 배포를 여러 번 해봤지만 아직 모르는 부분이 많습니다.

개인적으로 저도 초중간에 걸쳐있다고 생각합니다.

그런 저에게 가장 많은 서버 오류가 난 부분이 바로 저 셋입니다.

 

환경변수를 로컬에만 넣고 로컬에서 서버 실행만 해본 후 그대로 클라우드 서버에 푸시하면....

뭐 그냥 오류가 납니다. 깃에선 문제가 없겠지만... 뭐 그렇습니다.

꼭 배포하는 과정(저의 경우에는 깃)에다가 환경변수 저장을 잊지 마세요!

 

 

cors 오류는 http://퍼블릭 IP 로 접속하다가 HTTPS를 처음 시도할 때 가장 많이 생기는데, 이 외에도 많이 생깁니다.

Spring WebConfig에서 allowedOrigins 지정을 안 해줘서 생기는 경우도 있고, 스웨거 컨피그로 따로 설정 안해줘서 생기는 경우도 있고, 상황에 따라 다양히 생기니 잘 대처하시면 좋겠습니다.

 

포트 충돌은.. 뭔가 자세히 설명하긴 양이 너무 많지만 쉽게 말해서 여러분이 로컬호스트8080 URL을 로컬에서 쓰실 때 8080과 같은 번호가 포트 번호입니다. 8080이라는 방문을 통해 8080방에 들어갈 수 있는 건데, 그 방문에 여러 명이 함께 살면 좁고 힘들겠죠? 그래서 한 포트에 여러 루트가 꼬이면 안 됩니다.

그걸 잘못하면 포트에 충돌이 생기는데, 전 이 방법을 가장 추천합니다.

프로세스의 역할을 확인하고, 꼭 그 포트를 써야 한다면

미련을 가지지 말고 프로세스를 종료하고 다른 포트에서 실행되도록 바꾸세요.