Loki's Blog

들어가며

아무 데서도 참조되지 않는 쿼리 필드를 발견했다. 코드 검색으로는 어디서도 걸리지 않았고, 이 정도면 죽은 코드라고 판단할 만했다. 하지만 코드 검색은 우리 저장소 안에서 그 필드를 참조하는 코드가 있는지만 알려준다.

스키마에 노출된 필드라면, 우리가 관리하지 않는 클라이언트나 외부 소비자가 그 필드를 쿼리에 담아 쓰고 있어도 우리 쪽 저장소에는 아무 흔적도 남지 않는다. 코드에 안 보인다는 것만으로 지워도 된다고 확신하기는 부족했다.

커밋 기록과 슬랙을 뒤져 근거를 모았지만, 그럼에도 불안한 마음은 가시지 않았다. 삭제 자체는 되돌릴 수 있는 작업이었지만, 무언가 잘못됐을 때 그 사실을 알아차릴 방법이 마땅치 않다는 게 더 컸다. 이 불안은 왜 생기고, 어떻게 확신을 갖고 지워갈 수 있을까?

커밋과 슬랙에서 근거를 모았다

언제 만들어졌고 왜 안 쓰이게 됐는지부터 알아야 했다. 먼저 AI로 해당 코드의 생성 시점부터 이후 수정 이력까지 모두 추적했다. 변경될 때마다 남긴 메시지들을 시간 순으로 훑어보면 최소한의 실마리는 잡힐 거라 생각했다. 하지만 커밋 메시지만으로는 당시 맥락을 알기 어려워서, 주변 코드와 변경 흐름을 함께 분석해 왜 만들어졌고 왜 더 이상 쓰이지 않게 됐는지 유추하도록 지시했다.

동시에 슬랙 MCP로 관련 키워드를 검색해 히스토리도 확인했다. 커밋만으로 채워지지 않는 배경은 그 시점 대화에 남아 있을 가능성이 컸다. 다만 그 시절 쓰던 용어가 지금과 다르면 검색으로도 놓칠 수 있다는 한계는 있었다. 특히 이 쿼리가 도입된 시점 전후의 스레드를 우선적으로 살펴봤다. 단순히 누락된 죽은 코드인지, 아니면 의도적으로 남겨둔 코드인지를 판단하고 싶었다.

커밋과 슬랙을 모두 살펴보니, 생성된 지 3년, 마지막 수정은 2년 전이었다. 해당 쿼리를 소비하던 렌더링 로직은 새로운 아키텍처로 교체되며 제거됐고, 값을 공급하던 이 쿼리 정의는 같은 파일 안에 있었음에도 리팩토링 범위에서 빠져 남게 된 것이었다.

짐작하기로는, 그 리팩토링이 컴포넌트 구조를 바꾸는 데 집중되면서 같은 파일 안의 쿼리 정의까지는 검토 대상에 들지 못했을 것이다. 이 맥락을 근거로, 해당 쿼리 필드를 삭제하기로 결정했다.

근거를 모았는데도 배포 전까지 떨린 이유

근거가 있다는 것과 그 근거를 신뢰할 수 있다는 것은 달랐다. 삭제 PR을 올리고 리뷰까지 마쳤지만, 상용 배포 직전까지 계속 신경이 쓰였다. 리뷰어도 내가 정리한 근거를 보고 판단했을 뿐, 그 근거 자체에 빈틈이 있는지까지 따로 확인해준 건 아니었다. 몇 가지 가능성이 머릿속을 떠나지 않았다.

결국 내가 모은 근거가 전체의 일부에 불과할 수도 있다는 의심이었다. 커밋과 슬랙을 모두 확인했다고 해서, 당시의 모든 맥락이 기록으로 남아 있다는 보장은 없었다.

기록이 없다는 사실은, 없었다는 증거가 되지 못한다. 그저 내가 찾지 못했다는 사실만 말해줄 뿐이다. 근거를 아무리 모아도 이 불확실성 자체는 완전히 사라지지 않는다는 뜻이었다. 결국 할 수 있는 일은 그 확률을 낮추는 것뿐이었고, 배포가 무사히 끝나고 정상 동작을 확인한 뒤에야 비로소 그 불안이 가라앉았다.

