개발수양록

Claude Code의 '/model opusplan’과 showClearContextOnPlanAccept 옵션

Claude Code에서 /model opusplan 설정과 showClearContextOnPlanAccept 옵션을 소개합니다.

/model opusplan

/model opusplan 을 선택하면 Opus로 plan을 세우고 Sonnet으로 실행하는 전략을 쓸 수 있습니다. 복잡한 작업에서 Opus의 추론 능력으로 계획을 세우고, 실행은 비용이 낮은 Sonnet으로 처리하는 방식입니다. 그런데 같은 세션 안에서 모델이 전환되면, 그때까지 쌓인 히스토리 전체가 캐시 미스로 재과금됩니다. 턴이 많이 진행된 후에 전환할수록 삼각수 효과로 누적된 토큰이 크기 때문에 비용 타격이 큽니다.

Tip
 토큰 비용의 삼각수 효과와 Prompt Caching에 대한 자세한 설명은 Claude Code 토큰 비용과 프롬프트 캐싱을 참고하세요.

showClearContextOnPlanAccept 설정

세션 중간에 모델이 전환될 때 발생하는 부정적인 효과를 줄이는데 도움이 될 수도 있는 옵션이 있습니다. Claude Code 설정의 showClearContextOnPlanAccept 옵션이 true 이면, plan 승인 시 컨텍스트를 클리어할지 선택하는 옵션이 나타납니다. 'Yes, clear context(??% used) and by pass permissions' 를 선택하면, 컨텍스트를 클리어하면 planning 단계에서 쌓인 히스토리가 제거된 상태에서 실행이 시작되므로, 모델 전환으로 인한 캐시 무효화 비용을 피할 수 있습니다.

이 선택지가 나오도록 활성화하려면 ~/.claude/settings.json 에 다음과 같이 추가합니다.

{
  "preferences": {
    "showClearContextOnPlanAccept": true
  }
}

showClearContextOnPlanAccept은 기본값 변경 이력

Claude Code의 CHANGELOG에 따르면 showClearContextOnPlanAccept은 아래와 같은 이력을 가지고 있습니다.

  • v2.1.0(2026-01-07) : "Clear context" 옵션이 plan 승인 시 기본 선택으로 처음 도입

  • v2.1.2(2026-01-09) : Shift+Tab 단축키로 이 옵션을 건너뛸 수 있는 기능도 추가

  • v2.1.81(2026-03-20) : 기본값이 false 로 변경

따라서 2026년 3월 말 현 시점에서는 showClearContextOnPlanAccept 속성값을 직접 추가하지 않으면 "clear context" 옵션이 나타나지 않습니다.

Plan 실행 전 컨텍스트 클리어의 트레이드오프

이 옵션은 opusplan이 아닌 경우에도 유용할 때도 있습니다. 같은 모델로 plan mode를 사용하더라도, plan 단계에서 많은 턴이 쌓였다면 컨텍스트를 클리어하고 실행을 시작하면 이후 턴의 입력 토큰 크기를 줄일 수 있습니다.

그런데 컨텍스트 클리어에는 트레이드오프가 있습니다. Plan 파일 자체는 디스크(~/.claude/plans/)에 저장되어 보존되지만, planning 중에 읽은 파일 내용이나 탐색 결과는 모두 사라집니다. 따라서 실행 단계에서 필요한 파일을 plan을 가이드 삼아 다시 읽어야 하며, 이 과정에서 추가 토큰이 소비됩니다. planning 중의 논의 내용 중 plan 텍스트에 반영되지 않은 부분도 유실됩니다.

Plan 실행 전에 컨텍스트 클리어에 대해서 아래와 같은 부정적인 사용자 피드백이 있습니다.

  • #18523 Plan 승인 대화상자의 기본 옵션을 설정할 수 있게 해달라는 요청. 컨텍스트를 유지해야 복잡한 문제에서 더 나은 결정을 내릴 수 있고, auto-compact가 이미 컨텍스트를 관리하므로 강제 클리어가 불필요하다는 의견.

  • #18878 "Clear context" 기본 옵션을 비활성화하거나 순서를 변경할 수 있게 해달라는 요청. plan에 포함되지 않은 대화 맥락이 유실되는 문제를 지적하며, 파괴적인 동작이 기본값이 되어서는 안 된다는 의견.

  • #25734 "Clear context and implement"가 기본 옵션인 것은 파괴적이고 되돌릴 수 없다는 문제 제기. 터미널 스크롤백까지 지워져 복구가 불가능하며, 가장 파괴적인 옵션이 기본값이 되어서는 안 된다는 의견.

Claude Code 토큰 비용과 프롬프트 캐싱

