AI Agent 를 정확하게 정의하기

요즘 많은 매체 (기사, 유투브, 포스트) 에서 "AI Agent가 미래다" 라는 말을 많이 합니다. 대표적으로 Andrew Ng 선생님꼐서 1년 넘게 Agent에 대해 이야기 하고 계시죠. 그런데, "Agent" 라는 키워드에 대한 정의가 많이 다르고 본인들 유리할대로 사용하는 경우가 많더라고요. 올해 (24년) Agent를 직접 구현하여 시스템을 만드는 강의를 SK 개발자분들 대상으로 꽤 여러번 진행했는데, 그래도 직접 구현해본 사람으로서 많은 분들의 혼란을 줄여보고자 이 글을 작성합니다.

Agent 정의

AI 에이전트(Agent) 라는 단어만 들으면 어떻게 생각이 되시나요. 마치 무언가 알아서 척척 일을 해주는 AI 시스템인 것 처럼 보이죠.

ChatGPT 도 Agent 인가요? 많은 분들이 아니리고 할 것 같네요.  
Agent를 한 줄로 정의해보자면, 다음과 같습니다.

LLM(Large Language Model) 이 의사결정 로직을 담당하여 자율적 판단과 실행 능력을 갖추게 하는 시스템입니다.

조금 더 자세히 풀어서 써보자면,

단순히 모델을 호출해 응답을 생성하는 수준을 넘어, 에이전트는 주어진 문제를 해결하기 위해 상황을 분석하고 행동을 계획하며 (Planning) , 도구를 활용하여 (Tool Use) 복잡한 작업을 처리하는 시스템입니다. 예를 들어, 사용자가 질문을 하면 에이전트는 "웹 검색이 필요하다"거나 "코드 실행 후 결과를 검토해야 한다"는 판단을 내리고 이를 실행합니다.

위 정의에는 ChatGPT가 부합하죠. 저희가 질문을 하면 알아서 검색을 해주잖아요? LLM 이전 시대에는 의사결정 로직이 하드코드 대부분 하드 코드였습니다. if/else 분기로 이럴때는 검색을 하고, 어떨때는 하지 말고.

LLM 의 next token prediction 확률 모델이 if/else 역할을 하는 것입니다.

그래서 문제점은 Reliability 죠, 문제점은 일단 뒤로 미뤄두겠습니다. 사람도 실수 하니까요.

에이전트의 가장 큰 기대 효과는 스스로 계획하고 반복적으로 실행하며 최적의 결과를 도출한다는 점입니다. 이는 복잡한 요구 사항을 처리하거나 불확실성이 높은 상황에서 특히 유용합니다. 단순한 호출로 해결 가능한 작업은 기존의 방식으로 충분하지만, 복잡도가 높아질수록 에이전트의 유연성과 효과가 좋습니다.

LLM 이 이제 꽤 똑똑해 졌으니, 복잔한 것을 맡겨볼까? 이런 개념이죠.

문제는 정확하게 어디서부터 Agent! 이런 라인을 주기 어렵다는 것입니다. 자율성을 얼마나 줘야 Agent 일까요. chatgpt 처럼 search, dall-e, canvas, code interpreter, 과 같은 도구를 지니고 알아서 도구를 사용하면 Agent 라고 봐야할까요. 이 부분에서 모호함이 있는데, 많은 회사들이 Agent를 정의하는 선이 조금씩 다릅니다. 제가 생각하기에 Agent에 대해 가장 고민을 많이 해본 회사 중 두 곳, LangGraph와 Anthropic의 정의를 살펴 보겠습니다.

LangGraph 가 바라보는 Agentic System

LangGraph 는 LangChain 에서 만든 framework 입니다. 사실상 Agent를 빌드하기 위한 시스템이죠. 저도 LangGraph를 이용해서 AI Agent를 구현 했었고, 이를 강의하기도 했습니다. 앞으로도 당분간 계속 할 것 같고요.

LangGraph의 정의를 의역해서 보겠습니다.

Agent라는 명확한 물건은 없고, Agentic 한 시스템만 있다. 아래 요소들을 많이 갖출수록 더욱 Agentic 하다고 볼 수 있다.

Tool Calling

• LLM이 필요성을 판단해 웹 검색, 데이터베이스 쿼리, 외부 API 호출 등의 작업을 수행합니다. 이러한 작업은 시스템이 단순히 요청을 처리하는 데 그치지 않고, 사용자의 요구 사항을 이해하며 그에 맞는 도구를 활용한다는 점에서 차별화됩니다.

