AI 에이전트가 계속 책임을 회피하나요? YES Discipline Engine가 문제를 스스로 해결하게 만듭니다

지난주, 한 개발자가 그룹에서 말한 것이 저 자신이 여러 번 빠졌던 함정을 떠올르게 했습니다:

“제 에이전트가 계속 ‘직접 확인하세요’라고 하네요 — 사용하기보다 직접 하는 게 더 빠름을 느낍니다.”

그 frustrations에 완전히 공감합니다.

AI 에이전트의 게으른 모드

AI 코딩 에이전트를 한동안 사용해 보셨다면, 반드시 이런 문장들을 보셨을 것입니다:

• “이 문제는 데이터베이스 연결 때문일 수 있습니다 — 확인해 보시는 것을 권장합니다.”
• “기능이 구현되었으니 작동할 것입니다.”
• “제가 직접 확인할 수 없습니다 — 직접 수동으로 테스트해 볼 수 있습니다.”
• “이것은 환경 변수 문제일 수 있습니다.”

에이전트가 고장 난 것이 아닙니다. 이것은 AI 모델이 불확실성에 직면했을 때의 표준 응답입니다 — 결론을 사용자에게 맡기고, “안전한” 제안 제공 포지션으로 퇴각합니다.

문제는 에이전트를 설정한 것이 “제안 목록"을 받기 위해서가 아니라, 일을 마무리하기 위해서라는 것입니다. 실제로 문제를 해결해 주기를 바랍니다.

왜 에이전트는 책임을 회피할까요?

AI 모델 훈련에는 내재된 성향이 있습니다: 불확실할 때, 실수하는 것보다 책임을 회피하는 것이 더 “안전"합니다.

모델에게 있어서 “직접 확인해 보세요"라고 말하는 것은-low-risk 답변입니다 — 실수를 하거나 추가적인 문제를 야기하지 않습니다. 하지만 여러분에게 있어서 그 답변은 가치가 없습니다.

다른 관점으로 보면 더 명확해집니다:

방금 엔지니어를 고용했고 “왜 이 API가 계속 401을 반환하나요?“라고 물었다고 상상해 보세요.

게으른 모드 엔지니어: “토큰이 만료되었을 수 있습니다 — API 문서를 확인해 보세요.”

원하는 엔지니어: curl을 실행하여 응답 형식을 확인하고, 토큰 만료를 확인하고, 리프레시를 시도하고, 수정되었음을 확인하고, 결과를 알려줍니다.

차이는 능력이 아니라 소유권에 있습니다.

YES Discipline Engine: 5개의 강력한 규칙

YES Discipline Engine은 에이전트의 시스템 프롬프트에 내장된 일련의 행동 규칙입니다. 이 이름은 핵심 철학에서 유래했습니다: 에이전트가 “다 했어요"라고 말할 때 “네, 믿을게요"라고 할 수 있어야 합니다 — “확인해 볼게요"가 아니라.

규칙 1: 절대 추측하지 말고, 항상 확인하세요

1
2
3
4
5
6
7

❌ "문제는 데이터베이스 연결일 수 있습니다."
✅ Run psql -U user -h localhost testdb
   → "Connection refused (port 5432)" 획득
   → PostgreSQL이 실행 중이 아님
   → Run sudo systemctl start postgresql
   → 연결 재테스트 통과
   → 보고: 확인되고 수정됨

“X일 수 있습니다"는 반드시 “Y를 실행했고 Z 결과를 얻었습니다"가 먼저 와야 합니다.

규칙 2: 절대 회피하지 말고, 스스로 해결하세요

1
2
3

✅ "이 설정이 올바른지 직접 수동으로 확인해 보세요."
→ 설정 파일을 읽고, 문서와 비교하고, 불일치를 찾고, 수정하고, 확인
   → 권한이 없는 경우: 정확히 어떤 권한이 필요하고 왜 필요한지 설명

에이전트의 경계는: “스스로 범위 내 작업(허용된 파일 / 할당된 작업)을 해결하세요.” 범위 밖에서만 도움을 요청하되, 정확히 무엇이 필요한지 명확히 말하세요.

규칙 3: 증거 없이 주장하지 마세요

1
2
3
4

❌ "레이밋딩 기능이 완료되었습니다."
✅ Run for i in {1..15}; do curl -s localhost:3000/api; done
   → 처음 10개는 200, 마지막 5개는 429 반환 확인
   → 보고: 기능 확인됨, 요구사항 충족

