AI 에이전트란 무엇일까?

에이전트가 뭐고 왜 등장했나

에이전트는 단일 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배 이상으로 뛰는 건 기본이다.

 

에이전트 도입 전 체크리스트

• 단일 호출이나 RAG로 정말 안 풀리는 문제인가
• 사용자가 기다려 줄 수 있는 응답 시간은 몇 초인가
• 월 호출량 × 평균 토큰 × 단가를 계산해봤는가
• 루프 최대 횟수와 타임아웃을 정의했는가
• 중간 상태를 로그로 남길 수 있는가

 

나는 에이전트에 이렇게 치였다

단일 호출만 쓰다가 벽에 부딪혔다

처음엔 큰 모델 한 번 호출로 다 해결됐다. "이게 AI지" 하고 자신감만 붙었다. 그러다 여러 소스에서 자료를 모아 보고서를 만드는 기능이 필요해졌다. 단일 호출로는 근거 링크가 엉망으로 섞이고 내용이 누락됐다.

 

에이전트 프로토타입이 너무 느렸다

처음 만든 에이전트는 요약 → 검증 → 재작성 루프를 돌렸다. 결과 품질은 좋았지만 한 번 돌리는 데 3분이 걸렸다. 회의에서 "이걸 누가 기다리냐"는 피드백을 들었다. 프로토타입을 접을 뻔했다.

 

루프 제한과 빠른 모델로 돌파했다

해결책은 두 개였다. 하나는 에이전트 루프의 `max_steps`를 10에서 4로 줄인 것이다. 정확도는 살짝 떨어졌지만 시간이 대폭 줄었다. 다른 하나는 계획 단계에만 큰 모델을 쓰고 실행 단계는 더 빠른 경량 모델로 바꾼 것이다. 평균 응답이 10초 아래로 내려왔다.

 

배운 점 한 줄

좋은 기술보다 쓸 만한 서비스가 먼저라는 걸 뼛속으로 배웠다.

 

마치며

에이전트는 복합 작업을 푸는 강력한 도구지만 레이턴시와 비용이라는 그림자가 크다. 단일 호출 → RAG → 에이전트 순으로 필요할 때 골라쓰는걸 추천한다.