Design

저장된 갤러리 중 "산업별 필터"가 가장 실용적인 축이다 — 만들려는 제품과 같은 업종의 사이트만 모아 보면 그 업종의 관행(금융은 신뢰 표현, AI는 데모 배치, 이커머스는 상품 그리드)이 금방 드러난다. 콘셉트 작업이 아니라 실제 운영 사이트라 데이터 양과 반응형 같은 현실 제약이 반영돼 있다는 점도 Dribbble 계열 갤러리 대비 장점이다. 저장해둔 것들과 역할 구분: Supahero는 히어로 구간만, dark.design은 다크 테마만, CollectUI·Inspora는 전반, Curated는 산업별이다. Pro는 월 9달러인데 필터 저장이 핵심이므로 자주 쓰게 될 때 판단하면 된다. Framer 템플릿 스토어는 Framer를 안 쓰면 해당 없음.

저장된 레퍼런스 갤러리들과 결정적으로 다른 점은 "왜 그렇게 만들었는지"를 글로 설명한다는 것이다. CollectUI·Uiinspoo·Design Spells는 결과물을 보여주고 판단은 내 몫인데, 여기는 의도와 패턴을 언어로 정리해준다 — 그래서 화면을 베끼는 게 아니라 원리를 가져오기에 적합하다. 저장해둔 Learn UI(디자인 엔지니어링 원리, 인터랙티브)와 짝이 되는 자료이며, 그쪽이 모션·구현 감각이라면 여기는 제품 UX 판단이다. 주의: 대형 앱의 선택은 그 규모의 사용자와 데이터가 전제된 것이라 소규모 제품에 그대로 옮기면 과한 경우가 많다 — 결론보다 그 결론에 이른 근거를 보고 판단할 것.

저장해둔 swiped.design과 같은 계열(콘텐츠 레퍼런스)이지만 축이 다르다 — swiped는 개인이 쓰는 글의 구조, 여기는 회사가 올리는 시각물이다. 사이드 프로젝트나 제품을 공개할 때 출시 게시물의 이미지 구성과 카피를 어떻게 짜는지 실제 사례로 볼 수 있고, Headers·OG images 갈래는 저장해둔 Recent의 OG 이미지 카테고리와 함께 보면 된다(OG 이미지는 만들 일이 반드시 생기는데 참고 자료가 드문 축이다). 목적별 분류가 실용적이라 "출시"나 "리브랜딩"처럼 지금 필요한 상황만 골라 볼 수 있다. 주의: 대기업 계정의 제작 여력을 전제로 한 결과물이 많으므로 형식과 정보 구성만 참고하고 제작 난도는 걸러서 볼 것.

이 북마크함에서 드문 축 — UI가 아니라 문서·발표 자료의 레퍼런스다. 쓸모가 생기는 상황은 두 가지다. (1) 브랜드 가이드라인 64건: 제품의 컬러·타이포·로고 사용 규칙을 문서로 정리해야 할 때 구성 방식을 볼 수 있다. 저장해둔 로고착착·Logosystem이 로고 자체라면 여기는 "그 로고를 어떻게 문서화하는가"다. (2) 리포트 95건: 수치를 담은 문서의 레이아웃과 차트 배치 참고. 저장된 차트 라이브러리(chartcn·Bklit)로 구현하기 전에 지면 구성을 보는 용도로 쓸 수 있다. 피치덱은 15건으로 적으니 투자 유치 자료가 목적이면 기대를 낮출 것. 무료 범위와 Pro 차이는 확인이 필요하다.

저장해둔 자료 대부분이 "가져다 쓰는 것"이라면 이건 "판단력을 기르는 것"이다. 스프링 값이나 전환 곡선을 왜 그렇게 잡는지 몰라서 매번 감으로 맞추고 있다면 여기 모션 챕터가 직접적인 해답이 된다 — 값을 조작해보는 그림이 붙어 있어 글로만 읽는 것보다 남는 게 다르다. 참여 면면도 신뢰할 만한데, Emil Kowalski는 저장해둔 Sonner·Vaul의 제작자이고 Rauno Freiberg는 Vercel 디자인 엔지니어로 UI 디테일 글로 알려진 사람이다. 실용 연결: 여기서 원리를 잡고 → Kinetics·Motion Primitives에서 재료를 고르고 → DialKit으로 값을 맞추고 → Design Spells·details.so에서 아이디어를 얻는 흐름으로 쓰면 된다. 용어집은 저장해둔 NameThatUI와 함께 용어 확인용으로도 쓸 수 있다.

