이전 기사: https://zenn.dev/satoh_y_0323/articles/baaa25ddb7e41e

C3 GitHub: https://github.com/satoh-y-0323/claude-code-conductor / PyPI: https://pypi.org/project/claude-code-conductor/ / 공식 문서: https://satoh-y-0323.github.io/claude-code-conductor/

본 기사의 범위: v2.29.2 (이전 기사에서 「미출시」라고 적었던 내부 리팩토링 그룹의 정식 출시)와 v2.29.3 (ARCHITECTURE.md에 sdist 동봉 + deletions.txt 소급 적용 23건). 단, 본론은 두 가지 「뺄셈」에 관한 이야기입니다 ── (1) pip로 배포한 파일을 어떻게 "삭제"할 것인가, (2) Claude Code 본체의 업데이트에 C3를 어떻게 "따라가지 않을(追従しない)" 것인가. 공통점은 「추가는 순식간이지만, 어려운 것은 뺄셈과 기다림의 판단」이라는 점입니다.

서론

C3 (Claude Code Conductor)는 상위 Claude가 여러 전문 에이전트 (interviewer / architect / planner / developer / tester / code-reviewer / security-reviewer)를 지휘하는 멀티 에이전트 프레임워크입니다. pip install로 설치하고 c3 init을 실행하면, 사용처의 .claude/ 디렉토리에 에이전트 정의, skill, hook이 전개됩니다.

이전 기사는 "코드 부채를 고치기 전에 조사하면 매번 스코프가 줄어든다. 하지 않기로 하는 판단이야말로 가치가 있다"라는 이야기였습니다. 사실 그때 「미출시」라고 적었던 내부 리팩토링 그룹 (DRY 통합, db.py의 모듈 분할, bare except의 분류 통일, ARCHITECTURE.md 신설)은 그 후 v2.29.2로서 무사히 출시되었습니다 (전체 테스트 Pass 1339, Regression 0, 3.10/3.11/3.12 CI Green). 내용은 이전 기사와 동일하므로, 여기서는 「제대로 나왔습니다」라고만 말씀드리겠습니다.

이번에는 취지가 조금 다릅니다. 출시(released)된 것은 적지만, 그중에는 **「배포하는 것은 간단하지만, 삭제하는 것은 어렵다」**라는 배포 도구 특유의 뿌리 깊은 이야기가 한 건 있었습니다. 그리고 또 한 건, **「토대(Claude Code 본체)가 매일 업데이트되는 가운데, 무엇을 따라가고 무엇을 관망할 것인가」**라는, 프레임워크를 얹고 있는 입장에서의 판단 이야기를 덧붙입니다.

결론부터 말씀드립니다.

추가(더하는 코드)는 순식간에 쓸 수 있다. 어려운 것은 「삭제」와 「기다림」의 판단이다. 배포한 파일을 삭제하는 기제를 넣어도 역사적인 누락은 남으며, 토대의 업데이트에 반사적으로 따라가면 불필요하게 보증 범위가 넓어진다. 뺄셈과 관망의 규율이 장기적인 프레임워크 품질을 결정한다.

제1부: pip는 「더하기」는 잘한다. 하지만 「빼기」는 누가 할까?

배포 도구의 구조적인 허점

pip install -U your-tool은 새로운 파일을 추가하고, 기존 파일을 갱신합니다. 하지만 「이전 버전이 배포했던 파일을, 이제 필요 없으니 삭제한다」는 행위는 하지 않습니다. pip의 책무는 「패키지 본체 (site-packages)의 교체」이지, 당신의 도구가 사용자의 프로젝트에 써넣은 결과물의 뒤처리를 맡지는 않기 때문입니다.

C3는 바로 이 허점 위에 서 있습니다. c3 init / c3 update는 사용처의 .claude/에 skill, hook, 에이전트 정의를 전개합니다. 즉, C3가 다음 버전에서 특정 파일을 「그만두었을」 때 ── 구 버전 skill의 SKILL.md, 폐지한 hook, 이름 변경 전의 파일 ── 그것들은 모든 사용처의 .claude/에 계속 남게 됩니다.

