고백 하나로 시작하겠습니다. 요즘 가장 강력하다는 클로드 Fable 5에게 일을 맡겨 두면, 결과물이 어찌나 매끄러운지 저도 모르게 “음, 이번에도 잘했겠지” 하고 검토를 건너뛸 뻔한 순간이 자주 찾아옵니다. 바로 그 지점에서 건진 게 이 글의 결론입니다. 모델이 강력해질수록, AI에게 자기 답을 스스로 채점하게 두면 안 됩니다.
지난 글에서 저는 제 AI 하네스를 ‘강제’에서 ‘배려’로 바꾸고 있다고 고백했습니다. 혹시 ‘배려’라는 말을 검증을 슬그머니 느슨하게 푼 거라고 오해하실까 봐 곧장 정정합니다. 배려하는 하네스로 옮겨오면서 검증은 오히려 더 깐깐해졌습니다. 단, 깐깐함의 방향이 ‘AI를 가두는’ 쪽에서 ‘사람이 속지 않게 하는’ 쪽으로 통째로 뒤집혔을 뿐입니다.
이 깨달음은 클로드 Fable 5를 며칠 집중해서 쓰며 또렷해졌습니다. Fable 5는 6월 9일 공개된 Anthropic의 가장 강력한 모델로, 공개 자료 기준 코딩 벤치마크 SWE-Bench Pro에서 80%를 넘기며 다른 최상위 모델들을 큰 폭으로 앞섰다고 합니다. 길고 복잡한 작업을 사람 개입 없이 멀리까지 끌고 가고, 작업이 길수록 다른 모델과의 격차가 더 벌어지는 게 강점이죠. 빠르고 싼 모델이 아니라 정반대입니다.
그런데 바로 그 강력함이 함정이었습니다. 강력한 모델일수록 자신감 있게 대량의 작업을 멀리까지 밀고 나갑니다. 그럴수록 사람은 매끄러운 결과물 앞에서 검토의 끈을 슬며시 놓습니다. 모델이 똑똑해질수록, 결과물의 질을 가르는 건 모델 자체가 아니라 사람이 검토를 포기하지 않게 만드는 설계가 되더군요.
그래서 이 글은 1편이 일부러 남겨둔 숙제 — “그래서 배려하는 하네스는 구체적으로 어떻게 동작하느냐” — 를 이번엔 감정이 아니라 코드 레벨로 풀어 보려 합니다. 앞 이야기가 궁금하시면 기계를 길들이던 엔지니어, 사람에게 데이다부터 읽고 오셔도 좋습니다.
목차
- 강력한 모델일수록 “그럴듯한데?”가 더 위험합니다
- AI가 자기 답을 자기가 채점하게 두지 마세요 — 파인만 검증 게이트
- ‘배려’는 느슨함이 아니라 방향입니다 — 막던 걸 ‘안내’로
- 모든 작업에 같은 힘을 쏟지 않습니다 — 발산엔 세게, 루틴엔 가볍게
- 결국 핵심은 모델이 아니라, 사람을 루프에 남기는 설계입니다
1. 강력한 모델일수록 “그럴듯한데?”가 더 위험합니다
약한 모델과 일할 때는, 사실 검토가 쉬웠습니다. 결과물이 엉성하니까요. 어딘가 빠뜨리거나 헛다리를 짚으면 티가 났고, 사람은 자연스럽게 의심하며 들여다봤습니다. 모델의 부족함이 역설적으로 사람의 검토를 깨워둔 셈입니다.
강력한 모델은 이 안전장치를 꺼버립니다. Fable 5처럼 길고 복잡한 작업을 끝까지 자신감 있게 밀고 나가는 모델은, 열에 아홉이 정말로 훌륭합니다. 문제는 나머지 하나입니다. 아홉 번 매끄러웠던 산출물에 익숙해진 사람은, 열 번째의 그럴듯한 오답 앞에서도 별 의심 없이 스크롤을 내립니다. 틀린 것이 그럴듯한 모습으로 통과하는 순간이죠.
이건 새로운 함정이 아니라, 아주 오래된 함정입니다. 리처드 파인만이 1974년 칼텍 졸업식에서 했던 그 유명한 말이 정확히 이걸 가리킵니다.
“무엇보다 스스로를 속여선 안 됩니다. 그리고 당신 자신이야말로 가장 속이기 쉬운 사람입니다.”
AI 시대로 옮겨 적으면 이렇게 됩니다. AI가 만든 결과물을 그 AI에게(혹은 그걸 그대로 받아 든 나 자신에게) 채점하게 두면, 우리는 가장 속이기 쉬운 채점자에게 채점을 맡기는 것이다. 모델이 강력할수록 그 답은 더 그럴듯해지고, 그럴듯할수록 자기 검열은 더 헐거워집니다.
그래서 제 하네스의 최근 작업들은, 결국 한 문장으로 수렴했습니다. 똑똑한 AI일수록, 자기 채점은 맡기지 않는다.
2. AI가 자기 답을 자기가 채점하게 두지 마세요 — 파인만 검증 게이트
처음엔 이걸 위해 ‘feynman 스킬’을 새로 만들려고 했습니다. 그런데 막상
하네스를 뒤져 보니, 이미 그 용도의 도구가 들어가 있더군요. 지난 며칠 제가
한 일은 새로 만드는 게 아니라, 흩어져 있던 그 배선(wiring)을 마무리하는
일이었습니다. 핵심은 /feynman 커맨드 하나입니다.
작동 방식은 이렇습니다. PR이나 설계 변경을 올리기 직전, 두 종류의 에이전트가 따로 등장합니다.
- 적대적 red-team 에이전트는 제가 왜 그렇게 짰는지에 대한 서사에 일부러 접근하지 못합니다. 변경된 diff와 계획서만 보고, “이게 틀렸다면 어디서 틀렸을까”를 캐묻는 질문을 만듭니다. 그것도 추상적인 질문이 아니라, “이런 구체적 상황에서, 그때 시스템은 어떻게 동작하나요?” 라는 상황-예측 형태로요. 이 red-team이 바로 파인만이 말한 ‘학생’입니다.
- 제가 그 질문에 자유서술로 예측을 적으면, 이번엔 별도의 judge 에이전트가 등판합니다. judge는 제 답을 곧이곧대로 믿지 않습니다. 실제 코드와 문서를 직접 grep하고 테스트를 돌려, 제 예측이 사실과 맞는지를 직접 확인(grounding)합니다. 그리고 일치 / 모순 / 모호 / “모름을 인정” 중 하나로 판정합니다.
대략 이런 식의 대화가 오갑니다.
[red-team] 상황: 사용자가 이미 종료된 작업에 다시 완료 신호를 보내면,
큐는 그 작업을 어떻게 처리하나요?
[나] 종료 상태는 흡수 상태라 그냥 무시될 거라고 예상합니다.
[judge] 코드 확인 → 해당 분기에 가드가 없음. 예측과 모순.
→ 여기가 당신 이해의 빈틈입니다.
이 설계의 묘미는 두 가지입니다. 첫째, 말로만 그럴듯한 답은 통과하지 못합니다. judge가 코드를 직접 들춰 보기 때문에, 매끄러운 문장으로 얼버무릴 수가 없습니다. 둘째, 코드에 답이 그대로 적혀 있어서 베껴 낼 수 있는 질문은 아예 버려집니다. 그건 이해를 검증하는 게 아니라 받아쓰기를 시키는 거니까요.
핵심 통찰은 이겁니다. 같은 글을 쓴 본인이 채점하면, 사람은 반드시 관대해진다. 자기 답안지를 자기가 빨간 펜으로 채점하는데 점수가 후해지지 않을 도리가 없죠. 그래서 이 도구는 채점자를 굳이 따로 띄웁니다. 내가 나를 설득하는 게 아니라, 맥락이라곤 하나도 없는 제3자가 — 그것도 코드를 직접 grep까지 해서 — 검증하게 만든 거죠. 1번에서 말한 ‘가장 속이기 쉬운 채점자’를 구조적으로 갈아치우는 장치입니다.
짝꿍이 하나 더 있습니다. /readability-check는 결이 정반대입니다.
/feynman이 “내가 이걸 진짜 이해했나”를 본다면(설명하다 막히는 곳이 곧
이해의 빈틈), /readability-check는 “이 글을 남이 이해하나”를 봅니다.
표준 교육을 받은 비전문가의 눈으로 PR과 이슈 초안을 읽혀, 막히는 문장을
평이하게 다시 쓰게 합니다. 파인만 기법의 두 축 — 내 이해와 남의 이해 — 을
각각 한 도구씩 맡긴 셈입니다.
참고로 이 게이트는 지금 통과를 강제하지 않습니다. 안 했으면 “안 했네요” 하고 안내만 할 뿐, 작업을 막아 세우지는 않습니다. 왜 굳이 막지 않는지가 다음 이야기입니다.
3. ‘배려’는 느슨함이 아니라 방향입니다 — 막던 걸 ‘안내’로
지난 글에서 말한 ‘배려’의 정체가 바로 여기 있습니다. 결론부터 말하면, 저는 게이트들을 ‘차단’에서 ‘안내’로 바꾸고 있습니다.
예전의 제 하네스는 검사에 걸리면 그 자리에서 작업을 막아 세웠습니다. PR 본문에 정해진 섹션이 없으면 차단, 워크트리를 함부로 만들려 하면 차단. 규칙으로 AI를 가두는 구조였죠. 지난 며칠 한 작업의 상당수는, 그 차단들을 풀어 ‘안내’와 ‘확인’으로 바꾸는 일이었습니다.
| 강제 시대 (Before) | 배려 시대 (After) | |
|---|---|---|
| 검사 실패 시 | 작업을 막아 세움(deny) | 안내·확인(ask), 최종 판단은 사람 |
| 결과물 제시 | 완성본을 한 번에 토해냄 | 검토 가능한 중간 산출물부터 |
| 질문 방식 | 질문 없이 직행 | 한 턴에 1~2개씩 면담 |
| 어조 | 금지형 (“이렇게 하지 마”) | 긍정형 (“이 방향으로 가자”) |
PR 본문 검사는 차단에서 안내로 풀었고, 워크트리 자동 생성은 자동 차단에서 사용자 확인으로 낮췄습니다. 가독성 게이트도, QA 게이트도 같은 기조입니다. 사람을 막아 세우는 대신, 판단을 사람에게 돌려주는 방향이죠.
언뜻 모순처럼 들립니다. 2번에서는 검증을 더 깐깐하게 한다더니, 여기서는 막던 걸 푼다니요. 하지만 둘은 한 몸입니다. 막는 것의 목적은 ‘AI를 통제하는 것’이고, 안내하는 것의 목적은 ‘사람을 루프 안에 남겨 두는 것’입니다. AI를 강하게 막을수록 사람은 그 벽을 믿고 검토에서 손을 뗍니다. 반대로 벽을 낮추고 “여기 한번 보세요” 하고 판단을 돌려주면, 사람이 다시 루프 안으로 들어옵니다.
면담형 스킬들의 대화 원칙이 정확히 이 철학입니다. “직행을 한 박자 멈춘다”, “한 턴에 한두 개만 묻는다(질문 열 개를 쏟으면 회의보다 피곤하니까)”, “이미 말한 건 다시 묻지 않는다”. 대뜸 완성된 결과를 내밀고 맥락도 모르는 채 검토하라고 하면, 사람은 결국 리뷰를 포기합니다. 면담형 스킬의 진짜 목적은 그럴듯한 계획서를 뽑는 게 아니라, 사람이 끝까지 손을 떼지 않게 만드는 데 있습니다.
이건 사실 제 레포의 프롬프팅 가이드라인(“금지형 지시 대신 긍정형으로”)과도 한 몸입니다. AI에게도, 사람에게도, 막아 세우는 것보다 원하는 방향을 보여 주는 쪽이 결과가 좋더군요.
4. 모든 작업에 같은 힘을 쏟지 않습니다 — 발산엔 세게, 루틴엔 가볍게
여기까지 오니 자연스럽게 따라오는 질문이 있습니다. 그렇게 매번 면담하고 검증하면 너무 무겁지 않냐는 거죠. 맞습니다. 그래서 모든 작업에 같은 힘을 쏟지 않는 것이 그다음 원칙입니다.
힘을 잘못 배분하면 양쪽 모두에서 손해를 봅니다. 정답이 없어 발산이 필요한 기획에 힘을 아끼면 빈약한 결과가 나오고, 단순한 핸드오버 문서 한 장에 힘을 잔뜩 실으면 시간만 날아갑니다. 저도 이 둘을 거꾸로 했다가 다시 한 적이 적지 않습니다. 그래서 일을 시작하기 전에 먼저 묻습니다. “이건 발산인가, 실행인가, 루틴인가?”
| 작업 성격 | 들여야 할 힘(effort) |
|---|---|
| 새 기획·아이디에이션 (정답이 없고 발산이 필요) | 높음 |
| 이미 구체적으로 나온 계획을 실행 | 중간~높음 |
| 핸드오버 프롬프트 작성 같은 루틴 | 낮음 |
재미있는 건, 이 개념이 사람-AI 협업에 그대로 옮겨져 있다는 점입니다. 기획을 정리하는 면담형 스킬은 시작할 때 구체성 모드를 요청자가 직접 고르게 합니다. 방향만 던지고 결정은 작업자에게 맡기는 ‘러프’, 그 중간, 그리고 꼼꼼한 스펙까지 짜는 ‘구체’. 표현을 빌리면, 사람이 AI에게 구체성을 정해 주는 건 모델에게 effort 값을 건네는 일과 같고, 그 구체성은 결국 운영자가 사는 것이라는 거죠. 힘을 더 쓸지 덜 쓸지를 사람이 의식적으로 결정하게 만드는 장치입니다.
서브에이전트를 띄울 때도 마찬가지입니다. 제 하네스에는 작은 일꾼 AI를 부를 때 모델(=비용이자 effort)을 명시하지 않으면 한 번 더 확인하는 훅이 있습니다. 단순 검색이나 파일 찾기엔 가볍고 빠른 모델을, 깊은 사고가 필요한 일엔 더 센 모델을. 작업마다 의식적으로 고르라는 잔소리 장치인 셈이죠.
5. 결국 핵심은 모델이 아니라, 사람을 루프에 남기는 설계입니다
여기까지 소개한 도구들에는 사실 한 가지 공통된 전제가 깔려 있습니다. 일을 목적별로 잘게 쪼개야 한다는 것입니다. “기획하고 개발까지 한 번에 해줘”가 아니라, 각 단계에 맞는 입구를 따로 두는 식이죠.
- 새 기능의 기획을 구체화할 때는 기획용 면담 스킬로,
- 그 기획을 입력 삼아 개발 계획을 잡을 때는
plan-intake로, - 글이 남에게 읽히는지 볼 때는
/readability-check로, - 다 된 결과물을 비판적으로 검토할 때는
/critical-review로.
그래서 지난 며칠 작업의 절반은 사실 “스킬을 목적 단위로 쪼개고 정리하는” 일이었습니다. 평소엔 컨텍스트에서 빼 두었다가 필요할 때만 불러오는 라우터를 두어, 각 도구가 하나의 목적에만 집중하도록 만들었죠. 도구가 여러 목적을 겸하면, 결국 사람도 AI도 지금 무슨 단계인지 헷갈리니까요.
그리고 이 모든 걸 관통하는 골격은, 사실 1편에서 이미 이야기한 그 네 단계(기대 → 관찰 → 간극 → 개선방안)입니다. 면담형 스킬이 끊임없이 “제가 이해한 게 맞나요: ___” 하고 해석을 되돌려 확인하는 것도, 결국 그 프레임을 코드로 옮긴 것이죠. 사람과의 오해를 줄이려고 배운 틀이 AI와의 오해를 줄이는 데 그대로 쓰인다는 게, 저는 아직도 신기합니다.
다섯 가지를 한 줄로 묶으면 이렇습니다. 모델을 더 똑똑하게 만드는 게 아니라, 사람과 AI 사이의 ‘구체화·오해 제거’ 과정을 설계하는 일. 강력한 모델의 함정을 알아채고(1), 자기 채점을 제3자에게 넘기고(2), 막는 대신 판단을 돌려주고(3), 힘을 목적에 맞게 배분하고(4), 일을 목적별로 쪼개는(5) 방향으로, 제 하네스는 조금씩 움직이고 있었습니다.
기계를 길들이던 시절의 저였다면, 이 모든 걸 ‘더 촘촘한 차단 규칙’으로 풀려 했을 겁니다. 그런데 모델이 강해질수록 정답은 반대편에 있었습니다. AI를 더 세게 가두는 게 아니라, 사람이 끝까지 속지 않게 돕는 쪽으로요.
여러분의 하네스는 지금 AI를 막고 있나요, 아니면 사람이 속지 않게 돕고 있나요?
1편과 같은 날, 클로드 Fable 5를 며칠 쓰며 정리한 생각의 뒷이야기로 남깁니다. 여기서 다룬 파인만 검증 게이트와 안내형 게이트는 모두 제가 클로드에게 입히는 하네스(스킬·룰·훅·커맨드)의 일부입니다. → 하네스 엔지니어링 1편: 강제에서 배려로