글

라벨이 Claude Code인 게시물 표시

제작 에이전트와 검수 에이전트를 분리하니 실패 지점이 보였다

이미지
답부터 말하면 제작자와 검수자를 나누는 이유는 문장을 더 매끈하게 만들기 위해서가 아니다. 공개를 막아야 할 오류를 이름 붙이고, 수정한 뒤에만 통과시키기 위해서다. 2026년 9월 23일의 독립 검수 기록에서는 구체적인 수정 요구 4건이 나왔다. 제작자가 고친 뒤 같은 범위로 다시 검수했고, 그제야 판정이 REVISE에서 PASS로 바뀌었다. 왜 잘 쓰는 에이전트에게 검수까지 맡기면 안 될까? 문제는 작성자가 자신의 전제를 이미 알고 있다는 점이다. 문장이 자연스러우면 빠진 조건도 머릿속에서 자동으로 보완한다. 검수자는 그 전제를 공유하지 않아야 한다. 원고와 근거 파일을 대조하고, 현재형 주장인지 과거 기록인지, 절차가 실제로 끝까지 이어지는지 따로 확인해야 한다. 2026년 9월 14일 결정 기록도 이 구분을 택했다. 익명 비교에서 deep(장시간 작업하는 제작 에이전트) 제작본은 사실 정확성과 유용성이 각각 5 대 4로 앞섰고, 리드(작업을 나누고 검증하는 주 에이전트) 제작본은 가독성이 4 대 3으로 앞섰다. 그래서 제작은 deep, 검증은 리드가 맡는 구조로 정했다. 이 수치는 모델의 보편적 우열이 아니다. 당시 여섯 글로 누가 더 잘 쓰는지를 비교한 운영 기록이며, 검수를 분리하면 오류가 준다는 증거는 아니다. 같은 조건의 재평가도 아직 하지 않았다. 제작과 독립 검수의 역할 비교 구분 제작자가 주로 보는 것 독립 검수자가 확인할 것 통과 조건 원고 설명의 흐름과 독자 질문 주장과 근거의 일치 근거 없는 현재형 주장이 없음 절차 단계가 자연스럽게 읽히는지 실제 실행에 빠진 단계가 없는지 같은 경로를 끝까지 따라갈 수 있음 용어 문맥 안에서 이해되는지 식별자·버전·범위가 일관적인지 같은 대상을 같은 이름과 범위로 설명함 판정 초안 완성 REVISE 또는 PASS PASS 전에는 발행하지 않음 독립 검수는 실제로 무엇을 잡았나? 한 번의 검수에서 잡힌 수정 항목은 네 가지였다. 맞춤법보다 주장 범위와 실행 조건에 가까운 문...

Claude Opus 5.5 가격 20% 인하, Claude Code 비용도 20% 줄까?

이미지
답부터 말하면 토큰 사용량이 그대로인 API 작업은 단가 인하분(입력·출력 20%, 캐시 읽기 60%)만큼 저렴해지지만, 내 청구액이 반드시 20% 줄지는 않는다. Opus 5.5는 기본 effort가 medium이라 출력 토큰이 줄 수도 있지만, 끌 수 없는 adaptive thinking이 출력 토큰으로 과금되므로 thinking을 끄고 쓰던 작업은 출력이 늘 수도 있기 때문이다. 구독으로 Claude Code를 쓰는 사람은 더 조심해서 읽어야 한다. Pro·Max의 포함 사용량은 토큰 단가로 직접 청구되지 않으므로, 단가 인하율 대신 5시간 한도 도달 시점과 추가 사용 크레딧을 같은 기간에 기록해야 한다. 가격·사양 확인일은 2026년 9월 28일 KST다. 금액은 100만 토큰당 USD이며 세금·환율·카드 수수료와 별도 도구 비용은 포함하지 않는다. 가격표는 정확히 무엇이 20% 내렸나? Anthropic은 2026년 9월 22일 Claude Opus 5.5를 공개했다. 공식 발표 와 모델 문서 기준으로 컨텍스트는 100만 토큰, 최대 출력은 12만8000토큰이며 adaptive thinking은 항상 켜지고 기본 effort는 medium이다. Opus 5.5의 표준 API 단가는 입력 $4, 출력 $20, 5분 캐시 쓰기 $5, 1시간 캐시 쓰기 $8, 캐시 읽기 $0.20다. Opus 5의 $5·$25·$6.25·$10·$0.50과 비교하면 입력·출력·캐시 쓰기는 20%, 캐시 읽기는 60% 낮다. Anthropic은 기본 설정의 일반 작업에서는 작업당 토큰도 줄어 Opus 5보다 40% 저렴하다고 자체 시험 결과를 밝혔지만, 이 글은 그 수치를 검증하지 않았다. 모델별 표준 API 가격·사양 — 2026-09-28 조회, USD/100만 토큰 모델 입력 출력 캐시 읽기 컨텍스트 / 최대 출력 기본 effort Claude Opus 5.5 $4 $20 $0.20 1M / 128K medium Claude Opus 5 $5 $25 ...

