에이전트 기술: SOP 작성을 멈추고 경계 시스템 구축을 시작하세요

r/ClaudeAI의 최근 게시글에서는 에이전트 실패를 수정하기 위해 스킬, 도구, 프롬프트 또는 예외 규칙을 추가하는 일반적인 본능이 오히려 역효과를 낸다고 주장합니다. 작성자는 이러한 접근 방식이 시간이 지남에 따라 에이전트를 더 취약하게 만든다고 말합니다. 컨텍스트가 무거워지고, 도구 선택이 지저분해지며, 규칙들이 서로 충돌하기 시작합니다.

SOP로서의 스킬 vs. 경계 시스템

작성자에 따르면 핵심 문제는 많은 개발자들이 스킬을 표준 운영 절차(SOP)처럼 작성한다는 점입니다:

1단계: 이렇게 한다
2단계: 저렇게 한다
X가 발생하면 Y를 한다
Y가 발생하면 Z를 한다
A가 아니면 B를 하지 않는다, 단 C가 발생하면 예외

이 스타일은 결정론적 워크플로우에는 효과적이지만 개방형 에이전트 작업에는 실패합니다. 대신 작성자는 경계 시스템 접근 방식으로 전환할 것을 제안합니다. 여기서 좋은 스킬은 다음 질문에 답합니다:

• 이 스킬은 언제 반드시 트리거되어야 하는가?
• 절대 사용하면 안 되는 경우는 언제인가?
• 비즈니스 관점에서 성공은 무엇을 의미하는가?
• 모호함 없이 필요한 최소 도구 세트는 무엇인가?
• API나 외부 소스를 통해 반드시 검증해야 할 사실은 무엇인가?
• 에이전트가 멈추고 인간에게 확인을 요청해야 하는 상황은 언제인가?

“모델에게 숨 쉬는 법을 가르쳐서는 안 됩니다. 명확한 지도, 깔끔한 도구, 그리고 분명한 정지 신호를 줘야 합니다.”

도구: 적을수록 좋다

같은 원칙이 도구 정의에도 적용됩니다. 더 많은 도구가 자동으로 더 많은 능력을 의미하지는 않습니다. 도구 간 경계가 모호하면 모델은 어떤 것을 호출할지 결정하는 데 컨텍스트와 추론 예산을 소모합니다. 작성자의 경험 법칙:

최소한의 완전한 도구 세트, 최대한의 경계 명확성.

절차적 정확성보다 평가

좋은 스킬은 에이전트가 작성자의 정확한 단계를 따랐는지 여부가 아니라 다음을 수행했는지로 판단해야 합니다:

• 올바른 도구를 선택했는가?
• 올바른 매개변수를 전달했는가?
• 올바른 사실을 검증했는가?
• 멈춰야 할 때 멈췄는가?

작성자는 결론을 내립니다: 나쁜 스킬은 계속 길어지는 SOP이고, 좋은 스킬은 테스트된 경계 시스템입니다. 그는 커뮤니티에 다른 사람들이 이를 어떻게 처리하는지, 즉 스킬을 작고 모듈화된 상태로 유지하는지 아니면 긴 명령 팩으로 바꾸는지, 그리고 스킬이 실제로 에이전트를 개선하는지 아니면 더 많은 컨텍스트 부채를 만드는지 어떻게 알 수 있는지 질문합니다.