AI 에이전트, 언제 혼자 일하고 언제 팀으로 나눌까?

AI 에이전트는 먼저 1개로 시작하고, 툴을 더 잘 갖추는 편이 좋습니다. 멀티 에이전트 시스템은 각 에이전트가 독립적으로 조사하거나, 서로 다른 컨텍스트를 유지하거나, 별개의 업무를 책임질 수 있을 때 제 역할을 합니다. 기획, 조사, 코딩, 검토를 맡은 에이전트가 끊임없이 같은 정보를 공유해야 한다면, 실제로 일을 진척시키는 것보다 서로 조율하는 데 더 많은 노력이 들 수 있습니다.

판단 기준은 명확합니다. 에이전트가 분명한 과제를 받아 수시로 상의하지 않고도 유용한 일을 해낸 뒤, 검증 가능한 결과물을 돌려줄 수 있는가입니다. 그렇지 않다면 에이전트를 나누는 것은 대개 문제를 에이전트 간 메시지로 옮기는 데 그칩니다.

아래에서 설명하는 프레임워크의 동작은 2026년 10월 26일 각 개발사의 공식 문서를 기준으로 확인했습니다. 선택 기준표는 문서에 나온 패턴을 개발 현장에서 자주 마주치는 작업에 적용한 것입니다.

멀티 에이전트 시스템이란 무엇인가요?

멀티 에이전트 시스템은 하나의 큰 작업을 여러 에이전트가 나누어 책임지고, 서로 작업을 주고받도록 구성한 시스템입니다. 대규모 언어 모델(LLM) 애플리케이션에서 에이전트란 툴을 선택하고, 실행 결과를 살피며, 다음 행동을 결정하는 루프 안에서 동작하는 모델입니다. 멀티 에이전트에서는 이 모든 결정을 하나의 에이전트에 맡기는 대신, 여러 에이전트가 각자의 결정을 조율합니다. IBM의 개요는 상호작용하는 에이전트의 구조를 더 넓은 관점에서 설명합니다.

에이전트들이 같은 기반 모델을 사용해도 됩니다. 에이전트를 구분하는 기준은 모델 이름이 아니라 실행 컨텍스트와 책임 범위입니다. 조사 에이전트에는 원문 자료와 검색 툴을 주고, 코딩 에이전트에는 저장소와 구체적인 변경 요청을 전달하는 식입니다.

음악 프로듀서가 따로 녹음한 트랙을 합치는 장면을 떠올려 보겠습니다. 각자 녹음하는 방식은 연주자들이 확정된 편곡을 공유할 때 잘 작동합니다. 모두가 템포를 바꾸고 같은 구절을 다시 쓰고 있다면, 프로듀서는 서로 맞지 않는 녹음을 조정하느라 시간을 보내게 됩니다. 에이전트 팀도 독립적으로 일할 수 있는지, 계속 조율해야 하는지를 놓고 같은 선택을 해야 합니다.

AI 분야의 다중 에이전트 시스템: 이 글에서 다루는 범위

Google Cloud의 개요에서 설명하듯, 이 분야는 로봇, 자율주행차, 시뮬레이션까지 폭넓게 포함합니다. 이 글에서는 조사, 소프트웨어 개발, 비즈니스 업무를 수행하는 LLM 에이전트를 어떻게 구성할지에 집중합니다.

모델을 여러 번 호출한다고 해서 자동으로 멀티 에이전트 시스템이 되는 것은 아닙니다. 검색하고, 파일을 읽고, 코드를 작성한 다음 결과를 확인하는 모든 과정을 하나의 에이전트가 수행할 수 있습니다. 정해진 순서대로 프롬프트를 실행하는 방식 역시 자율적으로 판단하는 에이전트 없이 워크플로로만 구성될 수 있습니다. 구분의 핵심은 누가 결정을 내리고, 어떤 컨텍스트를 사용하느냐입니다.

