{3줄 요약}

Design QA는 디자인이 실제 제품에 의도대로 구현됐는지 확인하는 과정으로, 디자인 전달이 끝이라고 보지 않아요.
디자인과 구현 사이에 생기는 간격을 찾아 줄이는 게 Design QA의 역할이에요.
개발이 끝난 뒤만이 아니라 진행 중에 함께 보면 수정 비용을 훨씬 줄일 수 있어요.

이 방법을 쓰는 맥락

새 기능 개발이 완료됐을 때, 또는 개발 중간 단계에서 디자인과 구현이 맞는지 확인할 때 써요.

Design QA가 없으면 이런 일이 생겨요:

  • 버튼 색상이 디자인에서 #1A73E8인데 구현에서 #1976D2로 나와요 (비슷해 보이지만 달라요)
  • 간격이 16px이어야 하는데 15px로 구현됐어요 (사소해 보이지만 전체 리듬이 깨져요)
  • 에러 상태가 디자인에는 있는데 구현에는 없어요 (다음에 하기로 했는데 출시됐어요)
  • 애니메이션 타이밍이 200ms여야 하는데 400ms로 구현됐어요 (느리게 느껴져요)

개별 오류는 작아 보여도, 쌓이면 제품이 "뭔가 어수선하다"는 인상을 줘요.

단계별 실행 방법

1단계 — QA 기준 목록 미리 정하기

무엇을 확인할지 목록을 미리 만들어요.
매번 생각나는 것만 보면 빠지는 것이 생겨요.

시각 항목:

  • 색상이 Design Token 값과 일치하는가
  • 텍스트 크기, 굵기, 행간이 Typography Scale과 일치하는가
  • 간격(패딩, 마진)이 Space Token과 일치하는가
  • 모서리 반경이 정의된 값인가
  • 아이콘 크기와 색이 맞는가

인터랙션 항목:

  • 버튼 클릭 시 피드백(hover, active 상태)이 있는가
  • 애니메이션 타이밍이 명세와 같은가
  • 모달이 정확한 Elevation으로 나타나는가
  • 스크롤 동작이 자연스러운가

상태 항목:

  • 빈 상태가 구현됐는가
  • 로딩 상태가 있는가
  • 에러 상태가 구현됐는가
  • 비활성(Disabled) 상태가 맞는가

반응형 항목:

  • 모바일 크기에서 레이아웃이 유지되는가
  • 테블릿 크기에서 깨지는 부분이 없는가
  • 다양한 기기에서 폰트 크기가 정상인가

접근성 항목:

  • 색 대비가 WCAG 기준(4.5:1)을 만족하는가
  • 이미지에 alt 텍스트가 있는가
  • 키보드 Tab 순서가 자연스러운가

2단계 — 레이어별 비교하기

Figma 디자인 파일과 구현된 화면을 나란히 놓고 비교해요.

실용적인 방법들:

  • 픽셀 비교: Figma에서 캡처한 이미지와 실제 화면 캡처를 Figma에 겹쳐서 차이를 봐요
  • 브라우저 개발자 도구: CSS 값을 직접 확인해서 디자인 명세와 대조해요
  • Figma의 Compare 기능 또는 Storybook: 컴포넌트 상태를 체계적으로 비교해요

3단계 — 발견한 이슈 구조화하여 공유하기

발견한 이슈를 "여기 이상해요"가 아니라 구조화해서 전달해야 개발자가 정확히 수정할 수 있어요.

이슈 전달 형식:

  • 위치: 어느 화면, 어느 컴포넌트
  • 현재 상태: 지금 어떻게 구현됐는가 (스크린샷 포함)
  • 기대 상태: 어떻게 돼야 하는가 (디자인 파일 링크 또는 스크린샷)
  • 수치: 구체적인 값 차이 (16px → 12px이라면 명시)
  • 우선순위: 이것이 출시를 막는 수준인가, 다음에 해도 되는가

Jira, Linear, Notion 같은 도구로 이슈를 트래킹해요.

4단계 — 수정 후 재확인하기

수정 요청을 했으면 수정 후 다시 확인해야 해요. "됐겠지"라고 넘어가면 같은 문제가 출시돼요.

중요한 이슈일수록 재확인이 필요해요.
특히 다크 모드, 다양한 화면 크기, 에러 상태 같은 엣지 케이스는 수정 후에도 다른 곳에서 비슷한 문제가 생길 수 있어요.

Design Handoff가 QA 비용을 줄여요

QA에서 많은 이슈가 발견된다면, 그 전 단계인 Handoff(디자인 전달)가 불명확했기 때문이에요.

좋은 Handoff:

  • 모든 컴포넌트가 Design System에서 왔고 토큰이 지정됐어요
  • 모든 상태(hover, active, error, empty, loading)가 디자인됐어요
  • 반응형 동작 방식이 명시됐어요
  • 접근성 주의사항이 메모됐어요

Handoff가 좋으면 QA에서 발견되는 이슈가 줄어요.
QA는 Handoff의 수준을 측정하는 거울이기도 해요.

하지 말아야 할 것

"내 눈에 비슷해 보이면 됐다"고 넘어가지 마세요: 색상이나 간격 1~2px 차이도 Design System 일관성을 깨요.
작은 불일치가 쌓이면 큰 혼란이 돼요.

개발이 완료된 후에만 QA를 하지 마세요: 중간 중간 확인하면 수정이 작아요.
출시 직전에 몰아서 하면 큰 이슈가 나와도 시간이 없어요.

이슈를 구두로만 전달하지 마세요: 스크린샷과 수치 없이 "여기 좀 이상해요"라고 하면 무엇이 문제인지 개발자가 파악하기 어려워요.

실행 후 확인하기

  • 시각, 인터랙션, 상태, 반응형, 접근성 항목이 모두 체크됐나요?
  • 이슈가 위치·현재·기대·수치·우선순위로 구조화됐나요?
  • 수정 후 재확인했나요?
  • 이번 QA에서 자주 나온 패턴을 Handoff 과정 개선에 반영했나요?

관련 아티클

참고 문헌

  • Design Leadership Handbook (2019) - 디자인 품질 관리와 팀 프로세스의 핵심 원칙이에요.