AI 에이전트 유형별 특징과 차이점 완벽 정리

AI 에이전트의 유형

AI 에이전트의 유형은 단순 반사(simple reflex), 모델 기반 반사(model-based reflex), 목표 기반(goal-based), 효용 기반(utility-based), 학습(learning) 에이전트라는 하나의 분류 체계에서 비롯됩니다. 각 명칭은 에이전트가 얼마나 많은 정보를 기억하는지, 그리고 행동하기 전에 얼마나 앞을 내다보고 계획하는지를 설명합니다. 멀티 에이전트(multi-agent)와 계층적(hierarchical)이라는 두 가지 용어는 개별 에이전트의 의사결정 방식이 아니라, 여러 에이전트가 어떻게 상호 연결되는지를 나타냅니다.

이 목록은 사용자가 경험한 모든 모델보다 오래되었습니다. 이는 표준 AI 교과서에서 유래했으며, 대규모 언어 모델(LLM)의 등장 이후에도 여전히 설계의 핵심 기준이 되는 질문을 던지기 때문에 살아남았습니다. 그 질문은 바로 "이 에이전트가 행동하기 전에 무엇을 알아야 하는가?"입니다. 에이전트와 챗 어시스턴트의 경계가 어디인지 고민 중이라면, 먼저 AI 에이전트와 기반 LLM의 차이를 읽어보시기 바랍니다. 이 페이지는 그 내용을 전제로 시작합니다.

단순 반사 에이전트: 하나의 조건, 하나의 동작

단순 반사 에이전트는 현재 입력을 동작에 매핑하며 이전 상태에 대한 기억을 전혀 유지하지 않습니다. 온도가 25를 초과하면 팬을 켭니다. 이것이 메커니즘의 전부입니다.

여러분은 이미 이런 에이전트를 실행해 본 적이 있을 것입니다. 폼 제출 내용을 읽어 데이터베이스에 행을 추가하는 n8n 워크플로를 실행하는 웹훅은 단순 반사 에이전트입니다. 중간에 언어 모델이 개입하여 해당 행의 카테고리를 분류하더라도 여전히 단순 반사 에이전트입니다. 한 시간 전에 무엇을 했는지 물어봐도 답을 유지하는 곳이 없기 때문에 대답할 수 없습니다.

이 유형은 사람들이 예상하는 것보다 더 자주 올바르게 작동합니다. 실행 비용이 저렴하며, 실패 원인도 명확합니다. 조건이 일치했거나, 그렇지 않았거나 둘 중 하나입니다. 작업이 "X가 도착하면 Y를 수행하라"는 것뿐이라면, 메모리를 추가하는 것은 오류 가능성만 높일 뿐 아무런 이득이 없습니다. 웹훅으로 트리거되는 n8n 에이전트는 사용자 인터페이스가 결합된 이 분류 체계의 한 예시입니다.

올바른 동작이 과거 이력에 의존하는 순간 이 방식은 실패합니다. 스레드 상태가 없는 답장 봇은 세 번째 메시지에서 스스로 모순된 답변을 내놓습니다. 처음 두 개의 메시지가 입력값의 일부로 포함되지 않았기 때문입니다.

모델 기반 반사 에이전트: 이벤트 간 상태 유지

모델 기반 반사 에이전트는 환경에 대한 내부 상태를 유지하며, 새로운 입력이 들어올 때마다 해당 상태를 갱신합니다. 여기서 '모델'이라는 단어는 신경망이 아닌 세계에 대한 모형을 의미합니다. 이 용어는 현재의 의미보다 약 40년 앞서 사용되었기에, 처음 접하는 거의 모든 사람에게 혼란을 줍니다.

20분 동안 움직임이 없으면 조명을 끄는 홈 자동화 규칙은 모델 기반입니다. 반드시 그래야만 합니다. 단순 반사 에이전트에게 "지금 움직임 없음"과 "21:40 이후 움직임 없음"은 동일한 입력이므로, 저장된 상태만이 이 둘을 구분할 수 있게 합니다.

