개발자와 QA를 위한 영상 압축

MOV, MP4, WebM, GIF 재생산 기록을 축소하여 증거가 가독성을 유지하고 이슈, 풀 리퀘스트, 지원 티켓에 적합하도록 하는 실용적인 워크플로우입니다.

버그를 30초 만에 녹화했습니다. 하지만 재생산 파일을 업로드하는 데 더 오랜 시간이 걸렸고, 두 번 실패한 후 GitHub에서 파일이 너무 크다고 알려주었습니다. 혹은 QA가 MOV 파일을 첨부했지만 인라인으로 로드되지 않아 아무도 시청하지 않은 경우도 있습니다.

화면 녹화는 종종 회귀를 설명하는 가장 빠른 방법이지만, 리뷰어가 파일을 빠르게 열고 인터페이스를 읽으며 정확한 실패 경로를 다시 재생할 때만 가능합니다.

화면 녹화 파일 크기와 이슈 추적기 제한

이슈 추적기와 PR 호스트는 첨부 파일 크기를 제한합니다. QuickTime, CleanShot, OBS 등에서 나온 풀 해상도 MOV 또는 MP4는 잘라내기 전에도 수십에서 수백 메가바이트에 달하는 경우가 많습니다.

먼저 잘라내고, 업로드에 충분한 여유를 두고 추적기의 실제 제한까지 압축합니다. 가장 작은 숫자를 쫓기 전에 UI 텍스트를 보존하세요. 하드 캡이 중요한 경우 목표 파일 크기 프리셋을 사용하세요. 짧은 무음 루프가 영상보다 문제를 더 잘 설명할 때만 작은 GIF로 변환하세요.

버그 리포트를 위한 영상, GIF, 스크린샷 형식

버그 증거는 몇 가지 형태로 제공되며, 각각 다른 전달 방식을 요구합니다:

영상: 화면 녹화 도구와 데모 도구에서 제공하는 MOV, MP4, WebM, M4V, MKV 등.
GIF: 루프로 볼 때 더 잘 읽히는 짧은 UI 글리치, 호버 상태, 로딩 회귀.
이미지: 정지 프레임만으로도 보고서에 충분한 경우 PNG 및 JPEG 스크린샷.

QA가 제출했든, 내 자신의 PR에 증거를 첨부했든 동일한 큐와 프리셋을 사용합니다.

이슈와 풀 리퀘스트에 재생산 영상 첨부

비교 영상은 리뷰를 빠르게 만듭니다. 버그와 그 수정 사항을 보여주는 컴팩트한 MP4는 브랜치 체크아웃 없이 리뷰어에게 컨텍스트를 제공합니다. QA 승인도 동일한 방식으로 작동합니다. 가벼운 첨부 파일은 몇 달 후에도 검색, 재개봉, 공유가 더 쉽습니다.

테스트 통과 후 녹화 파일 일괄을 드롭하거나, 파일 하나를 복사하여 클립보드에 붙여넣을 수 있는 가벼운 버전을 받아올 수 있습니다.

반복 가능한 캡처 폴더 구성

티켓이나 테스트 실행마다 예측 가능한 폴더를 사용하세요: source, redacted, attachment. 원본 캡처를 보존하고, 사본에 승인된 삭제 작업을 수행한 후, 검토된 사본에서 더 작은 첨부 파일을 생성합니다. attachment 폴더의 파일은 추가적인 판단 없이도 지정된 추적기에 배치할 수 있어야 합니다.

파일 이름에 티켓 ID와 플랫폼을 포함하세요. 예: GC-142-windows-actual.mp4. 고객 이름, 이메일 주소, 내부 호스트 이름을 노출하는 파일 이름은 피하세요.

실제 이슈 추적기 첨부 파일 제한

