일하는 ai

16. 스킬 없는 멀티에이전트

9 min read

-

한 줄 결론: 스킬 없는 멀티에이전트는 분업이 아니라 역할극에 가깝습니다. “기획자 에이전트”, “개발자 에이전트”, “검수자 에이전트”라는 이름만 붙여도 그럴듯해 보이지만, 각자가 어떤 입력을 받고 어떤 절차로 판단하며 어떤 기준으로 완료하는지가 없으면 결과는 쉽게 흔들립니다.

안내: 이 글은 메이커 에반 영상의 핵심 주장과 Claude Code/Anthropic 공개 문서를 바탕으로, 실무자가 바로 적용할 수 있는 판단 기준으로 재구성했습니다.

왜 이 글이 필요한가

멀티에이전트는 보기에는 멋집니다. 역할을 여러 개로 나누면 사람 팀처럼 일할 것 같고, 병렬 실행으로 속도도 빨라질 것처럼 보입니다. 하지만 실제 운영에서는 다음 문제가 먼저 터집니다.

  • 역할 이름은 있는데 작업 절차가 없다.
  • 각 에이전트가 같은 완료 기준을 공유하지 않는다.
  • 중간 결정과 가정이 다음 에이전트에게 전달되지 않는다.
  • 결과물을 합칠 때 기준 충돌이 뒤늦게 발견된다.

그래서 먼저 설계해야 할 것은 에이전트 숫자가 아니라 스킬, 컨텍스트, 완료 기준입니다.

영상 핵심 요약

  1. 역할 이름은 능력을 만들지 않는다
    CFO, 개발자, PM 같은 이름을 붙여도 실제 판단 절차와 근거가 없으면 역할극에 머문다.

  2. 스킬은 반복 가능한 작업 단위다
    스킬은 단순 프롬프트 묶음이 아니라, 언제 실행하고 무엇을 읽고 어떤 순서로 검증할지 담은 작업 절차다.

  3. 멀티에이전트는 스킬 이후에 열어야 한다
    각 에이전트가 맡을 스킬과 산출물 기준이 정리된 뒤에 병렬화해야 충돌을 줄일 수 있다.

역할극과 스킬 기반 분업의 차이

구분역할극 멀티에이전트스킬 기반 멀티에이전트
역할 정의“너는 기획자야”처럼 이름 중심입력, 절차, 산출물, 검증 기준 중심
컨텍스트대화마다 즉흥적으로 전달필요한 자료와 규칙을 스킬에 고정
완료 기준좋게 만들어줘, 검토해줘어떤 조건이면 통과인지 명시
실패 복구다시 해봐실패 원인을 스킬/체크리스트에 반영
확장성에이전트가 늘수록 충돌 증가역할별 계약이 있어 병렬화 가능

핵심은 “몇 명의 에이전트가 있느냐”가 아니라, 각 에이전트가 반복 가능한 일의 단위를 가지고 있느냐입니다.

먼저 만들어야 할 3가지

1) 작업 계약

각 에이전트가 시작하기 전에 아래 4가지를 고정합니다.

  • 입력: 무엇을 받아야 시작할 수 있는가
  • 출력: 어떤 형태로 결과를 내야 하는가
  • 금지: 무엇을 임의로 바꾸면 안 되는가
  • 완료: 어떤 검증을 통과해야 끝인가

2) 스킬 또는 체크리스트

같은 역할을 2번 이상 반복할 예정이면 대화 프롬프트가 아니라 스킬로 빼는 편이 낫습니다.

  • 조사 스킬: 출처 우선순위, 인용 방식, 검증 기준
  • 구현 스킬: 테스트 순서, 파일 수정 규칙, 실패 복구법
  • 리뷰 스킬: 보안, 품질, 회귀 위험, 문서화 기준

3) trace 공유 방식

멀티에이전트에서 빠지는 것은 원문 지시문이 아니라 중간 결정의 이유입니다. 다음 에이전트에게는 결과물만 넘기지 말고 아래를 함께 넘겨야 합니다.

  • 방금 확정한 결정
  • 버린 대안과 이유
  • 남은 불확실성
  • 다음 단계에서 건드리면 안 되는 조건

멀티에이전트를 열어도 되는 조건

아래 조건을 만족하면 병렬화해도 됩니다.

  • 작업이 서로 독립적이다.
  • 공유해야 할 결정이 3~5개 문장으로 정리되어 있다.
  • 각 에이전트의 산출물 형식이 고정되어 있다.
  • 마지막 통합자가 충돌을 판단할 기준을 가지고 있다.

반대로 아래 상황이면 단일 흐름으로 가는 편이 안전합니다.

  • 요구사항이 아직 흔들린다.
  • 데이터 스키마, UI 톤, 문서 용어처럼 공통 기준이 정해지지 않았다.
  • “검수자 에이전트가 알아서 잡아주겠지”에 기대고 있다.
  • 실패했을 때 어느 에이전트의 판단이 원인인지 추적할 수 없다.

20분 개선 루틴

  1. 오늘 반복되는 작업 하나를 고른다.
  2. 그 작업의 입력, 출력, 금지, 완료 기준을 4줄로 쓴다.
  3. 기존 프롬프트에서 매번 반복하던 규칙을 체크리스트로 분리한다.
  4. 한 번 실행한 뒤 실패 원인 1개를 체크리스트에 반영한다.
  5. 같은 작업을 다른 에이전트에게 맡겨도 결과 형식이 유지되는지 확인한다.

이 루틴이 통과되기 전에는 에이전트를 늘리지 않는 것이 좋습니다.

실패 신호

  • 에이전트 이름은 많은데 산출물 형식이 제각각이다.
  • 리뷰 단계에서 “왜 이렇게 판단했는지”를 설명하지 못한다.
  • 병렬화 후 통합 시간이 더 길어진다.
  • 같은 실패가 다음 실행에서도 반복된다.
  • 스킬이나 체크리스트에 남는 개선 기록이 없다.

다음 읽기

영상 메타

그래프 뷰

백링크