워크플레이스 에이전트 시스템에서 LLM API 사용 시 한계와 문제

기업에서 전사용 워크플레이스 에이전트 시스템을 구축할 때 단순히 LLM API만으로는 복합적이고 복잡한 기업 환경의 요구사항을 충족하기 어려운 다양한 한계가 존재합니다.

본 분석에서는 토큰 한도, 컨텍스트 윈도우 제약, 숫자적 능력의 한계, 함수 호출의 복잡성 등 기술적 제약사항들과 함께 LLM 래퍼 서비스가 에이전틱 기능을 제공하지 않는 구조적 한계를 종합적으로 검토합니다. 특히 OpenAI, Claude, Google Gemini 등 주요 LLM 제공업체들이 추가적으로 제공하는 API 기능들을 활용하더라도 여전히 남아있는 장애물들과 기업 환경에서 요구되는 에이전틱 아키텍처의 필요성을 심도 있게 분석합니다.

LLM API의 기본적 기술 한계

1. 컨텍스트 윈도우 제약과 정보 처리 한계

LLM은 입력된 텍스트를 토큰 단위로 처리합니다. 이 토큰은 하나의 단어 전체일 수도 있고, 단어의 일부 또는 개별 문자일 수도 있습니다. 일반적으로 영어 기준으로 1토큰은 약 4자에 해당하지만, 언어 구조와 모델의 토크나이저(tokenizer)에 따라 차이가 발생합니다. 이 토큰화 과정 자체가 정밀한 정보의 단절이나 손실을 유발할 수 있는 구조적 원인 중 하나입니다.

또한, 모든 LLM에는 사전에 정의된 토큰 한도가 존재합니다. 예를 들어, OpenAI의 GPT-4o는 최대 128k 토큰의 컨텍스트 윈도우를 지원하지만, 출력은 4k 토큰으로 제한됩니다. Anthropic의 Claude 역시 최대 200k 토큰을 수용할 수 있지만, 출력은 동일하게 4k 토큰 이내로 제한됩니다.

이러한 컨텍스트 윈도우의 제약은 긴 문서나 복잡한 대화에서 문맥 기반 추론을 방해하며, 정보의 일관성과 정밀도를 저하시키는 주요 원인이 됩니다. 특히 문서의 앞부분에서 제시된 조건, 수치, 날짜, 예외사항 등을 모델이 출력 시점에 정확히 기억하거나 일관되게 반영하지 못하고 왜곡하는 현상이 빈번히 발생합니다.

이러한 문제를 해결하기 위해서는 RAG(Retrieval-Augmented Generation)와 같은 검색 증강 기법, 그리고 LLM과 외부 도구를 결합한 하이브리드 접근법이 요구됩니다. 단순히 컨텍스트 윈도우의 크기를 확장하는 것만으로는 한계가 있으며, 정보의 질과 문맥적 관련성을 높이는 방향이 보다 효과적입니다.

2. 추론과 정확성의 한계

LLM은 현재 정확한 계산이나 복잡한 논리적 추론이 요구되는 기업 환경에서는 한계가 됩니다. 특히 숫자 작업, 재무 분석, 통계 처리, 엔지니어링 계산 등 정확성이 필수적인 업무를 수행할 때 LLM API만으로는 충분한 신뢰성을 보장하기 어렵습니다. 이 부분 역시 보완적인 접근법이 필요합니다.

실제로 여러 연구자들은 LLM이 수행하는 산술 및 수리 연산의 오답률이 높다는 점을 지적하고 있으며, 또한 표 형식이나 CSV와 같은 구조화된 데이터를 다룰 때, LLM은 이 데이터를 단순한 연속형 토큰 스트림으로 처리하는 경향이 있으며, 셀 간의 공간적 관계를 명확히 이해하지 못합니다. 이로 인해 데이터 간의 연산, 비교, 정렬 등의 작업에서 오류가 발생하거나 정확도가 떨어질 수 있습니다. 결과적으로 이러한 구조화 데이터의 정밀한 처리가 요구되는 환경에서는 별도 기술적 방식이 필수적이라 할 수 있습니다.

그리고, LLM의 단계별 추론 과정에서 발생하는 오류는 연쇄적으로 전파되는 특성이 있다. 이러한 오류 전파는 실무 환경에서 특히 위험하다. 예를 들어, 복잡한 비즈니스 로직을 처리할 때 초기 단계의 작은 실수가 전체 프로세스의 무결성을 해칠 수 있습니다.

‍

3. 함수 호출과 도구 통합의 복잡성

