티스토리 뷰

 

들어가며: AI Agent라는 용어가 불러온 혼란

 

최근 몇 년 사이 AI Agent라는 용어는 빠르게 확산되었습니다. 산업 현장에서는 LLM을 활용해 요약을 생성하거나 판단을 보조하는 시스템도 Agent로 불리고, 학술 문맥에서는 자율적으로 행동을 선택하는 시스템만을 Agent로 정의하는 경우가 많습니다. 이로 인해 같은 용어를 사용하면서도 서로 다른 대상을 떠올리는 상황이 빈번하게 발생합니다.

 

이러한 혼란은 기술의 발전 속도 때문이라기보다는, 자동화·AI 보조·자율성이라는 서로 다른 개념이 하나의 단어로 묶여 사용되고 있기 때문이라고 볼 수 있습니다. 이 글에서는 AI Agent를 하나의 단일 개념으로 정의하려 하기보다는, Automation pipeline, AI-Assisted Automation, True AI Agent라는 세 단계로 나누어 정리합니다. 이를 통해 현재 우리가 구현하고 있는 시스템이 어디에 위치하는지를 보다 명확히 바라보는 데 목적이 있습니다.

 


 

Automation pipeline: 규칙 기반 자동화의 범위

 

첫 번째 단계는 Automation pipeline입니다. 이는 많은 서버 개발자에게 익숙한 구조로, 정해진 작업을 정해진 순서대로 실행하도록 설계된 자동화 시스템을 의미합니다.

 

예시로 살펴볼 시스템은 Spring Batch 기반의 Scheduled Batch Job입니다. RSS를 통해 외부 데이터를 수집하고, 사전에 정의된 규칙으로 내용을 정제한 뒤 Draft 상태로 저장합니다. 이후 Slack을 통해 알림을 보내고, 최종 게시 여부는 사람이 판단합니다. 이 전체 흐름은 자동으로 실행되지만, 시스템 내부에는 AI 요소가 포함되어 있지 않습니다.

 

이 구조의 특징은 자동화의 대상이 작업 절차 자체라는 점입니다. 언제 수집할지, 어떤 규칙으로 정제할지, 어떤 시점에 알림을 보낼지는 모두 사람이 미리 정의합니다. 시스템은 주어진 규칙을 반복 실행할 뿐, 정보의 중요성이나 목적 달성 여부를 스스로 판단하지 않습니다.

 

학술적으로 Agent는 환경을 인식하고, 그 인식에 기반해 행동을 선택하는 존재로 정의됩니다. 이러한 정의에 비추어 보면, 규칙 기반 자동화 파이프라인은 환경에 대한 해석이나 목표 지향적 행동 선택을 수행하지 않습니다. 따라서 Automation pipeline은 자동화된 시스템이기는 하지만, Agent로 분류되지는 않습니다.

 


 

AI-Assisted Automation: 판단을 보조하는 AI의 도입

 

두 번째 단계는 AI-Assisted Automation입니다. 이 단계에서는 기존 자동화 파이프라인에 AI가 일부 포함됩니다. 다만, AI의 도입이 곧바로 자율성을 의미하지는 않습니다.

 

앞선 예시 시스템에 AI를 추가해 보겠습니다. RSS로 데이터를 수집한 뒤, LLM을 활용해 콘텐츠를 요약합니다. 요약 결과를 기반으로 중요도 점수를 계산하고, 점수가 일정 기준 이상이면 자동으로 게시합니다. 기준에 미치지 못하는 경우에는 Slack을 통해 사람의 승인을 요청합니다.

 

이 구조에서는 이전 단계와 달리 AI가 요약과 중요도 판단에 관여합니다. 이는 사람이 모든 콘텐츠를 직접 검토하지 않아도 되도록 돕는 실질적인 개선입니다. 그러나 시스템의 전체 구조를 살펴보면, 여전히 파이프라인은 고정되어 있습니다. AI는 정해진 위치에서 정해진 입력을 받아 결과를 반환할 뿐, 다음에 무엇을 할지 스스로 결정하지는 않습니다.

 

공식 문서에서도 이러한 시스템은 일반적으로 AI-assisted workflow 또는 human-in-the-loop 시스템으로 설명됩니다. 즉, AI는 판단을 보조하는 도구이며, 의사결정 구조와 책임은 여전히 사람이 설계하고 관리합니다.

 

