agent-browser 화면 녹화: FPS 선택과 QA 활용법

브라우저 테스트 화면 녹화 FPS는 검토 목적에 맞춰 고릅니다

우선 30 fps에서 시작하면 됩니다. 일반적인 클릭과 호버 상태, 스크롤, CSS 전환, 사용 흐름을 충분히 알아볼 수 있으면서도 60 fps의 추가 부하는 피할 수 있어 새 기본값으로 채택됐습니다.

유효한 --fps 범위는 1부터 60까지입니다. 숫자가 높다고 언제나 더 강한 증거가 되는 것은 아닙니다. 페이지가 요청한 속도보다 드물게 다시 그려진다면 60 fps로 설정해도 서로 다른 페이지 상태 60개가 생기지는 않습니다.

v0.37.0에서 달라진 점

이제 녹화기는 실제 사용 중인 페이지를 시간의 흐름에 따라 보여 주는 방식으로 영상을 만듭니다. record start와 record restart는 현재 활성 페이지를 기본 30 fps로 캡처하고, --fps 1-60을 지원하며, Chrome의 Page.startScreencast를 사용합니다. 가끔 스크린샷을 찍는 방식과 달리, 카메라를 브라우저의 화면 출력 경로에 직접 연결한 것처럼 Chrome이 다시 그린 페이지 프레임을 그대로 받습니다.

v0.37.0 릴리스에서는 오류 처리도 더 엄격해졌습니다. ffmpeg가 없거나 출력 경로에 확장자가 없거나 녹화 옵션이 유효하지 않으면 브라우저나 녹화 상태가 바뀌기 전에 실패합니다. 새 녹화본을 시작하지 못해도 기존 녹화본은 유지됩니다. 녹화 중 페이지를 이동하면 이제 일반적인 페이지 이동과 마찬가지로 오래된 요소 참조와 프레임 상태를 지웁니다.

실제 QA 과정에서는 이 차이가 중요합니다. 잘못된 영상 경로 때문에 테스트 중인 페이지가 아무 경고 없이 바뀌어서는 안 됩니다. 두 번째 녹화본을 시작한다는 이유로 새 녹화가 제대로 시작되는지 확인하기도 전에 첫 번째 녹화본이 사라져서도 안 됩니다.

자동화 테스트 화면 녹화를 완성하는 다섯 단계

안정적인 순서는 확인, 열기, 녹화, 어설션, 중지입니다. 마지막 명령까지 실행해야 파일 기록이 마무리되고 저장되므로, 이 명령도 증거 계약의 일부입니다.

agent-browser doctor
agent-browser open https://app.example.com/login
agent-browser record start ./login-flow.mp4 --fps 30
agent-browser snapshot -i
agent-browser click @e1
agent-browser wait --url "**/dashboard"
agent-browser record stop

1. 먼저 인코더를 확인합니다. agent-browser doctor는 ffmpeg와 녹화 인코더 정보를 보여 줍니다. MP4에는 libx264, WebM에는 libvpx가 필요합니다. 표준 Homebrew 또는 Debian/Ubuntu ffmpeg 빌드에는 보통 둘 다 포함돼 있습니다.

2. 활성 탭에 녹화할 페이지를 준비합니다. record start에 URL을 지정하지 않으면 녹화기는 활성 페이지의 현재 상태에 그대로 연결됩니다. 페이지를 새로 고치거나 새 탭을 열거나 초기화된 브라우저 환경을 만들지 않습니다. 초기 로딩을 마친 앱, 인증된 세션, 페이지 내부 상태에 따라 버그가 발생할 때 유용합니다. URL을 넣으면 활성 탭이 먼저 이동하고 페이지를 불러온 뒤 녹화가 시작됩니다.

3. 확장자로 컨테이너를 선택합니다. .mp4는 libx264를 통한 H.264를, .webm은 libvpx를 통한 VP8을 선택합니다. 다른 확장자는 H.264와 함께 ffmpeg로 전달되며, ffmpeg가 해당 컨테이너를 지원할 때만 작동합니다. 확장자가 없는 파일명은 거부됩니다.

4. 자동화 안에 통과/실패 검사를 남겨 둡니다. 예시의 wait --url은 브라우저가 대시보드에 도착했는지 확인합니다. 영상은 사람이 상황을 이해하도록 돕지만, 픽셀을 테스트 어설션으로 바꾸지는 않습니다.

5. 닫기 전에 중지합니다. record stop은 녹화본을 저장하고 남은 데이터를 파일에 기록합니다. 먼저 세션을 닫으면 보관하려던 파일이 남지 않을 수 있습니다. 활성 페이지에서 한 녹화본을 끝내는 즉시 다음 녹화를 시작하려면 record restart를 사용합니다.

