AI가 시키지 않은 것을 자율 확장할 때 — 오버리치를 멈추는 법

AI 코딩 에이전트에게 “이 다섯 건만 고쳐”라고 시켰다. 그런데 돌아온 결과에는 시키지 않은 것까지 알아서 확장돼 문서 곳곳에 박혀 있었다. 나는 그걸 하나씩 찾아 되돌렸고, 다음 턴에 또 같은 일이 벌어졌다. 이 글은 범용 도구 taskery의 마찰 정정 세션에서 실제로 반복된 그 패턴 — AI의 오버리치(overreach), 즉 시키지 않은 자율 확장을 두 사례로 해부하고, 그것을 멈추는 원칙을 정리한 기록이다.

배경 — 범용 도구에 개인 사정이 자꾸 새어든다

taskery는 여러 PC와 여러 리포에 배포되는 범용 파이프라인 도구다. 그 첫 실사용 도입처가 내 다른 프로젝트 stash였고, stash를 쓰다 걸린 마찰 다섯 건을 taskery 코어 결함으로 보고 일괄 정정하는 세션이었다.

문제는 정정 자체가 아니었다. 세션 대부분이 에이전트가 자율로 확장한 것을 내가 반복해서 적발하고 되돌리는 흐름으로 흘렀다는 것이다. 핵심 긴장은 하나로 요약된다. taskery는 범용 도구인데, 내 개인 운영 방식과 stash라는 특정 프로젝트의 사정이 자꾸 도구 본체에 흔적을 남기려 했다.

오버리치 A — 개인 운영 방식을 시스템 표준으로 박다

첫 번째는 가장 미묘했다. 에이전트가 내 작업 습관 하나 — 단일 메인에서 지휘하는 방식 — 을 taskery의 표준인 것처럼 여러 문서에 명문화했다.

하지만 taskery의 기본값은 “각 워크트리 = 독립 세션”이다. 내가 단일 메인에서 지휘하는 건 개인 운영일 뿐 시스템 표준이 아니다. 특정 운영 모델을 표준으로 박으면 외부 사용자가 도구의 실제 능력(멀티세션 병렬)을 좁게 오해한다.

되돌린 방식은 이렇다.

• 전 문서에서 “이 방식 = 표준”이라는 표현을 걷어냈다.
• 대신 “호출 위치는 자유이고, 작업 디렉토리와 무관하게 동작을 보장한다”로 다시 썼다.
• 지원하는 운영 모델 세 가지(멀티세션 병렬이 기본 · 단일 메인 지휘 · 메인이 서브 세션을 띄우는 방식)를 나란히 명시해, 어느 하나를 표준으로 세우지 않았다.

오버리치 B — 도구 룰을 개인 메모리에 박다

두 번째는 룰이 사는 자리를 잘못 고른 경우다. 에이전트가 도구 개선 사항을 내 세션 메모리 본문을 고쳐 처리하려 했다.

taskery는 다른 PC, 다른 리포에서도 쓰는 도구다. 그러니 세션 메모리를 고치는 건 그 세션 한정일 뿐 문제 해결이 아니다. 핵심은 한 문장으로 남는다.

메모리는 다른 PC에서 효과가 없다.

즉, 도구 정책의 자리는 지금 이 세션의 메모리가 아니라 배포되는 도구 본체(템플릿에 실린 규칙·스킬·훅)다. 거기에 박아야 전 사용자에게 적용된다.

두 사례가 가리키는 하나의 원칙

두 오버리치는 방향이 같다. 범용이어야 할 도구에 특정한 것 — 개인 습관이든 특정 프로젝트 사정이든 — 을 박으려는 힘이다.

그래서 세 번째 마찰도 같은 잣대로 잘라냈다. stash가 쓰는 Xcode 빌드 캐시를 정리하는 로직을 taskery 코어에 넣자는 안이었는데, 그건 특정 프레임워크의 사정이라 범용 도구의 도메인 밖이다. 도메인 밖 문제는 그 프로젝트 영역에서 처리하기로 하고 이번 릴리스에서 제외했다.

정리하면 원칙은 셋이다.

• 개인 운영 방식을 시스템 표준으로 일반화하지 않는다. 내가 이렇게 쓴다고 도구의 기본값이 그게 되면, 다른 사용자는 능력을 좁게 오해한다.
• 범용 도구에 특정 프로젝트·특정 케이스의 흔적을 남기지 않는다. 도메인 밖 문제는 그 영역에서 처리한다.
• 룰의 자리는 “지금 이 세션”이 아니라 “배포되는 본체”다.

그런데 룰로 오버리치를 100% 막을 수 있나

솔직한 답은 아니오다. 세션 말미에 나는 이 해법을 만능처럼 포장하고 싶지 않아 스스로에게 물었다.

100% 완벽하냐? 룰을 강화해도 안 따르는 행동은 못 잡잖아. 그 한계를 그냥 인정해. 과장하지 말고.

룰을 아무리 촘촘히 세워도, 그 룰을 따르지 않는 행동 자체는 룰로 잡히지 않는다. 그러니 오버리치를 다루는 실전 습관은 룰 한 줄이 아니라 태도에 가깝다 — “플랜에 있으니까”를 근거로 명시 안 된 것을 확장하려 할 때 멈추고, 확장 대신 되묻는 것.

명시한 것만 반영하고, 그 밖은 스스로 확장하지 말고 의문을 제기해서 물어. “플랜에 박혀 있다”는 이유로 정당한 의문 제기를 생략하는 것도 하지 마.

즉, 오버리치는 완전히 봉인되는 결함이 아니라 매 턴 관측하고 되돌려야 하는 경향이다. 그 사실을 정직하게 인정하는 편이 과장된 완료 보고보다 낫다.

관련해서, 같은 도구의 테스트 단계에서 에이전트의 “거짓 PASS”를 어떻게 물리적으로 막았는지는 테스트 오라클 설계에서 이어 다룬다.