← 목록으로

멀티 에이전트 소환

/goal 한 줄을 선언하면, Claude가 에이전트 팀을 꾸려 끝까지 갑니다

하네스 엔지니어링 도구 멀티 에이전트 소환
한 세션의 한계

큰 일을 대화 한 세션에 다 넣으면, 세 가지 방식으로 무너집니다

짧은 질문과 답은 대화 한 번으로 충분합니다. 그런데 "교재 전체를 검수해서 고쳐라" 같은 큰 일을 한 대화에 다 넣으면, 아무리 좋은 모델도 앞에서 한 약속을 잊고, 서로 다른 작업이 섞이고, 절반쯤에서 끝났다고 말합니다. 모델의 성능 문제가 아니라 혼자 끝까지 가려는 구조의 한계입니다.

😴

에이전트 게으름

일을 끝까지 하지 않고 절반쯤에서 "다 했다"며 멈춥니다.

Agentic laziness · 10개를 시켰는데 3개만 하고 마무리
🪞

자기 편향

다른 가능성보다 자기가 먼저 낸 결론을 계속 옳다고 여깁니다.

Self-preferential bias · 자기 답을 자기가 후하게 평가
🎯

목표 표류

대화가 길어지는 사이에 처음 받은 목표에서 조금씩 멀어집니다.

Goal drift · 긴 작업 끝에 다른 일을 하고 있음

처방은 두 가지입니다. 목표를 선언해 고정하고, 일을 팀으로 나눕니다.
이 두 가지를 한 줄로 거는 명령이 /goal입니다.

출처: Anthropic, "A harness for every task: dynamic workflows in Claude Code" · 원문

/goal 선언

지시가 아니라 목표를 선언합니다

보통의 지시는 "이것을 해 주세요"입니다. Claude가 답을 한 번 내놓으면 거기서 끝납니다. /goal은 종료 기준 자체를 바꿉니다. 목표를 선언하면 Claude는 "답을 다 했습니다"가 아니라 "조건이 달성됐습니다"를 끝으로 삼습니다. 멈추려 할 때마다 목표가 정말 달성됐는지 검사받기 때문에, 중간에 그만두지 못하고 끝까지 갑니다.

지시: 한 번 답하면 끝

"보고서 초안 주세요"
  • 초안 하나를 내놓으면 임무 완료
  • 품질이 기준에 미치는지는 묻지 않음
  • 부족하면 사람이 다시 시켜야 함

목표 선언: 조건 달성까지

"이 교재를 임원 눈높이의 최고 수준으로 만들어라"
  • 멈추려 할 때마다 달성 여부를 검사받음
  • 미달이면 스스로 다음 작업을 이어감
  • 사람은 목표와 최종 판정만 맡음
한 문장으로

/goal은 "무엇을 해라"가 아니라 "어떤 상태가 되면 끝났다고 인정하겠다"를 거는 명령입니다. 일의 단위가 답변 한 개에서 목표 달성으로 바뀝니다.

팀 설계
다이내믹 워크플로우 목표를 받은 Claude가 작업을 분해해 에이전트 팀을 직접 짭니다

조직도는 AI가 그립니다

목표를 선언하면 Claude는 일을 쪼개고, 단계마다 필요한 에이전트(또 다른 Claude)를 소환해 역할을 나눕니다. 사람이 팀 구성을 설계할 필요가 없습니다. 이렇게 작업마다 새로 짜는 일 처리 계획과 역할 분담을 하네스, 그 한 벌을 다이내믹 워크플로우라고 부릅니다. 검수 작업이라면 보통 이런 구조가 나옵니다.

🔍

검수

여러 관점이 병렬로
같은 대상을 살핌

🧩

통합

발견을 모아 중복 제거
우선순위 확정

🔧

수정

파일별 병렬 수정
+ 전역 일괄 수정

⚖️

검증

별도 에이전트가
적대적으로 재검

이 구조 안에서 여섯 가지 핵심 패턴이 반복해서 쓰입니다. 앞의 둘은 일을 배치하는 뼈대고, 뒤의 넷은 품질을 끌어올리는 장치입니다. Claude는 작업마다 이 중 필요한 것을 골라 조합합니다.

1펼치고 합치기 (Fan-out)
과제 종합 (Synthesize)
검수와 수정 단계가 이렇게 움직입니다

일을 독립된 조각으로 펼쳐 여러 에이전트가 동시에 처리하고, 결과를 하나로 모읍니다. 여섯 관점의 검수도, 파일별 수정도 이 방식이라 사람이 순서대로 기다릴 필요가 없습니다.