c3 update를 해도 아무도 지워주지 않습니다. 이는 은근히 영향을 미칩니다.

• .claude/rules/*.md는 Claude Code 사양에 따라 항시 로드됩니다 (CLAUDE.md...

와 동격). 사용하지 않는 체크리스트가 남아 있으면 매 세션마다 불필요하게 context (컨텍스트)를 소모합니다. - 폐지한 skill (스킬)이 Claude Code의 Built-in (내장 기능)과 향후 이름이 충돌할 수 있습니다.

• "이게 무슨 파일이지?"라는 조사 비용이 이용처의 개수만큼 발생합니다.

과거 기사에서도 실제로 겪었던 문제입니다. 예를 들어 /code-review skill (스킬)을 Built-in (내장 기능)과 충돌하지 않도록 /review-phase로 이름을 변경했을 때, 기존 skills/code-review/SKILL.md가 이용처에 계속 남아 있는 문제가 발생하고 있습니다.

deletions.txt (삭제 매니페스트)

C3의 해답: c3 update가 삭제를 감지하지 못한다면, "이것을 지워줘"라고 명시적으로 전달하는 삭제 지시서를 가지면 됩니다. 그것이 바로 deletions.txt입니다. 한 줄에 하나의 경로(path)를 적으며, .claude/ 상대 경로 표기법으로 "더 이상 배포하지 않을 파일"을 나열합니다. c3 update 시 이 리스트를 읽어, 이용처에 해당 파일이 있으면 삭제합니다.

단, "타인의 디렉토리에서 파일을 삭제하는 것"은 위험한 작업이므로, 13단계의 세이프가드 (safeguard)를 적용했습니다:

• 파일이 없으면 no-op (존재하지 않는 파일은 건드리지 않음)
• 절대 경로 / 또는 ../를 포함하는 경로 / 심볼릭 링크 (symbolic link)는 무시 (traversal 방어)
• 디렉토리는 삭제하지 않음 (파일만 삭제)
• deletions.txt 자신이나 .claude/ 접두사 검증 (자기 삭제 보호)

...여기까지는 지난번까지 정비해 두었습니다. 문제는 "이 기구가 나중에 도입되었다"는 점이었습니다.

deletions.txt 기구 도입 전의 삭제는 아무도 기록하지 않았습니다.

deletions.txt가 도입된 것은 v2.18.0입니다. 하지만 C3는 v0.2.0 시절부터 명령어를 skill (스킬)로 옮기거나, hook (훅)을 통합 및 폐지하거나, PO (Parallel Orchestra)라는 거대한 서브시스템을 통째로 폐지하는 등 ── 대량의 파일을 삭제해 왔습니다. 이것들은 기구가 없던 시대의 삭제이므로, deletions.txt에 단 한 줄도 올라와 있지 않습니다.

즉: v0.2.0 ~ v1.x 계열을 계속 사용 중인 이용처에는, 이미 오래전에 폐지한 파일이 지금도 남아 있다는 뜻입니다. 그리고 deletions.txt 체커 (CI에서 "추가 누락"을 기계적으로 감지하는 메커니즘) 또한 "최근 태그 이후"만 확인하기 때문에, 이러한 역사적인 누락은 감지할 수 없습니다.

v2.29.1에서 우선 이용자의 지적을 통해 3개의 파일을 소급 적용하여 추가했습니다 (v2.15.0에서 rules/ → references/로 옮긴 체크리스트. 기구 도입인 v2.18.0보다 이동이 앞서 있었던 누락). 이를 수정하고 나니 당연히 다음과 같은 결론에 도달했습니다 ── "3건으로 끝날 리가 없다. 전부 찾아내자."

v2.29.3: 전체 이력을 전수 감사한다 ── 2단계 필터의 깔때기

이 부분이 본 기사의 핵심입니다. "기구 도입 전에 삭제한 파일"을 전부 찾아내려면 어떻게 해야 할까요? 단순하게 접근하면 과잉 탐지 (over-recall)의 늪에 빠지게 됩니다. C3에서는 2단계 필터로 범위를 좁혔습니다.

git 전체 이력의 삭제/이름 변경 59건
│ 제1 필터: 애초에 배포 대상인가? (_excludes.should_skip)
▼
...

제1 필터: 애초에 배포 대상인가.

git log --diff-filter=DR (삭제 D, 이름 변경 R)로 나타나는 후보 59건 중 상당수는 reports/*와 같은 실행 시 생성되는 결과물이거나 개발자 전용 파일로, 애초에 이용처에는 전달되지 않습니다. 배포 대상인지 여부를 판정하기 위해, 실제 배포 로직과 동일한 src/c3/_excludes.py의 should_skip을 재사용했습니다 (판정 로직을 이중으로 작성하면 반드시 차이가 발생하므로 SSOT 원칙 준수). 이를 통해 34건으로 줄였습니다.

제2 필터 (핵심): 실제로 출하되었는가.

이 부분이 효과적이었습니다. "git 이력에 삭제된 흔적이 있다"가 곧 "사용자에게 전달되었다"는 뜻은 아닙니다. 이용처의 .claude/에 남아 있는 것은, 과거 어느 시점의 공개 wheel (wheel)에 실제로 포함되어 있었던 파일뿐입니다. git 이력만 보면, 출하된 적이 한 번도 없는 파일까지 "삭제 후보"로 잡아내게 됩니다.

그래서 PyPI에 공개한 모든 태그(v0.2.0~v2.17.0의 68개 태그)에 대해, 각 후보 파일이 실제로 존재했는지 전수 조사를 실시했습니다:

# 후보 경로(path)가 과거의 어떤 공개 태그에 실재했는지 확인
published=0
for tag in $(git tag -l 'v*'); do
...

그 결과 「공개됨(published) = 23건 (진정한 누락)」과 「게시된 적 없음(never-published) = 11건 (제외)」으로 나뉘었습니다.

제외된 11건 ── 「never-published」의 정체가 흥미롭다

git 이력상으로는 삭제되었지만, 어떤 공개 태그에도 존재하지 않는 11건. 그 정체는 다음과 같습니다:

• 하나의 커밋 내에서 이름이 변경된 파일의 "구 명칭" ── 구 명칭은 어떤 태그에도 스냅샷되지 않음
• 릴리스 전의 시도 ── 태그를 생성하기 전에 만들었다가 삭제한 파일
• 단기적인 revert ── 넣자마자 바로 되돌려, 태그를 단 하나도 거치지 않음

이것들은 "git 상으로는 삭제되었지만" "어떤 공개 wheel에도 포함되지 않았다" ＝ 어떤 사용자에게도 전달되지 않았다는 뜻입니다. deletions.txt에 적어도 해가 되지는 않지만(부재 중이라면 no-op이므로), 노이즈이며 "역사의 기록"으로서 단순한 오류입니다. 배포해야 할 것은 정확한 삭제 지시이지, git의 내부 사정이 아닙니다.

AI에게 찾게 했더니 32%가 over-recall이었다

후보를 수집하는 데는 Claude Code에 내장된 조사 에이전트(Explore)를 사용했습니다. 하지만 Explore가 제시한 34건 중 11건(32%)이 never-published였습니다. Explore는 망라성(recall)을 우선하여 "사라진 흔적"을 닥치는 대로 긁어모으기 때문에 당연한 결과입니다.

정밀도(precision)를 담보한 것은 앞서 언급한 **제2 필터(공개 태그 실재 확인)**였습니다. 이는 지난 글의 기저에 흐르던 주제인 "AI의 지적은 결론에 넣기 전에 1차 검증을 거쳐야 한다"의 배포 감사 버전입니다. AI에게 망라하게 하고, 기계적인 실재 확인으로 걸러낸다 ── 역할 분담으로서 궁합이 좋습니다. 이 절차는 재사용 가능한 원칙이므로, historical_deletion_audit_publication_filter (1차 필터 should_skip + 2차 필터 공개 태그 실재 확인)로 패턴화했습니다.

결과적으로 23건을 추가했습니다. v0.2.0~v1.14.0을 계속 사용해 온 사용자들의 경우, 다음 c3 update 시에 구 commands/.md 9건 / 구 skills/.md 4건 / parallel-execution.md / 초기 hooks 4건 (session_start.py 통합 전) / PO 관련 5건이 제거됩니다. 검증 결과는 _load_deletions 43 entries / check_deletions --check exit 0 / wheel에 deletions.txt 43행 동봉 / pytest 1339 passed · 0 regression 이었습니다.

덤: v2.29.2에서 C3 전체의 지도인 ARCHITECTURE.md를 sdist "만"에 넣었습니다

v2.29.2에서 C3 전체의 지도인 ARCHITECTURE.md(이층 구조 · 오케스트레이션 · hook 라이프사이클 · 빌드/배포)를 신설했고, v2.29.3에서 sdist에만 동봉했습니다. wheel에는 넣지 않습니다. 이유는 "wheel 사용자는 GitHub에서 읽으면 된다. pip download나 pip install --no-binary :all:을 통해 sdist를 받는 사람만이 수중에 갖고 싶어 한다"는 것입니다.

이때 "덤으로 mkdocs(공개 문서 사이트)의 nav에도 추가할까?"라는 논의가 있었지만, 추가하지 않았습니다. ARCHITECTURE.md는 C3 개발자용(GitHub에서 읽는 계층)이고, mkdocs의 docs/는 C3 사용자용(pip install하여 사용하는 계층)으로, 독자층이 다릅니다. 같은 지도를 양쪽에 두면 SSOT(단일 진실 공급원)도 깨집니다. 제1부의 마지막 역시, 역시 "추가하지 않기로 한 판단"이었습니다.

제2부: Claude Code 본체의 업데이트에 C3를 어떻게 추종시킬 것인가 (거의 "관망"하게 된 이야기)

C3는 Claude Code의 위에 올라타는 (on top of) 프레임워크이므로, 본체의 업데이트는 항상 영향을 미칩니다. 저는 매일 아침 루틴으로 Claude Code의 changelog 일일 차분(daily diff)을 받아보고, "이것이 C3에 영향을 주는가"를 한 건씩 Claude와 대화하며 평가하고 있습니다. 이번(v2.1.152~v2.1.154) 평가 결과, 결과적으로 거의 전부 "관망 (Wait and see) (기록만 해두고, 트리거가 오면 움직인다)"로 결론이 났습니다. 그 과정이 흥미로웠기에 공유합니다.

참고: 본 섹션의 changelog 기술은 공식 changelog (code.claude.com/docs/en/changelog)를 직접 WebFetch 하여 1차적인 사실 확인을 거쳤습니다. 일일 리포트를 통한 전언으로 기사를 쓰면 사고가 날 수 있기 때문입니다.

subagent_type을 생략하면 결과물이 "조용히 사라지는" 결함 (defect) (v2.1.153에서 수정)

케이스 1: 공식 changelog v2.1.153에 다음과 같이 적혀 있습니다:

Fixed Agent tool with subagent_type: 'claude' running in an undocumented temporary worktree, which could silently discard outputs written to gitignored paths

번역하자면: Agent 툴을 subagent_type: 'claude'(또는 생략)로 호출하면, 문서화되지 않은 임시 worktree에서 동작하며, gitignore 대상 경로에 작성된 출력이 소리 없이 버려질 수 있었던 결함(defect)에 대한 수정입니다.

이는 C3에게 있어 가슴 철렁한 이야기였습니다. C3의 리포트 (.claude/reports/), 상태 (.claude/state/), 에이전트 기억 (.claude/agent-memory/)은 전부 gitignore 대상입니다. 만약 어딘가에서 subagent_type을 생략하고 Agent를 호출했다면, 서브 에이전트가 작성한 리포트가 말없이 사라지게 됩니다.

그래서 영향을 평가했습니다. 확인은 grep 한 번으로 끝냈습니다:

subagent_type.{0,20}["']claude["'] → 0건

C3에서는 구조적으로 해당 사항이 없었습니다. parallel-agents skill은 wt_* 변형(variant)을 명시하고, 일반적인 에이전트는 architect / planner / developer / tester / code-reviewer / security-reviewer를 고유 명칭으로 명시하며, 대화형은 상위 Claude가 페르소나를 채택하여 Agent 툴을 경유하지 않습니다 ── 즉, 어디에도 "subagent_type 생략 호출"이 없습니다.

다만 향후 누군가가 skill 문구에 "subagent_type을 생략하여 Agent를 호출한다"라고 적는다면 재발할 가능성이 있습니다. 따라서 **예방 규칙 "C3에서는 subagent_type을 항상 고유 명칭으로 명시하며, 'claude' 지정 및 생략 호출을 금기(taboo)로 한다"**를 확정하고 기록했습니다. 코드 변경은 하지 않습니다 (실질적인 피해가 0이기 때문입니다).

관망 상태입니다.

disallowed-tools 추가 (v2.1.152) ── 지난번 "allowed-tools 문제"의 대칭 해법이 등장했다

케이스 2: 공식 changelog v2.1.152:

Skills and slash commands can now set disallowed-tools in frontmatter to remove tools from the model while the skill is active

이는 지난 기사의 복선을 회수하는 이야기입니다. 지난번 /brainstorm 리뷰에서 code-reviewer가 "대화 skill에도 allowed-tools를 붙여야 한다 (High)"라고 지적했고, 저는 그것을 기각했습니다. 이유는, allowed-tools로 Read/Write/Skill에 한정하면, 승인 게이트(approval gate)에 사용하는 AskUserQuestion이 허용 목록(allowlist)에서 제외되어 망가지기 때문입니다. "상위 Claude가 페르소나를 채택하는 대화 skill에는 allowed-tools...

「붙이지 않는다」가 정답이라는 판단이었습니다. 그런데 v2.1.152의 disallowed-tools는 바로 그 **대칭해 (Symmetric solution)**입니다. 「허가 리스트 (Allowlist)」가 아니라 「금지 리스트 (Blocklist)」를 작성할 수 있으므로, AskUserQuestion 등의 대화 도구는 유지하면서 제외하고 싶은 특정 도구만 금지할 수 있습니다. 즉, 지난번의 거절은 「allowed-tools라는 형태로는 불가능하다」는 것이었을 뿐, disallowed-tools라면 「특정 도구를 제외한다」는 의도를 해치지 않고 실현할 가능성이 있습니다.

그렇다면 도입할 것인가? ── 지금은 관망하기로 했습니다. 이유는 간단합니다. 현재 C3의 대화 skill은 「아무것도 제한하지 않아도」 문제없이 작동하고 있으며, 제외하고 싶은 특정 도구도 없기 때문입니다. disallowed-tools를 도입할 동기(실질적인 피해)가 아직 없습니다. 따라서 「다음에 code-reviewer로부터 동일한 종류의 지적이 왔을 때의 대안」으로서 기록만 해둡니다.

교훈: 「플랫폼이 해결책을 내놓았다」 ≠ 「지금 바로 사용할 이유가 있다」. 해결책의 존재와 그것을 사용할 필요성은 별개의 문제입니다.

케이스 3: Opus 4.8의 기본 effort (v2.1.154) ── 첫 단추를 잘못 끼운 평가

공식 changelog v2.1.154:

Opus 4.8 is here! Now defaults to high effort · /effort xhigh for your hardest tasks

이것은 저(Claude)가 첫 단추를 잘못 끼워 평가를 오해한 케이스입니다. 처음에 저는 「4.8 채택으로 기본값이 high가 된다 = 품질 ↑ · 레이턴시 (Latency) ↑」라고 평가했습니다. 사용자의 지적을 받고 정정 ── 사실 직전까지 사용하던 Opus 4.7 (1M)의 기본값은 xhigh였고, 4.8은 high였습니다. 세대가 올라가면서 기본 effort는 오히려 낮아졌습니다.

오해한 원인은 명백합니다. 「effort 축」만 보고 「모델 세대 축」을 분리해서 생각하지 못했기 때문입니다. Anthropic이 기본값을 낮춘 것은, 세대 성능 향상으로 인해 「동일한 품질을 더 낮은 effort로 낼 수 있게 되었다」는 설계 판단일 가능성이 높습니다. effort만 보고 「품질 ↓」라고 단정 지으면 이러한 설계 의도를 놓치게 됩니다.

타협점은 「4.8은 우선 high 상태로 관망하고, 품질 저하가 관측되면 /effort xhigh로 올린다」입니다. effort를 반사적으로 올리지 않는 것, 이 또한 관망입니다.

참고로 이 정정을 확정할 수 있었던 것은 CHANGELOG가 아니라 **사용자의 실제 기기 상태 표시줄 (Status line)**이었습니다 (4.7 1M에서 effort를 변경하지 않은 상태로 xhigh라고 표시되어 있었습니다). CHANGELOG는 「변경점」만을 적지만, 상태 표시줄은 「현재의 실태」를 직접 보여줍니다. 기본값 확인에 있어서는 실제 기기 표시가 가장 강력한 1차 소스가 될 수 있습니다.

기타 (자동 적용 · 해당 없음)

나머지는 「아무것도 하지 않아도 되는」 그룹입니다:

• cache_creation_input_tokens (v2.1.152) → C3의 usage 반영 (비용 추적) 정밀도가 cache_creation_input_tokens가 0으로 보고되는 버그 수정으로 자동 개선. 아무것도 하지 않음.
• subagent 취소 후 stale permission 크래시 수정 (v2.1.152) → parallel-agents의 안정성에 자동 기여. 아무것도 하지 않음.
• MessageDisplay hook 신설 (v2.1.152) → 기존 C3 hook 라이프사이클에 해당 용도 없음. 수요가 생기면 검토.

4건을 평가하여 C3 측의 코드 변경은 0건. 전부 「기록하고 관망」했습니다. 이것은 태만이 아니라 규율입니다. 기반(Foundation)의 업데이트에 반사적으로 추종하면, (a) 실질적인 피해가 없는 변경에 공수를 들여야 하고, (b) 하위 호환성이나 테스트 보장 범위가 불필요하게 넓어집니다. 「실질적인 피해나 요청이라는 트리거가 오면 움직인다」를 기본 원칙으로 삼고 있습니다.

요약: 「더하기」보다 「빼기 · 기다리기」가 어렵다

두 이야기의 공통점은, 추가는 순식간이지만 어려운 것은 빼기와 기다림의 판단이라는 점입니다.

지난 기사의 "수정하기 전에 조사하면 스코프(Scope)가 줄어든다 / 하지 않기로 하는 판단이 가치가 있다"와 완전히 같은 맥락이었습니다. 해야 할 일(더하는 코드)보다, 하지 않을 일 · 지울 일 · 기다릴 일의 판단이 장기적인 프레임워크 품질을 결정합니다.

업무에서 활용할 수 있는 가능성

1. 설정이나 템플릿을 "배포하는" 도구는 삭제 전략을 처음부터 설계해야 한다

패키지 매니저(Package Manager)는 추가 및 업데이트는 해도 삭제는 하지 않습니다. dotfiles, 스캐폴딩(Scaffolding) 도구, IDE 확장, 사내 템플릿 배포 ── 사용자의 디렉토리에 쓰는 모든 것은 이 구멍을 가지고 있습니다. "그만둔 파일을 어떻게 지울 것인가"를 사후에 처리하려고 하면, 기구 도입 전의 역사적 누락이 반드시 남게 됩니다. 처음부터 "삭제 매니페스트(Deletion Manifest)"와 "부재 시 no-op(No-operation)의 안전한 삭제"를 설계에 넣어두면, 나중에 전체 이력을 감사하는 수고를 덜 수 있습니다.

2. "이력에 삭제된 흔적이 있다" ≠ "사용자에게 전달되었다"

삭제 감사 시 git 이력의 삭제/이름 변경(Rename)만 보면, 출하된 적이 한 번도 없는 중간 상태(커밋 내 이름 변경된 구 명칭, 릴리스 전의 시도, 수명이 짧은 revert)까지 잡아내게 됩니다. "실제로 publish 되었는가 (공개 태그를 통한 실재 확인)"를 이차 필터로 넣으면 정밀도(Precision)가 높아집니다. 배포해야 할 것은 정확한 지시이지, 내부 사정이 아닙니다.

3. AI의 조사는 재현율(Recall) 우선 ── 정밀도(Precision) 필터는 직접 준비한다

조사·탐색 계열의 AI(Claude Code에 내장된 Explore 등)는 망라성을 우선시하므로, 이번 사례에서는 후보의 32%가 과잉 재현(Over-recall)되었습니다. AI에게 망라하게 하고, 기계적인 실재 확인(스크립트)으로 좁히는 역할 분담이 효과적입니다. AI의 출력을 결론으로 삼기 전에, 반드시 일차적인 확인(Back-up) 메커니즘을 거쳐야 합니다.

4. 의존 대상(프레임워크/SDK/본체)의 업데이트는 "기록하며 관망하기"를 기본값으로

토대(Foundation)의 변경 로그(Changelog)에 전부 반응하지 마세요. 영향 평가를 수행하고, 실질적인 피해나 요구사항이 나올 때까지 움직이지 않습니다. "플랫폼이 대칭해(예: disallowed-tools)를 내놓았다"는 사실만으로는 그것을 사용할 이유가 되지 않습니다. 반사적으로 추종하면 보증 범위와 유지보수 비용만 늘어날 뿐입니다.

5. 기본값 확인은 변경 로그보다 "실기(Real Machine)"

변경 로그는 변경된 점만을 기록합니다. 현재의 실태(상태 라인, 설정 덤프, 실기의 동작)가 일차적인 소스로서 승리할 때가 있습니다. 이번에 Opus 4.7(1M)의 기본 effort를 확정할 수 있었던 것은 사용자의 실기 상태 라인이었습니다. 그리고 "effort 축"과 "세대 축"처럼, 평가 축은 분리해서 보아야 합니다. effort만 보고 품질을 판단하면 설계 의도를 오해하게 됩니다.

C3를 써보고 싶다면 ── 시작하는 법

C3는 한 줄로 설치하여 대화하며 사용할 수 있습니다.

pip install claude-code-conductor
cd your-project
c3 init # .claude/ 디렉토리에 에이전트 정의 · skill · hook이 전개됨

그 후 Claude Code에서 /start를 입력합니다. 질의(Hearing) → 설계 → 계획 → 구현 → 리뷰가 하나의 워크플로우로 이어져 있으며, 각 단계의 구분점에서 AskUserQuestion 승인 게이트가 작동합니다(멋대로 돌진하지 않습니다). 발산하며 생각하고 싶을 때는 /brainstorm(v2.29.0~)을 사용합니다.

그리고 미미하지만, C3는 배포한 파일을 "지우는" 것까지 관리해 줍니다. 버전을 올리면서 폐지된 skill이나 hook은 c3 update 시 deletions.txt를 통해 사용처로부터 (존재한다면) 제거됩니다. 오래된 버전에서 한꺼번에 올려도 구 버전 파일의 잔해가 .claude/에 쌓이지 않습니다. Claude / Codex / Cursor 중 무엇을 사용하든, .claude/

를 canonical source (표준 소스)로 하여 c3 init --platform codex|cursor 명령어로 어댑터 (adapter)를 생성할 수 있습니다.

버전 / 작업 요약