디자이너가 Claude Code로 UI 디자인 개선하는 워크플로우 짜는 법

Claude Code를 쓰면 디자이너가 개발자가 되어야 할까요. 그럴 필요는 없습니다.

더 현실적인 목표는 따로 있습니다. 정적 시안에서는 보이지 않는 것을 보는 것입니다. 응답이 3초 걸릴 때의 답답함, 이름이 길어졌을 때 무너지는 정렬, 키보드가 올라왔을 때 가려지는 버튼 같은 것들입니다. 이건 시안을 아무리 오래 들여다봐도 안 보입니다.

이 글은 그 루프를 만드는 순서입니다. 대부분은 그대로 복사해서 써도 됩니다.

먼저, Claude Code가 Figma에서 못 읽는 것

기대치를 먼저 맞추는 게 시간을 아낍니다. MCP로 연결해도 네 가지는 안 넘어갑니다.

• 이미지의 실제 픽셀. 사진이나 일러스트 안에 뭔가 그려져 있는지는 모릅니다.
• 프로토타입 인터랙션. 연결선으로 짜놓은 화면 전환은 전달되지 않습니다.
• 코멘트. 팀이 캔버스에 달아둔 논의는 안 보입니다.
• 버전 히스토리. 왜 이렇게 바뀌었는지는 알 수 없습니다.

에셋은 따로 내보내야 합니다. 보통 public/ 같은 폴더로 직접 export해둔 다음에야 참조할 수 있습니다. 이걸 모르고 "로고가 왜 안 나오지"로 반나절 보내는 경우가 흔합니다.

그리고 중요한 함의가 하나 있습니다. 프로토타입 인터랙션과 코멘트를 못 읽는다는 건, 의도를 말로 다시 써줘야 한다는 뜻입니다. 파일만 가리키고 "이거 만들어줘"라고 하면 맥락 없는 번역본이 나옵니다.

0단계. 파일이 준비돼야 결과가 나옵니다

이걸 건너뛰면 나머지가 전부 낭비입니다. Figma 파일이 아래 조건을 만족하지 못하면 결과 품질이 눈에 띄게 떨어집니다.

• Auto Layout이 적용돼 있을 것. 절대 좌표로 배치된 프레임은 반응형으로 번역되지 않습니다.
• 이름이 의미를 가질 것. Frame 247로는 아무것도 유추할 수 없습니다.
• 계층이 얕을 것. 그룹 안의 그룹 안의 그룹은 구조 파악을 방해합니다.
• 토큰이 정의돼 있을 것. 색과 간격이 스타일로 묶여 있지 않으면 하드코딩된 값이 우수수 들어옵니다.

흥미로운 역설이 여기 있습니다. AI가 잘 읽는 파일은 사람이 유지보수하기 좋은 파일과 거의 같습니다. 깔끔한 파일을 만들 이유가 하나 더 생긴 셈입니다.

1단계. 화면이 아니라 브리프부터

요청의 질이 결과의 질을 거의 결정합니다. "깔끔한 결제 화면"은 나쁜 요청입니다. 아래가 좋은 요청입니다.

처음 결제하는 사용자가 수수료와 취소 조건을 확인한 뒤 자신 있게 결제하게 한다.

차이는 판단 기준이 들어 있다는 점입니다. 결과물을 받았을 때 "이게 맞나"를 판정할 수 있게 됩니다.

브리프에 넣을 것은 네 개면 충분합니다. 핵심 사용자, 해야 할 일, 성공 조건, 반드시 지켜야 할 컴포넌트와 토큰.

2단계. 한 번에 다 만들게 하지 않기

한 프롬프트로 전체 화면을 요청하면 대부분 무너집니다. 네 단계로 끊는 게 안정적입니다.

1. 분석 — 파일 구조, 섹션 목록, 색 팔레트, 타이포그래피, 식별된 컴포넌트를 먼저 받습니다.
2. 토큰 추출 — 색·서체·간격 스케일을 설정 파일로 고정시킵니다.
3. 컴포넌트 — 개별 컴포넌트를 만들게 합니다.
4. 섹션 조립 — 그제서야 화면을 조립합니다.

