여백: whitespace · padding · margin · 근접성
현상
- 화면이 전체적으로 빽빽하고 답답하다. 요소를 줄인 것도 아닌데 정신없다.
- 제목이 위 문단과 아래 문단 사이 딱 중간에 떠 있어서, 어느 문단의 제목인지 헷갈린다.
- 버튼 글자가 테두리에 너무 붙어 있어 싸구려처럼 보인다.
용어
- whitespace(여백, negative space) — 요소가 없는 빈 공간. “남는 공간”이 아니라 디자인의 재료다. 여백이 넉넉하면 고급스럽고 차분해 보이고, 부족하면 싸고 급해 보인다.
- 비유: 고급 레스토랑 접시. 큰 접시에 음식을 조금만 올리면(여백) 정갈해 보이고, 꽉 채우면 뷔페 접시처럼 보인다.
- padding(안쪽 여백) — 요소의 테두리 안쪽, 내용과 테두리 사이 공간. 버튼 글자 주변 공간(현상 3).
- margin(바깥 여백) — 요소의 테두리 바깥, 다른 요소와의 거리.
- gap — 여러 자식 사이에만 주는 간격(웹 용어 38번). 요즘 레이아웃에선 형제 간격을 margin 대신 gap으로 주는 게 기본.
- 근접성(proximity, 게슈탈트 원리) — 사람은 가까이 있는 것끼리 한 묶음으로 인식한다. 그래서 여백은 “얼마나 띄울까”가 아니라 “무엇과 무엇을 묶을까”의 문제다.
- 규칙: 관련 있는 것은 가깝게, 다른 묶음과는 멀게. 그룹 안쪽 간격 < 그룹 사이 간격.
- 현상 2는 제목과 위·아래 간격이 같아서 생긴다. 제목은 자기 문단(아래)에 더 가깝게 붙여야 한다.
- spacing scale(간격 단위) — 여백 값을 아무 숫자나 쓰지 않고 정해진 단계에서만 고르는 것. 보통 4의 배수(4·8·12·16·24·32·48…), 흔히 “8pt grid“라 부른다. 15px, 17px 같은 값이 섞이면 미묘하게 어수선해 보인다. Tailwind의
p-2(8px), p-4(16px)가 이 단계다.
지시 예문
- “화면이 답답해. 섹션 사이 여백을 키우고, 전체 spacing을 8pt 단위(8·16·24·32)로 통일해줘.”
- “소제목이 위 문단과 아래 문단 사이 중간에 떠 있어. 근접성 원칙대로 소제목 위 여백은 크게, 아래 여백은 작게 해줘.”
- “버튼 padding이 좁아 글자가 테두리에 붙어 보여. 좌우 padding을 16px, 상하 10px로 늘려줘.”
타이포그래피 기초: 행간 · 자간 · 굵기 · 한 줄 길이
현상
- 본문 줄과 줄 사이가 좁아 빽빽하고 답답하다(진단 Q2).
- 큰 제목의 글자 사이가 헐렁하게 벌어져 보인다.
- 데스크톱에서 본문 한 줄이 화면 끝까지 너무 길어서, 줄 끝에서 다음 줄 시작을 찾느라 눈이 헤맨다.
- 제목·본문·캡션 크기가 13, 14, 15, 17, 19px처럼 애매하게 다 달라서 정돈돼 보이지 않는다.
용어
- typography(타이포그래피) — 글자를 읽기 좋고 보기 좋게 배치하는 기술 전반. UI는 대부분 글자라서 타이포가 화면 인상의 절반 이상을 정한다.
- 행간(line-height, leading) — 한 문단 안 줄과 줄 사이 간격. CSS
line-height. 본문은 글자 크기의 1.5배 안팎이 무난하고, 한글 본문은 조금 더 넉넉하게(1.6~1.8) 주는 경우가 많다. 제목처럼 큰 글자는 반대로 좁게(1.2~1.3) 줘야 덩어리져 보인다.
- 헷갈림 주의: gap은 요소 사이, line-height는 한 문단 안의 줄 사이.
- 자간(letter-spacing, tracking) — 글자와 글자 사이 간격. 큰 제목은 기본 자간이 헐렁해 보여서 살짝 좁히고(음수), 아주 작은 글씨나 대문자 라벨은 살짝 넓힌다. 한국 UI에선 본문도 미세하게 좁히는 경우가 흔하다.
- 굵기(font-weight) — 100(가장 얇음)~900(가장 굵음). 400 = Regular(보통), 500 = Medium, 600 = SemiBold, 700 = Bold. 강조는 크기보다 굵기 한 단계로 충분한 경우가 많다.
- 한 줄 길이(line length, measure) — 본문 한 줄에 들어가는 글자 수. 너무 길면 다음 줄을 찾기 어렵고, 너무 짧으면 줄바꿈이 잦아 끊긴다. 영문 기준 대략 45~75자가 편하다고 알려져 있다. 본문 영역에 max-width를 걸어 해결한다(현상 3).
- 비유: 신문이 넓은 지면을 여러 단으로 나눠 쓰는 이유.
- type scale(글자 크기 단계) — 글자 크기를 아무 숫자로나 쓰지 않고 정해진 몇 단계만 쓰는 것. 예: 12 · 14 · 16 · 20 · 24 · 32. 1번 레슨 spacing scale의 글자 버전. 단계가 적을수록 정돈돼 보인다(현상 4).
지시 예문
- “본문이 빽빽해. 본문 line-height를 1.7로 늘리고, 큰 제목은 1.25로 좁혀줘.”
- “히어로 제목 자간이 헐렁해 보여. letter-spacing을 -0.02em 정도로 좁혀줘.”
- “데스크톱에서 본문 줄이 너무 길어. 본문 영역 max-width를 680px 정도로 제한해줘.”
- “글자 크기가 너무 여러 가지야. 12·14·16·20·24·32 type scale로 정리해서 전부 맞춰줘.”
시각적 위계(visual hierarchy)
현상
- 상품명·가격·설명·버튼이 비슷한 크기·굵기라 어디부터 봐야 할지 모르겠다(진단 Q1).
- 중요하다고 이것저것 다 굵게·빨갛게 했더니 오히려 아무것도 눈에 안 띈다.
- 사용자들이 정작 눌러야 할 “구매” 버튼을 못 찾는다.
용어
- visual hierarchy(시각적 위계) — 화면 요소들에 중요도 순서를 매겨, 눈이 1순위 → 2순위 → 3순위 순으로 자연스럽게 흐르게 만드는 것. 위계가 없으면 모든 게 같은 목소리로 동시에 말하는 상태가 된다.
- 비유: 신문 1면. 헤드라인(가장 큼) → 부제 → 사진 → 본문 순으로 읽힌다. 모든 기사를 같은 크기로 실으면 무엇이 톱뉴스인지 모른다.
- 위계를 만드는 도구 — 크기만이 아니다.
- 크기 — 클수록 먼저 보인다.
- 굵기 — 굵을수록 강하다(2번 레슨).
- 색·대비 — 진할수록, 배경과 대비가 클수록 강하다. 보조 정보는 회색으로 흐리게.
- 여백 — 주변 여백이 넓을수록 돋보인다(1번 레슨).
- 위치 — 위쪽·왼쪽이 먼저 읽힌다(한국어·영어처럼 왼→오 언어 기준).
- 강조보다 약화(de-emphasis) — 위계는 중요한 걸 키우는 것보다 덜 중요한 걸 낮추는 것으로 더 쉽게 만들어진다. 라벨·날짜·부가 설명을 작게·연하게 하면 핵심이 저절로 떠오른다.
- “전부 강조 = 강조 없음” — 강조는 상대적이라 여러 개를 동시에 강조하면 서로 상쇄된다(현상 2). 한 화면의 1순위는 하나로.
- focal point(초점) — 화면에서 가장 먼저 눈이 가는 지점. 보통 그 화면의 핵심 행동(구매·가입)이 여기 와야 한다(현상 3).
- squint test(눈 가늘게 뜨기 테스트) — 화면을 보며 눈을 가늘게 떠서 흐릿하게 볼 때 무엇이 먼저 덩어리로 보이는지 확인하는 방법. 의도한 1순위가 먼저 보이면 위계가 잡힌 것.
지시 예문
- “상품 상세의 시각적 위계를 잡아줘. 1순위 상품명·가격, 2순위 구매 버튼, 3순위 설명. 설명과 부가 정보는 작고 연한 회색으로 낮춰줘.”
- “강조가 너무 많아서 아무것도 안 보여. 화면당 강조는 하나만 남기고 나머지는 기본 스타일로 돌려줘.”
- “구매 버튼이 focal point가 되게 해줘. 주변 여백을 넓히고 이 화면에서 유일한 진한 색으로.”
정렬과 그리드: 정렬선 · 레이아웃 그리드 · optical alignment
현상
- 제목, 본문, 이미지, 버튼의 왼쪽 시작 위치가 제각각이라 화면이 어수선하다. 뭐가 틀렸는지는 딱 집어 말하기 어렵다.
- 긴 설명 문단을 가운데 정렬했더니 줄마다 시작점이 달라 읽기 힘들다.
- 아이콘과 옆의 글자가 수치상으론 가운데 정렬인데 눈으로 보면 살짝 어긋나 보인다. 재생(▶) 아이콘이 원 안에서 왼쪽으로 쏠려 보인다.
용어
- alignment(정렬) — 요소들을 보이지 않는 같은 선에 맞추는 것. 사람 눈은 이 선(정렬선)을 무의식적으로 따라간다. 1~2px 어긋남도 “뭔가 어수선함”으로 느껴진다(현상 1).
- 왼쪽 정렬 vs 가운데 정렬
- 왼쪽 정렬 — 줄 시작점이 같아 읽기 편하다. 본문·목록·폼의 기본.
- 가운데 정렬 — 짧은 제목, 빈 상태 안내, 랜딩 히어로처럼 2~3줄 이하의 짧은 문구에만. 긴 문단에 쓰면 줄마다 시작점을 찾아야 해서 피곤하다(현상 2).
- 한 화면에서 정렬 방식을 섞지 않는 게 기본.
- layout grid(레이아웃 그리드) — 화면을 같은 폭의 세로 칸(column)으로 나눠, 요소를 그 칸에 맞춰 배치하는 보이지 않는 틀. 웹은 12열이 흔하다(2·3·4·6열로 나누기 쉬워서).
- column(열) — 내용이 들어가는 칸.
- gutter(거터) — 칸과 칸 사이 간격. CSS의 gap에 해당.
- margin(바깥 여백) — 그리드 전체의 양옆 여백.
- container(컨테이너) — 콘텐츠가 넓은 화면에서 무한정 늘어나지 않게 최대 폭(max-width)을 정한 틀.
- 비유: 원고지. 칸이 있으니 글자가 삐뚤빼뚤해지지 않는다.
- optical alignment(시각 보정 정렬) — 수치상 정렬이 아니라 눈에 정렬돼 보이도록 살짝 조정하는 것. 삼각형 재생 아이콘은 무게 중심이 왼쪽에 있어서 오른쪽으로 1~2px 옮겨야 가운데로 보인다. 원형 아이콘은 같은 크기의 사각형 아이콘보다 작아 보여서 살짝 크게 그린다(현상 3).
- baseline(기준선) — 글자가 올라앉는 보이지 않는 밑선. 크기가 다른 텍스트를 나란히 둘 때 박스 가운데가 아니라 baseline에 맞추면 정돈돼 보인다(
align-items: baseline).
지시 예문
- “섹션마다 왼쪽 시작점이 달라. 모든 콘텐츠를 같은 container(max-width 1200px, 좌우 24px)에 넣어 정렬선을 맞춰줘.”
- “긴 설명 문단이 가운데 정렬이라 읽기 힘들어. 본문은 왼쪽 정렬로 바꾸고 짧은 제목만 가운데로 둬.”
- “가격(큰 글씨)과 ‘원’(작은 글씨)이 위아래로 어긋나 보여. baseline 정렬로 맞춰줘.”
- “재생 아이콘이 원 안에서 왼쪽으로 쏠려 보여. optical alignment로 오른쪽으로 1~2px 옮겨줘.”
색 체계: 대비 · 팔레트 · semantic color
현상
- 연회색 배경 위 회색 글씨가 잘 안 읽힌다(진단 Q3).
- 버튼·링크·배지·아이콘에 색을 여기저기 다르게 써서 화면이 알록달록 산만하다.
- 에러 메시지를 빨간 글씨로만 표시했더니, 색약 사용자는 무엇이 잘못됐는지 모른다.
- 같은 파란색 계열인데 hover·배경·테두리에 쓸 연한·진한 버전을 그때그때 눈대중으로 만들고 있다.
용어
- 명도 대비(contrast) — 글자와 배경의 밝기 차이. 색상(hue)이 달라도 밝기가 비슷하면 안 읽힌다.
- 명도 대비율(contrast ratio) — 대비를 숫자로 잰 값. 접근성 기준 WCAG AA는 일반 본문 4.5:1 이상, 큰 글자(대략 24px 이상, 또는 굵은 19px 이상)는 3:1 이상, 버튼 테두리·아이콘 같은 UI 요소도 3:1 이상. 브라우저 개발자 도구나 대비 검사 도구로 바로 확인된다.
- 팔레트(palette)의 역할 구분
- primary(주요색) — 브랜드 색. 핵심 버튼·링크·선택 상태 등 가장 중요한 곳에만.
- neutral(무채색, gray) — 글자·배경·테두리 등 화면의 대부분. 좋은 UI는 생각보다 거의 회색이다.
- secondary/accent(보조·강조색) — 필요할 때만 소량.
- 60-30-10 규칙 — 대략 바탕 60% : 보조 30% : 강조 10%. 강조색이 많아질수록 3번 레슨의 “전부 강조 = 강조 없음”이 된다(현상 2).
- semantic color(의미 색) — 색에 고정된 의미를 주는 것. success(초록), warning(주황·노랑), error/danger(빨강), info(파랑). 한 번 정하면 그 의미로만 쓴다(빨강을 장식으로 쓰면 에러처럼 보인다).
- 웹의 semantic HTML과 같은 뿌리다. “semantic” = 겉모습이 아니라 의미·역할로 고른다. semantic HTML은 “생김새가 버튼 같아서 div”가 아니라 “역할이 버튼이라
<button>”, semantic color는 “빨간색”이 아니라 “에러 색”. 둘 다 의미로 이름 붙여두면 겉모습을 한 곳에서 바꿔도(다크 모드에서 에러 빨강을 조금 밝게) 쓰는 곳은 그대로다. 코드에선 red-500 대신 color-error처럼 의미 이름을 쓰는 것으로 이어진다(디자인 토큰).
- 색만으로 정보를 전달하지 않기 — 전체 남성의 꽤 큰 비율이 적록 색각이상이라 빨강·초록 구분이 어렵다. 색에 아이콘·텍스트를 함께 붙인다. “❗ 이메일 형식이 올바르지 않아요”(현상 3).
- shade scale(명도 단계) — 한 색을 50(가장 연함)~900(가장 진함) 단계로 미리 만들어 두고 골라 쓰는 것. Tailwind의
blue-50~blue-900이 이 방식. 배경엔 50~100, 테두리엔 200~300, 기본 버튼은 500~600, hover엔 한 단계 진하게(현상 4).
지시 예문
- “본문 회색 글씨가 배경과 대비가 낮아. WCAG AA 4.5:1 이상이 되게 글자색을 진하게 조정하고, 대비율도 알려줘.”
- “색이 너무 많아 산만해. primary 한 색만 핵심 버튼에 쓰고, 나머지는 neutral gray로 정리해줘.”
- “에러를 빨간 글씨로만 표시하고 있어. 에러 아이콘과 설명 텍스트를 함께 붙여줘.”
- “primary 색을 50~900 shade scale로 만들고, 배경·테두리·hover에 단계별로 적용해줘.”
디자인 토큰과 디자인 시스템
현상
- 메인 파란색이 화면마다
#3B82F6, #3A80F5, #2563EB로 조금씩 다르다. 여백도 15·16·18px이 섞여 있다(진단 Q4).
- 브랜드 색을 바꾸기로 했는데 코드 전체에서 색 코드를 찾아 바꾸는 데 하루가 걸렸고, 몇 군데는 놓쳤다.
- 다크 모드를 추가하려니 모든 컴포넌트를 하나씩 손봐야 한다.
용어
- hardcoded value / magic number — 색·여백·크기를 코드에 숫자 그대로 박아 넣은 것(
#3B82F6, margin: 15px). 같은 의도의 값이 곳곳에 따로 있어 어긋나고(현상 1), 바꿀 때 다 찾아야 한다(현상 2). 웹 용어 31번 single source of truth의 디자인 버전 문제.
- design token(디자인 토큰) — 디자인 결정값(색·여백·글자 크기·굵기·모서리 둥글기·그림자 등)에 이름을 붙여 한 곳에 정의한 것. 코드는 값 대신 이름을 참조한다. CSS 변수(
var(--color-primary))나 Tailwind 테마 설정으로 구현한다.
- 비유: 요리 레시피의 “소금 1큰술”. 매번 “소금 13g, 14g…”이라 적지 않고 계량 단위를 정해두면 누가 만들어도 같은 맛이 난다.
- 토큰의 층 — 보통 두세 단계로 나눈다.
- primitive(원시) 토큰 — 날것의 값 목록.
blue-500 = #3B82F6, space-4 = 16px. 5번 레슨 shade scale, 1번 레슨 spacing scale이 여기.
- semantic(의미) 토큰 — 역할 이름으로 primitive를 가리킴.
color-primary → blue-500, color-text-muted → gray-500, color-error → red-600. 컴포넌트는 이 층을 쓴다(5번 레슨 semantic color).
- component 토큰 — 특정 컴포넌트용.
button-primary-bg → color-primary. 큰 시스템에서만.
- 이 구조 덕분에 다크 모드는 semantic 토큰이 가리키는 값만 바꾸면 된다.
color-bg가 라이트에선 white, 다크에선 gray-900을 가리키게 하면 컴포넌트는 손댈 필요가 없다(현상 3).
- design system(디자인 시스템) — 토큰 + 컴포넌트(버튼·입력창·모달 등) + 사용 규칙과 문서를 합친 것. 토큰은 그 가장 아래 재료층이다. 진단 Q4의 답은 정확히는 “토큰”, 넓게 보면 “디자인 시스템”.
- 비유: 토큰은 레고 블록의 색·규격, 컴포넌트는 블록으로 만든 부품, 디자인 시스템은 부품 + 조립 설명서 전체.
지시 예문
- “코드에 하드코딩된 색·여백 값을 전부 찾아서 디자인 토큰(CSS 변수)으로 바꿔줘. 비슷한 값은 하나로 합치고 목록을 먼저 보여줘.”
- “primitive 토큰(blue-50~900)과 semantic 토큰(color-primary, color-text, color-text-muted, color-bg, color-border, color-error)을 나눠서 정의해줘.”
- “다크 모드 추가해줘. 컴포넌트는 건드리지 말고 semantic 토큰 값만 다크용으로 다시 매핑해줘.”
깊이와 모양: shadow · elevation · border radius · border
현상
- 흰 배경 위 흰 카드가 배경에 묻혀 어디까지가 카드인지 모르겠다.
- 그림자를 넣었더니 진하고 번져서 촌스럽다(2000년대 웹 느낌).
- 버튼은 각지고, 카드는 둥글고, 입력창은 살짝 둥글어서 모서리가 제각각이다.
- 둥근 카드 안에 둥근 이미지를 넣었더니 안쪽과 바깥쪽 곡선이 어긋나 보인다.
용어
- elevation(높이감) — 요소가 화면에서 얼마나 떠 있는지의 단계. 바닥(배경) → 카드 → 드롭다운 → 모달 순으로 높아진다. 높을수록 그림자가 크고 부드러워진다. 위에 떠 있는 것일수록 중요하거나 일시적인 것.
- 비유: 책상 위 종이. 바닥에 붙은 종이는 그림자가 거의 없고, 들어 올릴수록 그림자가 넓고 흐려진다.
- shadow(그림자) — 높이감을 표현하는 수단. 좋은 그림자의 요령:
- 연하게(검정 5~15% 정도 투명도), 넓게 흐리게(blur 크게), 아래쪽으로 살짝(위에서 빛이 온다고 가정).
- 진하고 좁은 그림자는 촌스러워 보인다(현상 2). 자연스러운 그림자는 작고 진한 것 + 크고 연한 것을 겹쳐 만든다.
- elevation 단계마다 그림자를 토큰으로 정해둔다(
shadow-sm, shadow-md, shadow-lg, 6번 레슨).
- border(테두리) vs shadow — 영역을 구분하는 두 방법. 테두리는 평평하고 정돈된 느낌, 그림자는 떠 있는 느낌. 배경과 카드를 구분하는 다른 방법은 배경색 차이(회색 배경 위 흰 카드). 셋 중 하나만 써도 충분한 경우가 많다 — 다 쓰면 무겁다(현상 1 해결).
- border radius(모서리 둥글기) — 모서리를 얼마나 둥글게 할지. 서비스 인상을 크게 좌우한다. 각질수록 단단·진지(금융·업무용), 둥글수록 친근·부드러움(소비자 앱). 단계를 토큰으로 정해 통일한다(현상 3).
- pill(알약형) — 높이의 절반 이상으로 둥글린 완전 둥근 끝. 태그·칩·일부 버튼.
- nested radius(중첩 모서리) — 둥근 박스 안에 둥근 박스를 넣을 때 안쪽 radius = 바깥 radius − 둘 사이 padding이어야 곡선이 평행해 보인다. 같은 값을 주면 안쪽이 상대적으로 너무 둥글어 어긋나 보인다(현상 4).
지시 예문
- “흰 카드가 흰 배경에 묻혀. 페이지 배경을 아주 연한 회색으로 바꾸거나, 카드에 연한 border를 넣어줘. 둘 중 하나만.”
- “그림자가 진하고 촌스러워. 투명도 낮추고 blur 키워서 부드럽게, shadow-sm/md/lg 3단계 토큰으로 정리해줘.”
- “border radius를 통일해줘. 입력창·버튼 8px, 카드 12px, 모달 16px, 태그는 pill.”
- “카드(radius 16px, padding 8px) 안 이미지 모서리가 어긋나 보여. nested radius 규칙대로 이미지 radius를 8px로 맞춰줘.”
버튼 위계: primary · secondary · ghost · destructive · 터치 영역
현상
- 결제 화면에 “결제하기”, “쿠폰 적용”, “취소” 버튼이 전부 같은 파란 버튼이라 어느 걸 눌러야 할지 망설여진다.
- “삭제” 버튼이 “저장” 버튼과 똑같이 생겨서 실수로 눌렀다.
- 모바일에서 작은 아이콘 버튼이 잘 안 눌리고 옆 버튼이 눌린다.
- 버튼 문구가 “확인”, “예”뿐이라 누르면 무슨 일이 일어나는지 모르겠다.
용어
- CTA(Call To Action) — 사용자가 해주길 바라는 핵심 행동을 부르는 요소. 결제하기, 가입하기 등. 3번 레슨 focal point가 되어야 하는 버튼.
- 버튼 위계(button hierarchy) — 버튼에도 3번 레슨의 시각적 위계를 적용해 중요도별로 다른 모양을 준다.
- primary — 채워진 진한 버튼(primary 색). 한 화면(한 영역)에 하나. “결제하기”.
- secondary — 테두리만 있거나(outline) 연한 배경. 보조 행동. “쿠폰 적용”.
- tertiary / ghost / text 버튼 — 배경·테두리 없이 글자만. 가장 약한 행동. “취소”, “나중에”.
- 비유: 회의 안건 순서. 의장이 가장 중요한 안건 하나를 먼저 크게 올리고, 나머지는 “기타 안건”으로 묶는 것.
- destructive(파괴적) 버튼 — 삭제·탈퇴처럼 되돌리기 어려운 행동. 빨강(5번 레슨 semantic color error)으로 구분하고, 기본으로 눈에 띄게 두지 않으며, 누르면 확인 단계를 둔다(현상 2).
- button variant / size — 위계별 모양(variant)과 크기(sm·md·lg)를 컴포넌트에 미리 정해두고 골라 쓰는 것(6번 레슨 디자인 시스템). shadcn의
variant="outline", variant="ghost", variant="destructive"가 이것.
- 터치 영역(touch target, hit area) — 손가락으로 눌리는 실제 범위. 보이는 아이콘이 작아도 눌리는 범위는 넉넉해야 한다. Apple은 최소 44×44pt, Google Material은 48×48dp를 권장한다. 아이콘은 작게 두고 padding으로 누르는 범위만 키운다(현상 3).
- 버튼 문구(label) — “확인·예” 대신 결과를 말하는 동사로. “삭제하기”, “3개 상품 결제하기”, “변경사항 저장”. 누르기 전에 무슨 일이 일어날지 알 수 있다(현상 4).
지시 예문
- “결제 화면 버튼 위계를 잡아줘. ‘결제하기’만 primary, ‘쿠폰 적용’은 secondary(outline), ‘취소’는 ghost.”
- “계정 삭제 버튼을 destructive 스타일로 바꾸고, 누르면 확인 모달을 띄워줘. 모달 버튼 문구는 ‘계정 삭제하기’.”
- “모바일 아이콘 버튼 터치 영역이 너무 작아. 아이콘 크기는 그대로 두고 터치 영역을 44×44 이상으로 늘려줘.”
- "’확인’ 같은 모호한 버튼 문구를 결과를 말하는 동사로 바꿔줘.”
현상
- “팝업 띄워줘”라고 했더니 원한 건 버튼 옆 작은 설명창인데 AI가 화면 가운데 큰 창을 만들었다.
- 모바일에서 필터를 화면 가운데 창으로 띄웠더니 손가락이 안 닿고 답답하다.
- 저장 완료를 알리는데 확인 버튼을 눌러야 닫히는 창이 떠서 귀찮다.
용어 — 한국어로는 전부 “팝업”이라 부르기 쉽지만, 이름이 다르면 동작과 용도가 다르다. 정확한 이름이 곧 정확한 지시다.
- modal / dialog(모달) — 화면 가운데 뜨고 뒤 배경을 어둡게 막는 창. 닫기 전엔 뒤를 조작할 수 없다(웹 용어 9번 scroll lock). 집중이 필요한 결정에: 로그인, 상세 입력, 중요한 확인.
- alert dialog(확인 모달) — 모달 중 “정말 할래요?”를 묻는 작은 것. 8번 레슨 destructive 행동 확인용.
- bottom sheet(바텀 시트) — 모바일에서 화면 아래에서 올라오는 판. 엄지가 닿기 쉬워 모바일 필터·옵션 선택·공유 메뉴에 맞다. 끌어올려 키우거나 끌어내려 닫는다(현상 2 해결).
- drawer / sheet / side panel(드로어) — 화면 옆에서 미끄러져 나오는 판. 모바일 햄버거 메뉴, 데스크톱 장바구니·상세 미리보기.
- popover(팝오버) — 특정 요소 바로 옆에 붙어 뜨는 작은 창. 클릭으로 열고 안에 버튼·입력도 넣을 수 있다. 날짜 선택기, 공유 옵션, 짧은 설정. 뒤를 막지 않는다.
- tooltip(툴팁) — 요소에 마우스를 올리면 뜨는 짧은 설명 글자만. 버튼·링크를 넣지 않는다. 터치 기기엔 hover가 없어서(웹 용어 16번) 핵심 정보를 툴팁에만 두면 안 된다. 현상 1에서 원한 게 이것(또는 popover).
- dropdown menu(드롭다운 메뉴) — 버튼을 누르면 아래로 펼쳐지는 선택지 목록. “⋯ 더보기” 메뉴.
- toast / snackbar(토스트) — 화면 구석에 잠깐 떴다 저절로 사라지는 알림. 저장 완료, 복사됨 같은 가벼운 결과 알림에. 확인 버튼을 누르게 하지 않는다(현상 3 해결, 웹 용어 22번 inline error vs toast).
- 고르는 기준: 얼마나 흐름을 끊어도 되는가. toast(안 끊음) < tooltip·popover(살짝) < bottom sheet·drawer(옆으로) < modal(완전히 멈춤). 흐름을 끊을수록 정말 필요할 때만 쓴다.
지시 예문
- “물음표 아이콘에 마우스 올리면 짧은 설명이 뜨는 tooltip 붙여줘. 모바일에선 탭하면 popover로.”
- “모바일 필터를 modal 대신 bottom sheet로 바꿔줘. 아래로 끌면 닫히게.”
- “저장 완료 alert를 toast로 바꿔줘. 3초 뒤 자동으로 사라지게.”
- “게시글 ‘⋯’ 버튼에 수정·삭제 dropdown menu 달고, 삭제는 alert dialog로 한 번 더 확인해줘.”
현상
- “아래 메뉴 만들어줘”라고 했는데, 원한 건 앱처럼 화면 맨 아래 고정된 아이콘 메뉴인데 AI가 페이지 끝에 푸터를 만들었다.
- “탭 만들어줘”라고 했더니 페이지 이동 메뉴를 원했는데 한 페이지 안의 내용 전환이 만들어졌다(또는 반대).
- 쇼핑몰 카테고리 깊숙이 들어가니 지금 어디에 있는지, 어떻게 위로 돌아가는지 모르겠다.
- 회원가입이 4단계인데 몇 단계 중 몇 번째인지 안 보여서 언제 끝나는지 모른다.
용어 — “메뉴”, “탭”처럼 뭉뚱그려 부르면 AI가 엉뚱한 걸 만든다.
- header / navbar(상단 바) — 화면 맨 위 로고·메뉴·로그인 버튼 영역. 스크롤해도 붙어 있으면 sticky header(웹 용어 39번).
- footer(푸터) — 페이지 맨 끝의 회사 정보·약관·링크 영역. 스크롤해야 보인다.
- tab bar / bottom navigation(하단 탭 바) — 모바일 앱처럼 화면 맨 아래에 고정된 3~5개 아이콘 메뉴. 앱의 최상위 화면 간 이동(홈·검색·마이). 현상 1에서 원한 것.
- sidebar / side navigation(사이드바) — 데스크톱에서 화면 왼쪽 세로 메뉴. 관리자·대시보드·문서 사이트. 모바일에선 drawer(9번 레슨)로 접힌다.
- tabs(탭) — 한 화면 안에서 같은 수준의 내용을 전환하는 것. 상품 상세의 “상세정보 / 리뷰 / 문의”. 페이지 전체가 바뀌는 게 아니라 아래 영역만 바뀐다.
- segmented control(세그먼트 컨트롤) — 붙어 있는 2~4개 버튼 중 하나를 고르는 작은 전환기. “일 / 주 / 월”, “목록 보기 / 지도 보기”. 탭보다 작고 보기 방식·필터 전환에 가깝다.
- breadcrumb(브레드크럼, 경로 표시) —
홈 > 의류 > 남성 > 티셔츠처럼 지금 위치까지의 경로를 보여주고, 상위로 바로 가게 해주는 링크 줄. 헨젤과 그레텔의 빵부스러기에서 온 이름(현상 3 해결).
- stepper / progress indicator(단계 표시) — 여러 단계 흐름에서 “4단계 중 2단계”를 보여주는 표시. 회원가입·주문서·설문(현상 4 해결).
- 현재 위치 표시(active state) — 내비게이션 어디서든 지금 보고 있는 항목을 구분해 줘야 한다(색·굵기·밑줄). 웹 용어 16번 인터랙션 상태의 하나.
지시 예문
- “모바일에서 홈·검색·장바구니·마이 4개짜리 하단 tab bar를 화면 아래에 고정해줘. 현재 탭은 primary 색으로.”
- “상품 상세에 ‘상세정보 / 리뷰 / 문의’ tabs 만들어줘. 페이지 이동 없이 아래 내용만 바뀌게.”
- “통계 화면에 ‘일 / 주 / 월’ segmented control 넣어줘.”
- “카테고리 페이지 상단에 breadcrumb 추가하고, 회원가입 4단계에 stepper 붙여줘.”
입력 요소 이름: radio · checkbox · switch · select · combobox · chip
현상
- 성별처럼 하나만 골라야 하는 항목이 체크박스라 둘 다 체크된다.
- 알림 켜기/끄기를 체크박스로 만들었더니 저장 버튼을 눌러야 적용되는지, 바로 적용되는지 헷갈린다.
- 200개 국가 중 하나를 고르는 select를 열었더니 끝없이 스크롤해야 한다.
- 입력창 안 회색 안내 문구가 타이핑하자마자 사라져서 뭘 입력하던 칸인지 잊었다.
용어 — 고르는 방식이 다르면 이름도 다르다.
- text field / input(입력창) — 한 줄 입력. 여러 줄이면 textarea.
- radio button(라디오 버튼) — 동그라미. 여러 선택지 중 딱 하나만. 옛 라디오의 채널 버튼(하나 누르면 다른 게 튀어나옴)에서 온 이름. 선택지가 2~5개로 적고 한눈에 다 보여줘야 할 때(현상 1 해결).
- checkbox(체크박스) — 네모. 여러 개를 동시에 고르거나, 하나짜리면 “동의함” 같은 켜고 끄기. 보통 제출 버튼을 눌러야 반영된다.
- switch / toggle(스위치) — 좌우로 미는 스위치. 즉시 적용되는 켜고 끄기. 알림 설정, 다크 모드. 형광등 스위치처럼 누르는 순간 바뀐다(현상 2: 바로 적용이면 switch, 제출이 필요하면 checkbox).
- select / dropdown(선택 상자) — 눌러서 펼쳐지는 목록에서 하나 고르기. 선택지가 많을 때(라디오로 다 늘어놓기엔 많을 때) 쓴다.
- combobox / autocomplete(자동완성 입력) — 타이핑해서 걸러 고르는 select. 국가·도시·주소처럼 선택지가 아주 많을 때(현상 3 해결).
- chip / tag(칩) — 작은 둥근 알약(7번 레슨 pill). 필터 선택(“신상품” “무료배송”), 입력된 값 표시(받는 사람 이메일들). 눌러서 켜고 끄거나 ✕로 지운다.
- slider(슬라이더) — 막대를 끌어 범위나 값을 고름. 가격대, 볼륨. 정확한 값 입력엔 약하다.
- number stepper(수량 조절) —
[-] 2 [+]. 장바구니 수량. (10번 레슨의 단계 표시 stepper와 이름이 같아 헷갈리니 “수량 stepper”처럼 구분해 말한다.)
- date picker(날짜 선택기) — 달력에서 날짜 고르기. 보통 popover(9번 레슨)로 뜬다.
- label · placeholder · helper text
- label(라벨) — 입력창 위에 항상 보이는 이름. “이메일”.
- placeholder(플레이스홀더) — 입력창 안의 회색 예시 문구. “example@mail.com”. 타이핑하면 사라진다. 그래서 라벨 대신 쓰면 안 된다(현상 4의 원인).
- helper text(도움말) — 입력창 아래 작은 설명. “8자 이상, 숫자 포함”. 에러 시엔 이 자리에 inline error(웹 용어 22번).
지시 예문
- “성별 체크박스를 radio button으로 바꿔줘. 하나만 고를 수 있게.”
- “알림 설정 체크박스를 switch로 바꾸고, 누르는 즉시 저장되게 해줘.”
- “국가 select를 검색 가능한 combobox로 바꿔줘.”
- “입력창들이 placeholder만 있고 label이 없어. 위에 label을 항상 보이게 달고, placeholder는 예시 값으로만 써줘.”
콘텐츠 표시 이름: hero · card · list · table · badge · avatar · accordion · carousel
현상
- 주문 내역(날짜·상품·금액·상태)을 카드로 쌓았더니 비교가 안 되고 스크롤만 길다.
- 알림 아이콘 옆 빨간 숫자 동그라미를 뭐라고 불러야 할지 몰라 “빨간 점”이라고 설명했다.
- FAQ 20개가 다 펼쳐져 있어 한참 스크롤해야 원하는 질문을 찾는다.
- 메인 배너를 자동으로 넘어가는 슬라이드로 만들었는데 사용자가 두 번째부터는 거의 안 본다.
용어
- hero section(히어로 영역) — 랜딩·메인 페이지 맨 위 첫 화면의 큰 제목·이미지·CTA 영역. 첫인상과 핵심 메시지를 담는다(웹 용어 2번 LCP 요소가 보통 여기).
- card(카드) — 사진·제목·짧은 설명을 한 덩어리 상자로 묶은 것. 훑어보며 고르는 콘텐츠(상품, 글, 장소)에 맞다.
- list(리스트) / list item — 한 줄씩 세로로 쌓은 목록. 설정 메뉴, 연락처, 알림. 카드보다 촘촘하다.
- table / data table(표) — 행·열로 같은 속성을 줄 맞춰 비교하는 형태. 주문 내역, 관리자 목록처럼 비교·정렬·필터가 필요한 데이터엔 카드보다 표(현상 1 해결). 모바일에선 가로 스크롤이나 카드형으로 바꾼다.
- 고르는 기준: 훑어보고 고르기 → card / 빠르게 찾기 → list / 비교하기 → table.
- badge(배지) — 다른 요소에 붙어서 상태·개수를 알리는 작은 표시. 알림 아이콘 위 빨간 숫자, “NEW”, “품절”. 누를 수 없는 표시용(현상 2의 이름). 11번 레슨의 chip(누를 수 있는 선택용)과 구분.
- dot(점 배지) — 숫자 없이 점만. “새 소식 있음”.
- avatar(아바타) — 사용자 프로필 사진 동그라미. 사진이 없으면 이니셜·기본 아이콘으로 대체(fallback). 여러 개를 겹쳐 놓으면 avatar group.
- divider(구분선) — 영역 사이 얇은 선. 1번 레슨처럼 여백만으로 구분되면 굳이 안 쓰는 게 깔끔하다.
- accordion(아코디언) — 제목을 누르면 아래 내용이 펼쳐지고 접히는 목록. FAQ, 상세 스펙처럼 다 볼 필요는 없는 긴 내용에(현상 3 해결). 악기 아코디언의 접히는 주름에서 온 이름.
- carousel / slider(캐러셀) — 옆으로 넘겨 보는 슬라이드. 공간은 아끼지만 첫 장 이후는 잘 안 보이고, 자동 넘김은 읽기 전에 넘어가 불편하다(현상 4). 중요한 내용은 캐러셀 두 번째 장에 숨기지 않는다. 회전목마에서 온 이름.
지시 예문
- “주문 내역을 카드 대신 data table로 바꿔줘. 날짜·상품·금액·상태 열, 날짜순 정렬 가능하게. 모바일에선 카드형으로.”
- “알림 아이콘에 안 읽은 개수 badge 붙여줘. 99개 넘으면 99+.”
- “FAQ를 accordion으로 바꿔줘. 처음엔 다 접혀 있게.”
- “메인 캐러셀 자동 넘김 꺼주고, 가장 중요한 배너 하나만 hero section에 고정해줘.”
아이콘과 이미지: icon style · stroke · aspect ratio · focal crop
현상
- 어떤 아이콘은 선으로만, 어떤 건 꽉 채워져 있고, 선 굵기도 제각각이라 조잡해 보인다.
- 아이콘 크기가 14, 18, 22px로 섞여 글자 옆에서 들쭉날쭉하다.
- 하단 탭 바 아이콘만 보고는 무슨 메뉴인지 모르겠다.
- 상품 사진이 정사각형·세로·가로로 섞여 카드 그리드가 울퉁불퉁하다. 잘라 넣었더니 사람 얼굴이 잘렸다.
용어
- icon style(아이콘 스타일) — 크게 두 가지.
- outline / line(선형) — 선으로만 그린 것. 가볍고 깔끔.
- filled / solid(채움형) — 안을 채운 것. 무겁고 눈에 띔.
- 한 화면엔 한 스타일로 통일. 흔한 예외: 탭 바에서 선택된 탭만 filled, 나머지는 outline(10번 레슨 active state).
- stroke width(선 굵기) — 선형 아이콘의 선 두께. 1.5px·2px 등 하나로 통일해야 한 세트처럼 보인다. 그래서 아이콘은 한 아이콘 세트(icon set/library)에서만 가져온다(Lucide, Heroicons, Material Symbols 등). 여러 세트를 섞으면 현상 1이 된다.
- icon size(아이콘 크기 단계) — 16 · 20 · 24px처럼 정해진 단계(1번 레슨 spacing scale과 같은 발상). 글자 옆 아이콘은 글자 크기와 비슷하게(14~16px 글자엔 16px 아이콘), 세로 가운데 정렬(4번 레슨 optical alignment).
- icon + label(아이콘과 글자 함께) — 아이콘만으로 뜻이 통하는 건 소수(검색 🔍, 닫기 ✕, 홈, 장바구니). 나머지는 글자를 붙인다. 탭 바도 아이콘 아래 짧은 라벨을 다는 게 기본(현상 3). 아이콘만 쓰면 웹 용어 19번 aria-label을 꼭 단다.
- aspect ratio(종횡비, 화면비) — 가로:세로 비율. 1:1(정사각, 상품·프로필), 4:3, 3:2(사진), 16:9(영상·배너), 4:5(세로형 SNS). 한 목록 안에선 비율을 고정하고 이미지를 그 틀에 맞춘다(CSS
aspect-ratio + object-fit: cover). 비율을 고정하면 로딩 중 layout shift도 막는다(웹 용어 1번).
- crop(크롭) · focal point(초점 위치) — 비율에 맞추려 이미지를 자를 때 어느 부분을 살릴지. 기본은 가운데를 남기지만 얼굴·상품이 가장자리에 있으면 잘린다.
object-position으로 남길 위치를 지정한다(현상 4).
- illustration vs photo — 일러스트는 분위기·개념(빈 상태, 온보딩), 사진은 실물·신뢰(상품, 후기). 한 서비스 안에서 일러스트 화풍도 하나로 통일.
지시 예문
- “아이콘이 여러 세트가 섞여 있어. 전부 Lucide로 통일하고 stroke width 1.5, 크기는 16/20/24 단계만 써줘.”
- “하단 탭 바 아이콘 아래에 짧은 라벨 달고, 선택된 탭만 filled 아이콘으로.”
- “상품 카드 이미지를 1:1 aspect ratio로 고정하고 object-fit: cover로 맞춰줘.”
- “인물 썸네일이 크롭되며 얼굴이 잘려. object-position을 위쪽(center top)으로 바꿔줘.”
디자인 작업물: wireframe · mockup · prototype · Figma 기초
현상
- “화면 구조만 먼저 보자”고 했는데 AI가 색·이미지까지 완성된 화면을 만들어 와서, 구조 논의가 색 취향 논쟁으로 샜다.
- 피그마 시안을 코드로 옮겼더니 글자가 길어지면 박스가 안 늘어나고 깨진다.
- 시안에 버튼이 화면마다 조금씩 다르게 복사돼 있어 어느 게 기준인지 모른다.
용어 — 디자인은 거친 것에서 정교한 것 순서로 만든다. 단계 이름을 알면 “지금 어느 수준으로 만들어 달라”를 정확히 말할 수 있다.
- wireframe(와이어프레임) — 회색 상자와 선으로만 그린 뼈대. 무엇이 어디에 어떤 순서로 들어가는지(정보 구조·레이아웃)만 본다. 색·폰트·이미지는 일부러 뺀다(현상 1에서 원한 것).
- 비유: 건축 평면도. 방 배치를 정하는 단계에서 벽지 색은 고르지 않는다.
- low-fi / hi-fi(저충실도 / 고충실도) — 완성도 수준. low-fi = 대충 그린 와이어프레임, hi-fi = 실제와 거의 같은 시안.
- mockup(목업) / 시안 — 색·폰트·이미지까지 들어간 완성된 정지 화면. 눌러지지는 않는다. 건축의 완공 예상도.
- prototype(프로토타입) — 시안을 눌러 볼 수 있게 화면끼리 연결한 것. 흐름·인터랙션을 미리 확인한다. 건축의 모델하우스.
- design handoff(핸드오프) — 디자인을 개발로 넘기는 단계. 간격·색·폰트 값(spec)과 상태별 화면(웹 용어 22번 loading·empty·error)을 함께 넘긴다.
- Figma(피그마) 기초 용어 — AI에 피그마 시안을 줄 때 자주 나온다.
- frame(프레임) — 화면·영역을 담는 상자. HTML의 div에 해당.
- auto layout(오토 레이아웃) — 프레임 안 요소를 flex처럼 자동 정렬·간격(gap)·padding으로 배치하는 기능. 이걸로 만든 시안은 내용이 길어지면 박스가 같이 늘어나 코드로 옮기기 쉽다. 절대 위치로 대충 놓은 시안은 코드로 옮기면 깨진다(현상 2).
- component(컴포넌트) — 재사용하는 원본 요소. 복사본(instance)은 원본을 고치면 함께 바뀐다(웹 용어 31번 single source of truth, 6번 레슨 디자인 시스템).
- variant(변형) — 한 컴포넌트의 여러 버전(primary/secondary, 크기, hover·disabled 상태)을 묶은 것. 8번 레슨 button variant와 같은 개념. 현상 3은 컴포넌트·variant 없이 그냥 복사해서 생긴다.
- variables / styles — 피그마 안의 디자인 토큰(6번 레슨).
지시 예문
- “회원가입 흐름을 wireframe 수준으로만 먼저 만들어줘. 회색 상자와 텍스트만, 색·이미지는 빼고.”
- “이 wireframe을 hi-fi mockup으로 올려줘. 우리 디자인 토큰 써서.”
- “피그마 시안을 코드로 옮길 때 auto layout 구조를 그대로 flex·gap·padding으로 옮겨줘. 절대 위치 쓰지 말고.”
- “버튼을 Figma component로 만들고 primary/secondary/ghost와 default/hover/disabled variant로 정리해줘.”
비주얼 스타일 이름: minimal · flat · glassmorphism · neumorphism · bento · brutalism
현상
- “세련되게 해줘”, “요즘 느낌으로”라고 했더니 AI가 매번 보라색 그라데이션 + 둥근 카드 + 이모지의 비슷비슷한 화면을 만든다.
- 원하는 분위기가 있는데 뭐라고 불러야 할지 몰라 레퍼런스 사이트 주소만 계속 붙인다.
- 반투명 유리 느낌을 넣었더니 배경 사진 위에서 글자가 안 읽힌다.
용어 — 스타일 이름은 “분위기”를 한 단어로 전달하는 압축어다. 이름 + 핵심 특징 1~2개를 같이 말하면 정확하다.
- minimalism(미니멀) — 요소를 최소로, 여백·타이포·회색 위주(1·2·5번 레슨을 극단까지). 강조색 하나. 차분·고급.
- flat design(플랫) — 그림자·입체감 없이 평평한 색 면. 깔끔하지만 무엇이 눌리는지 구분이 약해질 수 있다.
- skeuomorphism(스큐어모피즘) — 실물을 사실적으로 흉내(가죽 질감 달력, 나무 책장). 초기 아이폰 스타일. flat의 반대편.
- material design(머티리얼) — 구글의 디자인 시스템. 종이가 겹친 듯한 그림자 단계(7번 레슨 elevation)가 특징. 안드로이드 앱 느낌.
- glassmorphism(글래스모피즘) — 반투명 유리판 느낌. 뒤가 흐릿하게 비치는 배경(
backdrop-filter: blur) + 얇은 밝은 테두리. 화려하지만 배경에 따라 대비가 무너져 글자가 안 읽힌다(현상 3, 5번 레슨). 반투명 판을 더 불투명하게 하거나 글자 뒤 배경을 어둡게 깐다.
- neumorphism(뉴모피즘) — 배경과 같은 색에서 밝은 그림자·어두운 그림자로 볼록·오목하게 튀어나온 듯한 부드러운 입체. 예쁘지만 대비가 낮아 버튼 구분이 어렵고 접근성이 약해 실서비스엔 드물다.
- claymorphism(클레이모피즘) — 말랑한 점토 장난감 같은 둥글고 통통한 입체. 친근·귀여움.
- bento grid(벤토 그리드) — 크기가 다른 사각 칸들을 도시락처럼 빈틈없이 짜 맞춘 레이아웃. 기능 소개·포트폴리오에 유행. 일본 도시락(벤토) 칸막이에서 온 이름.
- brutalism / neo-brutalism(브루탈리즘) — 일부러 거칠고 투박하게: 굵은 검정 테두리, 원색, 딱딱한 그림자(blur 없는 그림자), 기본 폰트 느낌. 개성 강함.
- 흔한 AI 스타일(generic AI look) — 보라·파랑 그라데이션, 모든 게 둥근 카드, 이모지 아이콘, 가운데 정렬 히어로. “세련되게”만 말하면 이쪽으로 수렴한다(현상 1). 스타일 이름 + 피하고 싶은 것을 같이 말하면 벗어난다.
지시 예문
- “랜딩 페이지를 minimal 스타일로 바꿔줘. 흰 배경, 회색 위주, 강조색은 진한 초록 하나, 그라데이션·이모지 금지.”
- “기능 소개 섹션을 bento grid로 배치해줘. 큰 칸 하나에 핵심 기능, 작은 칸들에 부가 기능.”
- “neo-brutalism 느낌으로: 2px 검정 테두리, blur 없는 딱딱한 그림자, 원색 배경.”
- “glassmorphism 카드에서 글자가 안 읽혀. 카드 불투명도를 높이고 대비 4.5:1 이상 맞춰줘.”
모션 기초: duration · easing · micro-interaction · reduced motion
현상
- 모달이 열릴 때 딱딱하게 툭 나타나서 어색하다. 그래서 애니메이션을 넣었더니 이번엔 느릿느릿해서 답답하다.
- 메뉴가 열릴 때 기계적으로 일정한 속도로 움직여 싸구려처럼 보인다.
- 화면 곳곳이 튀고 흔들려 정신없다. 멀미가 난다는 사용자도 있다.
용어
- transition(전환) — 상태가 바뀔 때(열림/닫힘, hover) A에서 B로 부드럽게 이어주는 움직임. UI 모션의 대부분.
- duration(지속 시간) — 움직임이 걸리는 시간. UI는 짧게: 작은 요소(버튼 hover·토글)는 100~200ms, 모달·드로어 같은 큰 요소는 200~300ms 안팎. 500ms를 넘으면 기다리는 느낌이 든다(현상 1 후반).
- easing(이징, 속도 곡선) — 움직이는 동안 속도가 어떻게 변하는지. 현실의 물체는 일정한 속도로 움직이지 않는다.
- linear — 처음부터 끝까지 같은 속도. 기계적이고 어색하다(현상 2). 로딩 스피너처럼 계속 도는 것에만.
- ease-out — 빠르게 출발해 천천히 멈춤. 나타나는 것(열림·등장)에. 반응이 즉각적으로 느껴진다. 대부분의 UI 기본값으로 무난.
- ease-in — 천천히 출발해 빠르게 끝남. 사라지는 것(닫힘·퇴장)에.
- ease-in-out — 천천히 출발·빠르게·천천히 멈춤. 화면 안에서 자리를 옮기는 움직임에.
- spring(스프링) — 용수철처럼 살짝 튕기며 멈추는 물리 기반 움직임. 친근하고 생동감 있다(iOS 느낌).
- 비유: 자동차. 출발하자마자 최고 속도로 달리다 벽에 쾅 멈추는 차(linear)는 없다. 부드럽게 가속하고 감속한다.
- micro-interaction(마이크로 인터랙션) — 작은 행동에 대한 작은 반응 모션. 좋아요 하트가 톡 커졌다 돌아옴, 토글 스위치가 미끄러짐, 버튼이 눌리면 살짝 작아짐(웹 용어 16번 active state). 기능은 같아도 살아 있는 느낌을 준다.
- 모션의 목적 — 장식이 아니라 변화를 이해시키는 것: 무엇이 어디서 나타나 어디로 갔는지. 목적 없는 움직임이 많으면 정신없다(현상 3). 한 화면에서 동시에 움직이는 건 적게.
- reduced motion(동작 줄이기) — OS 설정에서 “동작 줄이기”를 켠 사용자(멀미·전정 장애 등)를 위해 큰 움직임을 끄거나 단순한 페이드로 바꾸는 것. CSS
prefers-reduced-motion으로 감지한다.
- 더 세밀한 모션 이름(stagger, pop in, rubber-banding 등)이 필요하면
animation-vocabulary 스킬에 현상을 말해 이름을 찾을 수 있다.
지시 예문
- “모달이 툭 나타나. 200ms ease-out으로 살짝 아래에서 올라오며 페이드인, 닫힐 땐 150ms ease-in으로.”
- “애니메이션이 전부 linear에 400ms라 느리고 기계적이야. 등장은 ease-out, 퇴장은 ease-in, 200ms 안팎으로 바꿔줘.”
- “좋아요 버튼에 micro-interaction 넣어줘. 누르면 하트가 1.2배로 톡 커졌다 돌아오게.”
- “prefers-reduced-motion 켜진 사용자에겐 이동·확대 애니메이션 빼고 페이드만 남겨줘.”
UX writing: microcopy · voice & tone · 용어 통일
현상
- 에러가 나면 “오류가 발생했습니다(Error 500)”만 뜬다. 사용자는 무엇이 잘못됐고 뭘 하면 되는지 모른다.
- 어떤 화면은 “로그인”, 어떤 화면은 “로그 인”, “사인인”이라고 써서 같은 기능인지 헷갈린다.
- 어떤 문구는 “저장되었습니다”, 어떤 건 “저장했어요”, 어떤 건 “저장 완료!”라 말투가 들쭉날쭉하다.
- 버튼은 예쁜데 문구가 “제출”이라 누르면 무슨 일이 일어나는지 모르겠다(8번 레슨).
용어
- UX writing(UX 라이팅) — 화면 속 글자를 사용자 행동을 돕도록 쓰는 일. 디자인의 일부다. 버튼·에러·안내·빈 화면 문구 전부.
- microcopy(마이크로카피) — 버튼 라벨, 입력창 안내, 에러, 토스트처럼 짧은 화면 문구. 짧지만 사용자가 가장 많이 읽는 글.
- voice & tone(보이스와 톤)
- voice(보이스) — 서비스의 고정된 성격. “친근하고 쉬운 말”, “정중하고 정확한 말”. 어디서나 같다.
- tone(톤) — 상황에 따라 조절하는 말투. 성공 땐 가볍게, 에러·결제 실패 땐 차분하고 구체적으로.
- 비유: 같은 사람(voice)이라도 축하할 때와 사과할 때 말투(tone)는 다르다.
- 한국어 서비스에선 문체 통일이 핵심: 해요체(“저장했어요”)와 합쇼체(“저장되었습니다”) 중 하나로 정한다(현상 3).
- 좋은 에러 메시지 구조 — 무엇이 잘못됐는지 + 어떻게 고치는지. 사용자를 탓하지 않고, 기술 용어·에러 코드는 숨기거나 작게.
- ❌ “유효하지 않은 입력입니다.”
- ⭕ “이메일 형식이 맞지 않아요. 예: name@example.com”
- ⭕ “인터넷 연결이 끊겼어요. 연결을 확인하고 다시 시도해 주세요. [다시 시도]”
- 용어 통일(terminology) — 같은 기능·대상은 항상 같은 단어로. 로그인/사인인, 장바구니/카트, 회원/사용자 중 하나로 정해 용어집(glossary)으로 둔다(현상 2). 6번 레슨 디자인 토큰의 글자 버전.
- 빈 상태·확인 문구 — 웹 용어 22번 empty state는 “이유 + 다음 행동”, 8번 레슨 destructive 확인은 “결과를 구체적으로”: “게시글 3개가 영구 삭제돼요. 되돌릴 수 없어요.”
지시 예문
- “앱 전체 문구를 해요체로 통일해줘. 바꾼 문구 목록도 보여줘.”
- “에러 메시지를 ‘무엇이 잘못됐는지 + 어떻게 고치는지’ 구조로 다시 써줘. 에러 코드는 사용자에게 보이지 않게.”
- "’로그인’, ‘로그 인’, ‘사인인’이 섞여 있어. ‘로그인’으로 통일하고, 서비스 용어집 파일을 만들어줘.”
- “결제 실패 문구 톤을 차분하고 구체적으로 바꿔줘. 이모지 빼고, 다음에 할 일을 버튼으로.”
UX 원칙: affordance · feedback · 인지 부하 · Hick · Fitts · progressive disclosure
현상
- 글자처럼 생긴 버튼을 사용자가 누를 수 있는 건지 몰라 지나친다.
- 버튼을 눌렀는데 아무 변화가 없어서 또 누른다(웹 용어 27번 중복 제출로 이어짐).
- 설정 화면에 옵션이 40개 늘어서 있어 뭘 바꿔야 할지 몰라 그냥 닫는다.
- 모바일에서 자주 쓰는 버튼이 화면 맨 위 구석에 작게 있어 누르기 힘들다.
용어 — 왜 그렇게 디자인해야 하는지를 설명하는 원리 이름들. AI에게 “이 원칙에 맞게 고쳐줘”라고 말하는 근거가 된다.
- affordance(어포던스) — 생김새가 “이렇게 쓰면 돼”를 암시하는 성질. 문손잡이 모양이 “당겨라”를 말해주듯, 입체감 있는 버튼은 “눌러라”를 말해준다.
- signifier(시그니파이어) — 그 암시를 주는 구체적 단서. 버튼의 배경색·테두리, 링크의 밑줄·색, 끌 수 있는 손잡이 아이콘(⋮⋮). 단서를 다 지우면 누를 수 있는지 모른다(현상 1). 15번 레슨 flat 스타일의 약점.
- feedback(피드백) — 사용자의 행동에 즉시 반응해 “알아들었어”를 알려주는 것. 누른 순간의 눌림(웹 용어 16번 active), 처리 중 로딩(웹 용어 11번), 끝난 뒤 토스트(9번 레슨). 반응이 없으면 또 누른다(현상 2).
- consistency(일관성) — 같은 것은 같은 모양·위치·이름으로. 한 번 배운 걸 다른 화면에서도 쓰게 한다. 6번 토큰·14번 component·17번 용어 통일이 다 이 원칙.
- cognitive load(인지 부하) — 화면을 이해하려고 써야 하는 머리 품. 선택지·정보·결정이 많을수록 올라간다. 줄이는 게 좋은 디자인의 큰 축이다.
- Hick’s law(힉의 법칙) — 선택지가 많을수록 고르는 시간이 늘어난다. 메뉴·옵션은 줄이거나 묶는다(현상 3).
- 비유: 메뉴가 200개인 김밥천국보다 메뉴 5개인 맛집에서 주문이 빠르다.
- progressive disclosure(점진적 공개) — 처음엔 핵심만 보여주고, 고급·드문 옵션은 “고급 설정”, “더보기”로 필요할 때 펼치게 하는 것. Hick’s law와 인지 부하의 해법(현상 3 해결, 12번 레슨 accordion이 도구).
- Fitts’s law(피츠의 법칙) — 누를 대상이 클수록, 가까울수록 빨리·정확히 누른다. 자주 쓰는 버튼은 크게, 손가락이 닿기 쉬운 곳에(8번 레슨 터치 영역). 모바일에선 화면 아래쪽(엄지 영역)이 누르기 쉽다 — 하단 탭 바·bottom sheet가 많은 이유(현상 4).
- Jakob’s law(제이콥의 법칙) — 사용자는 시간 대부분을 다른 서비스에서 보내므로, 우리 서비스도 익숙한 관례대로 동작하길 기대한다. 로고 누르면 홈, 오른쪽 위 장바구니. 독창성보다 관례가 먼저.
지시 예문
- “텍스트처럼 보이는 버튼에 signifier가 없어. 배경색이나 밑줄로 누를 수 있다는 걸 드러내줘.”
- “버튼 누른 뒤 피드백이 없어. 누르는 순간 눌림 상태, 처리 중 스피너, 완료 시 토스트를 넣어줘.”
- “설정 옵션이 너무 많아. 자주 쓰는 5개만 보이고 나머지는 ‘고급 설정’에 접어두는 progressive disclosure로 바꿔줘.”
- “모바일 주요 액션 버튼을 Fitts’s law 기준으로 엄지가 닿는 화면 하단에 크게 배치해줘.”
다크 모드 디자인: surface · 순검정 피하기 · 채도 낮추기
현상
- 라이트 모드 색을 그대로 뒤집었더니 새까만 배경에 새하얀 글씨라 눈이 시리고 글자가 번져 보인다.
- 다크 모드에서 카드·모달이 배경과 구분이 안 된다. 그림자를 넣어도 안 보인다.
- 라이트 모드에서 예쁘던 진한 파랑·빨강이 다크 배경 위에선 형광처럼 튀거나 어둡게 묻힌다.
- 로고·일러스트 이미지가 흰 사각 박스째로 떠 보인다.
용어
- 다크 모드는 “색 반전”이 아니다 — 6번 레슨 semantic 토큰마다 다크용 값을 따로 설계한다. 단순 반전은 현상 1~3을 모두 만든다.
- 순검정(#000)·순백(#FFF) 피하기 — 배경은 아주 진한 회색(예:
#0F172A, #121212 계열), 본문 글자는 살짝 낮춘 흰색(90% 안팎 밝기). 극단 대비는 눈부심과 글자 번짐(halation)을 만든다. 그래도 5번 레슨 대비율 4.5:1은 지킨다.
- surface(서피스) 단계로 높이 표현 — 어두운 배경에선 그림자가 거의 안 보인다(현상 2). 대신 위에 떠 있을수록 조금씩 밝은 회색으로 7번 레슨 elevation을 표현한다. 배경 < 카드 < 드롭다운 < 모달 순으로 한 단계씩 밝게. 얇은 테두리를 함께 쓰기도 한다.
- 비유: 어두운 방에서 물건은 그림자로 안 보이고, 조명에 가까울수록 밝게 보이는 것으로 높이를 안다.
- 채도·명도 조정(desaturate) — 진하고 채도 높은 색은 어두운 배경 위에서 진동하듯 튀거나 묻힌다(현상 3). 다크 모드에선 primary·semantic 색을 조금 밝고(명도↑) 덜 쨍하게(채도↓) 조정한 값을 쓴다. 5번 레슨 shade scale에서 한두 단계 밝은 쪽을 고르는 식.
- 이미지·로고 대응 — 투명 배경(PNG·SVG) 로고를 쓰거나 다크용 버전을 따로 둔다. 흰 배경이 박힌 이미지는 박스째 떠 보인다(현상 4). SVG 아이콘은
currentColor로 글자색을 따라가게 한다.
- system preference(시스템 설정 따르기) — OS의 라이트/다크 설정을 기본으로 따르고(
prefers-color-scheme), 사용자가 직접 바꿀 수 있게 하는 게 관례. 첫 화면 깜빡임은 웹 용어 8번 “다크 모드 깜빡임” 참고.
지시 예문
- “다크 모드 배경을 #000 대신 아주 진한 남색 회색으로, 본문 글자는 순백 대신 90% 밝기로 바꿔줘. 대비 4.5:1은 유지.”
- “다크 모드에서 카드가 배경과 안 구분돼. 그림자 대신 surface 단계(배경 < 카드 < 모달)를 한 단계씩 밝게 줘.”
- “primary·error 색이 다크 모드에서 너무 쨍해. 다크용 semantic 토큰 값을 명도 올리고 채도 낮춘 걸로 따로 정해줘.”
- “로고가 다크 모드에서 흰 박스로 떠. 투명 배경 SVG로 바꾸고 다크용 색 버전도 만들어줘.”