최근 몇 달 동안 거의 모든 AI 관련 기술에 **에이전트 (agent)**라는 단어가 사용되기 시작했습니다.

질문에 답하는 챗봇.

텍스트를 요약하는 어시스턴트.

모델을 호출하는 자동화.

API와의 통합.

모든 것이 "에이전트"처럼 보입니다.

하지만 여기서 첫 번째 문제가 발생합니다. 모든 것을 에이전트라고 부른다면, 우리가 실제로 무엇을 구축하고 있는지 이해하는 것을 그만두게 됩니다.

그리고 그런 일이 발생하면, 잘못된 기술적 결정을 내리게 됩니다.

불필요한 곳에 복잡성을 추가합니다.

유지보수하기 어려운 흐름을 설계합니다.

AI에게 너무 많은 자유를 부여합니다.

그러고 나서 시스템이 예측 불가능해지면 놀라게 됩니다.

이 글의 목적은 이 주제를 정리하는 것입니다.

하이프 (hype) 관점이 아닙니다.

마법 같은 약속 관점도 아닙니다.

소프트웨어 설계 관점에서의 정리입니다.

챗봇은 응답한다

가장 단순한 형태의 챗봇은 사용자의 입력에 응답합니다.

흐름은 보통 다음과 같습니다:

사용자 질문
→ 모델 응답

이것은 매우 유용할 수 있습니다.

고객 서비스, 문서화, 내부 지원, 아이디어 생성, 요약 또는 애플리케이션 내의 도움을 위해 사용될 수 있습니다.

하지만 본질적으로 챗봇은 대개 **반응적 (reactive)**입니다.

질문을 기다립니다.

응답을 생성합니다.

그리고 거기서 끝납니다.

반드시 도구를 조회하는 것도 아닙니다.

반드시 상태 (state)를 유지하는 것도 아닙니다.

반드시 단계를 실행하는 것도 아닙니다.

반드시 다음에 무엇을 할지 결정하는 것도 아닙니다.

따라서 챗봇은 강력할 수 있지만, 그렇다고 해서 에이전트인 것은 아닙니다.

어시스턴트는 컨텍스트 내에서 도움을 준다

어시스턴트는 이미 조금 더 정교할 수 있습니다.

더 명확한 지침을 가질 수 있습니다.

사용자의 컨텍스트 (context)를 알 수 있습니다.

특정 역할에 따라 응답할 수 있습니다.

애플리케이션 내에서 도움을 줄 수 있습니다.

예를 들어:

당신은 기술 지원 어시스턴트입니다.
내부 문서만을 사용하여 응답하세요.
답을 모른다면 케이스를 이관하세요.

이것은 경험을 크게 개선합니다.

하지만 여전히 반드시 에이전트인 것은 아닙니다.

왜 그럴까요?

왜냐하면 여전히 답변하는 것에만 국한될 수 있기 때문입니다.

계획을 세우거나, 도구 (tools)를 선택하거나, 행동을 실행하거나, 다단계 작업 (multi-step task)을 수행하며 나아가는 능력이 없을 수도 있습니다.

어시스턴트 (assistant)는 도움을 줍니다.

하지만 항상 행동하는 것은 아닙니다.

AI 워크플로우 (workflow)가 항상 에이전트 (agent)인 것은 아니다

우리는 AI를 사용하는 워크플로우 (workflows)를 가질 수도 있습니다.

예를 들어:

티켓 수신
→ AI로 티켓 분류
→ 우선순위 할당
...

이 흐름은 AI를 사용합니다.

하지만 경로는 우리가 정의합니다.

시스템은 무엇을 할지 자유롭게 결정하지 않습니다.

미리 설정된 단계를 따릅니다.

이것은 매우 중요합니다.

워크플로우 (workflow)가 에이전트 (agent)보다 훨씬 더 편리할 수 있습니다.

실제로 많은 실제 솔루션들은 에이전트가 아닌 워크플로우로 시작해야 합니다.

