글

처음 읽는다면

설정의 시작부터 막힌 문제, 도구에 드는 비용까지.

최근 보완: 2026-09-23 · 위 핵심 글 4편. 점검 순서와 관련 글을 보완했습니다. 실측·코드 분석·가정 계산은 구분해 표시합니다.

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

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

텔레그램 한 줄로 블로그 작업을 넘길 때 중복 실행을 막는 구조

이미지
답부터 말하면 텔레그램 메시지 ID를 요청 파일 이름과 처리 영수증의 공통 키로 써야 한다. 같은 메시지가 다시 들어와도 새 파일로 덮어쓰지 않고, 상태 파일이 있으면 에이전트에 다시 넣지 않는 구조다. 이 결론은 2026년 9월 28일 로컬 테스트 기준이다. 테스트 41개가 통과했고 실패는 0개였다. 다만 실제 텔레그램 사진 왕복과 장애 복구 시간은 아직 측정하지 않았다. 왜 명령 한 줄이 두 번 실행될 수 있나? 텔레그램에서 /blog 명령을 한 번 보냈다고 실행도 한 번이라고 볼 수 있을까. 수신 플러그인, 파일 감시, 에이전트 세션, 답장 전송 사이에는 각각 재시작과 재호출이 들어올 수 있다. 문제는 요청 내용이 아니라 경계다. 같은 업데이트를 플러그인이 다시 받거나, 파일 감시 이벤트가 반복되거나, 답장 전송 중 프로세스가 멈출 수 있다. 그래서 “이미 본 요청인가”를 각 단계가 같은 기준으로 판단해야 한다. 이 브리지는 메시지 본문 대신 텔레그램 메시지 ID를 기준으로 삼는다. 내용이 같은 두 요청은 서로 다른 작업일 수 있지만, ID가 같은 요청은 같은 전달 건이기 때문이다. 요청 파일은 어떻게 한 번만 만들어지나? 수신 단계는 먼저 임시 파일에 요청 전체를 쓴다. 파일을 동기화하고 닫은 뒤, requests/<메시지ID>.json 이라는 최종 이름에 배타적으로 연결한다. 최종 파일이 이미 있으면 덮어쓰지 않는다. 기존 파일 자체가 중복 수신 영수증이 된다. 소비자는 완성된 이름만 보므로 절반만 써진 JSON을 집어 들지 않는다. 임시 파일에 요청 전체를 기록한다. 파일 동기화와 닫기를 끝낸다. 메시지 ID 이름으로 배타적 링크를 만든다. 같은 이름이 있으면 기존 요청을 유지한다. 요청 파일은 처리 뒤에도 삭제하지 않는다. 2026년 9월 28일 테스트에는 같은 명령을 8개 동시에 넣어도 최종 요청 파일이 하나만 남는 검사가 있다. 파일 감시자가 처음 본 시점에 JSON 전체를 읽을 수 있는지도 별도로 확인한다...

AI 서브에이전트로 글 한 편에 95만~117만 토큰: 제작과 검수를 따로 재야 한다

