한 명에서 한 팀으로

서브에이전트 만들기

바쁜 팀장이 모든 일을 혼자 쥐고 있으면 책상이 서류로 무너진다. 일부를 떼어 ‘이것만 해서 결과만 가져와’ 하고 다른 사람에게 맡기는 순간 숨통이 트인다. 서브에이전트가 바로 그 ‘다른 사람’이다.

지난 모듈에서 우리는 컨텍스트 윈도우가 꽉 차면 에이전트가 흐려진다는 걸 봤다. 서브에이전트는 그 문제의 가장 깔끔한 해법이다.

핵심은 ‘분리된 머리’다. 메인 에이전트가 “이 폴더의 로그 200개를 읽고 에러만 추려와”라고 시키면, 서브에이전트는 자기만의 깨끗한 컨텍스트에서 그 일을 한다. 그리고 200개 로그 원문이 아니라 추려낸 결론 한 줄만 메인에게 돌려준다.

메인의 책상은 깨끗하게 유지된다. 잡일의 부스러기는 서브의 책상에서 다 치워지고, 메인에게는 정제된 결과만 올라온다. 이게 9모듈에서 예고했던 ‘물리적 브레이크’의 실전 모습이다.

서브에이전트는 무엇으로 정의되나

거창할 게 없다. 서브에이전트 하나는 보통 짧은 정의 파일 한 장으로 만들어진다. 이름, 어떤 일을 맡는지, 어떤 도구를 쥘 수 있는지, 그리고 한 단락짜리 지시문이 전부다.

신입에게 업무를 넘길 때 적어주는 인수인계 메모를 떠올리면 된다. “너는 로그 분석만 한다. 파일 읽기 권한만 있고, 결과는 에러 목록으로만 보고해라.” 딱 그 정도다.

# 한 장짜리 서브에이전트 정의
name: 로그스캐너
description: 로그 파일을 읽고 에러·경고만 추려 보고
tools: 파일읽기, 검색

# 지시문
주어진 폴더의 로그를 읽고 ERROR/WARN 줄만 모아라.
원문을 그대로 옮기지 말고 "건수 + 대표 사례 3개"로 요약해
한 문단으로만 보고해라. 추측·수정 제안은 하지 마라.

서브에이전트

메인이 특정 작업을 떼어 맡기는 보조 에이전트. 자기만의 깨끗한 컨텍스트에서 일하고 결과만 돌려준다.

분리된 컨텍스트

서브의 작업 부스러기가 메인 책상에 쌓이지 않게 막는 ‘물리적 칸막이’.

정의 파일

이름·역할·도구·지시문을 담은 한 장짜리 인수인계 메모.

역할 분담 설계

사람을 다섯 명 뽑았다고 일이 다섯 배 빨라지진 않는다. 누가 무엇을 맡고, 어디서 일이 넘어가는지가 정해져 있어야 팀이다. 에이전트도 똑같다.

역할이 겹치면 둘이 같은 일을 두 번 하고, 비면 아무도 안 한 채로 결과가 나온다.

좋은 역할 분담의 첫 원칙은 ‘하나의 에이전트는 하나의 일만’이다. 자료를 모으는 에이전트, 초안을 쓰는 에이전트, 검토하는 에이전트를 따로 둔다. 한 명에게 “모아서 쓰고 검토까지 해”라고 하면, 자기가 쓴 글을 자기가 검토하는 셈이라 눈이 흐려진다.

두 번째 원칙은 ‘경계를 분명히’다. 각 에이전트에게 입력으로 무엇을 받고 출력으로 무엇을 내놓는지 못 박는다. 수집가는 ‘출처 목록’을 내놓고, 작성자는 그 목록만 입력으로 받는다. 손에서 손으로 넘어가는 물건의 모양이 정해져 있어야 조립 라인이 돈다.

역할을 나눌 때 자주 쓰는 묶음

• 수집가. 자료·파일·검색 결과를 모아 정돈된 목록으로 넘긴다. 판단은 하지 않는다.
• 작성자. 받은 자료로 본문을 만든다. 자료 밖의 사실은 지어내지 않는다.
• 검토자. 작성자가 만든 결과만 보고 흠을 잡는다. 고치진 않고 ‘무엇이 문제인지’만 보고한다.
• 팀장(오케스트레이터). 누구에게 무엇을 줄지 정하고, 결과를 모아 다음 사람에게 넘긴다. 직접 실무는 거의 하지 않는다.

오케스트레이션

오케스트라에 연주자만 많고 지휘자가 없으면 소음이다. 멀티에이전트도 누군가 ‘지금 누가 무엇을 할 차례인지’를 잡아줘야 음악이 된다. 그 지휘자가 오케스트레이터다.

오케스트레이터는 직접 악기를 켜지 않는다. 일을 쪼개고, 나눠주고, 받아서, 합친다.

흐름은 단순하다. 먼저 큰 목표를 작은 일감으로 쪼갠다(분해). 그 일감을 적합한 작업자에게 내린다(위임). 작업자가 결과를 돌려주면 모아서 빈틈을 살핀다(수집). 그리고 조각들을 하나의 결과물로 엮는다(통합).

대개 메인 에이전트가 이 지휘자 역할을 맡는다. 사용자의 부탁을 받아 “이건 수집가에게, 저건 작성자에게” 하고 배분한 뒤, 돌아온 조각을 직접 이어붙여 최종 답을 만든다. 사용자는 팀이 여럿인지도 모른 채, 잘 정리된 결과 하나만 받는다.

지휘자가 챙겨야 할 세 가지

가장 흔한 실패는 통합 단계에서 일어난다. 작업자 셋이 각자 멀쩡한 결과를 내도, 셋을 이어붙이면 말투가 따로 놀거나 같은 내용이 겹친다. 그래서 좋은 오케스트레이터는 위임만큼 ‘합치는 일’에 공을 들인다.

너는 이 작업의 팀장이야. 직접 다 하지 말고 아래 순서로 진행해.
1) 이 목표를 3~4개 작은 일감으로 쪼개서 먼저 보여줘.
2) 각 일감을 서브에이전트에게 맡겨 결과만 받아와.
3) 받은 결과들의 겹침·빈틈·말투 불일치를 네가 정리해서
   하나의 결과물로 합쳐줘. 합치는 과정에서 무엇을 손봤는지도 알려줘.

병렬·파이프라인

일을 나누는 방식은 크게 둘이다. 여럿이 동시에 따로 하느냐(병렬), 한 줄로 서서 차례로 넘기느냐(파이프라인). 일의 성격이 둘 중 무엇인지를 먼저 봐야 한다.

이 선택을 잘못하면, 빠를 수 있는 일을 줄 세워 늦추거나 줄 세워야 할 일을 동시에 시켜 엉킨다.

병렬 — 서로 안 기다려도 되는 일

작업들이 서로의 결과를 필요로 하지 않으면 동시에 보낸다. 회사 다섯 곳을 각각 조사하는 일은, 한 곳 조사가 끝나야 다음을 시작할 이유가 없다. 다섯을 한꺼번에 풀어두고 다 돌아오면 모은다. 이걸 팬아웃(부채처럼 펼쳐 내보냄)이라 부른다.

병렬의 보상은 시간이다. 다섯 일이 각각 1분이면, 차례로 하면 5분이지만 동시에 하면 1분 남짓이다.

파이프라인 — 앞사람 결과가 있어야 하는 일

반대로 ‘자료 수집 → 초안 작성 → 검토 → 다듬기’처럼 뒷일이 앞일의 결과를 입력으로 쓰면 한 줄로 세운다. 검토자는 초안이 나오기 전엔 할 일이 없다. 억지로 동시에 시키면 검토자는 빈손으로 시작해 엉뚱한 걸 만든다.

판단 기준은 하나다. “이 일을 하려면 다른 일의 결과가 필요한가?” 필요 없으면 병렬, 필요하면 파이프라인. 실전에선 둘을 섞는다. 수집은 병렬로 다섯 곳을 동시에, 그다음 작성·검토는 파이프라인으로 차례차례.

팀으로 협업시키기

앞에서 배운 역할·지휘·흐름을 한데 모으면 ‘작은 팀’이 된다. 이제 진짜 일감 하나를 통째로 팀에게 던져보자.

혼자 하면 한 시간 걸릴 조사 보고서를, 팀으로 짜면 어떻게 돌아가는지 한 바퀴 따라가 본다.

예를 들어 “경쟁 제품 다섯 개를 조사해 한 장짜리 비교 보고서를 만들어줘”라는 일감을 보자. 팀장은 이걸 이렇게 굴린다. 먼저 수집가 다섯을 병렬로 풀어 제품마다 자료를 모은다. 자료가 다 돌아오면 작성자에게 넘겨 비교표 초안을 쓰게 한다. 그 초안을 검토자에게 보내 사실·일관성을 점검시킨 뒤, 팀장이 지적사항을 반영해 최종본을 낸다.

여기서 한 가지가 분명해진다. 사용자는 이 모든 과정을 몰라도 된다. 부탁 하나를 넣었고, 잘 정리된 보고서 하나를 받았을 뿐이다. 팀의 복잡함은 안에서 처리되고, 밖으로는 단정한 결과만 나온다.

