배포/운영 프로세스 — 스테이징/프로덕션/롤백

소프트웨어 배포에는 여러 단계의 환경이 있습니다. 비개발자도 이해할 수 있게 설명합니다.

로컬 (Local) — 개발자의 컴퓨터

개발자가 코드를 작성하고 테스트하는 환경입니다. 외부에서 접근할 수 없습니다.

개발 서버 (Development) — 개발팀 공용

여러 개발자가 작업한 코드를 합쳐서 테스트하는 환경입니다. 불안정할 수 있습니다.

스테이징 (Staging) — 테스트 환경

프로덕션과 동일한 설정으로 최종 테스트하는 환경입니다. 발주사가 검수하는 곳이 여기입니다. 실제 데이터가 아닌 테스트 데이터를 사용합니다.

프로덕션 (Production) — 실제 운영 환경

실제 사용자가 접속하는 환경입니다. 가장 안정적이어야 하며, 직접 코드를 수정하면 안 됩니다.

최소 구성: 스테이징 + 프로덕션 2개는 반드시 필요합니다. "프로덕션에 바로 배포"는 매우 위험합니다.

STEP 1: 코드 리뷰 (Code Review)

다른 개발자가 코드를 검토합니다. 버그, 보안 취약점, 코드 품질을 사전에 점검합니다.

STEP 2: 자동 테스트 (CI)

코드가 합쳐질 때 자동으로 테스트가 실행됩니다. 테스트를 통과하지 못하면 배포가 차단됩니다.

STEP 3: 스테이징 배포

스테이징 환경에 먼저 배포하여 발주사와 함께 확인합니다.

STEP 4: 승인 (Go/No-Go)

스테이징에서 문제가 없으면 프로덕션 배포를 승인합니다.

STEP 5: 프로덕션 배포

프로덕션 환경에 배포합니다. 가능하면 사용자가 적은 시간대에 배포하세요.

STEP 6: 모니터링 (배포 후 30분~1시간)

배포 직후 에러 발생률, 응답 시간 등을 모니터링합니다. 이상이 감지되면 즉시 롤백합니다.

롤백이란? 배포한 새 버전에 문제가 있을 때, 이전 정상 버전으로 되돌리는 것입니다.

롤백이 필요한 상황:

배포 후 서비스가 다운됨

핵심 기능(결제, 로그인)이 동작하지 않음

심각한 데이터 오류 발생

성능이 급격히 저하됨

롤백 전략:

핵심: DB 구조 변경이 포함된 배포는 롤백이 매우 어렵습니다. 이런 배포는 특히 신중하게 테스트하고, 백업을 반드시 확보한 후 진행하세요.

발주사가 확인할 것: "문제가 생기면 이전 버전으로 얼마나 빨리 돌아갈 수 있나요?"를 개발사에 꼭 물어보세요.

CI/CD란? 코드 변경 → 테스트 → 배포를 자동화하는 시스템입니다.

CI (Continuous Integration)

코드가 합쳐질 때 자동으로 빌드·테스트를 실행합니다.

CD (Continuous Deployment/Delivery)

테스트를 통과한 코드를 자동으로 스테이징/프로덕션에 배포합니다.

CI/CD의 장점:

배포 시간: 수동 1시간 → 자동 5분

인적 실수 방지 (수동 작업 제거)

배포 빈도 증가 (주 1회 → 일 수회)

문제 조기 발견 (자동 테스트)

CI/CD 도구:

MVP 단계에서는 GitHub Actions + Vercel 조합이 무료이면서 충분합니다. 규모가 커지면 AWS 기반으로 전환하세요.