컨텍스트 윈도우와 작업 기억 이해하기

같은 모델인데도 어떤 날은 놀랄 만큼 똑똑하고, 어떤 날은 이상할 만큼 둔해 보일 때가 있다. 많은 사람은 이 차이를 모델의 지능 차이로만 설명하려 한다. 하지만 실무에서는 그보다 더 자주, 모델이 지금 눈앞에 무엇을 보고 있느냐가 결과를 갈라놓는다.

바로 여기서 컨텍스트 윈도우를 이해해야 한다. 컨텍스트 윈도우는 AI가 한 번의 추론에서 읽고 붙잡고 참고할 수 있는 작업 공간이다. 이 공간은 크기가 제한되어 있고, 그 안에 들어온 정보들은 서로 경쟁한다. 그래서 핵심은 많이 넣는 일이 아니라, 지금 필요한 것을 구조 있게 넣는 일이다.

이 장에서는 컨텍스트 윈도우를 단순한 "입력 길이 제한"이 아니라, 제한된 작업 기억으로 이해해 보려 한다. 이 관점을 잡고 나면 왜 긴 프롬프트가 늘 좋은 것이 아닌지, 왜 과한 문서 첨부가 오히려 성능을 망칠 수 있는지, 왜 요약과 선택과 분리가 중요한지가 한꺼번에 납득되기 시작한다.

컨텍스트 윈도우는 AI의 작업 책상이다

컨텍스트 윈도우를 가장 쉽게 이해하는 방법은 책상에 비유하는 것이다. 사람도 일을 할 때 머릿속에 모든 정보를 동시에 넣고 처리하지 않는다. 지금 필요한 메모를 펼치고, 이전 결정을 적어 둔 문서를 옆에 놓고, 규칙이 적힌 체크리스트를 확인하면서 일한다. AI도 비슷하다. 다만 그 책상은 무한히 넓지 않다.

이 책상 위에는 여러 종류의 정보가 함께 올라온다. 시스템 지시문은 행동 기준이 되고, 사용자 메시지는 현재 목표가 되며, 이전 대화는 배경 맥락이 되고, 검색 결과나 첨부 문서는 근거 자료가 된다. 도구 설명과 도구 실행 결과도 여기에 포함된다. 문제는 이 재료들이 모두 같은 크기로, 같은 중요도로, 같은 방식으로 읽히지 않는다는 점이다.

책상이 좁은데 서류를 마구 쌓아 올리면 어떤 일이 생길까. 중요한 메모가 다른 종이 아래에 깔린다. 방금 봐야 할 문서보다 덜 중요한 자료가 눈앞을 차지한다. 서로 다른 지시가 한 자리에 뒤섞여 판단이 흐려진다. AI의 컨텍스트 윈도우도 바로 이런 식으로 망가진다.

그래서 컨텍스트 윈도우를 이해한다는 것은 단순히 "이 모델은 몇 토큰까지 되나?"를 아는 일이 아니다. 이 제한된 공간 안에서 어떤 정보가 중심이 되고, 어떤 정보가 방해가 되는지 아는 일이다.

토큰은 글자 수가 아니라 처리 단위다

컨텍스트 윈도우를 말할 때 빠지지 않는 단어가 토큰이다. 토큰은 AI가 텍스트를 읽을 때 사용하는 잘게 나뉜 처리 단위라고 생각하면 된다. 사람은 문장이나 단어 덩어리로 읽는 느낌이 강하지만, 모델은 내부적으로 입력을 더 작은 조각들로 나누어 다룬다.

여기서 중요한 점은 토큰이 우리가 평소 생각하는 글자 수나 단어 수와 정확히 같지 않다는 것이다. 짧아 보이는 문장도 토큰으로는 꽤 길 수 있고, 표나 코드, JSON, 로그처럼 구조가 복잡한 텍스트는 생각보다 많은 공간을 차지한다. 특히 코드 에러 로그나 반복되는 대화 기록은 보기보다 컨텍스트를 빠르게 잡아먹는다.

