AI 에이전트와 일반 챗봇의 차이 — 실제 프로젝트 관점에서
- AI 에이전트
- Claude
- LLM
- 자동화
- 아키텍처
“저희가 필요한 건 챗봇인가요, 에이전트인가요?” 클라이언트 미팅에서 매주 듣는 질문입니다. 단어 선택처럼 보이지만, 아키텍처·비용·운영 리스크 전부를 가르는 결정입니다. 제가 실제로 어떻게 구분하는지 적습니다.
정의부터 정리하자
두 단어를 섞어 쓰면 설계가 망가집니다. 저는 이렇게 나눕니다.
챗봇은 사용자 입력을 받아 LLM을 한 번 호출하고 답을 돌려줍니다. 상태가 거의 없고, 흐름은 선형이고, 외부 시스템에 쓰지 않습니다. FAQ 봇, 1차 응대, 단순 Q&A가 여기입니다.
AI 에이전트는 목표를 받아 여러 단계를 자율적으로 실행합니다. 도구를 호출하고, 결과를 보고, 다음 행동을 정합니다. 상태를 유지하고, 외부 시스템에 실제로 씁니다. 계약서 파이프라인, 코드 리뷰 봇, 사내 어시스턴트 일부가 진짜 에이전트입니다.
핵심 차이는 두 가지입니다. 자율성, 그리고 루프의 존재.
실제 프로젝트에서 본 차이
챗봇으로 충분했던 사례
유럽의 한 SaaS 고객이 “AI 에이전트로 고객 지원을 자동화하고 싶다”고 했습니다. 티켓 3개월치를 뽑아서 읽어보니 80%가 단순 FAQ 범위였습니다. 결론은 RAG 챗봇 한 개로 끝.
- 입력: 고객 질문
- 처리: 사내 문서에서 관련 청크 검색 → Claude가 답변 생성
- 출력: 답변 + 출처
도구도 루프도 없습니다. 하지만 티켓 45%를 자동 해결했고, 3개월 안에 ROI가 나왔습니다. 여기서는 챗봇이 정답이었습니다. 에이전트를 밀어붙였다면 비용만 두세 배 나왔을 겁니다.
에이전트가 꼭 필요했던 사례
또 다른 클라이언트는 “계약서 PDF를 받아 의무 조항을 추출해 Salesforce에 입력”을 원했습니다. 단계가 명확히 여러 개였습니다.
- PDF에서 텍스트 추출
- 조항 분류 (결제, 해지, 책임 등)
- 각 조항에 메타데이터 부착
- 기존 계약과의 일관성 검증
- Salesforce API 호출로 레코드 생성
- 실패 시 사람에게 에스컬레이션
이걸 챗봇으로 하면 코드가 누더기가 됩니다. LLM이 도구를 호출하고, 결과를 관찰하고, 분기해야 합니다. Claude Agent SDK로 구현했고, 현재 하루 수백 건의 계약서를 처리합니다.
구현 관점에서의 차이
코드로 보면 차이는 분명합니다.
챗봇: 선형 함수
async function handleMessage(query: string, userId: string) {
const chunks = await retrieve(query, userId);
const answer = await claude.messages.create({
model: "claude-sonnet-4-5",
max_tokens: 1024,
messages: [
{ role: "user", content: buildPrompt(query, chunks) },
],
});
return answer;
}한 번의 LLM 호출, 한 번의 DB 조회. 끝. 디버깅도 쉽습니다.
에이전트: 루프 + 도구 + 상태
async function runAgent(goal: string, userId: string) {
const state = { messages: [{ role: "user", content: goal }], done: false };
while (!state.done && state.messages.length < MAX_STEPS) {
const response = await claude.messages.create({
model: "claude-sonnet-4-5",
max_tokens: 2048,
tools: AVAILABLE_TOOLS,
messages: state.messages,
});
state.messages.push({ role: "assistant", content: response.content });
if (response.stop_reason === "tool_use") {
const toolResults = await executeTools(response.content, userId);
state.messages.push({ role: "user", content: toolResults });
} else {
state.done = true;
}
}
return state;
}루프, 도구 실행, 최대 단계, 실패 처리, 감사 로그. 복잡도가 한 자릿수 올라갑니다. 운영 비용도 같이 올라갑니다.
에이전트를 피해야 할 때
흔한 함정 세 가지입니다.
결정 트리로 충분한 경우. 에이전트를 쓰면 비용이 5~10배 들고 예측이 안 됩니다. 규칙 기반이나 단순 챗봇이 낫습니다.
단일 호출로 답이 나오는 경우. “이 문서 요약해 줘”에 에이전트는 사치입니다. LLM 한 번이면 됩니다.
실패 비용이 큰 실시간 트랜잭션. 결제, 법적 효력 있는 작업은 자율 에이전트가 아니라 사람이 최종 승인하는 구조로 설계합니다. 타협하지 않습니다.
에이전트가 제값을 할 때
반대로 다음 조건이 모이면 에이전트가 확실히 낫습니다.
- 작업이 여러 단계로 구성되고, 단계가 입력에 따라 달라진다.
- 외부 시스템 여러 개를 오케스트레이션해야 한다.
- 완료까지 분 단위가 걸려도 괜찮다.
- 실패해도 재시도하거나 사람에게 넘길 수 있다.
계약서 처리, 리서치 태스크, 코드 리뷰 자동화, 복잡한 데이터 이관. 이런 경우입니다.
실전 조언
초기에 결정하세요. 챗봇에서 에이전트로 확장은 쉽지만, 잘못 설계한 에이전트를 챗봇으로 되돌리는 건 전면 재작성입니다.
그리고 에이전트를 만든다고 모든 걸 LLM에 맡기지 마세요. 좋은 에이전트 시스템은 결정론적 코드(확실한 흐름)와 LLM 호출(판단이 필요한 지점)을 명확히 분리합니다. 저는 단계마다 자문합니다. “이거 if/else로 충분한가?” 답이 “예”면 if/else로 씁니다. 그게 운영 가능한 에이전트의 핵심입니다.
에이전트 도입을 고민 중이면 30분 무료 상담으로 유스케이스를 같이 검토해 드립니다.