LLM 버전은 배후에 메모리 저장소를 갖춘 모든 에이전트를 의미합니다. 예를 들어, 지속적으로 업데이트되는 대화 요약이나 에이전트가 매 실행 시작 시 읽어 들이는 일반 마크다운 파일이 이에 해당합니다. 에이전트를 위한 로컬 메모리 서비스는 이러한 개념을 패키지화한 것입니다. 작동 원리는 변하지 않습니다. 에이전트가 가진 세계에 대한 인식은 그 인식을 생성한 이벤트보다 더 오래 지속됩니다.

상태 유지에는 대가가 따릅니다. 오래된 정보는 정보가 없는 것보다 더 위험합니다. 에이전트가 그 정보를 완전히 신뢰하여 아무런 경고 없이 행동하기 때문입니다. 저장하는 모든 데이터에는 만료 기한을 설정하거나 재확인할 수 있는 방법이 필요합니다. 그렇지 않으면 에이전트는 3월에 폐기한 서버에 대해 계속해서 추론을 시도할 것입니다.

목표 기반 에이전트: 검증 가능한 상태를 향한 계획 수립

목표 기반 에이전트는 목표 상태를 전달받아 해당 상태에 도달하기 위한 일련의 동작을 탐색합니다. 에이전트는 도달해야 할 지점으로부터 역방향으로 추론하므로, 경로가 사전에 미리 작성되어 있지 않습니다.

코딩 에이전트는 직접 실행해 볼 수 있는 가장 명확한 예시입니다. "실패하는 테스트를 통과하게 하라"는 지시에는 파일명이나 구체적인 단계가 명시되어 있지 않습니다. 에이전트는 테스트를 읽고, 계획을 세우고, 코드를 수정하고, 테스트를 실행하고, 오류를 확인한 뒤 다시 시도합니다. 이 루프는 에이전트가 실제로 실행할 수 있는 검증 단계에서 종료됩니다. 이것이 바로 해당 지시는 작동하지만 "이 코드를 개선하라"는 지시는 작동하지 않는 이유입니다. 에이전트가 평가할 수 있는 목표는 에이전트가 도달할 수 있는 목표입니다. 에이전트가 평가할 수 없는 목표는 비용이 청구되는 무한 루프가 됩니다. 자신의 VPS에서 코딩 에이전트 실행하기를 활용하면 노트북 자원을 점유하지 않고도 해당 루프를 안전하게 구동할 수 있습니다.

비용은 이 과정에서 발생합니다. 계획 수립의 각 단계는 지금까지의 기록을 포함한 모델 호출을 반복하므로, 10단계 작업의 비용은 1단계 작업의 10배를 넘어섭니다. 중요한 엔지니어링은 루프의 형태와 루프를 종료하는 조건이며, 이는 루프 엔지니어링에서 다룹니다.

유틸리티 기반 에이전트: 여러 좋은 답변 사이에서의 선택

목표는 이진법적입니다. 유틸리티는 점수입니다. 유틸리티 기반 에이전트는 여러 수용 가능한 결과에 직면하며, 작성자가 정의한 함수에 따라 가장 높은 점수를 받는 결과를 선택합니다.

업무 시간이 시작되기 전에 업링크를 포화시키지 않으면서 완료해야 하는 백업 작업은 유틸리티 문제입니다. 여기에는 단 하나의 정답이 없으며, 오직 트레이드오프만 존재합니다. 가격과 답변 품질을 비교하여 어떤 모델이 어떤 요청을 처리할지 결정하는 라우터도 같은 형태를 띱니다.

어려운 것은 알고리즘이 아닙니다. 정직한 유틸리티 함수를 작성하는 것이 어렵습니다. 비용으로만 점수를 매기면 모든 요청에 대해 가장 저렴한 모델을 선택하게 되며, 여기에는 비싼 모델이 필요했던 요청까지 포함됩니다. 시스템은 정확히 측정된 항목을 최적화하는데, 측정하기 쉽다는 이유로 선택한 항목을 측정할 때 문제가 발생합니다.

학습 에이전트: 대부분이 이미 갖추고 있다고 가정하는 유형

