웹 API는 HTTP 상태 코드를 사용하여 효과적으로 오류를 알리지만, 배치 작업은 실행 환경이 오류를 인식하기 위해 다른 접근 방식이 필요합니다. 처음에는 작성자가 false 또는 status: 500 객체를 반환하여 오류를 알리려는 기존 Lambda 함수를 발견했습니다. 그러나 Lambda의 관점에서 이러한 조치는 성공적인 호출로 간주되어 CloudWatch에 오류가 기록되지 않았습니다. 결과적으로 구성된 CloudWatch 경보가 트리거되지 않았고 Slack 알림도 전송되지 않았습니다. 작성자는 웹 API에서 흔히 사용되는 500 상태 코드를 반환하는 익숙한 패턴이 배치 작업에는 적용되지 않는다는 것을 깨달았습니다. 대신, 배치 작업의 경우 실행 환경이 문제를 감지하려면 전체 호출이 실패해야 합니다. 이를 해결하기 위해 오류 처리가 예외를 발생시키도록 리팩토링되었으며, 이로 인해 Lambda 호출이 실제로 실패했습니다. 이 실패는 CloudWatch Errors 메트릭에 올바르게 반영되어 경보가 트리거되고 알림이 전송될 수 있었습니다. 이 경험은 오류 처리가 애플리케이션 코드 자체를 넘어선다는 것을 강조했습니다. 외부 모니터링 및 경보 시스템에서 오류를 관찰할 수 있도록 해야 합니다. 따라서 오류 처리를 고려할 때, 오류가 내부적으로 어떻게 관리되는지뿐만 아니라 외부 시스템에 어떻게 오류가 알려질 것인지도 질문해야 합니다. 이를 통해 배치 프로세스에 대한 모니터링 및 경보 메커니즘이 의도한 대로 작동하도록 보장합니다.