버그 재현 도구가 QA 만능상자가 되면 망한다

버그를 고쳤다고 말하는 건 쉽다.

“원인은 찾았고요.”

“패치도 했고요.”

“제 컴퓨터에서는 잘 됩니다.”

여기까지 들으면 마음이 놓여야 하는데, 이상하게 불안하다. 그래서 한 번만 더 묻게 된다.

“그런데 그 버그, 정말 같은 조건에서 다시 만들 수 있어?”

“패치 전에는 실패했고 패치 후에는 성공했다는 증거가 있어?”

“재현한다고 바꾼 설정은 원래대로 돌려놨어?”

이 세 질문에 답하기 위해 만든 것이 QueryPie ReproKit이다.

그런데 ReproKit의 장점을 제대로 이해하려면 먼저 오해 하나를 치워야 한다.

ReproKit은 또 하나의 거대한 테스트 자동화 도구가 아니다.

ReproKit은 테스트 공장이 아니라 사건 현장 재구성실이다

일반적인 테스트 자동화는 이렇게 묻는다.

오늘 빌드에서도 로그인, 정책 생성, 권한 변경 같은 핵심 기능이 정상인가?

ReproKit은 다른 질문을 한다.

고객이 겪은 이 이상한 증상을 같은 조건에서 다시 만들 수 있고, 패치 후 정말 사라졌다는 걸 증명할 수 있는가?

비슷해 보이지만 역할은 꽤 다르다.

정기 회귀 테스트는 매일 같은 코스를 달리는 순찰차에 가깝다. 자주 지나가며 도로에 문제가 없는지 살핀다.

ReproKit은 사고가 발생했을 때 출동하는 과학수사팀에 가깝다. 사고 당시의 조건을 복원하고, 흔적을 수집하고, 원인과 수정 결과를 하나의 사건 기록으로 묶는다.

그래서 정체성을 한 줄로 표현하면 이렇다.

ReproKit = 재현 실험실 + 실제 증거 수집 + 검증 가능한 사건 기록

조금 더 기술적으로는 세 계층으로 나뉜다.

계층	하는 일	비유
Repro Core	환경을 준비하고 증상을 재현하고 PASS/FAIL을 판정한다	사건 현장 재구성실
Evidence Capture	실제 제품 화면과 터미널 결과를 수집한다	현장 카메라와 녹취기
Result Package	로그, 화면, 판정, 정리 결과를 검증 가능한 묶음으로 만든다	봉인된 증거 봉투

핵심은 단순히 스크립트를 실행하는 게 아니다.

“무슨 조건에서, 어떤 경로를 거쳐, 무엇을 근거로 고쳤다고 판단했는가”를 다른 사람이 다시 확인할 수 있어야 한다.

여섯 단계가 팀의 공용어가 된다

티켓마다 재현 스크립트가 제각각이면 만든 사람만 운전할 수 있는 자동차가 된다.

시동 버튼도 다르고, 브레이크도 다르고, 어떤 버튼이 데이터베이스를 바꾸는지도 실행해봐야 안다.

ReproKit은 이 흐름을 여섯 단계로 통일한다.

doctor → setup → reproduce → verify → report → cleanup

doctor는 출발 전 점검이다. 필요한 서버, 도구, 자격 조건이 준비됐는지 확인한다.

setup은 실험 재료를 만든다. 테스트 사용자, 연결 정보, 컨테이너, 샘플 데이터 같은 것들이다.

reproduce는 문제 조건을 실제로 일으킨다.

verify는 현재 실행에서 수집한 근거로 증상이 재현됐는지, 패치 후 사라졌는지 판정한다.

report는 사람이 읽을 수 있는 사건 기록을 만든다.

cleanup은 실험을 위해 만든 것과 임시로 바꾼 것을 원래대로 돌린다.

평범한 단어 여섯 개지만 효과는 크다.

예전에는 이렇게 물었다.

“그 스크립트 어떻게 돌려요?”

이제는 이렇게 물을 수 있다.

“doctor는 통과했어?”

“reproduce가 실제 프록시 경로를 탔어?”

“verify는 방금 실행한 증거만 본 거야?”

“cleanup에서 임시 설정이 복구됐어?”

