메타인지 AI: 에이전트에 자기평가를 가르치기

저는 에이전트에게 실패하는 테스트를 고치라고 지시했습니다. 에이전트는 오류를 읽고, 단언문 불일치를 식별한 뒤, 기대값을 실제 출력에 맞게 변경하고 “테스트 수정 완료. 모든 테스트 통과.”라고 보고했습니다. 틀린 말은 아니었습니다. 테스트는 통과했습니다. 하지만 그 수정은 완전히 잘못된 것이었습니다.

테스트가 실패한 이유는 함수가 잘못된 데이터를 반환했기 때문입니다. 에이전트는 테스트가 잘못된 답을 기대하도록 만들어서 “고친” 것이었습니다. 에이전트는 제 지시를 완벽하게 따랐습니다: 실패하는 테스트를 고쳐라. 제가 의미한 것은: 테스트가 검증하는 코드를 고쳐라. 에이전트에게는 이 두 해석을 구분할 수 있는 메커니즘이 없었습니다. 지시사항 어디에도 테스트가 왜 실패하는지 평가한 뒤 어떻게 고칠지 결정하라는 내용이 없었기 때문입니다.

이 격차에는 이름이 있습니다. 행동 수준 지시사항과 메타인지 지시사항 사이의 격차입니다. 대부분의 사람들은 첫 번째 종류만 작성합니다.

요약

AI 에이전트 지시사항에는 두 가지 수준이 존재합니다. 행동 수준 지시사항은 에이전트에게 무엇을 할지 알려줍니다: “입력을 검증하라,” “테스트를 작성하라,” “RESTful 규약을 따르라.” 메타인지 지시사항은 에이전트에게 자신이 잘 수행하고 있는지 평가하는 방법을 알려줍니다: “만약 했다 대신 할 것이다라고 말하고 있다면, 검증하지 않은 것이다,” “세 번의 수정이 실패하면, 멈추고 아키텍처를 의심하라,” “확신은 증거가 아니다.” 대부분의 에이전트 설정은 행동 수준 지시사항만으로 구성되어 있습니다. 메타인지 계층이야말로 그럴듯한 출력을 만드는 에이전트와 정확한 출력을 만드는 에이전트를 구분짓는 핵심입니다. 저는 7가지 명명된 실패 모드, 6가지 기준의 증거 게이트, 그리고 헤징 언어 탐지를 포함한 프로덕션 메타인지 시스템을 95개의 훅과 함께 9개월간 운영해왔습니다.

에이전트 지시사항의 두 가지 수준

모든 에이전트 지시사항은 두 가지 수준 중 하나에서 작동합니다.

행동 수준 지시사항은 행동을 정의합니다:

# Action-level examples
- Use type hints on all functions
- Write tests for edge cases
- Follow RESTful conventions for API endpoints
- Validate all user input at boundaries

행동 수준 지시사항은 필수적입니다. 올바른 행동이 어떤 것인지 에이전트에게 알려줍니다. 하지만 구조적 한계를 공유합니다: 에이전트가 이를 충실히 실행할 것이라고 가정한다는 점입니다. 에이전트가 자신의 준수 여부를 어떻게 평가하는지는 고려하지 않습니다.

메타인지 지시사항은 자기 모니터링을 정의합니다:

# Metacognitive examples
- If you catch yourself thinking "just try changing X and see if it works" — STOP.
  That's a signal to investigate, not guess.
- If you've searched the same files three times — you're stuck.
  Step back and question your assumptions.
- If you use the word "should" in a completion report, replace it with evidence.
  Run the command. Paste the output.
- After three failed fixes, stop fixing. The problem is architectural.

이 구분이 중요한 이유는 행동 수준 지시사항은 에이전트에게 목적지가 어떤 모습인지 알려주고, 메타인지 지시사항은 에이전트에게 잘못된 방향으로 가고 있을 때 이를 감지하는 방법을 알려주기 때문입니다. 하나는 잘못된 행동을 방지합니다. 다른 하나는 잘못된 추론, 즉 애초에 잘못된 행동을 만들어내는 사고 패턴을 방지합니다.

GitHub의 obra/superpowers 프로젝트가 이 구분을 처음으로 명확히 표현했으며, 이를 “AI에게 실패 신호에 대해 자신의 내부 추론을 관찰하도록 가르치기”라고 불렀습니다.¹ 핵심 통찰은 이것입니다: 대부분의 스킬은 행동 수준에서 작동합니다(X를 해라, Y를 하지 마라). 메타인지 수준은 다르게 작동합니다(Y를 하려는 순간을 알아차려라).

