Claude Code가 1M context를 기본값으로 전환했다. 추가 요금은 없다는데, 그건 좋다.

근데 MRCR은 그대로인 거다. 1M 토큰 기준 Opus 4.6의 검색 정확도가 78%인데, 4번에 1번은 정보를 제대로 못 찾는다는 얘기다. GitHub 이슈에도 올라오고 있고, 컨텍스트가 쌓일수록 이전 결정을 잊고, 같은 말을 반복하고, 앞에서 한 얘기를 뒤에서 모르는 현상이 나타나더라고. Anthropic이 이걸 “context rot”이라고 부르긴 하는데.

나는 20k 정도로 유지하고 자주 clear하거나, 큰 작업은 subagent나 subplan으로 쪼개는 편이다. 이 정도면 정확도가 거의 깔끔하고 응답도 안정적이다.

추가 요금 없이 1M을 쓸 수 있는 건 필요할 때 유용하긴 하다. 근데 그게 기본값이 되어야 하는지는 다른 얘기인 거다.

여담으로, 내가 쓰는 opusplan mode는 1M context가 기본값이 아니다.

Claude Code에 AskUserQuestion이라는 도구가 있다. 대부분 존재 자체를 모르는데, Claude가 알아서 추측하는 것과 멈추고 물어보는 것의 차이를 만드는 도구다.

Claude가 확신이 없을 때 — 어떤 접근을 쓸지, 어떤 파일을 수정할지, 네이밍 컨벤션이 뭔지 — 선택지를 제시하고 멈출 수 있는 거다. 막연한 질문이 아니라, 코드베이스를 읽고 추론한 구체적인 옵션이다.

가장 잘 활용하는 방법은 plan mode인데, shift+tab으로 플랜 모드에 진입하고 원하는 것을 한 줄로 설명하면 Claude가 인터뷰를 시작한다. 코드에서 추론한 선택지를 제시하고, 답변을 받아 정제하고, 코드 한 줄 쓰기 전에 상세한 스펙이 완성되는 방식이다.

Anthropic의 Thariq가 이런 얘기를 했다: 최소한의 스펙으로 시작해서 AskUserQuestion으로 인터뷰를 받고, 새 세션에서 그 스펙을 실행하라고.

CLAUDE.md에 지시를 넣어서 Claude가 언제 물어볼지도 가르칠 수 있다:

공유 컴포넌트를 수정할 때, 항상 어떤 consumer를 업데이트할지 물어볼 것.

알아둘 세 가지:

• “Other”를 선택하면 자유 입력이 가능하다 — 선택지에 갇히지 않는다
• multiSelect: true면 체크박스로 여러 개를 선택할 수 있다
• 60초 타임아웃이 있는데, 느리면 추천 옵션을 먼저 선택하고 나중에 조정하면 된다

멘탈 모델로 보면, AskUserQuestion은 Claude가 “선택지는 있는데, 이 프로젝트는 당신이 더 잘 안다”고 인정하는 거다. 그 한 번의 멈춤이 잘못된 추측 세 개를 되돌리는 수고를 줄여주더라고.

aihero.dev에서 tracer bullet 글을 읽고 Claude Code에 그대로 적용해봤다. CLAUDE.md에 이 지침을 추가했다:

## Tracer Bullets

When building features, build a tiny, end-to-end slice of the feature first,
seek feedback, then expand out from there.

전에는 기능 하나 던져주면 Claude가 한 번에 전부 만들려고 했다. API 엔드포인트 → 상태 관리 → UI가 엮인 작업이면 검토하기 어려운 큰 diff가 나왔다. 어딘가 잘못돼 있고 찾는 게 일이었다.

지금은 Claude가 먼저 슬라이스를 나눈다. 엔드포인트 하나, 하드코딩된 UI 호출 하나. 동작 확인. 그 다음 확장. 문제가 쌓이기 전에 표면에 올라오고, 방향이 틀렸을 때 수정 비용도 작다.

