프롬프트 64자로 만든 대시보드, 직접 돌려봤다

지난 편 요약

1편에서는 Web Artifacts Builder의 설명서(SKILL.md)를 읽어봤다. 짧은 설명서 안에 프로젝트 초기화, UI 제작, 단일 HTML 번들링, 선택적 테스트까지 흐름이 꽤 명확하게 들어 있었다.

하지만 설명서가 좋아 보여도, 실제로 돌려봤을 때 어설프면 의미가 없다. 이번 편에서는 정말로 프롬프트 한 줄만 던졌을 때 어디까지 나오는지 확인한다.

💡 1편을 안 읽으셨어도 괜찮습니다. 이 글은 결과와 과정을 중심으로 설명해서, 처음 보는 분도 따라오기 쉽게 구성했습니다.

이 글에서 볼 핵심은 간단하다. AI가 실제로 어디까지 대신했는지, 그리고 어디부터는 여전히 사람이 판단해야 하는지다.


주문서는 이게 전부였다

AI 에이전트에게 건넨 프롬프트는 딱 이것이었다.

“매출 데이터를 보여주는 대시보드 웹앱을 만들어줘. 월별 매출 차트, 카테고리별 비율 파이 차트, 최근 거래내역 테이블이 있으면 좋겠어. 다크 모드도 지원해줘.”

길게 세세한 명세를 적지 않았다. 이 실험의 포인트는, 비교적 평범한 요청만으로도 어느 수준의 시안이 나오느냐였기 때문이다.

여기에 더해, 1편에서 소개한 Web Artifacts Builder 스킬을 AI 에이전트가 읽을 수 있게 설치해 두었다.


Step 1: 주방 세팅 — 스킬 설치

이미 1편의 설치 과정을 따라 했다면 이 단계는 짧다. 스킬 폴더를 AI 에이전트가 읽는 위치에 복사하면 된다.

git clone https://github.com/anthropics/skills.git /tmp/skills
mkdir -p .gemini/skills
cp -r /tmp/skills/skills/web-artifacts-builder .gemini/skills/

여기서 중요한 건 “설치”라는 단어가 생각보다 거창하지 않다는 점이다. 실행 파일을 따로 까는 느낌보다는, AI가 참고할 작업 설명서를 정해진 위치에 두는 과정에 가깝다.


이제부터는 전부 AI가 한 일이다

이제부터의 실험에서 내가 보고 싶었던 건 하나였다. 중간에 사람이 붙어서 계속 손봐줘야 하는가, 아니면 AI가 실제로 흐름을 이어갈 수 있는가?

결론부터 말하면, 아래 과정에서 사람이 추가로 개입한 횟수는 0번이었다.


Step 2: 요리 시작 — AI가 실제로 한 일

프롬프트를 받은 AI 에이전트(Antigravity)는 SKILL.md의 레시피를 따라 작업을 시작했다.

Antigravity 개발 환경 — AI 에이전트가 자율적으로 작업 중

2-1. 프로젝트 초기화

가장 먼저 실행한 것은 init-artifact.sh였다.

bash .gemini/skills/web-artifacts-builder/scripts/init-artifact.sh dashboard

이 명령 하나로 React 기반 프로젝트가 생성됐다.

  • ✅ React 19 + TypeScript (via Vite 8)
  • ✅ Tailwind CSS 3.4.1 + shadcn/ui 테마 시스템
  • ✅ 40개 이상의 shadcn/ui 부품 사전 설치
  • ✅ Parcel 번들링 설정

여기서 첫 번째 문제가 생겼다. 설치 도중 어떤 도구가 서버 실행 여부를 물으면서 흐름이 멈췄다. 그런데 AI 에이전트가 이 멈춤을 감지하고, 자동으로 우회해서 다시 작업을 이어갔다.

이 장면이 중요했다. 1편에서 설명서가 짧은 만큼 예외 상황 가이드가 얇다고 봤는데, 실제 사용에서는 설명서의 빈칸을 AI의 판단력이 어느 정도 메워주고 있었다.

