AI 에이전트 종류는 누가 나누느냐에 따라 달라요, 구글과 앤트로픽의 분류 비교

AI 에이전트라는 말은 자주 들리는데, 막상 종류를 물으면 무엇을 기준으로 나누는지부터 막혀요. 챗봇이나 어시스턴트와는 어떻게 다른지도 헷갈리고요. 그래서 구글 클라우드와 앤트로픽이 각자 낸 에이전트 설명 문서를 같은 날 받아 나란히 읽어 봤어요.

결론부터 적을게요. AI 에이전트 종류에 하나로 정해진 표준 분류는 없어요. 구글 클라우드 문서는 에이전트 유형과 카테고리에 서로 다른 정의가 있다고 적고, 앤트로픽 문서는 에이전트라는 말을 여러 방식으로 정의할 수 있다고 적어요. 2026년 10월 1일 오전 10시 43분(한국 시각)에 받은 문서 기준으로 두 회사의 분류는 이렇게 갈려요.

• 구글 클라우드: 사용자와 상호작용하는 방식에 따라 대화형 파트너와 자율 백그라운드 프로세스로, 에이전트 수에 따라 단일 에이전트와 멀티 에이전트로 나눠요. 에이전트와 어시스턴트와 봇의 차이도 표로 따로 적어요.
• 앤트로픽: 이런 것을 모두 에이전트형 시스템으로 묶은 뒤, 미리 정해진 코드 경로를 따르는 워크플로와 LLM 이 스스로 과정을 정하는 에이전트로 나눠요. 워크플로 쪽은 다섯 가지 패턴으로 다시 나눠요.

먼저 밝혀 둘 것이 있어요. 저는 에이전트를 직접 만들거나 돌려 보지 않았어요. 이 글은 두 회사 문서를 읽고 해당 문단을 옮긴 결과예요. 문서에 없는 내용은 없다고 따로 적었어요.

두 문서는 어떤 문서인가요

구글 클라우드 문서는 「AI 에이전트란 무엇인가요?」라는 제목의 설명 페이지예요. 한국어판도 있고, 최종 업데이트 날짜가 2026년 4월 2일로 적혀 있어요. 이 글에서 쓴 한국어 용어는 되도록 그 한국어판의 공식 번역을 따랐어요.

앤트로픽 문서는 엔지니어링 블로그의 「Building effective agents」예요. 게시일은 2024년 12월 19일이에요. 글 첫머리에는 이 글에서 다룬 도구 환경이 2024년 12월 이후 많이 바뀌었다는 안내문이 붙어 있고, 현재 방식은 Claude Managed Agents 문서를 보라고 적혀 있어요. 그래서 이 글에서는 앤트로픽 문서의 분류와 패턴만 옮기고, 그 글에 예시로 나온 모델 이름이나 도구 목록은 지금 기준으로 소개하지 않았어요.

두 문서의 정의도 조금 달라요. 구글 클라우드는 AI 에이전트를 AI를 사용해 사용자를 대신하여 목표를 추구하고 태스크를 완료하는 소프트웨어 시스템이라고 적어요. 앤트로픽은 에이전트라는 말을 여러 방식으로 정의할 수 있다고 먼저 밝혀요. 오랫동안 혼자 움직이는 완전 자율 시스템을 에이전트라고 부르는 고객도 있고, 미리 정한 워크플로를 따르는 구현을 그렇게 부르는 고객도 있다는 거예요. 그다음 이를 모두 에이전트형 시스템으로 묶고, 그 안에서 자기 기준의 구분을 내놓아요.

구글 클라우드의 분류: 에이전트, 어시스턴트, 봇

구글 클라우드 문서는 유형을 나누기 전에 에이전트와 어시스턴트와 봇의 차이부터 표로 정리해요. 한국어판 표를 그대로 옮기면 이래요.

표 아래에는 차이를 세 가지로 다시 적어요. 자율성은 에이전트가 가장 높고 봇이 가장 낮아요. 복잡성은 에이전트가 복잡한 태스크와 워크플로를, 어시스턴트와 봇은 더 간단한 태스크를 맡는 쪽이에요. 학습은 에이전트가 머신러닝으로 성능을 개선하고, 봇은 학습 기능이 제한적이거나 전혀 없다고 적어요.

헷갈리기 쉬운 문장이 하나 있어요. 같은 문서는 AI 어시스턴트를 따로 떨어진 물건이 아니라 에이전트의 한 형태로 적어요. 사용자와 직접 협업하도록 애플리케이션이나 제품으로 설계된 AI 에이전트이고, 사용 중인 제품에 내장되는 경우가 많다는 설명이에요. 표에서 셋이 나란히 있지만, 어시스턴트는 결정권을 사용자에게 남겨 둔 에이전트로 읽는 편이 문서에 맞아요.

