AI 웹 디자인 디렉팅

1장 기능 완성과 서비스 완성을 구분한다

예약 버튼이 열리고 폼이 제출되면 기능은 동작한다. 그러나 사용자는 “어떤 수업이 나에게 맞는가”, “언제·얼마인가”, “초보도 가능한가”, “취소할 수 있는가”를 먼저 판단한다. 이 질문에 답하지 못하면 기능은 있어도 서비스가 아니다.

기능 목록을 사용자 결정으로 바꾼다.

AI에게 “도예 클래스 landing page를 만들어 줘”라고 하면 업종의 평균 이미지를 만든다. 판단에 필요한 실제 조건이 없기 때문이다. 먼저 서비스의 결정, 증거, 다음 행동을 써야 한다.

주 사용자: 도예를 처음 해 보는 25–45세 직장인
첫 결정: 이번 주말 두 시간 수업을 예약해도 되는가
필요 증거: 초보 가능, 6명, 120분, 68,000원, 성수, 완성품 수령 3–4주
망설임: 결과가 못생길까, 준비물이 필요한가, 일정 변경이 가능한가
primary action: 이번 주 수업 보기
secondary action: 작업실 방식 이해하기

↑ 목차로 돌아가기

2장 “예쁘다”를 여섯 개의 관찰 가능한 층으로 바꾼다

품질을 취향으로만 말하면 AI도 팀도 수정 방향을 잃는다. 화면을 여섯 층으로 본다.

1. 서비스: 사용자가 내릴 결정과 행동이 분명한가
2. 콘텐츠: 실제 이름·가격·조건·오류가 있는가
3. 아트 디렉션: 어떤 감각을 왜 선택했는가
4. 시스템: token과 component가 반복을 통제하는가
5. 상태: mobile·loading·empty·error·disabled가 있는가
6. 검증: 과제·접근성·성능·visual diff를 통과했는가

한 층을 건너뛰고 다음 층을 polishing하면 비용이 커진다. 정보 구조가 틀렸는데 shadow를 다듬거나, hero copy가 추상적인데 사진만 바꾸는 식이다.

리뷰에서는 “촌스럽다” 대신 다음처럼 말한다.

현재 hero의 제목·설명·두 CTA가 모두 비슷한 시각 무게다.
첫 방문자가 5초 안에 수업 대상과 다음 행동을 찾기 어렵다.
제목은 결과, 설명은 대상·규모, primary CTA는 가장 가까운 날짜로 역할을 분리하자.
검증: 5초 노출 뒤 사용자가 서비스와 첫 행동을 말할 수 있는가.

↑ 목차로 돌아가기

3장 기존 사이트를 취향이 아니라 증거로 감사한다

리뉴얼 전 screenshot을 보며 바로 새 palette를 고르지 않는다. 현재 사이트가 지키는 것과 방해하는 것을 기록한다. Onda 이전 화면에는 “특별한 경험”, “최고의 강사”, “지금 시작하기”, emoji icon, 같은 card 세 개가 있다. 오류는 못생김이 아니라 구분할 정보가 없음이다.

감사는 네 가지 evidence를 모은다.

• 행동: analytics funnel, search query, form abandon, support 문의
• 콘텐츠: 오래된 가격, 중복 문구, 빠진 조건, 실제 photo 권리
• interface: keyboard, zoom, mobile overflow, error state
• performance: field LCP·INP·CLS, image weight, font request

데이터가 없으면 모른다고 표시한다. AI에게 analytics가 있다고 상상해 원인을 만들게 하지 않는다. 먼저 heuristic과 5명 내외의 task observation으로 가설을 만들고 계측을 시작한다.

관찰: 모든 class card가 “자세히 보기”다.
영향: 클릭 전 가격·시간·차이를 알 수 없다.
가설: 비교 정보가 card에 있으면 불필요한 detail 왕복이 줄어든다.
검증: 세 수업 중 조건에 맞는 하나를 고르는 시간과 오선택률.

↑ 목차로 돌아가기

4장 리뉴얼 범위를 보존·개선·삭제로 나눈다

리뉴얼은 모든 것을 새로 그리는 일이 아니다. 기존 사용자의 기억, 검색 노출, 운영 절차를 지켜야 한다. URL, page title, 핵심 content, conversion event, form field, analytics property를 inventory로 만든다.

scope에는 “하지 않을 것”도 쓴다. 결제, 회원가입, 후기 system을 이번 리뉴얼에서 만들지 않는다고 명시하면 AI가 불필요한 dashboard와 login을 추가하지 않는다.

↑ 목차로 돌아가기