워크플로우 (workflow)는 테스트하기가 더 간단하기 때문입니다.

관찰하기 더 쉽고.

유지보수하기 더 쉬우며.

설명하기 더 쉽고.

제어하기 더 쉽습니다.

Anthropic은 매우 유용한 구분을 제시합니다: **워크플로우 (workflows)**는 모델과 도구 (tools)가 미리 정의된 코드 경로를 통해 오케스트레이션 (orchestrated)되는 시스템인 반면, **에이전트 (agents)**는 작업을 해결하기 위해 프로세스와 도구 사용을 동적으로 지시할 수 있습니다.

출처: Building Effective Agents - Anthropic

그렇다면, 에이전트 (agent)란 무엇인가?

AI 에이전트 (AI agent)는 단순히 "답변하는 모델"이 아닙니다.

에이전트 (agent)는 모델이 작업 해결에 더 능동적으로 참여하는 시스템입니다.

이를 간단하게 보는 방법은 다음과 같습니다:

사용자가 목표 설정
→ 에이전트가 컨텍스트 (context) 분석
→ 도구 (tool) 사용 필요 여부 결정
...

OpenAI는 에이전트 (agents)를 계획을 세우고, 도구를 호출하며, 전문가들 사이에서 협업하고, 다단계 작업을 완료하기 위해 충분한 상태 (state)를 유지할 수 있는 애플리케이션으로 설명합니다.

출처: Agents - OpenAI API docs

차이점은 단지 모델에 있는 것이 아닙니다.

차이점은 모델을 둘러싼 시스템에 있습니다.

에이전트는 보통 여러 구성 요소를 결합합니다:

모델 (Model)
지침 (Instructions)
도구 (Tools)
...

모델은 그중 하나의 부분일 뿐입니다.

하지만 진정한 에이전트는 전체적인 설계 (Design)입니다.

핵심 키워드: 도구 (Tools)

단순한 챗봇과 에이전트 사이의 강력한 차이점은 도구의 사용입니다.

도구는 다음과 같을 수 있습니다:

데이터베이스 조회
API를 통한 정보 검색
파일 읽기
...

예를 들어, 고객 지원 시스템을 가정해 봅시다.

사용자가 다음과 같이 질문합니다:

내 주문은 어떻게 됐나요?

일반적인 챗봇은 다음과 같이 일반적인 답변을 할 수 있습니다:

'내 구매 내역' 섹션에서 주문 상태를 확인하실 수 있습니다.

반면, 에이전트는 다음과 같은 작업을 수행할 수 있습니다:

1. 고객 식별
2. 최근 주문 내역 검색
3. 주문 상태 조회
...

이 단계에서 우리는 더 이상 텍스트만을 이야기하는 것이 아닙니다.

우리는 시스템과의 통합 (Integration)을 이야기하고 있는 것입니다.

그리고 시스템 통합이 이루어질 때, 기술적 책임 (Technical responsibility)이 뒤따릅니다.

위험 요소: 과도한 자유 부여

에이전트는 "하고 싶은 대로 하는" AI가 되어서는 안 됩니다.

그것은 나쁜 아이디어입니다.

좋은 에이전트에게는 경계 (Limits)가 필요합니다.

무엇을 할 수 있고 무엇을 할 수 없는지 알아야 합니다.

잘 설계된 도구가 필요합니다.

권한 (Permissions)이 필요합니다.

검증 (Validations)이 필요합니다.

추적 가능성 (Traceability)이 필요합니다.

폴백 (Fallback)이 필요합니다.

어떤 경우에는 인간의 개입 (Human intervention)도 필요합니다.

왜냐하면 에이전트가 실제 행동을 실행할 수 있다면, 실제로 실수할 수도 있기 때문입니다.

잘못 조회할 수 있습니다.

잘못 해석할 수 있습니다.

잘못된 도구를 호출할 수 있습니다.

그럴듯하지만 틀린 답변을 생성할 수 있습니다.

해서는 안 될 행동을 취할 수 있습니다.