구글 클라우드의 분류: 두 가지 기준, 네 가지 유형

유형 분류 문단은 AI 에이전트를 기능, 역할, 환경에 따라 다양한 방식으로 분류할 수 있다는 문장으로 시작해요. 그리고 주요 카테고리로 두 가지 기준을 소개해요.

이 표에서 눈여겨볼 곳은 무엇이 실행을 시작하느냐예요. 대화형 파트너는 사용자 쿼리로, 백그라운드 에이전트는 이벤트로 움직인다고 적혀 있어요. 백그라운드 에이전트는 인적 상호작용이 제한적이거나 전혀 없고, 대기 중인 태스크나 태스크 체인을 완료한다고 해요.

이 두 기준이 유형의 전부는 아니에요. 문서는 에이전트를 다양한 방식으로 분류할 수 있다고 적고, 이 두 기준도 몇 가지 주요 카테고리로 소개해요. 페이지 아래쪽 사용 사례 문단에서는 고객, 직원 같은 여섯 범주로 에이전트를 다시 묶어요. 반사형이나 목표 기반 같은 교과서식 유형 이름은 이 문서에 나오지 않아요.

구글 클라우드가 적은 구성 요소와 기능

같은 문서는 에이전트가 어떻게 작동하는지도 네 가지 구성 요소로 적어요.

1. 페르소나: 역할에 맞게 일관된 성격을 유지하게 해 줘요.
2. 메모리: 단기, 장기, 합의, 단편적 메모리를 갖춰요. 단기는 즉각적인 상호작용, 장기는 과거 데이터와 대화, 단편적 메모리는 과거 상호작용, 합의 메모리는 에이전트 간에 공유된 정보를 맡아요.
3. 도구: 에이전트가 환경과 상호작용하는 데 쓰는 함수나 외부 리소스예요.
4. 모델: 대규모 언어 모델이 에이전트의 두뇌 역할을 해요.

주요 기능으로는 추론, 행동, 관찰, 계획, 협업, 자체 조정의 여섯 가지를 꼽아요. 문서는 핵심 기능이 추론과 행동이고, 시간이 지나며 다른 기능이 더해졌다고 설명해요. 행동의 예로는 메시지 전송, 데이터 업데이트, 다른 프로세스 트리거 같은 디지털 조치를 들어요.

앤트로픽의 분류: 워크플로와 에이전트

앤트로픽 문서는 나누는 방식이 달라요. 완전 자율 시스템이든 정해진 순서를 따르는 구현이든 모두 에이전트형 시스템으로 묶고, 그 안에서 구조로 둘을 갈라요.

Workflows are systems where LLMs and tools are orchestrated through predefined code paths.

워크플로는 LLM 과 도구가 미리 정해진 코드 경로를 따라 움직이는 시스템이라는 뜻이에요. 반대로 에이전트는 LLM 이 자기 과정과 도구 사용을 동적으로 정하고, 작업을 어떻게 끝낼지에 대한 통제를 스스로 유지하는 시스템이라고 적어요.

둘 다 바탕에는 같은 기본 단위가 있어요. 문서는 이를 증강된 LLM 이라고 부르고, 검색과 도구와 메모리 같은 능력을 더한 LLM 이라고 설명해요.

워크플로는 다시 다섯 가지 패턴으로 나뉘어요. 문서에 나온 예를 함께 옮기면 이래요.

오케스트레이터-워커는 병렬화와 모양이 비슷하지만, 하위 작업이 미리 정해져 있지 않고 입력에 따라 중앙 LLM 이 정한다는 점이 다르다고 문서는 적어요.

에이전트 쪽 설명은 이래요. 사람의 명령이나 대화로 일을 시작하고, 작업이 분명해지면 혼자 계획하고 움직이며, 필요하면 사람에게 돌아와 정보나 판단을 구해요. 체크포인트나 막히는 지점에서 멈춰 사람의 피드백을 받을 수 있고, 최대 반복 횟수 같은 중단 조건을 두는 것도 흔하다고 해요. 문서는 에이전트가 대개 환경의 피드백을 보며 반복해서 도구를 쓰는 LLM 일 뿐이라고 적어요.

두 분류를 나란히 놓으면

두 문서는 같은 말을 다른 자리에 둬요. 가장 눈에 띄는 단어가 워크플로예요. 구글 클라우드는 워크플로 에이전트를 백그라운드 에이전트 안에 넣고, 앤트로픽은 워크플로를 에이전트와 나란히 놓인 별개의 갈래로 둬요.

앤트로픽 문서에는 단일 에이전트와 멀티 에이전트라는 분류 이름이 따로 나오지 않아요. 중앙 LLM 이 작업을 다른 LLM 에 나눠 주는 오케스트레이터-워커 패턴이 있을 뿐이에요. 표에서 둘을 한 줄에 놓은 건 구조가 비교할 만해서이지, 두 문서가 같은 것이라고 적은 건 아니에요.

