AI 자동화는 처음 만들 때보다 운영할 때 실력이 드러납니다. 처음에는 버튼 하나로 결과물이 나오는 장면이 눈에 들어옵니다. 하지만 며칠만 지나도 더 중요한 질문이 생깁니다. 같은 명령이 같은 흐름으로 이어지는지, 실패했을 때 어느 단계에서 멈추는지, 사람이 확인해야 할 지점이 분명한지 보는 일이 필요합니다.
자동화가 커질수록 작업은 한 파일 안에서 끝나지 않습니다. 명령을 받는 부분, 자료를 모으는 부분, 글을 쓰는 부분, 이미지를 만드는 부분, 저장하는 부분, 공유하는 부분이 서로 이어집니다. 이 연결이 길어지면 작은 경로 차이도 큰 장애가 됩니다. 파일명 하나가 어긋나면 이미지 삽입이 실패하고, 저장 위치가 틀리면 결과물을 찾을 수 없으며, 발행 단계가 중복으로 돌면 같은 글이 여러 번 올라갈 수 있습니다.
그래서 자동화 점검은 “잘 되나?”라고 한 번 눌러보는 일이 아닙니다. 어느 단계가 어떤 입력을 받고 어떤 출력을 남기는지 확인하는 습관입니다. 초안이 만들어졌는지, 이미지가 약속한 이름으로 저장됐는지, HTML 변환 결과가 충분한 크기와 스타일을 가졌는지, 실제 페이지가 열리는지까지 봐야 합니다. 이런 확인이 쌓이면 자동화는 장난감이 아니라 운영 도구가 됩니다.
운영 도구가 되려면 반복성이 필요합니다. 오늘 통과한 절차가 내일도 같은 기준으로 통과해야 하고, 실패할 때는 같은 지점에서 같은 이유를 말해야 합니다. 특히 AI가 들어간 자동화는 결과 문장이 매번 조금씩 달라질 수 있습니다. 그래서 사람이 쓰는 문장 자체보다 파일 계약, 단계 순서, 저장 위치, 검증 조건이 더 중요합니다. 이 네 가지가 고정되어 있으면 결과물이 달라져도 운영자는 흐름을 해석할 수 있습니다.
자동화가 꼬이는 가장 흔한 이유는 누가 실행하는지 불분명한 상태입니다. 같은 스크립트를 여러 앱이 동시에 실행할 수 있고, 같은 설정 파일을 여러 런타임이 읽을 수 있습니다. 겉으로는 편해 보이지만 운영에서는 위험합니다. 특히 글 발행, 텔레그램 알림, 옵시디언 저장, 사이트 게시처럼 외부에 결과가 남는 작업은 한 곳에서만 자동으로 실행돼야 합니다.
좋은 기준은 간단합니다. 사람이 직접 호출하는 기능은 여러 환경에서 쓸 수 있어도 됩니다. 하지만 예약 실행과 자동 발행은 하나의 운영 런타임에서만 움직여야 합니다. 직접 “이 글 써줘”라고 말한 작업과 새벽에 자동으로 도는 작업은 성격이 다릅니다. 전자는 그 순간의 승인이고, 후자는 계속 반복되는 배경 작업입니다.
이 구분이 있어야 토큰 사용량도 관리됩니다. 어떤 자동화가 어느 모델을 쓰는지 모르면 비용과 한도를 파악하기 어렵습니다. 예전 모델이나 보조 fallback이 조용히 살아 있으면, 사용자는 분명 끈 줄 알았는데 백그라운드에서 계속 호출될 수 있습니다. 운영 런타임을 하나로 정하고, 나머지는 수동 호출과 검증 용도로 두면 이런 위험이 크게 줄어듭니다.
자동화 파일이 여러 폴더에 흩어지면 어느 파일이 최신인지 알기 어려워집니다. Claude 폴더의 스크립트, Codex 폴더의 스킬, Hermes 폴더의 실행본이 조금씩 달라지면 같은 명령도 환경마다 다르게 움직입니다. 처음에는 작은 차이로 보일 수 있지만 시간이 지나면 버그를 찾기 어려운 구조가 됩니다.
이 문제를 줄이려면 메인 source 폴더를 기준으로 삼는 편이 좋습니다. 수정은 source에서 하고, 각 런타임은 source를 바라보게 합니다. 이때 모든 것을 무작정 공유하면 안 됩니다. 코드와 스킬, 파이프라인 계약은 공유할 수 있지만 토큰, 세션, 로그, 캐시, 생성 결과물은 런타임에 남겨야 합니다. 코드와 상태를 분리하는 것이 핵심입니다.
링크 구조를 쓸 때도 검증이 필요합니다. symlink가 생겼다고 끝난 것이 아닙니다. 실제 실행 경로에서 import가 꼬이지 않는지, 자기 자신을 다시 부르는 재귀 구조가 없는지, 기존 shim이 살아남아 실행을 가로막지 않는지 확인해야 합니다. source 중심 구조는 강력하지만, 잘못 연결하면 여러 폴더에 복사해두던 시절보다 더 빠르게 같은 문제가 퍼질 수 있습니다.
source 중심 구조의 장점은 수정 위치가 선명해지는 데 있습니다. 문제가 생기면 런타임 폴더를 먼저 고치는 대신 source의 기준 파일을 봅니다. 그다음 runtime이 그 기준 파일을 제대로 바라보는지 확인합니다. 이 순서를 지키면 임시 수정이 여러 폴더에 흩어지는 일을 줄일 수 있습니다. 반대로 런타임 폴더를 직접 고치기 시작하면 source와 실행본이 다시 갈라집니다.
자동화에서 가장 위험한 성공은 실제로는 실패했는데 성공처럼 보이는 경우입니다. 예를 들어 저장 스크립트가 실행은 됐지만 아무 파일도 만들지 않았는데 상위 파이프라인이 “저장 완료”라고 찍으면, 사람은 한참 뒤에야 결과물이 없다는 사실을 알게 됩니다. 이런 false-positive는 단순한 오류보다 더 위험합니다.
좋은 파이프라인은 단계마다 확인합니다. 글 검증이 통과했는지 확인하고, 이미지 파일이 실제로 있는지 확인하며, 후처리된 이미지가 만들어졌는지 확인합니다. 마크다운에는 절대경로가 남지 않아야 하고, HTML에는 스타일이 포함되어야 하며, 발행 후에는 URL이 실제로 열려야 합니다. 이런 확인은 귀찮아 보이지만 장애 원인을 작게 잘라줍니다.
실패 메시지도 중요합니다. “오류가 났습니다”라는 말보다 “Stage 3 이미지 파일 없음”이 훨씬 낫습니다. 사람이 바로 다음 행동을 정할 수 있기 때문입니다. 자동화가 잘 설계됐다는 말은 실패하지 않는다는 뜻이 아닙니다. 실패할 때도 어디서 멈췄는지 정확히 알려준다는 뜻에 가깝습니다.
검증기는 때로 까다롭게 느껴질 수 있습니다. 글자수가 모자라거나, 말투가 섞이거나, 이미지 리포트가 없다는 이유로 멈추면 당장은 답답합니다. 하지만 이런 차단은 발행 후 수정하는 비용을 줄입니다. 공개 페이지에 올라간 뒤 발견하는 문제보다, 로컬 검증 단계에서 멈추는 문제가 훨씬 싸게 고칠 수 있습니다.
자동화가 만드는 산출물은 사람이 다시 찾을 수 있어야 합니다. 블로그 초안은 옵시디언의 정해진 폴더에 있어야 하고, 이미지는 정해진 이미지 루트에 있어야 하며, HTML은 변환된 파일로 남아야 합니다. 임시 폴더에만 남는 결과물은 테스트에는 편해도 운영에는 부족합니다.
이미지 경로는 특히 엄격해야 합니다. 실제 파일은 별도 이미지 폴더에 있어도, 마크다운에는 옵시디언에서 읽을 수 있는 상대경로가 들어가야 합니다. images/파일명.png처럼 예측 가능한 구조가 되면 마크다운 미리보기와 HTML 변환이 같은 이미지를 바라볼 수 있습니다. 절대경로가 섞이면 내 컴퓨터에서는 보이지만 게시 후에는 깨질 수 있습니다.
사이트 게시도 같은 원칙입니다. HTML 변환 결과를 바로 게시하고, 게시 후 URL을 확인해야 합니다. 발행 스크립트가 URL을 출력했다고 해서 끝난 것이 아닙니다. 실제 HTTP 응답이 정상인지, 리디렉션 후 페이지가 열리는지, 페이지 안에 제목과 이미지가 들어 있는지 확인해야 합니다. 여기까지 봐야 “올라갔다”고 말할 수 있습니다.
운영 기록도 산출물의 일부로 봐야 합니다. 어디에 초안이 저장됐는지, 어떤 이미지가 생성됐는지, 어떤 URL이 나왔는지, 어떤 검증이 통과했는지 남겨야 다음 점검이 쉬워집니다. 자동화는 사람의 기억을 대신하려는 도구이므로, 자동화 자체도 사람이 다시 추적할 수 있는 흔적을 남겨야 합니다.
큰 자동화를 한 번에 검증하려고 하면 실패 원인을 찾기 어렵습니다. 그래서 먼저 작은 테스트가 필요합니다. 이미지 API를 부르지 않고 파일명과 후처리만 확인하는 smoke test, 발행을 막고 HTML까지만 확인하는 dry run, 마지막으로 실제 이미지 생성과 발행을 포함한 full run을 나누면 좋습니다.
이 순서가 중요한 이유는 외부 변수를 줄이기 위해서입니다. 이미지 생성 API가 실패한 것인지, 이미지 삽입기가 실패한 것인지, HTML 변환이 실패한 것인지, 사이트 게시가 실패한 것인지 한꺼번에 섞이면 판단이 늦어집니다. 작은 테스트가 통과한 뒤 실제 테스트를 하면 실패 범위가 좁아집니다.
실제 테스트도 주제를 잘 골라야 합니다. 법률, 세금, 부동산, 투자처럼 근거 검증이 중요한 주제는 마지막 단계에서 쓰는 편이 좋습니다. 처음에는 운영 루틴이나 도구 사용법처럼 민감도가 낮은 주제가 적합합니다. 그래야 외부 사실 확인보다 파이프라인의 구조를 보는 데 집중할 수 있습니다.
작은 테스트와 실제 테스트를 나누면 승인 기준도 명확해집니다. smoke test는 로컬 연결을 봅니다. dry run은 발행 직전까지의 파일 품질을 봅니다. full run은 외부 게시와 공개 URL까지 봅니다. 이 셋을 섞지 않으면 “어디까지 통과했는지”를 정확히 말할 수 있습니다. 운영자는 성공을 한 단어로 보지 않고, 통과한 구간의 합으로 봐야 합니다.
AI 자동화 점검의 핵심은 화려한 결과물이 아니라 반복 가능한 기준입니다. 누가 실행하는지, 어디를 원본으로 보는지, 실패가 어디서 멈추는지, 산출물이 어디에 남는지, 실제 페이지가 열리는지 확인해야 합니다. 이 기준이 있으면 자동화가 커져도 운영자는 길을 잃지 않습니다.
이번 글의 목적도 같습니다. 실제 이미지 생성이 되는지, 후처리된 이미지가 마크다운에 들어가는지, 옵시디언 초안이 저장되는지, HTML 변환이 되는지, 홈페이지 게시 후 URL이 열리는지 확인하는 테스트입니다. 검색 노출이나 콘텐츠 완성도를 평가하는 글은 아닙니다. 운영 구조가 살아 있는지 보는 글입니다.
자동화는 한 번 성공했다고 끝나는 시스템이 아닙니다. 다음 날에도 같은 기준으로 확인할 수 있어야 합니다. 그래서 좋은 자동화는 코드보다 운영 기록이 중요합니다. 어떤 기준으로 통과했고, 어떤 위험을 남겼고, 다음에 무엇을 봐야 하는지 기록하면 다음 점검이 쉬워집니다. 자동화가 일을 대신하려면 먼저 자동화 자체를 믿을 수 있어야 합니다.
마지막으로 남는 기준은 단순합니다. 직접 요청한 한 번의 실행은 끝까지 수행하되, 예약 실행은 한 곳에서만 움직이게 합니다. 코드는 source에서 관리하되, 토큰과 세션과 로그는 runtime에 남깁니다. 실패는 숨기지 않고 단계명과 이유를 말하게 합니다. 이 원칙만 지켜도 자동화는 훨씬 차분하고 다루기 쉬운 시스템이 됩니다.