VibeCoding ツール｜Lovable / Codex / Claude Code　比較

이 글은 「AI 공부 지도 20부작」의 12편(M2) 입니다.
앞 편: M1 — Retrieval Layer가 왜 필요한가
다음 편: M3 — AI Agent 심화

Table of Contents

0. 들어가기 전에

FIG. Long-context ≠ Memory

컨텍스트 윈도우

토큰 한 번에 입력

해상도: 모든 입력을 동등하게

진짜 기억력

≠

맥락 유지·우선순위

1. “Claude 1M 토큰” 이라는 헤드라인이 놓치는 것

먼저 헤드라인 하나를 들어볼게요. 2025 년 후반에 Anthropic 에서 Claude Sonnet 의 1M 토큰 버전을 내놨습니다. 그때 기술 커뮤니티에서 가장 많이 본 반응이 이런 거였어요. “이제 AI 가 책 한 권을 통째로 기억하네.” 비슷한 반응은 Gemini 2M 때도 있었고, GPT 의 컨텍스트가 늘어날 때마다 반복돼요.

그런데 “기억” 이라는 단어가 여기서 틀렸습니다.

이 “1M 토큰” 이 하는 일은 정확히 이거예요. 당신이 한 번의 API 호출에 넣을 수 있는 프롬프트의 최대 길이가 100만 토큰 정도까지 늘었다. 책 한 권이든, 코드베이스 전체든, 1년치 회의록이든, 프롬프트에 붙여서 한 번에 넣으면 모델이 그걸 “이번 대답할 때 참고할 재료” 로 읽어줍니다. 대답이 끝나면 그 재료는 사라져요. 다음 호출 때는 다시 넣어야 하고요.

이건 “기억” 이라기보다 “이번에 책상에 올려놓을 수 있는 종이 양이 늘었다” 에 가까워요. 시험 볼 때 책상 위에 교과서를 1권 펼 수 있는 상황과 10권 펼 수 있는 상황의 차이 같은 거죠. 책상은 커졌지만, 시험이 끝나면 책상은 초기화됩니다. “그 학생이 공부를 많이 한다” 가 아니라 “그 학생이 한 번의 시험에서 참고할 수 있는 책이 많아졌다” 가 맞는 해석이에요.

왜 이 구분이 중요하냐면, 이 둘을 섞어 버리면 제품 판단이 전부 틀어지기 시작하거든요. 예를 들어 “AI 의 기억력이 좋아졌으니 이제 우리 서비스는 사용자 프로필을 따로 저장 안 해도 되겠네” 라고 누가 말한다면, 그건 잘못된 추론입니다. 1M 토큰은 그 프로필을 저장해 주지 않아요. 매번 프롬프트에 붙여야 모델이 본답니다. 붙이는 행위 자체에 토큰 비용이 발생하고요.

반대 방향으로 틀어지는 경우도 있어요. “기억 기능이 들어갔다니 ChatGPT 가 내 연애 고민을 평생 기억해 주는구나” 같은 해석. 이건 2024 년에 ChatGPT Memory 기능이 나왔을 때 실제로 많이 나왔던 반응이에요. 그 기능은 당신이 한 말 중 몇 개의 짧은 노트만 뽑아서 별도로 저장해 두는 장치 지, 모델 자체가 당신의 연애사를 학습한 건 아니에요. 메커니즘이 전혀 다릅니다.

그래서 이 글의 목표는 이거예요. “긴 컨텍스트” 와 “기억” 을 섞지 않고, 세 층을 분리해서 보는 것. 세 층은 각각 context window, session memory, persistent memory 입니다. 이제 하나씩 들어가 볼게요.

2. Context Window — 작업대 위에 올릴 수 있는 최대 종이 양

P4 에서 attention 을 꼼꼼히 봤었죠. 거기서 핵심은 이 한 줄이었어요. “모든 토큰이 모든 토큰을 본다.” 이 성질이 컨텍스트 윈도 의 크기와 직결돼요.

Attention 이 하는 일을 기억해 봅시다. 문장 안에 있는 토큰 N 개가 있으면, 각 토큰은 자기 Query 를 들고 나머지 N 개의 Key 와 비교해서 점수표를 만듭니다. 그래서 크기가 N×N 인 점수표가 만들어져요. 토큰 수가 2배가 되면 점수표의 칸 수는 4배 가 됩니다. 이게 O(n²) 복잡도 라는 이야기의 실체예요.

여기서 “1M 토큰을 지원한다” 는 말의 무게가 드러납니다. 토큰이 2,000 개였던 시절의 점수표는 4백만 칸이었어요. 토큰이 100만 개가 되면 점수표는 1조 칸 이 됩니다. 같은 attention 연산을 하려면 메모리와 계산이 25만 배로 뜁니다. GPU 한 장으로는 절대 못 감당해요.

그래서 실제 1M 컨텍스트를 지원하는 모델들은 몇 가지 공학적 꼼수를 써요. Flash Attention 으로 메모리 접근을 최적화하거나, Sliding Window Attention 으로 모든 토큰이 아니라 근처 토큰만 보게 한다거나, Linear Attention 처럼 근사 계산으로 복잡도를 낮추거나. 이런 기술들이 쌓여서 “1M 을 지원한다” 가 실현되는 겁니다. 즉 이 “1M” 숫자 뒤에는 “원래 attention 을 그대로 돌리면 미친 비용인데, 이것저것 꼼수를 써서 돌아가게 만들었다” 는 기술적 고통이 숨어 있어요.

