AI 에이전트는 어떻게 기억할까? — 멀티턴과 메모리 컴팩션 쉽게 이해하기

AI 에이전트와 길게 대화하다 보면 신기한 순간이 옵니다. 분명 30분 전에 "내 이름은 병곤이야"라고 했는데도 한참 뒤에 "병곤님" 하고 불러 줍니다. 마치 사람처럼 기억하는 것 같죠. 그런데 동시에 이상한 일도 겪습니다. 아주 긴 대화에서는 갑자기 초반 내용을 잊거나, "대화가 너무 길어 일부를 정리했어요" 같은 메시지를 보게 됩니다.

이 두 가지는 사실 같은 한 가지 사실에서 나옵니다. LLM은 원래 아무것도 기억하지 못합니다. 에이전트가 기억하는 것처럼 보이는 건 똑똑한 설계 덕분이고, 그 설계의 한계가 드러나는 순간이 바로 "컨텍스트가 가득 찼을 때"입니다. 이 글은 그 원리를, 코드를 거의 쓰지 않고 비유로 풀어 봅니다.

이 글에서 배우는 것

• LLM이 사실은 매 턴마다 대화를 처음부터 다시 읽는다는 것 (기억상실증 비유)
• 그런데도 "기억하는 것처럼" 보이게 만드는 멀티턴의 진짜 원리
• 대화가 길어지면 왜 한계에 부딪히는가 — 컨텍스트 창이라는 책상
• 한계를 넘기는 핵심 기술 메모리 컴팩션(compaction) = 회의록 요약
• 무엇을 남기고 무엇을 버려야 하는가, 그리고 흔한 실패
• 세션이 끝나도 기억하게 하는 단기 vs 장기 메모리

1. 충격 사실: LLM은 기억상실증 환자입니다

영화에 종종 나오는, 몇 분이 지나면 방금 일을 잊는 단기 기억상실증 환자를 떠올려 봅시다. 이 환자와 제대로 대화하려면 어떻게 해야 할까요? 방법은 하나뿐입니다. 만날 때마다 지금까지의 대화를 통째로 다시 읽어 주는 것입니다.

LLM이 정확히 이렇습니다. 모델 자체는 대화를 저장하지 않습니다. 한 번 답을 만들고 나면, 방금 무슨 말을 했는지조차 잊습니다. 전문 용어로 이걸 stateless(상태 없음) 라고 부릅니다.

핵심: LLM은 "대화를 이어 가는" 게 아니라, 매번 처음 보는 긴 글 한 편을 읽고 다음 한 줄을 쓰는 기계입니다.

그럼 챗봇이나 에이전트는 어떻게 어제 한 말, 10분 전에 한 말을 아는 걸까요? 비밀은 모델이 아니라 모델을 감싸고 있는 프로그램(에이전트) 에 있습니다.

2. 멀티턴의 진짜 원리 — "매번 전체를 다시 보낸다"

여러 번 주고받는 대화를 멀티턴(multi-turn) 이라고 합니다. 한 번의 질문-답변이 한 "턴"이고, 그게 여러 번 이어지는 거죠. 멀티턴이 동작하는 원리는 생각보다 단순합니다.

에이전트는 매 턴마다, 모델에게 지금까지의 대화 전체를 다시 처음부터 적어서 보냅니다.

세 번째 턴에서 모델이 실제로 받는 입력은 이렇게 생겼습니다.

[시스템] 너는 친절한 도우미야.
[사용자] 내 이름은 병곤이야.
[도우미] 안녕하세요 병곤님!
[사용자] 내 이름이 뭐였지?

모델은 이 글을 처음 보는 것처럼 읽고, "병곤님"이라는 다음 줄을 만들어 냅니다. 기억해서 답한 게 아니라, 눈앞에 답이 적혀 있어서 답한 겁니다. 다음 턴에는 이 답까지 포함해서 또 통째로 보냅니다.

이 그림이 이 글에서 가장 중요한 한 장입니다. "기억"의 정체는 사실 "매번 다시 첨부하는 대화 기록" 입니다. 에이전트가 한다는 일의 절반은, 바로 이 첨부물을 어떻게 관리하느냐의 문제입니다.

한 문장으로: 멀티턴 = 모델의 기억력이 아니라, 에이전트가 대화 기록을 매번 다시 붙여 주는 부지런함.

3. 그런데 책상이 너무 작습니다 — 컨텍스트 창

여기서 자연스러운 의문이 듭니다. "그럼 대화가 1만 번 이어지면, 1만 턴짜리 글을 매번 다시 보낸다고?" 네, 바로 그게 문제입니다. 그리고 모델이 한 번에 읽을 수 있는 글의 길이에는 상한선이 있습니다. 이 상한선을 컨텍스트 창(context window) 이라고 부릅니다.

비유하자면 모델의 책상 크기입니다. 책상 위에 올려놓은 종이만 읽을 수 있고, 책상 밖에 있는 건 존재하지 않는 셈입니다. 책상에 올릴 수 있는 분량을 세는 단위를 토큰(token) 이라고 하는데, 대략 단어 한 개가 토큰 한두 개 정도라고 생각하면 충분합니다.

