자율형 앱 운영 — AI가 어디까지 실행하고, 어디서 인간이 결정하는가

1. 1일의 사이클

정시에 시작하고, 다음 순서대로 회전합니다. 사람이 매번 지시를 내리는 출발점은 없습니다.

1. 관측검색 쿼리의 움직임·사이트 실화·실행 장부·비용·자격 정보의 기한을 읽습니다. 전날까지 해결되지 않은 버그가 있다면, 그곳에서 해결하십시오.
2. 기안그날에 할 일을 1건만 선택합니다. 절차서가 “1 세션 1 액션”이라고 정하고 있기 때문에, 한 번에 여러 개를 내보내지 않습니다.
3. 구현브랜치를 잘라 변경하고, PR을 발행합니다. 코드·기사·설정 중 어느 것이든 경로는 동일합니다.
4. 검증CI가 83종의 검사를 진행합니다(전체 83개에 대해 “고의로 부수면 떨어진다”는 것을 실측했습니다). 통하지 않는 한 병합되지 않습니다. 과장 표현의 검사와 대장의 산수 검사도 여기 포함됩니다.
5. 출하검증을 통과한 시점의 커밋만 병합됩니다. 병합=본격 공개. 하지만 이는 사이트 측에만 해당되고, iOS 앱은 별도 경로(§2)입니다.
6. 계측출하된 물품을 실행 ID로 대장에 1 행을 씁니다. 착수·결과·PR·중재·비용이 같은 행에 실립니다.
7. 다음 판단으로 돌아갑니다실패한 회는 실패 유형별로 기록하고, 다음 날 이후의 초안이 그것을 읽습니다. 대장이 기록되지 않은 회차를 감지하는 검사도 나중에 추가하고 있습니다(§7).

2. 담당 분담 — 즉시 제출할 수 있는 것과 심사를 통과하는 것

이 2을 1의 “자동 배포”로 설명하면 실제보다 더 강하게 들립니다. 나누어 씁니다.

Lane B의 실측（2026-08-11〜10-09・앱 본체의 장부）。 태그가 지정된 버전은 85이며, 그 중 App Store에 나열된 버전은 17（5.7.6 / 5.7.8 / 5.7.11 / 5.8.0 / 5.8.1 / 5.8.2 / 5.8.4 / 5.8.5 / 5.8.9 / 5.8.17 / 5.8.26 / 5.8.46 / 5.8.54 / 5.8.57 / 5.8.66 / 5.9.9 / 5.9.11）。 실기 확인 기록이 있는 버전은 5(기록 장부가 2026-08-28으로 시작되었기 때문에, 그 이전 버전은 기록이 없다고만 말할 수 있습니다. 확인 방법은 각 버전의 기록에 명시되어 있습니다. 기록이 있다는 사실만으로 자율적인 실제 기기 검증을 입증할 수는 없습니다). 대장에 저장된 상태의 관측으로부터, 공개 시각의 범위를 확인할 수 있는 버전은 6입니다. 각 버전의 코드 차이는 커밋에서 20.2%, 변경 행에서 8.2%가 AI 저자입니다(계산 방법은 §3의 코드 저자 비율과 동일합니다). 서명·트레일러·Claude Code의 흔적이 전혀 없는 커밋은 사람 측에 포함되므로, 손에 있는 환경에서 소유자의 서명으로 넣은 변경은 여기 나오지 않습니다. 공개 상태의 관측만으로는 실기 확인·심사 제출·공개를 AI가 실행했다는 증거가 되지 않습니다. 위의 §1의 “출하”에 이 17 버전은 포함되어 있지 않습니다.

권한표에는 19개 영역이 있으며, 그중 15개가 가동 중이고 10개가 승인제입니다. 되돌릴 수 있는 작업은 AI가 단독으로 실행하고, 되돌릴 수 없는 작업은 승인을 거칩니다. CI가 확인하는 것은 ‘되돌릴 수 없는 영역이 승인 불필요로 바뀌지 않았는지’, ‘가동 중인 영역이 근거 파일을 가리키는지’, ‘금액이 변하는 영역에 상한이 있는지’라는 3가지뿐이며, 실제로 사람이 승인했는지는 기계가 확인할 수 없습니다. 그 내용은 표에 적혀 있습니다.

같은 기능의 “넣기”와 “넓히기”를 별도의 영역으로 구분해 두었습니다. 펼쳐서 다시 돌려도, 본 사람이 보지 않은 것으로 변하지 않기 때문입니다. 단, 이 문을 통해 실행된 승격은 아직 1건도 없습니다. 단계 공개 중인 플래그는 1개(tf04_progress)이며, 가드는 매시간 판정을 내리고 있지만 판정에 필요한 모수(각 그룹 30)에 도달하지 못해 hold 상태 그대로입니다(2026-08-27의 실측 run 33076125334). 「확대」의 행은 2026-09-02에 「인간의 승인」에서 다시 작성했습니다. 자동 승급은 2026-08-28에 소유자가 활성화되어 있으며(rollout-promotion.json의 auto_promote.enabled), 권한표에서는 노출 50%까지가 기계 게이트가 포함된 AI 실행입니다. 페이지만이 오래된 작성 방식 그대로이며, 실제보다 인력이 더 많은 것처럼 읽을 수 있는 상태였습니다. 과소신고도 엇갈립니다 —— 옆에 놓은 권한표를 열면 다른 내용이 적혀 있다는 형태가 동일해서 수정했습니다.

3. 실제 측정 — 몇 번 움직였는지, 몇 번 사람이 들어왔는지

인간 개입률 25.0%를 그대로 표시합니다. 4회에 1회 실행에 사람이 들어 있습니다. 다만 이 숫자는 “그 실행에 사람이 1을 한 번이라도 만졌는가”를 세어낸 것이며, 워크플로우 설정을 1 행만 수정한 날도 전체가 개입됩니다. 그곳에서 개입을 종류별로 구분하고 있습니다.

출하된 19건은 모두 AI가 작성하고 있습니다. 실질적인 개입은 “기반 수리” 14.3%의 한 점에 있으며, 그 수리를 작성한 것도 AI였습니다. 인간이 한 일은 부서진 것을 알아차리고 고치라고 말하는 것입니다.

경로별로는 주 시스템 5/12·보조 시스템(대행) 14/16입니다. 주 시스템은 정시 실행 워크플로로, 8월 23일에 처음 출하했고 이후에도 결과물이 없거나 주간 사용 한도로 실패한 실행이 있습니다. 보조 시스템도 2회 실패했습니다. 이중화하지 않았다면 멈췄을 날이 여러 번 있었습니다. 미가동일은 2일(8월 16일·17일)입니다. ‘연속 가동’은 실행 결과 기록이 이어진 일수입니다. 사전 판정으로 건너뛴 경우와 실패도 포함합니다. 미가동(no_run)과 대장에 기록이 없는 날은 연속을 끊으며, 출하 여부는 ‘연속 출하’로 별도 집계합니다. 이 정의에 따른 현재 연속 가동은 59일이고, 최장 기록도 59일(2026년 8월 18일~2026년 10월 15일)입니다. ‘현재’는 대장의 마지막 기재일(2026년 10월 15일)을 기준으로 합니다. 가동의 정의상 실패했더라도 행이 기록된 날은 ‘기록이 있는 날’이므로 연속이 끊어지지 않습니다. 현재 연속 출하는 0일이며, 최장 연속 출하는 8일(2026년 9월 1일~2026년 9월 8일)입니다. 10월 1일의 복구 기록은 소유자 요청에 따른 유지보수입니다. 9월 20일과 10월 1일의 결과물 없는 실행을 기록하고 기존 원인 수정을 검증해 복구 기록을 연결했습니다. 정기 실행의 공개 성공이나 무개입 출하로는 세지 않습니다. 9월 16일·17일의 회수 기록도 소유자 요청 유지보수이며, 정기 실행·무개입 출하·기사 공개가 아닙니다. 9월 17일에는 페이지 내부 이동 수정 1건이 검증되었고, 포스터 시도와 롤백은 속도 기준을 충족하지 못한 1회의 주기였습니다. 받지 못한 작업 결과는 알 수 없으며, 간헐적인 렌더링 지연은 미해결 상태입니다. 9월 9일에는 사전 판정으로 중복 실행을 피한 기록만 있고, 구현에 착수하거나 출하하지 않았습니다. 이날도 위 연속 가동 일수에 포함됩니다. 9월 10일에는 점유 후 검증 환경 부족으로 중단된 1건과, 중복 방지로 종료된 별도 실행 1건을 기록했습니다. 둘 다 출하로 세지 않았습니다. 8월 30일·31일에는 주 시스템과 보조 시스템 모두 같은 주간 사용 한도로 실패하여 어느 쪽도 출하하지 못했습니다.

코드에는 별도의 지표가 있습니다. 3개 저장소·모든 브랜치·병합 제외·2026-08-11~08-21 범위에서 커밋의 99.5%(194건 중 193건), 변경된 줄의 94.2%(48,976줄 중 46,159줄)는 AI가 작성자입니다(2026-08-22 집계). 측정 당일은 집계 기간에 포함하지 않았습니다(비율이 높아지는 방향으로 작용하기 때문입니다. 8월 22일을 포함하면 94.2%→96.6%). 건수는 나중에 다시 세면 일치하지 않습니다. 모든 브랜치를 대상으로 하므로 squash 후 사라진 브랜치는 나중에 셀 수 없습니다. 같은 기간을 2026-08-26에 다시 세었을 때 194 → 164커밋(30건 감소)이 되었습니다. 비율은 달라지지 않습니다(99.5% → 99.4%, 변경된 줄의 94.2%는 동일). 다만 절대 건수를 인용할 때는 위 집계일과 함께 다뤄 주세요.

4. 자동화율 — 월별 추이와 영역별 내역

자율도는 12.5%→85.4%입니다. 2026년 6월부터 9월까지의 4개월분입니다. 같은 192 작업을 분모에 고정하고 계산하고 있습니다. 코드 변경의 AI 저자율은 업무 실행률과는 별개의 지표입니다. 월별로 변동하며, 9월은 중간 집계입니다. 월별 값은 자율도 추이의 code_ai_commit_rate / code_ai_line_rate에 기록되어 있습니다. 각 월의 실행 건수는 코드를 작성하는 것 이외의 작업(시책을 선택·검증·기록·멈춤)의 이전을 포함합니다. 9월 13일의 분모 변경에 따른 수치 변화는 실행 건수 증가와 별도로 기록하고 있습니다.

⚠ 실측은 2026년 8월과 9월 중간까지입니다. 그 이전은 재구성한 것으로, 당시 이 지표를 측정한 것은 아닙니다. ‘AI가 실행하는 작업의 증빙 파일이 처음 커밋된 달’을 해당 공정의 가동 시작 월로 보고 누적하는 방식입니다. 증빙 추가일과 실제 가동일은 며칠에서 몇 주까지 차이가 납니다. 분모 역시 현재의 목록(192개 작업)을 과거에도 고정 적용한 것이며, 당시에는 ‘해야 할 일 목록’ 자체가 없었습니다. 당시의 ‘제안에 그침’, ‘사람이 실행’, ‘미착수’ 세부 내역은 복원하지 않았으므로, 이 시계열로 나타낼 수 있는 것은 전체 자동화율뿐입니다. AI 관여율과 커버율의 추이는 만들 수 없습니다. 원본 데이터는 자율성 추이에 그대로 있으며, 한계 목록도 같은 파일의 known_limits에 들어 있습니다.

203 작업·13 영역을 1건씩 재고 조사하여, 누가 실행하느냐에 따라 계산한 것입니다. 종합 자동화율 85.4%, AI 실행률 91.1%, AI 관여율 95.0%, 커버율 93.8%（2026-09-15）。 미시작도 포함한 내역을 공개하고 있습니다. 9월 15일, 기존 CPP 업무를 동일 기간의 최초 다운로드·페이지 열람·비교 대상·동시 시책의 실측에 기반하여 AI 실행에 반영했습니다. AI 실행 164/180, 종합 164/192입니다. 평가는 서술적인 것이며, 획득 향상 및 인과 효과는 아직 확정되지 않았습니다. 164건 중 환불 감지·과금 복구·장애 안내의 3건은 소유자가 지정한 “테스트에서의 운영 준비 완료+본판 자동 감시”로 계상하고 있습니다. 본판의 최초 환불·과금 복구·장애 안내는 아직 관측되지 않았습니다. 9월 13일의 조건 변경 시점 기록: 변경 전의 실례 필수 기준: 159/176=90.34%. 과금 복구 준비 변경 직전：161/177=90.96%。 과금 회복 준비 후에는 162/178=91.01%. 장애 안내 준비 변경 직전：162/178=91.01%. 그 시점의 준비가 완료되면 163/179=91.06%, 약 +0.050 포인트. 당시 이 3건을 실례 필수 항목으로 제외한 참고값은 160/176=90.91%입니다. 테스트 범위·채점 조건 변경와환불 준비 증거、과금 복구 준비 증거와검증 범위、장애 안내 준비 증거와검증 범위를 공개하고 있습니다. 실제 장애 안내나 모든 이용자에 대한 도달·통지 의무의 충족을 나타내는 것이 아닙니다. 9월9일, X일본어 게시물의 예약 작업 및 공개 결과를 대조하고, 기존 1 업무의 실행자를 업데이트했습니다. 같은 날, 회사 서비스 1건의 계약·청구·서비스 제공·지불을 대조하고, 선불 지속 및 세금 구분 예외를 기록한 1 업무를 추가했습니다. 9월 11일, iPhone과 Watch의 실기 확인 6 항목을 완료하고, 실기 확인 1 업무의 실행 결과를 반영했습니다. 9월 12일, 검증된 1342의 자율 제출이 Apple에 접수된 것을 확인하고, App Review 제출 1 업무를 반영했습니다. 심사 통과와 App Store 공개는 아직 가점이 되지 않았습니다. 같은 날, 본판 Act의 정지·복원 훈련을 완료하고, 훈련 1 업무를 반영했습니다. 전체 정지 메커니즘이나 앱 킬을 입증했다는 의미는 아닙니다. 9월 13일, 전사의 월간 예산을 수립하여 지출 판단에 적용하고, 공개 설정과 실제 사건 판정을 다시 읽었습니다. 월간 예산 1 업무를 반영하여 AI 실행 161/177이 되었습니다. 기존 부채의 정산 및 전체 결제의 자동 제어를 완료했다는 의미는 아닙니다. 2026-08-25에 재고조사에 13건을 추가했으므로, 비율이 61.3%에서 58.6%로 감소했습니다. 그 이후의 구현에서 66.8%까지 복원되었습니다(2026-09-02 시점·당시의 분모). 구현이 감소한 것이 아니라, 해야 할 일 목록이 정확해진 만큼 분모가 증가하고 있습니다（추가한 13건 중 10건이 미구현되었습니다）。 작업의 입자 크기가 영역 간에 일치하지 않으며, 전체 작업을 동등하게 계산하고 있는 점은 한계로 부록합니다.

9월13일, 먼저 채점 범위를 정리했습니다. 현재 사업에서 진행하지 않는 이벤트·채용·개별 상담 영업의 6건과 기존 방침으로 진행하지 않는 환불 의견 전송 1건을 대상에서 제외했습니다. 이 정리 시점에서는 AI 실행 159건은 변함이 없으며, 진행 중인 분모는 179건에서 176건으로, 전체 대상은 199건에서 192건으로 변경되었습니다. 기존 스코프(9월 13일 변경 전): 실행 159/179=88.8%, 종합 159/199=79.9%. 구분모 199건의 월간 시리즈도 원본 데이터에 저장하고 있습니다. 활동 조사·준비를 시작하는 시점 또는 실제 과제·기존 의무를 확인한 시점에, 쌍이 되는 AI 측과 인간 측을 동시에 대상에 되돌립니다. 7건의 이유와 4 지표의 비교를 공개하고 있습니다.

5. 자율 점수 — “자동화된 양”이 아니라 “검증된 결정의 양”

§4 의 자동화 비율은 작업 피복 비율입니다。「 '무엇을 자동화할 수 있었는지'는 말하지만, '그 결정이 옳았는지 확인하는 메커니즘이 있는지'는 한 마디도 하지 않습니다. 검증되지 않은 결정을 100% 자동화하면, 피복률은 100%가 됩니다. 그렇기에 2026-09-04에, 다른 물자를 병설했습니다. 전환이 아닙니다 — 한쪽이 늘어나고 다른 한쪽이 늘어나지 않는 것이 의미가 있기 때문에, 양쪽을 그대로 내겠습니다.

계산 방법은 “반증기(=그 판단을 내릴 수 있는 구조)가 어느 층까지인지”입니다. 운영 결정을 5 계층으로 나누고, 구현 검증에 더해, 적격성 판단·가치 계약 결제·성숙 후 탐색을 연결했습니다. 구현 완료와 운영 실적에 의한 실증을 구분하여 표시합니다.

자율 점수는 48.4점(100점 만점, 2026-10-15 시점)입니다. 검증된 결정 피복률은 사전에 고정된 계약이 공개 후 실제 측정으로 결제된 후에야 가점됩니다. 90점 초과는 목표이며, 실제 측정으로 도달할 때까지 달성이라고 표시하지 않습니다.

복구는 이상 감지부터 실제 상태 확인까지 확인합니다. 출하한 후에 악화된 것을 기계가 스스로 찾아 되돌릴 수 없는 한, 더 위험한 영역의 권한을 전달하는 것은 원칙적으로 불가능합니다. 자동으로 되감은 회차가 1회라도 나올 때까지, 권한은 확장하지 않는다——라는 순서를 그대로 정해 두었습니다.

멈춘 회를 “층”으로 구분했습니다. 지금까지는 실행 전에 잠든 회·실행하고 떨어진 회·틀이 소진된 회가 모두 같은 “실패”로 나열되어 있었기 때문에, “선택 방법을 잘못했는지, 만드는 방법을 잘못했는지”에 답변할 수 없었습니다. 답변하지 못한 것은 조사 방법의 문제가 아니라 기록이 같은 열에 있었기 때문입니다. 대장에 기록된 출하 외의 결과를 아래 층으로 구분하고 있습니다.

가장 많은 것은 적격성 층입니다. 그리고 그곳에는 2026-09-04까지 “비밀키가 있는지” 외의 판정이 없었습니다. 만든 것은 그 판정이며, 기존 운전에서는 판정을 기록하고, 되돌릴 수 없는 작업은 실행 전에 멈춥니다. 새로운 가치 계약은 전체 5 기준이 통과되지 않으면 생성할 수 없습니다.

2026-09-05, 실행 정보의 결측을 “미착”으로 잘못 기록한 1건을 모델의 착수 증거와 대조하여 수정했습니다. 원본 행과 확인 증거는 운전대장의 정정 이력에 남겨두고 있습니다. 산출물의 결과는 아직 확정되지 않았으며, 출하 및 복구에는 포함되지 않았습니다.

이 점수를 올리기 어렵게 만드는 장치도 함께 넣어 두었습니다. 검사를 완화하면 점수가 자동으로 상승하므로, 검사 횟수가 감소한 기간 동안은 점수를 그대로 유지합니다. 복구하기 쉬운 세밀한 업데이트를 대량 생산해도 늘어나지 않도록, 그 기여에 상한을 두고 있습니다. 실패율은 점수에 포함되지 않습니다——실패율을 낮추는 것 자체가 목적이 되면 검사를 완화하는 압력이 되기 때문입니다. 그리고이 수치는 매일 실행을 결정하는 AI에게 보여주지 않았습니다. 계기를 최적화 대상으로 하면, 계측기로서의 수명이 끝나기 때문입니다.

배점 자체(자율 점수의 배점)와 실행 전 판정 기준(적격성 게이트의 기준), 그리고가치 계약의 커버 정책은, AI가 수정할 수 없는 측에 놓여 있습니다. 자신의 점수 매기는 방법을 스스로 결정할 수 있는 장소를 만들지 않기 때문입니다. 피복 방침이 기록된 것은 편리한 사실이 아닙니다 —— 가치 계약의 구조를 2026년 9월 4일에 준비해 두었음에도 불구하고, 공개 레인의 출하 14건에 사전 등록된 예측이 1개도 첨부되지 않았습니다. 지금은 세기만 할 뿐이며, 출하를 중단하지 않았습니다. 판정 결과는 적격성 판정 대장에 있으며, 점수의 추이는 자율 점수 기록에 있습니다. 가치 계약 및 결제、성숙·탐색 기록、복구의 증거도 공개하고 있습니다. 복구 훈련은 실제 성공 횟수에 포함되지 않습니다.

가장 위의 성분(검증된 결정 피복률)을 움직이려면 먼저 “어떤 지표로 가치를 측정할지”를 결정해야 합니다. 그 지표의 허가 목록과 기준값도 같은 장소에 놓여 있습니다 — 2026-09-04에 대해 소유자가 출하일율·공개일율·미해결 고장 건수의 3 지표를 승인했습니다. 2026-09-05에 남아 있는 3 지표(고장 감지까지의 시간·1 출하당 실비·판정 사유가 기록되지 않은 기각 비율)도 승인했습니다. 승인은 지표별로 장부에 기록하며, 승인만으로는 점수가 증가하지 않습니다. 비교 기준은 각 지표의 최근 14일의 중앙값입니다. 앞으로의 일일 자율 정책에서는 착수 전 가치 계약이 필수가 되며, 공개 후에 선언한 기간의 실측을 모아 결제합니다. 승인만으로는 점수가 증가하지 않습니다. 새로운 지표를 만들 권한을 AI에게 넘기지 않은 이유는, 방치해도 움직이는 지표를 선택하면 예측이 맞는 것처럼 보이게 되기 때문입니다입니다.

6. AI에게 부여되지 않은 권한이 이유와 함께 적혀 있습니다

공개하고 싶은 것은 할 수 있는 일의 목록이 아니라 경계 쪽입니다. 앱의 릴리스 경로 자체는 자동화되어 있지만, 그 체인을 시작할 권한을 개발용 AI 워크플로에 부여하지 않습니다. 설정 파일에 이유가 이렇게 적혀 있습니다.

이 권한이 있으면, 확인을 요구하지 않는 설정의 AI가 출하 워크플로를 직접 호출하고,인간을 전혀 개입시키지 않고 App Store에 출하할 수 있게 됩니다。 이 기능에 필요한 핵심 용도는 없습니다 — 리포지토리의 읽기·커밋·푸시·PR 작성·댓글이 모두 권한 없이 작동합니다. 필요하게 되면, 이 권한을 확대하는 것이 아니라,용도를 제한한 다른 경로를 만들어 주세요。 워크플로우 설정 파일의 댓글에서

실기에서 확인한 후 제출하십시오. 뒤가 아니라 먼저. 릴리스 절차서의 인간용 하드 규칙에서

7. 실행 로그 발췌 — 잘 되지 않은 회차도 동일한 형식으로 남깁니다

대장은 1 실행 1 행입니다. 출하한 회차와 실패한 회차를 같은 열에 적습니다. 아래는 실물에서 발췌한 내용입니다.

run_id      : ap-20260823-actions
date_jst    : 2026-08-23
route       : actions          outcome : shipped
pr          : 538              artifact: /obsidian/pricing/
repair_of   : ap-20260822-actions
note        : 主系（GitHub Actions）の初出荷。導入から12回目の定時起動で
              初めて成果物が出た。06:18→06:36 JST（約18分）。過去11回は
              10〜90秒で終わっており、所要時間そのものが「回ったが何も
              していない」との違いを示す。
              この行は主系自身が書いていない。出荷したのに台帳が
              0件のままだったのはこのため。

run_id      : ap-20260825-actions
date_jst    : 2026-08-25
route       : actions          outcome : failed
failure_class: auth_or_credential
detected_by : 副系のフォールバックが実行履歴を遡って発見
note        : 台帳に記録が無かった。成果物ゼロで落ちた回は
              「台帳を書く主体がいない」という構造的な穴がある。

이 2개 행이 나란히 있는 것 자체가 현재의 위치입니다. 첫 출하는 이루어졌지만, 대장을 작성할 주체가 실패한 실행에는 기록이 없다는 공백이 남아 있습니다. 9월 2일 기준 미해결 실패는 7건(8월 27일~31일, 그중 3건은 주간 사용 한도)이며, 대장에 그대로 기재되어 있습니다. 탐지까지 중앙값은 13.4시간, 최댓값은 70.8시간입니다. 복구까지 중앙값은 6.7시간입니다. 탐지는 8월 말보다 느려졌습니다(주 시스템이 3일 연속 ‘브랜치가 존재한다’는 이유만으로 건너뛰었고, 이를 8월 31일에 한꺼번에 발견했기 때문입니다).

