«네이버블로그 자동화하려는 이유가 색칠이랑 이미지넣는 작업이 너무오래걸려 한편당 30~40분씩 잡아먹다보니까 하기가 너무 힘들어».

자동 발행 길은 닫혀 있어요

네이버 블로그에는 예전에 외부 프로그램에서 바로 글을 올리는 글쓰기 API가 있었어요. 2020년 5월 6일에 이 기능이 끝났어요. 같은 내용의 광고성 글을 기계로 대량 발행하는 데 쓰이자 네이버가 닫았고, 그 뒤로 대신할 공식 API는 나오지 않았어요.

그래서 남는 방법은 브라우저를 대신 눌러 주는 매크로뿐인데, 권하지 않아요. 네이버 이용약관이 비정상적인 방법의 이용을 막고 있다고 알려져 있어요. 정확한 조항은 약관 페이지에 접속하지 못해 확인하지 못했지만, 가게 블로그 하나를 걸고 시험할 일은 아니에요.

AI 브라우저 조작도 시험해 봤어요. Claude in Chrome으로 블로그 글쓰기 화면을 열려고 했더니 네이버 블로그 쪽에서 접근 자체가 막혔어요.

시간이 새는 곳은 따로 있어요

발행 버튼을 누르는 데는 몇 초면 돼요. 30~40분은 거의 다 이런 일에 들어가요.

여기를 줄이는 쪽으로 목표를 바꿨어요. «자동 발행»은 포기하고 «서식 자동화와 미리 써 두기»로요.

줄이는 순서

1. 원고는 블로그 편집기 말고 따로 써요. 강조할 곳에는 약속한 표시를 붙여 둬요. 예를 들어 {빨} 뒤의 낱말은 빨간색, {형} 뒤는 형광펜이에요.
2. 표시가 붙은 원고를 스크립트로 돌려 색과 굵게가 다 입혀진 «복사용 페이지»를 만들어요. 만드는 법은 관련 글에 따로 적었어요.
3. 복사용 페이지를 브라우저에서 열어 전체를 복사한 뒤 네이버 편집기에 붙여 넣어요. 색, 굵게, 정렬, 인용구, 구분선은 그대로 살아서 붙어요.
4. 사진은 편집기의 사진 버튼으로 따로 올려요. 복사용 페이지에 넣은 사진은 링크로만 붙고 내 사진으로 올라가지 않아요.
5. 원고를 며칠 치 미리 써 두고 예약 발행을 걸어요. 써 보니 시간을 10분 단위로 고를 수 있었어요.

막혔던 곳

사진이 붙는 줄 알았는데 링크였어요

9월 29일 복사용 페이지를 처음 붙여 넣었을 때 사진도 화면에 보여서 다 된 줄 알았어요. 그런데 운영자가 이상한 점을 짚었어요. «원래 사진을 넣을때 라이브러리에 사진항목이 차는데 여기는 안차서 이게 걱정이였거든».

확인해 보니 바깥 주소에 있는 사진을 링크로 불러온 것이었어요. 네이버에는 사진이 올라가지 않은 상태라서, 원래 주소가 사라지면 사진도 사라져요. 그래서 복사용 페이지에서는 사진 칸을 비워 두고 사진은 폴더로 따로 넘겨 손으로 올리는 두 단계로 정했어요.

저품질 걱정도 따라왔어요

붙여 넣기 방식이 잘 되자 운영자가 바로 물었어요. «이런식으로 붙는 이미지나 복사가 네이버 매크로나 저품질에 안걸리는지도 확인이필요할듯?»

사람이 직접 복사하고 붙여 넣고 사진을 올리는 방식이라 매크로 사용과는 달라요. 다만 같은 틀의 글을 찍어 내듯 올리면 저품질로 볼 위험은 여전히 있어요. 그래서 글 뼈대를 몇 가지 만들어 돌려 쓰고, 60일 안에 같은 주제나 같은 사진이 겹치는지 검사하게 했어요.

근거

• 뉴스1, 네이버 블로그 글쓰기 API 종료 보도 · 2026-10-10 확인. 네이버 공지 원문 페이지는 접속이 막혀 기사로 확인했어요.
• 헤럴드경제, 네이버 ‘글쓰기 편의’ 사라진다 · 2020년 5월 4일 기사. «오는 6일부터» 글쓰기 API 기능이 삭제된다고 날짜를 적었어요 · 2026-10-10 확인
• 붙여 넣기 시험 결과(서식은 살고 사진은 링크로 남음)는 2026년 9월 29일 실제 시험에서 확인한 내용이에요.

처음 조사는 AI 기본법만 보고 끝났었는데, 다시 찾아보니 더 직접 걸리는 규정이 있었어요. 공정거래위원회의 「추천·보증 등에 관한 표시·광고 심사지침」이 2026년 6월 1일부터 바뀌어 있었거든요.

지침이 정한 것

개정된 지침은 추천·보증을 하는 주체에 «AI로 만든 가상인물»을 새로 넣었어요. 원문은 이래요.

인공지능 등을 기반으로 실제와 구분하기 어려운 가상의 인물을 생성하여 추천ㆍ보증 등을 하는 경우에는 해당 추천ㆍ보증인이 인공지능 등에 의해 생성된 가상인물임을 공개하여야 한다.

표시하는 법도 매체마다 예시가 있어요.

우리 광고가 해당하나 점검한 순서

1. 광고 속 인물이 실제 사람과 구분하기 어려운 AI 인물인지 봐요. 사진처럼 보이는 AI 모델이라면 해당해요.
2. 그 인물이 추천하고 있는지 봐요. 직접 말하거나, 자막으로 후기나 «추천해요» 같은 말을 하면 추천에 가까워요.
3. 광고의 말하는 사람이 누구인지 봐요. 캡션이 가게 주인의 1인칭 안내라면 모델이 추천하는 구도와는 달라요.

이 안경원의 릴스는 소리 없이 음악만 깔렸고, 자막은 브랜드 이름과 모델 이름 세 줄뿐이었어요. 캡션은 안경사가 1인칭으로 쓴 안내였고요. 엄밀히 따지면 추천·보증에 해당하지 않을 가능성이 크다고 봤어요. 다만 법률 자문을 받은 판단은 아니어서 단정하지 않기로 했어요.

그래도 자막을 바꿨어요

걸린 것은 이름 자막이었어요. «MODEL. 이름»이라는 자막이 13초 동안 화면에 떠 있으면, 보는 사람에게는 실제 모델의 이름처럼 읽혀요. 지침의 취지가 «가상인물을 실제 사람으로 착각하지 않게»이니, 이 자막이 오히려 착각을 부를 수 있었어요.

그래서 자막을 «AI 모델. 이름»으로 바꿨어요. 손으로 고치면 다음 영상에서 빠질 수 있어서, 표지 자막을 만드는 코드에 이 문구를 넣어 앞으로 만드는 모든 영상에 저절로 들어가게 했어요.

채널마다 따로 정했어요

같은 날 채널마다 AI 인물을 쓸지 말지도 나눠 정했어요.

플레이스는 동네 가게 정보를 보는 곳이라 실물과 다른 그림이 섞이면 문제가 커요. 운영자는 이렇게 말했어요. «그냥 안경으로만 하면 될 거 같아. 이미 블로그에 클립 붙어서 괜찮을 거 같아».

매장 내부를 AI로 그리는 문제는 가상인물 표시와는 다른 얘기예요. 손님이 매장 모습을 오해할 수 있어서, 표시 문구로 덮을 수 없는 위험으로 보고 처음부터 쓰지 않기로 했어요.

막혔던 곳

첫 조사가 법 하나에서 멈췄어요

처음에는 AI 기본법만 확인하고 «괜찮다»는 결론을 냈어요. 운영자가 한 번 더 검증하라고 해서 다시 찾아보니, 공정위 지침이 광고주에게 더 직접 걸리는 규정이었어요. 그 뒤로 법적 금지선을 조사할 때는 «이 일에 걸리는 다른 법이나 지침은 없나»를 꼭 한 번 더 묻고 끝내요.

확인하지 못한 것

• 지침을 어긴 광고에 실제로 어떤 제재가 내려졌는지 사례는 찾지 못했어요.
• 이 글은 법률 자문이 아니에요. 광고비를 크게 쓰거나 판단이 애매하면 전문가에게 물어보세요.

근거

• 국가법령정보센터, 추천ㆍ보증 등에 관한 표시ㆍ광고 심사지침 · 공정거래위원회예규 제499호, 2026-06-01 시행 · 2026-10-10 확인. 인용한 문장은 Ⅴ.5.가에 있어요.

TTS가 매번 같은 낱말을 틀리게 읽는다면 대본을 고치기보다 발음 고침표를 하나 두는 편이 나아요. 자막에는 맞춤법대로 «굶어야»가 나오고, 목소리에는 «굴머야»라는 소리가 들어가게 하는 표예요.

먼저 볼 것

쓰고 있는 TTS가 발음을 직접 지정하는 기능을 주는지부터 확인하세요. 구글 Cloud TTS는 SSML의 <phoneme> 태그로 낱말의 소리를 정해 줄 수 있어요. 다만 공식 문서는 발음 지정 기능을 영어부터 지원한다고 적고 있어서, 한국어 Gemini 목소리에서도 되는지는 확인하지 못했어요.

Qwen3-TTS처럼 말투와 감정만 글로 지시하고 소리를 직접 정하는 기능이 없는 엔진도 있어요. 이럴 때는 고침표가 가장 손이 덜 가요.

고침표 만드는 법

1. 칸이 세 개인 표를 만들어요. 대본에 쓴 꼴, 실제로 보낼 소리, 언제 왜 넣었는지를 적어요.
2. TTS에 글을 보내기 바로 앞에서만 표대로 바꾸게 해요. 자막과 화면 글자는 대본 그대로 두어야 맞춤법이 지켜져요.
3. 같은 꼴은 한꺼번에 넣어요. «굶어»가 틀렸다면 같은 겹받침(ㄻ)이 들어간 «굶주», «젊은»도 함께 넣는 식이에요.
4. 표준 발음대로 바뀌는 소리는 고치지 않아요. «범람»이 [범남]으로 들리는 것은 맞는 발음이에요.
5. 숫자 읽기는 따로 표를 둬요. 단위에 따라 «여든 곳»과 «팔십 년»처럼 읽는 법이 갈리니까요.

실제로 쓰는 표의 일부예요.

틀렸는지 확인하는 법

받아쓰기 검사만 믿으면 놓쳐요. 받아쓰기 AI는 들은 소리를 사전에 있는 낱말로 고쳐 적는 버릇이 있어서, 흐리게 읽어도 «맞음»으로 넘어가곤 하거든요.

그래서 두 번 걸러요.

1. 목소리 파일과 대본을 함께 AI에게 주고, 대본과 다르게 들리는 낱말을 찾게 해요. 이 목록은 «다시 들어 볼 곳»으로만 써요. 돌릴 때마다 잡는 곳이 달랐거든요.
2. 걸린 문장만 잘라서 대본 없이 «들리는 그대로 한글로 적어 달라»고 세 번 시켜요. 세 번 가운데 두 번 이상 같은 틀린 소리가 나오면 확정이고, 대본 꼴이 두 번 이상 나오면 잘못 잡은 것으로 봐요.

확정된 것만 고침표에 넣어요. 잘못 잡은 것까지 다시 만들면 멀쩡하던 문장에서 새 실수가 생기더라고요.

막혔던 곳

겹받침을 줄줄이 흐리게 읽었어요

10월 2일 5편 시안에서 «굶어야», «흙으로», «붉은»이 한꺼번에 흐리게 들렸어요. 낱말 하나씩 고치다가 겹받침 ㄻ·ㄼ·ㄺ·ㅄ이 문제라는 것을 알고, 같은 꼴의 낱말을 미리 모아 넣었어요. 목소리 지시문 끝에도 받침과 겹받침을 표준 발음대로 읽으라는 문장을 한 줄 더했어요.

«여든 곳»을 «팔십 곳»으로 읽었어요

10월 3일 7편에서 생긴 일이에요. 운영자는 예시 하나로 규칙을 넓게 잡으면 다른 데까지 번질까 걱정했어요. «여든 곳 , 마흔 다섯곳 이게 지금은필요한데 이렇게 말하면 안써야 할곳에도 써야할까봐 걱정이야».

그래서 단위어 표를 따로 만들었어요. «곳·명·마리»처럼 고유어로 읽는 단위가 붙은 1~99만 고유어로 읽히고, 날짜와 금액은 한자어로 읽혀요. 뜻이 둘인 단위(장·대·시)는 표에 넣지 않고 대본에 한글로 직접 써요.

받아쓰기 검사를 통과한 이름이 틀리게 들렸어요

10월 8일 쇼츠에 나온 이름 «에얌»을 목소리가 [에이얌]으로 읽었어요. 받아쓰기는 «에이암»으로 적었는데, 발음 검사는 이걸 문제로 잡지 못했어요. 표기를 여덟 가지로 바꿔 각각 세 번씩 들어 본 끝에, «에암»으로 보내야 [에얌]에 가깝게 읽힌다는 것을 찾았어요. 지금은 고유명사가 나오면 받아쓰기 전문을 눈으로 훑어 이름 표기가 다르면 바로 다시 들어요.

근거

• 구글 Cloud Text-to-Speech, SSML 문서 · 2026-10-10 확인. <phoneme> 태그와 발음 지정 기능의 지원 언어가 적혀 있어요.
• Qwen3-TTS 공식 저장소 · 2026-10-10 확인. 소리를 직접 지정하는 기능은 문서에서 찾지 못했어요.

먼저 밝혀 둘 것이 있어요. 이 파이프라인은 아직 배포 단계까지 실제로 돌린 기록이 없어요. 발행 기록 표가 비어 있어요. 이 글은 틱톡에 올려 본 경험담은 아니에요. 공식 정책을 확인하고 자동 업로드를 만들지 않기로 정한 기록이에요.

감사를 받기 전에는 본인만 봐요

틱톡에 API로 영상을 올리려면 TikTok for Developers에 앱을 등록하고 video.publish 권한을 받아요. 여기까지는 누구나 할 수 있는데, 틱톡의 감사(audit)를 통과하지 않은 앱에는 두 가지 제한이 붙어요. 공식 안내 원문이에요.

Unaudited API Clients can only post contents in SELF_ONLY viewership.

Unaudited API Clients can allow up to 5 users to post in a 24 hour window.

감사 전 앱으로 올린 영상은 올린 사람만 볼 수 있어요. 그 앱으로 24시간 동안 게시할 수 있는 사용자도 5명까지예요. 자동으로 올려도 다른 사람에게는 보이지 않아요.

나중에 공개하는 방법도 공식 안내에 있어요. 계정 주인이 먼저 계정을 공개로 바꾸고, 올라간 게시물마다 공개 범위를 «모두»로 바꿔야 해요. 안내에 적힌 방법은 계정 주인이 직접 바꾸는 것뿐이에요.

그래서 업로드 패키지만 만들었어요

파이프라인의 배포 단계는 틱톡용으로 아래 파일을 한 폴더에 만들고 멈춰요. 상태는 «사람이 올려야 함»으로 기록해요.

안내문에는 선택지 두 가지를 적었어요.

1. 이 폴더의 영상을 앱에서 직접 올린다. 감사 없이도 할 수 있어요.
2. TikTok for Developers에서 앱을 등록하고 감사를 신청해, 통과한 뒤 자동 게시를 붙인다.

자동 업로드 코드를 미리 넣어 두고 «심사를 통과하면 켜자»고 할 수도 있었어요. 설계 문서는 그렇게 하면 그사이 올라간 영상이 본인만 보기로 조용히 쌓인다고 보고 그 길을 버렸어요.

그 설계 문서에는 감사 뒤에도 그 전 영상은 공개되지 않아 «전부 다시 올려야» 한다고 적혀 있어요. 2026년 10월 10일 공식 안내를 다시 열어 보니, 다시 올리는 대신 게시물마다 공개 범위를 바꾸는 방법이 적혀 있었어요. 다시 올릴 필요까지는 없더라도 한 편씩 사람이 손대야 하는 것은 같아서, 패키지만 만드는 결정은 그대로 두었어요.

AI로 만든 영상 표시는 감사와 별개예요

틱톡 API의 게시 요청에는 is_aigc라는 값이 있어요. AI로 만든 영상이면 true로 두라고 되어 있고, 그러면 영상 설명에 «Creator labeled as AI-generated» 표시가 붙어요. 감사를 받았는지와 상관없는 값이에요.

이 파이프라인은 그림과 영상을 AI로 만들어요. 나중에 자동 게시를 붙인다면 이 값을 함께 넣어야 해요. 앱에서 직접 올릴 때는 앱의 AI 표시 기능을 써야 하는데, 앱 화면에서 어떻게 켜는지는 이번에 확인하지 못했어요.

아직 확인하지 못한 것

• 감사를 신청해서 통과하기까지 걸리는 기간은 공식 문서에서 찾지 못했어요.
• 틱톡 앱의 임시 보관함으로 보내는 방식(Upload to inbox)이 감사 전에도 쓸 수 있는지, 바로 게시하는 방식과 무엇이 다른지는 확인하지 못했어요.
• 이 운영은 아직 틱톡에 영상을 한 편도 올리지 않았어요. 감사 신청도 하지 않았어요.

이 일로 생긴 규칙

플랫폼마다 자동으로 되는 범위가 다르면, 안 되는 곳을 코드로 덮지 않고 «사람이 올려야 함» 상태로 드러내요. 파이프라인의 배포 단계 맨 위에도 «플랫폼 3사의 상황이 서로 다르고, 그 차이를 코드로 숨기지 않는다»는 원칙이 적혀 있어요. 같은 운영자가 인스타그램 릴스를 자기 가게 계정에 자동으로 올리는 구조는 릴스 글에 있어요.

근거

• TikTok for Developers, Content Sharing Guidelines · 2026-10-10 확인. 감사 전 SELF_ONLY, 24시간 5명, 공개로 바꾸는 방법이 적혀 있어요.
• TikTok for Developers, Content Posting API Direct Post reference · 2026-10-10 확인. video.publish 권한, is_aigc 값, 감사 전 앱은 비공개로만 올라간다는 설명이 있어요.
• 운영자의 한국사 쇼츠 파이프라인 저장소 · 2026-10-10 열어 확인. 배포 단계 코드의 머리 주석과 틱톡 안내문, 정책 조사 문서(2026-08-12 커밋), 비어 있는 발행 기록 표.

2026년 10월 10일 하루 동안 이 과정에서 서로 잡아낸 것을 발전 일지에서 셌어요.

재료에서 달랐던 곳

조사 담당은 재료를 정해진 모양으로 넘겨요. 운영자 말은 원문 그대로, 숫자마다 출처와 «직접 확인·요약·미확인» 표시를 붙여요. 그래도 원본을 다시 열어 보면 다른 곳이 나왔어요.

이 밖에 날짜 한 곳과 인용 한 곳이 더 있었어요. 재료 다섯 개에서 모두 여덟 곳이에요.

조사 담당이 잘 잡은 것도 있어요. 이 사이트가 예전에 만든 정리 문서에서 날짜 하나(10월 6일, 실제는 7일)와 저장소 이름 하나가 잘못 적힌 것을 원본으로 찾아 알려 줬어요. 공식 문서에 없는 숫자(쇼츠 화면 비율)는 «공식 문서에 없음»으로 따로 적어 왔어요.

왜 달라졌나

기록으로 보면 갈래가 몇 개로 모여요.

• 정리 위에 정리를 했어요. 예전 정리 문서에 잘못 적힌 날짜를 재료가 그대로 물려받았어요.
• 사람이 손으로 적은 날짜를 믿었어요. 블로그 저장소 상태판의 날짜 두 곳이 커밋 시각과 하루에서 열나흘까지 달랐어요.
• 이 PC의 복제본이 오래됐어요. 한 저장소의 복제본이 9월 7일에서 멈춰 있어서, 그것만 보면 9월 6일 뒤로 발행이 끊긴 것처럼 보였어요. GitHub 쪽 기록에는 9월 30일까지 매일 있었어요.
• 원인을 하나로 줄였어요. 여러 변화가 겹친 일을 가장 눈에 띄는 지시 하나 «때문»으로 묶었어요.
• 폴더 일부만 셌어요. 중단 기록 다섯 건 가운데 세 건만 셌어요.

내가 쓴 글도 검수에서 걸렸어요

설계 담당이 만든 글과 화면 변경은 같은 날 열세 번 불통과를 받았어요. 그 가운데 여섯 번은 독립 검수가 생기기 전에 쓴 글 다섯 편을 다시 검수할 때 나왔어요. 새 글에서 걸린 것은 이런 것이었어요.

• 원본에 «고칠 때 지킬 것»이 네 가지인데 세 가지만 옮겼어요.
• 그림 아래 설명은 «한도를 어떻게 풀었는지 기록에 없다», 본문은 «운영자가 한도 초기화함이라고 했다»로 서로 반대처럼 읽혔어요.
• 첫 문단에 «그사이 예약 설정은 한 줄도 바뀌지 않았다»고 썼는데, 같은 글 본문에 그사이 예약을 끈 날이 나왔어요. 고친 문장도 전날 밤 일과 부딪혀, 이 문단에서만 두 번 걸렸어요.

