히어로 섹션 hero section
페이지 최상단에서 화면을 거의 다 차지하는 첫 화면. 한 줄 메시지 + 보조 설명 + 주 행동 버튼이 기본 구성이다.
언제 방문자가 3초 안에 “여기가 뭐 하는 곳인지” 판단하게 만들 때. 문장이 길어지면 히어로가 아니라 서문이 된다.
도키피디아 v1.3
UI·UX 용어부터 스타일, 컬러, 모션, AI 워크플로까지. 모든 예시는 이 문서 안에서 실제로 작동합니다.
화면에 실제로 놓이는 것들의 이름. 각 항목의 예시는 이 문서 안에서 실제로 작동합니다 — 움직이는 것은 실제로 움직이고, 눌리는 것은 실제로 눌립니다.
페이지 최상단에서 화면을 거의 다 차지하는 첫 화면. 한 줄 메시지 + 보조 설명 + 주 행동 버튼이 기본 구성이다.
언제 방문자가 3초 안에 “여기가 뭐 하는 곳인지” 판단하게 만들 때. 문장이 길어지면 히어로가 아니라 서문이 된다.
스크롤해도 상단에 붙어 따라오는 내비게이션. position:sticky; top:0 한 줄이면 된다.
언제 페이지가 길고 이동이 잦을 때. 모바일에서는 높이가 화면을 잡아먹으니 얇게 유지한다.
도시락 칸처럼 크기가 다른 칸을 격자에 짜 맞추는 레이아웃. 정보 중요도를 칸 크기로 표현한다.
언제 성격이 다른 정보 여럿을 한 화면에 놓을 때. 칸 크기가 전부 같으면 벤토가 아니라 그냥 카드 그리드다.
관련된 정보 한 덩어리를 테두리·배경·그림자로 묶어 독립된 단위로 보이게 한 것.
언제 목록의 각 항목이 독립적으로 클릭·비교될 때. 주의 카드 안에 카드를 또 넣는 것은 AI가 만든 화면의 대표 증상이다.
데이터가 오기 전에 콘텐츠의 모양을 회색 블록으로 미리 보여주는 로딩 표현. 빈 화면이나 스피너보다 체감 대기시간이 짧다.
언제 로딩이 0.3~2초 정도로 예측 가능하고, 최종 레이아웃을 미리 알 때. 레이아웃을 모르면 스피너가 낫다.
스피너는 얼마나 걸릴지 모를 때(비결정형), 프로그레스 바는 진행률을 알 때(결정형) 쓴다. 둘을 바꿔 쓰면 사용자가 진행률을 오해한다.
언제 1초 이상 걸리는 모든 작업. 1초 미만이면 아무것도 띄우지 않는 편이 덜 산만하다.
화면 모서리에 잠깐 떴다 사라지는 알림. 작업을 막지 않는다는 점에서 모달과 다르다.
언제 성공·실패를 알리되 흐름을 끊고 싶지 않을 때. 되돌리기가 필요한 파괴적 작업에 특히 잘 맞는다.
뒤 화면을 가리고 사용자의 응답을 강제로 받아내는 창. 흐름을 끊기 때문에 남용하면 바로 이탈로 이어진다.
언제 되돌릴 수 없는 작업의 확인, 반드시 받아야 하는 입력. 마케팅 팝업에 쓰면 그건 다크 패턴 쪽에 가깝다.
툴팁은 마우스를 올리면 뜨는 짧은 설명 문구, 팝오버는 클릭으로 열리고 버튼·링크가 들어갈 수 있는 작은 패널이다.
이 값은 전환율 기준으로 계산됩니다.
언제 툴팁은 보조 설명 전용 — 툴팁에만 있는 정보는 모바일과 키보드 사용자에게 사라진다. 중요한 내용은 본문에 쓴다.
제목만 나열해 두고 클릭한 항목만 펼쳐 보이는 접이식 목록. HTML <details>만으로 자바스크립트 없이 만들 수 있다.
영업일 기준 2~3일입니다.
수령 후 7일 이내 가능합니다.
언제 FAQ처럼 항목이 많고 대부분은 안 읽을 때. 반대로 전부 읽어야 하는 내용을 접어두면 그냥 숨긴 것이다.
같은 자리에서 내용을 바꿔 끼우는 전환 장치. 항목끼리 대등한 관계일 때만 쓴다.
2주 만에 재구매율이 18% 올랐습니다.
언제 항목이 2~5개이고 이름만 봐도 내용이 짐작될 때. 순서가 있는 절차라면 탭이 아니라 스텝(마법사)이다.
붙어 있는 버튼 묶음에서 하나만 선택되는 컨트롤. 선택지가 적고 결과가 즉시 바뀔 때 라디오 버튼보다 빠르다.
언제 선택지 2~4개, 라벨이 짧을 때. 5개가 넘어가면 드롭다운으로 바꾼다.
눌러야 목록이 나오는 선택 컨트롤. 선택 전에는 무엇이 있는지 보이지 않는다는 것이 가장 큰 비용이다.
언제 선택지가 6개 이상이거나 화면이 좁을 때. 국가·연도처럼 목록이 길고 익숙한 값일수록 적합하다.
토글은 즉시 적용되는 켬/끔, 체크박스는 여러 개 선택 후 저장, 라디오는 여럿 중 하나. 셋을 섞어 쓰면 사용자는 저장 버튼을 눌러야 하는지 몰라 헤맨다.
언제 토글 = 설정 화면, 체크박스 = 폼, 라디오 = 배타적 선택. 토글 옆에 저장 버튼이 있으면 설계가 틀린 것이다.
입력 전에는 칸 안에 있던 라벨이, 입력을 시작하면 위로 떠올라 작아지는 방식. 플레이스홀더만 쓰면 입력하는 순간 무슨 칸인지 사라진다는 문제를 해결한다.
언제 폼이 길고 칸마다 라벨을 위에 두기엔 공간이 아까울 때. 주의 플레이스홀더만으로 라벨을 대신하지 않는다.
데이터가 아직 하나도 없을 때 보이는 화면. 대부분의 서비스에서 신규 사용자가 가장 먼저 보는 화면인데도 가장 늦게 설계된다.
언제 목록·검색결과·대시보드 등 데이터에 기대는 모든 화면. “왜 비었는지 + 무엇을 하면 되는지” 두 가지를 반드시 넣는다.
배지는 상태를 표시만 하고, 칩은 누르거나 지울 수 있는 조작 가능한 조각이다. 생김새가 비슷해 자주 혼동된다.
언제 배지는 상태·개수 표시, 칩은 필터·선택된 값 표시. 배지에 클릭 기능을 넣으면 사용자는 눌러도 되는지 모른다.
한 화면에서 가장 원하는 행동 하나만 채운 버튼(primary)으로 하고, 나머지는 테두리(secondary)나 글자(ghost)로 낮춘다.
언제 버튼이 두 개 이상 놓이는 모든 자리. 화면당 primary는 하나가 원칙이다.
키보드 Tab으로 이동할 때 현재 위치를 표시하는 테두리. 보기 싫다고 outline:none으로 지우면 키보드 사용자는 자기 위치를 잃는다.
언제 항상. 디자인이 마음에 안 들면 지우지 말고 :focus-visible로 모양을 바꾼다.
누름·호버·전환 같은 작은 순간에 붙는 짧은 반응. 기능은 그대로인데 “잘 만든 것 같다”는 인상을 만드는 대부분이 여기서 나온다.
언제 사용자의 행동에 시스템이 반응했음을 알려야 할 때. 0.15~0.35초를 넘기면 빠릿함이 사라지고 답답해진다.
마우스를 올렸을 때 생기는 변화. “누를 수 있다”는 신호이자, 데스크톱에서 밀도 높은 정보를 탐색하게 해주는 장치다.
언제 데스크톱 전용 보조 장치로. 주의 호버로만 접근되는 메뉴·정보는 터치 기기에서 통째로 사라진다.
스크롤할 때 배경과 앞 요소가 다른 속도로 움직여 깊이감을 만드는 기법.
언제 브랜드 사이트의 도입부처럼 인상이 중요한 구간에. 본문 읽기 구간에 넣으면 멀미와 성능 저하만 남는다.
요소가 화면에 들어오는 순간 나타나게 하는 연출. 여러 요소를 조금씩 시차를 두고 등장시키는 것을 스태거라 한다.
언제 처음 보이는 구간에서 시선 순서를 만들 때. 스태거 간격은 60~100ms가 무난하고, 이미 본 구간을 다시 애니메이션하면 성가시다.
여백을 아무 값이나 쓰지 않고 4 또는 8의 배수처럼 정해진 계단에서만 고르는 규칙. 화면이 정돈돼 보이는 이유의 대부분이 이것이다.
언제 처음부터. AI에게 시킬 때도 “여백은 4의 배수만 사용”처럼 못 박아두면 결과가 크게 달라진다.
글자 크기도 마찬가지로 계단을 정해 두고 그 안에서만 고른다. 크기 차이가 곧 정보의 위계가 된다.
언제 폰트 크기를 두 번째로 정하는 순간부터. 본문 16px을 기준으로 1.2~1.33배씩 올리는 방식이 가장 무난하다.
색을 --blue-500이 아니라 --accent, --surface처럼 역할 이름으로 정의하는 것. 다크 모드가 값 교체만으로 끝나는 이유다.
언제 라이트/다크를 모두 지원하거나 테마가 바뀔 가능성이 있을 때. 색상값을 코드에 직접 쓰기 시작하면 되돌리기 어렵다.
정지 아이콘 대신 호버·클릭에 반응해 움직이는 아이콘. 상태 변화(재생↔정지, 열림↔닫힘)를 설명 없이 전달한다.
언제 알림·좋아요·전송처럼 결과가 순간적인 행동에. 목록 안 모든 아이콘이 움직이면 화면이 소란스러워진다.
사용자가 겪는 과정에 관한 말들. UI가 “무엇을 놓는가”라면 UX는 “그래서 어떻게 되는가”다. 겉모습이 아니라 순서·부담·회복에 관한 판단이라, 예시는 대부분 좋은 예/나쁜 예 비교나 개념 도해로 보여준다.
UI는 화면에 놓인 것, UX는 그 화면을 거쳐 목적을 이루는 경험 전체. 예쁜 버튼(UI)이 있어도 결제까지 7단계(UX)면 실패한다.
언제 “UI를 고쳐달라”는 요청이 사실은 흐름 문제일 때가 많다. 화면을 손대기 전에 단계 수부터 센다.
콘텐츠를 어떻게 묶고 이름 붙이고 계층을 나눌지에 대한 설계. 메뉴 이름이 곧 정보 구조의 결과물이다.
언제 페이지를 그리기 전에. 메뉴 이름이 안 정해졌다면 아직 디자인할 단계가 아니다.
어포던스는 그 물건이 할 수 있는 일, 시그니파이어는 그걸 알려주는 단서. 링크가 눌리는 건 어포던스, 밑줄과 파란색은 시그니파이어다.
자세한 내용은 여기를 보세요
자세한 내용은 가격표 페이지를 보세요
언제 “왜 아무도 이 버튼을 안 누르죠?” 소리가 나올 때. 대개 기능이 아니라 단서가 없는 것이다.
크기·굵기·색·여백으로 “이걸 먼저 보라”는 순서를 만드는 것. 위계가 없으면 사용자는 전부를 훑다가 아무것도 안 읽는다.
언제 모든 화면에서. 눈을 가늘게 뜨고 봤을 때 제일 먼저 보이는 것이 제일 중요한 것이어야 한다.
선택지가 많을수록 결정 시간이 길어진다. 선택지를 줄이거나 묶어서 한 번에 판단할 개수를 줄이는 것이 해법이다.
언제 요금제·메뉴·필터 설계. 요금제를 5개에서 3개로 줄이면 전환이 오르는 이유가 이것이다.
목표가 크고 가까울수록 빨리 누른다. 중요한 버튼은 크게, 자주 쓰는 것은 손이 닿는 곳에 둔다.
언제 모바일 하단 바, 주 행동 버튼, 삭제 버튼 위치. 위험한 버튼은 일부러 작고 멀리 두는 것도 이 법칙의 응용이다.
사용자는 다른 사이트에서 보낸 시간이 훨씬 많다. 그래서 익숙한 관습을 따르는 편이 대체로 옳다.
언제 로고 위치, 장바구니 위치, 검색 아이콘 모양 같은 관습. 창의성은 브랜드 표현에 쓰고 탐색 구조에는 쓰지 않는다.
사람이 한 번에 붙잡아 두는 항목은 대략 7±2개, 실무에서는 4~5개로 보는 편이 안전하다. 길면 덩어리로 묶어(chunking) 준다.
언제 전화번호·카드번호·인증코드 입력, 긴 메뉴 그룹핑. 자릿수 구분만으로 오입력이 줄어든다.
사람은 가까이 있는 것(근접), 닮은 것(유사), 둘러싸인 것(공통 영역)을 한 덩어리로 본다. 선을 긋지 않아도 여백만으로 묶을 수 있는 이유다.
언제 라벨과 입력칸의 간격, 카드 안 요소 묶기. 라벨이 위 칸에 더 붙어 있으면 사용자는 그 칸의 라벨로 읽는다.
지금 필요한 것만 보여주고 나머지는 요청할 때 펼치는 방식. 화면을 단순하게 유지하면서 기능은 유지한다.
언제 초보자와 숙련자가 같은 화면을 쓸 때. 다만 필수 항목을 접어두면 그건 숨긴 것이지 정리한 것이 아니다.
시스템이 지금 무엇을 하는지 사용자에게 계속 알려주는 것. 응답이 없으면 사용자는 같은 버튼을 여러 번 누른다.
언제 서버를 기다리는 모든 버튼. 누른 즉시 비활성 + 상태 문구로 바꾸는 것이 중복 제출을 막는 가장 싼 방법이다.
에러 메시지를 잘 쓰는 것보다 에러가 나지 않게 막는 것이 우선이고, 그다음이 되돌릴 수 있게 하는 것이다.
언제 폼 검증, 삭제·전송 같은 파괴적 작업. “정말 삭제할까요?” 모달보다 “삭제됨 + 되돌리기”가 대체로 낫다.
사용자가 목적을 이루려고 머리에 이고 있어야 하는 양. 화면을 예쁘게 만드는 것보다 이걸 줄이는 게 대개 효과가 크다.
4821을 입력하세요
언제 여러 단계를 거치는 흐름. “기억하게 하지 말고 보이게 하라”가 원칙이다.
글이 많은 화면은 F자로, 시각 요소 위주의 화면은 Z자로 훑는 경향이 있다. 핵심 문구를 그 경로에 놓는다.
언제 히어로 문구·CTA 배치. Z 패턴에서 CTA는 마지막 꺾임(우하단)에 두는 것이 자연스럽다.
글자와 배경의 밝기 차이. 본문은 4.5:1 이상, 큰 글자·아이콘은 3:1 이상이 접근성 기준(WCAG AA)이다.
언제 회색 본문, 반투명 텍스트, 그라디언트 위 글자. “세련돼 보여서” 낮춘 대비가 접근성 문제의 1순위다.
손가락으로 누를 영역은 최소 44×44px(iOS 권장) 안팎이 필요하다. 아이콘이 작아도 누를 수 있는 영역은 키울 수 있다.
언제 모바일 아이콘 버튼, 목록의 삭제 버튼, 탭 바. 인접한 두 타깃 사이 간격도 8px 이상 둔다.
화면 폭에 따라 레이아웃을 바꾸는 것. 기기 이름이 아니라 내용이 깨지는 지점에서 끊는 것이 원칙이다.
위 그리드는 미디어 쿼리 없이 auto-fit + minmax만으로 접힙니다.
언제 처음부터. 좁은 화면을 먼저 그리고 넓힐 때 규칙을 더하는 쪽이 반대보다 훨씬 쉽다.
처음 온 사용자가 첫 성공에 도달하기까지의 과정. 기능 소개가 아니라 “한 번 해보게 하는 것”이 목적이다.
언제 가입 직후. 투어 슬라이드는 대부분 건너뛰기 눌린다 — 진행률과 첫 결과물을 보여주는 편이 낫다.
사용자가 의도하지 않은 선택을 하게 유도하는 설계. 단기 지표는 오르지만 신뢰와 재방문을 갉아먹는다.
언제 절대 쓰지 않기. 해지 숨기기, 기본 체크된 동의, 가짜 카운트다운도 같은 범주다.
방문 → 관심 → 행동으로 좁아지는 단계와, 각 단계에서 빠져나가는 비율. 어디가 새는지 모르면 어디를 고칠지도 모른다.
언제 개선 순서를 정할 때. 가장 많이 새는 한 단계를 고치는 것이 나머지 전부를 다듬는 것보다 크다.
사용성 테스트는 왜 막히는지를 소수에게서 관찰로 알아내고, A/B 테스트는 어느 쪽이 나은지를 다수에게서 숫자로 가른다. 순서를 바꾸면 잘못된 안 두 개를 비교하게 된다.
| 사용성 테스트 | A/B 테스트 | |
|---|---|---|
| 답하는 질문 | 왜 막히는가 | 어느 쪽이 나은가 |
| 인원 | 5명 내외 | 통계적으로 충분한 수 |
| 산출 | 관찰·발언 | 지표 차이 |
| 쓰는 시점 | 만들기 전·중 | 후보가 둘 이상일 때 |
언제 사용성 테스트는 5명만 해도 문제의 대부분이 드러난다. A/B는 트래픽이 충분할 때만 의미가 있다.
지금 웹에서 자주 쓰이는 스타일 10가지. 각 스타일의 특징을 이 문서 안에서 직접 재현했습니다. 스타일 이름 자체가 프롬프트입니다 — “예쁘게”가 아니라 “브루탈리즘으로”라고 말하면 통합니다.
반투명 + 배경 흐림으로 유리판이 겹친 듯한 표현. backdrop-filter: blur()가 핵심이다.
어울리는 곳 SaaS·핀테크·AI 서비스의 오버레이 카드. 주의 배경이 단색이면 효과가 사라지고, 대비가 낮아져 글자가 안 읽히기 쉽다.
배경과 같은 색의 면에 밝은 그림자와 어두운 그림자를 양쪽으로 넣어 눌리고 튀어나온 느낌을 만드는 방식.
어울리는 곳 스마트홈·오디오 등 물리 기기를 흉내 내는 UI. 주의 경계가 흐려 대비 확보가 어렵다 — 접근성 문제로 본문 UI에는 거의 쓰지 않는다.
굵은 산세리프, 원색, 각진 테두리, 장식 없는 노골적 구조. 세련됨을 일부러 걷어내 강한 인상을 남긴다.
어울리는 곳 크리에이티브 스튜디오, 페스티벌, 패션. 주의 정보량이 많은 서비스에 쓰면 그냥 읽기 힘든 화면이 된다.
요소를 덜어내고 여백과 타이포만으로 위계를 만드는 방식. 뺄 게 없을 때까지 빼는 것이 목표다.
어울리는 곳 포트폴리오, 프리미엄 제품, 문서형 서비스. 주의 여백이 넉넉해야 성립한다 — 요소만 지우고 간격을 안 늘리면 그냥 빈약해 보인다.
잡지 지면처럼 세리프 타이포와 그리드로 구성하는 방식. 글자 자체가 그래픽 역할을 한다.
어울리는 곳 매거진, 브랜드 스토리, 리서치 리포트. 주의 모바일에서 다단은 거의 항상 한 단으로 접어야 한다.
여러 색의 원형 그라디언트를 겹쳐 부드러운 색 번짐을 만드는 배경. 사진 없이 분위기를 만들 수 있어 SaaS에서 많이 쓴다.
어울리는 곳 AI·개발자 도구·보안 서비스의 히어로. 주의 보라 계열 메시는 AI가 기본으로 뱉는 조합이라 가장 흔해졌다 — 색을 바꾸지 않으면 “AI가 만든 티”가 난다.
어두운 배경에 형광 강조색 하나를 얹는 구성. 개발자 도구·인프라 서비스의 사실상 표준이 됐다.
어울리는 곳 개발자 도구, 데이터·인프라, 게임. 주의 순수 검정(#000)에 순수 흰색은 눈이 피로하다 — 배경은 살짝 밝게, 글자는 살짝 어둡게 둔다.
크기가 다른 칸을 격자에 짜 맞추는 레이아웃. UI 용어 섹션에 작동 예시가 있다.
어울리는 곳 제품 기능 소개, 대시보드, 포트폴리오 인덱스.
체커보드, 형광 핑크, 브라운관, 반짝이 같은 2000년대 초 시각 언어를 다시 꺼내 쓰는 스타일.
어울리는 곳 10~20대 타깃 커머스, 굿즈, 이벤트 페이지. 주의 신뢰가 중요한 업종(금융·의료·법률)과는 정면으로 충돌한다.
3D 오브젝트와 스크롤·드래그 인터랙션으로 공간감을 만드는 방식. Spline, Three.js, Rive 등으로 구현한다.
어울리는 곳 제품 쇼케이스, 스튜디오 포트폴리오, 브랜드 캠페인. 주의 용량과 성능 비용이 크고 모바일에서 발열·배터리 문제가 생긴다 — 정적 대체 화면을 반드시 준비한다.
“색은 취향이 아니라 전략이다. 변호사 웹사이트가 형광 핑크면 실력이 아무리 좋아도 어색해 보인다.” — 무드별로 메인 · 배경 · 포인트 세 자리를 정하는 프레임워크.
색을 개수로 세지 말고 역할로 정한다. 메인은 브랜드를 대표하고, 배경은 화면 대부분을 차지하며, 포인트는 행동을 유도한다.
언제 팔레트를 고를 때. 포인트색은 화면에서 가장 적게 쓰여야 포인트가 된다 — 전부 칠하면 아무것도 강조되지 않는다.
업종이 아니라 주고 싶은 인상에서 출발한다. 같은 업종이라도 목표하는 인상이 다르면 팔레트가 달라진다.
언제 프로젝트 시작 시. AI에게 넘길 때는 무드 이름 대신 hex 세 개를 역할과 함께 주면 결과가 훨씬 안정된다.
“고급스러워 보인다”는 인상의 상당 부분은 정지 화면이 아니라 상태가 바뀌는 순간에서 만들어집니다. 12가지 모두 이 문서 안에서 실제로 작동합니다. 표의 효과 이름을 누르면 해당 데모로 이동합니다.
| 효과 | 트리거 | 쓰는 자리 |
|---|---|---|
| Hover Effects 호버 효과 | 마우스 올림 | 카드·썸네일. 데스크톱 전용 보조 장치 |
| Smooth Loader 부드러운 로딩 | 페이지 로드 | 첫인상. 로고·문구가 서서히 드러남 |
| 3D Motion 3D 모션 | 스크롤 · 드래그 | 제품 쇼케이스. 화면에 Scroll & Drag 안내를 함께 |
| Entrance Reveal 등장 연출 | 화면 진입 | 섹션 첫 등장. 스태거로 시선 순서를 만듦 |
| Micro Interaction 마이크로인터랙션 | 클릭 · 입력 | 좋아요·저장·전송 등 작은 확인 |
| Parallax Effect 패럴랙스 | 스크롤 | 도입부 깊이감. 본문 읽기 구간은 피함 |
| Text Reveal 텍스트 리빌 | 화면 진입 | 헤드라인. 줄·단어 단위로 끊어 올림. 본문 전체에 걸면 읽기 방해 |
| Sticky Scroll 스크롤 고정 | 스크롤 | 한 장면을 붙잡고 내용만 바꾸는 구간. 제품 기능 3단계 설명 등 |
| Scroll Progress 진행 표시 | 스크롤 | 긴 글의 남은 분량. 상단 얇은 막대 하나면 충분 |
| Marquee 흐르는 띠 | 자동 반복 | 로고 목록·후기 띠. 정지 버튼이나 호버 정지를 같이 둠 |
| Shared Element 공유 요소 전환 | 클릭 · 페이지 이동 | 목록 → 상세로 넘어갈 때 같은 이미지가 이어지는 연출. 맥락이 끊기지 않음 |
| Skeleton → Content 로딩 해제 | 데이터 도착 | 회색 블록이 실제 내용으로 바뀌는 순간. 튀지 않게 짧은 페이드로 |
공통 원칙 대부분 Framer 같은 노코드 툴로도 구현되므로 코드가 전제 조건은 아닙니다. 트리거(호버/스크롤/로드/클릭)가 겹치지 않게 배분하는 것이 요령입니다.
평면 카드에 깊이를 넣는 연출. perspective로 소실점을 잡고 rotateX/rotateY로 기울입니다.
제품 쇼케이스처럼 "만져볼 수 있을 것 같은" 인상이 필요한 자리에 씁니다.
언제 제품 소개 히어로, 포트폴리오 카드. 주의 각도를 15~20도 넘기면 글자가 읽히지 않습니다. 본문 카드에는 쓰지 않습니다.
헤드라인을 줄 단위로 끊어 올리는 연출. 각 줄을 overflow:hidden 상자에 넣고 아래에서 밀어 올립니다.
아래 데모는 animation-timeline: view()로 만들어, 화면에 들어올 때마다 다시 재생됩니다.
미지원 브라우저에서는 애니메이션 없이 그대로 보입니다.
언제 첫 화면 헤드라인 한 덩어리. 주의 본문 문단 전체에 걸면 읽기를 방해합니다. 줄 수는 3줄 안쪽으로.
같은 목록을 끊임없이 흘려보내는 띠. 로고 모음이나 후기처럼 "많다"는 인상만 주면 되는 자리에 씁니다. 같은 내용을 두 벌 이어 붙이고 절반만큼 밀면 이음매가 보이지 않습니다.
언제 로고 띠, 키워드 나열. 주의 읽어야 하는 내용은 넣지 않습니다. 멈출 방법(호버·포커스)을 반드시 함께 둡니다.
그림 한 장을 붙잡아 두고 설명만 흘려보내는 구간. position:sticky 하나로 만듭니다.
제품 기능을 단계별로 설명할 때, 매번 화면을 바꾸지 않아도 됩니다.
1단계 왼쪽 그림이 화면에 붙어 있습니다. 스크롤을 내려도 따라옵니다.
2단계 설명만 지나갑니다. 사용자는 같은 대상을 계속 보면서 읽습니다.
3단계 구간이 끝나면 그림도 함께 올라가 사라집니다.
언제 하나의 화면·제품을 여러 단계로 설명할 때. 주의 구간이 너무 길면 갇힌 느낌을 줍니다. 화면 높이의 3배 안쪽으로.
회색 뼈대가 실제 내용으로 바뀌는 순간. 스켈레톤 자체보다 이 전환이 매끄러운지가 완성도를 가릅니다. 자리가 튀지 않게 스켈레톤과 콘텐츠의 높이를 맞추고, 짧은 페이드로 넘깁니다.
언제 목록·카드가 데이터를 기다릴 때. 주의 스켈레톤과 실제 콘텐츠의 높이가 다르면 내용이 튀어 올라 클릭을 헛치게 만듭니다.
prefers-reduced-motion을 켜 둔 사용자에게는 애니메이션을 멈춰야 합니다.
전정기관이 예민한 사람에게 패럴랙스와 큰 이동은 실제로 멀미를 유발합니다.
이 문서의 모든 데모도 해당 설정에서 정지합니다.
앞의 12가지를 무엇으로 구현하느냐는 별개의 결정입니다. 2025~2026 사이 브라우저가 두 가지 기능을 흡수하면서, 예전에 라이브러리를 깔던 일의 상당 부분이 CSS 몇 줄로 내려왔습니다. 자바스크립트를 0KB 더 얹지 않고 되는 일부터 확인하고, 안 되는 것만 라이브러리로 올라가는 순서가 낫습니다.
스크롤 위치가 곧 애니메이션의 재생 헤드가 되는 CSS 기능. 예전에는 스크롤 이벤트를 듣고 매 프레임 계산하던 것을
animation-timeline 한 줄로 대체합니다. 메인 스레드가 아니라 컴포지터에서 돌기 때문에 스크롤이 끊기지 않습니다.
| 쓰는 것 | 무엇 |
|---|---|
animation-timeline: scroll() | 스크롤 컨테이너의 전체 진행률에 물린다 (진행 막대) |
animation-timeline: view() | 그 요소가 화면에 들어왔다 나가는 동안의 진행률에 물린다 (등장 연출) |
animation-range | 타임라인 중 어느 구간에서만 재생할지 자른다 |
scroll-timeline / view-timeline | 타임라인에 이름을 붙여 다른 요소가 갖다 쓰게 한다 |
timeline-scope | 이름 붙인 타임라인을 형제·상위 요소까지 닿게 넓힌다 |
이 브라우저는 스크롤 연동 애니메이션을 아직 지원하지 않아 막대가 고정돼 있습니다.
scroll-timeline: --sdemo y로 이 상자에 타임라인 이름을 붙이고,animation-timeline: --sdemo를 물렸을 뿐입니다.언제 진행 막대, 스크롤 등장, 패럴랙스처럼 스크롤 위치에만 묶이는 연출.
주의 지원 범위가 아직 100%가 아니므로 @supports로 감싸고, 미지원 브라우저에서도 내용이 읽히는 상태를 기본값으로 둡니다.
DOM이 바뀌기 전후를 브라우저가 알아서 스냅샷으로 찍어 사이를 이어 주는 기능. 목록에서 상세로 넘어갈 때 같은 이미지가 자리를 옮겨 가는 연출(공유 요소 전환)을 직접 좌표 계산 없이 만듭니다.
| 쓰는 것 | 무엇 |
|---|---|
document.startViewTransition() | 같은 페이지 안에서의 전환(SPA). 이 안에서 DOM을 바꾼다 |
@view-transition | 페이지가 바뀔 때의 전환(MPA). 출발·도착 문서 양쪽에서 켠다 |
view-transition-name | 이어질 요소에 같은 이름을 붙인다. 이름이 같으면 이어진다 |
::view-transition-old() / -new() | 사라지는 쪽·나타나는 쪽을 각각 CSS로 꾸민다 |
언제 목록 → 상세, 탭 전환, 정렬 변경처럼 같은 것이 자리를 옮기는 순간.
주의 view-transition-name은 한 화면에 같은 이름이 둘 있으면 안 됩니다. 미지원 브라우저에서는 그냥 즉시 바뀝니다 — 기능이 깨지지는 않습니다.
두 기능 모두 아직 전 브라우저 100%는 아닙니다. 아래는 caniuse 기준이며 2026-08-23 조회값입니다. 숫자는 계속 오르므로 도입 전 원 출처를 다시 확인하세요.
| 기능 | 전역 지원 | Chrome / Edge | Safari | Firefox |
|---|---|---|---|---|
| View Transitions 단일 문서 | 90.2% | 111+ | 18.0+ | 144+ |
| animation-timeline 스크롤 연동 | 85.43% | 115+ | 26.0+ | 157+ |
출처 — caniuse: view-transitions · caniuse: animation-timeline · 문법은 MDN View Transition API · MDN 스크롤 연동 애니메이션
네이티브로 안 되는 것은 여전히 있습니다. 타임라인을 정밀하게 짜야 하거나, 리액트 컴포넌트가 사라지는 순간을 붙잡아야 하거나, 관성 스크롤을 깔아야 할 때입니다. 하나만 고르는 문제가 아니라 층을 나눠 쓰는 문제입니다.
| 도구 | 맡는 층 | 언제 이걸 쓰나 |
|---|---|---|
| GSAP | 타임라인 · 스크롤 | 여러 동작을 초 단위로 물려 짜는 시퀀스, 정교한 스크롤 연출. 프레임워크를 가리지 않음. 전 플러그인 무료(Webflow 지원) |
| Motion 구 Framer Motion | 리액트 UI 전환 | 모달·드로어·페이지 전환처럼 컴포넌트가 사라지는 순간까지 다뤄야 할 때. npm install motion → import { motion } from "motion/react" |
| Anime.js | 가벼운 트윈 | 몇 개 값만 부드럽게 바꾸면 될 때. GSAP까지 갈 이유가 없을 때 |
| Lenis | 스무스 스크롤 | 스크롤 자체에 관성을 붙이는 밑바닥 층. 위 어느 것과도 같이 씀 |
| AOS | 스크롤 등장 | 설정 없이 등장 연출만 빠르게. 지금은 animation-timeline: view()로 대체되는 경우가 많음 |
animation-timeline) → ③ 화면이 바뀌는 것뿐인가(View Transitions) →
④ 그래도 안 되면 라이브러리. 이 순서를 건너뛰면 진행 막대 하나에 수십 KB가 붙습니다.
출처 — gsap.com/pricing · motion.dev
이미지 생성, 코딩, 문서 작성 — 분야가 달라도 결론은 같습니다. AI에게 “비슷하게 만들어줘”라고 하지 말고, 전체가 따라갈 기준을 먼저 넘기세요.
| 기준의 형태 | 담기는 것 | 쓰는 분야 |
|---|---|---|
| 레퍼런스 보드 설정 시트 한 장 | PROFILE 블록(속성 고정) + 변주 축(각도·시간·성장단계·샷사이즈) 그리드 | AI 이미지 생성 |
| DESIGN.md 마크다운 파일 하나 | 색·폰트·여백·그림자 규칙. 애플·노션·스포티파이 가이드를 참고로 가져옴 | AI 코딩 에이전트 |
| Figma 원본 파일 이미지가 아닌 파일 | 색·글씨·여백이 값으로 들어 있어 규칙 추출이 가능 | PPT·문서 생성 |
| hex + 폰트 경로 확정값 명시 | Google Fonts 로딩 경로·스타일, Figma에서 뽑은 정확한 hex | AI 웹사이트 빌드 |
왜 통하는가 넷의 공통점은 AI에게 판단을 맡기지 않는다는 것입니다.
“여백을 적당히”가 아니라 “8의 배수만”, “파란색 계열”이 아니라 #3B7DD8.
판단의 여지를 남긴 자리마다 AI는 학습 데이터의 평균값을 채워 넣고, 그 평균값이 곧 “AI 티”입니다.
잘 설계된 흐름에서는 AI가 만들기 전에 선택지 형태로 조건을 되묻습니다.
요령 AI가 안 물어보면 사용자가 먼저 준다: 목적 · 대상 · 분량 · 톤 네 가지. 이 네 개가 비어 있을 때 AI는 가장 무난한 평균값으로 채웁니다.
단계마다 다른 도구를 쓰고, 각 단계의 산출물이 다음 단계의 입력이 됩니다.
| 단계 | 하는 일 | 도구 예 |
|---|---|---|
| 1 · 레퍼런스 수집 | 스크린샷 3장 준비 — 레이아웃용 1장, 특정 디자인 요소용(예: 추상 원형 패턴) 등. 한 장에 매달리지 않기 | Pinterest, SEESAW, Land-book |
| 2 · 자산 재구성 | ‘주니어 디자이너에게 지시하듯’ 프롬프트 작성 — “첫 이미지 레이아웃 유지 + 꽃 요소를 두 번째 원형으로 교체 + 세 번째 녹색 톤 적용” | Higgsfield (GPT Image 2) |
| 3 · 배경 애니메이션 | 텍스트·버튼을 뺀 순수 배경만 고해상도로 생성(글자 뭉개짐 방지). 부메랑 로직으로 무한 루프 만들기 | Seedance 2.0 |
| 4 · 실제 빌드 | 프롬프트에 폰트 로딩 경로와 정확한 hex를 반드시 포함 | AI 코딩 에이전트 + Figma |
| 5 · 섹션 확장 | “특징 → 후기 → 포트폴리오 → 프로세스 순으로 4~5개 섹션 구성” | — |
핵심 노하우 2개 ① 배경 영상은 글자를 빼고 만든다(AI가 텍스트를 뭉갠다) ② 짧은 클립을 역재생으로 이어 붙여 무한 루프처럼 쓴다.
AI가 만든 웹사이트가 다 비슷해 보이는 데는 이유가 있습니다. 아래는 그 증상 목록과, 자동 검출 도구가 실제로 잡아내는 항목입니다.
아래 항목은 자동 검출 도구가 “AI 룩”으로 지목하는 대표 패턴입니다. 하나만 있어도 티가 나고, 겹치면 확실해집니다.
| 증상 | 무엇이 문제인가 |
|---|---|
| 보라색 그라디언트 | AI 기본값. 보라~바이올렛 강조색이 감지되면 거의 항상 생성물이다 |
| 그라디언트 텍스트 | background-clip: text + 그라디언트. 대비가 무너지고 어디서나 본 인상을 준다 |
| 무방향 글로우 섀도 | 오프셋 0의 box-shadow 발광. 광원이 없는 그림자라 물리적으로 어색하다 |
| 어디서 본 폰트 | 기본 산세리프 한 종으로 전부 처리. 브랜드 구분이 사라진다 |
| 카드 안에 카드 | 과도한 중첩(over-nested UI). 경계가 겹쳐 위계가 사라진다 |
| 글자 크기 위계 없음 | 제목·소제목·본문이 거의 같은 크기. 무엇부터 읽어야 할지 알 수 없다 |
| 저대비 텍스트 | 세련돼 보이려고 낮춘 대비. 접근성 기준 미달 |
| 마스크로 잘린 헤딩 | 클리핑 때문에 글자 일부가 잘려 보이는 히어로 |
AI 코딩 에이전트에 붙여 쓰는 디자인 스킬들. 역할로 나누면 서로 겹치지 않습니다.
| 역할 | 스킬 | 설치 · 실행 |
|---|---|---|
| 심미안 주입 감각적인 스타일 | taste skill | npx skills add https://github.com/Leonxlnx/taste-skill기본 스킬만: --skill "design-taste-free" |
| 방향 결정 컬러·레이아웃 제안 | ui-ux-pro-max skill | /plugin marketplace add nextlevelbuilder/ui-ux-pro-max-skill/plugin install ui-ux-pro-max@ui-ux-pro-max-skill |
| 결과 감사 AI 룩 검출·수정 | impeccable | /plugin marketplace add pbakaus/impeccable다른 툴이라면: npx impeccable install |
| 스킬 모음 상황에 맞는 스킬 선택 | UI Skills | npx ui-skills start에이전트에게 CLI를 먼저 실행시켜 스킬을 고르게 함 |
| 디자인 엔지니어 노하우 | emilkowalski/skills | GitHub 저장소 (Stars 17k). Vercel·Linear 출신의 모션·디자인 스킬 |
| 완성도 원칙 16가지 | /make-interfaces-feel-better | 여백·그림자·타이포·인터랙션. 신규 제작과 기존 코드 검토 양쪽에 사용 |
주의 스킬은 외부 저장소의 코드를 에이전트에 붙이는 것입니다. 설치 전에 저장소 주소와 내용을 직접 확인하세요.
앞 장의 진단 항목들을 매번 손으로 지적하지 않으려면, 판단 기준 자체를 에이전트에 심어 두는 편이 낫습니다.
그 방법이 스킬입니다. 폴더 하나에 SKILL.md를 넣어 두면 에이전트가 작업 전에 읽고 그 기준대로 만듭니다.
클로드코드 전용이 아닙니다 — 커서·코덱스를 비롯한 대부분의 코딩 에이전트가 같은 형식을 읽습니다.
대부분의 스킬은 깃허브 저장소 하나로 배포되고, 설치 명령이 같습니다.
프로젝트 폴더에서 실행하면 그 프로젝트에만, -g를 붙이면 전역에 깔립니다.
주의 스킬은 남이 쓴 지시문이 내 에이전트에 들어가는 일입니다. 설치 전 저장소의 SKILL.md를 한 번 읽어 보세요.
별점이 높다고 내 프로젝트 톤에 맞는다는 뜻은 아닙니다.
별점은 2026-08-23 조회값입니다. 이 판은 몇 주 단위로 바뀌므로 숫자보다 성격을 보고 고르세요. 아래 넷은 서로 겹치지 않는 역할을 합니다 — 취향 교정 / 시안 생성 / 디자인 시스템 / 자산 제작.
| 스킬 | ★ | 무엇을 해주나 |
|---|---|---|
| taste-skill Leonxlnx | 79.2k | AI가 기본값으로 뱉는 밋밋한 화면을 막는다. 앞 장의 AI 밤티 진단과 짝을 이루는 취향 교정 계열 |
| hallmark Nutlope | 26.6k | 같은 계열의 안티-슬롭 스킬. 클로드코드·커서·코덱스를 함께 지원한다고 명시 |
| huashu-design alchaincyf | 23.4k | HTML을 직접 짜는 방식의 디자인 스킬. 프레임워크를 얹지 않고 결과물을 뽑을 때 |
| garden-skills ConardLi | 10.5k | 웹디자인을 포함한 스킬 묶음. 낱개로 골라 설치 |
| stitch-skills google-labs-code | 8.1k | 구글 Stitch와 물려 쓰는 스킬 모음. 아래 레퍼런스의 Stitch로 시안을 뽑아 이어붙이는 흐름 |
| openpencil ZSeven-W | 5.6k | 오픈소스 AI 네이티브 벡터 도구. 아이콘·일러스트를 직접 만들어야 할 때 |
| superdesign-skill superdesigndev | 0.4k | 별점은 작지만 성격이 다르다. 기존 코드베이스를 읽어 그 프로젝트의 디자인 시스템 안으로 시안을 만든다. 테마를 갈아끼우는 계열과 구분됨 |
고르는 법 처음 한 개만 깐다면 취향 교정 계열(taste-skill 또는 hallmark) 하나. 이미 디자인 시스템이 있는 프로젝트라면 superdesign처럼 기존 규칙을 읽는 쪽이 낫습니다. 취향 교정 계열을 두 개 겹쳐 깔면 지시가 충돌합니다.
앞의 기준 파일을 먼저 준다와 스킬은 같은 일을 다른 층에서 합니다. 기준 파일(DESIGN.md 등)은 이 프로젝트의 규칙, 스킬은 어느 프로젝트에서나 통하는 판단 기준입니다.
| 기준 파일 | 스킬 | |
|---|---|---|
| 범위 | 이 프로젝트 하나 | 설치한 모든 프로젝트 |
| 내용 | 색·폰트·간격 등 확정된 값 | "이럴 땐 이렇게" 판단 규칙 |
| 누가 쓰나 | 내가 직접 작성 | 남이 만든 것을 가져다 씀 |
둘은 대체 관계가 아닙니다. 스킬로 판단 기준을 깔고, 기준 파일로 이 프로젝트의 값을 못 박는 조합이 가장 잘 작동합니다. 값이 충돌하면 기준 파일이 이기도록 프롬프트에 한 줄 적어 두세요.
용도별로 묶었습니다. 도메인이 확인된 것만 링크를 걸었고, 나머지는 이름으로 검색하세요.
| 이름 | 무엇을 찾을 때 | 비고 |
|---|---|---|
| NameThatUI | “이 UI 요소 이름이 뭐지?” — 어설픈 말로 설명하면 정식 명칭 + API 심볼 + 붙여넣을 프롬프트를 준다 | macOS·Web 분류. 예: Parallax Scrolling → animation-timeline: scroll() |
| 이름 | 무엇을 찾을 때 | 비고 |
|---|---|---|
| Land-book | 실제 서비스의 랜딩 페이지 모음 | 업종별로 좁혀 보기 좋음 |
| SEESAW | 국내외 웹사이트 큐레이션 | 국내 사례 비중이 높음 |
| 레이아웃·무드 이미지 | 한 장에 매달리지 말고 3장을 모을 것 | |
| Lazyweb | 실제 앱·웹 화면 25만 개+ 데이터베이스 | MCP로 AI 에이전트에 직접 연동 — 에이전트가 디자인 결정을 내릴 때 참조 |
| Figma Community | 공개 UI 키트·템플릿 원본 파일 | 예: iOS and iPadOS 26 UI Kit (Apple Design Resources) |
완성된 화면을 먼저 고르고, 그 화면을 만든 프롬프트를 Copy해 AI에 붙여 넣는 방식. 최근 가장 널리 퍼진 흐름입니다.
| 이름 | 특징 | 무료 여부 |
|---|---|---|
| motionsites.ai | 모션이 들어간 웹 화면 갤러리. 카드마다 Copy full prompt. 카테고리가 섹션 단위(Hero / Landing Page / SaaS / Portfolio) |
Free / Premium 필터 있음 · 무료 템플릿 제한 있음 |
| 21st.dev | 컴포넌트 프리뷰 + Copy prompt | 오픈소스 라이선스 — 상업 프로젝트 사용 가능 |
| Manus (manus.im) | 텍스트만으로 페이지 전체 생성. 결과물에 Made with Manus 배지 | 유료 크레딧 기반 |
왜 이 방식이 퍼졌나 “예쁘게”를 설명할 수 없기 때문입니다. 결과를 먼저 고르면 설명이 필요 없고, 프롬프트는 이미 그 결과를 만들어낸 것이 검증돼 있습니다.
| 이름 | 성격 | 비고 |
|---|---|---|
| ui.shadcn.com | 소유형 — 코드를 프로젝트에 복사해 직접 소유 | 디자인·로직 100% 커스터마이징. 라이브러리 의존이 남지 않음 |
| ui.aceternity.com | 복붙형 — 설정 없이 바로 쓰는 프로덕션급 UI | Blocks / Templates / Labs 구성. 3D 지구본 같은 화려한 데모 |
| magicui.design | 복붙형 — 텍스트 등장·숫자 카운터·파티클 | 150종 이상 무료 제공 + Pro 유료 |
| Skiper UI | 세련된 웹 UI 요소 모음 | — |
| Vengence UI | 인터랙티브 컴포넌트 — “Build Landing Pages Faster” | 문서형 사이트, 검색 지원 |
| Animmasterlib | 페이지 전환 효과·인터랙션 코드 (Page Transition, Animated SVG Path Effect) | 무료 / PRO 혼재 |
| 이름 | 무엇 | 비고 |
|---|---|---|
| lordicon.com | 애니메이션 아이콘 | 모션이 붙은 아이콘 계열. Feather·Heroicons 같은 정적 아이콘셋과는 다른 축이다. |
| animate-ui.com | 애니메이션 UI·아이콘 | |
| lucide-animated.com | 오픈소스 Lucide의 애니메이션 파생 | |
| itshover.com/icons | 호버 반응 아이콘 | |
| potlabicons.com | 애니메이션 아이콘셋 | |
| jitter.video | 모션 디자인 툴 — 아이콘셋이 아님. 분류 시 주의 | |
| IconSax | 아이콘셋 | — |
| Shapefest | 3D 그래픽·도형 — “A huge system of 3D Illustrations” | Get All Access(유료 티어) |
| Craftwork Freebies | UI 키트 + 3D 일러스트 팩 | 예: General User Interface 3D Icon Pack(40종) |
| Getlayers | 3D 웹 요소·템플릿 | — |
| Spline | 3D 저작 도구 — 유일하게 직접 만드는 툴 | 3D·이머시브 스타일 구현용 |
| 이름 | 하는 일 |
|---|---|
| Figma MCP 디자인 QA | Figma MCP 연동으로 토큰·컴포넌트를 자동 추출 → AI가 코드와 시안의 불일치를 수정 → 엑셀 형태 QA 산출물. 플로우: QA하네스 생성 → 디자인 QA 요청 → 코드 반영 → 리포트 생성 → 디자인에도 동기화 |
| Framer | 코드 없이 모션 구현. 모션 6종 데모가 전부 Made in Framer |
| Higgsfield / Seedance 2.0 | 이미지·배경 영상 생성. 크레딧 기반 유료 |
이 문서의 컬러 팔레트, 스타일 분류, 도구·스킬 목록은 아래 제작자들이 공개한 자료를 바탕으로 재편집했습니다. UI·UX 용어 항목과 모든 작동 예시는 별도로 작성한 것입니다.
순서는 무관합니다. 각 계정은 인스타그램 핸들입니다.
| 제작자 | 이 문서에 반영된 부분 |
|---|---|
| @aewon.studio | 무드별 컬러 팔레트 · UI 스타일 10종 · AI 밤티 진단과 디자인 스킬 |
| @ai_freaks.kr | AI 디자인 도구·스킬 정리 · Figma MCP 디자인 QA |
| @kevin.snippet | 모션과 인터랙션 6종 |
| @naminsoo__ai | AI 웹사이트 5단계 파이프라인 |
| @ai.dingco | 기준 파일을 먼저 주는 방식 · 요구사항 인터뷰 |
| @andy__wormhole · @_dot.move | 레퍼런스 보드 구조 |
| @hedy.with · @infinity8master8 · @navibuilds · @janm_ux | 레퍼런스 사이트 · 컴포넌트 라이브러리 · 아이콘·에셋 목록 |
각 도구·서비스의 상표와 저작권은 해당 권리자에게 있습니다. 설치 명령어와 가격 정보는 시점에 따라 달라지므로 사용 전 공식 문서를 확인하세요.