5장 reference는 복사 대상이 아니라 원칙의 증거다

무드보드에 경쟁사 screenshot을 모으고 “이렇게 만들어 줘”라고 하면 유사성과 권리 위험이 커진다. reference마다 가져올 속성과 가져오지 않을 형태를 분리한다.

Reference A에서 가져올 것: 넓은 여백과 낮은 정보 밀도
가져오지 않을 것: header 구조, serif font 조합, 문구

Reference B에서 가져올 것: 과정 중심의 손 close-up
가져오지 않을 것: 촬영 구도 그대로, 색 보정, 제품 배열

세 종류를 섞는다.

• 같은 업종: 사용자가 기대하는 정보와 금기
• 다른 업종: 원하는 감정과 편집 리듬
• 물성 reference: 재료, 빛, surface, 움직임

AI에게 URL을 던지는 대신 관찰을 언어로 바꾼다. “A 사이트처럼”보다 “large type 한 개, thin divider, asymmetrical grid, natural side light, clay dust가 보이는 surface”가 재현 가능하고 독창적이다.

2부 AI가 따를 수 있는 아트 디렉션을 만든다

↑ 목차로 돌아가기

6장 한 장짜리 design brief에 성공과 금지를 함께 쓴다

좋은 brief는 긴 브랜드 서사가 아니라 반복되는 선택을 줄이는 문서다.

서비스: 성수의 6인 도예 workshop 예약
사용자: 처음 도예를 시도하는 직장인
핵심 task: 이번 주 가능한 입문 수업 하나를 고른다
브랜드 약속: 완벽한 결과보다 손의 감각과 사용할 장면을 남긴다
시각 축: tactile / quiet / editorial / imperfect
반대 축: glossy / playful / techy / luxurious
primary content: 날짜, 남은 자리, 시간, 가격, 초보 여부
primary action: 이번 주 수업 보기
필수 상태: mobile nav, booking dialog, field error, sold out
금지: 보라 gradient, emoji icon, pill 남용, “특별한 경험”, fake review
검증: 5초 이해, 예약 task, WCAG 2.2 AA, field CWV

AI에게 positive constraint만 주면 빈틈을 generic pattern으로 채운다. 금지 목록과 이유가 중요하다. “rounded corner 금지”가 아니라 “도예의 단단한 material 감각을 위해 card radius를 거의 쓰지 않는다”처럼 원칙을 연결한다.

↑ 목차로 돌아가기

7장 형용사를 시각 변수로 번역한다

“따뜻하고 세련되게”는 서로 다른 사람이 다르게 해석한다. 형용사를 layout·type·color·image·motion으로 번역한다.

Onda의 visual axis는 quiet ↔ noisy, tactile ↔ glossy, editorial ↔ dashboard, human ↔ automated 네 개다. 각 화면을 1–5로 평가하면 “고급” 같은 단어보다 수정 방향이 보인다.

↑ 목차로 돌아가기

8장 먼저 information hierarchy를 흑백으로 해결한다

color와 image를 끄고도 순서가 읽혀야 한다. hero에서 사용자가 보아야 할 순서는 service category→promise→대상과 규모→primary action→가장 가까운 availability다. headline이 크다고 hierarchy가 완성되는 것은 아니다. 주변 여백, alignment, contrast, repetition이 함께 만든다.

한 viewport에 primary action이 여러 개면 실제로는 primary가 없다. Navigation의 “예약하기”와 hero의 “이번 주 수업 보기”는 같은 intent를 공유하지만 맥락을 다르게 표현한다. secondary link는 visual weight를 낮춘다.

AI critique prompt:

이 화면에서 글자를 읽지 않고도 보이는 강조 순서를 1~7위로 적어라.
사용자의 목표 순서와 다른 항목을 찾고, 크기·여백·위치·색 중 하나만 바꾸는
최소 수정안을 제안하라. 새 section이나 decorative element를 추가하지 마라.

↑ 목차로 돌아가기

9장 layout을 12-column 숫자보다 관계로 설계한다

Grid는 12칸 자체가 아니라 alignment를 공유하는 약속이다. Onda desktop hero는 copy 0.82, image 1.18 비율이다. 왼쪽 copy는 좁아 headline에 의도적 줄바꿈이 생기고 오른쪽 image는 물성을 보여 줄 면적을 확보한다.

Section마다 같은 max-width card grid를 반복하지 않는다. hero는 split, principle은 full bleed strip, class는 bordered editorial grid, story는 dark three-column, visit은 asymmetrical two-column이다. 다양하지만 공통 gutter와 type scale이 연결한다.

