에이전트 운영 설계 노트 (3/9) — 에이전트 팀 설계 입문

-

에이전트 수를 늘린다고 팀이 자동으로 똑똑해지지는 않는다. 오히려 구조를 잘못 가르면 누가 책임지는지 흐려지고, 검증 비용이 커지고, 서로 다른 컨텍스트가 부딪히기 시작한다. 좋은 분리는 "더 복잡한 구조"가 아니라 "더 싼 실패"를 만드는 구조다.

핵심 요약

  • 기본값은 대체로 단일 에이전트가 맞다. 구조를 늘릴수록 조정 비용과 검증 비용이 함께 늘어난다.
  • 서브에이전트 분리는 역할 미학보다 소유 경계가 명확한가로 판단하는 편이 낫다.
  • 멀티에이전트는 병렬 처리보다 먼저 충돌 관리 비용을 감당할 수 있을 때만 값이 난다.
  • 좋은 팀 설계는 "몇 개로 나눌까"보다 누가 수정권을 갖는가, 누가 검증 책임을 지는가, 누가 최종 컨텍스트를 합치는가를 먼저 정한다.
  • 실제 운영에서 가장 자주 깨지는 지점은 추론 품질보다 컨텍스트 충돌, 중복 작업, 검증 누락, 책임 불명확이다.

1. 먼저 용어를 작게 정리하자

이 글에서는 세 구조를 실무적으로만 구분한다.

  • 단일 에이전트: 하나의 작업 맥락 안에서 계획, 실행, 점검을 모두 처리하는 구조
  • 서브에이전트: 메인 에이전트가 범위를 좁게 잘라 위임하고 다시 결과를 회수하는 구조
  • 멀티에이전트: 여러 에이전트가 각자 비교적 독립적인 역할과 상태를 가지고 협력하는 구조

중요한 점은 이름보다 책임이다. Anthropic 문서에서 말하는 subagent는 별도 컨텍스트 창과 허용 도구 범위를 가진 위임 단위에 가깝고, OpenAI Agents SDK의 handoff는 대화를 다른 전문 agent가 이어받는 구조에 가깝다. 어떤 시스템은 UI에서는 "멀티에이전트"처럼 보여도 실제로는 메인 에이전트의 확장된 도구 세트에 가까울 수 있고, 반대로 겉으로는 단일 에이전트처럼 보여도 내부적으로는 검증자, 실행자, 라우터가 분리돼 있을 수 있다.

그래서 실무 질문은 "우리는 멀티에이전트인가"가 아니라 아래에 가깝다.

  1. 누가 어떤 자산을 수정할 수 있는가
  2. 누가 검증 실패를 책임지는가
  3. 누가 최종 판단 전에 컨텍스트를 합치는가

2. 왜 대부분의 팀은 단일 에이전트에서 시작해야 하나

단일 에이전트의 가장 큰 장점은 단순함이 아니라 충돌이 한 화면에 드러난다는 점이다.

계획이 흔들리면 프롬프트나 지시를 다시 보면 된다. 파일을 잘못 건드리면 작업 범위를 좁히면 된다. 검증이 빠졌으면 같은 흐름 안에서 보강하면 된다. 즉, 문제의 위치가 비교적 잘 보인다.

반대로 구조를 나누기 시작하면 문제가 곧바로 두 종류로 늘어난다.

  • 원래 작업 자체의 문제
  • 에이전트 간 조정 문제

많은 팀이 두 번째 비용을 과소평가한다. 역할을 둘로 나누면 추론이 둘 배가 되는 것이 아니라, 대체로 아래 비용이 새로 생긴다.

  • handoff 포맷 설계
  • 중복 컨텍스트 전달
  • 결과 병합 기준
  • 검증 책임 배치
  • 실패 시 재시도 경로

그래서 단일 에이전트의 한계가 명확히 보이기 전에는, 구조를 늘리기보다 먼저 아래를 조정하는 편이 더 싸다.

  • 작업 범위 축소
  • 체크리스트 추가
  • 중간 검증 삽입
  • 읽기 전용 단계와 수정 단계 분리

3. 서브에이전트는 언제 유효한가

서브에이전트는 단일 에이전트와 멀티에이전트 사이의 중간 구조로 보는 편이 실용적이다. 핵심은 "역할이 다르다"가 아니라 경계가 짧고 회수가 쉽다는 점이다.

서브에이전트가 잘 맞는 상황은 대체로 이렇다.

  • 특정 파일군만 조사하면 되는 경우
  • 독립적인 초안 후보를 여러 개 뽑아 비교하고 싶은 경우
  • 메인 흐름을 멈추지 않고 배경 조사나 보조 검토를 맡기고 싶은 경우
  • 결과물이 요약, 리스트, 후보안처럼 병합하기 쉬운 형태인 경우