학습 에이전트는 과거 결과에 대한 피드백을 바탕으로 자신의 행동을 변경합니다. 이를 위해서는 결과를 평가하는 요소와 그에 대응하여 정책을 수정하는 요소가 필요합니다.

자체 호스팅 시스템 중 이 조건을 충족하는 경우는 거의 없습니다. 지난주에 작성한 메모를 읽는 에이전트는 메모리 파일이 있는 모델 기반 에이전트일 뿐입니다. 가중치는 동일하며 정책 또한 동일합니다. 정보 검색은 학습이 아니며, 이 구분은 실무적으로 중요합니다. 메모리 기반 시스템은 메모리를 수정하지 않는 한 실수를 영원히 반복하지만, 학습 시스템은 실수를 멈추도록 설계되어야 하기 때문입니다.

학습 기능을 구현하려면 먼저 평가 체계를 구축해야 합니다. 점수가 매겨진 테스트 세트, 변경 사항을 적용한 실행 결과, 그리고 해당 변경 사항을 유지하거나 폐기할지 결정하는 과정은 하나의 폐쇄 루프이며, 여기서 학습 구성 요소는 바로 사용자 자신입니다. 이는 생각보다 느린 작업이지만, 현재 자체 호스팅 환경에서 작동하는 유일한 방식입니다. 평가 하네스 자체 호스팅이 바로 그 시작점입니다.

멀티 에이전트 및 계층형 시스템: 유형이 아닌 구성 방식

이들은 여섯 번째나 일곱 번째 유형이 아닙니다. 에이전트가 어떻게 구성되는지를 설명합니다.

멀티 에이전트 시스템은 큐나 git 저장소와 같은 공유 환경 내에서 여러 에이전트를 동시에 실행합니다. 환경이 공유되므로 에이전트 간 충돌이 발생합니다. 두 에이전트가 하나의 파일을 수정하는 것이 전형적인 실패 사례이며, 이를 해결하려면 잠금(lock)이나 작업 큐(work queue)가 필요합니다. 프롬프트만으로는 해결할 수 없습니다.

계층형 시스템은 작업자 위에 관리자를 배치합니다. 관리자는 작업을 분할하여 각 부분에 할당하고, 돌아온 결과물을 병합합니다. 이 방식은 사람이 업무를 분담하는 방식과 유사하여 널리 쓰이지만, 관리자가 읽는 보고서가 늘어날수록 관리자의 컨텍스트가 커지기 때문에 비용이 많이 듭니다. 멀티 에이전트 하네스에서 실제 구현 방식을 확인할 수 있습니다.

제대로 작동하는 에이전트 하나가 어설프게 작동하는 에이전트 넷보다 낫습니다.

업무를 넘겨줄 때마다 정보가 누락될 가능성이 생깁니다. 하나의 루프로 시작하십시오. 병목 현상이 발생하는 단계를 명확히 정의할 수 있을 때만 분할하십시오.

왜 거의 모든 실제 시스템이 하이브리드 형태인가

직접 운영하는 배포 에이전트를 예로 들어 보겠습니다. 웹훅(webhook)이 에이전트를 시작시키는데, 이는 반사적(reflex) 동작입니다. 에이전트는 현재 릴리스 상태를 읽어 들이는데, 이는 모델 기반(model-based) 동작입니다. 실행 중인 버전에서 목표 버전으로 가는 단계를 계획하는데, 이는 목표 기반(goal-based) 동작입니다. 현재 부하를 바탕으로 롤아웃 윈도우를 선택하는데, 이는 유틸리티 기반(utility-based) 동작입니다. 에이전트는 자신의 정책을 스스로 수정하지 않으므로 학습(learning)하는 시스템은 아닙니다.

하나의 시스템이 동시에 분류 체계의 네 가지 범주를 모두 포함합니다. 이 분류 체계는 완성된 제품에 붙이는 이름표가 아니라, 설계 체크리스트로서의 가치를 지닙니다. 시스템이 오작동할 때 유용한 질문은 어느 계층이 잘못되었는가입니다. 잘못된 이벤트에서 발생한 트리거, 최신 상태를 잃어버린 상태, 절대 통과할 수 없는 목표 검사, 잘못된 결과를 보상하는 점수 산정은 각각 다른 해결책이 필요한 네 가지 서로 다른 버그입니다.

