4.8 버전이 동적 워크플로우를 쓰지 않을 때 고장 난 것처럼 느껴지는 이유
Why 4.8 feels broken if you're not running dynamic workflows
핵심 요약
4.8 버전의 '편집증적' 행동은 사실 동적 워크플로우에 최적화된 설계 때문이며, 일반적인 코딩 방식에서는 오버헤드로 작용함.
- 모델 최적화 — 4.8은 단일 파일 편집이 아닌 대규모 그래프 구조 메모리 추론에 최적화됨
- 편집증적 행동 — 외부 데이터 및 도구 결과의 간접 주입을 방지하기 위해 설계상 더 의심이 많아짐
- 플랜 격차 — Pro 티어는 동적 워크플로우를 지원하지 않아 모델의 오버헤드만 체감하게 됨
- 워크플로우 차이 — 오케스트레이션 스크립트를 사용하는 동적 워크플로우 환경에서는 해당 행동이 정상적으로 작동함
지난 48시간 동안 4.7 돌릴 때랑 똑같은 방식으로 4.8을 돌려봤거든. 빡빡한 코딩 루프, 직접적인 대화, 짧은 세션 위주로 말이야. 근데 진짜 무슨 편집증 걸린 것처럼 굴더라. 건드리지도 않은 파일을 계속 다시 읽질 않나, 있지도 않은 프롬프트 인젝션을 잡아내질 않나, 내가 시키지도 않은 검증 사이클에 토큰만 오지게 날려 먹음.
그러다 시스템 카드를 읽어봤는데, 4.8의 핵심 개선 사항은 코드 생성이 아니었음. 바로 긴 컨텍스트에서의 그래프 탐색 능력임. GraphWalks BFS F1 점수가 256K 컨텍스트에서 76.9%에서 85.9%로 껑충 뛰었거든. 이건 단일 파일 수정 능력이 아니라, 그래프 구조로 된 메모리 전반을 추론하는 능력이 좋아진 거임. 프롬프트 인젝션에 예민하게 구는 것도 다 이유가 있더라. 4.8은 설계 단계부터 의심이 많아지도록 조정됐거든. 안전장치 없는 상태에서 코딩 인젝션 테스트해보면 4.7보다 오히려 성능이 좀 떨어짐. 왜냐면 툴 결과값이나 외부 데이터에서 들어오는 간접적인 인젝션을 대규모로 처리하려고 튜닝됐기 때문이지.
4.8은 다이내믹 워크플로우랑 짝을 이뤄야 제맛임. 클로드가 JS 오케스트레이션 스크립트를 짜고, 하위 에이전트들한테 일을 뿌리고, 중간 결과물은 컨텍스트 윈도우가 아니라 스크립트 변수에 저장하면서 세션 내에서 이어가게 만드는 식이지. 이런 구조에서는 파일을 다시 읽는 행동이 충분히 이해가 감. 수백 개의 하위 에이전트를 관리하는 오케스트레이터 입장에서는 라우팅하기 전에 상태 확인이 필수니까. 근데 나처럼 빡빡한 대화 루프에서 쓰면 그냥 퇴보한 것처럼 느껴지는 거임. 내 생각엔 사람들이 "편집증적이다"라고 느끼는 대부분의 현상이, 4.8이 원래 설계된 목적대로 작동하는데 사용자가 그에 안 맞는 방식으로 쓰고 있어서 생기는 문제 같음. 이건 다이내믹 워크플로우가 실제로 돌아가는 엔터프라이즈/팀/맥스 컨텍스트 기준 이야기고. 만약 프로 플랜 쓰고 있으면 플랜 티어 제한 때문에 조용히 솔로 모드로 강등되니까, 4.8의 오버헤드만 고스란히 짊어지고 정작 아키텍처 이점은 하나도 못 누리는 꼴이지. 그쪽 상황은 내가 직접 테스트 안 해봐서 모르겠다.