모델 호출, 툴 사용, 종료 방식부터 이해해야 한다면 에이전트 루프부터 살펴보면 됩니다. 더 큰 틀의 AI 에이전트 아키텍처에서는 에이전트 수와 관계없이 상태, 권한, 관찰 가능한 결과가 필요합니다.

AI 에이전트는 언제 여러 개로 나눠야 할까요?

역할을 나누면서 새로 생기는 복잡성보다 줄어드는 복잡성이 클 때 여러 에이전트를 선택합니다. 유용한 분리는 근거 자료, 전문성, 책임 범위를 나눕니다. 형식적인 분리는 다음 프롬프트에 직함만 붙입니다.

프레임워크를 고르기 전에 다음을 기본 기준으로 삼으면 됩니다.

창업자에게 이는 어시스턴트의 첫 버전부터 조직도를 만들 필요는 없다는 뜻입니다. 개발자에게는 에이전트가 혼자 일을 진행하지 못하게 하는 의존성을 구체적으로 짚으라는 뜻입니다. 운영자에게는 참여한 전문가 수보다 수정 작업까지 포함한 최종 처리 결과로 평가하라는 뜻입니다.

익숙한 기획자, 조사자, 개발자, 검토자 구성은 해야 할 활동을 정리하는 데 유용합니다. 하지만 실행 프로세스까지 반드시 그렇게 나눠야 하는 것은 아닙니다. 코딩 에이전트 안에서 계획을 세울 수 있고, 툴 호출로 조사를 수행할 수 있습니다. 검토는 통과와 실패가 명확한 테스트부터 시작할 수 있습니다.

청구서 내보내기 기능을 고치는 요청을 예로 들어 보겠습니다. 계획이 데이터베이스 스키마에 의존하고, 구현 중 그 스키마의 예외가 드러난다면 별도 기획 에이전트에 계속 상황을 알려야 합니다. 이럴 때는 계획과 구현을 가까이 두는 편이 좋습니다. 다만 최종 패치, 내보내기 요구사항, 관련 테스트 결과를 전달받는 별도 검토자는 여전히 도움이 될 수 있습니다.

멀티 에이전트 아키텍처의 주요 패턴

패턴을 가르는 핵심은 누가 답변을 책임지고, 에이전트 사이에 얼마나 많은 정보가 오가느냐입니다. 감독형, 계층형, 핸드오프, 그룹 채팅은 서로 배타적인 제품 분류가 아니라 함께 조합할 수 있는 구성 방식입니다.

감독형·오케스트레이터-워커: 최종 결과는 하나의 에이전트가 책임집니다

상태를 유지하는 에이전트 워크플로용 런타임인 LangGraph는 범위가 정해진 작업을 위임하고 결과를 취합하는 감독 에이전트 구성을 지원합니다. 감독 에이전트는 사용자에게 전달할 결과를 끝까지 책임지고, 작업 에이전트는 조사 결과나 결과물을 반환합니다.

LangChain의 현재 감독 에이전트 튜토리얼에서는 일정 관리와 이메일 에이전트를 상위 수준의 툴로 감쌉니다. 감독 에이전트는 해당 툴을 호출하고 전문 에이전트의 최종 응답을 받습니다. 중간에 수행된 모든 작업을 자신의 대화 기록에 담을 필요는 없습니다.

구현할 때 구분해야 할 점도 있습니다. langgraph-supervisor 레퍼런스는 여전히 create_supervisor를 문서화하고 있지만, 대부분의 사용 사례에서는 툴을 통해 감독 패턴을 직접 구현하는 방식을 권장합니다. 그래야 작업 에이전트에 어떤 컨텍스트를 전달하고 무엇을 돌려받을지 더 세밀하게 제어할 수 있습니다. 이 패키지 문서에는 감독 에이전트가 다른 감독 에이전트를 관리하는 구성도 나옵니다.

제품 기능 조사, 기술적 의존성 검토, 서로 다른 출처에서의 근거 수집처럼 질문들이 독립적인 조사 보고서 작업에 이 패턴이 적합합니다. 각 작업 에이전트가 의미 있는 과제를 완수하는 동안 총괄 에이전트는 취합된 답변을 책임집니다.