따라서 문제는 단지 다음과 같은 것이 아닙니다:

어떻게 하면 에이전트를 더 똑똑하게 만들 수 있을까?

올바른 질문은 다음과 같습니다:

어떻게 하면 AI가 통제력을 잃지 않으면서 가치를 더할 수 있는 시스템을 설계할 수 있을까?

제 생각에, 이것이 바로 중요한 대화입니다.

모든 것에 에이전트가 필요한 것은 아니다

이 문구는 모든 AI 프로젝트 상단에 적혀 있어야 합니다:

모든 것에 에이전트가 필요한 것은 아니다.

때로는 더 잘 설계된 프롬프트 (Prompt)만으로 충분할 때가 있습니다.

때로는 전통적인 함수 (Function)만으로 충분할 때가 있습니다.

때로는 워크플로 (Workflow)만으로 충분할 때가 있습니다.

때로는 RAG (검색 증강 생성)가 필요합니다.

때로는 단순한 자동화 (Automation)가 필요합니다.

그리고 그 이후에야, 어떤 경우에는 에이전트 (Agent)가 필요합니다.

실수는 문제를 이해하기 전에 기술부터 시작하는 것입니다.

소프트웨어 개발에서 모든 것을 마이크로서비스 (Microservices), 이벤트 (Events) 또는 복잡한 아키텍처 (Architecture)로 해결하려 할 때와 비슷한 일이 발생합니다.

도구 자체는 좋을 수 있습니다.

하지만 너무 이른 시점에 사용된다면, 그것은 문제가 됩니다.

에이전트도 마찬가지입니다.

언제 에이전트를 고려해야 하는가

저는 작업이 다음과 같은 조건 중 여러 가지를 충족할 때 에이전트를 고려하기 시작할 것입니다:

여러 단계가 필요함
도구 (Tools)를 조회해야 함
컨텍스트 (Context)에 의존함
...

예시:

지원 티켓 (Support Ticket)을 분석하고 답변 제안
고객 정보를 조회하고 상태 요약
최근 주문을 검토하고 문제 감지
...

그러한 경우에는 에이전트가 의미가 있을 수 있습니다.

하지만 그 경우에도, 저는 단순하게 시작할 것입니다.

먼저 도구 하나.

그다음 두 개.

그다음 검증 (Validation).

그다음 상태 (State).

그다음 관찰 가능성 (Observability).

그다음 자율성 (Autonomy).

그 반대로 해서는 안 됩니다.

.NET 개발자를 위한 간단한 예시

고객 시스템을 위한 지원 에이전트를 만들고 싶다고 가정해 봅시다.

도메인에는 다음이 포함됩니다:

Customers (고객)
Orders (주문)
SupportTickets (지원 티켓)

그리고 우리는 에이전트가 다음과 같은 질문에 답할 수 있기를 원합니다:

이 이메일을 사용하는 고객의 요약을 알려줘.
그의 최근 주문을 보여줘.
열려 있는 티켓이 있나?
...

설계할 때 잘못된 방식은 모든 것에 자유로운 접근 권한을 주는 것입니다.

더 나은 방식은 구체적인 도구들을 노출하는 것입니다:

FindCustomerByEmail
GetCustomerSummary
GetRecentOrders
...

각 도구 (Tool)는 다음과 같아야 합니다:

명확한 이름
잘 정의된 입력 (Input)
구조화된 출력 (Output)
...

이 경우 에이전트는 "마법"을 부리는 것이 아닙니다.

에이전트는 우리가 설계한 능력 위에서 작동합니다.

이것은 대화의 흐름을 완전히 바꿉니다.

에이전트가 멀티 에이전트를 의미하는 것은 아니다

또 다른 흔한 오류는 에이전트(agent)에 대해 이야기한다면, 첫날부터 멀티 에이전트(multi-agent)에 대해 이야기해야 한다고 생각하는 것입니다.

그럴 필요는 없습니다.

