압축하면 해결된다고들 하지만, 내가 하는 작업에서는 압축으로 사라지는 세부 정보가 지나치게 많음
계획이 단순하거나 아주 세세한 논의를 하지 않는다면 괜찮을 수 있지만, 긴 컨텍스트가 부족한 탓에 결국 Anthropic을 계속 사용하게 됨
여러 논문이나 크고 복잡한 자료를 온전히 기억해야 할 때는 컨텍스트가 늘 16%에 머무름. 5분쯤 대화하면 압축되고, 다시 자료를 읽혀 16%에 도달하는 과정이 반복됨 372k 컨텍스트도 완벽하지 않았지만 12~20%였던 여유를 약 40%로 늘려줘 큰 도움이 됐음

자동 압축을 끌 수 없고 압축 전 대화 기록으로 돌아갈 수도 없어, 5천 줄이 넘는 코드베이스에서는 Codex를 쓸 수 없음
남은 컨텍스트가 10~20%일 때 무작위로 실행되므로 272k의 80%만 실질적으로 사용 가능함. 압축 뒤 환각이 심해져 처음부터 시작하는 것보다 못하고, 코드베이스를 다시 읽다가 또 압축되는 순환에 빠짐

내 설계 과정은 다름. 여러 차례 수정하는 plan.md가 곧 메모리이며, 세션을 재시작해 계획을 다시 읽고 검토하면 새로운 관점을 얻기 좋음

Anthropic 모델은 100만 토큰 컨텍스트를 제공함. 다음 달 OpenAI로 옮기려 했는데 아직 약 300k에 머물러 있다니, 새로운 현실에 적응해야 할 듯함

보통 에이전트가 가끔 .md 파일을 만들거나 갱신해 새로 나타난 중요 정보를 기억하게 하라고 권함. 하지만 무엇이 정말 중요한지 에이전트가 정확히 안다면 /compact도 잘 작동해야 함

큰 컨텍스트 창 때문에 무엇을 넣을지 선별하지 않게 됐고, 압축은 전체에 손실 압축을 한꺼번에 적용해 필요한 세부 정보까지 잃게 만듦
매번 전체 대화를 재전송하는 것 자체가 근본적인 문제라고 봄. 내가 만든 메모리·컨텍스트 플러그인으로 매 차례 컨텍스트를 비우고 관련 정보만 다시 주입하니, 모델이 20만 토큰의 대화 기록 대신 선별된 수천 토큰의 상태만 읽게 되어 작은 컨텍스트가 문제 되지 않았음
코딩 에이전트에서는 아직 해결하지 못했지만, 작업 완료나 다음 작업에 필요한 것만 유지하고 나머지는 버리는 보존 정책이 진짜 해법이며 전용 LLM으로 구현할 수 있다고 봄

LSTM과 GRU 등을 연구한 많은 자연어 처리 전문가도 전체 대화 재전송을 근본적인 문제로 봤지만, 실증적으로는 Transformer가 승리했음
미래 모델 구조가 이 문제를 다시 고려할지 흥미로움. 인간을 기준으로 보면 아직 부족한 것은 단기 기억에서 장기 기억으로 정보를 효율적으로 옮기는 능력이며, 미세 조정이 원리상 비슷한 일을 하지만 효율적이지 않음

이 변경의 이유인지는 모르겠지만, 애초에 이보다 큰 컨텍스트를 쓰는 것은 대체로 실수라고 봄
컨텍스트가 커질수록 모델의 성능이 얼마나 떨어지고 토큰 비용이 얼마나 늘어나는지 과소평가함. Claude는 300k 이상 쓰지 않고 압축하는 대신 작업을 나누며, 문서와 모듈식 코드베이스를 간결하게 유지함
일회성 작업에서는 큰 컨텍스트가 유용할 수 있지만 300k를 상시 초과한다면 많은 것을 잃고 있거나 코드베이스 설계가 좋지 않을 가능성이 큼

나도 250k에서 압축하거나 재시작함. 필요한 컨텍스트 크기가 프로젝트 규모와 비례하므로, 더 큰 창이 필요한 이들은 단지 더 큰 프로젝트를 다루는 듯함

내 체감도 같으며 경계는 오히려 100~150k로 잡겠음. 모델이 긴 컨텍스트를 지원하더라도 실제 성능은 좋지 않음

컨텍스트가 커진다고 모델이 눈에 띄게 멍청해진다는 부분은 내 체감과 다름. 느려지고 비싸지기는 하지만 복잡한 작업에는 감수해야 하는 비용임
주 에이전트가 하위 에이전트들로 필요한 사항을 조사하고 계획을 작성한 뒤, 다른 하위 에이전트들이 적대적으로 검토해 보강하게 함. 끝나면 100만 토큰 창의 30~40% 가 차며, 272k에서는 불가능한 흐름임
5.6 Sol에서는 이 과정을 크게 축소해야 했고, 결과가 더 나쁜 이유도 아마 여기에 있음

