블로그 자동화는 글쓰기에서 끝나지 않는다

AI가 그럴듯한 글을 써 주었다면, 이제 공개해도 될까요? 문장이 자연스러워도 논문의 다른 실험을 한 결과처럼 섞었을 수 있습니다. 그림에 출처를 붙였지만 사용 조건은 확인하지 않았을 수도 있습니다. 검토 뒤 문장을 고쳤다면, 앞서 받은 검토가 지금 원고에도 적용되는지 다시 물어야 합니다.

JJo의 블로그 자동화는 이 간격을 다루는 작업입니다. 초안을 빨리 만드는 것뿐 아니라, 무엇을 읽고 설명했으며 어떤 버전을 검토했고 무엇이 실제로 공개됐는지를 구분하려 합니다. 이 글은 AI로 기술 글을 제작하려는 사람을 위한 운영 과정 기록입니다. 읽고 나면 ‘작업표를 준비했다’, ‘검토했다’, ‘공개를 확인했다’가 왜 다른 상태인지 설명할 수 있는 것이 목표입니다.

절차 설명의 시작 기준은 2026년 10월 9일이며, 아래 현재 범위는 10월 23일 비공개 운영 기록과 대조했습니다. 실제 원고를 나눠 검토하고 작업 연결을 수정한 사례와, 로컬에서 검사한 코드가 있습니다. 그러나 모든 연구 원고의 검수가 끝났거나, 클라우드에서 매일 글을 만들고 여러 채널에 자동 발행하는 전체 시스템이 검증됐다는 뜻은 아닙니다.

#지금 운영 기록에서 확인할 수 있는 범위

10월 23일 다시 확인한 비공개 대상 대기열은 45편입니다. 연구 입력 저장소에는 이 대상 밖의 콘텐츠와 같은 글의 수정 이력도 들어 있으므로, 그 저장 건수를 검수 완료 글 수로 세지 않습니다.

최근 작업에서는 현재 에이전트가 원문·보충자료를 읽고 새 비공개 수정본을 만들었습니다. 여러 글의 원고가 보완됐어도, 최신 수식 목록·그림 권리·검색 자료·다섯 독자 관점·실제 화면 검토가 모두 끝난 것은 아닙니다. 일부 비공개 미리보기 빌드가 성공한 것과 공개 사이트 배포는 별개입니다. 10월 23일에는 Luna를 지정한 하위 에이전트 세 작업의 실제 호출과 종료를 확인했습니다. 세 작업의 결과는 모두 미완료 항목을 남겼으며, 그 지적을 한 비공개 수정본에 통합했습니다. 요청한 모델 이름을 도구가 인증한 실행 모델 신원으로 쓰지는 않습니다. 이번 갱신에서 GitBlog 공개 배포·Blogger 발행은 하지 않았습니다.

운영 상태를 확인할 때에는 어느 글의 어느 버전인가, 실제로 통과한 검사는 무엇인가, 다음에 필요한 근거는 무엇인가를 함께 보아야 합니다. ‘준비됨’이나 파일 개수 하나만으로 전체 완료를 판단할 수 없습니다.

#1. 먼저 묻는 것은 ‘몇 편 쓸까?’가 아니다

출발점은 독자가 답을 얻을 질문입니다. 발전소 뉴스를 다룬다면 “용량이 늘었다는 말은 전기를 이미 그만큼 더 만들었다는 뜻일까?”를 먼저 물을 수 있습니다. 여기서 필요한 것은 어려운 용어 목록이 아니라, 낼 수 있는 출력의 규모와 일정 시간 실제로 만든 전기의 양을 구분하는 설명입니다. MW와 MWh를 처음 보는 독자에게는 두 단위가 가리키는 양부터 준비해야 합니다.

같은 질문을 더 깊게 읽는 사람에게는 비교 조건, 운전 시간, 계산에 넣은 가정과 발표가 확인한 범위를 이어 줍니다. 쉬운 요약 뒤에 전문 용어를 갑자기 붙이거나, 학력별로 같은 정의를 반복하는 대신 한 사례를 점점 정밀하게 설명하는 방식입니다. 연구가 말한 결과와 설명자가 이해를 돕기 위해 만든 사례도 나눕니다.

