자동화는 처음 만들 때 기분이 좋습니다. 버튼 하나로 돌아가고, 정해진 시간에 알림이 오고, 파일이 알아서 저장되면 일단 성공한 것처럼 보입니다. 그런데 한 달만 지나면 진짜 문제는 다른 곳에서 생깁니다. API 키가 바뀌고, 폴더가 iCloud에서 밀려나고, 실행 로그는 남았는데 결과물은 비어 있고, 스케줄러는 “정상 실행”이라고 말하지만 실제 발행은 안 된 상태가 됩니다.
제가 자동화 작업을 하며 가장 많이 배운 것도 이 지점이었습니다. 새 스크립트를 만드는 능력보다 “어제도 돌았고, 오늘도 제대로 끝났는지 확인하는 능력”이 더 중요했습니다. Codex를 쓰기 전에는 제가 직접 터미널을 열고 로그를 찾고, 어느 파일이 최신인지 확인하고, 실패 흔적을 하나씩 맞춰야 했습니다. Codex를 붙인 뒤에는 이 과정을 루틴으로 묶을 수 있었습니다.
OpenAI는 Codex를 장기 작업과 자동화, 코드베이스 이해, 반복 워크플로에 맞는 코딩 에이전트로 설명합니다. 최근 릴리즈 노트에서도 Goal mode, Appshots, 브라우저 주석 같은 기능이 더 긴 작업을 이어가기 위한 방향으로 소개됐습니다. 저는 이걸 거창한 개발 프로젝트보다 개인 자동화 점검에 먼저 써보는 쪽이 현실적이라고 봅니다. ※ 근거: OpenAI Developers Codex Use Cases, ChatGPT Release Notes 2026-05-21
제가 Codex에게 가장 먼저 시키는 일은 새 기능 개발이 아닙니다. “오늘 뭐가 안 돌았는지 봐줘”입니다. 자동화가 많아질수록 중요한 질문은 “무엇을 만들까”가 아니라 “무엇이 조용히 실패했나”가 됩니다. 특히 launchd, cron, 블로그 파이프라인, 영상 발행, 러닝 대시보드처럼 여러 자동화가 엮이면 실패는 늘 조용히 숨어 있습니다.
실제로 아침 점검을 보면 겉으로는 정상처럼 보이는 항목도 있습니다. 실행 로그는 있지만 결과 JSON에 실제 URL이 없거나, 이미지 파일은 있는데 iCloud가 로컬 파일을 비워둔 경우가 있습니다. 사람 눈으로 매번 보면 놓치기 쉽습니다. Codex에게는 먼저 파일 존재, 마지막 수정 시각, 실행 로그, 결과물 크기, URL 응답 코드를 순서대로 보게 하는 편이 좋았습니다.
저는 이 루틴을 “상태판 먼저, 수정은 나중”으로 정했습니다. 바로 고치려고 들면 원인을 보기도 전에 파일을 건드립니다. Codex에게도 먼저 읽고, 실패 지점을 분리하고, 다음 행동 후보를 말하게 합니다. 이 순서가 생기니 자동화 점검이 덜 불안해졌습니다. 고장 난 줄도 모르고 지나가는 일이 줄었기 때문입니다.
자동화 시스템을 점검할 때 저는 세 덩어리로 나눕니다. 첫째는 실행 여부입니다. 정해진 시간에 스크립트가 돌았는지, 로그가 남았는지, 프로세스가 중간에 죽지 않았는지 봅니다. 둘째는 산출물입니다. 파일이 만들어졌는지보다 내용이 비어 있지 않은지, 크기가 평소와 크게 다르지 않은지, 필요한 URL이나 ID가 들어 있는지 확인합니다. 셋째는 후속 연결입니다. 발행 URL이 실제로 열리는지, 텔레그램 알림이 갔는지, 옵시디언 노트가 정해진 폴더에 저장됐는지 확인합니다.
제가 블로그 자동화를 점검할 때도 같은 구조를 씁니다. 마크다운이 있는지만 보지 않습니다. 이미지 마커가 남아 있는지, HTML에 CSS가 들어갔는지, 해시태그가 제목처럼 깨지지 않았는지, 사이트 발행 후 HTTP 응답이 정상인지까지 봅니다. Codex는 이런 순차 점검에 잘 맞습니다. “확인하고 끝”이 아니라 확인 결과를 다음 명령으로 이어가기 때문입니다.
이때 중요한 것은 질문을 작게 쪼개는 것입니다. “자동화 괜찮아?”라고 물으면 답도 흐려집니다. 대신 “오늘 실행된 자동화 중 결과물이 비어 있는 것만 찾아줘”, “발행 URL이 없는 JSON만 골라줘”, “마지막 성공 이후 바뀐 파일을 보여줘”처럼 말하면 훨씬 안정적입니다. Codex는 넓은 감상보다 좁은 체크리스트를 줬을 때 힘이 납니다.
Codex로 자동화 루틴을 만들 때 가장 효과가 컸던 문장은 “이게 되면 성공”을 먼저 말하는 방식이었습니다. 예를 들어 “블로그 파이프라인 고쳐줘”보다 “이미지 스타일 리포트가 없으면 Stage 3d에서 실패해야 하고, 같은 style_id면 통과해야 합니다”라고 말하는 편이 낫습니다. 그러면 Codex는 코드 수정과 검증 명령을 같은 흐름으로 묶습니다.
저도 처음에는 자동화 점검을 막연하게 부탁했습니다. 그러면 Codex가 상황을 잘 설명해도 실제 완료 기준이 흐릴 때가 있었습니다. 이후에는 성공 기준을 먼저 적었습니다. “URL이 정상 응답이면 성공”, “마크다운에 이미지 자리표시자가 남아 있지 않으면 성공”, “HTML 크기가 기준보다 작으면 CSS 누락으로 본다”처럼 말입니다. 이런 문장은 사람에게도 좋고, Codex에게도 좋습니다.
OpenAI의 Codex 유스케이스에도 반복 워크플로를 스킬로 저장하거나, 실제 결과를 검증하는 작업이 중요한 흐름으로 제시됩니다. 개인 자동화에서도 원리는 같습니다. Codex에게 똑똑한 답을 기대하기보다, 확인 가능한 조건을 주고 그 조건을 통과하게 만드는 편이 더 좋았습니다. ※ 근거: OpenAI Developers Codex Use Cases
자동화 점검은 결국 세 가지를 연결하는 일입니다. 로컬 파일, 실행 로그, 외부 URL입니다. 파일만 보면 실제 발행 여부를 놓치고, 로그만 보면 빈 결과물을 놓치고, URL만 보면 내부 저장 실패를 놓칠 수 있습니다. 그래서 저는 Codex에게 늘 이 세 가지를 같이 보게 합니다.
예를 들어 블로그 글 하나를 점검한다면 먼저 마크다운 파일을 봅니다. 다음으로 이미지 폴더에서 같은 슬러그의 커버와 섹션 파일을 확인합니다. 그 다음 HTML 변환 결과 크기를 봅니다. 마지막으로 발행 URL을 curl로 확인합니다. 이 흐름을 사람 손으로 매번 하면 귀찮지만, Codex에게는 아주 잘 맞는 반복 작업입니다.
제가 느낀 핵심은 “자동화의 자동화”가 아니라 “점검의 자동화”였습니다. 만드는 일은 한 번이지만 점검은 매일 반복됩니다. Codex는 이 반복을 부담 없이 맡길 수 있습니다. 특히 같은 명령을 다시 돌리고, 실패한 줄만 읽고, 다음 단계로 넘어갈지 멈출지 판단하는 작업에서 강점이 있습니다.
자동화가 깨졌을 때 바로 고치는 습관은 위험할 때가 있습니다. 그 순간은 빨라 보이지만, 나중에 같은 문제가 다시 생기면 왜 고쳤는지 기억이 안 납니다. 저는 Codex에게 점검 결과를 먼저 짧게 정리하게 합니다. 무엇이 깨졌는지, 어느 단계에서 막혔는지, 재발 방지로 무엇을 바꿨는지 남기는 식입니다.
최근에도 이미지 스타일이 글톤과 맞지 않는 문제가 있었습니다. 파일은 다 있었고 HTML도 정상이라 기존 검증은 통과했습니다. 하지만 눈으로 보니 하나의 글 안에 실사풍, 홀로그램, 파스텔 앱 UI가 섞여 있었습니다. 그래서 “하나의 글에는 하나의 스타일만 허용”이라는 규칙을 문서에만 두지 않고, Stage 3d 검증에서 style_id 리포트를 확인하도록 바꿨습니다.
이런 기록이 쌓이면 다음 점검이 쉬워집니다. Codex에게 “지난번과 같은 패턴이 있는지 봐줘”라고 말할 수 있기 때문입니다. 자동화 시스템은 결국 기억력이 중요합니다. 사람의 기억에만 맡기면 새벽에 깨진 문제를 오후에 또 놓칩니다. Codex를 점검 루틴에 넣는 이유는 바로 이 반복 기억을 파일과 검증으로 바꾸기 위해서입니다.
처음부터 모든 자동화를 한 번에 점검하려고 하면 루틴이 복잡해집니다. 저는 가장 자주 쓰고, 깨졌을 때 바로 불편한 자동화 하나부터 시작하는 편을 권합니다. 블로그라면 마크다운, 이미지, HTML, URL만 보면 됩니다. 영상이라면 결과 JSON, 업로드 ID, 썸네일, 알림 여부만 보면 됩니다. 러닝 대시보드라면 FIT 파일, HTML 생성, 발행 URL만 보면 됩니다.
이 작은 루틴이 안정되면 다음 자동화를 붙이면 됩니다. 중요한 것은 점검 항목을 늘리는 속도가 아니라 실패 기준을 분명히 하는 일입니다. “파일 있음”은 약한 기준입니다. “파일이 있고, 크기가 정상이고, 필수 필드가 있고, URL이 열린다”까지 가야 실무 기준입니다. Codex는 이 차이를 코드와 명령으로 옮기기 좋습니다.
저는 앞으로 자동화를 만들 때마다 점검 문장도 같이 만들 생각입니다. 새 스크립트를 하나 만들면 “이 스크립트가 성공했다는 증거는 무엇인가”를 바로 적는 것입니다. 이 습관이 생기면 자동화가 늘어나도 관리가 덜 무거워집니다. Codex는 그 증거를 매번 대신 확인해주는 작업 동료가 됩니다.
매일 돌리는 자동화라면 매일 확인하는 편이 좋습니다. 다만 사람이 매번 볼 필요는 없습니다. Codex에게 로그와 결과물만 먼저 훑게 하고, 깨진 항목만 사람이 보면 됩니다.
“확인해줘”보다 “성공 기준은 이것이고, 실패하면 여기서 멈춰줘”가 좋습니다. 예를 들어 “URL 200 확인, 결과 JSON 필수 필드 확인, 실패 시 수정 전 원인 보고”처럼 말하면 됩니다.
처음부터 코드로 만들 필요는 없습니다. 처음에는 Codex에게 반복 명령으로 시켜보고, 자주 쓰는 확인만 스크립트로 묶으면 됩니다. 자주 반복되는 점검만 자동화하면 충분합니다.
Codex로 자동화 시스템을 점검한다는 것은 멋진 대시보드를 만드는 일이 아닙니다. 어제 돌아간 일이 오늘도 제대로 끝났는지, 결과물이 비어 있지 않은지, 외부 URL까지 실제로 열리는지 확인하는 습관을 만드는 일입니다.
자동화는 많이 만들수록 관리가 중요해집니다. 저는 이제 새 자동화를 만들 때 실행 코드만 보지 않습니다. 성공 기준, 실패 기준, 재발 방지 기록까지 같이 봅니다. Codex는 이 흐름을 파일과 로그, 명령 실행으로 이어주는 도구입니다. 잘 쓰면 자동화가 많아질수록 오히려 마음이 가벼워집니다.