상대가 보는 하나뿐인 주소

외부 연동처에 등록해 둔 허용 주소가 열몇 개인데 절반은 어디에 쓰는지 아무도 몰랐다. 안 쓰는 것부터 지우기로 하고 각 주소의 접속 빈도를 뽑아 근거로 삼기로 했다.

Open Table of contents

목록에 섞여 있던 내부 주소

목록을 보다가 등록된 것 중 몇 개가 내부 서버 주소인 것을 발견했다. 그 서버들은 외부로 나갈 때 게이트웨이를 거치는 구성이었다.

그러면 그 주소가 상대에게 보일 일이 없는데 왜 목록에 있는지가 먼저 풀려야 했다. 그리고 그것들의 접속 빈도를 어떻게 뽑을지도 문제였다.

게이트웨이를 거치면 나가는 패킷의 출발지가 게이트웨이 주소로 바뀐다. 상대편 서버가 기록에 남길 수 있는 것은 그 하나뿐이다.

뒤에 몇 대가 있든 어느 대가 얼마나 자주 부르든 상대는 관측할 방법이 없다. 상대편 목록의 항목과 우리 쪽 서버가 일대일로 대응하지 않는 구조였다.

우리 로그에는 내부 서버별 호출 횟수가 남지만 그 숫자는 상대편 목록과 아무 관계가 없다. 반대로 게이트웨이 주소는 나가는 시점에 붙는 값이라 애플리케이션 로그에 별도 항목으로 안 잡힌다.

빈도가 높은 것은 상대가 모르고 상대가 아는 것은 빈도가 안 잡힌다. 접속 빈도로 삭제 대상을 고르려던 계획이 여기서 성립하지 않게 됐다.

내부 주소가 등록돼 있다는 사실 자체가 단서였는데 과거 어느 시점에는 그 주소가 상대에게 직접 보였다는 뜻이다. 그때는 게이트웨이를 안 거치는 경로가 있었을 것이다.

그래서 기준을 경유하지 않는 직접 호출 경로가 코드에 살아 있는가로 바꿨다. 대부분은 이미 게이트웨이를 타게 바뀌어 있었고 두 곳만 아직 직접 호출이라 그에 해당하는 주소만 남겼다.

후보로 분류한 것도 바로 지우지는 않았다. 코드 검색으로 직접 호출이 없다는 것과 실제로 그 주소로 나가는 트래픽이 없다는 것은 다르기 때문이다.

설정 파일을 거치거나 다른 저장소에 있는 호출은 한 번에 안 잡히고 가끔 도는 배치는 코드에 있어도 최근 기록이 없다. 그래서 지워도 될 것으로 보인다까지만 적고 실제 삭제는 상대편 담당과 일정을 맞춰 한 번에 하기로 했다.