이 기준은 글의 길이나 그림 수를 품질로 바꾸지 않습니다. 필요한 개념을 먼저 정의했는지, 비교 대상을 같은 조건에서 읽을 수 있는지, 조건이 바뀌면 어느 결론이 달라지는지 살핍니다. 설명에 도움이 되지 않는 수식이나 인포그래픽은 추가하지 않습니다. 이 과정 글도 문장과 작은 사례로 관계를 설명합니다.

#2. 에이전트는 일하고, 하네스는 연결을 지킨다

에이전트는 자료를 실제로 읽고 판단하며 원고를 만드는 작업자입니다. 출처 담당은 주장과 원문을 대조하고, 방법 담당은 수식·단위·분석 조건을 살피며, 편집 담당은 독자가 설명을 따라갈 수 있는지 확인합니다. 역할을 나눈다는 것은 각자 다른 근거를 들고 와 서로의 판단을 검토할 기회를 만든다는 뜻입니다.

하네스는 그 일을 이어 주는 코드와 규칙입니다. 어떤 자료와 원고를 검토하는지 묶고, 빠진 결과를 표시하며, 원고나 검사 기준이 바뀌었을 때 오래된 판정을 그대로 사용하지 못하게 합니다. 체크리스트가 붙은 작업표를 만들었다고 누군가 원문을 읽은 것은 아닙니다. 파일의 버전이 맞는다는 검사도 내용이 정확하다는 판단을 대신하지 않습니다.

실제 운영에서는 역할별 작업 준비와 수행을 구분했습니다. 작업 지시를 만들고 다음 역할이 받을 설명을 연결하는 것은 준비입니다. 그 뒤 자료를 열어 검토하고, 어떤 주장과 위치를 확인했는지 결과를 남겨야 수행입니다. 하네스가 작업표를 만들었다는 사실만으로 모델을 자동 호출했다고 기록하지 않습니다.

#3. 원문·수식·그림은 양쪽으로 대조한다

원문에서 원고로 가는 검토는 “핵심 근거를 빠뜨리지 않았는가?”를 묻습니다. 본문뿐 아니라 필요한 방법 절과 보충자료를 읽고, 핵심 그림·패널·식·절차를 목록에 연결합니다. 못 읽은 범위는 미확인으로 남깁니다. PDF에서 텍스트를 추출한 성공과 그 자료의 검토 완료는 다릅니다.

반대로 원고에서 원문으로 가는 검토는 “이 설명은 어디에서 왔는가?”를 묻습니다. 원고의 수치와 계산, 그림, 방법 설명이 실제 근거로 돌아가는지 봅니다. 논문에 명시된 식, 표기를 바꾼 설명, 선행 방법, 교육용 계산을 구분합니다. 수식이 없는 발표라면 절차와 물리량을 문장으로 검토하지, 형식을 채우려고 식을 발명하지 않습니다.

실제 산업 발표 검토에서는 서로 다른 계약의 용량을 합산한 부분과, 원고에 이미 있는 교육용 계산이 검토 목록에서 빠진 부분을 발견했습니다. 숫자만 다시 계산해 끝낼 문제가 아니었습니다. 어느 계약의 값인지, 회사가 말한 이유인지 독립적으로 확인한 사실인지, 확인한 문서에 없다는 말인지 공개 자료 전체에 없다는 말인지까지 범위를 고쳤습니다. 이 사례의 연구 검토가 진행됐다는 사실은 미디어·독자·화면 검수까지 끝났다는 뜻은 아닙니다.

그림도 같은 방식으로 읽습니다. 사진은 외형과 환경을, 설명 도식은 관계를, 측정 그래프는 조건에 따른 결과를 보여 줄 수 있습니다. 다른 발전소의 사진은 배경 설명에 쓸 후보가 될 수 있어도 이번 계약의 공사 완료를 증명하지 못합니다. 캡션에는 먼저 볼 부분, 비교 조건, 관찰할 수 있는 결과와 알 수 없는 것을 가까이 적습니다. 자료의 출처 표시와 이용 조건 확인 역시 별개로 살핍니다.

실제 연구 검토에서는 도판 설명만 보고 분석 대상이 확정됐다고 해석한 최초 판정을 철회한 일도 있었습니다. 다른 검토 결과와 본문·보충자료를 대조해 불일치를 남겼습니다. 검토자가 자신 있게 말했거나 여러 역할이 작업을 끝냈다는 사실은 원문의 불일치를 없애 주지 않습니다.