좋은 도구는 답만 표준화하지 않는다. 팀이 던지는 질문을 좋아지게 만든다.

ReproKit의 첫 번째 장점: 이상한 버그에 강하다

단위 테스트는 함수와 클래스의 계약을 확인하는 데 강하다.

브라우저 테스트는 사용자가 클릭하는 정상 흐름을 반복 확인하는 데 강하다.

하지만 현실의 버그는 가끔 경계를 넘나든다.

브라우저
  → API
  → 권한 정책
  → 프록시
  → 데이터베이스 드라이버
  → 감사 로그

화면은 정상인데 실제 쿼리는 실패할 수 있다.

API 응답은 성공인데 캐시에는 오래된 값이 남아 있을 수 있다.

데이터베이스 클라이언트에서는 오류가 보이는데 서버 로그에는 전혀 다른 예외가 찍힐 수 있다.

이런 문제는 테스트 하나로 잡기 어렵다. 여러 경계의 상태를 같은 실행 안에서 연결해야 한다.

ReproKit은 바로 이 지점에서 강하다.

실제 클라이언트를 실행하고, 제품 경로를 지나고, 로그와 결과를 같은 실행 ID로 묶는다. 단순히 “응답 코드가 200이었다”가 아니라 “사용자가 통과한 전체 경로에서 어떤 일이 있었는가”를 본다.

두 번째 장점: PASS라는 말에 영수증을 붙인다

자동화에서 가장 위험한 결과는 FAIL이 아니다.

근거가 약한 PASS다.

오래된 결과 파일을 다시 읽었는데 PASS가 나올 수 있다.

예쁘게 만든 가짜 화면을 실제 제품 화면처럼 착각할 수 있다.

패치 전과 패치 후가 서로 다른 데이터로 실행됐을 수도 있다.

그래서 ReproKit의 PASS에는 영수증이 필요하다.

- 이번 실행의 식별자
- 실제 제품 화면 또는 실제 터미널 결과
- 패치 전 실패와 패치 후 성공의 연결
- 사용한 fixture의 출처와 소유권
- 임시 설정과 장애 주입 장치의 복구 여부
- 로그와 보고서의 비밀값 노출 검사

이 구조 덕분에 결과 폴더는 단순한 파일 창고가 아니라 사건 기록이 된다.

리뷰어는 스크린샷 수십 장을 뒤지기 전에 먼저 확인할 수 있다.

“이 결과는 이번 실행에서 나온 건가?”

“실제 사용자가 보는 경로를 통과했나?”

“실험 장치는 모두 원복됐나?”

“보고서가 가리키는 로그와 화면이 정말 존재하나?”

좋은 테스트 자동화는 결과를 많이 만드는 도구가 아니다.

결과를 믿을 수 있게 만드는 도구다.

세 번째 장점: 재현 노하우가 사람에게서 팀으로 이동한다

복잡한 버그는 보통 한 사람의 머릿속에 재현법이 남는다.

“먼저 이 설정을 바꾸고, 그다음 저 클라이언트로 접속한 뒤, 로그에서 이 문구를 보면 돼요.”

이 설명은 담당자가 휴가를 가는 순간 사라진다.

ReproKit은 이 노하우를 실행 가능한 시나리오로 바꾼다.

• 필요한 조건은 manifest에 남긴다.
• 위험한 명령은 상태를 바꾼다고 표시한다.
• fixture의 생성과 삭제 책임을 기록한다.
• 판정 근거는 JSON, 로그, 실제 화면으로 남긴다.
• 결과는 다른 사람이 열어볼 수 있는 패키지로 묶는다.

버그를 한 번 잡는 데서 끝나지 않고, 다음 사람이 같은 문제를 더 빨리 이해할 수 있는 자산이 된다.

이게 ReproKit의 가장 현실적인 생산성 효과다.

디버깅 속도보다 인수인계 속도가 빨라진다.

네 번째 장점: 자신이 하지 말아야 할 일을 안다

도구가 성장하면 욕심이 생긴다.

“이왕 실행할 수 있는데 모든 회귀 테스트를 여기 넣으면 되지 않을까?”

그 순간 ReproKit은 위험해진다.