1번을 건너뛰면 안 됩니다. 분석 결과를 읽어보면 오해한 지점이 보이는데, 이걸 지금 고치는 것과 컴포넌트 서른 개 만들어진 다음에 고치는 건 비용이 완전히 다릅니다.

2번도 중요합니다. 토큰을 먼저 고정하지 않으면 화면마다 미묘하게 다른 회색이 생깁니다.

3단계. 정상 상태 하나로 끝내지 않기

여기가 디자이너가 얻는 가장 큰 이득입니다. 아래를 통째로 요청합니다.

이 화면의 상태를 모두 볼 수 있게 만들어줘. 전환할 수 있는 토글을 화면 위에 달아줘. ① 데이터가 있는 기본 상태 ② 데이터가 하나도 없는 상태 ③ 로딩이 3초 이상 길어지는 상태 ④ 네트워크 오류 ⑤ 권한이 없는 상태 ⑥ 이름과 금액이 아주 긴 상태

토글을 달아달라는 게 핵심입니다. 상태를 볼 때마다 코드를 고쳐달라고 하면 확인에 한참이 걸려서 결국 두세 개만 보고 말게 됩니다. 한 화면에서 클릭으로 전환되면 열 번이라도 봅니다.

360px 폭과 키보드가 올라온 상태도 같이 요청하세요. 모바일 대응은 명시하지 않으면 거의 빠집니다.

상태별로 무엇을 보아야 하는지는 AI가 만든 UI 검수 체크리스트에 따로 적어두었습니다.

4단계. 반복해서 나오는 실패 네 가지

미리 알고 있으면 검수가 빨라집니다.

컴포넌트 중복 생성. 이미 있는 버튼을 두고 비슷한 버튼을 하나 더 만듭니다. "기존 컴포넌트를 사용하고, 없으면 만들기 전에 먼저 물어봐"를 붙이면 줄어듭니다.

임의의 간격 값. 13px, 17px 같은 값이 섞입니다. 토큰을 먼저 고정하면 대부분 해결됩니다.

아이콘 발명. 없는 아이콘을 비슷한 걸로 대체하거나 새로 그립니다. 쓰는 아이콘 세트를 명시하고 "없는 아이콘은 만들지 말고 비워두고 알려달라"고 합니다.

반응형 붕괴. 데스크톱은 멀쩡한데 중간 해상도에서 깨집니다. 브레이크포인트를 숫자로 직접 지정해야 안정적입니다.

이 네 개가 예전 AI 디자인 도구의 고질 문제였고, 도구가 좋아진 지금도 완전히 사라지진 않았습니다.

5단계. 한 번에 하나씩, 이유를 붙여서

전체를 다시 만들게 하면 무엇이 바뀌었는지 추적할 수 없습니다. 한 문제씩 고칩니다.

그리고 요청할 때 판단 근거를 같이 달라고 하세요.

이 오류 문구가 사용자의 다음 행동을 알려주는지 설명하고, 다른 안 두 개를 이유와 함께 제안해줘.

이렇게 받으면 선택이 쉬워집니다. 그리고 거절할 때도 이유를 말할 수 있게 됩니다. 이건 단순한 팁이 아니라 안목을 훈련하는 방식 자체이기도 합니다.

변경 전후는 스크린샷으로 따로 남겨두세요. 세 번째 수정에서 뭔가 재미있어졌는데 되돌릴 수 없을 때가 옵니다.

6단계. 다시 Figma로

작동하는 화면을 본 다음에는 다시 캔버스로 돌아가는 게 좋습니다. 코드 안에서는 대안을 나란히 놓고 비교하기가 어렵고, 팀 리뷰도 불편합니다.

가져오면서 같이 가져올 것은 문제 목록입니다. 눌러보면서 발견한 것들을 적어놓으면 다음 라운드의 브리프가 저절로 만들어집니다.

어느 단계에서 어느 도구를 쓸지는 Figma와 Claude Code의 역할 분담에 정리해 두었습니다.

반론: 5배 빨라진다는 말은 믿을 만한가

이 조합을 소개하는 글마다 "5배 빨라졌다", "몇 주가 몇 분으로" 같은 문장이 붙습니다. 조심해서 볼 필요가 있습니다.

