아이디어를 코드로 옮기는 속도는 확실히 빨라졌습니다. AI 에이전트에게 만들 것을 설명하면 화면이 나오고 버튼도 눌립니다. 그런데 시간을 잡아먹는 곳은 그 앞단입니다. 무엇을 만들지, 누구에게 필요한지, 어느 정도면 끝난 것인지가 흐릿하면 에이전트는 빈칸을 자기 방식으로 채웁니다.

코드는 틀리면 오류가 납니다. 기획과 디자인은 그렇지 않습니다. 그럴듯하게 작동하면서 방향만 어긋난 결과가 계속 쌓일 수 있습니다. 나중에 문제를 발견해도 어느 판단에서 틀어졌는지 되짚을 문서가 없으면 처음부터 다시 설명해야 합니다.

이 글에서 다루는 여섯 가지는 일반적인 SaaS 목록이 아닙니다. 코딩 에이전트가 일을 시작하기 전에 질문을 던지게 하거나, 판단을 문서에 남기거나, 화면의 기준과 부품을 공유하는 방법론·스펙·연결 도구입니다. 공식 저장소와 문서를 기준으로 역할이 겹치지 않게 골랐습니다. 직접 사용 성능을 순위로 매긴 글은 아닙니다.

거인의 어깨에 올라타되, 전부 짊어질 필요는 없다

사용자 인터뷰, 요구사항 문서, 디자인 시스템, 테스트 절차는 누군가 오래 시행착오를 겪으며 다듬은 결과입니다. AI 에이전트가 이 지식을 읽고 따를 수 있게 만든 도구가 늘어난 것은 반가운 일입니다. 다만 여섯 개를 모두 설치하면 더 좋은 결과가 나오는 것은 아닙니다.

역할은 크게 세 층으로 나뉩니다.

필요한 것 도구 남기는 결과
모호한 생각을 질문과 계획으로 바꾸기 Superpowers, Spec Kit, BMAD 설계안, 요구사항, 실행 순서, 검토 지점
화면의 정체성과 금지선을 공유하기 DESIGN.md, taste-skill 색·타이포·간격·밀도·피해야 할 패턴
검증된 UI 부품을 실제 프로젝트로 가져오기 shadcn/ui MCP 검색하고 설치할 수 있는 컴포넌트 코드

처음에는 기획 도구 하나와 디자인 도구 하나면 충분합니다. 프로젝트가 커졌을 때만 역할과 문서를 늘리는 편이 낫습니다.

생각을 문서로 끌어내는 기획 도구 3가지

1. Superpowers: 에이전트가 먼저 묻게 만든다

Superpowers는 프롬프트 모음이라기보다 개발 절차를 스킬로 묶은 방법론에 가깝습니다. 공식 흐름은 brainstorming으로 요구를 좁히고, 별도 worktree에서 계획을 세우며, 작업을 나눈 뒤 테스트와 리뷰를 거쳐 마무리하는 순서입니다.

좋은 점은 “다크 모드도 넣어줘” 같은 한 문장이 곧바로 코드 변경으로 이어지지 않는다는 데 있습니다. 누구를 위한 기능인지, 기존 화면과 무엇이 달라지는지, 완료 조건은 무엇인지 먼저 묻게 할 수 있습니다. 아이디어만 있고 문서가 없는 사람에게 특히 유용합니다.

반대로 작은 오타 하나를 고치는데도 전체 절차를 다 돌리면 과합니다. 하위 에이전트를 여러 개 쓰는 흐름은 토큰과 검토 시간을 늘립니다. 설계가 필요한 변경과 단순 수정의 경계를 먼저 정해야 합니다.

Superpowers 공식 GitHub 저장소 화면

Superpowers는 질문, 계획, 테스트, 리뷰를 하나의 작업 습관으로 묶습니다. 화면은 공식 GitHub 저장소입니다.

2. GitHub Spec Kit: 기획을 추적 가능한 문서로 남긴다

Spec Kit은 spec-driven development를 위한 도구입니다. 핵심 흐름은 Specify, Plan, Tasks, Implement입니다. 필요하면 그 앞에 Constitution을 두어 프로젝트 원칙을 정하고, Clarify·Checklist·Analyze 같은 단계를 끼워 넣을 수 있습니다. 흔히 “무조건 다섯 단계”라고 설명하지만, 공식 문서는 고정 절차보다 필요한 검증을 조합하는 쪽에 가깝습니다.

