안녕하세요 HN, 저는 Meticulous (https://www.meticulous.ai)의 창립자 Gabriel입니다. 저희는 리플레이 테스트 (replay testing)를 위한 API를 구축하고 있습니다. 즉, 개발자가 웹 앱에서의 세션 (session)을 기록한 다음, 코드가 배포되기 전에 회귀 (regression)를 포착할 수 있도록 새로운 프론트엔드 (frontend) 코드에 대해 해당 세션들을 리플레이할 수 있게 해줍니다.

저는 Dropbox에서 근무하던 시절, UX를 위해 정기적으로 진행했던 '버그 배시 (bug bashes)'에서 Meticulous를 시작할 영감을 얻었습니다. 다섯 명이나 여섯 명의 엔지니어가 회의실에 모여 우리가 만든 것을 망가뜨려 보기 위해 다양한 플로우 (flow)를 클릭하며 지나갔습니다. 이는 효과적이었지만 시간이 많이 소요되었습니다. 배포 전 매번 동일한 일련의 동작들을 클릭해야 했기 때문입니다.

이는 회귀를 자동으로 포착하기 위해 세션을 리플레이하는 것에 대해 생각하게 된 계기가 되었습니다. 운영 (production) 환경에 대해서는 데이터를 변경하거나 부작용 (side effects)을 일으킬 수 있기 때문에 리플레이를 할 수 없습니다. 스테이징 (staging) 환경에 대해 리플레이할 수도 있겠지만, 많은 기업이 운영 환경을 대표할 수 있는 스테이징 환경을 갖추고 있지 않습니다. 또한, 각 리플레이 세션이 끝난 후 상태 (state)를 초기화하는 메커니즘이 필요합니다 (사용자가 웹 애플리케이션에 가입하는 과정을 리플레이한다고 상상해 보세요).

저희는 특히 고통스러운 버그 유형이라고 생각하는 회귀 (regression)에 초점을 맞추어 Meticulous를 설계했습니다. 회귀는 사용자가 활발하게 사용 중인 플로우에서 발생하는 경향이 있으며, 회귀의 수는 일반적으로 코드베이스 (codebase)의 크기와 복잡성에 따라 증가하며, 코드베이스는 항상 증가하는 경향이 있습니다.

Meticulous는 본인의 웹사이트뿐만 아니라 어떤 웹사이트에서도 사용할 수 있습니다. 예를 들어, 세션 기록을 시작한 다음 (예를 들어) amazon.com에 가입하고, amazon.com에 대해 두 번 리플레이한 뒤 결과 스크린샷을 비교하는 간단한 테스트를 만들 수 있습니다. 또한 Meticulous 대시보드 (dashboard)에서 녹화 및 리플레이를 시청할 수 있습니다. 물론, 보통은 운영 사이트에 대해 두 번 리플레이하는 대신, PR (Pull Request)의 베이스 커밋 (base commit)과 헤드 커밋 (head commit)에 대해 리플레이하게 될 것입니다.

저희 API는 현재 상당히 로우 레벨 (low-level)입니다. Meticulous CLI를 통해 세 가지 작업을 수행할 수 있습니다:

1. 'yarn meticulous record'를 사용하여 브라우저를 열 수 있으며, 이를 통해 localhost와 같이 원하는 URL에서 세션을 기록할 수 있습니다. 더 많은 세션을 캡처하고 싶다면 스테이징 (staging), 로컬 (local), 개발 (dev), QA 환경에 저희의 JS 스니펫 (snippet)을 주입할 수도 있습니다. 이는 여러분의 작업물을 테스트하기 위한 용도입니다! 스니펫을 주입할 경우, 동료들의 워크플로 (workflow)를 기록하기 전에 반드시 동료들의 동의를 구하시기 바랍니다. 현재 저희의 비식별화 (redaction) 기능은 매우 기초적인 수준이므로, 운영 (production) 환경 배포는 권장하지 않습니다.

2. 'yarn meticulous replay'를 사용하여 원하는 URL에 대해 세션을 재현 (replay)할 수 있습니다. 재현 과정 동안, 저희는 브라우저를 실행하고 Puppeteer를 사용하여 클릭 이벤트 (click events)를 시뮬레이션합니다. 예외 (exceptions) 목록과 네트워크 로그 (network logs)가 디스크에 기록됩니다. 재현이 끝나면 스크린샷 (screenshot)이 찍혀 디스크에 저장됩니다.

3. 'yarn meticulous screenshot-diff'를 사용하여 두 개의 스크린샷을 비교 (diff)할 수 있습니다.

여기에는 많은 잠재적 사용 사례가 있습니다. 스크린샷 비교 기능을 기반으로 UX 플로우 (flow)의 주요 회귀 (regressions)를 탐지하는 시스템을 구축할 수 있습니다. 또한 재현 중에 발생한 예외들을 비교하여 새로운 미처리 JavaScript (JS) 예외를 탐지할 수도 있습니다. 저희는 별도의 설정 없이도 바로 테스트를 제공하는 더 높은 수준의 제품을 구축할 계획입니다.

Meticulous는 기록 시간 (record-time)에 네트워크 트래픽을 캡처하고, 재생 시간 (replay-time)에 네트워크 호출을 모킹 (mock) 합니다. 이를 통해 프론트엔드 (frontend)를 격리하고 어떠한 부작용 (side effects)도 발생하지 않도록 방지합니다. 하지만 이 접근 방식에는 몇 가지 문제점이 있습니다. 첫 번째는 백엔드 (backend) 변경 사항이나 통합 (integration) 변경 사항을 테스트할 수 없고, 오직 프론트엔드 변경 사항만 테스트할 수 있다는 점입니다. (하지만 저희는 네트워크 스터빙 (network-stubbing)을 선택 사항으로 만들어, 원하신다면 스테이징 환경 (staging environment)을 대상으로 재생할 수 있도록 만들 예정입니다.) 저희 방식의 두 번째 문제는 API가 크게 변경될 경우, 테스트를 위해 새로운 세션 세트를 다시 기록해야 한다는 것입니다. 세 번째 문제는 서버 사이드 렌더링 (server-side rendering)에 크게 의존하는 웹 애플리케이션을 아직 지원하지 않는다는 점입니다. 하지만 저희는 Meticulous가 백엔드 환경에 구애받지 않도록(agnostic) 만들기 위해 이러한 트레이드오프 (trade-offs)를 감수할 가치가 있다고 판단했습니다.

물론 Meticulous가 여러분의 모든 테스트를 대체하지는 않을 것입니다. 저는 이를 기존의 테스트 도구 및 관행과 병행하여 사용하고, 추가적인 방어 계층 (layer of defense)으로 간주할 것을 권장합니다.

저희는 매월 20개의 세션을 재생할 수 있는 무료 플랜을 제공합니다. HN 출시를 기념하여 임시로 제한을 250개로 변경했습니다. 베이직 (basic) 플랜은 월 $100입니다. CLI 자체는 ISC 라이선스 하에 오픈 소스입니다. 저희는 기록 및 재생 (record+replay) 코드를 오픈 소스로 공개하는 것에 대해 활발히 논의 중입니다.

여러분께서 Meticulous를 마음껏 사용해 보셨으면 좋겠습니다! https://docs.meticulous.ai 에서 직접 체험해 보실 수 있습니다. 아직 다듬어지지 않은 부분이 있지만, 가능한 한 빨리 HN에 이 제품을 선보이고 싶었습니다. 저희가 이 제품을 기반으로 무엇을 더 구축하기를 원하시는지 알려주세요 (시각적 차이 비교 (visual diffs)? 성능 저하 (perf regressions)? 데드 코드 분석 (dead code analysis)? 회귀 방지 (preventing regressions)?). 또한 회사에서 어떤 종류의 재생 테스트 (replay testing)든 구축해 본 경험이 있는 분들의 의견도 듣고 싶습니다. 읽어주셔서 감사하며, 여러분의 댓글을 기다리겠습니다!