글

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

모델별 프롬프트, 따로 쓸 필요 없다? omo를 뜯어보고 내린 결론

2026-10-13 dev 브랜치 기준(커밋 origin/dev b78527c )으로 omo 의 프롬프트 구성을 검토했습니다. 저장소에 실제로 분리된 프롬프트 파일이 존재하는지와 그 분리가 실제 런타임에서 어떤 성능 차이를 내는지는 구분하여 살펴보아야 합니다. 분리의 존재와 효과의 차이 omo 의 코드베이스에는 모델별 전용 프롬프트 파일이 실제로 나뉘어 있습니다. 공통 뼈대를 유지하면서도 모델별 보정 지시가 별도의 Markdown 파일로 관리됩니다. 다만 파일이 분리되어 있다는 사실 자체가 프롬프트 분리의 실질적인 효과를 입증하지는 않습니다. 파일 안에 적힌 내용은 모델에 내리는 지시문일 뿐이며, 그 지시가 모델의 행동 변화나 성능 향상으로 이어졌는지는 런타임 결과로 측정해야 합니다. 이번 검증 범위에서는 모델 변형별 A/B 테스트 결과나 런타임 성능 측정치를 확인하지 못했습니다. Atlas 파일 여덟 개의 비교 Atlas 영역에는 총 8개의 Markdown 프롬프트 파일이 존재합니다. atlas-prompts.ts 파일은 각 모델 변형을 이 파일들에 연결하는 라우팅 역할을 담당합니다. 라우팅 대상 중 swe-2 항목은 kimi-k3.md 파일을 재사용하므로, 라우팅 항목의 개수와 실제 물리적 파일 수는 다릅니다. 8개 파일의 줄 수는 다음과 같습니다. 파일명 줄 수 gemini.md 526줄 default.md 496줄 opus-4-7.md 494줄 kimi.md 478줄 gpt.md 461줄 glm.md 402줄 kimi-k2-7.md 326줄 kimi-k3.md 326줄 파일의 줄 수나 파일 개수의 차이만으로 프롬프트의 품질이나 실행 효과의 우열을 판단할 수는 없습니다. 저장소의 커밋 활동 이력 또한 이번 검증 대상에 포함되지 않았습니다. 모델별로 적힌 보정 방향 각 파일에 담긴 프롬프트 지시는 모델별로 보정 의도를 보입니다. gemini.md 파...

omo Claude 프롬프트, Opus 4.7에만 따로 붙는 이유

2026-10-13 dev 브랜치 기준(커밋 origin/dev b78527c )으로 코드베이스를 확인했습니다. omo 프롬프트 체계에서 Claude 전용 파일이 어떻게 배치되어 있는지, 실제 코드 구성과 라우팅 로직을 바탕으로 살펴봅니다. 제목의 범위는 Atlas 제목에서 언급된 'Opus 4.7에만'이라는 범위는 omo 전체 Claude 프롬프트가 아니라 Atlas 에이전트의 파일에 한정된 내용입니다. Atlas의 마크다운 프롬프트 파일은 총 8개입니다. default.md , gpt.md , gemini.md , glm.md , kimi.md , kimi-k2-7.md , kimi-k3.md , opus-4-7.md 로 구성되어 있습니다. 이 중 Claude 전용 파일은 opus-4-7.md 하나입니다. 여기서 파일 수와 라우팅 키 수는 구분해야 합니다. atlas-prompts.ts 의 swe-2 항목은 새로운 파일 대신 kimi-k3.md 를 재사용하기 때문입니다. Atlas의 파일과 Opus 매처 Atlas 에이전트의 getAtlasPromptSource() 는 resolveVariant() 에 atlasPromptVariants 를 전달하여 모델에 적합한 프롬프트를 결정합니다. 이 과정에서 variant-resolver.ts 는 opus-4-7 변형을 isClaudeOpus47Model 에 연결합니다. 해당 판별을 담당하는 detector는 model-family-detectors.ts 에 위치합니다. 지정된 모델이 Opus 4.7 모델 계열에 해당하면 전용 변형인 opus-4-7.md 가 연결되며, 그 외 매칭 변형이 없는 모델은 default.md 를 사용합니다. Opus 파일의 두 보정 지시 분량 면에서 Atlas opus-4-7.md 는 494줄, default.md 는 496줄로 큰 차이가 나지 않습니다. opus-4-7.md 에는 <opus_47_counter_defaults> ...

협박 vs 계약, omo GPT 프롬프트가 고른 쪽

