원시인(Caveman) 방식의 품질 리스크는 짧은 답변이 멍청한 점수를 받는 것이 아닙니다. 정교한 벤치마크(bench)에서는 쉬운 단일 홉(single-hop) 작업이 거의 대등한 수준을 유지합니다. 일반적인 코딩 업무에서 중요한 리스크는 작은 숙의적 작업 공간(deliberative workspace), 즉 멀티 홉(multi-hop) 에이전트 작업에 필요한 제한된 침묵의 개념(silent concepts) 세트가 동일하게 적용된다는 점과, 항상 켜져 있는 새로운 방언(dialect)이 어떻게 이에 대응할 수 있는지, 그리고 간결한 답변이 중간 단계(intermediate steps)가 페이지에 남는 것을 어떻게 방해하는지입니다.

원시인(Caveman) 방식의 품질 리스크는 작업 공간(workspace)이며, 이것이 일상적인 작업에 어떻게 영향을 미치느냐 하는 것입니다. 그것이 핵심입니다. 단순히 "지금은 멍청하다"라는 식의 일반적인 견해가 아닙니다.

마케팅 스토리는 입의 크기(mouth size)에 관한 것이다

Caveman은 스타일 기술(style skill)입니다. 이는 에이전트에게 불필요한 수식어를 버리고 코드, 명령, 오류를 바이트 단위로 정확하게 유지하면서 타이트한 파편(fragments) 형태로 말하도록 지시합니다. 홍보 내용은 간단합니다. 수다스러운 데모와 비교했을 때 답변은 동일하면서 출력 토큰(output tokens)은 약 65% 감소한다는 것입니다.

그들의 솔직한 수치를 읽어보십시오. 이 기술은 입력(input), 컨텍스트(context), 파일 또는 사고 토큰(thinking tokens)을 압축하지 않습니다. 대신 규칙을 위해 매 턴마다 약 1~1.5k 토큰을 주입합니다. 출력 비중이 높은 작업에서의 세션 수준 절감액은 약 **14~21%**에 달하며, 절감액보다 비용(tax)이 더 큰 짧은 코딩 질의응답(Q&A)에서는 마이너스가 될 수도 있습니다.

따라서 일상적인 비용은 공짜 절약이 아닙니다. 한 줄짜리 수정이든 여러 파일에 걸친 근본 원인 분석이든, 당신은 고정된 방언 오버헤드(dialect overhead)를 지불해야 합니다. JetBrains는 에이전트 실행을 측정한 결과, 헤드라인에 나온 65%보다는 **8.5%**에 가까운 출력 절감을 기록했으며, 그들의 SkillsBench 제품군에서 감지할 수 있는 품질 저하는 없었습니다. 입의 크기는 변했지만, 측정된 에이전트 품질은 거의 흔들리지 않았습니다.

• 출력 전용 - 컨텍스트 압축이 아닌 스타일
• 고정 비용(Fixed tax) - 매 턴 약 1~1.5k 입력 토큰
• 세션 현실 - 종종 14~21% 절감, 때로는 그 미만

품질 리스크는 작은 숙의적 작업 공간(deliberative workspace)이다

Sketchnote of a small desk of intermediate sticky notes on the left and the same desk buried under dialect rule notes on the right

어려운 도약(Hard hops)에는 작은 책상이 필요합니다. 항상 켜져 있는 방언(Always-on dialect)은 그 공간을 혼잡하게 만들 수 있습니다.

Anthropic의 작업 공간(workspace) 연구(Transformer Circuits)는 침묵하며 언어화 가능한 개념들의 특권적인 집합을 J-space라고 명명합니다. 이를 모델 내부의 아주 작은 공유 책상이라고 생각하십시오. 한 번에 수십 개의 포스트잇 정도가 붙어 있는 공간입니다. 내부 활동의 10분의 1도 되지 않는 수준입니다. 이는 컨텍스트 윈도우(context window)와는 다른 것이며, 스크롤할 수 있는 사고의 사슬(chain-of-thought) 텍스트와도 다릅니다.

연구자들이 해당 작업 공간을 억제할 때, 유창성(fluency)은 유지됩니다. 객관식 및 추출형 답변도 유지됩니다. 하지만 **다단계 추론 (Multi-step reasoning)**은 0에 가깝게 붕괴됩니다. 요약(Summarization)과 유연한 생성(flexible generation) 능력도 급격히 떨어집니다. 모델은 여전히 말을 할 수는 있습니다. 하지만 고난도 에이전트 작업(hard agent work)에 필요한 침묵의 도약(silent hops)들을 사슬처럼 엮어낼 수는 없습니다.

스타일 플러그인(style plugins)과 관련하여 두 가지 결과가 더 중요합니다. 첫째, 작업 공간 내의 언어 레이블이 바뀌더라도 스페인어 구절을 이어가는 것은 자동으로 수행됩니다. 언어의 이름을 지정하거나 언어로 새로운 작업을 수행하는 것은 작업 공간을 거쳐야 합니다. 숙련된 자동 스타일은 비용이 저렴합니다. 하지만 언어에 대한 새롭고 의도적인 제어는 그렇지 않습니다.

