여기 서버타입 1~3이 있다고 하자. 이하 줄여서 서버로 통칭.
<전제>
1. 서버1과 2는 서버 3으로 특정한 패킷을 1초간격으로 계속 전송한다.
2. 서버1은 A,B 타입의 패킷을 보낸다
3. 서버2는 A,B,C,D 타입의 패킷을 보낸다.
4. 서버3은 서버1,2로부터 수신만을 하며 응답은 보내지 않는다.
5. 서버3은 서버1,2로부터 수신된 패킷을 분석하는 서버이다.
6. A,B 타입의 패킷은 서버 1,2의 송신모듈에서 만든다.
7. C,D 타입의 패킷은 서버 1,2의 송신모듈이 연동하는 타 모듈에서 수신한 것으로 서버3으로 toss한다.
8. 송신모듈은 본인이 수신부는 타인이 만들었다.
<상황>
여기에 추가기능이 들어갔다. 서버3에서는 1,2로부터 보내는 패킷이 특정시간 이상 도착하지 않으면 서버 1,2에서 패킷송신을 담당하는 모듈이 장애가 발생했다고 판단하는 것이다. 그 판단은 연결 이후 최초로 도착한 패킷의 특정부분을 분석하여 해당 서버 시스템의 이름을 기억해두고, 이 후 패킷과 비교를 하는 것.
그러나 서버3의 기능을 만든 사람도 모르는 문제가 하나 숨어있었다.
서버 1,2에서 보내는 A,B 타입의 패킷은 송신모듈이 직접 생성하는 것으로 config에 의해 입력된 SYSTEM ID을 가져와 전송시 포함시켜 보내준다. 그러나 C,D 타입의 패킷은 송신모듈도 다른 곳으로부터 받은 것으로서 일부러 내용을 열어보지 않는 한 뭐가 있는지 알 수가 없다.
그런데 서버3에서는 무조건 최초 도착한 패킷을 사용하기 때문에, 그 패킷의 타입이 뭔지 체크를 하지 않는 것이다. 즉, 서버1의 모듈과는 문제가 없었지만 서버2와 연동을 하게되면 문제가 발생한다. 서버2의 A,B,C,D 타입의 패킷은 순서가 정해져 있지 않기 때문에 최초로 도착한 패킷이 C,D일 경우 SYSTEM ID가 config에서 입력한 것이 아닌 최초 전송한 타 모듈이 기입한 것이기 때문이다.
<해결?>
본인의 상식으로는 toss하는 모듈이 패킷을 다시 까서, 강제로 SYSTEM ID를 패킷에 집어넣고 서버3로 전송하는 해결방식이 이해가 가지 않았지만, 밤을 꼴빡 샌 후라 피곤하기도 하고 더이상 왈가왈부 하기도 귀찮고 해서 '지시'하는 대로 했다. 그런데 이 모듈이 한 서버에만 설치된 것이 아니라서 모듈이 설치된 모든 서버에서 교체하는 작업도 병행해서 따라왔다.
수신부인 서버3의 추가기능에서 어차피 패킷을 분석하는데 거기에 예외처리 몇 줄 더 넣으면 되는 것이 아닌가? 타입 A, B일때만 거기에 적인 SYSTEM ID를 저장하고, 다른 패킷일때는 저장하지 않으면 되는 문제다.
<여운>
그래 거기까지는 좋았다. 일단 겉으로 보기에는 해결이 되어 집으로 갈 수 있을것 같았으나, 뭔가 미심쩍은 것이 있어 혹시 강제로 패킷에 ID를 넣은것이 다른 기능에 이상한 영향 즉, side effect를 끼치지는 않는지 물어보자 그제서야 송신 모듈을 고치면 수신 서버의 다른 부분이 작동하지 않는 것이 드러났다.
그로인해 결국 수신부를 고쳐서 다시 기동했는데, 또 그 부분은 고치면서 원래 문제가 되었던 부분은 끝까지 고치지 않았다. 이건 [아집]이라 본다. 따지고 보면 처음부터 자신만 고치면 해결된 문제(버그1)인데 내가 고치게 했고 그 부분을 고쳤기 때문에 문제가 되는 부분(버그2)이 생기자 그제서야 거기(버그2)만 수정을 했다. 이게 도대체 뭔가?
<총평>
상용에 적용을 하고, 마감시간이 아슬아슬하게 다가오는 상황, 재수가 없으면 갑의 한마디에 원복을 하는 상황이 다가오지 않았다면 끝까지 우겨보았을지도 모른다. 그러나 같이 간 사람들 다 지쳤고 나도 정신적/육체적으로 피곤 했기에 수긍 아닌 수긍을 하고 말았지만 스트레스를 엄청받았다. 그리고 더 짜증나는 것은 그러고도 결국 오전에 몰래 수정작업(버그2로 인해)을 했어야 했으며, 미심쩍어하는 갑으로 인해 오후 늦은시간 까지 모니터링을 내가 했어야 했다는 것이다.