https://youtu.be/wN1hnub6gyY?si=nX9v_Bd2rqIK5MrQ

비타의 애플리케이션 배포 전략

비타의 애플리케이션 배포 전략

들어가며

애플리케이션을 개발하는 것만큼 중요한 것이 배포다. 아무리 좋은 기능을 만들었더라도 배포 과정에서 서비스가 중단되거나, 장애가 발생했을 때 빠르게 복구하지 못하면 사용자 경험은 크게 훼손된다.

특히 운영 중인 서비스에서는 배포 방식이 단순한 기술 선택이 아니라, 서비스 안정성, 사용자 신뢰, 운영 부담, 인프라 비용까지 모두 연결되는 의사결정이 된다.

배포 전략을 이야기할 때 흔히 블루-그린, 롤링, 카나리 같은 용어를 접하게 되는데, 중요한 건 “어떤 전략이 가장 좋아 보이느냐”가 아니다. 진짜 중요한 건 우리 팀의 상황에서 어떤 전략이 가장 현실적이고 적합하냐다.

이번 글에서는 대표적인 배포 전략들을 정리하고, 어떤 기준으로 선택해야 하는지, 그리고 실제 한 팀이 왜 블루-그린 전략을 선택했는지를 함께 살펴본다.

배포 전략을 선택할 때 가장 먼저 봐야 할 것

배포 전략 선택에서 가장 중요한 기준은 기술 유행이 아니라 팀의 현실적인 제약과 서비스 요구사항이다.

크게 보면 다음 세 가지를 먼저 판단해야 한다.

다운타임을 허용할 수 있는가

어떤 서비스는 1~2분 정도의 중단이 큰 문제가 되지 않을 수 있다. 하지만 어떤 서비스는 짧은 중단도 곧바로 신뢰 하락과 이탈로 이어진다.

예를 들어 트래픽이 특정 기간에 집중되는 서비스, 결제나 예약처럼 실시간성이 중요한 서비스는 다운타임 허용 범위가 매우 낮다. 이 경우 단순 배포 전략은 처음부터 후보에서 제외될 수 있다.

배포 후 검증이 반드시 필요한가

새 버전이 운영 환경에서 어떤 영향을 줄지 충분히 검증해야 하는 팀도 있다. CPU 사용률, 메모리 사용량, 예상 못한 버그, 특정 사용자 흐름에서만 발생하는 오류 등은 실제 트래픽에서만 드러나는 경우가 많다.

이런 팀이라면 단순히 “무중단 배포”만으로는 부족하고, 일부 트래픽으로 새 버전을 검증하는 실험적 배포 전략이 필요할 수 있다.

버전 호환성 비용을 감당할 수 있는가

이전 버전과 새 버전이 동시에 떠 있는 전략은 생각보다 구현 난도가 높다. 특히 데이터베이스 스키마가 바뀌거나, 새 로직이 이전 구조와 호환되지 않으면 배포 전략 자체보다 버전 혼합성을 유지하기 위한 비용이 더 커질 수 있다.

결국 배포 전략은 “다운타임 최소화”와 “테스트 가능성”과 “호환성 비용” 사이에서 균형을 잡는 문제다.

단순 배포 전략: 가장 쉽지만 위험도 큰 방식

가장 먼저 볼 수 있는 건 구조가 단순한 배포 전략이다. 설정이 단순하고 구현 부담이 적어서 초기 팀이나 작은 프로젝트에서 자주 사용된다.

In-place 전략

In-place는 말 그대로 현재 서버에 새 버전을 덮어쓰는 방식이다.

기존 서버가 요청을 받고 있는 상태에서 배포를 시작하면, 새 빌드 산출물을 서버에 올리고 서버를 다시 시작한다. 문제는 이 재시작 구간 동안 사용자는 응답을 받지 못한다는 점이다.

이 전략은 구현이 매우 단순하다는 장점이 있지만, 운영 환경에서는 다음과 같은 문제가 크다.

서버 재시작 동안 다운타임 발생
문제가 생겨도 이전 버전이 남아 있지 않음
롤백하려면 이전 버전을 다시 배포해야 함

즉, 단순하지만 실패 시 대응이 매우 불편하다.