OpenAI의 함수 호출 기능은 프롬프트에서 JSON 형식으로 함수와 해당 인수를 설명할 수 있게 하는 기능입니다. 그러나 실제로 모델이 직접 함수를 호출하거나 실행하지는 않으며, 대신 호출해야 하는 함수와 사용할 인수를 JSON 형태로 반환합니다. 이 과정에서 모델이 실제 존재하지 않는 추가 인수를 생성하는 환각(hallucination) 현상이 발생할 수 있습니다.

함수 호출을 통한 외부 도구 연결 과정은 여러 단계를 거쳐야 합니다. 우선, 사용자 질문을 모델에 요청으로 보내고, 모델이 호출할 함수를 결정하면 JSON 출력을 파싱하여 실제로 함수를 실행해야 합니다. 이후 함수 실행 결과를 다시 모델에 입력하는 방식으로 반복하여 요청을 계속해야 하므로 프로세스가 복잡해집니다. 이러한 다단계의 과정은 전사용 시스템에서 다양한 기업 도구와의 연동을 구축할 때 상당한 개발 및 유지보수 부담을 초래합니다.

Model Context Protocol(MCP)은 AI 에이전트가 외부 도구와 데이터를 표준화된 방식으로 연결할 수 있게 하는 혁신적인 프로토콜로 주목받고 있으나, 실제 에이전트 시스템에 도입할 때는 다양한 문제점과 한계가 존재합니다. 또한 MCP는 아직 초기 기술로서 표준화가 완벽하지 않고, 성능 최적화와 생태계 성숙도 측면에서 기업의 대규모 채택을 위해서는 상당한 개선이 필요한 상황이기 때문에 신중한 접근이 요구됩니다. 유사한 방식으로는 이전에 나온 Openai의 Response API가 있습니다.

Latency 문제를 포함하여 MCP(Model Context Protocol)에서 심각한 문제 중 하나는 도구 오염 공격(Tool Poisoning Attack)입니다. 이 공격은 MCP 도구 설명 내에 악의적인 지시 사항을 은밀히 삽입하는 방식으로 이루어지며, 사용자에게는 보이지 않지만 AI 모델에게는 그대로 노출되는 형태로 유지됩니다. 예를 들어, 사용자에게는 단순히 “두 숫자를 더합니다”라고 표시되는 도구가 실제로는 사용자의 민감한 구성 파일이나 SSH 개인 키 등에 접근하도록 설계되어 있을 수 있습니다. 이러한 공격의 핵심적인 문제는 사용자 인터페이스가 도구의 실제 기능과 AI 모델이 인식하는 정보 사이의 불일치를 명확히 보여주지 못한다는 점입니다. 더욱 우려스러운 점은, 일부 MCP 클라이언트가 도구 설치 시 명시적인 사용자 승인을 요구하더라도, MCP의 패키지 또는 서버 기반 아키텍처가 일종의 “rug pull”을 허용한다는 사실입니다. 즉, 악의적인 서버 운영자가 사용자가 도구를 승인한 이후에도 도구 설명을 변경할 수 있어, 처음에는 안전해 보였던 도구가 나중에 악의적인 명령을 포함하게 될 가능성이 존재합니다.이러한 위협을 완화하기 위해서는 공인되고 검증된 MCP 패키지 만을 사용하는 것이 매우 중요합니다. 또한 도구의 정의 및 메타데이터에 대한 변경을 불가능하게 하거나, 변경 내역을 추적할 수 있는 무결성 검증 체계를 마련하는 것이 권장됩니다. 이러한 위협을 완화하기 위해서는 공인되고 검증된 MCP 패키지 만을 사용하는 것이 매우 중요합니다. 또한 도구의 정의 및 메타데이터에 대한 변경을 불가능하게 하거나, 변경 내역을 추적할 수 있는 무결성 검증 체계를 마련하는 것이 권장됩니다.

MCP는 아직 초기 단계의 기술로, 모든 AI 시스템에 보편적으로 적용될 수 있는 완성도 높은 표준을 갖추고 있다고 보기 어렵습니다. 특히 도입 초기에는 인증(Authentication) 사양조차 정의되어 있지 않았으며, 이후 OAuth 기반 인증 방식이 도입되었지만 실제로는 구현 복잡성과 일관성 부족으로 인해 많은 개발자들 사이에서 불만이 제기되었습니다. 인증 방식이 명확히 정립되지 않았던 시기에는 각 MCP 서버가 자체 방식으로 인증을 처리해야 했고, 일부 서버에서는 인증 절차 없이도 민감한 데이터에 접근이 가능한 심각한 보안 문제가 발생하기도 하였습니다.