작업 유형별 적합한 방식

• 고정된 트리거와 고정된 응답이 필요하며 이력이 필요 없는 경우: 단순 반사(simple reflex).
• 올바른 응답이 이전 상황에 따라 달라지는 경우: 모델 기반 반사(model-based reflex).
• 최종 상태는 확인할 수 있으나 경로를 미리 알 수 없는 경우: 목표 기반(goal-based).
• 여러 허용 가능한 결과가 존재하며 그 사이에서 실질적인 상충 관계(trade-off)가 발생하는 경우: 효용 기반(utility-based).
• 시간이 지남에 따라 결과가 개선되어야 하는 경우: 평가 루프(eval loop)를 구축하고, 본인이 학습 구성 요소임을 수용하십시오.

이 에이전트들을 직접 호스팅할 수 있습니까? 비용은 얼마나 듭니까?

네, 가능합니다. 비용은 두 가지로 나뉩니다. 오케스트레이션 비용은 저렴합니다. n8n 인스턴스나 Python 에이전트 루프는 대부분의 시간을 네트워크 호출을 기다리는 데 사용하므로 2 vCPU와 4 GB RAM이면 충분합니다. 비용이 발생하는 지점은 모델입니다.

에이전트가 호스팅된 API를 호출하는 경우 서버 사양은 거의 필요하지 않으며, 비용은 토큰 사용량에 따라 결정됩니다. 목표 지향형 에이전트의 경우 허용하는 계획 단계의 수에 따라 비용이 확장되므로 루프 횟수를 제한하십시오.

자체 하드웨어에서 모델을 실행한다면 RAM 용량이 실행 가능 여부를 결정합니다. 아래 수치는 2026년 8월 기준 4-bit 양자화 가중치에 대한 일반적인 게시 파일 크기이며, 컨텍스트 윈도우와 런타임이 가중치 외에 추가 공간을 필요로 하므로 총 RAM 필요량을 함께 기재했습니다.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

4-bit 양자화된 8B 모델의 가중치 크기는 약 4.9 GB이며, 10 GB RAM을 갖춘 장비에서 스와핑 없이 실행됩니다. 동일한 양자화 수준의 70B 모델은 가중치 크기가 43 GB이며 약 64 GB의 RAM이 필요합니다. 이 수치에서 간과된 점은 속도입니다. GPU가 없는 VPS에서 4-bit 8B 모델은 초당 한 자릿수의 토큰을 생성합니다. 이는 야간에 큐를 처리하는 에이전트에게는 적합하지만, 사람이 기다려야 하는 작업에는 매우 느립니다. 로컬 추론은 배치 작업용으로 유지하고, 대화형 작업에는 GPU나 API를 사용하십시오. 직접 호스팅 가능한 AI 에이전트 목록에서 디스크 공간을 할애할 가치가 있는 프로젝트를 확인할 수 있으며, 2026년 에이전트 학습 경로에서 학습 순서를 확인할 수 있습니다.

분류 체계가 도움이 되지 않는 지점

이 분류 체계는 도구나 권한에 대해 아무것도 설명하지 않습니다. 교과서적인 에이전트는 인식하고 행동할 뿐입니다. 해당 장을 집필한 누구도 에이전트가 운영 환경의 API 토큰을 보유하는 상황을 우려하지 않았습니다. 셸 접근 권한을 가진 목표 지향적 에이전트와 읽기 전용 데이터베이스 연결 하나만 가진 에이전트는 표의 같은 행에 위치하지만, 그 위험성은 완전히 다릅니다. 에이전트의 지능 수준을 결정하기 전에 에이전트가 무엇을 건드릴 수 있는지 먼저 결정하십시오. 그리고 자격 증명을 부여하기 전에 AI 에이전트에서 비밀 정보를 보호하는 방법을 읽어보시기 바랍니다.