1. 일감을 한 문장으로 정의한다“무엇을, 어떤 형태로” 끝나면 되는지 결과물의 모양을 먼저 못 박는다. 비교표 한 장인지, 보고서 세 쪽인지.
2. 팀장에게 통째로 맡긴다레슨 44의 ‘팀장 프롬프트’를 써서 분해·위임·통합을 팀장이 알아서 하게 한다.
3. 중간 산출물을 한 번 들여다본다수집가가 모은 자료 목록이나 초안을 한 번 확인하면, 엉뚱한 방향을 일찍 잡을 수 있다.
4. 최종본을 받고 검토자의 보고를 같이 읽는다결과물만 보지 말고, 검토자가 뭘 지적했고 어떻게 반영됐는지를 함께 본다.

검증 에이전트

글을 쓴 사람이 자기 글의 오탈자를 잘 못 잡는다. 너무 익숙해서다. 그래서 회사엔 따로 검수 담당이 있다. 에이전트 팀에도 ‘만든 사람과 분리된 검사역’이 필요하다.

작성자에게 “네 글 한 번 검토해봐”라고 하면 대개 “문제 없습니다”가 돌아온다. 자기 눈으론 안 보인다.

검증 에이전트는 작성자가 만든 결과만 보고 흠을 찾는다. 작성자가 어떤 의도였는지, 무슨 고생을 했는지 모른다. 오직 산출물과 ‘무엇을 만족해야 하는가’라는 기준만 본다. 이 무지가 오히려 강점이다. 변명을 들어줄 맥락이 없으니 결과를 결과로만 판정한다.

검증의 핵심은 ‘체크리스트’다. 두루뭉술하게 “좋은지 봐줘”가 아니라, 만족해야 할 조건을 항목으로 못 박아 하나씩 통과/실패를 매기게 한다. 그래야 “느낌상 괜찮다”가 아니라 “3번 항목 불충족”이라는 판정이 나온다.

검증 에이전트가 보는 것

• 사실성. 자료에 없는 내용을 지어내지 않았는가. 출처와 본문이 어긋나지 않는가.
• 요구 충족. 처음 시킨 조건(형식·분량·항목)을 다 지켰는가. 빠진 항목은 없는가.
• 내부 일관성. 앞뒤가 서로 모순되지 않는가. 같은 수치가 두 곳에서 다르지 않은가.

너는 검증 담당이야. 아래 결과물을 "만든 사람의 사정은 모른 채" 결과만 보고 판정해.
체크리스트로 하나씩 통과/실패를 매기고, 실패엔 근거를 한 줄씩 달아줘.
- 자료에 없는 내용을 지어냈는가? (사실성)
- 처음 요구한 형식·분량·항목을 다 지켰는가? (요구 충족)
- 앞뒤 모순·중복·수치 불일치가 있는가? (일관성)
고치지는 말고, 무엇이 왜 문제인지만 보고해. 통과면 "통과"라고만 답해.

적대적 검증·품질 게이트

검사역 한 명도 가끔 졸거나 놓친다. 정말 중요한 결과는, 서로 모르는 검사역 여럿에게 따로 보내 ‘다수가 통과시켰을 때만’ 내보낸다. 이게 품질 게이트다.

한 명이 “통과”라고 해서 그냥 통과시키면, 그 한 명이 틀렸을 때 막을 사람이 없다.

적대적 검증 — 일부러 흠을 찾게 한다

적대적 검증은 검사역에게 ‘이건 틀렸다고 가정하고 흠을 찾아내라’는 임무를 준다. 통과시키려 애쓰는 게 아니라, 떨어뜨릴 이유를 적극적으로 사냥하게 한다. 변호사가 아니라 깐깐한 반대신문자를 붙이는 셈이다.

여기에 ‘서로 모르게’를 더한다. 검사역 셋에게 같은 결과물을 따로따로 보내, 서로의 판정을 보지 못하게 한다. 그러면 한 명이 놓친 흠을 다른 두 명이 잡을 가능성이 커진다. 한 검사역의 착각이 전체로 번지지 않는다.

품질 게이트 — 다수결로 문을 연다

모인 판정을 다수결로 모은다. 셋 중 둘 이상이 통과시켜야 문이 열리고, 그렇지 않으면 결과물은 작성자에게 되돌아가 다시 고쳐진다. 통과할 때까지 이 문 앞을 못 지나간다.

비유하면 비행기 출고 검사다. 검사관 한 명의 사인으로 띄우지 않는다. 여러 검사관이 각자 점검표를 들고 흠을 찾고, 정해진 수 이상이 ‘이상 없음’을 줘야 활주로로 나간다. 되돌리기 어려운 결과일수록 게이트를 높인다.