실무에서 자주 생기는 착각이 있다. "문서 몇 개 안 넣었는데 왜 이렇게 답이 흔들리지?" 문서 개수가 적어도 각 문서가 장황하거나, 표와 숫자와 부연 설명이 많거나, 중복 문장이 길게 반복되면 실제 작업 공간은 금방 포화된다. 반대로 문서가 여러 개라도 핵심만 잘 정리되어 있으면 훨씬 안정적으로 작동한다.

즉, 컨텍스트 윈도우를 관리한다는 것은 텍스트의 겉모양이 아니라 실제로 모델이 처리해야 하는 단위의 양과 밀도를 관리하는 일이다.

작업 기억이라는 비유가 왜 중요한가

컨텍스트 윈도우를 작업 기억이라고 부르는 이유는, 이것이 장기 저장소가 아니라 당장 판단을 내리기 위한 임시 공간이기 때문이다. 사람도 장기 기억 속에 많은 사실을 알고 있어도, 복잡한 문제를 풀 때는 눈앞에 정리된 메모가 있어야 실수를 줄인다. AI도 비슷하다. 장기적으로 학습한 일반 지식이 있더라도, 이번 업무에 필요한 최신 규정이나 프로젝트 규칙, 고객 정보는 추론 시점에 다시 제공되어야 한다.

이 비유가 주는 실무적 교훈은 분명하다. 첫째, 모든 것을 한 번에 넣으려 하지 말아야 한다. 작업 기억은 창고가 아니라 책상이다. 둘째, 자주 필요한 정보라도 그때그때 꺼내 쓰기 쉽게 정리되어 있어야 한다. 셋째, 오래 남겨야 할 정보는 작업 기억 안이 아니라 바깥의 저장소에 보관해야 한다.

이 점을 이해하지 못하면 두 가지 극단으로 흐르기 쉽다. 하나는 "기억해야 하니까 다 넣자"는 방식이고, 다른 하나는 "모델이 똑똑하니까 알아서 하겠지"라는 방식이다. 앞의 방식은 책상을 서류 더미로 만들어 버리고, 뒤의 방식은 책상을 텅 비게 만든다. 둘 다 실무에서는 자주 실패한다.

긴 컨텍스트가 늘 좋은 것은 아니다

많은 사람이 큰 컨텍스트 윈도우를 보면 마음이 놓인다. 공간이 넓으니 정보를 많이 넣어도 괜찮다고 생각하기 때문이다. 물론 더 큰 공간은 분명 이점이 있다. 긴 문서를 통째로 읽히거나, 긴 대화의 흐름을 한 번에 유지하거나, 복잡한 작업에서 더 많은 단서를 제공할 수 있다.

하지만 공간이 넓다고 해서 아무렇게나 채워도 된다는 뜻은 아니다. 회의실이 넓다고 모든 사람을 다 불러 놓으면 회의가 좋아지지 않는 것과 같다. 오히려 발언은 산만해지고, 핵심 의사결정은 늦어지며, 누가 무엇을 우선해야 하는지도 흐려진다.

AI도 비슷하다. 긴 컨텍스트는 편의가 아니라 관리 책임을 함께 늘린다. 모델 앞에 자료가 많아질수록, 그 자료들 사이의 관련성·우선순위·형식 차이·최신성 문제도 같이 커진다. 다시 말해 큰 창고가 생겼다고 정리가 쉬워지는 것이 아니라, 정리 능력의 중요성이 더 커지는 셈이다.

그래서 실무에서는 "얼마나 많이 넣을 수 있나?"보다 "무엇을 넣을 때 성능이 올라가나?"를 먼저 물어야 한다.

모델은 모든 정보를 똑같이 다루지 않는다

이쯤에서 아주 중요한 사실을 짚고 넘어가자. 컨텍스트 안에 들어갔다고 해서 모든 정보가 똑같이 잘 읽히는 것은 아니다. 모델은 주어진 입력 전체를 기계적으로 복사해 보관하는 존재가 아니다. 추론 과정에서 어떤 정보에 더 주의를 기울이고, 어떤 정보는 상대적으로 약하게 반영한다.

