SEUNGWON.GO
AI 프로덕트 · 관점

AI에게 모든 대화를 기억시키는 것이 정말 좋은 설계일까

AI의 기억은 얼마나 많이 넣을 수 있느냐의 문제가 아니라, 무엇을 지금 기억해야 하는지를 결정하는 문제에 가깝다.

AI 프로덕트 개발기 · 글 고승원

도도네를 개발하면서 예상보다 훨씬 많은 고민을 하고 있는 부분이 있다. 바로 채팅창에서 대화의 맥락을 어떻게 이어갈 것인가이다. AI 에이전트 서비스를 만들다 보면 처음에는 단순하게 생각하기 쉽다.

이전 대화를 전부 컨텍스트에 넣으면 되는 것 아닌가?

모델의 컨텍스트 윈도는 계속 커지고 있다. 수십만 토큰은 물론이고 100만 토큰을 지원하는 모델도 등장했다. 그렇다면 사용자가 나눈 대화를 가능한 한 많이 모델에게 넣어주는 것이 가장 좋은 방법처럼 보인다. 하지만 도도네를 개발하면서 내린 결론은 조금 달랐다.

AI의 기억은 얼마나 많이 넣을 수 있느냐의 문제가 아니라, 무엇을 지금 기억해야 하는지를 결정하는 문제에 가깝다.

01 · The intuitive approach

긴 대화를 처리하는 가장 직관적인 방법

Claude Code나 Hermes 같은 AI 에이전트에서는 긴 작업을 이어가기 위해 Compaction이라는 방법을 사용한다. Anthropic 역시 장시간 실행되는 에이전트에서 컨텍스트를 관리하는 핵심 방법으로 compaction을 설명한다. 대화가 길어지면 오래된 대화 전체를 계속 유지하는 대신 중요한 내용을 요약하고, 최근 대화와 함께 새로운 컨텍스트를 구성하는 방식이다. Claude Code 역시 오래된 메시지와 작업 내용을 압축하면서 중요한 설계 결정이나 미해결 문제, 구현 정보 등을 보존한다.

Hermes의 구현은 조금 더 구체적이다. Hermes는 기본적으로 메시지가 몇 개인지를 기준으로 압축하지 않는다. 토큰 예산을 기준으로 한다. 현재 API 호출에서 사용된 실제 prompt token이 모델 컨텍스트 윈도의 일정 비율에 도달하면 자동으로 압축을 시작한다. 기본 threshold는 컨텍스트 윈도의 50%다. 다만 512K보다 작은 컨텍스트 모델에서는 너무 이른 압축을 막기 위해 최소 75%까지 threshold를 끌어올린다. 최근 메시지 일부는 원문 그대로 보호하고 가운데 구간을 요약하는 방식이다.

예를 들어 1M 토큰 컨텍스트를 사용할 수 있는 모델이라면 설정에 따라 상당히 긴 대화를 그대로 유지하다가 일정 수준에 도달했을 때 비로소 압축이 일어난다. 굉장히 합리적인 구조다. 특히 하나의 코딩 작업이나 리서치처럼 하나의 목표를 가지고 긴 시간 동안 계속 이어지는 작업에는 적합하다.

그런데 도도네는 조금 다른 문제를 가지고 있었다.

02 · Why not keep it all

도도네는 왜 전체 대화를 계속 넣지 않았을까

도도네는 AI 직원들이 일하는 가상의 오피스다. 한 명의 AI와 하나의 주제를 몇 시간 동안 깊게 이야기하는 구조만 존재하는 것이 아니다. 사용자는 마케팅 직원과 이야기하다가 개발 직원에게 일을 맡길 수도 있고, 프로젝트 채널에서 회의한 뒤 다시 특정 직원에게 후속 작업을 맡길 수도 있다. 그리고 하루가 지나 다시 그 직원을 찾아올 수도 있다.

즉 도도네에서 채팅은 단순한 대화창이 아니다. 업무가 발생하는 인터페이스다.

이 차이가 컨텍스트 설계를 바꿨다. 대화가 길어질 때 모든 과거 대화를 모델에게 계속 전달하면 기억은 많이 할 수 있다. 하지만 동시에 세 가지 문제가 생긴다.

첫 번째는 비용이다. LLM은 매 요청마다 컨텍스트를 다시 읽는다. 대화가 길어질수록 같은 과거 대화를 계속해서 모델에게 보내게 된다. 특히 매우 큰 컨텍스트 윈도를 가진 모델에서는 압축이 늦게 발생하면 세션 전체 비용이 크게 증가할 수 있다는 문제도 제기되고 있다. Hermes에서도 1M 컨텍스트 모델에서 기본 50% threshold라면 첫 compaction이 50만 토큰에서야 발생할 수 있다는 비용 관련 논의가 있다.

두 번째는 속도다. 입력 토큰이 많아지면 모델이 처리해야 할 정보가 많아진다. 굳이 이번 질문과 상관없는 몇 주 전 대화까지 매번 읽게 만들 필요는 없다.

