Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 LLM의 성능이 단순히 컨텍스트의 분량에 의존하는 것이 아니라, 정보의 배치와 구조적 관계가 중요함을 강조합니다. 지식 통합을 위한 Zettelkasten 방식이나 전략적 망각 같은 접근법이 필요하며, 향후 모델이 자체적으로 컨텍스트를 파일처럼 편집할 수 있는 방향으로 발전할 것으로 전망합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기이 글이 모든 원인을 “컨텍스트가 너무 길어서”로 돌리지 않는 점이 좋음. 컨텍스트는 분량뿐 아니라 정보의 배치도 중요함. LLM의 어텐션은 연관된 단어와 개념의 관계를 찾으며, 관련 정보가 텍스트에서 가까울수록 잘 작동함. 의존 거리 최소화(DLM) 를 알아두면 도움이 됨. 이미지의 두 문장은 단어와 의미가 같지만, 문장 C는 관련 단어 사이의 거리를 최소화함. 문단과 절도 관련 정보를 여러 수준에서 가깝게 배치하면 AI와 인간 모두 이해하기 쉬워짐. 불필요한 정보가 주변 정보 사이를 벌려놓는다는 점에서 점진적 공개와 하위 에이전트도 중요함.
예를 들어 스킬의 핵심 정보를 맨 아래에 두면, 로드 직후 시작되는 추론 블록과 가까워져 모델이 참고하기 쉬워질 수 있음. 추론과 대화가 길어져 초기 지시가 멀어졌다면 요약을 반복해주는 것도 유용하지만, 알림이 너무 많으면 다른 정보의 거리가 벌어짐. 한편 시스템 프롬프트를 무시하지 않도록 초반 정보에 가중치를 주는 경향도 있다고 보므로, 핵심 사실을 대화 맨 앞에 두는 방법도 활용할 수 있음.
반복 블록을 직접 저장하지 않고 참조하는 압축 알고리즘에서도 관련 정보가 모여 있으면 압축률이 좋아짐. 지능과 압축의 유사성을 보여주며, DLM의 정보이론적 측면도 시사함.
지나치게 정밀한 기억은 시간이 지나면 서로 충돌하고 복잡해지며, 이를 어떻게 처리할지는 아직 풀리지 않았다는 대목이 인간의 기억이 불완전한 이유를 설명해줌. LLM에 바라는 완벽한 기억이 오히려 창의성을 방해하고 적응에 불리할 수 있어 보임. 전략적 망각은 비결정적 시스템을 더 잘 활용하도록 도와줌. 완벽한 기억은 컴퓨터 자체가 담당하면 되므로 LLM에 반드시 필요한 것은 아님. 루프 엔지니어링 같은 추세 속에서도, 다소 낡게 들리는 컨텍스트 엔지니어링이 계속 필요한 이유가 됨.
에이전트 설계는 아직 제텔카스텐(Zettelkasten) 에서 배울 것이 많다고 봄. 추가만 허용하는 정책과 지속적인 정리로 지식을 통합하는 접근임. 일부는 구현됐지만 여전히 잠재력이 큼.
다음 발전 단계는 모델이 컨텍스트를 파일처럼 편집하도록 자기 컨텍스트의 완전한 제어권을 주는 것이라고 봄. 최근 논문에서는 컨텍스트 관리 자체를 별도로 훈련하는 방안도 다룸. 접두부 캐시가 무효화되는 문제에는 접미부 캐시를 구현하는 방안을 제안함.
논문은 https://arxiv.org/abs/2609.37725에서 볼 수 있음.
지능형 애플리케이션과 하네스, 작업 흐름을 만들 때 “무엇을 코드로 결정적으로 처리하고, 언제 모델에 확률적으로 맡길지 선택해야 한다”는 발표의 마지막 문장이 특히 좋음.
AI를 언제 어떻게 쓸지 판단할 때 내가 따져온 핵심을 잘 담아냄. AI에게 작업을 시킬지, 그 작업을 수행할 도구를 만들게 할지 자주 고민하는데, 답의 상당 부분은 해당 작업이 얼마나 결정적이거나 확률적인지에 달려 있음.
“FireRed의 차 관련 작업이 가중치에 들어 있어 컨텍스트를 오염시켰다”는 것은 서로 다른 개념을 섞은 것 아닌가? 컨텍스트 오염은 컨텍스트 속 내용 때문에 모델이 제대로 행동하지 못하는 것으로 이해했음. 가중치에 원인이 있다면 그냥 모델 자체의 결함 아닌가?
의도적 망각이라는 방향이 마음에 들며, 코드·설계·의도 같은 산출물에 진행 상황을 저장한 뒤 새 컨텍스트로 시작하는 방식이 잘 작동했음.
산출물에는 코드뿐 아니라 작업 후 정리한 설계와 실행 계획도 들어감. 이를 다른 에이전트에 넘겨 접근법을 검증하고, 목표를 갱신한 뒤 새 컨텍스트로 작업을 재개함. 뜻밖에도 설계 문서와 실행 계획이 코딩의 입력이 아니라 결과물이 됐는데, 이를 어떻게 받아들여야 할지는 아직 모르겠음.
컨텍스트가 20만30만 정도 쌓이면 초기화한다는 방식은 적어도 최신 모델에서는 내 체감과 다름. 모델은 아마 코드베이스를 살펴보느라 25만까지 금방 채우며, 그 정보가 없으면 오히려 성능이 떨어짐. 70만80만 컨텍스트에 이르기 전까지는 큰 변화가 느껴지지 않고, 그 이후도 예전만큼 나쁘지 않음. 특히 코딩에서는 장기 과제를 대상으로 한 검증 가능한 보상 기반 강화학습(RLVR) 이 상당히 도움이 됐을 것으로 추측함.
에이전트가 grep 대신 코드 색인으로 필요한 내용을 찾게 하면 효과가 아주 좋음.
표본이 나 하나뿐이지만, 컨텍스트가 길어질수록 모델이 멍청해지는 듯함. 하네스를 쓰는 고급 사용자는 아니고 비용상 채팅 인터페이스만 쓰는데, OpenAI와 Anthropic의 최상위 모델조차 몇 차례 대화하면 더 어리석은 행동을 하는 것처럼 보임.
DeepSeek v4.1 flash는 컨텍스트가 길어지면 현재 작업을 마무리하고 “다음 세션”에 다시 시작하자거나, 컨텍스트 예산이 거의 소진됐다는 말을 하기 시작함.
그래서 직접 인수인계 파일을 작성하게 한 뒤 컨텍스트를 완전히 비우고 있음. 하네스가 할 압축을 수동으로 하는 셈이라 이상하게 느껴지지만, 실제로 효과는 있음.
당장 출처를 제시할 수는 없지만 이미 잘 알려진 현상임. 관련 논문도 몇 편 있고, Anthropic 문서에도 목표 달성에 필요한 최소한의 컨텍스트만 전달하라는 내용이 있음. 많이 쏟아넣을수록 품질이 떨어짐.
나도 같은 현상을 겪었고, 이것이 내 코딩 에이전트 하네스 설계에 큰 영향을 줬음.
여기에 Claude API의 짧은 캐시 TTL 5분까지 겹치면, 캐시가 만료돼 일부 세션의 비용이 적정 수준의 10배쯤 나오기도 함. TTL을 1시간으로 늘릴 수는 있지만 토큰 비용이 상당히 올라감.
몇 달 전까지는 나도 이렇게 했지만, OpenAI와 Anthropic이 자체 하네스를 만들면서 내가 만든 하네스와 충돌하기 시작함. 결국 별도 설정을 하지 않는 편이 오히려 성능이 좋았음.
규칙이나 메모리를 따로 구성할 필요는 없어 보임. 굳이 만든다면 규칙이나 안전장치보다는 기록과 흐름 제어만 담은 스킬·에이전트를 쓰는 편이 앞으로 가장 나아 보임.