Python 스케줄러 중복 실행 방지: 안정적인 락 파일(Lock File) 설계와 예외 처리 전략

파이썬으로 배치 프로그램을 운영할 때 가장 빈번하게 발생하는 문제는 이전 작업이 끝나지 않았는데 다음 작업이 시작되어 데이터가 꼬이는 현상입니다. 이를 방지하는 가장 확실한 방법이 바로 '락 파일(Lock File)' 설계입니다.

단순히 cron이나 APScheduler를 사용한다고 해서 중복 실행이 자동으로 막히지는 않습니다. 네트워크 지연이나 대용량 데이터 처리로 인해 작업 시간이 예상보다 길어지면, 동일한 프로세스가 여러 개 실행되어 DB 데드락을 유발하거나 시스템 리소스를 고갈시키는 원인이 됩니다.

많은 개발자가 단순히 특정 경로에 파일이 존재하는지만 확인하는 방식으로 락을 구현하지만, 이는 프로세스가 비정상 종료되었을 때 락 파일이 남아서 다음 작업이 영원히 실행되지 않는 'Stale Lock' 문제를 야기합니다. 실무에서는 이러한 예외 상황까지 고려한 견고한 설계가 필수적입니다.

이 글에서는 운영 환경에서 신뢰할 수 있는 락 파일 설계 패턴과 OS 수준의 파일 잠금 기능을 활용해 배치 안정성을 확보하는 구체적인 방법을 살펴봅니다. 단순한 개념 설명을 넘어 실제 장애를 방지할 수 있는 판단 포인트를 함께 정리했습니다.

핵심 내용 먼저 보기

핵심 키워드 락 파일 설계 · 연관 검색어 Python 락 파일, 스케줄러 중복 실행 방지, 배치 프로세스 안정성, fcntl 사용법, stale lock 처리

배치 프로세스에서 락 파일 설계가 필수적인 이유

배치 작업은 원자성(Atomicity)이 보장되어야 합니다. 예를 들어 정산 데이터를 처리하는 스크립트가 중복 실행되면 중복 결제나 데이터 누락이 발생할 수 있습니다. 스케줄러는 정해진 시간에 명령을 내릴 뿐, 이전 프로세스의 생존 여부를 완벽히 추적하지 못하는 경우가 많기 때문에 애플리케이션 레벨에서 방어 로직을 갖춰야 합니다.

특히 클라우드 환경이나 컨테이너 기반 환경에서는 일시적인 리소스 부족으로 작업이 지연될 확률이 높습니다. 이때 락 파일은 현재 작업이 진행 중임을 알리는 '신호등' 역할을 하며, 시스템 전체의 정합성을 유지하는 최후의 보루가 됩니다. 단순히 '빨리 끝나겠지'라는 가정 대신 '언젠가는 겹칠 수 있다'는 전제로 설계해야 합니다.

OS 수준의 파일 잠금(fcntl)을 활용한 구현 방식

단순히 os.path.exists()로 파일을 체크하고 생성하는 방식은 파일 생성 직전에 다른 프로세스가 끼어드는 레이스 컨디션(Race Condition)에 취약합니다. 대신 리눅스/유닉스 계열에서는 fcntl 모듈을 사용하여 파일 디스크립터 수준에서 잠금을 거는 것이 훨씬 안전합니다.

fcntl.flock(f, fcntl.LOCK_EX | fcntl.LOCK_NB)를 사용하면 파일이 이미 잠겨 있을 때 즉시 예외를 발생시켜 중복 실행을 차단할 수 있습니다. 이 방식의 가장 큰 장점은 프로세스가 어떤 이유로든 종료되면 운영체제가 자동으로 파일 잠금을 해제해준다는 점입니다. 이는 파일은 남아있더라도 잠금은 풀린 상태가 되어 다음 주기의 배치가 정상적으로 실행될 수 있게 돕습니다.

비정상 종료와 Stale Lock 대응 전략

