진짜 문제는 메모리였는데, 몇 달 동안 모델을 탓했습니다
요약
AI 에이전트 사용 시 발생하는 컨텍스트 유실 문제를 모델의 성능 탓이 아닌 설계의 문제로 분석합니다. 효과적인 에이전트 활용을 위해 대화, 사용자 선호도, 프로젝트 정보, 라이브 상태라는 4단계 메모리 스택 구축의 필요성을 강조합니다.
핵심 포인트
- 에이전트의 기억력 문제는 모델 성능보다 컨텍스트 설계의 결함임
- 메모리는 대화, 사용자, 프로젝트, 라이브 상태의 4개 계층으로 구분됨
- 단순 대화 기록을 넘어 프로젝트의 제약 조건과 결정 사항을 구조화해야 함
- 에이전트가 매 세션마다 맥락을 즉시 파악할 수 있는 '집'을 제공해야 함
매일 아침 나는 세션을 열고 처음부터 다시 시작했습니다.
업무가 아니라, 설명하는 것 말입니다.
클라이언트가 누구인지. 지난주에 우리가 무엇을 결정했는지. 왜 그 파일이 그런 상태인지. 나에게는 명백하지만 도구에게는 보이지 않는 세 가지 제약 사항들까지 말이죠.
나는 그 모든 것을 다시 타이핑했습니다. 그리고 다음 날 또다시 반복했습니다.
몇 달 동안 나는 모델이 문제라고 스스로에게 말했습니다. 더 똑똑한 모델이라면 기억할 것이라고. 더 큰 컨텍스트 윈도우 (Context Window)가 이를 해결해 줄 것이라고. 나는 도구가 나를 따라잡기를 기다리고 있었습니다.
여기 내가 인정하고 싶지 않았던 부분이 있습니다.
도구가 내 프로젝트를 담아내지 못할 것이라는 점입니다. 내가 담아내야 했습니다.
전체적인 멘탈 모델 (Mental Model)은 내 머릿속에만 존재했습니다. 에이전트 (Agent)는 마지막 20개의 메시지만을 가지고 있었고 그 외에는 아무것도 없었습니다. 매 세션마다 에이전트는 기억상실증에 걸린 채 깨어났고, 나는 실제 업무가 시작되기도 전에 세상을 재구축하는 비용을 지불해야 했습니다.
만약 당신이 AI 에이전트와 함께 작업한다면, 당신도 바로 이런 아침을 경험해 보았을 것입니다. 세션을 엽니다. 에이전트는 잊어버렸습니다. 당신은 설명을 시작합니다. 그리고 재맥락화 (Re-context)의 세 번째 문단쯤에 도달하면, 내가 뒤처진 것인지 아니면 도구가 뒤처진 것인지 의구심이 들기 시작합니다.
당신은 뒤처진 것이 아닙니다. 당신은 계층 (Tiers)을 놓치고 있는 것입니다.
그것이 저에게 전환점이 되었습니다. 나는 메모리를 모델이 가지고 있거나 가지고 있지 않은 단일 요소로 취급하는 것을 그만두었습니다. 그것은 단일 요소가 아닙니다. 그것은 스택 (Stack)입니다.
첫 번째는 '이 대화'에 대한 메모리입니다. 짧고, 날카로우며, 윈도우 (Window)가 닫히면 사라집니다.
두 번째는 '당신'에 대한 메모리입니다. 당신의 선호도, 당신의 말투, 당신이 일을 처리하는 방식입니다. 이것은 모든 세션에서 유지되어야 하지만, 대부분의 사람들에게는 그렇지 못합니다. 왜냐하면 그것이 에이전트가 읽을 수 있는 곳이 아닌, 그들의 머릿속에만 존재하기 때문입니다.
세 번째는 '프로젝트'에 대한 메모리입니다. 결정 사항, 제약 조건, 코드 뒤에 숨겨진 이유들입니다. 이것은 잃어버렸을 때 비용이 가장 많이 드는 메모리입니다. 왜냐하면 이것을 잃는다는 것은 이미 결정한 것들을 다시 결정해야 함을 의미하기 때문입니다.
마지막으로 '지금 현재 무엇이 사실인가'에 대한 메모리가 있습니다. 라이브 상태 (Live State)입니다. 무엇이 배포되었는지, 무엇이 고장 났는지, 어제 이후로 무엇이 바뀌었는지에 대한 정보입니다.
대부분의 팀은 첫 번째 것, 즉 대화만을 사용합니다. 그것이 전부입니다.
당신이 실제로 원하는 유지력(retention)은 나머지 세 가지에 들어 있습니다. 그 중 어느 것도 자동으로 이루어지지 않습니다. 당신은 각 항목에 무엇이 포함될지 결정해야 하며, 당신이 머릿속에 담아두고 매번 입 밖으로 내뱉으며 수행해야 하는 방식이 아니라, 에이전트가 깨어날 때마다 만날 수 있는 '집'을 제공해야 합니다.
저는 불편한 의견을 솔직하게 말씀드리겠습니다.
매일 아침 당신이 다시 설명해야 하는 컨텍스트(context)는 모델이 당신을 실망시킨 것이 아닙니다. 그것은 당신이 에이전트를 설정하는 방식에서의 설계 결함(design gap)입니다. 해결책은 더 똑똑한 모델이 아닙니다. 에이전트가 항상 알고 있어야 할 것이 무엇인지 단 한 번 결정하는 것입니다.
제가 마침내 그렇게 했을 때, 아침이 바뀌었습니다. 세션이 빈 상태로 깨어나지 않았습니다. 제가 다시 설명할 필요 없이, 클라이언트, 제약 조건(constraints), 마지막 결정 사항들을 알고 있는 상태로 깨어났습니다.
속도가 되살아났습니다. 더 중요한 것은 정신적 부하(mental load)였습니다. 저는 프로젝트 전체를 제 머릿속에 유일한 진실의 원천(single source of truth)으로 담아두고 있었고, 그 무게를 나누어 갖지 않는 도구에 대해 조용히 원망해 왔습니다. 그 무게가 제 머리 밖으로 옮겨지는 순간, 작업은 예상치 못한 방식으로 가벼워졌습니다.
여기에 숨겨진 트레이드오프(tradeoff)가 있으며, 이를 명확히 짚고 넘어갈 가치가 있습니다.
에이전트가 기억할 수 있도록 무언가를 기록하는 것은 당장에는 더 느립니다. 마치 오버헤드(overhead)처럼 느껴집니다. 매번 새로 타이핑하는 것이 오늘 당장은 더 빠르기 때문에 더 빠르게 느껴질 수 있습니다. 하지만 그 비용은 눈에 보이는 청구서 대신 매일 조금씩 나누어 지불하기 때문에 보이지 않습니다.
저는 그 보이지 않는 청구서를 몇 달 동안 지불했습니다. 매일 아침 아주 작은 조각으로, 눈치채지 못한 채, 항상 존재했습니다.
그래서 진짜 질문은 이것입니다. 도구에 관한 것이 아닙니다.
당신의 에이전트가 당신에게 유용하기 위해 실제로 알아야 하는 것은 무엇이며, 그것은 지금 어디에 있습니까? 만약 정직한 답변이 '당신의 머릿속'에 있고, 당신이 그것을 다시 타이핑하고 있다면, 그것이 바로 결함(gap)입니다. 모델의 문제가 아닙니다.
저는 여전히 어떤 계층(tier)에 무엇을 담을지 조정하고 있습니다. 프로젝트에 속한다고 생각했던 어떤 것들은 사실 저에게 속한 것이었습니다. 영구적이라고 취급했던 어떤 것들은 실시간 상태(live state)였고 빠르게 노후화되었습니다. 계층을 잘못 설정하는 것 또한 그 자체로 하나의 교훈입니다.
하지만 저는 모델이 제 프로젝트를 기억해주기를 기다리는 것을 그만두었습니다.
대신 에이전트에게 메모리(memory)를 주기로 결정했습니다.
이제 당신의 차례입니다
당신은 세션 사이에 에이전트가 프로젝트를 잊어버리는 것을 어떻게 방지하시나요?
이 내용이 유용했다면
저는 성공과 정체기를 모두 포함하여 이 과정을 공개적으로 진행하고 있으며, 주로 LinkedIn과 YouTube에서 활동하고 있습니다. 공개적으로 빌드하는(building in the open) 실제 과정이 여러분에게 유용하다면, 그곳에서 확인하실 수 있습니다. X, GitHub에서 저를 찾으실 수 있으며, 작업물은 next8n.com에서 보실 수 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기