과거 기록을 얼마나 믿을 수 있을까?

근거가 남아 있어야 모을 수 있다. 이번에는 커밋과 슬랙이 맞아떨어졌기 때문에 판단할 수 있었다. 이번 판단이 들어맞은 데는 실력보다 운이 컸다는 생각이 들었다. 하지만 둘 중 하나라도 어긋났거나, 애초에 기록이 없었다면 같은 결론에 도달하기는 어려웠을 것이다. 이 경험을 통해 지금 내가 남기는 커밋 메시지와 PR 설명, 슬랙에 남기는 논의 하나하나가 몇 달 뒤 누군가의 판단 근거가 된다는 점을 느꼈다.

AI로 생성한 메시지는 "무엇을 바꿨는지"는 잘 설명하지만 "왜 바꿨는지"는 빠지기 쉽다. AI는 눈앞의 diff만 보고 메시지를 쓴다. diff에는 무엇이 바뀌었는지는 고스란히 담기지만, 그렇게 바꾼 이유는 diff 밖, 개발자의 머릿속에만 있다.

이 상태로 넘어가면 당장은 편해도, 나중에 그 코드를 수정하거나 제거할지 판단하는 사람에게 중요한 단서 하나가 비게 된다. 이번에 내가 커밋 이력과 슬랙을 오가며 맥락을 다시 짜맞춰야 했던 것도, 결국 그 "왜"가 기록 어디에도 온전히 남아 있지 않았기 때문이다.

기록이 신뢰되려면 변경의 이유가 담긴 맥락과, 그 맥락을 온전히 담을 수 있는 작은 수정 범위가 함께 필요하다. 수정 범위가 작으면 빠진 부분이 있는지 바로 눈에 띈다.

반면 수정 범위가 크면 여러 요인이 한 커밋 안에 뒤섞여, 무엇이 의도적으로 남겨졌고 무엇이 단순히 누락됐는지 구분하기 어려워진다. 이번에 마주친 쿼리도 마찬가지였다. 컴포넌트 구조 전체를 바꾸는 큰 리팩토링 안에, 쿼리 하나를 남겨야 할지 지워야 할지에 대한 판단은 따로 적히지 않았다.

정리하며

다음 사람을 위해 무엇을 남겨야 할까? 고민 끝에, 커밋 메시지를 생성할 때부터 "왜 이 변경이 필요한지"를 반드시 포함하도록 규칙을 추가하려 한다. PR에도 작업의 출발점과 개선 내용을 명시하도록 정리할 생각이다.

구두로 오간 논의는 그 자리에서 흘려보내지 않고, 끝나면 관련 스레드에 결론만이라도 정리해서 남겨야 한다. 같은 개념을 팀이나 사람마다 다르게 부르면 검색어가 어긋나 기록을 놓치기 쉬운데, 이번 조사에서도 겪었던 한계다. 그래서 코드와 문서에서 쓰는 용어를 슬랙에서도 동일하게 맞추려 한다. 검색되지 않는 기록은 없는 것과 다르지 않다.

좋은 기록이 좋은 판단으로 이어진다. 다음에 같은 코드를 마주쳤을 때는 커밋과 슬랙을 오가며 근거를 재구성할 필요 없이, 기록 자체만으로 판단에 필요한 단서를 얻고 싶다. 이렇게 남긴 기록은 단순한 시간 절약을 넘어 판단의 일관성까지 높여줄 것이다.

이제는 AI가 그 기록을 탐색해 사람보다 더 빠르고, 때로는 더 일관되게 판단을 돕는 시대다. 그렇다면 내가 할 일은 AI가 정확하게 찾아내고 해석할 수 있도록, 맥락과 의도를 빠짐없이, 그리고 검색 가능한 형태로 남겨두는 것이다. 기록의 품질이 곧 판단의 품질로 이어질 수 있도록 말이다.