#4. 병렬 검토는 같은 버전을 볼 때 의미가 있다

원고가 준비됐고 서로의 결과를 기다릴 필요가 없는 검토는 나눠 진행할 수 있습니다. 출처, 수식과 방법, 주장과 근거의 연결을 각각 검토한 뒤 부모 에이전트가 의견을 모으는 방식입니다. 같은 문단의 지적은 한 수정 묶음으로 합쳐 사실 오류, 빠진 연결, 가독성 순서로 처리합니다. 이번 시험에서는 출처, 수식, 주장 연결을 나눠 검토했습니다. 부모는 결과에서 같은 대상을 가리키는 지적을 모으고, 비교 표의 분모와 시험 기간의 해석을 수정했습니다. 세 작업이 종료됐어도 원문 전체·독자·공개 화면 검수가 남아 있어 글 전체 통과로 기록하지 않았습니다.

현재 역할 세션 코드는 역할별 지시와 빈 결과 틀을 준비하면서 ‘아직 실행하지 않음’을 명시합니다. 병렬 호출에 필요한 인수도 만들 수 있지만, 실제 에이전트 도구를 호출하는 단계는 별도입니다. 따라서 ‘Luna 프로필 작업표가 있다’는 사실만으로 Luna가 실행됐다거나, 구독 사용량으로 병렬 검수가 끝났다고 판단하지 않습니다. 확인할 것은 요청한 모델 이름뿐 아니라 실제 호출·종료 기록과 그 작업자가 제출한 근거입니다.

그러나 역할이 많다고 검토가 자동으로 독립적이거나 정확해지지는 않습니다. 비전공자·학생·연구자 관점을 맡긴 모델 검토는 설명의 도약을 찾는 편집 점검입니다. 실제 학생이나 교수에게 읽혀 학습 효과를 측정한 실험으로 쓰지 않습니다. 작업 시간이나 토큰 절감량도 측정 자료 없이 배수로 주장하지 않습니다.

같은 파일을 여러 작업자가 동시에 고치면 의견과 버전이 섞일 수 있습니다. 그래서 검토 범위와 맡은 파일을 나누고, 원고 수정은 모아서 적용합니다. 예를 들어 검토 뒤 그림을 교체했다면 새 그림의 권리·캡션·설명 연결과 실제 표시를 다시 확인해야 합니다. 제목만 바뀌더라도 주장 범위가 달라졌는지 살펴야 합니다.

이를 위해 원고·근거·설정의 파일 내용이 같은지 확인하는 해시를 사용합니다. 해시는 파일 내용에서 계산한 식별값이며 과학적 정확성을 보증하는 점수가 아닙니다. 입력이나 기준이 바뀌면 이전 통과 기록은 이력으로 보존하되 현재 버전의 근거로 복사하지 않습니다. 실제 재개 과정에서는 원고를 새로 쓰지 않고 오래된 연결 위치만 보완한 뒤, 현재 자료를 대상으로 다시 검토한 사례도 있었습니다.

#5. 검토 통과와 공개 승인은 별개다

출처 검토가 끝났다는 말은 그 범위에서 주장을 확인했다는 뜻입니다. 독자 설계가 끝났다는 말은 질문과 필요한 개념, 설명 순서를 정했다는 뜻입니다. 아직 만들지 않은 그림의 화면 검사까지 앞선 역할에 요구하면 작업이 막히지만, 설계가 끝났다고 글 전체를 공개할 수 있는 것도 아닙니다.

공개 전에는 현재 원고와 미디어, 대상 채널, 필요한 검토 결과를 함께 확인하고 운영자가 허용한 범위를 대조합니다. 과거에 특정 글이나 변경의 반영·배포를 승인받았더라도, 지금의 다른 글·수정본·미디어까지 자동으로 승인된 것은 아닙니다. 유효한 승인 범위 안에서는 같은 질문을 반복하지 않지만, 승인 자체를 과학·권리·검색·독자·화면 검수의 통과로 쓰지는 않습니다. 원고나 자산이 바뀌면 필요한 재검토·재승인을 확인하고, Blogger와 Instagram의 채널 권한이나 연결 범위를 함께 넓히지 않습니다.