반대로 아래라면 서브에이전트 분리가 잘 안 맞는다.

  • 여러 서브에이전트가 같은 파일을 만져야 하는 경우
  • 결과 해석 기준이 모호한 경우
  • 검증 없이 바로 반영되기 쉬운 경우
  • 메인 에이전트가 각 결과를 다시 길게 읽고 판단해야 하는 경우

즉 서브에이전트는 "작업을 덜어 주는 존재"가 아니라, 메인 에이전트의 컨텍스트 부담을 줄이는 압축 장치여야 한다. 회수한 결과가 다시 긴 문맥 덩어리로 돌아오면 분리 이득이 거의 없다.

4. 멀티에이전트는 언제 필요해지나

멀티에이전트가 의미를 가지는 순간은 대체로 역할 이름이 많아질 때가 아니라, 서로 다른 소유권과 검증 규칙이 동시에 필요해질 때다.

예를 들면 이런 경우다.

  • 생성자와 검증자를 의도적으로 분리해야 할 때
  • 외부 작업과 내부 승인 작업을 다른 권한으로 다뤄야 할 때
  • 장시간 비동기 작업을 여러 레인으로 운영해야 할 때
  • 각 에이전트가 보는 데이터나 도구 범위가 명확히 달라야 할 때

이때도 병렬화만 보고 멀티에이전트로 가면 자주 실패한다. 병렬 처리의 이점은 분명하지만, 병렬 상태에서 같은 사실을 서로 다르게 이해하는 순간부터 속도 향상이 조정 낭비로 바뀐다.

멀티에이전트는 결국 다음 질문에 답할 수 있을 때만 운영 가치가 있다.

  • 각 에이전트의 입력은 누가 보증하는가
  • 서로 모순되는 결과가 나오면 누가 우선권을 가지는가
  • 전체 실패를 어느 레이어에서 감지하는가
  • 최종 산출물의 저자는 누구인가

이 답이 없으면 시스템은 분업처럼 보여도 실제로는 책임 분산만 일어난다.

5. 첫 번째 기준: 소유 경계가 선명한가

에이전트 팀 설계에서 가장 먼저 봐야 할 것은 성능이 아니라 소유권이다.

좋은 분리는 보통 이런 문장으로 설명할 수 있다.

  • 이 에이전트는 탐색만 한다
  • 이 에이전트는 초안만 만든다
  • 이 에이전트는 검증만 한다
  • 이 에이전트는 지정된 파일 하나만 수정한다

나쁜 분리는 이런 식이다.

  • 둘 다 쓰기는 하는데 한쪽이 좀 더 전략적이다
  • 검토자이지만 필요하면 수정도 한다
  • 조사 담당이지만 급하면 최종안도 낸다

후자 구조는 초반에는 유연해 보이지만, 시간이 지나면 수정 충돌과 책임 회피가 같이 생긴다. 누가 무엇을 바꿀 수 있는지 불분명하면, 검증도 자연히 흐려진다.

실무에서는 권한을 기능보다 좁게 잡는 편이 좋다.

구조 권장 소유 방식
단일 에이전트 하나의 범위 안에서 읽기, 쓰기, 검증 책임을 일관되게 유지
서브에이전트 읽기 범위나 결과 형태를 좁게 고정
멀티에이전트 수정 권한, 승인 권한, 검증 권한을 명시적으로 분리

에이전트를 늘릴수록 "무엇을 할 수 있는가"보다 "무엇을 하면 안 되는가"를 더 선명하게 적어야 한다.

6. 두 번째 기준: 검증 비용이 줄어드는가, 늘어나는가

많은 설계가 여기서 뒤집힌다. 에이전트를 나누면 개별 역할은 더 또렷해질 수 있지만, 전체 결과를 믿기 위해 필요한 검증은 오히려 더 많아질 수 있다.

예를 들어 단일 에이전트는 아래 정도면 검증이 끝날 수 있다.

  • 범위 준수 여부 확인
  • 형식 확인
  • 핵심 주장 확인

그런데 서브에이전트나 멀티에이전트가 되면 여기에 추가로 이런 비용이 붙는다.

  • handoff 누락 여부 확인
  • 에이전트별 전제 차이 확인
  • 중복 수정 또는 상충 수정 확인
  • 병합 후 의미 왜곡 확인

즉 검증은 "마지막에 한 번"이 아니라 구조에 따라 층이 생긴다.

  1. 각 에이전트 내부 검증
  2. handoff 검증
  3. 병합 검증
  4. 최종 산출물 검증

이 비용을 감당할 준비가 없으면, 에이전트 수를 늘리는 대신 단일 흐름 안에 검증 체크포인트를 넣는 편이 더 낫다.

실무 판단은 단순하다.

  • 분리 후 검증이 더 싸지면 분리
  • 분리 후 검증이 더 비싸지면 보류

7. 세 번째 기준: 컨텍스트 충돌을 줄이나, 키우나

