찾기 어려웠던 버그 때문에 고객을 잃었습니다. 그래서 AI를 고용해 추적하게 했습니다.

지난달 한 고객이 결제 단계에서 막혔습니다. 이메일도 없고, 불만 접수도 없었습니다. 그저 떠났을 뿐입니다.

4일 후에야 단 하나의 로그 라인을 통해 알게 되었습니다. 그러고는 몇 시간 동안 로그와 데이터베이스를 뒤졌지만 원인을 찾지 못했습니다. 버그는 여전히 어딘가에 존재했고, 제가 할 수 있는 건 누군가에게 걸릴 때까지 기다리는 것뿐이었습니다.

그때 저는 '로그를 어떻게 더 빨리 읽을까?'라는 질문을 멈추고 다른 질문을 던졌습니다. '왜 사람이 나에게 고장 났다고 말해야 하는가?'

놀라운 점: 코드를 가리키지 않습니다

제가 AI 디버거를 상상했을 때, 에러 메시지를 붙여넣고 패치를 받는 것을 생각했습니다. 하지만 막힌 고객의 경우는 그렇지 않습니다. 막힌 고객은 종종 아무런 에러도 발생시키지 않습니다. 버튼이 아무 반응을 안 하거나, 페이지가 멈추거나, 결제 단계가 실행되지 않는 식입니다.

그래서 Bugwalk는 다른 곳에서 시작합니다. 사람으로부터 시작하는 것입니다.

방문 기록을 순서대로 읽습니다: 모든 클릭, 모든 요청, 모든 에러를 하나의 타임라인에 담아냅니다. 그리고 고객이 실패했을 때의 버전으로 코드를 읽어 들입니다. 그런 다음 해당 라인을 지목해 줍니다.

데모에서 발견한 것 (그리고 제가 예상하지 못한 이유)

여기 Fernhill이라는 작은 온라인 상점에서 나온 실제 예시가 있습니다.

A failed checkout in the Bugwalk demo

타임라인에는 쇼핑객이 정상적으로 로그인(200)한 후, TypeError: Cannot read properties of null 에러가 발생하고, POST /api/checkout에서 500을 반환하는 것이 보입니다.

조사 결과는 다음과 같습니다. 할인 테이블에 없는 쿠폰 코드가 마치 있는 것처럼 읽혀서, 쇼핑객이 가격을 보기 전에 결제 단계에서 오류를 일으킵니다.

이런 종류의 버그를 보세요. 모두에게 영향을 미치지 않습니다. 이메일로 받은 쿠폰 코드를 가지고 방문한 사람들에게만 영향을 줍니다. 코드를 클릭하고, 결제를 로드하지만 아무 일도 일어나지 않습니다. 저는 하루 종일 결제 단계를 테스트해도 절대 발견할 수 없었습니다. 떠난 쇼핑객은 그저 장바구니가 버려진 것처럼 보였을 뿐입니다.

이것이 제가 몇 시간 동안 찾지 못했던 종류의 버그였습니다.

사용 방법

경로는 짧습니다. 이는 빠른 시작 가이드에서 바로 가져온 내용입니다:

1. 프로젝트를 생성하고 모니터링하려는 앱의 이름으로 지정합니다.
2. SDK를 설치합니다. 앱에서 위자드를 실행하거나 프레임워크에 맞는 스니펫을 붙여넣습니다.
3. 앱을 한 번 엽니다. 첫 번째 이벤트를 확인하기에는 페이지 보기만 충분합니다.
4. GitHub 저장소와 연결합니다. 이를 통해 보고서가 정확한 라인을 가리킬 수 있게 됩니다.
5. 실패한 세션을 열고 “조사 실행(Run investigation)” 버튼을 누릅니다. 열리는 풀 리퀘스트를 검토합니다.

제가 가장 중요하게 생각하는 부분: 중요한 것에는 손댈 수 없습니다

저는 낯선 사람이 제 저장소에 마음대로 접근하도록 두지 않을 것이므로, 이 도구가 무엇을 할 수 있고 무엇을 할 수 없는지 알려드립니다:

• 사용자가 선택한 저장소를 읽고, 테스트를 실행하며, 브랜치를 하나 생성하고, 풀 리퀘스트를 열 수 있습니다.
• 기본 브랜치에 푸시하거나, 댓글을 달거나, 병합(merge)하거나, 데이터베이스에 쓰는 것은 할 수 없습니다.
• 모든 수정 사항은 자체 브랜치에 대한 풀 리퀘스트 형태입니다. 승인하기 전까지는 아무것도 배포되지 않습니다.

실제로 절약해 주는 것들

수동으로 작은 버그를 찾는 데는 약 4시간이 걸립니다 (대략적인 추정치이며, 벤치마크가 아닙니다). 이 시간은 세 가지 비용을 초래합니다:

• 시간: 로그 스크롤링, 쿼리 실행, 사용자가 무엇을 클릭했는지 추측하기
• 뇌 피로(Brain rot): 열린 탭 10개와 머릿속의 불완전한 가설 하나
• 집중력: 개발하던 기능이 사라지고, 그 기능을 처음부터 다시 구축해야 함

대신 얻는 것은 읽을 수 있는 풀 리퀘스트 하나입니다. 사용자는 자신의 기능에 계속 집중할 수 있고, 세부 사항은 이미 수집되어 있습니다.

가입 없이 사용해 보세요

제 글을 믿지 않아도 됩니다. 데모는 실제 실패 사례를 가진 진짜 상점이며 계정이 필요 없습니다: bugwalk.app/demo

자신의 앱에서 실행하고 싶다면 3일 무료 체험이 있습니다.

아직 초기 단계라 여러분의 의견을 듣고 싶습니다

1. 사용자가 오늘 버그를 만났다는 사실을 어떻게 알게 되나요: Sentry, 세션 재생(session replays), 지원 티켓, 아니면 운으로요?

2. “재현할 수 없는(can’t reproduce it)” 버그는 비용이 얼마나 드나요?

3. 이와 같은 도구가 저장소에 PR을 열도록 허용하시겠습니까? 그리고 수정 사항을 신뢰하기 전에 어떤 것을 보여줘야 할까요?

https://bugwalk.app

댓글로 알려주세요.