좋은 Context Packet은 어떻게 설계해야 할까

RAG를 공부하다 보면 retrieval 성능을 끌어올리는 데 집중하기 쉽다. 하지만 정작 LLM에 들어가는 것은 검색 결과 자체가 아니라, 그 결과를 어떤 구조로 묶어 넣은 context다.

이번 글에서는 Context Packet을 LLM이 문제를 풀기 위해 필요한 정보를 구조적으로 압축한 입력으로 보고, 좋은 packet이 어떤 조건을 만족해야 하는지를 고민하며 설계한 내용을 정리해보았다.

RAG의 한계

기본적인 RAG 파이프라인은 대략 다음과 같다.

query -> vector search -> top-k chunks -> concat -> LLM

이 구조는 간단하고 강력하지만, 검색된 chunk를 그대로 이어 붙이는 방식에는 몇 가지 한계가 있다.

• 정보는 많지만 구조가 없다
• 중요도 구분이 없다
• reasoning 순서가 없다
• 중복이 많아질 수 있다
• LLM이 무엇을 먼저 봐야 하는지 알기 어렵다

여기서 생기는 문제는 retrieval recall을 prompt quality와 동일시하기 쉽다는 점이다. 관련 문서를 많이 찾았다고 해서 모델이 그 정보를 잘 쓰는 것은 아니다.

관련해서 내가 참고한 방향은 세 가지였다.

이런 관점들이 Context Packet 설계로 이어진다. 중요한 내용을 아무 위치에나 많이 넣는 대신, 모델이 실제로 쓸 수 있는 위치와 구조로 직렬화하자는 방향이다. retrieval 결과가 모호하다면 그 상태를 숨기지 말고 packet 안에서 드러내야 한다.

Context Packet이란

내가 이해한 Context Packet은 다음에 가깝다.

LLM이 문제를 정확하게 풀기 위해 필요한 정보만 구조적으로 압축한 입력

Context Packet은 "LLM에게 무엇을 줄 것인가"보다 "LLM이 그것을 어떻게 읽고 사용할 것인가"에 초점을 둔다.

단순 RAG prompt와 비교하면 차이가 더 분명해진다.

좋은 packet은 에이전트가 알고 있는 것, 모르는 것, 불확실한 것을 함께 전달해야 한다. 그래야 LLM이 자신 있게 답할 수 있는 경우와 모호성을 드러내야 하는 경우를 구분할 수 있다.

관련 개념

RAG

RAG는 LLM의 parametric memory만으로는 최신성, 근거성, 정밀한 지식 접근에 한계가 있다는 문제에서 출발한다. Retriever는 외부 지식을 가져오는 non-parametric memory 역할을 한다.

다만 retrieval 자체가 필요하다는 말과, 검색 결과를 그대로 넣으면 된다는 말은 다르다. Context Packet은 retrieval 이후의 문제, 즉 어떻게 넣을 것인가를 다룬다.

Context Engineering

Prompt만 잘 써서는 충분하지 않은 경우가 많다. 모델에 들어가는 context의 품질, 밀도, 순서가 응답 품질을 크게 좌우하기 때문이다.

특히 코드 분석이나 기술 문서처럼 정보 간 관계가 중요한 문제라면 context를 단순 텍스트 묶음으로 보면 안 된다. 어느 파일이 근거인지, 어떤 관계를 따라가야 하는지, 어느 부분이 불확실한지를 구조로 드러내야 한다.

ReAct와 Toolformer

ReAct는 reasoning과 acting을 번갈아 수행하면서, 모델이 외부 정보와 상호작용하는 동안 reasoning trace를 갱신하도록 만든다.

Toolformer는 모델이 언제 어떤 API를 호출할지 학습한다는 관점에서, 외부 도구 사용을 언어 모델 능력의 일부로 본다.

같은 관점에서 보면 Context Packet은 LLM에게 전달되는 중간 작업 메모리에 가깝다. 단순 결과물이 아니라, 모델이 다음 reasoning을 이어가도록 정리된 snapshot이다.

왜 구조화가 필요한가

긴 context를 넣는다고 성능이 항상 좋아지지는 않는다. "Lost in the Middle"이 보여준 것처럼, 긴 문맥에서는 앞과 뒤의 정보가 상대적으로 잘 활용되고 중간 정보는 묻히기 쉽다.

그래서 packet에서는 다음을 신경 써야 한다.

• 중요한 정보를 앞쪽이나 명확한 위치에 둔다
• 중복된 근거를 줄인다
• 같은 역할의 정보를 같은 형식으로 정렬한다
• 불확실한 내용은 별도 필드로 분리한다

Context Packet의 네 가지 설계 문제

1. 정보 선택

모든 정보를 넣는 게 아니라, 답을 내는 데 필요한 최소 정보만 넣어야 한다.

실패 패턴은 대체로 비슷하다.

• 관련 없는 파일이 포함됨
• graph 범위가 너무 넓어짐
• noise가 늘어남
• 핵심 근거가 top-k 안에 있어도 packet에서는 흐려짐

selection은 retrieval과 다르다. Retrieval은 후보를 가져오는 단계이고, packet selection은 LLM에게 실제로 넘길 입력을 확정하는 단계다.

2. 정보 압축

긴 context는 비용과 품질 저하를 동시에 일으킨다. Prompt compression 기법들이 다루는 문제도 여기와 맞닿아 있다.

기본 방향은 단순하다.

1. 모든 문서를 다 넣지 않는다
2. 덜 중요한 부분을 잘라낸다
3. 핵심 정보 밀도를 높인다
4. token budget 안에서 answerability를 유지한다

중요한 건 짧게 만드는 일이 아니라, 답변 가능성을 유지하면서 noise를 줄이는 일이다.