여백을 “남는 공간”으로 보지 않는다. 관련 항목은 가까이, 다른 결정은 멀리 둔다. 8px 배수는 유용한 출발점이지 모든 간격을 같게 만드는 규칙이 아니다. Onda는 token --space-1부터 --space-5를 역할로 쓴다.

↑ 목차로 돌아가기

10장 typography로 브랜드의 목소리와 읽기 속도를 조절한다

Font를 많이 쓰면 개성이 생기는 것이 아니다. Onda는 system sans로 정보와 control을, Georgia 계열 serif fallback으로 editorial headline을 표현한다. 외부 web font를 불러오지 않아 권리와 performance risk를 줄인다. 실제 출시에서 상용 font를 쓰면 web embedding license와 pageview 조건을 확인한다.

Fluid scale은 viewport에 맞춰 부드럽게 변한다.

:root {
  --step-0: clamp(1rem, .95rem + .22vw, 1.12rem);
  --step-2: clamp(2rem, 1.5rem + 2vw, 3.2rem);
  --step-3: clamp(3.6rem, 2.4rem + 5vw, 7.2rem);
}

한글은 영문보다 같은 크기에서 밀도가 높아 보일 수 있다. line-height, word break, 조사만 다음 줄에 남는 현상, 숫자와 단위 spacing을 실제 문장으로 본다. image 안에 text를 굽지 않는다. 번역·확대·screen reader·검색에서 모두 손실된다.

↑ 목차로 돌아가기

11장 color는 palette가 아니라 역할과 대비로 정한다

AI는 여러 색을 조화롭게 추천할 수 있지만 어디에 얼마나 쓸지는 서비스 규칙이다. Onda는 canvas, surface, ink, muted, olive, clay, line, focus 역할을 먼저 정의한다.

--canvas: #f1eee6;
--surface: #fbfaf5;
--ink: #272d25;
--muted: #60675d;
--olive: #3f4938;
--clay: #a64f32;
--focus: #155bd5;

clay는 브랜드 강조, olive는 primary action, blue는 keyboard focus다. 브랜드 palette 안에 focus를 억지로 가두지 않는다. 상태 color는 success·warning·error 의미를 text와 icon에 함께 표시하고 color만으로 전달하지 않는다.

WCAG 2.2 AA의 일반 text contrast는 4.5:1, large text는 3:1을 기본 검사점으로 사용한다. 실제 font weight와 background image 위 overlay도 측정한다. disabled text를 너무 흐리게 만들어 정보가 사라지지 않게 한다. “고급스러운 연회색”이 읽히지 않으면 품질이 아니다.

↑ 목차로 돌아가기

12장 image direction에 subject·crop·negative space를 명시한다

좋은 hero image는 아름다운 사진이 아니라 copy와 layout이 함께 작동하는 asset이다. Onda prompt에는 세 bowl, 작업하는 손, clay dust, 오른쪽 subject, 왼쪽 negative space, late-afternoon side light를 썼다. “도예 공방 감성 사진”만 요청하지 않았다.

Subject: 장인의 얼굴이 아니라 손과 아직 마르지 않은 세 그릇
Story: 결과 판매가 아니라 만드는 시간
Composition: subject는 오른쪽 55%, 왼쪽은 copy용 calm negative space
Light: 따뜻한 창문 side light, glossy studio flash 금지
Texture: clay dust와 손자국 보존, 과도한 retouch 금지
Avoid: stock smile, logo, text, watermark, duplicated tools, 잘못된 손

생성 뒤 손가락·도구 중복·그림자·그릇 rim·text artifact를 100% 확대해 본다. 모바일 crop에서 주 subject가 잘리지 않는지 object-position을 확인한다. alt text는 prompt를 복사하지 않고 현재 페이지에서 image가 전달하는 의미를 쓴다.

이 책의 hero는 내장 이미지 생성 도구로 새로 만들었다. 원본 prompt, 생성일, 외부 reference 없음, 사용 위치를 figures/PROVENANCE.md에 기록했다. 실제 출판·광고에서는 이용한 모델의 당시 약관과 조직의 법률 정책을 다시 확인한다.

↑ 목차로 돌아가기

13장 실제 문구가 layout을 결정하게 한다

의미 없는 임시 채움 문장은 카드 높이와 줄바꿈 문제를 숨긴다. “초보자 클래스” 대신 “나만의 아침 그릇”, “120분”, “68,000원”, “소성 후 3–4주”처럼 선택에 필요한 문장을 먼저 쓴다.

좋은 microcopy는 세 질문에 답한다.

1. 지금 무엇을 보고 있는가?
2. 행동하면 무엇이 바뀌는가?
3. 실패하거나 마음이 바뀌면 어떻게 하는가?

