TIL - 20260706

juni·2026년 7월 6일

목록 보기

395/468

0706 백엔드 실무 심화 (13/N): 무중단 배포, 롤백과 릴리즈 관리

✅ 1. 배포란 무엇인가?

배포(Deployment)는 로컬이나 개발 환경에서 만든 코드를 실제 사용자가 접근하는 서버에 반영하는 작업입니다.
백엔드 실무에서는 단순히 git pull 하고 서버를 재시작하는 것만이 배포가 아닙니다.
환경변수, DB migration, 빌드, 프로세스 재시작, health check, 로그 확인, 롤백 가능성까지 함께 봐야 합니다.

코드 작성
  ↓
테스트
  ↓
빌드
  ↓
서버 반영
  ↓
DB migration
  ↓
프로세스 재시작
  ↓
헬스체크
  ↓
로그 확인

➕ 1-1. 배포가 위험한 이유

로컬에서는 정상인데 운영 환경에서는 환경변수가 빠질 수 있습니다.
DB 스키마 변경이 기존 데이터와 충돌할 수 있습니다.
새 코드가 기존 프론트엔드와 API 응답 구조가 맞지 않을 수 있습니다.
서버 재시작 중 잠깐 서비스가 끊길 수 있습니다.
외부 API, Queue, Batch, Webhook 처리 흐름이 배포 중 꼬일 수 있습니다.

나쁜 배포:
코드 반영
  ↓
서버 재시작
  ↓
에러 발생
  ↓
사용자 장애
  ↓
롤백 방법 없음

배포는 기능 개발의 끝이 아니라, 운영 서비스에 영향을 주는 중요한 작업입니다.

✅ 2. 릴리즈란 무엇인가?

릴리즈(Release)는 특정 변경사항 묶음을 사용자에게 공개하는 단위입니다.
배포는 서버에 코드를 올리는 행위이고, 릴리즈는 어떤 기능과 변경사항을 공개했는지 관리하는 개념입니다.

배포:
서버에 코드 반영

릴리즈:
이번 변경사항 묶음 관리

➕ 2-1. 릴리즈에 포함하면 좋은 정보

릴리즈 날짜
배포한 커밋/태그
변경된 기능
수정된 버그
DB migration 여부
환경변수 추가 여부
영향받는 화면/API
배포 전 체크 결과
배포 후 확인 결과
롤백 방법

## Release 2026-07-06

### 변경 사항
- 상담 신청 상태 변경 이력 추가
- 관리자 엑셀 다운로드 이력 저장
- 알림톡 실패 재처리 Queue 추가

### DB 변경
- ConsultStatusHistory 테이블 추가
- ExportLog 테이블 추가

### 환경변수
- KAKAO_API_BASE_URL 추가
- KAKAO_API_KEY 추가

### 배포 후 확인
- /health 정상
- 관리자 상담 목록 정상
- 알림톡 발송 Queue 정상

릴리즈 기록은 나중에 장애 원인을 찾을 때 큰 도움이 됩니다.

✅ 3. 중단 배포와 무중단 배포

➕ 3-1. 중단 배포

서버를 멈추고 새 코드를 반영한 뒤 다시 실행하는 방식입니다.

서버 중지
  ↓
새 코드 반영
  ↓
빌드
  ↓
서버 재시작

구조는 단순하지만 배포 중 사용자 요청이 실패할 수 있습니다.
트래픽이 적은 작은 서비스에서는 초기에는 이 방식으로 시작할 수 있습니다.
다만 고객 신청, 결제, Webhook 같은 요청이 있는 서비스에서는 점점 위험해집니다.

➕ 3-2. 무중단 배포

무중단 배포(Zero-downtime Deployment)는 배포 중에도 사용자가 서비스를 계속 사용할 수 있도록 하는 방식입니다.
서버 프로세스를 끊지 않거나, 새 버전이 준비된 뒤 트래픽을 전환합니다.

기존 버전 운영 중
  ↓
새 버전 준비
  ↓
새 버전 health check
  ↓
트래픽 전환
  ↓
기존 버전 종료

