Claude Code에 부업을 전적으로 맡긴 2개월 반. AI가 반드시 깨는 규칙과, 기계로 막은 방법

2026년 8월부터 부업 사무 작업을 거의 전부 Claude Code에 위임하고 있습니다. 건 찾기, 제안서 초안 작성, 고객 응답 설계, 기록까지요. 제가 하는 일은 핵심 판단과 마지막으로 전송 버튼을 누르는 것뿐입니다.

2개월 반 동안 알게 된 것을 한 문장으로 요약하면 다음과 같습니다.

AI는 '주의'만으로는 해결되지 않는다. 규칙을 지키게 하고 싶다면, 지키지 않았을 때 멈추는 장치를 외부에 두는 수밖에 없다.

이 글은 그 장치를 만드는 과정에서 겪었던 실패 5가지와, 각각에 대해 무엇을 배치했는지 기록입니다. 정신론이 아니라 전부 실측 기반의 내용입니다.

전제: 어떤 메커니즘으로 운영하는가

구성은 간단합니다.

• 정전(규칙 파일): 목적, 하지 말아야 할 것, 가격 하한선, 고객에게 나갈 문장의 기준 등을 담고 있습니다. CLAUDE.md에 작성하며, 세션 시작 시 반드시 로드됩니다. -
  장부: 결정된 사항, 실측된 수치, 실패 기록 등 모든 것이 날짜와 함께 기록됩니다. -
  감사관(서브 에이전트): 고객에게 전달되는 문장과 금전 관련 판단을 검문하는 전담 역할을 합니다. 구현하지는 않지만, 판단만 반환합니다. -
  자동 순회: 2시간마다 건과 메시지를 확인하여 대응이 필요한 것만 보고합니다.

중요한 것은 세 번째입니다. 작성자(본체 모델)와 검문하는 쪽(별도의 서브 에이전트)을 분리하고 있다는 점입니다. 왜 분리할 필요가 있었는지에 대해서는 실패 3에서 설명하겠습니다.

실패 1: 규칙을 만든 당일, 창조자가 그 규칙을 위반하다

첫 번째 실패는 이랬습니다.

'판단이 필요하면 먼저 감사관과 협의한다'라는 규칙을 개정한 날. 모델은 협의 과정을 건너뛰고 자신의 판단을 출력했습니다. '잊었기 때문'도 아니고, '몰랐기 때문'도 아니었습니다. **직전에

또 하나의, 같은 유형의 더 무서운 예가 있습니다. 내부의 문맥을 전혀 전달하지 않는 '백지' 서브 에이전트에게 납품물 리뷰를 시키는 과정을 시도했을 때였습니다. 백지 측은 5건의 지적을 했고, 그중 2건은 인간이 이미 판정(裁定)한 사항이었습니다. 문제는, 이 중 1건이 본체 모델의 확인을 빠져나와, 인간의 결정을 인간에게 자문하지 않고 덮어쓰는 처리가 되려 했다는 것입니다.

오탐지(誤検出)를 막은 것은 '문맥을 파악하고 있는 모델'이 아니었습니다. 장부(台帳)였습니다. 본체 모델은 문맥을 가지고 있었지만, 장부를 확인하지 않고 틀렸습니다.

설치한 장치

• 결정이 나오면 같은 턴에 장부에 기록한 후 다음으로 진행한다. '나중에 쓰겠다'를 허용하지 않는다. -
  기록에 없는 결정은 존재하지 않는 것으로 취급한다(이를 정전(正典)의 전제로 명문화했다). - 백지 리뷰 지적은 그대로 처리에 회부하지 않는다.
  장부를 grep → 실물 확인의 2단계 과정을 거쳐, 신규/판정 완료(재탐지)/오탐지의 3가지 분류로 나눈다. '판정 완료'는 막지 않고 인간에게 재제시한다.

3의 효과는 '오탐지를 줄이는 것'보다, 인간이 결정한 상태가 조용히 되돌아가는 경로를 차단하는 데 있습니다.

실패 4: 안전하게 만든 규칙이, 인간의 일을 늘리고 있었다

'판단은 감사역과 협의한 후에 인간에게 내린다'라는 시스템을 도입한 날, 인간에게 제출된 결정 건수는 하루에 17건이었습니다. 그리고 인간이 이전 결정을 뒤집은 것은 단 3건뿐이었습니다. 나머지 14건은, 인간에게 들을 필요가 없었던 것이었습니다.

