재현불가버그는 개발자라면 한 번쯤은 꼭 마주하게 되는, 가장 난감하고도 기억에 오래 남는 경험입니다. 이 글은 재현되지 않는 문제를 마주했을 때의 실제적인 사고 흐름과 태도, 그리고 그 과정에서 배운 점을 일상적인 언어로 풀어낸 기록입니다.
1. 증상은 분명한데, 원인은 보이지 않을 때
보이지 않는 문제 앞에서 사람이 먼저 흔들립니다
재현되지 않는 버그를 처음 마주했을 때의 공기는 늘 비슷합니다. 분명 누군가는 겪었고, 로그에도 흔적은 남아 있는데, 정작 제 손으로는 같은 상황을 만들 수 없을 때입니다. 이때부터 문제는 기술이 아니라 심리 쪽으로 슬슬 이동하기 시작합니다.
“분명 고쳤던 코드 같은데…”, “환경 문제 아닐까?” 같은 생각이 꼬리에 꼬리를 물고 이어집니다.
이런 상황에서 제가 가장 먼저 했던 건, 문제를 기술적으로 정의하기 전에 상황을 사람의 언어로 정리하는 것이었습니다. 막연하게 ‘에러가 난다’가 아니라, 언제, 누가, 어떤 행동 이후에 문제가 발생했는지를 최대한 일상적인 문장으로 풀어 적어봤습니다.
- 특정 시간대에만 발생했는지
- 특정 사용자 계정에서만 나타났는지
- 공통적으로 거치는 화면이나 버튼이 있는지
이런 질문들을 스스로에게 던지다 보면, 신기하게도 감정이 조금 가라앉습니다. 개인적으로는 이 과정이 굉장히 중요하다고 느꼈습니다. 문제를 감정에서 떼어내야, 그다음 단계로 넘어갈 수 있었기 때문입니다.
한편으로는 “이게 왜 나한테 걸렸지”라는 생각도 들었습니다. 하지만 지금 돌이켜보면, 이런 재현불가버그를 겪어보는 시점이 오히려 성장의 분기점이었던 것 같습니다. 단순히 코드를 잘 짜는 것과, 문제를 다루는 태도는 전혀 다른 영역이라는 걸 처음 체감했거든요.
2. 로그를 다시 믿기로 한 이유
코드는 거짓말을 해도 기록은 남습니다
문제가 재현되지 않을수록, 개발자는 눈에 보이는 코드보다 보이지 않는 기록에 의존하게 됩니다. 그중에서도 가장 기본이 되는 것이 로그입니다. 예전에는 로그를 “있으면 좋은 것” 정도로만 생각했는데, 이 경험 이후로 생각이 완전히 바뀌었습니다.
로그를 볼 때 가장 조심해야 할 점은, 내가 보고 싶은 것만 보려는 태도였습니다. 이미 머릿속에 가설이 생긴 상태에서 로그를 보면, 그 가설을 뒷받침하는 줄만 눈에 들어오게 됩니다. 그래서 저는 일부러 다음과 같은 방식으로 로그를 다시 봤습니다.
- 에러 발생 전후 5분간의 전체 흐름을 순서대로 읽기
- 정상 동작 로그와 나란히 비교하기
- “이상하다”라는 느낌이 드는 부분을 메모로 따로 남기기
이 과정에서 느낀 건, 로그는 생각보다 많은 이야기를 하고 있다는 점이었습니다. 다만 우리가 바쁠 때는 그 이야기를 들을 여유가 없을 뿐이었습니다. 특히 사용자 행동 로그는 코드만 봐서는 절대 알 수 없는 맥락을 제공합니다.
개인적으로 이 시점에서 가장 크게 배운 점은, 로그는 디버깅의 보조 수단이 아니라, 하나의 서사라는 것이었습니다. 그리고 이 서사를 끝까지 읽어내는 인내심이, 이런 재현불가버그 상황에서는 가장 강력한 무기가 됩니다.
3. 가설을 세우되, 집착하지 않기
틀릴 수 있다는 전제를 허락하는 연습
어느 순간부터는 원인이 될 만한 지점들이 머릿속에 몇 개 떠오르기 시작합니다. 이때부터가 진짜 위험한 구간입니다. 가설을 세우는 건 중요하지만, 그 가설에 집착하기 시작하면 오히려 시야가 좁아집니다.
저는 이 단계에서 스스로에게 규칙을 하나 정했습니다.
“하나의 가설은 하루 이상 붙잡지 않는다.”
가설을 검증하기 위해 코드를 수정하고, 테스트하고, 로그를 다시 확인하는 과정은 분명 필요합니다. 하지만 결과가 명확하지 않다면, 미련 없이 다음 가설로 넘어가야 했습니다. 이게 말처럼 쉬운 일은 아니었습니다. 특히 이미 많은 시간을 쏟은 가설일수록 더 그랬습니다.
이때 도움이 됐던 방법은 가설을 글로 적는 것이었습니다.
- 이 가설이 맞다면 어떤 현상이 나와야 하는지
- 그렇지 않다면 무엇이 관측될 수 있는지
이렇게 적어두면, 결과를 조금 더 객관적으로 볼 수 있었습니다. 개인적으로는 이 방식이 감정적인 판단을 줄이는 데 꽤 효과적이었습니다.
결국 문제를 해결로 이끈 것도, 가장 그럴듯해 보였던 가설이 아니라 가장 사소해 보였던 가설이었습니다. 이 경험 이후로, 저는 재현불가버그를 만났을 때 “대단한 원인이 숨어 있을 것”이라는 생각을 경계하게 되었습니다.
4. 동료에게 설명하는 순간, 실마리가 보이다
말로 설명하는 행위의 힘
혼자서만 문제를 붙잡고 있을 때는 생각이 계속 같은 자리를 맴돕니다. 그래서 저는 어느 정도 정리가 된 시점에서, 동료에게 상황을 설명해보았습니다. 단순히 해결을 기대하기보다는, 말로 설명하는 과정 자체를 목적에 두었습니다.
신기하게도, 설명을 하다 보면 스스로 이상하다고 느끼는 지점이 생깁니다.
“여기서 이 값이 바뀌는 게 맞나?”
“이 흐름이 이렇게 되는 게 자연스러운가?”
동료는 특별한 조언을 하지 않았지만, 그 질문을 스스로 던지는 순간 머릿속에서 무언가가 연결되었습니다. 결국 문제의 원인은 특정 조건에서만 실행되는 예외 처리 로직이었고, 평소에는 거의 타지 않는 코드였습니다.
이 경험을 통해 느낀 건, 재현불가버그를 혼자서만 해결하려는 태도는 생각보다 비효율적이라는 점이었습니다. 설명하는 행위 자체가 사고를 구조화해주고, 그 과정에서 빠진 전제를 드러나게 만듭니다.
개인적으로는 이후로 문제를 겪을 때, “이걸 누군가에게 설명한다면 어떻게 말할까”를 먼저 떠올리게 되었습니다. 그 자체가 하나의 점검 과정이 되었습니다.
5. 결국 남는 것은 해결 방법보다 태도였다
문제를 대하는 방식은 기록으로 남습니다
문제를 해결하고 나면, 허무할 정도로 원인은 단순한 경우가 많습니다. 이번에도 그랬습니다. 하지만 이 경험에서 얻은 것은 단순한 해결책이 아니었습니다. 오히려 문제를 대하는 태도와 과정이 더 크게 남았습니다.
이후 비슷한 상황을 겪었을 때, 예전처럼 조급해지지 않았습니다.
“재현 안 되면 어때, 결국 단서는 남아 있겠지”라는 생각을 하게 되었습니다. 이건 기술적인 숙련도라기보다는, 경험에서 비롯된 마음가짐에 가까웠습니다.
정리해보면, 제가 이 재현불가버그 경험을 통해 얻은 교훈은 다음과 같습니다.
- 문제를 먼저 사람의 언어로 정리할 것
- 로그를 흐름으로 읽을 것
- 가설에 집착하지 말 것
- 혼자만의 싸움으로 만들지 말 것
- 해결보다 과정을 기록할 것
이 글을 읽는 분들 중에도 비슷한 상황을 겪고 계신 분이 있다면, 지금 느끼는 답답함이 결코 헛된 시간이 아니라는 점을 꼭 말씀드리고 싶습니다. 이런 경험은 언젠가 반드시, 더 단단한 판단력으로 돌아옵니다.
저 역시 그랬고, 지금도 여전히 배우는 중입니다.