저는 번역 평가를 통해 Claude Code 기술에 관심을 갖게 되었는데, 이는 모호한 지침에 대해 의구심을 갖게 만드는 매우 좋은 방법입니다.

모델의 출력을 충분히 오랫동안 비교하다 보면, 단순히 "유창하게 들리는가?"라고만 묻지 않게 됩니다. 더 세부적인 질문들을 던지기 시작하죠. 어떤 컨텍스트 (Context)가 실제로 사용되었는가? 어떤 지침이 결과를 변화시켰는가? 모델이 개선된 것인가, 아니면 단지 더 자신감 있게 말하게 된 것인가?

그것이 제가 현재 AI 코딩 어시스턴트 (AI coding assistants)를 바라보는 방식이기도 합니다.

Claude Code 기술, Codex 설정, 멀티 에이전트 워크플로우 (multi-agent workflows), 그리고 로컬 모델 설정에 대한 현재의 열기는 실재합니다. GitHub Trending은 스킬 팩 (skill packs), 에이전트 래퍼 (agent wrappers), 리뷰 브릿지 (review bridges), 그리고 "내 코딩 에이전트를 더 좋게 만들기" 프로젝트들로 가득 차 있습니다. 하지만 저는 유용한 질문은 "2026년에 가장 좋은 Claude Code 기술은 무엇인가?"가 아니라고 생각합니다.

유용한 질문은 다음과 같습니다:

무엇이 기술 (Skill)에 속해야 하고, 무엇이 에이전트 주변의 하네스 (harness)에 속해야 하며, 무엇이 인간의 결정으로 남아야 하는가?

기술은 단순한 프롬프트가 아니라 워크플로우 패키지입니다

Anthropic의 Claude Code 문서는 기술 (Skills)을 재사용 가능한 지침 패키지로 설명합니다. 기술은 SKILL.md 파일을 중심으로 구축되며, Claude Code는 관련이 있거나 직접 호출될 때 이를 로드할 수 있습니다.

제가 가장 중요하게 생각하는 부분은 컨텍스트 로딩 (context loading)입니다.

Claude Code 기술 문서에 따르면, CLAUDE.md와 달리 기술의 본문은 기술이 사용될 때만 로드됩니다. 이는 긴 절차적 지침들이 모든 세션에 영구적인 비용 (tax)으로 작용하지 않게 된다는 점에서 중요합니다.

작은 프로젝트 기술은 다음과 같을 수 있습니다:

.claude/
  skills/
    summarize-changes/
...

이것은 단지 예시 레이아웃일 뿐입니다. 공식 문서(official docs)에서는 SKILL.md를 필수 사항으로 설명하며, 참조(references), 예시(examples), 템플릿(templates), 스크립트(scripts)와 같은 지원 파일들은 선택 사항으로 규정하고 있습니다.

보수적인 SKILL.md의 예시는 다음과 같을 수 있습니다:

---
description: "커밋되지 않은 변경 사항을 요약하고 위험 요소를 표시합니다. 커밋 전 로컬 디프(diff)를 검토할 때 사용하세요."
allowed-tools: Read Grep
...

저는 첫 번째 버전은 지루하게 유지할 것입니다. 하나의 일을 확실하게 수행하는 기술(skill)이, 작은 운영체제(operating system)가 되려고 시도하는 기술보다 더 가치 있습니다.

'원시인(Caveman)' 아이디어가 맞은 점과 틀린 점

caveman이 주목을 받은 한 가지 이유는 명백합니다. 해당 리포지토리(repo)의 GitHub Trending 설명에 따르면, Claude Code가 "원시인처럼 말하게" 함으로써 토큰 사용량을 줄여준다고 주장합니다. 이는 재미있는 갈고리(hook)입니다. 하지만 그 자체로 검증된 벤치마크(benchmark)는 아닙니다.

따라서 저는 이 아이디어를 테스트해야 할 가설로 취급할 것입니다.

유용한 부분은 "모든 곳에서 문법을 제거하는 것"이 아닙니다. 유용한 부분은 지침 압축(instruction compression)입니다. 많은 에이전트 프롬프트(agent prompts)에는 행동을 변화시키지 않는 공손함, 반복적인 프레이밍(framing), 그리고 설명적인 패딩(padding)이 포함되어 있습니다.

좁은 워크플로(workflow)를 위해서는 다음과 같은 종류의 지침만으로도 충분할 수 있습니다:

목표: 실패하는 테스트의 유력한 원인을 찾으세요.
수행 사항:
- 에러를 읽으세요
...

이것은 우아한 산문이 아닙니다. 그럴 필요도 없습니다.

