요약(TL;DR). Forge (CAIS 2026)는 소형 자체 호스팅 모델을 런타임 가드레일(retry nudges, step enforcement, error recovery, context compaction, VRAM budgeting)로 감싸며, 8B 모델이 에이전트 워크플로우(agentic workflows)에서 53%에서 99%로 성능이 향상되었다고 보고합니다. 저의 자체 컨텍스트 엔지니어링 키트(여섯 개의 Markdown 파일: CLAUDE.md, AGENTS.md, MEMORY.md, TESTING.md, GLOSSARY.md, ADR template)는 실제 아키텍처 감사에서 Gemma 4 31B를 12개 중 9개 발견에서 12개 중 11개 발견으로 끌어올렸으며, 이는 Claude Opus 4.7 성능의 약 75%에서 92% 수준에 해당합니다. 동일한 문제 영역이지만, 메커니즘과 비용 구조가 다릅니다. 이 포스트에서는 두 방법 모두를 살펴보고, 두 방법이 충돌하는 지점과 가상의 결합 방식이 어떻게 보일지 설명합니다.

두 접근 방식이 해결하는 문제
단일 채팅 턴 이상의 복잡한 작업에 소형 오픈 웨이트(open-weights) 모델을 실행해 보았다면, 아마도 동일한 현상을 목격했을 것입니다. 단일 단계(Single-step) 정확도는 괜찮아 보이지만, 다단계 에이전트 루프(Multi-step agent loops)는 무너집니다. 모델이 질문에 95%의 확률로 올바르게 답변할 수 있더라도, 여전히 고장 난 5단계 워크플로우를 내놓을 수 있습니다. 수학적 계산은 냉혹합니다. 95%의 정확도를 가진 5개의 체인 단계(chained steps)는 77%의 엔드 투 엔드(end-to-end) 완료율을 보입니다. 9단계의 경우 63%가 됩니다. 이것이 바로 복리적인 신뢰성 문제(compounding reliability problem)이며, 실제로 완수해야 하는 모든 에이전트 작업에 대해

이 프로젝트를 처음 알린 Hacker News 스레드(작성 시점 기준 106점, 댓글 35개)는 이를 8B 모델을 53%에서 99%로 끌어올리는 프레임워크로 인용했습니다. 다른 하나는 제가 지난 2주 동안 이 블로그에 게시해 온 연구 분야입니다. 그 논지는 다릅니다. 모델을 런타임(runtime)에 가로채는 대신, 모델이 작업을 확인하기도 전에 입력 프레임(input frame)을 다시 작성합니다. 6개의 파일로 구성된 컨텍스트 키트(Context Kit)(프로젝트 컨벤션(conventions)을 위한 CLAUDE.md, 출력 스키마(schemas)를 위한 AGENTS.md, 지속적인 발견 사항을 위한 MEMORY.md, 어설션(assertions)을 위한 TESTING.md, 어휘를 위한 GLOSSARY.md, 그리고 결정을 위한 ADR 템플릿)는 명명된 실패 패턴(failure patterns), 구조화된 출력 계약(structured output contracts), 그리고 이전 발견 사항의 메모리를 시스템 프롬프트(system prompt)에 로드합니다. 실제 아키텍처 감사(architecture audit) 결과는 다음과 같습니다. Gemma 4 31B는 Claude Opus 4.7이 12개 중 12개를 찾아낸 것과 대조적으로 12개 중 11개의 발견 사항을 포착했습니다. 키트 없이 동일한 작업에 동일한 모델을 사용했을 때는 12개 중 9개를 포착했습니다. 두 방식 모두 동일한 지표를 목표로 합니다. 즉, 소형 오픈 모델(small open model)이 프로덕션 환경에 적합한, 프런티어(frontier)급에 근접한 신뢰도에 도달하는 것입니다. 메커니즘은 완전히 다릅니다. 비용 프로필(cost profile) 또한 완전히 다릅니다. 제가 알기로는 양측 모두 이 둘의 조합을 테스트해 본 적이 없습니다.

