블로그

코드 리뷰와 풀 리퀘스트에 스크린샷 활용하기

게시 2026년 10월 25일 · 코드 리뷰, 풀 리퀘스트, 스크린샷, 워크플로

UI 변경은 diff만으로 검토하기 어렵습니다. 전후 비교, 주석, 핵심 상태를 담은 작은 스크린샷 세트면 풀 리퀘스트를 검토하기 쉬워집니다.

버튼 동작, 폼 유효성 검사, 로딩 상태를 바꾸는 풀 리퀘스트는 diff만으로 판단하기 어렵습니다. 리뷰어는 결국 브랜치를 체크아웃하고 다시 빌드한 뒤, 말한 화면을 찾아 헤매게 됩니다. 작고 잘 만든 스크린샷 세트가 그 수고를 없애 줍니다.

전후 캡처하기

눈에 보이는 변경이라면 같은 화면을 두 번 캡처하세요.

1. 기본 브랜치에서 영향을 받는 영역을 캡처합니다.
2. 내 브랜치에서 같은 창 크기와 배율로 동일한 영역을 캡처합니다.
3. 두 캡처를 모두 보관합니다. 한쪽만 더 촘촘히 자르지 마세요.

뷰포트, 브라우저 배율, 창 크기를 맞춰야 비교가 의미를 갖습니다. 반응형 레이아웃이라면 중요한 너비(예: 1280과 390)를 캡처하고 라벨을 붙이세요.

차이만 주석 달기

리뷰어에게 필요한 것은 어디를 봐야 하는지이지, 전체 투어가 아닙니다.

• 한 스크린샷에 여러 변경이 있을 때 번호: 1은 새 빈 상태, 2는 오류 메시지.
• 변경된 영역을 표시하는 도형.
• 기대 동작을 짧게 적은 텍스트.
• 고객 이름, 이메일, 토큰, 내부 URL처럼 비공개인 것은 모자이크 또는 흐림 효과.

화면 전체에 주석을 달지 마세요. 변경이 컨트롤 하나라면 화살표 하나와 문장 하나로 충분합니다.

정지 화면으로 부족할 때 상호작용 녹화하기

어떤 변경은 움직임 속에서만 이해됩니다. 예전에 너무 일찍 닫히던 드롭다운, 이제는 끝나는 스피너, 드래그 상호작용 같은 것들입니다. 빠른 녹화로 10~20초를 녹화한 뒤 MP4를 첨부하거나, 리뷰에 바로 보이길 원하면 GIF(Pro)를 쓰세요.

• 가능하면 한 클립 안에서 문제 동작을 먼저, 수정된 동작을 다음에 보여 주세요.
• 나레이션이 뭔가를 더하지 않는다면 마이크를 끄세요. 무음 클립은 자동 재생해도 안전합니다.
• 두 번 볼 수 있을 만큼 짧게 유지하세요.

증거를 풀 리퀘스트에 넣기

예측 가능한 구조는 리뷰어의 시간을 아껴 줍니다.

1. 무엇이 바뀌었는지 한 문장으로.
2. 전 / 후 이미지를 나란히 또는 항상 같은 순서로 위아래로.
3. 스크린샷의 상태가 기본 화면이 아니라면 재현 방법.
4. 확인할 것 — 회귀할 수 있는 한두 가지.
5. 중요하다면 환경: OS, 브라우저, 디스플레이 배율.

개인 드라이브 링크 대신 이미지를 풀 리퀘스트에 직접 첨부하세요. 공유 링크를 쓴다면 만료되거나 비밀번호가 필요할 수 있음을 기억하세요. 코드 리뷰에는 보통 첨부가 더 낫습니다.

세트는 작게 유지하기

리뷰어는 훑어봅니다. 집중된 스크린샷 세 장은 읽히지만, 열다섯 장은 그냥 지나쳐집니다.

• 눈에 보이는 변경마다 한 쌍.
• 브라우저 크롬과 무관한 패널은 잘라내세요.
• 맥락용으로만 넣는 이미지는 압축하거나 크기를 줄이고, 픽셀 수준 변경은 원본 해상도를 유지하세요.
• 같은 상태를 약간 다른 각도에서 반복한 스크린샷은 삭제하세요.

제출 전 체크리스트

자주 묻는 질문

스크린샷을 첨부해야 하나요, 화면 녹화를 첨부해야 하나요?

상태에는 정지 이미지, 상호작용에는 짧은 클립입니다. 10~20초 녹화면 전환을 보여 주기에 충분하며, 그보다 길면 보통 건너뛰게 됩니다.

리뷰용 스크린샷에서 고객 데이터를 어떻게 가리나요?

이름과 ID에는 강한 설정의 모자이크를, 비밀에는 불투명한 가림을 쓰거나 해당 영역을 잘라내세요. 흐림 효과는 모자이크보다 약하므로 민감한 것에는 쓰지 마세요.

리뷰용 스크린샷을 만들려면 Pro가 필요한가요?

캡처, 주석, 번호, 모자이크, 기본 MP4 녹화에는 필요 없습니다. GIF 내보내기, 스마트 지우개, 동영상 편집기의 효과는 Pro 기능이지만, 정지 이미지 세트와 MP4만으로도 대부분의 리뷰를 무료로 커버할 수 있습니다.

블로그의 다른 글