하지만 내가 더 중요하게 본 것은 세 번째 문제였다. Context Pollution이다.

03 · More isn’t always better

컨텍스트는 많다고 항상 좋은 것이 아니다

Anthropic은 Context Engineering을 설명하면서 긴 컨텍스트에서도 정보의 관련성과 context pollution 문제가 계속 존재한다고 지적한다. 이것이 꽤 중요한 포인트다. 컨텍스트 윈도가 100만 토큰이라고 해서 100만 토큰을 채워 넣는 것이 가장 좋은 상태라는 뜻은 아니다.

예를 들어 마케팅 AI 직원과 사용자가 이런 이야기를 했다고 해보자. 지난주에는 신규 서비스의 브랜딩을 이야기했다. 며칠 전에는 인스타그램 광고 카피를 만들었다. 어제는 제품 가격 정책을 검토했다. 오늘은 보도자료를 작성해 달라고 한다.

기술적으로는 이 모든 대화를 모델에게 전달할 수 있다. 하지만 오늘 해야 할 일이 보도자료 작성이라면 몇 주 전 인스타그램 카피 수정 과정까지 원문 그대로 들어오는 것이 과연 도움이 될까? 오히려 현재 작업과 상관없는 정보가 판단에 개입할 가능성이 생긴다.

그래서 도도네에서는 처음부터 “얼마나 많은 대화를 넣을 것인가”보다 “얼마나 가까운 대화까지 원문으로 유지할 것인가”를 더 중요하게 봤다.

04 · DoDone’s approach

도도네의 방식: 최근은 선명하게, 과거는 압축해서

현재 도도네에서는 최근 8건의 작업을 상세 컨텍스트로 유지한다. AI 직원과의 대화는 약 20K자, 마스터 채널은 약 16K자의 상세 컨텍스트 예산을 사용한다. 최근 8건까지는 세부 내용을 최대한 그대로 유지하고, 그보다 오래된 대화는 Rolling Summary로 압축해 이전 맥락을 이어간다.

최근 8건은 가능한 한 원문에 가까운 상세 정보로 유지한다. 그리고 그보다 오래된 내용은 하나의 누적 요약으로 접어서 다음 대화로 넘긴다.

1~12번째 과거 업무Rolling Summary
13~20번째 최근 업무Detailed Context
현재 업무Current Mission

중요한 것은 오래된 대화를 삭제하는 것이 아니라 해상도를 낮추는 것이다. 최근 대화는 고해상도로 기억한다. 과거 대화는 저해상도로 기억한다.

나는 이 방식이 사람의 기억과도 꽤 닮아 있다고 생각한다. 우리는 일주일 전에 누군가와 나눈 대화를 문장 하나하나 기억하지 않는다. 하지만 “그 프로젝트에서 가격을 29달러로 결정했다.”, “고객 타깃은 솔로프리너로 정했다.”, “다음 작업은 랜딩페이지 제작이었다.” 같은 중요한 맥락은 남는다. AI의 장기 대화 역시 이런 구조가 더 자연스럽다고 판단했다.

05 · The limits of summaries

그런데 요약에도 한계가 있다

물론 Rolling Summary가 만능은 아니다. 요약은 결국 정보 압축이다. 압축이 반복될수록 세부 정보는 줄어들 수밖에 없다. 특히 20개, 30개, 50개의 업무가 하나의 대화에 계속 쌓이기 시작하면 또 다른 문제가 생긴다. 사용자가 실제로 같은 일을 계속하고 있는지조차 불분명해진다.

처음에는 마케팅 전략을 논의하다가 중간에는 홈페이지를 만들고 이후에는 채용 이야기를 하고 다시 콘텐츠 제작을 시작할 수도 있다. 기술적으로는 하나의 세션으로 계속 연결할 수 있다. 하지만 기술적으로 가능하다는 것과 좋은 UX라는 것은 다른 문제다. 그래서 도도네에는 최근 재미있는 장치를 하나 추가했다.

06 · AI suggests a new chat

AI가 먼저 “새 대화를 시작해보세요”라고 말한다

현재 세션에서 미션이 20건에 도달하면 도도네가 사용자에게 알려준다. 상세하게 유지되는 최근 8건과 Rolling Summary로 접힌 약 12건 정도의 업무가 누적된 시점이다. 그때 다음 메시지가 표시된다.

💡 이 대화가 꽤 길어졌어요. 주제가 바뀌었다면 새 세션 시작하기를 추천해요. 응답이 더 정확해지고 AI 사용료도 줄어듭니다. 이어서 진행해도 이전 흐름은 요약으로 유지돼요.

