AI 에이전트 설계 패턴: 하나의 에이전트로 시작하되, 혼자 일하게 두지 마세요

AI 에이전트 제품을 만들 때, 대부분의 인디 파운더는 똑같은 곳에서 시작합니다. 에이전트 하나에 프롬프트를 잘 써서 모든 일을 시키는 것입니다. 처음에는 잘 됩니다. 단순한 작업이라면 문제가 없습니다.

하지만 작업이 복잡해지는 순간, 에이전트는 예측 불가능한 존재가 됩니다. 어제 잘 되던 것이 오늘은 안 됩니다. 같은 질문에 다른 순서로 답합니다. Google Cloud의 에이전트 설계 패턴 시리즈에서는 이 문제를 해결하는 세 가지 아키텍처를 제안합니다.

단일 에이전트의 한계: 천재 한 명에게 모든 업무를 맡기면 벌어지는 일

단일 에이전트 패턴은 가장 직관적입니다. 에이전트 하나에 도구(tool)를 연결하고, 시스템 프롬프트에 작업 방법을 설명합니다. "여행을 계획해줘"라고 하면, 에이전트가 알아서 날씨를 검색하고, 교통편을 확인하고, 일정을 짭니다.

문제는 작업이 두 개 이상으로 늘어날 때입니다. "늦게까지 여는 스시집을 찾고, 거기까지 가장 빠른 길을 알려줘"처럼 멀티스텝 작업을 시키면, 거대한 프롬프트가 필요합니다. AI는 비결정적(nondeterministic)이기 때문에, 매번 같은 순서로 실행된다는 보장이 없습니다.

단일 에이전트는 구현이 간단하지만, 복잡한 워크플로우에서는 통제력을 잃습니다. 작업이 복잡해질수록 행동이 불안정해집니다.

인디 파운더의 AI 제품이 "가끔 이상하게 동작한다"는 피드백을 받고 있다면, 단일 에이전트의 한계에 부딪힌 것입니다.

순차 에이전트: 조립 라인처럼 일하면, 실수가 사라집니다

순차 에이전트(Sequential Agent)는 하나의 큰 작업을 여러 전문 에이전트에게 정해진 순서대로 넘기는 패턴입니다. 조립 라인과 같습니다. 첫 번째 에이전트가 음식점을 찾으면, 그 결과를 두 번째 에이전트가 받아서 교통편을 검색합니다.

핵심은 에이전트 사이의 통신 방식입니다. 에이전트들은 공유 세션 스테이트(Shared Session State)라는 메모장을 통해 정보를 주고받습니다. 첫 번째 에이전트가 결과를 메모장에 쓰면, 두 번째 에이전트가 그것을 읽습니다. 단기 메모리라고 생각하면 됩니다.

• 장점: 높은 통제력과 예측 가능성. 항상 같은 순서로 실행됩니다.
• 단점: 유연하지 않습니다. 순서가 고정되어 있어서 동적인 상황에 적응하기 어렵습니다.
• 적합한 경우: 고객 문의 분류 → 답변 생성 → 감성 분석처럼 순서가 정해진 반복 작업.

인디 파운더의 SaaS에서 "접수 → 분석 → 응답"처럼 파이프라인이 명확한 기능이 있다면, 순차 에이전트가 정답입니다.

병렬 에이전트: 기다리는 시간이 고객을 떠나게 합니다

만약 박물관, 콘서트, 레스토랑을 동시에 찾아야 한다면 어떨까요? 순차적으로 하나씩 검색하면 3배의 시간이 걸립니다. 병렬 에이전트(Parallel Agent)는 독립적인 작업을 여러 에이전트가 동시에 처리하는 패턴입니다.

세 개의 검색 에이전트가 동시에 결과를 찾고, 마지막에 어그리게이터(Aggregator) 에이전트가 모든 결과를 종합해서 하나의 여행 계획을 만듭니다. 실무에서는 병렬 에이전트와 순차 에이전트를 조합합니다. 먼저 병렬로 검색하고, 그 다음 순차적으로 종합하는 구조입니다.

사용자가 응답을 기다리는 매 초가 이탈률을 높입니다. 독립적인 작업은 반드시 병렬로 처리하세요.

• 장점: 레이턴시 대폭 감소. 독립 작업에 최적.
• 단점: 여러 에이전트를 동시에 실행하므로 초기 비용이 높고, 결과 종합 로직이 필요합니다.
• 적합한 경우: 여러 소스에서 동시에 데이터를 수집하거나, 독립적인 분석을 병행하는 작업.

세 가지 패턴, 하나의 선택 기준: 통제 가능성

어떤 패턴을 선택해야 할까요? 복잡도가 아니라 통제 가능성이 기준입니다.

• 단일 에이전트: 도구 1~2개, 작업 순서가 중요하지 않을 때. 가장 빠르게 프로토타입을 만들 수 있습니다.
• 순차 에이전트: 작업 순서가 반드시 지켜져야 할 때. 에이전트가 "항상 같은 방식으로" 동작해야 하는 제품에 적합합니다.
• 병렬 에이전트: 독립적인 작업이 여러 개이고, 속도가 중요할 때. API 비용을 감수할 수 있다면 사용자 경험이 크게 개선됩니다.

대부분의 실전 AI 제품은 하나의 패턴만 쓰지 않습니다. 병렬로 데이터를 수집한 뒤 순차적으로 처리하거나, 단일 에이전트로 시작해서 기능이 커지면 순차 에이전트로 리팩토링하는 것이 일반적입니다.

인디 파운더의 실전 적용: 단순하게 시작하고, 필요할 때 쪼개세요

Google의 ADK(Agent Development Kit)처럼 프레임워크를 쓰면 패턴 전환이 쉽습니다. 하지만 프레임워크보다 중요한 것은 설계 원칙입니다.

• MVP는 단일 에이전트로 시작하세요. 프롬프트 하나로 동작하는 프로토타입을 먼저 만드세요. 사용자가 실제로 원하는 기능을 검증하는 것이 아키텍처보다 먼저입니다.
• "가끔 이상하게 동작한다"는 피드백이 오면 쪼개세요. 단일 에이전트의 프롬프트가 200줄을 넘기면, 순차 에이전트로 분리할 때입니다.
• 응답 시간이 5초를 넘기면 병렬화를 고려하세요. 사용자는 3초 이상 기다리면 떠납니다. 독립적인 API 호출이 여러 개라면 병렬 처리가 답입니다.
• 에이전트 사이의 인터페이스를 먼저 설계하세요. 공유 세션 스테이트에 무엇을 저장하고, 어떤 형식으로 넘길지 정하면 나중에 패턴을 바꾸기 쉽습니다.

다음 단계: 루프, 비평, 그리고 에이전트를 도구로 쓰는 패턴

이 세 가지는 기본 패턴입니다. Google Cloud는 후속 에피소드에서 더 고급 패턴도 소개합니다. 자기 수정을 위한 루프/비평 패턴, 동적 라우팅을 위한 오케스트레이터 패턴, 그리고 에이전트 자체를 도구로 쓰는 에이전트 애즈 툴(Agent as Tool) 패턴입니다.

AI 에이전트 제품을 만드는 인디 파운더에게 가장 중요한 것은 처음부터 완벽한 아키텍처를 설계하는 것이 아닙니다. 단일 에이전트로 빠르게 검증하고, 사용자 피드백에 따라 패턴을 진화시키는 것입니다. 아키텍처는 사용자가 결정합니다.

이 글은 Google Cloud Tech의 영상 AI agent design patterns을 기반으로 작성되었습니다.