고품질 UI 프로토타입 디자인

1. 핵심 목표

좋아 보이는 제품 인터페이스를 만들면서, 동시에 사용하기 편리하게.

결과물은 성숙한 디자이너가 완성한 실제 제품처럼 보여야 하며, 템플릿을 적용하거나 카드를 쌓고 색상만 바꾼 일반적인 프로토타입이 되어서는 안 됩니다. 전체적인 분위기, 시각적 위계, 서체 표현, 구성, 색상 관계, 그래픽 언어, 모션 효과 및 디테일 완성도에 중점을 둡니다.

심미성 우선, 하지만 사용성을 희생하지 않음: 시각과 기능을 함께 디자인하며, 기능을 삭제하여 표면적으로만 단순하게 만들지 않습니다.
스타일은 제품이 결정: 절제된, 정교한, 활기찬, 전위적인, 화려한 또는 실험적인 스타일을 허용하며, '고급스러운 미니멀리즘'만이 유일한 정답이 되어서는 안 됩니다.
대담하고 자율적으로 디자인: 사용자가 색상, 서체, 레이아웃 및 애니메이션 매개변수를 제공할 때까지 기다리지 않습니다. 요구 사항을 이해한 후 능동적으로 더 나은 솔루션을 탐색합니다.
템플릿 느낌 거부: 일반적인 SaaS 레이아웃, 고정된 색상 구성, 획일적인 카드 및 모든 곳에서 동일한 컴포넌트 조합을 기본값으로 사용하지 않습니다.
독립적인 추론: 동일한 카테고리라도 콘텐츠와 포지셔닝에 따라 자체적인 표현을 형성해야 하며, 이전의 시각적 솔루션을 기계적으로 재사용하지 않습니다.

디자인 원칙 참고

디자인 판단 시 다음의 성숙된 원칙을 참고할 수 있지만, 그 예시를 그대로 복사하거나 고정된 매개변수로 변환해서는 안 됩니다.

시각적 위계, 비율, 균형, 대비, 게슈탈트 및 시각적 초점.
그리드, 구성, 리듬, 여백, 통일성 및 브랜드 아이덴티티.
일관성, 발견 가능성, 점진적 공개, 피드백 및 접근성.
서체 성격, 글자 품질, 읽기 컨텍스트 및 서체 조합.
모션의 연속성, 자연스러운 가속/감속, 공간 관계 및 상호작용 피드백.

참고: NNGroup 시각 디자인 원칙 · Figma UI 디자인 원칙 · IBM Design Language · Apple HIG Motion

기존 페이지 재사용 금지

새 페이지를 만들 때 ui/ 디렉토리 아래의 기존 페이지를 읽거나, 스크린샷을 찍거나, 분석하거나, 그 HTML/CSS/JS를 복사하여 시작점으로 사용하지 않습니다.
이전 페이지의 색상, 서체, 레이아웃 구조, 컴포넌트 조합 및 모션 매개변수를 재사용하지 않습니다. 디자인 차이는 단순히 색상, 텍스트 또는 이미지만 변경하는 것이 아니라 정보 구조와 시각적 표현을 다시 생각해야 합니다.
이 스킬, skills/ui-metadata/SKILL.md, tools/ 사용 설명서 및 사용자가 해당 세션에서 제공한 참고 자료만 읽을 수 있습니다.
사용자가 명시적으로 기존 페이지를 수정하도록 요청한 경우에만 해당 페이지를 읽습니다.

2. 먼저 제품을 이해한 후 디자인 결정

먼저 제품 포지셔닝, 대상 사용자, 사용 시나리오, 콘텐츠 특성 및 브랜드 분위기를 판단한 후 시각적 방향을 결정합니다. 아래 분류를 템플릿으로 간주하지 말고 디자인 아이디어를 위한 출발점으로만 활용하십시오.

제품 분위기	탐색 가능한 디자인 표현
글로벌 / 영어 브랜드	간결한 카피, 표현력이 풍부한 서체, 큰 규모의 타이포그래피, 자간과 여백, 사진 및 심볼
트렌디 / 크리에이티브 / 젊은 감각	대담한 구성, 강한 서체 개성, 아이콘 및 심볼, 기하학적 그래픽, 시각화된 숫자, 유연한 색상 관계
전문 도구 / 데스크톱 소프트웨어	명확한 정보 구성, 정교한 서체, 편안한 정보 밀도, 세밀한 상태 피드백, 절제된 색상
기술 / AI / 데이터 제품	현대적인 서체, 데이터 시각화, 구조적 그래픽, 동적 피드백, 식별 가능한 기술적 비주얼
문화 / 예술 / 콘텐츠 브랜드	편집 스타일 타이포그래피, 세리프 또는 특수 서체, 사진, 질감, 여백, 감정이 풍부한 색상
고급 소비 / 라이프스타일	정교한 서체, 제품 이미지, 질감과 빛과 그림자, 디테일의 질감, 절제되지만 강렬한 브랜드 표현

다른 방향을 혼합하거나 현재 제품에 더 적합한 독창적인 방향을 제안할 수 있습니다. 특정 스타일 이름을 기계적으로 적용하지 마십시오.

결과물 컨테이너

유형	판단 기준	외부 프레임 및 스크롤	캔버스 경계
A 소프트웨어	관리자 페이지, 도구, 대시보드	전체 창 표시; 긴 목록 및 긴 텍스트는 부분 스크롤	창 내에 고정, 오버레이가 경계를 넘지 않음
B 웹 페이지	브랜드, 랜딩, 콘텐츠 사이트, 포트폴리오	자연스러운 문서 흐름; 전체 페이지 수직 스크롤	뷰포트가 캔버스이며, 경계 제한 없음
C 앱	모바일 우선, 특정 앱 / 휴대폰 / 미니프로그램 지칭	휴대폰 비율 외부 프레임; 프레임 내에서만 스크롤	휴대폰 프레임 내에 고정
D 컴포넌트	플레이어, 라이트박스, 업로드 박스 등 단일 컨트롤	콘텐츠의 자연스러운 크기로 표시; 내부 부분 스크롤	컴포넌트 프레임 내에 고정