하지만 저는 모든 것에 압축된 "원시인" 방식의 프롬프팅(prompting)을 사용하지는 않을 것입니다. 번역 평가자(translation evaluator)는 이를 빠르게 학습합니다. 즉, 짧은 텍스트가 자동으로 더 명확한 텍스트가 되는 것은 아니라는 점입니다. 만약 압축 과정에서 제약 조건(constraints), 예시(examples), 또는 예외 케이스(edge cases)가 제거된다면, 모델은 누락된 문맥(context)을 복구하는 데 더 많은 토큰을 소비할 수도 있습니다.

실질적인 규칙은 간단합니다: 요구 사항(requirements)이 아니라 문구(wording)를 압축하세요.

기술(Skills)에는 이를 둘러싼 하네스(Harness)가 필요합니다

기술은 반복 가능한 행동을 돕습니다. 하지만 기술 그 자체만으로는 범위 제어(scope control) 문제를 해결하지 못합니다.

코딩 에이전트(coding agents)에게는 모델을 둘러싼 하네스(harness)가 프롬프트만큼이나 중요합니다. 여기서 하네스란 다음과 같은 결정을 내리는 구성 계층(configuration layer)을 의미합니다:

• 어떤 지침(instructions)을 로드할 것인가
• 어떤 도구(tools)가 허용되는가
• 어떤 에이전트(agent)가 작업의 어느 부분을 처리할 것인가
• 어떤 체크(checks)를 작업 전후에 실행할 것인가
• 어떤 출력물(outputs)이 검토(review)를 필요로 하는가

이 지점에서 Claude Code의 서브에이전트(subagents)와 훅(hooks)이 관련성을 갖게 됩니다.

Claude Code 서브에이전트 문서는 탐색(exploration), 계획(planning), 구현(implementation)을 분리하기 위한 내장 및 사용자 정의 서브에이전트(subagents)를 설명합니다. 이는 리서치 과정이 메인 스레드(main thread)를 오염시킬 수 있기 때문에 유용합니다. 만약 에이전트가 코드베이스를 스캔하는 데 20분을 소비한다면, 저는 그 모든 탐색 과정이 최종 수정 사항과 동일한 컨텍스트(context)에 머무르는 것을 항상 원하는 것은 아닙니다.

훅(Hooks)은 하네스(harness)의 또 다른 측면입니다. Claude Code 훅 문서는 훅을 PreToolUse와 같은 이벤트 기반 구성(event-based configuration)으로 보여주며, 여기서 훅은 도구 호출(tool call)이 진행되기 전에 이를 검사할 수 있습니다. 저는 파괴적인 셸(shell) 패턴을 차단하거나, 간단한 검증 명령을 요구하거나, 로컬 프로젝트 컨벤션(conventions)을 강제하는 것과 같은 단순한 훅부터 시작할 것입니다.

훅(Hooks)은 단순한 장식이 아닙니다. 그것은 결과(consequences)를 수반하는 자동화입니다.

이것이 제가 실제로 시도해보고 싶은 설정입니다.

만약 제가 새로운 AI 코딩 워크플로우(workflow)를 구성한다면, 즉시 거대한 스킬 번들(skill bundle)을 설치하지는 않을 것입니다.

대신, 네 가지 계층으로 시작할 것입니다.

첫째, 저장소 지향(repo-orientation) 스킬입니다.

이는 코드가 어디에 있는지, 어떻게 테스트되는지, 어떤 명령어가 중요한지, 그리고 어떤 영역이 민감한지에 대한 답을 제공해야 합니다. 이는 반복적이고 로컬(local)한 성격을 띠므로 스킬(skill)에 속해야 합니다.

둘째, 검증(verification) 스킬입니다.

프론트엔드 앱의 경우, 이는 린트(lint), 타입 체크(typecheck), 그리고 하나의 스모크 테스트(smoke test)를 의미할 수 있습니다. 저의 개인적인 언어 도구(language-tooling) 실험의 경우, 스크립트 변경 사항을 신뢰하기 전에 아주 작은 픽스처 세트(fixture set)를 실행하는 것을 의미할 수 있습니다.

셋째, 읽기 전용 탐색 서브 에이전트(read-only exploration subagent)입니다.

파일 발견(file discovery) 및 리스크 매핑(risk mapping)을 위해 이를 사용하십시오. 핵심은 에이전트를 더 극적으로 만드는 것이 아닙니다. 핵심은 탐색(exploration)을 편집(editing)과 분리하여 유지하는 것입니다.

넷째, 위험한 변경 사항을 위한 검토 게이트(review gate)입니다.

모든 변경 사항에 다른 에이전트가 필요한 것은 아닙니다. 하지만 인증(auth), 데이터 손실(data loss), 마이그레이션(migrations), 동시성(concurrency), 그리고 생성된 코드 재작성(generated-code rewrites)은 두 번째 검토(second pass)를 거칠 가치가 있습니다.