지금 시작하기 대신 이번 주 수업 보기, 자세히 보기 대신 자리 확인, 제출 대신 선택 내용 확인을 쓴다. 버튼 근처에 “결제는 진행하지 않는 교육용 화면”처럼 실제 결과를 알린다.

AI에게 tone을 요청할 때 “친근하게”만 말하지 않는다.

문장은 차분하고 구체적으로 쓴다. 감탄사와 과장형 최상급을 쓰지 않는다.
초보자를 어린아이처럼 대하지 않는다. 한 문장에는 하나의 정보만 둔다.
가격·시간·변경 조건은 시적 표현보다 정확성을 우선한다.
금지: 특별한, 최고의, 잊지 못할, 당신의 창의력을 깨우세요.

3부 AI를 생성기가 아니라 디자인 동료로 사용한다

↑ 목차로 돌아가기

14장 한 번에 완성 대신 발산→비평→수렴을 시킨다

첫 prompt에서 전체 website를 완성하려 하지 않는다. brief를 고정하고 서로 다른 원칙의 세 방향을 만든다.

• A Quiet Workshop: 큰 여백, 낮은 밀도, 과정 사진 한 장
• B Working Archive: 도구와 과정 기록, 높은 정보 밀도, 날짜 중심
• C Neighborhood Studio: 지도·시간표·사람 이야기, local community 중심

각 방향에서 같은 content와 task를 사용해야 비교할 수 있다. 방향마다 다른 기능까지 만들면 visual principle이 아니라 scope를 비교하게 된다.

같은 정보 구조와 문구를 유지한 채 세 개의 art direction을 제안하라.
각 방향은 layout, type, color, image crop, interaction rhythm이 달라야 한다.
장점 두 개, 실패 가능성 두 개, mobile에서 지킬 원칙을 함께 적어라.

발산은 variation 수가 아니라 선택 축의 거리다. 세 안이 palette만 다르면 다시 한다.

↑ 목차로 돌아가기

15장 “더 예쁘게” 대신 critique packet을 만든다

AI에게 screenshot을 보여 주고 막연히 개선을 요청하면 장식을 추가하는 경향이 있다. critique는 관찰→영향→원칙→수정→검증 형식으로 쓴다.

관찰: class card 세 개가 동일한 background·height·CTA를 가진다.
영향: 첫 방문 추천과 재방문용 수업의 우선순위를 알 수 없다.
원칙: 첫 선택을 돕되 다른 선택을 숨기지 않는다.
수정: 첫 card만 surface contrast를 올리고 “첫 방문 추천” label을 둔다.
검증: 초보자가 15초 안에 추천 수업을 선택하는가.
금지: icon, badge, shadow를 추가해 해결하지 않는다.

AI에게 먼저 screenshot의 visual hierarchy를 묘사하게 하면 우리 의도와 실제 인지가 다른 지점을 찾을 수 있다. 그 다음 한 번에 변수 하나를 바꾼다. 여러 section을 동시에 고치면 무엇이 나아졌는지 알 수 없다.

↑ 목차로 돌아가기

16장 prompt를 네 개의 파일로 나눠 재현한다

긴 대화 하나에 기억을 맡기지 않는다. repository에 다음을 둔다.

design/
  brief.md        # 사용자·task·성공·금지
  direction.md    # visual axes·reference observation
  content.json    # 실제 문구·가격·상태 fixture
  review.md       # acceptance criteria·known issue

AI 작업의 매 turn에는 전체 요구를 반복하지 않고 변경 대상과 invariant를 명시한다.

변경 대상: class card 내부 hierarchy만.
유지: section width, three-column grid, actual copy, button behavior.
목표: price/time 비교가 설명보다 먼저 스캔되게.
반례: 320px에서 price가 잘리거나 CTA가 card마다 다른 높이가 되면 실패.
산출: 변경 diff와 이유, 영향을 받는 viewport 목록.

prompt도 source code처럼 review한다. “세련된” 같은 검증 불가능한 단어, 실제로 없는 사용자 data, 제3자 brand 복제 지시, scope creep을 제거한다.

↑ 목차로 돌아가기

17장 design token을 AI와 code 사이의 공통 언어로 쓴다

2025년 10월 Design Tokens Community Group은 첫 stable community report를 공개했다. 이는 W3C Standard가 아니라 Community Group report라는 지위도 함께 이해해야 한다. 핵심 가치는 tool 간에 color·dimension·typography 같은 의미를 교환할 구조다.

작은 서비스에서 token을 수백 개 만들지 않는다. primitive와 semantic을 분리한다.