한계는 결과를 통합하는 데서 드러납니다. 모든 에이전트가 다른 에이전트의 최신 발견을 알아야 한다면 감독 에이전트는 전달자에 머물게 됩니다. 또 감독 에이전트가 자신감 있는 종합 답변을 쓴다고 해서 빠진 근거가 채워지는 것도 아닙니다.

계층형 팀: 관리자를 통해 업무를 위임합니다

역할별 에이전트를 조율하는 프레임워크인 CrewAI는 에이전트, 작업, 실행 프로세스를 중심으로 크루를 구성합니다. 계층형 프로세스에서는 Process.hierarchical을 manager_llm 또는 manager_agent와 함께 사용합니다. 관리자는 업무를 배정하고 출력을 검토하며, 작업이 완료됐는지 판단합니다.

계층 구조는 관리자가 여러 팀을 감독하는 방식으로 확장할 수 있습니다. 다만 CrewAI의 계층형 크루 자체가 여러 층으로 깊게 중첩된 조직을 뜻하지는 않습니다. CrewAI는 작업이 정의된 순서대로 진행되는 Process.sequential도 지원합니다. 둘은 서로 다른 실행 방식이며, 협업을 가리키는 같은 이름이 아닙니다.

제품 평가를 조사 흐름과 구현 흐름으로 나누는 상황을 생각해 보겠습니다. 각 흐름의 책임이 이미 일관되게 정리되어 있고 안정적인 결과물을 만들어 낸다면 계층 구조를 고려할 만합니다. 반면 전체 작업이 짧은 답변 하나이고 관리자들이 서로의 지시를 되풀이하는 데 그친다면 설득력이 훨씬 떨어집니다.

한계는 관리에 드는 추가 비용입니다. 계층마다 과제를 해석하고 결과를 보고해야 합니다. 사람으로 이루어진 회사에 부서가 있다는 이유가 아니라, 실제 작업에 팀을 나눌 경계가 있을 때 계층을 추가해야 합니다.

핸드오프: 전문 에이전트가 이어받습니다

에이전트와 툴을 실행하는 코드 라이브러리인 OpenAI Agents SDK는 핸드오프를 다른 에이전트로 제어권을 넘기는 방식으로 구현합니다. handoffs 설정에는 에이전트가 위임할 수 있는 대상이 들어갑니다. 넘겨받은 전문 에이전트가 다음 응답을 책임집니다. 이는 관리자가 최종 답변의 책임을 유지하면서 as_tool()로 전문 에이전트를 호출하는 방식과 다릅니다. OpenAI의 오케스트레이션 문서는 이 차이를 명확히 설명합니다.

고객 지원 대화를 보면 차이가 분명해집니다. 결제 전문 에이전트가 추가 질문을 하고 청구서 문제를 해결해야 한다면 대화를 넘기는 것이 자연스럽습니다. 주 어시스턴트가 더 넓은 질문에 답하기 전에 결제 금액 계산만 필요하다면, 툴이나 범위가 한정된 전문 에이전트 호출로 충분할 수 있습니다.

한계는 제어권을 넘기는 경계에 있습니다. 넘겨받는 에이전트에는 관련 사실, 아직 풀리지 않은 질문, 필요한 권한이 있어야 합니다. 핸드오프가 이루어졌다고 해서 앞선 작업이 모두 옳았거나 전문 에이전트가 모든 행동을 할 권한을 가졌다는 뜻은 아닙니다. 접근 권한과 승인 규칙은 애플리케이션 코드로 강제해야 합니다.

책임 주체가 바뀌어야 할 때 핸드오프를 사용합니다. 단지 단계마다 다른 페르소나를 부여하려고 사용하면 컨텍스트를 잃을 기회만 늘어납니다.

그룹 채팅: 공유 대화 속에서 함께 작업합니다