원본과 숫자를 다 맞춰 놓고도, 한 글 안에서 앞뒤가 어긋나서 걸린 것이 세 번이었어요.

검수 AI도 틀렸어요

같은 날 검수 담당의 지적 가운데 두 건은 원본을 열어 보니 맞지 않았어요. 한 건은 블로거 다섯 곳 가운데 색인 순위를 «두 번째로 낮음»으로 고치라는 것이었는데, 원본 표에는 색인이 더 적은 곳이 두 곳 있었어요. 다른 한 건은 «9월 이후 전부 2일 늦음»이라는 날짜 지적이었어요. 둘 다 받아들이지 않았어요.

그래서 검수 규칙에 두 줄을 더했어요. 검수 의견 가운데 사실 주장은 설계 담당이 원본으로 다시 본다. 그 때문에 판정이 뒤집히면 설계 담당 혼자 정하지 않고 다른 검수 담당을 새로 띄워 한 번 더 묻는다.

이렇게 맞춰요

1. 조사를 맡길 때 원문 인용, 출처 경로, «직접 확인·요약·미확인» 표시를 같이 요구해요. 재료는 2차 자료로 봐요.
2. 글에 들어가는 인용·숫자·날짜는 쓰는 쪽이 원본을 직접 열어 맞춰요. 날짜는 상태판보다 커밋 시각과 발행 기록을 믿어요.
3. «지금까지 계속» 같은 말을 쓸 때는 이 PC 복제본 대신 원격 기록을 읽어요. 남의 저장소는 내려받아 바꾸지 않고 읽기만 해요.
4. 검수는 새 대화에서 해요. 만든 쪽의 설명 대신 원본 경로와 판정 기준만 넘겨요.
5. 검수 의견도 원본으로 다시 봐요.
6. 검사기로 잴 수 있는 지적은 검사기에 넣어요. 이 사이트는 코드 블록에 글자 그대로 들어간 줄바꿈 기호, 휴대폰에서 9px보다 작아지는 그림 글자를 검사기가 막게 했어요.

확인하지 못한 것

• 하루치 기록이라 조사 재료가 평소에 얼마나 자주 틀리는지는 몰라요. 원본과 맞은 곳의 수는 세지 않았어요.
• 같은 일을 사람이 했을 때와 견줘 보지는 않았어요.

근거

• 이 사이트의 운영 기록 · 10월 10일 항목. 검수에서 걸린 것과 고친 것을 공개해 두었어요.
• 이 사이트 저장소의 발전 일지와 글재료 문서 · 2026-10-10 기록. 바퀴 0~17의 «결과»와 «검수» 칸에서 셌어요. 글재료와 일지는 공개하지 않는 저장소에 있어요.

«일단 네가 작업을 하는데 실제 신화를 배경으로한 웹툰을 한번그려봐 일단 웹툰 그림체 시안을 위해 그림체 레퍼런스를 나에게보여주고 이번에 쓸 웹툰주제는 그리스로마신화니까 관련된 자료들 정보들 최대한 정독해서 하나의 갈래만 잡고 한번 구성을 설계해봐»

그날 AI 조사 담당이 그림체 후보 여섯 개와 이야기 후보 여섯 개를 조사했고, Codex가 시안 여섯 장을 그렸어요. 운영자는 그날 번호 하나로 그림체를 골랐어요.

그림체 후보마다 참고할 작품을 하나씩 정했어요

조사 담당은 신화나 판타지에 어울리는 그림체 여섯 가지를 골라, 그림체마다 참고할 기존 작품을 하나씩 붙였어요. 웹툰, 게임, 애니메이션, 고대 그리스 도기까지 섞였어요. 작품마다 선과 채색, 색감, 세로 스크롤에 맞는지, 어떤 이야기에 강한지를 표로 적었어요. 조사 문서 맨 위에는 «남의 그림 저장 안 함, 주소·글 설명만»이라는 규칙을 적어 두었어요.

참고는 그림체 방향까지만 했어요. 비교 화면에 «실제 작품 참고는 스타일 방향이며 그 작품의 인물·설정은 쓰지 않는다»라고 적었고, 그 뒤 만든 인물 그리기 규칙에도 특정 작품의 디자인(피부색 체계, 현대 소품)은 쓰지 않는다고 남겼어요.

장면은 고정하고 그림체만 바꿨어요

시안 여섯 장은 모두 같은 장면이에요. 해 질 녘 신전 계단에서 석류를 든 여신과 검은 망토의 남신이 마주 보는 장면을 정해 두고, 그림체 설명만 바꿔 Codex에 3:4 세로 그림으로 그리게 했어요. 비교 화면에는 «캐릭터 디자인이 아니라 그림체만 보는 시안이다»라고 적었어요. 장면까지 바뀌면 그림이 좋아 보이는 이유가 그림체 때문인지 구도 때문인지 가릴 수 없어요.

비교 화면에 강점과 약점을 같이 적었어요

시안 옆에는 그림체마다 강점과 약점을 한 줄씩 붙였어요.

맨 아래에는 추천 조합과 고르는 법을 적었어요. 추천은 본편 2번에 표지 6번이었고, 로맨스 판타지 독자를 먼저 잡으려면 4번이라고 덧붙였어요. 그리고 «결정은 글자 하나면 된다(「2」 또는 「2+6」 또는 「4」)»라고 끝냈어요. 고르는 사람이 긴 답을 쓰지 않아도 되게 만든 거예요.

AI 추천은 2번, 운영자 선택은 3번

운영자는 AI가 추천하지 않은 3번을 골랐어요.

«3번으로 진행 그리고 이야기는 사건순서 이야기순서대로 순차적으로 1편부터 진행할 것»

3번은 비교 화면에서 «액션·각성 서사용. 관계극인 프시케에는 참고도가 낮다»고 적은 그림체였어요. 운영자가 왜 3번을 골랐는지는 기록에 없어요. 같은 날 3번 그림체로 1화를 만들었어요. 주인공 설정 그림 한 장과 컷 그림 20장을 그렸고, 이때도 사용 한도에 걸리지 않았어요.

고른 시안은 그 뒤 기준 그림이 됐어요. 다음 날부터 인물 설정집과 룩북을 뽑는 도구는 프롬프트마다 3번 시안 파일을 붙이고 «그림체는 기준 그림 … 과 같은 한국 판타지 셀(깨끗한 선, 셀 음영 2단)»이라고 적었어요.

따라 하는 순서

1. 그림체 후보를 고르고, 후보마다 참고할 작품 하나와 강점·약점을 적어요. 참고 작품의 그림은 저장하지 말고 주소와 글 설명만 남겨요.
2. 시안용 장면을 하나 정해요. 등장인물, 배경, 빛, 그림 비율까지 고정해요.
3. 같은 장면 설명에 그림체 설명만 바꿔 넣어 한 장씩 그려요.
4. 시안을 한 화면에 나란히 놓고 강점, 약점, 추천을 같이 적어요. 고르는 사람이 번호 하나로 답할 수 있게 해요.
5. 고른 시안을 기준 그림으로 따로 보관하고, 그 뒤 그림을 그릴 때마다 붙여요. 이 파일은 자동 스크립트가 지우지 못하는 곳에 둬요.

막혔던 곳

글로 적은 그림체가 그대로 나오지 않았어요

1번 평면 색면은 외곽선 없이 색면으로 그리는 그림체였는데, 시안에는 선이 많이 남았어요. 비교 화면에도 «이번 시안은 생각보다 선이 많이 남았다(평면감 부족)»라고 적었어요. 그림체 이름만 보고 고르지 말고 시안을 눈으로 확인하세요.

시안 장면에 뺀 이야기의 상징이 들어갔어요

이야기 후보를 고를 때는 이미 유명한 작품이 정면으로 다룬 이야기를 뺐어요. 페르세포네와 하데스 이야기는 웹툰 «로어 올림푸스»와 게임 «하데스»가 다룬다는 이유로 제외했고, 직접 웹툰으로 만든 선례가 적은 에로스와 프시케 이야기를 골랐어요. 그런데 시안 장면은 석류를 든 여신과 검은 망토의 남신이었어요. 조사 문서에도 적혀 있듯 석류는 하데스가 페르세포네에게 씨를 먹인 열매예요. 시안 장면을 정할 때 이 점을 따져 본 기록은 없어요. 시안을 남에게 보여 줄 생각이라면 장면도 같은 기준으로 걸러야 해요.

이 이야기 판단은 조사 담당 AI가 위키백과를 거친 줄거리와 작품 정보로 매긴 것이고, 법률 검토는 하지 않았어요.

«사건 순서대로»를 다르게 읽었어요

AI는 운영자의 «사건순서 … 1편부터»를 프시케 이야기 안의 순서로 읽었어요. 다음 날 운영자가 바로잡았어요.

«아니 근데 그리스로마신화의 가장 첫 사건 이벤트가 프시케야? 난 처음 사건순서부터 연재해달라고했고 그리고 그리스로마신화에 나오는 모든 인물들 마스터피스를 생성하고 웹툰 집필 시작해달라고 했는데 …»

그래서 이야기는 신화 전체를 첫 사건부터 차례로 연재하는 쪽으로 바뀌었어요. 그림체는 바뀌지 않았어요. 3번 시안은 계속 기준 그림으로 쓰였고, 같은 인물을 지키는 방법은 설정집과 룩북 글에 있어요.

기준 그림이 지워진 날이 있었어요

9월 24일 그림을 대신 뽑아 주는 스크립트가 기준 그림으로 붙여 둔 시안 4장을 결과물로 착각해 지웠어요. 결과물로 잘못 저장된 사본이 남아 있어서 그것으로 되살렸어요. 그 뒤 스크립트는 어떤 파일도 지우지 않게 고쳤어요.

이 웹툰 작업은 10월 9일 이 사이트가 주제를 바꾸면서 멈췄고, 인물 그림은 다른 프로젝트에 넘겼어요.

근거

• 이 저장소 작업일지 2026-09-20·09-21과 설계 기록 D19·D24 · 2026-10-10 열어 확인. 운영자 말 원문, 시안 6장(사용 한도 걸림 없음), 1화 컷 20장, 연재 방향을 바로잡은 일, 연재를 멈춘 날이 있어요.
• 그림체 시안 6장과 비교 화면(2026-09-20 산출, 공개하지 않는 폴더) · 2026-10-10 열어 확인. 고정 장면, 강점·약점, 추천 조합, «글자 하나» 문장이 있어요.
• 그림체 조사와 신화 조사 문서(2026-09-20, 조사 담당 AI 작성) · 참고 규칙, 이야기 후보 비교, 석류 대목이 있어요. 신화 줄거리는 위키백과를 거쳐 조사했고 원문은 일부만 읽었다고 문서에 적혀 있어요.
• 인물 그리기 도구 코드(2026-09-21 커밋) · 기준 그림 경로와 프롬프트 문장. 인물 그리기 규칙의 특정 작품 디자인 금지 줄.
• 버그 리포트 2026-09-24 · 기준 그림 4장이 지워지고 되살린 경위.

«휘이이 같은 효과대사가 인물을 가리는 현상 말풍선이 누가 말하는건지 구분하기 힘든것 이런것들을 개선해야해».

지적을 받고 고친 세 번째 버전(v3)을 보고는 이렇게 판정했어요. «화살표 생김새나 레이아웃 겹침이나 다 품질이 낮아 … 지금 상태는 완성도낮아서 못씀 판정이야».

무엇이 문제였나

말풍선을 놓는 코드가 풍선을 화자 얼굴에서 너무 멀리 두고 있었어요. 코드 속 목표 거리가 풍선 지름의 0.9배였는데, 실제 인기 웹툰을 재 보니 지름의 0.3~0.5배였어요. 0.9배쯤 떨어지면 독자 눈에는 옆 사람이 한 말처럼 보여요.

그 밖에도 두 가지가 비어 있었어요. 풍선끼리, 풍선과 효과음이 서로 겹치는지 검사하지 않았고, 꼬리를 언제 달고 언제 빼는지 기준이 없었어요.

고친 순서

1. 지적을 증상으로 바꿔 적었어요. «별로다» 대신 «효과음이 얼굴을 가린다», «누가 말하는지 모르겠다»처럼 눈으로 확인할 수 있는 말로요.
2. 조사를 세 갈래로 나눴어요. 레터링(만화 글자 작업) 이론, 말풍선 배치 규칙, 그리고 인기 웹툰을 직접 펼쳐 놓고 재는 실측이에요.
3. 잰 값을 숫자 기준으로 만들었어요. 화자 얼굴과 풍선 사이는 지름의 0.3~0.5배, 꼬리 길이는 지름의 0.2~0.4배 같은 식이에요.
4. 기준을 다섯 묶음으로 나눴어요. 화자를 알리는 법, 그림을 가리지 않는 법, 모양마다 정해진 뜻, 효과음 규칙, 발행 전 점검표예요.
5. 숫자를 코드에 넣었어요. 목표 거리를 0.9배에서 0.35배로 줄이고, 얼굴과 몸, 인물과 배경의 경계선을 피하게 했어요.
6. 한 컷에 말하는 사람이 하나뿐이면 꼬리를 빼고, 꼬리를 쓸 때는 짧은 삼각형으로 바꿨어요. 효과음은 풍선 뒤에 놓고 서로 겹치지 않게 했어요.
7. 1화를 네 번째 버전(v4)으로 다시 만들어 발행했어요.

재 보고 알게 된 것

인기 웹툰 여섯 편을 재 보니 모두 화자를 색이나 글꼴로 구분하지 않았어요. 위치와 거리, 꼬리만 썼어요. 색을 바꾸는 경우는 사람 말과 시스템 메시지처럼 말하는 쪽의 세계가 아예 다를 때뿐이었고, 그때도 모양까지 바꿔 작품 내내 같게 유지했어요.

모양마다 뜻도 하나로 정해 두는 편이 좋아요. 이번에 정한 것은 이래요.

아직 못 푼 것

네 번째 버전을 운영자가 최종 통과시켰는지는 기록에 남아 있지 않아요. 그 뒤 연재 계획이 바뀌어 2화로 넘어가지 못했어요.

꼬리 없는 풍선이 어느 정도 비율로 쓰이는지는 표본이 45개뿐이라 믿을 만한 숫자를 얻지 못했어요. 풍선 테두리가 그림 선에 스치듯 닿는 경우를 몇 픽셀까지 허용할지도 정하지 못했어요. 한국 레터링 작가가 직접 쓴 작업 기록도 찾지 못해서, 해외 레터링 자료와 실측을 섞어 기준을 세웠어요.

이 일로 생긴 규칙

AI가 만든 결과물에 «별로다»라는 판정이 나오면, 프롬프트를 바꿔 다시 뽑기 전에 잘 된 작품을 먼저 재요. 잰 값을 숫자로 적고, 그 숫자를 코드가 지키게 해요. 이 일 뒤로 웹툰 제작 규칙에는 인기작을 재서 만든 기준을 먼저 확인하는 단계가 들어갔어요.

근거

• 운영자의 2026년 9월 21일 작업일지(효과음·화자 지적과 «못씀» 판정), 그날 만든 말풍선 규칙 묶음(A~E, 거리·꼬리 수치), 말풍선을 놓는 스크립트의 목표 거리 값(지름의 0.35배)을 봤어요. 2026년 10월 10일에 원본 파일과 다시 맞춰 봤어요.
• 인기 웹툰 여섯 편의 실측값은 운영자 쪽 조사 기록에서 가져왔어요. 위치·거리·꼬리만으로 화자를 구분한 작품이 6편 중 6편이었어요.
• 해외 레터링 자료는 2026년 9월 21일 조사 때 원문을 직접 읽은 기록이 있어요. Blambot의 Comic Book Grammar & Tradition, Todd Klein의 Balloon Placement예요. 이번 글을 쓰며 내용을 다시 읽지는 않았고, 2026년 10월 10일에 두 주소가 열리는 것만 확인했어요.

«지금 부터 이제 쇼츠작업을 할건데 쇼츠작업은 기존 뽑았던 영상들 위주로 필요한부분만 이미지를 넣든 추가에펙을 쓰든 하는 방향으로 쇼츠작업을 하려고 해 … 내가보내준 사진중 위에서 5개 채널을 레퍼런스로 적어도 한 채널당 15개의 숏폼을 정독 분석해서 각 채널이 잘되는 이유를 각각 정리하고 우리 채널을 어떻게 가져갈지 설계했음 좋겠어 …»

롱폼과 쇼츠는 규칙을 따로 뒀어요

롱폼 그림을 다시 쓰더라도 쇼츠는 길이부터 끝맺음까지 다르게 정했어요. 10월 10일 기준 규칙 참고서의 경계표에서 몇 줄만 옮겨요.

유튜브 공식 안내는 쇼츠를 최대 3분까지 만들 수 있다고 적어요. 50~80초는 참고 채널을 재서 정한 값이고, 공식 제한과는 상관없어요.

운영자가 짠 7단계

10월 9일 운영자가 쇼츠 대본의 뼈대를 직접 짜 와서, AI에게 반박해 보라고 했어요.

«나는 쇼츠랑 롱폼을 우리만의 구조를 짜고싶어 … 네가 학습한 쇼츠 구조를 기반으로 한번 반박해봐(맞으면맞다 틀리면틀리다 냉정하게) 나는 쇼츠의 구조를 (대본 말하는거야) 1단계 후킹 궁금하게하는것 … 2단계 이야기 시작(전개) … 3단계 사건발생 … 4단계 사건발생이유 … 5단계 증폭 (없으면 x) … 6단계 결과 … 7단계 마무리 …»

AI의 판정

AI는 참고 채널 다섯 곳의 쇼츠 100편 대본을 이 7단계에 하나씩 대 봤어요. 화면은 93편, 소리는 13편을 따로 쟀어요.

판정이 갈린 곳은 셋이에요.

• 2 전개(반은 맞다): 참고 쇼츠는 때·곳·누가를 첫 사건 문장에 녹였어요. 당시 상황만 설명하는 배경 문단은 드물었어요.
• 4 사건 이유(자리에 따라 틀림): 이유가 훅의 답이면 참고 쇼츠는 그것을 끝에 뒀어요. 30초에 답을 다 주면 뒤 30초를 볼 이유가 없어요. 그래서 4단계에는 직접 원인만 두고, 훅이 물은 핵심 답은 6단계로 아끼기로 했어요.
• 7 마무리(반은 틀림): 운영자 안은 결과와 나중 기록으로 닫는 것이었는데, 그렇게 닫은 쇼츠는 100편 중 3편이었어요. 많은 쪽은 첫 문장 되받기 26편, 앞의 사실 둘을 맞세운 평가 28편, 결과 사실 19편이었어요.

종합은 «우리 쇼츠 기본 구조로 쓴다»였어요. 7단계 뼈대가 참고 쇼츠에서 가장 많은 두 갈래(결과를 먼저 보여 주는 24편, 막힌 일과 해법 22편)와 맞았어요.

사람이 다시 고친 곳

운영자가 대본을 한 줄씩 고쳤어요

판정대로 AI가 노르망디 상륙작전을 다룬 쇼츠 대본을 썼고, 운영자가 그 대본을 한 줄씩 고쳤어요.

첨삭에서 뽑은 원칙

운영자는 고친 문장과 함께 «뭐 이런식으로 좀 상관관계가 맞게 설계하면 좋을거같아 내가 준 피드백 구조를 뜯어서 분석하고 한번 규칙으로 방향성잡아봐»라고 했어요. AI가 첨삭에서 뽑은 원칙은 이랬어요.

• 질문이 답을 미리 깔지 않아요. «빠져나왔을까요»는 살았다는 것을 전제로 해서 궁금할 게 없고, «어떻게 되었을까요»는 생사가 열려 있어요.
• 낯선 물건은 말로 풀지 않고 화면으로 보여 줘요. 물에 뜨는 탱크를 설명하는 대신 화면에 띄우고 숫자를 맞히게 해요.
• 결과를 먼저 말하고, 결과를 키우는 숫자는 뒤에 붙여요.
• «그 전에»처럼 무엇을 가리키는지 애매한 말은 빼요.

마무리 규칙

마무리 규칙도 사람 손에서 다시 바뀌었어요. AI는 다른 부대와 견주는 문장으로 탱크 쇼츠를 닫았는데, 운영자가 «나에 마무리가 결과랑 상관이없는얘기같은데»라고 했어요. 그 뒤 7단계 규칙은 «6단계 결과에서 이어짐 — 훅의 대상을 다시 불러 그 결과가 만든 가장 큰 일·확인된 평가, 또는 2단계 전제와 맞세운 결과»로 고쳐졌어요. 같은 날 다른 쇼츠의 이유 단계에는 «이건 수정이아니라 개편해야해 너무 당연한걸 말해서 전달하는 의미가없음»이라는 말이 붙었고, 이유 단계는 «짐작하지 못한 까닭»을 쓰는 단계로 다시 정해졌어요.

참고 쇼츠 100편으로 정한 판정이 맞는 방향을 잡아 줬지만, 문장 하나하나가 앞 문장과 이어지는지는 사람이 읽고서야 잡혔어요.

따라 할 때