무중단 배포는 운영 안정성을 높여줍니다.
단, DB migration과 상태 호환성을 잘못 설계하면 무중단 배포를 해도 장애가 날 수 있습니다.

✅ 4. PM2 reload

Node.js/NestJS 서비스를 PM2로 운영한다면 pm2 restart보다 pm2 reload를 고려할 수 있습니다.
reload는 클러스터 모드에서 프로세스를 순차적으로 교체해 중단을 줄이는 방식입니다.

➕ 4-1. restart와 reload 차이

명령어	설명
`pm2 restart`	기존 프로세스를 종료하고 다시 시작
`pm2 reload`	가능한 경우 순차 교체로 중단 최소화
`pm2 gracefulReload`	연결 처리 후 더 부드럽게 교체 시도

pm2 reload api

➕ 4-2. PM2 ecosystem 예시

module.exports = {
  apps: [
    {
      name: 'togethermall-api',
      script: 'dist/main.js',
      instances: 2,
      exec_mode: 'cluster',
      env: {
        NODE_ENV: 'production',
      },
    },
  ],
};

instances를 2개 이상 두고 cluster 모드를 사용하면 reload 시 중단을 줄일 수 있습니다.
서버 자원이 부족한 환경에서는 무리해서 인스턴스를 늘리면 오히려 메모리 압박이 생길 수 있습니다.

✅ 5. Health Check

Health Check는 서버가 정상적으로 실행 중인지 확인하는 API입니다.
배포 후 새 버전이 정상인지 확인할 때 필수입니다.

➕ 5-1. 기본 health API 예시

GET /health

➕ 5-2. 응답 예시

{
  "status": "ok",
  "timestamp": "2026-07-06T10:00:00.000Z"
}

➕ 5-3. DB 연결까지 확인하는 health check

@Get('health')
async healthCheck() {
  await this.prisma.$queryRaw`SELECT 1`;

  return {
    status: 'ok',
    database: 'ok',
    timestamp: new Date().toISOString(),
  };
}

단순 서버 실행 여부만 볼 수도 있고, DB 연결까지 확인할 수도 있습니다.
다만 health check가 너무 무거우면 오히려 부담이 됩니다.
기본 health와 deep health를 분리하는 것도 좋습니다.

/health:
서버 프로세스 정상 여부

/health/deep:
DB, Redis, 외부 의존성 일부 확인

✅ 6. Blue-Green 배포

Blue-Green 배포는 기존 운영 환경과 새 운영 환경을 동시에 준비하고, 트래픽을 새 환경으로 전환하는 방식입니다.

Blue:
현재 운영 중인 버전

Green:
새로 배포한 버전

Green 검증 완료
  ↓
트래픽을 Green으로 전환
  ↓
문제 없으면 Blue 종료

➕ 6-1. 장점

새 버전을 충분히 검증한 뒤 전환할 수 있습니다.
문제가 생기면 기존 Blue로 빠르게 되돌릴 수 있습니다.
대규모 서비스에서 안정적인 배포 방식입니다.

➕ 6-2. 단점

서버가 2세트 필요해 비용이 증가합니다.
DB migration 호환성을 더 신중히 봐야 합니다.
작은 서비스에서는 초기에 과할 수 있습니다.

➕ 6-3. 1인 개발자 기준

초기:
PM2 reload + health check + 수동 롤백

성장 후:
Blue-Green 또는 Docker 기반 배포 검토

지금 단계에서는 Blue-Green 개념을 이해하고, 실제로는 PM2 reload와 롤백 체계를 먼저 갖추는 것이 현실적입니다.

✅ 7. Rolling 배포

Rolling 배포는 여러 서버나 여러 인스턴스를 순차적으로 새 버전으로 교체하는 방식입니다.

서버 A 구버전 운영
서버 B 구버전 운영

서버 A 새 버전 배포
  ↓
정상 확인
  ↓
서버 B 새 버전 배포

한 번에 전체 서버를 바꾸지 않기 때문에 장애 위험을 줄일 수 있습니다.
여러 서버를 운영하는 구조에서 적합합니다.
단일 EC2 + PM2 구조에서는 PM2 reload가 비슷한 역할을 일부 해줄 수 있습니다.