사람도 마찬가지다. 책상 위에 문서 열 장이 있어도 모두를 같은 깊이로 읽지 않는다. 제목이 선명한 메모, 지금 과제와 직접 연결된 자료, 방금 본 정보, 형식이 잘 정리된 지침에 더 쉽게 끌린다. 반대로 중복이 많고 길고 애매한 문서는 눈앞에 있어도 실제 판단에는 약하게 작용한다.

AI의 컨텍스트 설계가 어려운 이유도 여기에 있다. 단지 정보를 넣는 것이 아니라, 모델이 어떤 것을 중심 정보로 여기게 만들 것인가를 설계해야 하기 때문이다. 중요 규칙이 긴 잡담 속에 묻혀 있으면 안 되고, 최신 정책이 오래된 예시 아래에 섞여 있으면 안 되며, 핵심 질문이 수많은 부연 설명 속에서 희미해져서도 안 된다.

결국 컨텍스트 엔지니어링은 저장 문제이면서 동시에 주의 집중 설계 문제다.

왜 정보가 많아지면 오히려 성능이 떨어질까

정보를 많이 주면 더 잘할 것 같지만, 실제로는 성능이 떨어지는 경우가 흔하다. 이유는 크게 네 가지로 이해할 수 있다.

• 관련 없는 정보가 주의를 빼앗는다. 지금 필요한 판단과 직접 관계없는 문장들이 많아지면, 모델은 핵심 근거를 더 흐리게 잡는다.

• 중요 규칙이 희석된다. 꼭 지켜야 할 제약이 긴 배경 설명 속에 섞이면, 출력이 형식을 어기거나 금지사항을 놓치기 쉽다.

• 서로 다른 정보가 충돌한다. 오래된 문서와 최신 문서, 일반 원칙과 예외 규정, 사용자 요구와 시스템 규칙이 한데 섞이면 판단이 흔들린다.

• 형식이 지저분하면 읽기 비용이 커진다. 장황한 로그, 중복된 대화, 정리되지 않은 표는 공간만 차지하는 것이 아니라 이해 부담도 키운다.

이 네 가지는 모두 같은 결론으로 이어진다. 컨텍스트의 문제는 양의 문제가 아니라 배치의 문제, 구조의 문제, 우선순위의 문제라는 것이다.

맥락 손실은 어떻게 일어나는가

컨텍스트 윈도우의 한계를 이해하려면 맥락 손실을 봐야 한다. 맥락 손실은 단순히 일부 정보가 잘려 나가는 상황만 뜻하지 않는다. 정보가 남아 있어도 실제로 판단에 제대로 반영되지 않는 상태까지 포함한다.

가장 단순한 경우는 길이 초과다. 입력이 너무 길면 앞부분 일부가 잘리거나, 필요한 자료를 다 실을 수 없게 된다. 하지만 더 흔한 문제는 그보다 미묘하다. 예를 들어 핵심 규칙이 초반에 있었는데 뒤쪽에 수많은 예시와 대화가 붙으면서 중요도가 약해질 수 있다. 또는 긴 문서를 통째로 넣었지만 사용자의 질문과 직접 연결된 단락이 희미해져 엉뚱한 대목을 근거로 답할 수도 있다.

요약도 조심해야 한다. 요약은 맥락 손실을 줄이기 위한 도구지만, 잘못하면 손실을 더 키운다. 특히 예외 조건, 금지 규칙, 수치 기준, 날짜 같은 정보는 요약 과정에서 쉽게 사라진다. "대체로 이렇다"라는 식의 부드러운 문장은 보기에는 깔끔하지만, 실제 업무에서는 가장 위험할 때가 많다.

맥락 손실은 다음과 같은 모습으로 나타난다.

• 분명히 준 지시를 모델이 지키지 않는다.

• 문서 안에 답이 있는데도 다른 말을 한다.

• 대화 초반의 중요한 결정 사항을 잊은 듯 행동한다.

• 길어진 작업일수록 점점 일반론적이고 안전한 말만 한다.

이런 현상이 반복되면 모델을 탓하기 전에 먼저 물어야 한다. 정말 이 정보가 살아 있는 맥락으로 전달되었는가?