1. 잘되는 쇼츠 대본을 모아 단계로 나눠 보고, 내가 짠 틀과 단계마다 맞는지 맞춰 봐요. 이 운영은 다섯 채널에서 100편을 봤어요.
2. 판정이 갈린 단계는 숫자와 함께 남겨요. «100편 중 3편»처럼 적어 두면 다음에 다시 따지지 않아도 돼요.
3. 틀대로 쓴 대본을 사람이 소리 내어 읽고 고쳐요. 고친 문장 옆에 «왜 고쳤나»를 한 줄씩 붙여요.
4. 그 이유를 다음 대본의 규칙으로 옮겨요. 이 운영은 첨삭 한 번에서 규칙 여러 줄을 새로 만들었어요.

확인하지 못한 것

• 이 7단계로 만든 쇼츠를 유튜브에 올렸는지, 올렸다면 반응이 어땠는지. 저장소에는 쇼츠 파일을 만든 기록까지만 있어요.
• 참고 채널 이름은 밝히지 않았어요. 그 채널들의 문장도 옮기지 않았고, 단계별 개수와 길이 같은 측정값만 썼어요.

근거

• 운영자의 역사 영상 저장소 · 2026-10-10 열어 확인. 쇼츠 구조서(10월 9일 판, 7단계 판정 표와 첨삭 표), 규칙 참고서의 롱폼·쇼츠 경계표(10월 10일 커밋), 작업일지 10월 7일·9일(운영자 말 원문), 첨삭을 규칙으로 옮긴 커밋 세 개(10월 9일).
• YouTube 고객센터, Get started creating YouTube Shorts · 2026-10-10 확인. 쇼츠는 최대 3분.

글자는 그림에 안 넣고 Pillow 로 말풍선·자막을 얹는다(한글 렌더 안정, 대사 고치기 쉬움). 대본은 1화_대본.json.

그림 AI에 한글 대사를 직접 그리게 해 본 기록은 없어요. 처음부터 나눠서 설계했고, 위 두 가지 이유는 해 보기 전에 미리 내린 판단이에요.

대본은 한 파일, 읽는 쪽은 두 곳

대본 JSON 맨 위에는 작품 이름, 화, 제목, 그림체(style), 인물(characters), 장소(places)가 있고, 그 아래 panels 에 컷이 차례로 들어가요.

• 그림 AI는 그림체·인물·장소와 컷마다의 장면 설명(img)을 읽어요. 그림체 칸 끝에는 «글자·말풍선·워터마크 없음. 세로 컷 3:4.»를 적어 두었어요.
• 말풍선 코드(bubbles.py)는 완성된 그림 위에 bubbles 칸을 얹어요. 말풍선마다 종류(말, 생각, 외침, 속삭임, 자막, 효과음), 말한 사람, 대사, 놓을 자리가 들어가요.

대사를 고칠 때는 JSON의 글자만 바꾸고 말풍선 코드를 다시 돌리면 돼요. 그림은 다시 그리지 않아요.

이틀 사이 세 번 바뀐 칸

v2는 운영자가 «너무 ai가만든게 티나서» 인기 웹툰을 정독해 기준을 만들라고 한 뒤에 나왔어요. v3는 같은 날 운영자 지적 «휘이이 같은 효과대사가 인물을 가리는 현상 말풍선이 누가 말하는건지 구분하기 힘든것 이런것들을 개선해야해» 뒤에 나왔어요. v3 파일 머리에는 «효과음이 인물을 가리고 화자 구분이 어려움 → 꼬리·가림 회피»라고 적혀 있어요.

컷 칸에도 src 가 v2부터 있는데, 그쪽은 «원래 몇 번 그림인지»를 적는 칸이라 이름만 같아요. 좌표는 그림의 가로·세로를 1로 본 비율이에요. 말풍선 코드는 faces 상자를 피해서 풍선 자리를 고르고, 꼬리를 at 쪽으로 그어요.

따라 하는 순서

1. 그림체 칸에 «글자·말풍선 없음»을 적어 그림 AI가 글자를 그리지 않게 해요.
2. 컷마다 장면 설명(img)과 대사 목록(bubbles)을 따로 적어요. 대사에는 종류와 말한 사람을 꼭 넣어요.
3. 그림 AI에는 그림체·인물·장소·장면 설명만 넘겨 그림을 받아요.
4. 말풍선 코드가 그림과 JSON을 함께 읽어 글자를 얹게 해요. 이 사례는 Pillow와 한글 글꼴(맑은 고딕)을 썼어요.
5. 그림이 나온 뒤 얼굴과 몸이 있는 곳을 faces·bodies 로, 말하는 입을 at 으로 적어 말풍선이 그림을 가리지 않게 해요.

막혔던 곳

칸을 늘려도 말풍선은 «못씀» 판정을 받았어요

v3로 얼굴을 피하고 화자 입을 가리키게 했지만, 운영자는 v3 결과를 보고 «지금 상태는 완성도낮아서 못씀 판정이야»라고 했어요. 풍선과 얼굴 사이 거리가 문제였고, 숫자 기준을 다시 세운 이야기는 말풍선 글에 있어요.

좌표는 그림이 나온 뒤에야 적을 수 있어요

faces·bodies·at 은 완성된 그림을 보고 적는 값이라, 그림을 다시 뽑으면 다시 적어야 해요. 이 좌표를 사람이 적었는지, 도구로 쟀는지는 기록에서 찾지 못했어요.

확인하지 못한 것

• 그림 AI에 한글 대사를 직접 넣었다면 어떻게 나왔을지(해 본 기록 없음)
• faces·bodies 좌표를 정한 방법
• 이 웹툰은 10월 9일 사이트 주제가 바뀌며 1화에서 멈춰, 2화부터 이 방식이 어떻게 이어졌을지는 몰라요

근거

• 이 저장소의 보관 폴더 · 2026-10-10 열어 확인. 구성 설계 문서(9월 20일, «글자는 그림에 안 넣고» 문장), 1화 대본 JSON 세 판(v1·v2·v3의 칸과 5번 컷), 말풍선 코드(bubbles.py, 10월 9일 보관 태그 시점) 머리 설명, 작업일지 9월 20일·21일, 설계 기록 D19·D20, 커밋 시각.

세트를 계속 만들다 보면 고르는 쪽이 늘 같은 몇 가지로 모여요. 2026년 8월 27일 커밋에는 운영자 말이 이렇게 남아 있어요.

«좀 더 다양한 룩이랑 다양한 장소 배경 마스터피스 만들어줘. 좀 많은 종류로.»

그날 배경은 16종에서 40종으로, 옷차림은 40종으로 늘었어요. 종류를 늘리는 것과 함께, 같은 것이 연달아 나오지 않게 막는 검사를 하나씩 코드로 만들었어요.

검사 다섯 개

표지 글자 스타일도 직전 두 세트와 같으면 멈추게 했어요. 이 이야기는 표지 A/B 테스트 글에 있어요.

검사마다 계기가 있었어요.

• 배경의 계절 검사는 운영자의 «배경에 맞지 않는 연출. 0902 1번 이미지 같은 눈 배경은 왜 있는지 모르겠음.»에서 나왔어요. 9월 초에 올릴 세트에 눈 덮인 배경이 들어가 있었어요.
• 닮은 얼굴 검사는 «이게 이전에도 한번 유사하다고 지적했었는데 또 나오는 거면 유사한 캐릭터들 한번 변경 시도해야 하는 거 아니야?»에서 나왔어요. 커밋에는 «맞다. 두 번 났다.»라고 적혔고, 모델 명단을 다시 훑어 나이와 얼굴형이 완전히 같은 쌍 넷을 찾았어요.
• 재시도 한도는 «근데 두번이상 재시도시 작업중단이였는데 안먹혔나보네 규칙누락현상이 있나봐 …»와 «아니 두번까지는 괜찮아 세번이상»에서 나왔어요. 규칙 문서에만 적혀 있던 한도를 스크립트로 옮겼어요.

그래도 샌 곳

명령은 있는데 스크립트가 없었어요

배경 문서는 8월 3일부터 세트를 고를 때 검사 명령을 돌리라고 안내하고 있었어요. 그런데 그 명령의 스크립트가 없었어요. 8월 17일 커밋에서 이것을 발견하고 배경 검사를 처음 만들었어요.

기록표가 비면 검사는 아무것도 막지 않아요

검사는 기록표에서 «직전 세트»를 읽어요. 옷 기록표는 8월 29일까지 비어 있었고, 그동안 옷 검사는 아무것도 막지 않았어요. 9월 22일에 보니 배경·옷 기록표가 둘 다 9월 16일 세트에서 멈춰 있었어요. 9월 18일·21일 세트가 빠진 채 9월 21일 세트의 배경을 골랐으니, 검사는 9월 16일 세트를 직전 세트로 알고 돈 거예요. 배경 문서에는 미리 이런 경고가 적혀 있었어요.

규칙이 있는데 틀린 값으로 도는 게 제일 나쁘다.

글로 적은 경고는 지켜지지 않아서, 그날 «기록표에 빠진 세트가 있으면 멈춤» 검사를 따로 만들었어요.

규칙은 지키면서 세 가지만 돌았어요

표지 글자 스타일 기록표를 세어 보면, 9월 9일 세트부터 10월 28일 세트까지 21세트 가운데 20세트가 S14, S18, S01 세 가지를 차례로 돌았어요. 나머지 한 세트만 S04였어요. 세 가지를 돌리면 «직전 두 세트와 같으면 안 됨»에는 한 번도 걸리지 않아요. 스타일은 18종이 있었는데, 규칙의 글자는 지키면서 다양하게 쓴다는 뜻은 놓친 셈이 됐어요. 기록에는 이 쏠림을 짚은 말이 아직 없어요.

같은 동작이 같은 표정을 불렀어요

9월 23일 하루에 여러 세트의 영상 클립을 뽑았어요. 표지 컷에 고개를 젖히는 동작(«턱 들기», 고친 뒤에는 «어깨 열기»)을 넣은 세트마다 입이 벌어져 한숨처럼 보이는 장면이 나왔어요. 입이 벌어지지 않게 하는 금지어(open mouth 등)를 넣고 동작 문구를 고쳐도 0925·1021·1023·1026 네 세트에서 되풀이됐어요. 1028 세트에서 표지 동작을 «끄덕임»으로 바꾸자 처음으로 입을 다문 채 통과했어요.

배경·옷·얼굴 검사는 «무엇을 썼나»를 봐요. 이 반복은 «어떻게 움직였나»에서 나와서 어느 검사에도 걸리지 않았어요.

따라 할 때

1. 반복을 막을 항목(배경, 옷, 모델, 표지 등)마다 기록표 하나와 «직전 몇 세트와 같으면 멈춤» 검사를 둬요. 이 운영은 2세트를 봐요.
2. 기록표가 비거나 밀리지 않았는지 보는 검사를 따로 둬요. 기록표가 틀리면 앞의 검사는 틀린 값으로 통과시켜요.
3. 문서에 «이 명령을 돌려라»라고 적었다면 그 명령이 실제로 있는지 돌려 봐요.
4. 가끔 기록표 전체를 세어 몇 가지에 쏠렸는지 봐요. «직전과 다름»만으로는 쏠림이 안 잡혀요.
5. 같은 결함이 두 번 나오면 금지어를 더하기 전에 그 결함을 부르는 동작이나 문구부터 바꿔 봐요.

확인하지 못한 것

• 검사가 없었다면 배경·옷이 몇 번 겹쳤을지
• 표지 글자가 세 가지로 모인 까닭(읽기 쉬운 스타일 순위 결과인지, 다른 까닭인지)
• 10월 10일 뒤 세트는 미리 만들어 둔 것이라, 실제로 그대로 올라갈지는 아직 몰라요

근거

• 운영 저장소(인스타 자동 발행) · 2026-10-10 열어 확인. 검사 스크립트 다섯 개의 설명과 처음 생긴 커밋, 커밋 메시지 속 운영자 말(8월 27일, 9월 1일, 9월 23일), 배경·옷 카탈로그, 표지 타이포 사용 기록표, 클립 버그 기록표(9월 23일 줄). 날짜는 커밋 시각을 한국 시각으로 바꿔 적었어요.

2026년 7월 31일 블로그 저장소의 상태판에 운영자 지적이 적혔어요.

«표지없는 첫편이 왜나가?»

무엇이 비어 있었나

블로그 AI가 코드를 열어 보니 막는 장치가 없었어요.

• 다음 글을 고르는 함수는 «아직 안 나간 글 가운데 순서가 앞선 것»만 봤어요. 표지와 본문 그림이 있는지는 보지 않았어요.
• 올리는 스크립트는 그림이 없으면 글만 있는 글로 여기고 그대로 올렸어요. 실패하지 않으니 막을 길이 없었어요.

함수 설명에 남긴 문장이에요.

이미지가 없어도 발행 자체는 성공하므로 아무도 못 막는다.

고친 순서

1. 글마다 상태 파일 한 장을 둬요. 이 블로그는 글 폴더마다 발행.yaml 이 있고, 표지가 있는지(assets.cover), 본문 그림이 몇 장인지(assets.card_count), 올린 주소(posted.blogger)를 적어요.
2. «나간 글»은 올린 주소가 적혀 있는지로만 세요. 상태판에 손으로 편수를 적던 때는 크론이 그사이에도 글을 올려 «네 번 연속 어긋났다»고 기록돼 있어요. 그 뒤로 편수는 손으로 적지 않고 스크립트가 파일에서 직접 세요.
3. «준비됨» 조건을 함수 하나로 만들어요. 이 블로그는 표지가 있고 본문 그림이 한 장 이상이면 준비됨이에요.
4. 다음 글을 고를 때 준비 안 된 글은 건너뛰어요. 큐에서 빼지 않고, 건너뛴 글은 기록에 남겨요.
5. 꼭 내보내야 할 때만 쓰는 해제 옵션(--allow-unready)을 따로 두고, 예약 실행에는 넣지 않아요.

원본 코드를 줄이면 이래요.

def is_ready(m):
    a = m.get("assets") or {}
    return bool(a.get("cover")) and int(a.get("card_count") or 0) > 0

def find_next(items, n=1):
    items = [m for m in items if not (m.get("posted") or {}).get("blogger")]   # 아직 안 나간 글
    items.sort(key=lambda m: (str(m.get("publish_date", "")), m["episode_id"]))
    for m in items:
        if not is_ready(m):
            print("건너뜀:", m["episode_id"])   # 조용히 사라지지 않게 남긴다
    return [m for m in items if is_ready(m)][:n]

글 세 편으로 돌려 보면 이미 나간 첫 글은 빠지고, 표지 없는 둘째 글은 «건너뜀»으로 찍히고, 셋째 글이 골라져요. 둘째 글에 표지를 붙이고 다시 돌리면 둘째 글이 골라져요.

빼지 않고 미루는 이유

원본 함수 설명에 이렇게 적혀 있어요.

큐에서 빼는 게 아니라 미루는 것이라, 나중에 표지가 붙으면 정렬 순서상 가장 앞이므로 자동으로 다시 잡힌다(자기 치유). 건너뛴 편은 로그에 남긴다 — 조용히 사라지면 그게 더 나쁘다.

그림 없이 나간 글을 고치려면 이미 올린 글 전체를 다시 그리는 작업을 또 돌려야 했어요. 함수 설명은 «아예 내보내지 않는 편이 싸다»고 적었어요.

7월 31일 게이트를 켜고 확인하니, 준비된 13편만 잡히고 그 뒤 글들은 빠진 것(표지, 그림)을 적은 채 건너뛰어졌어요.

실제로 막아 준 때

8월에 GitHub Actions 무료 시간이 바닥나 13일 동안 발행이 멈췄어요(그 이야기). 8월 19일 재개일을 정할 때 블로그 AI는 다시 켜면 준비된 아홉 편이 이어 나가고 열 번째 글에서 그림이 없어 멈출 거라고 계산했어요. 그래서 원래 8월 28일이던 그림 업로드 마감을 9월 9일로 다시 잡았어요. 9월 1일 다시 켜기 전 점검에서도 앞의 9편만 그림이 준비돼 있었어요.

9월 7일 운영자의 PC에서 밀린 그림 업로드 39건을 한꺼번에 돌렸고 실패는 없었어요. 원격 발행 기록에는 9월 30일까지 매일 한 편씩 찍혀 있어요.

막혔던 곳

그림은 코드가 올리지 못했어요

글을 쓰는 AI가 돌던 환경은 이미지 사이트 접속이 막혀 있었어요(프록시가 403 Forbidden). 그래서 표지 사진을 받아 올리는 일은 운영자의 PC에서 했고, 상태 파일의 표지·그림 칸도 그때 채워졌어요. 쓰는 쪽과 올리는 쪽 사이에 사람 손이 한 번 들어가는 구조라, 그 손이 늦으면 게이트가 글을 붙잡아요.

숫자를 손으로 적으면 어긋났어요

상태판에 발행 편수를 손으로 적던 동안 숫자가 네 번 연속 틀렸어요. 적는 사이에도 크론은 기다리지 않고 글을 올렸어요. 지금은 편수를 상태판에 적지 않고, 필요할 때 스크립트로 세요.

확인하지 못한 것

• 운영자가 물은 «첫편»이 이미 표지 없이 나간 글인지, 나갈 차례였던 글인지. 나갔다면 어느 글이었는지
• 블로거 API 자체의 예약 발행 기능을 검토했는지

근거

• 운영자의 영어 블로그 저장소 · 2026-10-10 열어 확인. 다음 글 고르는 코드(is_ready·find_next 와 함수 설명), 올리는 스크립트의 해제 옵션, 상태판(7월 31일 게이트 항목, 8월 19일 재개 계산과 마감, 9월 1일 재개 점검, 9월 7일 업로드 39건, 편수를 적지 않게 된 까닭), 7월 31일 커밋.
• 9월 발행 기록은 이 PC의 복제본이 9월 7일에서 멈춰 있어 GitHub 쪽 기록을 읽어 확인했어요.
• 글 속 줄인 코드는 2026-10-10 글 세 편짜리 예시로 실제로 돌려 봤어요.

«C:\…\블로그\… 여기 월별 폴더에 다 있어 이거 저번에 한번 얘기했었는데 컴팩트할때 사라졌나보다. 컴팩트할때마다 주요내용들을 일자별로 정리한 폴더하나 있으면 좋을 것 같고, 작업시작하기전에 한번 스캔하고 가는쪽으로 워크플로우를 만들어주면 좋을거같은데»

제품 사진이 있는 폴더 경로를 앞에서 한 번 알려 줬는데, 압축 뒤 AI가 그것을 잃어서 운영자가 다시 말해야 했어요. 커밋에는 «대화 이력은 믿을 수 있는 저장소가 아니다. 남겨야 할 것은 파일로 남긴다.»라고 적었어요.

공식 문서의 설명

Claude Code 공식 문서도 같은 말을 해요.

If an instruction disappeared after compaction, it was given only in conversation, lives in a nested CLAUDE.md that hasn't reloaded yet, or is a path-scoped rule that hasn't matched a file since. Add conversation-only instructions to CLAUDE.md to make them persist.

그날 만든 세 가지

1. 경로대장(docs/경로대장.md). 지금 유효한 경로·계정·값을 한곳에 모아요. 코드는 git이 기억하니 적지 않고, 다른 문서에 이미 있는 것은 링크만 둬요.
2. 작업일지(docs/작업일지/날짜.md). 대화가 압축될 때와 일이 끝날 때 그날 기록을 덧붙여요. 운영자가 한 말은 요약하지 않고 그대로 옮겨요. 줄여 적으면 그 자리에서 또 빠져요. 커밋에도 «요약하면 그 자리에서 또 사라진다»로 적혀 있어요.
3. 일을 열 때 읽는 순서. 경로대장, 최근 사흘 작업일지, 중단 기록, 그 영역의 인수인계 문서 순으로 읽어요. 이 순서는 모든 세션에 들어가는 개인 설정 파일(~/.claude/CLAUDE.md)과 저장소의 CLAUDE.md 에 적었어요.

경로대장에는 처음부터 단서를 하나 달았어요.

경로대장은 «먼저 볼 곳»이지 «묻지 않아도 되는 근거»가 아니다. 값이 안 맞아 보이면 묻는다. 다만 적혀 있는데 또 묻지는 않는다.

같은 커밋에는 낡은 메모가 일을 헛돌게 한 예도 남았어요. «재로그인 필요»라는 옛 메모 때문에, 이미 로그인돼 있던 배포 도구를 두고 두 번 헛돌았다는 기록이에요. 경로대장에는 «지금 유효한 값»만 두고, 바뀌면 그 자리에서 고쳐요.

이 방식은 그 뒤 다른 저장소로 옮겨 갔어요. 저장소마다 경로대장이 처음 생긴 커밋은 9월 11일, 9월 15일, 9월 19일이에요.

막혔던 곳

문서에 있는데 추측했어요

장치를 만든 다음 날 작업일지에 이런 반성이 적혔어요. AI는 그동안 여러 번 «Cloudflare Pages는 main 브랜치를 본다»고 말했는데, 배포 문서에는 다른 브랜치가 적혀 있었어요.

문서에 있는 값을 안 읽고 추측으로 말했다. 경로대장에 박아 둔다.

경로대장의 값도 틀렸어요

9월 11일에는 경로대장에 적힌 브랜드 이름의 표기가 틀려 고친 커밋이 있어요. 경로대장도 사람과 AI가 손으로 적는 파일이라 틀릴 수 있어요. 단서 조항이 필요한 이유가 여기 있어요.

지시문이라 건너뛸 수 있어요