그럼 왜 이런 꼼수를 써서라도 컨텍스트를 키우는 걸까요. 이유는 “작업대” 가 커지면 할 수 있는 일이 많아지기 때문 이에요. 예를 들어 이런 것들이 됩니다.

긴 논문 1 편을 통째로 넣고 “이 논문의 핵심 주장을 세 문장으로 요약해 줘” 요청
코드베이스 전체를 넣고 “이 함수가 어디에서 호출되고 있지?” 질문
1 년치 회의록을 넣고 “작년에 우리가 A 프로젝트 관련해서 내린 결정 세 가지 뭐였어?” 질문

기존에는 이런 걸 하려면 retrieval 로 관련 부분을 먼저 뽑아오는 수밖에 없었어요. 긴 컨텍스트 덕분에 “전부 던져놓고 알아서 찾아줘” 가 가능해진 거예요. 편해집니다.

하지만 기억해 두셔야 할 게 있어요. 이 “작업대” 는 휘발성입니다. 대답이 끝나면 작업대에 올려둔 종이는 모두 털어집니다. 다음 호출 때는 빈 책상부터 시작해요. 그래서 1M 토큰을 “AI 의 장기 기억” 이라고 부르는 건 정확하지 않아요. 장기 기억은 다음 호출에도 남아야 하는데, 이건 이번 호출 안에서만 살아 있는 공간이거든요.

한 줄로 정리하면 이래요. Context window 는 한 번의 호출에서 “모델이 읽을 재료” 의 최대 길이다. 기억 용량이 아니다. 이 감각을 붙잡고 다음 섹션으로 가 볼게요.

3. 긴 컨텍스트에서 무너지는 문제 — “Lost in the Middle”

큰 작업대에는 함정이 하나 있어요. 책상이 넓어진다고 모든 종이를 똑같이 읽어주는 건 아니에요.

Stanford 의 Liu 와 동료들이 2023 년에 낸 연구에 “Lost in the Middle: How Language Models Use Long Contexts” 라는 제목의 논문이 있어요. 여기서 저자들이 실험을 하나 했습니다. 모델에게 길~다란 문서를 하나 주고, 그 안 어딘가에 “정답 문장” 을 심어둔 다음, 질문을 던지는 거예요. 정답 문장을 문서 앞쪽 에 둘 때, 중간 에 둘 때, 끝쪽 에 둘 때 각각의 정답률을 비교했어요.

결과가 꽤 인상적이었습니다. 앞쪽과 끝쪽에 정답이 있을 때는 모델이 잘 찾았어요. 그런데 정답이 문서 중간 에 있을 때는 정답률이 뚝 떨어졌어요. 모델마다 정도는 다르지만, 많은 경우 중간 정답의 정답률이 앞/뒤의 절반 수준까지 떨어지기도 했습니다. 논문은 이 현상을 “Lost in the Middle (가운데에서 길을 잃는다)” 이라고 불렀어요.

비유해 볼까요. 100 쪽짜리 교과서를 하루 만에 훑어야 한다고 쳐봐요. 첫 10 쪽은 집중해서 읽어요. 마지막 10 쪽은 끝이 보이니까 또 집중해요. 그런데 40 쪽~60 쪽 사이는 졸립고 눈이 안 가죠. 사람도 그렇고 모델도 그런 경향이 있어요. 이게 왜 생기는지는 완전히 밝혀진 건 아니지만, 몇 가지 가설이 있습니다. 위치 인코딩이 긴 거리에서 희미해지는 영향, 학습 데이터 자체의 분포 (문서 앞과 끝에 중요한 문장이 많은 편향), attention 이 가까운 토큰에 좀 더 쏠리는 경향 같은 것들요.

이 현상이 실무에 주는 교훈은 이래요. “1M 컨텍스트에 다 넣으면 알아서 찾겠지” 가 항상 참은 아닙니다. 중요한 정보를 문서 가운데 깊숙이 묻어두면, 모델이 안 꺼내 올 수도 있어요. 그래서 긴 컨텍스트를 쓸 때도 retrieval 로 “정말 필요한 부분만 추려서 위쪽이나 아래쪽에 배치” 하는 방식이 여전히 효과적이에요. M1 에서 봤던 retrieval 이 long-context 시대에도 안 죽는 이유 중 하나가 여기 있습니다.

이 얘기에서 한 가지 더 끌어낼 수 있는 통찰이 있어요. 컨텍스트를 크게 쓰는 것과 컨텍스트를 잘 쓰는 것은 다른 문제다 라는 감각. 크기는 용량의 얘기고, 활용은 배치와 구조의 얘기예요. 좋은 프롬프트 엔지니어링의 상당 부분이 “같은 정보를 어느 위치에 둘 것인가” 를 고민하는 일이 되는 이유가 여기예요.

4. Session Memory — 대화 “기억” 은 사실 재첨부

자, 첫 번째 축 (context window) 은 “한 번의 호출 안에서 쓸 수 있는 재료의 양” 이었어요. 그럼 ChatGPT 에서 대화를 주고받을 때 앞서 말한 내용이 이어지는 건 뭘까요. 두 번째 축인 session memory 입니다. 그런데 이게 이름이랑 실체가 꽤 다르니까 한번 뜯어볼게요.

상상해 보세요. 당신이 ChatGPT 에 이렇게 말합니다. “안녕, 내 이름은 윤지야.” 모델이 “안녕 윤지, 반가워” 라고 답해요. 몇 턴 뒤에 당신이 “내 이름 뭐였더라?” 물으면 “윤지였죠” 라고 답해요. 기억한 것처럼 보이죠.

