Ship-and-Rollback as Normal — 12% production cohort의 분수령

88% AI pilot이 production 못 가는 이유 중 큰 것이 rollback을 실패로 해석하는 조직 문화. 12% 성공 cohort의 공통: ship과 rollback을 둘 다 normal operation으로 다룸. overview의 🤖 AI 시대 운영 표현 첫 노트. reversibility의 운영·조직 단위 응용. AI agent의 기본 working mode 자체가 ship-and-rollback이라서, 이 명제가 AI 시대에 가장 폭발적으로 작동.

한 줄

배포(ship)와 롤백(rollback)이 둘 다 verdict가 아닌 normal operation. 88% pilot이 production 못 가는 이유는 기술이 아니라 문화 — rollback을 실패로 해석. 12% 성공 cohort는 둘 다 지속적 학습 도구로 본다. AI 시대에는 AI agent의 working mode 자체가 작은 시도 → 빠른 rollback 구조라서, 이 패턴이 기술 표준이 됨. v1.0의 sandbox + git commit/revert가 정확히 이 implementation.

⚛️ 철학

원칙의 왜. 더 깊은 root와의 연결.

12% vs 88% — 시장 데이터

research/stateless-llm-sdk/research-to-production-gap|research-to-production-gap의 핵심 발견 (March 2026 enterprise survey):

88%의 AI pilot이 production에 도달하지 못한다. 12%만이 도달한다.

차이의 분석:

• 기술 — 비슷함. 같은 model, 비슷한 framework
• 팀 능력 — 비슷함
• 데이터 — 비슷함
• 문화의 차이가 가장 큼

12% 성공 cohort의 4가지 공통 패턴 중 하나가 ship-and-rollback as normal:

배포와 롤백이 둘 다 정상. 한쪽이 verdict가 아님.

88% 실패 cohort의 흔한 패턴:

• ship = 성공의 verdict
• rollback = 실패의 verdict
• rollback이 부끄러움. 누가 rollback 했나 추궁
• 결과: rollback 회피 → 위험한 결정 강행 → 큰 실패 → 결국 production 도달 못함

핵심 명제

Ship과 rollback은 학습 cycle의 두 단계다. PDCA의 모든 step이 정상이듯, 둘 다 정상.

Erlang의 let-it-crash 정신과 정렬

Joe Armstrong (Erlang/OTP 창시자)의 명제:

"Let it crash." Crash는 정상이다. 회복 mechanism이 잘 design되어 있으면 crash는 학습 trigger.

→ Ship-and-rollback이 application 단위에서 같은 정신. rollback은 정상이다, 회복 mechanism이 잘 design되어 있으면 rollback은 학습 trigger.

OTP의 supervision tree가 ship-and-rollback의 architectural 표현 — process가 죽으면 supervisor가 다시 시작, 죽음 자체가 design의 일부.

다른 root와의 연결

• reversibility — ship-and-rollback이 reversibility의 운영·조직 단위 표현. 직접 후속
• strategic-vs-tactical-programming — strategic은 ship-and-rollback 둘 다의 의미를 봄. tactical은 ship만 측정
• orthogonality — orthogonal 시스템이 rollback 비용 낮음 → ship-and-rollback이 가능
• anti-corruption-layer — 외부 시스템 결정 rollback의 mechanism
• tdd-as-small-deliberate-steps — 각 step이 ship-and-rollback의 작은 단위
• information-hiding — 변화 blast radius가 작으면 rollback 비용 작음

🧱 추상적 작동 구조

두 문화의 비교

Ship-and-rollback의 5가지 mechanism

→ mechanism + 문화 둘 다 필요. mechanism만 있으면 rollback은 가능하지만 사용 안 함. 문화만 있으면 rollback이 비싸서 못함.

Anthropic harnesses의 git commit/revert 패턴

sources/key-articles-summary#3. Anthropic — *Effective Harnesses for Long-Running Agents*|Anthropic harnesses 글의 핵심 mechanism:

AI agent task 시작
   ↓
변경 (작은 단위)
   ↓
git commit (descriptive message)
   ↓
검증 (test, smoke run)
   ↓
   - 성공: 다음 task로 (ship)
   - 실패: git revert (rollback)
   ↓
다시 시도 또는 다른 접근

→ Anthropic이 자체 production AI agent를 위해 도달한 답이 정확히 ship-and-rollback as normal. Git commit/revert가 AI 시대 표준 mechanism. 12% cohort 패턴의 가장 강력한 implementation.

⚠️ 약점/한계

원칙의 적용 한계. 잘못 적용 시 함정.

1. 데이터 변경이 동반된 ship은 rollback이 어려움

DB schema migration, 데이터 마이그레이션이 동반된 ship:

• Code rollback은 1분
• Data rollback은 복잡 (forward migration의 reverse가 데이터 손실 위험)
• 일부 변경은 truly irreversible (reversibility 약점 1)

해결: 데이터 변경과 코드 변경 분리. Expand → migrate → contract 패턴 — 새 schema 추가 (rollback 안전), 데이터 마이그레이션, 옛 schema 제거 (각 단계가 reversible).

2. 사용자 영향이 큰 변경은 rollback도 비용

이미 사용자에게 노출된 feature를 rollback:

• 사용자가 그 feature에 의존하기 시작
• Rollback이 사용자 신뢰 손실
• "왜 사라졌어?" 불만

해결: Feature flag + canary deployment. 소수 사용자에게 먼저 노출, 검증 후 확대. Rollback은 사용자 인지 전에.

3. 조직 문화가 mechanism보다 중요

기술 mechanism은 2주에 도입 가능. 문화 변화는 1년 이상. mechanism만 도입하고 문화 안 따라오면 rollback 도구가 있어도 사용 안 함.

해결: Blameless postmortem ritual을 mechanism과 동시에 도입. 처음 rollback할 때 칭찬. 문화 변화의 leverage point.

4. 너무 빠른 rollback이 충분한 학습 못함

문제 발생 즉시 rollback → 왜 발생했는지 분석 부족. 다음 ship에서 같은 문제 재발.

해결: Rollback 후 timed analysis 강제. rollback → 1시간 분석 → postmortem 작성 → 다음 ship. mechanism으로 학습 강제.

5. AI agent의 자동 rollback이 진짜 문제 발견 회피

AI agent가 test fail → 자동 rollback만 반복하면:

• test가 fail하는 root cause 분석 안 됨
• test 자체의 결함 발견 안 됨
• 무한 try → rollback loop

해결: Rollback 횟수 제한. N번 rollback하면 사람에게 escalate. AI 자동성 + 사람 escalation의 hybrid.

6. Rollback 자체의 비용

Rollback도 비용:

• 배포 자원 낭비
• 사용자 short-term 영향 (잠시 다른 버전)
• 운영 시간

해결: Rollback 비용을 ship 비용과 같이 측정. SLO에 rollback rate 포함. 너무 높으면 ship 결정 자체가 문제.

🔄 대안 흐름

이 원칙이 적용 안 되는 시나리오와 다른 답.

대안 1 — Forward-only deployment

Rollback 무시. forward만 설계. 잘못된 변경은 새 forward로 fix.

→ 일부 datacenter-scale 시스템에 정당. 단, 학습 cycle이 길어짐. 일반 시스템에는 부적합.

대안 2 — Canary deployment

소수 사용자에 먼저, 검증 후 확대. 암묵적 ship-and-rollback — 작은 규모로 시도, 이상 시 확대 안 하면 됨.

→ Ship-and-rollback의 덜 격렬한 버전. 모든 modern deployment에서 default.

대안 3 — Blue-green deployment

두 환경 운영. 새 버전 = green, 옛 버전 = blue. 즉시 전환 가능.

→ Ship-and-rollback의 infrastructure 표현. 가장 빠른 rollback (1초). 단, 자원 비용 2배.

