Claude.ai 메모리 시스템 같은 걸 드디어 portable하게 만든 줄 알고 눌렀는데, 전혀 그게 아니었음
여기 있는 건 그냥 store/remember 방식이고, 내가 더 낫다고 느낀 건 백그라운드 모델이 채팅 기록을 요약해서 메모리를 만드는 방식임
그쪽은 모델이 직접 메모리를 써야 하지 않아서 훨씬 잘 작동했고, 그래서 이걸 Claude.ai와 같은 수준으로 소개하는 건 다소 misleading하게 보임
나도 LibreChat 같은 쪽으로 옮기려고 같은 방식의 메모리 시스템을 계속 찾는 중인데 아직 못 찾았고, 지금 Claude.ai에 남아 있는 거의 유일한 이유가 그 기능임
참고로 그 시스템은 Claude.ai에만 있고 Claude Code에는 없음
이 접근은 정말 써보고 싶음
내 경험은 정반대라서, 나는 https://github.com/flippyhead/ai-brain을 주로 나 자신을 위해 만들었고 친구 몇 명도 씀
지금까지는 CLAUDE.md를 통해 AI에게 관련 메모리를 찾고, 언제 어떻게 저장할지 생각하게 하는 방식이 꽤 잘 먹혔음
이 방식은 우선순위에 따라 구조를 만들고 미래를 위한 노트도 남길 수 있어서, 단순히 전부 요약하는 방식과는 꽤 다르게 느껴짐
나는 자동 recall이 에이전트에게 보이지 않게 동작하는 쪽을 선호함
메모리 생성은 tool call도 꽤 잘하고, 컨텍스트 압축 시 자동으로 메모리를 만드는 방식도 괜찮다고 봄
다만 자동 생성이라면 비동기 consolidation이 필요하고, 그걸 dreaming이라고 부르는 건 좀 과장처럼 느껴짐
내 구현은 Elroy.bot에 있고, 여러 접근은 여기 정리해 뒀음: https://tombedor.dev/approaches-to-agent-memory/
그걸 어떻게 벤치마크하는지가 궁금함
백그라운드에서 메모리를 추출하면 prefix cache와 잘 맞추기 어려운 게 문제임
단순한 2단계 LOG.md(작업과 교훈의 상세 로그) + MEMORY.md(로그가 잘릴 때 승격된 항목 기록) + 턴 종료 시 실행되는 stop hook만으로도 꽤 멀리 갈 수 있음
이 개념은 꽤 흥미로움
사용자와 대화하는 에이전트 뒤에서 보조 인력들이 대화를 엿듣고 중요한 사실을 기록하거나, 관련 사실을 DB에서 찾아보다가 이 메모리 X가 관련 있어 보인다며 끼어드는 구조처럼 느껴짐
토큰이 공짜라면 쉬워 보이지만, 이걸 효율적으로 만드는 건 꽤 재미있는 문제임
구현 방식을 거의 안 밝힌 채 뭔가를 약속하는 프로젝트는 늘 큰 red flag로 보임
더 파보면 사실상 pg_vector에 mcp, 그리고 recall/remember 두 함수가 붙은 구조임
결국 RAG에 가깝고, 데이터 구조가 중요하다고 주장할 수는 있어도 지금까지 나온 이런 메모리 시스템들은 거의 다 비슷하게 동작했음
아직은 기본적인 vector DB search보다 검색이 더 좋아졌다는 걸 입증한 사례를 못 봤음
사이트는 멋지고, memory라고 쓰여 있고, LLM은 형편없지만 이 제품은 마법처럼 해결한다고 보여줌
정말 그게 된다면, 결국 vectordb를 그럴듯하게 포장한 것에 가깝기도 함
이런 agent memory systems는 과하게 설계된 것 같으면서도 동시에 덜 설계된 것 같고, 꽤 막다른 길처럼 보임
최신 모델이 필요로 하는 것과 금방 어긋나고 썩어버리지 않을 현실이 잘 상상되지 않음
예를 들어 결제 기능을 한 번 만들었다고 해서 don't use stripe 같은 메모리 때문에 이후 여러 세션이 자꾸 결제 쪽으로 기울어질 수 있음
더 나쁜 건 작성자 본인도 직접 써본 흔적이 너무 없다는 점임
완전히 unproven memory layer이고, 실사도 없이 화려한 마케팅 사이트에 과장된 주장만 올린 느낌임
나는 이걸 정보 문제로 보고, 대부분을 저장하지 않도록 의도한 작은 유틸을 만들었음: https://github.com/skorokithakis/gnosis
전제는 단순함. LLM이 원래 아는 내용은 계속 알 테니 LLM이 말한 건 저장하지 않고, 코드 관련 내용은 코드와 주석에 남기면 됨
대신 둘 다 아닌데도 절대 캡처되지 않는 것들이 있음
뭔가를 만들 때는 실제로 한 것보다 하지 않기로 한 것이 더 중요할 때가 많고, 이 유틸은 세션 끝에서 기각한 대안들과 그 이유를 잡아내 system knowledge로 저장함
결국 코드 grep만으로는 찾을 수 없는, 동료들 머릿속에만 있는 정보를 남기고 싶은 거고 지금까지는 꽤 잘 작동하지만 아직 이르긴 함
나는 직접 만든 bespoke memory system을 쓰는데, 모든 메모리를 맥락별 검색 공간으로 만들어서 이 문제를 피함 don't use stripe 같은 메모리는 모델이 payment processing 관련 작업을 하라는 프롬프트를 받았을 때만 컨텍스트로 들어옴
이런 걸 계속 찾고 있었고, 계정이 LLM 붐 이전부터 소프트웨어를 공개해 온 것도 보여서 반가움
다만 프로젝트마다 LLM 사용 내역 같은 게 붙었으면 좋겠음
LLM으로 생성했는지, 했다면 얼마나 했는지, 어느 단계에서 썼는지, 출력은 얼마나 꼼꼼히 검토했는지, 품질이 혼자 만들었을 때보다 최소한 같거나 더 낫다고 느끼는지 같은 정보가 있으면 좋겠음
특정 개인을 의심하려는 게 아니라 모든 프로젝트에 공통으로 있었으면 하고, 나도 그렇게 할 생각임
솔직히 이건 좀 entitled하게 들림
누가 억지로 이 프로젝트를 쓰라고 하는 것도 아니고, 코드는 직접 읽고 검토한 뒤 쓸지 말지 스스로 판단하면 됨
질문 자체는 타당하지만, 당사자 자기신고만으로 답하게 둘 수는 없다고 봄
설계도 테스트도 거의 안 했고 코드 품질도 별로라고 솔직히 인정할 사람이 많을 것 같지 않음
오히려 이런 질문에 답하려는 제3자 시스템이 필요할지도 모르겠는데, 물론 그것도 LLM 기반이면 꽤 주관적일 수 있음
LLM으로 소프트웨어를 만드는 방식은 정말 다양함
나는 요즘 대부분의 프로젝트를 여러 Markdown 파일 중심으로 굴리는데, AI로 먼저 조사하고 계획 세우고 구현 진행을 추적함
구현은 계획에 따라 단계적으로 하고 매 단계 검토도 계속함
내 워크플로를 문서화하라고 하면 그 파일들이 바로 그것임
코드의 99%는 생성되지만, 내가 만족하는 방식으로 생성되도록 신경 쓰고 있고 결과도 종종 혼자 만들었을 때보다 더 낫다고 느낌
그게 왜 중요한지 잘 모르겠음 좋은 소프트웨어도 나쁜 소프트웨어도 LLM 없이도, LLM과 함께도 만들 수 있음
목수에게 망치를 썼는지 nail gun을 썼는지, 지붕과 데크에는 각각 뭘 썼는지 묻지는 않음
신뢰 기반이 없다면 결국 직접 품질을 검증하거나 아예 스스로 만들어야 하고, 그 외에는 희망 섞인 기대에 가깝다고 봄
아직 쓸만한 memory를 못 찾았음
하나는 agents.md처럼 높은 수준 요약만 남겨서 구체적인 디테일, 예를 들면 이 요소를 수정하면 저 요소를 draft로 표시해야 한다 같은 정보에는 별 도움이 안 됨
반대로 너무 상세한 방식은 세부가 지나쳐서 무시되거나, 한 기능 영역의 디테일이 다른 영역 변경에까지 오염을 일으킴
결국 지금까지 제일 잘 먹힌 건 메모리 없이, 해당 세션/프롬프트에 중요한 컨텍스트만 수동으로 고르는 방식이었음
메모리에 관심이 큰 편이지만, 적어도 코딩용 도구로는 그다지 유용하다고 보지 않음
저장소가 무엇을 하는지, 무엇을 해야 하는지의 source of truth는 결국 repo itself임
지금 말한 건 차라리 코드 리뷰 가이드라인에 가깝고, 그런 건 변경 시점에 맞춰 명시적으로 컨텍스트에 넣으면 됨
메모리 시스템은 여기에 비해 너무 복잡하고 정확성도 떨어짐
나도 비슷하게 느낌
언젠가 이런 모델들이 continual learning을 갖게 될지 궁금함
이미 충분히 똑똑한데 진짜 메모리가 없어서 다루기 번거롭게 느껴짐
Claude가 만들어 준 메모리는 거의 전부 remember-to-not-forget류라서, 결국 기능을 꺼버렸음
내게는 몇 가지 단순한 것들이 꽤 잘 먹힘, 도구는 Codex 기준임
항상 최신인 상세 functional specification
여러 프로젝트로 구조화된 코드베이스
좋은 네이밍과 문서화가 된 코드. 클래스, 변수, 함수 이름은 아무리 길고 우스워 보여도 목적이 명확해야 하고, 이런 규칙은 Agent.md의 코딩 가이드라인에 넣어 둠
내 functional spec은 에이전트에게 Project.md 역할을 함
그리고 매번 agentic code review 전에 프로젝트 디렉터리 트리를 만들고, 코드베이스와 합쳐서 단일 파일로 만든 뒤 파일명에 timestamp를 붙임
이게 의외로 중요해서 LLM이 오래된 버전을 참조하는 걸 줄여주고, git을 굳이 보내지 않아도 빠르게 diff 보기에도 좋음
지금까지는 큰 규모의 복잡한 코드베이스에서도 이 단순한 워크플로가 꽤 잘 작동했음
토큰 효율은 별로지만 그냥 잘 됨
매번 전체 코드베이스를 다 합칠 필요는 없고, 이미 끝났거나 테스트됐거나 지금 작업과 무관한 프로젝트는 뺄 수 있음
그래도 printed directory tree에는 넣어서, 에이전트가 적어도 그 존재를 알고 필요하면 특정 파일을 요청할 수 있게 함
흥미로운 접근임
그 병합 작업은 어떻게 하는지 궁금함
수동인지, 변경 파일만 합치는지, 아니면 혼합형인지 알고 싶음
LLM memory는 이론상 좋지만, 실제로는 커질수록 메모리 없이 굴릴 때만큼이나 지저분해짐
첫 화면 예시처럼 내 프로젝트 계속 작업해줘라고 해도, 현실에서는 프로젝트 하나만 하는 경우가 드묾
5개, 10개쯤 메모리에 들어갈 수 있고, 각각 저장 당시에는 다 의미 있었을 것임
결국 sass 프로젝트 계속해줘처럼 다시 특정해야 하고, 세부 컨텍스트는 조금 얻는 대신 LLM context를 채우고 추가 MCP calls 비용도 내게 됨
맞는 말이지만, 이건 너무 naive implementation임
제대로 만든 구현이라면 이런 한계를 넘어설 수도 있음
결국 뭘 기억해야 하는지 구체적으로 지정하기 시작하면, 사실상 AI에게 파일로 write/read하게 시키는 것과 거의 다를 바 없어짐
이건 혼자 일하는 vibecoder만을 위한 건가 싶음
실제 사람들과 실제 프로젝트를 하면, 이 시스템은 프로젝트 전체 메모리를 가질 수도 없고 나 역시 전체 메모리를 갖고 있지 않음
다른 PR이 머지되면 내가 가진 기억은 바로 낡아지고, 내가 신경 쓰는 건 내 티켓뿐임
그래서 점점 이런 건 그런 종류의 협업 작업을 위한 도구가 아닐 수도 있겠다고 느껴짐
이제 소프트웨어를 만드는 비용이 사실상 거의 0에 가까워졌는데도, 아직 이런 걸 vibe-coded 마케팅 사이트로 팔려는 게 놀라움
누가 이런 걸 써보고 몇 주, 몇 달 기다리면서 실제로 되는지 확인할 시간이 있겠나 싶음
사이트 어디에도 RAG보다 낫다거나, 그냥 메모리 파일 폴더와 grep보다 낫다는 증거가 없음
그런데도 환상적인 주장만 늘어놓고 있고, 스크롤도 14fps로 버벅임
이건 24시간 전에 코딩한 수준으로 보이는데, 솔직히 너무 게으르게 느껴짐
Hacker News 의견들
Claude.ai 메모리 시스템 같은 걸 드디어 portable하게 만든 줄 알고 눌렀는데, 전혀 그게 아니었음
여기 있는 건 그냥
store/remember방식이고, 내가 더 낫다고 느낀 건 백그라운드 모델이 채팅 기록을 요약해서 메모리를 만드는 방식임그쪽은 모델이 직접 메모리를 써야 하지 않아서 훨씬 잘 작동했고, 그래서 이걸 Claude.ai와 같은 수준으로 소개하는 건 다소 misleading하게 보임
나도 LibreChat 같은 쪽으로 옮기려고 같은 방식의 메모리 시스템을 계속 찾는 중인데 아직 못 찾았고, 지금 Claude.ai에 남아 있는 거의 유일한 이유가 그 기능임
참고로 그 시스템은 Claude.ai에만 있고 Claude Code에는 없음
autoDream이라는 게 있었고, 여기서는 background memory consolidation engine이라고 설명함: https://kuber.studio/blog/AI/Claude-Code's-Entire-Source-Code-Got-Leaked-via-a-Sourcemap-in-npm,-Let's-Talk-About-it내 경험은 정반대라서, 나는 https://github.com/flippyhead/ai-brain을 주로 나 자신을 위해 만들었고 친구 몇 명도 씀
지금까지는
CLAUDE.md를 통해 AI에게 관련 메모리를 찾고, 언제 어떻게 저장할지 생각하게 하는 방식이 꽤 잘 먹혔음이 방식은 우선순위에 따라 구조를 만들고 미래를 위한 노트도 남길 수 있어서, 단순히 전부 요약하는 방식과는 꽤 다르게 느껴짐
메모리 생성은 tool call도 꽤 잘하고, 컨텍스트 압축 시 자동으로 메모리를 만드는 방식도 괜찮다고 봄
다만 자동 생성이라면 비동기 consolidation이 필요하고, 그걸 dreaming이라고 부르는 건 좀 과장처럼 느껴짐
내 구현은 Elroy.bot에 있고, 여러 접근은 여기 정리해 뒀음: https://tombedor.dev/approaches-to-agent-memory/
백그라운드에서 메모리를 추출하면 prefix cache와 잘 맞추기 어려운 게 문제임
단순한 2단계
LOG.md(작업과 교훈의 상세 로그) +MEMORY.md(로그가 잘릴 때 승격된 항목 기록) + 턴 종료 시 실행되는 stop hook만으로도 꽤 멀리 갈 수 있음사용자와 대화하는 에이전트 뒤에서 보조 인력들이 대화를 엿듣고 중요한 사실을 기록하거나, 관련 사실을 DB에서 찾아보다가
이 메모리 X가 관련 있어 보인다며 끼어드는 구조처럼 느껴짐토큰이 공짜라면 쉬워 보이지만, 이걸 효율적으로 만드는 건 꽤 재미있는 문제임
구현 방식을 거의 안 밝힌 채 뭔가를 약속하는 프로젝트는 늘 큰 red flag로 보임
더 파보면 사실상
pg_vector에mcp, 그리고recall/remember두 함수가 붙은 구조임결국 RAG에 가깝고, 데이터 구조가 중요하다고 주장할 수는 있어도 지금까지 나온 이런 메모리 시스템들은 거의 다 비슷하게 동작했음
아직은 기본적인 vector DB search보다 검색이 더 좋아졌다는 걸 입증한 사례를 못 봤음
memory라고 쓰여 있고, LLM은 형편없지만 이 제품은 마법처럼 해결한다고 보여줌정말 그게 된다면, 결국 vectordb를 그럴듯하게 포장한 것에 가깝기도 함
이미 리뷰가 있음: https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/
다른 수많은 LLM memory systems도 여기 모여 있음: https://zby.github.io/commonplace/agent-memory-systems/
그리고 이런 시스템에 바라는 점도 정리해 둠: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
이런 agent memory systems는 과하게 설계된 것 같으면서도 동시에 덜 설계된 것 같고, 꽤 막다른 길처럼 보임
최신 모델이 필요로 하는 것과 금방 어긋나고 썩어버리지 않을 현실이 잘 상상되지 않음
예를 들어 결제 기능을 한 번 만들었다고 해서
don't use stripe같은 메모리 때문에 이후 여러 세션이 자꾸 결제 쪽으로 기울어질 수 있음완전히 unproven memory layer이고, 실사도 없이 화려한 마케팅 사이트에 과장된 주장만 올린 느낌임
전제는 단순함. LLM이 원래 아는 내용은 계속 알 테니 LLM이 말한 건 저장하지 않고, 코드 관련 내용은 코드와 주석에 남기면 됨
대신 둘 다 아닌데도 절대 캡처되지 않는 것들이 있음
뭔가를 만들 때는 실제로 한 것보다 하지 않기로 한 것이 더 중요할 때가 많고, 이 유틸은 세션 끝에서 기각한 대안들과 그 이유를 잡아내 system knowledge로 저장함
결국 코드 grep만으로는 찾을 수 없는, 동료들 머릿속에만 있는 정보를 남기고 싶은 거고 지금까지는 꽤 잘 작동하지만 아직 이르긴 함
don't use stripe같은 메모리는 모델이 payment processing 관련 작업을 하라는 프롬프트를 받았을 때만 컨텍스트로 들어옴이런 걸 계속 찾고 있었고, 계정이 LLM 붐 이전부터 소프트웨어를 공개해 온 것도 보여서 반가움
다만 프로젝트마다
LLM 사용 내역같은 게 붙었으면 좋겠음LLM으로 생성했는지, 했다면 얼마나 했는지, 어느 단계에서 썼는지, 출력은 얼마나 꼼꼼히 검토했는지, 품질이 혼자 만들었을 때보다 최소한 같거나 더 낫다고 느끼는지 같은 정보가 있으면 좋겠음
특정 개인을 의심하려는 게 아니라 모든 프로젝트에 공통으로 있었으면 하고, 나도 그렇게 할 생각임
누가 억지로 이 프로젝트를 쓰라고 하는 것도 아니고, 코드는 직접 읽고 검토한 뒤 쓸지 말지 스스로 판단하면 됨
설계도 테스트도 거의 안 했고 코드 품질도 별로라고 솔직히 인정할 사람이 많을 것 같지 않음
오히려 이런 질문에 답하려는 제3자 시스템이 필요할지도 모르겠는데, 물론 그것도 LLM 기반이면 꽤 주관적일 수 있음
나는 요즘 대부분의 프로젝트를 여러 Markdown 파일 중심으로 굴리는데, AI로 먼저 조사하고 계획 세우고 구현 진행을 추적함
구현은 계획에 따라 단계적으로 하고 매 단계 검토도 계속함
내 워크플로를 문서화하라고 하면 그 파일들이 바로 그것임
코드의 99%는 생성되지만, 내가 만족하는 방식으로 생성되도록 신경 쓰고 있고 결과도 종종 혼자 만들었을 때보다 더 낫다고 느낌
좋은 소프트웨어도 나쁜 소프트웨어도 LLM 없이도, LLM과 함께도 만들 수 있음
목수에게 망치를 썼는지 nail gun을 썼는지, 지붕과 데크에는 각각 뭘 썼는지 묻지는 않음
신뢰 기반이 없다면 결국 직접 품질을 검증하거나 아예 스스로 만들어야 하고, 그 외에는 희망 섞인 기대에 가깝다고 봄
아직 쓸만한 memory를 못 찾았음
하나는
agents.md처럼 높은 수준 요약만 남겨서 구체적인 디테일, 예를 들면이 요소를 수정하면 저 요소를 draft로 표시해야 한다같은 정보에는 별 도움이 안 됨반대로 너무 상세한 방식은 세부가 지나쳐서 무시되거나, 한 기능 영역의 디테일이 다른 영역 변경에까지 오염을 일으킴
결국 지금까지 제일 잘 먹힌 건 메모리 없이, 해당 세션/프롬프트에 중요한 컨텍스트만 수동으로 고르는 방식이었음
저장소가 무엇을 하는지, 무엇을 해야 하는지의 source of truth는 결국 repo itself임
지금 말한 건 차라리 코드 리뷰 가이드라인에 가깝고, 그런 건 변경 시점에 맞춰 명시적으로 컨텍스트에 넣으면 됨
메모리 시스템은 여기에 비해 너무 복잡하고 정확성도 떨어짐
언젠가 이런 모델들이 continual learning을 갖게 될지 궁금함
이미 충분히 똑똑한데 진짜 메모리가 없어서 다루기 번거롭게 느껴짐
내게는 몇 가지 단순한 것들이 꽤 잘 먹힘, 도구는 Codex 기준임
Agent.md의 코딩 가이드라인에 넣어 둠내 functional spec은 에이전트에게
Project.md역할을 함그리고 매번 agentic code review 전에 프로젝트 디렉터리 트리를 만들고, 코드베이스와 합쳐서 단일 파일로 만든 뒤 파일명에 timestamp를 붙임
이게 의외로 중요해서 LLM이 오래된 버전을 참조하는 걸 줄여주고, git을 굳이 보내지 않아도 빠르게 diff 보기에도 좋음
지금까지는 큰 규모의 복잡한 코드베이스에서도 이 단순한 워크플로가 꽤 잘 작동했음
토큰 효율은 별로지만 그냥 잘 됨
매번 전체 코드베이스를 다 합칠 필요는 없고, 이미 끝났거나 테스트됐거나 지금 작업과 무관한 프로젝트는 뺄 수 있음
그래도 printed directory tree에는 넣어서, 에이전트가 적어도 그 존재를 알고 필요하면 특정 파일을 요청할 수 있게 함
그 병합 작업은 어떻게 하는지 궁금함
수동인지, 변경 파일만 합치는지, 아니면 혼합형인지 알고 싶음
LLM memory는 이론상 좋지만, 실제로는 커질수록 메모리 없이 굴릴 때만큼이나 지저분해짐
첫 화면 예시처럼
내 프로젝트 계속 작업해줘라고 해도, 현실에서는 프로젝트 하나만 하는 경우가 드묾5개, 10개쯤 메모리에 들어갈 수 있고, 각각 저장 당시에는 다 의미 있었을 것임
결국
sass 프로젝트 계속해줘처럼 다시 특정해야 하고, 세부 컨텍스트는 조금 얻는 대신 LLM context를 채우고 추가 MCP calls 비용도 내게 됨제대로 만든 구현이라면 이런 한계를 넘어설 수도 있음
이건 혼자 일하는 vibecoder만을 위한 건가 싶음
실제 사람들과 실제 프로젝트를 하면, 이 시스템은 프로젝트 전체 메모리를 가질 수도 없고 나 역시 전체 메모리를 갖고 있지 않음
다른 PR이 머지되면 내가 가진 기억은 바로 낡아지고, 내가 신경 쓰는 건 내 티켓뿐임
그래서 점점 이런 건 그런 종류의 협업 작업을 위한 도구가 아닐 수도 있겠다고 느껴짐
이제 소프트웨어를 만드는 비용이 사실상 거의 0에 가까워졌는데도, 아직 이런 걸 vibe-coded 마케팅 사이트로 팔려는 게 놀라움
누가 이런 걸 써보고 몇 주, 몇 달 기다리면서 실제로 되는지 확인할 시간이 있겠나 싶음
사이트 어디에도 RAG보다 낫다거나, 그냥 메모리 파일 폴더와 grep보다 낫다는 증거가 없음
그런데도 환상적인 주장만 늘어놓고 있고, 스크롤도 14fps로 버벅임
이건 24시간 전에 코딩한 수준으로 보이는데, 솔직히 너무 게으르게 느껴짐