거짓 증거 표

제가 구축한 메타인지 도구 중 가장 효과적인 것은 증거로 인정되지 않는 것을 정의하는 표입니다.²

에이전트에게 “작업을 검증하라”고 지시하면 에이전트는 검증을 생성합니다. 하지만 그 검증은 종종 결과의 시연이 아니라 의도의 재진술에 불과합니다. “테스트가 통과할 것입니다.” “구현이 모범 사례를 따릅니다.” “이것이 정확하다고 확신합니다.” 이 문장들 각각은 증거처럼 들립니다. 하지만 어느 것도 증거가 아닙니다.

거짓 증거 표는 특정 지름길에 이름을 붙여 사전에 차단합니다:

가치는 세 번째 열에 있습니다. 이것이 없으면 에이전트는 두 번째 열을 자신의 확신을 그럴듯하게 재진술하는 것으로 채웁니다. 이것이 있으면, 표는 에이전트가 각 특정 지름길을 취하기 전에 이름을 붙이고 차단합니다.³

이 표는 프롬프트 엔지니어링이 아닙니다. 인지 아키텍처입니다. 표는 에이전트에게 무엇을 다르게 하라고 지시하는 것이 아닙니다. 에이전트에게 자신의 출력에서 무엇을 관찰해야 하는지 알려줍니다. 에이전트는 자신의 응답을 ‘불충분’ 열과 대조하며 모니터링하고, 일치를 감지하면 그 지름길을 실제 증거로 교체해야 한다는 것을 인식합니다.

이 패턴은 확장 가능합니다. 도메인별 주장을 추가할 수 있습니다. 보안 리뷰의 경우: “취약점 없음”은 “코드를 리뷰했다”가 아니라 “확인한 특정 취약점 유형과 발견 사항”이 필요합니다. 접근성의 경우: “WCAG 준수”는 “대비를 확인했다”가 아니라 “axe 또는 Lighthouse 감사 출력”이 필요합니다.

메타인지 가드레일로서의 명명된 실패 모드

인간에게는 명명된 인지 편향이 있습니다: 확증 편향, 앵커링, 더닝-크루거 효과. 이름이 중요합니다. 편향에 이름을 붙일 수 있으면 이를 관찰할 수 있습니다. AI 에이전트에게도 자신의 실패 패턴에 대한 동일한 어휘가 필요합니다.

저는 에이전트가 반복적으로 보여주는 7가지 실패 모드를 문서화하고, 각각에 이름을 부여하며, 감지 신호를 추가했습니다:⁴

이름은 실패를 감지 가능하게 만듭니다. 이름이 없으면 에이전트는 확신 신기루를 만들어내고, 에이전트도 사용자도 이를 패턴으로 인식하지 못합니다. 이름이 있으면 지시사항은 이렇게 됩니다: “명명된 실패 모드를 보이고 있다면, 즉시 멈추고 평가 단계부터 다시 시작하세요.”

이 모니터링은 정확한 의미에서 메타인지적입니다: 에이전트가 출력(이 코드가 정확한가?)이 아니라 자신의 인지 과정(검증을 건너뛰고 있는가? 확신을 증거의 대체물로 사용하고 있는가?)을 관찰합니다. 모니터링은 에이전트가 출력을 생성하기 전에 일어나며, 이것이 출력 수준의 리뷰가 놓치는 오류를 잡아내는 이유입니다.

Anthropic의 자체 참조 스킬 구현도 이 접근 방식을 뒷받침합니다. 16개의 공식 Claude Code 스킬을 분석한 결과, 효과적인 에이전트 지시사항 설계의 구조적 패턴이 드러났습니다. 금지사항(“절대 X하지 마라”)은 제안(“Y를 고려하라”)보다 현저히 더 효과적이었는데, 일반적인 행동이 아니라 구체적인 회피를 명시하기 때문입니다.⁵ 명명된 실패 모드는 구체적 금지사항입니다: “절대 유령 검증을 하지 마라”는 “항상 테스트를 실행하라”보다 효과적인데, 행동을 재진술하는 것이 아니라 회피를 차단하기 때문입니다.

헤징 언어 탐지

제가 구현한 가장 단순한 메타인지 모니터는 에이전트 출력에서 특정 단어를 감지합니다:

Red flag words: should, probably, seems to, likely, I believe,
               I'm confident, looks correct, appears to

