디자인 QA 체크리스트 — 구현 검수에서 봐야 할 것

디자인 QA는 화면을 다 만들고 개발자에게 넘기면 끝나는 일이 아닙니다. 실제로 배포된 화면을 열어보면 간격이 2px씩 어긋나 있거나 모바일에서 버튼이 잘리는 경우가 심심치 않게 나옵니다. QA는 이런 차이를 출시 전에 잡아내는 마지막 관문입니다. 디자이너가 QA를 개발자의 몫으로 미뤄두면, 정작 의도했던 디테일은 사용자에게 닿기도 전에 사라지고 맙니다.

1. 미적 판단이 아니라 비교 작업

QA 단계에서 디자이너가 해야 할 일은 취향을 말하는 것이 아니라, 디자인 파일과 실제 구현 화면을 나란히 놓고 차이를 찾는 것입니다. 간격, 폰트 크기, 줄 간격, 색상값처럼 숫자로 확인 가능한 항목부터 먼저 점검하고, 그다음에 인터랙션과 애니메이션처럼 시간이 걸리는 항목을 봅니다. 순서를 바꿔서 인터랙션부터 보면 정작 기본적인 스타일 차이를 놓치기 쉽습니다.

화면 상태별로 빠짐없이 확인하기

QA에서 가장 자주 놓치는 것은 기본 상태 이외의 화면입니다. 데이터가 없을 때 나오는 빈 상태, 로딩 중 상태, 에러 상태, 긴 텍스트가 들어왔을 때의 줄바꿈, 목록이 한 개도 없거나 아주 많을 때의 레이아웃까지 모두 확인해야 합니다. 디자인 파일에는 대표 상태 하나만 그려져 있는 경우가 많기 때문에, QA 단계에서는 디자이너가 직접 실제 데이터를 넣어보며 예외 상태를 만들어보는 것이 중요합니다.

2. 반응형과 리포트도 QA의 일부

데스크톱에서만 확인하고 통과시키면 모바일이나 태블릿에서 컴포넌트가 깨지는 경우를 놓칩니다. 오토레이아웃으로 설계한 화면이라면 실제 브라우저나 앱에서 창 크기를 줄여가며 텍스트가 넘치거나 버튼이 겹치는 지점을 찾아야 합니다. 특히 텍스트 콘텐츠가 짧은 한국어와 길어지는 영어나 다른 언어가 함께 쓰이는 서비스라면, 다국어 상태에서의 줄바꿈도 QA 항목에 포함해야 합니다.

차이를 발견했다고 끝이 아닙니다. 어떤 화면에서, 어떤 상태에서, 디자인 값과 구현 값이 각각 얼마인지 구체적으로 남겨야 개발자가 빠르게 수정할 수 있습니다. 스크린샷만 던지고 “이거 다르네요”라고 말하는 리포트는 다시 확인하는 시간을 늘릴 뿐입니다.

QA에서 확인할 스펙의 품질은 결국 그 전 단계인 핸드오프에서 결정됩니다. 핸드오프를 어떻게 준비해야 하는지는 디자인 핸드오프 잘하는 법에서 정리했습니다. 컴포넌트 단위로 상태를 빠짐없이 정의해두면 QA에서 놓치는 예외 상태도 줄어드는데, 자세한 내용은 피그마 컴포넌트 제대로 만들기를 참고하세요. 디자인과 구현을 비교하는 기능은 피그마 공식 Dev Mode 가이드에서 확인할 수 있습니다.

3. QA를 미루면 비용이 뒤로 쌓이는 이유

QA를 출시 직전으로 미루는 팀일수록 문제를 늦게 발견한다. 디자인 초기 단계에서는 간격 2px, 색상 한 톤 차이가 사소해 보이지만, 이미 배포된 뒤에 발견하면 코드 수정과 재배포, 재검수까지 다시 거쳐야 한다. 같은 문제라도 발견 시점이 늦어질수록 고치는 데 드는 손이 늘어난다는 점에서, QA는 마지막 관문이 아니라 스프린트 중간중간에 끼워 넣어야 하는 습관에 가깝다.

흔한 오해 하나는 QA를 “디자이너의 완벽주의”로 여기는 것이다. 실제로 QA가 잡아내는 문제는 미적 취향이 아니라, 사용자가 실제로 마주치는 버튼이 잘리거나 텍스트가 넘치는 구체적인 결함이다. QA를 취향의 문제로 축소하면, 정작 사용성에 영향을 주는 차이를 검수 우선순위에서 뒤로 미루게 된다.

4. 마치며

디자인 QA는 출시 직전에 급하게 하는 일이 아니라, 매 스프린트마다 반복되는 습관으로 만들어야 효과가 있습니다.