좋은 컨텍스트의 설계 원칙

더 많이 넣는 것이 아니라 더 잘 고르는 것

좋은 컨텍스트는 길지 않다. 정확하다.
컨텍스트 엔지니어링의 목표는 모델에게 가능한 모든 정보를 주는 것이 아니다. 현재 작업을 성공시킬 확률을 가장 크게 높이는 정보를, 가장 작은 크기로 제공하는 것이다.

LLM은 입력된 컨텍스트 안에서 다음에 올 말을 예측한다. 따라서 불필요한 정보가 많아지면 모델은 더 똑똑해지는 것이 아니라 더 많은 선택지 사이에서 흔들린다. 관련 없는 과거 대화, 오래된 문서, 모호한 지시, 중복된 규칙은 모두 잡음이 된다. 잡음은 답변을 길게 만들고, 판단을 흐리며, 비용과 지연 시간도 늘린다.

좋은 컨텍스트 설계의 핵심 질문은 단순하다.

• 이 작업을 완료하는 데 꼭 필요한 정보인가?

• 이 정보는 믿을 수 있고 최신인가?

• 모델이 이 정보를 어떻게 사용해야 하는지 분명한가?

• 이 정보를 넣는 비용보다 얻는 이득이 큰가?

이 네 가지 질문에 답할 수 있어야 컨텍스트를 통제할 수 있다.

Minimum Viable Context: 최소 충분 컨텍스트

제품 개발에서 최소 기능 제품을 뜻하는 MVP라는 말이 있다. 컨텍스트에도 비슷한 관점이 필요하다. 여기서는 이를 Minimum Viable Context, 즉 최소 충분 컨텍스트라고 부르자.

최소 충분 컨텍스트란 현재 작업을 성공시키는 데 필요한 최소한의 지시, 사실, 도구, 제약의 묶음이다. 적게 넣자는 뜻이 아니다. 필요한 것은 빠뜨리지 않되, 필요 없는 것은 과감히 빼자는 뜻이다.

예를 들어 고객 지원 답변을 생성하는 작업이라면 모델에게 필요한 것은 다음과 같다.

• 답변의 역할: 고객 지원 담당자처럼 응답한다.

• 현재 문의 내용: 고객이 무엇을 물었는가.

• 관련 정책: 환불, 배송, 계정 처리 규칙.

• 고객 상태: 주문 번호, 결제 여부, 권한상 보여 줄 수 있는 정보.

• 출력 형식: 짧은 안내문, 단계별 절차, 내부 메모 등.

• 금지 사항: 확인되지 않은 보상 약속, 개인정보 노출, 정책 밖의 답변.

반대로 회사의 전체 연혁, 모든 상품 설명, 과거 상담 전체 기록은 대부분의 경우 필요하지 않다. 필요할 때 검색해서 넣으면 된다.

최소 충분 컨텍스트를 만들 때는 먼저 작업을 잘게 나누어야 한다. 하나의 거대한 요청처럼 보이는 일도 실제로는 여러 하위 작업으로 나뉜다. 예를 들어 보고서 작성은 자료 검색, 요약, 비교, 결론 작성, 형식 정리로 나뉜다. 각 단계가 필요한 정보는 다르다. 검색 단계에는 키워드와 필터가 중요하고, 결론 작성 단계에는 비교 기준과 의사결정 목적이 중요하다.

따라서 좋은 설계는 모든 단계에 같은 컨텍스트를 넣지 않는다. 단계마다 필요한 만큼만 넣는다. 이것이 비용을 줄이고 정확도를 높이는 가장 기본적인 방법이다.

후보 정보를 고르는 다섯 가지 기준

실무에서는 컨텍스트에 넣을 후보가 너무 많다. 문서, 데이터베이스, 대화 기록, 사용자 프로필, 도구 결과, 정책 파일, 이전 답변까지 모두 후보가 된다. 이때 감으로 고르면 시스템은 쉽게 흔들린다. 기준이 필요하다.

