AI 에이전트와 함께 쓰는 기획/디자인 도구 6가지

아이디어 하나를 코드로 옮기는 속도는 이제 정말 빠릅니다. AI에 말로 잘 설명하면 화면이 나오고 버튼이 눌리죠. (물론 완성도는 미뤄두고요) 그런데 정작 오래 걸리는 건 그 앞 단계입니다.

무엇을 만들지 정하는 일, 그리고 그 무언가가 어떻게 생겨야 하는지 정하는 일. 이 과정을 우리는 흔히 기획과 디자인이라고 합니다. 그 작업은 꽤 어렵습니다. 코드는 틀리면 에러가 뜨지만, 기획과 디자인에는 정답 파일이 없죠. 그래서 더 힘겹습니다.

다행히 IT에서 무언가를 만들어 온 수많은 사람들이 같은 시행착오를 겪었습니다. 그리고 그 경험을 모아 이미 방법론으로 정리해뒀습니다. 게다가 최근 1년 사이, 그 방법론을 AI가 곧바로 읽고 실행하는 형태로 포장해 배포하는 도구까지 쏟아졌죠. 그중 요즘 실제로 자주 쓰이는 것들을, 접근법이 겹치지 않게 6개 정도 골랐습니다. 한번 소개해 볼게요.

아참, 이 도구들은 모두 AI 도구, 특히 클로드 코드나 코덱스 같은 코딩 에이전트를 적극적으로 쓰고 있다는 가정 하에 추천합니다.

거인의 어깨에 올라타기

여러분이 기획자나 디자이너라면, 필요한 단계마다 경험과 직관을 발휘해 바로바로 문제를 지적하고 개선해 나갈 수도 있습니다. 그러니 익숙한 영역은 바닥부터 시작해도 됩니다. AI와 함께 내 방식대로 만들어도 좋습니다. 문제는 아무것도 모르는 상태에서 바닥부터 하는 경우입니다.

고객들은 그런 사정을 알아주지 않습니다. 이 제품을 개발자가 만들었다고, 기획이 허술한 걸 봐줄 리가 없습니다. 기획자가 만들었으니 디자인 정도 좀 놓쳐도 괜찮아, 하는 사람도 없을 겁니다. 그렇다고 모조리 다 남들만큼 잘하라는 건 가혹합니다.

그래서 거인의 어깨에 올라타야 합니다.

기획과 디자인을 잘하기 위한 고민은 지금까지 셀 수 없이 많았습니다. 사용자 인터뷰, 요구사항 문서, 디자인 시스템 같은 것들은 전부 남이 오래 고생해 정리한 결과물이죠. 이런 방법론과 도구를 잘만 사용하면 꽤 그럴듯한 결과물을 필요에 맞게 뽑아낼 수 있습니다.

그 방법론이 AI를 위한 도구로 포장돼 배포되기 시작한 건 최근 1년 사이의 일입니다. 2025년 8월 GitHub Spec Kit, 10월 Superpowers가 차례로 나왔고, 2026년 4월에는 구글이 DESIGN.md 스펙을 공개했죠. 형태도 대부분 가볍습니다. 슬래시 명령 한 줄이거나, 프로젝트 폴더에 마크다운 파일 한 장을 두는 정도예요. 그러니 이 작업에 익숙하지 않다면 남이 쌓아온 지식을 빌리는 편이 훨씬 빠릅니다.

아이디어를 현실로 끌어내리는 기획 도구 3가지

기획이 어려운 이유는 대개 비슷합니다. 머릿속에는 만들 것이 있는데 그게 문서가 아니라 아이디어 상태로만 있다는 거죠. 이걸 에이전트에 적당한 말로 던지면 에이전트는 말하지 않은 부분을 알아서 가정하고 코드로 만들어버립니다.

그렇게 나온 결과가 점점 쌓이고 커지다 의도와 완전히 어긋나버리면, 어디서부터 어긋난 건지 되짚을 기준조차 없습니다. 기준이 될 문서가 없으니까요.

그래서 기획을 위한 도구들은 그 문서를 꼼꼼히 만드는 데 도움을 줍니다. 3가지 도구를 준비했습니다.

• Superpowers는 기초를 닦습니다. 에이전트가 코드부터 쓰기 보다는 사용자에게 질문을 던져 스펙을 뽑아내게 만듭니다.
• Spec Kit은 뼈대를 세웁니다. 어느 정도 기본 계획이 있는 기획을 정해진 단계별 문서로 굳혀, 다음 사람도 같은 순서를 밟게 만듭니다.
• BMAD는 관점을 늘립니다. 문서를 다루는 에이전트를 여러 역할로 나눠, 혼자서는 놓치는 각도를 보게 만듭니다.