2026-10-13 dev 브랜치 기준(commit b78527c ) 코드베이스를 바탕으로 omo의 GPT 프롬프트 구성 방식을 살펴봅니다. 모델을 강하게 압박하는 경고문 대신 명확한 제약과 작업 범위를 사전에 정의하는 서술 구조가 사용됩니다. 본문에서 언급하는 계약은 법적 성격의 계약이 아니며, 프롬프트 파일에 명시된 동작 조건과 처리 규칙을 설명하는 표현입니다. 경고 대신 범위와 조건을 명시하는 방식 Ultrawork GPT의 gpt.md 에는 <output_verbosity_spec> , <scope_constraints> , <uncertainty_handling> 블록이 선언되어 있습니다. 각 블록은 기본 출력 길이, 작업 범위 제한, 불확실성이 발생했을 때의 처리 기준을 명시합니다. 이 방식은 모호한 주의를 주는 대신 프롬프트 자체에 동작 경계를 직접 부여합니다. 다만 파일에 적힌 프롬프트 지시와 시스템이 실제로 작동할 때 나타나는 관측된 효과는 명확히 구분해야 합니다. 프롬프트에 조건이 작성되어 있다는 사실이 실제 모델 동작의 품질을 직접 대변하지는 않습니다. Atlas의 불변식과 정지 조건 Atlas GPT의 gpt.md 에 위치한 <gpt_family_calibration> 블록은 4가지 불변식을 규정합니다. 독립 작업 병렬화 위임 뒤 검증 검증 뒤 체크박스 갱신 실패한 동일 세션 재개 작업의 정지 조건으로는 최상위 체크박스가 모두 - [x] 로 채워지고, Final Wave reviewer 전원이 APPROVE 판정을 완료하는 상황을 요구합니다. 이는 해당 Atlas 프롬프트 내부에 명시된 완료 기준이며, omo 전체 실행을 아우르는 전역 정지 조건이 아닙니다. 현재 줄 수와 백그라운드 위임 각 모델 변형 프롬프트 파일의 줄 수를 확인하면 다음과 같습니다. Ultrawork gpt.md : 192줄 Ultrawork default.md :...

"일단 구현부터" 하는 Gemini, 프롬프트로 고칠 수 있을까

이미지
2026-10-13 dev 브랜치 기준( origin/dev b78527c ) 코드베이스를 살펴보면, Atlas 와 Ultrawork 에 각각 gemini.md 전용 프롬프트 파일이 존재합니다. Atlas Gemini 와 Ultrawork Gemini 는 Gemini 모델을 다루기 위한 행동 지침을 담고 있습니다. 프롬프트가 명명한 두 실패 모드 두 프롬프트는 Gemini 모델이 나타낼 수 있는 특정한 행동 양식을 실패 모드로 명명하고 이를 통제하도록 지시합니다. 하나는 도구를 호출하지 않고 상태를 안다고 넘겨짚는 태도이며, 다른 하나는 작업 의도를 나누지 않고 곧바로 구현에 뛰어드는 성향입니다. 이 두 지시는 적용되는 단계가 명확히 다릅니다. Ultrawork Gemini 의 의도 분류는 작업 착수 전에 진행되며, Atlas Gemini 의 도구 호출 요구는 조사와 검증이라는 실제 행동 단계에서 적용됩니다. 다만 이러한 프롬프트 지시문이 존재한다는 점을 Gemini 모델 일반의 실증된 결함으로 확대하여 해석해서는 안 됩니다. 도구 호출을 요구하는 Atlas Atlas Gemini 에는 <TOOL_CALL_MANDATE> 블록이 정의되어 있으며, 그 내부에 YOUR FAILURE MODE 라는 제목의 지시문이 포함되어 있습니다. 이 블록은 실제 도구 호출 없이 파일 내용, 작업 상태, 검증 결과를 안다고 가정하는 상태 자체를 실패 모드로 규정합니다. 해당 지침에 따르면 도구 호출이 없는 응답은 실패로 취급됩니다. 또한 병렬 작업 수에 맞추어 task() 를 호출하도록 정한 규칙도 포함되어 있습니다. 이는 추측에 기반한 답변을 배제하고 도구 실행을 통해 상태를 확인하도록 요구하는 프롬프트 지시입니다. 착수 전에 의도를 나누는 Ultrawork Ultrawork Gemini 는 착수 단계에서 <GEMINI_INTENT_GATE> 블록을 제시합니다. 모델이 도구 호출이나 파일 탐색을 시작하기 전에 사용자의 요청을 여섯...