예외처리에 대한 잡설

예외처리에 대해 별 생각 없었다. 문제 생기면 throw 날리고, Advice에서 적절히 변환해서 클라이언트에 전달하면 되는 거 아닌가? 이런 생각은 서비스에 대한 몰이해에서 오는 것 같다. 예외처리는 그렇게 간단하지 않다. 오히려 몹시 까다로운 영역이다. 내가 담당하는 방문차량 예약 서비스에서 자주 발생하는 예외는 이렇다.

1. 사용자가 예약을 신청함.
2. 시스템은 예약이 들어오면 단지의 차단기 서버로 예약 내역을 전송함.
3. 이때 차단기 서버가 죽어있음.

차단기 서버는 우리가 관리할 수 있는 영역이 아니다. 또 우리는 정확히 어떤 이유로 요청이 전송이 안 되는 것인지 알 수도 없다. Connection time out이 발생하면 단지 저쪽 서버에 문제가 생겼다고 추측할 수 있을 뿐이다. 그러면 차단기 서버 관제사에 “서버 죽었습니다. 해결해주세요”하고 손 놓고 기다려야 할까? 그 사이에 계속해서 사용자로부터 예약이 들어오면 어떻게 하지? 최초에 차단기 서버가 죽었다는 것을 판단할 수 있게 해준 사용자에게는 어떻게 피드백을 주지? 차단기 서버가 복구될 때까지 예약을 막아야 할까? 관리자에게는 어떻게 알려야 할까?

• 최초로 차단기 서버가 죽었다는 것을 판단할 수 있게 한 사용자에게는 어떻게 피드백을 줄 것인지
• 단지 관리소에는 어떻게 이 사실을 알릴 것인지
• 개발자는 어떻게 이 문제를 파악하고, 알릴 것인지
• 문제가 생긴 사이 들어오는 예약은 어떻게 할 것인지

하나의 예외 케이스인데도 대충 생각해도 처리해야 할 게 여러 가지다.

기존 프로세스는 이랬다.

1. 예약 전송이 실패했다는 경보가 옴.
2. 개발자가 DB와 로그를 확인한 후 직접 요청을 한 번 날려봄.
3. Connection time out이 발생하면 차단기 서버가 죽었다고 판단하고 차단기 서버 담당 개발자에게 알림
4. 복구 중에 예약이 계속 들어올 수 있으니 차단기 서버와 연동을 잠시 중단함
5. 운영팀에게 알리고 단지에 내용 전달

그러니까 경보가 오는 것빼고는 다 손으로 해결해야 했다. 지금까지는 딱 두 곳에서 다른 시기에 이런 문제가 발생했기 때문에 수동으로 처리해도 큰 문제는 없었다. 하지만 이런 문제가 동시에 서너 곳에서 터진다면 시간도 오래 걸리고 파악하는 데 어려움도 있을 것이다.

이 문제를 어떻게 해결할 수 있을까?

차단기 시스템이 각각 다른 곳에서 한 번씩 죽었는데 이때 공통점이 있었다. Connection time out이 발생했다는 것. 그리고 아직까지 서버가 죽지 않았는데 커넥션 타임 아웃이 발생하는 경우는 없었다는 것. 이 사실을 기반으로 Connection time out이 발생하면 차단기 시스템에 문제가 생겼다는 것을 짐작할 수 있다. 그러면 이렇게 해볼 수도 있지 않을까?

• Connection time out 발생 시 파트너 시스템 다운 예상된다는 경보 채널로 알림
• 운영팀에 수동으로 전달하지 않고 메시지를 바로 운영팀 채널로 전송함.
• 복구되는 동안 예약 신청을 잠시 막아둠. 혹은 예약은 받되, 시스템 점검 중이라 제대로 신청이 안 될 수 있다는 알림 메시지를 띄움.
• 우리 시스템 내부적으로는 전송 실패한 내역을 일정 주기(5초가 될 수도 있고 1분이 될 수도 있음)마다 차단기 시스템으로 전송한다. 이게 일종의 Health check가 됨. 계속해서 커넥션 타임 아웃이 발생하면 무시하다가, 어느 순간 정상적으로 전송 완료 되면 경보 채널로 차단기 시스템 복구되었다는 알림 전송.
• 최초 사용자에겐 어떻게 알리지? 아무튼.

이 정도만 되어도 사람이 들여야 하는 노력을 줄일 수 있을 것 같다.

어쨌거나 예외처리는 그냥 catch해서 로그만 찍고 만다거나. 혹은 그냥 throw 해서 예외 메시지만 띡 보여주고 끝나는 게 아니라는 사실을 이번에 알았다. 또 이게 제대로 처리하려면 엄청 머리 아프고 방법은 알겠는데 코드는 도대체 어떻게 해야 하지? 비즈니스 로직에 try-catch 달아서 catch에 처리 로직 주렁주렁 달아놓아야 하나? 그렇게라도 하는 게 하지 않는 것보다 낫다고 생각하지만. 어쨌든 예외처리는 골치 아프고 고민해야 할 것도 많고 그런 만큼 나름대로 재미(?)도 있는 영역인 것 같다.