Chapter 9: Iron Laws & Anti-Patterns

Iron Laws는 Superpowers가 활성화된 agent의 모든 세션을 지배하는 협상 불가능한 규칙입니다. 가이드라인이나 기본값이나 제안이 아닙니다. 지시, 긴급성, 편의에 의해 재정의될 수 없는 엄격한 제약 조건입니다.

이 법칙들이 왜 존재하는지 — 그리고 이것들을 어겼을 때 무슨 일이 일어나는지 — 를 이해하는 것이 Superpowers를 효과적으로 사용하기 위해 필수적입니다.

4가지 Iron Laws

Iron Law 1: TDD

"NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST"

모든 기능, 모든 버그 fix, 모든 동작 변경은 원하는 동작을 설명하는 실패하는 test가 선행되어야 합니다. 이것은 TDD(Test-Driven Development)를 엄격하게 적용한 것입니다.

왜 이것이 협상 불가능한가:

실패하는 test 없이는 코드가 의도한 대로 작동한다는 증거가 없습니다. 구현하고 바라는 것입니다. 실패하는 test가 먼저 있으면, 구현이 충족해야 할 정확한 명세가 있고 — 영원히 실행되는 검증 메커니즘도 있습니다.

이것이 방지하는 것:

잘못된 것을 자신 있게 구현하는 것
아무것도 test하지 않기 때문에 항상 통과하는 test
"잘 작동할 것 같다"가 유일한 검증인 것
6개월 후 코드가 변경될 때의 regression

적용 방법:

1. test를 작성하세요 → 실패합니다 (RED)
2. 통과시키는 최소한의 코드를 작성하세요 (GREEN)
3. test를 깨지 않고 리팩토링하세요 (REFACTOR)

실패하는 test를 작성할 수 없다면, 아직 요구사항을 충분히 이해하지 못한 것입니다. 멈추고 명확히 하세요.

Iron Law 2: Verification

"NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE"

방금 검증을 실행하고 출력 결과가 앞에 있지 않은 한, 작업이 완료됐거나, fix됐거나, 통과됐다고 주장할 수 없습니다.

왜 이것이 협상 불가능한가:

정신 모델은 신뢰할 수 없습니다. "작동해야 하는" 변경이 종종 작동하지 않습니다. "이전에 작동했던" 코드가 이후 변경으로 인해 깨져 있을 수 있습니다. 유일하게 유효한 증거는 지금 바로 실제 검증 명령을 실행한 출력입니다.

이것이 방지하는 것:

높은 자신감으로 깨진 코드를 출시하는 것
"내 컴퓨터에서는 작동했다"는 실패 패턴
오래된 test 결과를 현재 것으로 취급하는 것
구두 보증이 증거를 대신하는 것

검증은 신선해야 합니다: 5개 commit 전에 test를 실행하고 현재 상태가 괜찮다고 주장하는 것은 검증이 아닙니다. 현재 상태에서 test를 실행하고, 출력을 읽고, 그런 다음 주장하세요.

Iron Law 3: Debugging

"NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST"

fix 코드를 작성하기 전에, Chapter 6에 설명된 대로 근본 원인 조사를 완료해야 합니다. 버그를 유발하는 것이 정확히 무엇인지 한 문장으로 말할 수 있어야 합니다.

왜 이것이 협상 불가능한가:

원인을 이해하지 않고 증상을 fix하는 것이 기술 부채를 축적하는 주요 원인입니다. 각 증상 fix는 복잡성을 추가하고, 실제 문제를 은폐하며, 근본 원인을 나중에 찾기 더 어렵게 만듭니다. Codebase는 아무도 이해하지 못하는 패치들의 집합이 됩니다.

이것이 방지하는 것:

같은 버그가 다른 형태로 다시 나타나는 것
각 fix가 다른 것을 깨뜨리는 fix 연쇄
아키텍처 명확성의 상실
3번 실패 패턴 (Chapter 6 참조)

근본 원인 서술 테스트: fix를 구현하기 전에, 주저 없이 이 문장을 완성할 수 있어야 합니다: "버그는 [특정 것] 때문에 발생합니다. 증거는 [증거]입니다." 완성할 수 없다면, 조사가 완료되지 않은 것입니다.

Iron Law 4: Skills

"NO SKILL WITHOUT A FAILING TEST FIRST"

Superpowers skill을 생성하거나 수정할 때, 동일한 TDD 규칙이 적용됩니다. skill의 의도된 동작을 보여주는 test를 작성하고, 실패하는지 확인한 다음, skill을 구현하세요.

왜 이것이 협상 불가능한가:

Skills는 코드입니다. 올바르거나 올바르지 않을 수 있는 동작을 가집니다. Test 없이는 skill 개발이 다른 테스트되지 않은 코드만큼 신뢰할 수 없습니다 — 작동하다가 갑자기 안 되고, 언제 작동을 멈췄는지 왜인지 알 방법이 없습니다.

Master Red Flags 테이블

이것들은 Iron Law가 곧 위반될 것이라는 경고 신호입니다. 이것들 중 하나라도 관찰하면, 즉시 멈추고 올바른 프로토콜로 돌아가세요.