대화가 길어지면 이 책상이 어떻게 차는지 봅시다. 특히 에이전트는 챗봇보다 훨씬 빨리 책상이 찹니다. 사용자와의 대화뿐 아니라, 도구(툴) 사용 결과까지 책상에 쌓이기 때문입니다.

책상이 가득 차면 무슨 일이 벌어질까요? 세 가지 문제가 생깁니다.

• 넘침: 더 못 올립니다. 한도를 넘으면 아예 요청이 실패합니다.
• 중간을 흘림: 종이가 너무 많으면 모델은 맨 앞과 맨 뒤는 잘 보지만 가운데를 흘려 읽는 경향이 있습니다(흔히 "Lost in the Middle"이라고 합니다).
• 느리고 비쌈: 매 턴 책상 전체를 다시 읽으니, 길수록 응답이 느려지고 비용도 올라갑니다.

그래서 긴 대화에서 갑자기 초반 내용을 잊은 듯한 에이전트는, 사실 기억을 잃은 게 아니라 책상에서 그 종이를 치운 것입니다. 무엇을 치울지가 다음 주제입니다.

4. 핵심 기술: 메모리 컴팩션 = 회의록 요약

책상이 꽉 차 가는데 대화는 계속해야 한다면, 우리는 직관적으로 무얼 하나요? 오래된 종이를 한 장으로 요약해서 자리를 비웁니다. 긴 회의가 끝나면 한 페이지 회의록을 남기고 발언 녹취록은 버리는 것과 똑같습니다.

이것이 바로 메모리 컴팩션(memory compaction) 입니다. 이름이 거창하지만 개념은 단순합니다.

컴팩션: 컨텍스트(책상)가 거의 다 차면, 오래된 대화 기록을 핵심만 요약본으로 압축해 자리를 회수하는 것.

그림으로 보면 이렇습니다.

핵심 감각 두 가지만 챙기면 됩니다.

1. 최근 대화는 건드리지 않습니다. 방금 한 말은 가장 중요하니 원문 그대로 둡니다. 압축 대상은 오래된 종이입니다.
2. 요약은 모델에게 시킵니다. "지금까지의 대화를 핵심만 정리해 줘"라고 LLM에게 한 번 더 부탁해, 그 결과로 옛 기록을 대체합니다.

말은 쉽지만, 여기엔 위험한 함정이 하나 있습니다. 무엇을 요약에 남기고 무엇을 버리느냐입니다. 잘못 버리면 에이전트가 "방금 정한 것"을 잊고 엉뚱한 길로 갑니다.

5. 무엇을 남기고, 무엇을 버릴까

회의록을 쓸 때를 생각해 봅시다. "누가 몇 시에 물을 마셨다"는 안 적지만, "다음 주까지 A안으로 진행하기로 결정"은 반드시 적습니다. 컴팩션도 똑같은 판단을 합니다.

특히 에이전트에서 책상을 가장 많이 잡아먹는 도구 출력을 다루는 요령이 중요합니다. 예를 들어 200줄짜리 파일을 읽었다면, 그 200줄을 통째로 남기는 대신 "그 파일에서 X 함수가 Y를 한다는 걸 확인함" 같은 한 줄 결론과 어디서 다시 읽을 수 있는지 위치 포인터만 남기면 됩니다. 원본이 다시 필요하면 그때 또 읽으면 되니까요.

컴팩션의 본질은 "삭제"가 아니라 번역입니다. 길고 원시적인 기록을, 짧고 의미 있는 결론으로 옮겨 적는 일입니다.

좋은 요약은 정해진 틀이 있다

자유 서술로 "음, 우리는 이런저런 얘기를 했고…"라고 요약하면 중요한 게 빠지기 쉽습니다. 그래서 실무에서는 빈칸을 채우는 양식으로 요약을 강제합니다. 모델에게 이런 틀을 주는 식입니다.

지금까지의 대화를 아래 항목으로 정리해 줘. 빈 항목은 "없음"이라고 적어:
 
- 사용자의 목표:
- 지금까지 내린 결정/제약:
- 현재 진행 중인 작업:
- 알아낸 핵심 사실:
- 다음에 할 일:

자유 작문 대신 이런 틀을 쓰면, "현재 진행 중인 작업" 칸이 비는 사고를 눈에 띄게 줄일 수 있습니다. 양식이 곧 안전장치인 셈입니다.

언제 압축을 시작할까

너무 일찍 하면 멀쩡한 맥락을 잃고, 너무 늦으면 책상이 넘쳐 요청이 실패합니다. 가장 흔한 기준은 책상이 일정 비율 차면 작동시키는 것입니다.

if 사용한 토큰 / 컨텍스트 창 크기 > 0.8:
    오래된 절반을 요약본으로 압축

대략 70~80%가 찼을 때 트리거를 거는 게 보통입니다. 가득 차기 직전까지 기다리지 않고, 여유가 있을 때 미리 정리해 두는 것이죠.

6. 세션이 끝나도 기억하려면 — 단기 vs 장기 메모리

