더 똑똑한 리소스 할당이 더 강력한 모델을 이긴다

당신은 Sonnet에게 방금 자신이 작성한 코드를 검토해 달라고 요청합니다. Sonnet은 괜찮아 보인다고 답합니다. 동일한 코드를 Opus에게 검토해 달라고 요청합니다. Opus는 대여섯 개의 문제를 찾아냅니다.

Opus가 단순히 더 똑똑하다고 결론 내리고 싶은 유혹이 생깁니다. 하지만 실험을 뒤집어서 — Opus가 코드를 작성하게 하고 Sonnet에게 검토를 요청한다면 — Sonnet은 여전히 문제들을 놓칩니다. 두 모델은 거의 동일한 학습 데이터 (training data)와 아키텍처 (architecture)를 공유합니다. 실제로 무엇이 다른 걸까요?

정답은 역량 (capability)이 아닙니다. 바로 탐색 전략 (search strategy) 입니다.

탐색 깊이 (Search Depth) > 모델 역량 (Model Capability)

두 명의 방사선 전문의가 동일한 CT 스캔을 읽습니다:

• 인턴 (Intern): 훑어봅니다. "뚜렷한 이상 소견 없음."
• 전문의 (Attending): 정해진 순서를 따릅니다 — 종격동 (mediastinum) → 폐문 (hilum) → 폐 실질 (lung parenchyma) → 흉막 (pleura) → 골창 (bone windows). 왼쪽 하단 사분면에서 3mm 결절을 찾아냅니다.

전문의의 눈이 더 날카로운 것이 아닙니다. 그녀에게는 프로토콜 (protocol) 이 있습니다.

Opus도 마찬가지입니다. Opus는 Sonnet보다 더 깊게 생각하는 것이 아니라, 더 체계적으로 탐색합니다. 모든 조건부 분기 (conditional branch)를 훑습니다. 경계값 입력 (boundary inputs)을 구성합니다. 자신의 가설에 의문을 제기합니다. 차이점은 가공되지 않은 추론 (raw reasoning) 능력이 아니라, 주의력 (attention)이 어떻게 할당되느냐에 있습니다.

모델의 주의력은 유한한 리소스입니다. 주의력을 어떻게 소비하느냐가 다음 단계의 모델로 업그레이드하느냐보다 더 중요합니다.

이는 두 가지 구체적인 문제로 나뉩니다: 언제 검사할 것인가, 그리고 모델에게 무엇을 보여줄 것인가. 세 번째는 메타적인 문제입니다: 플랫폼 전환 시에도 유지될 수 있도록 이러한 규칙들을 어디에 위치시킬 것인가?

1. 언제 검사할 것인가: GC 방식에서 영감을 얻은 감사 라우팅 (Audit Routing)

작성자가 자신의 코드를 검토해서는 안 되는 이유

내가 코드를 작성할 때, 나의 주의력은 A → B → C의 경로를 따릅니다. 코드를 검토할 때도 나는 동일한 경로를 따릅니다. 내가 전혀 고려하지 않았던 분기 D를 마법처럼 발견하지 못합니다. 이것이 바로 동일 모델의 사각지대 (same-model blind spot) 입니다.

모델은 똑같은 행동을 반복합니다. 방금 자신이 작성한 경로를 그대로 따라갑니다. 자신이 무엇을 모르는지조차 알지 못합니다.

단순한 해결책은 "검토를 위해 더 강력한 모델을 사용하라"는 것입니다. 하지만 이는 추론 비용 (inference cost)을 두 배로 늘릴 뿐이며, 근본적인 문제인 '검토 전략의 부재'를 해결하지 못합니다.

GC의 통찰 (The GC insight)

JVM의 가비지 컬렉션 (Garbage Collection, GC)에는 핵심적인 설계 결정 사항이 있습니다. 모든 객체를 동일한 빈도로 스캔할 필요는 없다는 것입니다. 새로 할당된 객체 (Eden)는 휘발성이 강하므로 자주 스캔합니다. 여러 번의 GC 사이클을 견뎌낸 객체 (Old Generation)는 안정성이 증명되었으므로 드물게 스캔합니다.

코드 리뷰도 마찬가지입니다. 모든 코드 변경 사항에 대해 전체 회귀 테스트 (regression)가 필요한 것은 아닙니다.

영역 (Zone)	개발 단계 대응	리뷰 전략
Perm Gen	설정, 사양, 기술 정의	모든 변경 시 전체 리뷰
...

이를 구현하기 위해서는 두 가지가 필요합니다:

변경 추적 카드 (A change tracking card). 모든 단계는 완료 후 카드를 출력합니다:

