responsive-design

responsive-design 스킬 개요

responsive-design 스킬은 container queries, fluid sizing, CSS Grid, Flexbox, mobile-first breakpoints를 활용해 적응형 인터페이스를 위한 최신식의 구현 가능한 가이드를 에이전트가 만들도록 돕습니다. 특히 실제 UI 레이아웃, 디자인 시스템 컴포넌트, 대시보드, 카드, 내비게이션, 데이터 밀도가 높은 화면을 만드는 사람에게 잘 맞습니다. 화면 크기마다 따로 brittle한 device-specific CSS를 유지하지 않고도 여러 화면 환경에서 잘 동작해야 할 때 responsive-design 스킬의 가치가 큽니다.

어떤 사람에게 responsive-design 스킬이 잘 맞나

단순히 “모바일 친화적으로 만들어줘” 수준을 넘는 도움이 필요하다면 이 responsive-design 스킬이 적합합니다. 프론트엔드 엔지니어, 구현 디테일까지 다루는 UI 디자이너, 그리고 일반적인 media query 조언이 아니라 컴포넌트 단위의 실제 반응형 패턴을 원하는 에이전트 사용자에게 잘 맞습니다.

실제로 어떤 일을 해결해 주는가

이 스킬이 해결하는 핵심 과제는 대략적인 레이아웃 목표를 실제 반응형 구현 전략으로 바꾸는 일입니다. 무엇을 fluid하게 만들지, 무엇에 breakpoint를 둘지, viewport query 대신 container query를 써야 하는 시점은 언제인지, 그리고 컴포넌트를 여러 문맥에서 재사용 가능하게 유지하려면 어떻게 설계해야 하는지를 정리해 줍니다.

일반 프롬프트와 다른 점

일반 프롬프트는 종종 device 기반 breakpoint나 과도한 media query처럼 다소 낡은 조언을 내놓습니다. 반면 responsive-design 스킬은 저장소에 정리된 최신 CSS 패턴에 초점을 둡니다. 특히 다음 요소가 중심입니다:

• 콘텐츠 기준의 mobile-first breakpoint 전략
• 재사용 가능한 컴포넌트를 위한 container queries
• clamp() 기반의 fluid typography와 spacing
• viewport 차원의 문제와 컴포넌트 차원의 문제를 분리하는 레이아웃 선택

설치 전에 가장 먼저 볼 포인트

결과물이 CSS, 컴포넌트 명세, UI 구현 가이드여야 한다면 이 스킬은 좋은 선택입니다. 반대로 시각적 목업만 필요하거나, no-code 도구 설명이 목적이거나, CSS 판단 없이 프레임워크 추상화만 원하는 경우에는 효용이 떨어집니다. 이 저장소는 automation script 중심이 아니라 reference 중심이므로, 실제 가치는 스크립트가 아니라 references/에 있는 패턴과 예시에 있습니다.

responsive-design 스킬 사용 방법

responsive-design 설치 맥락

루트 skill collection에서 다음 명령으로 설치합니다:

npx skills add https://github.com/wshobson/agents --skill responsive-design

upstream skill은 별도 script나 framework binding을 함께 제공하지 않기 때문에, 설치의 핵심은 이 가이드를 에이전트가 호출할 수 있게 만드는 데 있습니다. 엄격한 입력 스키마를 가진 코드 생성기라기보다, 문서와 패턴 중심의 스킬이라고 보는 편이 맞습니다.

먼저 읽어야 할 파일

다음 파일을 이 순서대로 읽는 것이 좋습니다:

1. plugins/ui-design/skills/responsive-design/SKILL.md
2. plugins/ui-design/skills/responsive-design/references/container-queries.md
3. plugins/ui-design/skills/responsive-design/references/fluid-layouts.md
4. plugins/ui-design/skills/responsive-design/references/breakpoint-strategies.md

이 순서가 중요한 이유는, 먼저 core skill에서 범위를 잡고 그다음 references에서 실제 출력 품질을 끌어올리는 구현 디테일을 보강하기 때문입니다.

스킬이 사용자에게 필요로 하는 입력

responsive-design 스킬은 다음 정보를 줄수록 결과가 좋아집니다:

