핵심 주장

SWE 작업에서 에이전트에 세션 기록 검색(memory retrieval)을 붙여도 성능 이점이 없었고, 경우에 따라 모델 품질을 떨어뜨렸다. 수개월간 세션 검색 유무 비교 결과, 차이를 만들지 못했으며 사람 검토 없이는 자동 메모리 개선 시도가 이점을 제공하지 못했다.

왜 세션 기록이 해로운가

1. 컨텍스트 중복

  • 좋은 커밋 메시지, PR 메시지, 문서, 메타데이터가 이미 코딩 산출물에 정리됨
  • 세션 기록은 이미 아는 내용을 다시 읽게 하고, 임시 판단·스크래치패드까지 토큰으로 소비

2. 메모리 정리 실패

  • 에이전트는 장기 기억에서 불필요한 컨텍스트를 제거하지 못함
  • 입력 컨텍스트 창의 모든 것을 ground truth로 취급 (상태 없음)
  • 이전 세션의 임의 결정·미검토 내용이 계속累积 → intent drift

3. 자동 암기의 악순환

  • 입력 데이터가 오염되어 있어도 코딩 벤치마크가 이를 감지하지 못함
  • 모델은 “일부 입력 컨텍스트는 삭제하라”는 지시를 실행할 수 없음
  • 결국 불필요한 쓰레기 컨텍스트로 토큰·비용만 증가

흔한 세션 메모리 아키텍처 (해법이 아님)

모든 transcript → DB 저장 → 벡터 검색 + Elasticsearch + SQL + 그래프
→ MCP / CLI skill로 에이전트 노출

이 전체 계층이 추가 작업일 뿐, 차이를 만들지 못했다.

대안: nori bots 방식 (사람 검증을 통한 학습)

완전 자동화가 아닌, 사람이 직접 diff를 검토하는 방식:

  • 매주 PR, Slack, Drive를 검토 → nori skillsets 변경안 제안
  • 기본값은 모두 거부 (수락 전 반드시 의도 확인)
  • 실제 수락률 20% 미만 — 나머지 80%의 자동 업데이트는 오히려 해로웠을 가능성

관련 있는 Hacker News 의견

  • 기억의 부작용: 세션 간 기억이 관련 없는 프로젝트에서 새어 들어와 출력 오류 발생 → ChatGPT에서 가장 먼저 끄는 기능
  • 세션 로그의 유효 용도: 검증 단계에서 에이전트가 수동 검증한 이력 추적 (Playwright 조작 여부, prod 설정 확인 여부 등)
  • 올바른 기억 대상: 문서·가이드·소스 주석·커밋 메시지·티켓. 세션별 요약 생성도 유효하나 자동 암기는 불필요
  • 하드웨어 관점: 100만 토큰도 인간처럼 코드베이스를 이해하기에 충분하지 않음

관련 개념