AI 에이전트(AI Agent) 는 거대한 단일 모델이 아니라 작은 AI 호출을 계획·실행·관찰·재계획 루프로 이어 붙여 목표를 푸는 구조다. 자동 코드 작성, 리서치, 업무 자동화처럼 한 번의 호출로 풀리지 않는 복합 작업이 늘면서 도입 사례가 빠르게 늘고 있다.
단일 호출로 끝나는 줄 알았던 시절이 있었다. 자료를 여러 군데서 모아 보고서를 만드는 일이 들어오자 한 번 호출로는 답이 나오지 않았다. 그때부터 에이전트 루프를 직접 만들어 보면서 속도와 비용 사이에서 한참 헤맸다. 그 과정에서 단일 호출 → RAG → 에이전트 순으로 옮겨 가야 한다는 걸 몸으로 익혔다.
에이전트가 뭐고 왜 등장했나
에이전트는 단일 AI랑 뭐가 다른가
AI 에이전트는 하나의 거대한 AI가 아니다. 작은 AI 호출을 여러 번 이어 붙여 목표를 이루는 구조다. 단일 호출은 “질문 한 번 → 답 한 번”으로 끝난다. 에이전트는 계획을 짜고, 도구를 쓰고, 결과를 보고 다시 계획을 고치는 과정을 반복한다.
비유하면 단일 AI는 천재 인턴 한 명이고, 에이전트는 팀장 밑에 여러 실무자가 돌아가는 팀이다. 팀장이 플랜을 짜고(Plan), 실무자에게 일을 시키고(Act), 결과를 보고(Observe) 필요하면 다시 지시한다(Reflect).
왜 지금 에이전트가 뜨고 있나
작년까지만 해도 단일 호출로 충분한 일이 많았다. 지금은 모델이 똑똑해지면서 한 번에 처리하기엔 벅찬 복합 작업이 늘어났다. 코드를 짜면서 테스트도 돌리고, 웹도 검색하고, 문서도 만드는 일은 단일 호출로는 품질이 안 나온다.
오케스트레이션(여러 AI 호출을 이어 붙이는 설계)을 붙이면 정확도가 올라간다. 대신 속도와 비용이라는 대가가 따른다.
에이전트는 내부에서 어떻게 도나
일반적인 에이전트 루프는 아래 모양이다.
# 간단한 에이전트 루프 예시
def run_agent(task, max_steps=10):
history = []
for step in range(max_steps):
# 1) 다음에 뭘 할지 계획
plan = llm.plan(task, history)
if plan.is_done:
return plan.answer
# 2) 도구 호출 (검색/코드실행/API)
result = tools.run(plan.action)
history.append((plan, result))
return "max steps 초과"핵심은 `max_steps`다. 이게 없으면 에이전트가 무한 루프에 빠지거나 비용이 폭주한다.
단일 호출, RAG, 에이전트 중 언제 뭘 쓰나
RAG(내 문서에서 답을 찾아 주는 방식, Retrieval Augmented Generation)까지 포함해 비교하면 선택이 쉬워진다.
| 구분 | 작동 방식 | 장점 | 단점 |
|---|---|---|---|
| 단일 호출 | 질문 하나에 답 하나 | 빠르고, 저렴 | 복합 작업에 약함 |
| RAG | 내 문서에 기반한 답 | 근거 있는 답 | 문서 외 답변에 제한 |
| 에이전트 | 여러 도구와 단계 | 복합 작업 가능 | 느림, 비쌈 |
입문자는 단일 호출부터 시작하는 게 맞다. 필요할 때만 RAG를 붙이고, 더 필요할 때 에이전트로 고려하는 순서가 좋다.
AI 에이전트를 도입할 때 빠지기 쉬운 함정
기술 먼저, 사용자 나중이 되는 실수
가장 큰 함정은 “에이전트 = 최신 기술 = 무조건 좋음”이라는 착각이다. 에이전트를 붙이면 응답이 10배 느려질 수 있고 비용도 그만큼 뛴다. 사용자가 5초 기다리면 이탈하는 서비스에 에이전트를 붙이면 오히려 독이다.
AI는 도구일 뿐이다. 사용자가 뭘 원하고 얼마나 기다려줄지를 먼저 정해야 한다.
지연 시간과 비용을 얕보는 실수
단일 호출 1초 × 10번이 10초가 되지 않는다. 각 단계마다 프롬프트가 누적되고 네트워크 왕복이 쌓여 실제로는 15~30초가 나오기 쉽다. 비용도 토큰이 매 단계 쌓여 10배 이상으로 뛰는 건 기본이다.
나의 에이전트 경험기
단일 호출만 쓰다가 벽에 부딪혔다
처음엔 큰 모델 한 번 호출로 다 해결됐다. “이게 AI지” 하고 자신감만 붙었다. 그러다 여러 소스에서 자료를 모아 보고서를 만드는 기능이 필요해졌다. 단일 호출로는 근거 링크가 엉망으로 섞이고 내용이 누락됐다.
에이전트 프로토타입이 30초를 찍었다
처음 만든 에이전트는 검색 → 요약 → 검증 → 재작성 루프를 돌렸다. 결과 품질은 좋았지만 한 번 돌리는 데 30초가 걸렸다. UX 회의에서 “이걸 누가 기다리냐”는 피드백을 들었다. 프로토타입을 접을 뻔했다.
루프 제한과 빠른 모델로 돌파했다
해결책은 두 개였다. 하나는 에이전트 루프의 `max_steps`를 10에서 4로 줄인 것이다. 정확도는 살짝 떨어졌지만 시간이 3분의 1로 줄었다. 다른 하나는 계획 단계에만 큰 모델을 쓰고 실행 단계는 더 빠른 경량 모델로 바꾼 것이다. 평균 응답이 10초 아래로 내려왔다.
마치며
에이전트는 복합 작업을 푸는 강력한 도구지만 레이턴시와 비용이라는 그림자가 크다. 단일 호출 → RAG → 에이전트 순으로 필요할 때만 꺼내 쓰는 게 안전하다.