파이썬 시그널 핸들러에서 print를 호출해도 안전할까

유닉스 계열 시스템에서 시그널은 프로그램의 정상적인 실행 흐름을 언제든 가로챌 수 있는 비동기 이벤트다. 그래서 C 언어에서 시그널 핸들러를 작성할 때는 그 안에서 호출할 수 있는 함수가 엄격하게 제한된다. 핸들러가 프로그램의 어느 지점에서든 끼어들 수 있기 때문에, 락을 잡고 있는 중이거나 자료구조가 중간 상태에 있는 순간에 진입하면 교착(deadlock)이나 데이터 손상으로 이어질 수 있다. 이 때문에 C의 시그널 핸들러 안에서는 이른바 async-signal-safe로 분류된 소수의 함수만 호출해야 한다는 원칙이 통용된다.

파이썬이 제약에서 자유로운 이유

흥미로운 점은 이 까다로운 제약이 파이썬 시그널 핸들러에는 그대로 적용되지 않는다는 것이다. 원문 필자의 설명에 따르면 CPython은 시그널 처리에 사실상 두 개의 핸들러를 둔다. 운영체제가 시그널을 전달하면 우선 저수준의 C 핸들러가 호출되는데, 이 핸들러는 사용자가 파이썬으로 작성한 핸들러를 그 자리에서 곧바로 실행하지 않는다. 대신 나중에 인터프리터가 일관된 상태에 도달했을 때 파이썬 핸들러가 호출되도록 예약해 둔다. 즉 위험한 제약이 적용되는 저수준 C 컨텍스트 안에서 사용자 코드가 돌아가는 것이 아니기 때문에, 파이썬 개발자는 핸들러 안에서 비교적 자유롭게 함수를 호출할 수 있다.

그렇다고 모든 함정이 사라지는 것은 아니다. 파이썬 시그널 핸들러는 예상 밖으로 재진입(reentrant)이 가능하다는 특성을 갖는다. 하나의 파이썬 시그널 핸들러가 실행되고 있는 도중에 또 다른 시그널이 도착하면, 첫 번째 호출이 끝나기 전에 같은 핸들러가 그 중간에서 다시 호출될 수 있다. 저수준 C 코드에서의 재진입 위험은 인터프리터가 걸러 주지만, 파이썬 레벨에서의 재진입 자체는 여전히 일어난다는 뜻이다.

print를 재진입시키면 벌어지는 일

원문은 이 재진입 특성을 print 호출과 결합해 시험한다. 핸들러가 print를 실행하는 도중에 다시 호출되면 어떻게 될까. 필자는 자기 자신에게 짧은 간격으로 시그널을 폭주시키는 스트레스 테스트를 작성해 이 상황을 인위적으로 만들어 냈다. 그 결과, 극단적인 조건에서는 시그널 핸들러 안의 print 호출이 프로그램을 크래시로 몰아넣을 수 있음을 확인했다. 파이썬이 C의 저수준 제약에서 벗어나 있다고 해서 시그널 핸들러가 완전히 무해한 것은 아니라는 점을 보여 주는 사례다.

다만 필자는 이 결과가 어디까지나 극단적인 상황을 전제한다는 점을 분명히 한다. 실제 프로그램이 이처럼 시그널을 연속으로 몰아치는 조건에 놓일 가능성은 높지 않다. 게다가 설령 문제가 발생하더라도 그 결과가 예외로 인해 프로그램이 멈추는 정도라면, C 시그널 핸들러가 잘못됐을 때 벌어질 수 있는 교착, 자료구조 손상, 아무 흔적 없이 조용히 실패하는 상황에 비하면 훨씬 감당하기 쉬운 실패다. 눈에 보이는 예외는 최소한 원인을 추적할 실마리라도 남기기 때문이다.

실무자에게 남는 교훈

한국의 파이썬 실무자에게 이 이야기가 주는 함의는 비교적 명확하다. print가 핸들러 안에서 크래시를 일으킬 수 있다는 사실은 흥미로운 지식이지만, 시그널 핸들러 설계의 실질적 고려 사항으로까지 확대 해석할 필요는 없다. 필자 스스로도 이를 시그널에 관한 트리비아로 위치시키며, 일상적인 코드에서 걱정할 문제로 보지 않는다.

그럼에도 변하지 않는 조언은 하나 있다. 시그널 핸들러 안에서는 사소하지 않은 작업을 하지 말라는 것이다. 파이썬의 두 단계 처리 구조가 저수준 제약을 상당 부분 완화해 주더라도, 재진입 가능성이 남아 있는 이상 핸들러는 최대한 짧고 단순하게 유지하는 편이 안전하다. 흔히 권장되는 방식은 핸들러 안에서는 플래그를 세우거나 이벤트를 기록하는 정도로 그치고, 실제 로직은 메인 실행 흐름으로 넘겨 처리하는 것이다.

마지막으로 이 실험 결과를 받아들일 때 유의할 한계가 있다. 원문의 크래시는 필자의 특정 환경에서, 시그널을 의도적으로 폭주시키는 인위적 조건 아래에서 재현된 것이다. 파이썬 버전이나 플랫폼, 시그널 도착 빈도에 따라 동작은 얼마든지 달라질 수 있으므로, 이를 print가 언제나 위험하다는 식의 일반 규칙으로 확장해서는 안 된다. 결국 이 사례가 알려 주는 것은 특정 함수의 위험성이라기보다, 비동기 이벤트가 개입하는 코드 경로에서는 언제나 재진입이라는 변수를 염두에 두어야 한다는 오래된 원칙이다.