접근 방식 1. Context Kit: 입력 프레임 재구성
컨텍스트 키트는 전적으로 프롬프트(prompt) 측면에 존재합니다. 6개의 마크다운(Markdown) 파일로 구성되며, 세션 시작 시 시스템 프롬프트에 한 번 로드됩니다. 런타임 콜백(runtime callbacks), 재시도 루프(retry loop), 에이전트 하네스(agent harness)는 없습니다. 모델은 키트를 읽고, 그다음 작업을 읽고, 답변을 작성합니다.

각 파일에 들어가는 내용:

CLAUDE.md (발췌)

이 코드베이스에서 목격된 실패 패턴(Failure patterns)

• "침묵하는 자기 수정(silent self-correction)" 안티 패턴(anti-pattern): 모델이 변경 사항을 드러내지 않고 내부 상태 드리프트(state drift)를 스스로 치유함. 어조(tone)에는 허용 가능하나, 상태(state)나 자금(money)에 대해서는 허용되지 않음.
• "텍스트 전용(plain text only)" 안티 패턴: 모든 중간 표현(intermediate representation)을 문자열로 강제하여, 구조화된 워크로드(structured workloads)를 저해함.
• "면책 조항이 포함된 보편적 주장(universal claim with disclaimer)" 냄새(smell): 섹션 제목은 일반성을 약속하지만, 마지막 하위 섹션에서 이를 번복함. 이러한 사항들을 플래그(flag)할 것.

도메인 어휘 (Domain vocabulary)

• P0/P1/P2/P3 = 우리 사양(spec)의 네 가지 계층(strata), 표준 정의는 GLOSSARY.md 참조.
• "계층 (Stratum)" vs "인터셉터 (interceptor)": 계층(stratum) = 수직 모델 내의 순서가 있는 레이어. 인터셉터(Interceptor) = 횡단 관심사(cross-cutting) 래퍼. 이 둘을 혼동하지 않는 것이 중요함. # AGENTS.md (발췌).

비판 패스(critique passes)를 위한 출력 스키마 (output schema):
output_schema :
findings :
- id : F-{n}
- severity : [ info , warn , error , critical ]
- principle_violated : <CLAUDE.md에서 가져온 이름>
- evidence : <입력에서 인용된 구절>
- proposed_fix : <한 문장>
- confidence : <0.0-1.0>
- signature_insight :
- single_most_actionable_fix : <문자열>
- rationale : <한 단락>

이 키트(kit)는 세 가지 일을 동시에 수행합니다. 첫째, 모델이 찾아내야 할 실패 패턴(failure patterns)의 이름을 지정하여, 모델이 호출될 때마다 처음부터 분류 체계(taxonomy)를 새로 만들어내지 않도록 합니다. 둘째, 출력 스키마(output schema)를 고정하여 다운스트림 도구(downstream tooling)가 응답을 결정론적(deterministically)으로 파싱할 수 있게 합니다. 셋째, 이전 발견 사항(findings)에 대한 기억을 전달하여 모델이 매 반복(iteration)마다 동일한 결함을 다시 발견하지 않도록 합니다.

이 접근 방식의 비용 항목은 두 군데에 존재합니다. 첫 번째는 키트를 작성하는 것입니다. 이는 실제 작업입니다. 6개의 파일은 중간 정도의 복잡성을 가진 프로젝트 기준으로 합쳐서 약 2,500 토큰(tokens)입니다. 이를 유지 관리하는 것은 하나의 규율(discipline)입니다. 운영 환경(production)에서 새로운 실패 패턴이 나타날 때마다 CLAUDE.md에 기록됩니다. 모든 아키텍처 결정은 ADR 폴더에 기록됩니다. 키트는 살아 움직입니다.

