방대한 컨텍스트로 인한 어텐션 희석 문제와 효율적인 MCP 기반 도구 추출 아키텍처

궁금하면 500원·2025년 11월 27일

AgenticAI ContextManagement LLM MCP PromptEngineering Software_architecture rag sLLM 데이터축소 어텐션희석

AI 미생지능

목록 보기

77/117

데이터 축소 및 도구 연동 하기

대규모 언어 모델을 활용한 시스템을 설계할 때 가장 먼저 직면하는 한계는 컨텍스트 윈도우의 관리와 토큰 비용, 그리고 어텐션의 효율성입니다.
아무리 컨텍스트 윈도우가 큰 모델이라 하더라도, 방대한 양의 데이터를 정제 없이 프롬프트에 주입하면 모델의 집중력이 분산되는 현상이 발생합니다.

본 글에서는 RAG 및 에이전틱 AI 시스템의 성능을 최적화하기 위한 핵심 전략인 LLM 기반 데이터 축소 기법과 효율적인 도구 연동 아키텍처에 대해 상세히 다룹니다.

1. LLM을 이용한 데이터 축소와 요약의 당위성

RAG 시스템 등에서 검색 결과로 얻은 방대한 문서를 그대로 프롬프트에 삽입하는 것은 안일한 접근입니다. 컨텍스트가 비대해지면 다음과 같은 치명적인 문제가 발생합니다.

어텐션 희석

입력 토큰의 양이 일정 수준을 넘어서면, 각 토큰이 가질 수 있는 어텐션 스코어의 영향력이 급격히 감소합니다.
결과적으로 모델은 컨텍스트 내부의 중요한 디테일을 무시하고 무작위적이거나 부정확한 답변을 출력하게 됩니다.

요약 손실 vs 비용 편익

30년 역사의 문서를 한 줄로 요약하면 디테일한 정보가 누락되는 '요약 손실'이 발생합니다. 그럼에도 불구하고 요약을 수행해야 하는 이유는 비용의 효율성과 질의 응답 성능의 균형 때문입니다.

비용 측면: 매 사용자 질의마다 수만 토큰의 원본 데이터를 반복해서 입력하면 막대한 API 비용이 누적됩니다.
반면, 데이터가 인입되는 시점에 1회성 비용을 들여 정제된 요약본을 만들어 두면, 이후 사용자 질의 시에는 최소한의 토큰만 소비하므로 장기적으로 비용이 크게 절감됩니다.

LLM 기반 요약의 정당성

요약 알고리즘의 본질은 결국 '프롬프트 엔지니어링'입니다.
프롬프트를 어떻게 구성하느냐에 따라 남길 정보와 버릴 정보의 방향성이 결정됩니다.

우리가 LLM 프롬프트에 배경 데이터를 제공하는 목적은 모델이 답변을 생성할 때 특정 방향으로 출력 편향을 일으키도록 유도하기 위함입니다.
따라서 요약 프로세스 자체를 LLM에게 맡기는 것은 매우 정당합니다.

LLM 기반 요약 지시의 핵심 전략
"이 데이터를 요약하되, 향후 사용자가 관련 질의를 던졌을 때 네가 가장 강력하게 힌트를 얻고 출력을 편향시킬 수 있는 구조로 요약해라."

이처럼 컨텍스트의 특성을 가장 잘 이해하고 있는 당사자인 LLM에게 지시할 때, 사후 질의 응답에 가장 최적화된 요약본을 얻을 수 있습니다.

2. 주요 데이터 축소 및 요약 기법

프롬프트 엔지니어링 기반의 대표적인 요약 기법들은 문서의 양과 구조적 특성에 따라 선택적으로 적용되어야 합니다.

Stuff 기법