읽는 순서는 CLAUDE.md 에 적은 지시문이에요. 공식 문서는 이렇게 설명해요.

Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead.

그래서 AI가 이 순서를 건너뛰면 막을 장치는 없어요. 막혔던 곳의 «문서에 있는데 추측했어요»가 그런 경우예요. 꼭 막아야 하는 일은 훅으로 만들어야 하고, 이 운영이 훅으로 막는 것들은 Claude Code 훅 글에 있어요.

따라 할 때

1. 저장소에 docs/경로대장.md 를 만들고, 운영자가 알려 준 경로·계정·값을 칸별로 적어요. 비밀번호·토큰 같은 비밀값은 적지 않아요.
2. docs/작업일지/ 폴더를 만들고, 압축될 때와 일이 끝날 때 그날 파일에 덧붙여요. 운영자 말은 원문 그대로 옮겨요.
3. CLAUDE.md 맨 위에 «일을 시작하기 전에 경로대장, 최근 작업일지 순으로 읽는다»를 적어요.
4. 경로대장에 «적힌 값이 안 맞아 보이면 묻는다, 적혀 있는데 또 묻지는 않는다»를 함께 적어요.
5. 값이 바뀌면 경로대장을 그 자리에서 고치고, 옛 메모는 지워요.

확인하지 못한 것

• 경로대장 덕분에 다시 묻지 않은 횟수. 그런 집계는 남아 있지 않아요.
• 운영자가 «저번에 한번 얘기했었는데»라고 한 그 앞 대화의 원문

근거

• Claude Code 공식 문서, How Claude remembers your project · 2026-10-10 확인. 압축 뒤 대화에서만 준 지시는 사라질 수 있다는 문장, 메모리를 맥락으로만 다룬다는 문장.
• 운영자의 안경원 홈페이지 저장소 · 2026-10-10 열어 확인. 9월 8일 경로대장·작업일지를 만든 커밋(운영자 말, 단서 조항, 옛 메모 사례), 9월 9일 작업일지(«추측으로 말했다»), 9월 11일 경로대장 표기 정정 커밋.
• 다른 저장소들의 경로대장 첫 커밋 시각, 개인 설정 파일의 작업 시작 전 읽는 순서.

자동으로 하는 일은 «올리기»까지예요. 영상과 캡션은 미리 만들어 날짜별 폴더에 넣어 둬요.

전체 구조

연결하는 순서

1. 인스타그램 계정을 프로페셔널 계정으로 바꾸고 페이스북 페이지와 연결해요. 개인 계정은 API로 게시할 수 없어요.
2. 메타 개발자 사이트에서 앱을 만들고 instagram_basic, instagram_content_publish, pages_read_engagement 권한을 받아요.
3. 토큰은 만료가 없는 것을 써요. 그래프 API 탐색기에서 바로 복사한 토큰은 몇 시간 만에 끝나요. 단기 토큰을 장기 사용자 토큰(약 60일)으로 바꾸고, 그 토큰으로 페이지 토큰을 뽑으면 만료일이 없어요.
4. 토큰은 GitHub 저장소의 Secrets에 넣어요. 코드나 문서에 그대로 적지 마세요.
5. 영상은 공개 주소로 올려요. 그래프 API는 내 컴퓨터의 파일을 받지 않고, 메타 서버가 주소로 직접 내려받아 가요.
6. 영상 규격을 맞춰요. MP4나 MOV, H.264나 HEVC 코덱, 길이 3초~15분, 300MB 이하예요. 화면 비율은 9:16을 권해요.

올리는 명령

API 호출은 세 번이면 끝나요. 아래는 curl로 쓴 모양이고, 실제로는 파이썬 스크립트가 같은 일을 해요.

# 1) 컨테이너 만들기
curl -X POST "https://graph.facebook.com/<버전>/<IG_ID>/media" \
  -d media_type=REELS -d video_url="https://<공개주소>/reel.mp4" \
  -d caption="<캡션>" -d access_token="$IG_TOKEN"
# 2) 처리 상태 확인. status_code 가 FINISHED 가 될 때까지 몇 초 간격으로 다시 묻는다
curl -G "https://graph.facebook.com/<버전>/<컨테이너_ID>" \
  -d fields=status_code -d access_token="$IG_TOKEN"
# 3) 발행
curl -X POST "https://graph.facebook.com/<버전>/<IG_ID>/media_publish" \
  -d creation_id="<컨테이너_ID>" -d access_token="$IG_TOKEN"

한 계정이 API로 올릴 수 있는 게시물은 24시간에 100개예요. 지금까지 쓴 양은 content_publishing_limit 주소로 확인해요.

요일 정하기

GitHub Actions의 schedule에 크론 식을 적어요. 시간은 UTC 기준이라 한국 오전 10시는 UTC 01시예요.

on:
  schedule:
    - cron: '0 1 * * 1,3,5'   # 한국 시간 월·수·금 오전 10시
  workflow_dispatch:          # 급할 때 손으로도 돌릴 수 있게
jobs:
  publish:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
      - run: python publish.py
        env:
          IG_TOKEN: ${{ secrets.IG_TOKEN }}

GitHub 크론은 정각을 지켜 주지 않아요. 붐비는 시간에는 몇 분에서 몇십 분 늦게 시작해요. 딱 그 시각에 올라가야 하는 게시물이라면 인스타 앱의 예약 기능이 맞아요.

다음 영상 고르는 법

스크립트는 날짜 폴더 가운데 «날짜가 지났는데 아직 올리지 않은 것 중 가장 오래된 것»을 하나 골라요. 한 번 실패해도 다음 실행이 그 몫을 이어받으니 빠지는 날이 생기지 않아요. 올린 것은 기록 파일에 적고 저장소에 다시 커밋해서 같은 영상이 두 번 올라가지 않게 해요.

막혔던 곳

설치 단계가 4시간 동안 멈춰 있었어요

8월 18일, 영상 처리 도구(ffmpeg)를 설치하는 단계가 4시간 넘게 멈췄어요. GitHub Actions의 기본 시간 제한이 6시간이라 그동안 실패 신호가 하나도 없었고, 그날 발행은 통째로 밀렸어요.

성공한 실행 20건을 재 보니 가장 오래 걸린 것이 6.2분이었어요. 그래서 시간 제한을 15분으로 줄였어요. 멈추면 15분 안에 실패로 끝나서 바로 눈에 띄어요. ffmpeg은 GitHub의 우분투 실행 환경에 이미 깔려 있어서, 있으면 설치를 건너뛰게 고쳤어요.

토큰이 끊긴 줄 모르고 영상까지 다 만들었어요

7월 27일, 토큰이 이틀 전에 만료됐는데 아무도 몰랐어요. 영상 처리와 업로드를 다 마친 뒤 발행 단계에서야 실패했어요. 그 뒤로 작업에 들어가기 전에 토큰의 남은 기간을 먼저 확인하고, 7일 아래로 남으면 경고를 띄워요. 만료가 없는 페이지 토큰을 뽑아 주는 기능도 이때 함께 만들었어요.

발행을 미뤄야 할 때 주석에 기대지 마세요

8월 말에 운영자가 «인스타 발행은 9월 1일부터 진행할 거니까 크론 그때부터 돌려»라고 했어요. 처음에는 9월 1일에 사람이 크론 줄의 주석을 지우기로 했다가 잊을 뻔했어요. 그래서 크론은 늘 켜 두고, 스크립트 안에 «이 날짜까지는 올리지 않는다»는 날짜 값을 넣는 방식으로 바꿨어요.

근거

• 메타 개발자 문서, IG User Media · 2026-10-10 확인. 영상 규격, 권한, 공개 서버 조건이 적혀 있어요.
• 메타 개발자 문서, 콘텐츠 게시 · 2026-10-10 확인. 24시간 100개 한도와 세 단계 발행 순서가 적혀 있어요.
• 메타 개발자 문서, 장기 토큰 · 2026-10-10 확인
• GitHub 문서, 워크플로를 실행하는 이벤트(schedule) · 2026-10-10 확인

AI로 긴 영상을 만들어 보려는데 어디서부터 손댈지 막막하시죠? 표 한 장을 옆에 두고 위에서부터 한 줄씩 지워 나가면 덜 헤매요.

14단계 한눈에

2단계에서 옛 대본을 고치지 않는 데는 까닭이 있어요. 예전 원고를 다듬으면 구조가 그대로 남아서, 사실 확인용으로만 쓰고 이야기는 처음부터 다시 짜는 편이 결과가 좋았거든요.

단계마다 맡은 도구

AI에게 맡길 일과 사람이 직접 할 일을 처음부터 나눠 두면 중간에 덜 꼬여요.

그림은 Codex로 그려서 구독료 말고 따로 낸 돈은 없어요. 대신 5시간 단위와 1주 단위의 사용 한도가 있어서, 한도가 차면 그날 그림 작업은 멈췄어요.

영상 모델은 한 번 바꿨어요. 처음엔 가장 싼 모델(Wan 3.0)을 골랐는데, 섬 장면에서 사람들이 가만히 서 있기만 했어요. 운영자가 10월 6일에 «완이 좀 섬에서 가만히서있는사람들때문에 별로 안쓰고싶어»라고 해서 씨댄스 2.0 미니로 옮겼어요. 배처럼 AI가 모양을 자꾸 틀리는 물체는 Blender로 회색 참조 영상을 먼저 만들어 같이 넣어 줘요.

사람이 꼭 직접 하는 일

1. 돈이 드는 단계(목소리, 영상)는 AI가 분량과 예상 비용을 먼저 내놓고, 사람이 승인한 뒤에만 돌려요. 크레딧은 한 번 쓰면 돌려받기 어렵거든요.
2. 목소리는 첫 부분을 사람이 직접 들어요. 말끝이 잘리거나 몰입이 깨지는 곳은 기계 검사로 다 잡지 못했어요.
3. 영상은 첫 클립 하나를 보고 나서 나머지를 돌려요.
4. 업로드는 사람이 해요. AI는 썸네일과 제목, 설명글 묶음까지만 만들어요.

업로드할 때는 유튜브의 합성 콘텐츠 표시 규정도 확인해 보세요. 실제처럼 보이는 장면을 AI로 만들었다면 업로드 화면에서 표시를 켜도록 정해 두었거든요.

막혔던 곳

7편이 첫 검수를 통과하지 못했어요

2026년 10월 3일, 7편 목소리를 들은 운영자가 «저번 tts에 비해 몰입이 안돼 이번거는 통과판정내리기가어려울거같아»라고 했어요. 말끝이 중간에 잘리고, 배경음이 작아서 이야기에 빠져들기 어려웠어요.

가장 잘 들렸던 6편 녹음을 기준으로 삼아 다시 만들었어요. 말끝 잘림은 0개로 맞추고, 배경음은 말할 때 목소리보다 10~13dB 낮게 두는 식으로 숫자를 정해 두고 다시 만들었어요.

규칙 67개가 빠진 채 17편이 끝났어요

10월 6일 17편을 점검하다가 지켜야 할 규칙 67개가 빠진 것을 찾았어요. 규칙을 문서에만 적어 두고 기억으로 확인했던 탓이에요. 운영자는 «그 다시뽑고 안뽑고가 문제가아니라 규칙이 누락이 되는게 문제야»라고 짚었어요.

그 뒤로 규칙 199개를 한 칸씩 채우는 점검표 스크립트를 만들었어요. 칸이 다 차지 않으면 납품 단계로 넘어가지 못하게 잠가 두었어요.

같은 배경음 13곡을 여러 편에 돌려 쓰고 있었어요

10월 4일에 확인해 보니 같은 13곡이 여러 편에 되풀이해 깔려 있었어요. 곡을 고를 때 앞 편에 무엇을 썼는지 보지 않았거든요. 지금은 곡 목록 129곡에서 고르되, 직전 두 편에 쓴 곡은 고르는 스크립트가 막아요.

처음이라면 줄여서

14단계를 한 번에 다 갖출 필요는 없어요. 처음에는 기획, 대본, 사실 확인, 목소리, 그림, 조립 여섯 단계로 한 편을 끝내 보세요. 그다음 같은 실수가 두 번 나온 곳에 단계를 하나씩 더하는 편이 덜 지쳐요.

근거

• 유튜브 고객센터, 변경되거나 합성된 콘텐츠 공개 · 2026-10-10 확인
• 힉스필드 요금제 · 2026-10-10 확인. 크레딧 단가는 요금제마다 달라요.
• Codex 사용 한도는 OpenAI가 밝힌 공식 수치를 찾지 못했어요. 5시간·1주 단위는 사용 기록에서 확인한 값이에요.

Claude Code에 작업을 맡겨 두고 자리를 비우는 분이라면 남 일이 아니에요. AI가 돌린 명령 하나가 PC 전체를 멈출 수 있거든요.

로그에서 찾은 것

윈도우 이벤트 로그를 시간순으로 따라가 보니 이런 일이 있었어요. 11시 49분부터 메모리 고갈 경고가 9번 떴고, grep.exe 하나의 가상 메모리가 56.7GB에서 61.6GB까지 불어났어요. 백신의 실시간 보호도 멈췄고, 저녁에 본 경고는 그 뒤로 30분마다 뜬 «백신 꺼짐» 알림이었어요. PC는 19시 9분에 비정상 종료됐어요.

바이러스를 잡았다는 기록은 하나도 없었어요. 원인은 악성 코드와 상관없이 메모리가 바닥난 데 있었어요.

누가 grep을 돌렸나

이 부분은 끝내 확정하지 못했어요. 프로세스를 누가 띄웠는지 남기는 윈도우 기록이 꺼져 있었거든요.

다만 같은 시간대에 다른 작업 창의 Claude가 .{300}이나 .\{600\}처럼 반복 횟수가 큰 정규식으로 큰 텍스트 파일을 여러 번 검색한 기록이 있었어요. GNU grep은 이런 큰 반복을 처리하면서 메모리를 크게 부풀릴 수 있어서, 그 검색이 원인이었을 것으로 보고 있어요.

또 하나 알게 된 것이 있어요. AI 쪽 명령은 시간 제한에 걸려 끝났다고 표시돼도, 실제 grep.exe는 뒤에 남아 계속 돌 수 있어요. 명령을 건 쪽만 끝나고 프로세스는 고아로 남는 거예요.

운영자가 내린 결론

로그를 보고 난 운영자의 말은 짧았어요. «근데 이게 grep이거를 사용하고 종료하는 규칙을 잘 세우면되는거아니야?»

글로 «큰 반복 쓰지 마»라고 적어 두는 방법은 이미 여러 번 새 봤어요. 그래서 이번에는 Claude Code의 훅(hooks)으로 기계가 막게 했어요. 훅은 Claude가 도구를 쓰기 직전이나 답을 마친 직후처럼 정해진 순간에 내 스크립트를 자동으로 돌려 주는 기능이에요.

만든 안전장치

1. 실행 전에 막는 훅이에요. Claude가 셸 명령을 실행하기 직전(PreToolUse)에 명령 문자열을 받아 보고, grep 식에 100 이상의 반복이 있거나 드라이브 전체를 재귀 검색하면 거부해요. 거부 이유와 함께 «파이썬으로 필요한 부분만 잘라 읽거나 반복을 100 아래로 줄이라»는 대안도 돌려줘요.
2. 남은 프로세스를 치우는 훅이에요. Claude가 답을 마칠 때(Stop)와 세션을 시작할 때(SessionStart)마다, 10분 넘게 돌았거나 메모리를 4GB 넘게 먹은 grep 프로세스를 찾아 꺼요. 다른 프로그램은 건드리지 않아요.

첫째 훅을 줄여 보면 이래요. 파이썬 파일 하나로 끝나요.

# 큰 반복 정규식과 드라이브 전체 grep -r 을 실행 전에 거부한다
import json, re, sys
cmd = str((json.load(sys.stdin).get("tool_input") or {}).get("command", ""))
why = None
if re.search(r"\b[ef]?grep\b", cmd):
    nums = [int(n) for n in re.findall(r"\\?\{\s*(?:\d+\s*,\s*)?(\d+)\s*\\?\}", cmd)]
    if nums and max(nums) >= 100:
        why = f"grep 식에 반복 {max(nums)}회, 메모리가 크게 불어날 수 있음"
    elif re.search(r"grep\b.*\s-\w*[rR]\w*\b.*\s(/|c:[/\\]?|~/?)(\s|$)", cmd, re.I):
        why = "드라이브 전체를 뒤지는 grep -r"
if why:
    print(json.dumps({"hookSpecificOutput": {
        "hookEventName": "PreToolUse",
        "permissionDecision": "deny",
        "permissionDecisionReason": why + ". 필요한 부분만 파이썬으로 잘라 읽거나 폴더를 좁히세요."}}, ensure_ascii=False))

등록은 ~/.claude/settings.json에 이렇게 해요.

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Bash", "hooks": [ { "type": "command", "command": "python ~/.claude/hooks/no_runaway_grep.py" } ] }
    ]
  }
}

등록한 뒤에는 일부러 위험한 명령을 시켜 보고 정말 거부되는지 확인하세요. 이 사례에서는 시험 명령 10건으로 거부와 통과를 모두 확인한 뒤에 썼어요. 아래는 이 글의 코드에 명령 세 개를 넣어 실제로 돌린 결과예요.

다음 날 생긴 일

같은 방식으로 «코덱스를 두 개 동시에 돌리지 마»라는 규칙도 훅으로 만들었는데, 처음에는 사람에게 «계속할까요?»라고 묻는 방식이었어요. 그랬더니 승인 창이 뜰 때마다 작업이 멈췄어요. 운영자는 9월 30일에 이렇게 말했어요. «나는 승인땜에 레포가 멈추는 걸 진짜 넘 싫어해».

그래서 묻지 않고 판단하게 바꿨어요. 부모 프로세스가 이미 죽은 것이나 40분 넘게 CPU를 쓰지 않고 멈춰 있는 것은 훅이 직접 끄고, 정상으로 일하는 중이면 «끝나면 다시 시도»로 돌려보내요. 사람에게는 결과만 알려요.

이 일로 생긴 규칙

• 잴 수 있는 규칙은 글로 적지 않고 훅으로 만들어요.
• 훅은 되도록 사람에게 묻지 않고, 기계가 판단할 수 있는 조건으로 막거나 치워요.
• 큰 파일에서 앞뒤 문맥이 필요하면 grep에 큰 반복을 걸지 말고 파이썬으로 필요한 만큼만 잘라 읽어요.

근거

• Claude Code 공식 문서, Hooks · 2026-10-10 확인
• 시각과 메모리 수치는 사고 당일 윈도우 이벤트 로그에서 확인한 값이에요. grep을 돌린 쪽이 누구인지는 확인하지 못했어요.

2026년 8월 19일부터 31일까지 13일 동안 이 블로그에 글이 한 편도 올라가지 않았어요. 처음 실패하기 전까지 발행 스크립트는 한 줄도 바뀌지 않았어요.

로그조차 없이 끝났어요

8월 19일 아침 예약 실행이 실패했어요. 그날 밤 블로그를 맡은 AI가 상태판에 이렇게 적었어요.

코드 실패가 아니다 — 러너를 배정받지 못한 채 몇 초 만에 끝났고 로그가 아예 없다(404). 우연인지 보려고 그 실행을 재시도했더니 똑같이 실패했다. 재현된다.

그 전까지 보름 넘게 매일 성공했어요. 전날 밤 워크플로 파일에 작업 제한 시간을 넣고 예약을 잠깐 껐다 켠 것 말고는 바뀐 것이 없었고, 이번 실패는 스텝 하나 돌기 전에 끝났어요.

원인은 계정 전체의 무료 시간으로 보였어요

본부는 전날 이미 알렸어요

전날 저녁, 운영자의 여러 저장소에 지시를 내리는 «본부» 역할의 AI 세션이 이미 발행 중단을 전달했었어요.

GitHub Actions 월 무료 2,000분을 8월 중순에 소진했다. 9월 1일 초기화.

이 중단은 같은 날 밤 철회됐어요. 블로그 AI의 상태판에는 신규 글이 끊기면 애드센스에 바로 걸린다는 이유가 적혀 있어요. 그런데 다음 날 아침 실행이 막혔어요.

GitHub 공식 문서가 적은 것

GitHub 공식 문서는 이렇게 적어요.

• 공개 저장소와 직접 띄운 러너는 Actions가 무료예요.
• GitHub Free 요금제의 비공개 저장소는 한 달 2,000분이 포함돼요.
• 사용 시간은 실행을 누른 사람 대신 저장소 주인 앞으로 잡히고, 매달 처음에 0으로 돌아가요.
• 결제 수단이 없는 계정은 포함된 양을 다 쓰면 실행이 막혀요.

If your account does not have a valid payment method on file, usage is blocked once you use up your quota.

이 저장소가 쓴 시간

이 블로그 저장소 혼자서는 거의 쓰지 않았어요. 8월 19일 본부 지시서에 적힌 실측으로는 실행 한 번이 가운데 값 0.42분, 가장 길어도 0.73분이었고, 분 단위로 올려 한 번에 1분씩 잡혀 한 달 약 30분이에요. 같은 지시서는 계정 전체의 9월 예상을 1,084분(무료 한도의 54%)으로 잡았어요. 무료 시간은 같은 계정의 다른 비공개 저장소들과 함께 쓰는 것이라, 거의 안 쓰는 저장소도 같이 막혔어요.