파일 존재 여부만 따지는 방식을 사용한다면, 서버가 갑자기 꺼지거나 kill -9로 프로세스가 강제 종료되었을 때 남겨진 락 파일 때문에 수동으로 파일을 지우기 전까지 배치가 멈추게 됩니다. 이를 방지하려면 락 파일 내부에 현재 실행 중인 프로세스 ID(PID)를 기록하는 설계를 도입해야 합니다.

새로운 프로세스가 시작될 때 기존 락 파일이 있다면, 파일 안의 PID를 읽어 해당 프로세스가 실제로 살아있는지 os.kill(pid, 0) 등을 통해 확인하는 로직이 필요합니다. 만약 해당 PID가 존재하지 않는다면 이전 작업이 비정상 종료된 것으로 간주하고, 기존 파일을 덮어쓰며 락을 획득한 뒤 작업을 이어가는 것이 실무적인 대응 방법입니다.

안정적인 운영을 위한 컨텍스트 매니저와 모니터링

락 로직을 매번 작성하기보다 파이썬의 with 문(Context Manager)으로 추상화하는 것이 좋습니다. 코드의 가독성이 높아질 뿐만 아니라, 예외가 발생하더라도 __exit__ 구문을 통해 안전하게 락을 해제하거나 로그를 남길 수 있기 때문입니다. 이는 코드 중복을 줄이고 실수로 락을 해제하지 않는 상황을 방지합니다.

또한 락 획득 실패 시 단순히 종료할 것인지, 아니면 일정 시간 대기 후 재시도할 것인지에 대한 정책도 중요합니다. 실시간성이 중요한 작업이라면 즉시 종료 후 모니터링 시스템에 알림을 보내고, 순차 처리가 중요하다면 큐(Queue)를 도입하거나 지수 백오프(Exponential Backoff)를 적용한 재시도 루프를 설계하는 것이 좋습니다.

락 파일 설계는 단순해 보이지만 운영 환경의 다양한 변수를 고려하면 생각보다 까다로운 작업입니다. 파일 시스템의 특성과 OS의 프로세스 관리 방식을 정확히 이해하고 설계해야 예기치 못한 배치 중단 사고를 막을 수 있습니다.

만약 단일 서버가 아닌 다중 서버(Multi-node) 환경에서 배치를 운영한다면, 로컬 파일 시스템 기반의 락보다는 Redis나 ZooKeeper 같은 분산 락(Distributed Lock) 시스템으로 확장하는 것을 고려해야 합니다. 하지만 단일 노드 내에서는 오늘 설명한 파일 기반 락만으로도 충분히 강력한 안정성을 확보할 수 있습니다.

오늘 살펴본 PID 체크와 OS 수준의 잠금 기법을 프로젝트에 먼저 적용해 보시기 바랍니다. 작은 설계의 차이가 시스템의 가동률과 데이터 신뢰도를 결정짓는 핵심 요소가 될 것입니다.

자주 묻는 질문

윈도우 환경에서도 fcntl을 사용할 수 있나요?

아니요, fcntl은 유닉스 계열 전용 모듈입니다. 윈도우 환경에서는 msvcrt 모듈의 locking 함수를 직접 사용하거나, 플랫폼 독립적인 기능을 제공하는 portalocker 같은 외부 라이브러리를 활용하는 것이 효율적입니다.

락 파일의 위치는 어디가 가장 적당한가요?

일반적으로 /tmp나 /var/run 디렉토리를 사용합니다. 시스템 재부팅 시 자동으로 정리되길 원한다면 임시 폴더가 적합하며, 배치가 실행되는 유저 권한으로 파일을 생성하고 수정할 수 있는 경로여야 합니다.

락 파일이 있는데 프로세스가 죽어있다면 무조건 지워도 되나요?

PID를 확인했을 때 해당 프로세스가 없다면 지워도 무방합니다. 다만, 아주 드문 확률로 PID가 재사용될 가능성이 있으므로 파일 생성 시간(mtime)을 함께 체크하여 너무 오래된 파일인 경우에만 삭제 후 재시작하는 로직을 추가하면 더 안전합니다.

---

해시태그

#락파일설계 #Python락파일 #스케줄러중복실행방지 #배치프로세스안정성 #fcntl사용법 #stalelock처리 #파이썬배치설계