Article

Astro 블로그 디자인 QA 체크리스트

2026. 4. 30. 작성: 감성개발자

UI 시안 검수와 측정 과정을 표현한 기술 일러스트

디자인 시안대로 화면이 나왔는지, 배포한 뒤에는 누가 확인하나요? Astro 블로그를 올리고 나면 “코드는 맞는데 화면은 어딘가 기본값처럼 보인다”는 순간이 꼭 한 번은 옵니다. 점수는 멀쩡한데 눈으로 보면 뭔가 빠져 있는 상태 말입니다.

이 글은 그 간극을 줄이려고, 실제 배포 화면에서 무엇을 먼저 봐야 하는지 정리한 공개형 QA 체크리스트입니다. 저는 이걸 “홈 1회, 상세 1회, 모바일 1회”를 최소 단위로 묶어서 돌립니다. 홈과 상세, 모바일을 따로 떼어 보지 않으면 배포 후 누락은 거의 항상 새어 나가기 때문입니다.

한 가지는 먼저 못 박아 두겠습니다. 좋은 페이지 경험은 속도만의 문제가 아닙니다. Google은 Core Web Vitals만 보지 말고 모바일 표시, 과도한 광고 여부, 본문과 기타 요소의 구분까지 함께 확인하라고 안내합니다. 그래서 디자인 QA는 미관 점검이 아니라 검색 경험 점검에 더 가깝습니다. (출처: Google Search Central - Understanding page experience in Google Search results, web.dev - Web Vitals)

작성 관점

에이전시 시절 마감에 쫓겨 넘긴 사이트일수록, 점수는 멀쩡한데 화면이 어딘가 기본값처럼 보이는 경우가 많았습니다. 그 경험 이후로 저는 정적 사이트를 배포할 때 Lighthouse 점수보다 실제 렌더링 화면을 먼저 봅니다. CSS 번들 누락, 광고 슬롯 순서 꼬임, 모바일 카드 간격 붕괴처럼 사용자가 바로 체감하는 문제는 결국 화면 확인에서 가장 빨리 잡히기 때문입니다.

1. 홈 화면에서 먼저 확인할 것

홈에서는 아래 4가지를 한 번에 확인합니다.

레이아웃: Featured 카드와 글 목록이 분리되어 보이는지
타이포: 제목/요약/날짜의 크기와 대비가 기본 브라우저 스타일이 아닌지
네비게이션: 헤더 메뉴(홈, 개인정보처리방침)가 일관된 간격으로 보이는지
광고 슬롯: 상단 슬롯과 피드 슬롯 플레이스홀더가 구분되어 보이는지

핵심은 “HTML이 보이는가”가 아니라 의도한 정보 위계가 유지되는가입니다. Google은 사용자가 메인 콘텐츠와 다른 요소를 쉽게 구분할 수 있어야 하며, 광고가 본문을 방해하지 않아야 한다고 설명합니다. 홈 화면은 그 기준이 가장 먼저 드러나는 경로입니다. (출처: Google Search Central - Understanding page experience in Google Search results)

2. 상세 화면에서 확인할 것

넓은 화면에서는 본문 열 옆에 나란히 정렬돼 있던 사이드바 슬롯이, 좁은 화면으로 바뀌면 본문이 시작될 자리로 파고들어 본문 블록들을 아래로 밀어내고 맨 아래 블록이 화면 밖으로 잘려 사라지는 반응형 재배치 실패를, 두 기기 프레임 대비로 보여주는 도식.

상세 페이지에서는 본문 구조와 부가 요소 배치가 함께 깨지지 않았는지 확인합니다.

본문 카드(배경/테두리/패딩)가 적용되는지
본문 중간 광고 슬롯(In-article)이 표시되는지
하단 슬롯(Bottom)과 댓글 영역이 순서대로 노출되는지
데스크톱에서 사이드바 슬롯이 sticky로 동작하는지
모바일에서 사이드바 슬롯이 하단으로 재배치되는지

Core Web Vitals는 로딩, 상호작용, 시각적 안정성을 함께 봅니다. 현재 핵심 지표는 LCP, INP, CLS 세 가지이며, 각각이 실제 사용 경험을 대표합니다. 상세 페이지에서 레이아웃이 흔들리거나 광고 영역 때문에 본문이 밀리면 CLS와 체감 품질이 동시에 나빠질 수 있습니다. (출처: web.dev - Web Vitals)

반응형 전환은 스크린샷 1장으로는 거의 항상 놓칩니다. 데스크톱에서는 멀쩡한데 모바일에서 사이드바 슬롯이 본문을 밀어내는 문제를 여러 번 뒤늦게 발견한 뒤로, 저는 최소 데스크톱과 모바일 2개 뷰포트를 각각 확인하는 걸 원칙으로 둡니다.

3. 배포 품질 게이트 제안

디자인 반영 이슈를 줄이려면 배포 직후 아래 4개 게이트를 통과시키는 방식이 안전합니다.

URL 게이트: 홈 + 상세 URL의 상태코드 200 확인
시각 게이트: 홈/상세 핵심 카드와 광고 슬롯이 모두 보이는지 확인
콘텐츠 게이트: 샘플 slug, 테스트 제목, 임시 문구가 남아 있지 않은지 확인
기록 게이트: 커밋 SHA, 배포 시각(UTC/KST), 검증 결과를 이슈 코멘트에 남김

Astro는 정적 사이트를 로컬에서 빌드한 뒤 배포하는 흐름을 기본으로 안내하고, GitHub Pages 배포 시에는 site와 base 설정을 명확히 맞추라고 설명합니다. 배포 설정이 맞더라도 마지막 화면 검증이 없으면 CSS 또는 라우팅 누락이 그대로 운영에 올라갈 수 있습니다. (출처: Astro Docs - Deploy your Astro Site to GitHub Pages, GitHub Docs - What is GitHub Pages?)

4. 체크리스트를 실제 운영에 붙이는 방법

배포 자동화를 아무리 잘 짜도 마지막에 사람 눈으로 보는 최소 체크리스트는 남겨둡니다. 소규모 팀일수록 자동화에 다 맡기고 싶어지지만, 화면 품질 문제는 통과/실패로 딱 떨어지지 않아서 결국 한 번은 눈으로 봐야 잡힙니다. 저는 아래 순서로 끝냅니다.

단계	확인 질문	통과 기준
홈	첫 화면에서 이 블로그가 어떤 사이트인지 즉시 보이는가	제목, Featured, 카드 간격이 정상
상세	본문이 메인이고 광고가 보조라는 구조가 유지되는가	본문 카드 우선, 광고 간섭 없음
모바일	글 읽기 흐름이 깨지지 않는가	카드 폭, 여백, 댓글, 광고 순서 정상
기록	다시 확인할 근거가 남는가	커밋, 배포 시각, 결과 기록 완료

이 표까지 통과하면 그날 배포는 손을 떼도 됩니다. 자동화가 잡아주지 못하는 마지막 한 겹을, 사람 눈이 여기서 메웁니다. 저는 이 네 줄을 배포 이슈 템플릿에 그대로 넣어두고, 매번 체크하며 결과를 코멘트로 남깁니다. 다음에 같은 화면을 다시 의심하게 될 때, 그 기록이 가장 빠른 근거가 되기 때문입니다.