부록 B. Claude Design + Claude Code 통합 체크리스트

좋은 시안이 구현 단계에서 무너지는 이유는 대개 디자인이 나빠서가 아닙니다. 더 자주 벌어지는 문제는 따로 있습니다. 누가 봐도 멋진 화면인데, 정작 개발에 들어가면 상태가 빠지고, 컴포넌트 이름이 뒤섞이고, 카피 최신본이 사라지고, 모바일 우선순위가 흔들립니다. 그러면 결과물은 "비슷한데 어딘가 아쉬운 제품"이 됩니다.

Claude Design과 Claude Code를 함께 쓰는 가장 큰 장점은 바로 이 틈을 줄여 준다는 점입니다. Claude Design은 팀의 디자인 시스템을 읽어 시안을 만들고, 준비된 결과를 핸드오프 번들로 묶어 Claude Code로 넘길 수 있습니다.¹ 여기에 코드베이스까지 연결되어 있으면 Claude가 실제 컴포넌트와 스타일 패턴을 더 잘 이해하므로, 시안과 구현의 거리가 훨씬 짧아집니다.²

하지만 도구가 좋아도 체크리스트가 없으면 놓치는 건 여전히 생깁니다. 아래 항목은 "디자인 생성 → 핸드오프 → 구현 → QA" 흐름 전체에서 빠뜨리기 쉬운 지점을 막기 위한 실전 점검표입니다. 구현 직전에 허둥대지 않으려면, 예쁜 화면보다 먼저 이 체크리스트를 통과시키는 편이 훨씬 이득입니다.

1. 시작 전에 확인할 것

처음부터 방향을 제대로 잡지 않으면, 나중에 고치는 비용이 눈덩이처럼 불어납니다. 그래서 첫 프롬프트를 넣기 전에 다음 항목부터 정리하는 것이 좋습니다.

• 이번 작업의 목표가 한 문장으로 설명된다. 예: "기존 무료 사용자가 3분 안에 유료 플랜 업그레이드를 완료하게 한다."

• 누가 이 화면을 쓰는지 분명하다. 창업자용인지, 운영자용인지, 일반 소비자용인지가 흐리면 화면도 흐려진다.

• 성공 기준이 있다. 예: 첫 화면에서 핵심 행동이 10초 안에 보여야 한다, 모바일에서 CTA가 첫 스크롤 안에 있어야 한다.

• 이번에 만들 산출물의 종류가 정해졌다. 와이어프레임인지, 하이파이 시안인지, 인터랙티브 프로토타입인지, 실제 핸드오프용 화면인지 먼저 정한다.

• 참고 자료를 모았다. 현재 제품 스크린샷, 경쟁 서비스 예시, 브랜드 가이드, 실제 카피, 정책 문구, 이미지 에셋이 여기에 포함된다.

• 접근성·반응형·법무 제약을 적어 두었다. 명암 대비, 키보드 조작, 모바일 브레이크포인트, 금지 표현, 지역별 문구 차이 같은 항목이 대표적이다.

• 구현 대상 저장소 범위를 정했다. 모노레포 전체를 무턱대고 연결하지 말고, 관련 프런트엔드 패키지나 디자인 시스템 폴더처럼 필요한 범위만 연결한다.²

이 단계에서 가장 위험한 문장은 "일단 한번 예쁘게 뽑아 보자"입니다. 초반에는 그 말이 가볍게 들리지만, 구현 단계에서는 "이걸 대체 뭘 기준으로 만들죠?"라는 질문으로 돌아옵니다.

2. Claude Design에서 첫 시안을 만들 때

첫 시안은 완성본이 아니라 방향을 잡는 지도입니다. 그렇다고 대충 만들어도 된다는 뜻은 아닙니다. 오히려 처음부터 실제 제품에 가까운 정보를 넣을수록, 이후 수정 횟수가 크게 줄어듭니다.

• 프롬프트에 사용자, 목표, 화면 종류, 제약 조건이 모두 들어갔다.