✅ 8. Canary 배포

Canary 배포는 일부 사용자에게만 새 버전을 먼저 적용한 뒤, 문제가 없으면 점진적으로 확대하는 방식입니다.

전체 트래픽 중 5%만 새 버전으로 전달
  ↓
에러율 확인
  ↓
문제 없으면 50%
  ↓
최종 100%

대규모 서비스나 위험한 변경에서 유용합니다.
인프라 구성이 복잡해질 수 있어 작은 서비스에서는 초기에 필수는 아닙니다.
하지만 기능 플래그와 함께 사용하면 특정 기능만 제한적으로 공개할 수 있습니다.

✅ 9. 기능 플래그

기능 플래그(Feature Flag)는 코드는 배포했지만 특정 기능을 설정값으로 켜고 끌 수 있게 만드는 방식입니다.
배포와 공개를 분리할 수 있습니다.

코드는 운영 서버에 배포
  ↓
기능 플래그 OFF
  ↓
관리자 또는 특정 사용자에게만 테스트
  ↓
문제 없으면 ON

➕ 9-1. 사용 예시

사전예약 신청 버튼 오픈 여부
새로운 상담 신청 모달 사용 여부
신규 알림톡 템플릿 적용 여부
특정 관리자에게만 새 기능 노출
3사 프로젝트 일부 메뉴 비공개 운영
새로운 엑셀 Export 방식 전환

➕ 9-2. Prisma 설정 예시

model FeatureFlag {
  id          Int      @id @default(autoincrement())
  key         String   @unique
  isEnabled   Boolean  @default(false)
  description String?
  updatedAt   DateTime @updatedAt
}

➕ 9-3. 실무 기준

위험한 기능:
배포 후 바로 전체 공개하지 말고 플래그로 제어

이벤트/사전예약:
오픈 시간과 종료 시간을 설정값으로 관리

관리자 신규 기능:
특정 역할 또는 특정 관리자에게만 먼저 공개

기능 플래그는 작은 회사에서도 매우 유용합니다.
특히 사전예약, 이벤트, 신규 관리자 기능처럼 오픈 시점이 중요한 기능에 좋습니다.

✅ 10. 롤백이란 무엇인가?

롤백(Rollback)은 배포 후 문제가 발생했을 때 이전 정상 상태로 되돌리는 작업입니다.
좋은 배포는 “어떻게 올릴지”뿐 아니라 “문제 생기면 어떻게 되돌릴지”까지 준비되어 있어야 합니다.

새 버전 배포
  ↓
오류 발생
  ↓
이전 버전으로 되돌림
  ↓
서비스 정상화

➕ 10-1. 롤백이 필요한 상황

API 500 에러 급증
관리자 로그인 불가
상담 신청 저장 실패
DB migration 문제
환경변수 누락
외부 API 연동 실패
프론트 화면 깨짐
배치/Queue Worker 장애
Webhook 처리 실패

✅ 11. 코드 롤백

코드만 문제가 있는 경우 이전 커밋이나 이전 빌드로 되돌릴 수 있습니다.

➕ 11-1. Git 기반 롤백 예시

git log --oneline
git checkout <previous-commit>
npm install
npm run build
pm2 reload api

급한 상황에서는 이전 정상 커밋으로 checkout 후 빌드/재시작할 수 있습니다.
하지만 운영에서는 태그나 릴리즈 단위로 관리하는 것이 더 안전합니다.

➕ 11-2. 태그 기반 릴리즈

git tag release-2026-07-06
git push origin release-2026-07-06

배포한 버전에 태그를 달아두면 나중에 어떤 버전이 운영에 올라갔는지 추적하기 쉽습니다.

✅ 12. 프론트엔드 롤백

React/Vite 프론트엔드는 빌드된 정적 파일을 S3/CloudFront 또는 Nginx에 배포합니다.
프론트 롤백은 이전 빌드 결과물을 다시 배포하는 방식이 좋습니다.

현재 배포:
dist-v20260706