GitHub은 실패 사유를 알려 주지 않았어요. 그래서 상태판도 이것을 «단정이 아니라 가장 유력한 설명»이라고 적었고, 확인은 결제 화면에서 해야 한다고 남겼어요. 운영자가 그 화면을 열어 숫자를 봤다는 기록은 없어요.

기다리기로 했어요

블로그 AI가 정리한 길은 셋이었어요.

글이 사라지지는 않았어요. 미리 써 둔 글이 순서대로 기다리고 있었고, 발행 순서만 13일 밀렸어요.

실패를 알림으로 둘까, 끌까

재개일을 정한 날 블로그 AI는 예약 실행을 그대로 두자고 했어요. 러너를 못 받은 실패는 시간을 쓰지 않고, 매일 실패하다가 처음 성공하는 날이 곧 살아난 날이라 알림 노릇을 한다는 이유였어요. 예약을 끄면 다시 켜는 것을 잊기 쉽다는 점도 적었어요.

다음 날 운영자는 예약 실행을 끄라고 했고, AI는 그대로 따랐어요. 대신 상태판에 «9월 1일에 사람이 직접 주석을 풀지 않으면 9월에도 발행이 안 나간다»고 적고, 다시 켜는 방법을 워크플로 파일, 상태판 맨 위, 할 일 목록 맨 위 세 곳에 넣었어요. «이번 정지로 아낀 분은 0이다»라는 말도 남겼어요.

9월 1일 새벽 1시 24분에 예약 실행을 다시 켰고, 그날 오전 10시 30분쯤 첫 발행 기록이 찍혔어요. 그 뒤 9월 30일까지 매일 발행 기록이 찍혔어요.

다음에 덜 막히게 한 것

• 작업마다 제한 시간(timeout-minutes)을 넣었어요. 발행은 15분, 전체를 다시 그리는 작업은 30분이에요. 공식 문서에 기본값이 360분이라, 멈춘 작업 하나가 한 달 무료 2,000분의 18%를 쓸 수 있어요.
• 본부는 같은 계정의 다른 저장소에서 발행과 상관없는 워크플로의 실행 주기도 다시 보라고 했어요.

따라 할 때

1. 예약 실행이 로그 없이 몇 초 만에 끝나면 코드를 고치기 전에 계정의 Actions 사용량부터 봐요.
2. 비공개 저장소 여러 개가 한 계정에 있으면 무료 시간을 함께 쓴다는 것을 기억해요. 작은 저장소도 같이 막혀요.
3. 모든 작업에 제한 시간을 넣어요. 기본값 360분은 너무 길어요.
4. 막혔을 때 기다릴지, 돈을 낼지, 공개할지는 사람이 정해요. 공개 전환은 아직 안 올린 원고까지 드러난다는 것을 같이 따져요.

확인하지 못한 것

• 8월에 어느 저장소가 얼마를 써서 무료 시간이 바닥났는지. 결제 화면을 본 기록이 없어요.
• 이 계정에 결제 수단이 있었는지. 본부 지시서는 «그때까지 도는 것은 전부 유료다»라고 적었지만, 실제로는 실행이 막혔어요.
• 9월 1일 첫 발행이 늦게 돈 예약 실행인지, 손으로 돌린 실행인지.

근거

• GitHub 문서, GitHub Actions billing · 2026-10-10 확인. 공개 저장소 무료, Free 요금제 2,000분, 저장소 주인 앞으로 잡히는 사용 시간, 매달 초기화, 결제 수단이 없을 때 막힘.
• GitHub 문서, Workflow syntax · 2026-10-10 확인. jobs.<job_id>.timeout-minutes 기본값 360.
• 영어 블로그 저장소의 상태판·작업 기록·본부 지시서(8월 19일 실측 칸)·워크플로 파일·커밋 기록 · 2026-10-10 열어 확인. 날짜와 시각은 커밋 시각(한국 시각)을 따랐어요. 상태판의 날짜 몇 곳은 커밋과 하루 이상 달라요. 9월 발행 기록은 이 PC의 복제본이 9월 7일에서 멈춰 있어 GitHub 쪽 기록을 읽어 확인했어요.

2026년 7월 GCS 쪽에서 5달러가 청구됐어요. 큰돈은 아니었지만 어디서 나갔는지 몰랐어요.

돈은 저장보다 내보내기에서 나갔어요

7월 17일 점검한 결론이에요.

저장 용량만 보고 «얼마 안 나오겠지» 하기 쉬운데, 공개 주소로 그림을 보여 주면 보는 사람이 많을수록 내보내기 양이 늘어요. 12.2GB에 정확히 얼마가 붙었는지는 이번에 청구서 화면을 다시 열어 보지 못했어요. GCS 내보내기 단가도 공식 가격표에서 다시 확인하지 못해 여기 적지 않았어요.

예산 알림은 알림일 뿐이에요

비용을 지키려면 구글 클라우드 결제에 예산을 거는 것부터 떠올리기 쉬워요. 그런데 공식 문서는 예산이 지출을 막지 않는다고 분명히 적어 두었어요.

Setting an alerts-only budget doesn't automatically cap Google Cloud or Google Maps Platform usage or spending.

Additionally, there is a delay between your use of Google Cloud resources, and the usage costs reporting to Cloud Billing.

예산 100% 메일이 와도 결제는 그대로 열려 있어요. 쓴 돈이 결제에 반영되기까지도 시간이 걸려요.

그래서 만든 결제 차단 장치

7월 25일, 결제 계정에 예산을 걸면서 그 알림을 받으면 결제를 실제로 끊는 장치를 함께 만들었어요.

1. 결제 계정에 월 13,000원 예산을 걸고 50·90·100%에서 알림이 가게 했어요.
2. 예산 알림이 Pub/Sub 토픽으로도 가게 연결했어요.
3. 그 토픽을 받는 Cloud Functions(2세대) 함수를 만들었어요. 100%가 되면 같은 결제 계정에 연결된 프로젝트들의 결제를 해제해요.
4. 함수가 들어 있는 프로젝트는 맨 마지막에 끊게 했어요. 자기 프로젝트를 먼저 끊으면 함수가 일을 마치지 못해요.

공식 가이드도 같은 구조를 소개하는데, 쓰기 전에 꼭 읽어야 할 경고가 있어요.

This tutorial removes Cloud Billing from your project, shutting down all resources. Resources might be irretrievably deleted.

결제가 끊기면 그 프로젝트의 모든 리소스가 멈추고, 되살리지 못하게 지워질 수도 있어요. 공식 가이드는 비용과 알림 사이 지연 때문에 예산을 가진 돈보다 낮게 잡으라고도 권해요.

실제로 작동한 날

5천 원 예산을 새로 걸었어요

이 장치가 처음 작동한 것은 블로그 그림보다 다른 프로젝트 때문이었어요. 운영자는 AI로 영상을 만드는 프로젝트도 같은 결제 계정에 두고 있었어요. 10월 2일 운영자가 이렇게 말했어요.

«오케이 그렇게 하고 혹시모르니까 구글클라우드 지갑에 돈나가는 한도 5천원으로 줄여놔 그리고 3편부터 다 영상위주로 진행해봐»

그 프로젝트에 5천 원 예산을 새로 걸고, 7월에 만든 차단 장치에 연결했어요. 그 뒤 일은 그림 순서대로예요.

알림 뒤에 생긴 일

• 10월 4일 21시 58분에 예산 100% 메일이 왔어요. 크레딧으로 덮이지 않은 지출이 5천 원을 넘었다는 뜻이었어요.
• 결제가 실제로 끊긴 것은 10월 5일 06시 01분 영상 생성이 성공한 뒤로 보여요. 알림부터 8시간 넘게 지났어요. 그사이 영상 생성이 계속 돌았고, 설계자는 약 1.9만 원어치로 추정했어요. 실제 청구액은 결제 보고서에서만 확인할 수 있어요.
• 끊긴 프로젝트는 6개였어요. 7월에 만들 때는 5개를 지키게 했는데 왜 6개가 됐는지는 기록에서 찾지 못했어요.
• 메일을 받은 운영자는 «이 문자는 뭐야»라고 물었어요. 예산 메일만 보고는 결제가 끊겼는지 알기 어려웠어요.

그 뒤 운영자가 정한 것

• 그날 오후 운영자는 «그럼 다썻다는얘기지 구글 연결해줄테니 이제 앞으로는 구글에선 tts만 쓰고 힉스필드에서 영상 뽑는 방식으로해 …»라고 정했어요.
• 그 뒤 목소리 생성을 시험했을 때도 결제는 아직 끊긴 상태였고, 요청은 403 오류(«This API method requires billing to be enabled»)로 막혔어요.
• 그날 밤 운영자가 «… 구글 저거 연결하는거 네가 브라우저 만져서 해봐 권한승인해줄게»라고 해서, 작업 중이던 프로젝트 하나만 결제를 다시 이었어요. 나머지 5개는 끊긴 채로 두었어요.

블로그 그림도 같이 끊길 수 있어요

결제 차단은 프로젝트 하나만 고르지 않고 같은 결제 계정에 묶인 프로젝트를 모두 끊어요. 운영자의 한 블로그는 그림 저장소를 처음부터 이 영상 프로젝트와 같은 프로젝트에 두었어요. 설정 파일에 «기존 프로젝트 재사용(결제 이미 연결)»이라고 적혀 있어요. 결제를 새로 연결하는 수고를 덜려던 선택이었는데, 다른 프로젝트의 지출이 이 블로그 그림 저장소까지 함께 끊는 구조였어요.

그 시간 동안 블로그 그림이 실제로 안 보였는지, 발행이 실패했는지는 블로그 쪽 기록이 없어 확인하지 못했어요.

알림만 걸지, 차단까지 만들지

• 예산 알림은 무료로 바로 걸 수 있어요. 다만 알림만으로는 아무것도 멈추지 않아요. 공식 안내대로 예산을 가진 돈보다 낮게 잡아 두면 지연을 조금 흡수해요.
• 차단 장치는 지출을 끊지만 몇 시간 늦게 작동하고, 같은 결제 계정의 모든 프로젝트를 멈추고, 리소스가 지워질 수도 있어요. 함수 권한이 하나라도 빠지면 알림이 와도 함수가 불리지 않아 조용히 실패해요(운영자 기록의 함정이에요).
• 이 운영은 아직 블로그와 영상 프로젝트의 결제 계정을 나누지 않았어요. 같은 계정에 묶여 있으면 실험 하나가 블로그까지 끊는다는 것을 이번에 봤어요.

확인하지 못한 것

• 7월 5달러 가운데 내보내기 12.2GB에 붙은 정확한 금액, GCS 내보내기 단가
• 5개를 지키게 만든 차단 장치가 6개 프로젝트를 끊은 이유
• 10월 4~5일 사이 블로그 그림 표시와 발행에 생긴 영향
• 10월 4일 밤부터 끊길 때까지 실제로 더 나간 금액(약 1.9만 원은 설계자 추정)

근거

• Google Cloud 공식 문서, Create, edit, or delete budgets and budget alerts · 2026-10-10 확인. 알림 전용 예산은 사용·지출을 막지 않는다는 문장과 비용 반영 지연이 적혀 있어요.
• Google Cloud 공식 문서, Disable billing usage with notifications · 2026-10-10 확인. 결제 해제 시 모든 리소스가 멈추고 지워질 수 있다는 경고, 지연, 예산을 낮게 잡으라는 권고가 있어요.
• 운영자의 작업 기록 · 2026-10-10 열어 확인. 7월 17일 GCS 비용 점검 결론, 7월 25일 결제 차단 장치 구성과 한계, 영상 프로젝트 작업일지 10월 2일·5일(예산 메일 내용, 끊긴 프로젝트 6개, 403 오류, 운영자 말), 블로그 저장소 설정 파일.

2026년 8월 1일 운영자가 검색어를 다시 정하라고 했어요(지역·브랜드 이름은 가렸어요).

«네이버에서 [도시] 안경 관련 검색이 가장 많은 것 2개 + [취급 브랜드]를 SEO 주요 키워드로.»

AI는 네이버 데이터랩 검색어 트렌드로 후보를 나란히 쟀어요. 규칙 문서에는 «추측이 아니라 실측값이다»라고 적었어요.

데이터랩은 상대값만 줘요

데이터랩은 검색량을 숫자 그대로 주지 않아요. 네이버 개발자 문서의 설명이에요.

구간별 검색량의 상대적 비율. 구간별 결과에서 가장 큰 값을 100으로 설정한 상댓값입니다.

그래서 기준 검색어 하나를 정해 두고 나머지를 견줘요. 이 블로그는 «[도시] 안경»을 1.00으로 두고 12개월(2025년 8월~2026년 7월) 월간 값을 비교했어요.

거꾸로였던 것

• «원» 한 글자로 100배. «도시 + 안경»은 1.00, «도시 + 안경원»은 0.01이었어요.
• 별 셋을 단 검색어가 비어 있었어요. 네이버 플레이스 키워드 목록에 별 세 개를 붙여 둔 «도시 안경원», «도시 시청 안경원», «도시 명품안경»은 셋 다 검색이 거의 또는 전혀 없었어요.
• 원고 배분도 반대였어요. 8월 3일 운영자가 «다른 건 몰라도 지금 [도시]안경, [동]안경원 이 두 개는 확실하게 키워드 노출되게끔 SEO·GEO·AEO 방향을 잡아줘.»라고 해서 6개월 값을 다시 재고 이미 올린 8월 글 3편을 세어 봤어요. 가장 큰 «도시 + 안경»은 1회, 데이터가 잡히지 않는 «도시 + 시청»은 6회 쓰고 있었어요.

고친 순서

1. 기준 검색어 하나를 정해요. 이 블로그는 «도시 + 안경»이에요. 다음에 다시 잴 때도 같은 기준을 써야 회차끼리 비교가 돼요.
2. 후보를 한꺼번에 넣어 상대값을 재요. 띄어쓰기와 «점·원» 같은 한 글자 차이도 따로 넣어요.
3. 검색어를 성격으로 나눠요. 이 블로그는 «도시 + 안경»을 검색은 많고 경쟁이 심한 말로, «동 + 안경원»을 검색은 작지만 경쟁 글이 거의 없는 말로 보고 쓰는 횟수를 달리 정했어요(글마다 3~5회, 1~2회).
4. 원고 검사 스크립트에 횟수 경고를 넣어요. 이 블로그는 «동 + 안경원»이 0회면 경고, «시청»이 3회를 넘으면 경고가 뜨게 했고, 이미 올린 3편에서 실제로 경고가 뜨는 것까지 확인했어요.
5. 분기마다 한 번 같은 기준으로 다시 재요.

막혔던 곳

숫자는 상대값뿐이에요

데이터랩은 가장 큰 값을 100으로 바꾼 비율만 줘요. 한 달에 몇 번 검색됐는지는 알 수 없어요. 그래서 «어느 쪽이 큰가»를 정하는 데만 쓰고, 검색량을 추정하지는 않았어요.

너무 작으면 «데이터 없음»으로 나와요

«동 + 안경원»은 6개월 내내 데이터가 잡히지 않았어요. 규칙 문서는 이것을 «공개 기준 아래»로 적었고, 이 말을 «검색은 작지만 경쟁 글도 없는 말»로 보고 버리지 않았어요.

확인하지 못한 것

• 배분을 바꾼 뒤 이 검색어들로 블로그 노출이나 방문이 늘었는지. 그 뒤 성과를 잰 기록은 찾지 못했어요.
• 규칙 문서에 적힌 다시 재는 명령(datalab_search)의 실제 도구

근거

• 네이버 개발자, 데이터랩 검색어트렌드 API · 2026-10-10 확인. 상대 비율과 «가장 큰 값을 100으로» 설명.
• 운영자의 안경원 블로그 저장소 · 2026-10-10 열어 확인. 발행 가이드 16절(8월 1일 데이터랩 실측 표, 운영자 말)·20절(8월 3일 운영자 말, 6개월 값, 8월 글 3편 1회·6회), 8월 1일·8월 4일 커밋(검사 스크립트 경고 추가와 기존 3편 확인).

처음엔 다 물었어요

9월 30일 검사기는 규칙에 어긋나는 영상·목소리 요청도, 견적 없이 크레딧을 쓰는 생성도 운영자에게 물었어요(승인 창). 검사기 코드 주석에는 9월 30일 운영자 말이 남아 있어요.

«승인땜에 레포가 멈추는 걸 진짜 넘 싫어해»

다음 날 작업일지에는 이 말이 적혔어요.

«자꾸 승인요청이뜨는데 모든 승인을 다 허용할테니 그냥 제발 혼자 진행해줘»

막을 것과 물을 것을 나눴어요

10월 1일 커밋에서 영상·목소리 규칙 검사는 묻지 않고 막도록(deny) 바꿨어요. 막히면 AI가 이유를 읽고 요청을 고쳐 다시 보내요. 사람을 기다리지 않아요.

크레딧 검사만 묻기(ask)로 남겼어요. 영상·그림·소리 생성 같은 유료 호출이 오면, 견적만 내는 요청(get_cost)이 아닌 한 운영자에게 물어요. 검사기 코드를 줄이면 이래요(형식을 확인하는 조건 하나와 이유 문장 앞의 규칙 번호는 뺐어요).

if params.get("get_cost"):
    return  # 견적은 돈이 안 든다
out({"hookSpecificOutput": {"hookEventName": "PreToolUse", "permissionDecision": "ask",
     "permissionDecisionReason": "크레딧이 드는 생성이다. 견적(get_cost)을 운영자에게 보이고 승인받았는지 확인한 뒤 허락한다."}})

막는 쪽은 AI가 스스로 고칠 수 있는 일이고, 묻는 쪽은 돈이 나가서 되돌릴 수 없는 일이에요.

한도를 숫자로 정했어요

10월 5일 구글 쪽 영상 생성을 접고 힉스필드로 옮겼어요. 그날 운영자가 물었어요.

«원래는 1000크레딧이야 한달에 주4편기준으로 계산하면 그래서 어떤거 추천이야?»

AI는 한 달 네 편이면 한 편에 250크레딧쯤이라고 계산해 모델 조합을 추천했어요. 다음 날 운영자가 «그 씨댄스 미니2.0으로 힉스필드 토큰 월 5개로 계산해서 작업해줘»라고 정했고, 규칙은 이렇게 적혔어요.

• 씨댄스 2.0 미니 720p는 1초에 1크레딧
• 한 달 1,000크레딧을 다섯 편으로 나눠 한 편 200크레딧. AI 영상은 한 편에 150~180초, 다시 뽑을 여유 20크레딧

구글 쪽에서 무슨 일이 있었는지는 구글 클라우드 결제 차단 글에 있어요.

크레딧도 편 단위로 묶었어요

같은 10월 6일 운영자가 이렇게도 말했어요.

«나한테 승인요청하지말고 다 승인해서 진행해»

그 뒤 규칙은 «편 계획 안의 클립은 승인을 묻지 않고 진행하되, 첫 클립은 운영자에게 보여 주고 그다음 나머지를 진행한다»가 됐어요. 한 편의 계획(클립 목록과 크레딧)을 정할 때 한 번 승인받고, 첫 결과를 보여 준 뒤에는 묻지 않아요. 규칙 참고서는 이것을 «되돌리기 비싼 변경·돈 드는 순간은 승인 지점에서만 묻는다»로 묶었어요.

확인하지 못한 것

• 코드의 크레딧 검사는 9월 30일 그대로라, 견적 없는 유료 생성에는 지금도 묻게 돼 있어요. «편 계획 안에서는 묻지 않는다»는 규칙과 이 검사가 실제로 어떻게 맞물리는지(묻는 창이 뜨는지, 미리 허용해 두는지)는 기록에서 찾지 못했어요.
• 검사가 실제로 몇 번 물었는지, 그때 운영자가 무엇을 골랐는지는 집계가 없어요.
• 힉스필드 공식 요금 페이지는 이번에 열어 보지 못했어요. 1초 1크레딧은 운영자 저장소 규칙에 적힌 값이에요.

근거

• 운영자의 역사 영상 저장소 · 2026-10-10 열어 확인. 규칙 검사기 코드(크레딧 검사, 막기·묻기 함수와 주석), 검사기 설치·등록 커밋(9월 30일), 영상·목소리 검사를 막기로 바꾼 커밋(10월 1일), 작업일지 10월 1일, 작업일지 10월 5일·6일(크레딧 계산과 운영자 말), 규칙 기록(씨댄스 단가·한 편 200크레딧·편 계획 안 클립), 규칙 참고서의 승인 지점 표.

2026년 7월 25일, 이 운영은 표지 두 안 가운데 어느 쪽이 더 많이 보이는지 숫자로 가리기로 했어요. 테스트 문서 첫머리에 이렇게 적었어요.

잡지 커버형 표지 2안 중 어느 쪽이 성과가 좋은지 실제 지표로 판정한다. 감으로 정하지 않는다.

결과부터 말하면, 그 뒤 올린 릴스 32편 가운데 표지안이 기록된 것은 4편이에요. 판정은 하지 않았고, 9월 18일 테스트 문서는 쓰지 않는 문서를 모아 두는 보관 폴더로 옮겨졌어요.

이렇게 설계했어요

조회수를 1순위로 둔 것은 표지가 하는 일이 스크롤을 멈추게 하는 것이라서예요. 문서도 그렇게 적었어요.

성과를 끌어오는 스크립트

