AI 기술은 지난 몇 년간 눈부신 속도로 진화하고 있습니다. 특히 새롭게 등장한 LLM은 기존의 단순한 규칙 기반 챗봇이나 자동 응답 시스템과는 차원이 다른 수준의 자연어 이해 및 생성 능력을 보여주며 AI가 실무와 일상에서 실질적인 가치를 만들어낼 수 있다는 가능성을 현실화했습니다.

1단계: LLM의 등장

초기에는 GPT-3와 같은 초거대 언어모델이 등장하며 사람과 자연스럽게 대화를 나누고 문장을 생성하고 요약하는 등 다양한 작업을 수행할 수 있게 되었습니다. 하지만 초기 모델들은 인터넷 검색과 개인 데이터 접근이 불가능하여 사실 기반의 응답이 어려웠습니다.

📝 예시: “우리 엄마 이름이 뭐야?”, “오늘 날씨 어때?”와 같은 질문에 제대로 대응하지 못함

2단계: RAG의 도입

이러한 한계를 극복하기 위해 등장한 기술이 바로 RAG(Retrieval-Augmented Generation)입니다. RAG는 외부 문서나 사내 데이터베이스에서 정보를 검색한 후 해당 내용을 바탕으로 LLM이 응답을 생성하는 방식입니다.

📝 예시: LangChain 기반의 RAG 서비스를 구축하여 관련 정보를 전달함으로써 답변 유도

하지만 여전히 모델은 구축한 데이터에 대해서만 동작할 뿐 복잡한 작업을 스스로 설계하거나 다단계로 수행하지는 못했습니다.

3단계: Function Calling과 Tool 사용

사용자 질문에 따라 단순히 텍스트를 생성하는 것을 넘어 외부 기능을 직접 호출할 수 있게 되면서 LLM의 활용 범위가 넓어졌습니다. 이때 등장한 기술이 Function Calling, OpenAI tools, 그리고 MCP(Model Context Protocol)와 같은 프로토콜입니다. (관련 내용은 이전 블로그에 정리해 놓았습니다.)

📝 예시: 사용자가 “오늘 파리로 소풍가려고 하는데 괜찮을까?”라고 물으면, get_weather("Paris")를 호출하고 응답값을 기반으로 설명

4단계: Agentic AI의 등장

Agentic AI는 목표만 주어지면 이를 달성하기 위해 필요한 도구를 스스로 선택하고, 상태를 추론하며, 워크플로우를 동적으로 생성하고 실행합니다. 이는 단순한 기술 발전을 넘어 AI의 활용 방식 자체를 근본적으로 바꾸고 있습니다. Agentic AI가 기존 기술에 비해 어떠한 장점이 있고 어떻게 활용될 수 있는지 제가 경험한 내용을 바탕으로 설명드리려고 합니다.

Agentic AI는 GPT, Gemini, Claude 등 기존의 대형 언어 모델(LLM)을 기반으로 이 모델이 마치 에이전트(Agent)처럼 스스로 목적을 인식하고 도구를 선택하며 실행하고 결과를 해석해 다음 행동을 결정할 수 있도록 구성하는 방법론이자 아키텍처적 접근 방식입니다. 즉, 새로운 AI 모델을 만든 것이 아니라 기존 AI를 더 자율적이고 능동적인 시스템으로 확장한 개념입니다.

앞서 말했듯이 Agentic AI는 AI가 스스로 목적을 이해하고 계획을 수립하며 필요한 도구를 선택해 실행하는 자율적인 문제 해결 방식입니다. 하지만 Agentic AI가 등장하기 전에도 LLM을 일정한 흐름(Workflow) 속에서 유용하게 활용하기 위한 다양한 시도가 있었습니다.

그 중심에 있었던 것이 바로 LangChain과 LangGraph입니다. LangChain은 LLM을 중심으로 다양한 기능(예: 검색, 요약, 계산 등)을 체인 형태로 연결할 수 있도록 도와주는 프레임워크입니다. 반면, LangGraph는 이보다 더 확장된 구조로, 각 단계를 상태 노드로 정의하고 조건에 따라 분기하거나 반복되는 흐름을 그래프 구조로 모델링할 수 있도록 설계되었습니다.