에이전트 애플리케이션과 워크플로를 구축하는 Microsoft Agent Framework는 다음 발언자를 고르는 오케스트레이터로 그룹 채팅을 구현합니다. Python의 GroupChatBuilder는 선택 함수 또는 에이전트 기반 오케스트레이터와 종료 조건을 지원합니다. 참여자들은 각자 별도의 세션을 가지며 대화 기록은 서로 동기화됩니다. 작동 방식은 Microsoft의 그룹 채팅 문서에 설명되어 있습니다.

이 방식은 상호작용을 통해 개선되는 제안서에 잘 맞습니다. 검토자가 빠진 요구사항을 지적하면 작성자가 초안을 고치고, 다른 전문 에이전트가 수정된 논리를 점검하는 식입니다. 독립적인 조사 갈래와 달리, 여기서는 뒤의 발언이 앞선 기여에 의도적으로 의존합니다.

한계는 대화가 계속 길어진다는 점입니다. 참여자들이 결과물을 바꾸는 대신 작업에 관해 이야기하는 데 차례를 소모할 수 있습니다. 공유 토론에서는 모두가 같은 잘못된 전제에 노출되기도 합니다. 그 대화에서 의견이 일치했다고 해서 독립적인 검증이 이루어진 것은 아닙니다.

그룹 채팅에는 개선할 결과물, 구체적인 통과 조건, 종료 규칙을 제시해야 합니다. 작업 순서가 명백하게 정해져 있다면 단순한 워크플로가 대체로 이해하기 쉽습니다.

더 넓은 구현 방식의 선택은 AI 에이전트 프레임워크 비교에서 다룹니다. 분리가 필요하다고 판단했다면, AI 에이전트 오케스트레이션에서 조율, 상태, 승인, 운영 제어를 살펴볼 수 있습니다.

멀티 에이전트 시스템은 어떤 작업에서 도움이 되나요?

서로 긴밀하게 얽힌 편집 작업보다 폭넓은 조사가 멀티 에이전트를 시도하기에 더 적합합니다. Anthropic이 공개한 Research 시스템은 총괄 에이전트와 병렬 작업 에이전트를 사용합니다. 작업 에이전트들은 각기 다른 방향을 조사한 뒤 결과를 반환합니다. Anthropic이 발표한 내부 평가에서는 Claude Opus 4를 총괄로, Claude Sonnet 4를 하위 에이전트로 사용한 구성이 단일 Claude Opus 4 에이전트보다 90.2% 높은 성능을 보였습니다. 이는 해당 조사 평가에서 보고된 상대적 개선 폭입니다. 성공률이 90.2%라는 뜻도, 에이전트를 추가하면 언제나 그만큼 좋아진다는 뜻도 아닙니다. 이 비교에서는 모델 구성과 연산량도 함께 달라집니다. Anthropic의 엔지니어링 설명에서 확인할 수 있습니다.

연동할 제품을 검토하는 개발자라면 각 후보의 문서를 독립적으로 조사하고, 같은 요구사항에 대한 근거를 반환하도록 하는 작업이 이에 해당합니다. 최종 결정을 내릴 때는 여전히 누군가가 상충하는 주장과 빠진 정보를 정리해야 합니다. 병렬 조사는 활용 가능한 근거를 늘릴 수 있지만, 서로 맞지 않는 근거를 일치시키지는 못합니다.

코딩은 의존 관계가 다릅니다. 독립적인 에이전트들이 각각 인증 코드를 살피고, 관련 테스트를 찾고, 라이브러리의 문서상 동작을 조사할 수 있습니다. 이런 조사는 범위가 한정되어 있습니다. 반면 여러 에이전트가 같은 인증 흐름을 동시에 다시 작성하는 구성은 훨씬 어렵습니다. 각자의 결정이 다른 에이전트의 작업을 무효로 만들 수 있기 때문입니다.

고객 지원에서는 책임 범위 때문에 분리할 수 있습니다. 일반 어시스턴트가 문제를 파악하고 전문 에이전트가 특정 영역을 처리하는 방식입니다. 이점은 대화가 길어지는 데서가 아니라, 전문 에이전트의 지침과 툴이 더 좁은 영역에 맞춰져 있다는 데서 나옵니다.