• "더 세련되게" 같은 추상 표현보다 "운영자가 지연된 워크플로를 10초 안에 찾게 해 달라"처럼 판단 가능한 문장으로 요청했다.

• 가능한 한 실제 카피를 넣었다. 로렘 입숨은 보기에는 깔끔하지만, 구현 단계에서 길이 문제를 늦게 터뜨린다.

• 처음부터 필요한 화면 상태를 함께 요구했다. 정상 상태만 만들고 끝내면, 나중에 로딩·빈 상태·오류 상태가 우수수 빠진다.

• 데스크톱만 보지 않았다. 최소한 좁은 태블릿이나 모바일 우선순위까지 함께 확인했다.

• 중요한 인터랙션은 말로만 남기지 않았다. 드로어가 열리는지, 탭이 전환되는지, 승인 버튼 뒤에 어떤 피드백이 나오는지까지 확인했다.

• 같은 목적의 대안 시안을 2~3개 비교해 봤다. Claude Design은 여러 방향을 빠르게 비교하는 데 강하므로, 초반에는 하나에 올인하기보다 후보를 나란히 놓는 편이 좋다.²

여기서 기억할 점은 간단합니다. "보여 주는 화면"만 만들지 말고 "작동할 화면"을 만들어야 한다는 것입니다.

3. 디자인 시스템과 코드베이스를 연결할 때

이 단계가 부실하면 시안은 멋진데 구현은 늘 새로 시작하게 됩니다. 반대로 이 단계가 탄탄하면, 시안이 곧 구현 가이드가 됩니다.

• 연결한 코드베이스가 현재 살아 있는 진짜 코드다. 옛날 브랜치나 실험용 레포를 붙이면 잘못된 컴포넌트를 학습한다.

• 디자인 시스템의 토큰이 정리되어 있다. 색상, 간격, 타이포그래피, radius, shadow 같은 기본 규칙이 최소한 일관적이어야 한다.¹

• 기존 컴포넌트 이름을 실제 이름으로 부른다. PrimaryButton, ProductCard, SettingsLayout처럼 팀이 이미 쓰는 이름을 그대로 쓰는 편이 좋다.²

• 이번 화면이 기존 컴포넌트 조합인지, 새 컴포넌트 추가인지 구분했다.

• 새 패턴을 만들었다면 왜 필요한지 이유를 남겼다. "예뻐 보여서"가 아니라 "기존 카드 구조로는 비교 테이블의 강조 계층을 표현하기 어렵다"처럼 설명 가능해야 한다.

• 대용량 폴더를 무작정 연결하지 않았다. .git, node_modules 같은 불필요한 파일 트리는 제외했다.²

• 팀 내 소스 오브 트루스가 분명하다. 색상은 코드 기준인지, 디자인 파일 기준인지, 아니면 현재 배포본 기준인지가 섞이면 꼭 충돌이 난다.

한마디로 요약하면, 이 단계의 목표는 "Claude가 우리 팀 언어로 생각하게 만들기"입니다.

4. 핸드오프 직전 체크리스트

핸드오프는 파일 하나를 넘기는 일이 아닙니다. 구현자가 덜 추측하게 만드는 일입니다. 공식 가이드도 명확한 컴포넌트 이름, 채팅 안의 의사결정 기록, 그리고 엣지 케이스 노출이 깔끔한 핸드오프의 핵심이라고 설명합니다.²

• 최종안이 무엇인지 명확하다. 변형이 여러 개라면 "이번 구현 기준은 v3"처럼 못 박아 둔다.

• 왜 그런 결정을 했는지 채팅이나 메모에 남겼다. 예: "사이드바 대신 탭을 쓴 이유는 한 화면에서 모든 섹션을 빠르게 비교해야 하기 때문."²

• 빈 상태, 로딩 상태, 오류 상태, 권한 없음 상태를 확인했다.²

• 긴 텍스트, 숫자 과다, 항목 0개, 항목 100개처럼 극단 입력도 확인했다.

• 실제 에셋의 위치가 정리되어 있다. 로고, 아이콘, 일러스트, 썸네일 원본이 어디 있는지 구현자가 다시 찾지 않게 한다.