결국 기획은 두루뭉술한 말과 생각을 문서로 바꾸는 일이 먼저고(입구), 그 문서를 남이 읽을 수 있는 형태로 남기는 일이 그다음이고(뼈대), 관점이 더 필요할 때 역할을 늘리는 게 마지막(관점 확장)입니다. 다만, 하나하나 꽤 피곤한 일이기도 하고, 구조도 조금은 달라서 셋을 다 깔 필요는 없습니다. 지금 내 기획이 막힌 지점이 어디냐에 따라 하나만 고르면 됩니다.

1. Superpowers: 코딩 에이전트가 “먼저 물어보게” 만드는 스킬 팩

코딩 에이전트에 얹는 플러그인이자 스킬 팩입니다. 여기서 스킬 팩은 “이런 상황에서는 이렇게 일해라”를 적어둔 지시문 모음이고요. 2025년 10월 공개된 무료 MIT 라이선스 도구입니다.

무엇을 해주나

코드를 쓰기 전에 에이전트를 멈춰 세웁니다. 코드 요청을 받으면 바로 쓰지 않고 질문부터 던져 스펙을 뽑도록요. 그래서 이 도구가 만들어주는 건 깊이 있는 대화입니다. “다크모드 넣어줘”라고 말했을 때 곧바로 파일이 바뀌는 대신, 어디까지가 다크모드인지 되묻도록 만드는 겁니다.

어떻게 흘러가나

크게 네 단계입니다. 거친 아이디어를 질문으로 다듬고, 대안을 저울질한 결과를 설계 문서로 저장합니다. 승인이 나면 일을 2~5분짜리 태스크로 잘게 쪼갭니다. 태스크마다 건드릴 파일 경로와 검증 절차를 붙여 서브에이전트에 하나씩 넘기고요. 결과는 리뷰하며, 테스트도 강제합니다. 이 절차는 따로 부르지 않아도 상황에 맞게 알아서 발동해요.

누가 쓰면 좋나

만들 것이 말로만 있고 문서가 하나도 없는 사람. 그리고 에이전트가 알아서 코딩해버려 결과가 의도와 계속 어긋나는 사람입니다.

이럴 땐 부담이 됩니다

• 오타 하나 고치는 일에까지 절차가 붙으면 방해가 됩니다. 따라서 깊은 설계가 필요할 때만 불러야 합니다.
• 서브에이전트를 여러 개 띄우니 토큰, 즉 AI가 읽고 쓰는 글자값을 많이 씁니다.

2. GitHub Spec Kit: 기획을 다섯 단계 문서로

GitHub이 직접 낸 툴킷입니다. 코딩 전에 “무엇을 왜 만드는지”를 문서로 먼저 확정하는 스펙 주도 방식을 구현해 둔 형태로, 그 과정을 슬래시 커맨드 다섯 단계로 만들어줍니다. 2025년 9월 공개, 무료 MIT입니다.

앞의 Superpowers가 질문을 던지는 데 집중한다면, 이쪽은 그 답을 어디에 어떤 순서로 적을지 정해줍니다. 기획이 처음인 사람에게 실제로 어려운 건 “무엇을 만들까”를 생각하는 일보다, 그 생각을 어떤 문서로 어디까지 적어야 충분한지 판단하는 일이거든요. Spec Kit은 그 판단을 대신해 줍니다.

어떻게 흘러가나

핵심은 다섯 단계(constitution, specify, plan, tasks, implement). 여기에 필요하면 검증용 명령을 끼워 넣을 수 있습니다. 각 단계마다 문서 하나씩을 남기니, 나중에 결과가 이상할 때 어느 단계에서 어긋났는지 되짚을 수 있습니다.

다른 도구와 다른 지점

가장 중요한 건 첫 단계입니다. 프로젝트의 원칙, 그러니까 constitution을 먼저 세우는 게 차별점입니다. “이 프로젝트에서 지킬 것”을 미리 정하고 그다음 기능을 얹는 순서입니다. 게다가 스펙에는 기술 스택을 빼고 무엇을, 그리고 왜만 담게 합니다. 어떻게 만들지를 일부러 뒤로 미루는 셈이죠. 비개발자에게는 이 제약이 오히려 편합니다. 모르는 걸 안 적어도 되니까요.

누가 쓰면 좋나

빈 폴더에서 새로 시작하는 사람. 기획을 단계로 쪼개 눈으로 확인하고 싶은 사람. 팀이나 조직에 같은 절차를 깔아야 하는 사람입니다.