사용자가 명시한 경우 그에 따르고, 명시하지 않은 경우 기능에 따라 유추합니다. 컨테이너는 표시 방식만 결정하며 시각적 스타일을 제한하지 않습니다.

컨테이너 디자인 핵심 사항

A 소프트웨어

창, 배경 및 콘텐츠가 완전한 표시 관계를 형성하도록 합니다. 외부 프레임은 제품을 위해 존재하며, 떠 있는 효과를 위해 불필요한 장식을 추가하지 않습니다.
주요 정보와 자주 사용되는 작업이 자연스럽게 공존하도록 우선시합니다. 복잡한 콘텐츠는 합리적인 영역 분할과 부분 스크롤을 통해 처리합니다.
먼저 공간 할당과 반응형 레이아웃을 완료한 후 스크롤 영역을 결정합니다. 자르기, 스크롤바 숨기기 또는 전체 크기 조정으로 레이아웃 문제를 은폐하지 않습니다.
좁은 화면에서는 정보 재배치, 그룹화 및 표시 방식을 우선 조정하며, 핵심 기능이 사라져서는 안 됩니다.
소프트웨어 폭은 전체 창의 85%를 초과하지 않으며, 높이는 90%를 초과하지 않고 주변에 간격을 두고 중앙에 표시합니다.

B 웹 페이지

콘텐츠에 따라 롱 페이지 내러티브, 모듈식 브라우징, 몰입형 첫 화면 또는 기타 적절한 구조를 선택합니다.
페이지에는 시각적 리듬과 콘텐츠 계층이 있어야 하며, 모든 섹션이 동일한 레이아웃을 반복하지 않도록 합니다.
내러티브 요구에 따라 스크롤 기반 애니메이션을 추가할 수 있습니다. 규칙을 충족시키기 위해 스크롤 효과를 강제로 추가하지 않습니다.

C 앱

모바일 장치에 적합한 탐색, 단일 열 또는 상황에 맞는 레이아웃 및 사용하기 쉬운 컨트롤을 채택합니다.
네이티브 컨트롤에 필요한 시각적 사용자 지정을 수행하되 접근성과 사용자 경험을 손상시키지 않습니다.
터치 영역, 하단 탐색 및 콘텐츠 스크롤은 실제 모바일 사용 습관을 준수해야 합니다.
iPhone 폰 치수로 디자인하는 것이 좋습니다(다이내믹 아일랜드 또는 전면 카메라 구성 요소를 만들 필요는 없음).

D 컴포넌트

컴포넌트의 용도와 콘텐츠에 따라 자연스럽게 형태를 갖추며, 완전한 소프트웨어 외부 케이스를 적용하지 않습니다.
유휴, 호버, 포커스, 로딩, 완료, 오류 등 상태를 설계하는 데 중점을 둡니다. 모든 상태 변화는 명확하고 일관되며 이해 가능해야 합니다.

위 네 가지 유형의 오버레이 경계는 다음 섹션을 참조하십시오.

컨테이너 경계: 인터페이스를 캔버스에 고정(소프트웨어 / 앱 / 컴포넌트 강제)

이것은 스타일 선호도가 아니라 하드 제약입니다. 웹 페이지의 경계는 브라우저 뷰포트이고, 소프트웨어, 앱, 컴포넌트는 각자의 경계가 있습니다. 캔버스 밖에는 '무대'(배경)만 존재합니다. 일단 대화 상자, 드로어, 오버레이, 가우시안 블러가 캔버스 밖으로 나가면, 인터페이스는 '소프트웨어'에서 '웹 페이지 스크린샷'으로 퇴화합니다. 이것이 이러한 프로토타입의 가장 흔한 허점입니다.

3계층 구조

제품 본체는 canvas 안에 배치하고, stage는 중앙 정렬과 배경 역할만 하며, 어떤 제품 의미도 stage에 두지 않습니다.

body > .stage          무대: 중앙 정렬 + 배경, 제품 콘텐츠 없음
       └ .canvas       캔버스: 제품 인터페이스 경계
          ├ 제품 콘텐츠 (타이틀 바 / 메인 영역 / 사이드바 …)
          └ .layer     오버레이 그룹: 대화 상자, 드로어, 드롭다운, 토스트
              ├ .scrim  스크림: 어둡게 + 블러
              └ .dialog 대화 상자 본체

핵심 속성(의사 코드):

.canvas {
  position: relative;    /* 오버레이 위치 지정 기준 */
  contain: paint;        /* 클리핑 + fixed 하위 요소를 캔버스에 고정, 생략 불가 */
  overflow: hidden;      /* 경계를 넘는 콘텐츠는 모두 잘라냄 */
  isolation: isolate;    /* 캔버스 내에서 스태킹 및 배경 샘플링 격리 */
  container-type: size;  /* 선택 사항: 내부에서 cqw/cqh를 사용하여 크기 조정 가능 */
  width: min(1440px, 100%);
  height: min(900px, calc(100svh - 2 * var(--stage-pad))); /* container-type을 사용하면 명시적 너비/높이가 필요함 */
}

.layer  { position: absolute; inset: 0; }              /* 캔버스 기준, 절대 fixed 사용 금지 */
.scrim  { position: absolute; inset: 0;               /* 크기가 캔버스 크기와 동일 → 블러 범위가 캔버스와 정확히 일치 */
          background: rgb(8 10 14 / .45); backdrop-filter: blur(10px); }
.dialog { position: relative; width: min(720px, 78cqw); max-height: 82cqh;
          display: flex; flex-direction: column; }
.dialog-body { flex: 1; min-height: 0; overflow: auto; }  /* 콘텐츠 영역만 스크롤 */

`contain: paint`를 명시적으로 작성해야 하는 이유