2-2. 화면 구성 요소 설계

그다음 AI는 프롬프트를 해석해서 필요한 부품을 나눴다. 결과적으로 아래 7개 컴포넌트를 만들었다.

  1. mock-data.ts — 월별 매출, 카테고리, 거래 내역 데모 데이터
  2. stat-card.tsx — 핵심 지표 카드 4개
  3. revenue-chart.tsx — 월별 매출 차트
  4. category-pie-chart.tsx — 카테고리별 도넛 차트
  5. transaction-table.tsx — 거래 내역 테이블
  6. theme-provider.tsx — 라이트/다크 모드 상태 관리
  7. theme-toggle.tsx — 테마 전환 버튼

이 부분에서 눈에 띈 건, 내가 “차트”라는 말만 했는데도 AI가 차트 라이브러리인 recharts를 스스로 찾아서 추가했다는 점이다. 사용자는 원하는 화면을 말했고, AI는 거기에 필요한 재료를 골라 넣었다.

초보자 관점에서 보면 여기서 중요한 건 라이브러리 이름이 아니다. 요청을 받으면 AI가 화면을 구성하는 부품 단위로 생각한다는 점이다. 이 감각이 잡히면 이후 다른 툴을 볼 때도 이해가 빨라진다. 반대로 데이터 구조를 어떻게 정할지, 어떤 지표를 보여줄지는 여전히 사람이 결정해야 한다.

2-3. 코드 품질은 어땠나

App.tsx를 열어보면 이런 코드가 나온다.

<div className="grid gap-4 grid-cols-1 sm:grid-cols-2 lg:grid-cols-4">
  <StatCard title="총 매출" value={`${summaryStats.totalRevenue.toLocaleString()}만원`} ... />
  <StatCard title="총 주문수" ... />
  <StatCard title="평균 주문액" ... />
  <StatCard title="전환율" ... />
</div>

여기서 좋았던 점은 세 가지였다.

  • 컴포넌트가 분리돼 있다. 한 파일에 전부 몰아넣지 않았다
  • 반응형 레이아웃이 기본이다. 모바일과 데스크톱을 함께 고려했다
  • 다크 모드가 구조적으로 들어가 있다. 단순 색 반전이 아니라 테마 흐름이 잡혀 있다

물론 이건 프로덕션 서비스용 코드와는 다르다. 입력 검증, 에러 처리, 테스트는 더 필요하다. 하지만 시안용 결과물로서는 생각보다 훨씬 정돈돼 있었다.


Step 3: 플레이팅 — 결과물 확인

AI는 브라우저를 열어 라이트 모드와 다크 모드를 확인했다.

☀️ 라이트 모드 🌙 다크 모드
매출 대시보드 — 라이트 모드 매출 대시보드 — 다크 모드

차트, 카드, 테이블이 자연스럽게 섞여 있고, 다크 모드에서도 화면이 크게 어색하지 않았다.

AI 슬롭은 실제로 줄었나?

1편에서 강조했던 규칙을 실제 결과에 대입해 보면 이렇다.

  • ❌ 보라색 그라데이션 — 없다
  • ❌ 과도한 중앙 정렬 — 없다
  • ❌ Inter 폰트 — 사용하지 않음
  • ✅ 다양한 시각 요소 — 카드, 차트, 테이블이 적절히 섞임

즉, 설명서에 있던 “AI 슬롭을 피하라”는 한 줄이 실제 디자인 결과에도 어느 정도 영향을 준 것으로 보였다.


Step 4: 서빙 — 번들링

화면을 만든 뒤에는 모든 파일을 하나로 묶는 단계가 이어졌다.

bash .gemini/skills/web-artifacts-builder/scripts/bundle-artifact.sh

여기서도 문제가 한 번 생겼다. create-vite v8 템플릿의 파비콘 파일명이 예전과 달라져서 번들링 에러가 났다. 그런데 AI 에이전트가 index.html의 해당 참조를 수정해서 다시 통과시켰다.