원글은 이걸 “AI slop을 통제하는 방법”이라고 표현했는데, 딱 맞는 말이다.

Claude Code로 긴 작업을 돌리고 화면을 잠근 뒤 돌아오면 세션이 죽어있는 거다. macOS가 디스플레이를 끄고 시스템도 슬립으로 들어가면서 Claude가 중간에 끊긴 건데.

caffeinate -d는 디스플레이가 슬립되는 걸 막는다. Claude Code와 함께 실행해두면 자리를 비워도 세션이 살아있다.

caffeinate -d claude

Claude Code가 이미 실행 중이라면 별도로 실행해도 된다.

caffeinate -d &

뚜껑을 닫는 경우(AC 전원 연결 상태의 클램쉘 모드)라면 시스템 슬립도 막아야 하니까 -s를 함께 쓴다.

caffeinate -ds claude

-d는 디스플레이 슬립 방지, -s는 시스템 슬립 방지(AC 전원 연결 시)인데, “화면 잠그고 자리 비웠다”는 상황 대부분은 -d만으로 충분하다.

끝나면 포그라운드로 실행했다면 Ctrl+C, 백그라운드라면 killall caffeinate.

Claude Code로 몇 시간짜리 작업을 자주 돌리다 보면 자연스럽게 손에 익게 되더라고.

OpenClaw이 1월에 바이럴된 건 하나의 아이디어 때문이었다. 터미널 앞에 앉아있지 않아도 AI 에이전트에게 메시지를 보낼 수 있어야 한다는 거. Telegram이나 Discord로 요청하면 알아서 처리하고 같은 채팅에 답을 보내준다. 깔끔한 개념이었다.

Anthropic이 그걸 Claude Code에 직접 넣었다.

Claude Code Channels는 v2.1.80에서 research preview로 출시됐다. 플러그인 방식인데, Telegram 또는 Discord 플러그인을 설치하고 --channels 플래그로 Claude를 시작하고 계정을 페어링하면 로컬 세션이 폰에서 접근 가능해진다. 채팅 앱에서 보낸 메시지가 실행 중인 세션으로 들어오고, Claude는 실제 파일, git 히스토리, 세팅해둔 MCP 도구들을 사용해 작업한 뒤 같은 채널로 응답을 보낸다.

claude --channels plugin:telegram@claude-plugins-official

핵심 아키텍처 선택은 아웃바운드 폴링만 사용한다는 거다. Claude가 설치된 기기가 Telegram이나 Discord에 연결을 먼저 시작하는 방식이라 인바운드 포트를 열 필요가 없다. ngrok도, Cloudflare Tunnel도 필요 없는 거다. OpenClaw는 이런 터널 설정이 필요한 경우가 많았는데 Channels는 그걸 아예 피한다.

한계도 있다. 세션이 열려있을 때만 작동하는 거라서, 터미널을 닫거나 기기가 슬립 상태면 폰에서 보낸 메시지는 조용히 사라진다. OpenClaw는 항상 켜져있는 독립 데몬으로 돌기 때문에 이 상황을 잘 처리한다. Channels는 백그라운드 터미널을 유지하거나 서버에서 Claude를 돌려야 한다.

그럼 OpenClaw는? 여전히 쓸 만하다. 50개 이상의 플랫폼을 지원하고(특히 Slack — Channels에는 아직 없다), Claude 이외의 모델도 쓸 수 있고, 세션이 살아있어야 할 필요도 없다. 근데 어차피 상시 돌아가는 기기에 Claude Code를 띄워두는 워크플로우라면 Channels가 더 단순한 선택이긴 하다. 도구 하나 줄고, 네이티브 통합이고, 별도의 인증 레이어도 없다.

OpenClaw가 보여준 패턴이 Claude Code의 공식 기능이 됐다.

