테스트 자동화 도구는 많지만, 서비스 팀이 가장 힘들어하는 지점은 "현실과 비슷한 통합 시나리오를 어떻게 재현하느냐"입니다. HTTP 요청만 흉내 내서는 부족하고, 데이터베이스와 메시지 큐, 외부 API까지 함께 움직여야 하는 경우가 많습니다. Keploy는 이 복잡함을 기록과 재생이라는 방식으로 풀어 보려는 저장소입니다.
해당 Repository의 접속 URL 및 version. Commit 빈도수에 따른 업데이트 수준.
- 저장소: https://github.com/keploy/keploy
- 최신 release:
v3.3.63 - 최신 commitSha:
ebf2a2a8f88b4e743d53d93bf8efc832237095f3 - 업데이트 수준: 2026년 4월 6일 기준 최근 푸시가 확인되고, 4월 5일 커밋에서도 MySQL recorder와 메모리 제한, CI 동시성 개선 작업이 활발하게 이어졌습니다.
무엇을 하는 저장소인가
Keploy는 실제 API 호출과 데이터베이스 질의, 스트리밍 이벤트를 기록해서 테스트 케이스와 데이터 Mock으로 변환하는 도구입니다. README가 강조하듯 네트워크 계층에서 eBPF로 트래픽을 캡처하기 때문에, 애플리케이션 코드에 SDK를 심지 않아도 되는 점이 핵심입니다. 결국 "운영에 가까운 흐름을 그대로 테스트 자산으로 가져온다"는 발상이 중심에 있습니다.
핵심 특징
가장 큰 특징은 코드 변경 없이 기록한다는 점입니다. 일반적인 통합 테스트 도구는 프레임워크별 설치와 계측이 필요한데, Keploy는 네트워크 계층에서 문제를 푼 덕분에 언어와 프레임워크에 비교적 독립적입니다.
둘째는 HTTP Mock을 넘어서 인프라 가상화까지 확장하려는 구조입니다. README에서 Postgres, MySQL, MongoDB, Kafka, RabbitMQ까지 언급하는데, 이는 단순 API 스냅샷보다 훨씬 넓은 테스트 범위를 겨냥한다는 뜻입니다.
셋째는 커버리지 관점을 넓게 잡는다는 점입니다. 단순 statement coverage가 아니라 API 스키마와 비즈니스 시나리오 커버리지까지 보려는 시도는 QA와 개발의 관점을 함께 다루려는 방향으로 읽힙니다.
- eBPF 기반 캡처로 코드 수정 없이 테스트 자산을 생성합니다.
- 데이터베이스와 큐까지 포함한 통합 흐름을 재생하려 합니다.
- 테스트 커버리지를 코드 수준과 API 수준에서 함께 보려 합니다.
실무에서 기대할 수 있는 효과
실무에서는 통합 테스트를 쓰고 싶어도 준비 비용이 너무 커서 포기하는 경우가 많습니다. Keploy는 이미 존재하는 트래픽을 활용하므로, 초기 테스트 자산을 만드는 비용을 줄여 줍니다. 레거시 서비스에도 상대적으로 적용하기 쉬운 이유입니다.
또한 장애 재현에도 유리합니다. 특정 외부 의존성과의 상호작용을 다시 재생해 보며 버그를 좁혀 갈 수 있기 때문입니다. 개발과 QA가 같은 데이터 흐름을 공유하기도 쉬워집니다.
실제로 볼 만한 예시
- 결제 승인 API가 특정 DB 응답 조합에서만 실패할 때, 기록된 흐름을 통째로 재생해 회귀 테스트로 남길 수 있습니다.
- 외부 SaaS와 연동된 주문 처리 시스템에서 HTTP 호출, DB 쓰기, 큐 발행이 한 번에 일어나는 장면을 오프라인 테스트로 옮길 수 있습니다.
장점과 한계
장점은 시작 비용을 낮춘다는 점입니다. 테스트를 "손으로 써야 하는 것"이 아니라 "실행 로그에서 뽑아내는 것"으로 바꾸기 때문에, 특히 테스트 부채가 큰 팀에서 매력적입니다.
한계도 분명합니다. 운영 트래픽을 그대로 재생한다고 해서 곧바로 좋은 테스트가 되지는 않습니다. 민감 정보 처리, 데이터 정규화, flaky 시나리오 정리 같은 후속 작업이 필요합니다. 또한 네트워크 레이어 캡처가 만능은 아니어서, 특정 애플리케이션 내부 상태까지 완전히 설명해 주지는 못합니다.
어떤 팀이나 개발자에게 맞는가
통합 테스트가 부족한 백엔드 팀, 레거시 API를 다루는 팀, QA 자동화를 빠르게 늘리고 싶은 조직에 잘 맞습니다. 반대로 단위 테스트만으로 충분한 작은 라이브러리 프로젝트에는 다소 과한 접근일 수 있습니다.
결론
Keploy는 테스트 작성을 자동화한다기보다, 테스트 자산을 수집하는 방식을 바꾸는 저장소입니다. 통합 테스트의 초기 비용을 낮추고 싶은 팀이라면 계속 추적할 이유가 큽니다.