세션 기록을 기억하는건 에이전트에 유용하지 않음

 (12gramsofcarbon.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • SWE 작업에서 에이전트가 문서·PR·커밋 같은 컨텍스트를 이미 볼 수 있다면, 과거 세션 기록 검색은 성능 이점을 만들지 못했음
  • 흔한 구현은 모든 transcript를 DB에 저장한 뒤 벡터 검색, Elasticsearch, SQL 검색, 그래프를 붙여 MCP나 CLI skill로 노출하지만, 여러 달의 비교 테스트에서 차이를 만들지 못했고 때로는 모델 품질을 떨어뜨릴 수 있었음
  • 좋은 커밋 메시지, PR 메시지, 문서, 메타데이터가 남는 환경에서는 중요한 정보가 이미 코딩 산출물에 정리되어 있어, 세션 기록은 중복 정보와 임시 메모를 토큰으로 다시 읽게 만듦
  • 에이전트는 장기 기억에 필요한 컨텍스트 제거를 잘하지 못하며, 상태가 없기 때문에 입력 컨텍스트의 코드·메모·토큰을 모두 의도로 취급해 intent drift가 누적될 수 있음
  • 세션 기록은 팀 관측성에는 쓸모가 있을 수 있지만 성능 개선 수단으로는 부정적이며, nori bots의 주간 변경 제안도 사람이 diff를 검토해야 했고 실제 수락률은 20% 미만이었음

세션 기록 검색이 성능을 높이지 못한 이유

  • SWE 작업에서 과거 세션 기록을 검색하게 해도, 다른 컨텍스트가 있는 조건에서는 성능 이점이 0으로 나타남
  • 세션 기록을 자동으로 훑어 에이전트 컨텍스트를 개선하려는 시도도 사람 검토 없이는 큰 이점이 없었음
  • 흔한 세션 기반 메모리 아키텍처는 다음 흐름을 가짐
    • 조직 전체의 모든 transcript를 DB에 저장
    • 그 위에 벡터 검색, Elasticsearch, SQL 검색 계층을 추가
    • 더 야심적인 팀은 세 가지를 모두 쓰고 그래프도 포함
    • MCP나 skill이 있는 CLI로 에이전트에 노출
  • 여러 달 동안 세션 검색 접근 유무를 비교한 결과, 이 추가 작업은 차이를 만들지 못했고 경우에 따라 모델을 더 나쁘게 만들 수 있었음
  • 유용한 정보는 이미 코딩 산출물에 정리되어 있음
    • 코드 변경에는 좋은 커밋 메시지, PR 메시지, 포괄적 문서, 코드와 함께 커밋되는 메타데이터가 포함됨
    • 에이전트는 특정 코드를 작업할 때 문서와 이전 PR을 보도록 지시받음
    • 세션 기록 검색은 이미 아는 내용을 다시 읽게 하고, 처음부터 기록하지 않기로 한 임시 판단과 스크래치패드까지 토큰으로 소비하게 만듦

자동 메모리가 흔들리는 지점

  • 에이전트는 장기 기억 유지에 중요한 메모리 정리를 하지 못함
    • 수천 개 세션에서 실제로 컨텍스트를 제거하는 사례를 본 적이 없었음
    • 프롬프트 엔지니어링으로 제거할 수 있는 성질이 아니며, 에이전트는 상태가 없기 때문에 입력 컨텍스트 창의 모든 것을 ground truth로 취급함
    • 코드, 기존 메모리, 모든 토큰이 의도의 표현으로 취급되며, 이전 에이전트 세션의 임의 결정이거나 사람이 검토하지 않은 내용도 마찬가지임
  • 이 과정에서 intent drift가 누적됨
    • 에이전트가 자율적으로 메모리 기반을 쌓을수록 이전 입력의 잘못된 의도 해석이 계속 쌓임
    • 입력 데이터가 오염되어 있다고 가정하는 코딩 벤치마크는 없으며, 모델은 입력 데이터가 틀렸다고 가정하면 오히려 불이익을 받음
    • “코드베이스를 삭제하지 말라”와 “일부 입력 컨텍스트는 삭제하라”를 동시에 만족시키는 쉬운 방법도 없음
  • 자동 암기는 결국 토큰을 쓰고, 비용을 키우고, 모델 품질을 떨어뜨리는 불필요한 쓰레기 컨텍스트로 귀결됨
  • 세션 기록은 팀 관측성에는 쓸모가 있을 수 있지만, 에이전트를 더 좋게 만드는 도구로 보기는 어려움

nori bots의 사람 검토 방식

  • 시간에 따라 컨텍스트를 배우는 방식 자체가 불가능한 것은 아니며, nori bots는 매주 PR, Slack, Drive 등 회사에서 일어난 일을 검토해 내장 nori skillsets 변경안을 제안함
    • 변경안은 Slack에서 팀을 태그하지만 기본값은 모두 거부임
    • 변경을 받아들이려면 diff를 직접 보고 의도에 맞는지 확인해야 함
    • 수락률은 20% 미만이며, 나머지 80%의 “자동” 업데이트는 모델을 더 나쁘게 만들었을 것으로 봄
    • 수백 명 규모 조직이 이런 업데이트를 항상 자동 저장한다면 더 지속 불가능해질 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • OpenAI가 ChatGPT에 세션 간 기억 기능을 넣었다고 했을 때가 떠오름. 결국 내 명시적 동의 없이 나에 대한 잡다한 정보를 찾아 프롬프트 사이에 복붙하는 기능처럼 느껴졌음
    “이 세 차를 비교해줘. 아, 참고로 나는 데이터 엔지니어고, 어머니의 결혼 전 성은 Joana고, 나쁜 시에는 알레르기가 있어. 코드는 DRY여야 하고, Python보다 SQL을 선호하며, 스칸디나비아에서 가장 독성이 강한 꽃은 뭐야?” 같은 식임
    기억된 맥락이 전혀 관련 없는 프로젝트와 대화로 새어 들어와 이상한 출력이 너무 많아서, 가장 먼저 끄는 기능임

    • 이런 기능은 ChatGPT를 질문 답변 도구가 아니라 친구/상담사/연인/비서처럼 쓰는 사람들을 위한 것 같음

  • 강하게 동의함. claude-code의 기억 시스템은 가끔 유용하지만, 현재 작업을 흐리는 오래된 정보를 끌어와 해로운 경우가 훨씬 많음. Claude 자신의 기억이 Claude를 심하게 오도하는 걸 자주 봤음
    추측하자면 훈련 과정 때문에 모델이 “지금 일어나는 일”과 “전에 일어났던 일”을 구분하지 못하는 것과 관련 있어 보임. 기억에서 추론하는 과정 자체가 훈련에 포함됐다면 달랐겠지만, 추론 시점에만 붙는 기능이라 모델을 헷갈리게 만드는 느낌임

    • 인간은 계속 기억을 만들지만, 더 이상 관련 없는 것은 잊기도 함. Claude가 그걸 할 수 있기 전까지는 LLM의 맥락이 계속 커지고 점점 더 조각날 뿐임
      LLM은 가벼운 맥락 오염도 견딜 만큼 똑똑하지 않음
    • Claude가 잘못된 길로 빠지면 보통 맥락을 지우고, 올바른 방향으로 유도하는 새 프롬프트를 씀
      그쪽으로 가게 만든 사고나 맥락에는 관성이 있어서, 그대로 두면 끈적하게 남아 있음
      그런데 나중에 그걸 기억에서 다시 꺼내오면 꽤 짜증남
    • 모델은 시간 감각과 시간이 지나며 세계 상태가 복잡하게 바뀐다는 감각이 매우 약함
      기억을 포함해 훈련한다는 아이디어는 흥미로움

  • 코드를 “무엇을 하게 만들려고 했는지”는 대체로 중요하지 않음. 중요한 건 코드가 실제로 무엇을 하는지임
    세션 로그는 분명 유용할 수 있지만, 그 위에 계속 쌓아 개발할 때가 아니라 검증 단계에 들어갈 때 유용함. 마크다운 계획과 CI 통과 사이, 새 코드 800줄이 생겼고 클릭해보면 대충 괜찮아 보이는 바로 그 구간임
    세션 로그는 어떤 수동 검증이 있었는지 보여줄 수 있음. CI는 기존 테스트를 돌리고, 코드는 새 단위 테스트가 무엇인지 보여주지만, 세션 로그는 에이전트가 Playwright로 앱을 직접 조작했는지, dev 설정뿐 아니라 prod 설정도 읽고 고려했는지 보여줌
    완벽하진 않지만, 모든 검증 작업이 저장소에 영원히 남는 테스트가 될 필요는 없음. 우리는 세션을 다시 분석해 에이전트가 묻지 않고 결정을 내린 지점을 찾고, 그 결정들에 대한 검증을 고려하도록 강제하는 데서 많은 효과를 봤음. 이런 건 처음부터 지시하기는 어렵지만, 세션 로그로는 쉽게 드러남

  • 짜증나는 문제임. 예전에 던진 가정형 질문 때문에 계속 가짜 전제를 만들어냄
    뭔가 조사해달라고 물어봤다는 이유만으로 내가 데이터센터를 소유하고 GPU를 많이 갖고 있다고 가정함

  • 이건 그냥 쓴 교훈의 한 형태 아닌가 싶음. 우리가 공들여 만든 맥락과 에이전트는 더 크고 더 나은 모델이 나오면 사라질 가능성이 큼
    그런 대화 기록은 능력이 낮은 모델에는 매우 유용하지만, 최전선 모델에는 거의 불필요할지도 모름

    • 문제는 이게 모든 맥락 관리에도 적용되는지임
      https://minimal-agent.com/ 기반의 커스텀 하네스를 쓰고 있는데, 이건 swe-mini-agent 기반이고 핵심 로직이 50줄 정도임. Bash만 있으면 충분함
      작은 작업에서는 각 모델의 표준 하네스보다 약 8배 빠르고 토큰도 8배 적게 씀
      큰 작업에서는 많이 테스트해보진 않았음. 동작은 하지만 그 경우엔 덜 집중적이고 생산성이 조금 떨어지는 것 같음. 큰 하네스의 2만 토큰짜리 시스템 프롬프트가 소프트웨어 개발 흐름을 유도하는 데 중요한 일을 하고 있을 수도 있음. 예를 들어 Fable이 Claude Code에 커스텀 시스템 프롬프트를 갖고 있다고 들었는데, 그게 훨씬 더 선제적으로 움직이는 이유일 수 있음
      그래서 맥락 엔지니어링에는 여전히 가치가 있다고 보고 싶음. 다만 모델이 새로 나올 때마다 그 가치는 줄어드는 것 같음. 모델이 대체로 덜 어리석은 행동으로 미세조정돼 있어서 손잡아줄 필요가 줄어들기 때문임
    • 흥미로운 관점임. 동의하지는 않는 쪽이지만, 꽤 마음에 들어서 생각하게 됐음
      우선 모델에는 여전히 맥락 계층이 필요하다고 봄. 맥락을 생각하는 한 방식은 압축임. 모델이 무엇을 해야 할지 파악하기 쉽게 만들기 위해 맥락을 제공하는 것임. 모델 용량과 맥락 길이가 무한한 세계에서도, 매번 모든 것을 제1원리부터 다시 유도하지 않아도 되게 해주므로 여전히 유용함. 모델이 더 적은 토큰으로 더 잘 수행하고, 우리가 토큰 비용을 신경 쓰는 한 맥락은 유용한, 어쩌면 필요한 지름길임
      어떤 형태로든 맥락 계층이 필요하다고 보면, 다음 질문은 어떤 계층이냐가 됨. 여기서는 모델에 익숙한 방식, 예를 들어 코드 옆에 놓인 마크다운 파일 같은 것과 함께 일하는 편이 낫다는 데 동의함. 하지만 이건 맥락의 필요 여부보다는, 과하게 설계된 해법이 주 사용자, 즉 에이전트를 이해하지 못한 문제에 가까움
    • 나도 이걸 궁금해했음. 사고 연쇄, 하네스 등은 핵심 모델 능력이 부족해서 생긴 일종의 우회로임
      그런데 훨씬 나은 다음 토큰 예측이 그 전체 구성을 그냥 구식으로 만들지 않을지 매우 궁금함. 어느 쪽이든 답이 나오면 많은 걸 드러낼 것임
    • 그렇지 않다고 봄. 뇌를 만들려면 내장된 구조와 편향이 더 많이 필요하지, 덜 필요하지는 않다는 걸 알게 될 것 같음
      뇌의 구조도 학습된다는 점을 기억해야 함. 다만 개인의 일생보다 훨씬 긴 시간 규모에서 학습될 뿐임

  • 정교한 기억 시스템을 굳이 만들 필요 없다는 데 동의함. 기억할 가치가 있는 건 문서, 가이드, 소스 주석, 커밋 메시지, 티켓에 있어야 함
    또 다른 계층은 필요 없음. 생각할 수 있는 모든 세분성은 이미 기존 모범 사례가 다 커버하고 있음

    • 또 다른 계층은 필요하다고 봄. 다만 그건 라우팅 계층이어야 함. Pi용 pi-brains 확장을 마무리하고 있는데, Pi는 여기 있음: https://github.com/earendil-works/pi
      이 확장은 다음을 함: https://github.com/gitsense/pi-brains
      지금은 “인간”이 정보 접근 방식에 대한 라우팅 규칙을 정의해야 하지만, 앞으로는 대화를 모니터링하다가 필요할 때 맥락을 주입하는 “지식 에이전트”를 지원할 예정임
    • 특히 프로젝트 바깥에 크게 벗어나 있는 계층, 예를 들면 ~/.claude/… 같은 건 더 그렇음
      기억이 필요했던 프로젝트에서는 그냥 AGENTS.md에 MEMORY.md를 써서 기억을 저장하거나 STATUS.md로 진행 상황을 추적하라고 한 줄 추가했음
    • 에이전트가 과거 작업 이력을 질의할 수 있는 데는 가치가 있음. 예를 들어 부정적 증거를 문서에 계속 쌓는 건 좋은 방식이 아님
      하지만 추적 로그에 태그로 달아두면 필요할 때 효율적으로 찾을 수 있음. 게다가 문서는 썩지만, 추적 로그는 커밋 해시나 다른 정보를 붙여 수명을 더 명확히 할 수 있음
    • “기억할 가치가 있는 건 문서, 가이드, 소스 주석, 커밋 메시지, 티켓에 있어야 한다”는 것도 결국 정교한 기억 시스템임. 숙련된 인간에게는 그렇게 보이지 않을 수 있지만

  • 여기에는 강하게 반대함
    나는 Claude/Codex가 로그를 남기게 함 [1]. AGENTS.md [0]에 프롬프트로 지시해뒀을 뿐임
    “모든 세션은 세션 로그 또는 계획 중 하나를 생성해야 하며, 끝에는 작성된 요약을 덧붙여야 한다. 기본은 로그이고, 실질적인 설계 작업에만 계획을 사용한다.”
    이건 엄청나게 가치 있음. 예를 들어 오늘도 몇 개 세션을 이렇게 시작했음: “Renovate 작업 상태가 어때?”, “최근 X 작업을 했는데 찾아줘”, “백업 문제는 고쳤나? 다음 단계는 뭐지?”, “이 버그가 다시 나왔어. 이미 고치지 않았나?”
    [0]: https://github.com/shepherdjerred/monorepo/blob/main/AGENTS....
    [1]: https://github.com/shepherdjerred/monorepo/tree/main/package...

  • 전반적으로 기억 시스템을 좋아함. 참고로 주로 Opus 4.8 + Max effort를 씀
    기억에서 관련 있는 내용을 꽤 자주 꺼냄. 예를 들어 자체 호스팅 OIDC 제공자 후보를 몇 개 제안해달라고 하면, “운영팀 규모를 고려하면 X와 Y 때문에 이쪽이 더 맞을 수 있다” 같은 식으로 말함
    물론 이런 건 CLAUDE.md에 넣어야 할 정보일 수 있음. 하지만 그 경우엔 그걸 CLAUDE.md에 넣어야겠다는 생각 자체가 없었고, 기억이 끄집어내줘서 좋았음
    가끔 빗나가기도 함. 오늘 인증 문제를 물었더니 “앱을 haproxy 뒤에 두기 때문에 이 trusted proxy 설정에 걸렸을 수 있다”고 했음. 우리 앱의 95%에는 맞는 말이라 언급할 가치가 있었지만, 이번에는 아니어서 정정해야 했음. 그래도 만약 프록시 뒤였다면 시간을 많이 아꼈을 수 있으니 말해준 건 좋았음

    • 전제 조건은 어느 정도의 세계 모델과 그에 따른 추론 능력처럼 보임. 예시는 모두 과거 맥락이 현재 상황과 관련 있을 때만 성립함
      특히 가정형 질문을 자주 하거나 다른 사람의 문제를 도와주는 경우엔 더 까다로움. 인간이라면 가정하지 않고 “이게 X의 운영팀에 대한 건가? 아직 규모가 Y인가?”, “이 앱도 전에 말한 다른 앱들처럼 프록시 뒤에 있나?” 같은 확인 질문을 할 가능성이 큼
      이런 맥락에는 올바르게 모델링해야 하는 뚜렷한 계층 구조도 있음. 예를 들어 서로 다른 규칙을 적용받는 여러 팀에 동시에 관여할 수 있는데, 인간은 이런 걸 자연스럽게 이해함

  • 기억을 꺼도 한 대화 안에서는 이런 일이 생김
    예전 대화에서 뭔가를 기억하고는, 내가 이미 성장하고 바뀌었는데도 그걸 계속 들이대는 짜증나는 친구 같음

  • 핵심적으로는 하드웨어 문제임. 100만 토큰은 인간이 이해하듯 코드베이스를 이해하기에 충분한 맥락이 아님
    선택적으로 잊는 능력은 잠재적으로 매우 가치 있음. 하지만 지금은 인간이 어떤 것의 대략적인 형태를 기억하고, 흥미롭지 않다고 판단하며, 그것이 흥미롭지 않다는 사실을 기억하는 능력을 대신하는 수준임
    기억은 인간이 안내할 때만 유용하다고 하지만, 올바른 해법은 그보다 더 깊다고 봄. 아마 전체 코드베이스와 모든 에이전트 세션을 모델 미세조정에 넣는 방향일 수 있음. 다만 그 시점에는 특정 세션을 모델에 넣지 않도록 안내가 필요할 수도 있음. 아니면 필요 없을 수도 있고, 쓴 교훈이 적용될지도 모름

    • 적어도 내가 작업해본 대부분의 프로젝트에서는 100만 토큰이면 클래스/프로젝트/배포 구조를 큰 줄기로 설명하기에 충분했고, 특정 이슈를 설명하는 데는 20만~50만 토큰 창이면 충분했음
답변달기