여기서 중요한 것은 강제로 세션을 종료하지 않는다는 것이다. 같은 프로젝트를 계속 진행하는 사용자라면 그냥 이어가면 된다. 하지만 주제가 이미 바뀌었다면 새 세션을 만드는 것이 훨씬 낫다. 새 세션이 만들어져도 필요한 이전 흐름은 요약된 컨텍스트를 통해 이어진다. 결국 선택권은 사용자에게 남긴다.

07 · Where to show it

이 알림을 어디에서 보여줄 것인가도 중요했다

긴 대화 알림을 단순히 메시지 개수에 따라 띄우는 것으로 끝내지 않았다. 도도네에서는 두 군데에서 이를 검사한다.

첫 번째는 업무 지시가 들어오는 순간이다. 직원과의 1:1 대화, 마스터 채널, 전체 채널, 미팅 후속 작업, 프로젝트 등 어떤 경로로 업무가 들어오든 지시가 접수된 직후 세션 길이를 비동기로 검사한다. 조건에 도달했다면 사용자가 방금 보낸 지시 아래에 자연스럽게 안내가 나타난다.

두 번째는 사용자가 채널에 진입하는 순간이다. 오피스에서 AI 직원을 클릭해 대화창을 열거나 프로젝트 채널에 들어갈 때 현재 세션의 상태를 검사한다. 이미 충분히 긴 세션이라면 새로운 메시지를 보내기 전이라도 바로 안내를 볼 수 있다.

그리고 같은 세션에서는 한 번만 알려준다. 사용자가 새 세션을 시작하면 다시 알림 가능한 상태가 된다. 아주 작은 UX지만 이런 것이 에이전트 서비스에서는 꽤 중요하다.

08 · Memory ≠ Context

AI 에이전트에서 Memory와 Context는 다르다

도도네를 만들면서 계속 명확해지고 있는 것이 하나 있다. Memory와 Context를 같은 것으로 보면 안 된다는 것이다.

Memory는 AI 직원이 장기간 알아야 할 정보다. 사용자의 선호. 회사의 정보. 업무 방식. 반복되는 규칙. 과거 프로젝트에서 결정된 중요한 사실. 이런 정보는 며칠 뒤나 몇 달 뒤에도 필요할 수 있다.

반면 Context는 조금 다르다. 지금 이 일을 하기 위해 필요한 작업 기억(Working Memory)에 가깝다. 바로 직전 요청. 현재 작업 중인 파일. 최근에 결정한 사항. 지금 해결해야 하는 문제. 이 둘을 모두 채팅 히스토리에 넣어 해결하려 하면 시스템이 금방 무거워진다.

그래서 좋은 에이전트 시스템은 결국 여러 층의 기억을 가지게 된다고 생각한다.

Current Mission

지금 수행하고 있는 일.

↓

Recent Context

최근 몇 개의 상세한 상호작용.

↓

Rolling Summary

과거 작업의 압축된 흐름.

↓

Long-term Memory

세션과 관계없이 장기간 유지해야 할 사실과 규칙.

모델의 Context Window는 이 가운데 필요한 것들을 그 순간 조합하는 공간일 뿐이다.

09 · Bigger windows, more engineering

컨텍스트 윈도가 커질수록 Context Engineering이 더 중요해진다

아이러니한 점이 있다. 모델의 컨텍스트 윈도가 작았던 시절에는 개발자가 어쩔 수 없이 정보를 줄여야 했다. 128K, 200K, 1M처럼 컨텍스트가 커지면서 이제는 많은 것을 넣을 수 있게 됐다. 그러자 새로운 문제가 생겼다. 무엇을 넣지 않을 것인가를 결정해야 한다.

좋은 AI 에이전트는 모든 것을 기억하는 AI가 아닐지도 모른다. 지금 필요한 것은 선명하게 기억하고, 오래된 것은 적절히 압축하고, 중요한 것은 장기 기억으로 옮기고, 주제가 달라지면 새로운 작업 공간을 만드는 AI.

결국 에이전트를 만들면서 점점 더 많이 하게 되는 일은 Prompt Engineering이 아니다. Context Engineering이다.

그리고 그 핵심 질문도 바뀌고 있다. 예전에는 “모델에게 무엇을 알려줄 것인가?”였다면, 지금은 오히려 “지금 이 순간, 모델이 무엇까지 알고 있어야 하는가?”에 가깝다.

AI에게 더 많은 것을 기억시키는 것보다, 필요한 것을 필요한 순간에 기억하게 만드는 것.

도도네를 개발하면서 내가 가장 오래 고민하고 있는 것도 바로 이 문제다. 아마 앞으로 AI 에이전트의 품질을 결정하는 중요한 차이는 여기에서 만들어질 것이라고 생각한다.

Context Engineering

더 많이 기억하는 AI가 아니라,
필요한 것을 필요한 순간에 기억하는 AI.

참고: Anthropic의 Context Engineering / 장시간 실행 에이전트의 compaction 설명, Hermes의 토큰 예산 기반 compaction 구현. 세부 수치·임계값은 버전·설정에 따라 달라질 수 있다.