[AI] 도구, 메모리, 계획: 챗봇과 AI 에이전트를 가르는 세 가지 기준

요즘 "AI 에이전트"라는 말을 정말 자주 듣습니다. 그런데 막상 "그래서 챗봇이랑 뭐가 다른데?"라는 질문을 받으면 선뜻 답하기 어렵습니다. 둘 다 LLM을 쓰고, 둘 다 자연어로 대화하기 때문입니다.

이 글은 IBM의 「AI 에이전트란 무엇인가?」 문서를 읽으며 공부한 내용을 바탕으로, 챗봇과 AI 에이전트의 차이를 도구, 메모리, 계획이라는 세 가지 기준으로 정리한 기록입니다. 그리고 그 기준을 Claude Code와 Codex로 개발해 온 제 경험에 대어 보았습니다.

LLM만으로는 왜 부족할까

출발점은 LLM의 한계입니다. LLM은 학습한 데이터를 기반으로 응답을 만듭니다. 학습이 끝난 시점에 지식이 멈춘다는 뜻입니다. 오늘 날씨, 회사 내부 문서, 지난번에 나눴던 대화처럼 학습 데이터에 없는 정보는 알 수 없습니다.

또 LLM은 기본적으로 질문 하나에 답 하나를 내놓는 구조입니다. "내년에 그리스에서 서핑하기 가장 좋은 주를 알려줘" 같은 요청은 여러 단계의 조사와 판단이 필요한데, 한 번의 응답으로는 그럴듯한 추측밖에 할 수 없습니다.

AI 에이전트는 이 빈틈을 메우기 위해 등장했습니다. IBM은 에이전트를 이렇게 정의합니다.

가용 도구를 사용해서 워크플로를 설계하고 작업을 자동으로 수행하는 시스템

핵심에는 여전히 LLM이 있습니다. 달라지는 것은 LLM 주변에 무엇을 붙였느냐입니다.

챗봇과 에이전트를 가르는 세 가지 기준

IBM 문서에서 챗봇과 에이전트를 비교하는 대목을 정리하면, 결국 세 가지 질문으로 모입니다. 모르는 것을 스스로 찾아오는가, 지난 경험을 기억하는가, 다음 단계를 스스로 정하는가입니다.

1. 도구 — 모르는 걸 스스로 찾아오는가

비에이전틱 챗봇은 내부 지식만으로 답합니다. 모르면 모르는 대로, 혹은 틀린 채로 답합니다.

에이전트는 정보가 부족하다고 판단하면 외부 데이터베이스, 웹 검색, API, 심지어 다른 에이전트까지 호출해서 정보 격차를 메웁니다. 서핑 예시라면 지난 몇 년간의 그리스 일기 예보 DB를 조회하고, 서핑 전문 에이전트에게 좋은 서핑 조건이 무엇인지 물어봅니다.

챗봇

학습 데이터 안에서만 답합니다. 모르는 정보는 추측으로 채워지고, 그 추측이 틀려도 스스로 알 방법이 없습니다.

에이전트

정보가 부족하다고 판단하면 검색, DB, API, 다른 에이전트를 호출해 필요한 정보를 직접 가져옵니다.

2. 메모리 — 지난 경험을 기억하는가

챗봇은 메모리가 없어서 응답이 만족스럽지 않아도 실수로부터 배우지 못합니다. 매번 처음 만나는 사람처럼 대화합니다.

에이전트는 과거 상호작용과 사용자 피드백을 저장합니다. 그래서 시간이 지날수록 사용자 선호에 맞춰지고, 한 번 해결한 문제의 해법을 다음에 다시 꺼내 쓸 수 있습니다.

챗봇

대화가 끝나면 잊습니다. 같은 설명을 매번 반복해야 하고, 지난번의 실수도 그대로 반복될 수 있습니다.

에이전트

상호작용과 피드백을 저장하고 다음 작업에 반영합니다. 쓸수록 사용자와 프로젝트에 맞춰집니다.

