긴 컨텍스트는 왜 기억이 아닐까(3편)

컨텍스트 창은 모델의 장기 기억이 아니라 이번 생성에서 펼쳐놓은 작업대에 가깝습니다. 작업대가 넓으면 더 많은 자료를 올릴 수 있지만, 필요한 문장이 그 위에 있다는 사실만으로 모델이 언제나 정확히 찾아 쓰는 것은 아닙니다. 대화 기록과 RAG, 장기 메모리는 정보를 저장하고 골라서 다시 작업대에 올리는 별도의 과정입니다.

편집자 노트 · B2B 도입 관점 — 「컨텍스트 100만 토큰」은 사내 문서를 전부 넣어두면 된다는 뜻이 아닙니다. 이 편은 파라미터·대화 기록·검색·장기 기억을 나눠 봅니다. 사내 지식을 어떤 방식으로 연결할지, 그 선택이 비용과 권한 설계에 어떻게 걸리는지 판단하실 때 쓰실 수 있습니다.

대화가 이어져 보여도 모델은 매 요청을 새 입력으로 받습니다

채팅 화면에서는 어제부터 이어온 대화를 자연스럽게 스크롤할 수 있습니다. 사용자는 모델이 앞의 대화를 기억한다고 느끼지만, 일반적인 호출에서 모델이 받는 것은 애플리케이션이 이번 요청에 다시 담아 보낸 메시지 묶음입니다.

이전 대화가 요청에 포함되면 모델은 볼 수 있습니다. 너무 오래되어 잘렸거나 요약본만 전달되면 원문은 볼 수 없습니다. 화면에 기록이 남아 있는 것과 현재 모델 입력에 그 기록이 들어 있는 것은 다른 상태입니다.

이 구분은 문제가 생겼을 때 중요합니다. 모델이 앞서 정한 조건을 잊었다고 느껴질 때 먼저 확인할 것은 모델의 기억력이 아니라, 실제 요청 payload에 그 조건이 남아 있는가입니다. 보내지 않은 정보는 긴 컨텍스트를 지원하는 모델도 사용할 수 없습니다.

파라미터와 컨텍스트와 메모리는 서로 다른 자리에 있습니다

LLM 주변에서 기억이라는 말은 여러 대상을 가리킵니다. 구분하지 않으면 “모델이 알고 있다”와 “이번 요청에서 읽었다”가 같은 문장에 섞입니다.

파라미터는 많은 데이터에서 배운 패턴을 담지만 특정 문서의 원본 저장소는 아닙니다. 컨텍스트는 원문을 직접 제공할 수 있지만 정해진 토큰 범위와 한 번의 요청에 묶입니다. 메모리와 검색 저장소는 모델 밖에 있으므로 무엇을 저장하고 언제 꺼낼지 별도 규칙이 필요합니다.

네 영역을 나누면 변경 방법도 분명해집니다. 회사 정책 문서가 바뀔 때 모델을 다시 학습시키기보다 검색 저장소를 갱신하는 편이 빠를 수 있습니다. 사용자가 이번 보고서에만 적용할 형식을 원한다면 장기 메모리보다 현재 프롬프트에 두는 편이 맞습니다.

컨텍스트 길이는 입력과 출력에 함께 쓰는 예산입니다

컨텍스트 길이는 보통 토큰 수로 표시됩니다. 이 예산에는 사용자 질문만 들어가지 않습니다. 시스템 지시, 이전 대화, 첨부 문서, 도구 호출과 결과, 그리고 생성할 답변 공간까지 함께 계산됩니다.

전체 컨텍스트 예산
  = 시스템 지시
  + 대화 기록
  + 검색·첨부 자료
  + 도구 요청과 관측
  + 새로 생성할 답변

문서를 많이 넣으면 모델이 볼 수 있는 정보는 늘지만 답변에 남길 공간이 줄 수 있습니다. 긴 입력을 처리하는 시간과 KV 캐시 메모리도 증가합니다. 모델 구조와 서빙 방식에 따라 증가 폭은 다르지만, 컨텍스트 길이를 무료 저장 공간처럼 취급하기 어려운 이유입니다.

토큰 상한에 닿았을 때 무엇을 자를지도 제품의 결정입니다. 가장 오래된 대화를 기계적으로 제거하면 초기에 합의한 목표가 사라질 수 있습니다. 반대로 모든 대화를 유지하면 중복된 시행착오가 중요한 근거보다 더 많은 자리를 차지할 수 있습니다.

들어 있는 정보와 사용된 정보는 다릅니다

컨텍스트 상한이 충분하면 긴 문서를 통째로 넣을 수 있습니다. 여기서 “입력 가능”과 “안정적으로 활용 가능”을 나눠 봐야 합니다.

Lost in the Middle 연구는 여러 문서 질의응답과 키-값 검색 과제에서 관련 정보의 위치를 바꿔가며 모델 성능을 측정했습니다. 연구 대상 모델들은 관련 정보가 입력의 시작이나 끝에 있을 때보다 긴 문맥의 가운데 있을 때 성능이 크게 낮아지는 경우를 보였습니다. 긴 컨텍스트를 지원한다는 사양만으로 모든 위치의 정보를 같은 수준으로 사용한다고 볼 수 없다는 결과입니다.

이 연구 하나가 모든 최신 모델과 과제의 성능을 대신하지는 않습니다. 다만 컨텍스트 평가에서 길이만 재면 부족하다는 기준은 남깁니다. 필요한 정보의 위치를 바꾸고, 관련 없는 문서를 늘리고, 여러 근거를 함께 연결해야 하는 과제를 별도로 시험해야 합니다.

