[AI 활용 기록] 기획안을 문서화해서 AI에게 넘기면, 프론트 목업이 바로 나올까?

오늘의 시도

기획에서 디자인, 디자인에서 코드로 이어지는 변환 과정을 AI가 각 단계마다 얼마나 메워주는지 보는 것

을 목적으로  figma로 제작한 기획안을 마크다운 파일로 문서화하고, 그 문서를 기준으로 AI에게 프론트엔드 목업 제작을 맡겼을 때 어떤 수준의 결과물을 확인해볼 수 있는지 시도해봤다. 

---

방법

먼저 프로젝트는 저번주에 AI를 활용하여 직접 기획한 "Plango"라는 개인 일정 플래너 서비스다. 기획안을 피그마로 문서화한 과정은 이전 글에서 다뤘다. 

[AI 활용 기록 ] AI로 서비스 기획안을 만들며 다시 배운 것

 

이번 시도에서는 그 기획안을 바탕으로 디자인 시스템까지 마크다운 파일로 제작했고, 이 문서를 기준으로 와이어프레임도 만들었다.

분석하여 제작한 기획안.md와 디자인시스템.md

두 가지 md 파일로 제작한 와이어 프레임

실무 수준의 와이어프레임은 아니었지만, 내가 생각하지 못한 부분을 AI가 문서로 분석하며 제안해주고 유저플로우를 잘 표현한 와이어프레임이 나왔다. 글로 작성된 아이디어 부분을 눈으로 확인하는 수준으로는 충분히 만족했다. 

 

다만 Claude로 넘길 때 이 와이어프레임 자체는 넘기지 않았다. 대신 수업 시간에 공유받은 프론트엔드 목업 md 파일, 기획 분석 문서, 디자인 시스템 문서 세 가지를 추출해서 이 문서들을 기준으로 작업을 진행했다. 디자인 시스템 문서 안에는 A.온보딩/계정부터 G.설정까지 유저 플로우가 세분화되어 정리돼 있었기 때문에, 와이어프레임 단계를 건너뛰고 문서에서 바로 코드로 생성되는 결과를 기대하고 있었다.

 