지금까지 이야기한 컴팩션은 하나의 대화 안에서 책상을 정리하는 기술입니다. 이걸 단기 기억(working memory) 이라고 부를 수 있습니다. 책상 위에 펼쳐 둔, 지금 당장 쓰는 종이들이죠.

그런데 우리가 진짜 원하는 건 다릅니다. 오늘 대화를 닫고 내일 새 창에서 다시 열어도 "아, 어제 그 프로젝트요" 하고 알아보는 것. 단기 기억만으로는 안 됩니다. 책상은 대화가 끝나면 깨끗이 치워지니까요. 여기서 장기 기억(long-term memory) 이 필요합니다.

장기 기억의 핵심은 "책상 밖 어딘가에 적어 두고, 필요할 때만 꺼내서 책상에 올린다"는 것입니다. 구현 방식은 크게 둘입니다.

• 검색형(RAG 메모리): 옛 대화·문서를 외부 저장소에 넣어 두고, 지금 질문과 관련된 조각만 검색해서 책상에 올립니다. 양이 방대할 때 적합합니다.
• 파일형(사실 메모): "사용자 이름=병곤", "선호 언어=한국어" 같은 핵심 사실을 작은 파일로 적어 두는 방식. 다음 세션을 시작할 때 이 메모만 책상에 먼저 깔아 둡니다. (이 블로그를 만드는 도구도 정확히 이 방식의 메모리를 씁니다 — 한 파일에 한 가지 사실.)

두 방식의 공통점이자 핵심은, 책상(컨텍스트 창)은 비싸고 작으니, 평소엔 서랍에 넣어 두고 필요한 것만 그때그때 올린다는 절약 정신입니다.

7. 입문자가 자주 놓치는 디테일 하나

마지막으로 실무에서 의외로 자주 데는 함정 하나만 짚겠습니다. 바로 컴팩션과 "프롬프트 캐싱"의 상충입니다.

많은 LLM 서비스는 속도·비용을 줄이려고 프롬프트 캐싱을 씁니다. 매번 똑같이 앞에 붙는 대화 앞부분을, 모델이 "이건 아까 그거"라며 빠르게 재사용하는 기능입니다. 책상 앞쪽 종이를 손대지 않으면 캐시가 잘 듣습니다.

그런데 컴팩션은 바로 그 앞쪽 종이를 통째로 바꿔 끼웁니다. 오래된 대화를 요약본으로 갈아 끼우는 순간, 캐시는 "어, 앞부분이 달라졌네?" 하며 무효가 됩니다. 그래서 컴팩션 직후 한 번은 응답이 느리고 비싸질 수 있습니다.

교훈: 컴팩션은 공짜가 아닙니다. 책상을 비워 멀리 갈 수 있게 해 주지만, 비우는 그 순간엔 캐시를 버리는 비용을 치릅니다. 그래서 매 턴 조금씩이 아니라, 임계치에 다다랐을 때 한 번에 크게 정리하는 편이 유리합니다.

8. 정리 — 한 장 요약과 체크리스트

길게 돌아왔지만, 사실 전부 한 문장으로 모입니다.

LLM은 기억하지 못한다. 그래서 에이전트는 매 턴 대화를 다시 붙여 주고(멀티턴), 책상이 차면 옛 기록을 요약으로 압축하며(컴팩션), 세션을 넘겨 기억할 것은 서랍에 적어 둔다(장기 메모리).

에이전트의 메모리를 직접 설계하거나 고를 때 점검할 항목입니다.

• 무엇을 남길지 기준이 있는가 (목표·결정·사실 vs 중복 출력·막다른 길)
• 요약을 자유 작문이 아니라 양식으로 강제하는가
• 컴팩션 트리거 시점이 정해져 있는가 (예: 책상 70~80%)
• 큰 도구 출력을 결론+위치 포인터로 줄이는가
• 세션을 넘는 기억을 위한 장기 메모리가 분리돼 있는가
• 컴팩션의 캐시 비용을 고려했는가

AI 에이전트가 "똑똑하게 기억한다"는 인상은, 사실 이 단순한 살림살이들을 부지런히 해낸 결과입니다. 마법이 아니라 정리 정돈인 셈이죠.

🔧 심화학습 — 직접 구현해 보기 이 글이 왜 그런 설계가 필요한지를 비유로 풀었다면, 후속편 에이전트 메모리 컴팩션, 직접 구현하기 — 멀티턴 루프부터 캐시·장기 메모리까지는 어떻게 만드는지를 Anthropic SDK 기반 파이썬 코드와 다이어그램으로 한 줄씩 구현합니다. 멀티턴 루프, count_tokens로 토큰 측정, 임계치 컴팩션 엔진(분할→요약→치환), 도구 출력 축약, 프롬프트 캐싱과의 상충 해결, 장기 메모리 승격까지를 묶어 동작하는 Agent 클래스 한 벌로 정리합니다.

다음 글 예고: 이 시리즈에서는 곧 장기 메모리를 RAG로 구현하는 법과, 여러 에이전트가 기억을 나눠 갖는 멀티 에이전트 메모리를 같은 입문자 눈높이로 다룰 예정입니다.