"이 앱의 이 동작이 왜 기분 좋은가"를 항목 단위로 모아둔 자료. 화면 전체 레이아웃을 보는 갤러리들과 달리 한 동작·한 디테일 단위라, 만들고 있는 기능에 작은 즐거움을 더할 아이디어를 찾을 때 효율이 높다. 태그(이스터에그, 404, 컨페티, 전환)로 목적에 맞춰 좁혀볼 수 있는 점도 실용적이다. 저장해둔 details.so와 가장 가까운 성격이며 이쪽이 모바일 앱과 이스터에그 비중이 크다. 구현체는 저장된 연출 계열·모션 라이브러리에서 찾고 여기서는 "무엇을 만들지"의 재료를 얻을 것. 주의: 디테일은 제품 톤에 맞을 때만 즐겁고 업무용 도구에 과하게 넣으면 방해가 된다.

설치해 쓰는 라이브러리가 아니라 판단 기준을 주는 자료다. 저장해둔 같은 계열과 역할이 갈린다 — component.gallery는 컴포넌트의 정식 명칭과 여러 디자인 시스템의 구현 비교, components.build는 접근성·표준 관점의 기준, 그리고 02UI는 선택 판단(모달 vs 드로어, 토스트 vs 인라인 메시지 같은 갈림길)이다. 비교 가이드 8편이 핵심이므로 컴포넌트를 고르다 막혔을 때 그쪽을 먼저 볼 것. 디자이너 대상이라 코드 레벨 세부는 없으니 구현은 저장된 라이브러리에서 찾고, 여기서는 "무엇을 쓸지"만 정하는 식으로 나눠 쓰면 된다.

같은 아이콘의 스타일 변형으로 위계를 만드는 계열(저장해둔 Phosphor, Keyline Icons)과 같은 자리. Solar의 특징은 변형 축이 굵기가 아니라 표현 방식이라는 점이다 — Duotone 두 종과 Broken(선이 끊긴 스타일)이 있어 같은 아이콘으로 더 뚜렷하게 다른 인상을 만들 수 있다. 특히 Broken은 다른 세트에 거의 없는 스타일이라 개성이 필요할 때 카드가 된다. 프레임워크 패키지 폭이 넓어 Vue·Svelte·Angular 프로젝트에서도 같은 세트를 쓸 수 있다. 중요: 아이콘 라이선스가 CC BY 4.0이라 상업적으로 써도 되지만 출처 표기 의무가 있다 — 저장해둔 MIT 세트(Lucide, Phosphor, Iconoir, Keyline)와 달리 표기 위치를 정해야 하므로 프로젝트 성격에 따라 부담이 될 수 있다. 여섯 스타일을 섞으면 산만하니 한둘로 고정할 것.

랜딩 페이지의 첫 화면을 설계할 때 보는 전문 레퍼런스. 히어로는 페이지에서 가장 시간이 오래 걸리고 제품 인상을 좌우하는 구간인데, 다른 갤러리는 페이지 전체 스크린샷을 보여줘 히어로만 비교하기 어렵다 — 여기는 그 구간만 900건 이상 나란히 놓고 볼 수 있다. 실제 서비스(Stripe·Figma 등)라 콘셉트 작업이 아니라 프로덕션에서 검증된 구성이라는 점도 장점이다. 헤드라인 길이, 서브 카피, CTA 개수와 위치, 시각 요소(스크린샷·일러스트·3D) 비율을 비교해볼 것. 저장해둔 cta.gallery(전환 문구)와 짝으로 보면 히어로의 구조와 카피를 함께 잡을 수 있고, 구현체는 저장된 블록 계열(Tailark, blocks.so, ONONC)에서 찾으면 된다.