모든 걸 담는 도구는 처음에는 편하지만, 나중에는 책임이 모호해진다. 일반 UI 테스트와 티켓 전용 재현이 섞이고, 같은 테스트가 여러 곳에서 중복되고, 누가 고쳐야 하는지 알 수 없게 된다.

그래서 경계가 중요하다.

질문	어울리는 테스트 자산
함수와 서비스 계약이 정상인가?	단위·통합 테스트
일반 사용자 흐름이 계속 정상인가?	브라우저 기능 테스트
릴리스 핵심 기능이 안정적인가?	정기 QA 회귀 테스트
특이한 장애를 다시 만들고 패치를 증명할 수 있는가?	ReproKit

ReproKit의 장점은 무엇이든 할 수 있다는 데 있지 않다.

어떤 문제를 자신이 맡아야 하는지 안다는 데 있다.

좋은 ReproKit 시나리오는 언젠가 졸업한다

티켓에서 시작한 재현 시나리오가 영원히 ReproKit에만 남아야 하는 건 아니다.

반복해서 발생할 가능성이 높은 회귀라면 더 작고 안정적인 테스트로 승격하는 편이 좋다.

복잡한 장애 증상
  → ReproKit으로 재현하고 패치 검증
  → 반복 회귀 가치 판단
       ├─ 티켓 고유 진단이면 ReproKit에 유지
       ├─ 순수 로직이면 단위·통합 테스트로 승격
       ├─ 일반 UI 흐름이면 브라우저 테스트로 승격
       └─ 릴리스 핵심 흐름이면 정기 QA suite로 승격

여기서 “승격”은 원본 시나리오를 반드시 지운다는 뜻이 아니다.

복잡한 실험실은 남겨두고, 그 안에서 확인된 핵심 회귀만 작고 빠른 테스트로 옮길 수 있다.

이 구조가 중요한 이유는 간단하다.

ReproKit은 사건을 이해하는 데 강하고, 일반 테스트 suite는 사건이 다시 발생하는지 빠르게 감시하는 데 강하다.

수사팀과 순찰팀은 둘 다 필요하지만 같은 일을 할 필요는 없다.

성숙도는 테스트 개수보다 중요하다

시나리오가 등록됐다고 바로 믿을 수 있는 건 아니다.

실행 파일만 있는 것과, 실제 화면·복구·출처 계약까지 갖춘 것은 신뢰 수준이 다르다.

그래서 ReproKit은 시나리오를 계단처럼 바라본다.

등록됨
  → 공통 명령으로 실행 가능
  → 표준 모듈 사용
  → 실제 사용자 증거 제공
  → fixture·출처·cleanup 신뢰 계약 충족
  → 정식 회귀 테스트 승격 후보

여기서 중요한 건 배지 수집이 아니다.

현재 이 시나리오가 무엇을 증명할 수 있고, 무엇은 아직 증명하지 못하는지 솔직하게 드러내는 것이다.

“실행됐다”와 “믿을 수 있다” 사이에는 생각보다 긴 계단이 있다.

결국 ReproKit이 주는 건 자신감이다

ReproKit을 단순히 버그 재현 자동화라고 부르면 절반만 설명한 셈이다.

진짜 가치는 세 가지에 있다.

첫째, 복잡한 장애를 같은 조건에서 다시 만들 수 있다.

둘째, 패치가 효과가 있었다는 근거를 실제 제품 경로에서 남긴다.

셋째, 그 재현 노하우를 담당자의 기억이 아니라 팀의 자산으로 바꾼다.

그리고 한 가지를 더 보탤 수 있다.

자신이 QA 전체를 대신하지 않는다는 경계 덕분에 오래 살아남을 수 있다.

ReproKit은 버그를 잡는 로봇이 아니다.

사건 현장을 다시 만들고, 증거를 봉인하고, 다음 사람이 같은 사건을 더 빨리 이해하게 해주는 과학수사 키트다.

좋은 디버깅 도구는 이렇게 말하지 않는다.

“믿어주세요. 통과했습니다.”

대신 증거 봉투를 내밀며 말한다.

“같은 조건으로 다시 해봤고, 여기 결과가 있습니다.”