대안 4 — Feature flag + dark launch

코드는 배포, 사용자 노출은 flag로 별도 제어. Ship과 enable이 분리됨.

→ Ship-and-rollback의 분리된 표현. 가장 fine-grained. 단, flag 누적이 코드 복잡도 증가.

대안 5 — Chaos engineering (Netflix)

고의로 깨뜨리고 회복. rollback을 일상화하는 게 아니라 failure를 일상화.

→ Ship-and-rollback의 상위 표현. 시스템 자체가 failure-resilient가 됨.

💡 인사이트

AI 시대 왜 지금 부활하는가 + 학내 segment 의미.

1. AI agent의 working mode 자체가 ship-and-rollback

전통적 개발: 큰 단위 ship → 큰 단위 rollback. 1일~1주 단위. AI 시대: 작은 단위 try → 작은 단위 revert. 분 단위.

Claude Code, Codex, Cursor 같은 modern AI agent의 작업 cycle:

1. 작은 변경 시도
2. 테스트
3. 통과 → commit (ship)
4. 실패 → revert (rollback)
5. 다른 접근

→ AI agent가 ship-and-rollback을 자연스럽게 implementation함. 88% 문화의 사람 팀은 ship-and-rollback이 조직 변화 비용이 컸지만, AI agent는 기본 working mode. 12% 패턴이 기술 표준화되는 시대.

2. Git commit이 AI 시대 ship의 단위

reversibility#2. *Git이 AI agent의 reversibility infrastructure*|reversibility 인사이트 2 다시:

Git commit 단위가 AI 시대 ship의 자연 단위. Git revert가 AI 시대 rollback의 자연 단위.

이전에는 production deploy가 ship의 단위. AI 시대에는 git commit이 ship의 단위. 단위가 수백 배 작아짐 → ship-and-rollback의 경제성이 폭발.

3. v1.0 design 직접 적용

→ 모든 layer에 ship-and-rollback 둘 다 동등한 시민으로 design. v1.0의 기본 운영 mode.

4. 학내 segment의 trust 가속

학생이 학내 도구를 채택할 때 가장 큰 장애물:

"잘못되면 어떻게 하지?"

Ship-and-rollback이 default면:

• "잘못되면 바로 되돌릴 수 있다"
• 학생이 안심하고 시도
• 도구 채택 가속

→ orthogonality#5. *Skill 사이 orthogonality = trust mechanism*|orthogonality 인사이트 5와 직접 만남. Trust = ship-and-rollback의 함수.

5. Blameless culture의 학내 의미

학내 환경의 자연스러운 ship-and-rollback 정합:

• 학생이 실험적 도구를 만듦
• 실패해도 OK (학점 risk 없음)
• 다른 학생이 실패에서 배움
• 점진 진화

학내 segment가 blameless culture에 자연스러움. v1.0이 기술 mechanism을 제공하면 학내 segment의 문화와 자연 정합. 88% 실패 기업과 다른 모양.

6. 교수·연구실 segment의 의미

연구 코드는 원래 실험적. 실패가 정상:

• 가설 → 코드 → 실험 → 틀린 가설 발견 → 새 가설
• 매 가설이 ship-and-rollback의 단위

연구실에 v1.0이 가져다 주는 가치:

• 연구 코드도 production 수준 mechanism 사용 가능
• 실험 history 보존 (immutable + git)
• 논문 작성 시 참조 가능 (git history가 실험 ledger)

→ 학내 segment 안에서도 연구실 segment의 specific 가치. v1.0이 학사용도와 연구용도 둘 다 정합.

7. Hickey의 immutable이 ship-and-rollback의 functional 기반

simple-not-easy + reversibility에서 정리한 immutable:

Mutable: ship → state 변경 → 옛 state 사라짐 → rollback = 백업 복원
Immutable: ship → 새 state 추가 → 옛 state 자동 보존 → rollback = state pointer 변경