{
  "color": {
    "clay-600": { "$type": "color", "$value": "#a64f32" },
    "olive-800": { "$type": "color", "$value": "#3f4938" },
    "action-primary": { "$type": "color", "$value": "{color.olive-800}" },
    "content-accent": { "$type": "color", "$value": "{color.clay-600}" }
  }
}

AI에는 hex 목록보다 역할을 준다. clay는 editorial accent, olive는 actionable control이다. 새 component가 임의 purple을 추가하면 token 검사와 review에서 잡는다. 모든 차이를 token으로 만들면 규칙이 아니라 예외 사전이 되므로 실제 반복에서만 추가한다.

↑ 목차로 돌아가기

18장 component를 모양이 아니라 상태 계약으로 명세한다

Button 명세는 height 48, radius 8에서 끝나지 않는다.

이름: PrimaryAction
의도: 현재 화면의 가장 중요한 reversible next step
내용: 결과를 나타내는 동사, 최대 두 줄 금지
상태: default, hover, focus-visible, active, disabled, busy
접근성: native button, visible focus, disabled 이유는 인접 text
반응형: touch target 유지, full-width는 narrow dialog에서만
금지: 한 viewport에 다른 primary action 세 개

Card도 click target, heading level, metadata 순서, empty image, sold-out state를 갖는다. component library는 screenshot collection이 아니라 상태를 재현하는 catalog가 되어야 한다.

AI가 새 page를 만들 때 기존 component를 재사용하도록 component name과 content slot을 제공한다. 모든 page에서 약간 다른 button을 생성하게 두지 않는다.

↑ 목차로 돌아가기

19장 edge case를 정상 화면과 동시에 생성한다

AI 결과가 좋아 보이는 가장 큰 이유 중 하나는 짧고 이상적인 data만 있기 때문이다. 정상 fixture와 함께 다음을 요청한다.

• class 이름 3자·32자
• 가격 없음·무료·100만원 이상
• sold out, 1자리, waitlist
• image loading 실패
• booking API loading·timeout·validation error·success
• 긴 한국어 주소와 영문 혼합
• 200% zoom, 320px, landscape mobile
• reduced motion, high contrast preference

state matrix를 만든다.

↑ 목차로 돌아가기

20장 Figma·prompt-to-app·code agent의 역할을 분리한다

2026년 8월 Figma 공식 도움말은 Figma agent, Figma Make, 개별 AI 도구를 구분한다. Make는 prompt나 기존 design에서 functional prototype을 만들고 code를 수정할 수 있다. Sites에는 code layer, text rewrite, content replacement, image 생성·편집이 있다. 기능 가용성은 plan과 시점에 따라 달라진다.

도구보다 작업을 선택한다.

generated prototype이 외부 font·package·image를 가져올 수 있으므로 publish 전에 dependency와 권리를 확인한다. tool이 export한 code를 “공식 production code”라고 가정하지 않는다.

4부 화면을 실제 서비스로 만든다

↑ 목차로 돌아가기

21장 semantic HTML과 접근성을 디자인 재료로 쓴다

접근성은 완성된 화면에 붙이는 검사표가 아니다. 구조를 제대로 고르는 순간 시각 디자인도 단단해진다. Onda의 상단은 header, 주요 이동은 이름이 있는 nav, 본문은 main, 각 수업은 article, 예약창은 dialog다. 제목 단계가 문서의 개요를 만들고, button은 행동을, a는 이동을 맡는다. 클릭이 된다는 이유로 div에 역할을 흉내 내지 않는다.

먼저 mouse를 치우고 다음 여정을 끝까지 진행한다.

1. Tab을 눌러 “본문으로 건너뛰기”를 보이게 한다.
2. 수업 section까지 이동하고 “자리 확인”을 연다.
3. dialog 안에서 날짜를 바꾸고 이름을 입력한다.
4. 닫은 뒤 focus가 열었던 button으로 돌아오는지 확인한다.
5. Shift+Tab, Escape, 200% zoom에서도 같은 task를 수행한다.

Onda는 native <dialog>를 사용한다. native element가 모든 문제를 자동 해결하지는 않지만 modal focus, top layer, Escape 동작의 더 나은 출발점이다. 열기 button마다 선택한 수업 이름을 dialog 제목 아래에 반영하고, 결과 문장은 aria-live="polite"인 output에 넣는다. 입력 오류가 생기면 message만 표시하지 않고 잘못된 field로 focus를 옮긴다.

<label class="name">
  예약자 이름
  <input required name="name" autocomplete="name">
</label>
<output id="booking-result" aria-live="polite"></output>