에이전트 설계에서 실제로 자주 터지는 문제는 "모델이 멍청해서"가 아니라 서로 다른 문맥이 동시에 살아남아 충돌하는 것이다.

컨텍스트 충돌은 대체로 네 형태로 나타난다.

  • 같은 작업 목표를 다르게 해석한다
  • 같은 파일 상태를 다르게 기억한다
  • 최신 결정을 일부 에이전트만 반영한다
  • 같은 용어를 다른 의미로 쓴다

단일 에이전트에서는 이런 충돌이 한 흐름 안에서 드러난다. 그러나 멀티에이전트에서는 서로 그럴듯한 중간 결과를 만든 뒤 마지막에 충돌하는 경우가 많다. 이때 비용이 큰 이유는, 각 결과가 이미 "꽤 완성돼 보인다"는 데 있다.

그래서 컨텍스트 충돌을 줄이려면 에이전트를 늘리기 전에 아래부터 정리하는 편이 좋다.

  • 공통 목표 문장을 짧게 고정하기
  • 수정 가능 파일을 미리 못 박기
  • 최신 결정 사항을 한 문단으로 요약하기
  • 결과 반환 형식을 고정하기

서브에이전트가 효과적인 경우는 대개 컨텍스트를 넓히는 것이 아니라 문맥을 잘라 내는 경우다. 반대로 멀티에이전트가 실패하는 경우는 서로에게 너무 많은 자유 문맥을 주는 경우가 많다.

8. 실전 판단표: 언제 갈라야 하나

아래 표는 구조 선택을 과장 없이 정리한 것이다.

상황 단일 에이전트 서브에이전트 멀티에이전트
작업 범위가 작고 명확함 가장 적합 과함 과함
조사와 초안을 느슨하게 분리하고 싶음 가능 적합 대체로 과함
같은 자산을 여러 역할이 동시에 만짐 위험 대체로 부적합 엄격한 조정 없이는 위험
검증자와 실행자의 독립성이 중요함 제한적 보조적 적합 가능
병렬화 이점이 큼 제한적 조건부 적합 가능
컨텍스트 최신성 유지가 어려움 상대적으로 유리 주의 가장 취약
운영 규칙과 승인 경계가 복잡함 빠르게 비대해질 수 있음 조건부 적합 가능

권장 기본값은 대체로 다음 순서다.

  1. 단일 에이전트로 시작
  2. 조사나 후보안 생성처럼 회수 쉬운 작업만 서브에이전트로 분리
  3. 소유권과 검증 경계를 명시할 수 있을 때만 멀티에이전트 도입

9. 흔한 오해 세 가지

오해 1. 역할 이름이 많으면 더 정교하다

대부분은 아니다. 이름을 늘리는 것보다 실패 경로를 줄이는 편이 더 중요하다.

오해 2. 병렬화는 항상 생산성을 높인다

병렬화는 병합 비용이 낮을 때만 이득이다. 병합이 비싸면 그냥 동시에 복잡해질 뿐이다.

오해 3. 검증자는 따로 두면 자동으로 품질이 오른다

검증자가 독립적으로 유효하려면 입력 기준, 체크리스트, 판정 권한이 함께 정의돼야 한다. 이름만 검증자여서는 품질 체계가 되지 않는다.

10. 작게 시작하는 팀을 위한 설계 체크리스트

에이전트를 나누기 전에 아래 다섯 가지에 답하면 과잉 구조를 많이 줄일 수 있다.

  1. 지금 가장 비싼 실패는 생성 품질 문제인가, 조정 실패 문제인가
  2. 새 에이전트를 추가하면 누가 어떤 파일이나 상태를 소유하는가
  3. 분리 후 검증 단계가 실제로 줄어드는가, 오히려 늘어나는가
  4. 서로 다른 에이전트가 같은 최신 결정을 안정적으로 공유할 수 있는가
  5. 충돌이 났을 때 최종 우선권을 가진 주체가 명확한가

이 질문에 답하기 어렵다면, 아직은 구조를 늘릴 타이밍이 아닐 가능성이 크다.

마무리

단일 에이전트, 서브에이전트, 멀티에이전트는 성숙도 단계처럼 보이기 쉽지만 실제로는 그렇지 않다. 더 많은 에이전트가 더 높은 단계라는 보장은 없다. 운영 관점에서 더 중요한 것은 복잡도를 어디에 두는지다.

좋은 분리는 협업 감각을 흉내 내는 구조가 아니라, 책임을 더 또렷하게 만들고 검증을 더 싸게 만들고 컨텍스트 충돌을 더 일찍 드러내는 구조다. 그 기준으로 보면 많은 팀의 다음 단계는 멀티에이전트가 아니라, 더 명확한 소유 경계와 더 싼 검증 설계일 수 있다.

함께 읽으면 좋은 글

참고 자료

시리즈 전체 안내: 시리즈 목차

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »