3줄 요약
- DamiDefi는 Claude Code로 앱 10개를 앱스토어에 출시했고, 매번 같은 약점을 안고 끝났다. 기능은 동작하지만 UI는 “디자인 문서를 많이 읽었으되 좋은 취향이 없는 기계가 만든 것” 같았다.
- 진단은 단순하다. 텍스트는 디자인 의도를 손실 없이 옮길 수 없다. 값으로 정해진 시각적 결정을 설명으로 압축하는 순간 일부는 반드시 사라지고, 코딩 에이전트는 그 설명을 재구성하면서 또 한 번 잃는다.
- 해결책은 디자인을 설명하지 않는 것이다. Moonchild라는 디자인 시스템 레이어에서 토큰·컴포넌트·간격 스케일을 정본으로 만들고, MCP로 Claude Code가 그 스펙을 직접 읽도록 한다.
10개의 앱, 같은 자리의 약점
저자는 솔로 빌더로 Claude Code를 써서 앱 10개를 앱스토어에 올렸다. 출시 속도는 보통 팀이 한 개를 내는 시간에 열 개를 내는 수준이다. 그런데 열 개 모두 같은 문제를 안고 있었다.
앱은 동작했다. 로직도 깔끔했다. 기능도 의도대로였다. 하지만 UI는 디자인 문서를 많이 읽었으되 좋은 취향이라곤 본 적 없는 기계가 만든 것처럼 보였다.
증상은 미묘하다. 화면 사이의 간격이 일관되지 않다. 버튼은 거의 맞는 크기지만 정확히는 아니다. 색상은 비슷하게 맞춰져 있으나 일치하지 않는다. 타이포그래피에는 분명한 위계가 없다. 어디 하나 명백히 깨진 곳은 없는데, “조립된” 소프트웨어 특유의 위화감이 남는다.
저자는 이 약점을 “AI와 단독으로 개발하는 대가"로 받아들였다. 출시 속도를 얻은 만큼 잃은 부분이라고. 3주 전에 디자인 시스템 관련 스레드에서 어떤 도구를 발견하기 전까지는.
텍스트로 디자인을 설명할 때 일어나는 일
기존의 바이브 코딩 워크플로우는 “원하는 것을 설명하고 Claude가 잘 해석하기를 바라는” 방식이다.
“기본 버튼은 파란색, 모서리는 둥글게, 패딩은 16px로 해줘.” Claude가 뭔가를 만든다. 가깝다. 패딩이 14px이다. 파랑이 약간 다르다. 수정을 설명한다. Claude가 다시 만든다. 더 가깝다. 버튼 하나에 20분을 쓴다.
이 패턴을 앱의 모든 컴포넌트에 곱하면 시간이 어디로 가는지 보인다. 저자가 글에서 굳히는 진단은 이렇다.
문제는 Claude가 디자인을 못한다는 것이 아니다. 텍스트가 디자인 의도에 대한 손실 포맷(lossy format)이라는 것이다.
디자인은 정확한 값들로 이루어진 시각적 결정이다. 그 결정을 본질적으로 근사적인 설명으로 압축하면, 그 압축에서 일부가 사라진다. Claude는 사라진 설명에서 디자인을 다시 만들어내고, 재구성 단계에서 또 잃는다. 두 번의 손실이 누적된다.
저자의 처방은 단순하다. 디자인을 설명하지 않는다. 실제 스펙을 그대로 건네고 Claude가 거기서 빌드하게 한다.
Moonchild — 채팅 기반 디자인 시스템 레이어
도구의 이름은 Moonchild다. 채팅으로 조작하는 디자인 시스템 레이어이고, 이 도구가 더 나은 프롬프트보다 잘 작동하는 이유는 아키텍처에 있다.
흐름은 다음과 같다.
- Moonchild 안에서 디자인 시스템을 만들거나 가져온다.
- 그 시스템을 써서 채팅으로 화면과 플로우를 생성한다.
- 전체 결과를 구조화된 출력으로 내보낸다. Claude Code·Cursor·Codex가 그 출력을 직접 읽는다.
출력은 스크린샷이 아니다. Figma 링크도 아니다. 실제 컴포넌트 위계, 토큰 값, 간격 스케일, 레이아웃 명세다. Claude Code가 Moonchild MCP를 통해 이걸 받으면, 더 이상 설명을 해석하지 않는다. 스펙을 읽고 그대로 빌드한다. 저자는 “이 구분이 곧 제품의 전부"라고 굳혀둔다.
디자인 시스템 에디터에는 일곱 개 섹션이 있다. Foundations, Guidelines, Themes, Styles, Components, Gallery, Assets. 토큰 카테고리는 10종이 넘는다. 색상·타이포그래피·간격·그림자·브레이크포인트·애니메이션 타이밍 등.
디자인 시스템을 들여오는 세 경로
처음부터 디자인 시스템을 만들지 않아도 된다. Moonchild는 세 가지 import 경로를 제공한다.
| 경로 | 설명 | 적합한 대상 |
|---|---|---|
| Figma 가져오기 | Figma의 디자인 시스템(토큰·컴포넌트·스타일)을 직접 import | 이미 Figma에 시스템이 있는 팀 |
| GitHub 가져오기 | 코드 패키지 형태로 존재하는 디자인 시스템을 리포에서 읽어 들임 | 코드로 시스템을 관리하는 팀 |
| 라이브 URL 가져오기 | 배포된 사이트·앱을 분석해 디자인 패턴을 추출 | 이미 만들어 둔 결과물을 정식 시스템으로 형식화하려는 바이브 코더 |
처음부터 시작한다면 Agentic Design System Builder가 제품 종류에 맞춰 Foundations·Themes·Components·문서를 통째로 생성해준다. 일반적인 시스템이 아니라 제품 카테고리에 맞춰 보정된 시스템이다.
MCP 연결이 바꾸는 핸드오프
저자가 빌드 방식을 바꿨다고 굳혀 말하는 지점이 여기다. Moonchild MCP가 Claude Code·Cursor에 직접 붙는다. 연결이 살아 있는 동안, 코딩 에이전트는 빌드 도중 언제든 Moonchild에서 디자인을 pull할 수 있다.
워크플로우의 차이는 한 줄로 잡힌다.
핸드오프는 스크린샷과 기도였다. 이제는 구조화된 pull과 PR이다.
| Before | After | |
|---|---|---|
| 입력 | “설정 화면을 만들어줘. 헤더, 섹션 3개, 저장 버튼. 기본 액션은 파랑.” | “Moonchild에서 내가 만든 설정 화면을 pull해.” |
| Claude가 받는 것 | 텍스트 설명 | 컴포넌트 위계 + 간격 값 + 타이포그래피 토큰 + 정확한 버튼 스펙 |
| 정확도 | 근사 | 모든 픽셀이 같은 출처에서 옴 |
실제 워크플로우 — 네 단계
저자가 새 기능·화면마다 돌리는 시퀀스는 네 단계다.
1단계 — Moonchild에서 화면을 생성한다.
디자인 시스템을 활성화한 채 Moonchild를 연다. 화면을 설명하거나 PRD 일부를 붙여 넣는다.
“[화면 이름]을 [제품 설명]용으로 만들고 있다. 사용자가 [주요 액션]을 할 수 있어야 한다. 보조 액션은 [목록]. 우리 디자인 시스템을 전체에 적용해라. 컴포넌트 레이블과 함께 전체 화면을 생성해라.”
Moonchild는 우리 컴포넌트와 토큰을 써서 화면을 만든다. 일반적인 AI UI가 아니라 우리 시스템이 이 인터페이스 문제에 적용된 결과물이다.
2단계 — 캔버스에서 다듬는다.
Moonchild의 무한 캔버스에서 채팅으로 반복 수정한다. “주 버튼을 아래로 옮겨라. 2번과 3번 섹션 사이에 구분선을 넣어라. 헤더를 sticky로 만들어라.” 매 변경이 컨텍스트 안에서 화면을 갱신한다. 매번 처음부터 다시 만드는 게 아니라 아트 디렉팅에 가깝다.
3단계 — Claude Code로 디자인을 pull한다.
“Moonchild에서 [화면 이름] 디자인을 pull해라. 디자인 시스템의 토큰 값들을 써서 React 컴포넌트로 빌드해라. 컴포넌트 위계는 디자인 명세 그대로 맞춰라. 어떤 값도 근사하지 마라. 정확한 간격·색상·타이포그래피 토큰을 써라.”
Claude Code는 컴포넌트 트리·모든 간격 값·모든 색상 토큰·타이포그래피 스펙을 구조화된 출력으로 읽는다. 설명에서 재구성하는 게 아니라 스펙에서 빌드하므로 결과가 맞아 떨어진다.
4단계 — 디자인이 바뀌면 다시 pull한다.
re-pull이 즉시 가능하므로 루프가 빠르다. Moonchild에서 디자인을 다듬으면 Claude Code가 최신 버전을 가져온다. 며칠짜리 핸드오프 사이클 없이 디자인과 코드가 동기화된다.
DS는 Moonchild 안에 갇히지 않는다
저자가 다른 글들이 놓치고 있다고 언급하는 지점이 있다. 디자인 시스템 자체가 Moonchild에 잠겨 있지 않다. DS 에디터에 다운로드 버튼이 있어 Foundations·Themes·Styles·Components·Guidelines·Assets 전체를 어떤 개발 도구든 소비할 수 있는 형식으로 내보낸다. Claude Code·Cursor·Codex·Lovable·Bolt, 내년에 쓸 다른 도구 모두.
이게 바이브 코더에게 의미 있는 이유는 도구가 빠르게 바뀌기 때문이다. 18개월 뒤에 쓰는 도구는 지금과 다를 가능성이 높다. Moonchild에서 제대로 만든 디자인 시스템은 그 변동을 가로질러 따라온다.
글이 인정하는 한계
저자는 정직하게 한계를 적어둔다.
- AI 코드 리뷰는 여전히 필요하다. Moonchild의 구조화 출력 덕분에 첫 시도 정확도는 확연히 올라가지만, 리뷰 없이 프로덕션에 올릴 수 있는 코드가 되는 건 아니다.
- DS는 들이는 만큼만 좋다. 컴포넌트가 들쭉날쭉한 Figma를 반쯤 import하면 들쭉날쭉한 결과가 나온다. Agentic DS Builder는 시작점으로 합리적이지만, 대량 생성 전에 에디터에서 시스템을 다듬는 시간이 출력 품질로 돌아온다.
- 복잡한 인터랙션은 직접 작업해야 한다. 설정 화면·대시보드·온보딩 같은 표준 화면은 잘 해낸다. 커스텀 애니메이션, 복잡한 상태 전이, 제품 고유의 인터랙션 로직은 여전히 사람이 직접 쓰거나 지시해야 한다.
누구를 위한 도구인가
저자가 적은 적합한 대상은 세 부류다.
- 디자이너 없이 앱을 출시하는 솔로 빌더. 동작은 하지만 “조립된” 티가 나는 소프트웨어를 만드는 사람들. Moonchild가 디자인 판단을 대체하지는 않는다. 다만 Claude Code에 디자인 의도를 추측하지 않고 실행할 수 있는 구조화 컨텍스트를 준다.
- 디자인 결정이 코드 안에서 일어나는 개발 주도 팀. 암묵적이던 시스템을 명시적·이동 가능·읽을 수 있는 형태로 정식화한다.
- 엔지니어링 시작 전에 클릭 가능한 화면이 필요한 PM. PRD를 붙여 넣고 플로우를 얻고 팀과 공유한다. 사후에 일어나던 정렬이 빌드 시작 전에 일어난다.
저자의 마무리는 이렇다.
바이브 코딩 시대는 솔로 빌더 세대를 만들어냈다. 대부분의 팀보다 빠르게 소프트웨어를 출시할 수 있는 사람들. 다음 층은, 만든 사람이 어떻게 만들어졌는지 신경 썼다는 게 보이는 소프트웨어를 출시하는 것이다.
전에 출시한 앱들은 동작했다. 지금 출시하는 앱들은 존재할 만해서 존재하는 것처럼 보인다.
가장 흥미로운 지점
이 글의 진단 가운데 가장 멀리 가는 한 줄은 “텍스트는 디자인 의도에 대한 손실 포맷"이라는 문장이다. 이 진단은 UI에만 적용되지 않는다. 정확한 값으로 정해진 시각적·구조적 결정 일체에 같은 압력이 걸린다. 데이터 스키마, 화면 흐름, 다이어그램, 토큰 위계, API 응답 형태. 텍스트로 풀어 설명할수록 코딩 에이전트가 재구성하는 단계에서 잃을 게 늘어난다.
해결의 방향도 같다. 설명을 잘 다듬는 게 아니라 설명을 거치지 않는 채널을 만든다. Moonchild의 MCP가 디자인 시스템을 그렇게 다루듯, 다른 도메인에서도 코딩 에이전트가 직접 읽을 수 있는 구조화 컨텍스트가 자라기 시작했다. 컴포넌트 카드, 스키마 카드, 워크플로우 카드. MCP가 이름을 얻기 전부터 일어나던 흐름이 도구 레이어로 굳어지는 시점이라 보아도 좋다.
출처
- 저자: DamiDefi (X)
- 발행일: 2026년 (X Article)
- 원문: https://x.com/DamiDefi/status/2063937190430671169