capturedFrames와 frames는 서로 다른 질문에 답합니다

두 카운터는 원본 재료와 완성 영상으로 나눠 읽으면 됩니다. capturedFrames는 페이지가 만든 서로 다른 프레임 수입니다. frames는 영상 파일에 기록된 프레임 수입니다. 정적인 페이지는 서로 다른 화면을 거의 만들지 않더라도, ffmpeg는 녹화본이 자연스럽게 재생되도록 같은 프레임을 반복해 기록할 수 있습니다.

시간 처리에는 중요한 예외가 하나 있습니다. 페이지의 변화가 멈추면 마지막 프레임을 유지합니다. 하나의 정적 구간은 최대 5초까지 유지한 뒤, 변화가 없는 나머지 구간을 생략합니다. 따라서 짧은 멈춤은 영상에 남지만 긴 유휴 구간은 압축됩니다. 장시간 안정성 테스트에서 재생 시간을 초시계처럼 사용해서는 안 됩니다.

그래서 capturedFrames가 적다고 무조건 녹화 실패는 아닙니다. 페이지가 단순히 움직이지 않았을 수 있습니다. 또한 60 fps를 실제로 살펴볼 가치가 있는 움직임에만 써야 하는 이유이기도 합니다. 녹화 가이드에 따르면 60 fps의 비트레이트는 30 fps의 약 2배지만, 서로 다른 프레임 수는 여전히 페이지가 다시 그려진 횟수에 달려 있습니다.

달라지는 비용 항목

팀에서 이미 agent-browser를 사용한다면 기본적인 영상 증거를 위해 별도 녹화 도구의 사용자 라이선스부터 추가할 필요가 없습니다. v0.37.0 패키지는 Apache-2.0 라이선스를 명시하므로 녹화기 자체에는 사용자당 소프트웨어 라이선스 비용이 없습니다. 추가되는 비용은 직접 운영하는 항목, 즉 ffmpeg 설정, CI 시간, 결과물 저장 공간, 사람이 결과를 검토하는 데 쓰는 시간입니다.

이는 완전한 피드백 또는 테스트 플랫폼을 구매하는 것과 분명히 다릅니다. Jam Team은 연간 결제 기준 크리에이터당 월 $14로 표시돼 있습니다. BugHerd Standard는 월간 결제 기준 사용자 5명에 월 $50이며 영상 피드백을 포함합니다. BrowserStack Automate는 연간 결제 기준 Chrome Desktop 병렬 실행 1개가 월 $59이며 디버깅 툴에 영상 녹화가 포함됩니다.

이들 제품은 녹화 외에도 더 많은 기능을 판매하므로 대체 가능하다고 결론 내리면 안 됩니다. BrowserStack은 관리형 브라우저 지원 범위를 제공합니다. BugHerd와 Jam은 협업, 이슈 캡처, 연동 기능을 제공합니다. 비용 판단의 범위는 더 좁아야 합니다. agent-browser가 이미 흐름을 실행하고 있고 부족한 결과물이 검토하기 쉬운 영상뿐이라면 두 번째 캡처 계층을 구매하지 않는 편이 낫습니다.

효과가 큰 순서로 본 일곱 가지 활용 사례

1. 실패한 CI 흐름을 진단하는 제품팀

로그인이나 결제 테스트가 불안정한 제품팀이라면 문제가 생기기 쉬운 경로 직전에 30 fps 녹화를 시작하고, 기존 URL 또는 요소 어설션을 유지한 채 실행 실패 시 MP4를 CI 결과물로 보관할 수 있습니다. 엔지니어는 텍스트 로그에서 놓치기 쉬운 동의 배너, 뒤늦게 나타난 오버레이, 포커스 이동, 화면 전환을 확인할 수 있습니다. 간헐적인 상태를 재현하느라 쓰는 엔지니어링 시간을 줄일 수 있다는 것이 실질적인 효과입니다.

2. 드래그, 스크롤, 애니메이션을 검토하는 프런트엔드팀

프런트엔드 엔지니어는 짧은 상호작용 하나만 분리해 60 fps로 캡처한 뒤 시작과 끝 상태의 스크린샷을 영상과 함께 둘 수 있습니다. 영상은 두 상태 사이의 움직임이 매끄러웠는지 보여 주고, 스크린샷은 정확한 픽셀을 보존합니다. 프레임이 누락되거나 드래그 대상이 엉뚱한 순간에 지나가는 것처럼 두 스크린샷 사이에 결함이 있을 때 가치가 있습니다.

3. 브라우저 에이전트의 행동을 점검하는 AI 제품팀

