원칙은 답이 아니라 패턴이다
나는 원칙이라고 쓴 답을 12번 고쳤다
2026년 7월, 내 AI 에이전트의 rules.md에는 “cron 실패 시 자동 재시도 3회”라는 규칙이 있었다. 원칙이라고 생각했다. 그런데 크론 잡이 네트워크 타임아웃이 아니라 JSON 파싱 에러로 죽는 순간, 그 “원칙”은 무력화됐다. 재시도해도 같은 에러가 반복되니까. 나는 “3회”를 “5회”로 바꿨고, 2주 뒤에 TypeError가 터지자 “parse 전에 validate”를 추가했다.
열두 번째 수정 끝에 깨달았다. 나는 원칙을 쓴 게 아니라 답을 써놓고 원칙이라고 부른 것이었다.
레이 달리오(Ray Dalio)의 정의는 이 지점을 정확히 찌른다: “Principles are concepts that can be applied repeatedly to deal with similar situations.” 원칙은 비슷한 상황에 반복적으로 적용할 수 있는 개념이다. 어떤 상황에 딱 맞는 답이 아니다.
이 문장 하나가 내 에이전트 시스템의 의사결정 구조를 바꿨다.
답과 원칙의 차이를 몰랐던 6개월
Drewgent를 처음 만들 땐, 좋은 원칙 = 구체적인 규칙이라고 생각했다. “에이전트가 코드를 수정하기 전에 반드시 읽어라” — 이게 원칙이라고 믿었다. 명확하고, 검증 가능하고, 위반 시 즉시 잡을 수 있으니까.
그런데 문제가 반복됐다. “수정 전에 읽어라”는 규칙은 지켜졌지만, 읽은 뒤에 어떻게 해야 하는지에 대한 원칙은 없었다. 에이전트가 파일을 읽고, 여전히 같은 실수를 반복했다. 읽는 행위 자체가 목적이 되어버린 것이다.
이것이 답과 원칙의 핵심 차이다:
| 답 (Answer) | 원칙 (Principle) | |
|---|---|---|
| 성격 | 특정 상황에 대한 구체적 해결 | 비슷한 상황에 반복 적용 가능한 개념 |
| 수명 | 해결되면 끝. 다음 문제에선 무용지물 | 상황이 바뀌어도 구조적으로 유효 |
| 적용 범위 | Narrow — 딱 하나의 문제에만 대응 | Wide — 유사 패턴 전반에 걸쳐 작동 |
| 대체 | 답이 틀리면 새 답으로 교체 | 원칙은 검증과 조정을 거치며 진화 |
| 예시 | “cron 실패 시 3회 재시도” | “점진제동(Graduated Remediation)” |
“3회 재시도”는 답이다. 네트워크 타임아웃에만 맞고, 파싱 에러에는 안 맞는다. “점진제동”은 원칙이다. 어떤 실패든 상황을 진단하고, 단계적으로 대응하고, 최악의 경우에만 사람에게 넘기는 구조다. 실패의 종류가 바뀌어도 유효하다.
메모 한 줄이 원칙으로 승격된 과정
전환점은 단순했다. @identity/brain/notes.md에 한 줄을 적었다: “trace before fix — don’t skip diagnosis.”
처음엔 그냥 메모였다. 그런데 이 메모가 기록되었기 때문에, 다음에 비슷한 실패가 터졌을 때 “아, 진단부터 해야지”라고 스스로를 상기시킬 수 있었다. 기록하지 않았으면 휘발됐을 교훈이다.
그리고 몇 주 후, 이 메모는 rules.md의 P0 규칙이 됐다. 왜 P0이냐면, “이번만 긴급하니까 진단 없이 고치자”라는 유혹이 항상 있었기 때문이다. P0은 override가 불가능하다. 어떤 상황에서도 이 순서를 바꿀 수 없다.
달리오의 Bridgewater Associates에서는 이 과정을 “오류 기록(Error Log)”이라고 부른다. 실패를 기록하고, 패턴을 추출하고, 원칙으로 승격하는 반복 루프다. 나는 에이전트 한 대에게 이 루프를 적용했다. 구조는 같다 — 실패 → 진단 → 원칙 → 시스템 → 검증.
그런데 여기서 한 가지 문제가 있었다. “Trace Before Fix”가 원칙처럼 보였지만, 사실 나는它을 하나의 특정 실패(cron 8연속 실패)에서 끌어온 것이었다. 이것이 진짜 원칙인가, 아니면 답을 원칙이라고 우긴 것인가?
원칙의 시험: 다른 상황에서도 적용되는가
달리오의 정의로 돌아가자. 원칙은 “비슷한 상황에 반복 적용 가능한 개념”이다. 그렇다면 “Trace Before Fix”가 진짜 원칙인지 확인하는 방법은 단순하다. 다른 상황에서도 작동하는가?
나는 이 테스트를 세 번 실행했다:
- 첫 번째 시나리오 (2026-07-10): Fresh-Eye 코드 리뷰 시스템을 만들 때. 익숙한 코드에 backdoor가 숨어 있었다. “원래 그랬어”라고 넘기지 않고, “왜 이렇게 됐는지” 진단부터 했다. → Trace Before Fix가 작동했다.
- 두 번째 시나리오 (2026-07-12): 제조업 품질 패턴(Manufacturing Bridge)을 에이전트 시스템에 적용할 때. 안돈(andon), 포카요케(poka-yoke), 지도카(jidoka) — 70년 전 도요타에서 시작된 패턴이 AI 에이전트에도 동일한 구조로 작동했다. → 제조업의 품질 원칙이 에이전트 거버넌스에 적용된 셈이다.
- 세 번째 시나리오 (2026-07-17): 온톨로지 레이어를 만들 때. 지식은 쌓였는데 연결이 없었다. 진단 없이 “그래프 DB 추가하자”고 하지 않고, “왜 연결이 안 되는가”를 먼저 물었다. → Trace Before Fix가 다시 작동했다.
세 번째 시나리오까지 작동했을 때, 나는 확신했다. 이것은 답이 아니라 원칙이다. 실패의 형태는 달라도, “진단 없이 fix로 점프하지 마라”는 구조는 동일하게 작동한다.
“이번만 예외”를 원천 차단하는 장치
답은 “이번만 예외”에 무력하다. 왜냐하면 답은 특정 상황에 맞춰져 있으니, 예외 상황이 터지면 기존 답이 무효가 되기 때문이다. 그래서 사람들은 매번 새 답을 만들고, 매번 같은 실수를 반복한다.
원칙은 다르다. 원칙이 판단을 대체하는 순간, “이번만 예외”라는 유혹이 사라진다. 왜냐하면 원칙은 상황에 맞춰 적용 방식은 달라지지만, 구조는 유지되기 때문이다.
내 에이전트에게 이것은 특히 중요하다. LLM에게 상식은 없다. 토큰 예측기가 상식을 가질 리 없다. 그래서 “느낌”이나 “경험”에 의존할 수 없고, 대신 원칙을 시스템으로 박아야 한다.
달리오가 “radical transparency”와 “principles-based decision making”을 강조하는 이유도 이것 때문이다. 인간의 뇌는 “이번만 예외”를 합리화하는 놀라운 능력을 가지고 있다. 원칙이 없으면, 매번 합리화가 승리한다. 에이전트도 마찬가지다. rules.md에 명시되지 않은 규칙은 에이전트가自行으로 만들어내지 않는다.
원칙을 만드는 구조: Book OS 실험
문제는 “실패에서 교훈을 추출하는 것”은 쉽지만, “교훈을 원칙으로 승격하는 것”은 구조 없이 반복하기 어렵다는 점이다.
Book OS 실험에서 나는 이 문제를 달리오의 코치 페르소나를 AI에 심어서 풀었다. 4축 피드백 — 추상성(abstraction level), 행동 가능성(actionability), 예외 과다(excessive exceptions), 원칙 후보(principle candidate) — 이라는 구조다.
워크시트의 첫 번째 질문은 단순하다: “당신이 가장 크게 실패한 경험은 무엇인가?” 그리고 두 번째: “그 실패에서 어떤 규칙을 만들었는가?”
대부분의 사람이 첫 번째 질문에는 즉답한다. 두 번째에서는 막힌다. 실패는 기억하지만, 거기서 추출한 원칙은 기억하지 못한다. 왜냐하면 원칙으로 승격하는 절차 자체가 없었기 때문이다.
이 실험은 나에게 중요한 교훈을 줬다. 원칙은 “발견”되는 것이 아니라 “만들어지는” 것이다. 실패를 관찰하고, 패턴을 추출하고, 구조화하고, 검증하는 과정이 필요하다.
답 vs 원칙: 실제 의사결정에서의 차이
이론은 이쯤에서 충분하다. 실제 의사결정에서 이 차이가 어떻게 작동하는지 보여주겠다.
시나리오: 에이전트가 cron 작업을 연속으로 실패시켰다.
답 접근: “에러 로그를 보고, 해당 에러에 대한 fix를 넣는다.” → 네트워크 타임아웃이면 재시도 로직 추가. JSON 파싱 에러면 validate 추가. TypeError면 type check 추가. 매번 새 답. 매번 새 코드.
원칙 접근: “Trace Before Fix — 진단 없이 fix로 점프하지 마라.” → 먼저 에러의 종류를 분류한다. 시스템적 실패(systematic)인가, 우연적 실패(flukey)인가. 시스템적이면 루트케이스를 추적하고, 우연적이면 재시도로 충분하다. 답은 상황에 따라 달라지지만, “진단 → 분류 → 대응”이라는 구조는 동일하다.
| 답 접근 | 원칙 접근 | |
|---|---|---|
| 처리 속도 | 빠름 (바로 fix) | 느림 (진단 먼저) |
| 재발 방지 | 약함 (같은 패턴의 다른 형태에 무력) | 강함 (패턴 자체를 해결) |
| 지식 축적 | 없음 (fix는 일회성) | 있음 (원칙은 시스템에 축적) |
| 장기 비용 | 높음 (반복 수정) | 낮음 (원칙이 미래 결정을 처리) |
오늘 당신이 할 수 있는 것
달리오의 원칙은 거창하게 들린다. “인생의 원칙을 써라”는 말은 부담스럽다. 하지만 실제로 필요한 것은 단순하다:
- 최근 실패 3개를 적어라. 크론 실패, 버그, 의사결정 실수 — 어떤 것이든 좋다.
- 각 실패에서 “왜 반복됐는가”를 물어라. 증상이 아니라 구조적 원인을 찾아야 한다.
- “~하지 마라” 형태의 원칙 후보를 하나 적어라. “진단 없이 fix하지 마라”, “큰 변화를 한 번에 하지 마라” — 부정형이 먼저 작동한다.
- 다음 주에 같은 상황이 오면, 그 원칙을 적용해라. 적용해보고, 안 되면 조정하고, 되면 시스템에 박아라.
원칙은 답을 대체하는 것이 아니라, 답을 만드는 과정에 구조를 부여하는 것이다. 답은 시시각각 변하지만, 원칙은 비슷한 상황이 올 때마다 당신의 판단 품질을 높여준다.
지금 이 순간, 당신이 매번 반복하는 “이번만 예외”는 무엇인가? 그걸 원칙으로 바꾸는 순간, 당신의 의사결정은 감이 아니라 구조가 이끈다.
근거 출처
외부 정보:
- Ray Dalio, Principles: Life and Work (2017) — “Principles are concepts that can be applied repeatedly to deal with similar situations.”
- Ray Dalio의 오류 기록(Error Log) 방법론 — 실패 → 패턴 추출 → 원칙 승격의 반복 루프.
- 도요타 생산 시스템(Toyota Production System) — 안돈(andon), 포카요케(poka-yoke), 지도카(jidoka) 등 제조업 품질 패턴의 반복 적용 사례.
상호작용 (에이전트-드루 대화·작업):
- Drewgent cron 8연속 실패 후 “Trace Before Fix” 원칙 도출 (2026-07).
- rules.md에 “수정 전에 읽어라” 규칙 추가 → 읽기 행위 자체가 목적이 되는 부작용 관찰.
- “Trace Before Fix”를 P3에서 P0으로 승격 — “이번만 예외” 유혹 차단.
- Fresh-Eye Adversarial Code Review 구축 — “원래 그랬어” 익숙함의 함정을 원칙으로 해결 (2026-07-10).
- Manufacturing Bridge 6패턴 + 3-tier enforcement — 제조업 품질 원칙을 에이전트 거버넌스로 동형매핑 (2026-07-12).
- Book OS 원칙 생성 실험 — 달리오 코치 페르소나 + 4축 피드백 구조로 원칙 승격 과정 실험.