• 컴포넌트 또는 페이지 유형
• 레이아웃 제약 조건
• 대상 화면 맥락
• 반응형 기준이 viewport 기반인지, container 기반인지, 혼합형인지
• 디자인 시스템 token이나 breakpoint 규칙
• 브라우저 지원 요구사항

약한 입력 예:
“Make this responsive.”

더 강한 입력 예:
“Create a responsive card grid for a dashboard. Cards must work in a full-width page and in a narrow sidebar. Use container queries where component context changes, fluid spacing and type, and keep breakpoints aligned to our sm/md/lg token scale unless content forces a different threshold.”

막연한 목표를 강한 프롬프트로 바꾸는 법

좋은 responsive-design usage 프롬프트는 보통 다섯 가지 요소를 포함합니다:

1. UI 대상: card list, nav bar, pricing table, form, data table
2. 행동 변화: stack, wrap, collapse, resize, reorder, reveal
3. 제약의 기준점: viewport, parent container, content width
4. 시스템 규칙: token scale, grid rules, minimum tap size, accessibility needs
5. 원하는 출력 형태: CSS example, implementation plan, breakpoint rationale, refactor advice

예시 프롬프트:

“Use the responsive-design skill to propose a responsive strategy for a product comparison table. Prioritize small screens first, avoid horizontal overflow where possible, use content-based breakpoints, and explain whether container queries or viewport media queries should control each part. Include sample CSS for typography, spacing, and layout transitions.”

언제 container queries를 요청해야 하나

컴포넌트가 브라우저 너비가 아니라 배치되는 위치에 따라 달라져야 한다면 container queries를 써야 합니다. 특히 재사용 가능한 카드, 사이드 패널, 위젯, 임베디드 모듈, 디자인 시스템 컴포넌트에서 중요합니다.

컴포넌트가 여러 부모 레이아웃에 등장한다면 저장소의 references/container-queries.md가 가장 중요한 참고 파일입니다. 실전 문법, named containers, 브라우저 지원 관련 메모까지 포함되어 있습니다.

breakpoint를 늘리기보다 fluid layouts를 요청해야 하는 때

UI 문제가 주로 텍스트, spacing, width를 자연스럽게 스케일링하는 데 있다면, 먼저 fluid 기법 쪽으로 에이전트를 유도하는 것이 좋습니다. references/fluid-layouts.md는 hard breakpoint 점프를 줄이고 clamp(), relative units, intrinsic sizing으로 더 자연스럽게 크기가 변하는 UI를 만들고 싶을 때 유용합니다.

보통 다음 항목에서 특히 효과가 좋습니다:

• 제목과 본문 텍스트
• 섹션 간 spacing
• 카드 크기
• 갑자기 snap되기 전에 여유 있게 늘어나야 하는 grid

breakpoint 가이드를 제대로 활용하는 방법

이 저장소는 device 카탈로그식 접근보다 콘텐츠 기준의 mobile-first breakpoint를 강하게 선호합니다. 실무에서는 각 breakpoint를 레이아웃 압력으로 설명해 달라고 요청하는 것이 좋습니다. 예를 들어 line length, 카드 과밀, table overflow, nav wrapping, 터치 타깃 문제 같은 근거가 있어야 합니다.

팀에서 이미 Tailwind나 Bootstrap breakpoint token을 쓰고 있다면 반드시 밝혀두세요. references에는 흔히 쓰는 scale이 포함되어 있어, 스킬이 임의의 값을 새로 만들기보다 기존 시스템에 맞춰 현대적인 전략을 매핑하는 데 도움이 됩니다.

실제 프로젝트에 맞는 추천 워크플로

실무적인 responsive-design guide 워크플로는 다음과 같습니다:

1. 컴포넌트 설명과 작은 화면/큰 화면에서의 실패 양상을 먼저 적습니다.
2. 코드부터 요구하지 말고 레이아웃 전략부터 요청합니다.
3. 무엇을 fluid하게 둘지, 무엇을 snap시킬지, 무엇을 reflow시킬지 결정합니다.
4. 전략이 타당해진 뒤에만 예시 CSS를 요청합니다.
5. 브라우저 preset만 보지 말고 실제 container width 기준으로 결과를 테스트합니다.
6. 첫 결과가 너무 일반적이면 screenshot, DOM structure, 현재 CSS를 붙여서 다시 반복합니다.

