# 전체 예시: 배포 파이프라인 개선 글

## 입력 브리프

```yaml
audience: 백엔드·플랫폼 개발자
purpose: 배포 파이프라인 재설계의 판단과 결과 공유
document_type: performance-case-study
evidence:
  - 기존 평균 배포 시간 18분
  - 변경 후 평균 7분
  - 실패율 3.2%에서 0.9%로 감소
  - 기존에는 실패 단계 확인이 어려움
  - 단계별 로그와 자동 롤백 추가
  - 수동 승인 대기 시간은 측정하지 않음
protected:
  - "kubectl rollout undo deployment/api --to-revision=7"
```

## 주장 장부

| 주장 | 근거 | 범위 |
|---|---|---|
| 배포 시간이 줄었다 | 18분 → 7분 | 동일 서비스, 동일 측정 방식 |
| 실패율이 줄었다 | 3.2% → 0.9% | 측정 기간은 브리프에 추가 확인 필요 |
| 실패 지점 추적이 가능해졌다 | 단계별 로그 | 파이프라인 단계 |
| 전체 배포 시간이 7분이다 | 수동 승인 대기 미포함 | 자동화 구간만 |

## 목차

1. 실패한 배포를 어디서 확인해야 할지 알 수 없었다
2. 평균 시간보다 먼저 실패 경계를 나눴다
3. 단계별 로그와 롤백을 추가했다
4. 자동화 구간은 18분에서 7분으로 줄었다
5. 승인 대기 시간은 다음 측정으로 남았다

## 작성 예시

# 실패 단계를 나눠 배포 시간을 18분에서 7분으로 줄인 과정

기존 배포는 평균 18분이 걸렸다. 실패하면 어느 단계에서 멈췄는지 바로 확인하기 어려워 로그를 다시 모으고 수동으로 롤백해야 했다. 이번 변경에서는 배포 단계를 분리하고 각 단계의 로그와 롤백 경로를 추가했다.

## 먼저 실패 경계를 분리했다

목표는 단순히 평균 시간을 줄이는 것이 아니었다. 실패 지점을 빠르게 확인하고, 문제가 생긴 배포만 이전 리비전으로 되돌릴 수 있어야 했다. 따라서 빌드, 배포, 상태 확인을 독립 단계로 나누고 각 단계가 종료 조건을 직접 기록하게 했다.

롤백에는 다음 명령을 사용했다.

```bash
kubectl rollout undo deployment/api --to-revision=7
```

## 자동화 구간은 평균 7분이 걸렸다

변경 후 자동화 구간의 평균 배포 시간은 18분에서 7분으로 줄었고 실패율은 3.2%에서 0.9%로 감소했다. 다만 이 값에는 수동 승인 대기 시간이 포함되지 않는다. 전체 리드 타임을 평가하려면 승인 요청부터 완료까지의 대기 시간을 별도로 측정해야 한다.

## 남은 일

현재 결과는 자동화 구간의 개선을 보여 준다. 다음 측정에서는 승인 대기 시간과 롤백 완료 시간을 분리해, 파이프라인 변경이 전체 배포 리드 타임에 미친 영향을 확인한다.

## 검토 포인트

- 측정 기간과 표본 수가 없으므로 게시 전 추가한다.
- 코드 블록과 수치는 그대로 보존한다.
- ‘완전히 자동화했다’거나 ‘사용자 경험이 좋아졌다’는 주장은 근거가 없어 넣지 않는다.