AI 에이전트란 무엇인가 — 챗봇과 무엇이 다른가

«에이전트»라는 말은 언어모델이 들어간 거의 모든 것에 붙게 됐다. 그건 마케팅의 문제이지 기술의 문제가 아니다. 그 아래에는 꽤 좁고 분명한 정의가 있고, 알아둘 가치가 있다. 무엇이 잘못될 수 있는지가 그 차이에서 결정되기 때문이다.

정의: 도구를 낀 모델이 루프를 돈다

평범한 챗봇은 하나만 한다. 텍스트를 받아 텍스트를 돌려준다. 아는 것은 모델 안에 있거나 프롬프트에 들어 있어야 한다.

에이전트는 세 가지를 더한다.

1. 도구. 모델이 호출할 수 있는 평범한 함수 — 데이터베이스 조회, HTTP 요청, 셸 명령, 파일 쓰기. 모델이 직접 실행하지는 않는다. 구조화된 «호출 요청»을 내보내면 우리 코드가 실행하고, 결과를 되먹인다.
2. 목표. 한 단계보다 위 수준의 과제. "4행을 읽어라"가 아니라 "이 청구서들을 대사(對査)하라".
3. 루프. 도구 결과가 나올 때마다 모델이 다음 행동을 정한다. 목표가 달성됐다고 판단하거나, 단계 한도에 닿거나, 실패할 때까지 계속한다.

그 루프가 전부다. 메모리·계획·서브에이전트·스크래치패드는 모두 그 위에 얹은 최적화다.

도구란 실제로 무엇인가

여기서 사람들이 놀란다. 도구는 특별한 AI 부품이 아니다. 이름과 설명, 인자 스키마를 가진 함수일 뿐이다. 반나절이면 만든다.

name: search_orders
description: 고객 이메일이나 주문번호로 주문을 찾는다.
parameters:
  query: string
  limit: integer (기본 20)

모델은 컨텍스트에 실린 이 설명을 보고 search_orders 가 적절하다고 판단해 인자와 함께 호출을 내보낸다. 실제 함수는 런타임이 실행하고 결과는 텍스트로 돌아온다. 모델이 데이터베이스를 직접 만지는 일은 없다.

여기서 두 가지가 따라 나온다. 첫째, 에이전트는 주어진 도구만큼만 유능하다. 모델이 기여하는 것은 «어느 도구를, 어떤 인자로» 라는 판단뿐이다. 둘째, 도구 «설명»은 프롬프트의 일부다. 지시가 모호하면 답이 틀리듯, 설명이 모호하면 호출이 틀린다.

MCP(Model Context Protocol) 는 모두가 같은 도구 서버를 다시 만드는 일을 멈추려고 존재한다. 서버가 무엇을 제공하는지 광고하는 방식을 표준화해, 하나의 구현이 여러 에이전트 제품을 상대할 수 있게 한다.

어려운 건 신뢰성이다

에이전트는 데모에서는 잘 보이지 않는 방식으로 실패한다. 각 단계가 95% 성공한다고 하자. 언어모델이 판단을 요하는 일을 할 때 나쁘지 않은 수치다.

모델이 잘못된 게 아니다. 오류가 곱해질 뿐이다. 실전에서 도는 에이전트가 하나같이 화려하지 않은 이유가 이것이다 — 5~15단계, 꽉 좁힌 영역, 비싼 지점마다 사람 체크포인트.

벤더 가이드에 반복해서 나오는 원칙도 같은 이유다. 되는 것 중 가장 단순한 구조를 택하라. 잘 쓴 단발 호출이 체인보다 낫고, 체인이 자율 루프보다 낫고, 자율 루프가 에이전트 떼보다 낫다. 한 칸 올라갈 때마다 유연성을 사고 예측 가능성을 지불한다.

에이전트가 실제로 값을 하는 곳

잘 맞는 일에는 공통된 모양이 있다. 목표는 분명하고, 경로는 불분명하며, 결과 «검증»이 싸다.

• 코딩. 테스트는 통과하거나 안 하거나다. 객관적 신호를 보고 스스로 반복할 수 있다.
• 조사와 수집. 여러 출처에서 자료를 모으는 일 — 어차피 사람이 결과를 읽는다.
• 분류(트리아지). 티켓 분류·라우팅, 이상 표시, 검토용 초안 작성.
• 데이터 정리. 스키마가 «거의» 같은 시스템들 사이의 레코드 대사.

반대로 잘 맞지 않는 일은 그 거울상이다. 검증이 비싸거나, 실수를 되돌릴 수 없거나, 올바른 경로가 이미 정해져 있는 경우 — 마지막 경우엔 그냥 스크립트를 쓰면 된다. 야간 리포트를 보내는 데 에이전트가 필요한 사람은 없다.

권한 경계

에이전트는 자기 단계를 스스로 정하므로, «무엇을 할 수 있는가»를 코드 경로를 읽어 답할 수 없다. 모델 «바깥»에서 강제해야 한다.

실무적으로는 이렇게 된다.

• 읽기는 넓게, 쓰기는 좁게. 필요한 건 다 보게 하되, 상태를 바꾸는 행동마다 관문을 둔다.
• 되돌릴 수 없는 일엔 승인. 돈, 외부 발신, 삭제, 프로덕션 배포.
• 예산. 단계 수, 실제 시간, 토큰 지출을 상한 짓는다. 루프에 갇힌 에이전트는 곧 과금 사고다.
• 재생 가능한 로그. 모든 도구 호출과 결과를 남긴다. 문제가 났을 때 «실제로 무엇을 했는가»가 몇 초 안에 답해져야 한다.

프롬프트 인젝션은 따로 언급할 값어치가 있다. 에이전트가 웹페이지·메일·PR 코멘트를 읽는다면, 공격자는 그 내용 안에 지시를 심을 수 있다. 모델은 우리 지시와 방금 읽은 지시를 신뢰성 있게 구분하지 못한다. 방어는 더 좋은 프롬프트가 아니라, 애초에 그 권한을 주지 않는 것이다.

과장과 실체를 가르는 법

«에이전틱»을 표방하는 제품 앞에서 세 가지만 물어보면 된다.

1. 정확히 어떤 도구를 부를 수 있나? 읽을 수 있는 목록인가, 손짓인가?
2. 한 단계가 실패하면 어떻게 되나? 재시도·상신·중단인가, 아니면 조용히 그럴듯한 오답을 내놓는가?
3. 묻지 않고 할 수 있는 일은 무엇인가? 답이 "전부"라면 그건 자율성이 아니라 한계 없는 책임이다.

에이전트는 더 똑똑한 챗봇이 아니다. 조종간에 손을 얹은 챗봇이고, 중요한 엔지니어링은 거의 전부 그 손에 관한 것이다.