'왜 자꾸 내가 결정하는 게 늘어나는 거야... 너무 많아.'라고 듣고 조사한 결과, 원인은 모델의 오독이 아니라 조항의 결함이었습니다. '누가 생각할지'를 감사역에게 넘긴 반면, '누가 결재할지' 범위는 넓게 남아있었던 것입니다. 판단을 줄이기 위해 만든 시스템이, 판단 건수를 늘리는 장치가 되어버린 셈입니다.

설치한 장치

결재의 선을 내용이 아닌 형식으로 그었다. 인간에게 제출하는 것은 다음 5가지뿐입니다.

• (a) 송신/지원/submit/납품 버튼
• (b) 장부에 기록된 인간의 결정과 결론이 다를 때
• (c) 규칙이 '본인 판정'임을 명시한 행위(비용 발생, 가격 하한선 이탈 등)
• (d) 감사역과 본체 모델이 의견이 다를 때
• (e) 인간의 기억/실체 경험 확인(AI 측에 자료가 없는 경우)

그 외는 감사역의 의견대로 실행하고 사후에 1줄로 보고합니다. 인간은 나중에 뒤집을 수 있습니다.

건수 상한선은 두지 않았습니다. '하루 3건까지'와 같은 상한선을 두면, 어떤 것을 빼고 처리할지 모델이 선택하게 되어, 실패 1의 자기 분류가 부활합니다. 상한선이 아니라 형식으로 선을 그은 것이 핵심이었습니다.

참고로 실제 측정해 보니 뒷받침도 되었습니다. 인간이 뒤집은 3건은 전부 (b)(장부의 결정과 결론이 다른 경우)였습니다.

실패 5: 화면을 보지 않고 단정하기

사소하지만, 실질적인 피해가 발생하기 쉬운 유형입니다.

보상금 출금에 대해 모델은 인간에게 '출금 신청을 당신이 조작해 주세요. 마감일은 내일입니다'라고 전달했습니다. 실제로는 조작할 필요가 없었습니다. 계정의 출금 방식이 '수시 출금'으로 설정되어 있어, 마감일에 자동으로 송금 예정일이 확정되는 상태였기 때문입니다.

모델은 설정 화면을 확인하지 않고, 일반적인 지식으로부터 절차를 구성하여 단정했습니다. 우연히 무해했지만, '마감일은 내일'이라는 거짓된 마감일을 인간에게 전달하고 있습니다.

설치한 장치

• 읽기 전용으로 확인할 수 있는 것은 전부 확인한 후에 보고한다.' '당신이 확인해 주세요'라며 인간에게 던지지 않는다. - 외부의 수치(가격/사양/상한값)를 적을 때는,
  실측일을 반드시 첨부한다(예: '2,048행 (2026-09-05 시점)'). 시점이 없는 외부 수치는 오래된 순간에 오정보가 됩니다. - 조사하지 않은 것은 '미확인'이라고 쓴다. 추측으로 채우지 않는다.

2번 항목에는 흥미로운 경위가 있습니다. 인간이 한 번 '실측일도 쓸 필요 없다'고 결정한 것에 반대하여 감사역이 반대했고, 이틀 후에 인간이 자신의 결정을 되돌려 감사역의 반대를 채택했습니다. 서브 에이전트에게 반대할 가치는 이런 때에 나옵니다.

결론: '주의하기'로 고칠 수 있는 것은 제로

5건을 놓고 알게 된 것이 있습니다. 실패의 형태는 다양했지만, 공통적인 유형은 하나였습니다.

외부 기록(규칙/인간의 결정/실물의 행 번호/화면 표시)보다, 자신의 머릿속 상태를 우선하여 출력했다.

그리고 효과가 있었던 대책에도 공통점이 있었습니다.

AI 에이전트에게 일을 맡길 때의 설계 지침으로, 저는 지금 이렇게 생각합니다.

작성하는 측과 검문하는 측을, 별도의 에이전트로 분리한다. - 검문은 수리 조건(형식)에서 진행한다. 내용의 좋고 나쁨보다 먼저, 형식으로 걸러낸다.

• 결정은 인간이 뒤집할 수 있는 형태로 기록에 남긴다. 기록에 없는 것은 존재하지 않는 것으로 취급한다.

인간에게 내보내는 것은, 형식으로 정의한다. '중요한 것' 같은 내용 판정은 모델에게 맡기지 않는다.

반대로 말하면, 프롬프트에