표준 16차시 이후의 심화·선택 트랙입니다. 새 기술을 더 배우는 게 아니라, A~F에서 익힌 같은 원칙(위계·대비·피드백·절제)을 다른 조건(다양한 화면·짧은 글·움직임·AI 도구)에 적용합니다. 강사가 읽고 그대로 말할 수 있는 캡션 설명 산문을 슬라이드마다 넣었습니다.
이 트랙은 새 이론 네 개를 나열한 게 아니라, 이미 배운 하나의 원칙이 네 가지 다른 조건에서 어떻게 다시 적용되는지를 따라간다. 윗줄(G1~G3)은 화면·글·움직임이라는 조건이 바뀌어도 같은 원칙(대비·위계·피드백·절제)이 어떻게 살아남는지 보여주고, 아랫줄(G4)은 그 원칙들을 묶어 AI를 비판적으로 쓰는 눈으로 장 전체를 회수한다.
사용자는 같은 앱을 폰·태블릿·PC에서 번갈아 본다. 흔한 오해는 "PC 화면을 그대로 작게 줄이면 폰 화면"이라는 것이다. 그러면 글자가 깨알같이 작아지고 칸이 꾸겨진다. 반응형 디자인의 핵심은 줄이기가 아니라, 같은 정보의 위계를 화면 폭에 맞춰 다시 짜는 것이다 — 가로로 놓였던 카드 3개를 폰에선 세로로 쌓고, 메뉴는 햄버거(☰)로 접는다.
제일 좁은 폰부터 설계하고, 넓어질수록 요소를 더한다. 좁은 화면에서 살아남은 것이 진짜 핵심이기 때문. PC부터 만들면 폰에서 꾸겨진다.
화면 폭이 어떤 값을 넘으면 레이아웃을 바꾸는 기준선. 흔히 모바일~640 · 태블릿~768 · PC~1024px 근처에서 칸 수가 바뀐다.
<meta name="viewport" content="width=device-width, initial-scale=1">.다크모드를 "검정↔흰색을 뒤집는 일"로 오해하면 반드시 깨진다. 라이트모드의 연회색 글자(#999)를 검은 배경에 그대로 두면 대비가 부족해 글자가 안 읽히고, 흰 박스만 등불처럼 눈을 찌른다. 다크모드의 본질은 뒤집기가 아니라 — C장에서 배운 '대비 4.5:1'이라는 같은 원칙을, 어두운 조건에서도 유지하면서 눈부심만 줄이는 것이다. 조명을 낮춰도 글자는 계속 보여야 한다.
화면 속 버튼 라벨·안내문·빈 화면의 한 마디는 갈림길의 표지판과 같다. "정상 →"이면 망설임 없이 가지만, "주의"라고만 적혀 있으면 뭘 주의하라는 건지 몰라 멈춰 선다. 이 짧은 글이 마이크로카피다. 핵심 원칙은 A장의 '헤맴을 없앤다'와 같다 — 다만 도구가 레이아웃이 아니라 단어일 뿐이다. 누르면 뭐가 되는지 라벨만 봐도 알게 하는 것이 전부다.
"확인" 대신 지금 하는 행동을 그대로 — "주문 완료하기 · 사진 올리기 · 친구 초대하기". 사람 말투·짧게·능동으로("처리가 완료되었습니다"✗ → "보냈어요"✓).
단골 반론이 있다 — "글은 짧을수록 좋으니 결제 버튼도 그냥 '확인'이 낫지 않나?" 절반만 맞다. 군더더기를 줄이는 건 옳지만, 정보가 빠지면 그건 간결이 아니라 불친절이다. 짧게 만드는 목적은 글자 수 줄이기가 아니라 '무엇이 되는지 빨리 알게' 하는 것이다. 그 목적을 해치면서까지 짧게 만들면 오히려 사용자를 다시 헤매게 한다.
"확인" / "오류 발생" / "데이터 없음"
글자는 짧지만 '무엇이·어떻게'가 빠져 사용자가 멈춘다.
잘 만든 영화는 장면이 바뀔 때 카메라가 부드럽게 따라가 "여기서 저기로 갔구나"가 자연스럽게 이해된다. 컷이 뚝뚝 끊기면 관객은 "어? 방금 뭐였지?" 하고 길을 잃는다. 앱의 화면 전환·애니메이션도 똑같다. 모션의 진짜 일은 예쁘게 보이는 게 아니라 — 무엇이 어디서 와서 어디로 갔는지 공간과 인과를 이어주는 것이다. 이건 D장에서 배운 '피드백' 원칙이 시간 축으로 확장된 것이다.
메뉴가 어디서 펼쳐졌는지, 삭제한 항목이 어디로 사라졌는지를 눈으로 따라가게 해 '길'을 잃지 않게 한다.
보통 200~300ms. 너무 빠르면(0.1초↓) 안 보이고, 너무 느리면(0.5초↑) 굼떠 보인다.
처음 살짝 빠르게, 끝에서 부드럽게 멈춤. 일정 속도(linear)는 기계적이고 어색하다.
"애니메이션은 화려할수록 좋다"는 흔한 믿음은 틀렸다. 모든 요소가 통통 튀고 빙글 돌면 화려한 게 아니라 어지럽다. 게다가 화면 전환마다 1초씩 기다리게 하면 앱이 느리게 느껴진다. 모션도 C장의 '절제' 원칙을 따른다 — 꼭 필요한 곳(화면 전환·상태 변화·새 항목 등장)에만 쓴다. 더 중요한 건, 어지럼에 민감한 사용자를 위해 모션을 끌 수 있어야 한다는 점이다.
→ 느려 보이고, 산만하고, 멀미를 부른다.
@media (prefers-reduced-motion: reduce)(MDN 문서화)로 애니메이션을 약하게 하거나 끌 수 있다. 어지럼·전정기관 장애가 있는 사용자에게 모션은 실제 불편이므로, 좋은 디자인은 이 신호를 존중한다 — 이것도 '사용자를 헤매게(괴롭게) 하지 않는다'는 같은 원칙이다.자동차 내비게이션은 길을 똑똑하게 추천하지만, 가끔 막다른 길로 안내하거나 공사 구간을 모른다. 그래서 운전자는 내비를 참고하되 운전대는 자기가 잡는다. design-sense 분석 탭의 AI 피드백도 똑같다. AI는 색·대비·정렬을 빠르게 짚어주는 유능한 조언자지만, '정답'을 내려주는 심판은 아니다. 흔한 통념 — "전문가가 만든 도구니까 시키는 대로 다 반영하면 된다" — 이 첫 번째로 깨야 할 오해다.
AI는 종종 "전환율을 올리려면 동의 버튼을 거대하게, 거절 버튼을 회색으로 작게 숨겨라" 같은 조언을 한다. 매출엔 좋아 보여도 이건 사용자를 속이는 디자인(다크패턴)이다. 여기서 E2(원칙·윤리) 장의 결론이 회수된다 — 최종 판단과 책임은 사람이고, 내 디자인의 이유는 내가 말로 설명할 수 있어야 한다. "AI가 그러래서"는 이유가 아니다.
| AI가 줄 수 있는 조언 | 비판적으로 되묻기 | 판단 |
|---|---|---|
| "본문 글자 대비가 낮다" | 4.5:1 기준으로 내 눈으로 확인 → 정말 안 읽히나? | 원리로 검증 후 수용 |
| "이 색이 더 트렌디하다" | 왜? 내 앱(누가·왜 쓰나)에 맞는 이유가 있나? | 이유 없으면 보류 |
| "거절 버튼을 숨겨 전환율을 올려라" | 사용자를 속이는가? → 다크패턴 | 권해도 거른다 |
이 트랙은 새로운 디자인 기술 네 개를 배운 게 아니다. A~F에서 익힌 같은 원칙(위계·대비·피드백·절제, 그리고 헤맴 없애기)이 조건만 바뀐 네 무대에서 어떻게 다시 적용되는지를 따라갔다. 그리고 그 모든 원칙은 마지막에 'AI를 비판적으로 쓰는 눈'으로 모여 A~G 전체를 닫는다.