Claude Code의 토큰 과금 구조를 이해하고 비용을 최적화하는 실용적인 팁을 정리합니다.

Claude Code는 Anthropic의 API를 호출하는 CLI 도구입니다. Enterprise Plan에서는 API 사용량에 따라 과금되므로, 과금 구조를 이해하면 같은 작업을 더 적은 비용으로 할 수 있습니다.

과금의 기본 단위: 토큰

Claude API는 토큰 단위로 과금됩니다. 토큰 종류별로 가격이 다릅니다.

토큰 종류 설명

Input 토큰

모델에게 보내는 모든 텍스트 (시스템 프롬프트, 대화 히스토리, 도구 정의 등)

Output 토큰

모델이 생성한 응답 텍스트

Thinking 토큰

Extended thinking 모드에서 모델이 내부적으로 추론하는 데 쓰는 토큰. Output과 같은 가격으로 과금

모델별 가격표

2026년 8월 기준으로 백만(1M) 토큰당 가격은 다음과 같습니다.

모델 Input Output Cache Write Cache Read

Fable 5

$10

$50

$12.50

$1.00

Opus 5/4.8

$5

$25

$6.25

$0.50

Sonnet 5

$2

$10

$2.50

$0.20

Sonnet 4.6

$3

$15

$3.75

$0.30

Haiku 4.5

$1

$5

$1.25

$0.10

Claude 5 패밀리가 나오면서 가격 구도가 달라졌습니다. 최상위 모델인 Fable 5는 Sonnet 5의 5배, Opus 5는 2.5배입니다. Haiku 4.5는 Sonnet 5의 절반 수준입니다.

Note

Sonnet 5는 2026년 6월 출시 당시 프로모션 가격(Input $2, Output $10)으로 시작했고, 8월 31일 이후 $3/$15로 인상될 예정이었습니다. 그런데 2026년 8월 10일에 이 프로모션 가격이 정식 가격으로 확정되었습니다. 이전 세대인 Sonnet 4.6은 기존 $3/$15를 유지합니다.

Prompt Caching의 효과

Claude API는 stateless입니다. 매 턴마다 시스템 프롬프트, 도구 정의, 이전 대화 히스토리를 모두 다시 보내야 합니다. 여기서 '턴’은 사용자가 한 번 입력하고 Claude가 한 번 답변하는 단위가 아닙니다. Claude Code는 agentic하게 동작하기 때문에, 사용자가 한 번 입력하더라도 Claude가 파일 읽기, 편집, 명령 실행 등 도구를 호출할 때마다 API 호출이 발생합니다. 즉 한 번의 사용자 입력이 여러 턴에 해당할 수 있습니다.

턴이 진행될수록 입력 토큰이 누적되어 증가합니다. 공식으로 표현하면 다음과 같습니다.

턴 n의 입력 토큰:
  input(n) = B + n·T + (O + Th)·(n − 1)

  B  = 시스템 프롬프트 + 도구 정의 (매 턴 고정)
  T  = 턴당 새 사용자 입력 토큰
  O  = 턴당 출력 토큰 (히스토리 누적)
  Th = 턴당 thinking 토큰 (히스토리 누적)

N턴까지의 총 입력 토큰:
  총 입력 = N·B + T·N(N+1)/2 + (O+Th)·N(N−1)/2

N(N+1)/2 는 삼각수 공식입니다. 즉 총 입력 토큰은 턴 수에 대해 이차(quadratic)로 증가합니다. 10턴 대화의 뒷쪽 턴은 앞쪽 턴보다 훨씬 많은 입력 토큰을 소비하며, 대화가 길어질수록 이 격차는 더 벌어집니다.

Prompt Caching은 이 삼각수 효과를 완화하는 핵심 수단입니다. 이전 턴까지의 히스토리는 대부분 캐시에 남아있으므로, 캐시가 적중하면 반복 전송되는 입력 토큰의 비용이 정가의 10%로 줄어듭니다. 캐싱 없이는 뒷쪽 턴의 비용이 급격히 올라가지만, 캐싱이 잘 적중하면 누적 비용 곡선을 크게 낮출 수 있습니다. 캐시가 잘 적중하면 입력 토큰 비용을 90%까지 절약할 수 있습니다.

캐시 유형 설명 가격(Input 대비)

Cache Write

새로운 내용을 캐시에 저장

125%

Cache Read

캐시된 내용을 재사용

10%

Cache Miss

캐시 만료 후 다시 저장

125% (Cache Write와 동일)