Claude Code 요금제와 실제 비용: Pro·Max·Team, API 종량제는 언제 더 쌀까?

Pro를 결제했는데 API 비용이 또 나왔다면? 요금제를 올리기 전에 로그인과 청구 경로부터 확인한다. 구독의 포함 사용량, 구독용 추가 사용 크레딧, Console/API 과금은 같은 항목이 아니다. 아래 가격표는 2026-09-14 조회값이며, 예시 토큰은 실제 사용량이 아닌 계산 가정이다. 편집 보완: 2026-09-23. 이번에는 청구 경로 확인 순서와 비교 기록 양식을 추가했다. 가격표 전체나 한국 계정 결제액을 이날 다시 검증한 것은 아니다. 이중 청구처럼 보일 때의 확인 순서 실행한 CLI의 버전과 로그인 계정을 기록한다. ANTHROPIC_API_KEY 의 설정 여부를 확인하되 키 값은 출력하거나 공유하지 않는다. 공식 Pro·Max 도움말은 이 변수가 있으면 구독 대신 API 키로 인증한다고 안내한다. 구독으로 쓰려던 개인 환경에 불필요한 키 설정이 있다면 설정 위치를 확인하고, Claude Code를 실행할 환경에서 해당 변수를 해제한 뒤 다시 실행해 구독 계정으로 로그인한다. 쉘 시작 파일이나 IDE에서 다시 주입되는지도 확인한다. 조직에서 관리하는 키는 임의로 제거하지 말고 관리자에게 인증 경로를 확인한다. Claude Code의 /usage 에서 구독 사용량과 세션 비용 추정치를 구분한다. 세션 달러 수치만으로 추가 청구가 발생했다고 판단하지 않는다. 구독의 추가 사용 크레딧 내역과 Console/API 사용 내역을 각각 확인한다. 최종 API 청구 판단은 Console 내역으로 하고, 구독료와 별도 사용료를 같은 기간으로 맞춰 비교한다. 이 절차의 문서 근거: Pro·Max에서 Claude Code 이용 , 공식 비용 관리 문서 (해당 인증·사용량 설명은 2026-09-23 조회). 독자의 계정에 로그인하거나 유료 작업을 실행한 검증은 아니다. 내 비용을 비교할 기록 양식 같은 기간에 작업과 완료 조건 / 모델 / 인증 방식 / 일반 입력·캐시 쓰기·캐시 읽기·출력 토큰 / 추가 사용료 / 한도에 막힌 시점 / ...

"ok" 한 마디에 $0.07 — AI 코딩 도구 비용은 어디서 새는가

이미지
“ok” 한 마디에 $0.07 — AI 코딩 도구 비용은 어디서 새는가 정정 (2026-08-11) — 아래 네 번째 절의 근거가 틀렸다. 분석 코드는 2026-04-06 커밋에서 파이프라인에서 빠졌고, 그 뒤로는 유료 호출이 없었다. 5월 글의 “0원”은 발행 시점에 맞는 서술이었다. 해당 절을 실측대로 고쳐 적었다. Claude Code 실측(두 번째·세 번째 절)은 영향이 없다. AI 코딩 도구 비용은 월 구독료로 끝나는 것처럼 보인다. 화면에 금액이 안 뜨니 그렇게 읽힌다. 헤드리스 모드로 실험을 하나 했다. 모델에게 “ok” 한 마디만 시켰다. 청구된 금액은 $0.0697 이었다. 실제로 주고받은 토큰은 123개다. 나머지 51,386개는 지시한 적이 없다. 단 이 비율은 가장 나쁜 경우에 가깝다는 점을 미리 적어둔다. 결론부터 적는다. 비용은 대화가 아니라 함께 실려 가는 컨텍스트에 몰려 있고, 그 값은 대부분 기록되지 않는다. 같은 도구인데 실행 방식에 따라 금액이 보이기도 하고 아예 안 남기도 했다. 5월에 발행한 글에서는 이 수집기를 “비용 0원”이라고 적었다. 그 값을 재본 기록은 어디에도 없었다. 청구서를 열어보게 만든 것 한도 경고를 90%에서 처음 본 적이 있다. 어떤 작업이 비쌌는지 되짚지 못한 적도 있다. 매일 도는 자동화의 회당 비용을 모른 채 몇 달을 굴린 적도 있다. 밖에서도 같은 얘기가 올라온다. Hacker News에 “Cursor removed cost information from the usage page and CSV export”라는 글이 걸렸다. 8월 2일 작성이고, 조회 시점 기준 336점에 댓글 154개다. 스레드 본문은 안 읽었으니 제거 의도는 모른다. 같은 날 수집된 제목 중에는 이런 것도 있었다. “I don’t trust agent tools when I can’t understand what the work costs”. 제목만 봤다. 그래서 남의 도구 말고 직접 굴리는 것부...