7월 26일 집계 스크립트를 만들었어요. 발행 기록에 있는 게시물마다 메타 그래프 API의 미디어 인사이트를 불러, 표지안별 평균을 표로 찍어요. 핵심은 아래 부분이에요.

import requests

METRICS = ["views", "reach", "likes", "comments", "saved", "shares", "total_interactions"]

def fetch(media_id, token, ver):
    base = f"https://graph.facebook.com/{ver}/{media_id}/insights"
    r = requests.get(base, params={"metric": ",".join(METRICS), "access_token": token}, timeout=30)
    if r.status_code == 200:
        return {d["name"]: d["values"][0]["value"] for d in r.json().get("data", [])}
    out = {}
    for m in METRICS:  # 한꺼번에 거부되면 지표를 하나씩 다시 요청
        rr = requests.get(base, params={"metric": m, "access_token": token}, timeout=30)
        if rr.status_code == 200:
            for d in rr.json().get("data", []):
                out[d["name"]] = d["values"][0]["value"]
    return out

지표를 한꺼번에 요청했다가 거부되면 하나씩 다시 묻는 것은 API 버전과 계정에 따라 나오지 않는 지표가 있어서예요. 결과 표 끝에는 «표본이 적으면(각 3건 미만) 우열을 단정하지 말 것. 최소 5건씩 쌓고 판단.»이라는 경고가 찍혀요.

메타 공식 문서를 보면 이 숫자들은 바로 나오지 않아요. 지표 계산에 쓰는 데이터는 최대 48시간 늦을 수 있고, 2년까지 보관돼요. 2024년 7월 2일 이후 올린 게시물은 노출 수(impressions) 지표가 중단됐어요. 이 스크립트는 조회수(views)를 써요.

이 글을 쓰며 이 스크립트를 실행해 보지는 않았어요. 운영 계정의 토큰이 필요해서예요.

실제로 쌓인 표본

표지안이 붙은 것은 7월 28일·31일(A), 7월 30일·8월 1일(B) 네 편이에요. 7월 27일 것은 브랜드 특별편이라 테스트에서 뺐고, 7월 29일 것은 테스트 전에 만든 세트였어요. 8월 4일부터 10월 9일까지 올린 26편에는 표지안이 없어요.

왜 멈췄나

사흘 만에 표지 형식이 바뀌었어요

7월 29일 운영자가 다음 세트부터 릴스 골격을 바꾸자고 했어요. 표지는 모델이 안경을 집어서 쓰는 4초짜리 동작 영상이 됐고, 이미 만들어 둔 세트만 옛 골격으로 올렸어요. 테스트가 비교하던 «정지된 표지 위 제호 배치»가 새 릴스에서 사라진 거예요. 옛 골격으로 만든 마지막 A/B 세트가 8월 1일에 올라갔어요.

표지를 일부러 매번 다르게 만들기 시작했어요

8월 3일 운영자는 참고할 표지 12장을 주며 이렇게 말했어요.

«표지가 아니라 표지 폰트 글자 스타일을 베끼라는 거야. 표지는 지금도 다양하게 가고 있으니까.»

그래서 표지 글자 스타일 12종을 만들어 돌려 쓰고, 직전 두 세트와 같은 스타일이 나오면 스크립트가 멈추게 했어요. 한 가지만 바꾸고 나머지는 고정해야 하는 A/B 테스트와 반대 방향이에요.

기록을 사람 손에 맡겼어요

표지안은 세트 폴더에 사람이 표지안.txt 를 만들어 적는 방식이었어요. 파일이 없어도 발행은 그대로 되고, 발행 기록에는 «미지정»이 적혀요. 8월 4일부터는 이 파일을 만들지 않았고, 아무 경고 없이 «미지정»이 26번 쌓였어요.

9월 18일 저장소를 정리하며 남긴 설명서에는 이렇게 적혀 있어요.

표지 마스트헤드 A/B(2026-07-25 시작). 표지 골격이 V2 로 바뀌며 비교 대상이 사라졌다

대신 남은 것

조회수 비교는 몇 주가 걸리지만, 표지 글자가 배경에 묻히는지는 바로 잴 수 있어요. 8월 30일 운영자가 «계속 자산 쌓아놓자.»라고 해서 글자 스타일을 18종으로 늘렸고, 이때 실제 표지 4장(파란 하늘, 흰 벽, 백사장, 흙담)에 18종을 모두 얹어 읽히는지 쟀어요. 어느 배경에나 안전한 스타일은 3종에서 6종으로 늘었어요.

표지 그림을 넣으면 18종을 얹어 보고 잘 읽히는 순서로 줄 세우는 기능도 만들었어요. 그 전에 글자가 배경에 묻혀 표지를 급히 바꾼 일이 두 번 있었는데, 커밋 기록에는 «두 번의 사고는 이걸 안 하고 감으로 골라서 났다»고 적혀 있어요.

다시 한다면

• 테스트를 열기 전에 판정할 때까지 표지 형식을 바꿀 계획이 있는지부터 확인해요. 각 안 5편이면 최소 10편이 필요하고, 하루 한 편씩 올려도 열흘이 걸려요. 이 운영은 사흘 만에 형식이 바뀌었어요.
• 표지안 기록이 빠지면 발행 스크립트가 경고를 내게 해요. 조용히 «미지정»으로 채우면 아무도 모르고 지나가요.
• 인사이트는 발행하고 이틀이 지난 뒤에 모아요. 공식 문서에 최대 48시간 늦을 수 있다고 적혀 있어요.
• 몇 주가 걸리는 질문(어느 표지가 더 많이 보이나)과 바로 잴 수 있는 질문(글자가 읽히나)을 나눠요. 바로 잴 수 있는 것은 테스트를 기다리지 않아도 돼요.

확인하지 못한 것

• 집계 스크립트를 실제로 돌렸는지, 돌렸다면 A와 B 가운데 어느 쪽 숫자가 컸는지. 운영 저장소에는 결과가 남아 있지 않아요.
• 운영자가 테스트를 끝내자고 따로 말했는지. 기록으로는 표지 골격이 바뀌면서 멈췄어요.

근거

• Meta 개발자 문서, Instagram Media Insights · 2026-10-10 확인. 조회수 정의, 최대 48시간 지연, 2년 보관, 2024년 7월 2일 이후 게시물의 노출 수 중단이 적혀 있어요.
• 운영 저장소(인스타 자동 발행) · 2026-10-10 열어 확인. 테스트 문서(7월 25일), 집계 스크립트(7월 26일 커밋), 발행 기록(릴스 32편의 표지안 값), 7월 29일 골격 변경·8월 3일·8월 30일 커밋 메시지, 9월 18일 보관 폴더 설명서, 7월 27일 세트의 «A/B 테스트 제외» 메모.

한 안경원은 2026년 9월 말부터 이 일을 스크립트에 넘겼어요. 원고에는 «여기는 빨간색» 같은 표시만 달고, 색과 굵기가 다 입혀진 페이지는 스크립트가 만들어요. 사람은 그 페이지를 복사해 붙여 넣고 사진만 올려요.

원리

네이버 편집기는 다른 웹페이지에서 복사한 내용을 붙여 넣으면 글자 색, 굵기, 배경색, 정렬, 인용구, 구분선, 글꼴을 그대로 받아 줘요. 사진은 받아 주지 않아요. 바깥 주소의 사진은 링크로만 남고 네이버에 올라가지 않아요. 2026년 9월 30일과 10월 2일 두 번 시험해서 같은 결과를 확인했어요.

서식은 반드시 태그 안의 style="..."로 넣어야 해요. 따로 둔 CSS 파일이나 클래스는 붙여 넣는 순간 사라지거든요.

표시 정하기

강조의 성격마다 짧은 표시를 하나씩 정해요. 이 안경원이 쓰는 표시 가운데 몇 개예요.

색은 숫자(색상 코드)로 정해 코드에 박아 둬요. 매번 «무슨 빨강이었지» 하고 고르지 않게요.

축소판 스크립트

아래 코드는 원고 파일 하나를 받아 복사용 HTML을 만드는 가장 짧은 모양이에요. 실제 도구는 사진 표시와 검사까지 하지만, 서식만 필요하면 이 정도로 충분해요.

# 원고.txt 의 {빨}…{/} 같은 표시를 인라인 스타일로 바꿔 복사용.html 을 만든다
import html, re, sys, pathlib

STYLE = {
    "빨": "color:#d10000;font-weight:bold;",
    "형": "background-color:#ffe3c8;font-weight:bold;",
    "파": "color:#1f5fbf;font-weight:bold;",
}
P = "text-align:center;font-family:'Nanum Gothic';"

src = pathlib.Path(sys.argv[1]).read_text(encoding="utf-8")
out = []
for para in re.split(r"\n\s*\n", src.strip()):          # 빈 줄 = 문단 나눔
    t = html.escape(para)
    t = re.sub(r"\{(.)\}(.*?)\{/\}", lambda m: f'<span style="{STYLE[m.group(1)]}">{m.group(2)}</span>', t)
    t = re.sub(r"\*\*(.+?)\*\*", r"<b>\1</b>", t)
    if t.startswith("## "):                                # 소제목 = 인용구
        out.append(f'<blockquote style="{P}font-weight:bold;">{t[3:]}</blockquote>')
    else:
        out.append(f'<p style="{P}">' + t.replace("\n", "<br>") + "</p>")
pathlib.Path("복사용.html").write_text("<meta charset='utf-8'>\n" + "\n".join(out), encoding="utf-8")

쓰는 순서

1. 원고를 메모장이나 편집기에 쓰고 강조할 곳에 표시를 달아요.
2. python 복사용.py 원고.txt로 돌리면 복사용.html이 생겨요.
3. 그 파일을 브라우저로 열고 Ctrl+A, Ctrl+C로 전체를 복사해요.
4. 네이버 블로그 글쓰기 화면에 Ctrl+V로 붙여 넣어요. 색과 정렬이 그대로 들어와요.
5. 비워 둔 사진 칸마다 편집기의 사진 버튼으로 사진을 올려요. 사진 파일은 미리 번호를 붙여 한 폴더에 모아 두면 빨라요.
6. 태그를 넣고 발행하거나 예약을 걸어요.

막혔던 곳

강조가 적다는 지적을 세 번 받았어요

9월 29일 운영자가 이렇게 말했어요. «너무 글자 색이나 강조나 테두리 이런게 부족한거같아 좀더 이런걸 많이사용하면 좋겠어». 규칙 문서에 «강조를 넉넉히»라고 적어 뒀는데도 10월 5일과 7일에 같은 지적이 또 나왔어요.

«넉넉히»는 사람마다 달라서 지켜지지 않았어요. 그래서 강조 양을 숫자로 정하고, 강조가 하나도 없는 문단이 있으면 스크립트가 알려 주게 바꿨어요.

붙여 넣으니 빈 줄이 두 배로 생겼어요

10월 6일, 사진 칸이나 소제목 인용구 앞뒤로 빈 줄이 두 개씩 들어가서 화면이 지나치게 벌어졌어요. HTML로 바꿀 때 문단 사이를 넉넉하게 잡은 것이 네이버에서 한 줄씩 더 붙은 탓이었어요. 변환 규칙에서 빈 줄을 하나로 줄여 해결했어요.

사진 구도가 늘 같으면 걱정이 생겨요

10월 7일 운영자가 «매번 비슷한 사진구조(안경에 텍같은걸로 설명) 이게 너무 반복되면 저품질먹을거같아서»라고 했어요. 그 뒤로 사진에 설명을 다는 방식을 아홉 가지(빨간 상자, 돋보기, 번호 띠, 지시선, 두 장 비교, 네 컷 등)로 나누고, 같은 방식이 이어지지 않게 돌려 쓰고 있어요. 네이버가 반복 구도를 실제로 낮게 평가하는지는 공식 근거를 찾지 못했고, 미리 피하는 쪽을 골랐어요.

규칙은 검사로 바꿔야 지켜졌어요

머리 칸이 빠지거나 금지어가 들어간 원고는 스크립트가 페이지를 아예 만들지 않고 멈추게 했어요. 문서에 적은 규칙은 여러 번 빠졌지만, 페이지가 안 만들어지면 그 자리에서 고치게 되거든요.

근거

• 붙여 넣었을 때 살아남는 서식과 사진이 링크로 남는 현상은 2026년 9월 30일과 10월 2일 네이버 스마트에디터에서 직접 시험한 결과예요.
• 네이버 스마트에디터가 붙여 넣기를 어떻게 처리하는지 설명한 공식 문서는 찾지 못했어요.

9월 8일부터 25일까지 작업이 멈출 때마다 중단 기록을 남겼고, 그 기록이 다섯 건이에요. 한 번은 로그인 만료, 네 번은 사용 한도였어요.

중단 기록은 안 남겼지만 9월 11일에는 다른 그림을 뽑다가 주간 한도에 한 번 더 걸렸어요.

한도는 두 겹이에요

공식 안내가 밝힌 두 한도

OpenAI 공식 안내는 Plus 요금제에서 5시간 동안 쓸 수 있는 양을 추정치로 밝히고, 주간 한도도 걸릴 수 있다고 적어요. 그림 생성도 같은 한도를 써요.

Image generation counts toward the same general usage limits as local messages and cloud chats.

세션 기록에 남은 두 칸

이 PC의 Codex 세션 기록 파일에도 한도가 두 칸으로 남아 있어요. window_minutes 가 300인 칸(5시간)과 10080인 칸(7일)이 있고, 칸마다 쓴 비율(used_percent)과 풀리는 시각(resets_at, 유닉스 시간)이 적혀요. 9월 24일에 받은 풀리는 시각은 닷새 뒤인 9월 29일이었어요. 5시간 칸에서는 나올 수 없는 시간이라 주간 한도였어요. 나머지 세 번은 다섯 시간 안에 풀렸어요.

공식 안내에 적힌 확인 방법은 사용량 화면과, Codex CLI 안에서 쓰는 /status 예요.

한도에 걸린 날

한도에 걸린 날은 그림을 많이 뽑은 날이었어요. 9월 10일 새벽 기록에는 «오늘 하루에 맨얼굴 38장 + 착용컷 140장 + 버린 것들(초기 19장·8장 등)을 뽑았으니 양이 컸다»고 적혀 있어요. 그림 몇 장이면 한도에 닿는지는 공식 안내에 없어요. 공식 추정치는 메시지 수로만 나와요.

로그인은 사람이 해야 해요

9월 8일에는 Codex의 그림 도구가 401 오류를 냈어요. Codex가 남긴 보고는 이랬어요.

내장 image_gen 인증 토큰 만료(401)로 전체 작업이 중단되었습니다. CLI/API 키는 사용하지 않았습니다.

로그인 정보 파일을 보니 마지막 갱신이 11일 전이었어요. codex login 은 브라우저를 띄워 사람이 눌러야 해서 AI가 대신 할 수 없어요. 중단 기록에 운영자가 할 일로 codex login 과 확인용 codex login status 두 줄을 적었고, 운영자가 로그인한 뒤 그날 13시 2분에 갱신된 것을 확인하고 이어 갔어요.

돈이 드는 길은 사람이 정했어요

API 키 길은 쓰지 않았어요

로그인이 막혔을 때 Codex는 API 키(OPENAI_API_KEY)로 돌리는 길을 제안했어요. Claude Code는 이 길을 쓰지 않았고, 중단 기록에 이렇게 적었어요.

그건 구독이 아니라 건당 과금되는 별도 API 라서, CLAUDE.md 6번·전역 규칙 3번 「크레딧이 드는 순간은 운영자 승인 없이 진행하지 않는다」에 정확히 걸린다. 돈이 나가는 선택을 내가 대신 하지 않는다.

공식 안내에도 API 키로 쓰는 양은 API 요금으로 따로 청구된다고 적혀 있어요. 한도에 걸린 Plus·Pro 사용자는 추가 크레딧을 사서 계속 쓸 수 있고, 값은 요금제에 따라 달라요.

기다릴지 풀지는 운영자가 정했어요

9월 10일 사용 한도 때 중단 기록은 운영자에게 «아무것도 안 하셔도 된다»고 적고, 상위 요금제나 크레딧을 사는 방법이 있지만 남은 것이 일곱 제품이라 기다리는 편이 낫다고 권했어요. 그날 밤 운영자가 «착용컷이어서»라고 해서 이어 갔어요.

두 번은 운영자가 직접 한도를 풀었어요. 9월 11일에는 «주간한도 풀었으니 계속 작업해», 9월 25일에는 «한도 초기화함»이라고 했어요. 작업 기록에는 방법이 없어서 10월 11일 운영자에게 물었더니 이렇게 답했어요.

«코덱스 한도푼거는 그리고 그때 무료리셋권이있었어»

추가 크레딧을 산 것이 아니었어요.

언제 멈춰도 이어 가게 만든 것

처음 세 건의 중단 기록에는 «손대다 만 것이 있나»를 묻는 칸이 따로 있고, 답은 모두 «없음»이에요. 그렇게 만든 방법이에요.

• 제품 하나가 그림 4장이라, 4장이 다 찬 제품만 홈페이지에 붙였어요. 9월 10일 기록에는 «4장이 안 차면 어느 자리인지 확신할 수 없다»고 적혀 있어요.
• 9월 11일 중단 기록은 남은 제품을 한 번에 8개(32장)씩 묶어 시키라고 적었어요. 멈춘 때에는 그때까지 붙인 그림을 빌드하고 커밋해 두었어요.
• 홈페이지에 적은 그림 경로가 모두 실제 파일인지 스크립트로 확인한 뒤 커밋했어요.
• 그림이 아직 없는 상품은 제품 사진 한 장만 보이고, 화면이 깨지지 않게 해 두었어요.
• 중단 기록에 풀리는 시각과 몇 번 제품부터 이어 갈지를 적었어요. 그래서 운영자는 «착용컷이어서», «착용컷 이어서» 한마디로 다시 시작할 수 있었어요.
• 9월 24일 묶음은 실패해도 다시 시도하지 않게 시도 횟수를 1로 두어, 같은 그림이 겹쳐 생기지 않았어요.

따라 할 때

1. 큰 작업을 시키기 전에 /status 로 남은 양을 봐요.
2. 작업을 묶음으로 나누고, 묶음이 끝날 때마다 그대로 써도 되는 상태로 저장해요.
3. 한도에 걸리면 같은 요청을 되풀이하지 말고 풀리는 시각과 이어 갈 위치를 적어 둬요.
4. API 키나 추가 크레딧처럼 돈이 드는 길은 사람이 정한다고 규칙에 적어 둬요. AI가 먼저 그 길을 제안하기도 해요.
5. 오래 쉬었다가 시작할 때는 codex login status 로 로그인부터 확인해요.

확인하지 못한 것

• 무료 리셋권이 어떤 조건으로 주어졌는지
• 9월 10일, 11일, 25일에 걸린 한도가 5시간 칸인지 주간 칸인지. 다섯 시간 안에 풀려 5시간 칸으로 보이지만 기록에 칸 이름은 없어요.
• 그림 몇 장이면 한도에 닿는지

근거

• OpenAI, Codex 요금과 사용 한도 안내 · 2026-10-10 확인(developers.openai.com/codex/pricing 에서 이 주소로 넘어가요). 5시간 단위 추정치, 주간 한도, 그림 생성이 같은 한도를 쓴다는 문장, 추가 크레딧, API 키 요금, /status 가 적혀 있어요.
• 안경원 홈페이지 저장소의 중단 기록 다섯 건(9월 8일, 10일, 11일, 24일, 25일)과 작업일지 9월 8일·10일·11일·25일·26일 · 2026-10-10 열어 확인. 오류 문구, 멈춘 양, 풀린 시각, 운영자 말이 있어요.
• 운영자 답 · 2026-10-11. 9월 11일·25일 한도를 무료 리셋권으로 풀었다는 말이에요.
• 이 PC의 Codex 세션 기록 파일 · 2026-10-10 열어 확인. rate_limits 칸의 모양(300분 칸, 10080분 칸)만 보고 다른 내용은 옮기지 않았어요.

«메모리비울때 크롬은 끄지않도록해 다음부터는 근데 메모리비울깨마다 크롬을 끄지않는 규칙을 안볼거같은데 이거 어떻게 하면 좋아?»

그래서 규칙을 한 줄 더 적는 대신, Claude가 명령을 실행하기 직전에 스크립트가 끼어들게 했어요. Claude Code의 훅(hook)이에요. 지금 운영자 PC와 이 사이트 저장소에는 훅이 여섯 개 걸려 있어요. 이 글은 훅이 언제 돌고 어디에 거는지, 그리고 막을지·물을지·알리기만 할지를 어떻게 가르는지 그 여섯 개로 보여 드려요.

훅이 도는 때

훅은 Claude Code가 정해진 때마다 실행하는 명령이에요. 자주 쓰는 때만 추리면 이래요.

이 밖에도 대화를 압축하기 전후, 하위 에이전트가 시작하고 끝날 때 같은 때가 더 있어요. 전체 목록은 아래 «근거»의 공식 문서에 있어요.

운영자가 쓰는 때는 세 가지뿐이에요. 막는 일은 명령 직전(PreToolUse)에, 치우는 일은 답을 마칠 때(Stop)와 세션을 열 때(SessionStart)에 해요.

어디에 거나

훅은 설정 파일의 hooks 칸에 적어요. 어느 파일에 적느냐로 적용 범위가 달라져요.