컨텍스트 후보는 적어도 다섯 가지 기준으로 평가해야 한다.

가장 먼저 볼 것은 관련성이다. 아무리 신뢰도 높은 문서라도 현재 질문과 무관하면 잡음이다. 관련성은 키워드 일치만으로 판단하면 부족하다. 사용자의 의도, 업무 단계, 질문의 범위까지 함께 봐야 한다. 사용자가 가격 비교를 요청했는데 제품 설치 매뉴얼을 넣는 것은 관련성이 낮다. 같은 제품 문서라도 목적이 다르면 가치가 달라진다.

두 번째는 신뢰도다. 공식 정책, 승인된 데이터베이스, 최신 운영 문서는 신뢰도가 높다. 반면 개인 메모, 오래된 채팅, 출처가 불분명한 요약은 낮다. 신뢰도가 낮은 정보를 반드시 써야 한다면 모델에게 그 한계를 알려야 한다. 예를 들어 이 내용은 비공식 메모이며 최종 정책이 아닐 수 있다고 표시해야 한다.

세 번째는 최신성이다. 컨텍스트는 시간이 지나면 부패한다. 특히 가격, 법률, 제품 기능, 내부 정책, 장애 상태는 빠르게 바뀐다. 최신성이 중요한 정보에는 작성일, 갱신일, 유효 기간을 함께 넣어야 한다. 모델은 날짜의 의미를 스스로 보장하지 못한다. 그러므로 어떤 날짜가 기준인지 명시해야 한다.

네 번째는 권한이다. 컨텍스트 엔지니어링은 정보 검색 기술만의 문제가 아니다. 접근 제어의 문제이기도 하다. 모델이 답변할 수 있는 정보는 사용자가 볼 수 있는 정보 안에 있어야 한다. 권한 필터를 거치지 않은 검색 결과를 그대로 넣으면, 모델은 내부 문서나 타인의 개인정보를 자연스럽게 답변에 섞을 수 있다.

다섯 번째는 비용이다. 긴 컨텍스트는 돈과 시간을 쓴다. 더 큰 문제는 긴 컨텍스트가 항상 더 좋은 결과를 만들지 않는다는 점이다. 동일한 사실을 세 번 반복해 넣는 것보다, 가장 믿을 수 있는 한 문장을 명확히 넣는 편이 낫다. 비용 평가는 단순히 토큰 수만 보는 것이 아니라, 정확도 향상에 실제로 기여하는지를 함께 봐야 한다.

신호 대 잡음비를 높이는 방법

컨텍스트의 품질은 신호 대 잡음비로 설명할 수 있다. 신호는 모델이 답을 만드는 데 필요한 정보다. 잡음은 판단을 흐리거나 사용되지 않는 정보다. 좋은 컨텍스트는 신호가 많고 잡음이 적다.

신호 대 잡음비를 높이는 첫 번째 방법은 중복을 줄이는 것이다. 같은 규칙이 여러 표현으로 반복되면 모델은 어느 문장을 더 중요하게 봐야 할지 헷갈릴 수 있다. 중복된 문서는 하나로 합치고, 충돌하는 규칙은 우선순위를 정해야 한다.

두 번째 방법은 정보의 역할을 표시하는 것이다. 단순히 문서를 붙여 넣는 것보다 이 블록은 정책, 이 블록은 사용자 입력, 이 블록은 검색 결과, 이 블록은 출력 규칙이라고 구분해 주는 편이 좋다. 모델은 구조화된 컨텍스트를 더 안정적으로 따른다.

세 번째 방법은 결론보다 근거를 넣는 것이다. 이미 누군가가 만든 요약 결론만 넣으면, 그 결론이 틀렸을 때 모델도 같이 틀린다. 가능하다면 원문에서 필요한 근거 문장, 수치, 조건을 함께 제공해야 한다. 단, 원문 전체를 넣기보다 현재 질문에 필요한 부분만 추출해야 한다.