그 수치들은 대부분 측정된 게 아니라 체감입니다. 비교 대상이 무엇인지, 어느 구간을 잔다는 건지(초안 생성만인지 검수와 수정까지인지), 결과물이 실제로 배포될 품질이었는지가 거의 밝혀져 있지 않습니다.

정직하게 말하면 이렇습니다. 초안까지 가는 시간은 확실히 극적으로 줄어듭니다. 그런데 배포 가능한 품질까지 가는 시간은 그만큼 줄지 않습니다. 검수와 수정이 새로 생기기 때문입니다.

그래도 남는 이득이 큽니다. 검수할 것이 생겼다는 건 검수할 수 있는 물건이 생겼다는 뜻이니까요. 예전에는 개발이 끝난 뒤에야 알 수 있던 것을 기획 단계에서 알게 되는 게 진짜 이득입니다. 속도가 아니라 순서가 바뀜다고 보는 게 정확합니다.

맡기지 말아야 할 것

분명한 것들만 적겠습니다.

문제의 우선순위는 맡기지 않습니다. 무엇부터 고칠지는 사용자와 사업을 알아야 정해집니다.

접근성 합격 판정도 맡기지 않습니다. 검사 도구를 돌리는 건 맡겨도, 통과했는지를 믿는 건 다른 일입니다. AI로 생성한 인터페이스가 WCAG를 통과하는 비율이 약 3분의 1이라는 점을 기억해두면 됩니다.

마지막으로 최종 미감은 맡기지 않습니다. 도구가 잘하는 건 평균적으로 준수한 결과이고, 평균은 정의상 남들과 같습니다.

도구의 가장 좋은 쓰임은 디자인을 자동 완성하는 게 아닙니다. 더 자주 검증할 수 있는 재료를 싸게 만드는 것입니다.

팀에 도입할 때 마찰이 생기는 곳

혼자 쓸 때는 재밌는데 팀에 까는 순간 조용한 저항이 생깁니다. 예측 가능한 것들이라 미리 알고 가는 게 낫습니다.

가장 흔한 건 개발자의 경계감입니다. 디자이너가 저장소를 건드리기 시작하면 "이거 나중에 내가 치우는 거 아니야"라는 공포가 생깁니다. 타당한 걱정입니다. 해법은 권한이 아니라 범위를 먼저 좁히는 것입니다. 별도 브랜치에서 프로토타입만 만들고 병합은 안 하겠다고 명시하면 대부분 풀립니다.

두 번째는 기대치입니다. 작동하는 화면을 한번 보여주면 팀은 그걸 결정으로 받아들입니다. 시안은 "아직 생각 중"으로 읽히는데 눌러지는 화면은 "다 됐네"로 읽힙니다. 공유할 때 무슨 질문을 보려고 만들었는지를 먼저 말해야 합니다.

세 번째는 유지보수입니다. 프로토타입을 버릴지 남길지 정하지 않으면 애매한 코드가 쌓입니다. 버릴 거라면 품질을 신경 쓸 필요가 없고, 남길 거라면 처음부터 저장소 규칙을 따라야 합니다. 시작할 때 한 문장으로 정해두면 나중에 싸울 일이 없습니다.

마지막은 협업 밀도입니다. AI 때문에 협업이 줄었다는 응답은 2025년 5%에서 2026년 20%로 늘었습니다. 혼자 빨라지는 만큼 팀이 같이 보는 시간을 의식적으로 다시 만들지 않으면, 생산성 지표만 오르고 기준은 조용히 흔들립니다.

마지막으로 하나. 이 루프를 돌리기 시작하면 시안을 더 적게 만들게 됩니다. 그게 이상하게 느껴져서 일을 덜 한 것 같은 기분이 들 수 있는데, 산출물의 종류가 바뀐 것뿐입니다. 예쁘게 정렬된 프레임 서른 장보다, 오류 상태까지 눌러지는 화면 하나가 팀에게 더 많은 정보를 줍니다. 평가가 그렇게 바뀜기까지는 시간이 좀 걸리지만요.

처음 한 달은 오히려 느려질 겁니다. 도구를 익히는 시간보다 뭐를 요청해야 하는지 감을 잡는 시간이 깁니다. 그 구간을 넘기면 상태를 열어보는 일이 별도 작업이 아니라 그냥 검토의 일부가 됩니다.