파일쓰기 아키텍처 재설계 여섯 개 하위 프로젝트를 전부 끝내고 릴리스한
다음, 남아있던 GitHub 이슈들을 하나씩 들여다봤다. 그중 하나가 “/sync의
self-healed links 기능이 죽은 코드”라는 제목이었다.
이슈만 보면 애초에 미완성 기능 같았다
이슈 설명을 읽어보니 SyncScanResult.selfHealedLinks라는 필드가 있는데,
실제로 채워지는 곳 없이 항상 빈 배열로 하드코딩돼 있었다. UI 렌더링
분기도, 리포트 출력 분기도 다 있는데 정작 데이터를 만드는 로직이
없었다. 딱 봐서는 “만들다가 중간에 그만둔 기능”처럼 보였다.
git log를 열어보니 실제로 동작한 적이 있었다
그냥 넘기기 전에 이 필드가 언제 생겼는지 히스토리를 추적해봤다. 2026년
6월 21일 커밋에서 실제로 동작하는 구현을 발견했다 — wiki/index.md에
적힌 위키링크들을 훑어서, 폴더 경로 없이 이름만 있는 링크를 실제 파일과
매칭해 본문을 직접 고쳐 쓰는 “자가 치유”를 정말로 수행하고 있었다.
문제는 그다음이었다. v0.85.0에서 index.md 파일 자체를 완전히 없애고
metadataCache 기반으로 옮기는, self-healing과는 전혀 무관한 마이그레이션
작업을 하면서 이 기능의 유일한 입력 소스가 통째로 사라졌다. 그 순간
반환값만 빈 배열로 하드코딩해서 빌드가 깨지지 않게 막았을 뿐, 그 값을
쓰던 타입 정의·UI 분기·리포트 출력 세 층은 그대로 방치됐다.
잘 동작하던 게 조용히 죽는 방식
며칠 전에 다룬 이슈(#1)는 정반대 모양이었다 — 실제로는 이미 고쳐진 문제인데 아무도 이슈를 다시 확인해서 닫지 않아 OPEN 상태로 남아있었다. 이번 건 그 반대다. 실제로 잘 동작하던 기능이 완전히 다른 작업에 휩쓸려 조용히 죽었는데, 그 죽음을 아무도 알아차리지 못해서 죽은 채로 남아있던 층들만 이슈로 등록됐다.
둘 다 결국 같은 얘기다. 코드나 이슈의 “현재 상태”와 “실제로 지금 참인 것” 사이의 간극은 저절로 안 메워진다. 한쪽은 고쳐진 걸 아무도 확인 안 해서 열려 있었고, 다른 쪽은 죽은 걸 아무도 확인 안 해서 살아있는 척 남아있었다.
지우는 작업에서도 발견한 것
죽은 코드를 지우다가 두 가지를 더 발견했다. 하나는 chat-view.ts의
리포트 분기 하나가 단순히 “안 쓰이는 코드”가 아니라 “논리적으로 도달
자체가 불가능한 코드”였다는 것 — 선행 조건이 이미 같은 케이스를 앞서
처리하고 리턴시키고 있어서, 그 분기까지 실행이 도달할 수 있는 경로
자체가 없었다.
다른 하나는 전체 브랜치 최종 리뷰에서 나왔다. 코드는 다 지웠는데,
README.md의 /sync 섹션 헤더가 여전히 “Self-Healing”을 광고하고
있었다. 코드를 맞게 지운 것과 문서까지 포함해 시스템 전체가 일관된
것은 별개의 질문이라는 걸, 재설계 시리즈에서 이미 한 번 배웠던 걸
훨씬 작은 스케일에서 다시 확인한 셈이다.
배운 점
이슈 하나를 그대로 믿지 않고 실제 히스토리를 추적해본 게 이번의
핵심이었다. “미완성처럼 보인다”와 “실제로 미완성이다”는 다른 질문이고,
그 차이는 git log를 열어보기 전엔 알 수 없었다. 그리고 죽은 코드를
지우는 작업도 생각보다 꼼꼼히 봐야 한다 — 도달 불가능한 분기, 문서에
남은 흔적까지 포함해서.