결과

  • 입력: 소스 파일 55개
  • 출력: bundle.html 1개
  • 크기: 808KB
  • 서버: 불필요

808KB라는 숫자만 보면 커 보일 수 있다. 하지만 React 런타임, 스타일, 차트 라이브러리, UI 부품, 로직이 모두 들어간 결과물이라는 점을 감안하면 납득 가능한 수준이었다.

여기서 독자가 기억하면 좋은 포인트는 하나다. 복잡한 프론트엔드 결과물이 최종적으로는 더블클릭 가능한 파일 하나로 정리됐다는 점이다.


Step 5: bundle.html 검증

완성된 bundle.html을 브라우저에서 직접 열어 확인했다.

  • ✅ 스탯 카드 4개 정상 렌더링
  • ✅ 월별 매출 차트 정상 동작
  • ✅ 카테고리별 도넛 차트 정상 동작
  • ✅ 거래내역 테이블 정상 출력
  • ✅ 다크 모드 토글 작동
  • 인터넷 없이 로컬에서 열림

마지막 항목이 특히 중요했다. 외부 CDN에 의존하지 않기 때문에, Wi-Fi를 끄고 열어도 화면이 유지됐다.


팩트 시트

  • 사람이 쓴 프롬프트 — 1줄
  • AI가 생성한 파일 — 55개
  • 커스텀 컴포넌트 — 7개
  • 사용된 기술 스택 — React 19, TypeScript, Vite 8, Tailwind 3.4.1, shadcn/ui, Recharts 3.8
  • 번들 결과bundle.html 808KB
  • 다크 모드 — ✅ 지원
  • 서버 필요 여부 — ❌ 불필요
  • AI가 자동 해결한 이슈 — 2건
  • 사람이 추가로 개입한 횟수 — 0번

나의 솔직한 판정

설명서의 약속 vs 실제 결과

  • 프로젝트 생성 — 약속대로 됐다. 다만 최신 템플릿 변화는 AI가 현장에서 대응했다
  • UI 품질 — 생각보다 좋았다. 시안 용도로는 충분히 설득력 있다
  • 번들링 — 실제로 단일 HTML이 나왔다
  • 디자인 방향 — AI 슬롭 방지 규칙이 어느 정도 반영된 결과였다

즉, 설명서에 적힌 핵심 약속은 대체로 실제 결과로 이어졌다.

그럼에도 남는 한계

  1. 프로토타입의 벽 — 로그인, 저장, 결제, 실데이터 연동은 별도 작업이다
  2. 808KB의 무게 — 차트 라이브러리까지 들어가니 번들이 가벼운 편은 아니다
  3. 데모 데이터의 한계 — 예쁜 화면 뒤에는 mock-data.ts가 있다

이 세 가지는 꼭 기억해야 한다. 이 도구는 완성 서비스를 뚝딱 만드는 마법봉이 아니라, 잘 동작하는 시안을 빠르게 만드는 도구다. AI가 해준 것은 설계와 구현의 상당 부분이지만, 무엇을 만들지 결정하고 결과를 채택할지 판단하는 책임까지 사라진 것은 아니다.


그래서, 기획팀 민지는?

이 시리즈를 관통하는 질문은 결국 이것이었다. 비개발자인 민지가 이 결과물을 이해하고 활용할 수 있는가?

답은 꽤 명확했다.

bundle.html을 슬랙으로 보내고 “더블클릭해봐”라고 했더니, 민지는 바로 화면을 열 수 있었다. 다크 모드도 눌러보고, “이거 진짜 웹사이트 같다”는 반응이 나왔다.

물론 덧붙여야 할 설명은 있었다. 이건 데모 데이터이고, 실제 회사 데이터를 붙이려면 별도 작업이 필요하다는 점이다. 하지만 시안 용도로는 충분히 통했다.

