prompt와 context window
오늘의 질문
지금까지 LLM이 다음 token을 어떻게 예측하고 고르는지를 다뤘다. 그런데 정작 실무에서 가장 자주 부딪히는 질문은 이거다.
질문을 어떻게 쓰느냐가 정말 답변 품질에 그렇게 큰 영향을 주나요? 그리고 대화가 길어지면 왜 갑자기 앞의 내용을 잊어버린 것처럼 굴죠?
이 두 가지는 사실 같은 뿌리에서 나온다. 모델이 답을 만들 때 실제로 “보는” 것이 무엇인지, 그리고 그걸 담는 그릇의 크기가 정해져 있다는 것을 알면 둘 다 설명된다.
먼저 답하기
한 문장으로 줄이면 이렇다.
모델은 사람과 대화하는 게 아니라, prompt라는 텍스트 뭉치를 매번 통째로 받아서 그 안에 있는 내용만 근거로 답을 만든다. 그리고 이 텍스트 뭉치가 들어갈 수 있는 공간(context window)에는 한계가 있다.
여기서 중요한 건 모델에게 “기억”이라는 게 따로 없다는 점이다. 여러 번 대화를 주고받는 것처럼 느껴지지만, 실제로는 매 순간 “지금까지의 대화 전체 + 이번 질문”을 하나의 텍스트로 다시 조립해서 모델에 통째로 넣어주는 것에 가깝다. 그러니 질문을 어떻게 쓰느냐가 답을 바꾸는 것도 당연하고, 대화가 이 공간의 한계를 넘으면 앞부분이 밀려나는 것도 당연하다.
주제에 맞는 핵심 설명
이 다이어그램에서 중요한 건 오른쪽이 아니라 가운데다. system prompt와 user prompt가 두 개의 다른 물건처럼 보이지만, 결국 둘 다 하나의 context window라는 공간 안에 함께 들어간다. 모델은 이 공간 전체를 근거로 삼아 응답을 만든다.
개념: prompt, system prompt, instruction, context window
prompt란 모델에게 전달되는 입력 텍스트 전체를 말한다. 사람이 흔히 “질문”이라고 부르는 것도 prompt의 일부지만, prompt에는 그 외에도 여러 가지가 함께 들어갈 수 있다.
system prompt란 모델의 역할, 말투, 지켜야 할 규칙 같은 걸 미리 정해두는 지침을 말한다. 사용자가 매번 “너는 친절한 상담사야”라고 설명하지 않아도 되도록, 대화가 시작되기 전에 미리 깔아두는 배경 설정이라고 생각하면 된다.
instruction이란 모델의 행동을 지시하는 문장을 말한다. system prompt 안에 담긴 지침도 instruction이고, 사용자가 질문 안에 “표로 정리해줘” 같은 요청을 넣는 것도 instruction이다.
이 부분에서 실제 업계 용어와 이 글의 용어 사이에 차이가 있다는 점을 짚어야 한다. OpenAI의 텍스트 생성 문서를 보면, 이런 지침을 전달하는 방법으로 instructions라는 별도의 파라미터를 두고 있으며, 이 문서는 이 파라미터가 모델이 응답을 생성하는 동안 지켜야 할 어조, 목표, 올바른 응답의 예시 같은 상위 수준의 지침을 제공하고, 이렇게 전달된 지침은 일반 입력(prompt)보다 우선적으로 적용된다고 설명한다. 또한 이 문서는 메시지에 역할(role)을 부여하는 방식도 함께 다루는데, 개발자가 미리 정해두는 지침에 해당하는 역할(developer)이 사용자의 메시지(user)보다 우선순위가 높다고 명시한다. 이 문서는 이 관계를 프로그래밍 언어의 함수와 인자에 비유한다. 개발자가 미리 정한 지침이 함수의 정의라면, 사용자의 메시지는 그 함수에 넘겨주는 인자에 해당한다는 것이다. 이 글에서 쓰는 “system prompt”라는 용어는 이 문서가 말하는 개발자 수준의 지침과 같은 역할을 가리키되, 특정 API의 파라미터 이름이 아니라 일반적인 개념으로 사용하고 있다는 점을 밝혀둔다.
context window란 모델이 한 번의 응답을 만들기 위해 참고할 수 있는 전체 텍스트의 한도를 말한다. system prompt, 지금까지의 대화 기록, 이번 질문까지 전부 이 한도 안에 들어가야 모델이 참고할 수 있다. 이 한도를 넘는 내용은 아예 모델에 전달되지 않거나, 오래된 부분부터 제외되는 방식으로 처리된다.
전후 예시: 나쁜 질문과 개선한 질문
아래 표는 같은 목적을 가진 질문을 두 가지 방식으로 써본 예시다. 실제 모델에 넣어서 나온 결과를 비교한 것이 아니라, 어떤 요소가 빠지면 모델이 무엇을 스스로 추측해야 하는지를 보여주기 위한 예시라는 점을 밝혀둔다.
| 항목 | 나쁜 질문 | 개선한 질문 |
|---|---|---|
| 예시 문장 | “이거 요약해줘” | “아래 회의록을 팀장님께 보고할 3줄 요약으로 정리해줘. 결정 사항과 다음 액션만 남기고 나머지는 빼줘.” |
| 대상(누가 읽는지) | 명시 없음 | 팀장님 |
| 형식 | 명시 없음 | 3줄 |
| 남길 것/뺄 것 | 명시 없음 | 결정 사항과 다음 액션만 |
| 모델이 채워야 하는 빈칸 | 요약의 길이, 대상, 톤, 무엇을 남길지 전부 | 거의 없음 |
나쁜 질문이 “틀린” 질문은 아니다. 다만 빈칸이 많을수록 모델이 그 빈칸을 스스로 추측해서 채워야 하고, 그 추측이 사용자가 원하던 것과 다를 가능성이 커진다. 개선한 질문은 새로운 정보를 추가한 게 아니라, 모델이 원래 추측해야 했던 것들을 사용자가 미리 채워준 것뿐이다.
제약: context window에는 한계가 있다
context window는 무한하지 않다. 그리고 이 한계는 실무에서 두 가지 방식으로 부딪힌다.
첫째, 대화가 길어지면 오래된 내용이 밀려날 수 있다. system prompt, 이전 대화 전체, 이번 질문을 모두 합친 길이가 한도를 넘으면, 어딘가는 잘려나가야 한다. 보통 가장 오래된 부분부터 제외되는 경우가 많다. 그래서 대화 초반에 설정해둔 맥락을 대화가 한참 진행된 뒤에도 모델이 “기억”할 거라고 기대하면 안 된다.
둘째, system prompt 수준의 지침이 항상 자동으로 유지되는 것은 아니다. 앞서 인용한 OpenAI 문서는 이 지점을 구체적으로 짚는데, 이전 대화 상태를 이어서 사용하는 방식으로 대화를 이어갈 경우, 이전 턴에서 사용했던 지침(instructions)이 이후 요청의 context에 자동으로 포함되지 않는다고 명시한다. 즉 “한 번 지침을 줬으니 계속 유지되겠지”라고 가정하면 안 되는 경우가 실제로 있다는 뜻이다. 이 부분의 정확한 동작은 어떤 방식으로 대화 상태를 관리하느냐에 따라 달라질 수 있으므로, 실무에서 중요한 지침이라면 매번 명시적으로 포함되는지를 직접 확인하는 것이 안전하다.
이 두 제약을 합치면 실무 원칙이 하나 나온다. 중요한 지침이나 맥락은 “예전에 말했으니 알아서 기억하겠지”가 아니라, 필요할 때마다 다시 명시적으로 포함시키는 방식으로 다루는 것이 안전하다.
자주 묻는 질문
system prompt와 user prompt 중 뭐가 더 중요한가요? 둘 다 필요하지만 역할이 다르다. 앞서 인용한 OpenAI 문서에 따르면 개발자 수준의 지침(system prompt에 해당)이 사용자 메시지보다 우선순위가 높게 처리된다. 즉 둘이 상충하는 지시를 담고 있다면 system prompt 쪽이 더 강하게 반영되는 구조다. 그렇다고 user prompt가 덜 중요한 것은 아니고, 실제로 무엇을 할지 구체적으로 정하는 건 user prompt 쪽인 경우가 많다.
context window가 꽉 차면 어떤 일이 벌어지나요? 정확한 처리 방식은 서비스나 구현에 따라 다르지만, 공통적으로는 새로운 내용을 넣을 자리를 만들기 위해 무언가를 빼야 한다. 가장 흔한 방식은 오래된 대화부터 제외하는 것이다. 이때 초반에 설정해둔 중요한 맥락이 함께 밀려날 수 있으므로, 긴 대화를 이어가는 서비스를 설계한다면 중요한 지침을 주기적으로 다시 넣어주는 장치를 고려하는 것이 좋다.
프롬프트를 길게 쓸수록 더 좋은 답이 나오나요? 꼭 그렇지는 않다. 위 표에서 봤듯 중요한 건 길이가 아니라 모델이 추측해야 할 빈칸을 얼마나 줄여주느냐다. 불필요한 내용으로 늘어난 프롬프트는 오히려 context window의 한정된 공간만 차지하고, 정작 중요한 지침이 다른 내용에 묻혀 덜 두드러지게 만들 수 있다. 실무에서는 “길게”보다 “구체적으로”가 더 정확한 방향이다.