가치만으로는 충분하지 않다 — 원칙이 있어야 가치가 행동이 된다
나는 매번 같은 실수를 반복하면서 “이번엔 다를 거야”라고 믿었다
2026년 7월, 내 AI 에이전트가 cron 작업을 여덟 번 연속으로 실패시켰다. 나는 매번 다른 에러 메시지를 보고 매번 다른 fix를 넣었다. NameError → fix. import 실패 → fix. TypeError → fix. 매번 “이번엔 됐다”고 생각했고, 매번 30분 후에 다시 터졌다.
문제는 fix가 틀려서가 아니었다. 진단을 건너뛰고 fix로 점프하는 행위 자체가, 내가 “빠르게 해결하는 사람”이라는 내 가설과 충돌하고 있었기 때문이다. 나는 속도를 중요시한다고 생각했다. 그래서 증상이 보이면 바로 손을 댔다. 그런데 그 속도가 오히려 여덟 번의 실패를 만들어냈다.
레이 달리오의 말이 정확히 이 지점을 찌른다: “Your values are what you consider important. Principles are what allow you to live a life consistent with those values.”
가치는 “빠른 해결”이었다. 그런데 그것을 일관되게 실천하는 원칙은 없었다. 그래서 나는 매번 본능에 의존했고, 본능은 매번 같은 실패로 귀결됐다.
가치와 원칙의 차이를 몰랐던 나
한동안 나는 “가치”와 “원칙”을 같은 단어로 쓰고 있었다. “나는 품질을 중시해”라고 말하면서, 실제로는 “일단 빨리 동작하게 만들어”라는 행동을 반복했다. 이것이 얼마나 모순적이었는지 깨닫는 데 몇 달이 걸렸다.
달리오의 정의를 빌리자면:
- 가치(Values) = 당신이 중요하게 여기는 것. “품질”, “속도”, “자율성”, “정직” 같은 것들.
- 원칙(Principles) = 그 가치를 삶에서 일관되게 구현하는 방법. 구체적 행동 지침.
가치만 있으면 “좋은 사람”일 수는 있다. 하지만 “일관된 사람”은 될 수 없다. 왜냐하면 매 순간 본능과 감정이 원칙을 대체하기 때문이다. 피곤할 때, 압박이 올 때, “이번만 예외”라고 느낄 때 — 원칙이 없으면 가치는 무력화된다.
내 에이전트도 마찬가지였다. rules.md에는 “빅뱅 리팩토링 금지”, “수정 전에 읽어라” 같은 규칙은 있었다. 하지만 “고장 났을 때 어떻게 접근할 것인가”에 대한 원칙은 없었다. 그래서 에이전트도 본능에 의존했다 — 증상이 보이면 바로 fix. 인간과 기계가 같은 병에 걸려 있었다.
메모 한 줄이 원칙이 된 과정
전환점은 단순했다. @identity/brain/notes.md에 한 줄을 적었다: “trace before fix — don’t skip diagnosis”
이게 전부였다. 특별한 프레임워크도, 대단한 방법론도 아니었다. 그냥 메모. 그런데 이 메모가 기록되었기 때문에, 다음에 같은 실수를 반복하지 않을 수 있었다. 기록하지 않았으면 휘발됐을 교훈이다.
그리고 몇 주 후, 이 교훈을 rules.md로 옮겼다. 처음엔 P3(하위 규칙)에 뒀다. 그런데 “긴급 수정”이라는 이름으로 진단을 건너뛰고 싶은 유혹이 항상 있었다. 그래서 P0으로 올렸다. P0은 override가 불가능하다. 어떤 긴급 상황에서도 이 순서를 바꿀 수 없다.
이것이 달리오가 말하는 “원칙을 만드는 과정”과 정확히 일치한다:
| 단계 | 달리오 | 나의 경험 |
|---|---|---|
| 실패 | 가치와 행동의 불일치를 인식 | 8연속 cron 실패 |
| 진단 | “왜 이런 일이 반복되는가” | 행동 사슬 추적 → 증상과 원인 분리 |
| 원칙 도출 | “다음엔 이렇게 하겠다” | “Trace before fix” P0 규칙 |
| 시스템화 | 원칙을 의사결정 프레임워크에 박기 | AGENTS.md + 5단계 진단 방법론 |
| 검증 | 같은 실수 재발 여부 확인 | 24시간 정상 동작 + 재발 모니터링 |
달리오의 Bridgewater Associates는 이 과정을 수백 명에게 적용했다. 나는 에이전트 한 대에게 적용했다. 구조는 같다. 실패 → 진단 → 원칙 → 시스템 → 검증.
원칙이 없는 시스템은 감에 의존한다
Trace Before Fix를 P0에 넣기 전, 내 의사결정은 “이 상황에서 보통 이렇게 하지”라는 감에 기반했다. 감은 보통 맞는다. 하지만 “보통”이 문제다. 감이 틀리는 순간 — 피곤할 때, 복잡할 때, 시간이 촉박할 때 — 시스템은 무너진다.
Book OS 실험에서도 같은 패턴이 나타났다. 원칙 생성 실험(#001)을 설계하면서, 나는 달리오의 코치 페르소나를 AI에 심었다. 4축 피드백 — 추상성, 행동 가능성, 예외 과다, 원칙 후보 — 이라는 구조다. 왜 구조가 필요했느냐면, 사람은 실패에서 교훈을 얻을 수 있지만, 교훈을 원칙으로 승격하는 과정은 구조 없이 반복되기 어렵기 때문이다.
워크시트의 첫 번째 질문은 단순하다: “당신이 가장 크게 실패한 경험은 무엇인가?” 그리고 두 번째 질문: “그 실패에서 당신은 어떤 규칙을 만들었는가?”.
대부분의 사람이 첫 번째 질문에는 즉답한다. 두 번째에서는 막힌다. 실패는 기억하지만, 거기서 추출한 원칙은 기억하지 못한다. 왜냐하면 원칙으로 승격하는 절차 자체가 없었기 때문이다.
원칙은 “이번만 예외”를 원천 차단한다
Trace Before Fix가 P3에 있었을 때, 나는 “이건 긴급하니까 진단 없이 고치자”라고 매번 스스로를 설득했다. 그리고 매번 같은 실패가 돌아왔다. P0으로 올린 순간, 그 유혹이 사라졌다. 원칙이 판단을 대체한 것이다.
이게 달리오가 “radical transparency”와 “principles-based decision making”을 강조하는 이유다. 인간의 뇌는 “이번만 예외”를 합리화하는 데 놀라운 능력을 가지고 있다. 원칙이 없으면, 매번 합리화가 승리한다.
내 에이전트도 마찬가지다. rules.md에 명시되지 않은 규칙은 에이전트가自行으로 만들지 않는다. “진단 없이 고치지 마라”가 코드로 박히기 전까지, 에이전트는 매번 증상에 반응했다. 원칙은 본능을 시스템으로 대체하는 장치다.
오늘 당신이 할 수 있는 것
달리오의 원칙은 거창하게 들린다. “인생의 원칙을 써라”는 말은 부담스럽다. 하지만 실제로 필요한 것은 단순하다:
- 지금 이 순간, 당신이 “이번만 예외”라고 생각하는 것이 무엇인지 적어보라. 그것은 아마도 원칙이 없는 영역일 것이다.
- 그 예외가 왜 반복되는지 한 문장으로 진단하라. “왜 나는 이걸 매번 미루는가?”, “왜 매번 같은 실수를 하는가?”
- 그 진단을 원칙 한 줄로 만들어라. 길 필요 없다. “trace before fix”처럼 짧으면 된다.
- 그 원칙을 어길 수 없는 곳에 박아라. rules.md, AGENTS.md, 아니면 그냥 메모 앱에 고정 Pins. 중요한 건 “어디에”가 아니라 “어길 수 없는가”다.
가치는 “무엇을 중요하게 여기는가”를 말해준다. 하지만 원칙은 “어떻게 행동할 것인가”를 정한다. 가치만으로는 충분하지 않다. 원칙이 있어야 가치가 행동이 된다.
지금 이 순간, 당신의 “이번만 예외”는 무엇인가?
근거 출처
외부 정보:
- 레이 달리오, Principles: Life and Work (2017) — “Your values are what you consider important. Principles are what allow you to live a life consistent with those values.” 원문 인용.
- 레이 달리오, Bridgewater Associates의 “radical transparency” 원칙 — 의사결정에 원칙을 구조적으로 적용하는 사례.
상호작용 (에이전트-드루 대화·작업):
- 2026년 7월 cron 작업 8연속 실패 — “Trace Before Fix” 규칙 탄생 배경. rules.md P0 등록, AGENTS.md 5단계 진단 방법론 추가.
- Book OS MVE 실험(#001) — 달리오 코치 페르소나를 활용한 원칙 생성 워크시트 설계. 실패 경험 → 원칙 도출 경로의 실험적 검증. (
P6-prefrontal/plans/2026-08-06_book-os-mve.md) @identity/brain/notes.md→rules.md→AGENTS.md— 메모에서 원칙으로, 원칙에서 시스템으로의 승격 과정. (published/when-memo-becomes-rule-trace-before-fix.html,published/systemic-diagnosis-methodology-build-log.html)