이럴 땐 부담이 됩니다

• 이미 큰 코드베이스에 기능을 조금씩 얹는 데는 약하다는 지적이 있습니다.
• 반대로 작은 작업에서는 리뷰할 문서가 코드로 만드는 것보다 많아집니다. 큰 작업에나 적합합니다.

3. BMAD Method: 기획을 혼자 말고 ‘팀’에게 시키기

“코딩 어시스턴트는 구현은 잘하지만, 말하지 않은 가정을 그대로 코드로 만들어버린다.”는 문제를 푼다고 스스로 소개합니다. 앞의 둘이 문서를 만들어준다면, 이쪽은 문서를 만드는 사람들을 통째로 만들어줍니다. 정식 이름은 Breakthrough Method for Agile AI Driven Development. 무료 MIT입니다.

이 도구는 애자일 팀의 역할을 에이전트로 나눠, 애자일 방법론을 쉽게 따르게 합니다. 분석가, PM, 아키텍트, 개발, QA 같은 역할이 각자 관점을 갖고 서로에게 일을 넘깁니다.

혼자 기획하면 내가 모르는 질문은 끝까지 안 나옵니다. 역할을 나누는 이유가 그겁니다. 아키텍트 역할이 붙으면 기술 결정의 근거를 묻고 PM 역할이 붙으면 완료 기준을 묻죠. 사람이 그 질문을 떠올리지 못해도 절차가 떠올려줍니다.

어떻게 흘러가나

네 단계 루프입니다. Clarify에서 막연한 아이디어를 질문으로 명확하게 만들고 Plan에서 PM·아키텍트가 PRD와 아키텍처 문서를 뽑습니다. Build and verify에서는 또 다른 에이전트가 PRD를 에픽과 스토리로 쪼개고 작은 단위로 구현·검증하고요. Learn and adjust에서 결과를 다시 Plan에 더합니다.

어떻게 쓰나

npx bmad-method install 명령어로 코딩에이전트에 설치합니다. 간단하죠. 계획 단계는 웹에서도 돌릴 수 있습니다. 구글 Gemini Gems나 ChatGPT 커스텀 GPT로 패키징된 번들로 계획만 세우고 구현은 IDE에서 잇는 방식입니다. 프로젝트 규모에 맞춰 절차를 조정하니, 작은 변경은 계획을 건너뛰고 바로 구현으로 보낼 수도 있습니다.

이럴 땐 부담이 됩니다

• 여러 종의 에이전트 역할과 인계 순서, CLI 명령, YAML 설정을 익혀야 합니다. 익숙해지는 데 꽤 걸리겠죠.
• 토큰을 많이 씁니다. 맥락을 유지하려고 주요 문서를 다시 이해해야 하는 구조기 때문입니다.
• 당연히 작은 프로젝트에는 과합니다. 만들 문서가 만들 제품보다 커지는 순간이 옵니다.

보기 좋고 쓰기 좋게 해주는 디자인 도구 3가지

디자인에서 막막한 부분은 기획과 다릅니다. 여기서는 결과물이 아예 안 나오는 게 아니라, 나오긴 나오는데 어딘가 이상해 보이는 게 문제입니다. AI에 화면을 맡기면 대체로 그럴듯한 게 나옵니다. 문제는 그 ‘그럴듯함’이 전부 비슷하다는 거죠. 기준을 주지 않으면 AI는 가장 무난한 기본값을 꺼내고 모두가 같은 기본값을 쓰니 결과가 거기서 거기입니다.

그래서 디자인 쪽 도구들은 레퍼런스를 주거나 차이를 만드는 데 집중합니다.

• DESIGN.md로는 기준을 만듭니다. 색·글꼴·간격을 AI가 읽을 수 있는 파일 한 장으로 입력해, 결과에 일관성과 완성도를 부여합니다.
• shadcn/ui MCP는 부품을 조달합니다. 미리 만들어진 괜찮은 컴포넌트들을 에이전트가 직접 찾아 가져오게 만듭니다.
• taste-skill은 출고 전 검수를 맡습니다. 조달한 부품을 그대로 배치했을 때 남는 “AI가 만든 티”를 규칙으로 막습니다.

1. DESIGN.md: 디자인 시스템을 AI가 읽는 파일 한 장으로

