Table of Contents
처음부터 디자인 도구를 찾은 건 아니었다. 이력서 어시스턴트와 생활 관리 어시스턴트를 처음 만들 때는 Claude나 Codex와 기능을 설계하면서 Markdown 문서 안에 화면도 함께 그렸다. 선과 표를 이용한 와이어프레임이었다.
+--------------+--------------------------+
| 사이드바 | 상단 제목 |
| +--------------------------+
| 메뉴 | 주요 콘텐츠 |
| | |
+--------------+--------------------------+정확히 어떻게 보여야 하는지보다 어느 영역에 무엇이 들어가고 어디로 이동하는지를 적는 방식이었다. 에이전트와 화면 구조를 이야기하고 바로 코드로 옮기기에는 편했다. 별도 도구를 열지 않아도 됐고 기능 설계 문서와 화면 흐름이 한곳에 남았다. 이력서 어시스턴트의 초기 화면과 생활 관리 어시스턴트의 첫 구성도 이 문서에서 시작했다.
처음 몇 화면은 그럭저럭 나왔다. 문제는 화면이 늘고 디자인을 다듬기 시작하면서 생겼다. Markdown 와이어프레임에는 색과 타이포, 간격, 라운드 같은 시각 기준이 없었다. 같은 카드가 다른 화면에서 어느 정도 크기여야 하는지, 모바일 폭에서 무엇을 줄여야 하는지도 정해져 있지 않았다. 한 부분을 고칠 때 비교할 시안이나 공통 규칙이 없으니 매번 그 화면만 보고 판단했다. 수정은 쌓였지만 전체 완성도는 쉽게 올라가지 않았다.
Markdown 와이어프레임이 쓸모없었던 것은 아니다. 정보 구조와 이동 흐름을 빠르게 잡는 데는 지금도 괜찮은 방식이라고 생각한다. 다만 구조를 정한 뒤 시각적 방향을 비교하고 여러 화면의 기준을 맞추는 단계에는 다른 도구가 필요했다.
개인 프로젝트에서 코드보다 자주 막힌 건 이 지점이었다. 기능과 데이터 구조는 머릿속에 있는데 무엇을 먼저 보여주고 어떤 규칙으로 화면을 이어 붙일지가 비어 있었다. 실제 고객이 쓰는 상용 서비스를 만들거나 디자이너와 계속 협업하는 상황이었다면 Figma를 선택했을 것 같다.
다만 당시에는 혼자 만드는 개인 프로젝트였고 이미 AI 도구와 개발 도구를 여럿 구독하고 있었다. 그래서 구독과 학습 비용을 더하기보다 지금 단계에서 부담 없이 시각적 방향을 잡을 방법부터 찾았다. Stitch를 써보고 Figma 무료 티어로도 버텨보다가 기존 Claude와 Codex를 연결해 쓸 수 있는 Pencil.dev를 알게 됐다.
이 글은 Pencil.dev와 Claude Design의 기능을 빠짐없이 비교하는 글은 아니다. 혼자 진행한 개인 프로젝트 세 개에서 제품 구상을 화면으로 만들고 그 화면을 다시 코드로 옮긴 기록이다. 프로젝트마다 다시 조정해야 했던 부분이 왜 달랐는지, 시안과 구현 사이에서 무엇이 빠졌는지를 정리해보려 한다.
Pencil.dev에서 Claude Design으로 옮긴 이유
Pencil.dev에서 마음에 든 건 모델을 따로 결제하지 않아도 된다는 점이었다. 이미 쓰고 있는 Claude와 Codex 모델로 디자인 작업이 돌아갔다. 구독을 늘리지 않아도 된다는 게 그때는 컸다.
여기서는 생활 관리 어시스턴트의 iOS 화면을 작업했다. 온보딩, 홈, 캘린더 같은 주요 화면을 캔버스에 늘어놓으니 앱의 전체 구조를 보기 편했다.
온보딩 화면을 순서대로 나란히 놓고 전체 흐름을 확인했다. 화면 아래에서 디자인 작업에 사용할 모델을 선택할 수 있다.
다만 계속 사용하기에는 걸리는 점이 있었다. 당시 내 환경에서는 도구가 무거웠고 화면 하나가 나오기까지 오래 기다려야 했다. 앱의 정보 구조를 확인하기에는 충분했지만 제품 화면으로 옮기려면 세부 요소를 다시 조정해야 했다.
Pencil.dev에 관한 내용은 당시 사용 경험을 기준으로 썼다. 지금은 이름이 pen.dev로 바뀌었고 “Design on canvas. Land in code.”라는 문구로 IDE 안에서 디자인하는 방식을 내세우고 있다. 내가 쓰던 때와 같지 않을 수 있으니 지금 사용을 고민하고 있다면 직접 확인해보는 편이 낫다.
그러던 중 Claude Design이 나왔다. 설명과 참고 자료를 받아 목업이나 프로토타입을 만들고 그 결과를 Claude Code로 넘길 수 있는 베타 도구다. 유료 Claude 구독에 포함돼 있어 별도 구독을 늘리지 않고 이어서 시도할 수 있었다. Pencil에서 잡아둔 생활 관리 어시스턴트의 구조를 가져오는 것부터 시작했다.
화면 수와 출발점에 따라 수정할 부분이 달랐다
세 프로젝트는 출발점부터 달랐다.
| 프로젝트 | 출발점 | 플랫폼·범위 | 주로 조정한 부분 |
|---|---|---|---|
| 생활 관리 어시스턴트 | Pencil에서 만든 초기 구성 | iOS, 약 30개 아트보드 | 화면 사이의 규칙과 모바일 대응 |
| 이력서 어시스턴트 | 이미 동작하는 16개 화면 | 웹 리디자인 | 시안과 기존 코드의 차이 |
| 여행 챗봇 | 글로 정리한 레이아웃 후보 3개 | 웹, 채팅 중심 소수 화면 | 후보 비교와 색 토큰 고정 |
생활 관리 어시스턴트는 화면 사이의 규칙을 맞춰야 했다
Claude Design을 처음 쓴 프로젝트라 도구에도 익숙하지 않았다.
모바일 앱이었고 그릴 화면이 많았다. 온보딩, 홈, 캘린더, 목표 흐름, 회고, 설정까지 9개 섹션과 약 30개 아트보드로 이어졌다. 화면 수가 늘어날수록 앞에서 정한 것과 뒤에서 나온 것이 달라지기 시작했다. 홈에서 쓰던 카드 모양이 보드에서는 미묘하게 바뀌고 앞에서 정한 여백이 뒤 화면에서는 다른 값으로 나오는 식이었다. 한 화면을 고치는 요청이 다른 화면의 규칙까지 바꾸기도 해서 전체를 맞추는 데 애를 먹었다.
Pencil에서 잡아둔 iOS 화면 구성이 있어서 처음부터 시작한 건 아니었다. 마스코트도 그전부터 있던 캐릭터라 새로 만들 필요는 없었고 대신 Claude Design에서 에셋으로 정리했다. 배경 가장자리의 색 번짐을 걷어내고 남은 흰 점을 지워 상황별 에셋 스무 종을 만들었다. 화면 방향은 두 갈래로 만들어 비교한 뒤 골랐다.
온보딩 첫 화면. 마스코트는 이전부터 있던 캐릭터를 에셋으로 정리해 썼다.
이력서 어시스턴트는 기존 화면을 다시 그렸다
이미 동작하는 화면이 열여섯 개 있었다. 만든 시점이 제각각이라 색과 여백이 화면마다 달랐다. 전부 스크린샷으로 찍어 올리고 브리프를 21KB 분량으로 써서 넘겼다.
이 프로젝트에서 시안과 구현이 조금씩 달라지는 일을 가장 자주 겪었다. 화면마다 차이를 찾아 고치다가 결국 공통 기준을 디자인 시스템으로 따로 정리했다.
아래쪽 탭으로 화면·상태·뷰포트를 바꿔 볼 수 있다. 로딩과 빈 화면, 오류까지 시안 안에 들어 있다.
여행 챗봇은 비교적 빠르게 방향을 정했다
마감 기한이 짧아서 오래 매달릴 수 없는 프로젝트였다. 브리프도 길게 쓰지 않았는데 결과물은 생각보다 마음에 들었다.
웹이었고 화면 수가 적었다. 채팅 화면 하나에 카드가 얹히는 구조라 여러 화면의 규칙을 동시에 맞출 일이 적었다. 그리기 전에 글로 정리해둔 것도 도움이 됐다. 저장소 문서에 레이아웃 후보를 셋으로 적어두고 있었다.
| 옵션 | 형태 |
|---|---|
| A | 순수 단일 컬럼. 메신저처럼 채팅 하나만 |
| B | 채팅 + 우측 “내 여행” 요약 패널 |
| C | 채팅 + 카드 상세 오버레이 |
이 문서를 그대로 첨부하고 목업을 받아 비교한 뒤 B로 정했다. 며칠 뒤 로그인 화면이 필요해졌을 때는 브리프를 따로 쓰면서 기존 색 토큰을 다시 적어 보냈다. 새 화면이 기존 화면과 따로 놀지 않게 하려는 것이었다.
뒤늦게 추가한 로그인 화면. 기존 색 토큰을 다시 적어 보낸 덕에 앞서 만든 화면과 같은 톤으로 나왔다.
세 프로젝트를 같은 조건에서 비교한 것은 아니다. 첫 프로젝트를 할 때보다 도구에 익숙해졌고 신규 설계와 리디자인이라는 차이도 있었다. 그래도 몇 가지 공통점은 보였다. 화면이 많을수록 앞뒤 규칙을 맞출 일이 늘었고 좁은 폭과 여러 상태를 함께 다루는 모바일에서는 조정할 부분이 더 많았다. 여행 챗봇처럼 화면이 적고 문서로 범위를 좁혀둔 프로젝트는 수정 범위가 작았다.
브리프가 길다고 잘 나오지는 않았다
이력서 어시스턴트에는 16개 화면의 스크린샷과 21KB짜리 브리프를 넘겼다. 여행 챗봇에 준 문서는 그보다 짧았다. 자료만 보면 이력서 어시스턴트에서 수정할 부분이 더 적을 것 같았지만 실제로는 여행 챗봇의 수정 범위가 작았다.
중요했던 건 문서의 길이보다 무엇을 정해두었느냐였다. 이력서 어시스턴트의 브리프에는 기존 화면의 기능과 고쳐야 할 내용이 많이 들어갔다. 그러나 어떤 규칙을 모든 화면에서 고정해야 하는지와 어디까지 바꿔도 되는지가 한눈에 나뉘지는 않았다. 여행 챗봇 문서는 A·B·C 세 가지 레이아웃 중 하나를 고르는 문제로 범위를 좁혔다. 선택한 뒤에는 색 토큰을 다시 적어 보내 새 화면에도 같은 기준을 썼다.
이후 브리프를 쓸 때는 내용을 많이 넣는 것보다 세 가지를 나눠 적기 시작했다.
- 이미 정해서 바꾸면 안 되는 것
- 아직 열어두고 비교할 것
- 기존 코드와 에셋에서 반드시 재사용할 것
AI 디자인 도구에 모든 판단을 맡기기보다 어디까지 판단할지를 정해주는 방식이었다. 이 구분이 없으면 상세한 문서도 긴 요구사항 목록이 되고 앞부분의 결정이 뒤 화면까지 이어진다는 보장은 없었다.
시안과 구현은 조금씩 달랐다
Claude Design에서 본 화면과 구현한 화면이 크게 다르지는 않았다. 차이는 한 번에 알아채기 어려울 만큼 작았다. 이력서 어시스턴트를 구현하면서 내가 남긴 지적을 모아보면 이렇다.
- 랜딩 최상단이 시안에서는 양옆으로 꽉 차는데 구현에서는 안 찼다
- 콘텐츠 영역 폭이 시안보다 넓었다
- 구현한 탑바는 흰색이었지만 시안의 색은 달랐다
- 사이드바 패딩과 마진이 시안과 미묘하게 달랐다
- 폰트 크기, 행간, 자간, 볼드 처리가 조금씩 달랐다
- 마스코트 뒤에 시안에 없던 보라색 원이 생겼다
하나하나는 사소하다. 그런데 화면마다 이런 게 서너 개씩 나오고 한 화면을 맞추면 다음 화면에서 또 나왔다. 어느 순간 이런 말을 하고 있었다.
이런 거 전부 하나하나 내가 다 찾아야 하나?
이런 차이는 모바일에서 더 자주 보였다. 데스크탑 폭에서 맞춰둔 것도 좁은 폭으로 가면 무너지는 경우가 잦았다. 생활 관리 어시스턴트에서 조정이 특히 어려웠던 것도 이 때문이었다.
원인을 하나로 돌리기는 어렵지만 내가 넘긴 산출물은 완성된 화면을 보여주는 데 초점이 맞춰져 있었다. 어떤 여백이 고정이고 어떤 값이 화면 폭에 따라 달라지는지, 카드가 컨테이너를 채우는 게 의도인지 우연인지까지는 분명하지 않았다. 이력서 어시스턴트에는 로딩·빈 화면·오류 시안도 있었지만 언제 그 상태로 들어가고 어떤 행동으로 빠져나오는지까지 정해진 것은 아니었다. 기존 코드의 컴포넌트 경계와 접근성 규칙까지 더해지면 같은 화면을 보고도 구현 선택이 달라질 수밖에 없었다.
시안을 비슷하게 옮기는 것과 이후 화면까지 같은 규칙으로 구현하는 것은 다른 일이었다. 전자는 스크린샷을 대조해 고칠 수 있지만 후자는 토큰과 반응형 기준, 컴포넌트 사용법이 있어야 했다.
시안 대신 반복해서 지킬 규칙을 정리했다
화면을 하나씩 대조하는 대신 반복해서 지켜야 할 규칙 자체를 문서로 뽑아달라고 요청했다.
Claude Design은 색과 타이포, 간격, 라운드, 섀도를 CSS 변수로 정리하고 버튼, 인풋, 카드 같은 컴포넌트 열두 종도 만들었다. 컴포넌트마다 구현 파일과 타입 정의, 사용법을 적은 문서도 붙었다.
“시안의 이 보라색”으로 가리키던 색에 이름과 값이 생겼다. 버튼도 변형과 크기별로 나뉘었다.
여기에 스킬 문서가 하나 생겼다. Claude Code에서 읽는 형식이고 안에 지켜야 할 것들이 못 박혀 있다. 배경은 흰색이 아니라 크림(#FAF9F6)이고 강조는 라벤더 하나(#7561F2)로 끌고 가되 보조 색은 화면당 하나까지만 쓴다. 테두리는 고정된 회색 hex 대신 잉크 색에 투명도를 적용하고 두께는 1.5px로 둔다는 식이다.
이 문서가 생긴 뒤부터 코딩 에이전트에게 매번 “시안과 비슷하게”라고 요청하지 않아도 됐다. 새 화면을 만들 때 같은 토큰과 컴포넌트를 먼저 읽게 하고 시각 검수는 그다음에 했다. 시안을 눈으로 비교하는 일에서 규칙을 참조하는 일로 바뀌었다. 디자인 도구의 결과가 코딩 에이전트가 반복해서 읽는 구현 계약이 된 셈이다.
여행 챗봇에서도 규모는 작지만 같은 방식을 썼다. 브리프에 적었던 색 토큰이 지금 프론트엔드 코드에 그대로 들어 있다.
--primary: oklch(0.48 0.075 210);
--accent: oklch(0.7 0.15 46);도구가 줄인 일과 여전히 남은 일
Claude Design이 가장 많이 줄여준 건 빈 화면에서 방향을 찾는 시간이었다. 같은 요구사항으로 두세 가지 화면을 만들고 비교하거나 기존 마스코트를 상황별 에셋으로 정리하는 일은 혼자 할 때보다 시도하기 쉬웠다. 디자인 용어를 잘 몰라도 보이는 결과를 두고 “이쪽 여백을 줄여달라”, “이 흐름은 카드로 묶어달라”고 이야기할 수 있다는 점도 편했다.
다만 제품의 흐름까지 판단해주는 것은 아니었다. 이 버튼을 누른 다음 어떤 상태가 되는지, 데이터가 없거나 API가 실패하면 무엇을 보여줄지, 기존 코드에서 어떤 컴포넌트를 재사용할지는 내가 정해야 했다. 시각적으로 완성된 화면이 나왔다고 제품 설계와 구현 준비까지 끝난 것은 아니었다.
그래서 지금은 Claude Design의 결과를 화면을 보며 논의할 수 있는 초안으로 본다. 제품에 필요한 결정을 내리고 정해진 부분은 토큰과 컴포넌트 규칙으로 옮긴다. 그 규칙을 Claude Code가 읽게 한 뒤 실제 코드 구조에 맞춰 구현한다.
모델에 따라 수정할 부분도 달랐다
평소 작업에서는 모델 차이를 크게 느끼지 못했다. 그런데 이 작업에서는 달랐다. 시안을 만드는 단계와 그 시안을 코드로 옮기는 단계 모두에서 차이가 보였다.
내가 작업한 세 프로젝트에서는 Fable로 만든 결과가 더 마음에 들었다. 같은 문서를 주고 비슷한 요청을 했을 때 첫 시안에서 수정할 부분이 적었고 구현 결과도 시안에 더 가까웠다. 프로젝트 수가 셋뿐이고 요청 조건도 완전히 같지는 않았으니 모델 전체의 우열로 일반화할 수는 없다.
다만 사용량 한도에 금방 걸렸다. Max 요금제를 쓰는데도 Fable로 작업하면 5시간 한도를 두 시간 만에 소진해 기다려야 했다. 요금제마다 과금 방식이 다르니 쓰기 전에 확인하는 편이 낫다. 그래서 디자인 방향을 잡거나 시안과 구현을 함께 볼 때만 Fable을 쓰고 문구 수정이나 이미 정해진 컴포넌트 구현에는 다른 모델을 썼다. 레이아웃과 시각 요소를 함께 다루는 작업이라 평소 코딩할 때보다 모델 차이가 눈에 잘 띈 것 같다.
다음 프로젝트에서는 이렇게 시작하려 한다
Claude Design은 4월 공개 직후부터 써왔다. 다만 개발자로 일해오면서 디자인 도구를 본격적으로 써볼 일은 많지 않았다. 그래서 어디까지 문서로 정하고 어디부터 화면에서 조정할지 기준을 잡는 데 시간이 걸렸다. Claude Design 자체도 아직 베타이고 공식 기능에는 코드베이스와 디자인 시스템을 가져오고 Claude Code로 넘기는 흐름도 있지만 세 프로젝트 모두에서 같은 방식으로 활용한 것은 아니다. 이 글은 도구 전체에 대한 평가라기보다 내 작업 방식을 찾아간 기록에 가깝다.
그렇다고 Pencil.dev나 Claude Design이 Figma를 대신한다고 생각한 것은 아니다. 프로젝트가 상용화되고 화면과 컴포넌트를 더 정교하게 관리해야 하거나 다른 사람과 디자인을 주고받는 단계가 오면 Figma도 제대로 써보고 싶다. 지금까지는 혼자 빠르게 방향을 찾는 방법을 익혔다. 다음에는 협업과 운영까지 포함한 디자인 작업도 경험해보고 싶다.
다음 프로젝트에서는 아래 순서로 시작해볼 생각이다.
- 브리프에서 고정할 것과 비교할 것을 나눈다.
- 색·타이포·간격 토큰과 기본 컴포넌트를 먼저 만든다.
- 같은 규칙 위에서 화면 방향을 두세 가지 비교한다.
- 선택한 화면과 디자인 시스템을 코딩 에이전트에 함께 넘긴다.
- 구현 뒤에는 대표 화면만 보는 대신 넓은 폭과 좁은 폭, 빈 상태와 오류 상태까지 대조한다.
각 도구가 맡는 일은 달랐다. Markdown 와이어프레임은 제품 구조를 이야기하기 좋았고 시안은 시각적 방향을 비교하는 데 도움이 됐다. 디자인 시스템은 그 결정을 여러 화면과 코드에 반복해서 적용하는 기준이 됐다. 다음 프로젝트에서는 이 세 가지를 처음부터 함께 두고 시작해보려 한다.
- #claude-design
- #pencil
- #design-system
- #ui
- #ai-tool