큰 컨텍스트 창을 신뢰하지 마라

AI의 기본기는 배우는 게 꽤 즐겁지만, 지금 흘러가는 방향에는 동의하지 않음
이런 스레드의 댓글들이 얼마나 불안하게 느껴지는지 말로 표현하기 어렵다. “XYZ가 나한테는 이렇게 됐다”는 선의의 경험담이 Facebook의 반려동물 관리나 요리 스레드 조언처럼 보임
3D 프린팅 Facebook 그룹은 더 심한데, 프린트는 하지만 실제로 무슨 일이 벌어지는지 이해하고 싶은 사람이라면 무슨 뜻인지 알 것 같음 LLM 세계, 특히 클라우드 LLM 세계에서는 공유된 엄밀함이 완전히 무너지고, 결국 주술적 따라 하기로 줄어든 느낌임. 누구도 다른 누구보다 더 맞거나 틀리지 않게 됨
“컨텍스트를 Dawn 주방세제로 닦고 말린 다음 풀스틱을 한 겹 발라봤나요?” 같은 분위기임
도와주려는 사람들을 너무 모질게 말하고 싶진 않다. 다만 다른 주제의 스레드와 너무 다르게 느껴짐. 보통은 누군가의 제안을 다른 사람들이 논쟁하거나 다듬고, 누군가가 bash 히스토리 선택 방식 같은 걸 설명해서 인생이 바뀌기도 하는데, 이런 스레드는 결국 “위협하면 먹히는 게 이상하지 않나요?”로 흐른다

LLM 작업흐름의 임의적이고 비결정적인 성격은 정말 찝찝함. 오래된 임베디드/시스템 쪽 사람으로서 항상 결정성과 반복 가능성을 우선해 왔음
그런데 에이전트는 대단하고, “사고 과정 설계자”가 되는 것도 즐겁다. 되돌아가진 않을 것임. AI 개발이 오늘 멈춰도 내 커리어는 예전과 같지 않을 듯함

기술 업계에는 LLM이 나오기 훨씬 전부터 이런 게 늘 있었음
객관적이고 측정 가능한 기준 대신 “조금 더 유명한 회사가 그렇게 하니까”로 결정되는 회의를 너무 많이 겪었다. 심지어 그 회사가 해당 방식을 보편적으로 따르지 않는다는 증거도 놀랄 만큼 힘을 못 썼음

IT 조언은 원래 어느 정도 이런 면이 있었음. 시스템과 결과가 복잡할수록 “더 좋다”와 “더 나쁘다”를 명확히 정의하기 어려워짐
여기에 LLM이 강하게 비결정적이라는 사실까지 더해지면, LLM 조언은 사실상 정원 가꾸기 조언처럼 됨
심지어 “벤치마크”도 대부분 누군가의 감각을 어느 정도 성공적으로 결정화해 보려는 시도에 가깝다

답답함에 크게 공감하고 대체로 동의함. LLM 기반 작업흐름을 형식화하려고 할 때마다, 왜 어떤 것은 되고 어떤 것은 안 되는지 아무도 제대로 모르는 것 같아 다시 실망하게 됨
그래서 결국 /plan으로 돌아가 “구현을 반복하기 전에 나중을 위해 Markdown 문서에 적어두라”고 시키고, 다음 달쯤에는 좀 더 엄밀하고 합리적 근거가 있는 무언가가 나오길 기대함
풀스틱은 전혀 쓰지 않는데 필요가 없기 때문임. 하지만 Dawn은 Bambu 빌드 플레이트를 다시 잘 붙게 만드는 데 꽤 효과가 있어 보인다. 일부러 찾아 쓴 건 아니고 설거지용으로 이미 있었음. IPA가 안 먹혀서 Dawn을 써봤고, 여러 번 출력물이 다시 잘 붙게 해줬다. 아직 N=30까지는 못 갔음

머릿속의 “공유된 엄밀함” 자체가 환상이고, LLM과 그 컨텍스트 문제가 그걸 드러내는 것일 수도 있음
수십 년간 살아온 기술 업계에서 엄밀함은 별로 보지 못했다. 도구는 늘어나고, 패러다임은 생겼다 죽고 다시 나타나며, 무엇이든 재는 잣대에는 단위가 다른 경쟁 잣대가 있음. 전력과 신호의 물리, 실리콘 웨이퍼의 지배적 비용을 지나면, 훨씬 오래된 소수 학문에 비해 우리는 거의 모두 숙련도만 다른 땜장이들에 가깝다
컨텍스트 한계는 비교적 쉽게 다뤄 왔다. 명세를 정하고 범위를 제한하면 됨. LLM이 좋은 결과를 내려면 명확한 명세와 강한 지도가 필요함
하지만 이것도 현재의 땜질식 실무 감각일 뿐이다. 어쩌면 90일 뒤에는 이 부담마저 사라지고, 간단한 프롬프트 하나로 세계적 수준의 운영체제와 프로그래밍 언어, 둘을 위한 수학적 형식 기반까지 생성될지도 모름

