Agent란 무엇인가 — Chatbot도, RAG를 얹은 챗봇도 아니다
← 전체 목차 · 이전: Agent와 Workflow, 뭐가 다른가 · 다음: Agent 효과는 모델이 전부 결정하는가
"도구를 호출할 수 있으면 Agent다", "지식베이스를 붙이면 Agent다" — 둘 다 표면 기능을 정의로 착각한 것이다. 도구 호출은 Chatbot에도, RAG 시스템에도 얼마든지 붙일 수 있다. Agent를 가르는 선은 기능 목록이 아니라 목표를 받은 뒤 누가 다음 스텝을 계속 결정하는가다.
질문 구동 vs 목표 구동
| 일반 LLM 대화 / Chatbot | RAG 문답 시스템 | AI Agent |
|---|
| 입력 단위 | 질문 한 마디 | 질문 한 마디 + 검색 | 최종 달성 목표 |
| 실행 단위 | 1회 추론 | 1회 검색-증강 추론 | 완전한 자율 루프 |
| 호출 간 관계 | 서로 독립 | 서로 독립 | 하나의 작업 컨텍스트로 연결 |
| 사용자 개입 안 하면 | 아무 일도 안 일어남 | 아무 일도 안 일어남 | 스스로 끝까지 진행 |
| 이상 처리 | 없음 | 없음 | 재시도·정보 보완·경로 수정 |
| 해결하는 문제 | 말이 되는 답변 | "답이 정확한가" | "일이 되었는가" |
한 줄로 요약하면: Chatbot과 RAG는 묻는 만큼만 답하고 멈추고, Agent는 목표 하나로 끝까지 간다.
자율 폐루프: 감지 – 계획 – 행동 – 검증 – 반성
목표 수신
→ 목표 분해 (무엇부터 할지)
→ 필요 자원 판단 (기억·도구 중 무엇을 쓸지)
→ 실행 스텝 생성
→ 도구 조달 (검색 / 계산 / API 호출)
→ 스텝마다 결과 검증
→ 경로 동적 수정
→ 목표 달성까지 반복
이 루프를 실무에서 구현하는 가장 흔한 형태가 **ReAct(생각→행동→관찰)**다. 모델이 매 턴 "지금 도구를 불러야 하는가, 부른다면 무엇을"을 스스로 판단(Thought)하고, 실행(Action)한 뒤, 그 결과(Observation)를 다시 판단의 입력으로 삼아 순환한다. 이 순환이 멈추는 시점(목표 달성 판정)까지가 하나의 Agent 작업 단위이며, 묻고 답하고 끝나는 단발 호출과는 완전히 다른 실행 구조다.
Agent를 이루는 최소 구성
| 모듈 | 역할 | 없으면 생기는 일 |
|---|
| 계획 | 목표를 실행 가능한 하위 작업으로 분해·정렬 | 복잡한 다단계 요구를 처리 못 하고 한 번에 답하려다 무너짐 |
| 도구 호출 | 외부 접점(검색·DB·API·코드 실행)으로 실제 조작 수행 | 지식과 언어만 있고 세상에 영향을 못 미침 |
| 기억 | 작업 이력·사용자 선호·중간 결과를 다음 스텝에 이어줌 | 매 스텝이 무에서 시작해 앞서 확정한 제약을 잊음 |
| 검증·반성 | 이번 스텝이 맞았는지, 목표에 부합하는지 스스로 판정 | 실패해도 모르고 계속 진행 — 멈춰야 할 때 못 멈춤 |
네 모듈 중 하나라도 빠지면 폐루프가 어딘가에서 끊긴다. "검증·반성"이 없는 시스템이 가장 위험한데, 실패를 스스로 감지하지 못하므로 무한 반복이나 조용한 오작동으로 이어지기 쉽다.
왜 "RAG를 붙이면 Agent"가 틀린가
RAG가 주는 것은 외부 정보원이다. 모델이 학습 데이터 밖의 사실을 근거로 더 정확히 답하게 해줄 뿐, 사용자가 묻지 않으면 아무 것도 하지 않는다는 성질 자체는 그대로다. 문서 라이브러리를 연결한 "강화된 문답 시스템"을 만들어도:
- 검색은 하지만 작업을 쪼개지 않는다
- 흐름을 계획하지 않는다
- 중간에 이상이 생겨도 처리하지 않는다
그래서 RAG는 Agent가 골라 쓸 수 있는 도구 중 하나이지 Agent 자체가 아니다. RAG는 "정보를 정확히 찾아오는" 문제를 풀고, Agent는 "정보를 쓰고, 판단하고, 행동해서 결과를 만드는" 문제를 푼다. 지식베이스를 아무리 잘 구축해도 이 경계를 넘지 못하면 업무는 여전히 해결되지 않은 채로 남는다 — "지식베이스도 완성했고 검색 정확도도 잡았는데, 실제 업무 문제는 그대로"라는 증상이 바로 이 오해의 결과다.
1초 판정법
사용자가 최종 요구만 입력하고
전 과정 개입 없이
시스템이 알아서 전부 완료 → Agent
사용자가 한 스텝씩 질문하고
한 스텝씩 이끌고
나눠서 조작해야 함 → 그냥 질문-응답 시스템
이 판정법을 뒤집으면 그대로 성숙도 지표가 된다: 하나의 작업을 완료하는 데 사람이 몇 번 개입해야 하는가. 개입 횟수가 0에 가까울수록 진짜 Agent에 가깝다.
핵심 통찰
- 구성 요소 목록으로는 Agent를 정의할 수 없다 — 벡터DB가 있는지, 도구 호출이 있는지는 전부 재료표일 뿐이다. 진짜 분수령은 "다음 스텝을 누가 정하는가"이며, 재료가 아무리 화려해도 다음 행동이 항상 사람에게서 나온다면 질문-응답 시스템이다.
- "묻지 않으면 움직이지 않는다"가 가장 확실한 판별 지문이다 — 계획이 있는지 없는지보다 훨씬 관측하기 쉬운 기준이다. 사용자가 침묵할 때 시스템이 스스로 다음 행동을 시작하는지만 보면 된다.
- 폐루프의 핵심은 "실행"이 아니라 "검증"이다 — 목표를 스텝으로 쪼개고 도구를 부르는 것은 파이프라인만 길어진 것일 뿐, 매 스텝 결과를 검증하고 경로를 다시 조정하는 회로가 있어야 비로소 선형 실행이 폐루프로 바뀐다. 검증 없는 다단계 실행은 그저 프롬프트를 길게 이어붙인 것과 다르지 않다.
- 기억은 실행 로그가 아니라 계획의 입력이다 — "과거 기억을 바탕으로 필요한 자원을 판단한다"는 것은 기억이 사후 추적용이 아니라 의사결정에 참여한다는 뜻이다. 대화 이력을 캐시처럼 쌓아두기만 하는 것은 기억 모듈의 실제 역할을 놓친 것이다.
- RAG와 Agent는 같은 축의 두 단계가 아니라 서로 다른 축이다 — RAG는 단일 답변의 정보 품질을 높이고, Agent는 작업의 완수 방식을 바꾼다. 그래서 "RAG를 계속 고도화하면 언젠가 Agent가 된다"는 명제는 성립하지 않는다 — 축 자체가 다르기 때문이다.
- 자율도는 설계해야 할 값이지 무조건 높일 지표가 아니다 — 완전 자율 Agent가 항상 정답은 아니다. 실제 업무는 비용·지연·안전성·통제 가능성과 함께 저울질해야 하며, 그래서 주요 지점마다 사람이 개입하는 "반자율" 형태가 산업 현장에서는 더 흔하다.
- Agent는 프로덕션에서 "대체"가 아니라 "단위"로 배치된다 — 업무 흐름 안에 끼워 넣는 지능 증강 단위로 취급하면 경계가 분명하고 모니터링·롤백이 가능하지만, 사람을 완전히 대체하는 블랙박스로 취급하면 통제력을 잃는다.
엔지니어링 실전 Tips
- 면접·설계 리뷰에서 "도구 호출 여부"로 시작하지 말 것. "사용자가 침묵할 때 시스템이 다음 행동을 스스로 시작하는가"로 먼저 물으면 즉시 판별된다.
- 검증·반성 모듈을 가장 먼저 검사할 것. 계획·도구·기억은 있는데 검증이 없는 시스템은 겉보기엔 Agent 같아도 실패를 스스로 감지하지 못해 가장 먼저 사고로 이어진다.
- RAG를 Agent의 "도구 중 하나"로 설계할 것. 검색 모듈을 Agent 파이프라인의 최상위에 놓지 말고, 계획 단계가 필요하다고 판단했을 때만 호출되는 하위 도구로 배치해야 역할이 명확해진다.
- 개입 횟수를 성숙도 지표로 계측할 것. 하나의 대표 작업을 완료하는 데 필요한 평균 인간 개입 횟수를 추적하면, "겉보기 Agent"와 "실제 자율 Agent"를 숫자로 구분할 수 있다.
- 목표 컨텍스트를 대화 이력과 분리해서 별도로 유지할 것. 최초 목표가 장문의 대화 이력 속에 묻히면, 스텝을 거듭할수록 조금씩 원래 목표에서 벗어나는 "표류"가 발생한다.
- 완전 자율을 기본값으로 삼지 말 것. 비용·시간·리스크가 큰 액션 앞에는 확인 지점을 두는 반자율 설계를 기본으로 하고, 완전 자율은 검증된 저위험 구간에만 허용할 것.