지속적인 가중치 갱신은 Anthropic처럼 클라우드 추론을 제공하는 회사에는 실현 가능한 방식이 될 수 없다고 봄. 그걸 원한다면 로컬에서 실행할 수 있는 모델을 살펴봐야겠지만, 그쪽도 실현까지 몇 년은 더 걸린다는 사실을 깨닫게 될 것임.
생산적인 LLM의 최종 형태에는 상태를 추적하는 실시간 지식·맥락 그래프와 지속적인 가중치 갱신이 모두 포함될 것으로 봄.
장기적으로는 가중치 갱신을 탐구하는 편이 더 흥미로움. 이것도 결국 ‘쓰라린 교훈’에 무너질 생각일 수 있지만, 이론적으로 모든 것을 가중치에 담을 수 있다고 해서 그것이 최적이라고 확신하지는 못함. 현재는 과적합 없이 자기 작업의 성능을 높이기가 너무 비싸고 까다로움.
당장 몇 달 안에는 적절한 지시와 맥락을 제공하는 것만으로도 역량을 크게 높일 수 있음. https://thinkingmachines.ai/blog/on-policy-distillation/#tra...
지금까지 사용한 모든 에이전트 실행 환경에서 자동 기억 생성을 꺼둠. Claude Code가 그래도 가끔 기억을 만들지만, 아마 95%는 삭제하는 편임. 거의 항상 현재 작업에만 해당하는 내용이라, 반복할 일이 아니라면 맥락을 어지럽히지 않도록 지움. 가장 바라는 개선은 무엇을 기억으로 남길지 더 잘 판단하는 것임.
‘꿈꾸기’ 부분을 보니 에이전트 대화 기록에 담긴 방대한 정보가 아직 충분히 활용되지 않는다는 생각이 듦. 대화 기록을 DuckDB에 넣고 분석해보길 권함. Claude Code라면 약 10분 만에 수집 파이프라인을 만들 수 있음. 도구 호출 실패의 반복 원인, 대규모 캐시 미스의 원인, 메인 대화와 하위 에이전트의 시간에 따른 효율 지표인 달러당 토큰 수나 토큰당 코드 줄 수 등을 살펴볼 만함.
나도 이렇게 시작해 흥미로운 사실을 발견함. 예를 들어 Opus 5.5 / Sol 6.1에 일을 지나치게 작은 단위로 나눠 맡기는 경향이 있었음. 이전 모델보다 한 번에 더 많은 작업을 처리할 수 있는데도 그 능력을 제대로 활용하지 못한 셈임.
나도 늘 같은 조언을 함. 기억 끄기는 에이전트를 쓰면서 분당 “이게 뭐야?”를 외치는 횟수를 줄이는 데 가장 효과적인 방법 중 하나였음.
Claude의 기억은 도움보다 성가심이 커서 나도 꺼둠. 반면 주로 이동 중 모바일로 질문하는 ChatGPT의 기억 기능은 켜두는데, 사용감이 훨씬 나음. 다만 Claude의 기억을 다시 켜본 지 오래돼 지금은 달라졌을 수 있음.
주기적으로 전체 기억을 정리하고, 필요한 질문을 내게 하도록 요청함. Claude Desktop UI에서는 직접 기억을 관리함.
이 정도면 충분히 잘 작동함. ‘꿈꾸기’는 금방 기억 비대화나 낡은 정보 축적으로 이어져 마음에 들지 않음.
에이전트가 매개변수 이름을 잘못 써서 도구 호출에 실패하는 경우를 자주 봄. 파일 생성 도구가 file_text를 요구하는데 file_content를 전달하는 식임. 동료는 사전 프롬프트 파일에 적어두라는데, 모델이 왜 이런 실수를 하는지 이해가 안 됨. 사용 가능한 도구와 매개변수 이름이 이미 맥락에 들어 있어야 하는 것 아닌가?
정말 같은 과정이 아니라면 인간을 위한 개념을 기계에 적용하면 안 됨. Claude는 생각하지 않을 때 쉬거나 호르몬과 다른 화학물질의 균형을 맞추지 않음. 꿈의 한 요소가 정보 정리와 관련 있다고 해서 정보 정리가 곧 꿈꾸기는 아님.
둘 다 위치를 바꾼다는 이유로 걷기를 우주 비행이라고 부르는 것과 같음.
여기서 사용한 논리에는 ‘꿈꾸기’라는 비유가 잘 맞는다고 느낌. 어떤 비유든 한계는 있음. 우주 비행의 예를 들자면, 우주비행사는 우주선 작업을 하며 ‘우주 유영(spacewalk)’을 함. 실제로 걷는 것은 아니어도 말이 통함.
이런 글을 반복해서 읽는 일이 너무 피곤함. Anthropic은 실제로 교훈을 얻지 못하고 있거나, 착각에 너무 깊이 빠져 끝내 이해하지 못할 것 같음.
본문에 설명돼 있는지는 모르겠지만, 그림 10에서는 위키+검색이 꿈꾸기보다 성능이 좋고, 위키+검색에 꿈꾸기를 추가해도 개선 폭은 작아 보임.
시간 범위에 따라 다를 수는 있겠지만 검색이 꿈꾸기보다 훨씬 저렴하다고 가정하면, 꽤 중요한 결과임.
충돌 해결도 중요하지만, 대부분의 기억 모델에 빠져 있는 것은 출처와 변경 이력이라고 봄. 해결의 근거가 된 원래 기억을 보존하지 않고 수정하거나 덮어써버림.
나는 변증법에 기반한 대안을 탐구하고 있음. https://particulars.fyi/.
memory-prune이라는 스킬을 사용함. 자동 생성된 기억을 평가해 그대로 남길지, 코드 주석이나 규칙, 프로젝트의 AGENTS.md, 전역 AGENTS.md/CLAUDE.md로 옮길지, 아니면 아예 삭제할지 결정하는 것이 유일한 역할임. 가장 자주 선택되는 것은 삭제임.
회상을 위한 기억 공고화와 비슷함. 기억 자체는 그대로 두고, 코드베이스 파일에 기억 항목을 가리키는 참조를 자동으로 만들어두면 어떨까? 그 참조가 도구 결과에 나타날 때 해당 기억을 에이전트 맥락에 넣는 방식도 비슷하거나 더 효과적일지 궁금함.
이 스킬을 공유해줄 수 있을까? 기억은 그냥 두면 관리하기 어려워지는 경우가 많아서, 관리 방법을 늘 개선하고 싶음.
내 에이전트 실행 환경에서도 이렇게 처리함. 맥락이 너무 커지면 같은 에이전트의 다음 세션으로 자연스럽게 인계하고 기억을 정리함. 가장 관련성 높은 내용을 추려 다음 시스템 프롬프트로 사용함.
어느 순간부터는 이 과정이 일어나는 것조차 알아차리지 못하게 됨.
Cerulean까지의 진행 그래프를 보니 기억 없이 쓰는 편에 상당히 마음이 기움. 장시간 실행하는 에이전트에서 가장 피하고 싶은 것은 변동성임. 그렇게 빠르게 어느 한 방향으로 몰아가는 요소는 적어도 내게는 대체로 바람직하지 않음.
그 그래프에서는 ‘기억 없음’ 실행도 목표에 도달하지 못함. 이것만으로 판단하기는 어렵지만, 부실하게 구현한 기억은 악화시키고 제대로 구현한 기억은 개선한다는 쪽으로 읽힘. 적어도 포켓몬에서는 그런 셈임.
흥미롭게도 인간에게도 적용되는 듯함. ‘꿈꾸기’는 과거에 겪은 어려움에 대한 자기 가정을 재검토하게 만드는데, 꽤 유익한 심리치료 과정처럼 느껴짐.
다만 실제로는 메모와 실제 이력을 교차 검증하고 있었으니, ‘꿈꾸기’라는 이름이 적절한지는 모르겠음. 상당히 엄밀한 꿈꾸기인 셈임.
모델은 유용한 기억을 만들거나 시간이 지나며 점진적으로 개선하는 일에 아주 서툴다고 느낌.
고쳐야 할 빈틈이 있는 모델이 자기 빈틈을 알아보고 수정 지침을 남기는 데도 서툴 수밖에 없는 근본적 한계인지, 아니면 단순히 그런 훈련을 받지 않은 것인지 궁금함. 코딩 에이전트가 구현은 잘하지만 추상화에는 약했던 내 경험과도 비슷함.
근본적 한계라기보다 훈련이 부족한 것이라고 봄. 우선 LLM은 여러 사람과 대화하는 훈련을 더 받아야 함. 인간은 다양한 상대와 상호작용하는 연습을 많이 하지만, LLM은 단일 대화 흐름에 지나치게 치우쳐 있음. 전체 대화를 읽으면 언어가 일관되지만, 일부 결과물만 다른 사람에게 보내면 맥락이 끊겨 어색해짐. 코드와 문서 변경에도 이런 독자에 대한 고려 부족이 이어짐.
자기 자신을 위해 좋은 결과물을 남기는 문제라면, 자기회귀 모델 대신 맥락 언어 모델을 살펴보면 흥미로울 것임. https://arxiv.org/abs/2609.37725
맥락 언어 모델은 자기 맥락을 파일로 보고, 작업을 완료하기 위해 이를 직접 관리해야 함. 이 구조가 관련성 관리 능력을 자연스럽게 요구함.
우리가 아는 한 인간은 뇌의 가중치를 조정해 기억을 저장함. 반면 모델은 세부 방식은 달라도 대체로 어딘가의 메모장에 적어두는 방식임. 글에서도 에이전트 기억을 ‘Claude가 경험으로 얻고 나중에 읽을 수 있는 맥락으로 저장한 지식’으로 정의하며, 가중치 변경 같은 학습 방식은 처음부터 제외함.
둘은 근본적으로 다른 과정이고, 가중치를 조정하는 편이 더 좋아 보임. 하지만 그렇게 되면 모두가 서로 다른 AI를 갖게 되는데, 업데이트는 어떻게 적용할까? Anthropic 같은 회사에는 큰 난제이므로 아마 그 경로를 꺼리는 이유일 것임. 가중치 차이만 저장해 다른 모델에 다시 적용하는 식으로 해결할 수 있을까?