AI 제품팀은 에이전트가 작업을 수행하는 동안 인증된 활성 페이지를 30 fps로 녹화한 뒤, 에이전트의 명령 기록과 어설션 옆에 영상을 첨부할 수 있습니다. 검토자는 잘못된 실행 계획과 에이전트가 작업하던 중 페이지가 바뀐 상황을 구분할 수 있습니다. 불투명했던 실행이 제품 관리자와 엔지니어가 함께 논의할 수 있는 증거로 바뀝니다.

4. 상태 의존적 버그를 재현하는 QA 엔지니어

QA 엔지니어는 버그의 전제 조건이 갖춰질 때까지 세션을 준비한 뒤 URL 없이 record start를 실행할 수 있습니다. 녹화가 현재 페이지에 그대로 연결되므로 처음부터 다시 불러온 페이지로 바뀌지 않습니다. 새로 고치면 사라지는 누적 장바구니 상태, 모달, 인증 경로 또는 다른 조건에 의존하는 버그에서 효과를 냅니다.

5. 고객에게 릴리스를 인계하는 에이전시

웹 에이전시는 인수 테스트 경로를 30 fps로 녹화하고 판단 지점마다 짧은 대기를 넣어, 자동화 엔진이 아니라 사람이 따라가기 좋은 속도의 영상을 고객에게 전달할 수 있습니다. 고객은 테스트 실행 도구의 접근 권한 없이도 정확한 경로를 검토할 수 있습니다. 결과물이 이미 흐름을 보여 주므로 에이전시가 회의에서 설명하는 시간이 줄어듭니다.

6. 장기 실행 타임라인을 보관하는 신뢰성팀

신뢰성 엔지니어는 움직임보다 순서가 중요할 때 긴 안정성 테스트를 10 fps로 녹화할 수 있습니다. 30 또는 60 fps보다 녹화 부하와 파일 증가량이 줄어듭니다. 눈에 보이는 실패 시점을 찾는 데는 여전히 유용하지만, 정적 구간이 압축되므로 타임스탬프는 재생 길이가 아닌 로그에서 확인해야 합니다.

7. 까다로운 브라우저 이슈를 개발팀에 넘기는 지원 엔지니어

지원 엔지니어는 통제된 계정에서 고객 경로를 재현해 30 fps로 녹화한 뒤, 녹화를 중지하고 개발팀 이관 자료에 첨부할 수 있습니다. 개발팀은 글로 작성한 티켓에서 흔히 빠지는 동작 시점과 예기치 않은 오버레이까지 함께 받습니다. 다만 워크플로가 비밀 정보와 고객 데이터의 녹화 유입까지 막을 때만 가치가 있습니다.

만들어 볼 만한 세 가지 제품

가장 좋은 기회: 에이전트 실행 증거 패키지

브라우저 에이전트 실행 한 번을 하나의 검토 패키지로 묶는 작은 서비스를 만들 수 있습니다. 어설션 결과, 명령 기록, 최종 스크린샷, MP4, 프레임 카운터, Jira 또는 Linear에 게시된 링크를 한데 담는 방식입니다. 제품팀과 엔지니어링팀이 이미 쓰는 이슈 워크플로에 결과물이 바로 들어가므로 비용을 지불할 이유가 생깁니다.

수요는 구체적입니다. 미국 키워드 데이터에서 “bug reporting tool”의 월간 검색량은 약 590회, CPC는 $43.80입니다. 기존 지출도 확인됩니다. Jam Team은 연간 결제 기준 크리에이터당 월 $14이고, BugHerd Standard는 월간 결제 기준 월 $50입니다. 판매 가능한 최소 버전에는 agent-browser 래퍼 하나, 결과물 저장소, 이슈 트래커 연동 하나, 민감 정보 제거 체크리스트가 필요합니다.

코덱이 아니라 인계 과정을 판매한다는 점에서 가장 강한 기회입니다. 다만 기술적 방어력이 낮다는 문제가 있습니다. Jira 게시와 영상 저장은 쉽게 복제할 수 있으므로, 신뢰할 만한 맥락을 조합하고 민감한 데이터의 유입을 막는 능력이 유난히 뛰어나야 합니다.

에이전시용 QA 인계 포털

에이전시가 흐름을 선택해 스테이징에서 실행하고, 어설션과 스크린샷, 보기 좋은 속도의 영상을 하나의 승인 링크로 공개하는 고객용 검토 페이지를 만들 수 있습니다. 기술적 증거를 두고 회의가 길어지기 쉬운 고객 승인 과정이 있으므로 에이전시와 외부 계약형 QA팀이 구매자가 됩니다.

