Skip to content
게으른 엔지니어의 기술 블로그
Go back

고치라는 지시부터, 다시 봐야 했다 3편 — 고치기 전에 한 번 더 물었다

고치라는 지시부터, 다시 봐야 했다 · 3/4편

확신을 실측 앞에 세워봤다 1편에서 반례 하나로는 원칙이 안 옮겨간다는 걸 실측으로 확인했다. 이번 편은 같은 날 있었던, 성격이 다른 두 사건이다. 하나는 코드를 고치기 전에 멈췄던 이야기, 다른 하나는 질문을 다시 들었던 이야기. 둘 다 “그대로 진행했으면 확실하게 틀렸을 것”이라는 공통점이 있다.

취소했는데 아무 안내가 없다

사용자가 /ingest를 쓰다가, 실행 도중 취소한 적이 몇 번 있었다. 그 시점까지 이미 성공적으로 만들어진 노트가 있는데도, 그 뒤에 자동으로 이어지는 /refactor 정리 제안이 아예 실행되지 않았다. 성공한 노트가 있으면 있다고 언급이라도 하든지, 아니면 그냥 자동으로 정리까지 돌려버리든지 둘 중 하나여야 하지 않겠냐는 지적이었다.

제일 먼저 떠오른 방법은 단순했다. 자동 실행을 막고 있는 조건문에서 “취소됐는지” 부분만 빼면 됐다. 실제로 그 방향으로 설계 문서까지 다 썼다.

왜 거기 있는지부터 봤다

코드를 고치기 직전에, 그 조건이 원래 왜 거기 있었는지 이력을 봤다. git blame으로 그 줄을 추적해보니, 우연히 남은 코드가 아니었다. 바로 전날, 다른 작업의 최종 리뷰 단계에서 일부러 추가된 조건이었고, 그 조건 하나만 지키는 전용 테스트까지 따로 만들어져 있었다. 그때 남긴 이유는 이랬다 — 사용자가 취소했는데 시스템이 곧바로 또 다른 AI 작업(리팩토링 제안을 위한 API 호출)을 자동으로 이어서 돌리면, “멈춰라”라는 사용자의 의도를 무시하는 셈이 된다는 것.

이 이력을 고치기 전에 사용자에게 그대로 전달했다. 사용자는 다시 생각해보더니 방향을 바꿨다 — “생각해 보면 내가 취소했으면 이유가 있어서 한 걸텐데.” 자동 실행 쪽으로 이미 써둔 설계 문서는 그대로 폐기했다. 대신 실제로 나간 수정은 훨씬 조심스러웠다. 자동 실행을 막던 조건과 그 테스트는 손도 안 대고 그대로 뒀다. 대신 취소 시 보여주는 요약 메시지에, 성공한 노트가 있으면 “정리가 필요하면 /refactor를 직접 실행해 확인해 달라”는 안내만 한 줄 추가했다. 멈추라는 의도는 존중하되, 뭘 해야 할지 몰라 막막했던 부분만 채운 것이다.

링크가 진짜로 있는지 물었는데

같은 날 다른 사건. 사용자가 노트 하나를 보여주며 물었다 — 본문에 [[wiki/2026/Q3/프레스토]]라는 링크가 있는데, 이게 실제로 존재하는 문서를 가리키는 링크가 맞아야 하지 않겠냐고. 이 질문을 “이 링크가 가리키는 파일이 실제로 존재하는가”로 알아들었다. 존재하지 않는 파일을 링크로 감싸면 안 된다는 규칙이 이 프로젝트에 이미 있었고, 그 규칙이 깨진 사례를 예전에도 몇 번 봤던 터라 자연스러운 해석처럼 느껴졌다.

그 해석을 따라 한 바퀴를 돌았다. 링크가 가리키는 노트 파일이 실제로 존재하는지 확인하고, 내용이 제대로 갖춰져 있는지, 원래 노트로 돌아가는 역링크까지 정확한지 확인했다. 관련된 노트를 하나 더 같은 방식으로 확인했다. 결론은 “문제없음”이었고, 그 결론 자체는 틀리지 않았다 — 두 파일 다 실제로 존재했고 내용도 멀쩡했다.

물었던 건 그게 아니었다 — 위키링크 파이프(|) 표시 텍스트 미지정

사용자가 정정했다. “난 이것들이 만들어진 걸 말한 게 아니고 본문에 보이는 게 거슬린다고 한 거야.” 실제 질문은 파일의 존재 여부가 아니라 화면에 보이는 모양이었다. 옵시디언 안에서 그 링크를 확인해보니, 스크린샷에 링크 텍스트가 “프레스토”가 아니라 전체 경로(“wiki/2026/Q3/프레스토”)로 그대로 나오고 있었다. 옵시디언 위키링크는 파이프(|) 기호로 표시 텍스트를 따로 지정하지 않으면 대괄호 안 내용을 통째로 그대로 보여준다 — 파일 이름만 자동으로 축약해주지 않는다. 원래 질문에 맞는 진짜 원인은 이거였다.

정확히 답할 수 있는 질문에 정확히 답했는데, 그게 애초에 물어본 질문이 아니었던 셈이다. 조사 자체는 엉성하지 않았다 — 그냥 처음부터 겨냥이 다른 곳을 향해 있었다. 사용자가 다시 짚어주지 않았다면 “확인해봤는데 문제없다”는 결론으로 그대로 끝났을 것이다.

남는 생각

두 사건은 확인한 대상이 달랐다. 하나는 코드가 왜 지금 이 모습인지 과거 기록을 확인했고, 다른 하나는 지금 듣고 있는 질문이 실제로 뭘 묻는 건지 다시 확인했다. 공통점은, 둘 다 “이미 아는 것 같다”는 느낌이 드는 순간에 있었다는 것이다. 조건 하나 빼는 건 뻔해 보였고, 링크 존재 여부를 확인하는 것도 뻔해 보였다. 뻔해 보이는 순간이야말로 한 번 더 확인할 타이밍이라는 걸, 같은 날 두 번 겪었다.


Share this post:

고치라는 지시부터, 다시 봐야 했다

  1. 1. 고치라는 지시부터, 다시 봐야 했다 1편 — 죽은 주석을 고치다가, 또 틀렸다
  2. 2. 고치라는 지시부터, 다시 봐야 했다 2편 — 가설은 반은 맞고 반은 틀렸다
  3. 3. 고치라는 지시부터, 다시 봐야 했다 3편 — 고치기 전에 한 번 더 물었다
  4. 4. 고치라는 지시부터, 다시 봐야 했다 4편 — 지우라는 지시와, 어떻게 지울지는 다른 질문이었다