이 코딩 및 고객 지원 시나리오는 설계 예시이며, 실제 배포 사례나 측정된 개선 결과를 보고하는 것이 아닙니다. 유용성을 판단하려면 더 나은 툴이나 범위를 명확히 한 프롬프트만으로는 기존 에이전트가 같은 수준으로 수행하기 어려운 일을, 새 에이전트가 해낼 수 있는지 살펴야 합니다.

멀티 에이전트 LLM 시스템은 왜 실패하나요?

각 에이전트를 따로 보면 유능해 보여도, 작업을 주고받는 경계에서 실패할 수 있습니다. 에이전트가 늘면 해석해야 할 과제, 신뢰해야 할 중간 결과, 원래 요구사항의 의미가 달라질 수 있는 지점도 늘어납니다.

토큰 사용량과 순차 작업 사이의 대기 증가

위임에는 지시문, 작업 에이전트의 컨텍스트, 반환 결과, 결과 취합이 추가됩니다. 재시도와 공유 대화 기록도 작업량을 늘립니다. Anthropic은 자체 데이터에서 멀티 에이전트 시스템이 채팅의 약 15×에 해당하는 토큰을 사용했다고 보고했습니다. 비교 기준은 단일 에이전트 실행이 아니라 채팅입니다. 따라서 일반적인 계획에 그대로 적용할 배수가 아닙니다. Anthropic이 보고한 토큰 사용량을 참고할 수 있습니다.

토큰 부담은 측정해야 할 위험이지, 모든 멀티 에이전트 구성이 반드시 더 많은 토큰을 쓴다는 보편 법칙은 아닙니다. 컨텍스트를 분리하면 불필요한 자료를 반복해서 불러오는 일을 줄일 수도 있습니다. 중요한 것은 실패한 작업 갈래와 재작업까지 포함해, 통과 기준을 충족한 결과를 얻는 데 든 총사용량입니다.

병렬 에이전트가 소요 시간을 줄일 수 있는 것은 서로 독립적인 작업에 한해서입니다. 조사가 끝나야 기획자가 움직이고, 계획이 나와야 코딩 에이전트가 시작할 수 있다면 여전히 의존 관계가 이어진 사슬입니다. 각 단계에 다른 이름을 붙인다고 동시 실행이 되는 것은 아닙니다.

더 어려워지는 디버깅

최종 답변만 보면 처음 잘못된 결정이 가려질 수 있습니다. 코딩 에이전트가 잘못된 요구사항을 정확히 구현하고, 검토자는 바로 그 잘못된 요구사항을 기준으로 구현을 승인할 수 있습니다. 마지막 응답만 살펴보면 엉뚱한 구성 요소를 원인으로 지목하게 됩니다.

Anthropic은 전체 실행 추적이 Research 시스템에서 검색, 출처 선택, 툴의 실패를 구별하는 데 도움이 됐다고 보고했습니다. 상태를 유지하는 에이전트 실행 과정에서 오류가 누적되는 현상도 설명합니다. 엔지니어링 관찰 내용에 자세히 나와 있습니다.

설계를 비교할 때는 작업이 처음 의도에서 벗어난 지점을 찾을 수 있는지 확인해야 합니다. 에이전트가 어떤 지시와 근거를 받았는지, 무엇을 반환했는지, 다음 에이전트가 무엇을 확정된 사실로 받아들였는지를 볼 수 있어야 합니다. 이 경계를 들여다볼 수 없다면 검토자 추가가 시스템을 개선하는지, 안심시키는 마지막 메시지만 더하는지 구분할 수 없습니다.

전달을 거치며 누적되는 오류

가상의 조사 에이전트가 “이 엔드포인트는 내보내기를 지원하는 것으로 보이지만, 필요한 권한은 명확하지 않습니다”라고 씁니다. 기획자는 이를 “내보내기 엔드포인트를 사용합니다”로 압축합니다. 코딩 에이전트는 계획을 구현합니다. 검토자는 계획과 패치를 대조한 뒤 차이가 없다고 판단합니다.

