서브에이전트 (Subagent)

서브에이전트(Subagent) 는 메인 대화와 분리된 자기 Context 안에서 실행되어 결과물만 되돌려주는 별도의 AI 실행 단위입니다. 비유하자면 자기 책상이 따로 있는 또 한 명의 동료 입니다. 내 책상 위 자료를 보지 못하고, 자기 책상에서 일을 마친 뒤 보고서만 건네줍니다.

재정의 — 본질은 일손이 아니라 격리다

서브에이전트를 처음 써보면 눈에 들어오는 것은 속도입니다. 경쟁사 세 곳을 각각 다른 에이전트에게 맡기면 세 개가 동시에 돌아가고, 메인 대화에는 조사 과정의 흔적 없이 보고서 세 개만 도착합니다. 이 경험 때문에 서브에이전트는 흔히 "동시에 여러 일을 시키는 기능"으로 이해됩니다.

하지만 실무에서 더 큰 값을 내는 쪽은 반대편입니다.

서브에이전트는 정보를 잃는 대가로 오염을 막는 거래 입니다.

메인 대화의 맥락을 못 본다는 것은 손실이지만, 동시에 앞 단계에서 만들어진 해석·가정·중간 결과에 물들지 않는다는 뜻이기도 합니다. 그리고 검증에서는 이 손실이 정확히 이득이 됩니다.

왜 셀프 검토는 관대해지는가

AI에게 "네가 만든 걸 검토해줘"라고 시키면 대개 통과합니다. 게으르거나 편향돼서가 아니라 구조 때문입니다.

작업이 길어지면 메인 Context에는 원본 자료뿐 아니라 그동안 AI가 만들어낸 해석·추론·가정·중간 결과가 함께 쌓입니다. 모델 입장에서 이것들은 전부 같은 자격의 정보 입니다. 원본 사실과 자기가 만든 해석이 구분되지 않은 채로 섞이고, 시간이 지나면 자기 해석을 새로운 사실처럼 다시 참고하게 됩니다.

이 상태에서 검토를 시키면 이런 일이 벌어집니다.

작성 단계  "고객 예산은 10억 원이다"      ← 실제로는 1억 원
                    ↓ 같은 Context
검토 단계  "10억 원 기준으로 구성이 적절하다"
           → 원본에서 예산을 다시 확인하지 않았다
           → 앞서 만든 결과 위에서 논리적 일관성만 검사했다

즉 사실 검증이 아니라 자기 일관성 검증 입니다. 그리고 자기 일관성 검증은 거의 항상 통과합니다. 앞뒤가 맞게 쓰는 것이 모델이 가장 잘하는 일이기 때문입니다.

서브에이전트는 이 고리를 물리적으로 끊습니다. 검증 서브에이전트는 결과물과 기준만 받습니다. 그 결과물이 어떤 과정을 거쳐 나왔는지, 중간에 어떤 가정이 있었는지 모릅니다. 그래서 기준과 대조하는 것 외에 할 수 있는 일이 없습니다. 이 제약이 검증의 품질을 만듭니다.

이것이 검증 Loop에서 "깨끗한 책상에서 검증한다"고 말하는 자리이며, 사람에게 적용하면 휴먼 인 더 루프에서 검토자가 원본을 봐야 하는 이유와 정확히 같은 원리입니다.

Skill과 서브에이전트 — 무엇으로 만들 것인가

둘 다 파일 하나로 정의된다는 점은 같습니다. 다른 것은 실행될 때 무엇을 받는가입니다.

실무 판정은 이 질문 하나로 대체로 끝납니다. "이 작업은 지금까지의 맥락을 알아야 잘하는가, 몰라야 잘하는가?"

• 알아야 잘한다 → Skill. 우리 팀 보고 형식대로 초안을 쓰는 일, 앞선 논의를 반영해 문서를 다듬는 일.
• 몰라야 잘한다 → 서브에이전트. 결과물을 기준과 대조하는 일, 서로 영향을 주면 안 되는 조사들.

