디자이너보다 클로드(Claude)에게 UI 검토를 맡기게 된 이유

아무도 이야기하고 싶어 하지 않는 디자인 QA 문제

개발자인 우리는 논리적 오류, 레이스 컨디션(race conditions), 메모리 누수(memory leaks)를 잡아내는 데는 탁월합니다. 하지만 버튼의 패딩이 16px가 아닌 14px인지, 혹은 파란색 계열의 색상이 브랜드와 약간 어긋나지는 않는지 찾아내라고 하면요? 우리는 눈이 멀어버립니다.

전통적으로 이 부분은 디자이너나 수동 검토를 하는 QA 팀에 맡겨졌습니다. 그들은 작업물을 스크린샷으로 찍고, Figma에서 주석을 달아 다시 보내줍니다. 반복되는 과정입니다. 느리고, 일관성이 없으며—솔직히 말해서—스프린트 세 번째쯤 되면 모두 지치고 문제가 빠져나가기 마련입니다.

저는 Claude의 Vision API를 사용하여 디자인 QA의 지루한 부분을 자동화하기 시작했고, 이것은 제가 일하는 방식을 진정으로 바꿔 놓았습니다. 인간의 판단을 대체해서가 아니라, 매번 신뢰성 있게 기계적인 부분들을 잡아내 주기 때문입니다.

비전 모델이 실제로 제공하는 것들

Claude(및 유사한 Vision 기능을 갖춘 LLM)는 스크린샷, 렌더링된 UI 상태 또는 디자인 내보내기 파일을 입력받아 자신이 보고 있는 것에 대해 추론할 수 있습니다. 다음과 같은 질문을 할 수 있습니다:

• "이 컴포넌트가 우리의 8px 그리드 시스템과 일치하나요?"
• "이 색상들이 우리 브랜드 팔레트에서 나온 건가요?"
• "대비 비율이 WCAG AA를 준수하나요?"
• "이 레이아웃이 첨부한 Figma 사양과 일치하나요?"

그러면 구조화되고 실행 가능한 피드백을 받게 됩니다. 모호한 디자이너의 말(designer-speak)이 아니라—실제 측정값, 구체적인 문제점, 제안된 수정 사항입니다.

Claude의 API를 사용한 기본적인 예시는 다음과 같습니다:

import anthropic
import base64

...

받게 되는 결과는 다음과 같습니다:

"발견된 문제: CTA 버튼에 가로 패딩이 12px입니다 (예상값 16px). 보조 텍스트 색상(#767676)은 흰색 배경과 대비 비율이 3.8:1로, WCAG AA를 충족하지 못합니다 (4.5:1 필요). 헤딩과 설명 사이의 수직 간격이 20px입니다 (8px 그리드에 맞춰야 함—16px 또는 24px 제안)."

이를 파이프라인에 임베딩하기

진정한 힘은 이것을 일회성 검사가 아니라 CI/CD 단계로 취급할 때 나옵니다. 저는 다음과 같은 간단한 GitHub Action을 구축했습니다:

1. Playwright를 실행하여 주요 페이지/컴포넌트의 스크린샷을 캡처하고
2. 이를 디자인 사양(design spec) 프롬프트와 함께 Claude에게 전송하며
3. 발견된 사항들을 PR 댓글로 게시하고
4. 심각한 문제(예: 대비 실패)가 발견되면 빌드를 실패시킵니다.

이러한 임계값(thresholds)을 설정할 수 있습니다. 예를 들어, 간격 불일치(spacing inconsistencies)는 경고로 처리하되, 접근성 위반(accessibility violations)은 병합을 차단하도록 할 수 있습니다. 이는 디자인 QA를 좌측으로 이동시켜(moves design QA left), 문제가 디자인팀이나 더 나쁜 경우 프로덕션에 도달하기 전에 포착하게 해줍니다.

작동하는 것과 그렇지 않은 것

Claude가 뛰어난 영역:

• 기계적 일관성 검사 (간격, 크기, 정렬)
• 접근성 감사 (대비, 계층 구조, 대체 텍스트(alt text) 존재 여부)
• 브랜드 가이드라인 준수 (색상 팔레트, 타이포그래피, 로고 사용)
• 구현된 결과물과 목업을 대규모로 비교

어려움을 겪는 영역:

• 주관적인 미적 판단(

광범위한 전략적 시사점에 관심이 있다면, [vision models]가 대규모로 디자인 문제를 포착하는 방법에 대한 좋은 글이 있습니다. 하지만 순수하게 엔지니어링 관점에서 볼 때 얻을 수 있는 교훈은 간단합니다. 이것은 이제 '있으면 좋은 기능(nice-to-have)'이 아니라 인프라라는 것입니다.

시작하기

1. 가치가 높은 컴포넌트 하나를 선택하세요 (예: 내비게이션 또는 카드 패턴)
2. '정확하다'는 것이 무엇인지 정의하는 구체적인 프롬프트를 작성하세요
3. 프롬프트를 조정하기 위해 수동으로 몇 번 실행해 보세요
4. 결과물을 신뢰하게 되면 CI(지속적 통합)에서 자동화하세요
5. 커버리지를 점진적으로 확장하세요

작게 시작하고, 가치를 증명한 다음, 규모를 키우세요. 다른 모든 툴링 결정과 마찬가지로요.

목표는 완벽함이 아니라—창피한 시각적 버그를 더 적게 배포하고 디자인 QA의 기계적인 부분에 쓰는 시간을 줄이는 것입니다. 매 스프린트마다 얻을 수 있는 승리입니다.