LLM 컨텍스트를 속이는 방법: 경량 AI 문서 어시스턴트 아키텍처

Markdown 문서 폴더 전체를 LLM 프롬프트에 집어넣는 것은 쉬워 보이지만, API 청구서를 확인하기 전까지만 그렇습니다. 컨텍스트 (Context)가 커지면 비용도 커지며, 특히 사용자가 반복적이거나 매우 구체적인 질문을 할 때 더욱 그렇습니다.

에지 (Edge)에서 실행되는 프로그래밍 가능한 리다이렉트 및 링크 매핑 플랫폼인 LinkShift.app 프로젝트를 위한 문서 어시스턴트를 구축할 때, 저는 Regex (정규 표현식), Liquid 템플릿, 에지 라우팅 규칙을 다루는 사용자들에게 학습 곡선이 매우 가파를 것이라는 점을 알고 있었습니다. 쉬운 길을 택해 API 예산이 녹아내리는 것을 지켜보는 대신, 저는 다계층 (multi-tier) 방식의 초저비용 AI 에이전트 아키텍처를 설계했습니다.

토큰 팽창 (token bloat) 문제를 해결하고 응답 시간을 매우 빠르게 유지한 방법은 다음과 같습니다.

계층형 아키텍처 개요

모든 개별 쿼리에 대해 전체 채팅 기록과 문서를 거대한 모델에 던지는 대신, 시스템은 세 가지 뚜렷한 단계를 통해 요청을 필터링합니다.

사용자 요청 -> [1. 접수원 (gpt-5.4-nano)] -> 의도 필터링 및 파일 라우팅 (Intent Filtering & File Routing)
                                                                  |
                                                                  v
...

1단계: 스마트 데이터 인제스션 (Smart Data Ingestion, 전처리)

Raw Markdown 파일을 LLM에 동적으로 공급하는 것은 믿을 수 없을 정도로 비효율적입니다.

• 제 문서의 28개 Markdown 파일 모두는 아주 작은 gpt-5.4-nano 모델을 사용하여 사전에 전처리 및 요약 (summarized) 되었습니다.
• OpenAPI/API 레퍼런스의 경우, 메인 스키마를 태그(엔드포인트)별로 분할했습니다. 각 섹션은 자체적으로 고도로 압축된 요약을 갖게 되었습니다.

2단계: "AI 접수원" 가드레일 (The "AI Receptionist" Guardrail)

사용자가 질문을 할 때, 질문은 즉시 더 비싼 메인 LLM에 닿지 않습니다. 첫 번째 방어선은 "접수원" 역할을 하는 gpt-5.4-nano 모델입니다. 이 모델은 두 가지 중요한 작업을 처리합니다:

1. 의도 검증 (Intent Validation): 쿼리가 실제로 LinkShift와 관련이 있는지 확인합니다. 이를 통해 누군가 내 API 예산을 사용하여 컴퓨터 과학 숙제를 하는 일을 방지합니다.
2. 파일 라우팅 (File Routing): 미리 작성된 경량 요약본을 스캔하여 질문에 답하는 데 필요한 정확한 문서 파일들을 찾아냅니다. 안전을 위해 상한선을 10개 파일로 설정했지만, 모델은 보통 매우 관련성이 높은 3~6개만을 동적으로 선택합니다.

그 결과는 어떨까요? 우리는 전체 문서의 아주 일부분만을 다음 단계로 전달합니다.

3단계: 정밀한 생성 및 "저토큰 컨텍스트 해킹 (Low-Token Context Hack)"

이제서야 약간 더 무거운 모델인 gpt-5.4-mini가 등장합니다. 이 모델은 사용자의 쿼리와 접수원(receptionist)에 의해 격리된 특정 파일들만을 입력받아, 환각(hallucination)이 없는 고품질의 답변을 구성합니다.

채팅 기록 해킹 (The Chat History Hack):
전체 채팅 로그를 메모리에 유지하면 컨텍스트 창(context window)이 빠르게 비대해집니다. 이를 우회하기 위해, gpt-5.4-mini가 응답할 때마다 지금까지의 대화에 대한 한 문장짜리 마이크로 요약(micro-summary)을 함께 생성하도록 했습니다. 다음 턴에서는 전체 채팅 기록 대신 오직 이 마이크로 요약만을 주입합니다.

이렇게 하면 컨텍스트를 완벽하게 유지하면서도, 번개처럼 빠른 답변을 제공하고, API 비용을 말 그대로 몇 푼 안 되는 수준으로 낮출 수 있습니다.

과잉 엔지니어링 증후군 (The Over-Engineering Syndrome)

이 모든 설정의 가장 재미있는 점은 무엇일까요? 현재 사용자가 단 한 명도 없음에도 불구하고 (무료든 유료든), 저는 이 아키텍처에 집착하며 프롬프트를 다듬고 엣지 케이스(edge cases)를 스트레스 테스트하는 데 며칠을 보냈다는 것입니다.

이는 전형적인 인디 해커(indie hacker) 또는 소프트웨어 엔지니어의 함정입니다. 단 1달러도 벌기 전에 엄청난 트래픽을 감당할 수 있는 초최적화된, 무한히 확장 가능한 인프라를 구축하는 것이죠.

긍정적인 면을 보자면, 이 시스템은 결함이 없고, 지갑을 털어가는 취약점으로부터 안전하며, 다음에 어떤 일이 닥치더라도 대응할 준비가 되어 있습니다.

직접 테스트해보고 싶거나, 접수원 가드레일(receptionist guardrail)을 깨뜨려보고 싶거나, 혹은 기술적인 질문을 어떻게 처리하는지 보고 싶다면, 여기서 자유롭게 플레이해 보세요: linkshift.app/docs.

여러분의 LLM 프로젝트에서는 컨텍스트 비용 (context costs)을 어떻게 처리하시나요? 이와 유사한 라우팅 시스템을 사용하시나요, 아니면 표준 벡터 데이터베이스 (RAG)를 선호하시나요? 댓글로 의견을 나누어 주세요!