개념: 단어 뜻 그대로 모든 문서 청크를 하나의 프롬프트에 밀어 넣고 한 번에 요약하도록 지시하는 방식입니다.
특징: 컨텍스트 윈도우가 매우 큰 대형 모델이 필요하며, 대용량 모델 사용에 따른 단일 호출 비용이 발생합니다.
다만 앞서 언급했듯 1회성 작업이므로 전체 아키텍처 관점에서 비용 부담은 크지 않습니다. 단, 문서가 너무 길 경우 어텐션 희석 문제가 발생할 수 있습니다.

Map-Reduce 기법

개념: 방대한 문서 집합을 페이지 또는 청크 단위로 쪼갠 뒤, 개별 청크에 대한 요약문을 먼저 생성합니다.
이후 생성된 요약문들을 다시 모아서 상위 단계의 요약문을 만들고, 최종적으로 하나의 요약본이 남을 때까지 이 과정을 재귀적으로 반복하는 방식입니다.

[원문 청크 A] -> [요약 A'] \
                            -> [최종 통합 요약]
[원문 청크 B] -> [요약 B'] /

리듀스의 컴퓨터 과학적 의미: 복잡한 다차원 데이터를 하위 차원인 예를들어 3차원 배열 -> 2차원 -> 1차원 -> 단일 스칼라 값 으로 축소해 나가는 과정을 의미합니다.
핵심: 각 단계마다 LLM에게 "정보 손실을 최소화하면서도, 최종 답변 시 편향을 가장 잘 일으킬 수 있는 핵심 정보를 남겨라"라는 지시를 일관되게 유지하는 것이 중요합니다.

Map-Refine 기법

개념: 문서 전체에 명확한 서사 구조나 인과관계가 존재할 때 사용하는 방식입니다.
예를 들어 1장을 읽어야만 2장을 이해할 수 있고, 2장을 바탕으로 3장이 전개되는 PDF 문서의 경우, 각 장을 독립적으로 요약한 뒤 합치면 서사가 파괴됩니다.
동작 방식: 1장의 요약본을 생성한 뒤, 이 1장 요약본과 2장 원문을 함께 모델에 입력하여 '1장의 맥락이 반영된 2장 누적 요약본'을 만듭니다.
이 과정을 문서 끝까지 반복하며 요약본을 지속적으로 갱신합니다.

Chain of Density

개념: 요약본의 정보 밀도를 단계적으로 높여가는 프롬프트 기법입니다.
무조건 글자 수를 줄이는 것이 아니라, 핵심 엔티티와 유의미한 정보를 압축적으로 주입하는 리파인 전략의 일종입니다.
구현: 복잡한 이론적 아키텍처보다는 프롬프트 설계 자체로 정의됩니다.
모델이 재귀적으로 자신의 출력을 검토하며 불필요한 수식어를 제거하고 밀도를 높이도록 유도하는 프롬프트 구조가 핵심입니다.

Cluster Map-Refine

개념: 데이터 청크들을 벡터 공간 상에서 클러스터링한 뒤, 각 클러스터별로 상위 개념의 요약 청크를 생성하여 계층적 트리 구조를 구축하는 기법입니다.
주의점: 이러한 고도화된 레벨의 검색 향상 기법들은 해당 논문이 테스트한 특수 데이터셋에 지나치게 오버피팅되어 있는 경우가 많습니다.
범용적인 도메인 데이터에 그대로 적용하면 클러스터링 단계에서 왜곡이 발생하여 실무 적용이 까다로울 수 있으므로 주의가 필요합니다.

3. 에이전틱 AI와 도구 연동 아키텍처

LLM이 자체적인 추론을 넘어 외부 API, 데이터베이스, 웹 검색 등의 도구를 자율적으로 선택하고 사용하는 고도화된 단계를 에이전틱 AI라고 합니다.

프롬프트 증강의 본질

아무리 복잡한 에이전트 시스템이나 외부 도구를 파이프라인에 배치하더라도, LLM 모델 자체를 실시간으로 변경할 수는 없습니다.
개발자가 제어할 수 있는 수단은 모델 파인튜닝이나 프롬프트 입력 제어 두 가지뿐입니다.

에이전트가 외부 도구를 실행하여 얻은 무수한 결과물들은 결국 최종 단계에서 하나의 시스템 프롬프트로 병합되어 LLM에 입력됩니다. 이를 증강 질의라고 부르며, RAG의 본질 역시 여기에 있습니다.

[사용자 질의] -> [에이전트/도구 실행] -> [방대한 결과 데이터 취합] -> [최종 프롬프트 증강] -> [LLM]

아무리 뛰어난 도구로 고품질의 데이터를 가져왔더라도, 최종 프롬프트 단계에서 취합 전략이 부실하여 컨텍스트가 산더미처럼 쌓이면 어텐션 희석으로 인해 최종 답변은 무너집니다.

대다수 입문서나 프레임워크 기초 편에서는 이 최종 취합 단계의 프롬프트 승부인 예를들어 검색 결과 중 중요한 내용을 프롬프트의 최상단과 최하단에 배치하는 Lost in the Middle 방지 전략 등을 깊게 다루지 않지만, 실제 프로덕션 환경에서는 이 지점이 시스템의 성패를 가릅니다.

4. 도구 지리 추출 전략 분석

사용자의 입력으로부터 어떤 도구를 어떤 인자로 호출할지 결정하는 전략은 크게 두 가지로 나뉩니다.

전략 분류	일괄 추출 전략	분산 추출 전략
개념	단일 대형 프롬프트에 모든 도구 정의를 넣고, 사용자 질의를 분석해 필요한 도구들을 한 번에 추출하는 방식	도구별로 특화된 작은 프롬프트나 전용 모델을 배치하여 개별적으로 도구 호출 파라미터를 추출하는 방식
장점	여러 도구 간의 의존성을 조율하고 우선순위를 판단할 수 있는 기회가 제공됨	개별 프롬프트 튜닝이 용이하며, 경량화된 소형 모델을 다수 배치하여 효율적으로 처리 가능
단점	지원하는 도구가 많아질수록 프롬프트 내 도구 정의가 비대해져 어텐션 희석으로 인한 도구 선택 실패율 증가	전체적인 맥락을 조율하는 상위 오케스트레이터의 역할이 별도로 요구됨

비-LLM 기반 추출의 활용

분산 전략 환경에서 RAG의 쿼리 추출은 반드시 LLM에 의존할 필요가 없습니다.
사용자 질의를 단순히 임베딩하여 벡터 DB를 검색하거나, Elasticsearch 등 역색인 엔진에 그대로 전달하거나, 정규식을 이용해 키워드를 파싱하는 방식이 소형 모델을 쓰는 것보다 훨씬 빠르고 정확할 수 있습니다.

도구 통합 전략과 MCP

최근 아키텍처는 수많은 도구를 개별적으로 관리하지 않고, LLM 입장에서는 단일 함수 인터페이스만 바라보게 통합하는 전략을 취합니다.
LLM은 오직 표준화된 함수 포맷으로만 인자를 출력하고, 실제 내부에서 MCP서버를 호출하거나 RAG를 수행하는 세부 로직은 애플리케이션 레이어로 캡슐화하는 방식입니다.

MCP 표준 프로토콜을 사용하면 시스템에 수많은 외부 서버가 연동되어 있더라도 LLM은 오직 MCP 가이드라인 프로토콜 레이어만 판정하면 되므로 모델의 연산 부담과 프롬프트 비대화를 극대하게 줄일 수 있습니다.

5. 실전 프롬프트 엔지니어링 및 구현 예시

외부 도구 연동의 핵심은 모델이 참조할 도구 정의, 즉 디스크립션을 극도로 상세하게 작성하는 것과 적절한 퓨샷 예시를 제공하는 것입니다.

5.1. 동적 SQL 추출 프롬프트 설계

아래 구조는 데이터베이스 스캔을 통해 테이블 스키마 정보를 동적으로 프롬프트에 주입하는 구조입니다.

# 시스템 지시문
너는 사용자의 자연어 질의를 분석하여 올바른 SQL 쿼리를 생성하는 전문 번역가다.
사용자 질의와 아래 제공되는 테이블 구조를 참조하여 정확한 ANSI SQL 쿼리만 반환하라.

[제약 조건]
1. 테이블 간의 JOIN 관계를 형성할 때는 반드시 정의된 기본키와 외래키 관계를 가진 컬럼으로만 매핑하라.
2. 사용자 질의 내용이 아래 제공된 테이블 구조와 매칭되지 않거나 유추할 수 없다면, 임의로 쿼리를 조작하지 말고 생성을 중단하라.

# 테이블 정보 (동적 생성 영역)
CREATE TABLE users (
    user_id INT PRIMARY KEY,
    user_name VARCHAR(50)
);
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    user_id INT,
    order_date DATE,
    FOREIGN KEY (user_id) REFERENCES users(user_id)
);

# 퓨샷 예시 
사용자 질의: 홍길동 사용자의 주문 내역을 보여줘
생성 SQL: SELECT o.order_id, o.order_date FROM orders o JOIN users u ON o.user_id = u.user_id WHERE u.user_name = '홍길동';

# 사용자 질의
사용자 질의: 최근 3일 이내에 주문한 사용자들의 이름을 추출해줘

이와 같이 정밀하게 설계된 인스트럭션과 구조화된 디스크립션이 담긴 프롬프트를 사용하면, 온프레미스 환경의 12B 규모의 소형 모델에 4비트 양자화를 적용해 구동하더라도 스키마 왜곡 없이 정확한 쿼리를 출력해 냅니다.
대형 상용 모델이 아니더라도 어텐션 편향을 유도하는 프롬프트 제어만 명확하다면 높은 정확도를 보장할 수 있습니다.

5.2. 함수 연동 제이슨 명세 예시

도구 연동을 전담하는 분산형 프롬프트 구성 시, 사용할 함수의 스펙을 명확한 제이슨 형태로 제공해야 합니다.

{
  "name": "get_current_weather",
  "description": "지정된 대한민국 도시의 현재 기상 정보를 실시간으로 조회합니다. 전 세계 타 국가 지역은 지원하지 않으므로 사용자가 대한민국 외 지역을 요청할 경우 이 함수를 호출해서는 안 됩니다.",
  "parameters": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "대한민국의 시/군/구 단위 도시명 (예: 서울, 여수, 부산)"
      },
      "unit": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "온도 표기 단위"
      }
    },
    "required": ["location"]
  }
}