이미지
답부터 말하면 2026년 9월 13일 세 편의 운영 기록에서 deep 서브에이전트 제작은 편당 95만~117만 토큰, 11~15분으로 보고됐다. 같은 기록의 짧은 이미지 교차 검수는 편당 3.5만~5만 토큰, 약 1분이었다. 다만 이 숫자는 원시 사용량 내역이나 청구서가 아니다. 당시 작업을 마친 뒤 남긴 운영 보고값이다. 그래서 달러 비용으로 바꾸지 않고, 어떤 역할에 토큰이 몰렸는지만 본다. 글 한 편에 왜 100만 토큰 가까이 들었나? 이때 말한 ‘글 한 편’은 본문만 쓰는 호출이 아니었다. 1차 출처를 찾고, 계산과 표를 확인하고, 이미지와 렌더러를 만들고, 검증 자료까지 남기는 묶음 작업이었다. 여기서 deep은 조사와 검증까지 길게 맡기는 서브에이전트 작업 범주이고, 리드는 작업을 나눠 주고 결과를 검증하는 메인 에이전트다. 운영 보고에는 9월 13일 세 편이 각각 95만~117만 토큰을 썼다고 적혀 있다. 걸린 시간은 11~15분이었다. 9월 14일 정리한 결정 기록에는 deep 제작 비용이 편당 70만~184만 토큰으로 적혀 있다. 두 범위가 왜 다른지는 확인하지 못했다. 결정 기록에는 어떤 글 몇 편을 셌는지 적혀 있지 않다. 그래서 제목에는 같은 날 만든 세 편의 범위만 쓰고, 70만~184만은 작업마다 폭이 컸다는 보조 기록으로만 본다. 많이 쓴 만큼 무엇이 남았나? 같은 운영 기록은 9월 13일 deep 제작 세 편과, 9월 14일 리드가 서브에이전트 없이 직접 쓴 세 편의 산출물을 비교했다. deep 글은 본문 1,737~1,887자, 출처 링크 2~5개였다. 리드 작성 글은 767~908자, 출처 링크 1개였다. deep 쪽에는 evidence.md가 있었고, 예금·적금 글은 원본 HTML 9개도 보관했다. 리드 작성 쪽에는 근거 문서와 원문 아카이브가 없었다. 그래서 토큰 차이가 문장 길이만의 차이는 아니었다고 본다. 2026-09-13 deep 제작과 2026-09-14 리드 직접 작성의 당시 비교 항목 de...

네이버 SmartEditor 붙여넣기: 성공 이벤트보다 본문 일치가 먼저다

이미지
답부터 말하면 붙여넣기 이벤트가 받아들여졌는지가 아니라, 편집기 본문이 넣으려던 전체 글과 같아졌는지를 완료 조건으로 삼아야 한다. 이벤트를 보내기 전에 변경 감시를 시작하고, 제한 시간 안에 정규화한 누적 본문이 정확히 일치할 때만 다음 단계로 넘어가는 방식이다. 2026년 9월 27일 한 번의 SmartEditor 자동화 기록에서 첫 구간은 48ms, 두 번째 구간은 239ms 뒤 반영됐다. 이후 다시 연 예약 글에서는 원고·주입 대상·편집기 본문이 각각 2800자로 일치했다. 그 예약은 이 실행이 아니라 동시에 돌던 다른 작업이 저장한 것이다. 48ms와 239ms는 속도 기준이나 성공률이 아니라 한 실행의 관찰값이다. 왜 paste 이벤트 성공만으로는 부족했나? 조사 중 합성 paste 이벤트는 defaultPrevented:true 를 반환했다. 그런데 직후 본문은 여전히 한 문단이었고, 조금 뒤에는 시험용 두 문단이 들어와 있었다. 문제는 이벤트 수락과 화면 반영이 같은 순간이 아니라는 점이다. dispatchEvent() 반환값, iframe 포커스, 즉시 읽은 문단 수는 모두 완료 조건이 아니었다. 선택 영역이 iframe 루트에 잡힌 관찰도 과거 60초 지연의 원인으로 확정할 수 없었다. 그렇다면 무엇을 기다려야 할까. 편집기가 실제로 만들어 낸 최종 상태를 기다려야 한다. 고정 sleep 대신 무엇을 기다렸나? 성공한 경로는 MutationObserver 를 붙여넣기 전에 등록했다. 그 다음 clipboard 이벤트를 보낸 뒤, 공백과 제로폭 문자를 정규화한 전체 본문을 매 변경마다 비교했다. 아래는 실제 코드를 줄인 형태다. const done = new Promise((resolve, reject) => { const timer = setTimeout(() => { observer.disconnect(); reject(new Error("paste timeout")); ...

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 조회). 독자의 계정에 로그인하거나 유료 작업을 실행한 검증은 아니다. 내 비용을 비교할 기록 양식 같은 기간에 작업과 완료 조건 / 모델 / 인증 방식 / 일반 입력·캐시 쓰기·캐시 읽기·출력 토큰 / 추가 사용료 / 한도에 막힌 시점 / ...