최근 서비스의 BM을 논의하는 과정에서, 현재 이용 중인 외부 서비스의 기능을 확인해야 했다. 이메일을 발송해 주는 서비스인데, 우리에게 중요한 부분은 Soft Bounce였다. 메일함이 가득 차거나 어떤 이유로 메일이 발송되지 못할 때, 이에 대한 알림을 받는 것이다.

우리가 이용 중인 서비스는 Soft Bounce를 지원한다. 이걸 지원한다는 것은, 이 서비스를 이용해서 이메일을 보냈을 때 메일 발송에 실패할 경우 이 정보를 확인할 수 있다는 뜻이다. 서비스도 꽤 큰 서비스이고 문서화도 잘되어 있고 구글 메일로 테스트할 때 잘 동작했다.

그런데, 네이버 메일로만 동작하지 않았다. 받는 메일의 수신함이 가득 차서 안내 메일이 분명 오는데 상태 값은 Delivered로 표시되었다. 이런 문제를 만나면 (필요하기도 했고) 정확한 원인을 파악하고 해결하고 싶어진다.

그렇게 원맨쇼가 시작되었다. 첫째로 메일의 원문을 분석해서 구글과 비교해보았다. 구글에는 Content-Type이 message/delivery-status인 MIME이 포함되어 있는데, 네이버에는 없었다. 그리고 이 부분에 작성된 정보가 발송 실패에 대한 원인과 안내를 나타내고 있었다.

아, 네이버에서 보내는 반송 메시지에 이 상태가 없어서 Soft Bounce로 처리할 수 없다고 확신했다. 너무나도 그럴듯하고 내가 아는 선에서 구조상 가능하기도 했고, 무엇보다 납득하기 좋았다.

그런데 문득 A가 다른 서비스로 테스트해 보는 것도 필요하지 않겠냐고 했던 얘기가 생각났다. 이미 나는 완벽하게 이해했기 때문에 굳이 그럴 필요가 없어 보인다고 했었는데, 갑자기 혹시나 하는 마음이 들어서 부랴부랴 다른 서비스에 가입했다. 이 서비스는 계정 생성부터 심사를 받아야해서 받았는데, 퇴근길 버스에서 심사 완료 메일을 받았다. 버스에 앉아서 노트북을 켜고 바로 테스트했는데, 거짓말처럼 Soft Bounce 라고 표시되었다.
(소리질러~~~~~)

내가 파악한 원인이 맞았을 수도, 틀렸을 수도 있지만 그냥 이용했던 서비스의 완성도가 떨어졌을 뿐이었다.

이렇게 무지는 아이러니하게도 “안다”는 생각을 가지게 한다. 모든 “아는 것”에 대해 의심할 필요는 없지만, 확인할 계기가 생긴다면 마다하지 않고 확인해 보는 것이 좋을 것 같다.

문득 이렇게까지 상호보완적일 수 있을까 싶다는 생각이 들었다.