alt text는 image prompt의 축약본이 아니다. 같은 사진도 상품 page에서는 그릇의 형태를, 작업실 소개에서는 만드는 과정을 설명한다. 장식 image는 빈 alt, 정보 image는 현재 맥락에서 잃게 되는 정보를 쓴다. 사진에 없는 감정이나 SEO keyword를 덧붙이지 않는다.

WCAG 2.2 AA를 최소선으로 삼되 숫자 통과를 사용자 경험과 혼동하지 않는다. Onda 검수표에는 다음이 포함된다.

• text·control·focus의 식별 가능한 contrast
• 320 CSS px 너비와 200% zoom에서 양방향 scroll 없음
• keyboard focus 순서와 가시성
• label, error, status의 programmatic association
• touch target과 target 사이 간격
• motion을 줄이려는 사용자의 설정 존중
• heading·landmark·link text만 읽어도 이해되는 구조

AI에는 “접근성을 개선해” 대신 task와 판정을 준다.

예약 dialog를 keyboard만으로 완료하라. focus 순서를 표로 기록하고,
열기 전·열린 뒤·validation 실패 뒤·닫힌 뒤의 focus element를 제시하라.
semantic element를 CSS 때문에 바꾸지 말고 WCAG 2.2 AA 실패는
criterion, 위치, 재현 step, 수정안으로 보고하라.

자동 검사는 빠른 guardrail이지만 이름이 자연스러운지, 읽는 순서가 맞는지, 오류 뒤 회복할 수 있는지는 사람이 task로 확인한다.

↑ 목차로 돌아가기

22장 반응형을 축소가 아니라 다시 편집한다

Desktop을 390px로 줄이면 작은 desktop이 된다. Mobile 디자인은 같은 서비스 결정을 더 좁은 시간과 공간에서 다시 편집하는 작업이다. Onda desktop hero는 copy와 image가 나란하지만 mobile에서는 promise→설명→행동→availability→image 순서다. 첫 화면에 image를 가득 채워 CTA를 아래로 밀지 않는다.

각 breakpoint가 아니라 content가 깨지는 순간을 관찰한다.

Viewport query는 page 전체 변화에, container query는 component가 놓인 공간의 변화에 적합하다. 같은 ClassCard가 main grid와 좁은 추천 rail에 들어갈 수 있다면 부모를 containment context로 만든다.

.class-list { container-type: inline-size; }

@container (width < 42rem) {
  .class-card {
    grid-template-columns: 1fr;
  }
}

Container query 사용 여부와 관계없이 320, 390, 768, 1024, 1440px만 보는 습관을 버린다. 그 사이 너비를 천천히 움직이며 line wrap, orphan, overflow, sticky overlap을 찾는다. Landscape mobile, browser UI가 열린 짧은 높이, 긴 번역, software keyboard가 열린 dialog도 본다.

Onda mobile review는 세 질문으로 끝낸다.

1. 첫 10초 안에 무엇을 예약하는 곳인지 알 수 있는가?
2. 엄지로 primary action에 도달하고 결과를 예측할 수 있는가?
3. image를 늦게 받거나 text가 30% 길어져도 정보 순서가 남는가?

↑ 목차로 돌아가기

23장 예약 interaction을 happy path 밖에서 설계한다

멋진 정적 landing page도 예약 순간에 신뢰를 잃을 수 있다. Interaction 품질은 animation의 매끄러움보다 사용자가 현재 상태와 다음 결과를 아는가에 달려 있다.

예약 흐름을 상태 기계처럼 쓴다.

idle → dialog_open
dialog_open → validating
validating → field_error | checking_availability
checking_availability → conflict | ready
ready → submitting → success | network_error
conflict → choose_another_slot → checking_availability
network_error → retry | save_contact

이 상태를 prompt에 넣지 않으면 AI는 alert('예약 완료') 같은 happy path를 만든다. UI 문구도 상태마다 답해야 한다.

교육용 Onda 화면은 서버로 전송하지 않는다. 그래서 button은 선택 내용 확인, notice는 결제는 진행하지 않으며 입력값은 저장되지 않습니다라고 명확히 쓴다. 실제 동작보다 더 큰 결과를 약속하지 않는 것도 디자인 품질이다.

Form 검수 순서는 다음과 같다.

• field를 비운 채 제출해 오류의 위치·문장·focus를 본다.
• IME로 한글을 조합하고 Enter가 조합 중 제출하지 않는지 본다.
• paste, autofill, password manager가 layout을 깨지 않는지 본다.
• 느린 network에서 button이 busy가 되고 중복 요청이 막히는지 본다.
• server 오류 뒤 입력값이 보존되는지 본다.
• 성공 뒤 뒤로 가기와 새로고침 결과가 안전한지 본다.