운영자는 어느 프로젝트에서든 필요한 다섯 개를 사용자 설정(~/.claude/settings.json)에 걸었어요. 이 사이트에서만 쓰는 점검 알림 하나는 이 저장소의 .claude/settings.json에 걸고 커밋했어요. 그래서 이 저장소를 여는 세션이면 어느 것이든 같은 알림을 받아요.

막을까, 물을까, 알리기만 할까

훅을 만들기 전에 결정부터 골라요. 같은 위험이라도 무엇을 고르느냐에 따라 작업이 서기도 하고 계속 가기도 해요.

여섯 개를 이 기준으로 나누면 이래요.

기계가 숫자나 상태로 판단할 수 있으면 막고, 사람의 뜻을 들어야 하면 묻고, 멈출 까닭이 없으면 알리기만 해요. 묻기는 사람이 자리를 비운 동안 작업 전체를 세워 두기 때문에, 이 운영에서는 Chrome 하나에만 써요.

훅 스크립트 자체가 오류로 죽을 때도 정해 둘 수 있어요. 10월 8일 Claude Code 2.1.295에서 명령형 훅에 onFailure: "block" 설정이 생겼고, 켜면 훅이 실패했을 때 작업을 막아요(10월 둘째 주 AI 소식). 막는 훅은 스크립트가 죽으면 위험한 명령이 그대로 지나갈 수 있고, 알리는 훅은 죽어도 작업이 서지 않아야 해요. 그래서 이 설정은 막는 훅에 어울린다고 봐요. 운영자의 훅은 아직 이 설정을 쓰지 않아요.

훅 하나 거는 순서

1. Claude Code에서 /hooks를 쳐서 지금 걸린 훅부터 봐요. 읽기 전용 목록이고, 훅마다 사용자 설정·프로젝트 설정·로컬 설정·플러그인 가운데 어디서 왔는지 보여 줘요.
2. 도는 때를 골라요. 실행을 막으려면 PreToolUse, 치우려면 Stop과 SessionStart, 세션을 열 때 알려 줄 것은 SessionStart예요.
3. 결정을 골라요. Chrome은 사람이 시켰을 때는 꺼도 되는 일이라 묻기로 했어요.
4. 스크립트를 써요. 훅은 표준입력으로 JSON을 받고, PreToolUse라면 tool_input.command에 실행하려는 명령이 들어 있어요. 아무것도 찍지 않고 끝나면 평소처럼 실행돼요. 아래 예시는 Chrome을 끄려는 명령이 오면 사람에게 묻는 훅을 짧게 줄인 코드예요.

# Chrome을 끄는 명령이면 실행 전에 사람에게 묻는다(ask)
import json, re, sys

data = json.load(sys.stdin)
cmd = str((data.get("tool_input") or {}).get("command", ""))
kill_chrome = [
    r"taskkill\b.*?/+im\s+\"?chrome",           # taskkill /IM chrome.exe
    r"stop-process\b.*?-name\s+\"?chrome",      # Stop-Process -Name chrome
    r"\b(pkill|killall)\b.*chrome",
]
if any(re.search(p, cmd, re.I) for p in kill_chrome):
    print(json.dumps({"hookSpecificOutput": {
        "hookEventName": "PreToolUse",
        "permissionDecision": "ask",
        "permissionDecisionReason": "Chrome을 끄는 명령이에요. 사람이 직접 시킨 경우에만 승인하세요."
    }}, ensure_ascii=False))

permissionDecision에 deny를 넣으면 막기, ask면 묻기예요. 막을 때는 이유와 대안을 permissionDecisionReason에 꼭 적어요. Claude가 그 글을 읽고 다른 방법을 찾아요. 종료 코드 2로 끝내도 막히지만, 이유를 함께 넘기려면 JSON이 편해요.

5. 설정 파일에 등록해요. 모든 프로젝트에 걸려면 ~/.claude/settings.json에 이렇게 넣어요.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|PowerShell",
        "hooks": [
          { "type": "command", "command": "python \"C:/Users/<내 계정>/.claude/hooks/no_kill_chrome.py\"", "timeout": 10 }
        ]
      }
    ]
  }
}

matcher는 도구 이름이고, |로 여럿을 묶어요. <내 계정>은 윈도우 사용자 이름으로 바꾸세요. 윈도우에서 명령 훅은 Git Bash가 깔려 있으면 bash로, 없으면 PowerShell로 돌아요. 운영자 설정은 python 실행 파일을 전체 경로로 적어 두었어요. 훅이 도는 셸에서 python을 못 찾으면 그렇게 쓰세요.

6. timeout을 짧게 잡아요. 단위는 초이고 기본값이 600초라서, 명령마다 도는 훅이 멈추면 오래 기다리게 돼요. 운영자는 10~20초, 이 사이트 점검 훅은 30초로 잡았어요.
7. 직접 넣어 시험해요. 실행하려는 명령을 흉내 낸 JSON을 스크립트에 흘려 넣으면 돼요.

echo '{"tool_input":{"command":"taskkill /IM chrome.exe /F"}}' | python no_kill_chrome.py

2026년 10월 10일 이 글의 코드에 명령 네 개를 넣어 본 결과예요.

낱말 «chrome»이 들어 있다고 다 걸리면 문서 검색까지 막혀요. 실제로 끄는 명령의 모양만 골라내야 해요.

막혔던 곳

승인 창 때문에 작업이 자꾸 멈췄어요

Codex CLI는 두 개를 동시에 돌리면 실패해요. 이 문제로 승인 창이 뜨며 작업이 서는 일이 생기자, 2026년 9월 30일 운영자가 이렇게 말했어요.

«나는 승인땜에 레포가 멈추는 걸 진짜 넘 싫어해 코덱스가 쓸데없이 도는거 직접확인후 판단해서 종료하는 방향은 안돼?»

지금 코덱스 지킴이는 묻지 않아요. 부르기 직전과 답을 마칠 때, 세션을 열 때 코덱스 프로세스를 직접 봐요. 부모 프로세스가 이미 죽은 것과 40분 넘게 돌았는데 CPU가 2초 동안 거의 움직이지 않은 것은 꺼요. 일하는 중인 것이 있으면 새 호출만 막고, «끝나면 다시 하라»는 이유를 Claude에게 돌려줘요. 운영자가 직접 연 코덱스 창은 건드리지 않아요. 이 일은 검색 명령 하나가 PC를 멈춘 날의 «다음 날 생긴 일»에도 적었어요.

시간 제한이 끝나도 grep이 살아 있었어요

9월 29일 메모리를 61GB까지 먹은 grep 하나가 PC를 멈춰 세웠어요. 도구의 시간 제한으로 Claude 쪽 명령만 끝나면 실제 grep 프로세스는 남아서 계속 자랄 수 있어요. 그래서 명령 직전에 막는 훅과, 답을 마칠 때마다 남은 것을 치우는 훅을 한 쌍으로 걸었어요. 사고 경위는 검색 명령 하나가 PC를 멈춘 날에 자세히 적었어요.

같은 폴더가 두 번 등록돼 상태 표시가 사라졌어요

같은 9월 29일, VS Code에서 연 폴더는 경로가 소문자 드라이브(c:/Users/...)로 넘어와 이미 쓰던 폴더(C:/Users/...)와 다른 폴더로 등록됐어요. 신뢰하지 않은 쪽에서는 상태 줄 같은 명령이 실행되지 않아 사용량 표시가 사라졌어요. 지금은 세션을 열 때 훅이 이미 신뢰한 폴더와 대소문자만 다른 항목을 찾아 신뢰를 맞춰요. 처음 보는 폴더를 새로 신뢰하지는 않고, 바꾸기 전에 설정 파일을 백업해요.

예약해 둔 점검이 세션과 함께 사라져요

이 사이트는 AI가 스스로 주간·월간 점검을 해요. 2026년 10월 10일 Claude Code의 예약 실행으로 점검을 걸어 보니, 예약은 그 세션 안에서만 살고 반복 예약은 7일 뒤 끝난다고 나왔어요. 그래서 저장소의 점검 스크립트를 세션을 열 때마다 돌리는 SessionStart 훅을 같이 걸었어요. 밀린 것이 없으면 아무것도 찍지 않고, 있으면 한 줄만 찍어 Claude가 읽는 맥락에 넣어요. 실패해도 세션이 열리도록 항상 0으로 끝나요.

근거

• Claude Code 공식 문서, Hooks reference · 2026-10-10 확인. 이벤트, 설정 파일 위치, permissionDecision 값(allow·deny·ask·defer), 종료 코드 2, 기본 timeout 600초, 윈도우의 기본 셸, 세션 시작 훅의 평문 출력이 맥락에 들어가는 것이 적혀 있어요.
• 운영자 PC의 사용자 설정과 훅 스크립트 다섯 개 · 2026-10-10 열어 확인. 기준값(반복 100, 10분·4GB, 40분·CPU)과 운영자 말은 스크립트 머리 주석과 운영자의 작업 규칙 문서에서 그대로 옮겼어요.
• Claude Code 변경 기록 · 2026-10-10 확인. 2.1.295(10-08)의 onFailure: "block" 항목이에요.
• 이 사이트 저장소의 프로젝트 설정과 점검 스크립트 · 2026-10-10.
• 글 속 예시 코드는 2026-10-10에 명령 네 개를 넣어 실제로 돌려 봤어요.

역할 나누기

맡기지 않는 일도 정해 두었어요. 법적 금지선 판단, 말투 검수, 되돌리기 어려운 변경, 커밋은 메인 창이 직접 해요. 하위 담당은 커밋하지 않아요.

하위 에이전트 만들기

Claude Code는 역할 파일을 하나 두면 그 역할을 맡은 하위 에이전트를 따로 띄워요. 하위 에이전트는 자기만의 대화 맥락과 도구 목록을 가져서, 조사하면서 읽은 수십 개 파일이 메인 창을 채우지 않아요.

1. ~/.claude/agents/ 폴더에 마크다운 파일을 하나 만들어요. 모든 프로젝트에서 쓰려면 이 폴더, 한 프로젝트에서만 쓰려면 그 프로젝트의 .claude/agents/예요.
2. 파일 맨 위에 이름과 설명, 쓸 도구, 모델을 적어요. 메인 창은 이 설명을 읽고 언제 이 역할을 부를지 정해요.
3. 그 아래에 이 역할이 지킬 규칙을 평소 말로 적어요.
4. 도구는 역할에 필요한 만큼만 줘요. 조사 담당에게는 읽기와 검색 도구만 주는 식이에요.

조사 담당 파일은 이런 모양이에요.

---
name: researcher
description: 자료 조사와 파일 탐색 담당. 여러 파일을 훑어 사실을 모아 온다. 발행용 문장은 쓰지 않는다.
tools: Read, Grep, Glob, Bash, WebSearch, WebFetch
model: sonnet
---
너는 조사 담당이다. 모르는 것은 추측하지 말고 «확인 못 함»이라고 적는다.
숫자와 날짜에는 출처 경로나 주소를 붙인다. 파일은 읽기만 하고 고치지 않는다.

Codex에게 그림 맡기기

부르는 명령

Codex CLI의 codex exec는 대화 화면 없이 한 번 실행하고 끝나는 명령이에요. 결과가 표준출력으로 나와서 스크립트가 받아 쓰기 쉬워요.

cat 프롬프트.txt | codex exec --sandbox workspace-write -c "sandbox_workspace_write.writable_roots=['C:/Users/<내 계정>/.codex']" -

<내 계정>은 윈도우 사용자 이름으로 바꾸세요. -c 뒤의 값은 TOML 문법이라 목록을 작은따옴표 대괄호(['...'])로 써요. Codex가 만든 그림은 .codex 폴더 아래에 저장되는데, 이 폴더를 쓰기 허용 목록(writable_roots)에 넣어 줘야 Codex가 방금 만든 그림을 다시 읽어요(«막혔던 곳»에 적었어요).

써 보니 달랐던 점

써 보면서 알게 된 것이 몇 가지 있어요.

• 한글 프롬프트를 명령 뒤에 바로 붙이면 윈도우에서 글자가 깨졌어요. 파일로 만들어 넘기고, 끝에 -를 붙여 표준입력에서 읽게 하세요.
• 두 개를 동시에 돌리면 실패했어요. 반드시 하나가 끝난 뒤 다음을 거세요.
• 결과 파일은 Codex가 답에 적어 준 경로에서 가져오되, 이번 호출 뒤에 새로 생긴 파일인지 꼭 확인하세요. 답에 첨부 그림 경로를 되풀이해 적는 일이 있었거든요.
• 그림 폴더를 날짜순으로 뒤져 «가장 최근 파일»을 가져오는 방식은 쓰지 마세요. 다른 창에서 Codex를 쓰고 있으면 남의 결과와 섞여요.

맡긴 뒤에 할 일

하위 담당의 보고는 그대로 믿지 않고 원본과 맞춰 봐요. 이 사이트 글을 준비할 때도 조사 담당 여덟을 동시에 띄웠는데, 처음 돌아온 보고 가운데 여섯이 읽지 못한 파일을 남긴 채였어요. 하나씩 돌려보내 마저 읽게 했고, 정리된 재료와 원본 기록이 다른 곳도 찾아 글에서 바로잡았어요.

서로 엮이지 않은 일은 한 번에 같이 띄우면 시간이 줄어요. 이때도 Codex만은 예외예요. 맡기는 것은 동시에 해도 되지만 실행은 하나씩이에요.

막혔던 곳

Codex 연결이 매번 끊겼어요

처음에는 Claude Code가 MCP로 Codex를 불렀는데, 어느 날부터 세션을 열 때마다 연결이 닫혔다는 오류가 떴어요. 확인해 보니 Codex CLI 0.154.0부터 MCP 서버로 띄우는 명령 자체가 없어졌어요. 9월 23일부터 Bash에서 codex exec를 직접 부르는 방식으로 모두 바꿨어요.

그림 11장 가운데 1장만 맞게 나왔어요

같은 날 --sandbox workspace-write만 붙여 그렸더니, Codex가 방금 만든 그림을 다시 찾지 못한다는 오류를 내고 엉뚱한 그림을 뽑기 시작했어요. 그때 기록은 Codex 설정 파일(~/.codex/config.toml)의 샌드박스 값을 명령이 덮어쓴 탓으로 봤고, 샌드박스 값을 빼서 풀었어요. 그날 시험에서는 writable_roots를 더해도 안 됐다고 적혀 있어요.

Codex를 0.155.1로 올린 뒤에는 위 예시처럼 --sandbox workspace-write와 함께 .codex 폴더를 writable_roots에 넣는 방식이 정상으로 동작했어요. 지금은 이 방식으로 불러요. 버전에 따라 결과가 달랐으니, 쓰는 버전에서 그림 한 장으로 먼저 시험해 보세요.

윈도우에서 Codex의 셸 기능이 늘 실패했어요

이 PC에서는 Codex에게 셸 명령이나 파일 저장을 시키면 매번 권한 오류가 나고 세션이 응답하지 않았어요. 그래서 Codex에게는 그림 생성만 맡기고, 파일을 옮기고 고치는 일은 Claude 쪽이 해요.

근거

• Claude Code 공식 문서, Subagents · 2026-10-10 확인. 역할 파일 위치와 이름·설명·도구·모델 칸이 적혀 있어요.
• OpenAI Codex 공식 문서, Non-interactive mode · 2026-10-10 확인. codex exec 사용법과 샌드박스 단계가 적혀 있어요.
• MCP 서버 명령이 없어진 버전(0.154.0)은 운영자가 쓰던 Codex에서 확인한 값이에요. OpenAI 릴리스 노트에서는 찾지 못했어요.

그리스 신화 웹툰을 준비하면서 이 문제를 겪었고, 등장인물 481명을 설계해 설정집과 룩북 814장을 뽑았어요.

설정집과 룩북

설정집은 인물 한 명을 한 장에 모은 그림이에요. 얼굴, 표정 여섯 가지, 앞·옆·뒤 전신과 키, 대표 동작, 소품, 색상표가 들어가요.

룩북은 그 인물의 옷차림을 모은 그림이에요. 한 장에 세 벌씩, 앞모습과 뒷모습, 허리띠나 신발 같은 부분 확대를 같이 그려요.

만드는 순서

1. 그림을 그리기 전에 설계표부터 써요. 인물마다 키, 실루엣, 한눈에 알아볼 표시 하나, 대표 색 하나, 소품 하나, 그리고 «이렇게는 그리지 않는다»를 한 줄로 적어요. 표에 없는 인물은 그리지 않아요.
2. 비슷한 인물끼리 겹치지 않는지 봐요. 실루엣, 머리 모양, 대표 색 가운데 두 가지 이상이 달라야 컷이 작을 때도 구분돼요.
3. 설정집을 한 장씩 뽑아요. 처음 한 장이 마음에 들면 그 그림을 기준 그림으로 정해 두세요.
4. 룩북 장수는 등장 횟수로 정해요. 이 작업에서는 사건에 10번 넘게 나오는 인물이 세 장(아홉 벌), 4~9번이 두 장, 그보다 적으면 한 장이었어요.
5. 그림을 뽑을 때마다 기준 그림을 실제 파일로 첨부해요. «이런 그림체로»라고 글로만 쓰면 결과가 흔들리더라고요.
6. 프롬프트 맨 앞에는 같은 안내문을 매번 붙여요. 기준 시트와 같은 선과 채색, 같은 칸 구성으로 그리고, 제목 띠나 표어 같은 글자는 넣지 말라는 내용이에요.
7. 주요 인물 몇 명을 먼저 뽑아 기준 시트와 나란히 놓고 봐요. 그림체가 맞으면 나머지를 진행해요.
8. 컷을 그리는 단계에서는 시트에 적힌 모습 말고는 새로 지어내지 않아요. 대본에도 시트의 묘사를 그대로 옮겨 써요.

Codex로 기준 그림을 붙여 그릴 때는 명령이 이런 모양이에요. 프롬프트는 파일로 만들어 넘겨야 한글이 깨지지 않았어요.

cat 프롬프트.txt | codex exec -i 설정집_기준.png -i 그림체_기준.png -

막혔던 곳

참고 그림 4장이 지워졌어요

9월 24일, 그림을 대신 뽑아 주는 스크립트가 참고로 붙여 둔 그림체 시안 4장을 지웠어요. Codex가 그림을 못 만든 채 답에 첨부받은 그림 경로를 적었는데, 스크립트는 «답에 나온 마지막 그림이 결과물»이라고 믿고 그 파일을 옮긴 뒤 원본을 치웠거든요. 같은 일이 네 번 일어났고, 참고 그림이 사라지자 그날 41장이 실패했어요.

결과물로 잘못 저장된 사본 4장이 남아 있어서 그것으로 되살렸어요. 그 뒤로 스크립트는 어떤 파일도 지우지 않고, 프롬프트에 적힌 경로가 아니면서 이번 호출이 시작된 뒤에 새로 생긴 파일만 결과로 받아요.

흔들린 그림 57장을 다시 뽑았어요

같은 날 스크립트를 새로 바꾸고 한 장만 확인한 채 대량으로 돌렸더니, 선과 채색이 기준과 다른 그림이 57장 나왔어요. 그 뒤로 도구나 프롬프트를 조금이라도 바꾸면 5장만 먼저 뽑아 보고 넘어가요.

설계표 158명이 가짜였어요

인물이 수백 명이라 설계표 일부를 스크립트로 채웠는데, 검수해 보니 158명은 이름으로 값을 대충 배정한 것이었어요. 실루엣이 비슷하다는 경고가 잇달아 뜨면서 드러났어요. 결국 계열별로 20~30명씩 나눠 사람이 한 명씩 다시 썼고, 검수를 통과하기 전에는 정본 표에 합치지 않기로 했어요.

사용 한도

Codex 그림은 구독료 안에서 뽑지만 5시간 단위와 1주 단위 한도가 있어요. 9월에는 1주 한도가 두 번 차서 며칠씩 멈췄어요. 한도에 걸리면 다시 시도하지 말고, 풀리는 시각을 확인해 두고 그때 이어 가는 편이 나아요. 사용 기록 파일(~/.codex/sessions/ 아래)에 남은 rate_limits 값에서 쓴 비율과 풀리는 시각을 볼 수 있어요.

근거

• OpenAI, Codex 요금과 사용 한도 안내 · 2026-10-10 확인. 5시간 단위로 쓸 수 있는 양은 추정치로만 밝히고, 주간 한도는 걸릴 수 있다고만 적어요. 위 «사용 한도» 절의 내용은 2026년 9월 사용 기록에서 확인한 값이에요. 한도에 걸렸을 때 이어 간 방법은 Codex 중단 기록 글에 있어요.
• 그림 두 장은 이 작업에서 실제로 기준으로 쓴 설정집과 룩북이에요. Codex로 그렸어요.

어떻게 옮겼나

1. 글 원본을 마크다운 파일로 두고, 빌드 스크립트가 HTML과 사이트맵, RSS를 만들게 했어요.
2. Cloudflare Workers에 정적 파일로 올리고 도메인을 연결했어요. 조회수만 따로 세는 작은 데이터베이스(D1)를 붙였어요.
3. 서치 콘솔에 도메인 속성으로 등록했어요. 도메인을 산 곳과 DNS가 같은 Cloudflare 계정이라 소유 확인 기록이 자동으로 붙었어요.
4. 빙 웹마스터 도구에도 같은 사이트맵을 냈고, 글을 올릴 때마다 IndexNow로 검색엔진에 알리게 했어요.
5. 발행 속도는 블로거 때의 매일 1편에서 주 3편(월·수·금)으로 줄였어요. 편마다 출처와 내부 링크를 더 챙기는 쪽을 골랐어요.

