서브에이전트가 전역지침을 읽지 않았다는 의심

아침판 서브에이전트 팀 구성 이야기가 이름 붙인 에이전트를 어떻게 짜느냐에 있었다면, 저녁판에서는 짜 둔 서브에이전트가 지침을 제대로 받았는지를 의심하는 말이 나왔다. 이 주제에는 9명이 74건을 보탰다. 시작은 토큰 이야기였다.

뭐 30분만에 토큰 40%녹네 ㅋㅋㅋ

오케스트레이션만 지침을 읽었다

전역지침은 어느 프로젝트에서든 공통으로 따르도록 사용자가 정해 둔 지침을 뜻하고, 오케스트레이션은 한 에이전트가 여러 서브에이전트에게 일을 나눠 맡기는 방식을 가리킨다.

오전 8시 32분 한 참여자는 고속 응답 설정으로 보이는 '울트라 패스트'(대화에서 정의되지 않은 용어) 때문에 30분 만에 토큰이 40% 녹았다며 패스트를 빼야겠다고 했다. 이 수치는 그 참여자의 체감 설명이다. 3분 뒤 같은 참여자는 밤새 돌린 작업이 이상해 에이전트에게 직접 물어봤다고 전했다.

질문은 짧았다. 서브에이전트들도 전역지침을 읽은 게 맞느냐는 확인이었고, 돌아온 답은 오케스트레이션을 맡은 쪽만 읽었다는 것이었다. 이 답은 에이전트 자신의 설명이어서 지침이 실제로 전달됐는지는 따로 확인된 것이 아니다.

너 이거 서브에이전트들도 전역지침 읽은거맞아?

이 말은 결과물을 보고 의심이 생긴 사람이 에이전트에게 직접 되묻는 장면으로 읽힌다. 확인 방법이 없으면 이런 의심은 말로 묻는 수밖에 없다. 다만 실제로 어떤 지침이 빠졌는지, 어떤 도구에서 그랬는지는 대화에 나오지 않았다.

오케스트레이션 쪽이 지침을 읽었다는 것과 서브에이전트가 읽었다는 것이 별개의 확인 대상이라는 점이 이 경험담의 핵심으로 보인다. 팀 구성이 복잡해질수록 확인해야 할 지점도 그만큼 늘어난다는 뜻으로 읽힌다.

지침이 많아서 안 읽힌다는 설명

8시 36분에는 다른 참여자가 원인으로 볼 만한 설명을 내놓았다. 스킬(반복 작업 절차 묶음)과 하네스(에이전트를 둘러싼 규칙·설정 묶음)가 불어나면 소넷 같은 모델이 처음에 불러올 수 있는 분량이 모자랄 수 있다는 의견이었고, 점검용 플러그인 링크도 함께 공유했다. 이 동작 원리는 그 참여자의 설명이며, 공식 문서로 확인된 내용은 아니다.

같은 참여자의 말에는 레포별로 적용되지 않는 글로벌 규칙까지 기본으로 불러와 시간이 오래 걸린다는 지적도 담겨 있었다. 8시 37분에는 최근 레포별 메모리를 긁어서 어떤 작업에 어떤 스킬과 MCP, 플러그인을 실제로 썼는지 점검한다는 설명이 이어졌다.

오전 9시 48분에는 다른 참여자가 클로드 코드(AI 코딩 도구)의 mods로 서브에이전트가 생성되는 모습을 클로드 코드 안에서 볼 수 있어 재밌다고 했다. 별도 오케스트레이션 대시보드를 만들 필요가 없어졌다는 말로, 지침 전달 여부와 직접 이어진 이야기는 아니다.

두 가지가 겹쳐 보인다. 지침이 많을수록 읽히지 않을 수 있다는 우려와, 실제로 쓴 것만 남기고 덜어내 보자는 점검 방식이다. 지침을 더 쓰는 방향이 아니라 덜어내고 확인하는 방향의 처방이 나온 것은 눈에 띈다. 토큰 소모 체감에서 출발한 대화가 지침 구조 점검으로 번진 점도 흥미롭다. 서브에이전트에 일을 맡기는 사람이 늘수록 지침 전달 여부를 어떻게 검증하느냐가 새 질문이 된다는 점을 시사한다. 다만 이 처방이 문제를 실제로 해결했는지는 이날 대화에서 확인되지 않았다.