디자인 시스템이라는 게 있습니다. 색·글꼴·간격·컴포넌트의 규칙을 미리 정해서, 어떤 화면을 새로 만들어도 톤이 흔들리지 않게 하는 규정집이죠. 큰 기업은 대부분 이걸 갖고 있습니다. DESIGN.md는 그 규정집을 AI가 그대로 읽을 수 있는 파일 한 장으로 만든 형식입니다. 구글 랩스가 2026년 4월 공개한 초안 스펙에 기반하며, Apache-2.0 소스입니다.

무엇을 해결하나

어떤 색이 무엇에 쓰이는지 AI가 추측하지 않게 만듭니다. 그리고 그 선택을 접근성 규칙에 대조해 검증하게 하고요. 지금까지 이 정보는 사람 머릿속이나 디자인 툴 안에 있었습니다. 그래서 화면을 하나 더 만들 때마다 같은 설명을 다시 해야 했죠. 파일로 두면 그 설명이 한 번으로 끝납니다.

생김새

파일 하나입니다. 대신 구조를 두 개로 나누었죠. 위쪽 YAML 머리말에는 기계가 읽는 값을 넣습니다. 색이나 글꼴 값에 이름을 붙여 재사용하는 단위를 토큰이라고 부르는데요, 이름과 색, 타이포, 간격 같은 값이 여기 들어갑니다. 아래쪽 마크다운 본문에는 사람이 읽는 근거를 적습니다. 왜 이 색을 골랐는지, 어디에 쓰면 안 되는지 같은 것들이죠. 파일을 프로젝트 루트에 두면 Claude Code/Cursor/Copilot 같은 에이전트가 읽습니다.

거인의 어깨에 타기

커뮤니티 플랫폼 getdesign.md에서는 유명 브랜드의 DESIGN.md 파일을 구할 수 있습니다. 다만, 이걸 그대로 쓰기보다 출발점으로 참고하는 쪽이 좋겠죠. 색과 글꼴이 이미 정해진 브랜드라면 그대로 옮기면 좋고, 감각이 전혀 없다면 좋아하는 브랜드의 파일을 참고해 루트에 한 장 두는 것부터 시작하면 됩니다.

이럴 땐 부담이 됩니다

• 아직 형식이 다 짜이지 않아 스펙, 토큰 스키마, CLI가 모두 바뀔 수 있습니다.
• 검증되는 범위는 형식으로 확인 가능한 규칙까지입니다. 톤이나 문화적 뉘앙스는 여전히 사람이 정해야 합니다.

2. shadcn/ui MCP: 무슨 컴포넌트가 있는지 에이전트가 직접 찾게

shadcn/ui는 스스로를 컴포넌트 라이브러리가 아니라 “코드 배포 플랫폼”이라고 규정합니다. 설치하면 라이브러리에 의존하는 대신 컴포넌트 코드가 내 프로젝트 안으로 들어와 직접 고칠 수 있죠. 무료 MIT입니다.

무엇을 해결하나

가장 강력한 건 컴포넌트를 검색해 쓸 수 있다는 겁니다. MCP는 에이전트가 외부 도구를 불러 쓰는 규격인데, 이 서버가 shadcn/ui CLI에 들어 있습니다. 일을 시키면 에이전트가 컴포넌트 목록 저장소인 레지스트리를 직접 검색/조회하고 설치 명령까지 받아옵니다.

공식 문서의 예시 표현은 이렇습니다. 설정된 레지스트리 전체에서 “히어로 하나 찾아줘”라고 하면, 적합한 걸 가져옵니다. 무슨 부품, 즉 컴포넌트들이 있는지 몰라 첫 화면조차 못 만들던 걸 해소해 줍니다. 필요한 걸 말로 부르면 되니까요.

‘AI가 만든 티’의 주범

다만, “AI가 만든 티”의 대표 사례로 가장 자주 지목되는 게 바로 shadcn/Tailwind 기본 외형이에요. 아무래도 비슷한 걸 조달하다 보니, 차별화가 또 어렵습니다. 부품을 쉽게 가져올 수 있다는 건, 남들도 같은 부품을 같은 기본값으로 가져왔다는 뜻이니까요.

그래서 여기서부터는 취향이 필요합니다.

3. taste-skill: “AI가 만든 티”를 규칙으로 금지하기

에이전트에 설치하는 스킬입니다. 스스로를 “AI 에이전트를 위한 안티 슬롭 프론트엔드 프레임워크”라고 부르죠. 만들어주는 게 아니라, 만들 때 하면 안 되는 것을 규칙으로 처리하는 쪽입니다. 무료 MIT이고 Codex/Cursor/Claude Code 등에서 씁니다.

어떻게 해결하나