문제 발생:
이전 정상 dist-v20260705 재배포
  ↓
CloudFront invalidation

➕ 12-1. 주의할 점

index.html 캐시가 오래 남으면 새/구 asset이 꼬일 수 있습니다.
JS/CSS 파일명에 hash가 붙는지 확인해야 합니다.
API 응답 구조 변경과 프론트 버전이 호환되는지 확인해야 합니다.

프론트 새 버전:
response.data.items 기대

백엔드 구버전:
response.items 반환

결과:
프론트 화면 깨짐

프론트/백엔드 동시 변경은 배포 순서를 신중하게 정해야 합니다.

✅ 13. DB migration과 롤백

DB 변경이 포함된 배포는 롤백이 훨씬 어렵습니다.
코드는 이전 버전으로 되돌릴 수 있지만, DB 구조와 데이터는 쉽게 되돌리기 어렵습니다.

➕ 13-1. 위험한 DB 변경

컬럼 삭제
테이블 삭제
enum 값 삭제/변경
NOT NULL 컬럼 추가
unique 제약 추가
대량 데이터 update
데이터 포맷 변환

이런 변경은 배포 전 스냅샷과 롤백 전략이 필요합니다.

➕ 13-2. 안전한 migration 사고방식

1단계:
새 컬럼 추가, nullable 허용

2단계:
코드가 새 컬럼도 함께 쓰도록 배포

3단계:
데이터 백필

4단계:
충분히 검증 후 기존 컬럼 제거

한 번에 컬럼을 삭제하거나 구조를 크게 바꾸면 롤백이 어렵습니다.
운영에서는 DB 변경을 여러 단계로 나누는 것이 안전합니다.

✅ 14. Backward Compatible 배포

Backward Compatible은 새 코드와 기존 데이터/기존 클라이언트가 함께 동작할 수 있게 만드는 것입니다.
무중단 배포에서 매우 중요합니다.

➕ 14-1. API 응답 호환 예시

{
  "id": 1,
  "status": "PENDING"
}

새 필드를 추가할 때:

{
  "id": 1,
  "status": "PENDING",
  "statusLabel": "신규 접수"
}

새 필드를 추가하는 것은 보통 안전합니다.
기존 필드를 삭제하거나 이름을 바꾸는 것은 위험합니다.

➕ 14-2. 위험한 변경

status → consultStatus로 필드명 변경
items 배열 구조 변경
price 타입 number → string 변경
기존 enum 값 삭제
필수 요청 필드 추가

프론트엔드가 아직 기존 구조를 기대하고 있다면 화면이 깨질 수 있습니다.
API 변경은 가능한 한 하위 호환성을 유지하는 것이 좋습니다.

✅ 15. 배포 순서 설계

프론트엔드, 백엔드, DB가 함께 바뀌는 경우 배포 순서를 잘 정해야 합니다.

➕ 15-1. 안전한 순서 예시

1. DB에 새 컬럼 추가
2. 백엔드가 기존/새 구조 모두 처리하도록 배포
3. 프론트엔드가 새 필드를 사용하도록 배포
4. 충분히 검증
5. 더 이상 쓰지 않는 기존 필드 제거

DB → 백엔드 → 프론트 순서가 항상 정답은 아니지만, 호환성을 기준으로 순서를 정해야 합니다.
핵심은 “중간 상태에서도 서비스가 정상 동작하는가?”입니다.

✅ 16. 배포 전 체크리스트

➕ 16-1. 코드 체크

1. main 브랜치 최신 상태 확인
2. 빌드 성공
3. 테스트 통과
4. 타입 에러 없음
5. lint 주요 오류 없음
6. 사용하지 않는 console.log 제거
7. 민감정보 로그 출력 여부 확인

➕ 16-2. 환경변수 체크

1. 새 환경변수 추가 여부 확인
2. 운영 .env 반영 여부 확인
3. GitHub Actions Secrets 반영 여부 확인
4. API Key 개발/운영 구분 확인
5. CORS Origin 확인
6. Webhook URL 운영 주소 확인

➕ 16-3. DB 체크

1. migration 파일 확인
2. migrate deploy 대상 확인
3. 운영 DB 스냅샷 필요 여부 판단
4. 위험한 migration 여부 확인
5. 기존 데이터와 호환성 확인
6. 롤백 가능성 검토

➕ 16-4. 운영 영향 체크

1. 고객 신청 기능 영향 여부
2. 관리자 주문/상담 기능 영향 여부
3. 알림톡/SMS Queue 영향 여부
4. Webhook 처리 영향 여부
5. Batch/Cron 영향 여부
6. 엑셀 Export 영향 여부
7. 광고/EP 파일 영향 여부

✅ 17. 배포 후 체크리스트

1. /health 응답 확인
2. PM2 프로세스 online 확인
3. Nginx error.log 확인
4. API 500 에러 증가 여부 확인
5. 관리자 로그인 확인
6. 고객 상담 신청 테스트
7. 관리자 상담 목록 반영 확인
8. Queue Worker 정상 처리 확인
9. 외부 API 실패 증가 여부 확인
10. Webhook 수신 정상 여부 확인
11. Batch 스케줄러 중복 실행 여부 확인
12. CloudWatch/Sentry 에러 확인

➕ 17-1. 명령어 예시

pm2 list
pm2 logs togethermall-api --lines 100
pm2 logs togethermall-worker --lines 100
sudo tail -n 100 /var/log/nginx/error.log
curl -i https://api.example.com/health

배포 직후에는 “사이트가 뜬다”만 보면 부족합니다.
핵심 API, Worker, 로그, 외부 연동까지 확인해야 합니다.

✅ 18. 장애 기준과 롤백 기준

배포 후 문제가 생겼을 때 언제 롤백할지 기준이 있어야 합니다.
기준이 없으면 계속 고치려고 하다가 장애 시간이 길어질 수 있습니다.

➕ 18-1. 즉시 롤백을 고려할 상황

상담 신청 저장 실패
관리자 로그인 불가
주문/결제 처리 실패
API 500 에러 급증
DB migration 오류
외부 API 대량 실패
프론트 메인 화면 접근 불가
Webhook 처리 실패
개인정보 노출 가능성 발견

➕ 18-2. 핫픽스로 처리할 수 있는 상황

일부 문구 오타
특정 버튼 위치 문제
관리자 화면 일부 스타일 깨짐
낮은 영향도의 필터 오류
일부 비핵심 페이지 오류

핵심 전환, 개인정보, 결제, 관리자 주요 기능에 문제가 생기면 빠르게 롤백하는 것이 낫습니다.
작은 UI 문제는 핫픽스로 처리할 수 있습니다.

✅ 19. 릴리즈 기록 남기기

배포가 끝나면 릴리즈 기록을 남기는 것이 좋습니다.
1인 개발자라도 이 습관은 나중에 큰 차이를 만듭니다.

➕ 19-1. 릴리즈 기록 템플릿

## Release 2026-07-06

### 배포 시간
- 2026-07-06 19:30

### 배포자
- 동준

### 주요 변경사항
- 상담 상태 변경 이력 저장 추가
- ExportJob 실패 상태 표시 개선
- 알림톡 재처리 Worker 추가

### DB 변경
- ConsultStatusHistory 테이블 추가
- ExternalApiLog 인덱스 추가

### 환경변수 변경
- KAKAO_API_BASE_URL 추가
- KAKAO_API_KEY 추가

### 배포 전 확인
- [x] 빌드 성공
- [x] migration 확인
- [x] 환경변수 반영
- [x] 상담 신청 QA
- [x] 관리자 권한 QA

### 배포 후 확인
- [x] /health 정상
- [x] PM2 online
- [x] Nginx error.log 특이사항 없음
- [x] 관리자 로그인 정상
- [x] 상담 신청 정상

### 롤백 방법
- 이전 커밋 release-2026-07-05로 checkout 후 재배포
- DB 변경은 스냅샷 기반 복구 필요 여부 확인

릴리즈 기록은 장애 대응, 경력 정리, 연봉협상 자료에도 도움이 됩니다.
단순히 “배포함”보다 “검증 기준을 갖고 안정적으로 운영함”이 훨씬 강합니다.

✅ 20. 실무 체크리스트

➕ 20-1. 무중단 배포 체크리스트

PM2 reload 또는 순차 재시작이 가능한가?
health check API가 있는가?
새 버전이 뜬 뒤 트래픽을 받을 수 있는가?
배포 중 기존 요청이 끊기지 않는가?
Worker와 API 서버 배포 순서가 정해져 있는가?
배포 중 Webhook이 들어와도 안전한가?
배치 작업 시간과 배포 시간이 겹치지 않는가?
DB migration이 하위 호환되는가?

➕ 20-2. 롤백 체크리스트

이전 정상 커밋이나 태그를 알고 있는가?
이전 빌드 파일을 보관하는가?
DB 변경이 롤백 가능한가?
위험한 migration 전 스냅샷을 만들었는가?
롤백 기준이 정해져 있는가?
롤백 후 health check를 수행하는가?
롤백 후 Queue/Batch/Webhook 상태를 확인하는가?
장애 기록을 남기는가?

➕ 20-3. 릴리즈 관리 체크리스트

이번 배포 변경사항이 문서화되어 있는가?
DB 변경과 환경변수 변경이 표시되어 있는가?
영향받는 API와 화면을 알고 있는가?
QA 결과를 기록했는가?
배포 후 확인 결과를 기록했는가?
문제가 생겼을 때 담당자가 무엇을 확인해야 하는지 정리되어 있는가?
배포 태그나 커밋 해시를 남겼는가?

✅ 21. AI를 활용해 배포/롤백 계획을 만들 때 질문법

배포 계획은 코드 반영 방법뿐 아니라 DB, 환경변수, Queue, Worker, Webhook, 프론트 호환성까지 함께 설명해야 합니다.
“배포 방법 알려줘”라고만 하면 실제 운영에서 필요한 위험 체크가 빠질 수 있습니다.

➕ 21-1. 좋은 질문 예시

React + NestJS + Prisma + PostgreSQL + AWS EC2/RDS/S3 구조에서 배포 계획을 세우고 싶어.

상황:
1. 백엔드는 EC2에서 PM2로 실행 중
2. 프론트는 S3 + CloudFront로 배포
3. DB는 RDS PostgreSQL
4. 이번 배포에는 ConsultStatusHistory 테이블 추가 migration이 있음
5. 알림톡 Queue Worker 코드도 변경됨
6. 관리자 상담 상태 변경 API 응답 구조가 일부 변경됨
7. 운영 중 상담 신청이 계속 들어올 수 있음
8. 배포 중 Webhook 요청도 들어올 수 있음
9. 문제가 생기면 빠르게 롤백해야 함

요청:
- 안전한 배포 순서
- DB migration 주의사항
- PM2 reload 방식
- 프론트/백엔드 호환성 확인
- Queue Worker 배포 순서
- 배포 전 체크리스트
- 배포 후 확인 체크리스트
- 롤백 기준과 절차
를 실무 기준으로 정리해줘.

➕ 21-2. AI 답변 검증 기준

단순히 git pull && npm run build만 말하지 않는가?
DB migration 위험도를 확인하는가?
하위 호환성, 프론트/백엔드 응답 구조 호환성을 고려하는가?
PM2 reload와 health check를 포함하는가?
Queue Worker와 Webhook 처리 영향을 확인하는가?
배포 전/후 체크리스트를 나누는가?
롤백 기준을 제안하는가?
위험한 migration 전 스냅샷을 언급하는가?

📌 요약

