솔직히 말하겠습니다.
당신이 짠 테스트 코드는 반쪽짜리입니다.
왜냐고요? 로컬이나 스테이징 환경의 데이터는 너무나 '예쁘기' 때문입니다. QA 팀이 넣어주는 데이터는 정제되어 있고, 개발자가 상상해서 만든 엣지 케이스는 현실의 기괴함을 따라갈 수 없습니다.
금융권 SI 프로젝트 시절, 오픈 당일 시스템이 뻗었던 기억이 납니다.
이유는 고작 특수문자가 섞인 사용자 ID 하나 때문이었습니다. 수천 줄의 단위 테스트(Unit Test)가 통과했지만, 그 ID 하나를 막지 못해 저는 시말서를 썼습니다.
그때 뼈저리게 느꼈습니다.
"가장 완벽한 테스트 데이터는 지금 운영 서버를 때리고 있는 트래픽 그 자체다."
최근 제 눈에 띈 도구 하나를 소개합니다. Tusk Drift입니다.
이 녀석의 철학은 단순하고 무식합니다.
"상상하지 마라. 그냥 실제 운영 트래픽(Traffic)을 녹화해서 그대로 다시 쏴라."
이게 왜 무서운지 아십니까?
개발자가 미처 생각하지 못한 사용자의 기상천외한 행동 패턴, 더러운 데이터, 네트워크 지연 상황까지 그대로 재현되기 때문입니다.
기본 원리는 간단합니다.
- Record: 운영 환경(Production)에서 발생하는 HTTP 트래픽을 트레이스(Trace)로 녹화합니다.
- Replay: CI/CD 파이프라인이나 로컬 환경에서 녹화된 트래픽을 당신의 API에 다시 던집니다.
- Compare: 기존 응답과 새 코드의 응답을 비교합니다.
--> 이게 바로 회귀 테스트(Regression Test)의 끝판왕입니다.
기존에도 트래픽 리플레이 툴은 있었습니다. (Goreplay 등)
하지만 Tusk Drift가 실무자 입장에서 '물건'인 이유는 디테일에 있습니다.
보통 리플레이 테스트를 하면 99% 실패합니다. 왜냐고요?
응답에 포함된 timestamp, UUID, random_string 같은 동적 필드가 매번 바뀌기 때문입니다. 이거 예외 처리하다가 밤샙니다.
그런데 이 툴은 똑똑합니다. JSON 응답을 비교할 때, 변하면 안 되는 비즈니스 데이터와 변해도 되는 동적 데이터를 구분해서 필터링합니다.
게다가 샌드박싱(Sandboxing) 기능이 훌륭합니다.
운영 트래픽을 재생한답시고 실제 결제 API를 호출해버리면 큰일 나겠죠? Tusk Drift는 로컬에 Mock Server를 띄워서 아웃바운드 I/O를 가로챕니다. 안전하다는 뜻입니다.
사용법도 10년 전 금융권 차세대 때 쓰던 툴들에 비하면 선녀 같습니다.
AI 에이전트가 코드를 분석해서 SDK 설정을 잡아줍니다.
export ANTHROPIC_API_KEY=your-key
tusk setup수동으로 하고 싶다면 그냥 init 하고 run하면 끝입니다.
# 트레이스 파일로 테스트 실행
tusk run --trace-file path/to/trace.jsonlNode.js와 Python을 지원하고, CI 파이프라인(GitHub Actions 등)에 태워서 PR 날릴 때마다 실제 유저 데이터를 들이부을 수 있습니다.
주니어 여러분.
"제 로컬에서는 되는데요?"라는 말은 프로의 언어가 아닙니다.
코드는 자산이 아니라 부채입니다. 배포 버튼을 누르기 전에, 당신의 코드가 '진짜 세상'을 마주할 준비가 되었는지 확인하십시오.
이력서에 "JUnit으로 테스트 커버리지 80% 달성"이라고 쓰는 것보다, "운영 트래픽 기반 리플레이 테스트 환경 구축으로 장애율 0% 도전"이라고 쓰는 게 면접관 눈에는 훨씬 섹시해 보입니다.
당신의 상상력을 믿지 말고, 데이터를 믿으세요.
그래야 주말에 전화를 받지 않습니다.
