프롬프트와 컨텍스트 — 창은 넓어졌지만 공짜는 아니다

한 줄 요약

컨텍스트 창은 모델이 한 번에 볼 수 있는 토큰의 상한이며, 넣을 수 있다는 것과 넣는 편이 낫다는 것은 전혀 다른 이야기다.

왜 이게 필요했나

문맥 길이가 늘어나면서 "전부 다 넣으면 되지 않나"는 생각이 자연스러워졌다. 실제로는 세 가지 비용이 따라온다.

돈. 입력 토큰에도 요금이 붙는다. 매 요청마다 문서 전체를 넣으면 그 비용이 요청 수만큼 곱해진다.

지연. 입력이 길수록 첫 토큰까지의 시간이 늘어난다. 어텐션 계산이 길이에 대해 선형보다 빠르게 증가하기 때문이다.

품질. 이것이 가장 반직관적이다. 관련 없는 내용을 많이 넣을수록 정답을 찾는 능력이 떨어진다. 긴 문맥에서 중간에 놓인 정보가 특히 잘 무시된다는 관찰이 여러 차례 보고되었다. 그래서 정답이 들어 있기만 하면 된다는 가정은 위험하다. 어디에 어떻게 놓였는지가 중요하다.

어떻게 동작하나

프롬프트 설계의 실용적인 원칙 몇 가지를 정리한다.

역할과 지시를 앞에, 데이터를 뒤에. 모델은 지시를 먼저 읽고 그 틀로 이후 내용을 해석한다. 데이터를 먼저 쏟아붓고 마지막에 지시를 붙이면 앞부분이 방향 없이 읽힌다.

출력 형식을 예시로 보여 준다. "JSON 으로 답하라"는 말보다 실제 JSON 예시 하나가 훨씬 강하다. 다만 예시는 토큰을 먹으므로 개수와 길이의 균형이 필요하다.

단계를 나누게 한다. 복잡한 추론에서 중간 과정을 쓰게 하면 정확도가 오른다. 다만 모든 질문에 이 방식을 강제하면 토큰과 지연이 늘고 단순한 질문에서는 오히려 헷갈리는 답이 나오기도 한다.

컨텍스트에 우선순위를 준다. 검색으로 가져온 문서를 그대로 이어 붙이는 대신, 점수가 높은 것을 앞뒤 끝에 배치하는 전략이 흔히 쓰인다. 중간이 약하다는 관찰을 역이용하는 것이다.

시스템 프롬프트는 계약서다. 거기에 적힌 제약이 지켜지지 않는다면 대개 두 가지 중 하나다. 제약이 모호하거나(예: "간결하게"), 뒤에 오는 데이터가 그 제약과 충돌한다. 특히 사용자가 넣은 텍스트 안에 지시문처럼 보이는 문장이 있으면 모델이 그것을 따르려 할 수 있다. 외부에서 들어온 내용은 데이터이지 지시가 아니라는 경계를 프롬프트 구조와 애플리케이션 양쪽에서 지켜야 한다.

현장에서 만나는 모습

컨텍스트 예산을 명시적으로 관리하는 것이 좋다. 전체 창이 얼마이고, 시스템 프롬프트가 몇 토큰이고, 검색 결과에 몇 토큰을 배정하고, 출력에 몇 토큰을 남길지 숫자로 정해 둔다. 그러지 않으면 사용자가 긴 문서를 붙여 넣은 날 출력이 잘려 나가는 사고가 난다.

그리고 프롬프트를 코드처럼 버전 관리해야 한다. 한 줄을 고쳤을 때 어떤 케이스가 좋아지고 어떤 케이스가 나빠지는지 평가 없이 판단할 수 없다. 평가 집합 없는 프롬프트 수정은 그냥 도박이다.

이어지는 퀴즈에서 확인할 것

컨텍스트를 늘리는 것이 왜 항상 이득이 아닌지, 프롬프트의 구조가 결과를 어떻게 바꾸는지 설명할 수 있는지 확인한다.