Post

에이전트 규칙을 지시문이 아니라 게이트로 강제해보자

사양을 먼저 읽으라고 지시했는데 세 번 다 읽지 않았다. 지시문은 지켜졌는지 확인할 방법조차 없어서, 편집이 일어날 때마다 반드시 도는 훅으로 옮겼다

에이전트 규칙을 지시문이 아니라 게이트로 강제해보자

에이전트 규칙을 지시문이 아니라 게이트로 강제해보자

에이전트가 지켜야 할 규칙을 문서로 적어두면 지킬 거라고 생각했다. 재보니 아니었다. 더 나쁜 건 지켰는지 확인할 방법조차 없다는 점이었다.

1. 서론 (Introduction)

  • 문제/상황 (Problem): 프로젝트에 규칙 문서를 두고 “작업 전에 사양을 읽어라”고 지시했다. 약한 모델을 실행자로 붙였더니 사양 조회 도구를 세 번 중 0번 호출했다. 실패 자체보다 심각한 건, 지시를 따랐는지가 로그에 남지 않아 놓쳤다는 사실조차 나중에 알았다는 점이다.
  • 목적 (Purpose): 규칙을 모델의 선의에 맡기지 않고, 실행 흐름에 끼어들어 반드시 도는 지점으로 옮긴다.
  • 대상 (Target Audience): 에이전트에 규칙 문서를 줘도 지켜지지 않아 곤란한 개발자.

2. 방법 및 과정 (Methods & Process)

  • 배경 조사 및 데이터 (Data Collection): 규칙을 전달하는 방식은 크게 셋으로 나뉘고, 강제력과 확인 가능성이 서로 다르다.

    방식강제력위반을 알 수 있는가비용
    지시문(프롬프트·문서)없음알 수 없음낮음
    서브에이전트 검토확률적검토자가 봐야 앎높음(토큰·시간)
    훅(도구 호출 전후)결정적종료 코드로 즉시낮음
  • 접근 방법 (Approach Methods):
    • [방법 1]: 역할은 서브에이전트에 맡기고, 넘기는 방식은 대화가 아니라 파일로 고정한다. 검토자는 정해진 경로의 산출물만 읽는다. 대화 맥락에 의존하면 호출 순서가 바뀔 때 조용히 어긋난다.
    • [방법 2]: 되돌리기 어려운 동작이 들어 있는 절차는 모델이 스스로 부르지 못하게 막는다. 본문에 커밋이 들어간 스킬에는 모델 호출 금지 플래그를 달아 사람이 명시적으로 부를 때만 돌게 했다.
  • 분석 및 해결 프로세스 (Analysis Flow):
    • 도구/기술: 표준 라이브러리 ast, 편집 도구 호출 직후 실행되는 훅, 종료 코드 규약.
    • 주요 단계: 편집 발생 $\rightarrow$ 훅이 편집된 파일을 파싱 $\rightarrow$ 실제 시그니처와 문서에 적힌 인자 목록을 대조 $\rightarrow$ 어긋나면 0이 아닌 코드로 종료.
    • 결과 도출 및 검증: 같은 파일에 인자 하나를 더하고 문서는 그대로 둔 편집을 흘려보냈다. 훅이 문서에 없는 인자: ['retries']를 집어내며 종료 코드 1을 냈다. 편집이 파일을 깨뜨린 경우도 파싱 단계에서 걸려 코드 2로 끝났다. 지시문이었다면 셋 다 조용히 통과했을 것이고, 게이트는 그중 2건을 막았다.

3. 결과 (Results)

  • 분석 결과 요약: 규칙을 훅으로 옮기자 위반이 종료 코드라는 관측 가능한 신호가 됐다. 지시문 방식에서는 “사양을 읽었는가”에 대한 0/3이라는 숫자조차 나중에 따로 재봐야 알 수 있었다. 훅은 위반한 편집마다 그 자리에서 멈춘다. 다만 훅이 검사할 수 있는 건 파일에 남는 것뿐이다 — 모델이 무엇을 읽었는지, 왜 그렇게 판단했는지는 여전히 이 방식으로 잡히지 않는다.

4. 인사이트 및 액션 (Insights & Action)

  • 인사이트 (Insight): 지시문과 게이트의 차이는 강제력보다 관측 가능성에 있다. 지시를 어겼는지 알 수 없으면 규칙이 살아 있는지조차 확인할 수 없고, 그 상태에서 초록불을 믿게 된다. 이번에 훅이 막은 두 건도 지시문이었다면 그냥 지나갔을 것이다. 막지 못했다는 게 문제가 아니라, 막지 못했다는 사실조차 남지 않는다는 게 문제다.
  • 실행 방안 (Action Plan): 규칙을 새로 정할 때 “이걸 어겼는지 기계가 알 수 있는가”를 먼저 묻는다. 답이 아니면 그건 규칙이 아니라 바람이다. 훅으로 옮길 수 있는 형태까지 좁힌 다음 문서에 적는다.
  • 한 줄 결론 (Key Takeaway): 어겼는지 확인할 수 없는 규칙은 규칙이 아니다. 편집마다 반드시 도는 자리로 옮겨야 신호가 된다. 샘플 코드
  • 다음 스텝 (Next Step): 지금은 문서와 시그니처 대조라는 좁은 규칙 하나만 훅으로 옮겼고, 실제 프로젝트의 편집 흐름에 상시로 붙여 운영해본 적은 아직 없다. 훅이 늘어났을 때 편집마다 생기는 지연이 얼마인지, 오탐이 잦아져 사람이 게이트를 꺼버리는 지점이 어디인지는 아직 재지 않았다.

This post is licensed under CC BY 4.0 by the author.