GitHub, Jira, Linear 및 대부분의 PR 호스트는 플랜과 파일 유형에 따라 인라인 첨부 파일 제한을 10MB에서 100MB 사이로 설정합니다. 풀 Retina 해상도의 30초 MOV는 디스크에서 ‘크다’고 느껴지지 않아도 해당 제한을 초과할 수 있습니다. PM과 지원팀과의 이메일 스레드에 재생산 클립을 붙여넣을 때 동일한 계산이 적용되는 경우 이메일 첨부 파일 크기 제한 을 참조하세요.

목표 파일 크기 프리셋은 알려진 제한 내에 적합합니다. GIF 루프만으로도 충분한 UI 회귀의 경우, 전체 MP4 대신 작은 루프를 내보내세요. PNG 스크린샷에 비해 모션 재생산에는 손실 압축과 무손실 압축 의 차이가 덜 중요합니다. 티켓 리더가 레이블을 여전히 읽을 수 있도록 스크린샷 프리셋은 보수적으로 유지하세요.

녹화 디렉토리의 폴더 모니터링은 누구나 첨부하기 전에 모든 새로운 캡처가 가벼워지도록 합니다. 이는 전체 팀이 같은 인박스에 MOV 파일을 드롭하는 회귀 기간 동안 특히 유용합니다.

유용한 버그 증거를 위한 사전 점검 체크리스트

압축은 초점이 맞지 않은 녹화를 구원할 수 없습니다. 파일을 첨부하기 전에 증거 자체를 확인하세요:

인식할 수 있는 상태에서 시작하여 문제를 유발하는 정확한 동작을 보여주세요.
로그인, 설정, 재시도, 대기 시간을 잘라내세요. 단, 이 중 하나가 버그의 일부인 경우를 제외합니다.
포인터를 표시하고 작은 컨트롤을 녹화하기 전에 앱 창을 확대하세요.
압축된 사본을 100%로 스크러브하여 레이블, 콘솔 텍스트, 오류 메시지가 여전히 가독성 있는지 확인하세요.
관련 없는 알림, 토큰, 고객 기록, 브라우저 탭을 제거하세요.
이슈 텍스트에 환경, 빌드, 예상 결과, 실제 결과를 명시하세요. 영상은 보고서를 대체하지 않고 보완해야 합니다.

광범위한 브라우저 재생이 중요한 경우 H.264 MP4를 사용하세요. GIF는 매우 짧은 무음 루프에 유용하지만, 제한된 색상 팔레트와 약한 압축으로 인해 더 긴 증거에는 부적합한 기본값입니다. 리뷰어가 더 선명한 프레임을 필요로 할 수 있으므로 이슈가 닫힐 때까지 원본 녹화를 보존하세요.

제한 차이가 충분히 크기 때문에 팀은 하나의 숫자를 외우는 대신 목적지를 확인해야 합니다. GitHub는 무료 저장소에서 10MB, 유료 저장소에서 100MB의 영상 업로드를 문서화 하고 있으며, Jira Cloud는 파일당 기본값을 1GB로 설정하고 관리자가 값을 변경할 수 있습니다 . 실제 목표는 훨씬 더 작을 수 있습니다. 리뷰어는 성공적인 업로드보다 빠른 재생을 필요로 하기 때문입니다.

GetCompress가 버그 리포트 워크플로우에 적합한 경우

녹화기의 내보내기 제어는 가끔씩 사용하는 클립에는 충분하며, 이슈 추적기는 단계, 환경, 예상 동작을 위한 장소입니다. 개발자와 QA가 다른 추적기 제한을 위해 MOV, MP4, WebM, 스크린샷, GIF 증거를 반복적으로 준비할 때 GetCompress가 더 적합합니다. 목표 영상 크기, 재사용 가능한 프리셋, 일괄 처리 큐, 폴더 모니터링은 캡처가 로컬에 있는 동안 다시 내보내기 작업을 제거합니다. GetCompress와 화면 녹화기, 티켓, 승인된 삭제 프로세스의 역할은 다릅니다.