이 도구의 가치는 문서가 남는다는 데 있습니다. 요구가 바뀌었을 때 코드만 비교하는 대신, 어느 요구사항과 작업 목록이 함께 바뀌어야 하는지 확인할 수 있습니다. 새 프로젝트를 여러 사람이 이어서 만들거나, 결정 근거를 나중에 설명해야 할 때 맞습니다.

이미 큰 코드베이스에 작은 기능 하나를 붙이는 일에는 부담이 될 수 있습니다. 문서를 관리하는 일이 구현보다 커지면 목적이 뒤집힙니다. 그런 상황에서는 같은 계열의 가벼운 도구인 OpenSpec처럼 범위를 좁히는 편이 나을 수 있습니다.

GitHub Spec Kit 공식 저장소 화면

Spec Kit은 요구사항과 계획, 작업 목록을 분리해 변경 경로를 남깁니다. 화면은 GitHub 공식 저장소입니다.

3. BMAD Method: 혼자 하던 기획에 역할을 붙인다

BMAD Method는 분석가, PM, 아키텍트, 개발, QA 같은 역할을 AI 에이전트로 나눕니다. 공식 방법론은 선택적인 Analysis, Planning, Solutioning, Implementation 단계로 구성되고, 작은 작업에는 Quick Flow를 따로 둡니다.

혼자 기획할 때는 내가 모르는 질문이 끝까지 나오지 않는 경우가 많습니다. 역할을 나누면 분석가는 문제와 사용자를 묻고, PM은 범위와 완료 조건을, 아키텍트는 기술 제약을, QA는 실패 조건을 확인합니다. 복잡한 제품이나 여러 이해관계가 얽힌 프로젝트에서는 이 역할 전환이 도움이 됩니다.

부담도 분명합니다. 여러 에이전트가 같은 문서를 다시 읽으며 토큰을 쓰고, 산출물이 제품보다 많아지는 순간이 올 수 있습니다. 설치 명령이 간단하다는 사실과 운영이 가볍다는 말은 다릅니다. 작은 변경이라면 Quick Flow나 더 단순한 도구를 쓰는 편이 낫습니다.

BMAD Method 공식 GitHub 저장소 화면

BMAD는 제품 개발의 서로 다른 관점을 에이전트 역할로 나눕니다. 화면은 공식 GitHub 저장소입니다.

화면의 기준과 부품을 맡는 디자인 도구 3가지

기획이 “무엇을 왜 만들지”를 붙잡는다면 디자인은 “어떤 결과가 우리 것처럼 보여야 하는지”를 붙잡습니다. AI에게 화면을 맡겼을 때 결과가 비슷해지는 이유는 모델이 무능해서만은 아닙니다. 색, 글꼴, 밀도, 접근성, 금지 패턴을 건네지 않았기 때문인 경우가 많습니다.

4. DESIGN.md: 디자인 시스템을 에이전트가 읽는 한 장으로

Google Labs의 DESIGN.md는 디자인 정체성을 에이전트가 읽을 수 있는 파일로 남기려는 alpha 프로젝트입니다. YAML frontmatter에는 색, 타이포, 간격 같은 구조화된 값을 넣고, Markdown 본문에는 왜 그런 선택을 했는지와 사용하면 안 되는 맥락을 적습니다.

이 방식의 장점은 규칙을 매번 다시 설명하지 않아도 된다는 점입니다. 새 화면을 만들 때 에이전트가 같은 토큰과 원칙을 읽을 수 있습니다. 그러나 파일 형식이 디자인 감각을 대신하지는 않습니다. 어떤 분위기와 대비가 맞는지는 여전히 사람이 정해야 하고, alpha 단계라 스키마와 도구가 바뀔 수 있습니다.

Google Labs DESIGN.md 공식 저장소 화면

DESIGN.md는 시각적 선택과 그 근거를 에이전트가 다시 읽을 수 있는 파일로 만듭니다. 화면은 Google Labs 공식 저장소입니다.

5. shadcn/ui MCP: 없는 부품을 상상하지 않고 찾아온다

shadcn/ui MCP Server는 AI 에이전트가 registry를 둘러보고, 필요한 컴포넌트를 검색해 프로젝트에 설치하도록 연결합니다. “로그인 폼을 만들어라”라고만 말하는 대신, 어느 registry에서 어떤 부품을 가져올지 지정할 수 있습니다.

여기서 얻는 것은 취향이 아니라 공급 경로입니다. 접근성이나 상태 처리가 이미 고려된 부품을 가져와 코드를 직접 소유하고 고칠 수 있습니다. 반면 기본 컴포넌트를 그대로 조립하면 다른 사이트와 비슷해 보이기 쉽습니다. shadcn/ui가 ‘AI가 만든 티’를 없애 주는 것이 아니라, DESIGN.md 같은 기준을 실제 부품에 적용할 시간을 벌어 주는 셈입니다.