“기능이 완료되었습니다"는 완료로 인정되지 않습니다. 출력 확인과 함께 “기능이 완료되었습니다"才行.

규칙 4: 실패한 방법을 반복하지 마세요

1
2
3
4
5

방법 A가 처음 실패하면:
→ 먼저 왜 실패했는지 진단
→ 그 다음 다음 단계 결정 (A 수정 또는 방법 B로 전환)

아님: 정확히 같은 명령을 다시 실행하고 "해 봤습니다"라고 말하기

규칙 5: 모든 작업에 명확한 상태가 있어야 합니다

작업 종결은 세 가지 중 하나여야 합니다:

• ✅ 완료: 확인 출력과 함께
• ✅ 차단: 구체적인 이유 + 계속하려면 필요한 것
• 🔄 진행 중: 다음 단계 설명

“될 것입니다"라는 것은 없습니다.

YES Discipline Engine 설치

이 규칙 세트는 일반 텍스트이며 모든 에이전트의 시스템 프롬프트에 직접 추가할 수 있습니다.

Claude Code / Claude API: 이 규칙 블록을 CLAUDE.md 또는 시스템 프롬프트에 추가하세요:

1
2
3
4
5
6
7

## YES Discipline Engine

- 규칙 1: 추측하지 마세요. 실제 명령을 실행하고 실제 출력을 보고하세요.
- 규칙 2: 회피하지 마세요. 범위 내라면 해결하세요. 아니라면 정확히 무엇이 필요한지 말하세요.
- 규칙 3: 증거 없이 주장하지 마세요. "완료"라고 말하기 전에 확인 출력을 보여주세요.
- 규칙 4: 동일하게 재시도하지 마세요. 방법 A가 실패했다면, 다음 시도 전에 왜 실패했는지 진단하세요.
- 규칙 5: 모든 작업은 다음으로 종결: ✅ 완료 (증거와 함께) | ❌ 차단 (구체적인 이유) | 🔄 진행 중 (다음 단계)

OpenClaw: 규칙을 SOUL.md의 <anti-slack> 블록에 추가하거나, 독립 스킬로 로드 (skills/yes-en/SKILL.md).

실제로 무엇이 달라지나요?

설치 후 가장显而易한 변화는 에이전트가 “더 똑똑해지는” 것이 아닙니다 — 여러분이 중개자가 될 필요가 없어진다는 것입니다.

이전 흐름:

1. 당신이 질문
2. 에이전트가 제안
3. 당신이 직접 확인
4. 돌아와서 에이전트에게 결과 알려줌
5. 에이전트가 다음 제안
6. 반복

YES 엔진 사용 시:

1. 당신이 작업 부여
2. 에이전트가 끝까지 실행하고, 전체 출력과 함께
3. 당신이 결과에 기반하여 다음 단계 결정

차이점은 steps 3-5가 todo list에서 사라진다는 것입니다.

한 가지 주의

YES Discipline Engine은 에이전트를 더 적극적이게 합니다 — 명령을 실행하고, 파일을 읽고, 코드를 수정합니다. 이는 여러분이 명확한 경계가 필요하다는 것을 의미합니다:

• allowed_files: 에이전트가 수정할 수 있는 파일
• 확인이 필요한 작업 (디플로이, DB 변경, 외부 게시)

“적극적"이Without 경계는 문제가 됩니다. YES 엔진은 에이전트가 명확한 범위를 가지고 있다고 가정합니다 — 범위 내에서는 자율적으로, 범위 밖에서는 물어봅니다.

여전히 에이전트가 “직접 확인하세요"라고 한다면, 다음 작업이 다르게 진행되는지 확인하기 위해 시스템 프롬프트에 이 5가지 규칙을 추가해 보세요.

추가 읽기

• AI 자체 리뷰 파이프라인: 에이전트가 PR을 보내기 전에コードをレビュー하게 만드는 방법 — 더完全な 에이전트 품질 관리 파이프라인 설계
• 처음부터 AI 멀티 에이전트 팀 구축: 우리의 실제 경험과 함정 — 에이전트 팀 구축 시 직면한 실제 문제들
• AI 에이전트 대 전통 트레이딩 봇: 차이점과 선택 방법 — 에이전트 자율성의 본질적 차이점에 대한另外的 관점