캐시에는 TTL(유효 시간)이 있습니다. API의 기본값은 5분이고, 쓰기 비용을 200%로 내는 대신 TTL을 1시간으로 늘리는 옵션도 있습니다. 실제 적용되는 TTL은 사용하는 Plan이나 실행 환경에 따라 다를 수 있으며, 이 글에서는 5분을 예시로 들었습니다. 자세한 내용은 Prompt Caching 공식 문서를 참고하세요.

캐시 히트율을 높이기 위해서 다음을 의식해야 합니다.

  • 캐시 TTL 안에 다음 턴 진행: 입력을 보내고 나서 다음 턴까지 TTL(예: 5분) 이내로 유지하면 캐시가 살아있습니다.

  • 세션 중간에 모델을 전환하지 않기: 모델을 바꾸면 캐시가 완전히 초기화됩니다. 하나의 대화 세션에서는 가능하면 하나의 모델을 유지합니다.

  • 가급적 대화 중 CLAUDE.md를 수정하지 않기: CLAUDE.md는 시스템 프롬프트의 일부로 매 턴 전송됩니다. 대화 중에 이 파일을 수정하면 시스템 프롬프트의 prefix가 달라져 기존의 모든 캐시가 무효화됩니다. 특히 턴이 많이 진행된 세션에서는 삼각수 효과로 쌓인 대량의 히스토리 토큰이 전부 Cache Write(125%)로 재과금되어 비용 타격이 큽니다. 수정이 필요하다면 새 세션에서 시작하는 것이 비용 면에서 유리합니다.

직접 시뮬레이션해보기

위의 내용을 바탕으로 자신의 사용 패턴에 맞는 비용을 직접 계산해볼 수 있는 시뮬레이터를 Claude Code로 만들었습니다. 세션 내의 턴 수, 토큰량, 캐시 히트율 등을 조절하면서 모델별 비용 차이와 누적 비용 곡선을 확인할 수 있습니다.

Claude Code Token Cost Simulator로 이동 →

참고 자료

Ubuntu에서의 OEM 커널 설치

Ubuntu OEM 커널과 HWE 커널과의 차이와 Ubuntu 공식 ISO 이미지에서 OEM 커널이 선택되는 원리를 정리합니다.

Ubuntu 공식 홈페이지에서 ISO를 받아 같은 방법으로 설치했음에도 설치 시점에 따라서 Lenovo ThinkPad에는 OEM 커널이, Dell XPS에는 HWE 커널이 설치되는 경우를 경험했습니다. 이 글에서는 두 커널의 차이와 자동 선택되는 원리 등을 정리합니다. 현상의 분석과 이 글의 작성에는 Claude Code의 도움을 받았습니다.

Ubuntu 설치 시점에 따른 경험 차이

저는 Lenovo와 Dell 2개의 모델에 Ubuntu를 설치해서 사용하고 있습니다. 2024년 11월에 Dell XPS 13 9350 모델에 Ubuntu 24.04를 설치했을 때는 웹캠이 제대로 동작하지 않았습니다. 2025년 8월경 Lenovo ThinkPad X1 Carbon Gen 13에 Ubuntu 24.04를 설치했을 때는 웹캠이 바로 잡혔습니다. 이 둘의 차이는 당시 Dell에서는 HWE 커널이 설치된 반면, Lenovo에서는 OEM 커널이 설치되었기 때문입니다.

2026년 2월 현재에는 2개의 모델이 모두 Ubuntu 공식 인증기기로 등록되어 있어서 OEM 커널이 설치될 것으로 예상됩니다.

OEM 커널 vs HWE 커널

Ubuntu 24.04 LTS에서 최신 하드웨어 지원을 위해 제공하는 커널은 크게 두 가지입니다.

항목 OEM 커널 HWE 커널

패키지명 예

linux-oem-24.04d

linux-generic-hwe-24.04

커널 접미사 예

6.17.0-1011-oem

6.17.0-14-generic

대상

특정 OEM 파트너 기기 (Lenovo, Dell 등)

일반 사용자 전체

포함 패치

해당 기기 전용 드라이버·패치 (카메라, 지문인식, 열 관리 등)

범용 최신 하드웨어 지원

관리 주체

Canonical OEM 팀 + OEM 파트너

Canonical / Ubuntu 커뮤니티

업데이트 경로

OEM 파트너 저장소 (oem.archive.ubuntu.com)

기본 Ubuntu 저장소

HWE(Hardware Enablement) 커널은 LTS 버전에서 새 하드웨어를 지원하기 위해 최신 업스트림 커널을 백포팅한 것입니다. OEM 커널은 여기에 더해 특정 기기에서만 필요한 패치가 추가로 적용됩니다. 즉, OEM 커널은 하드웨어 제조사와 Canonical이 협력하여, 해당 기기에서 "설치 후 바로 동작(out-of-the-box)"하는 경험을 제공하기 위한 것입니다.