에이전트가 완료 보고서에서 이러한 단어를 사용할 때마다, 그 단어 자체가 불충분한 검증의 증거입니다.⁶ “테스트가 통과할 것이다”는 에이전트가 테스트를 실행하지 않았다는 뜻입니다. “작동하는 것 같다”는 에이전트가 눈으로만 확인했다는 뜻입니다. “확신합니다”는 에이전트가 외부 증거 대신 내부 상태를 대체하고 있다는 뜻입니다.

구현은 기계적입니다. 훅 시스템이 에이전트의 출력을 가로채 헤징 언어를 표시합니다. 그러면 에이전트는 헤징 단어를 수행했어야 할 검증으로 교체합니다:

• “테스트가 통과할 것이다”는 이렇게 됩니다: 테스트를 실행하고, 0건 실패를 보여주는 출력을 붙여넣기
• “정확해 보인다”는 이렇게 됩니다: 정확성을 확인하는 구체적 단언문이나 검증을 인용
• “확신합니다”는 이렇게 됩니다: 그 확신을 뒷받침하는 증거를 나열

이 패턴은 obra의 검증 우선 완료 작업에서 비롯되었습니다: “AI 자신의 단어 선택이 불충분한 증거를 나타낸다.”¹ 인지 과학과의 유사성은 실재합니다. 인간의 메타인지에서 자기 보고의 정확성(“나는 이것을 이해한다”)은 실제 이해도와 상관관계가 낮습니다. “알겠다”고 말하는 사람이 실제로는 모르는 경우가 많습니다. 설명할 수 있는 사람이 대체로 이해하고 있습니다. AI 에이전트에게도 동일하게 적용됩니다: 구체적 증거를 인용할 수 있는 에이전트는 문제를 이해하고 있는 것입니다. “확신합니다”라고 말하는 에이전트는 그렇지 않을 수 있습니다.

3회 수정 회로 차단기

메타인지는 잘못된 추론을 감지하는 것에만 국한되지 않습니다. 언제 멈춰야 하는지를 감지하는 것이기도 합니다.

3회 수정 에스컬레이션 규칙: 같은 문제에 대해 세 번의 수정 시도가 실패하면, 에이전트는 반드시 멈추고 아키텍처를 근본적으로 의심해야 합니다.⁷ 네 번째 수정을 시도하는 것이 아닙니다. 같은 접근 방식에서 다른 각도를 찾는 것도 아닙니다. 멈추세요. 한 발 물러나세요. 문제가 솔루션에 있는지 아니면 문제 정의 자체에 있는지 질문하세요.

이 규칙은 디버깅 루프에 대한 회로 차단기 역할을 합니다. 이것이 없으면 에이전트는 제가 수정 나선이라고 부르는 것에 진입합니다: 실패한 시도마다 새로운 이론이 생기고, 새로운 수정이 생기고, 그것이 실패하고, 또 새로운 이론이 생깁니다. 에이전트는 자신이 올바른 문제를 다루고 있는지 한 번도 의심하지 않으면서 수십 번의 수정을 순환할 수 있습니다. 23개 에이전트 폭주 사건은 이것의 폭 버전이었습니다: 메타인지 검사가 “이 질문의 범위가 올바른가?”를 묻지 않았기 때문에 에이전트들이 잘못된 질문에 대해 합의에 도달한 것입니다.

3회 수정 규칙이 효과적인 이유는 에이전트의 추론에 상전이를 강제하기 때문입니다. 수정 1-3은 현재의 멘탈 모델 안에서 작동합니다. 수정 4(실제로는 “수정을 멈춰라”)는 에이전트에게 새로운 멘탈 모델을 구축하도록 강제합니다. 실제로 이는 대개 오류를 처음부터 다시 읽거나, 가정을 재검토하거나, 사용자에게 명확한 설명을 요청하는 것을 의미하며, 이 모든 것이 네 번째 추측보다 더 생산적입니다.

전후 비교: 무엇이 달라지는가

구체적인 예를 들어보겠습니다. API 엔드포인트에 입력 검증을 추가하라고 에이전트에게 요청했습니다.

메타인지 지시사항 없이:

Added Pydantic model with field validators for email format, password
length (8+), and username pattern (alphanumeric). Tests should pass.
The implementation follows FastAPI best practices.