2파이프라인 (Pipeline)
1단계 2단계 3단계 조각 A 조각 B 조각 C
여러 단계 작업이 이렇게 흐릅니다

조각마다 단계를 독립적으로 통과합니다. 빠른 조각은 앞 단계가 끝나는 즉시 다음 단계로 넘어가므로, 가장 느린 조각을 전원이 기다리는 일이 없습니다.

3적대적 검증 (Adversarial verification)
검증자 (Verifiers) 작업자 (Worker)
검증 단계가 이렇게 움직입니다

고친 에이전트와 별개의 에이전트가 결과를 깨뜨리려고 달려듭니다. 자기 답을 자기가 후하게 평가하는 자기 편향을 막는 장치입니다. 그래도 통과하면 신뢰도가 올라갑니다.

4심사위원단 (Judge panel)
A B C 독립 초안 3개 심사위원단 채택 장점 통합 (Synthesize)
정답이 하나로 정해지지 않은 설계에 씁니다

서로 다른 관점으로 초안 여러 개를 동시에 만들고, 별도 심사 에이전트들이 점수를 매깁니다. 1등안을 뼈대로 삼고 나머지 안의 좋은 점을 가져와 합칩니다.

5바닥까지 반복 (Loop-until-dry)
수색 찾기 (Find) 새 발견? 있음 → 다시 수색 없음 2회 연속 종료
빠짐없이 찾아야 하는 일에 씁니다

찾는 작업을 반복해서 돌리고, 새 발견이 두 차례 연속 나오지 않을 때 비로소 멈춥니다. "10개 찾으면 끝" 같은 고정 횟수로는 놓치는 꼬리까지 긁어냅니다.

6다각도 수색 (Multi-modal sweep)
대상 파일 구조로 수색 본문 내용으로 수색 고유명사로 수색 시간 순서로 수색
한 가지 검색 방식으로 부족할 때 씁니다

같은 대상을 서로 다른 방법으로 동시에 수색합니다. 각자는 다른 쪽이 뭘 찾았는지 모른 채 움직이고, 한 방식이 못 찾는 것을 다른 방식이 건져 올립니다.

용어 정리

하네스는 일 처리 계획과 역할 분담, 워크플로우는 그 작업용으로 새로 짠 하네스 한 벌입니다. /goal을 선언하면 Claude가 이 하네스를 그 자리에서 직접 짭니다. 코드를 쓰거나 설정할 일은 없습니다.

실전 사례

이 교재가 그렇게 만들어졌습니다

지금 보고 있는 페이지들이 거쳐 온 실제 기록입니다

/goal "비즈니스 리더 대상 Claude 완전 정복 가이드를 최고 수준으로 끌어올려라"

Claude는 이 한 줄을 받아 검수 에이전트를 여섯 개의 렌즈로 병렬 소환했습니다.

임원 독자 전략 컨설턴트 강의 운영 디자인 규약 AI 사실 정확성 한국어 문체
1
에이전트 22개

검수부터 검증까지, 한 번의 목표 선언으로 소환된 에이전트 수입니다.

2
37분 · 발견 81건

여섯 렌즈가 병렬로 교재 전체를 훑어 81건의 발견을 수집했습니다.

3
통합 43건 수정

중복을 제거하고 우선순위를 매겨 43건으로 통합한 뒤, 파일별 병렬 수정과 전역 일괄 수정으로 반영했습니다.

4
3중 검증

수정과 무관한 에이전트가 결과를 적대적으로 재검하는 검증을 세 차례 거쳤습니다.

이 과정에서 사람이 한 일은 두 가지입니다. 목표 한 줄을 선언한 것, 그리고 최종 결과를 판정한 것. 검수 항목을 정하고, 팀을 짜고, 일을 배분하고, 끝났는지 확인하는 일은 전부 Claude가 했습니다.

이 페이지도 마찬가지

지금 읽고 있는 이 페이지의 재구성도 두 번째 /goal 선언으로 진행됐습니다. 한 번 통한 방식은 다음 작업에서 그대로 다시 통합니다.

직접 해보기

Claude Code에서 /goal을 걸어 봅니다

목표 문장 하나를 다듬는 것이 이 실습의 전부입니다

1
Claude Code를 열고 /goal을 입력합니다

슬래시 명령창에 /goal을 치고 목표 문장을 적습니다. 별도 설치나 설정은 없습니다.