사실, 저는 거의 항상 그 부분부터 시작하지는 않을 것입니다.

먼저 단순한 에이전트(simple agent)를 제대로 설계할 수 있어야 합니다.

그 후에, 문제가 정말로 정당화한다면, 조정된(coordinated) 여러 에이전트를 고려할 수 있습니다.

예를 들어, OpenAI Agents SDK는 에이전트(agents), 도구(tools), 핸드오프(handoffs), 가드레일(guardrails)과 같은 개념으로 작동합니다. 이는 매우 강력하지만, 모든 시스템이 반드시 여러 에이전트로 시작해야 한다는 의미는 아닙니다.

출처: OpenAI Agents SDK

실무에서는 복잡성이 그 자리를 스스로 쟁취해야 합니다.

유행 때문에 추가되는 것이 아닙니다.

도구보다 기술적 기준이 더 중요하다

다양한 도구를 사용하여 에이전트를 구축할 수 있습니다:

Semantic Kernel
LangChain
LangGraph
...

하지만 도구가 기준(criterion)을 대체할 수는 없습니다.

예를 들어, LangGraph는 워크플로우(workflows)와 에이전트(agents)를 구분합니다. 워크플로우는 미리 정해진 경로를 가지는 반면, 에이전트는 더 동적이며 스스로의 프로세스와 도구 사용을 정의합니다.

출처: Workflows and agents - LangGraph docs

그것은 매우 좋습니다.

하지만 프레임워크(framework)를 선택하기 전에, 더 기본적인 질문들에 답해야 합니다:

어떤 문제를 해결하고 싶은가?
AI가 어떤 결정을 내릴 수 있는가?
어떤 도구가 필요한가?
...

이 질문들에 대한 답이 명확하지 않다면, 프레임워크가 당신을 구원해주지 못합니다.

나의 관점

저에게 유용한 에이전트란 가장 자율적으로 보이는 에이전트가 아닙니다.

필요한 최소한의 자율성 수준으로 구체적인 작업을 해결하는 에이전트입니다.

이것은 덜 매력적으로 들릴 수도 있습니다.

하지만 훨씬 더 현실적입니다.

통제 없는 자율성은 아키텍처(architecture)가 아닙니다.

그것은 리스크(risk)입니다.

좋은 에이전트는 모든 것을 할 필요가 없습니다.

허용된 일을 제대로 수행할 필요가 있을 뿐입니다.

마무리

모든 챗봇(chatbot)이 에이전트인 것은 아닙니다.

모든 어시스턴트(assistant)가 에이전트인 것도 아닙니다.

모든 AI 워크플로우(workflow)가 에이전트인 것도 아닙니다.

그리고 모든 문제에 에이전트가 필요한 것도 아닙니다.

구축하기 전에 개념을 정리하는 것이 좋습니다.

챗봇(chatbot), 어시스턴트(assistant), 워크플로우(workflow), 그리고 에이전트(agent) 사이의 차이점을 이해할 때 더 나은 설계를 할 수 있기 때문입니다.

도구를 더 잘 선택할 수 있습니다.

리스크(risk)를 더 잘 제어할 수 있습니다.

그리고 더 유용한 솔루션을 구축할 수 있습니다.

다음 전달 사항들에서는 이를 코드로 구현해 보겠습니다.

목표는 .NET 개발자들을 위한 AI 에이전트 실습 실험실(laboratory)을 구축하는 것입니다.

허세 없이.

설계(design)를 바탕으로.

도구(tools)를 갖추고.

제한 사항(limits)을 두며.

리포지토리(repos)와 함께.

그리고 실제적인 학습(learnings)과 함께 말이죠.

다음 전달 사항

멀티 에이전트(multi-agents)부터 시작하지 않고 .NET으로 첫 번째 AI 에이전트를 설계하는 방법

이 주제에 관심이 있다면, .NET, 도구(tools), 그리고 MCP를 사용하여 실습 예제를 구축하며 이 시리즈를 계속 이어가겠습니다.