옛 블로거 블로그는 지우지 않았어요. 처음에는 옛 글에 안내 문구를 넣고 새 주소로 돌려보낼 계획이었는데, 운영자가 9월 22일에 이렇게 말했어요. «블로거가 합쳐지면 오히려 어지러울거같아 걍 냅두자». 자동으로 새 주소로 넘기는 스크립트는 검색엔진이 속임수로 볼 위험이 있어서 쓰지 않았어요.

10일째 숫자

9월 30일, 운영자가 «평균대비 어느상태이고 어떻게 되고있는지 분석해줘»라고 해서 숫자를 모았어요. 그때 사이트에는 글 376편이 있었고 사이트맵 주소는 530개였어요.

숫자에서 가려낸 것

AI 크롤러가 구글보다 먼저 왔어요

AI 검색 쪽 크롤러가 구글봇의 4배쯤 왔어요. 그중 ChatGPT 사용자 요청으로 찍힌 297건은 사람이 AI에게 물어서 우리 글을 읽게 된 흔적으로 봤어요. 빙은 IndexNow 알림은 받았지만 열흘 동안 거의 오지 않았어요.

조회수가 너무 고르게 나왔어요

자체 조회수는 열흘 동안 1,048회였어요. 그런데 350편에 고르게 퍼져 있었고, 글마다 조회수가 사이트에 올라가 있던 날수에 거의 비례했어요. 사람이 고른 글이라면 이렇게 고를 리가 없어요. 자바스크립트를 실행하는 로봇이 모든 글을 골고루 훑은 흔적으로 판단했고, 이 조회수로는 인기 글을 고르지 않기로 했어요.

진짜 사람은 검색으로 들어온 40명이었어요

GA4에서 «직접 방문» 204회는 평균 5초 만에 나갔어요. 검색으로 들어온 40회는 절반쯤이 글과 상호작용했고 평균 49초를 머물렀어요. 열흘째에 믿을 만한 숫자는 이 40회와 서치 콘솔 클릭 22회 정도였어요.

처음 열흘을 볼 때

• 조회수 순위로 인기 글을 고르지 마세요. 몇 주 뒤 서치 콘솔의 페이지별 클릭으로 다시 보세요.
• 서버 요청은 사용자 에이전트로 나눠 보세요. AI 크롤러, 검색엔진, 점검 도구, 브라우저로만 나눠도 그림이 달라져요.
• «새 사이트가 몇 달 뒤 방문 몇 명이면 평균»이라는 공개 통계는 찾지 못했어요. 남과 견주기보다 지난주의 내 숫자와 견주는 편이 나아요.

막혔던 곳

9월 27일 뒤로 서치 콘솔을 못 읽었어요

숫자를 읽던 브라우저 확장 연결이 끊겨서 서치 콘솔과 GA4 최신 값을 며칠 못 봤어요. 10월 1일에 다시 연결해 9월 18일~27일 구간을 보강해 읽었어요. 서치 콘솔 색인 보고서는 그때까지도 9월 21일 값에 머물러 있었어요.

근거

• Blogger API v3, Posts 자료 설명 · 2026-10-10 확인
• 숫자는 2026년 9월 30일·10월 1일 사이트 점검 기록(서버 요청 분류, 자체 조회수, 서치 콘솔, GA4)에서 옮겼어요.

API가 다루지 못하는 것

블로거 API의 글(Posts) 자료에 들어 있는 칸은 제목, 본문, 라벨, 상태, 위치, 그림 정도예요. 아래 항목은 칸 자체가 없어요.

오류 없이 사라진 검색 설명

이 부분이 가장 큰 함정이었어요. 자동 발행 코드가 글마다 검색 설명을 customMetaData라는 칸에 담아 보냈는데, 블로거는 오류도 내지 않고 그 값을 버렸어요. 글(Posts) 자료에 그런 칸이 없거든요. 41편을 다시 올리면서 모두 «성공»으로 찍혀서 한참 뒤에야 알았어요.

글을 올린 뒤에는 실제 페이지 소스를 열어 <meta name="description">에 무엇이 들어갔는지 확인해 보세요. API 응답이 성공이어도 내 값이 들어갔다는 뜻은 아니더라고요.

다만 공을 많이 들일 일은 아니에요. 2026년 9월 6일 다섯 블로그를 견줘 보니, 글마다 다른 설명을 쓴 두 곳의 색인 수가 오히려 가장 적었어요. 설명은 검색 결과에 보이는 문구를 바꿀 뿐이고, 색인이 되느냐 마느냐를 정하지는 않았어요.

주소가 무의미하게 나오는 문제

블로거는 글 주소를 제목에서 만들어요. 제목에 라틴 문자가 하나도 없으면 blog-post_12.html 같은 기본 주소로 떨어져요. 일본어 블로그 28편이 모두 이렇게 나갔고, 영어 제목 107편은 한 편도 그러지 않았어요.

이미 색인된 주소는 나중에 바꾸면 손해가 커서 그대로 두었어요. 한글 블로그라면 처음부터 제목에 영어 낱말을 하나 섞는 방법이 있어요. 아니면 편집 화면에서 처음 올릴 때 주소를 직접 정하세요.

자동 발행 전에 손으로 끝낼 일

블로그를 새로 만들었다면 아래를 순서대로 한 번씩 끝내고 자동 발행을 켜세요.

1. 설정에서 검색엔진에 블로그가 보이도록 켜요. 꺼져 있으면 글을 아무리 올려도 색인에서 통째로 빠져요.
2. 블로그 제목과 설명, 언어, 시간대를 맞춰요.
3. 메타 태그에서 검색 설명 쓰기를 켜요. 이게 꺼져 있으면 글 편집 화면에 검색 설명 칸이 아예 안 보여요.
4. HTTPS 리디렉션을 켜요.
5. 크롤러와 색인 설정에서 보관함과 검색 결과 페이지만 색인하지 않게 둬요.
6. 서치 콘솔에 등록하고 사이트맵을 내요.
7. 목차와 소개, 개인정보 처리방침 페이지를 만든 뒤 레이아웃 화면에서 메뉴에 올려요.

막혔던 곳

모바일 리디렉션 오류가 계속 남았어요

서치 콘솔에서 리디렉션 오류를 고쳤다고 확인을 눌렀는데 9월 19일에 다시 실패가 떴어요. 블로거는 휴대폰으로 들어온 크롤러를 ?m=1 주소로 한 번 보내는데, 이 동작은 설정으로 끌 수 없어요. 테마에 막는 스크립트를 넣으면 모바일 화면이 깨질 위험만 커져서 손대지 않았어요.

이 일이 쌓여서 결국 블로그 한 곳은 자체 도메인 사이트로 옮겼어요. 옮긴 뒤의 이야기는 관련 글에 따로 적었어요.

근거

• Blogger API v3, Posts 자료 설명 · 2026-10-10 확인. 칸 목록에 주소 지정 칸과 검색 설명 칸이 없어요.
• 색인 수와 주소 사례는 2026년 9월 블로그 다섯 곳 운영 기록에서 확인한 값이에요.

«'결입니다' '자리입니다' 이런 추상적인 표현들이 블로그에서 되게 별로인 것 같아. 다음 발행글부터 저런 추상적인 거 말고 좀 더 직관적으로 써 줘.»

규칙 문서에 한 줄을 더했어요. 그런데 8월 26일에 같은 지적이 또 나왔어요.

«쓸데없는 비유 은유가 너무 많아. 결이니 뭐니, 선이 눈썹을 덮고 떨어지니 그런 은유적 표현 금지했을 텐데 안 지켜지는 거 보니까 좀 더 강조해.»

문서에 적은 금지는 AI가 글을 쓸 때마다 지켜지지 않았어요. 9월 15일 운영자는 «AI 티가 너무 많이 나서… 앞으로는 모든 글 쓸 때 이 규칙 적용해서 쓸 거야. 블로그, 플레이스, 인스타 캡션 등 글 쓰는 모든 곳에.»라고 했고, 그날 원고를 올리기 전에 스크립트가 검사하는 장치를 만들었어요.

실제로 걸린 문장

8월 1일에 지적받은 문장과 그날 고친 문장이에요.

첫 문장은 동사 없이 끝나서 무슨 상황인지 안 읽혔고, 둘째 문장은 «색이 남는다»가 무슨 뜻인지 독자가 풀어야 했어요. 고친 문장은 누가 무엇을 하고 있는지, 무엇이 눈에 띄는지 그대로 써요.

그런데 8월에 고친 문장도 9월에 생긴 규칙에는 다시 걸려요. 아래 그림이 이 글의 검사 코드로 세 문장을 실제로 돌린 결과예요. 셋째 문장은 이 글을 쓰며 쉼표만 빼 본 문장이에요.

어떤 표현이 AI 티로 읽히나

안경원 블로그 규칙에 모인 것 가운데 자주 나온 것만 추렸어요.

연결어미 뒤 쉼표는 이 블로그에서 가장 많이 나온 AI 티였어요. 참고한 공개 분류 체계는 이 쉼표를 기계가 사람보다 4.8배 자주 쓴다고 재어 두었어요.

검사기 만드는 순서

1. 지적받은 문장을 날짜와 함께 모아요. «별로다»라는 느낌만 적지 말고 실제 문장을 그대로 남겨야 나중에 무엇을 막을지 정할 수 있어요.
2. 문장마다 무엇이 문제인지 이름을 붙여요. 쉼표, 은유, 추상 어미처럼 갈래로 나누면 비슷한 문장을 한 번에 잡을 수 있어요.
3. 목록은 한 파일에만 둬요. 이 블로그도 규칙이 두 문서에 나뉘어 있다가 9월 15일 운영자의 «규칙이 둘이면 그 규칙을 하나로 개편해.» 한마디로 합쳤어요. 한쪽만 고치면 다른 쪽이 낡아요.
4. 막을 것과 알리기만 할 것을 갈라요. 지금 이 블로그는 19가지를 막고(검사가 멈춤), 37가지는 알리기만 해요. 참고한 공개 분류 체계는 긴 칼럼용이라, 짧은 매장 글에 맞게 항목마다 막을지 알릴지 볼지 말지를 골랐어요.
5. 검사 코드를 써요. 아래는 그 구조를 짧게 줄인 코드예요. 걸린 곳이 있으면 2로 끝나서, 올리기 전 단계에서 멈출 수 있어요.

# 블로그 원고에서 AI 티 나는 표현을 찾는다. 목록은 이 파일 한 곳에만 둔다.
import re, sys

RULES = [
    # (이름, 찾을 모양, 고치는 법)
    ("연결어미 뒤 쉼표", r"(?<![사창보참최중광])고,|[가-힣](?:으며|며|지만|면서|아서|어서),", "쉼표를 빼거나 문장을 끊는다"),
    ("물건이 사람처럼 움직이는 말", r"살아납니다|떨어져 나옵니다|부딪히지|묻힙니다|굽이칩니다|스며듭니다|번집니다|감돕니다|남습니다", "눈에 보이는 대로 쓴다"),
    ("추상 어미", r"쪽입니다|결입니다|자리입니다|축에 듭니다|로 읽힙니다", "무엇이 어떤지 바로 쓴다"),
    ("상투 도입·마무리", r"결론적으로|정리하자면|크게 (?:두|세|네) 가지로|다음과 같은", "빼고 바로 본론"),
]

text = open(sys.argv[1], encoding="utf-8").read()
found = 0
for no, line in enumerate(text.splitlines(), 1):
    for name, pat, fix in RULES:
        for m in re.finditer(pat, line):
            found += 1
            print(f"{no}행 [{name}] «{m.group(0)}» → {fix}")
print(f"걸린 곳 {found}개")
sys.exit(2 if found else 0)

쉼표 규칙의 (?<![사창보참최중광])는 «사고,» «광고,»처럼 명사 끝의 «고»를 빼려고 넣었어요. 처음에는 «하고,»처럼 좁게 잡았다가 «얇고,» 같은 흔한 꼴을 놓쳐서 넓혔어요.

6. 원고를 올리기 전에 돌려요. python check.py 원고.txt 처럼 파일 하나를 넣으면 걸린 행과 고치는 법이 나와요.
7. 이미 올린 글은 검사하지 않아요. 파일을 고쳐도 게시된 글은 바뀌지 않고, 못 고치는 경고가 빨갛게 쌓이면 사람이 검사기 출력을 안 보게 돼요.

고칠 때 지킬 것

검사기에 걸린 문장을 고치다가 새 AI 티를 만들기 쉬워요. 안경원 블로그 검사 스크립트 맨 위에 적힌 원칙 넷이에요.

• 주장의 강도를 바꾸지 않아요. «해야 한다»를 «한다»로, «일 수 있다»를 단정으로 바꾸지 않아요.
• 핵심 낱말은 남겨요. 꾸밈말만 덜어내고 제품명·모양·색은 그대로 둬요.
• 고치면서 새 AI 티를 넣지 않아요. 쉼표를 빼다가 다른 곳에 쉼표를 더하면 그것도 실패예요.
• 손대지 않을 것을 정해 둬요. 고유명사·제품명·모델명, 숫자·날짜, 따옴표로 옮긴 말, API·UV 같은 업계 약어는 그대로 둬요. 이 블로그에서는 안경테에 새겨진 글자가 여기에 들어가요.

막혔던 곳

문서에 적은 금지가 계속 샜어요

은유를 쓰지 말라는 규칙은 이미 문서에 있었는데(운영자 말의 «금지했을 텐데»), 8월 26일에 같은 지적이 두 번 나왔어요. 두 번째 말은 «선으로 남느니 뭐니, 결이 어떠니, 남는 자리이니 그딴 거 좀 쓰지 마»였어요. 규칙서에는 «남는다»와 «결»이 동사처럼 멀쩡해 보여서 특히 잘 샌다고 적혀 있어요. 그래서 목록을 문서에서 꺼내 검사 스크립트로 옮겼어요.

고정 문구 한 곳이 수십 개 원고에 퍼져 있었어요

쉼표가 가장 많이 걸린 곳은 여러 원고에 똑같이 들어가는 고정 문구였어요. 규칙서 기록에 따르면 그 한 곳을 고치니 원고 파일 36개가 같이 고쳐졌어요. 걸린 곳이 많으면 개별 원고보다 여러 원고가 함께 쓰는 문구부터 보세요.

검사기가 못 잡는 것

• 동사 없이 끝난 문장은 이 코드가 못 잡아요. 검사 결과 그림의 첫 문장 «아이보리 니트 위»가 그래요. 이런 것은 사람이 소리 내어 읽으며 봐요.
• 목록에 없는 새 유행어는 못 잡아요. 지적받을 때마다 목록에 더해야 해요.
• «너무 매끈하다», «누가 썼는지 모르겠다» 같은 인상은 규칙으로 못 잡아요. 이 사이트의 말투 규칙에도 그런 지적을 규칙으로 못 잡는 것이라고 따로 적어 두었어요.

비슷한 일이 서식에서도 있었어요. «강조를 넉넉히»라고 적어 둔 규칙이 세 번 어겨진 뒤 숫자로 바꾼 이야기는 복사용 페이지 글에 있어요.

근거

• 안경원 블로그 저장소의 글쓰기 규칙서와 발행 가이드 · 2026-10-10 열어 확인. 운영자 말(8월 1일, 8월 26일 두 번, 9월 15일 두 번), 지적받은 문장과 고친 문장, 은유 금지 표, 막는 19가지·알리는 37가지, 고정 문구 36개 파일 기록이 있어요.
• 같은 저장소의 문체 규칙 스크립트(2026-09-15 커밋) · 쉼표 규칙의 실제 모양과 «고칠 때 지킬 것»의 원문이 있어요.
• im-not-ai, 한국어 AI 티 분류 체계 · 2026-10-10 주소 확인. 안경원 블로그 규칙이 항목 번호와 «사람 대 AI 밀도» 숫자(쉼표 4.8배)를 가져온 공개 자료예요. 이번 글을 쓰며 분류 체계 본문을 다시 읽지는 않았어요.
• 글 속 검사 코드는 2026-10-10에 세 문장을 넣어 실제로 돌려 봤어요.

Claude 이용정책에 «기만 행위» 조항이 생겨요

Anthropic이 10월 8일 이용정책 개정을 발표했어요. 11월 12일부터 적용돼요. 정치든 장사든 남을 속이는 활동을 한데 모아 금지하는 조항이 새로 생겼고, 가짜 계정과 꾸며 낸 콘텐츠가 예로 들어가 있어요.

달라지는 점은 후기나 리뷰를 AI로 지어내 올리는 자동화예요. 실제 손님이 남기지 않은 후기를 만들어 내는 일은 이 조항에 정면으로 걸려요. 우리 가게 소개글을 AI로 쓰는 것과는 다른 얘기예요.

• Anthropic, 2026 Usage Policy update · 2026-10-08

Claude Haiku 5.5가 나왔어요

10월 7일 Claude Code 2.1.293에서 Haiku 5.5가 기본 Haiku 모델이 됐어요. 한 번에 100만 토큰까지 읽고, 값은 입력 100만 토큰에 0.1달러, 출력 100만 토큰에 0.5달러예요. 10만 토큰이 넘는 긴 입력은 입력 0.5달러, 출력 2.5달러예요.

달라지는 점은 비용이에요. 글 초안 검사나 파일 분류처럼 되풀이되는 가벼운 일을 하위 에이전트로 넘길 때 이 모델을 쓰면 비용이 크게 줄어요.

• Claude Code 변경 기록 · 2.1.293, 2026-10-07

Claude Code에 «Mods»와 훅 막기 설정이 들어왔어요

10월 1일 2.1.287에서 Claude Mods가 추가돼 플러그인이 Claude Code의 동작을 더 깊이 바꿀 수 있게 됐어요. 10월 8일 2.1.295에서는 명령형 훅과 HTTP 훅에 onFailure: "block" 설정이 생겼어요.

달라지는 점은 안전장치예요. 지금까지는 검사용 훅 스크립트가 오류로 죽으면 그냥 통과되는 경우가 있었어요. 이 설정을 켜면 훅이 실패했을 때 작업을 막아요. 사고를 막으려고 훅을 걸어 둔 분이라면 켜 둘 만해요.

• Claude Code 변경 기록 · 2.1.287(10-01), 2.1.295(10-08)

Suno가 말소리 모델을 내놨어요

Suno가 10월 1일 Speech 베타를 공개했어요. 말소리와 그 뒤에 깔리는 음악을 한 번에 만드는 모델이에요. 10월 5일에는 곡을 앨범으로 묶어 발행하는 기능이, 10월 8일에는 박자 찾기와 클립 길이 늘이기, 페이드 곡선 조절이 들어간 Studio 개선이 나왔어요.

달라지는 점은 영상 내레이션이에요. 목소리와 배경음을 따로 만들어 맞추던 일을 한 번에 해 볼 수 있어요. 수익을 내는 영상에 쓰려면 유료 요금제로 만든 결과물이어야 하니 요금제부터 확인하세요.

• Suno 릴리스 노트 · 2026-10-01, 10-05, 10-08

Runway에서 Seedance 2.5를 초안으로 싸게 돌려요

10월 2일 Runway의 Agent 도구에 Seedance 2.5 초안 모드가 들어왔어요. 480p로 빠르게 초안을 뽑고, 마음에 드는 것만 생성 뒤에 화질을 올리는 방식이에요. 모든 요금제에서 쓸 수 있어요. 같은 날 Runway가 OpenAI의 Dots에도 들어갔어요.

달라지는 점은 크레딧이에요. 영상 AI는 한 번 뽑을 때마다 크레딧이 나가서 시험을 몇 번 못 하는데, 낮은 화질로 여러 번 돌려 본 뒤 고르면 덜 써요.

• Runway 변경 기록 · 2026-10-02

ChatGPT 아이폰 앱에서 Codex 작업을 바로 열어요

10월 2일 아이폰용 ChatGPT에 홈 화면 위젯이 생겨서, 내 컴퓨터에서 돌린 최근 작업과 사용 한도를 볼 수 있어요. 10월 7일에는 Codex 작업 링크를 앱에서 바로 여는 기능이 더해졌어요.

달라지는 점은 밖에서 확인하기예요. PC에 Codex 작업을 걸어 두고 나왔을 때 휴대폰으로 진행 상황과 남은 한도를 볼 수 있어요.

• ChatGPT·Codex 변경 기록 · 2026-10-02, 10-07

한국 개인 사용자에게는 아직 먼 소식

10월 8일 OpenAI가 GPT-6.1 Sol의 Ultrafast 모드를 냈어요. 월 500달러 Pro 요금제와 일부 기업·교육 요금제에서만 쓸 수 있고, 처리 지역도 미국과 유럽뿐이에요. 일반 요금제 사용자에게는 당장 바뀌는 것이 없어요.

이번 호에서 뺀 것

네이버 블로그 피드 개편과 검색 순위 변화 소식은 네이버의 공식 공지를 찾지 못해 실지 않았어요. 카카오의 AI 전략 발표는 10월 13일 행사라 다음 호에서 다룰게요.