"1시간 대화했는데 AI가 기억을 못한다고?"

Introduction

AI와 한 시간 동안 열심히 코드를 디버깅했습니다. 오류를 찾고, 해결책을 논의하고, 개선 방향까지 이야기했죠. 그런데 "아까 그 에러 말인데요"라고 말하자마자 AI가 이렇게 답합니다. "어떤 에러를 말씀하시는 건가요?"

허탈함을 넘어 황당함마저 느껴지는 이 순간, 혹시 AI가 고장 난 건 아닐까 의심하게 됩니다. 하지만 이건 버그가 아닙니다. ChatGPT든 Claude든 모든 LLM이 겪는 근본적인 한계입니다.

더 충격적인 사실은 이겁니다. LLM은 애초에 우리와의 대화를 '기억'하지 않습니다. 메모리가 아예 없거든요. 우리가 메시지를 보낼 때마다 AI는 대화의 처음부터 끝까지 전부 다시 읽습니다. 마치 100페이지짜리 책에 101번째 문장을 쓰려면 1페이지부터 100페이지까지 다시 읽어야 하는 것처럼요.

그렇다면 왜 이런 비효율적인 방식을 쓸까요? 컨텍스트 윈도우는 왜 마음대로 늘릴 수 없을까요? 그리고 RAG라는 기술이 이 문제를 어떻게 해결할까요?

오늘은 ByteByteGo의 <The Memory Problem: Why LLMs Sometimes Forget Your Conversation>을 번역해서 가져왔습니다. AI를 단순히 사용하는 것을 넘어, AI의 한계를 이해하고 효과적으로 활용하고 싶은 개발자라면 반드시 알아야 할 내용입니다. 이 글을 읽고 나면 여러분은 AI와 대화하는 방식을 완전히 바꾸게 될 것입니다.

메모리 문제: LLM이 때때로 대화를 잊어버리는 이유

복잡한 코드를 디버깅하기 위해 LLM과 한 시간 동안 작업했다고 상상해보세요.

AI가 문제를 식별하고 해결책을 제안하며 생산적인 대화가 이어졌습니다. 그런데 "앞서 논의한 오류"를 언급하자, AI가 마치 이전 대화가 전혀 없었던 것처럼 반응합니다. 어떤 오류를 말하는지 명확히 해달라고 요청하며, 이전의 모든 내용을 잊어버린 것 같습니다. 더 심한 경우에는 허구의 답변을 만들어내기도 합니다. 이런 답답한 경험은 사용자로 하여금 뭔가 잘못되었다고 의심하게 만듭니다.

이러한 메모리 문제는 버그나 일시적인 결함이 아닙니다. 오늘날 사용 가능한 모든 대규모 언어 모델(Large Language Model, LLM)이 어느 정도 겪는 근본적인 아키텍처 제약입니다.

흔히 발생하는 문제들은 다음과 같습니다:

디버깅 논의에서 여러 잠재적 해결책과 오류 메시지를 탐색한 후, AI가 대화를 시작했던 원래 문제를 놓치는 경우가 있습니다.

기술적 논의는 주제가 전환되고 발전할 때 특히 어려움을 겪습니다. 데이터베이스 설계로 시작해서 API 아키텍처로 이동한 다음 다시 데이터베이스 최적화로 돌아가면, AI가 원래의 데이터베이스 논의를 전혀 기억하지 못하는 경우가 많습니다.

고객 지원 대화에서는 이미 답변한 질문으로 자주 되돌아가며, AI가 대화 초반에 제공된 정보를 다시 요청하기도 합니다.

문맥적 표현을 사용할 때 참조 오류가 특히 명확해집니다. "우리가 논의한 함수" 또는 "그 접근법"이라고 말하면, AI가 이전에 논의된 내용에 대한 인식을 완전히 잃고 명확한 설명을 요청합니다.

이러한 현상이 왜 발생하는지 이해하는 것은 일상 업무에서 AI 어시스턴트를 사용하는 모든 사람, 이러한 모델을 통합한 애플리케이션을 구축하는 사람, 또는 단순히 현재 AI 기술의 실제 능력과 한계를 파악하려는 사람 모두에게 매우 중요합니다.

이 글에서는 LLM이 전통적인 의미에서는 실제로 아무것도 기억하지 못하는 이유, 컨텍스트 윈도우(context window)가 무엇인지, 그리고 왜 그것이 대화 길이에 엄격한 제한을 만드는지 살펴보겠습니다.

컨텍스트 윈도우: 메모리의 환상

LLM은 전통적인 의미의 메모리를 갖고 있지 않습니다.

ChatGPT나 Claude에 메시지를 보낼 때, 이러한 모델들은 저장된 메모리 저장소에서 우리의 이전 대화를 불러오지 않습니다. 대신, 맨 처음부터 전체 대화를 다시 읽으며, 새로운 응답을 생성하기 위해 모든 메시지를 처음부터 다시 처리합니다.

