버그 리포트에 넣을 스크린샷 만들기
좋은 버그 스크린샷은 창 전체와 상태와 오류 문구를 함께 담습니다. 잘라 낸 캡처가 왜 개발자가 필요로 하던 그 한 가지를 잃는지, 그리고 공유 트래커에 올리기 전에 무엇을 가려야 하는지.
버그 리포트에 붙은 스크린샷은 대개 둘 중 하나입니다. 오류 문구만 딱 잘라 낸 작은 이미지이거나, 화면 전체를 찍었지만 어디를 봐야 하는지 표시가 없는 이미지. 앞의 것은 정보가 모자라고 뒤의 것은 정보가 너무 많습니다.
받는 사람이 필요로 하는 것은 정해져 있습니다. 무엇이 잘못됐는지, 어떤 상태에서 그랬는지, 그리고 다시 만들어 낼 수 있는지. 이 셋을 담고 나머지를 정리하면 대개 한 장으로 끝납니다.
한 장에 들어가야 하는 것
- 창 전체. 화면 크기, 열려 있던 탭, 사이드바 상태, 창 제목 — 재현 조건이 여기 들어 있습니다.
- 오류 문구 전체. 잘리지 않은 채로. 축약된 오류 문구는 검색이 되지 않습니다.
- 시각. 로그와 맞춰 보는 데 쓰입니다. 상단 표시줄이 찍혀 있으면 그것으로 충분합니다.
- 버전 정보. 앱 버전, 브라우저 버전, 운영체제. 캡처에 없다면 글로 적어 주세요.
- 그 순간의 상태. 어떤 항목이 선택되어 있었는지, 어떤 값이 입력되어 있었는지.
- 문제가 있는 곳을 가리키는 표시 하나. 없으면 받는 사람이 스무 초를 찾는 데 씁니다.
자를 때 사라지는 것
오류 문구만 잘라 낸 이미지는 “친절하게 정리한 것”처럼 보이지만 대개 정보를 지웁니다. 사라지는 것 중에 자주 결정적인 것들이 있습니다.
창의 폭입니다. 레이아웃이 깨지는 문제의 절반은 특정 폭에서만 나타나는데, 잘라 낸 이미지에는 원래 창이 얼마나 넓었는지가 남지 않습니다. 그리고 다른 화면 요소와의 관계입니다. 사이드바가 열려 있었는지, 알림이 떠 있었는지, 스크롤이 어디였는지가 원인인 경우가 실제로 많습니다.
그래서 순서는 이렇게 잡는 편이 낫습니다. 창 전체를 찍고, 문제 지점에 표시를 하나 놓고, 자르지 않고 그대로 보냅니다. 좁혀야 할 만큼 화면이 복잡하다면 두 장을 보내세요. 전체를 담은 한 장과, 문제 지점을 확대한 한 장.
또 하나 흔한 것. 화면을 휴대폰으로 찍은 사진입니다. 급할 때는 어쩔 수 없지만, 반사와 기울어짐과 화면 재생 줄무늬 때문에 글자가 잘 안 읽히고 색도 달라집니다. 색이 문제인 버그라면 이 사진은 증거로 쓸 수 없습니다. 캡처 기능을 쓸 수 있으면 쓰세요.
재현 단계에는 번호를
“여기 눌렀다가 저기서 저장하면 터집니다”를 화살표 세 개로 표현하면 받는 사람은 어느 것부터인지 알 수 없습니다. 순서를 실어 나를 수 있는 표시는 번호뿐입니다.
- 단계마다 화면이 바뀐다면 한 단계에 한 장씩 찍고, 번호는 장을 넘어가며 이어서 매깁니다.
- 같은 화면 안에서 여러 곳을 순서대로 다룬다면 한 장에 번호를 놓습니다. 다섯 개를 넘으면 나누세요.
- 이슈 본문에도 같은 번호로 문장을 씁니다. 이미지가 안 열리는 환경이 있고, 무엇보다 오류 문구를 텍스트로 함께 붙여야 검색됩니다.
- 중간 단계를 지웠다면 번호를 다시 매기세요. 1, 3, 4가 남아 있으면 받는 사람은 2번을 찾다가 시간을 씁니다.
Marka의 번호 표시는 이 마지막 항목을 도구가 처리합니다. 하나를 지우면 나머지가 스스로 다시 매겨지고, 기준은 놓은 순서라서 표시를 옮겼다고 순서가 뒤바뀌지 않습니다.
올리기 전에 가릴 것
이슈 트래커는 대체로 공유 공간입니다. 사내 전체가 볼 수 있거나, 프로젝트에 따라서는 외부에서도 볼 수 있습니다. 그리고 스크린샷은 티켓이 닫힌 뒤에도 몇 년씩 남습니다.
- 인증 토큰과 세션 값. 개발자 도구를 함께 찍었다면 헤더와 쿠키가 그대로 보입니다.
- 주소창의 접근 키나 서명이 붙은 링크. 그 링크 자체가 열쇠인 경우가 있습니다.
- 고객의 실제 데이터. 이름, 전화번호, 주소, 주문 내역. 사내 관리 화면 캡처가 가장 위험한 부류입니다.
- 내 계정 정보. 로그인한 이메일, 사번, 프로필 사진.
- 내부 서버 주소와 포트, 그리고 옆에 켜 둔 다른 창 — 사내 메신저나 메일이 같이 찍히는 일이 흔합니다.
주의할 점이 하나. 가리는 것과 지우는 것을 혼동하지 마세요. 재현에 필요한 정보를 가려 버리면 리포트가 쓸모없어집니다. 고객 이름을 통째로 덮는 대신 “고객 A”로 바꿔 쓰거나, 아이디는 가리되 형식은 남겨 두는 식이 낫습니다. 받는 쪽이 알아야 하는 것은 값 자체가 아니라 형식인 경우가 많습니다.
Marka로 만드는 흐름
맥에서라면 ⇧⌘4를 누른 뒤 스페이스바로 창을 통째로 찍고 — ⌃를 함께 누르면 파일 대신 클립보드로 갑니다 — Marka에 붙여넣습니다. m으로 가리기에 들어가 토큰과 고객 이름을 문지르고, n으로 재현 단계에 번호를 놓고, a로 문제 지점에 화살표를 하나 놓습니다. 그다음 클립보드로 복사해 이슈 본문에 그대로 붙이면 파일이 한 번도 만들어지지 않습니다. 도구 단축키는 맥 전용입니다.
가리기에서 방식을 고를 때 기준은 이 문서의 다른 글과 같습니다. 토큰이나 고객의 실제 번호처럼 새어 나가면 조치가 필요한 것에는 단색을, 이름이나 얼굴처럼 존재만 보여도 되는 것에는 모자이크를 쓰세요. 모자이크는 무료이고, 단색과 흐림, 그리고 화살표와 번호를 포함한 주석 도구는 Pro입니다.
맥에는 “민감 정보 찾기”가 하나 더 있어서, 보내기 직전에 이미지를 훑고 이메일 주소나 숫자열 같은 후보를 나열해 줍니다. 체크한 것만 가려집니다. 다만 두 번째 확인용입니다. 스스로 가리지 않고 반드시 놓칩니다. 이 기능은 맥 전용이고 Pro이며, 아이폰과 아이패드에는 없습니다. 그리고 Marka의 화면 표시 언어는 이 버전에서 중국어 간체입니다.
자주 묻는 질문
오류 문구를 스크린샷으로만 보내도 되나요?
권하지 않습니다. 이미지 안의 글자는 검색이 되지 않아서, 같은 오류를 다룬 예전 티켓이나 로그를 찾을 수 없습니다. 스크린샷은 상황을 보여 주는 용도로 붙이고, 오류 문구 자체는 텍스트로도 함께 붙여 주세요.
창 전체를 찍으면 개인정보가 너무 많이 찍히는데요?
그래서 자르기가 아니라 가리기를 쓰는 것입니다. 창 전체를 찍은 뒤 토큰과 고객 이름을 덮으면 재현에 필요한 조건 — 창 폭, 사이드바 상태, 열려 있던 탭 — 이 남습니다. 잘라 내면 그 조건들이 함께 사라집니다.
무엇을 가리고 무엇을 남겨야 하나요?
값은 가리고 형식은 남기세요. 개발자에게 필요한 것은 대개 “고객 아이디가 있었다”와 그 형태이지 실제 값이 아닙니다. 다만 재현에 값 자체가 필요한 경우 — 특정 문자열에서만 터지는 버그 — 라면 그 사실을 본문에 적고, 값은 안전한 경로로 따로 전달하세요.
화면을 휴대폰으로 찍은 사진을 붙여도 되나요?
캡처를 쓸 수 없는 상황이라면 없는 것보다 낫습니다. 다만 반사와 기울어짐과 화면 줄무늬 때문에 글자가 잘 안 읽히고 색이 달라지므로, 색이나 렌더링이 문제인 버그에는 증거가 되지 않습니다. 그리고 사진에는 주변 사물과 다른 사람이 함께 찍힙니다.
한 이슈에 스크린샷을 몇 장까지 붙이는 게 좋나요?
재현 단계마다 화면이 바뀐다면 단계 수만큼입니다. 그 외에는 두 장이 적당합니다. 전체 상황을 담은 한 장과 문제 지점을 확대한 한 장. 열 장을 붙이면 읽는 사람이 어느 것이 중요한지 판단하는 일까지 떠맡게 됩니다.
Marka로 해보기
Marka는 아이폰·아이패드·맥용 스크린샷 주석 앱입니다. 보이면 안 되는 곳을 문질러 모자이크하고, 봐야 할 곳에 화살표를 놓고, 단계에 번호를 매기고, 올릴 곳의 비율로 자른 뒤 보냅니다. 모든 처리는 기기 안에서 끝나고 업로드도 계정도 분석도 없으며 내려받기는 2.4 MB입니다. 이미지 열기, 자르기, 모자이크 브러시, 내보내기는 무료이고 Pro는 세 기기를 아우르는 한 번 구입입니다.