AI 에이전트 추천이 어려운 진짜 이유: 아직 같은 범주가 아니에요
AI 에이전트라는 이름으로 서로 다른 도구가 판매되고 있어요. 제품을 추천받기 전에 자율성·실행 권한·승인 절차부터 비교해 보세요.
비즈니스들어가며
같은 시각, 두 사람이 검색창에 다른 문장을 넣어요. 한 명은 ‘AI 에이전트 추천’, 다른 한 명은 ‘AI 에이전트 뜻’.
뜻을 검색한 사람은 입문자라고 생각하기 쉬워요. 그런데 이번에 분석한 검색 경로 모델에서는 뜻을 확인한 뒤 추천을 찾는 연결이 반복됐어요. 실제로 같은 개인이 이 순서로 검색했다는 기록은 아니며, 여러 검색어 사이의 연결을 추정한 결과예요.
지금 이 순서가 중요한 이유가 있어요. 올해 들어 에이전트는 데모 단계를 지나 실제 도입 검토서 위에 올라오기 시작했거든요. 검토서에는 후보 목록과 비교표가 필요한데, 비교표를 만들려면 먼저 무엇과 무엇을 같은 줄에 놓을지 정해야 해요.
구독자님, 저는 이 순서를 에이전트 제품을 비교할 기준이 아직 분명하지 않다는 신호로 봤어요. 추천을 받으려면 먼저 어떤 기능과 권한을 가진 도구끼리 비교할지 정해야 하니까요.
검색 경로 모델에서는 뜻이 추천보다 앞에 놓였어요
숫자부터 볼게요.
‘AI 에이전트’의 최근 3개월 월평균 검색량은 29,416회예요. 12개월 추세를 회귀로 추정하면 연율 환산 +107%(R² 0.515)로, 관심 자체는 분명히 커지고 있어요.
흥미로운 건 그다음이에요. 분석된 상위 중요 모델 경로 15개에는 모두 ‘AI 에이전트 뜻’이 들어 있었어요. ‘뜻’과 ‘추천’이 함께 등장한 13개 경로에서는 예외 없이 뜻이 먼저 놓였고요.
여기서 한 가지는 분명히 해둘게요. 이 데이터는 개인의 클릭 기록이 아니라, 검색어들이 서로 어떻게 연결되는지를 집합적으로 추정한 그래프 모델이에요. 그래서 “한국인은 추천보다 뜻을 더 많이 검색한다”고 읽으면 틀려요. 오히려 경로 빈도 자체는 ‘추천’이 367로 ‘뜻’의 347보다 조금 높아요. 읽을 수 있는 건 크기가 아니라 순서예요.
상위 경로 15개에서 공통으로 나타난 순서는 살펴볼 만해요. 다만 큰 표본은 아니고 실제 개인의 행동 기록도 아니에요. 이 결과만으로 모든 구매자의 행동이나 시장 전체의 성격을 확정할 수는 없어요.
보통의 제품 카테고리에서는 이 순서가 반대예요. 무선 이어폰이나 노트북을 살 때 우리는 정의를 먼저 찾지 않아요. 바로 비교표로 가요. 정의 검색이 앞에 붙는다는 건 그 시장이 아직 구매 단계에 들어가지 못했다는 뜻이에요.
반론도 하나 있어요. ‘뜻’을 겨냥한 입문용 콘텐츠가 대량으로 생산되면서 생긴 공급 효과일 수 있어요. 그렇다 해도 질문은 남아요. 왜 이 시장에서는 아직도 정의 콘텐츠가 소비될까요. 공급이 많아도 수요가 없으면 경로에 남지 않거든요.
추천하려면 먼저 같은 기능과 권한을 가진 도구끼리 비교해야 해요
노트 앱 추천은 어렵지 않아요. 노트 앱끼리 비교하면 되니까요. 가격, 동기화, 협업 기능처럼 비교 축이 이미 공유되어 있어요.
에이전트는 사정이 달라요. 지금 이 이름표 아래에는 질문에 답만 하는 챗봇, 정해진 순서대로만 도는 자동화, 브라우저를 대신 클릭하는 도구, 여러 시스템을 오가며 스스로 다음 수를 정하는 루프가 함께 놓여 있어요. 이 도구들은 맡길 수 있는 일과 스스로 행동하는 범위가 달라서 같은 기준으로 순위를 매기기 어려워요.
Anthropic은 이 경계를 비교적 또렷하게 그어요. 워크플로1는 LLM과 도구가 미리 정해진 코드 경로로 조정되는 시스템이고, 에이전트는 LLM이 과정과 도구 사용을 스스로 지휘하는 시스템이라는 구분이에요. 같은 글에서 이들은 고객마다 에이전트를 서로 다르게 정의한다는 사실도 함께 인정해요. 공급자가 정의를 내놓으면서 동시에 합의가 없다고 적어둔 셈이에요.
한 가지는 짚어둘게요. 이 구분은 업계 전체의 법적, 학술적 합의가 아니라 한 주요 공급자가 자기 경험에서 그은 실무 선이에요. 다른 회사는 다르게 나눠요. 그래서 계약서에 ‘에이전트’라고만 적혀 있으면 그 단어는 아직 아무것도 규정하지 않아요. 문제가 생겼을 때 기준이 되는 건 이름이 아니라 그 아래 붙은 권한 목록과 승인 절차예요. 정의가 합의되지 않은 시장에서 문서를 쓰는 사람은 단어 대신 동작을 적어야 해요.
범주가 쪼개지고 있다는 증거는 기술 표준 쪽에도 있어요. Google이 2026년 3월에 정리한 에이전트 프로토콜 지형에는 MCP2, A2A, UCP, AP23, A2UI, AG-UI가 함께 등장해요.
이 목록을 개발자 관점이 아니라 구매자 관점으로 옮기면 이렇게 읽혀요.
- MCP는 이 도구가 우리 데이터 어디까지 손을 뻗는지를 정해요. 보안 검토 대상이에요.
- A2A는 우리 에이전트가 다른 회사의 에이전트와 직접 대화하는지를 정해요. 계약과 책임 소재의 문제예요.
- UCP와 AP2는 주문과 결제 권한을 다뤄요. 재무와 내부통제가 볼 항목이에요.
- A2UI와 AG-UI는 그 과정이 사람 눈에 어떻게 보이는지를 정해요. 감사와 사용자 경험의 문제예요.
같은 ‘에이전트 도입’인데 심사 부서가 네 곳으로 갈려요. 이건 하나의 제품 범주가 아니라, 여러 층으로 분화 중인 스택이라는 뜻이에요. 이 상태에서 ‘에이전트 추천 5선’ 같은 목록은 정보가 되기 어려워요. 비교 축이 없는 목록은 순위가 아니라 나열이니까요.
같은 모델을 써도 다른 제품이에요
더 까다로운 경우가 있어요. 이름도 같고, 안에 들어간 모델도 같은데 서로 다른 제품인 상황이요.
한쪽 설정에서 이 도구는 캘린더를 읽기만 해요. 일정을 정리해서 보여주고 끝나요. 다른 쪽 설정에서는 같은 도구가 초대장을 발송해요. 참석자 목록을 만들고, 메일을 보내고, 회의실을 잡아요.
기술 사양서에서 이 둘은 구분되지 않아요. 기능 목록에는 ‘캘린더 연동’이라는 한 줄로 똑같이 적히거든요. 그런데 조직 안에서 이 둘은 완전히 다른 물건이에요. 앞쪽은 잘못돼도 사용자가 화면을 닫으면 끝나지만, 뒤쪽은 잘못되면 외부 수신자 30명에게 이미 도착해 있어요.
되돌릴 수 있느냐가 갈리는 지점이에요. Anthropic의 자체 사용 데이터에서도 되돌릴 수 없는 행동은 전체 도구 호출의 1%에 못 미쳤어요. 비중은 작지만 한 번 실행하면 되돌리기 어려우므로 별도의 확인 절차가 필요해요. 다른 호출에서도 사고가 날 수 있다는 점은 구분해야 해요.
그래서 비교표의 행 제목을 제품명으로 잡으면 실패해요. 같은 제품이 서로 다른 두 줄에 들어가야 하는 경우가 생기거든요. 행 제목은 제품이 아니라 권한 조합이어야 해요.
어디까지 맡길 수 있는지 확인해야 해요
독자가 정의를 확인할 때 실제로 알고 싶은 건 단어의 사전적 의미가 아니에요. 어디까지 맡겨도 되는지예요.
2026년 4월 Anthropic이 내놓은 운영 정의도 무엇을 스스로 수행하는지 설명해요. 에이전트는 목표를 위해 계획하고, 행동하고, 결과를 관찰하고, 수정하는 루프를 스스로 도는 시스템이에요. 일이 끝나거나 사람에게 물어야 할 때까지요. 같은 문서는 도구마다 항상 허용, 승인 필요, 차단을 설정하는 방식을 함께 설명해요.
여기서 중요한 게 드러나요. 제품을 실제로 정의하는 건 모델 이름이나 마케팅 문구가 아니라 설정 화면이에요. 그래서 정의는 세 축으로 번역하는 게 실용적이에요.
| 축 | 물어볼 질문 | 확인할 곳 | 위험 신호 |
|---|---|---|---|
| 자율성 | 방법을 스스로 고르나요, 정해진 절차만 따르나요 | 아키텍처 문서, 실패 시 재시도 방식 | ”알아서 처리합니다”만 있고 경로 설명이 없음 |
| 행동권 | 읽기만 하나요, 발송·결제·삭제까지 하나요 | 권한 스코프, 연동 목록 | 읽기와 쓰기 권한을 한 덩어리로 요구 |
| 중단점 | 언제 사람에게 묻고, 실패하면 어떻게 되돌리나요 | 승인 정책, 감사 로그4, 롤백 절차 | 승인 단계가 옵션이고 기본값이 전체 허용 |
이 표를 들고 가면 벤더 미팅의 질문이 바뀌어요. “이건 에이전트인가요”가 아니라 “기본값이 무엇인가요”를 묻게 되거든요. 앞의 질문에는 모든 벤더가 그렇다고 답하지만, 뒤의 질문에는 답이 갈려요.
세 축에서 답이 갈리는 지점도 예상 가능해요. 자율성을 물으면 대체로 후하게 답해요. 자율적일수록 좋아 보이니까요. 행동권을 물으면 답이 짧아져요. 권한 스코프 문서를 그 자리에서 못 여는 경우가 꽤 있어요. 중단점을 물으면 종종 로드맵 이야기가 나와요. “다음 분기에 감사 로그를 붙일 예정입니다”라는 답이 나왔다면, 지금 그 제품은 파일럿 대상이지 도입 대상이 아니에요.
세 축 모두에서 문서로 답이 나오는 벤더는 생각보다 적어요. 그리고 그 소수가 실제 비교표에 올라갈 후보예요. 추천 목록을 좁히는 건 기능 비교가 아니라 이 문서 확인 단계예요.
권한 설정과 계약 조건이 구체화되는지 보려고 해요
지난 호에서 소비자에게 안착한 AI는 전부 이름을 지운 AI였다는 이야기를 다뤘어요. 이번 관찰은 그보다 한 단계 앞이에요. 이름을 지우기 전에, 시장은 먼저 그 이름 아래 무엇을 넣을지 합의해야 해요.
저는 범주가 성숙하는 순간이 정의 문장이 정교해질 때가 아니라고 봐요. 오히려 권한 설정 화면과 계약서가 정교해질 때예요.
클라우드가 그랬어요. 초기에는 “클라우드가 뭔가요”가 검색어였지만, 지금 그 질문을 하는 구매자는 거의 없어요. 대신 리전, 권한 정책, 가용성 보장 조건을 물어요. 질문이 사라진 게 아니라 이동한 거예요. 추상적인 범주 질문이 구체적인 계약 조건 질문으로 옮겨간 순간이 그 시장의 성숙 지점이었어요.
이 해석은 확인해 볼 수 있는 형태로 만들 수 있어요. 제 판단이 맞다면, 앞으로 ‘에이전트 뜻’은 그냥 줄어드는 게 아니라 다른 검색어로 자리를 옮겨야 해요. ‘에이전트 권한 설정’, ‘승인 워크플로 설계’, ‘에이전트 감사 로그’ 같은 운영 질문이 그 자리를 채우는지가 지표예요. 반대로 뜻 검색만 조용히 줄고 운영 질문이 늘지 않는다면, 그건 성숙이 아니라 관심이 식은 거예요. 몇 달 뒤에 같은 데이터로 다시 확인해 볼게요.
판매하는 쪽에도 같은 이야기가 성립해요. 제품 페이지에서 ‘에이전트’라는 단어를 지우고 그 자리에 맡길 수 있는 일과 멈추는 지점을 적으면, 구매자가 뜻을 검색하러 나갈 이유가 줄어들어요. 정의를 확인하려고 다른 페이지로 이동한 방문자는 제품 검토를 중단할 수도 있어요. 카테고리 이름을 설명하는 콘텐츠는 그 카테고리 전체에 기여하지, 특정 제품에 기여하지 않거든요.
마치며
세 줄로 정리할게요.
- 이번 모델에서 뜻이 추천보다 먼저 놓인 것을 저는 비교 기준을 먼저 확인하려는 신호로 해석했어요. 다만 검색 빈도 자체는 추천이 조금 더 높다는 점도 함께 기억해 주세요.
- 지금 ‘에이전트’는 제품 범주가 아니라 여러 층이 섞인 이름표예요. Anthropic조차 정의를 제시하면서 업계 합의가 없다고 적어두고 있어요.
- 그래서 판단 순서를 바꿔야 해요. 무엇을 추천받을지보다, 무엇을 맡길 수 있는지가 먼저예요.
다음에 에이전트 도입 검토 자료를 받으시면, 제품명 칸 옆에 세 칸을 더 만들어 보세요. 스스로 고를 수 있는 범위, 외부 상태를 바꾸는 행동, 승인과 롤백의 위치요. 세 칸이 비어 있는 제품은 아직 비교 대상이 아니라 후보 이전 단계예요.
그리고 검토 회의에서 한 번만 이렇게 물어보세요. “이 도구가 잘못 실행했을 때, 우리 중 누가 몇 분 안에 되돌릴 수 있나요.” 이 질문에 이름과 시간이 함께 나오면 그때부터 추천 목록이 의미를 가져요.
오늘 얻은 관점, 다음 이슈에서도 이어가세요.
쏟아지는 소식 사이에서 오래 남는 한 편을 골라 격일로 보내드립니다.
이메일 확인 후 구독이 완료돼요.
이미 구독 중이신가요? 로그인하고 댓글 남기기
SEND A COFFEE
이 관점이 좋았다면, 다음 글에 커피 한 잔
오스왈드에게 커피와 함께 짧은 쪽지를 보내주세요. 응원은 다음 취재와 집필에 보탭니다.
참고자료 & 더 읽기
핵심 출처
- Anthropic, “Building effective agents”, 2024. 12. 19. 링크 ··· 워크플로와 에이전트를 가르는 기준선이 여기 있어요. 패턴 설명보다 앞부분의 정의 문단을 먼저 읽어보세요.
- Anthropic, “Trustworthy agents in practice”, 2026. 4. 9. 링크 ··· 계획·행동·관찰·수정 루프라는 운영 정의와, 도구별 허용·승인·차단 설정이 함께 나와요. 오늘 글의 세 축이 여기서 왔어요.
- Google Developers Blog, “Developer’s Guide to AI Agent Protocols”, 2026. 3. 링크 ··· MCP, A2A, UCP, AP2, A2UI, AG-UI가 각각 어떤 층을 맡는지 정리돼 있어요. 범주가 하나가 아니라는 걸 가장 빠르게 확인할 수 있는 자료예요.
관련 지난 호
- 단톡방에 없는 기술은 제품이 아니에요 ··· 에이전트가 왜 아직 안 퍼졌는지를 검증 부담 관점에서 다뤘어요.
- AI 에이전트는 이미 준비됐는데, 우리가 아직 못 믿는 거예요 ··· 자율성과 승인 비율, 되돌릴 수 없는 행동의 비중을 실제 사용 데이터로 본 호예요.
용어 설명
각주
-
워크플로(Workflow): 사람이 미리 정해둔 순서대로 도구와 모델을 차례로 호출하는 자동화예요. 실행 전에 경로가 정해져 있어서 테스트와 예측이 쉬워요. ↩
-
MCP(Model Context Protocol): AI가 외부 도구나 데이터에 접근하는 방식을 표준화한 개방형 규격이에요. 도구마다 따로 연결 코드를 짜지 않아도 되게 해줘요. ↩
-
AP2(Agent Payments Protocol): 에이전트가 결제할 때 누가, 어떤 한도로 승인했는지를 증빙 가능한 형태로 남기는 프로토콜이에요. 무엇을 사는지가 아니라 누가 허락했는지를 다뤄요. ↩
-
감사 로그(Audit log): 시스템이 어떤 행동을 언제 누구의 권한으로 했는지 남기는 기록이에요. 사고가 났을 때 되돌릴 지점을 찾는 근거가 돼요. ↩

여러분의 생각이 다음 호를 만듭니다
이번 호에서 가장 공감했거나, 다른 경험을 한 지점은 무엇인가요?