현재 MCP는 보안 강화를 위해 OAuth 인증, 최소 권한 원칙(Principle of Least Privilege), 입력 유효성 검사(Input Validation) 등 여러 보안 가이드라인을 제시하고 있으며, 프로토콜 사양 역시 빠르게 발전 중입니다. 그럼에도 불구하고 기업이 MCP를 대규모로 도입하기 위해서는 생태계의 성숙도, 구현의 일관성, 성능 최적화, 장기적인 유지관리 체계 등에 대한 신뢰성과 안정성이 충분히 확보되어야 한다는 지적이 지속적으로 제기되고 있습니다.

LLM Wrapper vs Agentic Architecture의 구조적 차이

LLM Wrapper의 본질적 한계

LLM 래퍼(wrapper)란 GPT-4와 같은 사전 훈련된 언어 모델 위에 구축된 도구나 애플리케이션을 의미합니다. 이러한 래퍼는 주로 사람이 읽을 수 있는 텍스트를 입력받아 응답을 생성하는 채팅 인터페이스 중심으로 설계되며, 대부분의 상용 LLM 기반 대중 서비스 역시 이러한 구조를 따릅니다.

문제는 이러한 래퍼가 단순히 입력과 출력을 연결하는 수준에 머무르기 때문에, LLM이 제공할 수 있는 더 복잡하고 유의미한 기능들을 제한적으로 밖에 활용하지 못한다는 점입니다. 특히 다단계 업무 흐름, 문맥을 유지한 상태 기반 액션 처리, 외부 시스템과의 연동 등이 요구되는 실제 비즈니스 환경에서는 LLM 래퍼만으로는 한계가 분명합니다. 또한, 이러한 단순 인터페이스는 LLM이 중간 처리 단계로 사용되어야 하는 복잡한 데이터 파이프라인 상의 활용을 가로막는 요인이 되기도 합니다.

에이전틱(agentic) 아키텍처는 LLM을 기능 단위로 구성하여 각 작업을 독립된 에이전트로 분리함으로써, 단순 작업부터 복잡한 프로세스 자동화에 이르기까지 다양한 수준의 AI 기능을 체계적으로 구현할 수 있도록 합니다. 이러한 아키텍처는 멀티 에이전트 간의 협업뿐만 아니라, 문서 분석, 숫자 처리, 조건 기반 분기 등 기능 단위의 세분화된 역할 수행에도 적합합니다. 각각의 에이전트는 특정 작업에 최적화되어 설계되며, 필요에 따라 조합되어 복잡한 비즈니스 로직을 구성할 수 있습니다. 이로 인해 단일 모델에 모든 기능을 위임하는 구조보다 유연성과 확장성이 뛰어나며, 결과의 일관성과 정확도 또한 높일 수 있습니다.

하지만 이러한 기능은 단순한 LLM 래퍼 서비스로는 구현이 불가능하며, 복잡한 에이전트 설계와 체계적인 시스템 통합이 필요합니다. 따라서 기업 환경에서는 단순 래퍼 수준의 서비스가 아닌, Agentic AI 아키텍처에 기반한 구조적 접근이 필요합니다.

LLM 프레임워크의 복잡성 문제

LLM 프레임워크의 복잡성 문제는 래퍼 구조의 한계를 더욱 명확히 드러냅니다. 대부분의 AI 애플리케이션은 단순한 응답 생성 이상의 구조화된 처리, 외부 시스템 연동, 데이터 정제 및 강화, 상태 기반 추론, 보안 통제 등 다층적인 기능을 필요로 하며, 이를 위해서는 보다 유연하고 목적 지향적인 설계가 가능한 프레임워크 또는 맞춤형 아키텍처가 필수적입니다.

뿐만 아니라, 단순한 질의응답이나 문서 요약과 같은 단위 작업, 이질적인 형식의 문서 해석, 수치 기반의 정밀 계산 등 기본적인 기능 수행에 있어서도 에이전틱한 설계가 요구되는 경우가 많습니다. 예를 들어, 특정 문서에서 지표를 추출하고 이를 수치로 계산한 후, 결과에 따라 다양한 후속 작업을 이어가는 방식은 단일 LLM 호출로는 구현하기 어렵습니다. 즉, 단순한 멀티 에이전트 협업뿐만 아니라 기능 단위의 정교한 에이전트 구조 또한 필요합니다.

결론

기업의 전사용 워크플레이스 에이전트 시스템 구축에서 LLM API만으로는 다양한 한계와 장애물에 직면하게 됩니다. 토큰 한도와 컨텍스트 윈도우 제약은 대용량 기업 데이터 처리를 어렵게 만들고, 수학적 추론 능력의 한계는 정확한 계산이 필요한 업무에서 신뢰성 문제를 야기합니다. 데이터 보안과 프라이버시 우려는 민감한 기업 정보를 다루는 환경에서 치명적인 제약으로 작용하며, 특정 LLM 서비스 의존성 문제는 업무 연속성을 위협할 수 있습니다.

‍