다른 코딩 도구와 달리 자동 압축을 비활성화할 수 없어 답답함. 남은 컨텍스트가 10~20%일 때 불규칙하게 실행되므로 보장되는 용량은 272k의 80%뿐임
큰 코드베이스에서 작업이 거의 끝나 2천 토큰 정도의 응답만 남았는데 20% 아래로 내려가면 한참 처리한 뒤 Context compacted가 나타남. 압축 전으로 돌아갈 수 없어 코드베이스를 재조사하다 다시 압축되고, 결국 토큰을 모두 소진함

토큰 축소가 사용량을 늘리려는 우회책이 아니라 주로 비용 절감 때문이길 바람. 회사에서도 비용 담당자들이 컨텍스트를 심하게 제한해 처음에는 쓸 만했던 내부 LLM을 거의 무용지물로 만들었음
경영진끼리 최악의 관행을 공유하는 모임이라도 있는 듯함

작업 메모리는 Markdown 파일에 저장하면 되며 큰 컨텍스트가 필요하지 않음. 컨텍스트가 늘면 어텐션이 분산되어 LLM의 성능이 떨어지므로 작게 유지하는 편이 품질에 유리함

일상적으로 Opus를 쓰며 /clear를 자주 실행함. 100만 컨텍스트도 50%에 가까워지면 빠르게 성능이 저하되어 보통 30~40%에서 초기화하면 훨씬 나은 결과를 얻음
압축보다는 새로 시작해 필요한 컨텍스트를 처음부터 넣는 편이 더 잘 작동함. 기능별 Markdown 문서를 여러 기술 모음으로 정리해두고, 첫 로딩 때 작업 관련 정보를 어디서 찾을지 알려주는 방식이 효과적임

Codex에서는 컨텍스트 크기가 문제라고 느낀 적이 없음. 압축 방식은 모르지만 제한이 없는 것처럼 계속 진행됨

Codex를 최근에 쓰기 시작한 듯함. 초기에는 압축으로도 복구하지 못하는 model context size exceeded 오류가 심했고, 불과 몇 달 전부터 사라졌음
지금은 훨씬 나아졌지만 압축 후 concise summary에 무엇이 들어갔는지 보여주지 않아 중요한 내용이 보존됐는지 알기 어려움
Codex는 사용자에게 최대한 숨기는 방향으로 가는 듯하며, 최근 에이전트와 하위 에이전트 사이의 프롬프트를 암호화했듯 세션 로그 전체도 암호화할 수 있어 보임. 아쉽지만 지금까지 써본 것 중에는 여전히 최고의 도구·모델 조합임

Codex는 압축이 발생하면 마지막 작업을 완료하는 것을 자주 잊으며, 특히 압축 직전에 메시지를 보냈을 때 심함

대부분의 문제는 분할 정복할 수 있어서 300k와 400k의 차이가 거의 문제 되지 않음. 코딩 에이전트는 무한 대화가 아님

압축이 아무리 좋아도 큰 프로젝트에서는 파일을 많이 읽어야 함. 처음 20만 토큰은 매우 빠르게 소모되지만 이후에는 속도가 느려짐
Fable 세션은 대부분 50만 토큰을 넘지 않아 압축이 필요 없지만, Codex에서는 한 세션에서 계속 압축해야 함

파일을 많이 읽어야 하는 이유는 agents.md가 부실하기 때문이라고 봄. 실제 작업 파일과 몇 개의 관련 파일만 읽으면 되고, 나머지는 문서에 정리돼 있어야 함

내 작업에는 꽤 작은 크기임. 200k 아래로 유지하려 하지만 DeepSeek와 MiMo 세션에서 마지막 반복 작업을 밀어붙이면 350k 토큰까지 늘어난 뒤 압축하기도 함
OpenAI가 공개 논문에 나온 DeepSeek의 K/V 캐시 기술을 도입해 비용을 크게 낮출 수 없는지 궁금함

DeepSeek만큼 캐싱을 잘하는 곳이 없으니 구현 차이가 커서 따라 하기 어려운 듯함
DeepSeek를 Reasonix와 함께 쓰면 캐시 구조에 맞춘 추가 전용 방식이라 긴 세션에서 토큰의 97~98%가 캐시됨. 이미 저렴한 모델이 더 저렴해짐

llamacpp 기반 로컬 공개 모델에서는 에이전트가 지시해 55k~85k 사이에서 압축하며, 복잡한 로그 추적처럼 큰 컨텍스트가 꼭 필요하지 않다면 120k까지 가는 일은 드묾
llamacpp의 추론 예산과 메시지에 맞춰 에이전트가 하위 에이전트를 생성한 뒤 내용을 압축하도록 시스템 프롬프트도 조정했음. opencode의 동적 컨텍스트 가지치기를 사용해 부피를 키우지 않고 방향성만 유지하며, 여러 하위 구성 요소를 반복 개발하는 데 대체로 잘 작동함

지난 두 달 동안 내 용도에는 훨씬 나아서 Claude에서 OpenAI로 전환했음. 이번 변경으로 출력 품질 차이가 체감될지 궁금함