실제로 안에서는 이런 일이 벌어지고 있어요. 두 번째 질문을 던지는 순간, 앱이 모델에게 이런 식의 프롬프트를 통째로 보냅니다.

사용자: 안녕, 내 이름은 윤지야.
모델: 안녕 윤지, 반가워.
사용자: (중간 대화 턴들 …)
모델: (그에 대한 답 …)
사용자: 내 이름 뭐였더라?

보시면 모델은 당신 이름을 “기억한” 게 아니에요. 앱이 앞의 대화 전체를 매번 다시 프롬프트에 붙여서 보내고 있는 거예요. 모델은 그 프롬프트 맨 위에서 “윤지” 라는 문자열을 보고, “아, 이번 질문에서 참조할 이름이 여기 있네” 하고 대답하는 거죠. 두 번째 턴이 끝나는 순간 그 기억은 또 사라집니다. 세 번째 턴에서는 또 처음부터 붙여서 보내요.

다시 말해 Session memory 는 “모델의 기억” 이 아니라 “앱이 매 호출마다 앞 대화를 재첨부하는 행동” 입니다. 기억의 착시예요. 이 구분이 왜 중요하냐면, 실무에서 벌어지는 많은 문제들이 이 착시 때문에 발생하거든요.

예를 들어 이런 질문. “ChatGPT 대화가 길어지니까 앞부분 내용을 자꾸 잊어버려요. 왜 그렇죠?” 진짜 원인은 이거예요. 대화가 길어지면서 재첨부되는 프롬프트 길이가 모델의 컨텍스트 윈도 한도에 가까워져요. 앱은 한도를 안 넘기려고 가장 오래된 대화 턴부터 잘라내거나 요약해서 붙입니다. 그래서 맨 앞에서 당신이 한 “내 이름은 윤지야” 가 어느 순간 프롬프트에서 사라져 있고, 모델은 그때부터 이름을 “잊어버린 듯” 행동해요. 모델이 잊은 게 아니에요. 앱이 안 보여준 거예요.

또 하나. “API 호출 비용이 대화 턴이 늘어나면서 기하급수적으로 늘어요.” 이유도 같아요. 재첨부되는 프롬프트가 매 턴마다 길어지니까, 입력 토큰 비용이 누적돼서 늘어납니다. 10 턴째의 호출은 1 턴째보다 프롬프트가 훨씬 길어요. 그래서 긴 대화는 비쌀 수밖에 없어요.

이걸 이해하면 ChatGPT 가 왜 긴 대화에서 갑자기 이상해지는지, 왜 같은 질문을 새 탭에서 던지면 답이 다른지, 같은 질문을 반복하면서 왜 비용이 뛰는지가 모두 같은 뿌리에서 설명돼요. Session memory 는 모델 쪽이 아니라 앱 쪽의 기법 이라는 감각이 잡히면 이 모든 의문이 풀립니다.

5. Session Memory 의 현실적 한계

Session memory 가 “앞 대화를 재첨부하는 것” 이라면, 당연히 따라오는 한계가 있어요. 세 가지만 짚을게요.

첫째, 토큰 한도에 걸리면 앞 대화가 잘립니다. 앞서 얘기한 그대로예요. 모델의 컨텍스트 윈도가 200K 라면, 재첨부된 프롬프트가 200K 를 넘는 순간 앞쪽 대화가 사라져요. 이게 “대화가 길어지면 앞 내용을 잊어버리는” 현상의 정체입니다. 1M 컨텍스트 모델에서는 한도가 훨씬 커지지만, 그래도 언젠가는 걸려요.

둘째, 세션을 닫으면 모두 사라집니다. 브라우저를 닫고 내일 다시 ChatGPT 를 열면, 어제 대화의 컨텍스트는 완전히 리셋돼 있어요 (물론 앱이 “대화 기록” 을 저장하는 UI 는 있지만, 그건 앱이 텍스트 로그를 DB 에 저장한 거지 모델이 기억하는 게 아니에요). 새 세션을 시작하면 모델 입장에서는 당신이 처음 보는 사용자로 돌아갑니다. 어제 대화의 내용을 이번 세션에 이어가려면, 당신이 직접 복사해서 붙여야 합니다.

셋째, 여러 대화를 넘나들면 전부 따로따로입니다. 한 세션에서 “내 프로젝트 A 에 관해 깊게 논의” 하고, 다른 세션에서 “프로젝트 A 관련해서 이어서 얘기하자” 라고 말해도 두 번째 세션의 모델은 프로젝트 A 를 모릅니다. 대화 히스토리를 같이 재첨부하지 않으면 연결이 안 돼요.

이 한계를 알면 “AI 를 장기 어시스턴트로 쓰려면 뭐가 더 필요한가” 라는 질문이 자연스럽게 떠오릅니다. 그게 세 번째 축, persistent memory 입니다.

6. Persistent Memory — 세션을 넘는 기억의 4 가지 방법

Persistent memory 는 말 그대로 “세션이 끝나도 남아 있는 기억” 이에요. 그런데 이 “기억” 을 구현하는 방법이 여러 가지입니다. 뭉뚱그려서 한 단어로 부르지만 속사정은 꽤 다르니까 4 가지로 나눠 볼게요.

(a) RAG — 필요할 때 외부에서 끌어옴

M1 에서 꼼꼼히 봤던 친구죠. 문서를 미리 chunk 로 쪼개서 벡터 DB 에 넣어두고, 질문이 들어오면 관련 청크를 retrieval 해서 프롬프트에 붙여 주는 방식이에요. 이 구조의 기억은 “모델 바깥의 검색 가능한 저장소” 에 있습니다. 세션이 닫혀도 저장소는 남아요. 다음 세션에서 질문을 던지면 다시 retrieval 로 꺼내 와서 붙여요.