→ Functional paradigm이 ship-and-rollback을 데이터 차원에서 default로 만듦. Datomic의 as-of query (시간 시점 query)가 ship-and-rollback의 데이터 표현.

8. AI 시대 새 ship-and-rollback 단위 — Conversation

AI agent의 대화가 새 단위:

• 사용자 prompt = ship 시작
• AI 응답 = ship 완료
• 대화를 되돌리기 = conversation rollback
• 새 path로 다시 = 새 ship

reversibility#7. *AI 시대 새 reversibility mechanism*|reversibility 인사이트 7의 conversation history가 ship-and-rollback 단위. v1.0이 대화 단위 ship-and-rollback도 도구화하면 학생이 AI와 안전하게 실험 가능.

9. 12% cohort가 AI 시대 production의 분수령

이 명제의 가장 강한 표현:

88% AI pilot이 production 못 가는 이유 = ship-and-rollback 문화 부재 12%가 가는 이유 = ship-and-rollback as normal

이게 research/stateless-llm-sdk/research-to-production-gap|research-to-production-gap의 핵심 발견. 단순 기술 차이가 아니라 문화·mechanism의 차이. v1.0이 기술 mechanism을 도구화하면 문화 변화의 leverage가 됨.

학내 segment에서: 학생이 처음부터 ship-and-rollback default로 학습 → 88% 함정에 빠지지 않음. 이게 v1.0이 학내에 가져다 주는 fundamentals 중 가장 implementation에 가까운 것.

다음에 가야 할 자리

이 노트가 호출한 다른 원칙들 — 자연스러운 다음 노트:

• named-ownership — 12% cohort의 또 한 가지 공통 패턴. 같은 데이터에서 추출
• tdd-as-small-deliberate-steps — 각 step이 ship-and-rollback의 가장 작은 단위
• tracer-bullets — 작은 end-to-end의 ship-and-rollback

→ AI 시대 운영 표현 두 노트가 짝. named-ownership이 자연스러운 다음.

관련

• overview
• reversibility — ship-and-rollback의 기술 단위. 짝
• orthogonality — 직교가 rollback 비용 낮춤
• anti-corruption-layer — 외부 결정 rollback mechanism
• strategic-vs-tactical-programming — 둘 다의 의미를 보는 게 strategic
• research/stateless-llm-sdk/research-to-production-gap|research-to-production-gap — 12% cohort 패턴의 직접 source
• sources/key-articles-summary#3. Anthropic — *Effective Harnesses for Long-Running Agents*|key-articles-summary — git commit/revert 패턴
• research/stateless-llm-sdk/design-principles|design-principles — 7 원칙 6번 (Ship-and-Roll-Back as Normal Operation)의 직접 source

Sources

직접 source (12% cohort)

• March 2026 enterprise survey (88% AI pilot fail) — research/stateless-llm-sdk/research-to-production-gap|research-to-production-gap 노트의 정리

Erlang let-it-crash

• Armstrong, J. (2003). Making Reliable Distributed Systems in the Presence of Software Errors. PhD thesis. — let-it-crash 원전
• Programming Erlang — Joe Armstrong (2nd ed, 2013)
• Designing for Scalability with Erlang/OTP — Cesarini & Vinoski

Anthropic git commit/revert

• Anthropic — Effective Harnesses for Long-Running Agents — git이 AI 시대 ship-and-rollback의 표준

Deployment 패턴 (대안 흐름)

• Continuous Delivery — Jez Humble & David Farley (2010)
• Site Reliability Engineering — Beyer et al (Google SRE book). canary, blue-green
• The Phoenix Project — Gene Kim. DevOps 문화

Chaos engineering (대안 5)

• Chaos Engineering — Casey Rosenthal & Nora Jones (O'Reilly, 2020). Netflix Chaos Monkey

Functional ship-and-rollback (인사이트 7)

• Datomic — Rich Hickey. as-of query
• Designing Data-Intensive Applications — Martin Kleppmann. event sourcing