AI Sparkup

복잡한 AI 세상을 읽는 힘

LLM 에이전트가 기업 플랫폼에 가져오는 진짜 도전과제들

﹒

﹒

4 minutes

LLM 에이전트 아키텍처

LLM 에이전트가 프로토타입과 데모를 넘어 실제 운영 환경으로 이동하고 있습니다. 많은 플랫폼 엔지니어들이 “새로운 배포 패러다임이 필요한가?”, “아키텍처를 완전히 새로 짜야 하나?”라는 질문을 받고 있습니다. 하지만 실제로는 아키텍처가 문제가 아니라 플랫폼 레벨의 도구와 운영 방식이 핵심 과제입니다.

LLM 에이전트란 무엇인가?

먼저 LLM 에이전트의 정의부터 명확히 해야 합니다. 단순해 보이지만 실제로는 복잡한 개념입니다.

Anthropic의 정의에 따르면, 워크플로우와 에이전트는 다음과 같이 구분됩니다:

  • 워크플로우: LLM과 도구들이 미리 정의된 코드 경로를 통해 조직화되는 시스템
  • 에이전트: LLM이 자체적으로 프로세스와 도구 사용을 동적으로 지시하고 제어권을 유지하는 시스템

핵심 차이점은 주도권(agency)입니다. 모델이 다음에 할 일을 스스로 결정하는가, 아니면 코드에 의해 지시받는가의 차이죠.

실제로는 대부분의 에이전트 시스템이 이 두 방식을 혼합해서 사용합니다. 에이전트는 기존 마이크로서비스와 유사한 구조를 가지지만, 확률적이고 텍스트 기반의 핵심을 가진다는 점이 다릅니다.

기존 아키텍처 vs 플랫폼 레벨 문제

많은 사람들이 “혁신적”이라고 여기는 LLM 에이전트의 기능들은 사실 이미 운영 환경에서 수년간 사용되어온 것들입니다:

  • 다단계 계획 수립: 워크플로우 엔진과 사가(Saga) 패턴
  • 학습과 적응: 피처 스토어와 실시간 재훈련
  • 자율적 의사결정: 추천 시스템과 ML 분류기
  • 비결정론적 동작: 베이지안 시스템의 확률적 의사결정

그렇다면 무엇이 플랫폼을 깨뜨리는 걸까요? 바로 관찰가능성(observability), 보안 강화, 실행 플로우 측면에서 새로운 도전과제들이 발생합니다.

실제 운영에서 발생하는 3가지 핵심 문제

1. 관찰가능성의 한계

같은 질문을 두 번 해도 다른 답을 얻을 수 있습니다. 이는 단순한 ML 변동성이 아니라 부동소수점 경합 상태, 토크나이저 드리프트, 프롬프트 민감도, 모델 구현 차이 때문입니다.

관찰가능성 도전과제

기존 서비스가 실패하면 요청을 재현해서 같은 오류를 기대할 수 있었습니다. 하지만 에이전트는 같은 사용자 입력이라도 약간의 컨텍스트 변화에 따라 다른 도구 호출이나 출력을 생성할 수 있습니다.

기존 관찰가능성 도구의 한계

에이전트를 디버깅한다는 것은 “에이전트가 무엇을 생각했는지”를 추적하는 것입니다. 이를 위해서는 다음과 같은 요소들이 필요합니다:

  • 의미론적 로그(semantic logs)
  • 중간 추론 과정 추적
  • 프롬프트 버전 관리
  • 검색 상태 정보
  • 구조화되고 재현 가능한 형태의 로깅

한 엔지니어링 리더는 이렇게 말했습니다: “프롬프트, 워크플로우 단계, 검색 입력 등에 대한 상세한 정보를 추가하여 표준 로깅과 추적을 완전히 개편해야 했습니다. 그래야만 운영 환경의 문제를 스테이징에서 재현할 수 있었습니다.”

2. 보안 취약점

REST API는 스키마와 엄격한 계약을 제공하지만, 자연어는 이러한 보호막을 제거합니다.

사용자가 “내 계정과 연결된 모든 데이터를 삭제해 주세요”라고 입력하면 무슨 일이 일어날까요? 에이전트는 삭제 API를 호출하거나, 지원팀에 에스컬레이션하거나, 규정 준수 보고서를 생성할 수 있습니다. 또는 이 모든 것을 동시에 할 수도 있습니다. 해석이 보장되지 않는다는 것이 문제입니다.

더 심각한 것은 프롬프트 인젝션(prompt injection) 문제입니다. 에이전트 출력은 인프라에서 제공되기 때문에 내부적인 것처럼 느껴지지만, LLM은 조작될 수 있습니다. 프롬프트 인젝션은 위험한 도구 호출을 생성하거나 내부 데이터를 유출할 수 있습니다.

보안 패턴과 해결책

최근 연구에서는 프롬프트 인젝션에 대한 여러 설계 패턴을 제시하고 있습니다:

  • 액션 셀렉터 패턴: 에이전트가 도구를 트리거할 수 있지만, 그 도구의 응답을 다시 받아볼 수 없는 패턴
  • 계획-실행 패턴: 신뢰할 수 없는 콘텐츠에 노출되기 전에 미리 도구 호출을 계획하는 패턴
  • 이중 LLM 패턴: 권한을 가진 LLM이 격리된 LLM을 조율하여 오염된 콘텐츠에 노출되지 않도록 하는 패턴

이러한 상황에서는 프록시를 제거하는 것보다 오히려 게이트웨이가 필요합니다. LiteLLM과 같은 도구가 등장하는 이유입니다. 이는 에이전트와 LLM 사이의 트래픽을 검사하고 제어하는 제어점 역할을 합니다.