아무도 해결하지 않았는데 최초의 불확실성이 사라졌습니다. 더 많은 에이전트가 참여했지만 빠진 근거를 확인한 에이전트는 없었습니다.

요약과 함께 출처, 명시적인 미확인 사항, 실제 결과물을 반환해야 합니다. 검토자에게는 작성자가 설명한 요구사항만 주지 말고 원래 요구사항을 전달합니다. 이는 역할을 느슨하게 정의해 길게 늘어놓은 구성보다, 규모가 작고 작업 과정을 확인할 수 있는 팀을 선호할 이유입니다.

에이전트 팀에 대한 기대는 어디서 과장되나요?

역할 수로 역량을 가늠하기는 어렵습니다. 에이전트가 늘어난다고 지식, 독립적인 판단, 실행 속도가 저절로 늘지는 않습니다. 핵심은 분리했기 때문에 어떤 새로운 작업이 가능해지는가입니다.

단일 에이전트도 툴을 병렬로 사용할 수 있으므로 동시 검색만을 위해 팀이 필요한 것은 아닙니다. 필요할 때 전문 지침을 불러올 수도 있습니다. LangChain은 하나의 에이전트가 제어권을 유지하면서 필요에 따라 관련 지식을 가져오는 스킬 패턴을 문서화하고 있습니다.

프롬프트 분리를 보안 격리와 혼동해서도 안 됩니다. 한 에이전트를 조사자, 다른 에이전트를 승인자라고 부른다고 접근 권한이 제한되지는 않습니다. 의도한 툴 권한과 승인 경계는 애플리케이션이 강제해야 합니다.

여러 에이전트를 써야 한다는 가장 설득력 있는 근거는 대개 구체적입니다. 특정 에이전트에 별도의 컨텍스트가 필요하거나, 질문을 독립적으로 조사할 수 있거나, 다른 대화 영역을 책임져야 한다는 식입니다. “팀처럼 보인다”는 이유만으로는 부족합니다.

바로 적용하려면: 가장 작고 유용한 분리부터 비교합니다

단일 에이전트를 기준 구성으로 유지하고, 눈에 보이는 실패를 해결할 에이전트만 추가합니다. 현재 시스템이 잘 작동한다면 관리자와 검토자를 더하는 순간 그 필요성을 다시 입증해야 할 새 시스템이 됩니다.

1. 1

   현재 워크플로에서 무엇이 실패하는지 구체화합니다

   에이전트가 근거를 놓치거나, 잘못된 툴을 고르거나, 요구사항을 잃거나, 수용할 수 없는 결과물을 만드는 실제 작업을 고릅니다. 에이전트 수를 원인으로 보기 전에 빠진 툴과 모호한 지침부터 고칩니다.

2. 2

   범위를 한정한 대안을 정의합니다

   코딩 어시스턴트라면 주 에이전트가 패치를 계속 책임지게 하고, 검토가 부족한 경우에만 독립적인 검토자를 추가합니다. 검토자에게 줄 입력과 반드시 반환해야 할 근거를 명시합니다. 전체 워크플로를 한꺼번에 바꾸지 않습니다.

3. 3

   통과 기준을 충족한 결과를 비교합니다

   같은 작업 집합과 같은 통과 기준으로 기존 구성과 대안을 실행합니다. 완성도, 총토큰 수, 소요 시간, 실패를 진단하거나 바로잡는 데 필요한 사람의 작업량을 기록합니다. 결과를 해석할 때는 모델 차이도 고려합니다.

4. 4

   분리를 유지할지 다시 합칠지 결정합니다

   추가 운영 부담을 감수할 만큼 결과가 좋아진다면 해당 에이전트를 유지합니다. 주로 컨텍스트를 반복하거나 다른 에이전트의 작업을 다시 설명하는 데 그친다면, 그 활동을 원래 에이전트 안으로 합칩니다. 측정으로 확인된 문제가 없는 운영자는 기다려도 됩니다. 독립적인 조사 갈래가 있는 개발자는 지금 실험할 이유가 더 분명합니다.