배포는 코드를 운영 서버에 반영하는 작업이고, 릴리즈는 어떤 변경사항 묶음을 사용자에게 공개했는지 관리하는 단위입니다.
배포는 코드, 환경변수, DB migration, 빌드, 프로세스 재시작, health check, 로그 확인, 롤백 가능성을 함께 봐야 합니다.
무중단 배포는 배포 중에도 서비스 요청이 끊기지 않게 하는 방식이며, PM2 cluster + reload로 작은 서비스에서도 일부 구현할 수 있습니다.
Blue-Green, Rolling, Canary 배포는 더 안정적인 방식이지만 초기에는 PM2 reload, health check, 롤백 체계를 먼저 갖추는 것이 현실적입니다.
기능 플래그를 사용하면 코드는 배포하되 특정 기능 공개 시점을 설정값으로 제어할 수 있어 사전예약, 이벤트, 신규 관리자 기능에 유용합니다.
DB migration이 포함된 배포는 코드 롤백보다 훨씬 위험하므로 컬럼 삭제, enum 변경, unique 제약 추가, 대량 update는 특히 조심해야 합니다.
API 응답 구조와 DB 스키마 변경은 하위 호환성을 고려해 여러 단계로 나누는 것이 안전합니다.
배포 전에는 빌드, 환경변수, DB migration, 권한, Queue, Webhook, Batch 영향을 확인하고, 배포 후에는 health check, PM2, Nginx log, 주요 기능, 외부 API 실패 여부를 확인해야 합니다.
좋은 운영자는 배포 방법뿐 아니라 롤백 기준과 릴리즈 기록까지 함께 관리합니다.

juni

이전 포스트

TIL - 20260705

다음 포스트

TIL - 20260706

TIL

0706 백엔드 실무 심화 (13/N): 무중단 배포, 롤백과 릴리즈 관리

✅ 1. 배포란 무엇인가?

➕ 1-1. 배포가 위험한 이유

✅ 2. 릴리즈란 무엇인가?

➕ 2-1. 릴리즈에 포함하면 좋은 정보

✅ 3. 중단 배포와 무중단 배포

➕ 3-1. 중단 배포

➕ 3-2. 무중단 배포

✅ 4. PM2 reload

➕ 4-1. restart와 reload 차이

➕ 4-2. PM2 ecosystem 예시

✅ 5. Health Check

➕ 5-1. 기본 health API 예시

➕ 5-2. 응답 예시

➕ 5-3. DB 연결까지 확인하는 health check

✅ 6. Blue-Green 배포

➕ 6-1. 장점

➕ 6-2. 단점

➕ 6-3. 1인 개발자 기준

✅ 7. Rolling 배포

✅ 8. Canary 배포

✅ 9. 기능 플래그

➕ 9-1. 사용 예시

➕ 9-2. Prisma 설정 예시

➕ 9-3. 실무 기준

✅ 10. 롤백이란 무엇인가?

➕ 10-1. 롤백이 필요한 상황

✅ 11. 코드 롤백

➕ 11-1. Git 기반 롤백 예시

➕ 11-2. 태그 기반 릴리즈

✅ 12. 프론트엔드 롤백

➕ 12-1. 주의할 점

✅ 13. DB migration과 롤백

➕ 13-1. 위험한 DB 변경

➕ 13-2. 안전한 migration 사고방식

✅ 14. Backward Compatible 배포

➕ 14-1. API 응답 호환 예시

➕ 14-2. 위험한 변경

✅ 15. 배포 순서 설계

➕ 15-1. 안전한 순서 예시

✅ 16. 배포 전 체크리스트

➕ 16-1. 코드 체크

➕ 16-2. 환경변수 체크

➕ 16-3. DB 체크

➕ 16-4. 운영 영향 체크

✅ 17. 배포 후 체크리스트

➕ 17-1. 명령어 예시

✅ 18. 장애 기준과 롤백 기준

➕ 18-1. 즉시 롤백을 고려할 상황

➕ 18-2. 핫픽스로 처리할 수 있는 상황

✅ 19. 릴리즈 기록 남기기

➕ 19-1. 릴리즈 기록 템플릿

✅ 20. 실무 체크리스트

➕ 20-1. 무중단 배포 체크리스트

➕ 20-2. 롤백 체크리스트

➕ 20-3. 릴리즈 관리 체크리스트

✅ 21. AI를 활용해 배포/롤백 계획을 만들 때 질문법

➕ 21-1. 좋은 질문 예시

➕ 21-2. AI 답변 검증 기준

📌 요약

TIL - 20260705

TIL - 20260707

0개의 댓글