내가 쓰는 도구는 어느 쪽일까, 두 문서의 기준으로 보기

두 문서 어디에도 특정 소비자용 제품이 어느 유형에 속하는지 적은 문장은 없어요. 그래서 이 글도 제품 이름을 분류하지 않을게요. 대신 두 문서가 실제로 쓴 기준을 질문으로 바꾸면 스스로 대 볼 수 있어요.

1. 결정은 누가 내리나요? 구글 클라우드 표에서 어시스턴트는 작업을 추천하고 결정은 사용자가 내려요. 에이전트는 독립적으로 결정을 내릴 수 있어요.
2. 무엇이 실행을 시작하나요? 구글 클라우드 기준으로 대화형 파트너는 사용자 쿼리로, 백그라운드 에이전트는 이벤트로 움직여요. 봇은 트리거나 명령에 반응해요.
3. 단계가 미리 정해져 있나요? 앤트로픽 기준으로 정해진 코드 경로를 따르면 워크플로, LLM 이 과정을 스스로 정하면 에이전트예요.
4. 몇 개가 함께 일하나요? 구글 클라우드 기준으로 하나면 단일 에이전트, 여럿이 협력하거나 경쟁하면 멀티 에이전트예요.

규칙을 정해 두고 앱끼리 잇는 자동화와 에이전트의 차이가 궁금하다면 AI 에이전트와 자동화 차이를 다룬 글도 함께 보세요.

AI 에이전트 사용 사례, 두 문서가 꼽은 분야

구글 클라우드 문서는 조직들이 배포한 사용 사례를 여섯 가지 범주로 묶어요.

앤트로픽 문서는 부록에서 고객과 일하며 특히 유망하다고 본 두 분야를 꼽아요. 하나는 고객 지원이에요. 익숙한 챗봇 화면에 도구 연동을 더한 형태이고, 환불이나 티켓 수정 같은 조치를 프로그램으로 처리할 수 있다고 적어요. 다른 하나는 코딩 에이전트예요. 코드는 자동 테스트로 검증할 수 있어서 잘 맞는다고 하면서도, 해법이 시스템 전체 요구에 맞는지 보려면 사람의 검토가 여전히 중요하다고 덧붙여요.

코드를 직접 짜서 첫 에이전트를 만들어 보고 싶다면 AI 에이전트 개발 입문 가이드를 이어서 보셔도 좋아요.

두 문서가 함께 적은 주의점

에이전트가 늘 정답은 아니라는 점은 두 문서 모두 적어요.

앤트로픽 문서는 가장 단순한 해법부터 찾고 필요할 때만 복잡도를 올리라고 권해요. 에이전트형 시스템을 아예 만들지 않는 것이 답일 수도 있다고 적고요. 이런 시스템은 지연 시간과 비용을 내주고 성능을 얻는 경우가 많고, 에이전트의 자율성은 더 높은 비용과 오류가 쌓일 가능성을 뜻한다고 해요. 그래서 격리된 환경에서 충분히 시험하고 알맞은 안전장치를 두라고 권해요.

구글 클라우드 문서는 에이전트가 어려움을 겪는 영역을 네 가지로 적어요.

• 깊은 공감이나 복잡한 인간관계 이해가 필요한 일, 예를 들어 상담이나 갈등 해결
• 윤리적 위험이 높은 상황, 예를 들어 법 집행, 의료 진단과 치료, 사법 결정
• 예측할 수 없는 물리적 환경, 예를 들어 수술이나 재해 대응
• 리소스가 많이 드는 경우, 예산이 제한적인 소규모 프로젝트나 조직에는 맞지 않을 수 있음

에이전트에게 긴 작업을 맡길 때의 안전장치는 AI 에이전트에 장기 작업을 위임하는 가드레일 글에서 따로 다뤘어요.

이 글이 확인하지 않은 것

제가 한 일은 2026년 10월 1일 오전에 구글 클라우드의 설명 페이지(영어판과 한국어판)와 앤트로픽 엔지니어링 블로그 글을 받아 해당 문단을 옮긴 것까지예요. 아래는 확인하지 않았어요.

• 특정 제품이 어느 유형에 속하는지
• 다른 회사나 학계 교재가 쓰는 분류
• 앤트로픽이 안내문에서 가리킨 Claude Managed Agents 문서의 현재 내용
• 두 문서가 든 사용 사례가 실제로 얼마나 효과를 냈는지

구글 클라우드 문서는 2026년 4월 2일에 마지막으로 업데이트됐고, 앤트로픽 문서는 2024년 12월 19일에 게시된 글이에요. 두 회사의 설명은 바뀔 수 있으니, 분류를 근거로 도구를 고를 때는 원문을 한 번 더 열어 보세요.