Phase N 변경 카드
  ├─ 인터페이스 변경: userService.getProfile() — 반환 타입 변경
  ├─ 변경된 파일: src/services/profile.ts
...

이 카드는 감사 라우팅 (audit routing)을 유도합니다:

영향도 (Impact) = 0개의 새로운 인터페이스                      → 건너뜀 (Skip)
영향도 (Impact) ≤ 2개 단계 (로컬 인터페이스 변경)             → Minor GC: 셀프 리뷰 + 직접적인 의존 관계 리뷰
영향도 (Impact) ≤ 5개 단계 (공유 모듈 변경)                    → Major GC: 영향을 받는 모든 단계에 대한 전체 리뷰
...

가정 레지스트리 (An assumption registry). 모든 단계는 완료 시 세 가지 사항을 기록합니다:

1. 발생하지 않을 것이라고 가정한 것은 무엇인가?
2. 이 가정이 깨진다면, 무엇이 깨지는가?
3. 어떤 인터페이스/상태/동작을 변경했는가?

이후 단계들은 코드를 작성하기 전에 이 레지스트리를 읽습니다. 만약 새로운 작업이 이전의 가정을 깨뜨린다면, 해당 충돌은 조용히 덮어쓰여지는 것이 아니라 명시적으로 해결되어야 합니다.

2. 모델에게 무엇을 보여줄 것인가: 규칙보다 앵커 (Anchors Over Rules)

"언제 검사할 것인가"는 리소스 스케줄링 (resource scheduling)에 관한 문제입니다. 더 근본적인 질문은 다음과 같습니다: 모델의 입력값에 무엇을 넣을 것인가? 주의력 (attention)이 유한하다면, 어떤 것이 희소한 자리를 차지해야 하는가?

금지 사항이 약한 이유

전통적인 프롬프트 엔지니어링 (prompt engineering)은 금지 사항에 의존합니다: "표준 Markdown 링크를 사용하지 마세요." "예외 케이스 (edge cases)를 잊지 마세요." "중복된 코드를 생성하지 마세요."

하지만 모델은 명령 실행기 (command executor)가 아니라 패턴 매칭 (pattern-matching) 시스템입니다. "X를 사용하지 마세요"라는 문구를 읽는 것은 오히려 X 패턴을 활성화합니다. 금지 사항을 쌓아 올릴수록 각 규칙의 영향력은 희석됩니다. 열 개의 규칙이 한 개의 규칙보다 열 배 더 효과적인 것이 아니라, 오히려 더 나쁜 결과를 초래합니다.

앵커 (Anchors)

대안은 다음과 같습니다: 모델에게 규칙 대신 예시를 제공하십시오.

"표준 Markdown 링크를 사용하지 마세요"라고 말하지 마세요. 대신 올바른 Obsidian 스타일의 링크가 포함된 파일을 보여주세요.

"로직을 작성하기 전에 경계 조건 (boundary conditions)을 확인하세요"라고 말하지 마세요. 코드를 건드리기 전에 모든 상태 조합에 대한 진리표 (truth table)를 작성하도록 요청하세요.

이것이 제가 "2.5 레이어 (2.5 layer)" 접근 방식이라고 불러온 것의 핵심입니다. 사양 (spec, 무엇을 만들 것인가)과 구현 (implementation, 어떻게 만들 것인가) 사이에는, 이 특정 프로젝트에 대해 올바른 출력이 어떤 모습인지 모델에게 보여주는 **앵커 (anchors)**라는 중간 레이어가 존재합니다.

Steph Ango의 obsidian-skills 프로젝트 (별 33K 개)는 깔끔한 공개 사례입니다. 그는 "[]() 형식의 링크를 사용하지 마세요"라고 쓰지 않았습니다. 대신 올바른 구문이 적용된 .md 파일을 배포했습니다. 모델은 이를 읽고 학습합니다. 규칙보다 저렴하며, 더 효과적입니다.

구체적인 사례

실무에서 가장 효과적인 앵커 중 하나는 자동 생성된 UI 사양 파일이었습니다. 이는 디자인 단계에서 생성되어 구현 단계에서 소비되는 YAML 문서입니다. 이 문서에는 모든 페이지, 각 페이지의 컴포넌트 (components), 상태 (loading/empty/error/edge), 그리고 반응형 중단점 (responsive breakpoints)이 나열되어 있습니다. 모델은 UI 코드를 생성하기 전에 이 문서를 읽습니다.