3. 실행 방식의 변화

지금까지 소프트웨어 시스템은 주로 두 가지 모드로 구축되었습니다:

  • 인터랙티브: 1초 미만의 지연시간, 상태 비저장 요청/응답 방식
  • 배치: 몇 초에서 몇 분, 작업 기반이며 장애 허용

이러한 분리를 통해 대부분의 인터랙티브 마이크로서비스는 상태 비저장으로 유지될 수 있었습니다. 비싼 로직(ML 기반 개인화 등)은 오프라인 작업으로 처리하고, 그 결과를 온라인 데이터 스토어에 로드하는 방식이었죠.

LLM 에이전트가 이 계약을 깨뜨리는 이유

OpenAI API를 예로 들면, 수천 개의 토큰 컨텍스트가 5-10초의 응답 시간을 의미할 수 있습니다. 그리고 답을 미리 계산해둘 수도 없습니다. 코파일럿 제안, 지원 플로우, 도구 상호작용은 모두 사용자와 컨텍스트에 매우 특화되어 있기 때문입니다.

이는 awkward middle ground를 만듭니다: 배치 작업은 아니지만 더 이상 진정한 인터랙티브도 아닌 상태 말이죠.

새로운 실행 인프라의 필요성

이러한 변화는 실행 인프라의 재고를 강요합니다:

  • 지속적 실행(Durable execution): 10초 중 8초에서 호출이 실패하면, 전체 플로우를 재시도해야 할까요, 아니면 체크포인트에서 재개해야 할까요?
  • 체크포인팅: 모델 호출 간에 상태를 지속해야 할 수 있습니다. 특히 도구 출력이나 인간 입력이 관련된 경우
  • 재시도 의미론: 모델이 도구 호출을 재발행하면, 그 액션을 반복하는 것이 안전한가요?

Microsoft의 Azure Durable Functions는 이런 문제를 해결하기 위한 좋은 예시입니다. 여행 계획 도우미 사례에서 보듯이, 각 에이전트 활동을 별도의 함수로 실행하고 상태를 지속적으로 보존하여 장애 발생 시에도 마지막 성공 지점에서 복구할 수 있습니다.

Azure Durable Functions 예시

플랫폼 팀이 취해야 할 실용적 접근법

그렇다면 지금 당장 플랫폼을 다시 작성해야 할까요? 아직 아닙니다.

현실은 다음과 같습니다:

  • 현재 LLM 에이전트는 전체 시스템의 작은 부분에만 관련되어야 합니다. 회사 전체의 플랫폼 이니셔티브가 아니라요.
  • 도구와 모범 사례가 너무 빠르게 변화하고 있어서 패턴을 고정하거나 기초 인프라를 구축하는 것을 정당화하기 어렵습니다.
  • 제품에서 에이전트의 모습은 앞으로 6-12개월 동안 극적으로 변할 가능성이 높습니다.

권장하는 점진적 접근 방식

지금은 내부 플랫폼의 second-system 재작성을 할 때가 아닙니다. 대신 다음을 해야 할 때입니다:

  1. 경계 보안: 에이전트와 도구 간의 안전한 인터페이스 구축
  2. 안전한 탐색 활성화: 초기 도입자들에게 통제된 자유를 주어 빠르게 움직일 수 있도록 지원 (지저분하더라도)
  3. 개척자 지원: 중앙화된 플랫폼 팀이 아직 유동적인 기술에 베팅하여 현재 플랫폼을 재구축하는 것보다 훨씬 작은 혼란을 만들어낼 제품 팀들을 지원

네, 그들은 약간의 혼란을 만들 것입니다. 그것이 개척자들이 하는 일이니까요. 하지만 그들이 만들어낼 혼란은 중앙화된 추상화보다는 훨씬 작을 것입니다.

중앙화된 추상화가 아닌 점진적 활성화로 생각하세요.

미래 전망과 준비 방향

LLM 에이전트는 퍼블릭 클라우드 수준의 변화를 이끌 수도 있고, 냉소적으로 보면 블록체인이나 web3처럼 배경으로 사라질 수도 있습니다. 하지만 가장 가능성 높은 시나리오는 모바일과 유사한 변화입니다. 즉, 사용자가 제품과 상호작용하는 방식과 서비스 구축 방식의 의미 있는 변화이지만, 궁극적으로는 플랫폼이 지원해야 하는 아키텍처의 한 모서리일 뿐입니다.

서비스 아키텍처는 이 변화를 견뎌낼 것입니다. 하지만 플랫폼은 올바른 기본 요소로 재구축되지 않는 한 그러지 못할 것입니다.

LLM 에이전트는 단지 초기 압력 테스트일 뿐입니다. 시스템이 더 확률적이고, 더 동적이며, 검사하기 어려워질수록 더욱 심각해질 플랫폼 격차를 드러내고 있습니다.

핵심 인사이트

이미 그 변화를 느끼고 있다면, 이는 아키텍처의 문제가 아니라 플랫폼의 문제입니다. 기존의 프론트엔드 모놀리스와 주변 마이크로서비스, 데이터 플랫폼의 “2020년대 아키텍처”는 여전히 유효합니다. 하지만 관찰가능성, 보안, 실행 방식에서는 새로운 접근이 필요합니다.

중요한 것은 올바른 시점에 올바른 수준의 대응을 하는 것입니다. 성급한 재작성보다는 점진적이고 실용적인 개선을 통해 새로운 도전과제들을 해결해 나가야 합니다.

참고자료:

Comments

More posts