실무에서 자주 보는 맥락 손실의 장면들

고객지원 챗봇을 예로 들어 보자. 정책 문서 전체를 다 넣어 주었는데도 챗봇이 틀린 답을 내놓는 경우가 있다. 자세히 보면 최신 예외 규정이 문서 구석에 한 줄로 들어 있고, 오래된 일반 정책 설명이 여러 페이지를 차지하는 경우가 많다. 모델은 문서를 읽었지만, 정작 중요한 기준은 약하게 반영한 것이다.

문서 작성 에이전트에서도 비슷한 일이 생긴다. 브랜드 톤 가이드, 독자 정보, 금지 표현, 제품 설명서, 이전 초안을 한 번에 다 넣으면 든든해 보인다. 하지만 막상 결과물은 톤도 흐리고 구조도 애매한 경우가 많다. 왜냐하면 "누구에게 어떤 목적의 글을 쓰는가"보다 주변 참고자료의 부피가 더 커져 버렸기 때문이다.

코딩 에이전트는 더 극적이다. 전체 저장소 설명, 긴 에러 로그, 여러 파일의 코드, 테스트 결과, 수정 요청이 뒤섞여 들어가면 모델은 문제의 중심을 놓치기 쉽다. 이때 필요한 것은 모든 파일이 아니라, 문제와 직접 연결된 파일 구조, 실패한 테스트, 관련 규칙, 수정 범위다.

실무의 교훈은 단순하다. 정보가 많다고 안심할 것이 아니라, 지금 실패를 풀기 위한 재료가 전면에 와 있는지를 봐야 한다.

좋은 컨텍스트는 "충분하지만 날씬하다"

좋은 컨텍스트는 빈약해서도 안 되고, 비만해서도 안 된다. 너무 적으면 근거가 부족해지고, 너무 많으면 초점이 흐려진다. 그래서 좋은 컨텍스트를 한마디로 표현하면 충분하지만 날씬한 컨텍스트라고 할 수 있다.

여기서 충분하다는 것은 모델이 답을 지어내지 않고도 판단할 수 있을 만큼 필요한 근거가 들어 있다는 뜻이다. 날씬하다는 것은 그 판단에 직접 쓰이지 않는 주변 정보가 과도하게 섞여 있지 않다는 뜻이다.

이 균형은 생각보다 중요하다. 많은 팀이 "정확도를 높이려면 자료를 더 넣자"는 방향으로 움직이지만, 어느 순간부터는 정확도가 오르지 않고 오히려 흔들린다. 이유는 간단하다. 부족한 상태에서 조금 더 넣는 것은 도움 되지만, 이미 충분한 상태에서 더 밀어 넣는 것은 방해가 되기 쉽기 때문이다.

좋은 설계자는 이 지점을 감으로만 보지 않는다. 질문과 자료 사이의 연결성을 보고, 문서 조각의 길이를 보고, 반복과 충돌을 줄이고, 핵심 규칙이 눈에 띄는 형식으로 배치되었는지 확인한다.

형식은 내용만큼 중요하다

같은 정보라도 어떻게 놓아두느냐에 따라 읽히는 힘이 달라진다. 흐릿한 문단 속에 묻힌 규칙보다, 역할과 목표와 제약이 구분된 구조가 훨씬 잘 작동한다. 최신 문서와 오래된 문서를 섞어 두는 것보다, 출처와 날짜와 우선순위를 드러내는 편이 안전하다. 긴 로그 전체를 던져 주는 것보다, 핵심 에러와 재현 조건을 먼저 요약해 주는 편이 훨씬 낫다.

이것은 AI가 게으르다는 뜻이 아니다. 오히려 제한된 작업 공간에서 판단해야 하므로, 구조가 곧 해석의 힌트가 되기 때문이다. 사람도 급할 때는 잘 정리된 체크리스트를 더 신뢰한다. AI도 마찬가지다.

그래서 컨텍스트를 설계할 때는 내용뿐 아니라 형식을 함께 봐야 한다. 무엇이 규칙인지, 무엇이 사실인지, 무엇이 현재 목표인지, 무엇이 참고용인지가 구분되어야 한다. 이 구분이 흐리면 모델도 흐려진다.