이 순서는 처음부터 최종 CSS를 바로 요구하는 방식보다 결과가 좋습니다.

가장 잘 맞는 출력 형식

다음과 같은 출력 형태로 요청하면 효과적입니다:

• responsive implementation plan
• breakpoint rationale table
• CSS starter pattern
• component refactor strategy
• audit of an existing layout
• “container query vs media query” decision

이 형식들은 단순히 “반응형 코드 줘”라고 하는 것보다 판단을 더 명확하게 끌어냅니다.

출력 품질을 높이는 실전 팁

더 나은 responsive-design for UI Design 결과를 원한다면:

• 레이아웃 관계가 중요할 때는 현재 HTML 구조를 포함합니다
• 콘텐츠 길이 변화가 큰지 명시합니다
• 읽기 가능한 최소 텍스트 크기와 최소 interactive target 크기를 적어둡니다
• 콘텐츠 재정렬이 허용되는지 에이전트에 알려줍니다
• container query 중심 해법을 제안하기 전에 legacy browser 제약을 먼저 알려줍니다

이 정보가 없으면 스킬이 기술적으로는 최신이지만 실제 지원 매트릭스나 컴포넌트 아키텍처에는 맞지 않는 패턴을 선택할 수 있습니다.

responsive-design 스킬 FAQ

responsive-design 스킬은 초보자도 쓰기 쉬운가

기본 CSS를 알고 있다면 그렇습니다. 다만 이 스킬은 입문 튜토리얼형이라기보다 개념적으로 현대적인 방향에 가깝기 때문에, CSS를 읽을 수 있고 반응형 의사결정을 더 잘하고 싶은 사용자에게 특히 강합니다. 초보자도 사용할 수는 있지만 container queries, intrinsic sizing, fluid scales 같은 용어는 나올 수 있습니다.

이 스킬이 프레임워크별 코드를 생성하나

주된 강점은 아닙니다. 저장소 콘텐츠는 CSS 패턴 중심입니다. React, Vue, Tailwind, plain CSS에 맞춰 달라고 요청할 수는 있지만, 핵심 가치는 프레임워크 통합 세부사항보다 반응형 전략 자체에 있습니다.

일반적인 UI 프롬프트보다 responsive-design이 더 나은가

반응형이 과제의 핵심이라면 대체로 그렇습니다. 일반 프롬프트는 오래된 breakpoint 습관이나 피상적인 “모바일에서는 쌓기” 수준의 안내로 흐르기 쉽습니다. responsive-design skill은 레이아웃 결정을 위해 더 분명하고 최신의 어휘와 기준을 에이전트에 제공합니다.

언제 responsive-design을 쓰지 말아야 하나

다음이 주된 작업이라면 굳이 쓰지 않는 편이 낫습니다:

• 비주얼 브랜딩
• 정적 목업 생성
• 애니메이션 비중이 큰 인터랙션 디자인
• 레이아웃과 무관한 프레임워크 설정
• 적응형 동작 결정 없이 픽셀 단위 복제만 필요한 작업

또한 팀이 현대적인 CSS 기능을 사용할 수 없고 IE 시절 호환 패턴이 필요하다면 적합도가 떨어집니다.

브라우저 지원 이슈도 다루나

부분적으로는 그렇습니다. references는 특히 container queries를 중심으로 최신 지원 상황을 언급하고, graceful fallback 가능성을 시사합니다. 다만 이것이 compatibility matrix 전용 스킬은 아닙니다. 브라우저 지원이 중요하다면 프롬프트에 최소 지원 브라우저를 명시하세요.

디자인 시스템 작업에도 도움이 되나

그렇습니다. breakpoint 철학, token에 맞춘 spacing과 typography, 그리고 container별로 재사용 가능한 컴포넌트 동작을 다루는 데 잘 맞습니다. 페이지별 해킹을 줄이고 더 이식성 높은 컴포넌트를 만들고 싶을 때 특히 유용합니다.

