포트 충돌, 에러 한 줄 없었는데..아침 자동화가 시작도 안 했다?(크론 오류·자동화 사고)

카드뉴스 자동화를 서버 한 대로 옮기는 작업 자체는 무난하게 끝났습니다.
문제는 그다음 날 아침, 매일 글을 쓰던 자동화가 시작조차 하지 않으면서 나타났습니다.

아침 자동화가 시작조차 하지 않았다

저는 이 블로그를 포함해 여러 무인 파이프라인을 서버(VPS) 한 대에서 같이 돌립니다.
같은 작업이 겹쳐서 두 번 실행되는 사고를 막으려고 "잠금 포트"라는 방식을 씁니다.

원리는 단순합니다. 파이프라인이 시작할 때 자기 전용 포트를 열어봅니다.
이미 다른 프로세스가 그 포트를 쓰고 있으면 "누군가 먼저 돌고 있다"고 판단하고, 아무 일도 하지 않은 채 스스로 종료합니다.

이 방식은 지금까지 잘 작동했습니다. 문제는 '전용'이 실제로는 전용이 아니었던 순간이었습니다.

2026년 8월 11일, 카드뉴스 자동화 데몬 세 개를 서버로 이관했습니다.
이 과정에서 이미 다른 파이프라인이 쓰고 있던 잠금 포트 두 개를 그대로 재사용해버렸습니다. 번호를 새로 받았어야 했는데, 옮기는 김에 비어 있는 줄 알고 그 자리를 그대로 썼습니다.

에러도 없고, 로그 파일도 없었다

다음 날인 8월 12일 아침 8시, 티스토리 글을 쓰는 자동화가 평소처럼 깨어날 시각이었습니다.
그런데 그날 로그 폴더에는 아침 실행 기록이 아예 없었습니다. 앞뒤 날짜인 8월 10일·11일·13일에는 08시 로그 파일이 하나씩 남아 있는데, 8월 12일 자리만 통째로 비어 있었습니다.

에러 메시지도 없었습니다. 텔레그램으로 온 건 딱 한 줄, "제작이 이미 진행 중입니다"였습니다.
이 문구는 원래 중복 실행을 막을 때 나오는 정상 안내입니다. 평소에도 가끔 보던 말이라 알림만 봐서는 고장인지 아닌지 구분이 되지 않았습니다.

정리하면 이렇습니다. 고장은 났는데 고장처럼 생긴 신호가 하나도 없었습니다. 에러 로그도, 실패 알림도, 심지어 실행 기록조차 남지 않았습니다.

원인은 전날 옮긴 데몬이 차지한 포트였다

코드를 열어보니 답은 실행 첫 몇 줄에 있었습니다.
파이프라인은 시작하자마자 자기 잠금 포트를 열어보고, 실패하면 "이미 진행 중" 알림 한 줄만 보내고 그 자리에서 끝냅니다. 로그 파일은 그보다 뒤 단계에서 만들어지기 때문에, 여기서 끝나면 기록이 아예 남지 않습니다.

그런데 그 포트를 차지하고 있던 건 원래 주인이 아니라, 전날 이관한 카드뉴스 데몬이었습니다.
자동화는 설계대로 정확히 움직였습니다. 다만 "먼저 돌고 있다"고 믿은 상대가 자기와 아무 상관 없는 다른 작업이었을 뿐입니다.

겹친 포트는 두 개였고, 그 두 자리를 원래 쓰던 작업은 셋이었습니다. 여기서는 편의상 잠금 포트 A·잠금 포트 B라고 부르겠습니다(실제 포트 번호는 보안상 밝히지 않습니다).

겹친 자리를 쓰던 작업	실제로 확인된 일	확인 근거
티스토리 아침 제작	8월 12일 08시 실행이 시작조차 못 함(로그 파일 없음). 그날 분량은 오전 11시 20분에 다시 돌려 2편으로 메움	로그 폴더 · 발행 장부
색인 판정	같은 자리를 물고 있었지만 재배정 전까지 결번은 확인되지 않음 — 다음 차례였다면 같은 이유로 멈출 자리	판정 장부 · 도구 소스의 포트 주석
주간 색인 리포트	주 1회 실행이라 이관과 재배정 사이에 돌아올 차례 자체가 없었음(위와 동일한 대기 상태)	크론 요일표 · 도구 소스의 포트 주석