Recreate 전략

Recreate는 기존 인스턴스를 완전히 내리고, 새 인스턴스를 띄운 뒤 새 버전을 배포하는 방식이다.

In-place와 비슷해 보이지만 차이가 있다. In-place는 기존 서버 위에 덮어쓰는 개념이라면, Recreate는 아예 기존 인스턴스를 종료하고 새로 만드는 흐름에 가깝다.

그래서 이 전략은 단순한 대신 다음 문제가 더 뚜렷하다.

인스턴스를 새로 띄우는 시간까지 포함되어 다운타임이 더 길어질 수 있음
배포 실패 시 복구가 더 느릴 수 있음
이전 버전이 살아 있지 않아 즉시 롤백이 어려움

운영 중인 서비스에서 이 전략이 위험한 이유는, 배포가 항상 성공한다는 보장이 없기 때문이다. 기존 서버는 이미 내려갔는데 새 서버가 정상 기동하지 않으면, 그 순간 서비스는 그대로 멈춘다.

단순 배포 전략의 한계

단순 배포 전략의 핵심 문제는 크게 세 가지다.

첫째, 다운타임이 발생한다. 둘째, 롤백이 어렵다. 셋째, 배포 실패 시 장애 시간이 길어질 수 있다.

작은 내부 도구나, 잠깐의 중단이 허용되는 서비스라면 괜찮을 수 있다. 하지만 사용자 경험이 중요한 서비스에는 부담이 크다.

안정적 배포 전략: 서비스 중단 없이 배포하기

운영 중인 사용자에게 배포 사실을 거의 느끼지 못하게 하고 싶다면, 안정적 배포 전략이 필요하다. 대표적으로 블루-그린과 롤링이 있다.

블루-그린 배포 전략

블루-그린은 현재 운영 중인 환경(예: 블루) 과 새 버전을 올릴 별도의 환경(예: 그린) 을 동시에 두고, 준비가 끝나면 로드밸런서의 트래픽만 전환하는 방식이다.

흐름은 단순하다.

기존 환경은 계속 사용자 요청을 받는다
새 환경에 새 버전을 배포한다
헬스 체크로 정상 동작을 확인한다
문제가 없으면 트래픽을 새 환경으로 한 번에 전환한다

이 방식의 장점은 매우 명확하다.

다운타임이 거의 없다
새 버전이 완전히 준비되기 전까지 사용자는 기존 버전을 사용한다
문제가 있으면 트래픽 전환을 되돌려 빠르게 롤백할 수 있다

즉, 블루-그린은 안전하게 갈아끼우는 전략이다. 사용자 입장에서는 배포 순간을 거의 인지하지 못한다.

물론 단점도 있다. 가장 큰 단점은 비용이다. 기존 환경과 새 환경이 동시에 떠 있어야 하므로, 순간적으로 인스턴스 비용이 두 배 가까이 들 수 있다.

롤링 배포 전략

롤링 배포는 인스턴스를 여러 개 운영하고 있을 때 유용하다. 전체 인스턴스를 한 번에 바꾸는 것이 아니라, 그룹 단위로 순차적으로 새 버전으로 교체한다.

예를 들면 6대의 인스턴스가 있다면, 2대씩 묶어서 순차적으로 교체할 수 있다.

이 방식의 장점은 다음과 같다.

다운타임 없이 배포 가능
추가 인프라 비용이 상대적으로 적음
배포 중에도 일부 인스턴스는 계속 서비스 가능
문제가 생기면 중간에 멈추거나 복구 전략을 적용하기 좋음

즉, 블루-그린보다 비용 효율적인 무중단 배포 전략이라고 볼 수 있다.

다만 롤링에는 중요한 전제가 있다. 여러 인스턴스를 운영하고 있어야 효율이 좋다. 인스턴스가 1개뿐인 환경에서는 롤링의 장점이 거의 사라진다.

또 하나 중요한 점은, 롤링은 기존 버전과 새 버전이 잠시 동안 동시에 존재한다는 것이다. 이 부분이 뒤에서 말할 버전 혼합성 문제로 이어진다.

실험적 배포 전략: 배포와 동시에 검증까지 하고 싶다면