responsive-design 스킬을 더 잘 활용하는 방법

responsive-design 스킬에 실제 제약을 주기

가장 큰 품질 향상은 제약을 구체화할 때 나옵니다. 실제 width, token 이름, 콘텐츠 샘플, UI 상태를 제공하세요. “Responsive dashboard card”는 모호하지만, “긴 제목과 두 개의 액션이 있는 카드를 320px sidebar와 1200px main grid에서 함께 사용한다”는 식이면 바로 활용 가능한 입력이 됩니다.

코드만이 아니라 판단을 요청하기

더 좋은 프롬프트:
“Use the responsive-design skill to decide which parts should use fluid sizing, which need breakpoints, and where container queries are justified.”

이 방식은 다음보다 훨씬 강한 추론을 끌어냅니다:
“Write responsive CSS.”

리팩터링이라면 기존 CSS를 함께 제공하기

이미 레이아웃 코드가 있다면 현재 CSS를 그대로 붙여 넣고 단순화해 달라고 요청하세요. 그러면 불필요한 media query를 제거하고, 취약한 width 가정을 찾아내고, 필요하다면 viewport-only 로직을 컴포넌트 인식 규칙으로 바꾸는 데 도움이 됩니다.

자주 나타나는 실패 패턴

첫 출력이 여전히 약할 수 있는 경우는 보통 다음과 같습니다:

• 에이전트가 콘텐츠 근거 없이 breakpoint를 추측함
• viewport 규칙이 더 단순한데도 container queries를 과하게 사용함
• fluid typography에 min/max bounds가 없음
• 레이아웃 변화가 접근성이나 읽기 편의성을 무시함
• 예시는 보기 좋지만 실제 DOM structure와 맞지 않음

이런 문제는 각 규칙의 rationale을 요구하고, UI 문제와 규칙을 연결해 달라고 하면 대부분 교정할 수 있습니다.

첫 초안 뒤에는 반복 프롬프트를 활용하기

좋은 후속 프롬프트 예:

• “Reduce unnecessary breakpoints and explain what can be fluid instead.”
• “Refactor this so the component works in both narrow sidebar and wide content areas.”
• “Add fallbacks for teams that cannot rely fully on container queries.”
• “Audit this layout for overflow, cramped text, and awkward wrap points.”

처음부터 전체 재작성을 요구하는 것보다, 이런 후속 지시가 실제 도입 가능성을 더 많이 끌어올립니다.

화면 크기만이 아니라 컴포넌트 맥락으로 검증하기

responsive-design 스킬의 핵심 통찰 중 하나는 많은 실패가 viewport width만 테스트해서 생긴다는 점입니다. 같은 컴포넌트를 다음 환경에 넣어 확인하면 결과가 더 좋아집니다:

• 전체 페이지 콘텐츠
• sidebar
• modal
• 촘촘한 dashboard grid
• 삽입형 marketing section

container에 따라 동작이 달라진다면, 처음부터 그 사실을 스킬에 알려 적절한 반응형 메커니즘을 선택하게 하세요.

reference 파일을 프롬프트 앵커로 활용하기

더 깊이 있는 출력을 원하면 저장소 reference를 직접 언급하세요:

• 컴포넌트 반응형은 references/container-queries.md
• 자연스러운 스케일링은 references/fluid-layouts.md
• mobile-first breakpoint 판단은 references/breakpoint-strategies.md

이 방법은 에이전트가 일반적인 프론트엔드 조언이 아니라, 더 근거 있는 responsive-design usage를 하게 만드는 가장 쉬운 방법 중 하나입니다.

더 좋은 acceptance criteria로 결과 개선하기

스킬에 다음처럼 구체적인 목표를 주면 좋습니다:

• media query 수 줄이기
• 특정 width 이하에서 horizontal overflow 없애기
• 읽기 좋은 line length 유지
• 여러 container size에서 재사용 가능한 컴포넌트 만들기
• token에 맞춘 spacing과 type 유지
• breakpoint 사이 layout shift 최소화

acceptance criteria가 명확할수록 responsive-design 스킬은 실제 프로덕션 UI 작업에서 훨씬 더 유용해집니다.