기술 튜토리얼 글에서 스크린샷은 보조 자료가 아니라 길 안내에 가깝습니다. 독자는 이미 많은 텍스트와 설정값, 버튼 이름, 작은 UI 차이를 동시에 읽고 있습니다. 이때 스크린샷이 잘 들어가 있으면 “아, 지금 이 화면에서 이 버튼을 찾으면 되는구나”가 바로 보이고, 잘못 들어가 있으면 오히려 더 헷갈립니다. 그래서 스크린샷은 많다고 좋은 것도 아니고, 선명하다고 좋은 것도 아닙니다. 독자가 지금 필요한 정보만 빠르게 찾을 수 있게 설계돼 있어야 합니다.
제가 튜토리얼 글을 읽을 때 가장 자주 지치는 경우는 대체로 비슷합니다. 전체 데스크톱 화면을 그대로 캡처해서 글자 크기가 너무 작거나, 어디를 봐야 할지 모르게 화살표를 여러 개 그려 넣었거나, 스크린샷은 있는데 그 앞뒤 설명과 연결이 안 되는 경우입니다. 반대로 정말 읽기 쉬운 튜토리얼은 한 장의 캡처가 “어디서, 무엇을, 왜 봐야 하는지”를 바로 알려줍니다.
이 글은 그런 차이를 만드는 규칙을 정리한 글입니다. 특별한 디자인 감각보다, 어떤 장면을 캡처해야 하고 어떤 장면은 오히려 빼야 하는지에 더 집중합니다. 스크린샷은 시각 자료이지만, 튜토리얼 안에서는 사실상 정보 설계의 일부이기 때문입니다.
기술 튜토리얼 글에서 스크린샷을 어디서, 얼마나, 어떤 방식으로 넣어야 독자가 헤매지 않는지 정리합니다. 크롭, 주석, 캡션, 순서, 모바일 대응까지 실제 편집 규칙 중심으로 설명합니다. 핵심 1 핵심 2 핵심 3기술 튜토리얼 글에 스크린샷을 넣을 때 가독성이 좋아지는 규칙
먼저 결론: 스크린샷은 “화면 전체 기록”이 아니라 “독자가 지금 찾아야 할 상태의 증거”여야 한다
모든 단계에 스크린샷을 넣지 말고, “상태가 바뀌는 지점”에만 넣는다
한 장의 스크린샷에는 한 가지 포인트만 담는 편이 좋다
먼저 결론: 스크린샷은 “화면 전체 기록”이 아니라 “독자가 지금 찾아야 할 상태의 증거”여야 한다
제 기준에서 좋은 튜토리얼 스크린샷은 아래 세 가지를 동시에 만족합니다.
- 지금 단계에서 꼭 봐야 하는 화면만 보여준다
- 어디를 보면 되는지 한눈에 알 수 있다
- 본문 설명과 순서가 정확히 맞아떨어진다
즉 스크린샷은 예쁘게 캡처하는 것보다, 독자가 다음 행동을 결정할 수 있게 만드는 것이 더 중요합니다.
1. 모든 단계에 스크린샷을 넣지 말고, “상태가 바뀌는 지점”에만 넣는다
가장 먼저 잡아야 하는 원칙은 이겁니다. 튜토리얼에는 스크린샷이 많을수록 좋지 않습니다. 오히려 정말 필요한 순간에만 넣어야 합니다.
제가 보통 스크린샷을 넣는 지점은 아래와 같습니다.
- 설정 화면이 처음 등장할 때
- 버튼 위치를 찾기 어려울 때
- 성공/실패 상태를 구분해야 할 때
- 텍스트만으로 설명하면 독자가 쉽게 놓칠 때
- 한 번 보면 구조를 바로 이해할 수 있는 UI일 때
반대로 잘 안 넣는 경우도 있습니다.
- 단순한 한 줄 명령어 입력
- 버튼 이름만으로 충분히 찾을 수 있는 경우
- 코드 블록이 더 정확한 경우
- 바로 다음 화면에서 더 중요한 변화가 있는 경우
즉 스크린샷은 “이 단계에 그림이 있으면 보기 좋다”가 아니라 “그림이 없으면 독자가 헤맬 가능성이 높다”일 때 넣는 편이 좋습니다.
2. 한 장의 스크린샷에는 한 가지 포인트만 담는 편이 좋다
가독성이 떨어지는 튜토리얼 캡처의 공통점은 한 화면에 너무 많은 의도를 담으려 한다는 점입니다. 버튼도 보여주고, 탭도 보여주고, 결과 표도 보여주고, 경고 메시지도 보여주려다 보면 결국 아무 것도 제대로 안 보이게 됩니다.
그래서 저는 한 장당 포인트를 하나만 정합니다.
- 이 장은 버튼 위치를 보여주는 장
- 이 장은 입력 필드를 보여주는 장
- 이 장은 성공 상태를 보여주는 장
- 이 장은 에러 메시지를 구분하는 장
한 장에 포인트를 하나로 줄이면 크롭도 쉬워지고, 캡션도 짧아지고, 본문과의 연결도 좋아집니다.
3. 전체 화면을 그대로 쓰지 말고, 대부분은 과감하게 잘라야 한다
스크린샷 가독성을 망치는 가장 흔한 원인은 “화면을 너무 넓게 보여주는 것”입니다. 브라우저 전체, 운영체제 메뉴바, 탭 12개, 좌측 사이드바, 우측 광고 패널까지 다 들어가면 정작 독자가 봐야 할 UI는 너무 작아집니다.
좋은 튜토리얼 캡처는 대개 이렇게 자릅니다.
- 지금 단계와 무관한 바깥 영역 제거
- 브라우저 탭 여러 개 제거
- 좌우 빈 여백 제거
- 불필요한 메뉴나 사이드바 제거
- 필요한 패널 또는 모달만 남기기
예를 들어 Search Console 화면을 설명한다면, 사이트 전체 화면보다 “왼쪽 메뉴 + 중앙 결과 패널 + 지금 봐야 하는 카드” 정도만 남기는 편이 더 좋습니다.
화면을 자르는 기준은 단순합니다. 이 요소가 없으면 독자가 길을 잃는가? 아니라면 자르는 편이 낫습니다.
4. 번호와 짧은 주석은 효과적이지만, 장식처럼 많이 쓰면 오히려 더 산만해진다
주석은 스크린샷을 읽기 쉽게 만들어 주는 가장 강한 도구 중 하나입니다. 하지만 동시에 가장 쉽게 과해지는 도구이기도 합니다. 빨간 화살표 네 개, 네온 박스 두 개, 밑줄 세 개를 한 장에 같이 넣으면 독자는 더 빨리 피곤해집니다.
제가 가장 자주 쓰는 방식은 이겁니다.
- 번호 원형 1~3개
- 한 가지 강조 색
- 꼭 필요한 짧은 레이블만
예를 들면:
1DNS TXT 레코드 복사2저장 버튼 클릭3검증 결과 확인
이 정도면 충분한 경우가 많습니다. 주석의 목적은 화면을 디자인하는 게 아니라 시선을 안내하는 것입니다.
5. 본문 단계와 스크린샷 순서가 정확히 맞아야 한다
의외로 자주 생기는 문제인데, 스크린샷은 맞는데 글 순서와 안 맞는 경우가 많습니다. 본문은 “먼저 A를 누른 뒤 B를 확인하세요”라고 되어 있는데, 스크린샷은 이미 B가 선택된 뒤 상태를 보여주고 있으면 독자가 혼란스러워집니다.
그래서 저는 스크린샷을 넣을 때 항상 아래를 맞춥니다.
- 본문의 단계 번호
- 스크린샷 안 번호
- 캡션 설명
예를 들면 본문이 이렇게 갑니다.
Settings메뉴로 이동합니다.Ownership verification을 엽니다.- DNS TXT 값을 복사합니다.
그러면 스크린샷도 이 흐름을 보여줘야 합니다. 최소한 캡션은 이렇게 맞는 편이 좋습니다.
스크린샷이 먼저 있고 본문이 나중에 따라가면, 이미지가 아니라 퍼즐이 됩니다.
6. 스크린샷은 코드 대체물이 아니다
기술 글에서 정말 자주 보이는 실수입니다. 코드나 명령어를 스크린샷으로 넣는 경우입니다. 이건 거의 항상 가독성을 떨어뜨립니다.
코드, 명령어, 설정값은 가능한 한 텍스트로 넣는 편이 맞습니다.
나쁜 예
- 터미널 명령어를 화면 캡처로 넣음
.env파일 내용을 스크린샷으로 보여줌- JSON 설정을 작은 캡처로 넣음
좋은 예
npm.cmd run build
npx.cmd serve out
스크린샷은 코드 자체를 보여주는 데 쓰기보다, 그 코드가 실행된 결과나 위치를 보여주는 데 쓰는 편이 좋습니다.
예를 들면:
- 코드: 텍스트 블록
- 결과 화면: 스크린샷
이 조합이 가장 읽기 쉽습니다.
7. 캡션은 “이 이미지가 뭔지”보다 “왜 지금 봐야 하는지”를 말해야 한다
좋지 않은 캡션은 보통 이런 식입니다.
- 설정 화면
- 콘솔 결과
- 관리자 페이지
이건 이미지가 무엇인지도 애매하고, 왜 중요한지도 알려주지 못합니다.
좋은 캡션은 보통 이렇게 씁니다.
- DNS TXT 값을 복사해야 하는 위치
Ownership verified가 보여야 다음 단계로 넘어갈 수 있는 상태- 잘못된 canonical 경로가 출력되는 예시
즉 캡션은 “무엇을 보고 어떤 판단을 해야 하는지”를 짧게 알려줘야 합니다.
이 레포의 마크다운 렌더링도 이미지 title이나 alt를 자동으로 캡션으로 보여주기 때문에, 한 줄 설명을 의식해서 쓰면 글 전체 가독성이 훨씬 좋아집니다.
8. 모바일과 좁은 화면에서도 읽히는지 한 번은 꼭 봐야 한다
스크린샷은 데스크톱에서 괜찮아 보여도 모바일에서 급격히 읽기 어려워질 수 있습니다. 특히 이런 경우가 많습니다.
- 너무 넓은 화면을 한 장으로 넣음
- 글자 크기가 작은 UI를 그대로 캡처함
- 좌우 정보가 많은 테이블 화면을 축소함
- 다크모드/라이트모드가 섞여 대비가 깨짐
이럴 때는 보통 두 가지 중 하나를 택하는 편이 좋습니다.
- 전체 화면 대신 필요한 부분만 크롭
- 한 장을 두 장으로 나눠 순서대로 보여주기
모바일에서 읽히는지를 확인하는 기준은 단순합니다. 확대하지 않고도 “지금 봐야 할 요소”를 찾을 수 있는가입니다.
9. 다크모드와 라이트모드 캡처를 섞을 때는 의도를 분명히 해야 한다
튜토리얼 글에서 의외로 가독성을 해치는 요소가 화면 테마 혼합입니다. 어떤 장면은 다크모드, 어떤 장면은 라이트모드, 어떤 장면은 브라우저 확대 110%, 어떤 장면은 기본 배율이면 글 전체가 산만하게 느껴집니다.
가능하면 한 글 안에서는 아래를 맞추는 편이 좋습니다.
- 같은 테마
- 같은 배율
- 같은 브라우저 크기
- 같은 강조 색
예외가 있다면 그 자체가 설명 포인트일 때뿐입니다. 예를 들어 “다크모드에서만 이 버튼이 오른쪽에 있습니다” 같은 경우가 아니라면, 일관성이 훨씬 중요합니다.
10. 파일명과 순서를 정리해 두면 나중에 수정이 훨씬 쉬워진다
이건 쓰는 순간보다 나중에 더 크게 차이 납니다. 스크린샷 파일명이 image1.png, final-final2.png, capture-last.png 같은 식이면, 글을 고칠 때 어디가 어느 단계인지 금방 헷갈립니다.
저는 보통 이런 규칙을 씁니다.
01-search-console-overview.png
02-search-console-verification.png
03-search-console-success-state.png
혹은 폴더 기준으로도 이렇게 둡니다.
public/articles/tutorial-screenshot-rules/
01-bad-example.png
02-good-example.png
03-crop-example.png
이 규칙은 이미지 교체, 본문 순서 수정, 압축본 재생성 때 아주 유용합니다.
11. alt text도 “장식 묘사”보다 화면에서 중요한 정보가 무엇인지 써야 한다
스크린샷의 alt text는 종종 비워 두거나, “스크린샷” 같은 말로 끝내기 쉽습니다. 하지만 기술 튜토리얼에서는 alt text도 꽤 중요합니다. 이미지가 안 보이는 상황에서도 어떤 화면에서 무엇을 확인해야 하는지 전달할 수 있기 때문입니다.
좋은 alt text 예시는 보통 이런 식입니다.
- Search Console 소유권 확인 화면에서 DNS TXT 값을 복사해야 하는 영역
- Vercel 도메인 설정 화면에서
www리다이렉트를 활성화한 상태 - 메타태그 미리보기 도구에서 Open Graph 이미지가 누락된 예시
즉 alt text는 “이건 스크린샷이다”가 아니라, “이 스크린샷에서 무엇이 중요한가”를 써야 합니다.
12. 제가 실제로 쓰는 스크린샷 편집 체크리스트
튜토리얼 글에 이미지를 넣기 전 저는 보통 아래를 봅니다.
- 이 장면이 정말 스크린샷이 필요한가
- 한 장에 포인트가 하나만 남았는가
- 불필요한 주변 UI를 잘랐는가
- 번호나 주석이 과하지 않은가
- 본문 단계 순서와 정확히 맞는가
- 캡션이 “왜 봐야 하는지”를 설명하는가
- 코드를 스크린샷으로 대체하고 있지 않은가
- 모바일 폭에서도 중요한 요소가 읽히는가
- 파일명과 alt text가 정리돼 있는가
이 체크리스트만 지켜도 스크린샷은 장식에서 길 안내로 바뀝니다.
마무리
기술 튜토리얼 글에서 스크린샷의 역할은 단순한 시각 보강이 아닙니다. 독자가 “지금 어떤 화면에서 무엇을 찾고, 어떤 상태를 확인해야 하는지”를 빠르게 이해하게 만드는 정보 설계 도구에 가깝습니다. 그래서 좋은 스크린샷은 선명한 화면 자체보다, 적절한 크롭, 하나의 포인트, 정확한 순서, 짧고 분명한 캡션을 갖고 있습니다.
제 기준에서는 스크린샷을 잘 넣는 글이 결국 더 사람 중심적인 기술 글입니다. 본문만으로는 헤맬 수 있는 지점을 정확히 보강하고, 코드는 코드답게 텍스트로 유지하고, 이미지는 결과와 위치를 설명하는 데 집중하기 때문입니다. 다음 단계에서는 이런 화면 자료와 자주 나란히 놓이게 되는 코드 블록 자체를 어떻게 읽기 쉽게 정리할지로 이어갈 수 있습니다.