Memory

• 이전 대화 맥락과 작업 결과를 저장하고 이를 기반으로 차후 의사결정에 반영합니다. 에이전트는 이러한 메모리 기능을 통해 일관된 맥락을 유지하고, 복잡한 문제를 단계적으로 해결할 수 있습니다.

Planning

• 현재 상황을 평가하고 적절한 행동 계획을 세웁니다. 이는 에이전트가 단순히 응답을 생성하는 수준을 넘어, 현재 상태를 분석하고 최적의 결과를 도출하기 위한 전략을 수립한다는 점에서 중요한 역할을 합니다.

여기에 Human-in-the-loop, 인간의 개입 또는 상호작용 까지 더 추가하면 가장 설득력있는 Agentic 동작이라고 볼 수 있겠습니다.

LangGraph는 LLM Application을 구현하기 위한 프레임워크입니다.  컨셉이나 구현이 궁금하시다면, 보다 자세한 내용은 아래 링크를 참조하세요.

[1] LangGraph의 Agent 컨셉을 재해석한 문서

Anthropic이 바라보는 Agent

Anthropic도 본인들이 바라보는 Agent에 대해 좋을 글을 작성했습니다. 직접 AI Agent 시스템을 다양하게 구축하면서, 정의와 함께 구현 팁도 공유를 했으니 관심있으신 분들은 한번 보시면 좋겠습니다.

[2] Anthropic의 Agent 에 관한 포스트

Anthropic도 마찬가지고 아까 제가 한줄로 정의한 "LLM이 자율적으로 판단하는 것" 을 Agentic 시스템이라고 정의했습니다. 그리고 Agentic 시스템들을 아래와 같이 분류 했는데요, 그 중에서 "많은 자율성을 가진 구조" 만 Agent라고 칭하더군요.

Workflow

• 정해진 코드 흐름에 따라 작동하며, RAG(Retrieval-Augmented Generation) 또는 Prompt Chaining과 같은 기존 패턴이 포함됩니다. 이러한 방식은 비교적 간단한 작업에 적합하며, 시스템 설계 및 구현에서 예측 가능성을 제공합니다.

Agent

• 작업 도구와 순서를 스스로 결정하며, 작업 중 발생하는 피드백(에러, 사용자 입력 등)을 기반으로 동적으로 문제를 해결합니다. 이 접근법은 시스템이 사전에 정의되지 않은 다양한 상황에 적응하고, 새로운 문제를 해결할 수 있는 유연성을 부여합니다.

LangGraph와 Agentic 함을 정의하는 큰 방향은 비슷하고, 그 중에서 명확하게 Agent 인 것만 Agent 라고 따로 부릅니다. 아래와 같은 요소를 충족한 것들만요.

• Human - in - the - loop 으로 사람과 상호작용합니다.
• 환경을 들고 활용합니다. Computer Use 가 이 경우에 해당하겠죠.
• LLM 호출을 자체적으로 판단해서 많이 할 수도 있습니다.

Agentic 시스템을 구현하는데 있어서, Agent를 처음 부터 사용하는 것은 권장하지 않더군요. 간단한 구조로 해결이 안되는 경우에 점차적으로 비대해져 Agent를 사용할 수 밖에 없게 될 것이 큰 골자 입니다. 매우 동의하는 바 입니다.

[3] Anthropic의 Agent 컨셉을 재해석한 문서

Agent는 언제 사용해야하는가?

정의만 살펴보니 조금 탁상공론 같습니다, 실제 구현에 관점에서 한번 보겠습니다.

명확한 절차와 규칙이 있는 작업

• Workflow로 충분하며, 예측 가능하고 안정적인 결과를 도출할 수 있습니다. 예를 들어, 데이터베이스 검색이나 특정 조건에 따라 데이터를 필터링하는 작업은 워크플로우 기반으로도 쉽게 구현할 수 있습니다.

복잡한 의사결정과 높은 유연성이 요구되는 작업

• Agent가 필요합니다. 여러 도구를 활용하며 동적으로 문제를 해결해야 하는 상황에서 강점을 발휘합니다. 특히, 사용자의 요청이 다단계 작업을 필요로 하는 경우가 이에 해당하겠죠. 검색을 하고, 요약하고, 다시 필요한 정보를 추리고, 또 검색하고, 검증하고, ....