이 표에서 제가 더 오래 붙잡고 있던 건 두 번째·세 번째 줄입니다.
실제로 산출물이 빈 건 아침 제작 한 건뿐이었지만, 나머지 둘도 똑같은 자리에 서 있었습니다. 며칠만 늦게 알았어도 같은 방식으로 조용히 멈췄을 겁니다. 사고는 한 건이었지만, 지뢰는 세 개였습니다.

포트를 다시 나눠주고, 대장에 이름을 올리는 규칙이 생겼다

해결 자체는 어렵지 않았습니다. 같은 날 겹치던 세 작업을 비어 있는 새 번호로 옮겨줬습니다.
그 뒤로 같은 증상은 다시 나타나지 않았습니다.

진짜 바뀐 건 그다음이었습니다. "새 자동화를 만들 때는 잠금 포트를 대장에서 빈 번호로 골라 먼저 등재한다"는 규칙이 이 사고를 계기로 운영 문서에 박혔습니다.
지금 그 대장은 열댓 개의 번호를 관리하는 장부가 됐습니다. 새 파이프라인을 만들 때마다 빈 번호를 확인하고 등록하는 절차가 먼저입니다.

그리고 우리 운영 문서에는 이 사고 뒤로 부쩍 자주 꺼내 보게 된 문장이 하나 있습니다. 관제는 "돌았나"가 아니라 "나왔나"를 본다.
크론이 정해진 시각에 돌았다는 기록만 보고 안심하면 안 된다는 뜻입니다. 이번엔 그 반대 방향으로도 배웠습니다. 기록이 남지 않았다는 것 자체가 이미 신호였습니다.

같은 상황을 겪는다면 이 순서로 확인해보세요

① 여러 자동화가 한 서버를 공유한다면, 각자 쓰는 포트·파일명 같은 자원을 한 곳에 목록으로 모아 관리합니다.

② 새 자동화를 이관·추가할 때는 그 목록부터 확인하고 빈 자리만 씁니다. "비어 있겠지"가 이번 사고의 출발점이었습니다.

③ "이미 실행 중"처럼 평소에도 나오는 정상 안내는 고장 신호와 구분이 되지 않습니다 — 그날 실제로 나온 산출물(글 수, 점검 결과)을 따로 셉니다.

④ 로그가 남지 않은 실행은 "조용히 잘 끝난 것"이 아니라 "시작도 못 했을 수 있는 것"으로 봅니다.

이런 무인 배치 사고는 이번이 처음이 아니었습니다. 예전에 무인 세션이 질문만 던지고 멈춰버렸던 자동화 시스템 오류 사고도 "겉보기엔 고장이 아닌 침묵"이라는 점에서 같은 계열이었습니다. 검색 등록이 거절되고 나서야 제휴 링크 비중을 처음 재봤던 다음 검색등록 거절 사고 글도 같은 운영 기록 시리즈입니다.

FAQ

Q1. 잠금 포트가 정확히 뭔가요?
파이프라인이 시작할 때 자기 전용 포트를 열어보는 방식입니다. 이미 열려 있으면 "누가 먼저 돌고 있다"고 판단해 스스로 조용히 종료합니다. 같은 작업이 중복으로 두 번 실행되는 걸 막는 용도입니다.

Q2. 왜 에러도 로그도 안 남았나요?
포트를 잡지 못하면 "이미 진행 중"이라는 알림 한 줄만 보내고 그 자리에서 끝나도록 짜여 있기 때문입니다. 로그 파일은 그보다 뒤 단계에서 만들어지니 기록이 남을 자리까지 가지도 못했고, 중복 방지는 원래 정상 동작이라 에러로 분류되지도 않았습니다.

Q3. 재발을 막으려면 핵심이 뭔가요?
새 자동화를 만들거나 옮길 때 기존 잠금 포트 목록부터 확인하고 빈 번호만 쓰는 것, 그리고 크론이 돌았다는 기록이 아니라 실제 산출물이 나왔는지를 따로 세어보는 것입니다.

Q4. 자동화를 하나만 돌리는 사람도 신경 써야 하나요?
자동화가 하나뿐이면 이 사고는 해당되지 않습니다. 다만 두 개 이상의 무인 작업이 같은 서버·같은 자원을 공유하는 순간부터는, 자원이 겹치지 않는지 목록으로 관리하는 습관이 필요합니다.