새 글의 공개에는 실제 Google Search Console 또는 Naver 검색 데이터를 먼저 확인하는 정책도 적용합니다. 10월 22일 연결된 브라우저에서 웹 검색·3개월 보고서를 확인했으며, 실제 표시 기간은 8월 18일부터 10월 20일까지였습니다. 검색어는 0행이고 페이지 표에는 홈 한 행만 있었습니다. ‘검색 도구를 조회하지 못함’과 ‘조회했으나 기사별 검색어를 얻지 못함’은 다른 상태입니다. 이 실적 표로 모든 글의 색인 상태나 검색 수요 부재를 판정할 수는 없습니다. 일반 웹 검색이나 모의 자료의 검사 성공으로 기사별 검색 자료를 대체하지 않습니다. 이 과정 글 역시 초안으로 보관하며, 저장소에 파일이 있다는 사실을 사이트 공개 완료로 기록하지 않습니다.

이 구분 덕분에 기다릴 일과 진행할 일도 나눌 수 있습니다. 원문 접근이나 권리 허가가 필요한 항목은 확인 범위와 재개 조건을 남깁니다. 그 자료 없이도 가능한 설명 설계나 허용된 사진 후보 조사는 진행할 수 있지만, 후보를 찾았다는 이유로 미완료 검토를 통과시키지는 않습니다. 기존 과학 원고를 이 과정 글의 작성이나 공개 승인만으로 발행 준비 완료라고 표시하지도 않습니다.

#6. CI, 배포, 공개 화면은 서로 다른 확인이다

GitBlog에서는 원고가 사이트로 만들어지는 빌드와 자동 검사부터 확인합니다. CI, 즉 변경을 반영할 때 실행하는 자동 검사에서는 문법 오류나 깨진 내부 구조를 발견할 수 있습니다. 그러나 빌드가 성공해도 인용이 주장을 뒷받침하는지, 모바일에서 긴 식이 넘치는지, 그림이 설명과 맞는지는 별도입니다.

다음은 승인된 변경이 실제 배포에 반영됐는지 확인하는 일입니다. 저장소의 변경, 배포 작업의 성공, 독자가 보는 공개 주소는 서로 다른 관찰 대상입니다. 로컬 미리보기에서 글을 봤다는 기록을 공개 페이지 확인으로 바꾸지 않습니다. 공개 주소를 다시 열어 제목과 본문, 이미지, 수식, 내부·외부 링크를 확인해야 합니다.

특히 화면에는 파일 검사로 알 수 없는 문제가 나타납니다. 상세 조사표가 기본 화면을 가리거나, 출처를 펼친 뒤 원래 읽던 위치로 돌아가기 어렵거나, 홈에서 긴 글의 전문이 이어질 수 있습니다. 데스크톱과 모바일에서 실제 표시를 보고, 핵심 설명과 한계는 기본 본문에 남기며 긴 유도와 상세 근거는 필요할 때 찾아갈 수 있게 배치합니다.

운영 기록도 저장 후 다시 읽는 기준을 적용합니다. 저장 요청이 생성된 것과 값이 반영된 것은 다르고, 값이 맞는 것과 화면이 읽기 좋은 것도 다릅니다. 실제 기록 전달에서는 대상 값과 기존 내용을 다시 대조하고 재시도 중복을 확인했습니다. 이 확인 범위를 매일 전체 제작의 성공이나 모든 공개 글의 재검수로 확대하지 않습니다.

#7. 과정 글은 같은 기준 원본에서 이어 고친다

SSOT는 Single Source of Truth, 같은 설명을 여러 곳에서 따로 고쳐 서로 어긋나지 않도록 기준 원본을 하나 정하는 방식입니다. 이 운영 설명에는 기준 원본이 있고, 공개 글은 그중 공개 가능한 내용을 옮긴 파생본입니다. 계정 정보, 개인 파일 위치, 내부 작업 식별자는 독자가 과정을 이해하는 데 필요하지 않으므로 공개하지 않습니다.

기준 원본의 설명과 실행 사실의 기록도 구분합니다. 절차가 바뀌면 관련 설명과 변경 이유를 고치고, 실제 수행 결과는 확인한 범위에 맞춰 남깁니다. 단순한 상태 조회를 새로운 구현 완료로 적지 않습니다. 작업 중 다른 편집이 발견되면 최신 내용을 다시 읽고 보존하며, 오래된 본문으로 덮어쓰지 않습니다.

