세 줄 요약
- 매일 작업 내역을 수집해 글로 만들고 자동 발행하는 블로그 파이프라인을 플랫폼 선정부터 계정 인증까지 정의했다. 발행 채널은 GitHub Pages(Hugo + PaperMod)로 확정.
- 어제 여러 세션에서 각각 수정한 내용이 충돌해 전부 날아간 사고 때문에, 자동 커밋과 자동 발행의 실행 순서를 다시 짰다. 커밋 23:30 → 발행 00시.
- 이 글의 수집 데이터에는 커밋이 0건, 변경 라인이 +0/-0, 프로젝트 집계가 “없음"으로 잡혔다. 파이프라인이 자기 자신을 만드는 첫 회차라서 그렇다.
1. 개발일지 블로그를 “완전 무인"으로 정의했다
오늘의 본 작업은 코드가 아니라 정의였다. 요구사항은 명확했다. 매일 여러 프로젝트를 오가며 작업하는데, 그날 무엇을 했는지가 자동으로 글이 되고, 정해진 시간에 자동으로 올라가야 한다. 사람이 붙는 구간이 하나라도 상시로 남으면 그건 무인이 아니라 그냥 반자동이다. 최종 목표는 방문자 유입을 통한 광고 수익화다.
플랫폼은 GitHub Pages 정적 블로그로 못 박았다. 테마는 PaperMod. 선정 근거는 취향이 아니라 자동화 가능성 한 줄이다.
git push하나로 배포가 끝난다. 로그인 폼도, 캡차도, 세션 만료도 없다.
워드프레스나 티스토리 같은 호스팅형 플랫폼은 글을 올리는 순간이 곧 브라우저 자동화 구간이 된다. 로그인 세션이 만료되면 파이프라인은 조용히 멈추고, 그 사실을 며칠 뒤에 알게 된다. 정적 사이트 + git push 조합은 실패해도 exit code로 튀어나온다. 무인 운영에서 “조용히 실패하지 않는 것"은 “빠른 것"보다 훨씬 중요하다.
GitHub 계정은 liquidation-man으로 잡았고, 여기서 파생된 원칙이 하나 더 붙었다. 개인정보는 전부 가린다. 금액, 계정 식별자, API 키, 고객 정보는 수집 단계에서 마스킹 토큰으로 치환된 상태로 글 생성기에 들어온다. 생성기는 원문을 볼 수 없고, 복원할 방법도 없다. 참고로 오늘 넘어온 데이터에는 마스킹 토큰이 하나도 등장하지 않았다. 오늘 다룬 소재 자체에 민감정보가 없었다는 뜻이다.
2. 진짜 문제는 시각이 아니라 순서였다
어제 사고가 있었다. 여러 세션에서 같은 저장소를 동시에 건드렸고, 자동 커밋이 돌 때 충돌이 나면서 수정 사항이 통째로 유실됐다. 그래서 오늘 먼저 한 일이 “오늘 자동 커밋 되기 전에 충돌이 없는지 판단"이었다. 커밋을 실행하는 게 아니라, 커밋이 안전한 상태인지를 선행 점검하는 단계를 앞에 세운 것이다.
그다음이 순서 재배치다. 블로그 자동화를 매일 23시에 돌리기로 했었는데, 이 상태에는 구조적 결함이 있다.
- 23:00 — 오늘 작업을 요약해 글을 쓴다
- 23:xx — 자동 커밋이 오늘 작업을 저장소에 반영한다
글이 먼저 나가고 커밋이 나중에 붙으면, 글은 항상 오늘의 마지막 작업을 놓친다. 수집기가 보는 것은 커밋 로그인데, 아직 커밋되지 않은 작업은 존재하지 않는 것과 같다. 그래서 순서를 뒤집었다. 커밋 23:30, 발행 00시. 하루 치 작업이 전부 저장소에 들어간 뒤에 그걸 읽어서 글을 만든다.
여기서 정직하게 남겨둘 것이 하나 있다. “자동 커밋은 며칠 주기 몇 시로 스케줄링돼 있는지” 현재 등록값을 확인하는 작업을 요청했지만, 그 조회 결과는 오늘 수집 데이터에 남아 있지 않다. 실제 스케줄러 등록이 커밋 23:30 / 발행 00시로 반영 완료됐는지는 이 글 시점에서 확인 못 함. 그리고 이 글 자체의 타임스탬프는 2026-07-25T23:30:00+09:00이다. 목표한 00시가 아니라 커밋과 같은 시각이다. 즉 순서 역전 위험이 아직 남아 있고, 내일 첫 항목으로 검증해야 한다.
Windows 작업 스케줄러에 파이썬 스크립트를 등록해 자동 실행하는 구성에서 사람들이 대개 신경 쓰는 건 트리거 시각과 반복 주기다. 하지만 여러 자동화가 같은 저장소를 공유하는 순간 진짜 변수는 작업 간 선후 관계가 된다. 두 작업이 30분 간격으로 등록돼 있어도, 앞 작업이 40분 걸리면 순서는 그냥 뒤집힌다. 시각으로 순서를 흉내 내는 대신, 뒤 작업이 앞 작업의 산출물(커밋 해시)을 확인하고 시작하게 만드는 편이 안전하다.
3. 무인 파이프라인에 딱 하나 남은 사람 개입 구간
gh auth login. GitHub CLI 인증은 브라우저를 띄워 사람이 승인해야 한다. 자동화로 우회할 수 있는 성격이 아니고, 우회해서도 안 되는 구간이다.
그래서 오늘 진행 방식은 “순서대로 하되, 인증 단계에서는 브라우저를 띄우고 사람이 직접 승인"이었다. 이 지점을 없애려 애쓰는 대신 최초 1회로 몰아넣고 명시하는 쪽을 택했다. 한 번 인증하면 이후 push는 저장된 자격증명으로 돌아간다. 무인 자동화라는 말은 사람이 0번 개입한다는 뜻이 아니라, 정상 동작 중에는 0번이라는 뜻이다.
4. 게임 프로젝트는 원점으로 되돌렸다
병렬로 진행 중인 로그라이크 게임 쪽에서는 정반대 방향의 결정이 나왔다. “뭐 하는 게임인지 모르겠다, 목표가 뭔지, 위험요소가 뭔지, 재미 요소도 그렇고” — 기획을 다시 하기로 했다.
만들다 만 것을 이어 붙이는 것보다, 한 줄 정의가 안 나오는 상태에서 코드를 더 쌓는 게 훨씬 비싸다. 플레이어가 무엇을 원하고, 무엇이 그걸 막고, 실패하면 무엇을 잃는지가 정리되지 않으면 밸런싱 수치는 근거 없는 숫자일 뿐이다. 오늘은 재기획 착수까지이고, 산출된 기획 문서는 아직 데이터에 없다.
막혔던 것들
| 문제 | 대응 |
|---|---|
| 세션 간 동시 수정 → 커밋 충돌로 작업 유실 | 커밋 전 충돌 선행 점검 단계 추가 |
| 발행이 커밋보다 먼저 돌아 마지막 작업 누락 | 커밋 23:30 → 발행 00시로 순서 재배치 |
gh auth login은 비대화형 실행 불가 | 최초 1회 수동 인증으로 격리, 이후 토큰 사용 |
| 수집 결과가 커밋 0건 / 프로젝트 없음 | 원인 미확인 — 내일 수집기 커버리지 점검 |
오늘 배운 것
하나. 무인 자동화가 깨지는 지점은 대부분 각 작업이 잘못 동작해서가 아니라, 서로의 순서를 잘못 가정해서다. 어제의 유실 사고도, 오늘의 커밋 0건도 전부 순서 문제였다.
둘. 파이프라인이 자기 자신을 관측 대상에 포함하면 첫 회차는 반드시 비어 보인다. 오늘 총계가 커밋 0개 · +0/-0 라인으로 찍힌 건 아무 일도 안 해서가 아니라, 오늘 한 일이 “그 일을 기록하는 장치"였기 때문이다. 이럴 때 빈 데이터를 그럴듯한 수치로 채우면 그 순간부터 이 블로그의 모든 숫자는 신뢰를 잃는다. 없으면 없다고 쓰는 게 유일하게 지속 가능한 선택이다.
셋. 사람이 반드시 필요한 구간은 제거 대상이 아니라 격리 대상이다.
내일 할 일
- Windows 작업 스케줄러 실제 등록값 조회 — 커밋 23:30, 발행 00시가 맞게 들어갔는지 확인. 오늘 미확인 상태.
- 수집기 커버리지 점검 — 프로젝트 집계가 “없음"으로 나온 원인 파악. 커밋이 없어서인지, 수집 경로가 좁아서인지 구분.
- 첫 자동 발행 실검증 — 사람 개입 없이 글 생성부터
git push, GitHub Pages 빌드까지 통과하는지. - 게임 프로젝트 한 줄 정의 작성 — 목표 / 위험요소 / 재미 요소 세 항목부터.