이것은 마치 책을 읽는데, 누군가 다음 문장을 쓰고 싶을 때마다 첫 페이지부터 다시 시작해서 그 지점까지의 모든 내용을 읽어야 하는 것과 같습니다. 책이 100페이지까지 늘어났다면, 101번째 문장을 추가하기 전에 100페이지 전체를 읽어야 합니다.

이것은 각 요청이 독립적인 무상태(stateless) 접근 방식입니다. 처음에는 엄청나게 비효율적으로 보일 수 있습니다. 하지만 실제 데이터 전송량은 놀라울 정도로 적습니다. 30,000단어에 달하는 긴 대화도 약 200-300킬로바이트의 데이터로 변환될 뿐입니다. 참고로, 소셜 미디어 플랫폼의 사진 한 장은 일반적으로 1-2메가바이트로, 광범위한 AI 대화보다 5~10배 더 큽니다. 기본적인 광대역 인터넷 연결조차도 이 정도의 데이터는 1초도 안 되는 시간에 전송할 수 있습니다.

진짜 병목 현상은 네트워크 전송이 아니라 컴퓨팅 처리에 있습니다. 300KB를 전송하는 데는 밀리초가 걸리지만, 모델을 통해 이러한 토큰을 처리하는 데는 훨씬 더 오래 걸립니다.

하지만 이러한 무상태 설계는 중요한 이점을 제공합니다. 사용 가능한 모든 서버가 다른 서버와 조율하거나 세션 메모리를 유지할 필요 없이 모든 요청을 처리할 수 있습니다. 대화 중에 서버가 고장 나더라도 다른 서버가 원활하게 인계받을 수 있습니다. 이렇게 로드 밸런싱을 통한 수평적 확장이 더 쉬워집니다.

이러한 무상태 특성은 또한 LLM이 완전히 현재 순간에만 존재한다는 것을 의미합니다. 서버가 메시지 간에 대화 상태를 저장하지 않기 때문에 개인정보 보호가 강화됩니다. 브라우저를 닫으면 서버 측에서 대화가 진정으로 종료됩니다. 브라우저 탭을 닫고 한 시간 후에 돌아오면, 같은 세션을 계속하지 않는 한 LLM은 이전 대화를 기억하지 못합니다.

대화를 다시 읽는 것은 컨텍스트 윈도우라고 하는 것 안에서 일어나며, 이것은 전체 대화가 들어가야 하는 고정 크기의 메모장처럼 작동합니다. 모든 LLM은 특정 용량을 가진 이 메모장을 갖고 있으며, 가득 차면 시스템은 계속 작성하기 위해 이전 내용을 지워야 합니다. 용량은 토큰(token)으로 측정되는데, 이는 LLM이 처리하는 텍스트의 기본 단위입니다. 토큰은 대략 단어의 4분의 3 정도지만, 복잡한 전문 용어, URL, 또는 코드 스니펫은 단순한 단어보다 훨씬 더 많은 토큰을 소비합니다.

아래 다이어그램을 보면 컨텍스트 윈도우의 개념을 이해할 수 있습니다:

현대의 컨텍스트 윈도우는 크기가 천차만별입니다:

소형 모델은 약 4,000토큰, 즉 약 3,000단어 또는 단편 소설 길이의 윈도우를 가질 수 있습니다.

중형 모델은 16,000~~32,000토큰을 제공하며, 가장 큰 상용 모델은 100,000~~200,000토큰을 자랑하며 이론적으로는 소설 한 권 전체를 담을 수 있습니다.

그러나 이러한 더 큰 윈도우는 상당한 컴퓨팅 비용과 느린 처리 시간을 수반합니다.

우리의 메시지, AI의 응답, 그리고 우리가 볼 수 없는 숨겨진 시스템 지시사항 등 모든 것이 이 토큰 제한에 포함됩니다. 첫 단어를 입력하기도 전에, 시스템은 이미 AI에게 어떻게 행동해야 하는지 알려주는 지시사항으로 수백에서 수천 개의 토큰을 사용합니다. 또한 코드 스니펫, URL, 기술적 콘텐츠는 일반 텍스트보다 토큰을 훨씬 빠르게 소비합니다. 글머리 기호나 줄 바꿈과 같은 서식 선택조차도 토큰 비용이 발생합니다.

LLM이 앞서 언급된 내용을 참조하거나 일관된 추론을 유지할 때, 그것은 메모리처럼 느껴집니다. 하지만 이 환상은 모델이 그 순간에 모든 이전 메시지를 처리하는 것에서 비롯됩니다. 다시 말해, 기억하는 것이 아니라 적극적으로 읽고 있는 것입니다. 문맥 인식은 각 응답을 생성하는 짧은 순간 동안만 존재합니다.

컨텍스트 윈도우 확장의 어려움

왜 컨텍스트 윈도우 크기를 늘릴 수 없을까요?

컨텍스트 윈도우를 단순히 더 크게 만들 수 없는 핵심 이유는 LLM이 어텐션 메커니즘(attention mechanism)이라고 하는 것을 통해 텍스트를 처리하는 방식에 있습니다. 이 메커니즘은 대화의 모든 단어가 다른 모든 단어와의 관계를 이해해야 합니다. 이것은 회의를 조직하는데 모든 사람이 논의 내용을 완전히 이해하기 위해 다른 모든 사람과 일대일 대화를 해야 하는 것과 같습니다.