로고를 새로 만들거나 디자이너에게 방향을 전달할 때. 가장 실용적인 부분은 필터다 — "핀테크 + 기하학 + 모던" 식으로 조건을 좁혀 볼 수 있어서 막연히 스크롤하는 갤러리보다 시간이 훨씬 덜 든다. 디자이너에게 레퍼런스를 넘길 때 무드보드 형태로 정리하기도 쉽고, 애니메이션 로고 컬렉션은 로고 모션을 발주하거나 직접 만들 때 참고가 된다. 저장해둔 항목과 역할 구분: 로고착착은 한국 브랜드의 공식 로고 자산(실제 사용), svgl·Developer Icons는 기존 브랜드·기술 로고 파일, icon.museum은 앱 아이콘, 그리고 여기는 새로 만들 로고의 디자인 레퍼런스다. 주의: 레퍼런스는 방향 참고용이며 기존 로고와 유사하게 만들면 상표 문제가 생길 수 있다.

저장된 레퍼런스 갤러리가 이미 여럿이므로 역할로 구분해 쓸 것 — CollectUI는 웹 UI 밀도, Recent는 분야 확장과 OG 이미지·앱 스크린샷, Uiinspoo는 모바일·대시보드, dark.design은 다크 테마, cta.gallery는 전환 문구, navbar.gallery는 내비게이션, details.so는 인터랙션 디테일, 그리고 Inspora는 갱신 빈도(매시간)와 7개 분야 균형이다. 트렌드를 자주 확인하는 용도라면 여기가 맞고, 특정 화면 유형을 파려면 위의 전문 갤러리가 낫다. 주의: 갱신이 잦다는 건 큐레이션 밀도가 낮을 수 있다는 뜻이기도 하니 훑는 시간을 정해두고 볼 것.

저장된 레퍼런스 갤러리 중 모바일 앱과 대시보드 비중이 높은 쪽. CollectUI가 전반적 비주얼, Recent가 분야 확장(브랜딩·패키지), dark.design이 다크 테마, 여기는 화면 유형(모바일·대시보드)이다. 대시보드는 실제로 만들 일이 많은데 잘 된 사례를 모아 보기 어려운 영역이라 그 축이 유용하다. 주의: 다른 갤러리와 마찬가지로 콘셉트 작업이 섞여 있어 실제 데이터 양·에러 상태가 반영되지 않은 경우가 많다.

저장해둔 Phosphor와 같은 강점(같은 아이콘의 웨이트 변형으로 위계 만들기)을 가지면서 shadcn 호환을 명시한 세트. rounded·sharp 코너를 함께 제공하는 점이 차별적인데, 제품의 border-radius 톤에 아이콘 코너를 맞출 수 있어 디테일에서 이질감이 줄어든다(각진 디자인에 둥근 아이콘을 쓰면 미묘하게 어긋난다). MIT라 상업 사용에 걸림돌이 없다. 851종은 Lucide(약 1,700)보다 적으므로 자주 쓸 아이콘이 있는지 먼저 확인할 것.

앱을 스토어에 올릴 때 반드시 만들어야 하지만 참고 자료를 찾기 번거로운 세 가지(스크린샷, 온보딩, 페이월)를 한곳에서 볼 수 있다. 특히 페이월은 전환에 직결되는데 실제 유료 앱의 화면을 모아 보기가 어려운 영역이라 가치가 크다. 저장해둔 Recent의 앱 스크린샷 카테고리와 겹치지만 이쪽이 ASO 목적에 특화돼 있다. 주의: 잘 팔리는 앱의 페이월 패턴 중에는 다크 패턴에 가까운 것도 섞여 있으므로 구조만 참고하고 사용자를 속이는 요소는 걸러낼 것.