• 카피의 책임자가 정해져 있다. 임시 문구인지, 마케팅 확정본인지, 법무 검토 전 버전인지가 불명확하면 마지막에 다시 흔들린다.

• 인터랙션 설명이 있다. 클릭 후 이동, 토스트, 모달, 인라인 검증, 저장 성공 피드백처럼 화면 밖에서 일어나는 행동도 기록한다.

• 반응형 규칙이 있다. 모바일에서는 숨길 것, 접을 것, 순서를 바꿀 것을 미리 적는다.

• 내보내기 방식이 목적에 맞다. 이해관계자 리뷰용이면 URL·PDF·PPTX가 편하고, 구현용이면 Claude Code 핸드오프 번들이 기준이 된다.¹

• 핸드오프를 받는 사람이 "이걸 그냥 구현하면 되는지"와 "어디는 판단이 필요한지"를 구분할 수 있다.

이 항목이 끝나면 핸드오프는 더 이상 "잘 부탁드립니다"가 아니라 "이 규칙대로 이어서 만드세요"가 됩니다.

5. Claude Code로 넘긴 뒤 바로 확인할 것

디자인이 아무리 좋아도, 구현 시작 방식이 거칠면 다시 무너집니다. Claude Code 쪽에서는 속도보다 순서를 지키는 편이 훨씬 유리합니다. 특히 계획을 먼저 세우고 구현을 나중에 시작하는 습관이 중요합니다.³

• 핸드오프 번들의 README, 디자인 파일, 채팅 맥락을 먼저 읽었다.²

• 저장소의 CLAUDE.md와 관련 규칙 파일을 확인했다. 구현 규칙, 테스트 명령, 아키텍처 예외 사항은 여기서 먼저 잡는 편이 좋다.³

• 바로 코딩하지 않고 먼저 구현 계획을 만들었다. 어떤 화면을 어떤 컴포넌트로 매핑할지, 새로 만들 것은 무엇인지, 상태는 어디서 관리할지를 적는다.³

• "모르는 점 목록"을 먼저 뽑았다. API가 없는지, 기존 컴포넌트가 부족한지, 애니메이션 스펙이 모호한지 초반에 드러내야 한다.

• 기존 컴포넌트를 우선 사용하고, 부족한 부분만 확장한다.

• 디자인 토큰 매핑을 확인했다. 시안의 색상과 코드의 토큰 이름이 다르면 초반에 바로 맞춘다.

• 구현 단위를 작게 쪼갰다. 레이아웃, 상태, 인터랙션, 접근성, 테스트를 한 덩어리로 몰아치지 않는다.

• 검증 명령이 준비되어 있다. 빌드, 테스트, 린트, 타입체크, 스토리북 확인 경로가 분명해야 한다.³

여기서는 멋진 프롬프트보다 좋은 출발 순서가 더 중요합니다. 막 달리기 전에 지도부터 펴는 셈입니다.

6. 구현 중 품질 게이트

구현 단계에서 자주 생기는 착각이 있습니다. "화면이 얼추 같으니 거의 끝났다"는 생각입니다. 실제로는 이때부터가 진짜 시작인 경우가 많습니다. 시각적 유사성만으로는 제품 품질을 보장할 수 없기 때문입니다.

• 정상 경로뿐 아니라 실패 경로까지 구현했다.

• 폼 검증 메시지가 디자인 의도와 톤을 유지한다.

• 포커스 이동, 키보드 조작, 스크린 리더 흐름을 확인했다.

• hover만 있고 focus가 없는 식의 반쪽 인터랙션이 아니다.

• 모바일 터치 타깃이 너무 작지 않다.

• 데이터가 많아져도 레이아웃이 깨지지 않는다.

• 긴 이름, 긴 가격, 긴 태그처럼 현실적인 텍스트 길이를 견딘다.

• 다크 모드나 테마 전환을 쓰는 제품이라면 변형 상태도 확인했다.

• 로딩 스켈레톤과 실제 데이터 화면 사이의 점프가 과하지 않다.