이건 “기억” 이라기보다 “외부 검색 엔진을 항상 옆에 두기” 에 가깝습니다. 모델 자체는 아무것도 기억 안 해요. 바깥 저장소가 기억하는 거예요.

장점은 최신성과 대용량 처리 입니다. 저장소를 실시간으로 업데이트할 수 있고, 수십 GB 의 문서도 처리 가능해요. 기업의 사내 문서 검색, 고객 지원 챗봇 같은 데에 기본 구조로 쓰이는 이유가 여기예요.

단점은 retrieval 품질에 전적으로 의존 한다는 거. 검색이 엉뚱한 청크를 뽑아 오면 모델도 엉뚱한 답을 해요. M1 에서 봤던 “retrieval 의 4층” 이 자꾸 등장하는 이유가 이거예요.

(b) Summary Memory — 긴 대화를 주기적으로 요약해 저장

두 번째 방식은 이래요. 대화가 길어지면 앱이 앞쪽 대화를 주기적으로 요약 해서 짧은 문장으로 바꿔 둡니다. 다음 호출 때는 원본 대화 전체 대신 그 요약만 재첨부해요. 토큰을 아끼면서 “대충의 맥락” 은 유지하는 기법이에요.

비유하자면 회의록을 매 시간마다 한 줄로 줄여 놓는 것 같아요. 원본 녹취는 버리고 “이 시간에는 A 안건을 통과시켰다” 한 줄만 남기는 거죠. 녹취의 디테일은 사라지지만, 전체 흐름은 보존됩니다.

ChatGPT 나 Claude 의 긴 세션이 실제로 이걸 내부적으로 쓰고 있어요. 대화가 한도에 가까워지면 앞쪽 턴을 자동으로 요약으로 교체합니다. 사용자는 모르게 이뤄지는 처리예요.

단점은 요약 과정에서 디테일이 날아간다 는 것. “5 번째 턴에서 내가 특정 숫자를 말했는데 그 숫자가 뭐였지?” 같은 질문은 요약 이후에는 답을 못 할 수 있어요. 요약이 그 숫자를 중요하다고 판단 안 했으면 버려졌을 수도 있거든요.

(c) Vector Memory (Episodic Memory) — 대화 단편을 임베딩으로 인덱싱

세 번째 방식은 RAG 를 “대화 기록” 에 적용한 버전이에요. 대화 중에 나온 중요한 사실이나 발화를 임베딩 벡터로 만들어서 별도 저장소에 쌓아 둡니다. 다음 세션에서 새 질문이 들어오면, 그 질문과 관련된 과거 발화를 벡터 검색으로 꺼내서 프롬프트에 붙여 줘요.

예를 들어 이런 식. 당신이 지난 달에 “나는 고양이를 키운다” 고 말했다 치면, 그 문장은 임베딩 벡터로 저장소에 들어가 있어요. 오늘 “우리 집 고양이가 밥을 잘 안 먹어” 라고 하면, 시스템이 “고양이 키운다” 라는 과거 발화를 꺼내서 프롬프트에 붙여 줍니다. 모델은 마치 기억한 것처럼 답해요.

이걸 학계에서는 Episodic Memory 라고 부르기도 해요. 에피소드처럼 작은 단편들을 인덱싱해서 필요할 때 꺼내는 방식이니까요. ChatGPT 의 Memory 기능이 대체로 이 계열에 가깝습니다 (뒤에서 더 자세히).

장점은 개인화가 세밀해진다 는 것. 사용자별로 다른 저장소를 만들어서 “이 사용자만의 기억” 을 쌓을 수 있어요.

단점은 검색 정확도 문제와 프라이버시 문제 입니다. 엉뚱한 발화가 검색되면 대화가 이상해지고, 민감한 정보가 저장소에 남으면 유출 리스크가 생겨요.

(d) Memory Adaptation (Doc-to-LoRA) — 모델 가중치에 직접 편입

네 번째 방식이 지금까지 세 개와 가장 다릅니다. 모델 자체를 소규모로 학습시켜서 기억을 가중치 안에 넣는 방식 이에요. 대표적인 게 Doc-to-LoRA 죠.

앞 세 개는 전부 “모델은 그대로 두고, 바깥에서 정보를 가져와서 프롬프트에 붙이는” 구조였어요. Doc-to-LoRA 는 그 전제를 깨는 방식입니다. 문서를 미리 모델에 학습시켜서, 가벼운 가중치 차분 (LoRA 어댑터) 로 들고 있어요. 쿼리 때는 프롬프트에 안 붙여도 모델이 이미 “알고” 있습니다.

비유하자면 “매번 참고서를 들고 시험 보는 것 (RAG)” 과 “참고서를 공부해서 머리에 넣고 시험 보는 것 (Doc-to-LoRA)” 의 차이 예요. 전자는 참고서가 늘면 가방이 무거워지지만 최신 내용을 쓰기 쉬워요. 후자는 가방은 가볍지만 공부한 내용만 쓸 수 있어요.

이건 세션을 넘어도 완전히 살아 있는 진짜 “기억” 에 가장 가까운 구조예요. 모델 가중치에 들어가 있으니까, 앱이 재첨부하든 말든 모델이 이미 내용을 갖고 있거든요.

