7 hours ago
1
지난 글 "우아한 디버깅 툴 1부: 웹뷰/웹페이지 원격으로 디버깅하기"에서는 이슈 정보를 쉽게 기록하고 공유하는 방법에 대해 다뤘습니다. 하지만 QA를 더 원활하게 진행하기 위해서는 아직 개선해야 할 부분이 많았습니다. 이번 글에서는 QA 업무 생산성 향상을 위해 추가한 기능들을 소개합니다.
들어가기 전 복습하기
- 기록방 : 원격 디바이스에서 기록한 데이터를 크롬 개발자 도구의 UI로 조회할 수 있는 페이지
- CDP : Chrome Devtools Protocol. 기록방에서 사용하는 데이터 포맷
- SDK : 대상 웹뷰에서 동작하며 플로팅 버튼을 생성하고 각종 기능을 실행하는 역할을 합니다.
세션 리플레이 (Session Replay)
이슈가 발생했을 때, QA 담당자는 이슈를 다시 재현하고 그 과정을 영상으로 녹화해야 합니다. 네트워크 기록은 이미 자동으로 수집되지만, 영상 녹화를 위해선 여전히 수동으로 재현하는 과정이 필요했죠. 하루에도 수십, 수백 개의 테스트 케이스를 확인하는 QA 담당자에게 매번 이슈를 재현하는 일은 상당한 리소스를 소모하는 일입니다.
만약 네트워크 기록뿐만 아니라 영상까지 자동으로 기록되어 바로 보고할 수 있다면 어떨까요? QA 담당자는 반복적인 재현 작업에서 벗어나 리소스를 절약할 수 있고, 개발자 역시 이슈 발생 상황을 시각적으로 확인하며 문제 해결 시간을 단축할 수 있습니다.
영상을 어떻게 기록할까?
‘영상’이라고 표현했지만, 실제 영상을 녹화한 것이 아니라 세션 리플레이(Session Replay) 기술을 활용했습니다. 실제로는 DOM 스냅샷과 사용자 인터랙션 이벤트를 기록해 브라우저에서 재현하는 방식입니다.
데이터 수집 및 영상 재현 기능은 rrweb 오픈소스 라이브러리를 사용했습니다. 주간 다운로드 수가 100만에 달할 만큼 안정적이고 최적화가 잘 되어 있는 라이브러리죠. rrweb 플레이어(Player)는 재생 속도 조절, 남은 시간 표시, n초 단위 이동 등 일반적인 영상 플레이어에서 기대할 수 있는 다양한 기능을 제공하며, 디자인도 원하는 대로 바꿀 수 있습니다. 이렇게 rrweb는 이벤트 감지 및 플레이어를 전담합니다.
우리가 할 일은 데이터를 CDP 포맷으로 정제해서 서버에 저장하고, 기록방에 Session Replay 탭을 신설하여 해당 데이터를 읽어와 rrweb 플레이어에 전달하기만 하면 됩니다.
이렇게 기록방에 마치 원래 개발자 도구의 기능이었던 것처럼, Session Replay 탭이 추가되었습니다!
비용이 많이 들지 않을까?
Sentry나 Datadog에서 제공하는 세션 리플레이 비용이 꽤 높은 편이라 인프라 비용에 대한 걱정이 있었습니다. 하지만 rrweb은 첫 화면 스냅샷 외에는 변경 이벤트만 기록하고 재현하기 때문에 예상보다 용량이 크지 않았습니다.
위에 36초 길이의 영상은 Next.js로 구성된 비마트 장바구니 웹뷰에서 몇 가지 동작을 기록했는데, 1500회 정도의 이벤트와 1.4MB의 데이터로 저장되었습니다. 웹소켓 통신과 rrweb의 최적화된 데이터량을 고려하면 비용 부담 없이 가볍게 사용할 수 있습니다.
슬랙 DM 알림
기록방 링크는 주로 티켓에 첨부합니다. 티켓 생성/수정은 주로 PC에서 이루어지는데, 정작 테스트 디바이스는 모바일이다 보니, 클립보드 복사 기능을 제공하더라도 링크와 재현 정보를 PC로 옮기는 번거로운 과정이 있었습니다. 이를 해결하기 위해 슬랙 개인 DM을 보내주는 기능을 추가했습니다.
문제는 디바이스와 사용자를 자동으로 연결할 수 없었다는 점입니다. 베타앱에 로그인한 테스트 계정이 반드시 해당 사용자의 것이라는 보장이 없었기 때문이죠. 결국 사용자가 직접 자신의 디바이스와 슬랙 ID를 입력하는 구글 시트를 운영하게 되었습니다.
기록방 생성 시 디바이스 정보로 구글 시트에서 유저를 판별하고, 슬랙 봇을 통해 기록방 링크와 디바이스, 앱, 사용자 정보를 DM으로 전달합니다. 이슈 제보자는 이 메시지를 그대로 개발자에게 전달하면 됩니다.
티켓 생성 기능
기록방 덕분에 재현 없이 이슈 티켓을 생성할 수 있게 되었습니다. 여기서 한 걸음 더 나아가, 베타앱에서 바로 티켓을 생성하고 기록방과 각종 정보를 자동으로 입력하면 시간을 더 단축할 수 있지 않을까요?
슬랙 DM을 위해 만들었던 구글 시트에 티켓 생성에 필요한 데이터를 추가했습니다.
이제 베타앱에서 티켓 생성 창을 띄우고, 구글 시트 정보를 기반으로 티켓을 만들 수 있습니다. 서버는 구글 시트 정보를 내려받아 티켓 생성 요청을 처리하고, 티켓 생성 API를 사용해 티켓을 생성합니다.
생성된 티켓 링크를 슬랙 DM으로 받아 접속하면,
생성된 티켓 예시
재현 환경, 기록방, 티켓 생성 창에서 입력한 담당자, 제목 등 필요한 정보가 모두 자동으로 채워져 있습니다. 이슈 제보자는 이슈 상황 설명만 추가하면 티켓 생성이 완료되고, 개발자는 더이상 디버깅에 필요한 데이터가 누락되어 재요청하고 기다리는 일이 없어졌습니다!
티켓 생성 흐름
티켓 생성 흐름을 도식화하면 위와 같습니다.
어드민
처음에는 구글 시트를 사용했지만, 프로젝트별로 티켓 생성 창에 노출할 정보를 수정해야 하고, 사용자가 많아지면서 가독성이 떨어지고 다른 사람 정보를 실수로 수정하는 등 한계가 명확해졌습니다.
이러한 문제를 해결하기 위해,어드민 페이지는 사내 로그인을 통해 사용자를 식별하며 아래와 같은 기능을 지원합니다.
사용자 정보 등록
사용자는 기본정보로 자신의 직군과 테스트에 사용하는 디바이스의 ID를 등록합니다. 이 정보를 통해 유저를 식별해서 DM을 보내거나, 직군에 따른 티켓 양식이 적용됩니다.
티켓 템플릿 사전 등록
티켓을 생성할 지라 프로젝트와, 프로젝트별 정보를 템플릿으로 등록해두고 티켓 생성 창에서 선택할 수 있습니다.
기능 소개, 사용자 가이드, 개발자 도입 가이드 제공
사용자 가이드는 단순 문서가 아닌, 체험형으로 제공해 쉽게 익힐 수 있도록 했습니다.
Network Rewrite
QA 업무 중에 API를 강제로 실패시키거나, API 응답에 따른 UI 변경을 확인이 필요할 때 기존에는 Charles라는 Proxy 도구를 사용했습니다. 하지만 물리적으로 연결해야하고, 복잡한 설정이 필요한 불편함이 있었는데요.
Network Rewrite는 별다른 설정 없이 API의 요청/응답 데이터를 조작해 테스트 환경을 강제할 수 있는 기능입니다.
처음에는 service worker사용을 고려했지만, msw와의 충돌이나 별도 js 파일의 필요성 등 불필요한 복잡성이 예상되었습니다. 대신 XMLHttpRequest와 fetch를 오버라이드하여 실제 요청/응답 데이터를 수정하는 방식을 채택했습니다. 그리고 조작 데이터는 sessionStorage에 저장하기 때문에 웹뷰가 유지되는 동안만 유효합니다.
기록방 생성을 위해 수집한 네트워크 기록을 기반으로 리스트를 보여주고, 선택한 API의 실제 요청/응답 데이터를 수정할 수 있습니다.
마무리하며
QA Flow As-Is
QA Flow To-Be
우아한 디버깅 툴 도입 후, 이슈 재현, 수집 과정이 사라지면서 업무 플로우가 단방향이 되었습니다. 이슈 제보자는 더 이상 데이터 수집에 시간을 낭비하지 않고 이슈를 등록할 수 있게 되었고, 개발자도 이슈에 필요한 데이터를 기록방을 통해 빠짐없이 전달받아서 끊김없이 이슈 해결을 할 수 있습니다.
‘우아한 디버깅 툴’의 목표는 단순합니다. 모든 직군의 QA 업무를 조금이라도 더 편하게 만드는 것.
앞으로도 우아한 디버깅 툴은 이슈 상황의 네트워크 기록을 개발자 로컬 환경에서 동일하게 재현하거나, 네트워크 시나리오를 미리 어드민에 등록하는 등 QA 업무를 더 효율적으로 만들기 위해 계속 발전해 나갈 예정입니다.
English (US) · 