앱 아이콘을 만들어야 할 때 참고할 레퍼런스. 앱 아이콘은 작은 정사각형 안에서 원거리 식별성, 배경 대비, 라이트·다크 모드, 여러 크기 축소를 모두 만족해야 하는 특수한 디자인 문제라 일반 로고 레퍼런스로는 감이 안 잡히는데 그 구간을 정확히 채운다. 데스크톱 앱이나 PWA 아이콘 작업 시 먼저 볼 것. 저장해둔 Macapp Supply가 앱 자체(UI 완성도)를 본다면 여기는 아이콘만 본다.

다크 모드를 기본으로 가는 제품을 디자인할 때 훑는 레퍼런스. 다크 테마는 밝은 화면을 단순히 반전한다고 되지 않는 영역이라(순수 검정 대신 뉴트럴 계열, 그림자 대신 표면 밝기 차이, 채도 낮춘 강조색, 대비 관리) 실제로 잘 된 사례를 보는 게 가장 빠르다. 저장해둔 다른 갤러리(CollectUI, Recent)와 달리 주제가 하나로 좁혀져 있어 목적이 분명할 때 효율이 높다. 개발자 도구·AI 제품은 다크가 기본인 경우가 많으니 그 계열 카테고리를 먼저 볼 것.

저장된 다른 아이콘 세트와 용도가 완전히 다르다 — Lucide·Phosphor·Iconoir가 UI 기능 아이콘이라면 여기는 삽화에 가까운 손그림이다. 빈 상태 화면, 온보딩 일러스트, 블로그 삽화, 프레젠테이션처럼 "그림"이 필요한 자리에 맞고, 버튼이나 내비게이션에 쓰면 톤이 튄다. 26만 개라는 수량은 브라우징이 아니라 검색을 전제로 한 규모이고 동의어 검색이 있어 실제로 찾아진다. 출처 표기 불필요라 라이선스 부담이 없는 점도 장점. 주의: 다섯 가지 스타일이 섞이면 산만하므로 프로젝트에서는 한 스타일로 고정할 것.

저장해둔 레퍼런스 갤러리들보다 범위가 넓어 브랜딩·타이포·패키지까지 볼 수 있다는 게 차이다. 실무적으로 특히 유용한 건 두 카테고리 — OG 이미지(공유 링크 썸네일을 어떻게 디자인하는지 모아 보기 어려운 영역이다)와 앱 스크린샷(스토어 등록용 이미지 구성). 둘 다 만들 일은 반드시 생기는데 참고 자료를 찾기 번거로운 축이라 여기를 기억해둘 값어치가 있다. 웹 UI만 필요하면 저장해둔 CollectUI 쪽이 밀도가 높다.

히어로나 섹션 배경에 깔 분위기용 그라디언트가 필요할 때. CSS로 내보내지므로 이미지 파일이 아니라 코드로 들어가 용량 부담이 없고 다크모드에 맞춰 색만 바꾸기도 쉽다. 저장해둔 Grainient(유료, 그레인 질감 중심)와 비교하면 이쪽은 무료이고 레이어 블렌드 기반이라 더 부드러운 톤이다. Tailwind 내보내기가 있어 클래스로 바로 붙일 수 있는 점이 실무에서 편하다. 주의: 큰 면적의 블렌드 그라디언트는 저사양 기기에서 페인트 비용이 있을 수 있고, 텍스트 대비를 해치기 쉬우니 본문 위에 깔 때는 대비를 확인할 것.

Lucide와 규모가 비슷한 선 아이콘 세트. Lucide보다 선이 조금 더 가늘고 기하학적인 편이라 미니멀한 디자인에 잘 맞는다. 실무 판단은 늘 같다 — 수량보다 자주 쓸 아이콘들의 톤이 맞는지부터 볼 것. Swift와 Flutter 배포판이 있어 웹과 모바일 앱이 같은 아이콘을 써야 하는 경우 통일이 쉬운 점은 저장된 다른 세트 대비 장점이다. 저장해둔 morphicons가 Iconoir를 지원 세트로 포함하므로 아이콘 모핑을 쓸 계획이면 조합이 된다.