단점은 학습 비용과 업데이트의 번거로움 입니다. LoRA 는 풀 파인튜닝보단 싸지만 그래도 공짜가 아니에요. 문서가 바뀌면 다시 학습해야 하고요. 그래서 자주 바뀌는 동적 데이터에는 안 맞아요. 반대로 거의 안 바뀌는데 매번 프롬프트에 넣기엔 너무 큰 문서 (회사 온보딩 핸드북, 수백 페이지짜리 정책 문서 같은 것) 에는 아주 잘 맞습니다.

이 네 가지 방식을 기억해 두세요. 다음 섹션에서 ChatGPT 의 Memory 기능이 이 네 개 중 어디에 해당하는지를 풀어 볼 거예요.

7. ChatGPT/Claude 의 “Memory” 기능은 무엇인가

2024 년 초부터 ChatGPT 에 “Memory” 라는 기능이 추가됐어요. Claude 도 2025 년에 비슷한 기능을 추가했고요. 이 기능을 처음 봤을 때 많은 사람들이 “드디어 AI 가 나를 기억하는구나” 라고 받아들였어요. 실체는 어떨까요.

기능이 하는 일을 먼저 볼게요. 사용자가 대화 중에 “내 아이 이름은 지후야”, “나는 비건이야” 같은 말을 하면, ChatGPT 가 짧은 노트 를 자동으로 만들어서 계정에 저장해요. 사용자가 “Manage memories” 화면을 보면 실제로 이런 노트들이 리스트로 나옵니다. “User’s child is named Jihoo”, “User is vegan” 같은 줄들이죠.

다음 대화에서는 이 노트들이 시스템 프롬프트처럼 맨 앞에 자동으로 붙어서 모델에게 전달돼요. 그래서 새 세션을 시작해도 모델이 “안녕 지후 아빠” 같은 말로 반응할 수 있어요.

이걸 아까 네 가지 방식과 비교해 보면 이게 (b) Summary Memory 와 (c) Vector Memory 의 하이브리드 예요. 요약된 노트를 쌓아 두고 (summary), 검색 가능한 형태로 인덱싱 (vector) 해서 필요할 때 프롬프트에 붙이는 구조죠. 모델 가중치는 그대로예요. Doc-to-LoRA 수준의 진짜 편입은 아닙니다.

즉 ChatGPT Memory 는 모델이 당신을 “학습” 한 게 아니에요. OpenAI 가 당신 계정에 작은 노트 파일을 만들어 두고, 당신이 대화할 때마다 그 노트를 자동으로 프롬프트 맨 앞에 첨부해 주는 기능 이에요. 실체를 알고 나면 아래 같은 것들이 자연스럽게 이해됩니다.

노트는 사용자가 직접 보고 수정할 수 있어요. 왜? 저장소 안의 텍스트니까요. 모델 가중치였다면 사용자가 못 꺼내요.
노트를 지우면 기억이 사라져요. 왜? 저장소에서 지우면 다음 세션에 첨부될 게 없으니까요.
이 기능은 같은 모델을 쓰는 다른 사용자에게는 영향 안 줘요. 왜? 노트는 당신 계정에만 붙어 있으니까요. 모델 자체가 바뀐 게 아니에요.
데이터 프라이버시 우려는 “모델에 내가 학습됐다” 가 아니라 “OpenAI 서버에 내 노트가 저장돼 있다” 예요. 우려의 성격이 달라요.

이 감각이 잡히면 “AI 의 기억 기능” 관련 뉴스를 훨씬 냉정하게 읽을 수 있어요. 대부분의 상용 제품에서 “기억” 은 (a)~(c) 조합이지 (d) 는 아니에요. (d) 는 기업 내부 배포나 특수한 온프레미스 환경에서나 등장합니다.

8. 긴 컨텍스트 vs 메모리 — 언제 어느 걸

세 축을 다 봤으니까 이제 실무에서 “어느 것을 언제 쓰는가” 를 정리할 차례예요. 이게 의외로 헷갈리는 지점이라서 한번 표처럼 정리해 볼게요.

Context window 가 유리한 상황:

한 번의 작업에 참조할 자료가 대량인데, 이번 한 번만 참조하면 되는 경우. 예: 긴 논문 요약, 대용량 코드 리뷰, 1회성 대량 데이터 분석.
자료 간의 관계 를 파악해야 하는 경우. 예: “이 100 개 문서 중에서 서로 모순되는 부분 찾아줘.” 이런 건 retrieval 로 조각 조각 꺼내면 관계를 못 봐요. 전부 같이 올려놓고 봐야 해요.
빠르게 프로토타입을 만들 때. 굳이 벡터 DB 세팅 안 하고 프롬프트에 다 붙여서 실험해 볼 수 있어요.

Persistent memory 가 유리한 상황:

같은 정보를 반복해서 참조해야 하는 경우. 예: 개인 프로필, 회사 온보딩 문서, FAQ 베이스. 매번 프롬프트에 붙이면 토큰 비용이 누적돼요.
세션을 넘어 유지돼야 하는 경우. 예: 사용자 선호도 기반 개인화, 지속적인 프로젝트 상태 유지.
자료가 너무 커서 context window 에 안 들어가는 경우. 예: 수 GB 의 사내 문서베이스.

두 개는 대체재가 아니라 상호보완 이에요. 거의 모든 실제 시스템에서 둘을 섞어 씁니다. RAG 로 필요한 부분을 긁어와서 long-context 안에 예쁘게 배치하는 식으로요.

한 가지 감을 드리는 원칙이 있어요. “자주 바뀌고 많고 이번 한 번만 보면 되는 건 context, 자주 안 바뀌고 반복 참조되는 건 memory.” 이 기준으로 자료를 분류해 보시면 각 자료를 어디에 넣을지가 자연스럽게 정해져요.