화면을 그리기 전에 값부터 정하게 하는 방식이에요. 랜딩 페이지와 대시보드는 필요한 값이 다르죠. 그 값을 근거와 함께 먼저 적게 하는 게 이 스킬의 핵심입니다. 취향을 감으로 두지 않고 숫자로 명시합니다.

예를 들어, DESIGN_VARIANCE는 배치를 얼마나 흔들지(1은 완벽한 대칭, 10은 실험적 구성), MOTION_INTENSITY는 움직임의 강도(1~3은 정지, 8~10은 스크롤 연동 애니메이션), VISUAL_DENSITY는 정보 밀도(낮으면 여백 위주, 높으면 대시보드처럼 빽빽하게) 같은 것들을 정합니다.

금지 목록으로 AI 티 막기

“AI 티”로 읽히는 패턴에 이름을 붙여 못 쓰게 합니다.

• 가운데 정렬 히어로를 기본값으로 쓰지 않기
• 똑같이 생긴 카드 세 장을 가로로 늘어놓지 않기
• 이미지+텍스트 좌우 교차 배치를 세 번 연속 쓰지 않기
• 대문자 라벨은 세 섹션당 한 개까지, 흐르는 텍스트(마키)는 페이지당 한 개까지
• 보라색 네온 글로우, 근거 없는 수치(92%·4.1배 같은 것), “John Doe” 같은 가짜 이름 금지

만든 화면이 “어디서 본 것 같다”는 반응을 받은 사람, 특히 랜딩 페이지·포트폴리오처럼 첫인상이 전부인 화면을 만드는 경우에 효과가 큽니다.

이럴 땐 부담이 됩니다

• 기본 스킬이 아직 실험 버전(v2)이라 규칙이 계속 바뀝니다.
• 금지 목록이 곧 저자의 취향이기도 합니다. 세리프 글꼴을 기본값으로 쓰지 말라는 조항처럼, 내 브랜드와 맞서는 규칙이 있으면 지워야 합니다.
• 색·모서리 반경 같은 테마 값만 빠르게 바꾸고 싶은 거라면 과합니다.

전부 다 깔 필요는 없습니다

여기까지 읽고 전부 설치하고 쓰기로 마음먹었나요? 사실 그건 이 도구들을 가장 잘못된 방법으로 쓰는 겁니다. 함께 말해둘 게 두 가지 있습니다.

도구가 겹칠수록 결과가 나빠질 수 있습니다. 그러니 전부 쓰기보다 필요한 부분만 골라 쓰는 편이 낫습니다. 각자가 추구하는 방식이 조금씩 다르기에 만드는 결과물도 다르거든요. Spec Kit의 constitution 개념만 쓰고 실제 스펙은 OpenSpec으로 쓴다거나, BMAD를 통째로 쓰지 않고 필요한 스킬만 로컬 .claude 폴더에 복사하면 전체 결과가 어긋나는 식이죠.

비용은 토큰과 리뷰할 문서량입니다. 계획 하나에 10만 토큰을 봤다는 후기가 있는가 하면, 프로젝트 전체로 보면 스펙 주도가 오히려 싸게 먹힌다는 반박도 있어요. 디자인에서도 어쨌든 AI가 참고할 것이 늘어나니, 작업량이 많아집니다. 물론, 이런 걸 써야 시행착오가 줄어들어 오히려 절약된다는 주장도 있습니다. 어느 쪽도 아직 단정할 수 없습니다. 확실한 건 문서가 늘면 사람이 읽어야 할 양도 는다는 것입니다. 흔히들 말하는 ‘바이브’를 즐길 수 없게 될지도 모릅니다.

마치며

기획과 디자인을 신경 쓰지 않은 상태에서 ‘딸깍’만으로 제대로 된 결과물이 나오는 건, 마치 벼락을 맞을 확률과 비슷할 겁니다. 어찌저찌 돌아가기는 하겠지만, 정작 만든 자기 자신을 비롯해 그 누구도 쓰지 않을 가능성이 크죠. 돌아가는 것과 쓸 만한 것 사이의 거리는 큰 법입니다.

결국 이 모든 과정은 “고객”, 즉, 실제로 쓸 사람을 신경 쓰는 데서 출발합니다. 내가 만든 이 ‘무언가’를 쓰는 사람은 누구인지, 그 사람은 왜 이걸 써야 하는지 이해하는 데 시간을 들여보세요. 그보다 좋은 기획과 디자인의 출발은 없습니다.

6가지 도구들이 어깨는 빌려줄 겁니다. 다만 누구를 위해, 왜 만드는지는 어느 파일에도 적혀 있지 않습니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.