재생↔일시정지, 메뉴↔닫기, 복사↔체크처럼 상태가 바뀌는 아이콘 버튼에 쓴다. 보통은 두 아이콘을 페이드로 교차시키는데 그건 상태 변화를 설명하지 못한다 — 모핑은 "같은 것이 변했다"는 관계를 보여주므로 의미 전달이 다르다. 중요한 실무 이점: 이미 쓰고 있는 아이콘 세트(Lucide 등)를 그대로 쓰면서 모핑만 얹는 구조라 아이콘 세트를 바꿀 필요가 없다. 저장해둔 Lucide Animated·itshover가 "미리 만들어진 애니메이션 아이콘 세트"라면 여기는 "임의의 두 아이콘을 잇는 엔진"이라 성격이 다르다. 중단 가능한 스프링이라 연타에도 어색하지 않다. 선 아이콘 전용이므로 면(fill) 아이콘에는 맞지 않는다.

UI 사운드를 실제로 넣을 때 가장 실용적인 자원. 핵심은 두 가지다 — (1) 오디오가 CC0라 라이선스 확인 부담이 없다(저장해둔 다른 사운드 항목 중 라이선스가 모호한 것과 대비된다), (2) 같은 큐를 12가지 톤으로 제공해 제품 성격에 맞춰 전체 사운드 팔레트를 한 번에 통일할 수 있다. 개별 효과음을 여기저기서 주워 쓰면 톤이 어긋나는데 그 문제를 구조적으로 해결한다. 순서는 저장해둔 Velvet UI(언제 어떤 소리를 낼지 원칙) → 여기(무엇을 쓸지) → soundz.js·soundcn(어떻게 재생할지)로 보면 된다. 소리는 항상 옵트인, 음소거 컨트롤 상시 노출은 변하지 않는 원칙이다.

화면 유형별 시각 레퍼런스가 필요할 때 훑는 곳. 저장해둔 갤러리들과 성격이 갈린다 — navbar.gallery는 내비게이션, cta.gallery는 전환 문구, details.so는 인터랙션 디테일, 여기는 화면 전체의 비주얼 톤과 레이아웃이다. 주의: 대부분 Dribbble 계열의 콘셉트 작업이라 실제 제품의 제약(데이터 양, 에러 상태, 빈 화면, 반응형)이 반영돼 있지 않은 경우가 많다. 톤과 레이아웃 아이디어만 가져오고 구조는 실제 제품 사례에서 확인할 것.

Lucide(약 1,700종)보다 수량이 많아 세부 개념 아이콘이 필요할 때 후보가 된다. 다만 아이콘 세트 선택은 수량보다 일관성과 스타일 적합성이 우선이므로, 실제로는 자주 쓸 20~30개가 원하는 톤으로 나오는지부터 확인하는 게 맞다. 여러 세트를 한 번에 검색하려면 저장해둔 Icônes·yesicon을 쓰고, 굵기 변형이 필요하면 Phosphor, 애니메이션이 필요하면 Lucide Animated·itshover를 볼 것. 라이선스가 확인되지 않으므로 상업 프로젝트 전 명시 문서를 찾을 것.

제품 목업, 랜딩 히어로의 3D 오브젝트, 기능 소개용 짧은 3D 영상이 필요할 때. Blender를 켜서 재질과 조명을 세팅하는 과정을 건너뛰고 브라우저에서 결과물만 뽑는 것이 요점이라, 3D 전문 도구를 다루지 않는 입장에서 실효가 크다. 단 전제 조건이 있다 — 3D 모델 자체는 준비돼 있어야 한다(모델링 도구가 아니다). 모델이 없다면 저장해둔 Thiings(3D 오브젝트 에셋) 같은 기성 에셋을 먼저 구할 것. 결과물이 이미지·영상이므로 웹에서 회전시키는 인터랙티브 3D가 목적이라면 Three.js 계열이나 저장해둔 3D 컴포넌트 쪽으로 가야 한다.

"어떤 움직임을 만들 것인가"를 정하는 단계에서 보는 자료. 코드가 아니라 완성된 모션 클립이므로 구현체는 저장해둔 Motion Primitives·Kinetics 쪽에서 찾고, 여기서는 방향과 타이밍 감각을 얻는 식으로 나눠 쓰면 된다. 이징 섹션은 곡선을 고를 때 실용적이다. 주의: 출처가 X 게시물이라 대부분 애프터이펙트·프로토타입 작업물이고 웹에서 그대로 구현하기 어려운 것이 섞여 있다 — 참고할 때 "이걸 브라우저에서 60fps로 돌릴 수 있는가"를 먼저 따질 것.