3. 계획 — 다음 단계를 스스로 정하는가

챗봇은 사용자가 계속 입력을 줘야 움직입니다. 다음에 무엇을 할지는 사용자가 정합니다.

에이전트는 복잡한 목표를 하위 작업으로 쪼개고, 실행하면서 얻은 정보로 계획을 다시 평가하고 수정합니다. 서핑 예시에서 날씨 데이터만으로 결론을 내리지 못하자 "서핑 조건 알아보기"라는 하위 작업을 스스로 만든 것이 바로 이 부분입니다.

Goal 내년에 그리스에서 서핑하기 가장 좋은 주 찾기

↓

Plan · 하위 작업 1 과거 그리스 일기 예보 DB를 조회한다

↓

Re-plan · 하위 작업 추가 날씨만으로는 판단할 수 없다 → "서핑 조건 알아보기" 작업을 스스로 만든다

↓

Tool · 하위 작업 2 서핑 전문 에이전트에게 좋은 서핑 조건을 묻는다

↓

Result 두 정보를 종합해 가장 좋은 주를 답한다

세 가지 기준을 표로 정리하면 다음과 같습니다.

기준	비에이전틱 챗봇	AI 에이전트
도구	내부 지식만 사용	검색, API, 다른 에이전트 호출
메모리	대화가 끝나면 잊음	피드백을 저장하고 적응
계획	사용자 입력에 의존	작업 분해와 자기 수정

챗봇 시절, 세 가지 역할은 내가 하고 있었다

이 표를 제 개발 경험에 대어 보면 차이가 꽤 선명합니다.

Claude Code나 Codex가 나오기 전에는 ChatGPT에 코드를 붙여넣고 기능 구현이나 코드 리뷰를 요청했습니다. 문제는 챗봇이 제 프로젝트를 전혀 모른다는 점이었습니다. 프로젝트 상황을 매번 직접 설명해야 했고, 그래도 프로젝트에 맞지 않는 일반적인 답이 돌아와서 채팅을 몇 번씩 주고받으며 다듬어야 했습니다.

비슷한 작업을 할 때마다 이 과정이 반복됐습니다. 돌아보면 필요한 코드를 골라 붙여넣는 일(도구), 프로젝트 맥락을 다시 설명하는 일(메모리), 다음에 무엇을 물어볼지 정하는 일(계획)을 전부 제가 대신하고 있었던 셈입니다.

에이전트가 작업을 나눠 맡긴 경험

지금은 Claude Code와 Codex로 개발합니다. 한번은 코드 리뷰와 검증을 요청했더니 에이전트가 작업을 나눠 서브 에이전트들에게 맡겼습니다. 하나는 코드와 테스트 코드를 기준으로 검증하고, 다른 하나는 ADB로 실제 디바이스에서 기능을 직접 써 보며 테스트했습니다.

Request 코드 리뷰와 검증을 요청한다

↓

Plan 메인 에이전트가 작업을 "코드 검증"과 "실기기 검증"으로 나눈다

↓

Tool · Sub-agent 리뷰 에이전트는 코드와 테스트 코드를, 테스트 에이전트는 ADB로 실제 디바이스를 검증한다

↓

Result 실기기 테스트는 통과, 그러나 테스트 코드가 기능을 제대로 검증하지 못한다는 지적

흥미로운 것은 결과였습니다. 실물 테스트는 성공했는데, 리뷰 에이전트가 테스트 코드의 잘못된 부분을 지적했습니다. 기능은 제대로 동작하지만, 테스트가 그것을 제대로 검증하지 못하고 있었던 것입니다. 덕분에 검증 체계 자체를 더 단단하게 만들 수 있었습니다.

이것은 IBM의 서핑 예시와 같은 구조입니다. 목표를 하위 작업으로 쪼개고(계획), 각 작업에 맞는 수단을 골라 다른 에이전트에게 맡기고(도구), 결과를 종합해 판단했습니다. 챗봇 시절 제가 직접 하던 일을 에이전트가 가져간 것입니다.