예를 들어, 다음과 같은 멀티 소스 기반 정보 조회 워크플로우 상황을 생각해볼 수 있습니다(LangGraph 예시).

● Knox Team 메시지 데이터: A Vector DB에 저장

● KakaoTalk 데이터: B Vector DB에 저장

이때 사용자가 “우리 엄마 이름이 뭐야?”라고 질문하면 시스템은 다음과 같은 순서로 동작할 수 있습니다.

1. 먼저 A Vector DB에서 관련 정보를 검색(Retrieve)합니다.

2. 만약 관련된 문서가 존재하면 → 해당 내용을 LLM에 전달하여 응답을 생성합니다.

3. A에 관련 데이터가 없다면 → 다시 B Vector DB에서 Retrieve를 수행하고 결과를 바탕으로 LLM이 답변을 생성합니다.

이처럼 조건에 따라 경로를 분기하거나 여러 데이터 소스를 순차적으로 탐색해야 하는 구조는 LangChain의 체인 구성 또는 LangGraph의 상태 기반 분기 구성을 통해 간단하고 효율적으로 구현할 수 있습니다.

LangChain과 LangGraph는 LLM 기반 시스템을 구성하는 데 매우 강력한 도구였지만 한 가지 공통적인 한계가 있었습니다. 바로 다음과 같은 워크플로우의 흐름을 사람이 직접 설계해야 한다는 점입니다.

● 어떤 순서로 작업을 수행할지

● 어떤 조건에서 어떤 도구를 호출할지

● 실패/오류 시 어떤 분기로 갈지

이 모든 결정은 개발자 또는 설계자가 사전에 정의해야 했고, 예상치 못한 상황이 발생하면 흐름을 유연하게 바꾸기가 힘들었습니다.

같은 상황을 Agentic AI는 다르게 접근합니다.

앞서 언급한 “우리 엄마 이름이 뭐야?”라는 동일한 질문에 대해 Agentic AI는 다음과 같은 방식으로 스스로 판단하고 문제를 해결합니다.

1. 사용자의 질문을 분석하여 답변 가능 여부 판단

2. 응답 내용이 정확하지 않거나 근거가 부족하다고 판단되면 → 사용 가능한 함수 호출

a. get_from_a(“우리 엄마”), get_from_b(“우리 엄마”)

3. 신뢰도가 낮거나 불확실하다고 판단되면 → 쿼리를 추론 기반으로 재구성해 함수 호출

a. get_from_a(“mom”), get_from_a(“어머니”)....

4. 추출된 정보를 바탕으로 최종 응답 생성

이 과정에서 중요한 점은 모든 판단과 재시도, 함수 선택이 사람이 설계한 조건문 없이 AI 내부의 추론에 따라 수행된다는 것입니다. 즉, 사람이 흐름을 짜주는 것이 아니라 AI가 주어진 목표를 기반으로 최적의 실행 경로를 탐색하고 결정하는 구조입니다.

제가 실제로 운영 중인 서비스에 Agentic AI를 도입하면서 경험한 변화를 소개하고자 합니다. Agentic AI가 어떤 방식으로 워크플로우를 대체했고 어떤 실질적인 이점을 얻을 수 있었는지 구체적인 사례를 통해 살펴보겠습니다.

저희 Cloud Infra 개발 그룹에서는 SPC(Samsung Private Cloud)라는 클라우드 서비스를 개발 및 운영하며 AWS와 호환되는 EC2, VPC, S3 등의 서비스를 제공하고 있습니다. 여기서 저는 대규모 데이터를 쿼리로 분석할 수 있는 Baikal의 개발을 담당하고 있습니다.

Baikal은 AWS Athena처럼 동작하며, 다양한 팀에서 Baikal을 활용해 데이터 조회 및 분석 업무를 수행하고 있습니다. 하지만 문제는 모든 사용자가 SQL에 익숙한 것은 아니라는 점이었습니다. 특히 비개발자나 데이터 분석 경험이 부족한 개발자는 SQL 작성에 많은 어려움을 겪었고 이로 인해 데이터를 적극적으로 활용하지 못하는 문제가 있었습니다.

저는 이러한 문제점을 인식하여 자연어를 SQL로 변환하는 NL2SQL(Natural Language to SQL) 서비스를 만들었고, 이후 Agentic AI를 접목해 자동화 수준과 정확성을 높일 수 있었습니다.