8. 할 수 없는 것

이 기반은 “전체 영역이 자동으로 종료되는” 상태가 아닙니다. 절차서와 보고서에 적힌 것을 그대로 배열합니다.

「완전 자동화할 수 있었다」라고는 쓰지 않습니다. 말할 수 있는 것은 AI가 일상적인 운영을 지속적으로 실행할 수 있는 구조로 만든 것과 자동화가 멈췄을 때 알아차리는 형태로 만든 2입니다.

9. 홍보 원고도 같은 자로 채점하고 있습니다

과거 5개의 보도자료 실적으로 채점식을 보정하고 있습니다. n=5의 보정이며, 외삽의 근거가 되지 않습니다.

가장 침체된 것은 고유명사가 1도 들어가지 않은 회였습니다. 배포 원고에는 과장된 표현이 나오면 CI가 떨어뜨리는 검사를 포함해 두었습니다.

10. 살아 있는 대장

이 페이지의 숫자 출처입니다. 업데이트 여부도 포함하여 그대로 볼 수 있습니다.

관측 가능한 실제 비용은 $50.8681（10 실행분·2026-09-02 시점）입니다. 부계 16 실행분은 스케줄 시작 세션의 로그를 외부에서 읽을 수 없기 때문에 제로가 아니라 미관측입니다. 월별 상한 $40는 임시값이며, 실제 측정에 기인한 것이 아닙니다.

이 금액은 2026년 8월 25일에 나중에 다시 입력한 것입니다. 직전까지 대장은 $0.8149(1 실행분)이라고 표시되어 있었습니다. 8월 23일의 출하 1회분 $7.2967이 전부 누락되었기 때문입니다. 빠진 이유는 오타가 아니라 구조 때문입니다. 실행의 마지막에 금액을 출력하는 메커니즘이 있지만, 이를 장부에 기록하는 주체는 다음 날의 실행이며, 그 다음 날이 §7의 실패로 멈췄습니다. 기록이 가장 필요한 회차에 기록이 떨어집니다.

이 구멍은 막혔습니다. 매일 아침 9에 동작하는 다른 실행이 실행 기록을 직접 읽고 장부에 기록합니다. 다음 날 실행이 떨어져도 기록은 남습니다. 단, 완전하지 않습니다. 그 글은 종류(기사인지 수리인지)가 실행 기록으로 판단할 수 있을 때만종류를 작성합니다. 판단할 수 없는 회는 비어 있는 상태로 남아 있으며, 빈 행은 이 뒤에 나타나는 1 회당 상한을 판단하지 않습니다. 실제로, 현재 문제가 되고 있는 8월 23일의 행이 그 상태에서, 3.6배 초과가 판정되지 않은 채 통과하고 있었습니다(손으로 보충했습니다). §7의 “대장을 쓰는 주체가 떨어진 회에는 존재하지 않는다”고, 형태가 같은 구멍입니다.

이 $7.2967에는 이미 1개의 문제가 있었습니다. 1회당 상한은 $2.00으로 정해 두었습니다. 3.6배입니다. 그럼에도 불구하고 멈추지 않은 것은 상한을 실행할 때 보는 경로가 없었기 때문입니다. 값은 적혀 있었고, 그 값이 모순되지 않는지 검사하는 시스템도 있었지만, 실제로 달리고 있는 운전이 그 값을 읽는 장소는 어디에도 없었습니다.

8월 25일에 배선했습니다. 단달리고 있는 중에는 멈출 수 없습니다 — 비용은 실행이 끝날 때까지 확정되지 않기 때문입니다. 멈출 수 있는 것은 다음 1회이며, 초과가 사람들의 리뷰를 받을 때까지 다음 정시 실행을 진행하지 않는 형태로 하고 있습니다. 멈추는 것은 주계만이므로, 리뷰를 기다리는 동안에도 부계가 출하를 계속합니다（§3의 1/6・10/10）。 해제는 인간에게만 가능합니다 —— AI가 자신의 초과를 스스로 통과할 수 있다면, 상한은 “부탁드립니다”가 됩니다. 이 정지는 본판에서 아직 한 번도 발화하지 않았습니다.