야, 이거 봤어? AI 에이전트가 기억하는 방식에 에빙하우스 망각 곡선을 적용한 프로젝트가 나왔어. `YourMemory`라는 건데, 마치 사람처럼 안 쓰는 정보는 잊어버리고 자주 쓰는 건 더 오래 기억하게 만든다는 거야.
솔직히 그동안 AI 에이전트 개발할 때, 맥락(Context)을 어떻게 잘 유지하느냐에만 초점을 맞췄잖아. 길게 가져갈수록 더 똑똑해질 거라 생각했지. 근데 `YourMemory` 프로젝트 개발자가 그러더라. "모든 대화를 기억하는 에이전트의 가치를 모르겠어요. 오히려 생산성을 해치는 것 같아요." 이 말에 확 공감이 가더라.
불필요한 기억은 독이다
`YourMemory`의 핵심은 기존 RAG(Retrieval-Augmented Generation) 시스템이 겪는 문제점, 그러니까 정적인 파일 캐비닛처럼 모든 걸 쌓아두다가 불필요한 노이즈로 맥락 창이 질식하는 문제를 해결하는 거야. 토큰 비용도 엄청나게 상승하고, 에이전트 추론 능력도 떨어지는 문제가 있었지.
이 시스템은 메모리에 '강도' 점수를 부여해서, 호출될 때마다 기억을 강화하고 망각 곡선을 평탄하게 만들어. 반대로 사용되지 않는 데이터는 점차 잊혀지고, 특정 임계점에 도달하면 아예 정리되는 방식이야. 로코모 데이터셋으로 벤치마크해 보니, `Recall@5`에서 52%의 정확도를 보여서, 기존의 정적인 벡터 스토어보다 거의 두 배의 정확도를 내면서 토큰 낭비는 84%나 줄였다고 해.
결국, "무엇을 기억해야 할지"만큼 "무엇을 잊어야 할지"가 에이전트에게 중요하다는 거지.
코그니션도 '버리기'로 선회하다
이 `잊기`의 중요성은 `Devin`을 만든 코그니션(Cognition)의 최근 입장 변화에서도 엿볼 수 있어. 코그니션은 10개월 전에는 멀티 에이전트가 비효율적이라고 했거든. 에이전트 간 맥락을 공유해야 제대로 작동한다고 말했지. 그런데 최근 입장을 180도 바꿨어.
이제는 "맥락을 공유하지 않아야 더 잘 작동하는 구조"를 발견했다고 해. 코딩 에이전트가 몇 시간 동안 쌓은 긴 맥락은 오히려 어텐션을 분산시켜 '맥락 부패(Context Rot)'를 유발한다는 거야. 반면, 코드 리뷰 에이전트가 백지 상태에서 코드 변경점(diff)만 보고 검토하면, 짧은 맥락 덕분에 훨씬 정확하게 버그를 잡아낸다고 해.
사람도 자기가 쓴 코드의 실수를 잘 못 찾잖아. 에이전트도 마찬가지라는 거지. 맥락을 분리해서 새로운 시각으로 보면 버그 발견율이 확 올라가고, 자연스럽게 비용도 절감되는 효과가 나타난다는 거야. `Devin Review`가 PR당 평균 2개의 버그를 찾고, 그중 58%가 로직 오류나 보안 취약점이었다니, 이 방식이 통한다는 걸 보여주는 사례지.
README가 대시보드가 되는 시대
이런 '똑똑하게 덜어내기'나 '분리하기'의 연장선상에서 흥미로운 또 다른 사례가 있어. `clawsweeper`라는 자동화 도구 이야기인데, 이 도구는 GitHub 레포지토리의 이슈와 PR을 스스로 관리하면서 레포의 현재 상태를 `README` 파일에 실시간으로 업데이트해. 말 그대로 `README`가 새로운 대시보드 역할을 하는 거야.
이게 왜 중요하냐면, 우리는 보통 프로젝트 상태를 보려면 별도 대시보드 페이지를 만들고 그곳에 정보를 띄우려고 하잖아. 그런데 `clawsweeper`는 `README`라는, 이미 모두가 읽는 핵심 문서를 살아있는 상태판으로 활용하는 거야. 레포가 스스로 자신의 상태를 설명하고, 할 일을 정리하고, 운영 기록을 남기는 시대가 온다는 거지. 이건 에이전트가 자신의 '맥락'을 직접 정리하고 노출하는 또 다른 방식 아닐까?
에이전트 시스템 설계의 새로운 관점
이 세 가지 사례에서 공통으로 얻는 인사이트는 이거야. AI 에이전트 시스템을 만들 때, 무조건 많은 정보를 기억시키고, 모든 에이전트가 모든 맥락을 공유하게 하는 것이 능사는 아니라는 점이야.
오히려 불필요한 정보는 과감히 잊게 하고, 복잡한 작업은 맥락을 분리해서 전문 에이전트에게 맡기고, 심지어는 작은 모델과 큰 모델을 적절히 조합해서 비용 효율을 높이는 `Smart Friend` 같은 방식도 고려해야 해. `Smart Friend`는 아직 초기 단계지만, 프론티어 모델의 높은 비용을 고려하면 이런 방식이 필수가 될 거야.
결국, AI 에이전트 개발의 다음 단계는 '더 많이'가 아니라 '더 현명하게' 정보를 다루는 데 있다는 걸 보여주는 사례들이지. 어떤 정보를 기억하고, 어떤 정보를 잊고, 어떻게 정보를 분리해서 작업 효율을 높일지 고민하는 것이 중요해.
지금 우리가 만들고 있는 에이전트 시스템에서, 혹시 불필요한 맥락 때문에 성능이나 비용 문제를 겪고 있진 않아?