I audited my AI coding setup: a security hook that never ran, and 11 dead agents

이미지
For months I believed my Claude Code setup was fine. Hooks, agents, rules, automations. Everything looked healthy, because nothing threw errors. Then I audited the whole thing for the first time since building it. Roughly half of it was either dead or faking it. The worst find: a security hook that had never run. Not once. Since the day I installed it. The security hook that never fired I wrote a hook to stop secrets (API keys, tokens) from leaking into tool output. The code checked a field called tool_result . The actual field in the payload is named tool_response . One word. The match never succeeded, so the hook silently did nothing on every single call, for months. No error, no warning. A guard that never fires looks exactly like a guard with nothing to catch. Fixing the typo would not have been enough, though. The hook ran after the tool executed. By the time it could mask anything, the model had already read the output, secret included. Post-hoc masking is too late by des...

AI 코딩 스킬, 많을수록 좋을까 — 자산이 부채로 바뀌는 손익분기

이미지
AI 코딩 스킬은 자산이다. 처음 몇 개는 그렇다. 그런데 수가 늘면 세금이 붙는다. 어느 스킬이 뜰지 예측이 안 되고, 도구 출력이 컨텍스트를 먹고, 모델이 바뀌면 쌓은 걸 전부 다시 만진다. 스킬을 관리하는 앱이 시장에 나온 게 그 신호다. 만들지 말라는 게 아니다. 만든 만큼 쳐내야 자산으로 남는다. 스킬은 자산으로 시작한다, 그런데 요즘 개발자들이 자기 .claude 디렉터리를 통째로 공개한다. TypeScript 교육자 Matt Pocock도 스킬 묶음을 GitHub에 올렸다. 제목이 “Skills for Real Engineers”이고, 소개가 “내 .claude 디렉터리에서 바로”다. skills.sh 같은 스킬 레지스트리도 생겼다. 스킬이 자산인 건 맞다. 손으로 반복하던 작업을 트리거 한 줄로 줄인다. 결과도 매번 일정해진다. 그래서 다들 쌓는다. 그런데 같은 GitHub에 묘한 게 같이 뜬다. 스킬을 “관리하고 동기화하고 정리”하는 데스크톱 앱이다. skills-manager는 Cursor·Claude Code·Codex 등 15개 넘는 도구의 스킬을 한곳에서 관리한다고 소개한다. 자산을 관리하는 전용 앱이 필요해졌다는 건, 그 자산이 관리 대상이 됐다는 뜻이다. 관리 대상은 곧 부담이다. 여기서 질문이 갈린다. AI 코딩 스킬은 많을수록 좋은가. 다음 중 하나라도 있나 비슷한 일을 하는 스킬이 둘 이상이라, 어느 게 뜰지 헷갈린 적이 있다. 스킬 하나를 고쳤더니 엉뚱한 데서 다른 게 어긋난 적이 있다. 내가 무슨 스킬을 만들어뒀는지, 목록을 열어봐야 기억나는 적이 있다. 셋 중 하나라도 해당되면 이미 부채 구간에 발을 걸친 것이다. 세 신호를 하나씩 본다. 신호 1 — 어느 스킬이 뜰지 예측이 안 된다 스킬이 늘면 비슷한 트리거를 여럿이 주장한다. “리뷰”라는 말에 코드 리뷰 스킬도 반응하고, 글 리뷰 스킬도 반응한다. 그러면 매 요청마다 “어느 스킬을 부를지” 판별하는 비용이 붙는다. 자동 라우팅 점...

MCP vs CLI — AI 코딩 에이전트 도구 연결, 둘 다 써보고 정리한 선택 기준