두 번째는 추론 비용(inference cost)입니다. 프롬프트 캐싱(Prompt caching)을 사용하면 첫 번째 호출 이후 입력 측 비용은 거의 무료에 가깝습니다. Anthropic의 5분 캐시 TTL(Time To Live)과 OpenRouter의 캐싱 지원 덕분에, 캐시 히트(cache hits) 시 반복되는 입력 토큰 비용은 정가(list price)의 10%로 떨어집니다. 백만 토큰당 $0.12/$0.37인 Gemma 4 31B 호출 시, 7,500 토큰의 캐시된 시스템 프롬프트(system prompt)와 2,000 토큰의 작업(task), 그리고 4,000 토큰의 출력을 합치면 감사(audit) 한 번당 비용은 약 $0.003입니다. 제가 실행한 전체 4개 모델 감사 비용은 총 추론 비용 $0.05였습니다. 수치는 끝에 링크된 4부작 시리즈에서 가져왔습니다. 키트를 로드했을 때 아키텍처 감사(architecture audit)의 발견율(findings rate)은 12개 중 9개에서 12개 중 11개로 상승했습니다.

그것이 바로 75%에서 92%에 달하는 수치입니다. 이는 단 하나의 작업, 하나의 프롬프트 구조(prompt structure), 하나의 온도 설정(temperature setting, 0.3)을 사용한 결과입니다. 벤치마크 관점에서 보면 N=1입니다. 이를 동료 검토(peer-reviewed)를 거친 결과가 아닌, 방향성을 제시하는 신호(directional signal)로 취급하십시오. 메커니즘은 순수하게 "추론 호출 전(front of the inference call)" 단계에서 작동합니다. 추론 시점(inference time)에는 단일 모델 호출 외에는 아무것도 실행되지 않습니다. 중단할 에이전트 루프(agent loop)도 없고, 재시도 예산(retry budget)도 없으며, 하네스(harness)도 없습니다.

접근 방식 2. Forge: 런타임(runtime)에서 가로채기
Forge는 정반대의 형태를 가집니다. Forge는 사용자가 이미 소비자용 하드웨어(8~14GB VRAM 영역)에 셀프 호스팅된 모델을 보유하고 있으며, 7단계 중 3단계에서 실패하는 도구 사용 에이전트 루프(tool-using agent loop)를 가지고 있다고 가정합니다. Forge는 루프를 감싸고(wrap) 모델이 오작동할 때 개입합니다. CAIS 2026 데모 페이지에 따르면, 가드레일 스택(guardrail stack)은 다음과 같이 설명됩니다: 재시도 유도(Retry nudges), 단계 강제(step enforcement), 오류 복구(error recovery), 컨텍스트 압축(context compaction), 그리고 하드웨어 인지형 VRAM 예산 책정(hardware-aware VRAM budgeting). 각 구성 요소가 무엇을 하는지에 대한 합리적인 재구성(정확한 코드는 공개 페이지에 없으므로, 명명된 함수를 바탕으로 한 정보에 기반한 추론입니다):

Forge 스타일의 가드레일 래퍼(guardrail wrapper)에 대한 개념적 재구성.

이름은 발표된 메커니즘과 일치하며, 본문은 예시용입니다.

class GuardrailedAgent :
def init ( self , model , tools , max_steps = 10 , vram_budget_gb = 8 ):
self . model = model
self . tools = tools
self . max_steps = max_steps
self . vram_budget_gb = vram_budget_gb
self . context = []

def step ( self , task ):
    for i in range ( self . max_steps ):
        self . compact_if_over_budget ()
        response = self . model . generate ( self . context , task )
        if self . is_malformed ( response ):
            # 재시도 유도(retry nudge): 도구 스키마(tool schema)를 다시 주입
            self . context . append ( self . retry_nudge ( response ))
            continue
        if not self . respects_step_order ( response ):
            # 단계 강제(step enforcement): 순서가 잘못된 도구 호출을 거부
            self . context . append ( self . order_violation_msg ( response ))
            continue
        tool_result = self . execute ( response )
        if tool_result .

is_error(): # 에러 복구: 에러 메시지를 컨텍스트에 다시 포함하여 구조화된 재시도 수행
self.context.append(self.error_recovery_prompt(tool_result))
continue
return tool_result

return self.fallback()

핵심적인 속성은 가드레일 (guardrails)이 도구 불가지론적 (tool-agnostic)이라는 점입니다. 이들은 에이전트가 무엇을 하고 있는지 알지 못합니다. 대신, 잘못된 형식의 JSON이 어떻게 생겼는지, 순서가 잘못된 도구 호출 (tool call)이 어떤 모습인지, VRAM 예산을 초과하기 직전의 컨텍스트가 어떤 상태인지는 알고 있습니다. 이러한 개입 (interventions)은 국소적이고, 기계적이며, 비용이 저렴합니다.

보고된 결과에 따르면, Forge 환경에서의 8B 모델은 에이전트 워크플로 (agentic workflows)에서 99%의 완료율을 달성했습니다. Hacker News에서 언급된 "53%에서 99%로"라는 프레임워크가 헤드라인 수치입니다. CAIS 2026 페이지 자체에서는 가드레일이 없는 베이스라인 (baseline)을 범위(프런티어 API의 경우 49%에서 87%)로 보고하고 있으므로, 정확한 "53%"라는 수치는 제가 이 글을 쓰는 시점에 공개된 PDF를 통해 확인할 수 없었던, 논문 내 특정 8B 베이스라인 설정에서 기인했을 가능성이 높습니다. 하지만 이 주장의 질적인 형태는 충분히 뒷받침됩니다. 즉, 소형 모델에 가드레일을 더하는 것이 가드레일이 없는 프런티어 모델보다 다단계 작업 (multi-step tasks)에서 더 우수하다는 것입니다.

Forge의 비용 라인은 런타임 (runtime)에 위치합니다. 각 가드레일 개입은 추가적인 모델 호출 (재시도, 수정된 단계, 복구된 에러) 비용을 발생시킵니다. 논문의 평가 하네스 (eval harness)는 50개 이상의 모델 및 백엔드 구성에 걸쳐 9개 시나리오에서 50회의 실험을 실행했으며, 이는 매우 많은 호출을 의미합니다. 소비자용 하드웨어에서 이러한 호출은 달러 관점에서는 사실상 무료이지만, 실제 지연 시간 (latency)과 처리량 (throughput) 비용이 발생합니다. API로 호스팅되는 소형 모델의 경우, 개입당 비용이 누적됩니다. 완료를 위해 세 번의 재시도가 필요한 실행은 한 번 대신 네 번의 생성 (generations) 비용을 지불하게 됩니다.

설정 작업 또한 런타임 인프라에 해당합니다. Forge를 에이전트 하네스 (agent harness)에 통합해야 하고, 단계 강제 계층 (step-enforcement layer)이 읽을 수 있는 방식으로 도구 스키마 (tool schemas)를 정의해야 하며, 특정 GPU에 맞춰 VRAM 예산 관리자 (VRAM budgeter)를 튜닝해야 합니다. CLAUDE.md 측면의 작업은 호출이 나가기 전에 이루어집니다.

Forge 측면의 작업은 외부로 나가는 모든 호출(call)을 중심으로 이루어집니다. 두 방식의 차이점: 제가 제시할 수 있는 가장 명확한 대비 방식은 두 접근법이 동일한 스택의 서로 다른 계층(layer)에 존재한다는 것입니다.

구분	Context Kit	Forge Guardrails
개입 시점 (Intervention point)	추론 전 (Pre-inference, 입력 프레임)	추론 시 (At inference, 런타임 루프)
메커니즘 (Mechanism)	실패 패턴 명명, 스키마 고정 (schema pinning), 메모리 전달 (memory carry-forward)	재시도 유도 (Retry nudges), 단계 강제 (step enforcement), 오류 복구 (error recovery), VRAM 예산 관리 (VRAM budgeting)
작업 위치 (Where the work lives)	작성 시간 (6개의 MD 파일)	런타임 (모든 호출을 감싸는 가드레일 래퍼)
호출당 한계 비용 (Marginal cost per call)	프롬프트 캐시 (prompt cache) 사용 시 거의 제로에 가까움	개입당 한 번의 추가 호출
타겟팅하는 실패 모드 (Failure mode it targets)	모델이 도메인이나 출력 계약 (output contract)을 이해하지 못함	다단계 루프 내에서 모델이 오작동함
도구 인식 여부 (Tool-aware?)	예 (도메인 어휘가 내장됨)	아니요 (설계상 도구 불가지론적/tool-agnostic)
세션 간 지속성 (Persistence across sessions)	예 (디스크 상의 파일)	아니요 (라이브 프로세스 상태)
설정 노력 (Setup effort)	초기에 높음, 지속적인 노력은 낮음	프레임워크가 있다면 초기에 낮음, 워크로드별 지속적인 튜닝 필요
최적 적합 작업 (Best fit task)	단발성 비평 (Single-shot critique), 감사 (audit), 구조화된 출력 초안 작성	다단계 도구 사용 에이전트 루프 (Multi-step tool-using agent loops)
보고된 성능 향상 (Reported lift)	아키텍처 감사 결과 9/12에서 11/12로 향상 (단일 작업, N=1)	9가지 에이전트 시나리오에서 53%에서 99%로 향상 (논문 근거, 각 50회 실험)

이 차이점을 생각하는 가장 유용한 방법은 제가 발견한 바에 따르면 '노동 전이 (labour transfer)'입니다. Context Kit은 작업을 추론 예산 (inference budget)에서 작성 예산 (writing budget)으로 옮깁니다. 6개의 파일을 작성하는 데 한 번 비용을 지불합니다. 그 이후의 각 추론 호출에는 거의 비용이 들지 않습니다. Forge는 그 반대입니다. Forge는 소형 모델이 루프 내에서 오작동할 것임을 인정하고, 수정이 필요할 때만 추론 시점에 수정 비용을 지불합니다. 만약 당신의 워크로드가 "문서 하나를 단 한 번 매우 주의 깊게 감사해야 한다"라면, Context Kit이 적합한 형태입니다. 감사는 단일 호출이며, 가드레일을 적용할 루프가 없습니다. 만약 당신의 워크로드가 "하루에 200번, 7단계 브라우저 자동화 에이전트를 실행해야 한다"라면, Forge가 적합한 형태입니다.

모든 가능한 브라우저 자동화 실패 사례를 다루는 Context Kit의 작성 예산(writing budget)은 무한합니다. 반면, 잘못된 형식의 JSON(malformed JSON)이나 순서가 잘못된 클릭(out-of-order clicks)을 잡아내는 런타임 가드레일(runtime guardrails)은 다룰 수 있는 수준(tractable)입니다. 대부분의 실제 워크로드는 이 두 가지가 섞여 있습니다. 바로 이 점이 두 방식의 조합을 흥미롭게 만듭니다. 가설적 조합: 동일한 워크로드에 두 계층을 모두 적용하는 경우. 두 논문 모두 이 조합을 테스트하지는 않았습니다. 아래의 프레임워크는 결과가 아닌 가설입니다. 제가 이를 글로 써 내려가는 이유는 부분적으로는 이 가설을 구체화하기 위함이며, 또 다른 이유는 다음 한 달 동안 실제로 이 실험을 수행하고 싶기 때문입니다. 논지는 다음과 같습니다: 두 개입(intervention)은 서로 겹치지 않는 실패 모드(failure modes)를 공격하므로, 이득은 중복되기보다는 대략적으로 가산적(additive)이어야 합니다. # 가설: 두 계층을 쌓는다. # Context Kit은 입력을 형성(shapes)한다. Forge는 루프를 감싼다(wraps). # 해결되는 실패 모드는 대체로 서로 분리되어 있어야 한다. context_kit = load_context_k