Intel Meteor Lake / Lunar Lake CPU를 탑재한 기기들은 HWE 커널에서 완전히 지원되지 않은 하드웨어가 있었습니다. 대표적인 예가 내장 카메라(MIPI/IPU7)와 일부 지문인식 센서입니다.

OEM 커널이 자동으로 선택되는 원리

Ubuntu 인스톨러(Subiquity)는 설치 중에 ubuntu-drivers 도구를 호출하여 현재 하드웨어를 감지합니다. 이때 DMI(System Management BIOS) 정보를 읽어 Canonical OEM 파트너 목록과 대조합니다.

예를 들어 Lenovo ThinkPad X1 Carbon Gen 13의 경우, 아래와 같은 메타패키지가 매칭됩니다.

Package: oem-sutton-dacia-meta
Modaliases: meta(dmi:*bvnLENOVO:bvrN4B*:pvrThinkPad*)
Depends: linux-oem-24.04c, oem-sutton-meta
Ubuntu-Oem-Kernel-Flavour: oem
Description: hardware support for Lenovo ThinkPad X1 2-in-1 G10, X1 Carbon G13

Modaliases 필드의 패턴(dmi:*bvnLENOVO:bvrN4B*:pvrThinkPad*)이 현재 기기의 DMI 정보와 일치하면, 해당 메타패키지와 함께 OEM 커널이 자동으로 설치됩니다.

설치 흐름을 정리하면 다음과 같습니다.

Ubuntu 설치 중
└─ ubuntu-drivers 가 DMI 정보 확인
   └─ OEM 메타패키지 패턴 매칭
      └─ oem-sutton-dacia-meta 설치
         └─ linux-oem-24.04d 의존성으로 OEM 커널 설치
            └─ → 부팅 커널: 6.17.0-1011-oem

어떤 커널이 설치될지는 하드웨어가 Canonical OEM 파트너 목록에 등록되어 있느냐에 달려 있습니다.

다음과 같이 Intel Ultra 7 258V CPU를 쓰는 기기라도 차이가 생길 수 있습니다.

기기 OEM 메타패키지 설치되는 커널

Lenovo ThinkPad X1 Carbon G13

oem-sutton-dacia-meta

linux-oem-24.04d (OEM 커널)

Dell XPS 13 9350

oem-somerville-tyrogue-meta

linux-oem-24.04d (OEM 커널)

OEM 파트너 목록에 없는 기기

없음

linux-generic-hwe-24.04 (HWE 커널)

그래서 설치 시기와 모델에 따라 어느 커널이 설치 될지가 달랐던 것입니다. 우분투 공식 인증기기라면 OEM 커널이 설치시에 바로 감지되어 설치될 가능성이 높습니다.

아래 명령을 참고로 알아두시면 기기에 대한 정보를 파악하는데 도움이 됩니다.

  • ubuntu-drivers list-oem : 기기에 감지된 OEM 메타패키지

  • sudo dmidecode -s system-product-name : 기기의 정확한 모델명

OEM 커널을 수동으로 설치/제거

현재 어떤 커널이 설치되어 있는지는 다음 명령으로 확인할 수 있습니다.

설치된 커널과 OEM 메타패키지 확인
# 현재 부팅된 커널
uname -r

# 설치된 커널 패키지 목록
dpkg -l | grep linux-image | grep '^ii'

# ubuntu-drivers가 감지하는 OEM 메타패키지 확인
ubuntu-drivers list-oem

우분투 초기 설치 시점에 HWE 커널이 자동 선택되었지만, OEM 커널로 전환을 하고 싶다면 아래와 같이 수동으로 설치할 수 있습니다.

OEM 커널 수동 설치
# 설치 가능한 OEM 메타패키지 목록 검색
apt search linux-oem-24.04

# OEM 커널 수동 설치 (24.04 기준)
sudo apt install linux-oem-24.04d

앞으로 업데이트에도 HWE 커널이 설치되지 않도록 하려면, HWE 커널의 메타 패키지를 제거하면 됩니다.

HWE 커널 제거
sudo apt remove linux-headers-generic-hwe-24.04

또는 HWE 커널의 메타 패키지를 보류(hold) 상태로 설정할 수 있습니다.

HWE 커널 보류 설정
sudo apt-mark hold linux-headers-generic-hwe-24.04

반대로 OEM 커널 없이 HWE 커널만 사용하고 싶다면, OEM 메타패키지를 제거하면 됩니다. 단, 해당 하드웨어에서 필요한 드라이버가 빠질 수 있으므로 주의가 필요합니다.

참고 자료