예를 들어, 단순한 질의응답 작업은 기존 LLM 호출이나 RAG로 충분합니다. 하지만 "현재 주가 데이터를 분석해 보고서를 작성하고, 필요한 경우 가설을 검증하거나 추가 정보를 검색하며, 중간 결과를 요약"하는 작업이라면 Agent가 필요하겠죠.

Anthropic 의 분류에 따라, workflow 와 Agent로 구분했습니다. 제 의견에는 보다 Agentic 한 방법들이 필요하다라고 표현하는게 더 맞을 것 같습니다.

실제로 Agent를 구현한다면?

1. LangChain → LangGraph

• LangChain은 초보자에게 적합한 프레임워크로, 간단한 PoC(Proof of Concept) 단계에서 유용합니다. 비교적 작은 규모의 프로젝트에 적합하며, 진입장벽이 낮기 때문에 LangChain 으로 구현하시는 것을 추천드립니다. 문제는 LangChain으로 Agentic 시스템의 모든 요소를 구현할 수는 없습니다. Tool use 나 메모리는 쉽게 구현가능하나, Human-in-the-loop 같은 기능은 제공하지 않거든요.
• LangGraph는  프로덕션 레벨에서의 요구사항을 대부분 충족하며, 중간개입과 모니터링, 디버깅 기능이 더 잘 되어있습니다. 당연히 그만큼 진입장벽이 있고요. 그래서 LangChain으로 부족하면 LangGraph로 보다 Agentic한 시스템을 구현하시는 것을 추천드립니다.

2. 직접 구현

• LangGraph로도 불충분한 경우가 분명히 있을 거에요. 지원안하는 도구를 연결하고 싶다거나, 우리만의 API 사용이 필요하다거나. 그러면 직접 LLM API 호출하면서 구현해야곘죠. 초기 진입 장벽은 제일 높지만 디버깅과 제어에서 더 큰 자유를 제공합니다.

아마도 많은 분들이 LangGraph 를 사용하시게 되거나, (혹은 제가 소개하지 않은 다른 framework를 사용하게 되시거나) 직접 구현하시게 될 것입니다. 경험상 노코드 툴이나 LangChain은 프로덕션 레벨의 구현엔 많이 부족하더라고요.

결론

그래서 Agent가 뭐냐?

LLM 이 자율성을 가지고 로직을 결정하면 Agentic 시스템이고요, 정확하게 Agent라고 지칭하기 위한 최소 자율성의 선은 사람마다, 회사마다 다릅니다. 어쩄든 그냥 LLM 호출을 여러번 한다고 Agent는 아닙니다.

요즘 많은 분들이 Agent 라는 용어를 남발하시는 것 같아요. 언제나 신기술이 나오고, 어렵고, consensus 가 형성되기 전에는 그렇죠. "AI" 도 그렇죠. 사실 딥러닝, 트랜스포머, LLM 이런거 아니아도 다 AI 니까요. 가끔 단순 앱을 AI 시스템이라고 과대 광고하시는 프로젝트들을 보면, 너무하다고 생각이 들 때가 있습니다. 요즘 Agent 도 그런 것 같아요.

Agent 에 대한 이해에 도움이 되셨으면 좋겠습니다.

Agent를 직접 구현하실 분들을 위해 첨언하자면,

궁극적으로 중요한 것은 에이전트의 자율성을 어떻게 설계하고 엔지니어가 이를 어떤 방식으로 제어할 것인가입니다. 복잡한 요구를 처리하는 시스템을 설계할 때, 얼마나 자율성을 부여하는 것이 보다 똑똑하고, reliable 할지지 고민하셔야 합니다. Agent라고 불리기 위해 억지로 자율성을 더 부여하는 것은 본질에 벗어난다고 생각합니다. 결국 AI고 Agent고 모두 문제를 해결하기 위한 수단이니까요.

LangGraph와 Anthropic 모두, 에이전트 설계 시 불필요한 복잡성을 피하고 필요한 경우에만 점진적으로 Agentic 하게 구성할 것을 권장합니다.

마지막으로,

o1, o3 가 나오는 것을 보면서 느끼시겠지만, 로직을 판단하는 LLM 을 점점 더 똑똑해지고, 점점 더 reliable 해지고, 또 더 저렴해 질 것입니다. 그러니 Agentic 시스템을 설계 꼭 미리 하시고, 모델만 바꿔끼면 되도록 준비해두시면 분명 빛을 발할 순간이 곧 올 겁니다.