전 편에서
디버그 로그 코드를 세 번 연속으로 다시 훑었다. 매번 검증 기준을 한 단계씩 올릴 때마다
(코드에 호출문이 있다 → 실제로 실행해서 확인한다 → 이번 세션 밖으로 범위를 넓힌다)
그 전 단계에서는 안 보이던 구멍이 나왔다. SOURCE_LOST, RAW_LINK_CORRECTED,
MD_EXTENSION_STRIPPED — 셋 다 “AI 출력을 코드가 조용히 고쳤는데 그 사실이 아무
데도 안 남는다”는 똑같은 모양이었다.
이 정도면 다 됐다고 생각했다. 근데 아니었다.
방법을 바꿔서 한 번 더 — 이번엔 사냥감을 먼저 정하지 않았다
여기까지도 커밋하고 나니, 이번엔 방향을 바꿔봤다. 지금까지는 전부 “과거에 실제로
보고된 버그 목록”에서 거꾸로 찾아 들어가는 방식이었다. 이번엔 반대로, 아무 목록도
없이 src/ 전체에서 console.warn이 있는 자리를 처음부터 다 훑었다. 보고된 적
없는 구멍도 잡힐지 보려는 거였다.
셋이 더 나왔다. 하나는 Gemini가 제목을 JSON으로 안 주고 이상하게 주면 조용히 raw 텍스트 파싱으로 넘어가는 지점. 나머지 둘은 리팩토링 큐에서 더 신경 쓰이는 케이스였다 — AI가 “이 파일들을 합쳐라/나눠라”라고 카드를 띄워놓고, 정작 실행 버튼을 누르면 그 카드가 가리키는 원본 파일이 실제로는 없어서 조용히 아무 일도 안 일어나는 경우였다. 사용자 입장에서 제일 헷갈릴 수 있는 유형인데, 지금까지 한 번도 로그에 안 남고 있었다.
여섯 개가 되고 나니 양이 꽤 됐다. 그래서 다 한 번에 처리하는 대신 우선순위를 나눴다 — 비용 싸고 효과 확실한 것부터, 애매한 것, 아예 다른 설계가 필요한 것. 방금 찾은 셋은 전부 1순위였고, 그대로 처리했다.
후보였는데 아니었던 것
우선순위 목록에 있던 것 중 하나 — AI 노트를 만들 때 원본이 외부 URL인지 내부 위키링크인지에 따라 source를 다르게 채우는 분기 — 를 연결하려고 코드를 다시 읽다가, 이번엔 반대 결론이 나왔다.
지금까지 고친 것들은 전부 “정상 경로를 벗어난 드문 이상 상황”이었다. SOURCE_LOST도,
RAW_LINK_CORRECTED도, 방금 찾은 리팩토링 스킵 케이스도 — 다 흔치 않게 일어나는
일이었다. 근데 이 분기는 성격이 달랐다. meta.sourceFile이 있을 때마다 매번
정상적으로 갈라지는 흔한 로직이었다 — 외부 URL이면 이쪽, 위키링크면 저쪽, 그냥
분기일 뿐이다. 여기다 로그를 남기면 이상 징후가 아니라 거의 매번 찍히게 된다.
“드문 이상 징후만 남긴다”는 원래 설계 원칙과 정면으로 어긋나는 거였다.
그래서 이건 연결하지 않기로 하고, 문서에 왜 연결하지 않았는지 이유를 남겼다. 같은 패턴을 찾아내는 눈으로 다시 보면, 겉보기엔 비슷해 보이는 거짓 후보도 걸러낼 수 있다는 걸 확인한 셈이다.
남는 생각
1편에서 배운 건 “검증 기준을 계속 엄격하게 올려야 한다”는 거였다. 이번에 배운 건
조금 다르다 — 패턴 찾기에 익숙해지면, 그다음엔 아무 데나 같은 이름표를 붙이고
싶어진다. SOURCE_LOST, RAW_LINK_CORRECTED, MD_EXTENSION_STRIPPED를 연달아
찾고 나니, “AI 출력을 코드가 고치는 지점”처럼 보이면 일단 로그를 붙이고 싶은
쪽으로 기울었다. 실제로 소스 상속 분기도 처음엔 그렇게 보였다.
근데 코드를 다시 읽어보면 성격이 다르다는 게 드러났다. 구멍을 계속 찾아내는 것 못지않게, 찾아낸 것 중에 구멍이 아닌 걸 구멍이 아니라고 말할 수 있어야 검증이라는 이름값을 하는 거였다. 패턴에 취해서 전부 같은 이름표를 붙이면, 로그는 늘어나는데 정작 신호 대비 잡음만 늘어난다 — 그건 원래 이 기능을 만든 이유(드문 이상 징후만 남긴다)를 스스로 무너뜨리는 일이다.