3. 정보 정렬

같은 정보라도 어떤 순서로 보여주느냐에 따라 모델이 읽는 방식이 달라진다.

예를 들어 코드 분석이라면 "질문과 직접 연결된 파일 -> 호출 경로 -> 주변 근거 -> 불확실한 후보"처럼 읽는 순서를 만들어줄 수 있다. 그러면 모델이 처음부터 모든 정보를 같은 중요도로 훑지 않아도 된다.

4. Reasoning scaffold

Context Packet은 단순 자료 묶음이 아니라, 모델이 어떤 방식으로 생각해야 하는지 힌트를 줄 수 있다.

예를 들면 다음 필드를 둘 수 있다.

• query_intent: 질문의 유형
• evidence: 직접 근거
• related_paths: 따라가야 할 관계
• uncertainty: 불확실한 지점
• suggested_steps: 먼저 확인할 순서

이런 구조가 있으면 LLM은 "관련 정보가 여기 있다"를 넘어, "이 순서로 확인하면 된다"에 가까운 입력을 받는다.

적용 시나리오 — 코드 분석 시스템

지금까지 정리한 네 가지 설계 문제(selection / compression / ordering / reasoning scaffold)를 좀 더 손에 잡히게 그려보기 위해, 한 가지 시나리오를 가정해본다. 자연어로 들어온 코드 관련 질문에 대해 관련 파일과 호출 경로를 찾아 LLM이 분석 결과를 내놓는 코드 분석 시스템이다.

이런 시스템에서는 retrieval 결과를 바로 analyzer에 넘기는 대신, 한 단계 끼워서 Context Packet으로 정돈한 뒤 넘기는 흐름이 자연스럽다.

query -> retrieve -> structure/pack -> analyze

여기서 Retriever는 자료를 찾고, Context Packet은 그 자료를 문제를 풀 수 있는 형태로 재구성한다.

구체적으로는 다음 처리를 packet 계층에 둔다.

1. Selection: 질문에 필요한 symbol, file, path만 남긴다
2. Compression: token budget 안에 들어오도록 중복과 noise를 줄인다
3. Ordering: 중요한 요약과 근거를 모델이 잘 읽는 위치에 둔다
4. Reasoning scaffold: evidence, limitation, output contract를 분리한다

코드 레벨에서의 설계 원칙

위 네 가지를 실제 Pydantic 모델로 옮기면서 잡았던 원칙들을 정리하면 다음과 같다.

최종 ContextPacket 구조

지금까지의 원칙을 하나의 모델로 모으면 다음과 같다. 필드 순서 자체가 설계 의도이며, output_contract를 첫 필드에 두고 summary와 evidence를 각각 앞쪽과 뒤쪽에 배치해 Lost in the Middle을 피한다.

class ContextPacket(BaseModel):
    """LLM 입력 직전의 정제된 컨텍스트"""

    output_contract: PacketOutputContract  # 출력 계약을 가장 먼저 선언
    packet_version: str = "v1"
    query: PacketQuery
    scope: PacketScope
    summary: PacketSummary                 # 앞쪽 배치 (U-shape)
    candidates: PacketCandidates
    paths: list[GraphPath] = Field(default_factory=list)
    evidence: list[EvidenceItem] = Field(default_factory=list)  # 끝쪽 배치 (U-shape)
    impact_nodes: list[ImpactNode] = Field(default_factory=list)
    metadata: PacketMetadata

명확한 query, 제한된 scope, 핵심 path, 증거 기반, 출력 형식 강제 - 이 다섯 가지를 한 모델 안에 모아두면 같은 retrieval 결과에서도 deterministic한 답변을 받기가 쉬워진다.

Packet 직렬화

Context Packet은 내부적으로는 Pydantic 모델이나 typed object일 수 있지만, LLM에 들어갈 때는 결국 문자열로 직렬화된다.

이때는 JSON 또는 XML-style tag를 쓸 수 있다.

<context_packet>
  <query_intent>impact_analysis</query_intent>
  <primary_evidence>
    ...
  </primary_evidence>
  <uncertainty>
    ...
  </uncertainty>
</context_packet>

JSON은 시스템 내부 처리와 검증에 좋고, XML-style tag는 prompt 안에서 instruction, context, input을 구분하는 데 유리하다. 어느 쪽이든 중요한 건 모델이 각 정보의 역할을 혼동하지 않도록 만드는 일이다.

에이전트 UX 원칙과의 대응

Context Packet의 각 필드는 임의로 추가된 게 아니라, 에이전트 시스템이 사용자에게 신뢰를 주기 위해 지켜야 할 UX 원칙과 1:1로 대응시킬 수 있다.

정리

Context Packet을 설계한다는 건 retrieval 결과를 단순히 예쁘게 포장하는 일이 아니라, 검색된 정보 중 무엇을 실제 분석 입력으로 삼을지 정하고, LLM이 읽기 쉬운 순서와 밀도로 다시 짜는 일이다.

이러한 설계를 도출하며 얻은 인사이트는 다음과 같다.

1. retrieval recall과 prompt quality는 다르다
2. top-k chunk는 후보이고, packet은 최종 분석 입력이다
3. 좋은 packet은 selection, compression, ordering, reasoning scaffold를 함께 다룬다
4. 불확실성을 숨기지 않고 구조로 드러내는 것이 에이전트 신뢰성에 중요하다

여기서 정리한 Context Packet의 스키마는 초기 설계 버전으로, 현재는 시스템에 녹이면서 더 정교화되고 달라진 부분이 꽤 있다. packet 필드 구성, trimming 정책 등을 적용해보며 공부한 내용은 별도 포스트에서 이어서 다뤄볼 예정이다.