📈 "에이전트"라는 말의 인플레이션

오늘날 LLM이 들어간 거의 모든 기능이 "에이전트"라 불린다. 그러나 이렇게 불리는 것의 상당수는, 잘 구조화된 단일 API 호출 한 번으로 동일한 결과를 낼 수 있는 것들이다. 어떤 기능에 LLM이 관여한다는 이유로 "에이전트"라는 범주가 대화에 끼어들고, 에이전트 프레임워크가 선택되고, 다단계 루프가 구축되고, 복잡도가 불어난 끝에, 6주 뒤 잘 구조화된 호출 한 번이면 똑같이 나왔을 출력을 내는 정교한 시스템이 만들어진다.

이 인플레이션의 비용은 단지 미관의 문제가 아니다. 불필요한 에이전트화는 지연(latency), 토큰 비용, 디버깅 부담, 그리고 뒤에서 다룰 고유한 실패 모드를 함께 들여온다. 따라서 "무엇이 에이전트인가"를 정확히 긋는 일은 이론적 정밀함이 아니라 실무적 절약의 문제다.

이 글은 개념 → 경계 → 원리 → 응용 → 심화의 순서로 그 경계를 따라간다.

📖 먼저 용어부터: 단일 호출, RAG, 에이전트

자주 혼용되는 세 가지를 먼저 분리한다.

단일 LLM 호출 (Single Call). 입력을 주면 출력이 나온다. 한 번으로 끝난다.

입력 → LLM → 출력

순수한 LLM은 프롬프트를 받아 텍스트를 생성할 뿐이며, 현재 컨텍스트를 넘어서는 기억도, 외부 도구를 호출할 수단도, 자율적으로 목표를 추적할 능력도 갖지 않는다. "이 문장을 요약하라", "이 리뷰의 감성을 분류하라" 같은 작업이 여기 속한다. 실무에서 다루는 대다수의 "AI 기능"은 사실 이 범주로 충분하다.

RAG (검색 증강 생성, Retrieval-Augmented Generation). LLM이 알지 못하는 정보를 미리 검색해 프롬프트에 주입한 뒤 답하게 하는 방식이다.

관련 문서 검색 → 프롬프트에 주입 → LLM → 출력

여기서 결정적인 점은, 검색이 LLM 호출에 선행하여 단 한 번 일어난다는 것이다. LLM은 주어진 자료를 근거로 답할 뿐, "더 찾아볼지"를 스스로 결정하지 않는다. 검색의 시점과 범위가 코드에 의해 고정된다. 따라서 RAG는 단일 호출의 확장이며, 아직 에이전트가 아니다.

에이전트 (Agent). 여기서부터 범주가 바뀐다. 가장 간결한 정의로, 에이전트는 도구를 루프 안에서 자율적으로 사용하는 LLM이다. 일반적인 LLM과 달리 에이전트는 중간 결과를 평가하고 자신의 오류로부터 동적으로 회복하며, 이 루프 안에서 작동해야 한다.

목표 → [ 생각 → 행동(도구) → 관찰 → 다시 생각 → ... ] → 결과

핵심은 두 가지, 루프와 자율성이다. LLM이 "지금 무엇이 필요한가"를 스스로 판단해 도구를 사용하고, 그 결과를 관찰한 뒤 다음 행동을 결정한다. 한 번 묻고 한 번 답하는 것이 아니라, 상황에 따라 스스로 경로를 구성한다.

세 범주의 비교