
AI 에이전트를 독립형 애플리케이션처럼 구축하는 것을 멈추세요
요약
많은 팀이 AI 에이전트를 독립형 애플리케이션처럼 구축하여 중복된 로직과 확장성 문제를 겪고 있습니다. 에이전트가 모든 기능을 직접 소유하는 대신, 인증·도구·컨텍스트 등을 공유 플랫폼에서 제공받는 아키텍처로 전환해야 합니다.
핵심 포인트
- 에이전트마다 인증, 권한, 도구 등을 반복 구현하는 것은 비효율적임
- 전통적 소프트웨어 공학처럼 공유 플랫폼 기반의 아키텍처가 필요함
- 에이전트는 가볍게 유지하고 비즈니스 로직에 집중해야 함
- 컨텍스트 서비스와 도구 레지스트리를 통한 책임 분리가 핵심임
지난 몇 달 동안 저는 꽤 많은 엔터프라이즈 AI 프로젝트를 실험해 왔습니다.
한 가지 분명해진 사실이 있습니다.
대부분의 팀은 여전히 웹 애플리케이션을 구축하던 방식과 동일한 방식으로 AI 에이전트 (AI agents)를 구축하고 있다는 점입니다.
모든 새로운 유스케이스 (use case)가 또 다른 에이전트가 됩니다.
또 다른 프롬프트 (prompt).
또 다른 지식 베이스 (knowledge base).
또 다른 API 통합 (API integration).
처음에는 작동합니다.
하지만 확장 (scale)되지 않습니다.
모든 에이전트는 동일한 문제를 해결하기 시작합니다
10개의 AI 에이전트를 가진 회사를 상상해 보세요.
하나는 영업 (Sales)을 돕습니다.
하나는 재무 (Finance)를 지원합니다.
또 다른 하나는 인사 (HR)를 보조합니다.
또 다른 하나는 주간 보고서를 생성합니다.
외부에서 보기에는 달라 보이지만, 내부적으로는 많은 동일한 문제들을 해결하고 있습니다.
각 에이전트는 다음을 필요로 합니다:
- 인증 (authentication)
- 권한 제어 (permission control)
- 비즈니스 정의 (business definitions)
- 엔터프라이즈 데이터에 대한 액세스 (access to enterprise data)
- 공유 문서 (shared documents)
- 도구 (tools)
- 모니터링 (monitoring)
그럼에도 불구하고 많은 팀이 이러한 기능들을 반복해서 구현합니다.
그 결과, 매달 유지보수가 점점 더 어려워지는 중복된 로직이 발생합니다.
*우리는 이미 소프트웨어 엔지니어링 (Software Engineering)에서 이 문제를 해결했습니다
*
전통적인 애플리케이션은 더 이상 인프라를 처음부터 구현하는 경우가 거의 없습니다.
인증 (Authentication)은 공유됩니다.
로깅 (Logging)은 공유됩니다.
모니터링 (Monitoring)은 공유됩니다.
설정 (Configuration)은 공유됩니다.
플랫폼이 나머지를 제공하기 때문에 개발자들은 비즈니스 로직 (business logic)에 집중합니다.
저는 AI 엔지니어링 (AI engineering)도 동일한 아키텍처 (architecture)를 향해 가고 있다고 생각합니다.
에이전트가 모든 것을 스스로 소유해서는 안 됩니다.
에이전트는 공유된 플랫폼 기능들을 소비해야 합니다.
에이전트 외부에 존재해야 하는 것은 무엇인가?
엔터프라이즈 AI 시스템을 바라볼 때, 저는 에이전트가 가볍게 유지되어야 한다고 점점 더 확신하게 됩니다.
모든 것을 프롬프트 (prompts) 내부에 임베딩 (embedding)하는 대신, 저는 책임을 분리하고 싶습니다.
예를 들어:
컨텍스트 서비스 (Context Service)
비즈니스 정의, 신뢰할 수 있는 데이터 세트 (datasets), 그리고 재사용 가능한 조직 지식을 담당합니다.
도구 레지스트리 (Tool Registry)
에이전트가 사용 가능한 API, SQL 도구, 검색 서비스 및 엔터프라이즈 시스템을 발견할 수 있는 단일 장소입니다.
권한 계층 (Permission Layer)
모든 에이전트는 자체적인 권한 부여 규칙을 구현하는 대신 동일한 액세스 정책을 따릅니다.
메모리 서비스 (Memory Service)
고립된 대화 기록 대신 공유되는 장기 메모리 (long-term memory)를 제공합니다.
관측 가능성 (Observability)
에이전트가 어떻게 성능을 내고 있는지, 어떤 도구를 호출하고 있는지, 그리고 어디에서 실패가 발생하는지 이해할 수 있는 하나의 대시보드입니다.
이러한 기능 중 그 어느 것도 개별 에이전트 내부에 속해서는 안 됩니다.
이것들은 플랫폼의 관심사 (platform concerns)입니다.
에이전트를 작게 유지하세요
제가 배운 한 가지 교훈은 에이전트가 작을수록 일반적으로 개선하기가 더 쉽다는 것입니다.
에이전트가 단일 책임에 집중할 때, 테스트, 디버깅 및 교체가 더 쉬워집니다.
공유 플랫폼이 그 외의 모든 것을 처리합니다.
점점 더 복잡한 프롬프트 (prompts)를 만드는 대신, 우리는 더 나은 인프라 (infrastructure)에 투자해야 합니다.
플랫폼이 더 재사용 가능해질수록, 모든 새로운 에이전트를 구축하는 것은 더 단순해집니다.
다른 사고 모델 (A Different Mental Model)
저는 더 이상 AI 에이전트를 애플리케이션으로 생각하지 않습니다.
저는 그것을 런타임 컴포넌트 (runtime component)로 생각합니다.
작업을 전달받습니다.
컨텍스트 (context)를 요청합니다.
사용 가능한 도구를 발견합니다.
권한을 확인합니다.
업무를 완료합니다.
지능의 대부분은 에이전트 자체 내부에 있지 않습니다.
그것은 에이전트를 지원하는 플랫폼 전반에 분산되어 있습니다.
마치며
현재 AI 에이전트를 구축하는 것은 놀라울 정도로 쉬워졌습니다.
하지만 기업 내부에서 수십 개, 나아가 수백 개의 에이전트를 운영하는 것은 그렇지 않을 것입니다.
가장 빠르게 움직이는 조직이 반드시 더 많은 에이전트를 구축하는 것은 아닙니다.
그들은 해당 에이전트들이 실행될 수 있는 더 나은 플랫폼을 구축할 것입니다.
제 생각에, 그것이 바로 엔터프라이즈 AI 엔지니어링이 나아갈 다음 방향입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기