28장 출시 판정은 결과물이 아니라 증거 묶음으로 한다
완료 기준은 “담당자가 마음에 들어 함”이 아니다. Onda release packet에는 다음이 들어간다.
01 brief와 하지 않을 범위
02 before audit와 보존·개선·삭제 표
03 content source와 승인자
04 art direction과 reference observation
05 token·component·state contract
06 desktop·mobile·dialog baseline
07 keyboard·zoom·screen reader task 결과
08 performance budget와 field monitoring plan
09 dependency·font·image provenance
10 known issue, owner, due date, rollback plan
출시 회의는 세 가지 판정만 한다.
GO: blocker가 없고 핵심 task·접근성·성능 예산을 통과했다.CONDITIONAL GO: 사용을 막지 않는 issue의 owner와 기한이 있다.NO GO: 결제·예약·로그인 같은 핵심 task, 법적 권리, 개인정보, 심각한 접근성 문제가 남았다.
AI가 생성했다는 사실은 책임 주체가 아니다. Product owner는 서비스 결과, designer는 hierarchy와 state, engineer는 구현·보안·성능, content owner는 정확성, 조직은 권리·privacy를 승인한다. 한 사람이 여러 역할을 맡아도 항목은 생략하지 않는다.
5부 Onda Atelier 10일 리뉴얼 워크북
이제 원고를 읽는 데서 멈추지 않고 저장소의 before, site, figures를 직접 비교한다. 하루 60–90분을 기준으로 했지만 팀 workshop에서는 2–3일로 압축할 수 있다. 매일 산출물 하나와 판정 하나를 남긴다.
1일차 서비스 결정을 한 문장으로 쓴다
before/index.html을 열고 5초만 본 뒤 창을 가린다. 무엇을 제공하는지, 누구를 위한 것인지, 다음 행동이 무엇인지 적는다. 답을 찾지 못했다면 화면을 탓하기 전에 빠진 content를 표시한다.
작성 template:
사용자는 [상황]에서 [결정]하기 위해 이 page에 온다.
결정에 필요한 최소 증거는 [가격/시간/조건/신뢰]다.
primary action 뒤에는 [예상 가능한 결과]가 일어난다.
이번 범위에 포함하지 않는 것은 [기능]이다.
Onda 답: “도예 초보 직장인이 이번 주말 두 시간 수업을 예약할지 결정한다.” 결제와 회원가입은 제외한다. 판정은 다른 사람이 문장만 읽고 page에 필요한 첫 세 section을 추론할 수 있는가다.
2일차 before audit을 끝낸다
현재 page의 모든 제목, CTA, image, form, URL을 sheet에 옮긴다. 각 항목을 보존/개선/삭제/미정으로 분류하고 근거를 한 줄로 쓴다. “오래되어서”는 근거가 아니다. 사용성·정확성·권리·운영 비용 중 하나에 연결한다.
Mobile keyboard, 200% zoom, image off, 느린 network로 같은 task를 수행한다. 발견마다 재현 step을 쓴다.
[390×844] 첫 화면에서 서비스 종류가 보이지 않는다.
재현: 새 session → home → scroll하지 않음.
영향: 검색 결과에서 들어온 사용자가 이탈할 수 있음.
증거 수준: heuristic, analytics 미확인.
판정: 최소 10개 발견 중 사실과 가설이 구분되어 있는가.
3일차 실제 content와 edge fixture를 고정한다
제목을 꾸미기 전에 수업 이름, 대상, 시간, 가격, 포함 항목, 변경 조건, 주소, 운영 시간을 채운다. 개인정보나 영업기밀은 합성 fixture로 바꾼다. 긴 이름, sold out, network error도 동시에 만든다.
AI 요청:
주어진 사실만 사용해 class comparison copy를 작성하라.
없는 후기·자격·통계·효과를 만들지 마라.
각 card는 이름 20자, 설명 55자, 시간, 가격, 대상, availability를 갖는다.
정상 2개, sold-out 1개, 32자 제목 edge fixture 1개를 JSON으로 반환하라.
판정: 모든 숫자와 주장을 확인할 source·owner가 있는가. 없다면 sample임을 표시했는가.
4일차 세 방향을 같은 내용으로 발산한다
Quiet Workshop, Working Archive, Neighborhood Studio 세 방향을 만든다. Palette만 바꾸지 말고 정보 밀도, image 역할, type contrast, composition을 다르게 한다. 같은 실제 content와 viewport를 사용한다.
각 안을 1–5점으로 평가한다.
| 기준 | 가중치 | 질문 |
|---|---|---|
| 결정 명확성 | 30 | 5초 안에 대상과 행동을 아는가 |
| 브랜드 구별 | 20 | 업종 template와 구별되는 이유가 있는가 |
| content 적합 | 20 | 실제 긴 문장과 상태를 견디는가 |
| 접근성 | 15 | 순서·contrast·focus가 성립하는가 |
| 구현 가능성 | 15 | 예산·일정·stack 안에서 가능한가 |
가중 점수와 함께 가장 큰 실패 위험을 적는다. 판정: 승리안이 “예뻐서”가 아니라 서비스 결정과 증거로 설명되는가.
5일차 token과 component 계약을 만든다
site/style.css의 :root를 열어 color·spacing·type·container token을 역할별로 읽는다. 임의 값이 반복되는 위치를 찾되 한 번만 쓰는 모든 값을 억지로 token화하지 않는다.
Primary button, ClassCard, BookingDialog 세 component를 골라 anatomy·상태·content limit·keyboard·responsive rule을 작성한다. AI에게 새 component를 만들기 전에 기존 contract로 해결 가능한지 묻게 한다.
판정: 같은 의미가 서로 다른 색·radius·label로 만들어지면 test가 실패하도록 규칙을 쓸 수 있는가.
6일차 semantic 구조와 mobile 순서를 구현한다
CSS를 끄고 site/index.html을 읽는다. 제목 개요와 landmark가 서비스 구조를 설명하는지 확인한다. 그 다음 390px에서 section 순서를 보고 desktop 장식보다 task가 먼저 오는지 판단한다.
실습 check:
- skip link가 focus될 때 보인다.
- nav의 이름이 있다.
- 수업 card 제목이 page heading 아래에 있다.
- 모든 button이 keyboard로 실행된다.
- image에 width·height와 맥락에 맞는 alt가 있다.
- 320px에서 horizontal overflow가 없다.
판정: mouse 없이 수업 선택과 dialog 닫기를 완료하는가.
7일차 오류와 회복 경로를 완성한다
예약자 이름을 비우고 선택 내용 확인을 누른다. message가 보이고 focus가 field로 가는지 확인한다. 실제 서비스로 확장한다면 loading, slot conflict, network error, success fixture를 만든다.
오류 문장은 사용자 탓 대신 원인과 회복을 쓴다.
| 나쁜 문장 | 바꾼 문장 |
|---|---|
| 잘못된 입력입니다 | 이름을 입력하면 선택 내용을 확인할 수 있습니다 |
| 오류가 발생했습니다 | 자리를 확인하지 못했습니다. 입력은 보존했으니 다시 시도해 주세요 |
| 예약 불가 | 그 사이 자리가 찼습니다. 같은 날 16:00에는 3자리가 있습니다 |
판정: 실패 뒤 사용자가 처음부터 다시 하지 않고 다음 행동을 선택할 수 있는가.
8일차 실제 browser에서 visual·performance QA를 한다
Build script로 webbook과 site를 만든 뒤 고정 viewport에서 screenshot을 남긴다. Desktop home, mobile home, booking dialog 세 장은 같은 code에서 나와야 한다. DevTools에서 console error, failed request, image natural size, document overflow를 확인한다.
Lighthouse 같은 lab 도구는 회귀 신호로 쓰고 field CWV를 대신하지 않는다. Hero asset을 modern format으로 변환한 production candidate와 원본을 육안 비교한다. 작은 file이 banding과 손 artifact를 만들면 quality를 한 단계 올린다.
판정: 예산 초과에 owner와 해결 계획이 있으며 screenshot의 blocker가 0개인가.
9일차 다섯 번 관찰하고 한 번만 크게 바꾼다
목표 사용자와 가까운 사람 5명에게 같은 task를 준다. 말한 취향보다 행동을 기록한다. 발견을 모두 즉시 구현하지 않고 반복 빈도·영향·서비스 원칙으로 우선순위를 정한다.
가장 큰 문제 하나를 수정하고 전후 task를 다시 비교한다. 이때 여러 section과 copy를 동시에 바꾸지 않는다. 판정: 무엇을 바꿨기 때문에 어떤 행동이 달라졌는지 설명할 수 있는가.
10일차 권리·운영·rollback까지 묶어 출시한다
Image provenance, font license, icon license, package license, 개인정보 field, analytics consent를 확인한다. AI 생성물은 model·date·prompt·reference·human edit·사용 위치를 기록한다. 제3자 로고나 identifiable person이 우연히 생성되지 않았는지 눈으로 검수한다.
마지막 release note:
목표 task와 성공 기준:
통과한 browser·viewport:
접근성 확인 방식과 남은 issue:
performance budget과 monitoring URL:
asset·font·code 권리 기록 위치:
배포 owner / rollback 명령 / 의사결정자:
다음 측정일:
판정: 배포한 사람이 없어도 다른 사람이 되돌리고 문제를 재현할 수 있는가.
6부 막혔을 때 펼치는 실무 처방전
“프리미엄하게” 했는데 더 싸 보인다
검정 배경, 금색, 큰 serif, glass effect를 추가하지 않는다. 먼저 premium의 서비스 근거를 찾는다. 예약 가능 인원이 적은가, 재료가 특별한가, 설명이 세심한가, 시간 약속이 정확한가. 근거가 없다면 visual은 과장이다. 근거가 있다면 정보 밀도를 줄이고 소재와 과정의 증거를 크게 보여 준다.
Prompt 처방:
luxury visual cliché를 추가하지 말라. 높은 가격을 정당화하는 실제 증거
[6인 제한, 재료 포함, 개별 지도, 소성·배송]가 먼저 읽히도록 hierarchy를 수정하라.
black/gold/glass/shadow는 사용하지 않는다.
기존 사이트와 너무 달라 사용자가 길을 잃는다
리뉴얼 전 URL, navigation label, 주요 task의 시작 위치, account state를 비교한다. Brand refresh와 information architecture migration을 같은 날 강행하지 않는다. 이름을 바꿀 때는 한동안 옛 이름을 보조 text로 두고 analytics event가 이어지는지 확인한다.
AI가 매번 다른 component를 만든다
Screenshot만 주지 말고 component inventory, import path, 허용 variant, 금지 pattern을 제공한다. “기존 것을 재사용하라”가 아니라 PrimaryAction, TextLink, ClassCard 중 선택하고 새 component가 필요하면 기존 것으로 표현할 수 없는 상태를 먼저 쓰게 한다. CI에서 색 literal, 임의 spacing, 금지 dependency를 검사한다.
모바일에서 느낌이 완전히 달라진다
Desktop의 공간 관계를 그대로 유지하려 했는지 본다. Mobile의 첫 결정, 콘텐츠 순서, image crop을 별도 brief로 쓴다. 모든 장식을 지우는 대신 브랜드를 만드는 핵심 하나—Onda의 serif headline과 clay accent—는 보존한다.
생성 image는 멋진데 page와 어울리지 않는다
Subject보다 composition 실패일 가능성이 크다. Copy가 왼쪽이면 negative space 위치, viewport별 crop, 주변 surface color, caption 역할을 확인한다. Image를 다시 만들기 전에 CSS object-position, container ratio, copy 폭을 세 조합으로 비교한다.
실제 content를 넣자 layout이 무너진다
문구를 임의로 줄여 숨기지 않는다. 꼭 보여야 하는 정보, progressive disclosure 가능한 정보, 운영상 삭제 가능한 중복을 content owner와 나눈다. Card 높이를 강제로 맞추기보다 metadata와 CTA alignment를 grid로 고정하고 설명 길이 변화를 허용한다.
접근성 수정 뒤 디자인이 못생겨졌다
Focus ring, label, error를 숨겨 원상복구하지 않는다. 문제는 접근성이 아니라 system에 상태가 설계되지 않았던 것이다. Focus color를 별도 token으로 두고 offset·두께를 component에 맞춘다. Label과 helper text의 typographic hierarchy를 정리한다. 보이는 상태가 많아질수록 좋은 system은 더 안정적으로 보인다.
screenshot diff가 매번 흔들린다
Font·clock·animation·random fixture·browser version을 고정한다. Network image를 local fixture로 바꾸고 font ready 뒤 capture한다. 그래도 1px anti-alias 차이가 남으면 허용 threshold를 작게 두되 text 잘림과 위치 변화가 묻히지 않는지 sample diff로 검증한다.
AI가 없는 사실과 후기를 만든다
Prompt에 allowed facts와 unknown을 분리하고 source가 없는 claim은 [확인 필요]로 반환하게 한다. Fake review를 placeholder로도 publish하지 않는다. Testimonial이 없으면 과정·가격·변경 정책 같은 검증 가능한 신뢰로 page를 설계한다.
디자인 리뷰가 취향 싸움으로 끝난다
의견을 관찰→사용자 영향→원칙→최소 수정→검증으로 다시 쓰게 한다. 의사결정자가 선택할 수 있도록 서비스 기준의 trade-off 두 개를 제시한다. “대표님 취향”도 실제 조직 제약일 수 있지만, 사용자 task를 해친다면 위험과 evidence를 release note에 남긴다.
부록 A AI 디자인 지시문 카드
새 landing page가 아니라 방향을 만들 때
역할: 너는 visual decorator가 아니라 service design partner다.
사용자와 결정: [누가 무엇을 결정]
확인된 사실: [가격, 시간, 조건, 증거]
visual axes: [quiet↔noisy 등 네 축과 목표 점수]
반드시 보존: [URL, content, event, component]
금지: [cliché, fake claim, scope expansion]
같은 content와 task로 원칙이 다른 세 방향을 제안하라.
각 방향에 hierarchy, layout, typography, color role, image direction,
mobile order, failure risk를 적어라. 구현은 아직 하지 마라.
Screenshot을 비평할 때
화면에 실제 보이는 것만 관찰하고 의도를 상상하지 마라.
1) 강조 순위 1~7
2) 사용자가 5초 뒤 기억할 세 요소
3) service goal과 어긋난 계층·리듬·type·color·image·state
4) 변수 하나만 바꾸는 최소 수정
5) 변경을 판정할 task 또는 수치
새 section과 decorative element를 추가하지 마라.
Code로 옮길 때
source of truth: brief.md, content.json, tokens.json, components.md
변경 대상: [component/section]
유지할 invariant: semantic order, actual copy, analytics name, API contract
필수 상태: default, hover, focus, disabled, loading, empty, error, success
viewport: 320–1600px, zoom 200%, reduced motion
성능 예산: [JS/image/font]
권리: 제공한 local asset만 사용, 외부 download와 brand 복제 금지
산출: code diff, 선택 이유, test, screenshot, known issue
출시 전 red-team을 시킬 때
이 화면을 출시 반대 입장에서 검사하라. 단, 증거 없는 결함을 만들지 마라.
핵심 task 실패, keyboard/zoom, 긴 content, slow network, error recovery,
privacy, misleading copy, third-party rights, CWV budget, rollback을 확인한다.
각 항목은 severity, 재현 step, evidence, 최소 수정, 재검증으로 기록한다.
부록 B 최종 검수표
서비스와 콘텐츠
- [ ] page마다 사용자의 첫 결정과 primary action이 하나다.
- [ ] 가격·기간·대상·제약이 실제 source와 일치한다.
- [ ] 추상적 최상급과 fake review·fake metric이 없다.
- [ ] 행동 label이 다음 결과를 예측하게 한다.
- [ ] empty·loading·error·success 문구가 회복 방법을 말한다.
시각 시스템
- [ ] 네 개 visual axis와 반대 축을 설명할 수 있다.
- [ ] reference마다 가져온 원칙과 배제한 형태를 기록했다.
- [ ] color·type·space·focus가 semantic token을 사용한다.
- [ ] component의 모든 interaction state가 있다.
- [ ] mobile은 desktop 축소가 아니라 content 우선순위로 재구성됐다.
사용성과 접근성
- [ ] keyboard만으로 핵심 task를 끝낸다.
- [ ] focus가 항상 보이고 dialog 전후 위치가 자연스럽다.
- [ ] heading·landmark·label·status가 programmatically 연결된다.
- [ ] 320px·200% zoom·긴 한글·영문 혼합에서 손실이 없다.
- [ ] reduced motion에서도 정보와 feedback이 남는다.
성능과 운영
- [ ] LCP image dimension·format·loading priority가 적절하다.
- [ ] JS·image·font·third-party 예산을 기록했다.
- [ ] lab 결과와 field CWV를 구분한다.
- [ ] 주요 viewport와 상태의 승인 baseline이 있다.
- [ ] monitoring owner, known issue, rollback 절차가 있다.
권리와 신뢰
- [ ] image·font·icon·code dependency의 source와 license를 기록했다.
- [ ] AI asset의 model·date·prompt·reference·수정·사용 위치를 기록했다.
- [ ] 실제 인물·상표·저작물과 혼동될 요소를 검수했다.
- [ ] 개인정보를 최소화하고 저장·전송·동의를 정확히 알린다.
- [ ] 생성물은 사람의 창작적 선택과 검수 과정을 거쳤다.
부록 C 파일 안내와 실행
이 책의 모든 실습은 책과 함께 제공되는 project에서 실행한다.
ai-web-design-direction/
├── before/ # 의도적으로 평범하게 만든 리뉴얼 전 화면
├── site/ # Onda 완성 화면과 예약 interaction
├── figures/ # 원리 diagram·실제 capture·provenance
├── manuscript/book.md # 이 원고
├── test/ # 구조·접근성·권리 guardrail
└── scripts/ # build·capture·verify·local server
Node.js 20 이상에서 실행한다.
npm test
npm run build
npm start
Browser에서 http://127.0.0.1:4197/dist/site/index.html을 연다. 전체 검수는 npm run qa로 test→build→실제 browser capture→재build→원고·asset 검증 순서로 진행한다. Capture 환경에 Chrome/Chromium이 없으면 npm run capture만 건너뛰고 제공된 screenshot을 비교할 수 있지만, 자신의 변경을 승인할 때는 실제 target browser에서 다시 찍는다.
부록 D 저작권·AI 생성물 기록 원칙
이 책은 미국 저작권청의 AI 생성물 보고서를 참고하되 특정 국가의 법률 자문을 제공하지 않는다. 관할권과 계약에 따라 결과가 달라질 수 있으므로 상업 출판·광고 전에는 이용한 도구의 당시 약관과 필요한 전문가 검토를 거친다.
안전한 실무 원칙은 단순하다.
- 특정 작가·생존 디자이너·경쟁사의 고유한 표현을 복제하도록 지시하지 않는다.
- Reference는 원칙을 관찰하는 데 쓰고 source file·사진·문구를 가져오지 않는다.
- 생성 image와 code도 유사성, logo, 얼굴, text artifact, dependency를 사람이 확인한다.
- Prompt, model, date, input reference, human selection·edit, 사용 위치를 기록한다.
- Stock·font·icon은 “무료”라는 말 대신 정확한 license와 상업 이용 조건을 보존한다.
- 사용자의 입력과 업로드가 모델 학습·보관에 어떻게 쓰이는지 조직 정책으로 확인한다.
Onda는 실제 공방이 아닌 가상 서비스이며 주소도 가상이다. Hero image는 외부 reference 없이 이 책을 위해 생성했고 원 prompt를 공개했다. 독자는 자신의 결과물에 대해 별도 provenance를 작성해야 한다.
참고 자료
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2, https://www.w3.org/TR/WCAG22/
- web.dev, Defining Core Web Vitals thresholds, https://web.dev/articles/defining-core-web-vitals-thresholds
- MDN Web Docs, CSS container queries, https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Containment/Container_queries
- Design Tokens Community Group, Design Tokens Format Module 2025.10, https://www.designtokens.org/tr/2025.10/
- Figma Help Center, Get started with Figma AI, https://help.figma.com/hc/en-us/articles/24039793359767-Get-started-with-Figma-AI
- Figma Help Center, Create and edit a functional prototype or web app, https://help.figma.com/hc/en-us/articles/31304485164695-Create-and-edit-a-functional-prototype-or-web-app
- Figma Help Center, Use AI tools in Figma Sites, https://help.figma.com/hc/en-us/articles/31433998164375-Use-AI-tools-in-Figma-Sites
- U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability, https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf
맺음말 디자인 품질은 좋은 취향을 반복 가능한 결정으로 바꾸는 일이다
AI는 빠르게 화면을 만든다. 그래서 무엇을 만들지보다 무엇을 승인하지 않을지가 더 중요해졌다. 보라색 gradient를 금지하는 것만으로 고유한 서비스가 생기지는 않는다. 사용자의 결정, 실제 content, visual axis, 상태 계약, 접근성, 성능, 권리라는 기준이 함께 있어야 한다.
좋은 AI 웹 디자인은 prompt의 우연한 성공이 아니다. Brief가 방향을 만들고, 실제 content가 layout을 압박하고, component contract가 반복을 통제하고, browser evidence가 출시를 판정하는 시스템이다. 이 과정을 익히면 AI 결과가 마음에 들 때까지 다시 뽑지 않는다. 왜 부족한지 말하고, 가장 작은 변수를 고치고, 실제 사용자의 행동으로 확인할 수 있다.
기능이 작동하는 화면에서 신뢰할 수 있는 서비스로 가는 마지막 거리는 사람의 디렉션이다. 이제 그 거리를 감으로 건너지 않아도 된다.