AI가 interaction code를 수정했다면 screenshot만 승인하지 않는다. 정상·오류·취소·재시도 네 경로를 실행하고, console error와 network request를 함께 기록한다.

↑ 목차로 돌아가기

24장 motion은 공간과 인과를 설명할 때만 쓴다

AI가 만든 화면은 scroll reveal, floating shape, parallax, cursor effect를 쉽게 쌓는다. Motion은 개성을 더하는 무료 장식이 아니다. 주의를 빼앗고 멀미를 유발하며 main thread를 점유한다.

Onda에는 두 종류만 허용한다.

• button과 link의 짧은 상태 전환: 입력을 인식했다는 feedback
• dialog의 제한된 등장: 현재 작업 맥락이 바뀌었다는 설명

duration은 브랜드 감정만으로 정하지 않는다. 반복 횟수와 작업 속도를 고려한다. 자주 누르는 control은 더 짧고, layout을 이해시키는 드문 전환만 조금 길 수 있다. transform과 opacity를 우선하고 큰 blur·filter·layout property animation을 피한다.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    scroll-behavior: auto !important;
    animation-duration: .01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: .01ms !important;
  }
}

Reduced motion은 모든 피드백을 없애라는 뜻이 아니다. 위치 이동 대신 즉시 색·경계·text 상태로 바꿔 인과는 남긴다. Autoplay video를 쓴다면 pause control, muted 정책, poster, data 비용, 대체 content를 함께 설계한다.

리뷰에서 “부드럽다”를 다음 evidence로 바꾼다.

사용자 행동 없이 반복되는 motion: 0개
primary task를 지연하는 entrance: 0개
reduced-motion에서 task 손실: 0개
animation 중 layout shift: 0개
keyboard focus와 hover feedback의 의미 차이: 없음

↑ 목차로 돌아가기

25장 성능 예산을 시안 단계에서 정한다

빠른 사이트는 개발팀이 나중에 압축해서 만드는 것이 아니다. Hero에 어떤 asset을 얼마나 크게 쓰는지, font를 몇 벌 쓰는지, 첫 화면에 component를 몇 개 놓는지가 이미 성능 결정이다.

Core Web Vitals의 “좋음” 기준은 75번째 percentile에서 LCP 2.5초 이하, INP 200ms 이하, CLS 0.1 이하다. Lab score 한 번과 실제 field data는 다르다. 출시 전 lab test로 문제를 막고, 출시 뒤 실제 사용자 data를 device·connection·page별로 본다.

Onda의 예산 예시는 다음과 같다. 팀과 audience에 맞게 수치를 조정하되 예산 자체를 없애지 않는다.

예제 PNG는 원본 생성 asset과 출판 재현성을 보존하기 위해 포함했다. 실제 production에서는 화면에 필요한 크기의 AVIF/WebP 변형, srcset, sizes, cache header를 만든다. <img width height>로 aspect ratio를 예약해 CLS를 줄인다. LCP 후보인 hero는 lazy load하지 않고, below-the-fold image만 lazy load한다.

<img
  src="onda-hero-1280.webp"
  srcset="onda-hero-768.webp 768w, onda-hero-1280.webp 1280w"
  sizes="(max-width: 760px) 100vw, 58vw"
  width="1536" height="864"
  alt="늦은 오후 도예 작업실에서 작은 그릇을 다듬는 손">

INP가 나쁘면 animation만 의심하지 않는다. 긴 event handler, 큰 hydration, synchronous storage, tag manager를 performance trace로 찾는다. CLS는 dimension 없는 image·광고, 늦게 바뀌는 font, DOM 위쪽에 삽입되는 banner를 본다. AI에게 score만 주지 말고 trace의 long task, LCP element, 요청 waterfall을 제공한다.

↑ 목차로 돌아가기

26장 screenshot diff를 취향 회의의 기억장치로 만든다

Design QA에서 “전에는 괜찮았던 것 같다”는 가장 비싼 문장이다. 승인한 화면을 baseline으로 저장하고 변경 뒤 같은 viewport·data·font·browser에서 다시 찍는다. Onda는 실제 HTML을 1440×1000, 390×844에서 capture한다. 예약 dialog도 열린 상태를 별도 baseline으로 둔다.

Pixel 차이가 모두 결함은 아니다. Anti-aliasing, 날짜, random content, animation frame은 noise가 된다. Capture 전에 다음을 고정한다.

