내 AI 에이전트가 이미 15번이나 존재하던 기능을 만들었다

나는 AI 에이전트에게 워크플로우 규칙(workflow rule) 하나를 추가해달라고 요청했다. 하지만 에이전트는 세 개를 만들었다.

그 후 grep 명령어를 한 번 실행해 보니, 이미 15개의 훅(hooks)과 4개의 스킬(skills)이 정확히 똑같은 작업을 수행하고 있다는 것을 발견했다.

요약(TL;DR): AI 에이전트는 행동하기 전에 시스템의 인벤토리(inventory)를 조사하지 않기 때문에, 이미 존재하는 것을 자신 있게 만들어버린다. 해결책은 더 똑똑한 모델을 사용하는 것이 아니다. 에이전트가 무언가를 작성하기 전에 ls와 grep을 실행하도록 경로(path)에 강제하는 것이다.

내가 요청한 것과 에이전트가 만든 것

요청은 간단했다: "지금 당장 확인할 수 없는 작업은 잊어버리지 않도록 이슈(issue)로 기록해 줘."

에이전트는 이미 존재하는 것들을 살펴보는 것부터 시작하지 않았다. 바로 구축(building)부터 시작했다. 단 한 번의 턴(turn) 만에 에이전트는 다음과 같은 작업을 수행했다:

• 규칙 파일(rules file)에 새로운 섹션 추가
• 인젝션 훅(injection hook)에 새로운 트리거(trigger) 연결
• 스톱 훅(stop hook)에 새로운 어휘(vocabulary) 병합
• 두 개의 새로운 이슈 라벨(issue labels) 발명

작동은 잘 되었다. 내가 작성하라고 요청한 테스트들도 통과했다. 에이전트는 완료되었다고 보고했다.

그 후 나는 에이전트가 스스로에게 먼저 물었어야 할 질문을 던졌다: 이와 유사한 것이 이미 존재하지는 않는가?