shadcn/ui MCP 공식 문서 화면

MCP Server는 registry 검색과 컴포넌트 설치를 에이전트가 수행하게 합니다. 화면은 shadcn/ui 공식 문서입니다.

6. taste-skill: 만들기 전에 금지선을 긋는다

taste-skill은 AI 코딩 에이전트가 흔히 만드는 밋밋한 화면을 줄이기 위한 프론트엔드 지침 모음입니다. 무조건 가운데 정렬, 같은 카드 반복, 근거 없는 거대한 문구, 비슷한 색과 간격 같은 패턴을 피하도록 지시합니다. 화면의 밀도나 움직임 강도처럼 취향으로 넘기기 쉬운 값을 명시하자는 접근도 들어 있습니다.

장점은 결과가 나온 뒤 “뭔가 촌스럽다”고 고치는 대신, 만들기 전에 피해야 할 패턴을 공유한다는 것입니다. 다만 현재 v2는 실험 버전이고, 금지 목록에는 저자의 취향도 섞입니다. 브랜드가 serif를 쓰는 데 이유가 있다면 기본 금지 규칙을 지워야 합니다. 빠른 테마 교체만 원하는 일에도 지나친 도구입니다.

taste-skill 공식 GitHub 저장소 화면

taste-skill은 완성된 화면을 평가하는 도구라기보다, 에이전트가 피해야 할 선택을 미리 적어 두는 지침입니다.

여섯 개 가운데 무엇을 같이 쓰면 될까

제가 이 도구들을 도입안에 넣는다면 아래처럼 시작하겠습니다.

상황 먼저 고를 조합 이유
아이디어만 있고 문서가 없음 Superpowers + DESIGN.md 질문으로 범위를 좁히고 최소한의 시각 기준을 남길 수 있음
새 제품을 팀이 함께 시작 Spec Kit + DESIGN.md + shadcn/ui MCP 요구·계획·작업과 디자인 규칙, 구현 부품의 경로가 이어짐
역할과 검토가 많은 복잡한 제품 BMAD + DESIGN.md, 마지막에 taste-skill 여러 관점을 먼저 드러내고 시각적 일관성과 금지 패턴을 확인
기존 제품에 기능 하나 추가 기획 도구 하나 + 기존 디자인 시스템 전체 방법론을 다시 얹지 않고 변경 근거만 남김

조합이 늘수록 문서 사이의 충돌도 늘어납니다. Spec Kit의 constitution과 BMAD의 계획 문서, Superpowers의 설계안이 서로 다른 말을 하면 에이전트는 어느 쪽이 최신인지 알기 어렵습니다. 원칙 문서는 하나, 실행 절차도 하나로 두는 편이 안전합니다.

설치하기 전에 확인할 네 가지

  1. 지금 부족한 것이 질문인지, 기록인지, 부품인지 구분합니다. 질문이 부족한데 MCP부터 붙이면 빠르게 엉뚱한 화면이 나옵니다.
  2. 산출물의 주인을 정합니다. Constitution, DESIGN.md, 작업 목록 중 어느 파일이 최종 기준인지 적어 둡니다.
  3. 작은 변경 하나로 시험합니다. 홈 전체가 아니라 가입 폼 한 화면처럼 되돌리기 쉬운 범위가 좋습니다.
  4. 토큰보다 검토 문서량을 셉니다. 문서가 늘면서 사람이 읽어야 할 시간이 줄지 않는다면 자동화가 아닙니다.

기획과 디자인을 신경 쓰지 않은 상태에서 AI 에이전트만 붙이면 결과는 나오지만, 실제로 쓰는 사람에게 맞을 가능성은 낮습니다. 여섯 도구가 대신 결정해 주는 것도 아닙니다. 다만 머릿속에만 있던 판단을 질문, 문서, 규칙, 부품으로 나눠 에이전트와 함께 검토할 수 있게 해 줍니다.

결국 출발점은 도구가 아니라 사람입니다. 누가 이 결과를 쓰는지, 왜 필요한지, 어디에서 실패하면 안 되는지를 먼저 적을 수 있다면 AI 에이전트는 훨씬 덜 헤맵니다. 그 세 문장이 없다면 도구 여섯 개를 깔아도 빈칸만 더 정교하게 채울 뿐입니다.

참고한 자료