긴 작업일수록 바깥 기억이 필요하다

작업이 짧고 단순할 때는 현재 컨텍스트 안에 대부분을 담아도 괜찮다. 하지만 작업이 길어질수록 모든 흔적을 컨텍스트 윈도우 안에만 보관하는 방식은 곧 한계에 부딪힌다. 이전 결정 사항, 중간 산출물, 실패한 시도, 사용자 선호, 다음 단계 계획이 계속 쌓이기 때문이다.

이때 필요한 것이 바깥 기억이다. 다시 말해 컨텍스트 윈도우 밖에 저장소를 두고, 필요한 순간에만 다시 불러오는 방식이다. 아직 자세한 방법은 다음 장들에서 다루겠지만, 여기서 핵심만 먼저 잡아 두자. 작업 기억은 작게 유지하고, 장기적으로 남길 것은 밖에 기록하라는 것이다.

사람도 긴 프로젝트를 머릿속으로만 끌고 가지 않는다. 회의록을 남기고, 의사결정 메모를 만들고, 할 일을 적어 둔다. AI 시스템도 마찬가지다. 매번 모든 것을 한 번에 넣으려 하지 말고, 기록과 선택과 요약과 분리를 통해 작업 기억을 가볍게 유지해야 한다.

"많이 넣기"보다 "맞게 넣기"가 중요한 이유

이제 이 장의 핵심 문장을 분명히 해 보자. 컨텍스트 엔지니어링에서 중요한 것은 많이 넣는 일이 아니라 맞게 넣는 일이다.

맞게 넣는다는 것은 몇 가지를 동시에 뜻한다. 지금 과제와 직접 관련된 정보만 남긴다는 뜻이고, 행동 기준과 참고 자료를 구분한다는 뜻이며, 최신성과 신뢰도가 높은 정보를 앞세운다는 뜻이다. 또한 긴 기록을 그대로 밀어 넣지 않고, 현재 단계에서 필요한 형태로 다듬는다는 뜻이기도 하다.

이 차이는 결과에서 크게 드러난다. 많이 넣은 시스템은 얼핏 똑똑해 보이지만, 실제로는 산만하고 일관성이 떨어진다. 맞게 넣은 시스템은 자료가 적어 보여도, 필요한 순간에 필요한 근거를 정확히 꺼내 온다. 전자는 기억력 자랑에 가깝고, 후자는 실무 능력에 가깝다.

컨텍스트 엔지니어가 해야 할 일도 여기에 있다. 모델을 정보로 압도하는 것이 아니라, 모델이 제대로 집중할 수 있는 작업 환경을 만들어 주는 것이다.

이 장의 관점을 다음 기술로 연결하기

컨텍스트 윈도우를 작업 기억으로 이해하면, 다음에 배울 기술들이 왜 필요한지 자연스럽게 이어진다. 작업 기억이 좁고 소중하다면, 중요한 것은 밖에 기록해야 한다. 지금 필요한 것만 골라 넣어야 한다. 길어진 맥락은 압축해야 한다. 서로 다른 역할과 민감한 정보는 분리해야 한다.

즉, 앞으로 살펴볼 여러 실전 기법은 모두 하나의 문제에서 출발한다. 제한된 작업 기억을 어떻게 낭비하지 않을 것인가 하는 문제다. 이 장은 그 바닥 개념을 다지는 장이라고 생각하면 된다.

컨텍스트 윈도우는 단순한 스펙 표의 숫자가 아니다. AI가 실제로 일하는 작업대의 크기이며, 동시에 그 작업대 위에 무엇을 어떤 순서로 놓을지 결정하게 만드는 설계 조건이다. 이 사실을 이해하는 순간, 우리는 더 이상 긴 프롬프트를 만능 열쇠처럼 믿지 않게 된다. 대신 묻게 된다. 이 모델은 지금 정말 필요한 것을 보고 있는가.

좋은 컨텍스트 설계는 바로 그 질문에서 시작된다.