2026년에 쓸만한 기획 디자인 AI 에이전트 도구 6가지 > AI Agent

이전글챗GPT가 내 컴퓨터 상에서 AI 코딩 에이전트로써 작동하게 하는 방법 … 다음글 2026년에 사용되고 있는 자율 AI 에이전트 4가지

최고관리자

26-08-29 03:14 0개 25회

2026년에 쓸만한 기획 디자인 AI 에이전트 도구 6가지

# AI 에이전트와 함께 쓰는 기획·디자인 도구 6가지 AI 코딩 에이전트 덕분에 아이디어를 실제 화면과 코드로 옮기는 속도가 매우 빨라졌습니다. “할 일 관리 앱을 만들어줘”라고 요청하면 몇 분 만에 화면이 생기고 버튼도 작동합니다. 하지만 **빠르게 만들어진 것과 사람들이 실제로 쓸 수 있는 제품은 다릅니다.** 무엇을 왜 만들어야 하는지, 사용자는 누구인지, 화면은 어떤 규칙으로 구성할지 정하지 않으면 결과는 쉽게 흔들립니다. * 기능은 많지만 정작 사용자가 원하는 문제를 해결하지 못합니다. * 요청할 때마다 색상, 간격, 버튼 모양이 달라집니다. * 에이전트가 말하지 않은 부분을 임의로 가정해 구현합니다. * 결과가 잘못되어도 기준 문서가 없어 어디서 어긋났는지 찾기 어렵습니다. * 어디서 본 듯한 ‘AI 스타일’의 랜딩 페이지가 반복됩니다. 이 문제를 줄이기 위해 최근에는 기존의 기획·디자인 방법론을 AI 에이전트가 바로 읽고 실행할 수 있는 **스킬, 명령어, Markdown 문서, MCP 서버** 형태로 제공하는 도구가 등장하고 있습니다. 이 글에서는 다음 6가지를 기획 도구와 디자인 도구로 나누어 살펴봅니다. | 영역 | 도구 | 핵심 역할 | | --- | --- | ----- | | 기획 | **Superpowers** | 에이전트가 코드보다 질문과 설계를 먼저 하게 만듦 | | 기획 | **GitHub Spec Kit** | 아이디어를 원칙·스펙·계획·작업 문서로 구조화 | | 기획 | **BMAD Method** | PM·분석가·아키텍트·개발·QA 관점으로 나누어 검토 | | 디자인 | **DESIGN.md** | 색상·글꼴·간격·컴포넌트 규칙을 AI가 읽는 파일로 정의 | | 디자인 | **shadcn/ui MCP** | 에이전트가 필요한 UI 컴포넌트를 검색하고 가져오게 함 | | 디자인 | **taste-skill** | 흔한 AI 디자인 패턴을 줄이고 시각적 방향을 명시 | > 이 글은 요즘IT의 「AI 에이전트와 함께 쓰는 기획/디자인 도구 6가지」를 참고하되, 초보자도 직접 선택하고 적용할 수 있도록 공식 저장소와 문서를 바탕으로 사용 순서, 예시 프롬프트, 주의점을 새롭게 구성했습니다. 도구의 명령어와 지원 에이전트는 빠르게 바뀔 수 있으므로 설치 전 공식 문서를 확인하세요. *이미지 출처: [요즘IT 원문](https://yozm.wishket.com/magazine/detail/3885/)* ## 목차 1. [왜 코딩 전에 기획과 디자인이 필요할까?](#왜-코딩-전에-기획과-디자인이-필요할까) 2. [6가지 도구 한눈에 비교하기](#6가지-도구-한눈에-비교하기) 3. [기획 도구 3가지](#기획-도구-3가지) 4. [디자인 도구 3가지](#디자인-도구-3가지) 5. [프로젝트별 추천 조합](#프로젝트별-추천-조합) 6. [실전 작업 흐름](#실전-작업-흐름) 7. [도입 전 체크리스트](#도입-전-체크리스트) *** ## 왜 코딩 전에 기획과 디자인이 필요할까? AI 에이전트는 빈칸을 그냥 두지 않습니다. 사용자가 설명하지 않은 부분이 있으면 학습 데이터에서 가장 가능성이 높아 보이는 값을 가져와 채웁니다. 이 성질은 간단한 시제품을 만들 때는 편하지만, 실제 제품에서는 위험할 수 있습니다. 예를 들어 “프리랜서를 위한 일정 관리 서비스를 만들어줘”라고만 요청하면 에이전트는 다음을 임의로 정할 수 있습니다. * 주요 사용자를 1인 프리랜서로 볼지 소규모 팀으로 볼지 * 일정과 프로젝트 가운데 무엇을 중심에 둘지 * 모바일과 데스크톱 중 어느 환경을 우선할지 * 무료·유료 기능을 어떻게 나눌지 * 밝은 화면과 어두운 화면 중 어떤 스타일을 사용할지 에이전트가 빠르게 구현했더라도 이 가정이 잘못되면 처음부터 다시 만들어야 합니다. 그래서 AI 시대에는 코딩보다 먼저 **판단 기준을 문서로 고정하는 일**이 중요해졌습니다. ``` flowchart LR A[막연한 아이디어] --> B[질문과 사용자 정의] B --> C[스펙과 완료 기준] C --> D[디자인 규칙] D --> E[컴포넌트와 구현] E --> F[검증과 개선] ``` ### 기획 도구와 디자인 도구의 차이 * **기획 도구**는 무엇을, 누구를 위해, 왜 만들지 정합니다. * **디자인 도구**는 그 결과가 어떤 규칙과 부품으로 보이고 작동할지 정합니다. 둘은 순서가 있습니다. 예쁜 화면을 먼저 만든 뒤 사용자를 끼워 맞추기보다, 사용자의 문제와 기능 범위를 정한 다음 시각적 규칙을 만드는 편이 좋습니다. *** ## 6가지 도구 한눈에 비교하기 | 도구 | 해결하는 문제 | 결과물 | 권장 규모 | 학습 부담 | | --- | ------- | --- | ----- | ----- | | **Superpowers** | 에이전트가 질문 없이 바로 코딩하는 문제 | 설계 대화, 계획, 작은 작업 목록 | 소형\~중형 | 낮음\~보통 | | **GitHub Spec Kit** | 기획 문서의 순서와 범위를 모르는 문제 | 원칙, 스펙, 계획, 작업, 구현 기록 | 중형\~대형·신규 프로젝트 | 보통 | | **BMAD Method** | 한 사람의 관점으로 기획해 놓치는 문제 | 역할별 기획·아키텍처·스토리 문서 | 중형\~대형·복잡한 제품 | 높음 | | **DESIGN.md** | 화면마다 디자인 규칙이 달라지는 문제 | AI와 사람이 읽는 디자인 시스템 파일 | 모든 규모 | 낮음\~보통 | | **shadcn/ui MCP** | 어떤 UI 부품을 써야 할지 모르는 문제 | 프로젝트 안에 설치된 컴포넌트 코드 | React·Tailwind 기반 프로젝트 | 보통 | | **taste-skill** | 결과에서 흔한 ‘AI 디자인’ 느낌이 나는 문제 | 시각적 방향과 금지 규칙 | 랜딩·포트폴리오·대시보드 | 낮음 | ### 먼저 결론부터 말하면 6개를 모두 설치할 필요는 없습니다. * 아이디어가 너무 막연하다면 **Superpowers** * 새 프로젝트를 정해진 문서 순서로 관리하려면 **Spec Kit** * 여러 직무의 관점이 필요한 복잡한 제품이라면 **BMAD** * 화면의 일관성이 필요하면 **DESIGN.md** * 검증된 UI 부품을 빠르게 조달하려면 **shadcn/ui MCP** * 결과가 지나치게 평범하고 AI가 만든 것처럼 보이면 **taste-skill** 가장 중요한 선택 기준은 ‘유명한 도구인가’가 아니라 **현재 프로젝트가 어디에서 막혀 있는가**입니다. *** ## 기획 도구 3가지 *이미지 출처: [요즘IT 원문](https://yozm.wishket.com/magazine/detail/3885/)* ### 1\. Superpowers: 코딩하기 전에 질문부터 시키기 *이미지 출처: [요즘IT 원문](https://yozm.wishket.com/magazine/detail/3885/)* #### 어떤 도구인가요? Superpowers는 코딩 에이전트에 추가하는 스킬 프레임워크이자 개발 방법론입니다. 사용자가 기능을 요청했을 때 에이전트가 즉시 코드를 작성하지 않고, 먼저 질문을 통해 의도와 범위를 확인하도록 만듭니다. 예를 들어 “관리자 페이지에 다크 모드를 추가해줘”라는 요청에는 다음과 같은 질문이 필요합니다. * 운영체제 설정을 자동으로 따라야 하나요? * 사용자가 직접 선택한 모드를 기억해야 하나요? * 차트와 외부 위젯도 다크 모드에 포함되나요? * 기존 브랜드 색상은 어떻게 바뀌어야 하나요? * 접근성 대비 기준은 무엇인가요? 이 질문 없이 바로 코딩하면 기능은 작동하더라도 사용자가 기대한 범위와 다를 가능성이 큽니다. #### 기본 작업 흐름 1. **Brainstorming**: 아이디어를 질문으로 구체화합니다. 2. **설계 승인**: 결정 사항을 짧은 구간으로 보여주고 사용자의 확인을 받습니다. 3. **계획 작성**: 구현을 몇 분 단위의 작은 작업으로 나눕니다. 4. **격리된 작업 환경**: 필요에 따라 별도 브랜치·워크트리에서 작업합니다. 5. **구현과 테스트**: 작은 단위로 코드를 작성하고 테스트합니다. 6. **리뷰**: 요구사항 충족과 코드 품질을 각각 확인합니다. 7. **마무리**: 테스트 후 병합·PR·보관 여부를 결정합니다. #### 이런 사람에게 좋습니다 * 만들고 싶은 것은 있지만 문서로 정리하지 못한 사람 * 에이전트가 너무 빨리 구현해 자주 되돌리는 사람 * 기획 대화를 하면서 요구사항을 발견하고 싶은 사람 * 하나의 코딩 에이전트 안에서 설계부터 테스트까지 이어가고 싶은 사람 #### 바로 써볼 요청 예시 ``` 프리랜서를 위한 프로젝트 마감일 관리 화면을 만들고 싶어. 아직 코드를 작성하지 말고, 주요 사용자와 가장 중요한 문제를 명확히 하기 위한 질문을 한 번에 하나씩 해줘. 답변이 모이면 가능한 설계안 2개와 각각의 장단점을 제안해줘. 내가 설계를 승인한 뒤에만 구현 계획을 작성해줘. ``` #### 장점 * 설치 후 상황에 맞는 스킬이 자동으로 적용되는 편입니다. * 요구사항을 작은 작업과 검증 절차로 연결합니다. * 테스트와 리뷰를 작업 흐름에 포함하기 좋습니다. * Claude Code, Codex, Cursor, Gemini CLI 등 여러 코딩 에이전트를 지원합니다. #### 주의할 점 모든 수정에 깊은 절차가 필요한 것은 아닙니다. 오타 수정이나 색상 값 하나를 바꾸는 작업에도 질문·설계·테스트 절차를 모두 적용하면 오히려 느려집니다. 또한 서브에이전트와 반복 리뷰를 사용하면 토큰 소비량이 커질 수 있습니다. 새로운 기능이나 구조 변경처럼 **잘못 만들었을 때 되돌리는 비용이 큰 작업**에 집중해서 사용하는 편이 좋습니다. #### 참고 링크 * [Superpowers 공식 GitHub 저장소](https://github.com/obra/superpowers) * [Superpowers 설치·지원 에이전트 안내](https://github.com/obra/superpowers#installation) *** ### 2\. GitHub Spec Kit: 아이디어를 단계별 문서로 고정하기 *이미지 출처: [요즘IT 원문](https://yozm.wishket.com/magazine/detail/3885/)* #### 어떤 도구인가요? GitHub Spec Kit은 \*\*스펙 주도 개발(Spec-Driven Development)\*\*을 위한 공식 툴킷입니다. 스펙을 코드 작성 전에 잠깐 만드는 참고 문서가 아니라, 구현 과정 전체를 움직이는 중심 자료로 사용합니다. Superpowers가 질문과 대화를 통해 아이디어를 구체화한다면, Spec Kit은 그 결과를 **어떤 순서의 문서로 남길지** 정해줍니다. #### 핵심 단계 | 단계 | 목적 | 답해야 하는 질문 | | --- | --- | --------- | | **Constitution** | 프로젝트의 변하지 않는 원칙 정의 | 우리가 반드시 지켜야 할 기준은 무엇인가? | | **Specify** | 무엇을 왜 만드는지 명시 | 사용자는 누구이고 어떤 결과가 필요한가? | | **Plan** | 기술적 구현 방법 결정 | 어떤 구조와 기술로 만들 것인가? | | **Tasks** | 실행 가능한 작업으로 분해 | 누가 무엇을 어떤 순서로 할 것인가? | | **Implement** | 계획에 따라 구현 | 각 작업의 완료 조건을 충족했는가? | | **Converge** | 구현과 문서의 차이를 점검 | 스펙·계획·코드가 서로 일치하는가? | 프로젝트 원칙을 먼저 만들고, 스펙 단계에서는 기술 스택보다 **무엇과 왜**에 집중한다는 점이 중요합니다. 기술 결정은 계획 단계로 미룹니다. #### 프로젝트 원칙 예시 ``` - 사용자 데이터는 명시적인 동의 없이 외부로 전송하지 않는다. - 모바일 화면을 우선 설계한다. - 핵심 작업은 세 번 이내의 클릭으로 완료할 수 있어야 한다. - 모든 기능에는 측정 가능한 완료 기준과 테스트가 있어야 한다. - 접근성은 WCAG AA 수준을 기본 목표로 한다. ``` #### 바로 써볼 스펙 요청 예시 ``` 지역 소상공인이 매일 매출과 재고를 간단히 기록하는 모바일 웹앱을 정의해줘. 사용자는 엑셀에 익숙하지 않은 50대 매장 운영자야. 기술 스택은 아직 정하지 말고, 사용자의 문제, 핵심 시나리오, 기능 범위, 제외할 기능, 성공 지표, 수용 기준을 중심으로 스펙을 작성해줘. 불명확한 내용은 임의로 결정하지 말고 질문 목록으로 분리해줘. ``` #### 이런 사람에게 좋습니다 * 빈 폴더에서 새로운 제품을 시작하는 사람 * 생각을 단계별 문서로 확인하고 싶은 기획자·개발자 * 여러 사람이 같은 기획·개발 절차를 사용해야 하는 팀 * 몇 달 뒤에도 결정 이유를 추적할 수 있어야 하는 프로젝트 #### 장점 * 기획과 구현의 차이를 문서 단계별로 추적할 수 있습니다. * 비개발자도 스펙 단계에서 기술 구현을 몰라도 참여할 수 있습니다. * 원칙, 요구사항, 계획, 작업과 코드가 연결됩니다. * 명확화·일관성 분석·체크리스트 같은 선택 명령을 추가로 활용할 수 있습니다. #### 주의할 점 작은 기능 하나를 위해 스펙과 계획 문서를 여러 개 만들면 코드보다 문서가 많아질 수 있습니다. 이미 운영 중인 제품에 작은 기능을 추가하는 상황이라면 더 가벼운 [OpenSpec](https://github.com/Fission-AI/OpenSpec)을 비교해보는 것도 좋습니다. 문서가 있다고 기획이 자동으로 좋아지는 것도 아닙니다. 잘못된 가정을 문서에 정확하게 적으면, 에이전트는 그 잘못된 방향을 더 성실하게 구현할 수 있습니다. 사용자 조사와 실제 검증은 별도로 필요합니다. #### 참고 링크 * [GitHub Spec Kit 공식 저장소](https://github.com/github/spec-kit) * [Spec Kit 공식 문서](https://github.github.io/spec-kit/) * [OpenSpec 공식 저장소](https://github.com/Fission-AI/OpenSpec) *** ### 3\. BMAD Method: 여러 직무의 관점으로 기획하기 *이미지 출처: [요즘IT 원문](https://yozm.wishket.com/magazine/detail/3885/)* #### 어떤 도구인가요? BMAD Method는 하나의 에이전트에게 모든 일을 맡기는 대신, 실제 제품팀처럼 역할을 나누어 기획·설계·구현·검증하는 방법론입니다. 분석가, PM, UX, 아키텍트, 개발자, QA 역할이 서로 다른 질문을 던지고 결과를 다음 역할에 전달합니다. 혼자 기획하면 자신이 이미 알고 있는 질문만 반복하기 쉽습니다. 역할을 나누면 다음과 같이 관점이 늘어납니다. * **분석가**: 이 문제가 실제로 존재한다는 근거는 무엇인가? * **PM**: 첫 번째 버전에서 반드시 필요한 기능은 무엇인가? * **UX 역할**: 사용자가 가장 자주 막힐 지점은 어디인가? * **아키텍트**: 이 결정이 확장성과 유지보수에 어떤 영향을 주는가? * **개발자**: 구현 가능한 작은 작업으로 어떻게 나눌 것인가? * **QA 역할**: 어떤 상태가 되면 완료라고 판단할 수 있는가? #### 기본 작업 흐름 ``` flowchart TD A[아이디어 명확화] --> B[PM·분석가의 제품 계획] B --> C[UX·아키텍처 설계] C --> D[에픽·스토리 분해] D --> E[개발·검증] E --> F[학습과 계획 조정] F --> B ``` #### 이런 사람에게 좋습니다 * 기능과 이해관계자가 많은 중형·대형 제품 * PM·디자이너·개발자 관점을 혼자 챙겨야 하는 1인 개발자 * PRD, 아키텍처, 에픽, 스토리 문서가 필요한 팀 * 구현 전에 여러 선택지와 위험을 깊게 검토해야 하는 프로젝트 #### 바로 써볼 요청 예시 ``` 직원 100명 규모의 회사에서 사용할 회의실 예약 서비스를 기획하려고 해. 분석가, PM, UX 디자이너, 보안 담당자 관점으로 나누어 검토해줘. 각 역할은 핵심 질문 5개와 가장 큰 위험 3개를 제시하고, 서로 충돌하는 요구사항이 있으면 결론을 내리지 말고 의사결정 항목으로 정리해줘. 아직 코드를 구현하지 말고 MVP 범위와 PRD 초안까지만 만들어줘. ``` #### 장점 * 한 사람이 놓치기 쉬운 질문을 역할별 절차가 보완합니다. * 기획부터 구현까지 연결되는 전체 제품 개발 흐름을 제공합니다. * 프로젝트 규모에 따라 일부 역할과 단계를 선택할 수 있습니다. * 웹 기반 계획과 IDE 기반 구현을 나누어 활용할 수 있습니다. #### 주의할 점 BMAD는 강력한 만큼 배울 것이 많습니다. 역할, 문서 인계, 설정과 명령을 익혀야 하고, 여러 에이전트가 같은 맥락을 읽으면서 토큰도 많이 사용합니다. 작은 랜딩 페이지나 개인용 도구라면 회의하는 에이전트가 실제 사용자보다 많아지는 상황이 생길 수 있습니다. 역할을 전부 실행하기보다, 현재 부족한 관점 한두 개만 선택하는 편이 실용적입니다. #### 참고 링크 * [BMAD Method 공식 GitHub 저장소](https://github.com/bmad-code-org/BMAD-METHOD) * [BMAD Method 공식 문서](https://docs.bmad-method.org/) *** ## 디자인 도구 3가지 *이미지 출처: [요즘IT 원문](https://yozm.wishket.com/magazine/detail/3885/)* 기획 도구가 ‘무엇을 왜 만들지’를 정한다면 디자인 도구는 다음 세 가지를 해결합니다. 1. **기준 만들기** — DESIGN.md 2. **부품 조달하기** — shadcn/ui MCP 3. **출고 전 취향 검사하기** — taste-skill ### 4\. DESIGN\.md: 디자인 시스템을 AI가 읽는 파일로 만들기 *이미지 출처: [요즘IT 원문](https://yozm.wishket.com/magazine/detail/3885/)* #### 어떤 도구인가요? DESIGN.md는 시각적 정체성과 디자인 시스템을 코딩 에이전트가 지속적으로 이해할 수 있게 만드는 파일 형식입니다. Google Labs가 공개한 규격으로, 하나의 파일 안에 두 종류의 정보를 함께 담습니다. * **YAML 머리말**: 색상, 글꼴, 간격, 모서리 반경처럼 기계가 정확히 읽어야 하는 값 * **Markdown 본문**: 왜 이 값을 선택했는지, 어디에 사용하고 피해야 하는지에 대한 사람 중심 설명 AI에게 매번 “우리 브랜드의 주색은 진한 초록이고 버튼 모서리는 8px이야”라고 설명하는 대신, 프로젝트 루트의 DESIGN.md를 읽도록 하면 됩니다. #### 간단한 예시 ``` --- name: Forest Ledger colors: primary: "#1F5C46" secondary: "#DCEADF" accent: "#E7A93B" neutral: "#F7F8F5" typography: h1: fontFamily: Pretendard fontSize: 2.5rem body-md: fontFamily: Pretendard fontSize: 1rem spacing: section: 6rem rounded: card: 12px button: 8px --- ## Brand direction 차분하고 신뢰할 수 있는 재무 도구처럼 보여야 한다. 과도한 그라데이션과 네온 효과는 사용하지 않는다. ## Usage - primary는 주요 행동 버튼과 현재 선택 상태에만 사용한다. - accent는 경고가 아닌 강조에 제한적으로 사용한다. - 본문 한 줄 길이는 데스크톱에서 70자를 넘기지 않는다. ``` #### 무엇을 해결하나요? * 화면마다 색상과 간격이 달라지는 문제 * 새로운 대화에서 디자인 설명을 반복해야 하는 문제 * 디자이너의 의도와 개발 결과가 달라지는 문제 * 에이전트가 임의로 디자인 토큰을 만드는 문제 * 접근성 대비를 놓치는 문제 #### 바로 써볼 요청 예시 ``` 현재 프로젝트의 DESIGN.md를 먼저 읽고 대시보드 화면을 수정해줘. 새로운 색상·글꼴·간격 값은 임의로 만들지 말고 기존 토큰을 사용해줘. 필요한 토큰이 없다면 코드를 수정하기 전에 추가 후보와 이유를 제안해줘. 완료 후 사용한 토큰과 WCAG 대비 검사 결과를 정리해줘. ``` #### 장점 * AI와 사람이 같은 디자인 기준을 읽을 수 있습니다. * 구조 검사와 색상 대비 같은 일부 규칙을 CLI로 확인할 수 있습니다. * 변경 전후 디자인 토큰 차이를 비교할 수 있습니다. * 토큰을 Tailwind용 JSON·CSS나 표준 디자인 토큰 형식으로 내보낼 수 있습니다. #### 주의할 점 DESIGN.md 형식은 아직 활발히 발전 중이므로 스키마와 CLI가 바뀔 수 있습니다. 또한 파일이 검증할 수 있는 것은 색상 값, 토큰 참조, 대비처럼 구조화된 규칙입니다. 브랜드의 감정, 문화적 의미, 이미지 스타일의 섬세한 차이는 여전히 디자이너가 판단해야 합니다. 다른 브랜드의 DESIGN.md를 그대로 복사하면 일관성은 생길 수 있지만 정체성은 사라집니다. [getdesign.md](https://getdesign.md/)의 예시는 출발점으로만 참고하세요. #### 참고 링크 * [DESIGN.md 공식 GitHub 저장소](https://github.com/google-labs-code/design.md) * [DESIGN.md 규격 문서](https://github.com/google-labs-code/design.md/blob/main/docs/spec.md) * [DESIGN.md 예시 모음](https://getdesign.md/) *** ### 5\. shadcn/ui MCP: 에이전트에게 UI 부품 검색 맡기기 *이미지 출처: [요즘IT 원문](https://yozm.wishket.com/magazine/detail/3885/)* #### 어떤 도구인가요? shadcn/ui는 React와 Tailwind CSS 기반 프로젝트에서 사용할 수 있는 컴포넌트 코드 배포 방식입니다. 일반적인 패키지처럼 내부가 감춰진 채 의존하는 것이 아니라, 선택한 컴포넌트 코드가 프로젝트 안으로 들어오기 때문에 직접 수정하기 쉽습니다. MCP 서버를 연결하면 코딩 에이전트가 등록된 레지스트리에서 컴포넌트를 검색하고, 상세 정보를 확인하고, 프로젝트에 추가하는 명령을 가져올 수 있습니다. #### 쉽게 설명하면 * DESIGN.md가 **인테리어 규칙서**라면, * shadcn/ui MCP는 에이전트가 직접 방문하는 **가구·부품 창고**입니다. 사용자는 모든 컴포넌트의 이름을 알 필요가 없습니다. “검색 필터가 있는 데이터 테이블과 상세 정보 패널이 필요해”라고 말하면 에이전트가 적절한 부품을 찾아 조합할 수 있습니다. #### 이런 작업에 잘 맞습니다 * 관리자 페이지와 SaaS 대시보드 * 폼, 대화상자, 드롭다운, 테이블이 많은 제품 * 접근성과 상태 처리가 갖춰진 기본 컴포넌트가 필요한 프로젝트 * 여러 레지스트리의 사내·외부 컴포넌트를 에이전트가 찾아야 하는 환경 #### 바로 써볼 요청 예시 ``` shadcn/ui 레지스트리에서 고객 목록 화면에 적합한 데이터 테이블, 검색 입력창, 상태 필터, 페이지네이션, 고객 상세 Sheet 컴포넌트를 찾아줘. 설치하기 전에 후보와 필요한 의존성을 보여줘. 승인 후 현재 DESIGN.md 토큰을 적용해 조합하고, 키보드 탐색과 빈 상태·로딩·오류 상태까지 구현해줘. ``` #### 장점 * 컴포넌트 이름을 몰라도 자연어로 검색을 요청할 수 있습니다. * 코드가 프로젝트 안에 들어오므로 세부 수정이 가능합니다. * 에이전트가 레지스트리와 설치 명령을 직접 확인할 수 있습니다. * 기본적인 접근성과 상호작용 패턴을 갖춘 부품에서 시작할 수 있습니다. #### 주의할 점 shadcn/ui를 설치했다고 제품 디자인이 자동으로 완성되는 것은 아닙니다. 많은 프로젝트가 같은 기본 컴포넌트와 Tailwind 스타일을 사용하므로, 그대로 배치하면 익숙하지만 차별성 없는 화면이 될 수 있습니다. 반드시 다음을 별도로 정해야 합니다. * 정보의 우선순위와 화면 구조 * 브랜드 색상과 타이포그래피 * 모바일·키보드·스크린리더 사용 경험 * 로딩·오류·빈 상태 * 컴포넌트를 쓰지 않아야 할 상황 #### 참고 링크 * [shadcn/ui 공식 문서](https://ui.shadcn.com/docs) * [shadcn/ui MCP Server 안내](https://ui.shadcn.com/docs/mcp) * [shadcn/ui 컴포넌트 목록](https://ui.shadcn.com/docs/components) *** ### 6\. taste\-skill: 흔한 AI 디자인 패턴을 줄이기 *이미지 출처: [요즘IT 원문](https://yozm.wishket.com/magazine/detail/3885/)* #### 어떤 도구인가요? taste-skill은 AI 에이전트가 프론트엔드를 만들 때 자주 반복하는 무난하고 진부한 패턴을 줄이기 위한 디자인 스킬입니다. 새로운 디자인을 대신 만들어주는 도구라기보다, **시각적 방향을 수치로 정하고 피해야 할 패턴을 규칙으로 제한하는 검수 기준**에 가깝습니다. #### 디자인 방향을 숫자로 명시하기 ‘세련되게’, ‘감각적으로’, ‘힙하게’ 같은 말은 사람에게도 모호하고 AI에게는 더 모호합니다. taste-skill은 다음과 같은 축을 사용해 방향을 구체화합니다. | 축 | 낮은 값 | 높은 값 | | --- | ---- | ---- | | **Design Variance** | 대칭적이고 안정적인 구성 | 비대칭적이고 실험적인 구성 | | **Motion Intensity** | 정적인 화면 | 스크롤·전환 애니메이션이 적극적인 화면 | | **Visual Density** | 넓은 여백과 적은 정보 | 대시보드처럼 많은 정보를 밀도 있게 표시 | 예를 들어 기업용 재무 대시보드라면 `Variance 3 / Motion 2 / Density 8`, 크리에이터 포트폴리오라면 `Variance 8 / Motion 7 / Density 3`처럼 방향을 구분할 수 있습니다. #### 흔한 ‘AI 디자인’ 패턴 제한하기 * 모든 내용을 가운데 정렬한 히어로 섹션 * 같은 모양의 카드 세 개를 나란히 배치 * 이미지와 텍스트를 좌우로 번갈아 반복 * 필요 이상으로 많은 대문자 라벨과 마키 효과 * 보라색 네온 글로우를 이유 없이 사용 * 근거 없는 통계 수치와 가상의 사용자 이름 이러한 패턴이 무조건 나쁜 것은 아닙니다. 문제는 제품의 목적과 관계없이 자동 기본값처럼 반복될 때입니다. #### 바로 써볼 요청 예시 ``` 이 포트폴리오 랜딩 페이지를 개선해줘. Design Variance 7, Motion Intensity 4, Visual Density 3을 기준으로 사용해줘. 가운데 정렬 히어로, 동일 카드 3개 반복, 보라색 네온 그라데이션은 사용하지 마. 프로젝트 과정과 판단 근거가 결과 이미지보다 먼저 이해되게 정보 구조를 바꿔줘. 수정 전에 현재 화면에서 AI가 만든 것처럼 보이는 패턴을 먼저 지적해줘. ``` #### 이런 사람에게 좋습니다 * AI가 만든 랜딩 페이지가 모두 비슷해 보이는 사람 * 포트폴리오처럼 첫인상이 중요한 화면을 만드는 사람 * 디자인 피드백을 감상이 아닌 규칙으로 전달하고 싶은 사람 * 코딩 에이전트에 최소한의 아트디렉션을 주고 싶은 사람 #### 장점 * 추상적인 취향을 비교 가능한 값과 규칙으로 바꿉니다. * 반복되는 AI 기본 패턴을 사전에 줄일 수 있습니다. * Codex, Cursor, Claude Code 등 여러 에이전트에서 활용할 수 있습니다. * 기존 화면을 검토하는 디자인 리뷰 체크리스트로도 쓸 수 있습니다. #### 주의할 점 taste-skill의 금지 목록 역시 제작자의 취향을 반영합니다. 브랜드가 고전적인 세리프 글꼴을 사용하거나 대칭적인 구성이 중요한 경우에는 기본 규칙이 오히려 방해가 될 수 있습니다. 스킬을 절대 규칙으로 사용하지 말고, 프로젝트에 맞지 않는 항목은 제거하거나 수정하세요. 색상과 간격 값만 바꾸려는 간단한 작업이라면 DESIGN.md만으로 충분할 수 있습니다. #### 참고 링크 * [taste-skill 공식 홈페이지](https://www.tasteskill.dev/) *** ## 프로젝트별 추천 조합 ### 1\. 작은 랜딩 페이지·포트폴리오 **추천:** Superpowers + 간단한 DESIGN.md + taste-skill * Superpowers로 대상 사용자와 핵심 메시지를 질문합니다. * DESIGN.md에 색상, 글꼴, 간격과 이미지 방향만 정리합니다. * taste-skill로 흔한 AI 랜딩 페이지 패턴을 줄입니다. Spec Kit과 BMAD 전체 흐름은 문서가 지나치게 많아질 수 있습니다. ### 2\. 신규 SaaS·관리자 서비스 **추천:** GitHub Spec Kit + DESIGN.md + shadcn/ui MCP * Spec Kit으로 프로젝트 원칙과 기능 범위를 고정합니다. * DESIGN.md로 대시보드의 정보 밀도와 토큰을 정의합니다. * shadcn/ui MCP로 테이블, 폼, 대화상자 같은 검증된 부품을 조달합니다. taste-skill은 기본 화면이 완성된 뒤 시각적 개성이 부족할 때 추가합니다. ### 3\. 이해관계자가 많은 복잡한 제품 **추천:** BMAD의 필요한 역할 + Spec Kit 일부 + DESIGN.md * BMAD에서 분석가, PM, 보안, 아키텍트처럼 필요한 역할만 선택합니다. * 합의된 결과를 Spec Kit의 constitution과 spec에 옮깁니다. * DESIGN.md로 팀 전체의 디자인 기준을 한 파일에 고정합니다. 두 방법론의 전체 명령을 동시에 사용하면 문서와 용어가 충돌할 수 있으므로, 어느 도구를 중심으로 쓸지 먼저 정해야 합니다. ### 4\. 운영 중인 프로젝트에 작은 기능 추가 **추천:** Superpowers의 질문 단계 또는 OpenSpec + 기존 디자인 시스템 * 현재 코드와 사용자의 영향 범위를 먼저 확인합니다. * 필요한 스펙만 가볍게 작성합니다. * 새로운 디자인 규칙을 추가하기보다 기존 토큰과 컴포넌트를 우선 사용합니다. *** ## 실전 작업 흐름 6가지 도구를 활용하더라도 최종 작업 흐름은 복잡할 필요가 없습니다. ### 1단계: 사용자와 문제 정의 ``` 누가 이 제품을 사용하나요? 그 사람이 현재 가장 불편한 순간은 언제인가요? 기존 해결 방법은 무엇이며 왜 충분하지 않나요? ``` Superpowers의 질문 방식이나 BMAD의 분석가 역할을 활용할 수 있습니다. ### 2단계: 기능 범위와 성공 기준 작성 ``` 첫 번째 버전에서 반드시 해결해야 할 한 가지 문제는 무엇인가요? 포함할 기능과 제외할 기능은 무엇인가요? 어떤 상태가 되면 기능이 완료되었다고 판단하나요? ``` Spec Kit 또는 가벼운 OpenSpec으로 문서를 남깁니다. ### 3단계: 디자인 원칙 고정 DESIGN.md에 최소한 다음을 적습니다. * 주색·보조색·배경색·텍스트 색상 * 제목과 본문 글꼴·크기 * 간격과 모서리 반경 * 페이지 정보 밀도 * 이미지·아이콘 스타일 * 사용하지 않을 시각적 패턴 * 접근성 기준 ### 4단계: 컴포넌트 선택과 구현 shadcn/ui MCP 등으로 필요한 부품을 찾되, 설치 전에 다음을 확인합니다. * 프로젝트 기술과 호환되는가? * 접근성과 키보드 조작을 지원하는가? * 불필요한 의존성이 추가되지 않는가? * 기존 디자인 토큰을 적용할 수 있는가? ### 5단계: 사용자 시나리오로 검증 ``` 신규 사용자가 도움말 없이 첫 작업을 완료할 수 있는가? 모바일 화면에서도 핵심 행동이 보이는가? 로딩·오류·빈 상태에서 다음 행동을 알 수 있는가? 시각적 강조가 실제 중요도와 일치하는가? ``` taste-skill의 규칙과 사람이 직접 사용하는 테스트를 함께 적용합니다. ### 6단계: 문서와 결과 동기화 구현하면서 바뀐 결정은 스펙과 DESIGN.md에도 반영합니다. 문서와 코드가 다르면 다음 작업에서 에이전트가 오래된 문서를 믿고 잘못 수정할 수 있습니다. *** ## 도입 전 체크리스트 ### 도구 선택 * 현재 문제를 한 문장으로 설명할 수 있는가? * 질문, 문서화, 역할 확장, 디자인 기준, 부품 검색, 시각 검수 중 무엇이 필요한가? * 기존 프로젝트에 이미 비슷한 규칙과 문서가 있지 않은가? * 도구가 만드는 문서를 실제로 읽고 관리할 사람이 있는가? * 작업 규모에 비해 방법론이 지나치게 무겁지 않은가? ### 설치와 보안 * 공식 저장소와 최신 설치 안내를 확인했는가? * 플러그인·스킬의 코드를 신뢰할 수 있는가? * 설치 전 Git 브랜치 또는 백업을 만들었는가? * 에이전트가 접근할 파일과 실행할 명령의 범위를 제한했는가? * 회사 프로젝트에서 외부 스킬과 MCP 사용이 허용되는가? ### 기획 검증 * 대상 사용자가 구체적으로 정의되어 있는가? * 해결할 문제와 만들고 싶은 기능을 구분했는가? * 에이전트가 임의로 세운 가정을 따로 표시했는가? * 포함 범위와 제외 범위가 모두 적혀 있는가? * 측정 가능한 완료 기준과 성공 지표가 있는가? ### 디자인 검증 * 디자인 토큰이 실제 코드 값과 연결되는가? * 모바일·키보드·스크린리더 사용을 확인했는가? * 로딩·오류·빈 상태가 설계되어 있는가? * 다른 서비스의 디자인을 그대로 복제하지 않았는가? * ‘AI 티’를 없애는 것보다 사용 목적과 정보 우선순위를 먼저 확인했는가? *** ## 자주 생기는 실패와 해결법 | 증상 | 가능한 원인 | 해결 방법 | | --- | ------ | ----- | | 질문만 계속하고 구현이 시작되지 않는다 | Superpowers·BMAD 절차가 작업보다 무거움 | 작은 작업임을 명시하고 필요한 단계만 사용 | | 비슷한 문서가 여러 개 생긴다 | Spec Kit·BMAD·OpenSpec을 동시에 중심 도구로 사용 | 하나를 기준 문서로 정하고 나머지는 보조로 제한 | | 화면은 일관되지만 개성이 없다 | DESIGN.md에 값만 있고 이유와 이미지 방향이 없음 | 브랜드 근거, 사용 맥락, 금지 패턴 추가 | | shadcn/ui 느낌이 너무 강하다 | 기본 컴포넌트를 수정 없이 배치 | 정보 구조와 토큰을 먼저 정하고 컴포넌트 변형 | | taste-skill 결과가 브랜드와 충돌한다 | 기본 금지 규칙을 절대 기준으로 사용 | 브랜드에 맞지 않는 규칙을 제거·수정 | | 토큰 비용과 작업 시간이 급증한다 | 역할·서브에이전트·리뷰가 과도함 | 고위험 결정에만 깊은 절차 적용 | | 문서와 실제 화면이 다르다 | 구현 후 스펙·DESIGN.md를 갱신하지 않음 | 작업 완료 조건에 문서 동기화 포함 | *** ## 마무리 AI 코딩 에이전트는 구현 속도를 크게 높여주지만, 무엇을 만들지와 어떤 모습이어야 하는지를 대신 책임져주지는 않습니다. 기획과 디자인 도구는 정답을 만들어주는 마법이 아니라 **사람이 더 좋은 질문을 하고, 결정 이유를 남기고, 결과를 검증하도록 돕는 발판**입니다. 막연한 아이디어를 대화로 풀고 싶다면 Superpowers, 문서의 뼈대가 필요하면 GitHub Spec Kit, 여러 직무의 관점이 필요하면 BMAD Method가 적합합니다. 화면의 일관성은 DESIGN.md, UI 부품 조달은 shadcn/ui MCP, 흔한 AI 디자인 패턴을 줄이는 일은 taste-skill이 도울 수 있습니다. 그러나 6개를 모두 설치한다고 제품이 여섯 배 좋아지는 것은 아닙니다. 도구가 겹치면 지시와 문서가 충돌하고 사람이 검토할 양만 늘어날 수 있습니다. 지금 프로젝트가 막힌 지점 하나를 고르고, 가장 작은 도구 하나부터 적용해보세요. 마지막 판단 기준은 언제나 같습니다. > **누가 이 제품을 사용하며, 그 사람은 왜 이 제품을 계속 사용해야 하는가?** 이 질문에 답하지 못한다면 아무리 빠른 에이전트와 정교한 디자인 도구도 쓸 만한 제품을 대신 만들어주기는 어렵습니다. *** ## 참고 자료 * [요즘IT — AI 에이전트와 함께 쓰는 기획/디자인 도구 6가지](https://yozm.wishket.com/magazine/detail/3885/) * [Superpowers 공식 GitHub 저장소](https://github.com/obra/superpowers) * [GitHub Spec Kit 공식 저장소](https://github.com/github/spec-kit) * [OpenSpec 공식 저장소](https://github.com/Fission-AI/OpenSpec) * [BMAD Method 공식 GitHub 저장소](https://github.com/bmad-code-org/BMAD-METHOD) * [DESIGN.md 공식 GitHub 저장소](https://github.com/google-labs-code/design.md) * [DESIGN.md 예시 모음](https://getdesign.md/) * [shadcn/ui MCP Server 공식 문서](https://ui.shadcn.com/docs/mcp) * [taste-skill 공식 홈페이지](https://www.tasteskill.dev/)

콘텐츠를 불러오는 중..