에이전트 루프에 단순한 제약 하나를 걸어 컨텍스트 크기 문제를 피하고 있음. 사용자 최상위 대화 스레드에서는 모든 도구 호출을 막는다. 도구 호출이 필요한 일은 에이전트의 재귀 호출 안에서만 일어나고, 결과만 호출자에게 반환하게 함
100만 LOC가 넘는 코드베이스에서도 하루 종일 같은 고수준 대화를 이어가면서 의미 있는 토큰 한계에 닿지 않았다. 압축이나 요약 요령도 필요 없음. 재귀 호출에서 5천만 토큰을 태워도 루트 대화 스레드는 10만 토큰도 안 건드릴 수 있음
에이전트가 다시 Narnia로 내려갈 때마다 “부트스트랩”하는 재작업은 필요하지만, 항상 모든 걸 담으려는 커다란 평면 컨텍스트를 들고 다니는 것보다 훨씬 효율적임 재귀는 토큰 사용량 제어에 매우 효과적이지만 한계도 있다. 재귀 깊이 1을 넘어서 이득을 본 적은 없음. 에이전트가 몇 번 시도하는 건 봤지만 실제 성능은 안 나왔다. 외부의 기호적 재귀는 최전선 모델들이 학습한 대상이 아닌 듯함. 컨텍스트 안에서 재귀를 흉내 내는 데는 훌륭하지만, 토큰 사용량을 줄이려는 목적이라면 그건 원치 않는 방향임

Claude Code를 쓰는 사람이라면 모든 작업을 워크플로 안에서 하라고 시키면 됨. 그용 도구가 있고, Opus 4.8과 함께 나온 기능인데 긴 작업도 좀 더 잘하는 것 같음
이 시점에서는 메인 대화가 작업을 조율하는 역할만 하게 된다

직관적으로 말이 됨. 어떤 하네스를 쓰길래 그런 제약을 설정할 수 있는지, 어떻게 설정하는지 궁금함

Claude Code는 어떤 경우 이걸 자동으로 하는 듯함. “컨텍스트를 많이 먹겠다”는 식의 휴리스틱이 있어서 하위 에이전트로 넘기기로 판단하는 것 같음
문제 해결이나 데이터 분석 흐름에서 자주 보는데, 데이터 수집과 집계를 하위 에이전트에 던진 뒤 요약 결과만 꺼내온다
비슷하게 메인 에이전트가 설계 문서나 Markdown 파일에 컨텍스트를 유지하고 진행하면서 업데이트하게 하기도 함. 그러면 언제든 지우기, 재시작, 인계가 가능해짐

다른 방식을 쓰고 있는데, 아직 얼마나 잘 동작하는지 파악 중임. 재귀로 들어가는 대신, 컨텍스트가 너무 커지거나 막히면 에이전트가 요약/보고/성찰 단계를 거쳐 스레드를 재시작하고, 핵심 발견을 영속 메모리에 쓰고 프롬프트를 다시 작성할 수 있게 함
말하자면 꼬리 호출 최적화가 있는 재귀에 가까움
어떤 면에서는 명세 주도 접근의 일반화인데, 형식 명세에 더해 이어받는 버퍼가 메모리에 남는다

흥미로운 이유는 컨텍스트와 토큰 사용량을 줄이는 것이 사용자에게는 이익이지만 AI 공급사의 재무적 이익과는 어긋나기 때문임
전문가가 아니어도 이 “간단한 요령”은 컨텍스트 문제를 고치고 토큰 사용을 훨씬 촘촘히 제어하게 해줄 것처럼 들린다. 이런 팁을 HN 댓글로 공유해 줘서 고맙다. 앞으로 아는 사람들이 AI 에이전트를 쓰는 방식이 바뀔 수도 있겠음. 따라가기가 어렵다

Anthropic이 구독 플랜에서 100만 토큰 컨텍스트 창을 제공한 뒤로는 Opus에서 이런 경험을 하지 못했음. 평소에도 50만 토큰을 자주 넘기고, 가끔 80만 토큰 근처까지 가도 이 문제가 보이지 않는다
진짜 한계에 가까운 90만 토큰 이상에서는 어느 정도 봤지만, 글쓴이가 본 것만큼 심하진 않았음
애초에 단일 작업이나 같은 컨텍스트를 유지할 만큼 관련된 작업 묶음에서는 컨텍스트 창을 그렇게까지 채우는 일이 드물고, 보통은 20만~60만 정도임
이런 경험을 하는 사람이 전혀 없다는 뜻은 아니지만, 어떤 사람들에게는 이름까지 붙일 정도로 자주 보인다는 게 이상하게 느껴진다