그래도 경계는 사람이 정한다

물론 전부 맡겨 둘 수는 없었습니다. 테스트 코드를 검증하던 에이전트가 테스트를 통과시키려고 프로덕션 코드까지 고치려 한 적이 있었는데, 그것은 이번 작업 범위 밖이라 제가 막았습니다.

에이전트가 스스로 계획을 세우더라도, 어디까지 손대도 되는지는 사람이 정해 줘야 합니다. IBM이 말하는 HITL(Human-in-the-Loop)이 왜 필요한지 체감한 순간이었습니다.

계획 능력이 강할수록 범위 설정이 중요해진다

에이전트는 목표를 달성하기 위한 가장 짧은 길을 찾습니다. "테스트를 통과시켜라"라는 목표만 주어지면 테스트가 아니라 프로덕션 코드를 고치는 것도 하나의 해법이 됩니다. 스스로 계획을 세우는 능력이 생긴 만큼, 작업 범위와 금지 영역을 명확히 알려주는 일이 사람의 몫으로 남습니다.

제품 이름이 아니라 정도의 문제

다만 경계가 생각보다 흐릿하다는 점도 짚고 싶습니다. 지금의 ChatGPT나 Claude 웹도 웹 검색, 메모리 같은 기능이 붙으면서 예전보다 에이전트 쪽으로 많이 다가왔습니다.

그래서 "ChatGPT는 챗봇, Claude Code는 에이전트"처럼 제품 이름으로 나누기보다는, 세 가지 능력을 얼마나 갖췄느냐의 정도 문제로 보는 것이 맞다고 생각합니다. IBM이 챗봇은 하나의 "양식"이고 에이전시는 "기술 프레임워크"라고 구분한 것도 같은 맥락이라고 이해했습니다.

그렇다고 모든 것을 에이전트로 만들 필요는 없습니다. IBM도 간단한 작업이라면 계획 단계 없이 응답을 반복해서 다듬는 것만으로 충분하다고 말합니다. 질문 하나에 답 하나로 끝나는 일에 계획과 도구 호출을 붙이면, 오히려 비용과 지연만 늘어납니다.

정리하며

챗봇과 AI 에이전트는 둘 다 LLM 위에 서 있습니다. 차이는 모델 자체가 아니라 그 주변에 붙은 능력에서 나옵니다. 모르는 것을 찾아오는 도구, 지난 경험을 기억하는 메모리, 다음 단계를 스스로 정하는 계획입니다.

챗봇 시절에는 이 세 가지를 사람이 대신했습니다. 에이전트는 그 일을 가져갔지만, 어디까지 해도 되는지 정하는 일은 여전히 사람에게 남아 있습니다. 제가 이해한 한 줄 정의는 이렇습니다.

AI 에이전트는 LLM에 도구, 메모리, 계획을 더해, 사용자가 일일이 지시하지 않아도 목표까지 스스로 나아가는 시스템이다.

레퍼런스: IBM - AI 에이전트란 무엇인가?

Key Points

• AI 에이전트의 핵심은 여전히 LLM입니다. 달라지는 것은 LLM 주변에 무엇을 붙였느냐입니다.
• 도구: 에이전트는 정보가 부족하면 검색, DB, API, 다른 에이전트를 호출해 스스로 메웁니다.
• 메모리: 과거 상호작용과 피드백을 저장해, 쓸수록 사용자와 프로젝트에 맞춰집니다.
• 계획: 목표를 하위 작업으로 쪼개고, 실행 중 얻은 정보로 계획을 다시 수정합니다.
• 경계는 사람이 정합니다. 스스로 계획을 세우는 만큼, 작업 범위를 정하는 HITL이 필요합니다.
• 챗봇과 에이전트는 정도의 문제입니다. 제품 이름보다 세 가지 능력을 얼마나 갖췄는지로 봐야 합니다.