사용자가 만약 "현재 한국 날씨 어때?"라고 입력했을 때, 프롬프트 내부 문맥상 명시적인 도시 이름이 생략되어 있더라도 모델은 사용자의 컨텍스트를 예를들어 현재 접속 위치 또는 대화 맥락을 암묵적으로 추론하여 location: "서울" 혹은 사용자의 현재 위치로 인자를 판정하여 제이슨 구조를 정확히 채워 반환하게 됩니다.

최종 취합의 중요성 다시 보기

이렇게 개별 함수 프롬프트를 통해 추출된 실행 결과물들은 결국 다시 아키텍처 초반의 거대 프롬프트 취합 레이어로 회귀합니다.

각 에이전트 도구가 수집해 온 가공되지 않은 텍스트 데이터를 그대로 쏟아부으면 최종 답변 퀄리티는 다시 무너집니다.

따라서 외부 도구 연동 설계의 최종 종착지는 언제나 '수집된 다수의 도구 결과물들을 어떻게 다시 압축하고 정렬하여 최종 LLM에 전달할 것인가'에 대한 고도화된 컨텍스트 핸들링 체계를 구축하는 것입니다.

궁금하면 500원

레거시를 이해하면서도 새로운 기술을 현실적으로 적용할 수 있는 백엔드 개발자가 되는 것이 목표입니다.

이전 포스트

LLM 시스템 도입의 숨은 복병, 품질 평가와 성능 튜닝에 대한 고민

다음 포스트