• 애니메이션이 보기 좋기만 한 것이 아니라, 성능 비용도 감당 가능하다.

• 분석 이벤트나 핵심 추적 지점이 빠지지 않았다.

디자인 QA의 핵심은 "닮았는가?"보다 "정확히 동작하는가?"입니다. 시각적 정확도, 접근성, 레이아웃 충실도를 함께 검수해야 진짜로 손실 없는 구현에 가까워집니다.⁴

7. 배포 전 최종 검수

배포 직전에는 새 기능 추가보다 누락 제거가 더 중요합니다. 이 단계에서는 감각보다 체크가 이깁니다.

• 최종 구현이 원래 의도한 사용자 행동을 실제로 유도한다.

• 첫 화면에서 핵심 정보 위계가 유지된다.

• CTA가 시안보다 약해지지 않았다.

• 에러 문구와 도움말 문구가 최신본이다.

• 브라우저 크기를 바꿔도 깨지는 구간이 없다.

• 필요한 테스트가 통과했다.

• 코드 리뷰 기준이 준비되어 있다. 시각 차이만 보지 말고 상태 처리, 재사용성, 접근성, 유지보수성까지 본다.

• 커밋과 PR 설명에 디자인 의도와 구현 판단이 남아 있다.

• 이해관계자가 확인해야 할 링크나 스크린샷이 정리되어 있다.

• 배포 후 관찰할 지표가 있다. 클릭률, 완료율, 오류율, 이탈 위치처럼 "이 디자인이 실제로 먹히는지" 볼 수 있어야 한다.

배포는 끝이 아니라 현실 점검입니다. 제품은 예쁜 스크린샷으로 평가받지 않고, 실제 사용 결과로 평가받으니까요.

8. 팀이 자주 놓치는 빨간 깃발

아래 신호가 보이면, 지금은 속도를 더 낼 때가 아니라 한 번 멈춰야 할 때입니다.

• 시안에는 있는데 코드에는 없는 상태가 많다.

• "디자이너한테 다시 물어봐야 할 것 같아요"가 반복된다.

• 기존 컴포넌트로 되는지 새로 짜야 하는지 팀 내 의견이 다르다.

• 데스크톱 화면만 확정되고 모바일은 미정이다.

• 카피가 마지막 날까지 계속 바뀐다.

• 구현 중에 디자인 시스템 규칙이 뒤집힌다.

• 동일한 버튼이나 카드가 화면마다 조금씩 다르다.

• Claude Code가 만든 결과를 사람이 다시 거의 처음부터 고쳐야 한다.

이런 경우에는 보통 한 가지가 빠져 있습니다. 디자인이 아니라 맥락입니다. 즉, 무엇을 왜 그렇게 만들었는지가 빠진 상태입니다.

9. 30초 최종 점검표

회의 들어가기 전이나 PR 올리기 전에, 마지막으로 이것만 훑어도 큰 사고를 많이 줄일 수 있습니다.

• 목표 사용자가 분명한가?

• 핵심 행동이 첫 화면에서 보이는가?

• 기존 컴포넌트로 구현 가능한가?

• 새로 필요한 패턴이 무엇인지 분명한가?

• 로딩·빈 상태·오류 상태가 있는가?

• 모바일 우선순위가 정리됐는가?

• 카피 최신본이 반영됐는가?

• 핸드오프 번들에 결정 이유가 남아 있는가?

• Claude Code 구현 계획이 먼저 작성됐는가?

• 테스트와 QA 기준이 준비됐는가?

이 열 가지에 모두 체크할 수 있다면, 적어도 "시안은 좋았는데 구현에서 망했다"는 말은 들을 확률이 크게 줄어듭니다. 좋은 디자인은 영감에서 나오지만, 좋은 제품은 점검표를 통과하면서 완성됩니다.

참고

¹Introducing Claude Design by Anthropic Labs

²Using Claude Design for prototypes and UX  Claude

³Claude Code: Workflows and Best Practices 2026

⁴Design QA Checklist  Claude Code Skill for UI Verification