이 앵커가 있기 전에는 모델이 픽셀 값을 추측하고, 컴포넌트 이름을 임의로 지어내며, 에러 상태를 건너뛰곤 했습니다. 모델이 "나빠서"가 아니라, 프로젝트 특화된 참조 자료 (project-specific reference)가 없었기 때문입니다. 앵커는 단 하나의 규칙도 추가하지 않았습니다. 단지 모델이 보는 데이터의 분포를 바꾸었을 뿐이며, 그것이 모델이 생성하는 결과물을 바꾸었습니다.

3. 이러한 규칙들이 존재하는 곳

앞선 두 섹션은 전략 (strategy)을 정의합니다. 하지만 전략이 단일 플랫폼의 형식에 종속된다면 그 전략은 생명력을 잃습니다.

함정은 감사 라우팅 (audit routing)이나 사양 체크리스트 (specification checklists)를 workflow.md 파일 내부에 작성하는 것입니다. 왜냐하면 workflow.md는 일반적으로 플랫폼 플러그인으로서 필요할 때만 읽히기 때문입니다. Claude Code에서 OpenCode, Cursor 또는 Gemini CLI로 전환하면 이 체계는 무너집니다.

해결책은 다음과 같습니다: 플랫폼에 구애받지 않는 참조 파일 (platform-agnostic reference files)에 결정 테이블 (decision tables)을 작성하십시오. 워크플로 (workflow)는 이를 참조할 뿐, 직접 구현하지는 않습니다.

플랫폼 특정적 워크플로 (Platform-specific workflow):
  "단계 완료 → gc-audit-routing.md 읽기 → 결정 테이블에 따라 감사 실행"

...

각 플랫폼 어댑터 (adapter)가 실행 방식을 결정합니다. 결정 로직 (decision logic) 자체는 한 곳에 존재합니다.

이는 하나의 원칙으로 일반화됩니다: 어떻게 결정할지에 대한 결정은 워크플로 스크립트 (workflow scripts)에 속하지 않습니다. 워크플로 스크립트는 단계의 순서 (sequencing of steps)를 처리합니다. 결정 기준 (decision criteria)은 참조 문서 (reference documents)에 들어가야 합니다.

종합하기

문제	리소스	일반적인 접근 방식	더 나은 접근 방식
언제 검사할 것인가	어텐션 (Attention)	균등한 커버리지 또는 더 강력한 모델	GC 구역화 (GC zoning): 영향 범위에 따라 어텐션 할당
무엇을 보여줄 것인가	입력 샘플 (Input samples)	금지 사항 쌓기 (Prohibition stacking)	앵커 (Anchors): 입력 분포를 통해 출력 형성

두 문제 모두 동일한 전제를 공유합니다: 모델의 연산량 (compute)은 유한합니다. 엔지니어링 레버 (engineering lever)는 원시 역량 (raw capability)이 아니라 할당 전략 (allocation strategy)입니다.

이것은 철학적인 주장이 아니라 엔지니어링 제약 (engineering constraint)입니다. 코드 리뷰는 수천 개의 추론 (inference) 토큰을 소모합니다. 이 예산을 모든 파일에 균등하게 분산하는 것은 Eden-zone 및 세대 간 변경 사항 (cross-generation changes)에 집중하는 것보다 효과가 떨어집니다. 원시 요구사항 텍스트를 컨텍스트 (context)에 밀어 넣는 것은 어텐션 관련 위치 (attention-relevant positions)에 구조적 앵커 (structural anchors)를 배치하는 것보다 효과가 떨어집니다.

그에 따른 결과는 자연스럽게 뒤따릅니다:

• 더 많은 버그를 잡기 위해 더 강력한 모델을 구매하지 마세요 — 버그가 실제로 숨어 있는 곳에 기존의 어텐션 (Attention)을 사용하세요
• 더 많은 프롬프트 규칙 (Prompt rules)을 작성하지 마세요 — 모델에게 더 나은 예시 (Examples)를 제공하세요
• 플랫폼마다 리뷰 로직 (Review logic)을 새로 구현하지 마세요 — 결정 테이블 (Decision table)을 중앙에 배치하고, 플랫폼이 이를 실행하게 하세요

모델은 매년 변합니다. 하지만 어텐션 할당 (Attention allocation)과 샘플 분포 (Sample distribution)의 원칙은 변하지 않습니다.

*이 기사는 오픈 소스 프레임워크 프로젝트의 작업 내용을 바탕으로 작성되었습니다. GC-audit 라우팅 (Routing) 및 플랫폼 독립적 결정 패턴 (Platform-independent decision patterns)은 해당 리포지토리 (Repository)에 기능 제안 (Feature proposals)으로 등록되어 있습니다.