이 단계는 Automation pipeline과 True AI Agent 사이의 중요한 중간 지점입니다. 자동화의 효율과 유연성은 크게 향상되지만, 시스템이 목표를 해석하고 행동 계획을 수립하는 주체가 되지는 않습니다.

 


 

True AI Agent: 목표 기반 자율 시스템

 

세 번째 단계는 True AI Agent입니다. 이 단계에서 시스템은 더 이상 고정된 파이프라인을 따르지 않습니다. 사용자는 구체적인 작업 절차가 아니라, 달성하고자 하는 목표만을 제시합니다.

 

예를 들어, 사용자는 “OpenAI와 Anthropic의 최신 업데이트를 찾아 블로그에 게시하라”라는 목표를 전달합니다. 이후 시스템은 어떤 정보 소스를 탐색할지, 어떤 검색 쿼리를 사용할지, 수집한 정보가 중요한지 여부를 스스로 판단합니다. 글의 구조와 톤을 결정하고, 게시 여부를 판단하며, 필요하다면 다른 접근 방식을 시도합니다.

 

이러한 시스템이 Agent로 분류되는 이유는 행동 계획 수립과 수정의 주체가 시스템 내부에 있기 때문입니다. 학술적 정의에서 Agent는 목표 지향적으로 행동을 선택하고, 그 결과를 다시 인식에 반영하는 존재로 설명됩니다. True AI Agent는 이러한 순환 구조를 갖습니다.

 

LangChain이나 Claude Agent SDK와 같은 프레임워크는 이러한 구조를 구현하는 데 도움을 주는 도구입니다. 다만, 특정 프레임워크를 사용한다고 해서 자동으로 Agent가 되는 것은 아닙니다. 중요한 것은 시스템이 목표를 기준으로 행동을 선택하고, 실패를 전제로 전략을 조정할 수 있는지 여부입니다.

 


 

세 단계의 차이를 가르는 기준

 

Automation pipeline, AI-Assisted Automation, True AI Agent의 차이는 사용된 기술의 최신성이나 AI 모델의 종류에서 비롯되지 않습니다. 핵심은 판단과 의사결정이 어디에서 이루어지는가입니다.

 

Automation pipeline에서는 판단이 사람에게 있습니다.

AI-Assisted Automation에서는 판단의 일부를 AI가 보조하지만, 구조와 책임은 여전히 사람에게 있습니다.

True AI Agent에서는 목표 달성을 위한 판단과 행동 선택이 시스템 내부에서 이루어집니다.

 

이 기준을 적용해 보면, 현재 산업 현장에서 Agent로 불리는 많은 시스템이 실제로는 AI-Assisted Automation 단계에 속한다는 점을 확인할 수 있습니다. 이는 기술적으로 부족하다는 의미라기보다는, 설계 의도와 역할이 다르다는 의미에 가깝습니다.

 


 

정리하며: 개발자의 시선에서 바라본 AI Agent

 

AI Agent라는 개념은 기술 발전과 함께 계속 변화하고 있습니다. 그렇기 때문에 특정 시스템을 Agent라고 부를 수 있는지에 대해 단정적으로 결론을 내리기보다는, 어떤 기준으로 바라볼 것인지를 정리하는 것이 더 중요하다고 느껴집니다.

 

개발자로서 시스템을 설계하거나 운영할 때, “이 시스템은 목표만 주어졌을 때 스스로 행동을 선택할 수 있는가”라는 질문은 하나의 기준점이 될 수 있습니다. 이 질문에 대한 답을 통해, 우리가 구현한 시스템이 자동화인지, AI 보조 자동화인지, 또는 자율적인 Agent에 가까운지를 비교적 명확하게 판단할 수 있습니다.

 

이 글에서 정리한 세 단계는 정답을 제시하기보다는, 개념을 정리하기 위한 하나의 틀에 가깝습니다. 각 단계는 서로 배타적인 선택지가 아니라, 문제의 성격과 조직의 요구에 따라 선택될 수 있는 설계 방향입니다. 이러한 관점에서 AI Agent라는 용어를 조금 더 신중하게 사용해 보는 것도 의미 있는 출발점이 될 수 있습니다.