9. 실무 패턴 — Claude Code · Cursor 는 어떻게 기억하나

이제 구체적인 제품 하나를 뜯어볼게요. Claude Code 나 Cursor 같은 코딩 어시스턴트는 어떻게 “프로젝트의 맥락” 을 들고 있을까요. 이게 좋은 케이스 스터디예요.

먼저 결론부터. Claude Code 는 “기억 착시” 를 안 써요. 대신 명시적 재진입과 compaction 으로 운영합니다.

분해해 보면 이래요.

(1) 세션 내 workspace 파일 상태. Claude Code 는 프로젝트 디렉토리를 인식해요. 세션 중에 파일이 바뀌면 tool call 로 파일 상태를 읽어 와서 context 에 반영합니다. 이건 session memory 의 자연스러운 확장이에요. 앞 대화에서 편집한 파일의 새 상태를 매번 다시 읽는 거죠.

(2) 명시적 재진입 (AGENTS.md · CLAUDE.md · memory 파일 재로딩). 세션을 새로 열었을 때 “이 프로젝트는 어떤 것이다” 를 모델이 이해하려면, 프로젝트 루트에 있는 CLAUDE.md 나 AGENTS.md 같은 파일을 매 세션 초반에 의도적으로 다시 읽어 옵니다. 이건 persistent memory 의 (a) RAG 계열 처리예요. 저장소는 그냥 파일 시스템이고, 세션이 시작하면 무조건 이 파일을 첨부하는 규칙이 있는 거죠.

이 “명시적 재진입” 이 묘하게 정직한 설계예요. 사용자가 어떤 정보가 언제 모델에 로드되는지를 직접 보고 통제할 수 있어요. 파일을 편집하면 다음 세션의 모델 행동이 바뀝니다. “AI 가 마법처럼 나를 기억” 하는 척 안 하고, “이 파일을 읽혔으니까 이 맥락을 알아” 라고 명백히 드러내는 거예요.

(3) Compaction. 세션이 길어지면 컨텍스트가 차요. Claude Code 는 일정 시점에서 앞쪽 대화를 자동으로 요약본으로 교체 합니다. 이때 원본 tool call 결과나 파일 내용은 요약되면서 간결해지지만, 중요한 부분은 살아남아요. 사용자는 “이제 compact 합니다” 라는 알림을 받고 세션이 계속돼요.

Compaction 이 재미있는 이유가 하나 있어요. 단순히 요약해서 버리는 게 아니라, 원본 상태를 프로젝트 파일에서 다시 읽을 수 있게 남겨 두는 구조 예요. 요약이 너무 뭉개져서 뭔가 빠졌다 싶으면, 모델이 파일 읽기 도구로 원본을 다시 긁어와요. 그래서 “요약 때문에 중요한 게 날아갔다” 는 상황이 비교적 드물어요. 요약은 요약이고, 원본은 디스크에 그대로 있으니까요.

이 구조가 좋은 이유를 비즈니스 코딩 이전의 상태 → 개입 → 이후의 상태 로 보면 이렇게 풀립니다.

이전: 전통적인 코딩 어시스턴트는 IDE 안에 뚝 떨어져서 세션마다 매번 “어떤 프로젝트인지 다시 설명해야” 하거나, 아니면 “서버가 알아서 기억” 한다면서 뭘 알고 뭘 모르는지 모호했어요. 개발자는 모델의 “기억 상태” 를 통제 못 하고 추측만 했어요.
개입: Claude Code 는 “매 세션 시작에 특정 파일을 읽는다” 는 규칙을 둬서, 모델의 맥락 구성을 개발자가 파일로 통제하게 만들었어요. 거기에 compaction 으로 긴 세션에서도 핵심 상태를 유지해요.
이후: 개발자는 “이 파일만 고치면 다음 세션의 모델 행동이 이렇게 변한다” 를 예측할 수 있고, 긴 리팩토링 세션도 잘라지지 않고 이어 갈 수 있어요. 결과적으로 “AI 가 내 프로젝트를 이해하는가” 라는 모호한 질문이 “내가 AI 에게 뭘 읽혔는가” 라는 통제 가능한 질문으로 바뀝니다.

이게 이번 글의 비자명한 포인트 중 하나예요. 좋은 memory 시스템은 “기억하는 척” 을 잘하는 게 아니라, “뭘 기억하고 뭘 잊는지” 를 사용자가 통제할 수 있게 해주는 것. Claude Code 의 설계가 이 기준에서 꽤 잘 됐다고 봅니다.

10. 실수 포인트 3 가지

긴 컨텍스트와 메모리를 다루면서 실무자들이 자주 빠지는 세 개의 함정을 정리해 볼게요.

(a) “1M 토큰이니까 다 넣자”

첫 번째 함정. 컨텍스트가 커졌으니 관련 문서를 전부 프롬프트에 쏟아붓는 거예요. 두 가지 문제가 생겨요.

Lost in the middle 로 정확도가 떨어져요. 3 절에서 봤듯이, 중간 부분 정보는 제대로 안 읽힙니다. 100 만 토큰을 넣었는데 모델이 정작 중요한 중간 부분을 놓치면, 차라리 10 만 토큰으로 추린 게 나았을 수 있어요.

비용이 폭증합니다. 1M 토큰의 입력 비용이 200K 토큰의 다섯 배인 건 당연한데, 문제는 한 번 호출이 아니라 반복 호출에서 누적 돼요. 같은 문서를 100 번 쓰면 100 배 청구돼요. Prompt caching 으로 일부 완화는 되지만 근본적 해결은 아니에요.

