매주 금요일만큼은 제 시간에 퇴근하고 싶은 게 직장인들의 마음이지만... 저녁 늦게 일이 터져서 어쩔 수 없이 야근을 해야 할 때도 있지요. 특히 개발자가 그렇지요. 서버 장애는 밤낮을 가리지 않으니까요.
이번 장애는 한 외국의 게임카드 구입후 받은 문자 메시지에서 시리얼 번호가 빠져있었습니다. 이 문제가 목요일에도 발생했었는데, 금요일에 또 발생하여 당황스러웠고 밤늦게 해결했습니다. 과정을 적어보니 생각보다 복잡한 과정들이 있었습니다.
해당 외국 업체의 서버 주소는 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개여서 발생하는 문제도 있습니다. 코드가 중복되기 때문에 수정을 하려면 두 곳 다 수정해야 하기 때문입니다. 제가 입사하기 전부터 구조가 그렇게 짜여져 있었는데, 이걸 통합할 수 있는지 검토해봐야 하겠습니다. 이번 사건과 같이 중복 코드는 상당한 골치거리가 되기 때문입니다.
