한 편으로 끝내기: 2026 단일 에이전트에서 멀티 에이전트 파이프라인까지

작년 B2B SaaS 팀과 함께 「올인원 고객지원 Agent」를 만들었습니다. system prompt 하나에 프리세일즈·애프터세일즈·견적·장애 대응 네 페르소나와 20페이지 FAQ를 넣었죠. 첫 주 NPS는 좋았습니다. 3주차엔 환불 티켓 안에서 업셀을 쫓고, 내부 코드명을 고객에게 그대로 보냈습니다.

아무도 모델이 멍청하다고 하지 않았습니다. 문제는 단순했어요: 네 자리 일을 한 명에게 몰아준 것. 2026년 업계 공감대는 굳어 가고 있습니다——단일 에이전트가 쓸모없는 건 아니지만, 경계가 뚜렷하고 툴체인이 짧은 일에 맞습니다. 조사→스펙→코드→테스트→리뷰→배포처럼 다단계·병렬·상호 수정이 필요하면 멀티 에이전트 파이프라인을 진지하게 그려야 합니다.

Agent 백과사전은 생략하고, OpenClaw·IDE Agent·내부 PoC에서 본 이전 경로만 다룹니다. 메모리와 비용이 걱정이면 Agent Memory vs 채팅 기록, 팀 Agent 비용도 함께 보세요.

단일 에이전트 시대: 「연기」는 잘하지만 「협업」은 약함

초기 Agent 제품은 system prompt 전문성과 페르소나 전환 매끄러움으로 경쟁했습니다. 「시니어 아키텍트」「독설 리뷰어」「다정한 PM」을 문단에 쓰면 한 스레드에서 말투가 바뀝니다——이게 단일 에이전트 역할 연기입니다.

장점은 분명합니다: 배포 간단, trace 한 줄, 디버깅 쉬움. Cursor, Claude Code, 커스텀 GPT가 2024–2025년에 이 길을 밀었죠.

한계도 똑같이 분명합니다:

• 컨텍스트 오염——조사 메모, diff, 테스트 로그가 한 창에 섞여 뒤 단계가 앞 노이즈에 끌림.
• 책임 모호——실패 시 계획 vs 실행 구분이 안 되고 한 단계만 재실행하기 어려움.
• 병렬도 제로——모델은 한 줄 사고. 실제 팀은 조사·구현·테스트를 동시에 함.
• 권한 분리 어려움——코드 Agent와 프로덕션 DB Agent에 같은 툴 권한을 주고 싶지 않음. 단일 prompt로는 세밀히 못 나눔.

일이 「질문 답하기」에서 「머지 가능한 PR 내기」로 바뀌면 prompt를 두껍게 할수록 효용이 급감합니다. 모델 퇴보가 아니라 문제 형태가 엔지니어링 과제가 된 것——분업·인수인계·리플레이가 필요합니다.

멀티 에이전트 시대: 「한 명 천 가면」에서 핸드셰이크로

멀티 에이전트 협업은 비유를 바꿉니다. 같은 배우가 가면을 바꾸는 게 아니라 무대 위 여러 역이 대본과 연출로 이어짐. Planner는 분해만, Coder는 허용 경로만, Reviewer는 diff 읽기 전용——「겸사겸사 두 줄 고침」 권한은 없음.

맞추는 세 가지:

• 공유 상태——계획, 파일 트리, 테스트 결과, TODO는 그래프 상태나 Memory Store에, 채팅에 흩뿌리지 않음.
• 구조화된 인수인계——이전 단계는 JSON/patch/checklist, 다음은 스키마 합격 필드만. 「위 참고」는 실행 불가.
• 종료와 중재——완료·사람 에스컬레이션·롤백은 Evaluator나 규칙 노드가, 마지막 Agent의 「됐어요」에 맡기지 않음.

만능 지원 봇을 Intent Router, FAQ Retriever, Ticket Writer, Escalation Guard로 쪼개니 고객-facing 내부 용어 오발송은 0——모델 교체가 아니라 Escalation Guard에 고객 발화 툴이 없었기 때문입니다.

단일 에이전트 내부: ReAct와 층 구조

팀으로 나누기 전 한 마리의 내장을 봅니다. LangChain, OpenAI Agents SDK, Cursor 모두 2026년 골격은 비슷합니다:

위에서 아래로:

• 지시층——System Prompt, AGENTS.md, Skills가 목표를 실행 가능 제약으로. Skills는 독립 Agent 전 재사용 서브루틴.
• ReAct 루프——Reason → Tool → Observe. Bash/Browser/MCP/Search 호출 후 재추론. 심장박동.
• 도구·런타임——Filesystem, Git, Sandbox 경계. MCP는 2026년 사실상 표준.
• 결정론 제약——Hooks, Middleware, Evaluator가 루프 밖에서 삭제 방지·테스트 강제·스키마 검증.
• 상태·메모리——Plan, Logs, Memory Store가 다음 ReAct에 진짜 상태 전달.

멀티는 이 그림을 버리지 않고 박스를 복제해 그래프로 연결합니다. LangGraph는 스레드 내 메시지와 스레드 간 store 분리(Memory 개념)——공유 대상이 채팅인지 버전 관리 상태인지 정합니다.

파이프라인: 자주 쓰는 네 토폴로지

「많을수록 좋다」가 아닙니다. 토폴로지 먼저, 인원 다음:

2026년 뚜렷한 흐름: 결정론 단계를 LLM 밖으로. 포맷, lint, 테스트, 태깅은 CI나 Hooks. Agent는 생각과 초안. 클라우드 Mac에서 iOS 빌드할 때도 Agent는 diff만, xcodebuild는 격리 runner——「개발은 프로덕션 안 건드림」과 같습니다.

LangChain 멀티 에이전트 개념은 Supervisor, Swarm, Handoff를 그래프 엣지로——엣지 선택이 모델 선택보다 중요합니다.

2026 스택 3계층

노드 3개 넘고 IDE/VPS/Cron에 상시 돌리면 「Python prompt 연결」은 한계. 3계층으로 수렴:

Runtime(LangGraph)——다음 노드, 상태 저장, 실패 롤백. LangGraph는 Pregel 슈퍼스텝으로 팀형 전역 스케줄링에 적합.

Framework(LangChain)——모델 호출, 툴 래핑, RAG. 부품만 주고 토폴로지는 강제 안 함. adapter만 빌려 LangGraph만 쓰는 팀도 흔함.

Harness(DeepAgents 등)——테스트, 배포, 사람과 정렬. 궤적 평가, prompt A/B, 권한 샌드박스, OpenClaw/Cursor 통합. 2026 경쟁축은 「똑똑함」에서 「프로덕션 Harness」로.

런칭 체크리스트

내부·파일럿용 최소 목록(벤더 무관):

• 조직도 말고 상태 그래프——노드는 동사, 엣지는 데이터 계약.
• 핸드오프 스키마——JSON Schema 등으로 부분 재시도.
• 노드별 최소 툴 권한——Reviewer 읽기 전용.
• 단일 trace id——툴 호출·token·지연 일괄 리플레이.
• 메모리 계층——스레드 내, 세션 간, RAG 분리.
• 노드별 비용 예산——Planner 대형, Formatter 소형·규칙.

실행 환경도 분리: VPS에 OpenClaw 게이트웨이·경량 노드, xcodebuild·무거운 브라우저 자동화는 클라우드 Mac——뚜껑 닫으면 전원 퇴근 방지. 하드웨어 층 분업입니다.

자주 묻는 질문