AI 도구를 더 붙이기 전에, 나는 원칙부터 다시 썼다
AI 도구를 더 붙여도 판단이 좋아지지 않았던 이유
나는 한동안 의사결정이 막힐 때마다 도구를 추가했다. 검색이 느리면 검색 도구를 붙이고, 기억이 끊기면 메모리 레이어를 만들고, 실행이 늦으면 자동화를 늘렸다. 그런데 이상하게도 도구가 늘어날수록 결정은 빨라지지 않았다. 무엇을 원하는지, 지금 실제로 무슨 일이 일어났는지, 그래서 무엇을 해야 하는지가 여전히 흐렸기 때문이다.
문제는 실행력이 아니었다. 판단의 앞단에 원칙이 없었다. 원칙이 없으면 새 도구도 새 정보도 결국 그때그때의 기분과 급한 일에 끌려간다. 나는 Ray Dalio의 Principles를 읽으며 이 문제를 다시 정의했다. 원칙은 멋진 문장이 아니라, 반복되는 상황에서 판단의 질을 일정하게 유지하는 재사용 가능한 기준이었다.
1부. 원칙은 답안지가 아니라 판단의 커널이다
외부 정보(하베스터 수집): 책에서 가져온 원칙의 정의와 가치·원칙의 구분이다.
책에서 가장 먼저 가져온 구분은 간단했다. 가치는 무엇이 중요한지 말하고, 원칙은 그 가치를 일관되게 살기 위한 방법을 정한다. “이번 장애는 재시도 세 번으로 해결한다”는 특정 상황의 답이다. “수정 전에 실패를 분류하고 원인을 추적한다”는 비슷한 문제에 반복 적용할 수 있는 원칙이다.
이 차이를 모르면 실패할 때마다 새 답을 만든다. 네트워크 오류에는 재시도를 넣고, 파싱 오류에는 검증을 넣고, 타입 오류에는 타입 체크를 넣는다. 당장은 고쳐지는 것 같지만, 시스템에는 교훈이 쌓이지 않는다. 다음 실패가 오면 다시 처음부터 생각해야 한다.
상호작용(에이전트-드루 대화·작업): 이 구분을 Drewgent의 규칙 설계에 적용하며 확인한 경험이다.
내 작업에서도 같은 일이 있었다. 에이전트에게 “수정하기 전에 파일을 읽어라”라고 규칙을 추가했지만, 읽은 뒤에도 같은 실수가 반복됐다. 읽는 행위가 목적이 되었기 때문이다. 이후 나는 규칙을 “진단 없이 fix로 점프하지 마라”로 좁히고, 실패의 종류와 영향 범위를 먼저 확인하는 구조로 바꿨다. 한 번의 답이 아니라 여러 실패에 적용할 수 있는 판단 순서를 만든 것이다.
그래서 원칙의 가치는 개수에 있지 않다. 원칙이 많아도 서로 충돌하거나 적용 시점을 모르면 장식에 불과하다. 반대로 중요한 판단 몇 개가 명확하면, 도구와 프로세스는 그 아래에 배치할 수 있다. 나는 개인 OS에서 이 층을 P0 규칙 레이어로 두었다. 원칙은 에이전트가 마음대로 바꾸는 설정이 아니라, 사람이 승인해야 바뀌는 커널이다.
2부. 원칙을 세우기 전에 반드시 물어야 할 세 가지
Dalio가 제시하는 사고의 출발점은 거창한 자기계발 문장이 아니었다. 생각하기를 원한다면 먼저 세 가지를 분리해야 한다.
- 무엇을 원하는가? 목표를 모른 채 문제를 풀면, 바쁘게 움직여도 엉뚱한 곳에 도착한다.
- 무엇이 사실인가? 원하는 모습과 관찰된 현실을 섞지 않는다. 실패 기록과 측정값을 불편하더라도 본다.
- 그 사실을 바탕으로 무엇을 할 것인가? 목표와 현실의 간격을 줄이는 설계를 고르고 실행한다.
나는 이 세 질문을 더 긴 5단계로 운영한다. 목표 설정 → 문제 식별 → 진단 → 설계 → 실행이다. 중요한 건 순서다. 목표를 정하기 전에 도구를 고르지 않고, 진단하기 전에 해결책을 코딩하지 않는다. 설계가 실행에 앞서야 실행할 일이 보인다.
이 원칙이 실제로 유용했던 사례가 있다. 개인 OS를 만들 때 처음에는 여러 에이전트를 더 붙이고 싶었다. 하지만 먼저 흩어짐 지도를 그렸다. 병목은 “자동화 부족”이 아니라 기록과 교훈이 연결되지 않는 것이었고, 반복되는 본성 패턴은 불편한 실패 기록을 미루는 것이었다. 그 진단 뒤에야 정제 파이프라인과 P-LAYER 설계가 나왔다. 비병목을 자동화하는 대신, 결정에 영향을 주는 연결부터 만들었다.
이때 원칙은 다른 사람의 문장을 복사하는 것으로 끝나지 않았다. 책의 원칙은 출발점이고, 내 환경에서 스트레스 테스트를 거쳐야 했다. “설계가 실행에 앞선다”는 문장을 실제 작업 순서에 넣어보고, “원칙은 사람이 승인한다”는 규칙을 P0 게이트로 구현했다. 그 과정을 통과한 문장만 내 원칙이 됐다.
3부. 인생 원칙은 매니지먼트 원칙으로 내려와야 한다
Principles의 세 번째 축은 매니지먼트다. 나는 이 부분을 “남을 관리하는 기술”로 읽지 않았다. 목표를 이루는 머신을 설계하고 운영하는 방식으로 읽었다. 사람, 에이전트, 문서, 자동화는 모두 시스템의 부품이고, 관리자는 부품을 탓하기 전에 배치와 인터페이스를 점검해야 한다.
예를 들어 “정직하게 일하자”는 인생 원칙만으로는 부족하다. 매니지먼트 원칙으로 번역하면 이렇게 바뀐다. 실패를 숨기지 않도록 로그를 남긴다. 초안과 검증 결과를 분리한다. 에이전트가 제안한 원칙은 사람이 승인하기 전까지 운영 규칙이 되지 않게 한다. 말로 다짐하는 대신, 실패가 드러나고 수정이 멈추지 않는 구조를 만든다.
내가 운영 중인 구조에도 이 번역이 들어가 있다.
- P0: 시스템을 움직이는 원칙과 승인 게이트. 사람이 검토하지 않은 규칙은 커널에 들어오지 않는다.
- P6: 실패 뒤의 사고 기록. “이번 주 통증 + 그 통증에서 얻은 교훈”을 남겨 경험을 다음 판단의 재료로 만든다.
- 정제 파이프라인: 관찰 → 교훈 → 검색. 메모를 쌓아두는 데서 멈추지 않고 반복 패턴을 찾아 원칙 후보로 올린다.
- 검증: 원칙이 다른 상황에서도 작동하는지 확인한다. 한 번 맞았다는 이유로 영구 규칙으로 만들지 않는다.
이 구조는 원칙을 숭배하지 않게 해준다. 원칙도 현실과 부딪히면 수정해야 한다. 다만 수정은 기분이나 유행이 아니라, 새로운 사실과 반복된 결과를 근거로 해야 한다. 이것이 내가 이해한 radical truth다. 나에게 듣기 좋은 이야기를 지키는 것이 아니라, 목표 달성을 방해하는 사실을 먼저 보게 만드는 운영 방식이다.
원칙을 오늘의 결정으로 바꾸는 15분 루틴
원칙은 노트에 적는 순간 완성되지 않는다. 다음 결정에서 사용되어야 한다. 나는 다음 네 문장으로 원칙 후보를 만든다.
- 반복되는 불편은 무엇인가? 최근 실패나 미뤄지는 일을 하나만 고른다.
- 내가 원하는 결과와 실제 사실은 무엇인가? 희망, 해석, 관찰을 분리해 적는다.
- 다음번에도 적용할 판단 문장은 무엇인가? 특정 도구나 숫자보다 상황의 패턴을 쓴다.
- 어디에 강제할 것인가? 체크리스트, 파일, 승인 단계, 알림 중 하나로 옮긴다.
예를 들어 “이번 주에도 작업이 밀렸다”에서 멈추면 회고가 아니다. “목표가 불명확한 상태에서 도구부터 추가했고, 실제 병목을 측정하지 않았다”까지 내려가야 한다. 그다음 “진단 전에는 빌드하지 않는다”를 원칙 후보로 만들고, 다음 작업의 시작 조건에 진단 문서를 넣는다. 원칙이 행동의 앞단에 들어갈 때 비로소 판단 품질이 달라진다.
나는 성공을 의지력의 결과로 보지 않게 됐다. 반복 가능한 원칙을 만들고, 그 원칙을 시스템에 넣고, 실제 결과를 다시 관찰한 결과다. 책에서 말하는 “고통 + 성찰 = 진전”은 내 작업에서는 “실패 기록 + 원칙 후보 + 다음 적용”이라는 작은 루프로 나타났다.
원칙을 하나만 고른다면
오늘 하나만 가져간다면 이것이면 충분하다.
진단 없이 실행하지 않는다.
목표를 확인하고, 사실을 분리하고, 원인을 진단한 뒤에 설계하고 실행한다.
이 문장은 느려 보인다. 실제로 첫 단계에서는 느려진다. 하지만 매번 같은 문제를 다시 고치는 비용을 줄이고, 새 도구를 붙이기 전에 정말 필요한 변화가 무엇인지 보여준다. 원칙의 목적은 결정을 대신하는 것이 아니다. 결정을 만드는 과정을 덜 흔들리게 하는 것이다.
최근 반복되는 실패 하나를 골라 15분만 기록해보자. 무엇을 원했는지, 무엇이 사실이었는지, 다음번에는 어떤 문장을 지킬지 적는다. 그리고 그 문장을 다음 작업의 체크리스트나 승인 단계에 넣는다. 원칙을 읽는 데서 끝내지 말고, 오늘의 시스템에 한 줄로 설치해보자. 그 한 줄이 다음 결정을 바꿀 수 있다.
근거 출처
외부 정보(하베스터 수집):
- Ray Dalio, Principles: Life and Work — 원칙의 정의, 원칙의 중요성, 핵심 인생 원칙, 매니지먼트 원칙, 목표→문제→진단→설계→실행의 5단계, Pain + Reflection = Progress 개념.
- 위 책의 핵심 프레임을 정리한 2026-08-16 큐레이션 메모 — “무엇을 원하는가 → 무엇이 사실인가 → 무엇을 할 것인가” 사고 순서와 약 200개 원칙으로 다양한 문제를 다루는 구조.
상호작용(에이전트-드루 대화·작업):
- 개인 OS 설계 문서에서 Dalio의 결정·원칙 축을 P0 규칙 레이어와 P6 사고 기록으로 번역한 작업.
- 흩어짐 지도에서 병목과 반복되는 본성 패턴을 먼저 진단한 뒤, P-LAYER 설계도와 정제 파이프라인을 만든 작업.
- 에이전트가 원칙을 제안할 수는 있지만 P0 규칙은 사람이 승인해야 한다는 게이트를 세운 결정.
- 실패 기록을 다음 원칙 후보로 승격하고, 다른 상황에서도 작동하는지 검증하는 Drewgent 운영 경험.