이런 얘기를 자주 보는데, Opus 모델들이 10만 토큰 미만에서도 기본적인 회상 실수를 하는 걸 여러 번 봐서 말도 안 된다고 느낌
개인적으로 Opus의 똑똑한 구간은 6만 토큰 미만이라고 본다. Opus 4.7과 4.8은 더 세분화된 토크나이저 때문에 더 나쁘다

Opus 4.6은 20만을 넘기면 약에 취한 것 같았고, 4.7은 건너뛰었고, 4.8은 약 35만까지 괜찮았으며, Fable은 제한적인 테스트에서 40만을 넘어도 훌륭했음
품질은 상승 추세로 보인다

모두가 같은 모델과 하네스를 쓰는 것도 아니고, 모델을 같은 방식으로 쓰는 것도 아님
모델과 모델 버전마다 서로 다른 어텐션 구조를 쓰고, 이는 긴 컨텍스트 성능에 영향을 준다. 장기 컨텍스트 학습의 양과 종류도 분명 다를 것임
에이전트마다 컨텍스트를 구성하는 방식과 컨텍스트 압축 구현도 다르다
같은 모델, 같은 에이전트/하네스, 매우 비슷한 작업이 아니라면 컨텍스트 크기와 관련한 모델 동작 경험이 같을 거라고 볼 이유가 없다

30만 정도는 자주 넘기고 80만에서도 작업해 봤지만, 분명 관찰 가능한 문제임
문제에 따라 큰 컨텍스트 창이 동작할 수는 있지만, 30만 미만의 작은 컨텍스트 쪽으로 기울이는 편이 더 효과적이라고 느낌

동의함. Claude 계열은 이 면에서 릴리스마다 점점 좋아지고 있음
Opus 4.5는 20만 한계에 다가가면 도구 호출이 실패하기 시작했고, Opus 4.6은 혼란스러워지기 전 약 30만까지 갔고, Opus 4.7은 40만쯤까지 늘릴 수 있었지만 그 뒤 멍청한 구간이 시작됐음. Opus 4.8에서는 50만을 편하게 넘긴 세션도 있었다
Fable은 써본 시간이 제한적이었지만, 80만~90만까지 무리 없이 간 세션도 몇 번 있었다

최근 버전의 Opus는 10만을 넘어도 괜찮지만, 보통은 20만 아래로 유지하려고 함
그래서 소위 메모리 시스템이 대개 모델을 더 멍청하게 만드는 실수라고 본다. 모델에는 메모리가 있는 게 아니라 컨텍스트만 있고, 관련 없는 사실을 컨텍스트에 밀어 넣을수록 문제에 쓸 컨텍스트가 줄어듦. 방해가 적을수록 결과가 좋아진다
에이전트가 뭔가를 기억하게 하는 방법은 인간 개발자가 다른 개발자에게 친절한 프로젝트를 만들 때처럼 작업을 문서화하게 하는 것임. 색인 페이지가 있는 좋은 개발 문서와 체크리스트가 있는 좋은 계획을 간결한 Markdown 파일로 저장하고 저장소에 커밋하는 것이 모델에게 이상적인 메모리이고, 모델이 도대체 뭘 해왔는지 파악하는 데 필요한 이상적인 문서다. 사람이나 다른 모델이 코드 리뷰할 때도 도움이 되고, 단점이 없다

적어도 내 경우 Opus는 계속 메모리에 뭔가를 써놓지만, 같은 실수를 반복하기 전에 그 메모리를 확인하는 건 꾸준히 잊어버림
그래서 “메모리 확인하라고 기억해!”가 다시 메모리로 저장된다. 확실히 잘 작동하는 시스템은 아님

“메모리” 시스템은 개발자들이 AI에 기여하고 있다고 느끼기 위한 방법임

여기 댓글 거의 전부가 개인 경험에 호소하고 있음. 반대로 원글은 여러 모델에 대해 어떤 표준화된 테스트 성능을 비교한 연구 두 편을 참조함
그 테스트들이 얼마나 좋은지는 말할 수 없지만, LLM 성능처럼 모호하고 주관적인 것에 대한 일화적 증거보다는 나쁠 수 없다

