이 글을 쓰는 이유
당사(Join Class LLC)에서는 도서 집필, 매출 집계, 아침 요약본 등을 claude -p의 헤드리스 실행으로 처리하고 있습니다. 사람이 보지 않는 시간에 작동하기 때문에, Claude Code의 출시 기능은 '편리한 신기능'이 아니라, 비용과 사고율에 변화가 생기는지라는 관점에서 읽어내야 합니다.
2026년 10월에는 2.1.287부터 2.1.295까지 세부적인 기능들이 연속적으로 출시되었습니다(전체 목록은 havoptic의 10월 리리스 페이지에 정리되어 있습니다). 이 글에서는 기능을 하나하나 소개하기보다, 도입을 결정하는 입장의 사람들을 위해 다음 세 가지 내용을 작성합니다.
- 해당 기능으로 무엇이 달라지는가 (비용 절감인가, 사고율 감소인가)
- 무엇은 맡기고, 무엇은 맡기지 않을 것인가
- 당일 중으로 시도할 수 있는 절차, 함정, 검증 방법
전제 조건으로, 여기에 작성된 내용은 당사의 주간 업그레이드 점검(후술)이 10/12에 발표한 리포트와 실제로 작동하는 스크립트를 기반으로 합니다. 각 기능의 사양은 도입 전에 반드시 공식 CHANGELOG에서 확인해 주십시오.
결론부터: 10월 출시 기능 채택 여부 표
당사는 '자동화 기여도 / 도입 용이성 / 비용 절감 / 신뢰성 및 안전성 / 사업 KPI 영향'의 5가지 축을 각각 10점으로 점수화하고, 30점 이상인 경우만 도입 후보로 선정합니다.
| 기능 (버전) | 합계 | 판단 |
|---|
| Haiku 5.5가 기본 Haiku로 변경 (2.1.293) | 37 | 읽기 전용 에이전트만 전환하여 사용 |
| ... | hooks의 `onFailure: | |
1. Haiku 5.5: 무엇을 맡기고, 무엇을 맡기지 않을 것인가
2.1.293 버전부터 기본(default) Haiku가 Haiku 5.5로 변경되었습니다 (릴리스 노트 요약에 따르면, 1M 컨텍스트에서 4.5보다 훨씬 저렴하다고 합니다).
맡길 수 있는 것은 Read/Grep 기능만 가진 집계형 에이전트입니다. 저희 회사에서는 아침 다이제스트(각 부서의 STATE.md를 읽어 표로 정리하는 작업)가 해당됩니다.
---
name: ai-ceo-morning
description: 아침 다이제스트 에이전트. 모든 부서의 상태를 수집하여 CEO용 요약을 생성한다.
...
맡기지 말아야 할 것은 집필형(출판, 기사 작성)입니다. 저희 회사에는 '점수 90점 이상만 출력'이라는 품질 기준이 있는데, 여기서 모델을 사용하면 수정 작업 루프가 늘어나고 결과적으로 호출 횟수가 증가합니다. 이전 절에서 보았듯이 고정비는 한 번 사용할 때마다 발생하므로, 저렴한 모델로 3번 다시 하는 것보다 비싼 모델로 한 번에 처리하는 것이 더 저렴하다는 일이 흔하게 일어납니다.
함정: model:
을 한 번도 지정하지 않으면 에이전트는 부모 세션의 모델을 상속받습니다. 저희 회사에서도 모든 에이전트가 미지정 상태였습니다. 'Haiku가 기본값이 되었다'는 말에 속아 저절로 싸진다고 착각해서는 안 됩니다.
2. effort 지정: 정형 처리만 낮추기
2.1.292 버전부터 서브 에이전트에게 작업 강도(effort)를 지정할 수 있게 되었습니다. 저희 회사의 방침은 간단하여 다음과 같이 나눕니다.
- low: STATE 집계, 승인 큐 처리, 매출 취득
- high: 도서 집필, 가설 검증
무인 실행 측에서는 라퍼에 그대로 전달할 수 있습니다.
source /Users/kyoagun/workspace/one-ceo/.company/scripts/lib/claude-run.sh
RESULT=$(claude_run dept-dev --effort low -p
있습니다. 그런데 10/12 보고서에서, **이 스크립트 자체가 오탐지하고 있었다**는 것을 알게 되었습니다.
CURRENT_VERSION=$(claude --version 2>/dev/null || echo "unknown")
LAST_VERSION=$(cat "$VERSION_FILE" 2>/dev/null || echo "none")
if [ "$CURRENT_VERSION" != "$LAST_VERSION" ]; then
...
비교하고 있는 것은 '로컬 버전'과 '이전 로컬 버전'이며, 최신 릴리스와는 비교하지 않았습니다. CLI가 자동 업데이트되지 않았기 때문에, 매주 '변경 없음'이라고 보고하면서 실제로는 2.1.289에 머물러 있어 6버전이나 뒤처져 있었습니다. 게다가 2.1.289에는 2.1.288에서 발생한 '종료 시 마지막 메시지가 사라지는' 버그가 남아있었습니다(수정은 2.1.291).
무인 실행에 치명적인 것은, 2.1.293에서 수정된 **compaction 이후 완료된 작업을 다시 수행하는 버그**입니다. 긴 출판 플로우 도중에 이것이 발생하면, 게시 관련 처리가 두 번 실행될 위험이 있습니다. 비교 대상을 npm의 최신 버전으로 변경합니다.
LATEST_VERSION=$(npm view @anthropic-ai/claude-code version 2>/dev/null)
LOCAL_VERSION=$(claude --version 2>/dev/null | awk '{print $1}')
if [ -n "$LATEST_VERSION" ] && [ "$LOCAL_VERSION" != "$LATEST_VERSION" ]; then
...
**검증 방법:** 실행 후 `claude --version`
이 `npm view`
의 값과 일치하는지, 그리고 `.claude-version-last`
이 업데이트되었는지 확인합니다.
## 결론: 릴리스 노트는 '자사 고장 모드'로 읽기
이번 달을 되돌아보면, 신 기능을 추가한 것이 아니라, **'측정하지 않았던 비용', '지나쳤던 안전 장치', '오탐지하던 감시' 세 가지를 고칠 구실로 릴리스를 활용했다**는 것이 실체입니다.
도입 판단 체크리스트를 남겨둡니다.
- 무인 실행의 1회당 실제 비용을 측정하고 있는가 (측정할 수 없다면, 모델 변경 전에 Wrapper를 넣는다)
- 신기능은 대화형(dialogue)용인가, 헤드리스(headless)용인가
- 안전 관련 hook은, 고장 났을 때 멈추는 쪽으로 기울어지는가
- 버전 관리는 '최신 릴리스'와 비교하고 있는가
당사가 Claude Code로 사내 업무를 자동화하는 과정에서 겪었던 실패와 설계는 Zenn의 책에 정리했습니다. hooks를 통한 승인 게이트나, 무인 실행 운영 설계를 자세히 알고 싶은 분은 방문해 주세요.
### Discussion
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