그래서 context window 가 커졌다고 해도 “필요한 만큼만 넣는다” 는 원칙 은 여전히 유효해요. Retrieval 이 죽지 않는 이유입니다.

(b) “AI 가 기억한다” 과신

두 번째 함정. ChatGPT Memory 같은 기능이 있으니까, 민감한 정보를 “AI 에게 맡기기만 하면 알아서 기억해 주겠지” 라고 맡기는 경우. 앞서 봤듯이 그 “기억” 은 OpenAI 서버의 노트 파일이에요. 유출, 공유, 삭제 전부 당신 통제 바깥에서 일어날 수 있어요.

실무에서는 이렇게 접근하는 게 안전해요. “모델에게 기억시킨다” 가 아니라 “저장소에 기록한다” 라고 생각하기. 저장소에 뭐가 쌓이는지, 누가 접근하는지, 얼마나 오래 남는지를 전부 체크해야 해요. “AI 가 기억한다” 라는 감각을 빼고 나면, 이게 평범한 데이터 관리 문제라는 게 보여요.

기업 환경이라면 특히 중요해요. 사용자별 memory 를 상용 LLM 서비스에 올려두면 GDPR, 개인정보보호법 같은 규제 이슈가 바로 올라와요. “AI 가 기억해 준다” 가 법률 문제로 넘어가는 순간이 있어요.

(c) 세션 종료 = 기억 리셋임을 잊음

세 번째 함정은 조금 소프트하지만 흔해요. 사용자가 어제 긴 대화를 통해 복잡한 맥락을 쌓았어요. 오늘 새 세션에서 이어가려는데, AI 가 전혀 모르는 척을 해요. 사용자는 당황하죠. “어제 그렇게 얘기했는데 왜 까먹었어.”

해법은 간단해요. 세션 간 연결이 필요하다는 걸 인식하고, 명시적으로 맥락을 이어가는 장치를 두는 것. Claude Code 의 CLAUDE.md 나 개인 노트 파일을 “세션 시작 시 항상 읽히는 파일” 로 만들어 두는 방식이 가장 단순하고 강력해요.

ChatGPT Memory 기능을 쓰면 이 중 일부는 자동화되지만, 완전하진 않아요. “중요한 것만” 뽑혀서 저장되는데 그 “중요한 것” 의 판단이 AI 에게 맡겨지거든요. 정말 중요한 맥락은 직접 메모로 저장해서 세션 시작 시 붙이는 게 안전해요.

11. Claude Code 의 compaction 이 왜 똑똑한 설계인가

마지막으로 compaction 이라는 한 장치에 집중해서 왜 좋은 설계인지를 풀어 볼게요. 지금까지 본 개념들을 종합하는 복습 삼아요.

Compaction 은 긴 세션에서 앞쪽 대화가 컨텍스트 한도를 압박할 때, 앞 대화를 요약으로 치환하는 기법이에요. 얼핏 보면 “그냥 요약 교체” 같지만 디테일이 여럿 있어요.

(1) 자동 요약과 수동 개입의 균형. Compaction 은 자동으로 일어나지만, 사용자는 그 시점을 알 수 있고 필요하면 수동으로 유발할 수도 있어요. 이건 모델의 “기억 정리” 를 블랙박스로 두지 않고 사용자에게 공개하는 설계예요. 아까 얘기한 “뭘 기억하고 뭘 잊는지 통제 가능해야 한다” 는 원칙을 지키는 방식이에요.

(2) 원본 보존. 요약으로 치환되는 것은 “프롬프트에 붙는 것” 이지, 실제 파일이나 도구 호출 결과는 디스크에 그대로 남아 있어요. 모델이 “아 이 부분 원본이 필요해” 라고 판단하면 파일 읽기 tool 로 다시 꺼낼 수 있어요. 요약의 손실을 뒤에서 회복할 경로가 열려 있는 구조예요. 이게 단순 요약 시스템과의 결정적 차이예요.

(3) 세션 지속. Compaction 덕분에 대화가 수백 턴으로 길어져도 세션이 안 끊겨요. Context window 한계를 우회하는 실용적 장치가 되는 거예요. 이건 session memory 의 한계 (토큰 한도에 걸리면 앞이 잘림) 를 소프트하게 푸는 방식이에요.

(4) Long-context 시대에도 유효한 이유. 1M 토큰 모델이 나와도 compaction 이 필요해요. 왜냐하면 (a) 1M 토큰 입력은 비싸요. 꽉 채워서 매번 보내면 비용이 쌓이죠. (b) Lost in the middle 이 있어요. 꽉 채운다고 다 잘 쓰이는 게 아니에요. (c) 긴 프롬프트는 레이턴시가 커요. 사용자 경험이 나빠져요. 그래서 컨텍스트가 아무리 커져도 “지금 필요한 만큼만 프롬프트에 유지한다” 라는 원칙은 남아요. Compaction 이 그걸 자동화하는 거예요.

이 설계가 던지는 메시지는 이거예요. “긴 컨텍스트와 지속 기억은 둘 중 하나를 고르는 문제가 아니라, 서로를 보완하게 잘 엮는 문제다.” Claude Code 는 세션 내 context 는 compaction 으로 관리하고, 세션 간 memory 는 파일 기반 persistent memory 로 관리해요. 두 층이 분리돼 있고, 각자의 역할이 명확해요. 그래서 사용자가 “AI 의 기억 상태” 를 혼란스러워하지 않아요.

