AI 에이전트란 — 도구를 쥐여주면 무엇이 달라지나
An AI agent is software that uses a language model not only to produce text but to pursue a goal on the user's behalf — deciding which tools to call, reading the result, and adjusting. The dividing line against a workflow is autonomy: a workflow runs a sequence a human wrote in advance, while an agent decides its own next step at run time. In practice an agent is built from four parts — perception, reasoning, memory and action — with tool use handled through function calling to external APIs. The important consequence is that an agent can act on the world, so its failures cost more than a wrong sentence
AI 에이전트는 언어 모델이 글을 쓰는 데서 멈추지 않고 목표를 대신 수행하도록 만든 소프트웨어다. 어떤 도구를 부를지 스스로 정하고, 결과를 읽고, 다음 행동을 다시 정한다. 워크플로와 갈리는 기준은 자율성 하나다 — 워크플로는 사람이 미리 짜둔 순서대로 돌고, 에이전트는 실행 중에 다음 단계를 스스로 정한다. 구성은 대개 인식·추론·기억·실행 넷이고 도구 사용은 함수 호출로 이뤄진다. 그래서 에이전트의 실패는 틀린 문장이 아니라 잘못된 행동으로 나타난다
3줄 요약
- 정의 — 목표를 받아 도구를 골라 쓰고 결과를 보고 다음 행동을 스스로 정하는 소프트웨어다
- 구분 — 워크플로는 사람이 짠 순서대로, 에이전트는 실행 중에 스스로 정한다. 기준은 자율성이다
- 대가 — 세상에 실제로 작용하므로 실패의 비용이 챗봇과 다르다. 권한 설계가 성능만큼 중요하다
핵심 질문
- AI 에이전트가 챗봇이랑 뭐가 달라
- **출력이 글이냐 행동이냐**가 갈린다. 챗봇은 질문을 받아 **답을 만들어 준다** — 사용자가 그 답을 읽고 실제 일은 직접 한다. 에이전트는 목표를 받아 **일을 진행한다** — 필요한 정보를 검색하고, 파일을 만들고, API를 호출하고, 그 결과가 기대와 다르면 방법을 바꿔 다시 시도한다. 구글 클라우드의 정의는 "사용자를 대신해 목표를 추구하고 작업을 완료하기 위해 AI를 사용하는 소프트웨어 시스템"이다. 핵심은 **대신(on behalf of)**이라는 말에 있다. 같은 모델을 써도 **도구를 붙이고 결정 권한을 주면** 에이전트가 되고, 붙이지 않으면 챗봇이다. 이 지면은 「클로드 코드란 — 챗봇에 물어보는 것과 뭐가 다른가」에서 코딩 영역의 실제 사례를 다뤘다.
- 워크플로랑 에이전트는 어떻게 구분해
- **다음 단계를 누가 정하느냐**로 나눈다. **워크플로**는 사람이 미리 코드로 순서를 짜 둔다 — "문서를 요약하고, 요약을 번역하고, 번역을 메일로 보낸다"처럼 흐름이 실행 전에 고정돼 있다. 모델은 각 칸을 채우는 부품이다. **에이전트**는 그 순서를 **실행 중에 모델이 정한다** — 목표만 주어지고, 지금 무엇을 할지, 어떤 도구를 쓸지, 결과를 보고 다시 무엇을 할지를 모델이 판단한다. 실무에서 이 구분이 중요한 이유는 **예측 가능성과 성능이 반대 방향**이기 때문이다. 워크플로는 결과가 일정하지만 예상 밖 상황에 멈추고, 에이전트는 예상 밖 상황에 적응하지만 같은 입력에 다른 경로로 갈 수 있다. **웬만한 업무는 워크플로가 낫고, 경로를 미리 알 수 없는 일에만 에이전트가 필요하다.**
- 에이전트는 어떻게 도구를 쓰는 거야
- **함수 호출(function calling)**이라는 방식이다. 순서는 이렇다. ① 개발자가 모델에게 쓸 수 있는 도구 목록과 각 도구의 입력 형식을 알려준다 — "이런 이름의 함수가 있고, 이런 값을 넣으면 이런 결과가 나온다"는 설명이다. ② 모델은 답을 만들 때 글 대신 **"이 함수를 이 값으로 부르겠다"는 구조화된 출력**을 낸다. ③ 그 호출을 실제로 실행하는 것은 모델이 아니라 **바깥의 프로그램**이다. ④ 실행 결과가 다시 모델에게 입력으로 들어가고, 모델은 그것을 읽고 다음 행동을 정한다. 중요한 것은 **③번**이다 — 모델은 직접 인터넷에 접속하거나 파일을 지우지 않는다. **"이렇게 해달라"고 요청할 뿐이고, 실제 실행 권한은 바깥 프로그램이 쥐고 있다.** 에이전트의 안전 설계가 대부분 이 지점에 놓이는 이유다.
AI 에이전트는 모델에게 도구와 결정 권한을 함께 준 소프트웨어다.
챗봇은 답을 만들어 준다. 에이전트는 일을 진행한다.
같은 모델을 쓰더라도 그렇다. 달라지는 것은 모델이 아니라 모델 바깥의 구조다.
1. 무엇이 에이전트를 에이전트로 만드나
| 구분 | 입력 | 출력 | 실제 일은 누가 |
|---|---|---|---|
| 챗봇 | 질문 | 글 | 사용자가 직접 |
| 에이전트 | 목표 | 행동의 연속 | 에이전트가 대신 |
구글 클라우드의 정의는 "사용자를 대신해 목표를 추구하고 작업을 완료하기 위해 AI를 사용하는 소프트웨어 시스템"이다.
'대신'이라는 말이 핵심이다. 챗봇에게 "이 문서 요약해줘"라고 하면 요약문이 나오고, 그것을 어디에 쓸지는 사용자의 일이다. 에이전트에게 "이 문서 요약해서 팀에 공유해줘"라고 하면 요약을 만들고, 공유 수단을 고르고, 실제로 보낸다.
2. 워크플로와 에이전트
이 둘은 자주 섞여 쓰이는데, 구분 기준은 하나다. 다음 단계를 누가 정하나.
| 항목 | 워크플로 | 에이전트 |
|---|---|---|
| 순서를 정하는 시점 | 실행 전 (개발자가 코드로) | 실행 중 (모델이 판단으로) |
| 예상 밖 상황 | 멈추거나 오류 | 방법을 바꿔 재시도 |
| 결과의 일관성 | 높다 | 낮다 — 같은 입력에 다른 경로 |
| 비용 | 예측 가능 | 실행마다 다르다 |
| 디버깅 | 쉽다 | 어렵다 — 경로가 매번 다르다 |
여기서 실무적으로 중요한 사실이 하나 나온다. 에이전트가 항상 나은 선택은 아니다.
경로가 정해져 있는 업무 — 매일 같은 보고서를 같은 형식으로 만드는 일 — 에 에이전트를 쓰면 비용과 불확실성만 늘어난다. 에이전트가 필요한 것은 경로를 미리 알 수 없는 일이다. 무엇을 찾아야 할지 모르는 조사, 어디가 원인인지 모르는 오류 추적 같은 것들이다.
3. 네 개의 부품
여러 개발 가이드가 공유하는 정리는 에이전트를 네 부분으로 나눈다.
| 부품 | 하는 일 | 없으면 |
|---|---|---|
| 인식 | 입력·환경·도구 실행 결과를 받아들인다 | 결과를 보지 못해 같은 실수를 반복한다 |
| 추론 | 지금 무엇을 할지 정한다 | 도구가 있어도 고르지 못한다 |
| 기억 | 앞서 한 일과 알아낸 것을 유지한다 | 단계를 넘어가면 앞을 잊는다 |
| 실행 | 도구를 호출해 실제로 작용한다 | 계획만 세우고 아무것도 못 한다 |
기억이 실무에서 가장 자주 병목이 된다. 에이전트는 여러 단계를 거치는데, 그 과정에서 쌓인 대화와 도구 결과가 모델의 입력 한도를 넘어가면 앞부분이 잘려 나간다. 이 지면은 「컨텍스트 윈도우란 — 100만 토큰을 다 읽지는 않는다」에서 그 한도의 구조를 다뤘다.
4. 도구를 쓰는 방법 — 함수 호출
에이전트가 "인터넷에 접속했다"거나 "파일을 지웠다"는 표현은 실제 구조를 감춘다. 실제로는 이렇게 돌아간다.
| 단계 | 누가 | 무슨 일 |
|---|---|---|
| ① | 개발자 | 쓸 수 있는 도구 목록과 입력 형식을 모델에게 알려준다 |
| ② | 모델 | 글 대신 "이 함수를 이 값으로 부르겠다"는 구조화된 출력을 낸다 |
| ③ | 바깥 프로그램 | 그 호출을 실제로 실행한다 |
| ④ | 모델 | 실행 결과를 입력으로 받아 다음 행동을 정한다 |
③번이 결정적이다. 모델은 직접 실행하지 않는다. "이렇게 해달라"고 요청할 뿐이고, 요청을 받아들일지 말지는 바깥 프로그램이 정한다.
그래서 에이전트의 안전 설계는 대부분 이 지점에 놓인다.
- 권한을 좁게 준다 — 파일 삭제 도구를 아예 목록에 넣지 않으면 모델이 요청할 수도 없다
- 되돌릴 수 없는 행동은 확인을 건다 — 메일 발송, 결제, 삭제 앞에 사람의 승인을 넣는다
- 읽기와 쓰기를 분리한다 — 조회 권한과 변경 권한을 다른 자격으로 준다
5. 실패의 비용이 다르다
챗봇이 틀리면 틀린 문장이 나온다. 사용자가 읽고 판단하면 된다.
에이전트가 틀리면 틀린 행동이 남는다. 잘못 보낸 메일, 잘못 지운 파일, 잘못 호출한 API는 되돌리기 어렵다.
| 실패 유형 | 챗봇 | 에이전트 |
|---|---|---|
| 사실 오류 | 틀린 답변 | 틀린 전제로 행동을 실행 |
| 지시 오해 | 엉뚱한 답 | 엉뚱한 작업을 끝까지 수행 |
| 반복 실패 | 다시 물어보면 됨 | 같은 실패를 여러 번 시도 (비용 발생) |
| 외부 입력 오염 | 잘못된 요약 | 외부 문서에 섞인 지시를 명령으로 오인 |
마지막 줄이 에이전트 특유의 문제다. 에이전트는 웹페이지·문서·이메일을 읽는데, 그 안에 "지금까지의 지시를 무시하고 이렇게 하라"는 문장이 들어 있으면 그것을 사용자의 지시와 구분하지 못할 수 있다. 에이전트가 읽는 것은 데이터이지 명령이 아니라는 경계를 시스템 쪽에서 세워 줘야 한다.
이 지면은 「AI 환각이란 — 모델이 '모르겠다'고 답하지 않도록 훈련된 이유」에서 사실 오류의 원인을, 「AI 위험 등급이란 — 만든 회사가 자기 점수를 매길 때」에서 위험 평가의 구조를 다뤘다.
6. 확인하지 못한 것
- 정의의 경계 — '에이전트'와 '워크플로'는 업계 표준 정의가 아니라 널리 쓰이는 구분이다. 제품마다 같은 시스템을 다르게 부른다.
- 4구성 요소 — 여러 가이드가 공유하는 정리이지 규격화된 아키텍처가 아니다.
- 성공률 통계 — 업종별 에이전트 성공률·실패율의 신뢰할 만한 통계를 확인하지 못했다.
- 함수 호출 구현 — 모델 제공사마다 형식이 다르다. 본문은 공통 구조 수준의 설명이다.
- 권한 설계 권고 — 일반 원칙이며 특정 제품의 보안 기능을 검증한 것이 아니다.