즉, 민지가 직접 이걸 처음부터 만들 수 있다고 말하기는 어렵다. 하지만 민지가 원하는 화면을 훨씬 빠르게 눈앞에 보여줄 수 있는 상태는 됐다. 실무에서는 이 차이가 아주 크다.


이 도구의 천장은 어디인가

실험을 해보니 경계선도 분명했다.

할 수 있는 것

  • ✅ 복잡한 UI 시안
  • ✅ 차트, 테이블, 토글, 모달 같은 인터랙션
  • ✅ 반응형 레이아웃
  • ✅ 더블클릭 가능한 단일 HTML 공유

할 수 없는 것

  • ❌ 서버 로직
  • ❌ 인증, DB, 결제, 실시간 데이터
  • ❌ React 외 프레임워크 지원

즉, 이 도구는 프론트엔드 프로토타이핑에 강하고, 백엔드가 필요한 문제에는 약하다. 이 경계를 알고 쓰면 굉장히 유용하고, 모르고 쓰면 금방 실망할 수 있다.


이 스킬을 추천하는 사람, 추천하지 않는 사람

추천

  • 기획자/PM — 원하는 화면을 말보다 시안으로 보여주고 싶을 때
  • 1인 창업가 — 투자자나 동료에게 빠르게 프로토타입을 보여주고 싶을 때
  • 프론트엔드 입문자 — React + Tailwind + shadcn/ui 구성을 구경하고 싶을 때
  • 디자이너 — 정적인 시안을 실제 동작 화면으로 보고 싶을 때

비추천

  • 백엔드 중심 프로젝트를 만드는 사람
  • 이미 팀 차원의 개발 환경이 잘 갖춰진 조직
  • 곧바로 프로덕션 배포까지 기대하는 경우

최종 판정

1편에서 레시피를 읽었고, 2편에서 실제로 돌려봤다.

Web Artifacts Builder는 “바이브 코딩의 진입 장벽을 낮춰주는 도구”라는 포지셔닝에 꽤 정확하게 들어맞는다.

이 도구의 핵심은 만능이 아니라는 점이다. React 기반 화면 제작, 초기 세팅 자동화, 단일 HTML 공유라는 범위 안에서는 강하다. 그 대신 서버, 데이터, 인증 같은 문제는 솔직하게 자기 범위 밖에 둔다.

그래서 내 결론은 이렇다. 마법은 아니지만, 실무에서 꽤 쓸모 있는 자동화다. 특히 “일단 눈에 보이는 결과물부터 빨리 만들고 싶다”는 순간에는 확실히 강하다.

프로토타이핑 도구로서 ⭐⭐⭐⭐ (5점 만점 중 4점).

별 하나를 뺀 이유는 명확하다. bundle.html의 구조적 한계와 초보자가 부딪힐 수 있는 제약에 대한 가이드가 SKILL.md 안에 충분히 적혀 있지 않다.


에필로그 — 민지에게

이 시리즈 전체를 관통한 질문은 결국 하나였다. 비개발자도 이 흐름의 결과물을 이해할 수 있는가?

답은 “반쯤 그렇다”에 가깝다.

민지는 결과물을 보는 데 성공했다. 하지만 민지가 직접 AI 에이전트를 설치하고, 터미널을 열고, 프롬프트를 다듬으며 같은 결과를 반복해서 만드는 단계까지는 아직 벽이 있다.

그렇다고 가치가 없는 건 아니다. 오히려 현실적인 가치는 여기 있다. 할 줄 아는 사람이 훨씬 빠르게, 훨씬 자주, 훨씬 부담 없이 시안을 만들어줄 수 있게 된다는 점이다.

그리고 그건 생각보다 큰 변화다.


소스 코드

이 글에서 만든 대시보드의 전체 소스 코드는 GitHub에 공개되어 있다.

🖥️ bundle.html — 내가 만든 대시보드 직접 열어보기


관련 링크


레시피를 읽고, 실제로 돌려보고, 어디까지 가능한지 확인했다. 좋은 도구는 만능이 아니라, 자기 자리를 분명히 아는 도구다.