AI에게 앱 화면 디자인을 맡겨 봤습니다. 언뜻 보면 꽤 그럴듯합니다. 그런데 하나하나 재 보니 화면 네 장에 글자 크기가 13가지, 색도 13가지였습니다. 흐려서 잘 안 읽히는 글자는 24곳이었습니다.
같은 일을 규칙과 검사를 갖춘 작업 틀 안에서 시키고 몇 번 다듬었더니, 글자 크기는 다섯 단계로 정리됐고 안 읽히는 글자도, 누르기 어려운 버튼도 하나도 남지 않았습니다.
이 작업 틀을 하네스(harness) 라고 부릅니다. AI가 일하는 폴더에 넣어 두는 규칙 파일, 검사 스크립트, 역할을 나눈 에이전트, 그리고 정해진 순간에 자동으로 도는 명령(훅)의 묶음입니다.
이 글에서는 다음을 차례로 봅니다.
- 실험: 하네스 없이 한 번, 하네스 안에서 한 번
- 숫자로 본 전후 비교와 그 비용
- 하네스의 생김새: 8단계와 사람 승인 3곳
- 디자인 기법 8가지를 규칙과 검사로 바꾸기
- 버전 1에서 4까지 다듬기와 객관 지표
- 검사기가 틀렸을 때
- 무료로 피그마에 그리기: Talk to Figma
- 한계
숫자 읽는 법. [직접 측정] 은 저희가 직접 돌려서 잰 숫자, [표준] 은 웹 접근성 표준 WCAG에 적힌 기준, [공식 문서] 는 만든 쪽(애플 등)이 직접 낸 가이드입니다. [경험칙] 은 표준이 아니라 이 하네스가 스스로 정한 목표라는 뜻입니다.
1. 실험: 같은 부탁을 두 번
- 도구. 클로드 코드(Claude Code)는 터미널에서 파일을 읽고 명령을 실행하는 AI 코딩 도구입니다. 피그마(Figma)는 앱 화면을 그리는 디자인 도구입니다. 요즘은 AI가 피그마에 직접 화면을 그릴 수 있어서, 디자인 초안을 AI에게 맡기는 사람이 많아졌습니다.
- 과제. 서울시 공공자전거 따릉이의 대여소 현황 앱입니다. 데이터는 서울 열린데이터광장의 서울시 공공자전거 실시간 대여정보(OA-15493)를 썼습니다.
- 조건. 같은 기획 문서, 같은 모델(Claude Opus), 같은 부탁 문장입니다. "화면은 3~4개 정도면 돼"까지 똑같습니다. 하나(A)는 기획 문서와 데이터만 있는 빈 폴더에서, 다른 하나(B)는 하네스 폴더에서 시작했습니다.
A는 목록, 상세, 빈 화면, 오류 화면 네 장입니다. 요약 카드도 있고 색도 풍부합니다.
B는 다섯 장입니다. 로딩 화면까지 있고 훨씬 단정합니다. 대신 좀 밋밋합니다.
2. 숫자로 본 전후, 그리고 비용
두 피그마 파일에서 모든 레이어를 같은 스크립트로 꺼내 비교했습니다(npm run compare). A에는 정해 둔 토큰이 없으니, "규칙 위반 수" 대신 서로 다른 값이 몇 개인지로 셌습니다.
| 지표 [직접 측정] | A 하네스 없음 | B 하네스 |
|---|---|---|
| 서로 다른 색 | 13 | 7 |
| 서로 다른 글자 크기 | 13 | 4 |
| 서로 다른 간격 값 | 15 | 6 |
| 서로 다른 모서리 둥글기 | 6 | 2 |
| 변수에 안 묶인 색 비율 | 100% | 0% |
| 명도 대비 미달 글자 | 24 | 0 |
| 44px보다 작은 터치 영역 | 3 | 0 |
Frame 12 같은 기본 레이어 이름 | 10 | 0 |
| 빠진 상태(5개 중) | 1 (로딩) | 0 |
| 에이전트 작업 시간 | 3.1분 | 17.9분 |
| 비용 | $1.41 | $7.86 |
| 블라인드 비평 점수 | 11/20 | 12/20 |
일관성과 접근성은 확실히 좋아졌습니다. 대신 비용도 그대로 적습니다. 시간은 약 5.8배, 비용은 약 5.6배였습니다. 기획을 정리하고, 와이어프레임을 그리고, 사람 확인에서 멈추는 단계가 있기 때문입니다.
숫자가 하나 더 있습니다. 만든 과정을 모르는 비평 에이전트에게 화면과 기획 문서만 주고 채점하게 했더니 20점 만점에 11점과 12점, 거의 같았습니다. 규칙과 검사는 일관성과 접근성을 고쳐 주지만, 보기 좋은지까지 해결해 주지는 않는다는 뜻입니다. 둘 다 "데이터 기준 시각이 안 보인다", "목록이 누를 수 있어 보이지 않는다", "1대 남은 곳과 넉넉한 곳이 같은 색이다"라는 같은 문제를 놓쳤습니다.
3. 하네스의 생김새: 8단계와 사람 승인 3곳
작업은 여덟 단계로 흘러갑니다.
- 기획 문서 → 2. 레퍼런스 조사 → 3. 정보 구조 → 4. 와이어프레임 → 5. 디자인 시스템 → 6. 피그마 화면 → 7. 검증 → 8. 개발자에게 넘기는 핸드오프
단계마다 스크립트가 통과 / 실패 / 아직 안 함을 판정합니다. 굵게 표시한 세 단계에서는 사람이 승인해야 다음으로 넘어갑니다.
폴더 안에는 단계별로 일을 나눠 맡는 에이전트 다섯(조사, 정보 구조, 디자인 시스템, 피그마 작업, 비평), 순서를 묶은 스킬, 검사 스크립트와 훅이 있습니다. 피그마에 쓰는 일은 figma-operator 에이전트 하나만 하고, 비평가 에이전트는 고치지 않고 점수만 제안합니다.
설계 원칙은 하나입니다. 기계가 잴 수 있는 건 기계가 재고, 사람은 기계가 못 보는 것만 본다. 그래서 디자인 기법마다 "숫자로 잴 수 있나?"를 물었습니다. 잴 수 있으면 규칙 파일과 검사로, 못 재면 사람 체크리스트로 보냈습니다.
4. 디자인 기법 8가지 → 규칙과 검사
| 기법 | 쉬운 뜻 | 하네스 장치 | 검사가 보는 것 |
|---|---|---|---|
| 디자인 토큰 | 색·간격 같은 값에 이름을 붙이고 화면은 이름만 쓰기 | tokens.json + 같은 이름의 피그마 변수 | 모든 색이 변수에 연결됐나, 토큰에 없는 색은 없나 |
| 타입 스케일 | 글자 크기를 몇 단계로 정하고 일정한 비율로 벌리기 | 토큰의 허용 크기 | 그 밖의 크기는 오류, 단계 수와 단계 사이 평균 비율 계산 |
| 4/8 그리드와 여백 | 크기·간격을 4의 배수로, 좌우 여백 통일 | 간격 토큰, 좌우 16 | 오토 레이아웃 간격·패딩이 토큰에 있나, 위치가 4 단위인가 |
| 명도 대비 | 글자와 배경의 밝기 차이 | WCAG 2.2 기준 | 글자마다 가장 가까운 부모 배경색과 대비 계산 |
| 터치 영역 | 손가락으로 누를 수 있는 크기 | components.json에 누를 수 있는 컴포넌트 표시 | 44보다 작으면 오류 |
| 상태 설계 | 불러오는 중·비었을 때·오류일 때 화면 | ia.json에 화면별 필요한 상태 | 그 프레임이 피그마에 없으면 오류 |
| 컴포넌트와 반복 | 같은 것은 어디서나 같은 모양 | 컴포넌트 목록 | 화면마다 높이·색이 다르면 경고, 기본 레이어 이름 잡기 |
| 마이크로카피 | 버튼과 안내의 짧은 문구 | copy.json에 말투·금지어·글자 수 한도 | "오류가 발생", "죄송합니다"는 오류, 버튼 6자 넘으면 경고 |
기준이 어디서 왔는지는 구분해 둡니다.
- 명도 대비는 경험칙이 아니라 표준입니다. 본문 글자는 배경과 4.5:1 이상, 큰 글자는 3:1 이상 (WCAG 2.2 SC 1.4.3). 아이콘이나 입력창 테두리 같은 글자 아닌 요소도 3:1 이상입니다 (SC 1.4.11) [표준].
- 터치 영역 44포인트는 애플 Human Interface Guidelines의 권장값입니다 [공식 문서].
- 글자 크기 다섯 단계 이하, 정렬선 4개 이하, 간격 토큰 준수율 95% 이상 같은 숫자는 표준이 아니라 이 하네스가 정한 목표입니다 [경험칙].
실제로 잡힌 예입니다. 다듬는 중에 손으로 고친 요약 카드 사이 간격 하나가 2px이었습니다. 그 상태를 다시 넣어 검사하면 "간격 토큰 밖"이라고 바로 오류가 납니다. 눈으로는 거의 안 보이는 차이입니다. 지금 버전 화면에 규칙을 전부 돌리면 오류 0, 경고 0입니다 [직접 측정].
반대로 시각적 위계, 핵심 숫자 하나 먼저 보여 주기, 색은 의미에만 쓰기, 가까운 것끼리 묶기 같은 건 숫자로 판정하기 어렵습니다. 이런 건 사람 체크리스트 12항목과 비평 에이전트에게 맡겼습니다. 비평가는 점수를 제안만 하고, 확정은 사람이 합니다.
마지막 장치는 훅입니다. 정해진 순간에 클로드 코드가 대신 실행하는 명령입니다. 피그마에 쓰기 직전에 figma-guard가 먼저 돕니다. 디자인 시스템 승인이 없는 상태에서 프레임을 만들려 하면 종료 코드 2로 막습니다. 승인된 파일이 아닌 다른 파일이나 다른 팀에 쓰는 것도 같은 방식으로 막습니다. 규칙을 문서에만 적지 않고 실행 단계에서 막는 것입니다.
5. 버전 1에서 4까지, 그리고 지표
- 버전 1은 앞에서 본 하네스 결과(B)입니다.
- 버전 2는 비평을 받아 기준 시각, 오른쪽 화살표, 1~2대일 때 호박색 "얼마 없음" 표시, 맨 위 요약 카드 세 개를 넣었습니다. 이때 2px 간격이 린트에 걸렸고, 4px 격자에 안 맞던 높이 두 개도 경고로 잡혀 고쳤습니다.
- 버전 3은 지도형으로 바꿨습니다. 실제 공유 자전거·이동 앱 일곱 개를 살펴보니 공통 패턴이 있었습니다. 숫자가 적힌 핀, 0대일 때 다른 색, 대여·반납 전환, 떠 있는 검색창, 아래에서 올라오는 시트, 기준 시각. 데이터는 망원·합정·서교 일대 17곳의 실제 스냅샷이고, 지도 바탕은 오픈스트리트맵 데이터로 직접 그렸습니다.
- 버전 4는 버전 3만 본 비평 에이전트의 지적 12건을 하나씩 디자인 기법으로 바꿔 고쳤습니다.
| 비평 | 쓴 기법 | 고친 것 |
|---|---|---|
| 핀끼리 겹친다 | 클러스터링, 충돌 회피 | 28px 안의 핀은 하나로 묶어 합계와 "2곳" 배지 |
| 0대 핀이 지도를 덮는다 | 색은 의미에만, 시각적 무게 조절 | 0대는 작은 흰 원 + 빨간 테두리 |
| "16대 / 거치대 15"가 헷갈린다 | 핵심 숫자 하나 먼저 | 숫자 하나만 크게, 나머지는 보조 줄 |
| 위도·경도 소수점 | 점진적 공개 | 삭제 |
| 오류 배너 안 초록 버튼 | 시각적 위계 | 빨간 막대 + 글자 버튼 |
| 위치를 안 쓰는데 내 위치 버튼 | 거짓 단서 없애기 | 버튼 삭제 |
느낌만이 아니라 숫자로도 비교합니다. npm run metrics는 피그마 노드에서 객관 지표를 계산합니다 [직접 측정].
| 지표 | v2 | v3 | v4 | 기준 |
|---|---|---|---|---|
| 명도 대비 통과율 | 100% | 100% | 100% | 100% [표준] |
| 명도 대비 최소 | 5.79:1 | 5.76:1 | 5.76:1 | 4.5:1 이상 [표준] |
| 터치 영역 44pt 이상 | 100% | 100% | 100% | 100% [공식 문서] |
| 글자 크기 단계 | 4 | 4 | 5 (13/15/17/22/40) | 5단계 이하 [경험칙] |
| 타입 스케일 평균 비율 | 1.63 | 1.29 | 1.35 | 참고 |
| 화면당 왼쪽 정렬선(지도 제외) | 2.4 | 4.4 | 3.1 | 4 이하 [경험칙] |
정렬선은 글자와 카드가 시작하는 세로 줄의 개수입니다. 버전 3에서 4.4개까지 늘었다가, 검색창 글자를 목록 이름과 같은 열로 옮겨 버전 4에서 3.1개로 줄었습니다.
6. 검사기가 틀렸을 때
버전 3에서 경고가 11개 나왔는데, 대부분 검사기 쪽 문제였습니다. 화면보다 큰 지도 바탕 레이어를 격자 위반으로 보고, 오른쪽 여백에 맞춘 버튼을 왼쪽 기준 격자로 쟀던 겁니다.
이럴 땐 디자인을 검사에 맞춰 비틀지 않았습니다. 규칙을 고친 다음, 그 경우를 테스트로 남겼습니다. npm test를 돌리면 13개가 모두 통과합니다 [직접 측정].
7. 무료로 피그마에 그리기: Talk to Figma
피그마 공식 MCP는 무료 요금제에서 호출 수 한도가 있어서, 반복해서 고치다 보면 금방 막힙니다. 실제로 이 실험의 마지막 수정도 한도 때문에 멈췄습니다. 그래서 버전 2부터는 오픈소스 플러그인 Talk to Figma(grab/cursor-talk-to-figma-mcp)를 썼습니다. MIT 라이선스입니다.
구조는 이렇습니다.
- 피그마 데스크톱 앱에서 플러그인을 켜고, 이 컴퓨터에만 열린 중계 서버에 연결하면 채널 이름이 나옵니다.
- 터미널에서 그 채널로 명령을 보내면 플러그인이 피그마 안에서 실행합니다.
- 원래 플러그인은 정해진 명령만 실행합니다. 저희는 로컬 사본에 플러그인 코드를 그대로 실행하는
run_script명령을 하나 추가했습니다.
설정은 Plugins 메뉴의 Development에서 manifest 파일로 플러그인을 불러오면 끝입니다. 버전 4 화면 페이지를 비워 둔 상태에서 화면을 그리는 스크립트를 채널로 보내면, 몇 초 만에 지도 화면부터 목록까지 여덟 장이 다시 그려집니다. 핀 묶음, 기준 시각, 대여·반납 전환이 모두 컴포넌트와 변수로 그려져 있고, 이 과정에서 공식 MCP 호출은 0번이었습니다 [직접 측정].
8. 한계
- 보기 좋은 디자인은 규칙이 만들지 않습니다. 블라인드 비평 점수는 11 대 12로 거의 같았습니다.
- 비싸집니다. 시간 약 5.8배, 비용 약 5.6배. 작은 화면 하나를 빨리 보고 싶을 때는 하네스가 과합니다.
- 실험은 한 번씩입니다. 같은 조건을 여러 번 돌린 평균이 아니라 A·B 각 1회 결과입니다. B의 사람 승인 단계는 실험 진행자가 대신 답했습니다.
- 기계 검사가 못 잡은 결함도 있었습니다. 출처 문구가 단어 중간에서 줄바꿈된 것, 상세 화면에서 거치대 수가 두 번 나온 것은 검사를 통과했습니다.
- 경험칙 숫자(다섯 단계, 정렬선 4개 등)는 이 하네스의 목표일 뿐 정답이 아닙니다.
정리하면 순서는 이렇습니다. 하나, 하네스 없이 한 번 맡기고 결과를 숫자로 잰다. 둘, 잴 수 있는 기법은 토큰, 규칙 파일, 린트로 바꾼다. 셋, 잴 수 없는 위계와 인상은 사람 승인과 비평으로 본다. 넷, 검사기가 틀리면 디자인이 아니라 검사를 고치고 테스트로 남긴다. 규칙은 일관성과 접근성을 지켜 주고, 좋은 디자인은 그 위에서 사람이 고르는 겁니다.
영상으로 보기
같은 과정을 실제 터미널과 피그마 화면으로 영상에 담았습니다.
출처
- 서울특별시, 서울시 공공자전거 실시간 대여정보 (OA-15493) — 공공누리 제1유형
- W3C, WCAG 2.2 Understanding SC 1.4.3 Contrast (Minimum) · SC 1.4.11 Non-text Contrast
- Apple, Human Interface Guidelines — Buttons
- Design Tokens Community Group, Design Tokens Format
- Nielsen Norman Group, Progressive Disclosure
- grab/cursor-talk-to-figma-mcp — MIT
- 지도 바탕: © OpenStreetMap contributors (ODbL)
