HyperTeams프로세스 4 — 즉시 배포
이 장에서 배우는 것 빠른 배포가 왜 위험을 줄이는지(늘리는 게 아니라), 그리고 루프가 어떻게 닫히는지.
검증을 통과하면 나갑니다
자동 검증을 통과한 것은 사람 승인 없이 배포될 수 있습니다. 테스트가 판정을 대신했기 때문입니다.
여기서 불안해지는 게 자연스럽습니다. "사람이 안 보고 나간다고?"
빠른 배포가 오히려 안전한 이유
직관과 반대인데, 작고 자주 배포하는 쪽이 위험이 작습니다.
graph TD
A["큰 배포 · 드물게"] --> A1["변경 100개가 한 번에"]
A1 --> A2["문제 생기면 어느 것 때문인지 모름"]
A2 --> A3["롤백하면 100개가 다 사라짐"]
B["작은 배포 · 자주"] --> B1["변경 1개"]
B1 --> B2["문제 = 그 1개"]
B2 --> B3["롤백 범위도 1개"]| 큰 배포 | 작은 배포 | |
|---|---|---|
| 원인 추적 | 어려움 | 자명함 |
| 롤백 비용 | 큼 | 작음 |
| 발견까지 | 오래 | 빠름 |
마이크로 스프린트로 나눈 이유가 여기서도 이어집니다. 작업이 작으니 배포도 작습니다.
점진적 롤아웃
그래도 한 번에 전부 바꾸지 않습니다.
| 방식 | 어떻게 |
|---|---|
| 카나리 | 일부 사용자(예: 5%)에게 먼저. 문제 없으면 확대 |
| 블루그린 | 새 버전을 나란히 띄우고 트래픽을 옮김. 문제 시 즉시 되돌림 |
어느 쪽이든 되돌리는 경로가 미리 있습니다. 빠르게 나가되 빠르게 되돌릴 수 있게 하는 것입니다.
모니터링이 다음 입력이 됩니다
배포하고 끝이 아닙니다.
여기서 나오는 신호가 다음 사이클의 의도가 됩니다.
graph TD
D["배포"] --> M["모니터링"]
M --> S["신호 발견<br/>'쿠폰 입력 후 이탈률이 높다'"]
S --> I["다음 의도<br/>'쿠폰 오류 메시지를 명확히'"]
I --> P1["의도 포착"]
P1 --> D루프가 닫힙니다. 배포가 끝점이 아니라 다음 출발점이라는 게 이 뜻입니다.
무엇이 있어야 이게 가능한가
솔직하게, 이 단계는 전제 조건이 가장 많습니다.
하나라도 없으면 "즉시 배포"는 위험합니다. 이 목록이 갖춰지지 않은 조직은 프로세스 1~3만 도입하고 배포는 기존 방식(사람 승인)으로 두는 게 맞습니다.
방법론을 전부 도입해야 하는 게 아닙니다. 갖춰진 만큼만 쓰는 게 안전합니다.
사람이 남는 자리
4단계 어디에도 "사람이 코드를 쓴다"가 없습니다. 대신 사람은 세 곳에 있습니다.
- 프로세스 1 앞 — 무엇을 만들지 정하는 판단
- 프로세스 3의 기준 — 테스트가 진짜 합격 기준인지 보는 눈
- 중요한 변경의 승인 — 다음 장의 가드레일
확인
1. 작고 자주 배포하는 쪽이 왜 더 안전합니까?
답
원인 추적과 롤백이 쉽기 때문입니다. 변경 100개가 한 번에 나가면 문제 시 어느 것 때문인지 모르고 롤백하면 100개가 다 사라집니다. 변경 1개면 문제도 그 1개이고 롤백 범위도 1개입니다.
2. 배포 후 모니터링이 왜 프로세스의 일부입니까?
답
모니터링 신호가 다음 사이클의 의도가 되기 때문입니다. "쿠폰 입력 후 이탈률이 높다"가 "오류 메시지를 명확히"라는 다음 의도로 이어지며 루프가 닫힙니다.
3. 자동 배포 전제가 안 갖춰진 조직은 어떻게 해야 합니까?
답
프로세스 1~3만 도입하고 배포는 기존 방식(사람 승인)으로 둡니다. 방법론을 전부 도입해야 하는 게 아니라 갖춰진 만큼만 쓰는 게 안전합니다.
마지막으로, 이 속도를 감당하게 해주는 장치들입니다 → 가드레일과 도입 전 점검