Claude Code에는 allow, ask, deny 세 가지 permission이 있다. settings.json에 설정하고, deny → ask → allow 순으로 먼저 매칭된 규칙이 적용된다. Bash(npm run *), Read(/home/*) 같은 패턴 매칭도 지원한다.

--dangerously-skip-permissions는 이름 자체가 무서워서 안 쓰는 사람들이 많은데, 대신 승인 피로를 없애려고 allow에 Bash(*)를 넣는 경우가 있다. 결국 같은 거다. 플래그는 위험을 눈에 보이게 표시하고, Bash(*)는 그걸 설정 파일 안에 숨기는 것뿐인 거다.

더 나은 방법은 실제로 필요한 것만 추리는 건데, Bash(git *), Bash(npm run *) 같이 자기 워크플로우에 맞는 명령어만 allow에 넣고 위험한 건 deny에 박아두면 된다. 한 번만 제대로 설정해두면 매번 승인 누를 필요도 없고, 전체를 열어두지 않아도 된다.

Claude Code v2.1.69에 voice dictation이 들어왔다. /voice로 켜고, Space 누른 채로 말하고, 손 떼면 텍스트로 변환된다. 끝이다.

입력만 되는 거다 — Claude 응답은 여전히 텍스트다. Siri처럼 양방향 음성이 아니라, 그냥 키보드 대신 말로 프롬프트 치는 거다.

좋은 점은 코딩 어휘를 알아듣는다는 건데, Regex, OAuth, camelCase, async/await 같은 단어들이 제대로 변환된다. 프로젝트명이나 git 브랜치명도 컨텍스트에서 힌트를 잡아내더라고. 음성이랑 타이핑 섞어 쓸 수 있어서, 대충 말로 던지고 키보드로 다듬는 식으로 쓰면 된다.

20개 언어 지원에 한국어도 포함된다. Space가 다른 키랑 겹치면 meta+k 같은 걸로 바꿀 수 있다.

제약: claude.ai 인증이 필요하고 로컬 마이크가 있어야 한다. SSH나 원격 서버에서는 안 된다.

솔직히 사무실에서 쓰기는 좀 애매하긴 하다. 동료들 옆에서 터미널한테 말 거는 건 어색하니까. 재택이나 혼자 있을 때 쓰는 게 맞다.

Claude in Chrome은 지금 내가 쓰고 있는 Chrome을 Claude Code가 직접 제어하는 extension이다.

Playwright랑 결정적으로 다른 점이 있는데, Playwright는 별도 Chromium 인스턴스를 새로 띄운다. 그래서 로그인이 필요한 페이지면 쿠키를 따로 저장하거나 인증 스크립트를 직접 짜야 한다. Claude in Chrome은 그런 거 없다. 내 Chrome이니까 당연히 로그인이 이미 돼있고, Claude는 그걸 그냥 쓴다.

예를 들어 SSO가 붙어 있는 스테이징 환경에서 주문 플로우를 테스트하고 싶다고 하자. Playwright면 세션 설정하다가 20분 날리기 쉽다. Claude in Chrome이면 그냥 물어보면 된다.

한 가지 아쉬운 점은 속도다. playwright-cli에 비해 체감상 좀 느리다. 반복적으로 돌려야 하는 자동화라면 Playwright가 낫다. 하지만 인증이 필요하거나 빠르게 직접 테스트하듯 써보고 싶을 때는 Claude in Chrome이 훨씬 편하다.

새 커맨드가 나왔다. /btw.

Claude가 작업 중일 때 간단한 질문을 할 수 있는 거다. 응답은 오버레이로 뜨고, 닫으면 사라진다.

핵심은 대화 히스토리에 안 들어간다는 건데, 컨텍스트 오염이 없다. 메인 작업을 방해하지도 않는다. 현재 대화 전체를 볼 수 있지만 tool은 사용하지 않아서 토큰 소모도 거의 없다.

단일 응답만 가능하고 이어서 질문은 안 된다. 대화가 필요하면 그냥 일반 프롬프트를 쓰면 된다.

/btw 아까 그 config 파일 이름 뭐였지?
/btw 지금 짜고 있는 로직 설명해줘

나는 작업 중에 질문을 자주 하는 편이라 이게 딱 맞다. 전에는 사소한 질문 하나가 컨텍스트에 쌓이고 이후 모든 메시지의 토큰 비용을 올렸는데, 이제는 잠깐 보고 끝이다.

서브에이전트의 반대라고 보면 되는데, /btw는 전부 보지만 행동 못 한다. 서브에이전트는 행동 가능하지만 빈 컨텍스트에서 시작한다.

기존에 git worktree & claude 명령어로 직접 쓰던 게 claude 내장 기능으로 -w 플래그가 나왔더라고. 나는 원래 이 과정이 귀찮아서 worktree skill로 만들어서 쓰고 있었는데, 내장 기능으로 나왔으니 그냥 쓰고 있다.

worktree를 여러 개 쓰는 입장에서 바로 쓸 수 있는 것도 편하고, 무엇보다 claude session 종료할 때 그 worktree를 바로 정리할 수 있는 게 좋다.

Docker Sandbox 이전에는 선택지가 두 개였다. bash 명령어마다 수동으로 승인하거나, --dangerously-skip-permissions 걸고 기도하거나. 전자는 생산성을 죽이고, 후자는 이름 그대로 위험하다.

Docker Sandbox는 그 사이에 있다. OS 레벨 프리미티브(macOS는 Seatbelt, Linux는 bubblewrap)로 파일시스템과 네트워크 격리를 건다. Claude는 작업 디렉토리 안에서만 읽고 쓸 수 있고, 허용된 도메인만 접근 가능하다. 안전한 명령어는 permission 프롬프트 없이 바로 실행되고, 그 외에는 차단된다. /sandbox만 치면 된다.

--dangerously-skip-permissions와의 결정적 차이는 prompt injection 방어다. 악성 의존성이 Claude를 속여서 뭔가 실행시켜도, ~/.bashrc 건드릴 수 없고, SSH 키 유출 안 되고, 공격자 서버에 연결도 못 한다. skip-permissions는 이 모든 게 뚫려 있다.

근데 아직 거친 부분이 꽤 있다. Docker 자체가 sandbox 안에서 호환이 안 돼서 excludedCommands로 빼줘야 한다. 환경변수 하나 추가하려면 sandbox 재시작해야 하는데 대화 컨텍스트가 날아간다. 일부 dev 의존성은 sandbox OS 아키텍처랑 안 맞고, watchman은 작동을 안 해서 Jest 쓸 때 --no-watchman 붙여야 한다. 그리고 sandbox 안에서 명령어가 실패하면 dangerouslyDisableSandbox escape hatch가 발동되는데, 이게 생각보다 자주 뜬다.

방향은 맞다. 아직 매끄럽지 않을 뿐이다.

agent-browser에서 dogfood라는 스킬을 냈다. 웹앱을 실제 사용자처럼 탐색하면서 버그와 UX 이슈를 찾고, 스크린샷과 재현 영상, 재현 단계를 포함한 구조화된 리포트를 돌려주는 거다.

그전까지는 AI 에이전트로 탐색적 QA를 하려면 브라우저 자동화를 직접 조립해야 했는데, 이 스킬은 그 과정을 Claude Code에서 단일 명령으로 쓸 수 있게 묶어놓은 거다.

테스트 파일을 짜거나 assertion을 작성하는 방식이 아니라 사람 QA처럼 앱을 한 번 쭉 돌아보는 방식이다. 결과가 구조화된 리포트로 나온다는 게 실제로 쓸 수 있는 포인트이긴 한데, 실제로 얼마나 빠른지, 토큰을 얼마나 잡아먹는지는 직접 테스트해봐야 알 것 같다.

Haiku 3는 많은 사람에게 나쁜 인상을 남겼다. 나도 그랬다. 쓸만한 모델이 아니었고, 그 인식이 Haiku 전반에 대한 선입견으로 굳어진 거다.

근데 Haiku 4.5가 Opus보다 나은 지점이 하나 있는데, 지침을 말 그대로 따르는 거다. Opus는 추론을 잘한다. 그게 장점이긴 한데, 그 추론 능력이 오히려 문제가 되는 경우가 있더라고. 프롬프트에 적힌 걸 자기 판단으로 해석하거나 무시하는 거다. 실제로 Opus 4.6에 참조 문서를 4~5번 다시 읽으라고 해도 계속 특정 지침을 무시했다는 GitHub 이슈도 있고, 슬라이드 텍스트 생성 벤치마크에서는 Haiku가 지침 준수율 65%로 프리미엄 모델의 44%를 앞섰다는 결과도 있다.

프롬프트를 해석하지 말고, 개선하지 말고, 그냥 실행하게 하고 싶을 때 Haiku가 더 믿음직하다. 빠르고 저렴하다는 이유로 쓰는 사람이 많은데, 지침 충실도 쪽은 잘 언급되지 않는다.

Claude Code의 auto memory는 Claude가 세션 간에 스스로 메모를 남기는 기능인데, 빌드 명령어, 디버깅 패턴, 코드 스타일 같은 걸 Claude가 알아서 판단해서 저장하는 거다.

나는 여기에 수동 레이어를 하나 얹어서 쓰고 있다. Claude가 마음에 안 드는 방식으로 코드를 짰을 때 — 잘못된 패턴이든 스타일이든 — 그 자리에서 고쳐준다. 그 시점에 remember skill이 실행되면서 auto memory에 저장할지 물어보는데, 앞으로도 계속 이렇게 했으면 하는 내용이면 저장하는 거다.

이렇게 하면 교정이 세션을 거치며 쌓이더라고. 매번 같은 실수 반복하는 대신, 다음 세션 시작할 때 이미 그 맥락이 로드돼 있는 상태가 된다.

근데 remember skill만 있다고 자동 trigger가 되는 건 아니다. CLAUDE.md에 skill auto trigger 조건을 따로 적어줘야 한다. 그게 없으면 교정하는 순간에 skill이 발동이 안 된다.

Claude Code를 만든 Boris Cherny의 CLAUDE.md는 약 2.5k 토큰, 100줄 수준이다. 어떤 개발자는 이걸 8배 길이로 쓰다가 오히려 결과가 더 나빠졌다는 사례도 있더라고.

이유는 간단한데, CLAUDE.md는 매 세션 시작 시 컨텍스트에 포함된다. 시스템 프롬프트, 툴 정의, MCP 스키마만으로 이미 30,000~40,000 토큰이 나간다. CLAUDE.md가 길수록 실제로 쓸 수 있는 컨텍스트가 그만큼 줄어드는 거다.

Boris의 방식은 이렇다. 처음부터 많이 적어두는 게 아니라, Claude가 뭔가 잘못할 때마다 한 줄씩 추가하는 거다. 실제 실수 기반으로 점진적으로 쌓이는 거라 군더더기가 없다.

CLAUDE.md에 들어간 것들 중 대부분은 사실 거기 있을 필요가 없다. 워크플로우, 다단계 프로세스, 스타일 가이드 같은 건 skill로 빼면 된다. skill은 필요할 때만 로드되니까. CLAUDE.md에는 모든 요청에 반드시 적용돼야 하는 것만 남기는 거다. 나머지는 낭비다.

Claude Code v2.1.72에 /loop가 추가됐다. 세션 안에서 프롬프트를 반복 실행하는 기능인데, 쓰기 편하다.

/loop 5m 배포 끝났는지 확인하고 알려줘

5분마다 Claude가 깨어나서 프롬프트를 실행하고 다시 대기한다. 인터벌 생략하면 기본 10분이다. 다른 커맨드도 loop에 붙일 수 있다.

/loop 20m /review-pr 1234

일회성 리마인더는 /loop 없이 그냥 자연어로 말하면 된다.

오후 3시에 릴리스 브랜치 푸시하라고 알려줘
45분 후에 통합 테스트 통과했는지 확인해줘

예약된 작업 확인이나 취소도 자연어로 된다. 어떤 작업이 예약돼 있어? / 배포 체크 작업 취소해줘.

한계는 알고 쓰는 게 좋다.

작업은 세션 스코프다. 터미널 닫으면 다 사라진다. 재시작해도 복원 안 된다. 반복 작업은 3일 지나면 자동 만료되는데, 장기 자동화에 쓰기엔 맞지 않는 거다.

Claude가 응답 중일 때 타이밍을 놓치면 대기했다가 idle 상태에서 1회 실행된다. 놓친 횟수만큼 몰아서 실행하지는 않는다. /loop 5m 작업이 긴 대화 중에 세 번 지나쳤어도, idle 되는 순간 딱 한 번만 실행된다.

세션당 최대 50개 작업 예약 가능하다.

터미널 없이 돌아가거나 재시작 후에도 유지돼야 하는 자동화라면 GitHub Actions schedule 트리거나 Desktop scheduled tasks 쪽을 써야 한다.

Claude Code에서 터미널 밖에서 작업하는 방법이 세 가지가 생겼는데, 얼핏 비슷해 보여서 헷갈린다.

Web (Dispatch) 은 제일 설명하기 쉬운 거다. Claude가 클라우드에서 실행되는 거라 내 기기랑 무관하다. claude --remote "인증 버그 수정해줘" 하면 Anthropic 샌드박스에 GitHub 레포가 클론되고 독립적으로 작업이 진행된다. 노트북 닫아도 되고, 나중에 돌아와서 PR 만들면 끝. 병렬로 여러 개 돌려도 된다.

Remote Control 과 Channels 는 둘 다 로컬이다. 내 기기에서 실행된다. 근데 여기서 성격이 갈린다.

Remote Control은 내가 Claude와 대화하는 주체인데, 기기만 다른 상황을 위한 거다. 책상에서 세션을 시작하고 소파로 이동했는데 계속 조작하고 싶은 경우 같은 거. claude.ai/code나 Claude 앱 열면 세션이 보이고, 거기서 메시지 보내고, 답 읽고, 툴 사용 승인하면 된다. 같은 대화, 다른 화면인 거다.

claude --remote-control "auth 모듈 리팩터링"
# → claude.ai/code와 Claude 앱에서 세션이 보임

Channels는 다른 무언가가 Claude를 트리거하도록 만드는 거다. 내가 직접 조작하는 게 아니라 리스너를 세팅하는 개념이다. Telegram으로 메시지가 오면 Claude가 처리하고 답을 보내고, 새벽 3시에 CI 웹훅이 발화하면 Claude가 실패 로그 읽고 디버깅을 시작한다. 내가 보고 있지 않아도 된다.

claude --channels plugin:telegram@claude-plugins-official
# → Telegram 봇으로 메시지가 오면 Claude가 반응

예시로 보면 차이가 명확해진다.

소파에서 “이 PR에 뭐가 남았어?”라고 물어보고 채팅 스레드에서 답을 읽고 싶다 — Channels. 소파에서 Claude가 리팩터링하는 과정을 단계별로 지켜보며 중간에 메시지 보내고 싶다 — Remote Control.

CI 실패할 때마다 Claude가 자동으로 진단을 남겨줬으면 한다 — Channels. 돌아가는 Claude 세션에 폰으로 끼어들어 “그 파일은 넘어가줘”라고 하고 싶다 — Remote Control.

Channels는 반응형이고, Remote Control은 대화형이다.

Claude Code v2.1.80에서 skill frontmatter에 effort 필드가 추가됐다. 스킬이 실행될 때 얼마나 깊이 추론할지를 스킬 자체에 지정할 수 있게 된 거다.

---
name: remember
description: 선호 설정을 메모리에 저장
effort: low
---

low, medium, high 세 단계다. 이전에는 effort가 세션 단위 설정이었는데, /effort high 해놓고 무거운 작업 끝낸 다음에 리셋 잊어버리거나, 가벼운 스킬인데 high effort 켜진 채로 돌아가는 일이 있었다. 이제 스킬이 그 의도를 직접 갖고 다닌다.

실용적인 구분은 명확하다. remember 스킬은 파일에 한 줄 저장하는 거라 low면 충분하다. research나 plan-deep은 멀티 파일 분석에 아키텍처 추론까지 하는 거라 high가 맞다. medium은 Opus 4.6의 기본값이고, 대부분의 작업엔 이게 적당하다.

스킬 작성자가 토큰 예산 의도를 스킬 자체에 담을 수 있다는 게 좋은 점인데, 빠르고 가볍게 동작하도록 만든 스킬이라면 그게 항상 보장되는 거다.

Claude는 각 SKILL.md의 description을 읽고 대화 맥락과 매칭을 시도한다. 이론상으로는 맥락이 맞으면 적절한 스킬이 로드되는 건데, 실제로는 자주 빗나간다.

description은 소프트 매칭이다. Claude에게 힌트를 주는 거지, 규칙을 부여하는 게 아니다. 특정 타이밍에 스킬을 정확히 실행시키려면 두 가지 방법이 있다.

방법 1: 직접 slash command. /skill-name 입력하면 바로 실행된다.

방법 2: CLAUDE.md에 trigger 규칙 명시. 아래처럼 적어두면 된다:

"commit"이라고 하면 smart-commit 스킬을 실행해.
구현이 완료되면 code-review 스킬을 실행해.

부작용이 있는 스킬 — 배포, 커밋, 메시지 발송 — 은 원래 이런 식으로 제어해야 하는 거다. disable-model-invocation: true 플래그도 같은 이유로 있는 거고. 의도치 않은 자동 실행을 막기 위해서다.

스킬이 원하는 타이밍에 안 켜진다면 description 문제가 아니라 trigger 방식 문제인 거다.

Claude Code 처음 세팅할 때 Oh My Claude Code를 깔았다. Statusline, Ralph 루프, 에이전트 30개, 오케스트레이션까지. 처음엔 나쁘지 않았다.

근데 Claude Code를 제대로 쓰기 시작하면서 — 컨텍스트 관리, 에이전트 비용, 얼마나 가볍게 유지할지 — OMC가 무겁게 느껴지더라고. 내가 고른 적 없는 에이전트들이 돌고 있고, CLAUDE.md에 내가 쓴 게 아닌 오케스트레이션 로직이 쌓여 있었다.

결국 지우고 다 직접 만들었다. Statusline 설정, 간단한 루프 스크립트, 내가 이해할 수 있는 CLAUDE.md.

OMC는 시작점으로는 괜찮다. 다만 어느 정도 익숙해지면 뭐가 돌아가는지 직접 알고 싶어지는 시점이 오긴 한다.

LLM에는 학습 데이터 컷오프가 있다. 최근 메이저 버전이 나온 라이브러리를 물어보면 Claude는 자신 있게 예전 API를 알려주는 거다. Context7은 이 문제를 해결한다. Upstash가 만든 오픈소스 도구인데, 질문하는 순간 공식 최신 문서를 실시간으로 가져와 프롬프트에 주입해준다. 오래된 지식도, 환각된 메서드 시그니처도 없다.

지금까지 Context7은 MCP 서버로만 쓸 수 있었다. MCP 설정에 추가해두면 백그라운드에서 돌면서 에이전트가 필요할 때 문서를 가져오는 방식이다. 잘 작동하긴 하는데 비용이 있다. MCP 서버의 툴 정의가 세션 내내 컨텍스트 창에 올라가 있고, 가져온 문서도 필요 이상으로 통째로 들어오는 거다.

이제 CLI가 나왔다. npx ctx7 setup 하나면 끝. MCP 설정 불필요.

실질적인 차이는 이렇다. MCP는 항상 켜져 있는 오버헤드인 거다. CLI + skill 조합은 라이브러리 관련 질문이 실제로 나올 때만 문서를 로드한다. 동일한 최신 정보를 얻으면서 컨텍스트 사용은 필요한 시점에만 집중되는 거다.

평소에 컨텍스트를 20k 안팎으로 유지하려는 입장에서는 반가운 변화인데, 필요한 문서만 뽑고, 쓰고, 끝. 군더더기 없다.

npx ctx7 setup. 한번 써보시라.

Claude Code에서 opusplan이라는 모델 옵션 알고 있는가?

/model 치면 목록에 안 나온다. /model opusplan이라고 직접 입력해야 활성화된다. 플랜 모드에서는 Opus, 나머지 작업은 Sonnet으로 동작하는 숨겨진 옵션인 거다.

컨셉은 단순한데, 계획은 똑똑한 모델이 짜고 실행은 빠른 모델이 하는 거다. Shift+Tab으로 플랜 모드 들어가면 Opus가 사고하고, 플랜 확정 후 구현 단계에서는 자동으로 Sonnet으로 전환된다.

개인적으로 이게 맞다고 보는 게, 플랜만 잘 짜면 80%는 끝난 거다. Opus가 아키텍처와 단계를 제대로 잡아주면 Sonnet이 실행하는 데 문제없다. 보일러플레이트 작성이나 명확한 diff 적용에 최고급 모델이 굳이 필요하진 않으니까.

/model opusplan. 한번 써보시라.

Claude Code가 기본 effort를 high에서 medium으로 바꾸고, “ultrathink” 키워드로 한 턴만 high로 올릴 수 있게 했다.

기존 기본값이 high였는데, 솔직히 과했다. 변수명 바꾸는 것도 high, 오타 고치는 것도 high. 생각 안 해도 되는 데 토큰을 태우고 있었던 거다.

이제 medium으로 일상적인 건 빠르게 처리하고, 진짜 깊이 생각해야 할 때 — 아키텍처 결정이나 복잡한 버그, 멀티 파일 리팩토링 — 프롬프트에 “ultrathink” 넣으면 된다. 그 턴만 high고, 다음 턴은 다시 medium으로 돌아온다.

처음부터 이랬어야 하는 거긴 하다. 대부분의 작업은 깊은 사고가 필요 없고, 필요한 순간은 본인이 알거든.

medium + 필요할 때 ultrathink. 이게 맞다.

1M 컨텍스트. 다 넣으면 알아서 해주겠지?

그게 아니다. MRCR이라는 벤치마크가 있는데, 긴 컨텍스트에서 특정 정보를 정확히 찾는 능력을 측정하는 거다. 1M 토큰 기준으로 이전 세대 모델은 17% 정도였고, 지금 최고 모델도 76%다. 넣은 정보를 모델이 생각보다 잘 못 찾는 거다.

메일함에 100만 개 메일 넣어두고 하나 찾으라는 거랑 비슷한 거긴 하다.

그래서 나는 20k 정도로 유지한다. 이 정도면 거의 다 찾고, 응답도 깔끔하다. 크다고 좋은 게 아니라 딱 맞게 넣는 게 낫더라고.

Claude Code 스킬을 손으로 작성하고 있다면 Anthropic의 skill-creator를 써보는 게 낫다.

Create, Eval, Improve, Benchmark 네 가지 모드가 있는데, 스킬 만드는 것만이 아니라 eval로 테스트하고, 버전 간 A/B 비교하고, description 최적화해서 Claude가 적절한 타이밍에 스킬을 트리거하게 만들 수 있다.

eval 시스템이 제일 좋은 부분인데, 테스트 프롬프트 정의하고 기대하는 결과 적어두면 스킬이 실제로 동작하는지 알려준다. 감으로 확인하는 게 아니라서 편하다.

벤치마크 모드도 있어서 pass rate, 시간, 토큰 사용량을 추적할 수 있다. 모델 업데이트 후에 스킬이 아직도 잘 동작하는지 확인할 때 쓰기 좋다.

skill-creator 플러그인 설치하고 /skill-creator 실행하면 된다.