네 번째 방법은 우선순위를 명시하는 것이다. 모든 정보가 같은 무게로 들어가면 모델은 충돌 상황에서 흔들린다. 예를 들어 내부 정책이 사용자 요청보다 우선한다, 최신 문서가 과거 문서보다 우선한다, 시스템 지시가 예시보다 우선한다는 식으로 기준을 써 두어야 한다.

컨텍스트 피라미드: 안정, 동적, 임시 정보

좋은 컨텍스트는 한 덩어리가 아니다. 수명이 다른 여러 층으로 나뉜다. 이를 컨텍스트 피라미드로 생각하면 설계가 쉬워진다.

가장 아래에는 안정적인 기반 컨텍스트가 있다. 이 층에는 자주 바뀌지 않는 규칙이 들어간다. 예를 들어 시스템의 역할, 말투, 보안 원칙, 답변의 기본 형식, 금지 행동이 여기에 속한다. 기반 컨텍스트는 모든 요청에 반복적으로 사용되므로 짧고 분명해야 한다. 여기에 많은 업무 지식을 넣기 시작하면 전체 시스템이 무거워진다.

중간에는 작업별 동적 컨텍스트가 있다. 사용자의 현재 요청, 검색된 문서, 관련 데이터, 선택된 도구, 고객 상태처럼 요청마다 달라지는 정보다. 실제 성능 차이는 대부분 이 층에서 난다. 검색 품질, 필터링 기준, 압축 방식, 권한 확인이 모두 이 층의 설계 문제다.

가장 위에는 순간적으로 쓰고 버리는 임시 컨텍스트가 있다. 에이전트가 중간 계산을 하거나, 도구 호출 결과를 잠시 비교하거나, 후보 답변을 검토할 때 쓰는 정보다. 이 정보는 다음 요청까지 오래 보존할 필요가 없다. 오히려 계속 남겨 두면 대화 기록을 오염시킨다.

이 세 층을 구분하면 무엇을 저장하고, 무엇을 검색하고, 무엇을 버릴지 결정하기 쉬워진다. 안정 정보는 버전 관리한다. 동적 정보는 요청 시점에 선택한다. 임시 정보는 작업이 끝나면 제거하거나 요약만 남긴다.

많은 실패는 이 층을 섞을 때 발생한다. 임시 판단을 장기 메모리처럼 저장하거나, 오래된 동적 정보를 기반 규칙처럼 계속 쓰거나, 기반 컨텍스트에 너무 많은 예외를 넣으면 시스템은 점점 예측하기 어려워진다.

근거 기반 답변을 위한 출처 설계

모델에게 근거 기반으로 답하라고 말하는 것만으로는 부족하다. 근거를 사용할 수 있는 형태로 넣어야 한다.

가장 간단한 방법은 컨텍스트 안의 자료에 출처 식별자를 붙이는 것이다. 예를 들어 문서 A, 정책 B, 검색 결과 3처럼 각 블록에 고유한 이름을 준다. 더 좋은 방식은 문서 제목, 버전, 작성일, URL 또는 내부 문서 ID를 함께 제공하는 것이다.

출처 식별자는 모델에게 두 가지 이점을 준다. 첫째, 답변을 만들 때 어떤 근거를 사용했는지 추적할 수 있다. 둘째, 서로 충돌하는 정보가 있을 때 비교가 쉬워진다. 예를 들어 2024년 정책과 2026년 정책이 함께 들어왔다면, 최신 정책을 우선하라는 규칙을 적용할 수 있다.

인용 규칙도 명확해야 한다. 답변의 모든 문장에 출처를 붙일 필요는 없지만, 사실 주장, 수치, 정책 판단, 법적·의료적·재무적 조언처럼 민감한 내용에는 근거가 필요하다. 반대로 일반적인 안내 문장이나 사용자의 입력을 되풀이한 문장에는 인용이 필요하지 않을 수 있다.