# 에이전트가 건너뛴 질문
ls ~/.claude/hooks/*.py | grep -iE "defer|completion|issue|residual|todo|handover|stop-"
ls ~/.claude/skills/ | grep -iE "issue|todo|inventory|fresh"

출력 결과는 비어 있지 않았다. 매우 많았다.

나를 멈추게 한 숫자

15개. 4개.

hooks: 15
skills: 4

이미 15개의 훅이 연기(deferral), 완료 주장(completion claims), 그리고 이슈 인계(issue handoff)를 처리하고 있었다. 4개의 스킬(issue-inventory, github-issue, search-issues, fresh)은 이미 "잊어버리지 않도록 기록해 줘"라는 흐름을 정확히 다루고 있었다. 그중 하나인 github-issue에는 내 에이전트가 방금 두 개의 라벨을 만들어 비슷하게 구현하려 했던 due: 필드가 이미 존재했다.

에이전트는 시스템을 확장한 것이 아니었다. 시스템 옆에 두 번째 시스템을 키워버린 것이다.

그리고 에이전트가 새로 만든 두 개의 라벨 — timed-followup, awaiting-reaction — 은 태어나자마자 쓸모없는 것이 되었다:

# 실제로 이 라벨들을 읽는 것이 있기는 한가?
grep -rl "timed-followup" ~/.claude/
# → 에이전트 자신이 방금 작성한 파일들뿐임. 이를 소비하는 것은 아무것도 없음.

아무도 읽지 않는 라벨은 기능(feature)이 아닙니다. 그것은 콜론(:)이 붙은 쓰레기일 뿐입니다.

에이전트가 왜 이런 행동을 하는가 (그리고 인간은 보통 왜 안 하는가)

코드베이스에 합류한 인간 엔지니어는 첫 한 시간을 읽는 데 사용합니다. 그들은 hooks 디렉토리를 엽니다. issue-inventory라는 이름의 스킬(skill)을 발견하고는, "내가 지금 만들려는 것과 비슷해 보이는데"라고 생각합니다. 호기심과 중복된 일을 하고 있다는 느낌을 피하려는 마음이 그들을 먼저 확인하도록 유도합니다.

에이전트에게는 이 두 가지가 모두 없습니다. 에이전트는 눈앞에 있는 대상에 대해 그럴듯하고 작동 가능한 변경 사항을 만들어내도록 최적화되어 있습니다. 가장 저항이 적은 경로는 기존 코드를 감사(audit)하는 것이 아니라 새로운 코드를 작성하는 것입니다. 그래서 에이전트는 유창하고 자신감 있게, 그리고 이미 존재하는 작업 위에 새로운 것을 구축합니다.

이것이 바로 사람들이 _"에이전트는 코드를 작성하지만, 기억하지는 못한다"_라고 말할 때 의미하는 것과 동일한 실패입니다. 결여된 기억은 대화 내용이 아닙니다. 바로 시스템입니다. 에이전트는 이미 무엇이 존재하는지에 대한 지도(map)를 로드한 적이 없으므로, 모든 요청이 마치 아무것도 없는 상태(greenfield)처럼 보입니다.

내가 추출한 규칙: 구축하기 전에 인벤토리(inventory)를 확인하라

효과가 있었던 해결책은 "더 나은 모델을 사용하는 것"이 아니었습니다. 그것은 에이전트가 특정 종류의 새로운 것을 작성하도록 허용되기
_전(before)_에 배치된 게이트(gate)였습니다:

새로운 훅(hook), 스킬(skill), 규칙(rule), 또는 라벨(label)을 만들기 전에, 동일한 개념에 대해 ls와 grep을 실행하십시오. 만약 이미 그 역할을 수행하는 것이 있다면, 그것을 확장하십시오. 아무것도 없다면, 그때 구축하십시오. 그리고 무엇을 검색했는지 명시하십시오.

구체적으로, 교정된 에이전트의 출력물은 이제 다음과 같습니다:

# 인벤토리 단계 — "새로운 메커니즘 구축"이 허용되기 전에 실행됨
existing=$(ls ~/.claude/{hooks,skills} | grep -iE "<concept>")
if [ -n "$existing" ]; then
...

살아남은 판단 규칙은 단 하나의 이진(binary) 결정이었습니다: 이 개념에 대해 기존 메커니즘이 존재하는가 — 예 또는 아니오? "새로운 것이 더 나은가"가 아닙니다. 만약 '예'라면, 설령 새로운 것이 더 깔끔하더라도 새로운 구축은 잘못된 선택입니다.

에이전트의 작업물 중 제가 남겨둔 것은 아주 작았습니다. 이전에는 소유자가 없었던, 진정으로 새로운 의사결정 규칙(decision rule) 하나뿐이었습니다. 그 외의 모든 것 — 새로운 훅 파일(hook file), 새로운 레이블(labels), 재발명된 due: 필드 — 은 이미 존재하던 시스템 속으로 다시 통합되었습니다.

직접 시도해 보세요

수개월에 걸쳐 축적된 시스템에 AI 에이전트를 실행한다면, 에이전트가 과거에 수행했던 변경 사항 중 하나를 지목하며 다음과 같이 물어보세요:

이 작업 이전에, 당신이 확장해서 사용할 수 있었던 기존 요소는 무엇이었나요?

그런 다음 에이전트가 건너뛰었던 ls/grep 명령을 직접 실행해 보세요. 에이전트가 구축한 것과 이미 존재하던 것 사이의 격차는, 에이전트가 결코 수행하지 않았던 인벤토리(inventory) 단계의 크기입니다.

에이전트가 다음번 확신에 차서 새로운 파일을 만들기 전에, 에이전트 앞에 둘 수 있는 가장 작은 "구축 전 검색" 체크 항목은 무엇일까요?

Sho Naka (nomurasan). 저는 매일 저의 툴링(tooling)에 AI 에이전트를 실행하며, 일주일의 대부분을 에이전트의 확신에 찬 출력물 중 어떤 것을 남기고 어떤 것을 기존 시스템에 통합할지 결정하는 데 보냅니다.

이 글은 제가 작성한 일본어 에세이를 바탕으로 작성되었으며, 언어 간 재작성(cross-language rewrite) 과정에서 AI의 도움을 받았습니다. 글에서 설명하는 작업과 이를 잡아낸 grep은 저의 것입니다.