UI에 사운드를 넣기로 했을 때 라이브러리를 고르기 전에 먼저 읽을 자료. 저장해둔 soundz.js와 soundcn이 "어떻게 재생할 것인가"라면 여기는 "언제 어떤 소리를 낼 것인가"를 다룬다 — 이 판단을 건너뛰면 소리가 성가신 기능이 되기 쉽다. 특히 네 가지 유형 분류(상태 변화/도착/확인/실패)는 그대로 구현 설계에 옮길 수 있고, 옵트인·상시 음소거 원칙은 접근성과 사용자 불만 측면에서 실무적으로 중요하다. 컴포넌트 라이브러리가 아니라 읽고 판단하는 레퍼런스이므로 설치할 것은 없다.

전환이 걸린 화면(가입 유도, 결제 버튼, 뉴스레터 폼, 가격표)을 설계할 때 훑는 레퍼런스. 컴포넌트 라이브러리가 "어떻게 만드는가"를 준다면 여기는 "무엇을 어떤 문구와 배치로 보여주는가"를 준다 — 버튼 하나의 카피, 보조 문구, 주변 여백, 부가 정보(무료 체험·카드 불필요 같은 안심 문구)의 조합을 실제 사례로 확인할 수 있다. 저장해둔 navbar.gallery(내비게이션), details.so(인터랙션 디테일)와 같은 성격의 레퍼런스 갤러리이니 화면 영역별로 나눠 쓰면 된다. 주의: 사례는 그 제품의 맥락에서 통한 것이므로 문구를 그대로 옮기지 말고 구조만 참고할 것.

국내 서비스 만들 때 파트너사 로고, 제휴사 목록, 결제·간편로그인 버튼(카카오·네이버·토스 등), 회사 소개의 "함께하는 브랜드" 섹션에 로고가 필요할 때. 구글 이미지에서 해상도 낮은 PNG를 주워 오는 대신 각 사의 공식 배포처와 CI 가이드라인으로 바로 연결해준다는 게 핵심 가치다. 컬러 코드가 정리돼 있어 로고 옆 배경색이나 버튼 색을 브랜드 규정대로 맞추기도 쉽다. 저장해둔 svgl(글로벌 브랜드 로고)·Developer Icons(기술 스택 로고)와 역할이 나뉘며, 국내 브랜드는 그 둘에 거의 없으므로 여기가 유일한 출처가 되는 경우가 많다. 중요: 로고는 다운로드 가능 여부와 별개로 각 사의 브랜드 가이드라인(최소 여백, 색 변형 금지, 상업적 사용 조건)을 따라야 하며, 특히 제휴 관계를 암시하는 배치는 사전 합의가 필요하다 — 사이트도 저작권 귀속을 명시하고 있다.

포트폴리오·이력서 사이트의 기술 스택 섹션, 문서의 "지원 프레임워크" 표, 통합 목록 페이지처럼 기술 로고가 여러 개 필요할 때 쓴다. 투명 배경 PNG를 검색해 다니는 일을 없애는 게 목적이고, 다크 모드용 변형이 준비돼 있어 배경색이 바뀌어도 로고가 묻히지 않는 점이 실무에서 편하다. 저장해둔 svgl과 목적이 겹치므로 둘 다 열어 원하는 로고가 있는 쪽을 쓰면 되고, 범용 UI 아이콘(화살표·설정 등)은 여기가 아니라 Lucide/Phosphor/Icônes 쪽이다. 주의: 기업·제품 로고는 저작권과 브랜드 가이드라인의 대상이므로 상업적 맥락(특히 비교·광고성 문구 옆)에서는 각 회사의 로고 사용 규정을 확인할 것 — 라이브러리 라이선스가 로고 사용권까지 주지는 않는다.