모르는 경우의 행동 규칙도 함께 넣어야 한다. 좋은 컨텍스트 설계는 모델이 항상 답하도록 몰아붙이지 않는다. 정보가 없을 때는 없다고 말하게 해야 한다. 예를 들어 다음과 같은 규칙이 필요하다.

• 제공된 근거에서 확인되지 않는 사실은 단정하지 않는다.

• 필요한 정보가 없으면 사용자에게 추가 정보를 요청한다.

• 내부 정책이 없으면 일반 원칙과 확인 필요 사항을 구분해 말한다.

• 출처가 충돌하면 최신성, 신뢰도, 권한 기준에 따라 판단하고 충돌 사실을 표시한다.

이 규칙은 모델의 능력을 제한하는 것이 아니라, 신뢰할 수 있는 답변의 범위를 정하는 것이다.

좋은 컨텍스트를 만드는 운영 절차

원칙은 절차로 바뀌어야 한다. 실제 시스템에서는 다음 흐름을 기본값으로 삼을 수 있다.

첫째, 작업을 분류한다. 사용자가 무엇을 원하는지, 답변인지 요약인지 검색인지 도구 실행인지 파악한다. 작업이 달라지면 필요한 컨텍스트도 달라진다.

둘째, 후보 정보를 모은다. 사용자 입력, 관련 대화 기록, 검색 결과, 데이터베이스 조회 결과, 도구 목록, 정책 문서를 후보로 가져온다. 이 단계에서는 넓게 모아도 된다.

셋째, 후보를 평가한다. 관련성, 신뢰도, 최신성, 권한, 비용 기준으로 걸러낸다. 특히 권한 필터는 답변 직전이 아니라 검색 직후에 적용하는 편이 안전하다.

넷째, 컨텍스트를 구성한다. 기반 규칙, 현재 작업, 관련 근거, 도구 사용법, 출력 형식, 금지 사항을 구분해 넣는다. 중요한 정보일수록 명확하고 짧게 쓴다.

다섯째, 답변 후 검증한다. 모델의 답변이 제공된 근거를 벗어나지 않았는지, 출처가 맞는지, 민감한 정보가 새지 않았는지 확인한다. 필요한 경우 답변을 다시 생성하거나 사용자에게 확인 질문을 한다.

이 절차를 자동화하면 컨텍스트는 우연이 아니라 시스템의 일부가 된다. 프롬프트 한 문장을 잘 쓰는 수준을 넘어, 입력 정보의 흐름을 설계하는 단계로 이동한다.

설계 체크리스트

좋은 컨텍스트인지 빠르게 점검하려면 다음 질문을 사용하면 된다.

• 현재 작업의 목표가 한 문장으로 분명한가?

• 모델이 따라야 할 역할과 제약이 짧게 정리되어 있는가?

• 포함된 정보가 실제 답변에 쓰일 가능성이 높은가?

• 오래되었거나 출처가 불분명한 정보가 섞여 있지 않은가?

• 사용자가 볼 수 없는 정보가 들어가지 않았는가?

• 같은 내용이 반복되거나 서로 충돌하지 않는가?

• 출처 식별자와 인용 규칙이 있는가?

• 정보가 부족할 때의 행동이 정의되어 있는가?

• 작업이 끝난 뒤 버릴 정보와 저장할 정보가 구분되어 있는가?

이 질문에 모두 답할 수 있다면 컨텍스트는 이미 상당히 안정적이다.

컨텍스트 엔지니어링의 실력은 많이 넣는 능력이 아니라, 빼도 되는 것을 아는 능력에서 드러난다. 모델은 우리가 넣은 정보 안에서 움직인다. 그러므로 좋은 시스템은 모델을 압도하지 않는다. 필요한 방향으로 안내한다. 최소한의 고품질 컨텍스트가 모델의 답변을 더 정확하고, 빠르고, 안전하게 만든다.