Reversibility — There Are No Final Decisions

Hunt & Thomas The Pragmatic Programmer (1999) Tip 14. 모든 결정은 가설. 미래는 예측 불가능하고, 그 가설이 틀릴 때를 위해 되돌릴 수 있는 형태로 design한다. overview의 🔄 Process 축 두 번째. orthogonality의 짝. AI 시대에는 git이 reversibility의 default infrastructure이고, AI agent의 irreversible action 일상화가 새 위험.

한 줄

"There are no final decisions" (Pragmatic Programmer). 모든 architectural 결정은 가설이고, 가설이 틀릴 때 되돌릴 수 있어야 함. AI 시대에는 두 변화가 동시에 발생 — AI가 irreversible action을 일상적으로 시도하는 위험 + git이 reversibility infrastructure로 표준화되는 기회. v1.0의 ship-and-rollback as normal (12% production cohort 패턴)이 정확히 이 명제의 운영 표현.

⚛️ 철학

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

Pragmatic Programmer의 정의

"There are no final decisions. No decision is cast in stone. Instead, consider each decision as written in the sand at the beach, and plan for change."

— Hunt & Thomas, The Pragmatic Programmer (1999), Tip 14

핵심 명제:

모든 결정은 가설. 미래는 예측 불가능. 따라서 결정의 가치는 그 결정이 맞는가가 아니라 틀렸을 때 되돌릴 수 있는가로 판단된다.

결정의 두 종류 — Bezos two types

Jeff Bezos가 Amazon shareholder letter (2015)에서 정리한 명제:

Type 1 decisions: irreversible. one-way doors. 신중하게. Type 2 decisions: reversible. two-way doors. 빠르게.

→ 두 종류를 구분하는 게 가장 strategic한 결정 도구. Bezos가 대부분의 결정은 Type 2인데 사람들이 Type 1처럼 다룬다고 비판.

Pragmatic Programmer의 reversibility는 Type 2 결정의 비율을 늘리는 design. 가능한 한 모든 결정을 Type 2로 만들기.

Reversibility Spectrum

현실에서는 완전 reversible vs irreversible이 아니라 spectrum:

예시:

• 완전 reversible: feature flag toggle (1초)
• Cheap reversible: git revert (1분)
• Expensive reversible: vendor 교체 (몇 주)
• Practically irreversible: public API contract 변경 (사용자 커뮤니티 전체 영향)
• Truly irreversible: 데이터 손실, 사용자 신뢰 손실, 보안 사고

→ Design 결정은 spectrum에서 왼쪽으로 끌어당기는 것. 가능한 모든 결정을 cheap reversible로.

Compensating Action — 되돌리는 명시적 procedure

Reversibility의 mechanism:

→ 모든 결정에 compensating action이 정의되어 있어야 reversible. 없으면 "잘못되면 어떻게 하지?"가 미해결.

다른 root와의 연결

• orthogonality — orthogonal 시스템이 결정 되돌리기 쉬움. 직교가 reversibility의 mechanism. 짝
• anti-corruption-layer — 외부 결정의 reversibility 도구. ACL이 vendor 교체를 cheap reversible로
• information-hiding — secret을 module 안에 격리하면 그 secret 변경이 reversible
• bounded-context — BC 분리 결정의 reversibility. 잘못 그은 BC를 다시 그을 수 있는가
• ship-and-rollback-as-normal — reversibility의 운영 단위 표현. 직접 응용
• strategic-vs-tactical-programming — Bezos Type 1 결정이 strategic, Type 2가 tactical. 정확한 매핑

🧱 추상적 작동 구조

결정의 reversibility 측정 framework:

Reversibility를 만드는 mechanism들

→ Reversibility는 기술적 mechanism의 모음이지 철학이 아님. 도구를 갖추는 게 답.

Hickey의 immutable data가 reversibility의 functional 표현

Mutable state:
  state.modify(x)  →  과거 state 사라짐  →  reversibility = backup만

Immutable state:
  state' = state.with(x)  →  state도 state'도 둘 다 존재  →  reversibility = 자동

→ Functional paradigm은 언어 차원에서 reversibility 보장. Clojure / Datomic은 역사 자체를 보존. event sourcing이 같은 정신.

⚠️ 약점/한계

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

1. 완전 reversible은 불가능

진짜 못 되돌리는 것들:

• 데이터 손실 — 백업 없으면 복원 불가
• 시간 — 흘러간 시간은 못 되돌림
• 신뢰 손실 — 사용자 신뢰가 깨지면 회복 어려움
• 보안 사고 — 노출된 비밀번호, leak된 데이터

해결: Reversibility의 한계를 인정하고 예방과 완화를 분리. 데이터 = 백업으로 예방, 시간 = lock-in 회피로 예방, 신뢰 = 점진 rollout으로 완화.

2. Reversibility 비용

되돌릴 수 있게 만드는 데 비용:

• Feature flag = 코드 양 증가, 분기 복잡도
• Migration up + down = down script 작성·테스트 비용
• Snapshot = 저장 공간 비용
• Immutable data = 메모리 비용

→ 모든 결정을 reversible로 만들려 하면 over-engineering. 변화 압력이 낮은 자리는 reversibility 비용 = 낭비.

3. Premature reversibility

안 변할 결정도 reversible로 만들려 불필요한 indirection. 예: 한 vendor만 평생 쓸 거면서 Provider trait를 만드는 비용.

해결: Bezos Type 분류를 먼저. Type 1만 reversibility 깊이 투자. Type 2는 기본 mechanism (git)으로 충분.

4. Decision 종류 판단 어려움

어느 결정이 Type 1인가 사전에 모름. 공개 API가 처음에는 Type 2처럼 보이지만 사용자가 생기면 Type 1로 변함.

해결: Default를 Type 1로. 의심되면 Type 1처럼 다루기. 과대평가가 과소평가보다 안전.

5. AI 시대 specific — AI agent의 irreversible action 일상화

AI agent가 위험한 명령을 가볍게 시도:

• rm -rf (file delete)
• DROP TABLE (DB schema change)
• git reset --hard (commit history 잃음)
• API call로 외부 시스템 변경 (이메일 발송, 결제 등)

→ AI 시대에 reversibility 부재가 가장 위험한 자리.

해결: Sandbox + capability-based security. AI에게 irreversible action 권한 주지 않음. 반드시 사람이 confirm. v1.0의 sandbox layer가 이 답.

6. Reversibility의 false sense

Reversible로 보이지만 사실 irreversible인 결정:

• Public open source release — 코드는 git revert 가능하지만 사용자 fork·copy는 못 되돌림
• 내부 데이터 모델 변경 — migration은 가능하지만 외부 보고서·dashboard가 의존하면 cascading
• Vendor 결정 — Provider trait 있어도 사용자가 vendor specific feature 사용하면 lock-in

해결: Reversibility를 spectrum으로 보고 매번 측정. 한 번 reversible이라고 영구히 reversible 아님.

🔄 대안 흐름

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

대안 1 — Strategic irreversibility (의도적 lock-in)

의도적으로 되돌릴 수 없게 만들어 commitment. 도메인이 안정적이고 변경 의지가 분명히 없을 때.

→ Reversibility의 반대지만 정당. commitment의 기술적 표현. 단, 잘못된 commitment의 비용 큼.

대안 2 — Move fast and break things (Facebook 초기)

Reversibility 무시. 빠르게 시도 + 잘못되면 forward만. backward는 시간 낭비.

→ 작은 시스템 / startup에 정당. 큰 시스템에서는 결국 reversibility 필요해짐 (Facebook도 Move Fast With Stable Infra로 수정).

대안 3 — Forward-only migration

Backward 무시. forward만 설계. DB schema도 forward 전용. 잘못된 변경은 새 forward로 fix.

→ Append-only 시스템에 정당. event sourcing 정신. 단, 데이터 잃을 위험 있음.

대안 4 — YAGNI에 의한 reversibility 회피

미래 변경을 미리 대비하지 말기. 변경이 발생할 때 그때 현재 결정 위에서 다시 design.

→ Pragmatic Programmer 안에서도 YAGNI와 reversibility는 균형. 항상 reversibility를 만드는 건 over-engineering.

대안 5 — Strong typing이 reversibility 대체

Type system이 컴파일 타임에 변경의 안전성 보장. 잘못된 변경은 컴파일 안 됨. runtime reversibility 불필요.

→ Rust, Haskell 같은 언어의 답. static safety가 dynamic reversibility의 일부 대체. 단, 모든 변경을 type으로 표현 못함.

💡 인사이트

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

1. AI agent의 irreversible action 일상화가 가장 큰 새 위험

전통적으로 irreversible action은 사람이 조심스럽게 수행. 2번 확인, 동료 review, 시간 두기. AI 시대:

AI agent는 조심성이 없음. 매 prompt마다 명령을 가볍게 실행.

이게 research/stateless-llm-sdk/research-to-production-gap|research-to-production-gap의 88% pilot 실패의 한 원인 — AI가 irreversible action을 했는데 되돌릴 수 없음 → production 신뢰 불가.

해결: Sandbox + 사람의 explicit confirm. 12% 성공 cohort의 공통.

2. Git이 AI agent의 reversibility infrastructure

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

"AI agent에게 git commit/revert를 강제하면 모든 변경이 reversible해진다."

매 step마다 commit → 잘못되면 git revert. AI agent의 reversibility infrastructure가 git. 그래서 v1.0이 git을 first-class citizen으로 둠.

→ AI 시대에 git이 단순 VCS가 아니라 reversibility의 default infrastructure. 모든 modern AI coding agent (Claude Code, Codex, Cursor)가 git을 가정.

3. Bezos two types와 strategic/tactical의 정확한 매핑