멀티 에이전트 시스템에 관해 자주 묻는 질문

ChatGPT는 멀티 에이전트 시스템인가요?

ChatGPT라는 이름만으로 특정 워크플로의 아키텍처를 알 수는 없습니다. 어떤 기능을 멀티 에이전트라고 부르려면 별개의 에이전트가 작업을 주고받거나 제어권을 넘긴다는 문서상 근거가 있어야 합니다. 채팅 인터페이스, 툴 사용, 긴 답변만으로는 근거가 충분하지 않습니다.

멀티 에이전트 시스템의 예로는 무엇이 있나요?

Anthropic의 Research 시스템은 작업 에이전트에 조사를 위임하고 그 결과를 취합합니다. 오케스트레이터-워커 패턴의 사례입니다.

가장 좋은 멀티 에이전트 시스템은 무엇인가요?

모든 상황에 통하는 최선은 없습니다. 범위가 정해진 전문 작업에는 감독형, 대화의 책임 주체를 바꿔야 할 때는 핸드오프, 반복적인 비평이 도움이 될 때는 그룹 채팅처럼 작업에 맞는 패턴을 선택합니다. 분리해도 결과가 나아지지 않는다면 단일 에이전트를 유지합니다.

AI 에이전트의 '대표 4가지'는 무엇인가요?

업계에서 정식으로 합의한 '대표 4가지' 목록은 없습니다. 기획자, 조사자, 개발자, 검토자는 에이전트 팀을 제안할 때 흔히 쓰는 역할 이름이며 필수 구성 요소는 아닙니다. 별도 에이전트를 만들기 전에 각 역할이 할 일부터 정의합니다.

ChatGPT는 에이전트인가요, LLM인가요?

ChatGPT는 애플리케이션 이름이고, LLM은 그 기반이 되는 모델의 종류입니다. 에이전트는 모델을 사용해 행동을 고르고 결과에 대응하는 시스템을 가리킵니다. 서로 다른 계층을 설명하는 용어이므로 같은 뜻으로 취급하지 말고 구체적인 기능을 살펴봐야 합니다.

AI 에이전트의 7가지 유형은 무엇인가요?

일곱 가지로 정리한 목록은 의사결정 규칙, 학습 방식, 작업 역할, 협업 패턴처럼 서로 다른 분류를 한데 묶은 것입니다. 반드시 구현해야 하는 고정된 일곱 부분의 아키텍처가 있는 것은 아닙니다. 여기서 설계를 결정할 때는 개별 에이전트의 동작과 여러 에이전트의 배치를 구분해야 합니다.

가장 흔한 AI 에이전트는 무엇인가요?

실무에서 유용한 분류로는 고객 지원 어시스턴트, 조사 에이전트, 코딩 에이전트가 있습니다. 이는 작업 유형에 따른 분류이며, 검증된 인기 순위는 아닙니다. 이름만으로는 단독 실행인지, 감독 에이전트 아래에서 실행되는지, 핸드오프로 이어지는지 알 수 없습니다.

AI 에이전트의 구체적인 예를 들어 줄 수 있나요?

주문을 조회하고 다음 행동을 고르는 고객 지원 에이전트, 검색하고 출처를 확인하는 조사 에이전트, 파일을 수정하고 테스트를 실행하는 코딩 에이전트가 있습니다. 여러 단계를 거치더라도 각각 단일 에이전트일 수 있습니다.

AI 에이전트의 5가지 유형은 무엇인가요?

IBM은 고전적인 분류 체계로 단순 반사형, 모델 기반 반사형, 목표 기반, 효용 기반, 학습형 에이전트를 설명합니다. 이는 에이전트가 결정을 내리거나 학습하는 방식을 분류한 것입니다. 애플리케이션에 LLM 작업 에이전트를 몇 개 써야 하는지 정해 주는 분류는 아닙니다.

AI를 활용한 개발에서 실질적인 판단에 도움이 되는 내용을 받아 보려면 뉴스레터를 구독하세요.