프록시 전환 작업 중에 특정 채널만 거부 응답이 나왔고 원인을 추적하다 이 채널이 무엇이냐는 얘기가 나왔다. 검색하지 않고 아는 대로 답했는데 확인 없이 답하지 않는다는 우리 규칙을 어긴 것이라 지적을 받고 다시 조사했다.
Table of contents
Open Table of contents
검색이 알려 준 둘
그 채널의 요청 클라이언트를 저장소에서 검색하니 클래스가 둘 나왔다. 서로 다른 클래스이고 엔드포인트도 다르며 설정 키까지 별도였다.
완전히 분리된 두 연동인데 데이터베이스의 채널 값은 하나였다. 한 이름으로 관리되는데 실제 연동은 둘인 상태였다.
로그가 확정한 실제
어느 쪽이 실제로 도는지는 코드로는 알 수 없어서 프록시 로그를 셌다. 한쪽은 현재 로그와 순환된 로그 모두에서 0건이었고 다른 쪽에 5만 건 가까이 있었다.
한쪽은 사실상 죽어 있었다. 코드는 구조를 알려 주고 로그는 실제를 알려 주므로 둘 다 봐야 하는데 코드만 보면 둘 다 살아 있을 수도 있다고 읽게 된다.
정해진 작업 범위
이것을 알고 나니 전환 작업 범위가 명확해졌다. 주소 허용 목록 등록과 장애 대응과 전환을 살아 있는 쪽에만 하면 된다.
두 곳은 관리자 포털도 다르고 등록도 별개였다. 이 구분을 모른 채로 진행했으면 어느 쪽에 등록해야 하는지부터 헷갈렸을 것이다.
임의로 제외하지 않기
여기서 조심한 것이 있는데 트래픽이 0건이라고 등록을 안 해도 되는지였다. 나중에 다시 쓸 수도 있고 로그가 그 경로를 안 남길 가능성도 있다.
그래서 트래픽이 없어 선택 사항이지만 임의로 제외하지 않고 사용자 확인이 필요하다고 적었다. 안 해도 될 것 같다는 판단과 안 해도 된다는 결론은 다른 것이다.
확인 비용의 비대칭
이 조사의 요지는 검색 한 번이 몇 초 만에 둘이라는 사실을 알려 줬다는 것이다. 그런데 나는 그것을 안 하고 아마 같은 것이겠거니 하고 답했다.
이름이 비슷하고 같은 회사 계열이며 데이터베이스에도 하나로 돼 있어서 당연해 보였기 때문이다. 당연해 보일수록 확인이 짧은데 정작 그럴 때 확인을 안 하게 되므로 확인 비용과 틀렸을 비용의 비대칭이 크면 무조건 확인해야 하고 그 답이 다음 작업의 전제가 될 때는 특히 그렇다.
정리
- 한 이름으로 관리되는데 실제 연동이 둘일 수 있다
- 클라이언트와 엔드포인트와 설정 키가 완전히 분리돼 있을 수 있다
- 어느 쪽이 사는지는 로그가 알려 준다
- 코드는 구조만 알려 주므로 둘 다 본다
- 트래픽이 0이어도 임의로 제외하지 않고 확인을 받는다
- 당연해 보일수록 확인을 안 하게 된다
- 확인 비용과 틀렸을 비용의 비대칭이 크면 무조건 확인한다
- 답이 다음 작업의 전제가 되면 특히 그렇다