이미지
MCP vs CLI — AI 코딩 에이전트 도구 연결, 둘 다 써보고 정리한 선택 기준 AI 코딩 에이전트에 도구를 붙이는 방식을 두고 MCP냐 CLI냐 하는 글이 늘었다. 나는 양쪽을 다 쓴다. 코드 검색은 MCP 서버로 하고, 시크릿 차단과 블로그 발행은 CLI 쪽에 맡긴다. 그런데 오늘 평소와 다른 디렉토리에서 세션을 열었다가, 늘 쓰던 MCP 서버가 조용히 빠져 있는 걸 발견했다. 에러 한 줄 없었다. 이 사건까지 겹치고 나서야 정리가 됐다 — 판단 기준은 도구의 모양이 아니라 “무엇을 통제해야 하는가”였다. 먼저 요약. 세션 안에서 반복되는 조회는 MCP가 이기고, 실행을 막거나 검증해야 하는 작업은 CLI가 이긴다. 그리고 내 환경에서 제일 잘 굴러가는 구조는 둘 중 하나를 고르는 대신, CLI 훅이 MCP 사용을 강제하는 조합이었다. 누가 읽으면 좋은가 Claude Code나 Codex에 MCP 서버를 몇 개 붙였는데, 컨텍스트만 커지고 체감 이득이 없던 적이 있다. 에이전트가 cat과 grep으로 코드를 통째로 읽어대서, 토큰 사용량이 신경 쓰인 적이 있다. .env 노출 같은 사고를 막고 싶은데, MCP 서버를 잘 고르면 될 거라고 기대한 적이 있다. 셋 다 내가 직접 겪은 일이다. 같은 상황이라면 아래 기준을 그대로 가져다 써도 될 것 같다. 내 환경에서 두 방식이 놓이는 자리 MCP(Model Context Protocol)는 에이전트가 세션 안에서 도구를 함수처럼 호출하는 연결 방식이고, CLI는 에이전트가 셸에서 명령을 실행하는 방식이다. 아래 표의 훅은 그 실행 앞뒤에 끼어드는 검사 스크립트를 말한다. 내 환경에서 실제로 돌아가는 작업을 연결 방식별로 나누면 이렇다. 작업 연결 방식 이유 코드 구조 파악·검색 pluck (MCP) 반복 조회, 토큰 절감 브라우저 조작·검사 chrome-devtools (MCP) 세션 상태 유지 시크릿 노출 차단 secret-output-gu...

AI 코딩 에이전트는 .env를 읽는다 — OpenAI도 10개월째 못 막은 문제

이미지
AI 코딩 에이전트는 .env를 읽는다 — OpenAI도 10개월째 못 막은 문제 AI 코딩 에이전트한테 저장소를 통째로 맡기는 사람이 늘었다. 그런데 그 저장소 안에는 보통 .env 가 같이 들어 있다. 내 경우엔 시크릿이 새는 걸 막는 보안 훅이 오타 하나로 몇 달간 돌지 않고 있었다. 그동안 에이전트가 키 파일을 읽어도 걸러낼 장치가 없었다는 뜻이다. 결론부터 적으면, .gitignore 로는 에이전트한테 시크릿을 숨기지 못한다. 막아야 할 지점은 파일이 아니라 도구 호출이다. 이 글은 그 이유를 OpenAI Codex의 공개 이슈 하나로 짚고, 내 설정에서 .env 가 읽히는지 확인하는 법까지 정리한다. AI 코딩 에이전트 보안에서 가장 자주 새는 구멍이 여기다. 다음 중 하나라도 해당되나 .env 를 .gitignore 에 넣었으니 안전하다고 생각한 적이 있다. 에이전트한테 “이 디렉터리 전체를 분석해줘”라고 시켜 본 적이 있다. API 키나 토큰을 프로젝트 루트의 설정 파일에 그대로 둔 적이 있다. 셋 중 하나라도 해당되면 이 글이 짚는 위험에 노출돼 있다. 왜 그런지는 에이전트가 파일을 읽는 방식을 보면 바로 드러난다. 에이전트가 파일을 읽는 방식 깃과 에이전트는 파일을 보는 길이 다르다. .gitignore 는 git add 단계에서만 작동한다. 깃이 추적하지 않을 파일을 지정할 뿐이다. 반면 코딩 에이전트는 깃을 거치지 않는다. rg (ripgrep)나 grep , cat 같은 도구를 직접 호출해서 파일 시스템을 읽는다. 에이전트 입장에서 .env 는 그냥 텍스트 파일 하나일 뿐이고, 깃이 무시하든 말든 상관이 없다. 그래서 “민감 파일을 .gitignore 에 넣어 뒀으니 에이전트도 안 읽겠지”라는 가정이 깨진다. 에이전트가 코드 검색을 하다가 .env 안의 문자열이 검색어에 걸리면, 그 내용은 도구 출력으로 모델에 전달된다. 모델에 전달된다는 건 외부 서버로 전송된다는 뜻이다. 핵심은 차단 지점이다. 파일에...