Thinking Agent

● 사용자의 입력이 SQL인지 자연어인지 판단

● 입력 유형에 따라 SQL Agent 또는 NL Agent로 요청 라우팅

SQL Agent

● SQL 쿼리 처리

● 쿼리를 임베딩 후 벡터 DB에 저장하여 유사 쿼리 검색 기반 마련

NL(Natural Language) Agent

● 자연어 쿼리를 SQL로 변환

● 실제 테이블 스키마 조회, 벡터 DB에서 유사 쿼리 검색

● 관련 정보를 기반으로 SQL 생성

Validation Agent

● 생성된 SQL이 정상적으로 실행 가능한지 검증

● 오류 발생 시 NL Agent로 다시 전달하여 쿼리 재생성 유도

Agentic AI 도입의 주요 이점

Agentic 구조를 도입함으로써 기존 방식에 비해 다음과 같은 실질적인 개선 효과를 얻을 수 있었습니다.

1. 워크플로우의 유연성 향상

기존에는 모든 조건과 흐름을 개발자가 명시적으로 설계해야 했습니다. 그런데 Agentic AI의 도입으로 AI가 상황에 맞춰 필요한 작업 흐름을 스스로 생성하고 조정할 수 있게 됨에 따라 더 이상 모든 예외 상황을 코드로 처리하거나 사전에 모든 조건을 예측할 필요가 없어졌습니다.

2. 에이전트별로 최적화된 모델 설정 가능

에이전트마다 역할이 다르므로 각각의 목적에 맞는 LLM을 선택해 사용할 수 있습니다. 예를 들어 단순 분기 판단만 수행하는 Thinking Agent에는 비교적 가벼운 모델을 적용하고, NL Agent에는 자연어를 SQL로 정확하게 변환하는 특화된 LLM을 사용할 수 있습니다. 이를 통해 비용과 성능을 균형 있게 최적화할 수 있습니다.

3. 추론 기반의 도구 활용

Agent는 자체적인 추론 능력을 활용해 더 나은 방식으로 문제를 해결합니다. 예를 들어 "SELECT * FROM store"라는 쿼리에 유사 결과가 없을 경우 "SELECT * FROM shop”, "CREATE TABLE store" 등의 쿼리로 맥락에 맞게 변경하여 함수 호출을 다시 시도함으로써 문제를 해결하려 합니다. 이처럼 Agentic AI는 단순한 자동화를 넘어 상황을 인식하고 자율적으로 판단하며 문제를 해결하는 고도화된 방식을 구현합니다.

4. 효율적 Context 활용

기존의 RAG 시스템은 사용자의 질문이 단순하든 복잡하든 관계없이 무조건 관련 문서를 검색하여 context에 포함시키고 LLM에 전달하는 구조였습니다. 이 방식은 항상 retrieval과 embedding, context 재구성을 거치기 때문에 비용과 응답 속도 면에서 비효율적일 수 있습니다.

반면 Agentic AI는 질문의 목적과 필요성을 판단한 후 context가 반드시 필요한 경우에만 외부 정보를 검색하거나 tool을 호출합니다. 예를 들어 단순한 질의에는 context 없이 바로 답변하고, 복잡하거나 근거가 필요한 질문에만 on-demand 방식으로 context를 보강합니다.

이전 글에서 Function Calling과 MCP를 통해 AI에 ‘손과 발’을 달아주었다고 표현한 바 있는데요. 이제 Agentic AI를 통해 우리는 AI에 ‘생각하는 힘’, ‘의사결정 능력’, ‘자율성’을 부여하고 있습니다. 앞으로의 AI는 단지 ‘무엇을 할지’를 지시받는 존재가 아니라 ‘어떻게 할지’를 스스로 고민하고 실행하는 존재로 진화하게 될 것입니다. 단순한 기술적 진보를 넘어 AI가 함께 일하는 디지털 동료가 되는 변화의 시작이죠.

지금 이 글을 읽고 계시는 여러분의 팀과 서비스 및 문제 해결 방식에 Agentic AI를 어떻게 접목할 수 있을지 고민해보는 것이 곧 다음 세대를 준비하는 가장 실질적인 전략이 되지 않을까요?