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원리부터 다시 유도하지 않아도 되게 해주므로 여전히 유용함. 모델이 더 적은 토큰으로 더 잘 수행하고, 우리가 토큰 비용을 신경 쓰는 한 맥락은 유용한, 어쩌면 필요한 지름길임
어떤 형태로든 맥락 계층이 필요하다고 보면, 다음 질문은 어떤 계층이냐가 됨. 여기서는 모델에 익숙한 방식, 예를 들어 코드 옆에 놓인 마크다운 파일 같은 것과 함께 일하는 편이 낫다는 데 동의함. 하지만 이건 맥락의 필요 여부보다는, 과하게 설계된 해법이 주 사용자, 즉 에이전트를 이해하지 못한 문제에 가까움

나도 이걸 궁금해했음. 사고 연쇄, 하네스 등은 핵심 모델 능력이 부족해서 생긴 일종의 우회로임
그런데 훨씬 나은 다음 토큰 예측이 그 전체 구성을 그냥 구식으로 만들지 않을지 매우 궁금함. 어느 쪽이든 답이 나오면 많은 걸 드러낼 것임

그렇지 않다고 봄. 뇌를 만들려면 내장된 구조와 편향이 더 많이 필요하지, 덜 필요하지는 않다는 걸 알게 될 것 같음
뇌의 구조도 학습된다는 점을 기억해야 함. 다만 개인의 일생보다 훨씬 긴 시간 규모에서 학습될 뿐임

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

특히 프로젝트 바깥에 크게 벗어나 있는 계층, 예를 들면 ~/.claude/… 같은 건 더 그렇음
기억이 필요했던 프로젝트에서는 그냥 AGENTS.md에 MEMORY.md를 써서 기억을 저장하거나 STATUS.md로 진행 상황을 추적하라고 한 줄 추가했음

에이전트가 과거 작업 이력을 질의할 수 있는 데는 가치가 있음. 예를 들어 부정적 증거를 문서에 계속 쌓는 건 좋은 방식이 아님
하지만 추적 로그에 태그로 달아두면 필요할 때 효율적으로 찾을 수 있음. 게다가 문서는 썩지만, 추적 로그는 커밋 해시나 다른 정보를 붙여 수명을 더 명확히 할 수 있음

“기억할 가치가 있는 건 문서, 가이드, 소스 주석, 커밋 메시지, 티켓에 있어야 한다”는 것도 결국 정교한 기억 시스템임. 숙련된 인간에게는 그렇게 보이지 않을 수 있지만

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

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

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

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

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