일화적 증거를 더 보태자면, 내가 한 모든 테스트에서 Llama 계열은 지시 따르기가 형편없었음. RULER의 다른 모델들은 잘 모르겠다
Chroma 결과에서는 Sonnet 4를 보는데, 내 경험에서도 Sonnet 4는 형편없었다. Sonnet 4.5에서 완벽히 작동한 같은 프롬프트가 Sonnet 4에서는 처참히 실패했음
최신 최고 성능 모델과 공개 가중치 모델을 모두 포함한 새 테스트를 보고 싶다. 최고 성능 모델들은 늘 지시를 더 잘 따르고 주제에서 덜 벗어나는 듯한데, 이를 뒷받침할 데이터가 있으면 좋겠음

그 연구들은 2024년과 2025년 자료임. 현재 Claude 모델에는 적용되지 않는다

AI의 제품 관리자처럼 행동하면서, 만들 기능마다 짧은 PRD를 쓰라고 강하게 요구하는 방식으로 꽤 효과를 보고 있음
이렇게 하면 시간이 지나도 무엇이 만들어졌는지 참조할 수 있고, 각 기능마다 덜 표류하게 된다. 기능마다 별도 대화를 둠
내게는 탈선은 막으면서도 필요할 때 과거 결정을 참조하게 하는 적당한 절충안임. Pocock의 방식에서 마음에 안 드는 점은 PRD를 덜 쓰고 먼저 깊이 있는 논의로 정렬을 맞추는 식인데, 그 초기 왕복에 가장 좋은 구간을 너무 많이 낭비한다는 것임

임시로 하는 건지, 아니면 openspec 같은 더 구조화된 접근을 쓰는지 궁금함
나도 먼저 계획을 세우는 편이지만, 세션 안의 할 일 목록으로 남아서 나중에 참조하기 어렵다

에이전트 내부에서 무슨 일이 벌어지는지 따지는 일은 아마 오래 소프트웨어 개발의 일부로 남지 않을 것임
개인적으로는 이미 LLM과 에이전트를 블랙박스로 본다. 각 기능 요청을 여러 LLM에 주고 결과를 비교함. “세션”을 수동으로 쓰지는 않는다. 결과만 본다. 마음에 안 들면 git reset --hard를 하고 프롬프트를 바꾼 뒤 기능 요청을 다시 시작함
어떤 에이전트가 가장 잘하는지 지속적으로 감을 잡기 위해 로그를 남기고, 내 요구를 가장 잘 충족하는 에이전트의 ELO 점수를 계산함. 내게 중요한 건 그 점수이지, 에이전트가 어떻게 달성했는지는 그다지 중요하지 않다

실제 추론 비용을 생각하면 이건 정말 말도 안 되게 낭비적인 방식이고, 자랑할 일이 아님

어떤 종류의 프로젝트나 코드 작업을 맡기는지 궁금함
보안이나 다른 검증이 많이 필요 없는 프런트엔드 작업 유형에는 괜찮을 수도 있겠다고 추측함
하지만 규제 산업이나 극도로 신중해야 하는 작업에는 적합하지 않아 보인다

어떤 모델이 가장 앞서가고 있음?

맞다, 컨텍스트 관리가 핵심임
자체 프레임워크를 만들고 이 문제를 디버깅하는 데 많은 시간을 쓰는데, 절대적인 컨텍스트 크기보다 창 안에 찌꺼기나 잘못된 방향 지시가 들어 있어 사용자가 중요하다고 생각하는 내용을 덮어버릴 확률이 더 문제임
이건 LLM이 방금 전 접근에서 실패했던 일을 계속 다시 하려는 모습으로 나타난다. 컨텍스트 창 안에서 어떤 것이 자주 등장하면, 설령 틀린 것이어도 가중치가 생김
LLM에 도구를 잔뜩 주지 않고, 도구를 검색하는 데 쓸 도구를 주는 식의 요령도 많이 있음
하지만 더 큰 해법은 프로세스에 있다. superpowers 같은 걸 써서 LLM을 단계별로 강제하고, 앞으로 가져갈 컨텍스트를 통제해야 함

Pi용으로 아주 작은 개인 확장을 만들어 /last 명령을 추가했음. 전체 세션을 지우고 에이전트의 마지막 출력 메시지만 남긴다
이렇게 수동 “압축”이 가능해짐. 기본적으로 에이전트에게 “논의한 계획을 편집해야 할 파일 참조와 함께 정리하라”고 말한 뒤 /last를 호출하고, 그다음 구현하라고 지시함
[1] https://pi.dev/

여기서 “모델들”이라고 뭉뚱그리는 게 마음에 들지 않음. 모델마다 어텐션 구조가 다르고, 그래서 긴 컨텍스트 동작에도 큰 차이가 날 수 있다
긴 컨텍스트가 문제이고 대부분 모델에서 품질 저하가 생긴다는 건 맞지만, 오래된 모델의 동작을 새 모델에 그대로 일반화하진 않겠다