실측 결과(Edge, 1400×1200): overflow: hidden만 있을 때 캔버스 내의 position: fixed 요소는 여전히 브라우저 뷰포트를 기준으로 위치를 잡고 이탈합니다. contain: paint(또는 transform / filter / will-change: transform / contain: layout)를 추가해야 fixed가 캔버스에 고정되고 잘립니다. container-type: size는 단독으로 작동하지 않으며 contain: paint와 함께 사용해야 합니다. cqw/cqh가 필요하지 않으면 container-type을 제거할 수 있습니다.

금지 사항

캔버스 내에서 position: fixed를 사용하여 오버레이 배치 – 기준이 뷰포트이므로 본질적으로 경계를 초과합니다.
캔버스 내 요소의 크기를 지정하기 위해 vw / vh / dvh 사용 – 뷰포트 단위는 필연적으로 캔버스를 깨뜨립니다.
body, .stage 또는 캔버스 외부 요소에 스크림, 블러, 그림자 적용.
transform: scale()을 사용하여 캔버스를 전체적으로 축소하여 화면에 '맞추기' – 텍스트, 블러, 그림자가 함께 흐려집니다. 올바른 방법은 min()으로 크기를 지정하고 내부에서 자동으로 조정하는 것입니다.
캔버스 외부 무대에 제품 의미 콘텐츠(설명 텍스트, 버튼, 장식 그래픽 등)를 표시하는 것.

대화 상자 크기 규격(소프트웨어 유형 강제)

기본 가로: 너비 > 높이. 소프트웨어 대화 상자는 가로 모드를 우선적으로 사용해야 합니다.

콘텐츠 양	비율 방향	권장 크기(캔버스 기준)	설명
많음 (테이블, 차트, 긴 양식, 편집기)	너비 > 높이, 16:9 또는 4:3	너비 캔버스의 60%–80%, 높이 캔버스의 75% 이하	콘텐츠가 많으면 16:9 우선, 다음 4:3; 가로 공간을 효율적으로 사용하기 위해 병렬 배치 필요
중간 (설정 패널, 여러 필드 양식)	너비 > 높이	너비 480–640px, 높이 320–420px	가로 유지, 하지만 너무 넓지 않음
적음 (확인, 단일 필드, 알림)	정사각형에 가까움	너비 320–420px, 높이 220–320px	세로도 합리적이므로 비율을 위해 억지로 넓힐 필요 없음
세로 목록 (긴 목록, 트리, 선택기)	높이 > 너비	너비 320–400px, 높이 캔버스의 60%–80%	세로는 허용되는 예외입니다: 단일 목록은 본질적으로 세로로 배열됨
작업 영역 (일정, 칸반, 전체 화면 편집)	캔버스 전체 크기에 가까움	캔버스 내 16–24px 여백	여전히 fixed가 아니며 여전히 캔버스 내에 있음

판단 순서: 먼저 '콘텐츠를 병렬로 배치해야 하는가?'를 묻습니다. 병렬 배치가 필요하거나 가로 가독성 요구 사항이 있는 경우(표, 차트, 코드, 타임라인) → 가로; 단일 목록 / 트리 구조 / 단계별 양식 → 세로 가능.

구현 방법: aspect-ratio로 비율 고정, max-height로 최대 높이 제한, 너비는 cqw, 높이는 cqh 사용.

.dialog--wide   { width: min(72cqw, 860px); aspect-ratio: 16 / 9; max-height: 78cqh; }  /* 콘텐츠 많음 */
.dialog--panel  { width: min(56cqw, 680px); aspect-ratio: 4 / 3;  max-height: 78cqh; }  /* 콘텐츠 많음·컴팩트 */
.dialog--compact{ width: min(32cqw, 380px); aspect-ratio: 5 / 4; }                        /* 콘텐츠 적음 */
.dialog--tall   { width: min(30cqw, 360px); height: min(72cqh, 620px); }                   /* 단일 세로 목록 */

콘텐츠가 매우 높으면 max-height가 적용되고 비율이 깨질 수 있습니다. 이는 의도적인 것입니다. 비율이 약간 변형되더라도 콘텐츠가 캔버스 밖으로 넘치는 것을 방지하는 것이 더 중요합니다.

기타 제약 사항:

대화 상자는 캔버스 내에서 중앙에 정렬되며, 주변 여백은 24px 이상이어야 합니다. 가장자리에 붙거나 캔버스 밖으로 나가지 않습니다.
콘텐츠가 초과되면 .dialog-body만 스크롤되고 헤더와 바닥글은 고정됩니다.
어두워지는 스크림은 rgb(0 0 0 / .35) ~ rgb(0 0 0 / .5)를 사용하고, 블러는 8–16px입니다. 적용 범위는 캔버스와 정확히 일치해야 합니다.
동일한 소프트웨어 내에서 대화 상자가 그룹으로 나타날 때 크기는 체계적으로 일관되어야 합니다(동일한 유형은 동일한 크기 사용). 하나는 16:9이고 다른 하나는 좁고 긴 막대 모양이어서는 안 됩니다.

3. 디자인 프로세스

시작하기 전에 skills/ui-metadata/SKILL.md를 읽고 해당 규격에 따라 페이지 디렉토리에 metadata.json을 작성합니다.

0. 이미지 입력의 출처 선언(imageToUI)

사용자가 생성 입력으로 '하나 이상의 이미지'를 제공하는 경우(예: '이미지를 보고 UI 만들기', '이미지 복원', 'AI가 이미지를 1:1로 복제'), metadata.json에 imageToUI 필드를 기록하여 해당 이미지의 출처를 명시해야 합니다. 이를 통해 갤러리 카드가 원본 참조 이미지를 추적하고 클릭하여 볼 수 있습니다. 처리 방식은 입력 유형에 따라 다릅니다.