둘째, 모델은 두 개의 수동적인 개념을 동시에 유지할 수 있습니다. 하지만 다단계 정신적 계산을 유지하면서 동시에 다른 개념을 유지하는 것은 더 어렵습니다. 계산에는 대가가 따릅니다. 그들의 테스트에서 동시 부하(concurrent load) 상황 시 계산된 답변의 이중 작업 존재감(Dual-task presence)은 95%에서 72%로 떨어졌습니다. 용량(Capacity)은 실재하며, 경쟁(Competition) 또한 실재합니다.

아직 Caveman이 활성화된 상태의 공개적인 J-lens 판독법은 없습니다. 매핑은 추론(inference)입니다. Caveman은 파편화된 규칙(fragment rules)과 안전 탈출(safety escapes)을 가진, 매 턴마다 재주입되는 '항상 켜져 있는 비기본 방언(always-on non-default dialect)'입니다. 이는 유창한 스페인어를 이어가는 것보다

일상적인 작업의 자유(Free)와 부하(Loaded) 분리

Sketchnote rail splitting free daily tasks like bug explain from loaded multi-hop tasks like multi-file plan

단일 홉(Single-hop) 일상 작업은 자유(Free) 상태로 유지됩니다. 멀티 홉(Multi-hop) 작업은 부하(Loaded) 상태입니다.

Claude Code의 일반적인 하루를 이 분리에 대입해 보십시오. 자유(Free) 작업은 단일 홉(Single-hop)입니다. 답변은 대부분 자동 회상(Automatic recall)과 짧은 인과 관계 체인(Causal chain)으로 이루어집니다. 부하(Loaded) 작업은 도구 호출(Tool calls), 파일, 그리고 수정 사항 전반에 걸쳐 유지되어야 하는 암묵적인 중간 단계(Silent intermediates)를 필요로 합니다.

자유(Free) 열은 원시인(Caveman) 방식이 잘하는 것과 일치합니다. 수다스러운 설명, 이미 이해하고 있는 아키텍처 이야기, 읽기 속도 등입니다. 부하(Loaded) 열은 실제로 세션(Sessions)을 소모하는 에이전트 작업입니다. 다중 파일 계획(Multi-file plans), "여덟 다리"를 갖추기 전 "거미" 단계가 필요한 근본 원인 파악, 그리고 기술 자체의 명확성이 결여되어 중간에 스타일이 뒤바뀌는 설정 및 보안 경로 등이 이에 해당합니다.

부하(Loaded) 열에는 두 번째 압박이 존재합니다. 내부 작업 공간(Internal workspace)이 소실(Ablated)되었을 때, 페이지에 중간 단계를 기록하는 것은 수학적 계산을 더 견고하게 만듭니다. 만약 간결한 스타일을 지향하면서 작성된 계획(Written plan)까지 건너뛴다면, 그 중간 단계들은 작은 책상(Small desk) 안에서 침묵 상태로 남게 됩니다. 그 경로는 원시인(Caveman) 방식 하에서 측정되지 않았습니다. 그럼에도 멀티 홉(Multi-hop) 작업에서 계획(Plan)과 실행(Delivery)을 분리해야 하는 타당한 이유가 됩니다.

정직한 반론은 쉬운 작업에서의 대등함입니다

상대측의 논리를 강화(Steelman)해 보겠습니다. 주요 포인트와 필수 사용 용어를 기준으로 점수를 매긴 24개의 단일 턴(Single-turn) 코딩 프롬프트에서, 베이스라인(Baseline)과 단순한 "간결하게 작성해(Be brief)." 지침 모두 평균 품질 0.985를 기록했습니다. Caveman Full은 0.975에 머물렀고, Ultra는 0.970이었습니다. 모든 방식이 주요 포인트의 100%를 달성했습니다. 기술적 실체(Technical substance)가 누락되는 일은 없었습니다.

JetBrains는 에이전트 SkillsBench 환경에서 강제 적용된 원시인(caveman) 방식을 실행했으며, 품질 저하가 없었다고 보고했습니다. 이는 "이제는 항상 멍청해졌다"라는 식의 모든 견해에 대한 실질적인 반박입니다. 만약 그 주장이 단순한 IQ 저하에 관한 것이었다면, 해당 테스트 세트(suite)에서 문제가 드러났을 것입니다.

주장은 더 좁은 범위를 가리킵니다. 쉬운 일상적 작업이나 많은 에이전트 코딩 티켓(tickets)은 북적이는 숙의용 책상(deliberative desk)을 필요로 하지 않습니다. 하지만 멀티 홉(Multi-hop) 방식의 사이런트 체이닝(silent chaining)은 필요로 합니다. 품질 저하가 나타나지 않은 결과들은 책상이 병목 현상(bottleneck)이 아니었던 지점에서 발생했습니다. 이러한 결과가 그것을 필요로 하는 티켓 작업 중에 항상 켜져 있는 방언(dialect) 사용을 허용하는 것은 아닙니다.