실무에서는 중요한 지시를 한 번만 긴 문서 가운데 두기보다 명확한 구획과 제목을 붙이고, 질문과 가까운 곳에 핵심 조건을 다시 제공하는 방법을 씁니다. 문서를 줄이는 일이 단순한 비용 절감이 아니라 모델이 주의를 배분할 대상을 정리하는 일이기도 합니다.

RAG는 검색한 결과를 새 문맥으로 넣는 구조입니다

RAG는 Retrieval-Augmented Generation, 검색 증강 생성입니다. 모델 파라미터만으로 답하지 않고 외부 문서에서 관련 구간을 찾은 뒤, 그 내용을 현재 컨텍스트에 넣어 답을 생성합니다.

초기 RAG 연구는 사전학습 모델의 파라미터형 기억과 위키피디아 벡터 인덱스의 비파라미터형 기억을 결합해 지식 집약 과제를 평가했습니다. 핵심은 모델이 모든 사실을 가중치 안에서 꺼내게 하는 대신, 갱신하고 출처를 추적할 수 있는 외부 지식을 함께 사용한다는 데 있었습니다.

현재 일반적인 RAG 흐름을 단순화하면 네 단계입니다.

질문 정리
  → 관련 문서 검색·재정렬
  → 필요한 구간을 컨텍스트에 배치
  → 근거를 사용해 답변 생성

RAG가 모델의 파라미터를 바꾸는 것은 아닙니다. 이번 요청에 참고 자료를 더하는 방식입니다. 그래서 문서를 갱신하면 다음 검색부터 새 내용을 사용할 수 있고, 답과 함께 어느 문서를 사용했는지 남길 수 있습니다.

검색을 붙이면 실패 지점도 네 곳으로 나뉩니다

RAG는 근거를 제공하지만 사실성을 자동 보장하지는 않습니다. 질문을 잘못 해석해 검색어가 빗나갈 수 있고, 적절한 문서가 색인에 없을 수 있습니다. 검색은 맞았지만 필요한 문장이 잘린 구간 밖에 있을 수도 있고, 모델이 받은 근거와 다른 결론을 만들 수도 있습니다.

그래서 최종 답 하나만 평가하면 어디를 고쳐야 할지 알기 어렵습니다.

검색 정확도가 높은데 답이 틀리면 생성 지시나 인용 검증을 봐야 합니다. 정답 문서가 한 번도 들어오지 않았다면 모델을 바꾸기 전에 색인과 검색을 고쳐야 합니다. RAG의 품질은 검색 점수와 답변 점수를 따로 볼 때 비로소 설명됩니다.

장기 메모리는 무엇을 남기지 않을지도 정해야 합니다

대화 메모리는 과거 내용을 저장했다가 다음 요청에 다시 넣는 구조입니다. 사용자 선호, 이미 내린 결정, 완료한 단계처럼 다음 작업에 필요한 작은 상태를 남길 수 있습니다. 대화 전체를 매번 보내는 것보다 토큰을 아낄 수 있습니다.

하지만 요약은 압축인 동시에 삭제입니다. “고객은 짧은 보고서를 선호한다”는 메모리를 남기면서 그 선호가 특정 프로젝트에만 해당했다는 조건을 버릴 수 있습니다. 모델이 만든 추론을 확정된 사실처럼 저장하면 다음 대화에서 잘못된 전제가 더 단단해질 수도 있습니다.

그래서 메모리에는 출처와 범위, 갱신 시점을 함께 두는 편이 안전합니다. 사용자가 직접 말한 선호인지 모델이 추론한 것인지, 한 작업에만 적용되는지 계속 유지할지, 새 정보가 들어오면 덮어쓸지 이력을 남길지 구분합니다.

정보의 수명에 따라 저장 위치를 정하면 구조가 단순해집니다.

이번 답에만 필요        → 현재 프롬프트
한 작업 동안 유지       → 작업 상태
여러 대화에서 재사용     → 검증된 장기 메모리
원문과 최신성이 중요     → 문서 저장소 + RAG
모델 전반의 행동을 변경   → 후속학습

다음 편에서는 컨텍스트 안에서 모델이 답을 만들어가는 과정을 더 자세히 봅니다. 생각을 길게 적는 것이 언제 도움이 되는지, 그럴듯한 추론과 근거 있는 결론을 어떻게 구분할지, 업무마다 평가 방법을 달리해야 하는 이유를 다루겠습니다.

도입을 검토한다면

사내 지식을 모델에 연결하실 때 실무에서 갈리는 지점은 세 가지입니다.

첫째, 길이보다 무엇을 골라 넣었는지가 답을 정합니다. 컨텍스트를 넓히면 더 많은 자료를 올릴 수 있지만, 검색이 엉뚱한 문서를 골라 오면 그 자료가 그대로 근거가 됩니다. 답 품질의 상한은 대체로 검색 품질이 정합니다.

둘째, 권한이 컨텍스트로 새지 않게 설계해야 합니다. 사람마다 볼 수 있는 문서가 다른 조직이라면 검색 단계에서 이미 권한이 적용되어야 합니다. 모델에게 「보여주되 말하지 말라」고 지시하는 방식은 통제가 아닙니다.

셋째, 기억처럼 보이는 것을 기억으로 계약하지 않습니다. 대화 기록, 검색 색인, 장기 메모리는 저장 위치와 보존 기간, 삭제 책임이 각각 다릅니다. 개인정보나 고객 자료가 오가는 업무라면 이 구분이 그대로 보안 요건이 됩니다.

다음 편 → 생각을 길게 쓰면 답이 더 좋아질까 (4편)