입력이 이미지 URL인 경우(http://, https:// 또는 //로 시작하는 링크): 해당 링크를 imageToUI에 그대로 기록합니다. 예: "imageToUI": "https://dribbble.com/shots/15820088-Furniture-Board-Desktop-concept". 갤러리는 이미지 아이콘을 렌더링하고 클릭하면 새 탭에서 해당 출처를 엽니다.
입력이 base64 인코딩 또는 로컬 이미지 경로인 경우: AI는 먼저 사용자에게 두 가지 옵션 중 하나를 선택하도록 요청해야 하며, 자동으로 처리해서는 안 됩니다.
1. 해당 이미지의 소스 링크 주소 제공(공개된 출처가 있는 참조 이미지(예: Dribbble / Behance / 디자인 파일 링크)에 권장됨); 또는
2. AI가 이 이미지를 ui/<slug>/assets/ 디렉토리에 복사하여 출처를 보관하도록 허용(강력 권장 – 출처 추적 가능, 오프라인에서도 볼 수 있고 프로토타입과 함께 게시됨). 그런 다음 imageToUI를 "./assets/source-<slug>.png"와 같은 상대 경로로 작성합니다.
⚠️ 금지: base64 문자열이나 로컬 절대 경로를 imageToUI에 그대로 기록하는 것. 로컬 경로는 갤러리 서버에서 액세스할 수 없고, base64는 브라우저에서 열 수 없어 카드 아이콘이 작동하지 않습니다. 사용자가 명시적으로 선택하기 전까지 이 필드를 작성하지 마십시오.

필드 값 규칙(갤러리 catalog.mjs가 이를 기반으로 구문 분석, 자세한 내용은 skills/ui-metadata/SKILL.md 참조):

http:// / https:// / //로 시작 → 외부 링크로 간주, 클릭 시 이동.
기타(./assets/..., assets/...) → 프로토타입 디렉토리 내의 리소스로 간주, /prototypes/<slug>/...로 구문 분석되어 새 탭에서 이미지 열기.
비어 있거나 작성되지 않음 → 카드에 해당 아이콘이 표시되지 않음.

1. 디자인 작업 명확히 하기

제품 포지셔닝, 사용자 시나리오, 핵심 작업, 정보 우선 순위 및 첫 화면의 중요 사항을 결정합니다. 먼저 실제 카피와 합리적인 데이터를 준비한 후 프레젠테이션 방식을 디자인하며, 텅 빈 placeholder 콘텐츠를 피합니다.

2. 시각적 방향 결정

간결한 디자인 설명으로 이 페이지의 분위기를 명확히 하고, 고정된 형식이나 매개변수 테이블을 작성할 필요는 없습니다. 적어도 다음을 명확히 합니다.

전체적인 시각적 인상과 브랜드 성격.
타이포그래피, 구성 및 정보 계층이 콘텐츠를 어떻게 표현하는지.
서체가 개성과 품질을 어떻게 구축하는지.
색상이 분위기, 식별성 및 중요 포인트를 어떻게 구축하는지.
아이콘, 그래픽, 사진 또는 데이터 시각화가 표현에 어떻게 기여하는지.
애니메이션이 경험을 향상시킬 수 있는지, 어떤 모션 언어를 채택해야 하는지.

3. 디자인 시스템 구축

현재 페이지의 필요에 따라 CSS 변수와 재사용 가능한 스타일을 구축합니다. 색상, 서체, 글꼴 크기, 간격, 둥근 모서리, 테두리, 그림자 및 모션 효과는 일관된 디자인 논리를 가져야 하지만, 고정된 수, 값 또는 비율을 강제하지 않습니다.

디자인 시스템을 창의성을 제한하는 매개변수 테이블로 만들지 마십시오. 유연하게 조정할 수 있지만, 모든 선택은 전체적인 효과에 기여해야 합니다.

4. 시각 디자인 핵심 사항

4.1 타이포그래피 및 구성

사용자가 첫눈에 어디를 봐야 하는지 알 수 있도록 하고, 자연스럽게 다른 정보를 이해하도록 합니다.
글꼴 크기, 글꼴 두께, 서체 성격, 색상, 위치, 여백 및 정렬을 사용하여 계층을 구축하며, 카드와 테두리에만 의존하지 않습니다.
콘텐츠에 따라 그리드, 비대칭, 오프셋, 분할 열, 오버레이, 몰입형, 편집 스타일 또는 기타 구성을 탐색합니다.
대담한 크기 대비, 특수 줄바꿈 및 시각적 긴장감을 허용하지만, 전체적으로 조화롭고 읽기 쉬워야 합니다.
페이지는 밀도, 무게 및 리듬의 변화가 있어야 하며, 모든 영역이 평균적으로 동일한 힘을 받지 않도록 합니다.
기본값으로 중앙 정렬, 대칭, 동일한 너비의 카드 또는 동일한 블록 배열을 사용하지 않습니다.
시각적 디자인은 사용자가 정보를 이해하고 작업을 완료하는 데 도움이 되어야 하며, 스크린샷 효과만을 추구해서는 안 됩니다.

4.2 기능과 미니멀리즘의 관계

기능 완성도와 시각적 아름다움은 함께 실현되어야 합니다. 미니멀리즘은 기능을 삭제하는 것이 아닙니다.

제품 카테고리에 따라 사용자가 합리적으로 기대하는 완전한 기능을 제공하며, 페이지를 더 비우거나 단순하게 만들거나 스크린샷을 더 좋게 만들기 위해 기능을 임의로 삭제하지 않습니다.
먼저 정보 아키텍처, 기능 그룹화, 진입점 위치, 상호 작용 흐름 및 시각적 표현을 최적화합니다.
점진적 공개, 상황별 작업, 빠른 실행, 아이콘 표현, 메뉴 및 드로어 등을 사용하여 시각적 부담을 줄입니다.
자주 사용되는 기능은 쉽게 발견하고 조작할 수 있어야 합니다. 덜 사용되는 기능은 접을 수 있지만, 발견하기 어려울 정도로 불필요하게 숨겨서는 안 됩니다.
아이콘은 텍스트를 줄일 수 있지만, 이해하기 쉬워야 합니다. 중요한 작업에는 필요한 경우 텍스트 레이블을 유지합니다.
사용자가 명시적으로 미니멀리즘을 우선시하거나, 중복 기능을 삭제하도록 요청하거나, 특정 기능이 제품 범위에 속하지 않는 경우에만 삭제를 고려하고 그 이유를 설명합니다.
기능 진입점, 상태 및 피드백은 완전해야 합니다. 시각적으로만 존재하고 실제로 응답하지 않는 컨트롤을 만들어서는 안 됩니다.

4.3 카피 및 정보 표현

인터페이스는 매뉴얼이 아닙니다. 간결하게 표현할 수 있으면 긴 설명을 작성하지 않지만, 필요한 정보를 잃지 않기 위해 글자 수를 줄여서는 안 됩니다.
인터페이스에는 '데모 / 프로토타입 / 모의'와 관련된 어떤 텍스트나 그래픽도 있어서는 안 됩니다: '데모 모드', '샘플 데이터', 'Mock 데이터', '테스트 계정', '이것은 프로토타입입니다' 등을 작성하지 않습니다. 말풍선 레이블, 화살표 힌트, 번호 표시, 교육용 하이라이트 상자를 그리지 않습니다. '개념도', '플레이스홀더 이미지', 'Lorem ipsum', '추가 예정'을 사용하지 않습니다. 인터페이스의 모든 단어와 아이콘은 제품에 실제로 있을 법한 내용이어야 합니다.
프로토타입을 실제 출시된 제품 인터페이스로 디자인합니다. 카피는 실제 비즈니스 데이터처럼, 차트는 신뢰할 수 있는 수치 관계를 가지며, 빈 상태는 제품 자체의 안내 문구를 쓰고, 오류 메시지는 사용자가 실제로 직면할 상황을 씁니다. 구현할 수 없는 부분(서버 측 인터페이스)은 전달 설명에서 언급하고 인터페이스에 작성하지 않습니다.
영어 브랜드 또는 글로벌 페이지는 간결한 단어, 짧은 레이블, 큰 글꼴 크기의 텍스트 및 시각적 심볼을 사용할 수 있습니다.
트렌디하고 창의적인 페이지는 아이콘, 심볼, 그래픽 및 시각화된 숫자를 더 많이 사용할 수 있습니다. 전문 도구는 정보의 명확성을 최우선으로 합니다.
중국어 표현은 자연스럽고 정확해야 하며, 장식을 위해 영어나 의미 없는 약어를 억지로 넣지 않습니다.
카피는 구체적이고 정보를 제공해야 하며, 공허한 마케팅 용어, 반복되는 제목 및 자기 서술적인 안내를 피합니다.
상태, 추세, 프로세스, 분류 및 비율은 이해 비용에 따라 아이콘, 차트, 구조도 또는 텍스트를 선택할 수 있으며, 특정 표현 방식을 강제하지 않습니다.

4.4 서체 디자인(중점 사항)

기본 시스템 서체를 최종 솔루션으로 사용하지 마십시오. 긴 본문, 밀도 높은 정보, 읽기 중심 시나리오를 제외하고는 적극적으로 서체를 선택해야 합니다.

고급스러움 / 디자인 감각 / 브랜드 감각이 필요할 때, 적극적으로 디스플레이 서체나 서체 조합을 찾고 기본 서체로 대충 처리하지 마십시오.
제목, 브랜드 로고, 주요 숫자, 본문, 보조 정보는 다른 성격을 가질 수 있지만, 조합은 조화로워야 하며 너무 많은 서체를 쌓지 마십시오.
영어: 기하학적 산세리프, 휴머니스트 산세리프, Grotesk, 세리프, 좁은 / 넓은 서체, Display, 손글씨, 실험적 서체. 분위기에 따라 선택하고 기본적으로 Inter를 사용하지 마십시오.
중국어: 현대 고딕, 명조 / 세리프, 둥근 고딕, 필기체, 특수 디스플레이 서체. 디스플레이 서체는 짧은 제목에만 사용하고, 긴 본문은 가독성을 우선시합니다.
숫자: 기준선, 글자 높이, 너비, 정렬이 통일되어야 하며, 너비가 일정하지 않은 아트 서체를 사용하지 마십시오.
글꼴 두께, 너비, 자간, 대소문자, 이탤릭체, 줄바꿈을 통해 디자인 감각을 표현할 수 있으며, 서체 이름만 변경해서는 안 됩니다.
기본 최소 글꼴 크기는 12px(하한선, 절대 규칙은 아님)입니다. 작은 로고 / 패턴 내 인라인 텍스트는 필요에 따라 작게 조정할 수 있습니다. 타이포그래피는 너비 자동 적응 줄바꿈에 의존하며, 수동으로 줄바꿈하지 않습니다.

서체 출처, CDN 참조, 로딩 속도 저하 처리에 대한 자세한 내용은 6절 '서체'를 참조하십시오.

4.5 색상 디자인

특정 색상 값, 색상 비율 또는 강조 색상을 고정적으로 사용하지 마십시오. 먼저 제품 분위기를 판단한 후 적합한 색상 관계를 대담하게 탐색합니다.

고급 회색, 중성색, 저채도 색상, 자연색, 따뜻함과 차가움의 대비, 브랜드 색상, 밝은 대비색, 어두운 고급스러움, 단색 시스템 등의 방향을 고려할 수 있습니다. 색상은 절제될 수도 있고 선명할 수도 있습니다. 중요한 것은 조화, 계층, 식별성 및 감정 표현입니다.

연한 녹청색, 청록색, 연한 파란색과 같은 차가운 청록 계열은 색상 탐색의 앞순위에 두지 마십시오. 현재 AI가 만드는 인터페이스의 대부분이 이 스타일이어서 너무 비슷해 보일 가능성이 높으므로 최후의 보루로 남겨두십시오.

색상은 명확한 역할을 가져야 하며, 배경, 콘텐츠, 텍스트, 중요 포인트 및 상태 사이에 명확한 관계가 형성되어야 합니다.
강조 색상은 특정 색상으로 고정될 필요가 없으며, 브랜드와 페이지 콘텐츠에 따라 선택해야 합니다.
그라데이션, 투명도, 재질 및 빛과 그림자를 사용할 수 있지만, 디자인 목적이 있어야 하며 그라데이션, 발광 또는 유리 효과를 기본적인 고급스러움으로 간주하지 마십시오.
색상 대비는 텍스트와 중요한 컨트롤을 식별할 수 있을 정도로 충분해야 합니다. 분위기를 위해 가독성을 희생하지 마십시오.
저채도 또는 고급 회색을 추구하여 페이지가 중요 포인트, 계층 및 활기를 잃지 않도록 하십시오.

4.6 아이콘, 그래픽 및 이미지

아이콘, 심볼, 기하학적 그래픽, 일러스트레이션, 사진 및 데이터 시각화는 모두 주요 시각 언어가 될 수 있으며, 텍스트와 카드에 국한되지 않습니다.
제품 분위기에 따라 그래픽 스타일을 선택하고, 선, 비율, 질감 및 표현 방식이 조화를 이루도록 합니다.
기능 아이콘은 식별성을 우선시합니다. 브랜드 또는 창의적인 그래픽은 더 개성적일 수 있습니다.
스타일이 현저히 다른 아이콘 라이브러리를 혼용하지 말고, 공식 기능 아이콘 대신 이모지를 사용하지 마십시오.
그래픽은 표현 목적이 있어야 합니다: 식별 지원, 관계 설명, 상태 전달, 브랜드 구축 또는 시각적 긴장감 강화.
이미지는 명확한 구성, 색상 및 콘텐츠 논리를 가져야 하며, 무작위 콜라주나 관련 없는 자료로 페이지를 채우는 것을 피합니다.

4.7 디테일과 완성도

서체 렌더링, 자간, 정렬, 경계, 아이콘 비율, 계층, 상호 작용 상태 및 콘텐츠 디테일에 주의를 기울입니다.
테두리, 구분선, 그림자, 둥근 모서리, 질감 및 투명 효과는 필요에 따라 사용하며, 장식을 위한 장식을 하지 않습니다.
컴포넌트 간에는 일관성을 유지해야 하지만, 중요한 영역에는 합리적인 시각적 차이를 허용합니다.
페이지는 첫 화면만 정교해서는 안 됩니다. 스크롤 영역, 팝업, 메뉴, 빈 상태 및 오류 상태도 완전히 디자인되어야 합니다.
'디자인 시안처럼 보이게' 하기 위해 실제 사용 시의 가독성, 조작성 및 응답 속도를 희생하지 마십시오.

4.8 테두리가 잘리지 않도록 해야 함(클리핑 컨테이너 필독)

테두리가 있는 컴포넌트를 콘텐츠를 클리핑하는 부모 컨테이너에 넣을 때, 부모 컨테이너의 내부 여백은 컴포넌트의 모든 상태에서 최대 테두리 너비보다 크거나 같아야 합니다. 그렇지 않으면 테두리가 한쪽이 잘려 경계가 누락되어 '렌더링이 깨졌다'고 직접 읽힙니다.

메커니즘

overflow: hidden은 컨테이너의 padding box(콘텐츠 상자 + 내부 여백)를 자릅니다.

컨테이너 내부 여백은 하위 요소의 바깥쪽 오버플로를 흡수할 수 있습니다 → 충분한 여백을 남겨두면 테두리를 드러낼 수 있습니다.
그러나 box-shadow 확장과 outline은 테두리 상자 외부에 그려지므로 내부 여백으로 복구할 수 없습니다.

해결 방법(우선 순위별)

1. 전역 box-sizing: border-box(첫 번째 선택) – 근본적으로 오버플로 제거:

*, *::before, *::after { box-sizing: border-box; }

2. 부모 컨테이너에 테두리 여유 공간 확보 – padding ≥ 테두리 너비 + 1px. 실측 결과: 테두리 4px일 때 padding ≤ 6px이면 오른쪽 테두리 잘림, ≥ 7px이면 완전히 표시됨. 테두리 너비와 정확히 같은 4px에서도 여전히 잘리므로 반드시 여유를 두십시오.

3. inset 그림자로 테두리 대체 – 공간을 차지하지 않고 절대 잘리지 않음:

.card { border: 0; box-shadow: inset 0 0 0 1px var(--line); }

금지 사항

확장 box-shadow / outline을 상시 테두리로 사용(테두리 상자 외부에 그려지므로 잘리기 쉬움).
음수 마진으로 인접 테두리 병합(클리핑이 있을 때 반드시 잘림).

hover 시에만 테두리가 나타나는 경우

가장 빈번한 시나리오: 기본 상태는 정상이지만, hover 시 테두리가 한쪽 잘림. 투명 테두리로 자리를 잡고 색상만 전환하면 전환 시 튀거나 넘치지 않습니다.

.item { border: 1px solid transparent; transition: border-color .18s; }
.item:hover { border-color: var(--line); }

컴포넌트별 확인은 9절 자체 점검 13번 항목을 참조하십시오.

4.9 네이티브 컨트롤 스타일 통일

브라우저 네이티브 컨트롤(스크롤바, select 드롭다운, input / textarea 포커스 상태, checkbox / radio / range 강조 색상, 날짜 선택기 등)은 시스템에 의해 렌더링되므로 자체 UI와 외관이 일치하지 않아 가장 간과하기 쉽고 전체적인 통일감을 해치는 허점입니다. 페이지에 나타나는 모든 네이티브 컨트롤은 제품의 시각적 언어로 통합되어야 하며, 시스템 기본 외관을 유지해서는 안 됩니다.

스크롤바: WebKit은 ::-webkit-scrollbar* 시리즈를, Firefox는 scrollbar-width / scrollbar-color를 사용하여 트랙과 썸의 색상, 둥근 모서리 및 hover 상태를 통일합니다. 로컬 스크롤 영역에만 적용하고, 너비는 절제하며(약 8–10px), 전역적으로 굵게 하지 않습니다.
입력 상자: input / textarea / select는 appearance: none을 사용하여 자체 테두리, 둥근 모서리 및 focus-visible 포커스 상태를 그리고 브라우저 기본 테두리와 내부 그림자를 사용하지 않습니다.
select 드롭다운: 네이티브 option 패널은 심층적으로 사용자 정의할 수 없습니다. appearance: none + 자체 그리기 확장 화살표를 사용하고, --control-* 변수를 사용하여 버튼 및 입력 상자와 일관성을 유지합니다. 검색, 그룹화, 사용자 정의 강조 표시가 필요한 경우 네이티브 select 대신 자체 그리기 드롭다운을 사용합니다.
강조 색상: checkbox / radio / range / progress는 accent-color: var(--brand)를 사용하고 시스템 파란색을 유지하지 않습니다.
복합 입력: 색상, 날짜, 시간 등의 패널은 사용자 정의할 수 없습니다. 중요한 제품의 경우 자체 그리기 또는 입력 형식 제한으로 대체합니다.

핵심: 모든 네이티브 컨트롤의 내부 여백, 글꼴 크기, 둥근 모서리, 포커스 상태를 디자인 변수(예: --control-bg / --control-border / --control-radius / --control-focus)에 통합하여 카드, 버튼과 동일한 시각적 시스템을 유지하고 '두 가지 언어'를 근절합니다.

5. 애니메이션 디자인 및 구현

애니메이션은 UI 디자인의 일부이며, 단순히 버튼에 hover 효과를 추가하는 것이 아닙니다. 제품 분위기와 사용자 요구에 따라 애니메이션이 인터페이스에서 수행하는 역할을 적극적으로 판단해야 합니다.

5.1 먼저 애니메이션 요구 사항 판단

사용자가 뛰어난 애니메이션, 고급 모션 효과, 부드러운 애니메이션, 화려함, 몰입감, 영화 같은 느낌, 동적 비주얼 또는 유사한 요구 사항을 명시적으로 언급하는 경우, 애니메이션을 디자인의 핵심 요소로 삼고 GSAP와 같은 전문 애니메이션 라이브러리를 적극적으로 사용하여 복잡한 효과를 구현해야 하며, 단순한 CSS transition으로 대충 처리해서는 안 됩니다.
브랜드 웹사이트, 크리에이티브 쇼케이스, 제품 출시, 포트폴리오, 인터랙티브 내러티브 등 동적 표현에 적합한 페이지의 경우, 리듬감 있는 등장, 스크롤 내러티브, 시차, 텍스트 애니메이션, 그래픽 변형, 마스크 공개, 계층적 움직임 및 매끄러운 전환을 적극적으로 디자인할 수 있습니다.
전문 도구, 관리자 페이지 및 고빈도 작업 인터페이스의 경우, 애니메이션은 상태 이해, 공간 관계 구축 및 피드백 제공을 도와야 합니다. 정교하고 부드러울 수는 있지만 효율성을 방해해서는 안 됩니다.
사용자가 복잡한 애니메이션을 명시적으로 요구하지 않은 경우, 제품 분위기에 따라 적절하게 디자인하고 기술 과시를 위해 의미 없는 모션 효과를 추가하지 않습니다.
모든 요소를 동일한 페이드인 및 위로 이동 효과로 만들거나, 각 컴포넌트가 독립적으로 공연하게 하지 마십시오.

5.2 애니메이션 질감

기계적인 선형 운동을 피하십시오: 공간 이동, 크기 조정 및 인터페이스 전환은 일반적으로 자연스러운 가속, 감속, 비대칭 이징 또는 스프링 효과를 사용합니다. Linear는 일정한 속도의 회전, 진행률 표시줄, 지속적인 스크롤 등 실제로 필요한 경우에만 사용합니다.
질감 있는 이징 사용: 이동 거리, 요소의 질량감 및 시나리오에 따라 ease-out, ease-in-out, power, expo, back, spring 등의 곡선을 선택합니다. 과장된 탄성 효과는 자제하고, 저렴해 보이는 반복적인 튀는 동작을 피합니다.
적절한 댐핑 감 추가: 큰 패널, 오버레이, 드래그, 팔로우, 마그네틱 효과 및 공간 전환에는 관성, 댐핑, 바운스 또는 스프링 느낌을 주어 동작을 더 자연스럽게 만들 수 있습니다.
동작에는 인과 관계가 있어야 합니다: 들어가기, 나가기, 펼치기, 접기, 전환, 드래그 및 상태 변화는 공간과 물체에 대한 사용자의 직관과 일치해야 합니다.
편성에는 리듬이 있어야 합니다: 피크 시간 오프셋, 오버랩, 연속 연결 및 계층적 움직임을 사용할 수 있지만, 주종 관계가 있어야 하며 모든 요소가 동시에 무작위로 움직여서는 안 됩니다.
애니메이션은 콘텐츠와 작업에 응답해야 합니다: 의미 없는 영구 루프, 지속적인 떠다님 및 주의를 산만하게 하는 배경 애니메이션을 피합니다.
성능 우선: transform, opacity 등 합성에 적합한 속성을 우선 사용합니다. 복잡한 필터, 블러 및 대면적 실시간 효과는 신중하게 사용하고 프레임 드롭을 피합니다.

5.3 GSAP 스킬 및 GSAP 우선 사용

GSAP 애니메이션을 만들기 전에 먼저 판단합니다. 현재 시스템/에이전트에 gsap-skills 스킬이 설치되어 있으면, 애니메이션 디자인 시 이를 호출하여 최신 API와 작성법을 얻습니다. 설치되어 있지 않으면 사용자에게 설치 확인을 요청하고 npx skills add https://github.com/greensock/gsap-skills 실행을 권장합니다(사용자가 설치 여부를 결정). 설치 후 애니메이션 디자인에 사용합니다. 기억에 의존하여 구식 GSAP 사용법을 작성하지 마십시오.

복잡한 애니메이션(등장 내러티브, 스크롤 기반, 타임라인 편성, 인터랙티브 드래그, 다중 요소 협업)은 GSAP를 우선 사용합니다.

Timeline을 사용하여 애니메이션 그룹을 통합적으로 편성하고(레이블, 오버랩, 중첩, 콜백), 서로 관련 없는 delay 세트에 의존하지 않습니다.
스크롤 기반은 ScrollTrigger를 사용합니다. 부드러운 스크롤, 글자별 애니메이션, 경로, 플립 등은 필요에 따라 플러그인을 가져옵니다.
간단한 상태 피드백은 CSS transition / keyframes으로 충분하므로 라이브러리를 위해 라이브러리를 가져오지 않습니다.
CDN(예: gsap@3)을 통해 도입하고 8절의 기술 규칙을 따릅니다. 애니메이션은 모듈식으로 관리하여 재생/일시 중지/역방향/재설정/정리를 용이하게 합니다.

5.4 연속 작업, 중단 및 복구

인터랙션 애니메이션은 사용자의 연속 작업을 고려해야 합니다. 새 작업이 도착하면 현재 시각적 상태에서 자연스럽게 이어져야 하며, 깜빡이거나 초기 위치로 돌아가거나 애니메이션 상태가 실제 UI와 분리되어서는 안 됩니다.

가역 상태(펼치기/접기, 켜기/끄기): 동일한 Timeline을 재사용하고, reverse() / play()로 자연스럽게 역방향 재생하며, 새로 생성하지 않습니다.
연속적으로 대상 값 변경(드래그, 커서 따라가기): gsap.quickTo()를 사용하여 움직임이 항상 최신 입력을 따르도록 하고, 매번 새 tween을 생성하지 않습니다.
다중 시퀀스 연결: Timeline / 중첩 Timeline / 콜백 / 상태 머신을 사용하여 통합 관리하고, 동일한 속성을 놓고 경쟁하는 독립적인 애니메이션을 생성하지 않습니다.
상호 작용 의미에 따라 '시퀀스 계속 / 역방향 재생 / 새 대상으로 전환 / 다른 속성 병렬 실행'을 구분하고, 항상 추가하거나 항상 종료하지 않습니다. 실제로 충돌하는 속성만 재정의합니다(GSAP는 overwrite: "auto"를 사용하고, 임의로 kill()하거나 전역 overwrite: true를 사용하지 않음).

5.5 접근성 및 성능

prefers-reduced-motion: reduce를 존중하고, 사용자에게 모션 효과를 줄이는 옵션을 제공합니다. 애니메이션을 줄일 때 정보와 기능은 여전히 완전해야 합니다.
중요 콘텐츠를 숨기거나 사용자가 즉시 얻어야 하는 정보를 지연시키기 위해 애니메이션을 사용하지 않습니다.
고주파 깜빡임, 빠르고 큰 규모의 확대/축소 및 불편함을 유발할 수 있는 시차를 피합니다.
스크롤 애니메이션은 정상적인 스크롤, 키보드 조작 및 터치 조작에 영향을 주지 않아야 합니다.
페이지를 떠나거나 컴포넌트가 소멸될 때 이벤트 리스너, ScrollTrigger 및 더 이상 필요하지 않은 애니메이션 인스턴스를 올바르게 정리합니다.
첫 화면의 중요한 콘텐츠는 애니메이션 라이브러리가 로드될 때까지 기다렸다가 표시되어서는 안 됩니다.

참고:

6. 자료

tools/resource-getter/get.py를 사용하여 일괄적으로 자료를 가져오고, 사이트 URL을 직접 조합하거나 페이지 곳곳에 출처가 불분명한 외부 링크를 흩뿌리지 마십시오. 전체 출처 매트릭스, 라이선스 및 문제 해결은 tools/resource-getter/README.md를 참조하십시오.

선택 우선 순위

투명 벡터 일러스트레이션: unDraw / Storyset / DiceBear / Doodle Ipsum
배경이 제거된 PNG: Pixabay(--transparent) / pngimg
사진: Pixabay / Picsum / Unsplash / Pexels
손으로 그린 SVG(기하학, 장식, 차트)
AI 생성 이미지(최후의 수단, 아래 규칙 참조)

기본적으로 핫링크, 느리면 로컬에 저장. get의 auto 모드는 TTFB를 측정합니다: > 0.9초 또는 읽기 > 2.5초이면 느린 것으로 판단하고 ui/<page>/assets/에 다운로드해야 합니다. 그보다 빠르더라도 20개의 원격 대용량 이미지를 첫 화면에 쌓지 마십시오.

…

(번역을 위해 잘렸습니다)

즐겨 사용하는 AI에게 물어보기

문서

고품질 UI 프로토타입 디자인

1. 핵심 목표

디자인 원칙 참고

기존 페이지 재사용 금지

2. 먼저 제품을 이해한 후 디자인 결정

결과물 컨테이너

컨테이너 디자인 핵심 사항

컨테이너 경계: 인터페이스를 캔버스에 고정(소프트웨어 / 앱 / 컴포넌트 강제)

3계층 구조

contain: paint를 명시적으로 작성해야 하는 이유

금지 사항

대화 상자 크기 규격(소프트웨어 유형 강제)

3. 디자인 프로세스

0. 이미지 입력의 출처 선언(imageToUI)

1. 디자인 작업 명확히 하기

2. 시각적 방향 결정

3. 디자인 시스템 구축

4. 시각 디자인 핵심 사항

4.1 타이포그래피 및 구성

4.2 기능과 미니멀리즘의 관계

4.3 카피 및 정보 표현

4.4 서체 디자인(중점 사항)

4.5 색상 디자인

4.6 아이콘, 그래픽 및 이미지

4.7 디테일과 완성도

4.8 테두리가 잘리지 않도록 해야 함(클리핑 컨테이너 필독)

메커니즘

해결 방법(우선 순위별)

금지 사항

hover 시에만 테두리가 나타나는 경우

4.9 네이티브 컨트롤 스타일 통일

5. 애니메이션 디자인 및 구현

5.1 먼저 애니메이션 요구 사항 판단

5.2 애니메이션 질감

5.3 GSAP 스킬 및 GSAP 우선 사용

5.4 연속 작업, 중단 및 복구

5.5 접근성 및 성능

6. 자료

선택 우선 순위

관련 스킬

steipete/sag

steipete/oracle

steipete/peekaboo

mattpocock/design-an-interface

mattpocock/prototype

mattpocock/grill-me

`contain: paint`를 명시적으로 작성해야 하는 이유