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

이슈를 여섯 개 닫았다 — 근데 버그는 하나뿐이었다

만들고 있는 Obsidian 플러그인에 오래 쌓여 있던 GitHub 이슈들을 오늘 하나씩 다시 열어봤다. 이름만 보면 다 그럴듯한 버그였다 — “태그가 대소문자로 파편화된다”, “응답 검증이 얕다”, “로그가 안 남는다”. 하나씩 파고들어서 끝까지 확인했더니, 여섯 개를 닫았는데 실제로 코드를 고친 건 딱 하나였다. 나머지 다섯 개는 다시 확인해보니 애초에 버그가 아니었다.

공통점을 하나 찾았다

닫은 이슈들을 다시 훑어보다가 공통점을 발견했다. 전부 “이 버그를 고치다가 발견함” 식으로 기록돼 있었다. 즉 처음부터 직접 겪어서 재현한 문제가 아니라, 다른 버그를 조사하던 중에 근처 코드를 보다가 “어, 이것도 비슷하게 문제 있어 보이는데”라며 플래그만 꽂아둔 것들이었다.

이게 나쁜 습관은 아니다. 뭔가 조사하다가 의심스러운 걸 놓치지 않고 기록해두는 건 맞는 태도다. 문제는 그 순간엔 “그럴듯해 보인다”에서 멈추고, 실제로 재현하거나 끝까지 추적하는 검증은 생략된 채로 이슈만 남는다는 것이었다. 그리고 그 검증은 결국 나중에, 오늘, 한꺼번에 몰아서 해야 했다.

동기가 사라진 걱정

가장 인상적이었던 건 “나중에 이걸 다시 만들 때는 이 위험을 조심하라”는 식으로 남겨둔 이슈였다. 태그 처리 로직 하나를 표준 파서 기반으로 통째로 재작성하면 날짜 필드 값이 조용히 오염될 수 있다는, 실제로 재현까지 해서 확인한 진짜 위험이었다.

근데 다시 열어보니, 애초에 그 재작성을 하려던 이유(태그 형식을 못 알아채는 버그)가 이미 다른 방식으로 고쳐져 있었다. 위험은 여전히 사실이지만, 그 위험을 감수하면서까지 해야 할 이유 자체가 사라진 것이다. 버그가 없어졌는데 “그 버그를 고치는 방법이 위험하다”는 경고만 백로그에 남아 있었던 셈이다.

눈으로 훑은 것과 끝까지 따라간 것

제일 오래 붙잡고 있던 이슈는 “AI 응답 검증이 얕다”는 거였다. 다른 함수들은 응답이 이상하면 어디가 왜 이상한지 하나하나 짚어서 에러를 던지는데, 이 함수는 그냥 옵셔널 체이닝으로 조용히 빈 값 처리하고 넘어가고 있었다. 코드만 보면 확실히 더 허술해 보였다.

그런데 실패할 수 있는 모든 경로를 하나씩 다 따라가 봤다. 네트워크 에러, HTTP 에러, 응답 형식이 이상한 경우, JSON 파싱이 실패하는 경우, 심지어 라이브러리의 공식 타입 정의까지 열어서 “상태 코드 400 이상이면 기본적으로 예외를 던진다”는 동작을 확인했다. 그러다 코드 안에 있던 방어 코드 한 줄이, 그 라이브러리가 이미 그 이전에 예외를 던져버리기 때문에 절대 실행될 수 없는 죽은 코드라는 것까지 발견했다.

결과적으로 모든 실패 상황에서 최종 결과는 완전히 똑같았다. 어느 쪽이든 항상 안전하게 기본값으로 폴백했다. 눈으로 훑었을 땐 “이쪽이 더 허술하다”였는데, 끝까지 따라가 보니 “다르게 짜여 있을 뿐, 결과는 같다”였다.

그렇다고 전부 괜찮았던 건 아니다

여섯 개 중 하나는 진짜였다. 디버그 리포트를 보내는 기능이, 정작 크래시가 나서 플러그인이 재시작된 바로 그 상황에서 쓸모가 없어지는 버그였다. 크래시에도 살아남으라고 디스크에 따로 기록해두는 로그 파일이 있었는데, 정작 그 파일을 다시 읽어 오는 코드가 어디에도 없었다.

이건 실제로 코드를 고쳤다. 디스크 파일을 읽어 오는 함수를 새로 만들고, 화면을 그리기 전에 그 파일을 먼저 확인하도록 순서를 바꿨다. 이 하나가 있어서, 오늘 있었던 일이 “다 확인해보니 별거 아니었다”로 끝나지 않고, “다섯 개는 아니었지만 하나는 진짜였다”로 남았다.

남는 생각

다른 버그를 조사하다가 “이것도 비슷해 보인다”는 걸 발견하면, 그 자리에서 검증까지 끝내기보다는 일단 기록해두고 넘어가고 싶어진다. 지금 파던 문제에 집중하는 게 맞으니까. 근데 그 판단을 미루는 대가는 사라지지 않고 그냥 미래로 넘어갈 뿐이다. 오늘 그 대가를 한꺼번에 치른 셈이다 — 이슈 하나씩 다시 열어서, 처음부터 끝까지 다시 추적하고, 라이브러리 문서까지 뒤져야 했다.

그렇다고 “발견하는 족족 그 자리에서 다 검증하라”는 결론을 내리고 싶지는 않다. 지금 하던 일의 흐름을 끊으면서까지 모든 의심을 즉시 해소하는 게 항상 더 나은 선택은 아니다. 다만 한 가지는 분명해졌다 — “비슷해 보인다”는 것과 “확인했다”는 것은 다른 상태이고, 백로그에 남을 땐 그 둘이 똑같은 모양의 이슈로 보인다는 것. 나중에 다시 열어볼 사람(그게 나 자신이라도)을 위해, 최소한 “확인 안 함”이라는 표시라도 남겨뒀으면 오늘 같은 전수 재검증은 필요 없었을지도 모른다.


Share this post:

Previous Post
파일쓰기 재설계 이후 — 잘 되던 기능이, 완전히 다른 작업에 휩쓸려 조용히 죽어 있었다