또한 이 체계는 단계가 실패할 때 어떤 일이 발생하는지에 대해서도 언급하지 않습니다. 실제 에이전트는 런타임의 대부분을 오류 처리, 즉 속도 제한이나 모델이 예상하지 못한 값을 반환하는 도구에 대응하는 데 사용합니다. 시스템의 사용 가능 여부를 결정하는 것은 바로 그 코드이며, 분류 체계의 어떤 행도 이를 설명하지 않습니다.

FAQ

AI 에이전트의 5가지 유형은 무엇입니까?

단순 반사형(simple reflex), 모델 기반 반사형(model-based reflex), 목표 기반(goal-based), 효용 기반(utility-based), 그리고 학습(learning) 에이전트입니다. 이들은 에이전트가 행동하기 전 알고 있는 정보의 양에 따라 분류됩니다. 단순 반사형 에이전트는 현재 입력값만 확인합니다. 모델 기반 에이전트는 환경에 대한 상태를 유지합니다. 목표 기반 에이전트는 목표 상태를 향해 계획을 세웁니다. 효용 기반 에이전트는 여러 허용 가능한 결과의 점수를 매겨 가장 높은 것을 선택합니다. 학습 에이전트는 피드백을 통해 자신의 정책을 변경하는데, 직접 호스팅하는 환경에서 이를 구현하는 경우는 거의 없습니다.

단순 자동화를 위해 어떤 유형의 AI 에이전트를 사용해야 합니까?

단순 반사형 에이전트를 사용하십시오. 실무적으로는 고정된 순서를 실행하는 webhook이나 스케줄러를 의미합니다. 올바른 응답이 방금 들어온 입력값에만 의존한다면, 메모리를 추가하는 것은 기능 향상 없이 실패 가능성만 높일 뿐입니다. 이전에 발생한 일을 알아야 하는 의사결정이 하나라도 생기는 시점에 모델 기반 설계로 전환하십시오.

VPS에서 직접 AI 에이전트를 실행할 수 있습니까?

네, 가능합니다. 오케스트레이션 계층은 가볍기 때문에 2 vCPU와 4 GB RAM만으로도 워크플로우 엔진이나 에이전트 루프를 충분히 실행할 수 있습니다. 핵심은 모델을 어디서 실행할지 결정하는 것입니다. 호스팅된 API를 사용하면 서버 사양을 낮게 유지할 수 있고 비용은 토큰 단위로 발생합니다. 로컬 모델은 파라미터 수에 비례하는 RAM이 필요하며, GPU가 없으면 초당 한 자릿수의 토큰만 생성하므로 채팅보다는 대기열 기반의 배치 작업에 적합합니다.

거대 언어 모델(LLM) 자체가 AI 에이전트입니까?

아닙니다. 모델은 입력 텍스트를 출력 텍스트로 매핑한 뒤 종료됩니다. 모델이 에이전트가 되려면 외부 세계에 작용하고 그 결과를 다시 입력으로 피드백하는 루프가 필요합니다. 이를 위해서는 모델이 호출할 수 있는 도구와 루프를 언제 멈출지 결정하는 조건이 있어야 합니다. 에이전트는 이 래퍼(wrapper)이며, 모델은 그 내부의 구성 요소 중 하나일 뿐입니다.

멀티 에이전트 시스템이 필요합니까?

보통은 필요하지 않습니다. 여러 도구를 갖춘 단일 루프가 대부분의 작업을 처리하며 디버깅도 훨씬 쉽습니다. 작업의 일부가 완전히 독립적이어서 동시에 실행될 수 있거나, 특정 부분에 다른 모델이 필요한 경우에만 여러 에이전트가 도움이 됩니다. 멀티 에이전트의 비용은 조정 과정에서 발생합니다. 상태 공유가 필요하고, 작업자의 보고를 읽을 때마다 컨텍스트가 늘어나는 관리자가 필요하기 때문입니다. 작업 단계 중 속도가 느린 지점을 명확히 짚어낼 수 있을 때 두 번째 에이전트를 추가하십시오.