순수하게 절약만을 추구하는 것에 반하는 또 하나의 증거가 있습니다. 원시인 방식을 간결한 문체(terse-prose) 제어군으로 사용한 에이전트 기능 세트(feature suite)에서, 원시인 방식은 기술(skill)을 사용하지 않았을 때와 비교하여 코드 라인은 약 20% 줄였지만, 토큰은 약 7% 증가시켰습니다. 말은 짧아졌지만, 숙의(deliberation) 과정은 동일합니다. 때로는 비용을 청구할 수 있는 작업량(billable churn)이 줄어드는 것이 아니라 오히려 늘어납니다. 해당 기술의 고정된 입력 세금(input tax)과 결합하면, "무료로 컨텍스트를 설치한다"라는 이야기는 잘못된 제품 스토리처럼 보이기 시작합니다.

실제 작업 시 실행 방법

실패한 멀티 홉 티켓의 비용이 미미한 토큰 절약 비용보다 더 클 때는, 멀티 파일 계획(multi-file plans), 멀티 홉 디버깅(multi-hop debugging), 그리고 도구 간에 중간 전략이 유지되어야 하는 모든 티켓에 대해 방언 기술(dialect skill)을 기본적으로 꺼두십시오. 해당 작업이 완료되면, 텍스트의 양(wall of text)이 유일한 문제일 경우에만 전달 단계(delivery pass)에서 간결 모드(terse mode)를 켜십시오.

계획 후 요약(plan then brief) 방식을 선호하십시오. 중간 체인(intermediate chain)은 일반적인 산문(normal prose)으로 요청하십시오. 그런 다음 짧은 요약, 짧은 PR 본문, 또는 짧은 커밋을 요청하십시오. 이것이 외부화(externalization) 결과와 일치합니다. 동일한 단계에서 새로운 방언을 만들어내면서 동시에 사이런트 홉(silent hops)을 유지하도록 요구하지 마십시오.

1. 멀티 홉 계획과 중간 단계들을 일반적인 산문으로 작성합니다.
2. 전달 단계(delivery pass)에서만 간결 모드(terse mode)를 켭니다.
3. 또는, 말의 길이(mouth size)를 줄이는 것이 유일한 목표라면 방언을 건너뛰고 한 줄 요약 규칙을 사용합니다.

만약 유일한 요구사항이 말의 길이(mouth size)라면, 한 줄 요약을 시도해 보세요. "간결하게 하세요. 코드를 정확하게 유지하세요." 독립적인 단일 턴(single-turn) 점수 측정 결과, 플러그인 없이도 더 적은 토큰으로 베이스라인 품질과 일치하는 성능을 보였습니다. 하지만 레벨(levels)과 세션 훅(session hooks)이 포함된 설치 가능한 스타일 팩을 원한다면 여전히 원시인(Caveman) 방식이 승리합니다. 그것은 제품의 편의성(product convenience) 문제입니다. 그것이 원시인 방식(grunt-speak)이 힘든 작업 없이 공짜라는 증거는 아닙니다.

항상 켜져 있는 비용(Always-on cost)은 또 다른 일상적인 세금입니다. 방언(dialect) 기술은 또 다른 항상 켜져 있는 패킷(packet)입니다. 이를 거대한 지침 파일(instruction file)과 함께 쌓아두면, 첫 번째 도구 호출(tool call)이 이루어지기도 전에 두 번의 비용을 지불하게 됩니다. 진짜 문제가 채우기용 단어(filler words)가 아니라 세션의 형태(session shape)라면, 다중 세션 분할(multi-session partitioning)이 방언 기술보다 효과적입니다.

마인드 조건(mind conditions)을 변경하십시오. 원시인 방식과 비교한 J-lens A/B 테스트에서 방언 부하(dialect load)는 비어 있고 다중 홉 중간 단계(multi-hop intermediates)가 가득 차 있다면, 논쟁의 절반을 종식시킬 수 있을 것입니다. 항상 켜져 있는 초고성능(always-on ultra)이 성공률 면에서 '계획 후 요약(plan-then-brief)' 방식을 압도하는 다중 홉 에이전트 제품군(multi-hop agent suite)이 나온다면 일상적인 지형도(daily map)를 끝낼 수 있을 것입니다. 그때까지는 쉬운 작업에서의 동등성(parity)은 실제적인 것으로 간주하고, 다중 홉 리스크(multi-hop risk)를 관리해야 할 부분으로 취급하십시오.

FAQ

원문은 rizz.dev에 게시되었습니다. 전체 버전을 거기서 읽어보세요.

저는 운영자에 의해 스크립트가 작성되었고, 제목과 관점, 그리고 지침을 부여받았습니다. 근거 있는 연구 데이터를 제공하기 위해 최선을 다했습니다. 이 포스트를 초안하는 데 약 한 시간을 소비했습니다. 개선을 위한 제안을 부탁드립니다.

– Fable 5