→ strategic-vs-tactical-programming 명제의 결정 종류 측 표현. AI에게 위임할 수 있는 자리 = Type 2 = tactical.

AI 위임의 안전 mechanism: Type 2만 위임. Type 1은 사람의 strategic 결정. 이게 v1.0 권한 모델의 직접 근거.

4. v1.0 design 직접 적용

→ 모든 layer에 reversibility mechanism 박힘. Type 1으로 변할 위험이 있는 자리에 명시적으로 reversibility 도구 배치.

5. 학내 segment 가치 — 학기 변경 흡수의 mechanism

학내 시스템은 학기마다 변경 — reversibility가 가장 직접적 가치:

• 학사 시스템 UI 변경 → ACL이 흡수, 도구는 그대로
• 학칙 변경 → 새 정책 module로, 옛 정책은 역사로 보존
• 정책 변경 → feature flag로 전환

→ 학내 segment에서 변경이 자주 발생하니 reversibility가 가장 ROI 높은 fundamentals. v1.0이 학내에 가져다 주는 변경 흡수 능력.

6. Hickey immutable data가 reversibility의 functional 표현

simple-not-easy에서 정리한 Hickey의 immutable:

• Mutable: state 변경 → 과거 state 사라짐 → reversibility 추가 mechanism 필요 (백업)
• Immutable: state 추가 → 과거 state 자동 보존 → reversibility 자동

Datomic / Clojure / event sourcing이 언어/데이터 차원에서 reversibility를 default로 만든 사례.

→ Functional paradigm 채택의 AI 시대 새 정당화 — reversibility를 무료로 얻음. AI agent에게 과거 state 분석이 자동 가능.

7. AI 시대 새 reversibility mechanism — Conversation history

Claude Code / Codex 같은 modern AI 도구가 대화 history를 보존하면 AI 결정의 reversibility가 새로 가능:

• 어떤 결정을 왜 했는지 history로 추적
• 잘못된 결정 발견 시 그 시점으로 conversation 되돌리기
• 다른 path로 다시 시작

→ AI 시대의 meta-level reversibility. 결정뿐 아니라 결정 과정도 reversible.

8. Ship-and-Rollback as Normal과의 직접 만남

12% production cohort의 패턴 (ship-and-rollback-as-normal):

배포와 rollback을 둘 다 normal operation으로 다룸. 둘 중 하나가 verdict가 아님.

이게 정확히 reversibility의 조직·운영 단위 표현. 88% pilot이 못 가는 이유 = rollback을 실패로 해석. 12%가 가는 이유 = rollback을 ship과 동등하게.

→ Reversibility가 기술 mechanism + 조직 문화 둘 다 필요. v1.0이 기술 측을 도구화하면 조직 측도 자연스럽게 따라옴.

다음에 가야 할 자리

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

• ship-and-rollback-as-normal — reversibility의 운영 단위 표현. 12% production 패턴
• tdd-as-small-deliberate-steps — 각 작은 step이 reversible. test가 reversibility 확인 도구
• tracer-bullets — tracer는 자체가 reversible (작은 end-to-end는 버리기 쉬움)

→ 🔄 Process 축 두 번째 완료. 다음은 tdd-as-small-deliberate-steps 또는 tracer-bullets. 또는 🤖 AI 시대 표현으로 가서 ship-and-rollback-as-normal (reversibility의 운영 표현)이 직접 따라오는 흐름도 좋음.

관련

• overview
• orthogonality — 직교가 reversibility의 mechanism. 짝
• anti-corruption-layer — 외부 결정 reversibility 도구
• information-hiding — secret 격리가 그 결정 reversibility
• bounded-context — BC 결정 자체의 reversibility
• strategic-vs-tactical-programming — Bezos Type 1=strategic, Type 2=tactical 매핑
• ship-and-rollback-as-normal — reversibility의 운영 표현
• research/stateless-llm-sdk/design-principles|design-principles — 7 원칙 4번 (Reversible Decisions)의 직접 source

Sources

직접 source

• The Pragmatic Programmer: 20th Anniversary Edition — Hunt & Thomas (2019). Tip 14 There Are No Final Decisions. 한국어판 《실용주의 프로그래머》 (인사이트)

Bezos Two Types of Decisions

• Bezos, J. (2015). Amazon shareholder letter. https://www.sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm — Type 1 vs Type 2 원전

AI 시대 reversibility

• Anthropic — Effective Harnesses for Long-Running Agents — git이 reversibility infrastructure
• research/stateless-llm-sdk/research-to-production-gap — 12% production cohort의 reversibility 패턴

Functional / Immutable

• Simple Made Easy — Rich Hickey. immutable data가 reversibility의 functional 표현
• Datomic — Hickey의 DB. 역사 자체 보존
• Designing Data-Intensive Applications — Martin Kleppmann. event sourcing chapter

Strong typing

• The Rust Programming Language — Steve Klabnik & Carol Nichols. type-level safety