지워도 되는 것과, 지우면 안 되는 것

몇 년 전 심어졌던 로그 하나를 지웠다.

그 로그는 현재 사용처가 불분명했던 터라 코드를 정리하는김에 지우게 되었는데, 그제야 누군가는 그 몇 년 전 심어졌던 로그를 보고 있었다는 사실을 알게 되었다.

그 로그는 오래된 지표였다.

검색 결과에서 실제 콘텐츠가 클릭되었는지를 확인하기 위해 만들어진 지표로, 당시에는 제한적으로나마 의미가 있었지만 지금의 서비스 구조에서는 더 이상 그 역할을 하지 못하고 있었다.

예전에는 한 페이지 안에서 콘텐츠가 바뀌었고 사용자의 맥락도 끊기지 않았지만, 지금은 클릭하면 새 탭이 뜨고 컨텍스트는 자연스럽게 분리된다. 지표는 남아 있었지만, 그 안에 담긴 데이터는 이미 흐트러져 있었다.

연말이었다. 코드 품질 개선이라는 미션 아래 중복된 코드와 불필요한 지표들을 하나씩 정리하고 있었다. 그러다 그 로그가 눈에 들어왔다. 코드 양만 차지하고 데이터로서의 신뢰도도 보장하기 어려운 지표였다.

우선 disable 해두고 영향도를 살펴보기로 했다. 며칠을 지켜봤지만 아무런 반응도 없었다. ‘아무도 안 쓰는구나.’ 그렇게 판단했고, 나는 그 로그를 정리했다.

며칠 뒤 휴일에, 코드 리팩토링 작업이 있어 우연히 회사에 나와 있었다. 그날 Jira 알림을 확인하다가 해당 로그에 대한 인시던트가 등록되어 있는 것을 보게 되었다. 고객사 담당자가 남긴 기록이었다.

평소 같았으면 다음 주 월요일에 답했을 일이다. 하지만 이번 일만큼은 사전 공유 없이 정리한 내 판단 미스가 분명했기에, 그날 바로 코멘트를 남겼다.

사과를 했고 상황을 설명했으며, 다음부터는 먼저 묻겠다고 약속했다. 그건 급함보다는 책임에 가까운 선택이었다.

그제야 알았다. 누군가는 그 데이터를 정확해서가 아니라, 익숙해서 보고 있었다는 사실을.

데이터의 정합성을 이야기하려면 설명은 길어질 수 있다. 왜 이 지표가 더 이상 사용자 행동을 정확히 반영하지 못하는지, 구조가 어떻게 바뀌었는지, 왜 신뢰도를 담보하기 어려운지까지 모두 말할 수는 있었다.

하지만 나는 그 이야기를 하지 않았다. 이건 코드의 문제라기보다, 일을 둘러싼 나와 그 사람의 문제에 더 가까웠기 때문이다.

일을 하다 보면 지워도 되는 것과 지우면 안 되는 것이 있다. 코드는 지울 수 있어도 운영의 관성은 쉽게 지워지지 않고, 데이터는 틀려도 차트는 살아남는다.

논리보다 관계가, 정확도보다 기록이 더 큰 힘을 갖는 순간도 있다. 이런 일들은 어디에도 매뉴얼로 남아 있지 않다.

이번 일을 겪으며 나는 한 가지를 배웠다.

의미 없어 보이는 코드일수록, 지우기 전에 한 번 더 멈춰 생각해봐야 한다는 것.

그리고 정확한 데이터가 중요하다는 사실은 변하지 않지만, 현실에서는 정확도보다 관성이 더 오래 살아남는 경우도 많다는 점이다. 그걸 받아들이는 것 역시, 이 세계에서 오래 일하는 법 중 하나일지 모른다.