무중단 배포만으로 충분하지 않을 때도 있다. 배포 후 실제 트래픽에서 어떤 일이 벌어지는지 보고 싶을 때는 실험적 배포 전략이 필요하다.

대표적으로 카나리와 섀도우 전략이 있다.

카나리 배포 전략

카나리는 새 버전에 일부 트래픽만 먼저 보내고, 모니터링을 통해 문제가 없는지 확인한 뒤 점진적으로 비율을 늘리는 전략이다.

예를 들어 처음엔 10%만 보내고, 문제가 없으면 30%, 50%, 100%로 올릴 수 있다.

이 방식의 핵심 장점은 배포 리스크를 작은 범위에서 먼저 확인할 수 있다는 점이다.

특정 버그가 새 버전에만 있는지 확인 가능
CPU, 메모리, 에러율 같은 지표를 점진적으로 관찰 가능
대형 장애로 번지기 전에 중단 가능

다만 카나리는 단순히 배포 도구만 있다고 되는 전략이 아니다. 모니터링 체계와 해석 기준이 함께 있어야 한다. 그래서 일정 수준 이상의 운영 성숙도가 필요하다.

섀도우 배포 전략

섀도우는 실제 사용자 요청을 복제해서, 기존 버전과 새 버전에 동시에 보내고 결과를 비교하는 전략이다.

사용자는 기존 버전의 응답을 받고, 개발자는 새 버전이 같은 요청을 어떤 방식으로 처리하는지 뒤에서 관찰한다.

이 전략의 장점은 상당히 강력하다.

같은 요청을 기준으로 이전 버전과 새 버전의 성능 비교 가능
실제 운영 트래픽 기반 검증 가능
장애를 사용자에게 직접 노출하지 않고 문제를 확인할 수 있음

예를 들어 성능 개선을 했는데 실제로 CPU 사용률이 줄었는지, 혹은 특정 요청에서 새 버전만 비정상적으로 튀는지를 바로 비교할 수 있다.

하지만 섀도우에도 치명적인 단점이 있다. 바로 버전 혼합성 비용이다.

버전 혼합성 비용이 왜 중요한가

블루-그린을 제외한 롤링, 카나리, 섀도우 전략은 대부분 일정 시간 동안 이전 버전과 새 버전이 동시에 존재한다.

이때 문제가 생긴다.

예를 들어 새 버전에서 DB 컬럼을 추가하거나 삭제했다고 해보자. 그런데 이전 버전은 여전히 예전 스키마를 기준으로 동작하고 있다면?

이전 버전과 새 버전이 같은 DB를 바라보며 충돌할 수 있음
배포 중간 상태에서 특정 요청만 실패할 수 있음
호환성을 유지하기 위해 애플리케이션 로직이 복잡해질 수 있음

즉, 버전이 섞여 있어도 안전하게 동작하도록 만드는 비용이 꽤 크다. 이 문제는 배포 전략을 선택할 때 생각보다 훨씬 중요하다.

실제로 팀이 바쁠수록, 기능 개발과 운영 개선에 리소스가 부족할수록, 이 호환성 비용은 큰 부담이 된다.

결국 어떤 배포 전략이 좋은가

정답은 하나가 아니다. 배포 전략은 서비스와 팀의 상황에 따라 달라진다.

아주 단순하게 정리하면 다음처럼 볼 수 있다.

다운타임을 허용할 수 있다면

In-place나 Recreate 같은 단순 배포 전략도 현실적인 선택이 될 수 있다. 설정이 쉽고 구현 비용이 적기 때문이다.

다운타임은 허용할 수 없지만 실험적 검증까지는 필요하지 않다면

블루-그린이나 롤링 같은 안정적 배포 전략이 적합하다.

배포 후 성능과 안정성을 실제 트래픽에서 검증해야 한다면

카나리나 섀도우 같은 실험적 전략이 더 어울릴 수 있다.

다만 트래픽이 너무 적다면

실험적 전략의 효과가 떨어질 수 있다. 예를 들어 하루 트래픽이 매우 적은데 40:60 비율 실험을 해도 통계적으로 신뢰할 만한 결론을 내기 어렵다.