#	Red Flag	의미하는 것	STOP 행동
1	"이것이 작동해야 합니다"	검증이 건너뛰어졌습니다	지금 검증 명령을 실행하세요
2	"아마 괜찮을 겁니다"	증거 없는 가정	증거를 찾거나 불확실성을 인정하세요
3	"test가 통과해야 합니다"	test가 실행되지 않았습니다	test를 실행하세요
4	"이 fix를 한번 시도해 보죠"	근본 원인 조사가 없습니다	먼저 debugging의 Phase 1을 완료하세요
5	"나중에 test를 추가하겠습니다"	TDD 위반이 진행 중입니다	지금 실패하는 test를 먼저 작성하세요
6	"작은 변경이라 test가 필요 없습니다"	TDD 예외가 만들어지고 있습니다	예외 없음. test를 작성하세요.
7	"맞습니다!" (즉각적인)	형식적 동의	먼저 Read → Understand → Verify → Evaluate
8	깨진 동작에 맞게 test를 수정하는 것	버그를 은폐하는 것	test가 아닌 코드를 fix하세요
9	Main에 직접 commit하는 것	격리 프로토콜을 우회하는 것	Worktree와 branch를 만드세요
10	같은 버그에 대한 네 번째 fix 시도	아키텍처 문제가 은폐되고 있습니다	멈추세요. 재설계하세요. 패치를 계속하지 마세요.
11	test 출력을 보여주는 대신 요약하는 것	가능한 hallucination 또는 선택적 읽기	실제 출력을 보여주세요
12	새 worktree에서 baseline test를 건너뛰는 것	알 수 없는 시작 상태	코드를 작성하기 전에 전체 test suite를 실행하세요

Anti-Pattern 요약

다음 anti-pattern들은 이 가이드의 모든 챕터에 걸쳐 나타납니다. 참고용으로 여기에 모았습니다.

Chapter 1에서: Foundation

도구 잘못된 설정: CLAUDE.md 또는 설정 문서를 읽지 않고 Superpowers를 사용하는 것. Skills는 올바르게 트리거되려면 적절한 설정이 필요합니다.
Skill 우회: 적절한 skill을 호출하지 않고 agent에게 "그냥 해줘"라고 요청하는 것. Skills는 이유가 있습니다; 우회하면 품질이 낮은 결과물이 나옵니다.

Chapter 2에서: Writing Plans

계획 없는 구현: 계획을 작성하고 검토하기 전에 코드 작성을 시작하는 것. 계획은 아키텍처 문제를 저렴하게 발견합니다; 코드는 그렇지 않습니다.
모호한 계획: 구체적인 단계 대신 결과로 계획을 작성하는 것. "인증 구현"은 계획이 아닙니다. 구체적인 행동의 번호가 매겨진 순서가 계획입니다.

Chapter 3에서: Executing Plans

독립 작업의 순차 실행: 병렬화할 수 있는 작업을 하나씩 실행하는 것. 이것은 불필요하게 실제 시간을 배가시킵니다.
병렬 작업 간 공유 상태: 같은 파일이나 상태를 수정하는 작업을 병렬로 실행하는 것. 이것은 merge conflict와 race condition을 만들어냅니다.

Chapter 4에서: TDD

구현 후 test 작성: 코드가 작성된 후 test를 작성하는 것. 이러한 test는 요구사항보다 구현 주변으로 형성될 가능성이 높습니다.
구현 세부 사항 테스트: 동작이 변경되지 않아도 코드가 리팩토링될 때마다 깨지는 test를 작성하는 것. 구현이 아닌 동작을 테스트하세요.

Chapter 5에서: Brainstorming

구현 전 Brainstorm 건너뛰기: 문제 공간을 탐색하지 않고 바로 코딩으로 가는 것. Brainstorm은 모든 창의적 작업 전에 필수입니다.
Brainstorm을 형식적 절차로 취급하기: 진정으로 대안을 탐색하지 않고 brainstorm 동작을 거치는 것. 가치는 의식이 아닌 탐색에 있습니다.

Chapter 6에서: Debugging

추측과 확인: 근본 원인 조사 없이 fix를 시도하는 것. 이것이 3번 실패 패턴의 주요 원인입니다.
여러 것을 동시에 Fix하기: 버그를 해결하기 위해 여러 변경을 하여 어느 변경이 효과가 있었는지 알 수 없게 만드는 것.
조기 완료 선언: 검증을 실행하기 전에 "fixed"라고 말하는 것.

Chapter 7에서: Code Review

형식적 동의: 평가 없이 review 피드백에 즉시 동의하는 것. 이것은 작동하는 코드에 잘못된 제안을 적용합니다.
심각도 수준 무시: 모든 피드백을 동일하게 긴급하게 취급하는 것. Critical 문제는 차단합니다; minor 문제는 기록됩니다.

Chapter 8에서: Git Worktrees

Main에 직접 Commit하기: merge 또는 PR 외에 main에 대한 모든 변경. Main은 항상 배포 가능한 상태입니다.
Baseline Test 없이 작업하기: 기본 branch의 모든 test가 통과하는지 먼저 확인하지 않고 기능 작업을 시작하는 것.

Enforcement

Iron Laws는 도구가 아닌 agent 동작에 의해 강제됩니다. 위반을 관찰했을 때 — agent에 의한 것이든 위반을 야기할 지시에 의한 것이든 — 올바른 응답은 위반되는 법을 명명하고 올바른 프로토콜로 돌아가는 것입니다.

이것은 방해가 아닙니다. 이것이 품질이 유지되는 방법입니다. Iron Law에 대한 모든 예외는 이 특정 경우가 그것을 정당화할 만큼 특별하다는 내기입니다. 그 내기는 거의 항상 틀립니다.