Codex의 역할

Codex는 특히 검토(review)와 위임(delegation)을 위한 두 번째 경로(second lane)로서 유용할 수 있습니다.

공식 openai/codex-plugin-cc 저장소에 따르면, Claude Code 사용자가 검토 또는 위임된 작업을 위해 Claude Code 내부에서 Codex를 호출할 수 있도록 해줍니다. 해당 README에는 /codex:review, /codex:adversarial-review, /codex:rescue, /codex:status, /codex:result와 같은 명령어가 나열되어 있습니다.

이를 통해 패턴이 구체화됩니다: Claude는 주요 구현 흐름(main implementation flow)에 머물러 있는 동안, Codex는 제한된 검토(bounded review) 또는 백그라운드 조사(background investigation)를 수행합니다.

설정의 경우, 저는 특정 모델 선택이 보편적인 것처럼 가장하기보다는 문서화된 Codex 설정 키(config keys)에 연결된 아티클 수준의 예시를 유지하겠습니다. OpenAI의 Codex 설정 레퍼런스는 config.toml 내의 model 및 model_reasoning_effort를 문서화하고 있습니다.

프로젝트 수준의 예시는 다음과 같습니다:

# .codex/config.toml
model = "gpt-5.5"
model_reasoning_effort = "high"

정확한 모델은 귀하의 계정, 조직 및 현재 Codex 릴리스가 지원하는 것과 일치해야 합니다. 중요한 점은 샘플 모델 문자열이 아닙니다. 모델(model)과 추론 노력(reasoning-effort)의 기본값은 프롬프트에 흩어져 있는 것이 아니라 설정(configuration)에 포함되어야 한다는 점입니다.

또한 리뷰 게이트(review gates)가 무한 루프에 빠지는 것도 피하고 싶습니다. Codex 플러그인의 README에서는 리뷰 게이트가 길게 지속되는 Claude/Codex 루프를 생성하여 사용량 제한(usage limits)을 빠르게 소진할 수 있다고 경고합니다. 이 경고는 진지하게 받아들일 가치가 있습니다.

로컬 모델(Local Models)은 어떤가요?

로컬 모델은 비용 제어 측면에서 매력적이지만, 저는 우선 저위험 작업(low-risk work)부터 맡길 것입니다.

OpenAI의 Codex 설정 참조(config reference)에는 --oss 옵션으로 실행할 때 로컬 제공자(local-provider) 선택을 위한 지원 값으로 lmstudio와 ollama를 포함하는 oss_provider가 포함되어 있습니다. 이는 로컬 모델 워크플로우가 단순한 환상이 아니라 실제적인 설정 경로임을 말해줍니다.

그럼에도 불구하고, 첫날부터 작은 로컬 모델에게 프로덕션 편집(production edits)을 맡기지는 않을 것입니다.

저는 다음과 같은 작업부터 시작할 것입니다:

• 로그 요약 (summarizing logs)
• 유사한 오류 그룹화 (grouping similar errors)
• grep 쿼리 초안 작성 (drafting grep queries)
• 긴 명령 출력 압축 (compressing long command output)
• 관련성 가능성에 따른 파일 순위 지정 (ranking files by likely relevance)

그다음 더 강력한 코딩 모델이 실제 패치(patch)를 처리하거나, 저장소(repository)에 무엇인가가 기록되기 전에 사람이 검토할 수 있습니다.

로컬 배포가 "판단력을 제거한다"는 의미여서는 안 됩니다. 그것은 "저렴하고 위험이 낮은 언어 작업을 비싼 차선(expensive lane)에서 분리한다"는 의미여야 합니다.

나의 현재 규칙

저는 어떤 기술이 영리하다고 해서 그것을 신뢰하지 않습니다. 저는 그 기술이 워크플로우를 검사(inspect)하기 더 쉽게 만들 때 신뢰합니다.

좋은 Claude Code 스킬(Skill)은 반복되는 하나의 절차를 더 작고, 명확하며, 트리거하기 쉽게 만들어야 합니다.

좋은 Codex 설정은 리뷰와 위임(delegation)을 더 명시적으로 만들어야 합니다.

좋은 하네스(harness)는 에이전트가 작업 범위를 벗어날 가능성을 낮춰야 합니다.

그것이 바로 제가 유망하다고 생각하는 이 생태계의 부분입니다. AI 코딩 어시스턴트(AI coding assistants)가 마법처럼 모든 것을 작성할 것이라는 아이디어가 아닙니다. 그보다는 엔지니어링의 지루한 부분들을 위험한 부분들을 보이지 않게 만들지 않으면서도 프로그래밍 가능하게(programmable) 만들 수 있다는 가능성입니다.