• viewport와 device scale
• locale·timezone·clock
• fixture와 API response
• motion off와 transition 종료
• font load 완료
• consent banner와 user state

Diff triage는 severity로 나눈다.

Screenshot은 접근성 tree나 interaction을 보지 못한다. DOM assertion, keyboard task, console error, performance 측정과 함께 쓴다. Baseline을 자동 갱신하는 script는 검사의 의미를 없애므로 사람의 승인과 change note가 필요하다.

↑ 목차로 돌아가기

27장 다섯 명의 관찰에서 디자인 언어를 다시 고친다

사용성 test는 “마음에 드세요?”라고 묻는 선호도 조사가 아니다. 실제와 비슷한 상황, 관찰 가능한 task, 사전에 정한 성공 조건이 필요하다.

Onda의 test script:

상황: 이번 토요일 오후, 도예를 처음 해 보는 친구와 수업을 찾고 있습니다.
과제 1: 초보자에게 맞는 수업과 비용을 확인해 주세요.
과제 2: 가장 빠른 시간을 골라 예약 직전까지 진행해 주세요.
과제 3: 준비물과 작품 수령 시점을 찾아 말해 주세요.

성공: 도움 없이 정확한 수업·가격·날짜·조건을 말함
관찰: 망설인 위치, 되돌아간 횟수, 잘못 예상한 click 결과
금지 질문: 이 색이 예쁜가요? 이 버튼이 보이나요?

진행자는 가르치지 않고 참가자가 기대한 결과를 말하게 한다. 막혔을 때 바로 설명하지 말고 마지막으로 확신했던 지점을 묻는다. 녹화·개인정보 동의 범위를 먼저 정하고 필요 이상으로 참가자 정보를 수집하지 않는다.

다섯 명은 통계적 대표성을 보장하지 않지만 반복되는 큰 문제를 찾는 데 유용하다. 모든 한 사람의 취향을 반영하지 않는다. 발견을 빈도·영향·회복 가능성으로 정리한다.

발견: 5명 중 3명이 hero의 "이번 주 수업 보기"를 즉시 예약으로 예상했다.
영향: dialog가 열리자 가격을 다시 찾으려고 닫음.
원인 가설: CTA 결과와 다음 화면 정보가 불일치.
수정: dialog 상단에 선택 수업·가격·소요 시간 요약.
재검증: 같은 task에서 dialog를 닫는 비율과 완료 시간.

출시 뒤에는 event를 서비스 질문에 연결한다. hero_cta_click 숫자만 모으지 말고 class 비교→slot 선택→validation error→확인 단계의 이탈을 본다. Analytics가 없는 사용자의 목소리는 support query와 현장 관찰로 보완한다. 숫자가 오른다고 deceptive pattern을 허용하지 않는다.

↑ 목차로 돌아가기

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점으로 평가한다.

가중 점수와 함께 가장 큰 실패 위험을 적는다. 판정: 승리안이 “예뻐서”가 아니라 서비스 결정과 증거로 설명되는가.

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를 만든다.

오류 문장은 사용자 탓 대신 원인과 회복을 쓴다.

판정: 실패 뒤 사용자가 처음부터 다시 하지 않고 다음 행동을 선택할 수 있는가.

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 생성물 보고서를 참고하되 특정 국가의 법률 자문을 제공하지 않는다. 관할권과 계약에 따라 결과가 달라질 수 있으므로 상업 출판·광고 전에는 이용한 도구의 당시 약관과 필요한 전문가 검토를 거친다.

안전한 실무 원칙은 단순하다.

1. 특정 작가·생존 디자이너·경쟁사의 고유한 표현을 복제하도록 지시하지 않는다.
2. Reference는 원칙을 관찰하는 데 쓰고 source file·사진·문구를 가져오지 않는다.
3. 생성 image와 code도 유사성, logo, 얼굴, text artifact, dependency를 사람이 확인한다.
4. Prompt, model, date, input reference, human selection·edit, 사용 위치를 기록한다.
5. Stock·font·icon은 “무료”라는 말 대신 정확한 license와 상업 이용 조건을 보존한다.
6. 사용자의 입력과 업로드가 모델 학습·보관에 어떻게 쓰이는지 조직 정책으로 확인한다.

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 결과가 마음에 들 때까지 다시 뽑지 않는다. 왜 부족한지 말하고, 가장 작은 변수를 고치고, 실제 사용자의 행동으로 확인할 수 있다.

기능이 작동하는 화면에서 신뢰할 수 있는 서비스로 가는 마지막 거리는 사람의 디렉션이다. 이제 그 거리를 감으로 건너지 않아도 된다.

↑ 목차로 돌아가기