블로그 자동화 범위 제한 환경변수 복구, 전체 재실행 비용·중복 막기
블로그 자동화 범위 제한 환경변수 복구의 핵심은 스크립트보다 먼저 BLOG_PREP_PREFIX를 지정하는 거예요. 2026년 8월 19일에는 공개 발행이나 새 r0819 작업 생성 없이 기존 ready 일부만 다시 조립됐으며 별도 비용도 발생하지 않았어요.
--help가 구현되지 않은 스크립트에서는 도움말 확인 시도도 실제 main 실행이 될 수 있기 때문이다
읽기 전에 확인할 근거
블로그 자동화 범위 제한 환경변수 복구의 핵심은 스크립트보다 먼저 BLOG_PREP_PREFIX를 지정하는 거예요. 2026년 8월 19일에는 공개 발행이나 새 r0819 작업 생성 없이 기존 ready 일부만 다시 조립됐으며 별도 비용도 발생하지 않았어요.
이번 일은 도움말을 확인하려고 prep_publish.py에 --help를 붙이면서 시작됐어요. 보통 익숙한 프로그램에서는 사용법만 보여주고 멈추지만, 모든 파이썬 파일이 그렇게 움직이는 건 아니에요. 도움말 입력을 알아보고 종료하는 코드를 프로그램 안에 따로 만들어 둬야 해요.
도움말을 물었는데 왜 조립이 시작됐을까요
확인한 prep_publish.py에는 --help를 읽거나 도움말을 출력한 뒤 종료하는 처리가 없었어요. 파일 끝에서는 실행 여부를 확인한 다음 main을 바로 호출합니다. 명령 뒤에 --help가 붙어 있어도 main으로 들어가는 구조였어요.
Python 공식 문서는 sys.argv를 명령줄에서 전달된 인자 목록이라고 설명해요. 쉽게 말하면 Python은 “--help라는 글자가 함께 들어왔다”는 사실을 프로그램에 전달할 뿐이에요. 그 글자를 보고 무엇을 할지는 프로그램 코드가 정해야 합니다.
택배 상자에 ‘문의’라고 적어 두었다고 자동으로 배송이 멈추지는 않는 것과 비슷해요. 분류기가 그 표시를 알아보도록 만들어 두지 않았다면 평소 배송 과정이 계속됩니다. 이번 prep_publish.py도 같은 상태였어요.
실제로 영향을 받은 범위는 어디까지였나요
영향은 로컬 조립 단계에 머물렀어요. 기존 ready 일부가 다시 만들어졌지만 블로그 공개 발행은 실행되지 않았고, r0819 접두사의 새 작업도 생성하지 않았어요. 큐의 공개 상태 변화나 외부 서비스 비용도 없었습니다.
- 공개 발행: 하지 않았어요.
- 새 r0819 작업 생성: 하지 않았어요.
- 기존 ready 파일: 일부가 다시 조립됐어요.
- 외부 유료 호출과 복구 비용: 발생하지 않았어요.
여기서 ready 재조립과 공개 발행을 섞어 말하면 안 돼요. ready는 게시 화면에 넣기 전의 로컬 조립물이에요. 이 파일이 다시 만들어졌다는 사실만으로 인터넷에 새 글이 올라간 것은 아닙니다.
발행큐 전체가 수정됐다거나 575건이 바뀌었다고 단정할 근거도 없어요. 이번 기록에서 확정할 수 있는 범위는 기존 ready 일부가 재조립됐다는 데까지예요.
BLOG_PREP_PREFIX는 어디에서 범위를 줄일까요
범위 제한의 실제 소유 위치는 publish/prep_publish.py의 main이에요. main은 BLOG_PREP_PREFIX 환경변수를 읽고, 값이 있으면 각 작업 ID가 그 문자열로 시작하는지 비교합니다. 시작 문자열이 다르면 그 작업은 조립 반복문에서 건너뛰어요.
예를 들어 오늘 작업 ID가 모두 r0819_로 시작한다면 BLOG_PREP_PREFIX도 r0819_로 맞추는 방식이에요. 그러면 조립기는 큐 전체를 같은 대상으로 보지 않고, ID의 첫 부분이 맞는 작업만 다음 검사로 넘깁니다.
이 장치는 새 작업을 만들어 주는 기능이 아니에요. 공개 발행 버튼도 아닙니다. 이미 큐에 들어 있는 작업 가운데 어떤 ID를 조립 대상으로 볼지 좁히는 필터예요. 그래서 큐에 r0819_ 작업이 없다면 접두사를 지정해도 새 작업이 생기지 않아요.
왜 PowerShell에서 먼저 지정해야 할까요
Microsoft Learn에 따르면 PowerShell 현재 프로세스의 환경변수는 그 세션에서 시작한 자식 프로세스에 전달돼요. PowerShell에서 BLOG_PREP_PREFIX를 먼저 정한 다음 Python을 실행하면 prep_publish.py가 그 값을 읽을 수 있는 이유예요.
순서가 중요해요. 먼저 조립기를 시작한 뒤 접두사를 정하는 것이 아니라, 조립기를 시작하기 전에 현재 PowerShell 세션에 범위를 넣어야 합니다. 창고 문을 연 뒤 출고 구역을 정하는 게 아니라 문을 열기 전에 오늘 출고 구역을 표시하는 셈이에요.
현재 세션에만 지정하는 방식은 사용자 또는 컴퓨터 전체에 영구 설정하는 것보다 이번 복구에 잘 맞아요. 작업창을 벗어난 다른 자동화까지 같은 접두사를 계속 물려받게 만들 필요가 없기 때문이에요.
광범위한 재실행을 피한 이유
전체 재실행은 확인해야 할 범위를 불필요하게 키워요. prep_publish.py는 접두사가 비어 있으면 큐의 작업을 차례로 검사합니다. 상태 조건에 맞는 작업이 많을수록 ready 파일과 오류 기록을 다시 확인할 양도 늘어날 수 있어요.
이번 사고에서는 공개 글을 되돌리거나 큐 전체를 새로 만들 이유가 없었어요. 공개 발행이 없었고 새 r0819 작업도 생기지 않았기 때문입니다. 이미 좁게 확인할 수 있는 문제에 전체 큐 재실행을 붙이면 복구보다 재검수 일이 더 커져요.
그래서 복구 원리는 단순해요. 먼저 오늘 작업의 공통 접두사를 정하고, 큐 안에 그 접두사의 작업이 실제로 있는지 확인한 다음, 같은 PowerShell 세션에서 필요한 조립만 실행하는 거예요.
다시 실행하기 전 확인할 순서
첫째, 오늘 조립할 작업 ID의 공통 시작 문자열을 확인해요. 날짜가 8월 19일이라는 이유만으로 r0819_라고 추측하지 말고 실제 큐의 ID와 글자까지 맞춰야 합니다.
둘째, 현재 PowerShell 세션에서 BLOG_PREP_PREFIX를 그 값으로 지정해요. 이번 사례의 원리는 $env:BLOG_PREP_PREFIX에 오늘 접두사를 넣은 뒤 Python 자식 프로세스를 시작하는 방식입니다.
셋째, 실행 전 접두사가 비어 있지 않은지 다시 봐요. 빈 값이면 prep_publish.py의 접두사 건너뛰기 조건이 작동하지 않아 넓은 범위를 검사할 수 있어요.
넷째, 조립 결과와 공개 결과를 따로 확인해요. ready 파일이 만들어졌다는 메시지는 로컬 준비가 끝났다는 뜻이지 공개 발행 완료라는 뜻이 아닙니다. 실제 공개는 별도의 발행 절차와 라이브 확인이 있어야 해요.
이 방법은 작업 ID에 공통 접두사가 있을 때만 맞아요. 날짜 접두사가 없거나 여러 날짜를 한꺼번에 조립하려는 작업이라면 같은 필터를 그대로 적용하면 필요한 작업까지 빠질 수 있습니다.
확인한 기준
2026년 8월 19일에 로컬 prep_publish.py의 main, BLOG_PREP_PREFIX 조회, 작업 ID 시작 문자열 비교, 파일 끝의 main 호출을 확인했어요. 발행큐는 공개 발행 여부와 새 r0819 작업 생성 여부를 구분하는 용도로 대조했습니다.
Microsoft Learn 환경변수 공식 설명 바로가기
이번 확인은 도움말 미구현으로 main이 실행된 원인과 조립 범위 제한 원리까지예요. 공개 발행이나 별도의 복구 성공 결과는 만들거나 확인하지 않았습니다.
📎 함께 보면 좋은 글
댓글
댓글 쓰기
질문은 자유롭게 남겨주세요. 광고성 댓글, 비방, 개인정보가 포함된 댓글은 삭제될 수 있습니다.