이것의 수학적 특성은 제곱 성장 문제를 만들어냅니다. 즉, 입력을 두 배로 늘리면 작업량이 두 배가 되는 것이 아니라 네 배가 됩니다.

이 동일한 수학적 원리가 LLM의 토큰 처리에도 적용됩니다. 대화에 1,000개의 토큰이 있으면, 모델은 토큰 간에 약 100만 개의 관계를 계산해야 합니다. 10,000개의 토큰으로 늘어나면 이제 1억 개의 관계를 계산해야 합니다. 이것이 긴 대화에서 나중 메시지가 점점 더 오래 걸리는 이유입니다. 8,000개의 토큰을 처리하는 것은 4,000개의 토큰보다 두 배가 아니라 네 배의 시간이 걸립니다.

문제는 처리 시간에 그치지 않습니다. 이러한 토큰 관계 각각은 처리하는 동안 GPU 메모리에 저장되어야 합니다. 10,000토큰 대화는 이 모든 관계를 추적하기 위해서만 기가바이트의 메모리가 필요합니다. 현대 GPU는 인상적인 성능에도 불구하고 고정된 메모리 제한이 있습니다. 대화가 이러한 제한을 초과하면, 우리가 얼마나 오래 기다리든 처리가 불가능해집니다.

이것이 방대한 자원을 가진 회사들조차 단순히 무제한 컨텍스트 윈도우를 제공할 수 없는 이유입니다.

RAG가 컨텍스트 윈도우 문제를 해결하는 방법

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 컨텍스트 윈도우 제한을 다루는 가장 유망한 접근 방식 중 하나입니다. LLM의 제한된 메모장에 모든 것을 넣으려고 시도하는 대신, RAG 시스템은 각 특정 질문에 필요한 관련 정보만 신속하게 가져오는 똑똑한 사서를 두는 것처럼 작동합니다.

작동 방식은 간단합니다.

질문을 하면, RAG 시스템은 먼저 방대한 외부 데이터베이스를 검색하여 관련 문서나 구절을 찾습니다.

그런 다음 이러한 특정 정보만 질문과 함께 컨텍스트 윈도우에 삽입합니다.

LLM은 새로 검색된 매우 관련성 높은 정보를 기반으로 답변을 생성합니다. 컨텍스트 윈도우에 도서관 전체의 지식을 담는 대신, 시스템은 각 쿼리에 필요한 특정 책만 가져옵니다.

아래 다이어그램을 참조하세요:

이 접근 방식은 적당한 크기의 컨텍스트 윈도우를 거의 무제한처럼 느끼게 만들 수 있습니다. 외부 데이터베이스는 어떤 컨텍스트 윈도우도 담을 수 없는 수백만 개의 문서를 포함할 수 있습니다. 기술 문서 검색, 지식 베이스 질의응답, 대규모 데이터셋에서 특정 정보 찾기와 같은 작업에서 RAG 시스템은 탁월한 성능을 보입니다.

그러나 RAG가 컨텍스트 윈도우 제약을 완전히 없애는 마법의 해결책은 아닙니다. 검색 시스템이 효과적으로 작동하려면 여전히 컨텍스트가 필요합니다. "그 숫자들은 어떻습니까?"라고 물으면, 우리가 특정 숫자 세트에 대해 논의하고 있다는 것을 알지 못하면 시스템은 관련 정보를 검색할 수 없습니다. 이는 대부분의 RAG 시스템이 여전히 대화 기록을 유지하며 이전 대화에 컨텍스트 윈도우 공간을 사용한다는 것을 의미합니다. 또한 검색된 모든 정보는 최종 처리를 위해 여전히 컨텍스트 윈도우 안에 들어가야 합니다. 복잡한 질문에 답하려면 20개의 다른 문서에서 정보가 필요한데 컨텍스트 윈도우가 5개만 담을 수 있다면, 시스템은 무엇을 포함할지 선택해야 합니다.

결론

LLM의 메모리 제한은 관리해야 할 제약 조건입니다. 이러한 경계를 이해하면 현실적인 기대치를 설정하고 AI 어시스턴트와 더 효과적으로 작업할 수 있습니다.

이러한 지식은 또한 LLM과의 대화에 접근하는 방식을 바꿉니다. 복잡한 문제를 집중된 세션으로 나누고, 질문에 명확한 맥락을 제공하며, 제한에 도달하고 있음을 인식하는 것이 모두 학습 과정의 일부가 됩니다. AI 애플리케이션을 구축하는 개발자에게 이러한 제약은 대화 관리, 검색 시스템, 사용자 경험에 대한 설계 결정에 영향을 줍니다.

이러한 제한에도 불구하고, LLM은 여전히 매우 강력한 도구입니다. 복잡한 프로그래밍, 분석 및 수많은 다른 작업을 지원할 수 있습니다.