이 출력에는 세 가지 헤징 신호가 포함되어 있습니다: “should pass”(테스트를 실행하지 않음), “follows best practices”(어떤 관행인지 명시하지 않음), 그리고 엣지 케이스 고려의 증거가 없습니다. 공허한 보고서로 포장된 확신 신기루입니다.

메타인지 지시사항 포함(같은 작업, 같은 에이전트):

Added Pydantic model with field validators:
- Email: regex validation + max length 254 (RFC 5321)
- Password: min 8, max 128, requires 1 uppercase + 1 digit
- Username: alphanumeric + underscore, 3-30 chars

Test output (just ran):
  tests/test_auth.py::test_valid_registration PASSED
  tests/test_auth.py::test_invalid_email_rejected PASSED
  tests/test_auth.py::test_short_password_rejected PASSED
  tests/test_auth.py::test_empty_username_rejected PASSED
  tests/test_auth.py::test_unicode_username_rejected PASSED
  5 passed in 0.34s

Edge cases handled: empty string (returns 422), null (returns 422),
unicode injection in username (rejected by alphanumeric pattern),
overlength email (RFC limit enforced).

Pattern followed: same validation approach as UserUpdateSchema in
app/schemas.py line 45.

차이점은 두 번째 에이전트가 더 나은 코드를 작성했다는 것이 아닙니다. 두 에이전트 모두 동일한 코드를 작성했을 수 있습니다. 차이점은 두 번째 에이전트가 특정 증거 기준에 대해 작업을 검증하고, 확신이 아니라 증거를 보고했다는 것입니다.

자신만의 메타인지 계층 구축하기

이 프레임워크는 이식 가능합니다. 제 특정 시스템이 필요하지 않습니다. 세 가지 구성 요소가 필요합니다:

1. 거짓 증거 표. 에이전트가 가장 자주 하는 주장에 대해 증명으로 인정되지 않는 것을 정의하세요. 위의 6가지 기준부터 시작하여 도메인별 행을 추가하세요. 세 번째 열(불충분)에 핵심 가치가 있습니다.

2. 명명된 실패 모드. 에이전트가 가장 자주 실패하는 3-5가지 방식을 문서화하세요. 각각에 이름을 부여하세요. 감지 신호를 추가하세요. “명명된 실패 모드를 보이고 있다면, 멈추고 재평가하라”는 지시를 포함하세요.

3. 헤징 언어 탐지. 자신의 도메인에서 불충분한 검증을 나타내는 특정 단어를 나열하세요. “헤징 단어를 그 헤지를 제거할 수 있는 증거로 교체하라”는 지시를 추가하세요.

이 세 가지 구성 요소가 결합되어 모든 행동 수준 지시사항 위에 놓이는 메타인지 계층을 형성합니다. 행동 수준 지시사항은 올바른 행동이 어떤 모습인지 정의합니다. 메타인지 계층은 에이전트가 올바른 행동에서 자신이 이탈하는 것을 감지하는 방법을 정의합니다.

구현은 CLAUDE.md나 AGENTS.md에 섹션을 추가하는 것만큼 간단할 수 있습니다:

## Self-Monitoring

### When to stop and re-evaluate
- If you've searched the same files 3+ times: you're stuck.
- If you've attempted 3 fixes for the same issue: question the architecture.
- If you use "should" or "probably" in your response: replace with evidence.

### What doesn't count as evidence
[your false evidence table here]

### Named failure modes to watch for
[your failure modes here]

시행이 훅(결정론적, 건너뛸 수 없음), 규칙 파일(컨텍스트에 로드됨), 인라인 지시사항(모델 준수에 의존) 중 어디에서 이루어지느냐에 따라 메타인지 계층의 신뢰성이 결정됩니다. 훅이 가장 강력한데, 프롬프트 수준이 아니라 도구 사용 수준에서 가로채기 때문입니다. 하지만 프롬프트 수준의 메타인지 지시사항도 에이전트의 행동만이 아니라 평가 기준을 변경하기 때문에 에이전트 출력 품질을 측정 가능하게 향상시킵니다.

메타인지가 할 수 없는 것

메타인지 프로그래밍은 AI 에이전트를 더 신뢰할 수 있게 만듭니다. 현명하게 만들지는 않습니다.

거짓 증거 표는 특정 지름길을 잡아냅니다. 표에 명시되지 않은 새로운 지름길은 잡아내지 못합니다. 명명된 실패 모드는 알려진 패턴을 감지합니다. 아직 명명되지 않은 패턴은 감지하지 못합니다. 헤징 언어 탐지는 표면적인 확신 대체를 잡아냅니다. 잘못된 출력이 올바르다고 에이전트 스스로 진정으로 납득한(“납득”이라는 말이 적용되는 한에서) 경우는 잡아내지 못합니다.

