내가 죽은 엔드포인트 감지를 자동화하고 Node.js 코드베이스에서 16,000줄을 제거한 방법

Source: Dev.to

문제

8년간의 제품 반복 작업이 우리 Express API에 흔적을 남겼습니다. 수백 개의 엔드포인트에 걸쳐 45,000줄의 코드가 쌓였고—출시된 기능, 출시되지 않은 기능, 교체된 통합, 포기된 실험 등—어떤 것이 아직 사용 중인지 정확히 알 수 없었습니다.

정적 분석만으로는 해결되지 않았습니다. ESLint 같은 도구는 코드 수준에서 도달할 수 없는 부분을 알려줄 수 있지만, 엔드포인트가 실제 트래픽을 받고 있는지는 알 수 없습니다. 코드는 완전히 도달 가능하지만 프로덕션에서는 완전히 죽어 있을 수 있습니다. 우리는 다른 신호가 필요했습니다.

초기 수동 프로세스

우리는 접근 로그를 활용해 첫 번째 단계를 수작업으로 진행했습니다. 로그 데이터를 등록된 Express 라우트와 교차 검증하여, 몇 달 동안 트래픽이 전혀 없었던 엔드포인트를 후보로 선정하고, 각각을 수동으로 검증한 뒤에만 작업을 진행했습니다.

이 과정에서 접근 방식이 효과적임을 확인했습니다: 12개의 엔드포인트를 수동으로 제거했습니다. 하지만 수작업으로는 규모를 확장할 수 없었습니다. 검증은 느리고, 교차 검증은 번거롭고, 아직도 수백 개의 엔드포인트가 남아 있었습니다.

자동 탐지기

우리는 로그 분석 단계를 자동화하는 탐지기를 만들었습니다. 이 탐지기는 다음을 수행합니다:

• 접근 로그를 수집합니다.
• 관찰 기간(설정 가능) 동안 트래픽을 받은 모든 라우트를 추출합니다.
• 이를 Express 앱에 등록된 모든 라우트와 매핑합니다.
• 메타데이터(마지막 확인 날짜, 시간별 호출량, 사라지기 전 호출한 서비스 또는 클라이언트)를 포함한 순위화된 후보 리스트를 출력합니다.

탐지는 빠릅니다. 검증은 여전히 사람이 필요합니다—죽은 것으로 보이는 엔드포인트가 실제로는 분기별 작업, 레거시 모바일 클라이언트, 메인 트래픽 로그에 나타나지 않는 내부 스크립트에 의해 호출될 수 있기 때문입니다. 하지만 자동화된 출력 덕분에 증거를 검토하는 형태로 검증 속도가 크게 빨라집니다.

결과

코드베이스가 이제 더 쉽게 탐색되고, 온보딩이 빨라지며, 리팩터링이 덜 두렵게 되었습니다.

교훈

가장 어려운 부분은 탐지가 아니라 틀릴까 두려움이었습니다. 레거시 코드베이스에서 일해 본 모든 엔지니어는 이 느낌을 압니다—엔드포인트가 죽은 것처럼 보이고 로그도 확인되지만, 누군가가 1년에 한 번이라도 호출한다면 어떻게 할까 하는 고민이 있습니다.

답은 더 긴 관찰 기간과 검증 체크리스트이며, 마비가 되는 것이 아닙니다. 프로덕션, 스테이징, 카나리 환경에서 12개월 동안 트래픽이 전혀 없고, 예약 작업, 스크립트, 런북 등 어디에서도 참조되지 않았다면 그 엔드포인트는 죽은 것입니다. 제거하세요.

향후 작업

우리는 이를 Node.js/Express 코드베이스용 독립 실행형 도구로 만드는 방안을 탐색하고 있습니다. 여러분 팀도 같은 문제를 가진 레거시 API를 운영하고 있다면, 어떻게 다루고 있는지(또는 다루지 않고 있는지) 알려주시면 좋겠습니다.