처음부터 서브에이전트로 시작할 필요는 없습니다. 하나의 Skill에 업무 노하우를 충분히 담는 것에서 출발하되, 하나의 Skill은 하나의 작업만 맡긴다는 원칙을 지키다가 아래 신호가 나타날 때 분리하면 됩니다.

• 여러 Skill을 조합해야 한다
• 상황에 따라 실행 순서가 달라진다
• 중간 결과를 보고 방향을 바꿔야 한다
• 각 업무별로 필요한 권한이 다르다

관점이 없는 에이전트는 백과사전을 만든다

별도 설정 없이도 범용 에이전트가 기본 제공되기 때문에, 서브에이전트를 처음 쓰는 순간부터 병렬 조사는 바로 됩니다. 문제는 그 결과물입니다. 조사 보고서를 읽어보면 어느 회사 기획팀에 줘도 똑같을 내용 인 경우가 대부분입니다.

이유는 단순합니다. 무엇을 확인해야 하는지 알려주지 않았기 때문입니다. 전용 에이전트를 만들 때는 최소한 다음 다섯 가지가 들어가야 합니다.

1. 이름 — 무엇을 하는 에이전트인가
2. 역할 — 어떤 입장에서 보는가
3. 조사·판단 관점 — 무엇을 중심으로 볼 것인가
4. 반드시 확인할 것 — 빠지면 안 되는 항목
5. 결과물 형식 — 어떤 형태로 내놓는가

같은 회사를 조사해도 신뢰도 관점(업력·사건사고·평판 → 리스크 등급표), 비즈니스 현황 관점(매출·제품 라인업·주요 고객 → 현황 요약표), 신사업 방향성 관점(최근 발표·채용·투자 → 방향성과 근거)으로 나누면 결과의 깊이가 완전히 달라집니다. 관점이 다르면 결과가 다릅니다.

검증 에이전트라면 여기에 하나가 더 붙습니다. 통과 조건을 판정 가능한 문장 으로 적어야 합니다. "잘 썼는지 봐줘"가 아니라 "결론이 첫 3줄 안에 있는가 / 모든 주장에 숫자 근거가 있는가 / 예상 질문에 대한 답이 포함됐는가"처럼, 예·아니오로 답할 수 있어야 검증이 성립합니다.

서브에이전트를 쓰면 오히려 손해인 경우

격리는 공짜가 아닙니다. 아래 상황에서는 메인 대화에서 처리하는 편이 낫습니다.

• 맥락 의존도가 높은 작업 — 그동안의 결정과 논의 흐름을 계속 참고해야 하는 일. 격리된 곳으로 보내면 이미 정리된 전제를 처음부터 다시 설명해야 합니다.
• 한 번에 끝나는 짧은 작업 — 전달 비용이 작업 자체보다 큽니다.
• 중간에 방향을 자주 바꿔야 하는 작업 — 서브에이전트는 결과물만 돌려주므로 진행 중에 개입하기 어렵습니다.
• 기준이 아직 없는 작업 — 검증 에이전트를 만들어도 대조할 기준이 없으면 또 하나의 인상 평가가 될 뿐입니다.

마지막 항목이 실무에서 가장 자주 걸립니다. 서브에이전트를 늘려도 품질이 안 오른다면 대개 에이전트가 부족한 게 아니라 통과 기준이 없는 것 입니다.

서브에이전트 설계 체크리스트

• 이 작업이 앞선 맥락을 몰라야 더 잘하는 작업임을 설명할 수 있다
• 에이전트에 관점(무엇을 중심으로 볼지)이 적혀 있다
• 반드시 확인할 항목과 결과물 형식 이 지정되어 있다
• 검증용이라면 통과 조건이 예·아니오로 판정 가능 하다
• 반복 실행 시 최대 횟수 가 정해져 있다 (무한 반복 방지)
• 결과물을 최종적으로 사람이 되돌릴 수 있는 지점이 있다

이 여섯 개가 채워지면 서브에이전트는 일손이 아니라 품질 장치가 됩니다. 채워지지 않은 채로 개수만 늘리면 검토할 결과물만 늘어납니다.