더 근본적으로, 메타인지 지시사항은 안목을 근사하지만 만들어내지는 않습니다. Jiro 시스템은 except: pass를 방지하고 테스트 증거를 강제할 수 있습니다. 아키텍처가 올바른지, 네이밍이 의도를 담고 있는지, 솔루션이 명시된 문제가 아닌 실제 문제를 해결하는지는 판단할 수 없습니다. 그러한 판단에는 현재의 모델들이 근사하지만 안정적으로 수행하지 못하는 종류의 맥락적 추론이 필요합니다.

누군가 Jiro 시스템에 대한 제 트윗에 답글을 달았습니다: “당신은 기본적으로 루프에 절제, 안목, 그리고 도덕적 일시 정지에 가까운 것을 가르치려 하고 있는데, 이것들은 기본 Ralph 패턴이 처리량의 이름으로 명시적으로 최적화하지 않는 것들입니다.”⁸

맞는 말이었습니다. 메타인지 프로그래밍은 기계가 갖추지 못한 자질을 위한 구조적 비계입니다. 그 비계는 하중을 지탱합니다. 이것이 없으면 기계는 대규모로 확신 신기루를 생산합니다. 이것이 있으면 기계는 대규모로 검증된 출력을 생산합니다. 이 두 결과 사이의 격차가 밤새 실행시켜놓을 수 있는 에이전트와 옆에서 지켜봐야 하는 에이전트의 차이입니다.

하지만 비계는 건물이 아닙니다. 건물(안목, 판단력, 질문에 대한 올바른 답이 다른 질문이라는 것을 아는 능력)은 여전히 인간의 영역입니다. 지금으로서는.

핵심 정리

에이전트 시스템을 구축하는 엔지니어를 위해:

• 행동 수준 지시사항만이 아니라 메타인지 지시사항도 작성하세요. 행동 수준 지시사항은 올바른 행동을 정의합니다. 메타인지 지시사항은 에이전트가 올바른 행동에서 자신이 이탈하는 것을 감지하는 방법을 정의합니다. 두 번째 종류가 그럴듯한 출력과 검증된 출력을 구분짓는 핵심입니다.

• 에이전트의 실패 모드에 이름을 붙이세요. 실패 패턴에 이름(확신 신기루, 유령 검증, 지름길 나선)이 붙으면 에이전트가 이를 관찰할 수 있습니다. 이름 없는 실패는 무한히 반복됩니다.

AI 기반 워크플로우를 확장하는 팀을 위해:

• 확장하기 전에 거짓 증거 표를 구축하세요. 에이전트가 하는 각 주장에 대해 증명으로 인정되지 않는 것을 정의하세요. 세 번째 열(불충분)이 에이전트에게 “검증하라”고 요청할 때 취하는 구체적 지름길을 사전에 차단합니다.

• 헤징 언어는 신뢰할 수 있는 신호입니다. 에이전트가 완료 보고서에서 “~할 것이다,” “아마,” 또는 “확신합니다”라고 말할 때마다, 에이전트는 주장하는 검증을 수행하지 않은 것입니다. 기계적으로 감지하고 교체하세요.

메타인지 감사 도구

자신의 에이전트 지시사항을 평가하고 싶으신가요? 아래의 인터랙티브 도구는 CLAUDE.md, AGENTS.md, 또는 시스템 프롬프트를 분석하여 이 글에서 설명한 메타인지 차원 전반에 걸쳐 점수를 매깁니다.

에이전트 지시사항을 붙여넣으면, 감사 도구가 다음을 식별합니다: 지시사항 중 행동 수준 대 메타인지의 비율, 어떤 명명된 실패 모드가 포함되어 있는지, 헤징 언어 탐지가 존재하는지, 그리고 어디에 격차가 있는지.

Claude Code Mastery 시리즈의 일부로, 자율적 AI 개발 뒤의 인프라를 기록합니다: 결정론적 제어를 시행하는 훅부터 아키텍처 규율로서의 컨텍스트 관리, 단일 에이전트의 맹점을 잡아내는 멀티 에이전트 숙의까지. 이 시스템을 뒷받침하는 복리 엔지니어링 철학은 각 구성 요소가 이후에 구축되는 모든 것을 가속하는 이유를 설명합니다.