Sentry가 제 Express 에러를 잡았습니다. 요청은 영원히 멈춰 있었어요.
(dev.to)
Express 4 환경에서 Sentry SDK를 사용할 때, async 핸들러의 에러가 프로세스를 종료시키지 않고 요청을 무한 대기 상태로 만드는 치명적인 '좀비 요청' 현상이 발견되어 개발자의 주의가 필요합니다.
이 글의 핵심 포인트
- 1Express 4의 async 핸들러 내 await 이후 에러는 Express 에러 미들웨어로 전달되지 않고 unhandled rejection이 됨
- 2Sentry SDK 사용 시 unhandled rejection을 포착하여 보고하지만, 프로세스 종료를 막아 요청이 무한 대기 상태가 됨
- 3Sentry 미사용 시에는 Node.js가 프로세스를 종료시켜 장애를 즉시 인지할 수 있으나, Sentry 사용 시에는 서버가 '정상'으로 표시되어 발견이 어려움
- 4Express 4의 해결책은 핸들러를 .catch(next)로 감싸거나 Express 5로 업그레이드하는 것임
- 5Sentry의 setupExpressErrorHandler는 동기 에러는 잡지만, async unhandled rejection은 잡지 못함
이 글에 대한 공공지능 분석
왜 중요한가?
이 문제는 서비스가 '정상'으로 표시되면서도 실제 사용자에게는 응답을 주지 않는 '침묵의 장애(Silent Failure)'를 유발합니다. 프로세스가 죽으면 재시작을 통해 장애를 인지할 수 있지만, 이 경우 서버는 살아있는 것으로 나타나 모니터링 시스템을 기만할 수 있습니다.
어떤 배경과 맥락이 있나?
Node.js 생태계에서 널리 쓰이는 Express 4는 async 핸들러가 반환하는 Promise의 거부(rejection)를 자동으로 에러 핸들러로 전달하지 못하는 구조적 한계가 있습니다. 반면 Express 5는 이를 자동으로 처리하도록 개선되었습니다.
업계에 어떤 영향을 주나?
Sentry와 같은 에러 모니터링 도구를 사용하는 팀일수록 오히려 이 위험에 더 노출됩니다. 에러는 Sentry에 기록되지만, 프로세스가 죽지 않기 때문에 운영팀은 에러 로그는 보되 실제 사용자 경험이 망가지고 있다는 사실은 뒤늦게 발견하게 됩니다.
한국 시장에 어떤 시사점이 있나?
많은 한국 스타트업이 안정성을 위해 Sentry 등 모니터링 도구를 적극 도입하고 있습니다. 하지만 도구의 설정 방식에 따라 오히려 장애 인지 시점을 늦출 수 있으므로, Express 4를 사용하는 레거시 환경에서는 반드시 핸들러에 .catch(next)를 적용하거나 Express 5로의 전환을 검토해야 합니다.
이 글에 대한 큐레이터 의견
이 사례는 모니터링 도구가 제공하는 '가시성'이 때로는 '착시'를 일으킬 수 있음을 보여주는 전형적인 사례입니다. Sentry는 에러를 성공적으로 포착하여 개발자에게 알렸지만, 동시에 Node.js의 기본 동작인 '에러 발생 시 프로세스 종료'를 방해함으로써 시스템을 좀비 상태로 만들었습니다. 이는 모니터링 도구의 설정이 시스템의 회복 탄력성(Resilience)에 어떤 영향을 미치는지에 대한 깊은 고민이 필요함을 시사합니다.
물론 Sentry를 통해 에러를 기록하는 것은 운영상 매우 중요하며, 프로세스가 죽는 것을 방지하는 것도 서비스 가용성 측면에서 긍정적입니다. 그러나 '에러 보고'와 '요청 처리 실패'가 분리되어 발생하는 이 트레이드오프는 매우 위험합니다. 개발자는 단순히 에러가 Sentry에 찍히는 것에 안주할 것이 아니라, 에러 발생 시 클라이언트에게 적절한 500 에러를 반환하고 프로세스가 안전하게 재시작될 수 있는 구조를 설계해야 합니다. 따라서 Express 4를 유지해야 한다면 핸들러를 명시적으로 감싸는 방어적 코딩을, 가능하다면 Express 5로의 업그레이드를 실행 가능한 최우선 과제로 삼아야 합니다.
관련 뉴스
댓글
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.