앞으로도 같은 과정 글에서 달라진 절차와 시행착오를 설명하는 것이 목표입니다. 새 실행마다 비슷한 일지를 공개 글로 늘리기보다, 독자가 알아야 할 차이를 해당 절에 반영합니다. 기준 원본이 바뀌었다고 공개 페이지도 자동 수정되는 것은 아닙니다. 공개본을 갱신할 때에는 검토·승인·배포·공개 확인의 단계를 다시 거칩니다.

#8. 클라우드로 옮길 수 있는 것과 아직 연결할 것

다른 환경으로 옮길 때 필요한 것은 하네스 코드뿐만이 아닙니다. 역할 설정, 스킬, 운영 문서와 테스트를 함께 가져가야 같은 절차를 재현할 수 있습니다. 인증 정보와 개인 운영 데이터를 공개 배포 묶음에 넣지 않고, 원문과 사진은 이용 조건에 맞게 별도로 다뤄야 합니다. 새 환경에서는 파일 무결성, 의존성 설치, 작업 준비와 실제 수행을 차례로 확인해야 합니다.

이전 인계 과정에는 설치와 파일 해시·테스트용 실행을 확인했다는 기록이 있습니다. 다만 이 갱신에서는 당시 클라우드 환경과 전체 테스트 결과를 다시 검증하지 않았으므로 숫자를 현재의 성공 건수로 제시하지 않습니다. 코드 검사가 통과한 기록이 있더라도 테스트 입력을 실제 기사·모델 실행·발행 검수로 바꾸어 해석할 수 없습니다.

과거 기록의 서브에이전트 실행, Sheets 전달, main 반영, CI·배포·공개 확인은 각각 원래의 실행 근거와 해당 콘텐츠 버전으로 확인해야 합니다. 이 갱신에서는 그 이력을 전수 재검증하지 않았으므로 현재의 운영 성공 사례로 묶어 제시하지 않습니다. 요청한 모델 이름, 실제 호출 기록, 도구가 인증한 모델 신원도 서로 다릅니다. 모델 신원을 확인하지 못했다면 미확인으로 남깁니다. Blogger 발행과 다음 예약 실행의 성공, 아직 검수되지 않은 연구 원고의 공개 역시 별도 확인 대상입니다.

공개 후 분석 역할을 준비할 때에도 같은 경계를 적용해야 합니다. 실제 공개 관찰이 현재 작업 기록과 맞는지 확인한 뒤 후속 작업을 열어야 합니다. 모의 자료로 연결을 시험한 결과는 실제 기사 분석이나 새 게시 권한을 뜻하지 않습니다.

Blogger에는 별도의 간격이 있습니다. 로컬 게시 어댑터에는 API로 글을 만들거나 수정하는 경로가 있지만, 클라우드 인계 묶음에 그 게시 도구와 계정 인증까지 포함한 것은 아닙니다. 새 환경에서는 게시 도구와 필요한 의존성, 그 환경에서 사용할 인증을 별도로 검증해야 합니다. 인증 정보는 공개 원고나 배포 묶음에 넣지 않으며, 로그인 가능 여부와 실제 게시·수정·공개 화면 확인도 각각 살펴야 합니다.

채널별 글의 역할도 다릅니다. Blogger에서는 한두 핵심 관계를 그 글 안에서 이해할 수 있게 설명하고, GitBlog에서는 필요한 모형·방법·비교 조건과 원문까지 깊게 이어 읽게 합니다. 교차 링크만 붙이고 현재 글의 답을 미루지 않습니다. 자동화의 다음 목표는 더 많은 통과 표시가 아니라, 설명과 실제 공개 화면 사이의 간격을 줄이는 일입니다.

결국 블로그 자동화의 완료 조건은 “AI가 글을 썼다”가 아닙니다. 독자의 질문에 답하는 설명을 만들고, 그 설명의 근거와 사용 조건을 확인하고, 같은 버전에 대한 검토와 승인을 거쳐, 독자가 보는 결과를 다시 확인하는 것입니다. 무엇이 끝났고 무엇이 남았는지 다음 작업자와 독자가 구분할 수 있을 때, 자동화가 글쓰기의 속도뿐 아니라 운영의 신뢰성에도 기여할 수 있습니다.