이 섹션이 이 글의 핵심 통찰 중 하나예요. 좋은 AI 시스템은 “1M 토큰을 제공하느냐” 나 “memory 기능이 있느냐” 같은 단일 축으로 판단되는 게 아니라, context 와 memory 의 역할 분리가 깔끔하게 설계돼 있는가 로 판단돼요. 이 감각을 갖고 제품을 평가하기 시작하면 기술 뉴스가 완전히 다르게 읽힐 거예요.

12. 한 문장 닫음

Context window 는 “이번 호출에 쓸 수 있는 종이 양”, session memory 는 “앱이 앞 대화를 매번 재첨부하는 행동”, persistent memory 는 “세션을 넘어서 남는 저장소 또는 가중치”. 셋은 완전히 다른 메커니즘이고, “Claude 1M 토큰” 이라는 헤드라인은 이 중 첫 번째만 키운 거다. 기억력 향상이 아니라 작업대 확장이다. 이 세 축을 분리해서 보면 긴 컨텍스트, Memory 기능, RAG, Doc-to-LoRA 모두 같은 지도 위에서 읽힌다.

다음 읽기

M3 — AI Agent 심화 [준비 중]
M1 — Retrieval Layer가 왜 필요한가 [이미 발행]

시리즈 처음부터: F1~F6 기초 · B1~B3 배경 · M1 Retrieval

자주 묻는 질문 (FAQ)

Q1. 그럼 “Claude 1M 토큰” 은 아무 의미가 없는 건가요?

의미 없는 건 절대 아니에요. “한 번의 호출에서 다룰 수 있는 자료의 양” 이 극적으로 커졌다는 건 큰 진보예요. 긴 논문 요약, 대용량 코드 리뷰, 1 회성 대량 데이터 분석 같은 작업이 전과는 비교가 안 될 정도로 쉬워져요. 다만 이게 “세션을 넘어서 기억하는 능력” 의 향상은 아니다 는 점이 포인트예요. 작업대가 커진 거고, 기억력이 생긴 게 아니에요. 두 가지를 섞어서 과대평가하지 않으면 정확한 기대치를 세울 수 있어요.

Q2. ChatGPT Memory 기능에 개인 정보를 맡겨도 되나요?

기능 자체의 안전성은 OpenAI 의 보안 수준에 의존해요. 기술적으로는 당신 계정에 속한 노트 파일이지만, 외부 서버에 저장된다는 점은 잊지 마세요. 개인적인 선호도, 식이 제한, 취미 같은 건 맡겨도 큰 리스크는 아닙니다. 하지만 민감한 의료 정보, 금융 정보, 회사 기밀 을 맡기는 건 추천드리기 어려워요. 한번 저장된 노트는 당신이 지울 수 있지만, 로그나 백업이 어떻게 관리되는지는 투명하지 않아요. 기업 환경이라면 더더욱 조심해야 하고요. 민감한 건 자체 저장소에서 관리하고, 일반적인 건 AI 에게 맡기는 이중 구조가 안전해요.

Q3. 긴 컨텍스트와 RAG 중에서 하나만 선택해야 한다면?

하나만 선택하는 문제가 아닌 게 핵심인데, 굳이 고르라면 “자료가 자주 바뀌냐 안 바뀌냐” 를 기준으로 해 보세요. 최신성이 중요한 실시간 데이터, 주기적으로 업데이트되는 문서 세트라면 RAG 가 유리해요. 바꿀 때마다 저장소만 갱신하면 되거든요. 반대로 1 회성 분석, 자료 간 관계 파악, 즉석 실험 이라면 long-context 가 편해요. 프롬프트에 다 붙여서 한 번에 훑는 게 빠르거든요. 실제 프로덕션 시스템에서는 두 개를 섞어 써요. RAG 로 관련 부분을 뽑고, long-context 안에 예쁘게 배치해서 처리하는 식으로. 둘 중 하나가 죽는 일은 당분간 없을 거예요.

뉴스레터 구독 안내

매주 월요일, AI·LLM·에이전트 관련 실무 정리를 한 통씩 보내드립니다. 이런 기술 해설을 차분히 쌓아가고 싶으시면 구독해 주세요.

뉴스레터 구독하기

시리즈 안내 (AI 공부 지도 20부작)
– F1~F6: 기초 (LLM / 토큰 / 임베딩 / Transformer / 딥러닝)
– B1~B3: 배경 (Attention, scaling, pretraining)
– M1: Retrieval Layer가 왜 필요한가
– M2: 긴 컨텍스트와 기억은 같은 말이 아니다 (현재 글)
– M3: AI Agent 심화
– (이하 20편까지)

📍 AI 공부 지도 — 15/29편

이 글은 AI의 기초부터 Meta-Harness·응용 비교까지 순서대로 읽는 29편 시리즈의 15편입니다.
📚 전체 지도 보기

← 이전 편: M1. Retrieval Layer · 다음 편: M3. Agent 심화 →

💡 이 편의 한 줄 요약

Claude 1M 토큰이 “AI 기억력 향상”이 아닌 이유. context window·session memory·persistent memory 3가지를 분리하면 lost-in-the-middle까지 보인다.

소스 리스트

태일러 지식백과사전 — AI 공부 지도 카테고리 (본 시리즈 20편 전체)
AI 공부 지도 엔트리맵 — 전체 구조 + 3가지 독법
“Attention Is All You Need” (Vaswani et al., 2017)
Anthropic · OpenAI · Google 공식 docs
mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown 영상 — 쉬운 설명 레퍼런스

著者: 바이브코딩 태일러 (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ “AI 공부 지도” 22편은 위키 자료와 공식 논문·공식 문서를 근거로 정리한 체계적 학습 커리큘럼입니다.

Post Views: 19