즉, 배포 전략은 기술의 우열이 아니라 다운타임 민감도, 트래픽 규모, 검증 필요성, 버전 호환성 비용으로 고르는 것이 맞다.

페스타북 팀이 블루-그린을 선택한 이유

영상 속 팀은 축제 기반 플랫폼 특성상 특정 기간에 사용자가 집중되는 서비스를 운영하고 있었다. 이런 서비스는 짧은 시간의 장애도 사용자 불편과 신뢰도 하락으로 직결된다.

그래서 이 팀은 먼저 명확한 기준을 세웠다.

1. 다운타임은 절대 허용하지 않는다

축제 기간 중 몇 분의 장애도 치명적일 수 있기 때문에, In-place와 Recreate 전략은 초기에 제외했다.

2. 실험적 배포 전략은 아직 시기상조라고 판단했다

아직 충분한 트래픽이 보장되지 않았고, 무엇을 검증해야 하는지조차 명확하지 않은 초기 단계에서는 카나리나 섀도우가 큰 가치를 주기 어렵다고 봤다. 그래서 실험적 전략도 제외했다.

3. 남은 후보는 블루-그린과 롤링이었다

여기서 핵심 판단 기준은 버전 혼합성 비용이었다.

롤링은 무중단 배포가 가능하고 비용도 효율적이지만, 구버전과 신버전이 동시에 공존하는 동안 호환성을 유지해야 한다. 이 팀은 당시 다른 영역에 더 많은 리소스를 써야 했고, 인프라와 모니터링, 호환성 로직까지 신경 쓰는 부담이 너무 크다고 판단했다.

그래서 최종적으로 블루-그린 전략을 선택했다.

이 선택은 꽤 현실적이다. 인프라 비용은 조금 더 들더라도, 운영 복잡성과 버전 호환성 부담을 줄이고 배포 안정성을 확보하는 쪽을 택한 것이다.

블루-그린 전략을 실제로 사용하며 얻은 이점

이 팀은 블루-그린을 운영하면서 몇 가지 분명한 장점을 체감했다고 한다.

첫 번째는 배포 실패 부담이 줄었다는 점이다.

새 버전 배포가 실패해도 사용자는 기존 버전을 계속 사용하고 있기 때문에, 배포 실패가 곧바로 사용자 장애로 이어지지 않는다. 이건 팀 입장에서 심리적 안정감도 크다. “실패하면 큰일 난다”가 아니라 “성공하면 전환하면 된다”는 구조가 되기 때문이다.

두 번째는 빠른 롤백이 가능했다는 점이다.

실제 배포 중 헬스 체크가 오래 걸리는 문제를 발견했고, 확인 결과 서버는 올라왔지만 특정 오류 때문에 지연되고 있었다고 한다. 이때 즉시 배포를 중단하고 롤백을 진행했으며, 사용자는 계속 이전 최신 버전을 이용할 수 있었다.

이 경험은 결국 하나를 보여준다.

좋은 배포 전략은 “성공적으로 배포하는 전략”이 아니라 “실패해도 사용자를 지키는 전략”이다.

마무리

애플리케이션 배포 전략은 단순히 기술 블로그에서 본 멋진 패턴을 따라 선택하는 것이 아니다. 서비스 특성, 운영 여건, 팀 역량, 인프라 비용, 장애 허용 범위를 모두 고려해서 정해야 한다.

정리하면 다음과 같다.

다운타임 허용 가능 여부를 먼저 판단한다
새 버전을 실제 트래픽으로 검증할 필요가 있는지 본다
구버전과 신버전이 동시에 존재할 때의 호환성 비용을 고려한다
팀이 감당할 수 있는 복잡도 안에서 전략을 선택한다

그리고 이 사례가 보여주듯, 팀마다 최적의 답은 다를 수 있다.

어떤 팀은 카나리가 맞고, 어떤 팀은 롤링이 맞고, 어떤 팀은 블루-그린이 가장 현실적일 수 있다.

중요한 건 “정답 같은 전략”을 찾는 것이 아니라, 우리 팀이 지금 가장 안전하고 지속 가능하게 운영할 수 있는 전략을 고르는 것이다.

우아한테크코스 테코톡