기술 스택은 대화하면서 정했다. React 19, TypeScript, Tailwind v4, shadcn/ui 조합으로 갔고(Recommended 부분으로 모두 선택했다., 상태관리는 Zustand로 도메인별 스토어(useGoalStore, useScheduleStore, useCalendarStore)를 분리했다. 드래그앤드롭은 @dnd-kit을 썼고, 라우팅은 기능 단위 디렉터리 구조로 잡았다. 

빠르게 완성된 프런트 아키텍처

 

이전에 프론트엔드 개발을 시작하며 아키텍처를 고민하거나 초기 세팅을 할 때 Tailwind 버전을 확인하지 못하거나 shadcn/ui 버전과 CSS가 충돌되는 등 겪었던 어려운 부분들을 상당히 빠르고 정확하게 진행되는 것이 신기했다.  

 

참고로 나는 claude CLI pro 계정으로 진행했는데, 터미널에서 실시간으로 처리되어 반영되는 과정에서 질문을 하거나 처리 내역을 볼 때 프런트엔드 개발 경험을 통해 소통이 되는 것이 좋았다.

 

개발 과정에서 어렵지 않게 질문을 던지는 부분도 새로웠다. (왜 그 부분을 추천하는지 등을 제안하는 부분이 특히)

4시간 정도의 작업으로 라우트 20여 개, 컴포넌트 20여 개, 약 3,400줄 분량의 프런트엔드 코드가 나왔다. 백엔드 연동 전이라 목업 데이터로 화면 검증부터 진행했다.

 

Claude가 제작한 프런트 목업 화면 (랜딩 페이지/월간 뷰 페이지)

이전에 작업한 와이어 프레임 화면 (랜딩 페이지/월간 뷰 페이지)

 

비교해 보면 랜딩 페이지는 서로 다른 형태로 생성되었지만, 월간 뷰 페이지는 전체적인 레이아웃과 핵심 기능 구성이 매우 유사하게 구현되었다.

 

랜딩 페이지는 이후에도 바이브 코딩을 통해 자유롭게 수정할 수 있는 반면, 다양한 기능이 포함되는 월간 뷰는 안정적인 구조를 갖추는 것이 더욱 중요하다. 이러한 핵심 화면이 기대한 방향으로 안정적으로 구현된 점이 가장 만족스러웠다.

---

해당 방식의 장점

피그마에서 마크다운으로 옮기는 단계에서 정보 손실이 크지 않았다.

 

화면 구조, 컴포넌트 목록, 인터랙션 규칙까지 상세하게 문서로 옮겨졌고, 이 문서를 그대로 입력값으로 쓰니 라우팅 구조와 상태관리 분리, 기술 스택 조합이 한시간 만에 붙었다. 기술 스택을 정하는 과정에서도 프로젝트 성격에 맞는 조합을 실시간으로 제안받아 반영할 수 있었고, IA 문서에 정리해둔 페이지 구조는 거의 그대로 라우트로 매핑됐다.

 

 

핵심 기능 중 하나인 일정 변경 테스트 화면 (drag-and-drop)

 

코드 자체의 완성도도 만족스러웠다. 가장 핵심 기능 중 하나였던 유연한 일정 변경 부분(drag-and-drop)을 가장 많이 사용되는 React 라이브러리를 기준으로 추천하여 빠르게 구현했다는 점이 인상깊었다.

 

목표 설정 테스트 화면 - 모달 부분이 굉장히 잘 구현되었다

 

 

최근 Gemini로 진행한 바이브코딩한 결과를 리뷰해야 하는 기회가 있는데, 거기서는 모든 코드가 index.html 한 파일 안에 몰려 있어서 구조를 따라가기가 어려웠다. 반면 Claude는 기능 단위, 도메인 단위로 파일을 자연스럽게 분리해서 코드를 짰고, 프론트앤드 개발의 지식이 조금이라도 있는 입장해서 특히 이 점이 좋았다.

 

1시간 정도 진행되어 나온 프런트 코드 결과

---

치명적인 단점

그러나 메인 기능인 드래그앤드롭은 완전히 동작하지 않았다. 라이트 모드 액티브 상태가 화이트 톤으로 뭉개져 구분이 안 되는 컴포넌트도 있었고, 만들다 만 빈 페이지도 여러 개 남았다.

주간 일정 관리에서 일간 조정이 안되는 UX 오류

일정을 완료하여 체크를 하면 갑자기 체크 박스가 안보이는 화이트톤 UX와 갑자기 등장한 리퀴드 글래스 플로팅 버튼

아코디언 버튼을 누르면 글이 잘리는 UX (스크롤 불가)

 

문서에 기록되어 있으나 반영되지 않은 설정 페이지

 

 

또한 초기엔 대시보드 진입 시 화면이 보이지 않는 충돌도 발생했다. 원인은 Zustand selector 안에서 .filter()를 직접 호출한 것이었다.

const monthlyGoals = useGoalStore((s) => s.goals.filter((g) => g.period === 'monthly'))

 

.filter()는 렌더마다 새 배열을 반환하고, React 19의 useSyncExternalStore는 참조가 바뀔 때마다 스토어 변경으로 판단해 재구독한다.

 

이 과정이 무한 반복됐고, 동일 패턴이 세 개 파일에 퍼져 있었다. 이 버그는 타입 체크나 린트로 잡히지 않는 런타임 문제다. 프런트엔드 전용 검증 하네스가 없었기 때문에 오류가 발생한 뒤 브라우저를 직접 띄워 Console log를 확인하며 재현한 뒤에야 원인을 찾을 수 있었다.

 

즉,

하네스가 없으면 같은 패턴의 버그가 다른 라우트에서 또 나와도 매번 수동으로 찾아야 한다.

---

하네스 엔지니어링의 목적을 찾다

기획 문서를 아무리 상세히 쪼개도 커버되지 않는 두 영역이 있었다. 디자인 디테일과 런타임 안정성이다.

 

전자는 시각 정보가 텍스트로, 텍스트가 다시 코드로 옮겨지는 과정에서는 반영되지 않는 영역이 존재하고, 후자는 자동 검증 장치가 없으면  발견할 때까지 남아 있었다. 문서와 컨텍스트는 아키텍처와 기능 구현 속도를 보장하지만 실행 시점의 버그를 막아주지는 않는다는 것을 확인했다. 이는 자동으로 도는 검증 하네스, 즉 앱을 실제로 띄워 특정 라우트를 실행해보는 절차가 있어야 해결되는 문제다.

 

특히 이번 프로젝트에서 가장 기대되는 부분은 프런트엔드 구현 이후의 과정이다. 백엔드와 데이터베이스를 직접 구축하고, 인프라를 설정하며, AI 기능을 실제 서비스에 연동하는 경험까지 이어질 예정인 만큼 앞으로의 개발 과정이 더욱 기대된다.