대문 제작: imrahelk
매주 금요일만큼은 제 시간에 퇴근하고 싶은 게 직장인들의 마음이지만... 저녁 늦게 일이 터져서 어쩔 수 없이 야근을 해야 할 때도 있지요. 특히 개발자가 그렇지요. 서버 장애는 밤낮을 가리지 않으니까요.
이번 장애는 한 외국의 게임카드 구입후 받은 문자 메시지에서 시리얼 번호가 빠져있었습니다. 이 문제가 목요일에도 발생했었는데, 금요일에 또 발생하여 당황스러웠고 밤늦게 해결했습니다. 과정을 적어보니 생각보다 복잡한 과정들이 있었습니다.
- 해당 외국 업체의 서버 주소는 A, B가 있다.
- A는 구버전 서버이고, B는 신버전 서버이다.
- A, B 모두 카드 구입 요청하는 기능을 구현했다.
- 장기적으로 B로 가는 게 맞으나 안정성이 떨어져서 A를 계속 사용하고 있었다.
- 목요일 저녁에 갑작스레 A를 중단하고 B를 사용하라는 통보를 받았다.
- 목요일 저녁에 A에서 B로 서버 연결을 변경하였다.
- 그러나 A, B서버로부터 받는 카드 구입 결과의 포맷이 달라 추가 수정을 했다.
(이 때에도 문자 메시지에 시리얼 번호가 빠지는 오류가 있었음) - A 서버로 카드 구입 후 성공/실패 처리할 우리 서버의 URL이 등록되어 있으나, B는 그렇지 않다.
- 이에 성공/실패 처리 URL을 우리 서버에서 직접 실행하게 했다.
(두 케이스의 URL이 같은 게 아니라 다르다는 점) - 게임 카드 구입 후 문자 메시지에 시리얼 번호가 빠지는 문제가 해결되었다.
- 금요일 저녁에 위 문제가 다시 발생함을 확인했다.
- 확인 결과, A에 등록된 성공/실패 처리 URL이 B에도 등록되었다. (우리에게 아무 연락 없이)
- 이로 인해 성공/실패처리 URL이 2번 실행되고 있었다.
- B에 등록된 URL이 먼저 실행되었으나, 변경된 카드 구입 결과 포맷에 대한 처리가 반영되지 않아 시리얼 번호가 누락되었다.
- 나중에 실행되는 URL은 성공/실패 처리가 이미 완료되었기 때문에 별다른 처리하지 않고 종료된다.
- B에 등록된 URL이 실행하는 코드에서 변경된 카드 구입 결과 포맷에 대한 처리를 반영하여 문제 해결하였다.
B 서버에 URL을 등록할지 말지를 제가 확인해야 했던 것입니다. 현지 업체에서 이걸 임의로 등록할 줄은 몰랐던 것입니다. 개발을 하다보면 별의 별 일들이 있습니다. 그리고 성공/실패 처리 URL이 2개여서 발생하는 문제도 있습니다. 코드가 중복되기 때문에 수정을 하려면 두 곳 다 수정해야 하기 때문입니다. 제가 입사하기 전부터 구조가 그렇게 짜여져 있었는데, 이걸 통합할 수 있는지 검토해봐야 하겠습니다. 이번 사건과 같이 중복 코드는 상당한 골치거리가 되기 때문입니다.