미국 키워드 데이터에서 “website qa testing”의 월간 검색량은 110회이며, 전년 대비 55% 증가했고 CPC는 $23.91입니다. MVP는 재사용 가능한 흐름 몇 개, 30 fps 캡처, 댓글, 승인 또는 거절 기능으로 구성할 수 있습니다. 다만 기존 업체의 기능 범위가 넓다는 문제가 있습니다. BugHerd의 Standard 요금제에는 이미 무제한 프로젝트, 고객 사용자, 스크린샷, 메타데이터, 영상 피드백이 포함됩니다. 새 제품은 또 하나의 댓글 핀이 아니라 에이전트가 생성한 증거로 승부해야 합니다.

모션 테스트 프리셋 계층

테스트에 timeline, default, motion 라벨을 붙여 각각 10, 30, 60 fps로 연결하고, 캡처 프레임과 기록 프레임 사이에 예상 밖의 차이가 생기면 표시하는 가벼운 CI 툴을 만들 수 있습니다. 애니메이션과 상호작용 회귀 전반에서 일관된 증거가 필요한 프런트엔드 플랫폼팀이 구매자가 됩니다.

미국 키워드 데이터에서 “automated browser testing”의 월간 검색량은 110회, CPC는 $14.96입니다. 상업성이 더 강하고 범위가 좁은 “automated browser testing tools”는 월간 검색량이 20회에 불과하지만 CPC는 $63.21입니다. 소수의 구매자에게 도달하는 비용이 높다는 신호입니다. MVP는 테스트 명세, agent-browser 명령 래퍼, 실패한 경우에만 보관하는 영상, 간결한 결과물 목록으로 구성됩니다.

다만 성장세가 약합니다. 더 넓은 키워드의 검색량은 전년 대비 18% 감소했으며, 60 fps는 부하를 더하면서도 여전히 페이지가 다시 그려지는 속도의 제약을 받습니다. 따라서 독립된 회사가 아니라 증거 제품 내부의 기능으로 시작하는 편이 맞습니다.

화면 녹화만으로 입증할 수 없는 것

영상은 관찰 수단이지 정확성을 보장하는 수단이 아닙니다. 올바른 데이터베이스 행이 기록됐는지, API 응답이 유효했는지, 모든 브라우저와 기기가 같은 방식으로 동작하는지는 알려 주지 못합니다. 어설션, 로그, 스크린샷을 함께 보관해야 합니다.

환경 위험도 사라지지 않습니다. 녹화하려면 PATH에 ffmpeg와 맞는 인코더가 있어야 합니다. 높은 프레임 레이트는 부하를 늘리고 긴 녹화는 디스크를 사용하며, 자원이 제한된 헤드리스 장비에서는 코덱 또는 GPU 제약이 생길 수 있습니다. 화면을 느리게 다시 그리는 페이지는 매초 서로 다른 프레임 60개를 제공할 수 없습니다.

개인정보 보호는 제품의 필수 요건으로 다뤄야 합니다. 녹화기는 활성 화면 영역과 페이지 내부 상태를 캡처합니다. 바로 그 특성 때문에 유용하지만, 테스트 계정, 비밀 정보 마스킹, 결과물 보관 기간, 접근 제어에 명확한 규칙이 필요합니다. 이는 운영상의 판단이지 기본으로 제공되는 민감 정보 제거 기능을 약속하는 것은 아닙니다.

마지막으로 agent-browser는 증거를 기록할 뿐 해석하지는 않습니다. 실행 후 모델이 영상을 검사하게 하려면 별도 시스템이 필요하며, 이는 에이전틱 영상 이해에 더 가깝습니다. 이 계층은 결정론적인 통과/실패 검사와 분리해야 합니다.

다음 주 월요일에 바로 해볼 일

다음 주에는 웹 테스트 자동화 대상 중 실패가 잦은 로그인, 결제 또는 게시 경로 하나를 고릅니다. doctor를 실행하고 기존 활성 페이지를 30 fps로 녹화하되 현재 어설션은 유지한 다음, record stop을 호출하고 MP4를 테스트 결과에 첨부합니다. 검토자가 움직임 결함을 판단하기 어려울 때만 60 fps로 올리고, 긴 실행에서 주로 순서를 볼 때는 10 fps로 낮춥니다. 영상이 단지 부드럽게 보이는지가 아니라, 재실행 없이도 검토자가 실패 원인을 진단할 수 있는지가 시범 운영의 성공 기준입니다.

팀의 검토에 바로 쓸 수 있는 증거를 만드는 브라우저 에이전트가 필요하다면, 실제 QA 워크플로에 맞춰 구축해 드릴 수 있습니다.