2
목표 문장을 검증 가능하게 적습니다

좋은 목표 문장의 조건은 세 가지입니다. 완료를 검증할 수 있게(끝났는지 기계적으로 판정 가능), 품질 기준 명시(어느 수준이면 합격인지), 범위 명시(어디까지 건드려도 되는지).

3
중간 보고를 받습니다

발견을 모은 시점, 수정 계획이 선 시점처럼 방향을 점검할 지점에서 보고하게 합니다. 진행 중에도 사람이 끼어들 자리를 미리 만들어 두는 것입니다.

4
최종 승인은 사람이 합니다

목표 달성 보고가 오면 결과를 직접 확인하고 판정합니다. 실행은 맡기되 판단은 넘기지 않는 것이 /goal 사용의 기본 자세입니다.

나쁜 목표 문장

"이 교재 좀 더 좋게 만들어줘"
  • "좋게"가 무엇인지 판정할 수 없음
  • 품질 기준이 없어 어디서든 멈출 수 있음
  • 범위가 없어 엉뚱한 파일까지 손댈 수 있음

좋은 목표 문장

"교재 페이지 전부를 임원 눈높이로 끌어올려라. 수치마다 출처가 있고, 오탈자와 깨진 링크가 0건이면 완료다. 이 폴더 밖은 건드리지 마라"
  • 완료 조건을 기계적으로 판정 가능
  • 품질 기준이 숫자로 명시됨
  • 건드릴 범위가 분명함
실전 /goal 템플릿
/goal (달성할 목표를 한 줄로 적는다)
  예) 이 폴더의 강의 자료 전체를 임원 보고 수준으로 끌어올려라

# 완료 조건 (이게 전부 충족돼야 끝난 것이다)
  · 모든 수치에 출처가 달려 있다
  · 오탈자와 깨진 링크가 0건이다
  · 페이지마다 핵심 메시지가 첫 화면에 보인다

# 범위
  · 이 폴더 안의 파일만. 다른 폴더는 건드리지 않는다

# 진행 방식
  · 발견을 모두 수집하면 통합 보고를 먼저 하고, 수정은 승인 후 진행하라
FAQ

자주 묻는 질문

/goal을 처음 쓸 때 가장 많이 나오는 질문들

일반 대화와 무엇이 다릅니까?
일반 대화는 한 세션 안에서 묻고 답하면 거기서 끝납니다. /goal은 목표를 선언하는 순간 에이전트 팀이 꾸려지고, 목표를 달성할 때까지 계획·실행·검증을 반복합니다. 짧은 질문은 대화로, 끝까지 완수해야 하는 큰 일은 /goal로 구분해 쓰는 것이 기본입니다.
진행 중에 멈추거나 방향을 바꿀 수 있습니까?
가능합니다. 목표 문장에 중간 보고 지점을 적어 두면 그 시점마다 사람이 진행 상황을 확인하고 방향을 조정할 수 있습니다. 보고 시점이 아니어도 언제든 직접 개입해 작업을 멈추거나 지시를 더할 수 있습니다.
비용은 얼마나 듭니까?
에이전트를 여럿 띄우는 만큼 일반 대화보다 토큰을 몇 배에서 수십 배까지 씁니다. 그래서 모든 일에 걸지 않고, 결과의 가치가 비용을 넘어서는 작업에만 겁니다. 교재 전체 검수, 대규모 자료 정리, 여러 출처 검증 같은 일이 여기에 해당합니다.
틀리면 누가 책임집니까?
사람입니다. /goal은 실행을 맡기는 것이지 판단까지 넘기는 것이 아닙니다. 그래서 중간 보고 지점과 최종 승인 단계를 목표 문장에 미리 적어 둡니다. 사람의 최종 판정 없이는 결과를 내보내지 않는 것이 원칙입니다.
어디까지 맡겨도 됩니까?
되돌릴 수 있는 일은 넓게, 되돌릴 수 없는 일은 좁게 맡깁니다. 문서 작성, 코드 수정, 분석처럼 결과를 검토하고 되돌릴 수 있는 작업은 끝까지 맡겨도 됩니다. 발송, 배포, 결제처럼 되돌리기 어려운 동작은 반드시 사람 승인을 사이에 둡니다.
출처

자동화 마무리

/goal 한 줄이 멀티 에이전트 팀을 소환합니다. 실전 트랙을 모두 봤다면, 인덱스로 돌아가 오늘 실습에서 걸어 볼 목표 한 줄을 정하세요.