매일 기록한 AI 기록

Claude 호출이 실패하면 요금제부터 올리고 싶어진다. 그 전에 실패가 정말 모델 사용량 문제인지, 내 컴퓨터의 하네스가 쥐고 있는 인증 슬롯이 모두 막힌 것인지 먼저 확인해야 한다. 2026년 9월 15일과 16일, Claude를 쓰는 에이전트 하네스 omo에서 겪은 실패는 로컬 인증 슬롯 단계에서 먼저 드러났다. 15일에는 두 슬롯이 모두 rate-limit로 차단돼 있었고, 16일에는 한 슬롯이 응답하는데도 여러 세션이 슬롯을 나눠 잡아 추가 요청이 막혔다. 이 글은 여러 세션에서 Claude를 돌리다 호출이 막힌 개발자를 위한 확인 순서다. 목표는 결제 여부를 판단하기 전에 오류 문자열, 로컬 슬롯 상태, 실패·성공 시각, 동시 호출 수를 차례로 보고 다음 행동을 고르는 것이다. 먼저 범위를 밝힌다. 아래 오류는 omo 런타임의 인증 슬롯 장애 조치에서 나온 것이다. Claude Code 공식 /usage 화면이나 공식 한도 안내와 같은 오류가 아니고, 9월 기록의 일회성 사례다. 지금 모든 계정에서 같은 일이 생긴다는 뜻도 아니다. 무슨 일이 있었나 2026년 9월 15일, 텔레그램으로 보낸 요청 세 건이 작업 세션에 정상적으로 들어갔다. 그런데 회신은 세 건 모두 요청 처리가 끝났지만 최종 답변을 확인하지 못했습니다 였다. 처음에는 텔레그램 연결 문제처럼 보였다. 같은 시각의 인증 상태를 보니 원인은 다른 곳에 있었다. omo의 credential pool에서 Claude용 claude-sdk-oauth 슬롯 두 개가 모두 rate-limit 상태였다. default 슬롯은 15:42:46 KST까지 차단돼 있었고 failureCount는 5였다. account-2 슬롯은 15:31:28까지 차단, failureCount 3이었다. 런타임(Senpi)의 장애 조치 함수 runCredentialFailover 는 사용할 수 있는 후보 슬롯이 0개면 No credential slots available 을 던진다. 결국 그 폴백 문구...

PTY 기반 에이전트 세션에서 브라우저 자동화 CLI의 aside repl 을 장기 실행한 뒤 응답이 끊긴다면, REPL을 더 만지기 전에 출력 경로부터 확인해야 한다. 2026년 10월 12~13일 운영 기록에는 REPL을 띄운 지 1분 안에 세션이 세 번 멈췄고, 메인 스레드가 write(2) 에서 기다렸다고 남아 있다. 우회는 장기 REPL을 메인 세션 PTY에서 빼고 단발 실행이나 PTY 밖 FIFO 입력으로 돌리는 것이고, 커널 수준의 원인은 증명하지 못했다. 살아 있는 프로세스가 답하지 않았다 터미널 화면과 텔레그램 응답이 함께 멈췄다. 운영 메모에는 세 번 모두 메인 세션에서 REPL을 띄운 뒤 1분 안에 같은 정지가 나타났다고 적혀 있다. 한 번의 긴 작업이 아니라, 같은 실행 방식 뒤에 반복된 정지였다. 이 세션은 감시기(supervisor)가 띄운 PTY 안에서 돈다. 감시기가 PTY 출력을 계속 읽어 pty.log 에 남겨야 세션이 다음 출력을 쓸 수 있다. 그 pty.log 가 더 이상 진행하지 않았다. sample 로 본 메인 스레드는 쓰기 대기 상태였고, 감시기 쪽 PTY에는 읽을 출력이 없었다. REPL을 종료해도 응답이 돌아오지 않아 세션을 재시작해야 했다. 이 세 가지는 서로 다른 관찰이다. 로그 정지는 출력이 진행하지 않는다는 신호이고, 스택은 어느 호출에서 기다리는지를 보여 준다. REPL 종료 뒤에도 풀리지 않았다는 사실은 자식 프로세스 하나를 끄는 것으로 복구되지 않았다는 뜻이다. 처음에는 감시기를 잘못 의심했다 이틀 동안 정지는 네 번이었다. 그중 세 번이 aside repl 을 띄운 지 1분 안에 일어났고, 처음에는 이 연관을 보지 못했다. 첫 가설은 감시기가 빈 읽기를 한 번 만나면 출력 감시를 끊는다는 것이었다. 빈 읽기 뒤에도 감시를 다시 걸고, 그때마다 pty_eof 기록을 남기도록 고쳤다. 다음 정지 때 이 기록은 한 번도 남지 않았다. 두 번째 가설은 kqueue 가 "읽을 출력이 ...

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 파...

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> ...

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 :...

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> 블록을 제시합니다. 모델이 도구 호출이나 파일 탐색을 시작하기 전에 사용자의 요청을 여섯...