Codex + 비밀 도구 하나가 저희 에이전시에서 사용해 온 디자인 워크플로우입니다... 그리고 그 결과물은 확실히 다른 차원에 있습니다.
몇 달 동안 계속 말해왔습니다. 앱이 AI 슬롭처럼 보인다면, 그건 Codex 문제가 아닙니다. 워크플로우 문제입니다.
대부분의 빌더는 같은 루프에 갇혀 있습니다. AI로 기능을 출시합니다. 백엔드는 작동합니다. 로직은 탄탄합니다. 하지만 인터페이스는 다른 모든 바이브 코딩 앱과 똑같아 보입니다. 사용자는 2초 만에 앱이 진짜인지 아닌지 결정합니다.
예전 해결책은 디자이너를 고용하는 것이었습니다. Figma 파일을 몇 주 동안 기다립니다. 그리고 개발자가 그 디자인을 해석해서 코드로 다시 빌드하는 것을 지켜봅니다. 디자인이 실제로 적용될 때쯤이면 모멘텀을 잃고 필요하지도 않은 돈을 써버렸습니다.
그 전체 프로세스는 이제 선택 사항입니다.
이번 워크스루를 위해 저는 부동산 모바일 앱 컨셉인 Haven을 만들었습니다. 20분 만에 전체 디자인 시스템을 구축했습니다. 1시간도 안 돼서 모든 화면을 디자인했습니다. CSS 한 줄 다시 쓰지 않고 Codex를 통해 프로덕션 코드를 출시했습니다.
이것이 제가 지금 사용하는 워크플로우입니다. 그리고 AI로 제품을 출시하는 모든 빌더는 이것이 어떻게 작동하는지 이해해야 합니다.
Moonchild가 실제로 무엇인가
비밀 도구는 Moonchild입니다.
지난 1년 동안 출시된 거의 모든 AI 디자인 도구를 테스트해봤습니다. 대부분 첫 화면은 괜찮아 보이지만, 두 번째 페이지를 만드는 순간 무너집니다. 일관성이 문제입니다. Moonchild는 다른 어떤 도구도 해결하지 못한 방식으로 이 문제를 해결합니다.
디자인 시스템에서 시작하는 채팅 기반 디자인 캔버스입니다. 빈 프롬프트에서 시작하지 않습니다. 스크린샷에서 시작하지 않습니다. 실제 시스템에서 시작합니다. 시스템을 세 가지 방식으로 가져올 수 있습니다:
→ Figma, GitHub, 또는 라이브 URL에서 가져오기
→ 에이전틱 디자인 시스템 빌더에 브랜드 설명하기
→ Dribbble 등에서 디자인 영감 가져오기
시스템이 들어오면 예전 방식으로 디자인을 프롬프트하지 않습니다. PRD를 붙여넣습니다. 시스템에 맞춰 전체 화면을 생성합니다. 그런 다음 거기서 아트 디렉션을 진행합니다.
그리고 내보내기 경로가 루프를 완성합니다. Moonchild는 MCP 커넥터를 제공하여 디자인을 구조화된 출력으로 Codex에 직접 전달합니다. Codex가 해석할 스크린샷이 아닙니다. 실제 디자인 데이터입니다. 컴포넌트, 토큰, 레이아웃, 모든 것입니다.
그것이 워크플로우입니다. 이제 그것을 실제로 사용하는 방법을 알려드리겠습니다.
대부분의 빌더가 AI를 디자인에 사용하는 방식의 문제점
대부분의 빌더가 하는 일은 이것입니다.
Codex에 새 기능을 빌드하라고 프롬프트합니다. 기능이 출시됩니다. 괜찮아 보입니다. 그런 다음 다음 기능을 프롬프트합니다. 약간 다르게 보입니다. 다섯 번째 기능쯤 되면 앱은 다섯 개의 다른 제품을 이어붙인 것처럼 보입니다.
사람들이 AI 디자인이 나쁘다고 말할 때 이걸 의미합니다.
모델이 나쁜 것이 아닙니다. 워크플로우가 나쁜 것입니다.
Codex는 당신의 디자인 언어가 무엇인지 전혀 모릅니다. 모든 프롬프트는 새로운 컨텍스트입니다. 모든 화면은 추측입니다. 모든 컴포넌트는 이전 컴포넌트에서 점점 더 멀어집니다. 색상이 변합니다. 타이포그래피가 변합니다. 모든 것이 누적됩니다.
해결책은 간단합니다. Codex에 따라야 할 시스템을 제공하세요. 그리고 실제 디자인을 빌드하도록 제공하세요.
대부분의 워크플로우는 둘 중 하나만 제공합니다. Moonchild와 MCP 연결은 동시에 둘 다 제공합니다.
1단계: 먼저 디자인 시스템을 구축하세요. 항상 그래야 합니다.
모든 사람이 건너뛰는 단계입니다. 또한 가장 중요한 단계이기도 합니다.
@ignytlabs에서는 화면을 건드리기 전에 모든 단일 클라이언트를 위해 디자인 시스템을 구축합니다. 예전에는 디자이너가 이틀이 걸렸습니다. Moonchild는 약 20분 만에 해냅니다.
이번 워크스루를 위해 저는 부동산 모바일 앱 컨셉인 Haven을 만들었습니다. Moonchild에 디자인 시스템을 가져오는 몇 가지 방법이 있습니다. Figma, GitHub, 또는 라이브 URL에서 가져올 수 있습니다. 에이전틱 디자인 시스템 빌더에 브랜드를 설명할 수 있습니다. Haven의 경우 바이브에서 시작할 때 주로 하는 방식을 따랐습니다. Dribbble에서 디자인 영감을 얻었습니다. 제가 원하는 느낌을 완벽하게 살린 모바일 부동산 앱 스크린샷 3개와 Haven이 무엇이고 누구를 위한 앱인지에 대한 간단한 설명을 넣었습니다. 도구가 디자인 언어를 추출하고 시스템을 처음부터 구축했습니다.
놀라웠던 점은 모든 것을 미리 볼 수 있다는 것입니다. 제가 지난 글에서 썼던 Google Stitch 워크플로우를 포함한 대부분의 AI 도구는 평평한 토큰 파일을 제공합니다. 색상. 폰트. 간격 정도입니다. 이 도구는 다릅니다. 전체 컴포넌트 라이브러리와 갤러리를 구축합니다. 모든 배지, 버튼, 카드, 칩이 앱 안에서 실제로 보이는 방식으로 렌더링됩니다. 아무 컴포넌트나 클릭하면 라이브로 볼 수 있고, 변형과 크기를 테스트할 수 있는 컨트롤이 있습니다. 미리보기 바로 아래에는 해당 컴포넌트의 실제 JavaScript, CSS, 예제, 종속성이 있습니다. 코드베이스에 바로 가져와서 사용할 수 있습니다.
갤러리는 디자인 방식을 완전히 바꿔놓는 부분입니다. "브랜드 배지"나 "평점 배지"가 컨텍스트 안에서 어떻게 보여야 할지 추측하는 대신, 모두 나란히 볼 수 있습니다. 매물. 임대. 추천. 전체 제품군을 한 번에 볼 수 있습니다. 단 하나의 화면도 생성되기 전에 정보에 기반한 디자인 결정을 내릴 수 있습니다.
이것이 스타일 시트와 실제 시스템의 차이입니다.
2단계: PRD에서 UI로
디자인 시스템이 준비되면 예전 방식으로 디자인을 프롬프트하지 않습니다.
PRD를 붙여넣습니다.
한 페이지짜리 기능 브리프. 제품 사양. 목표 진술. 가지고 있는 어떤 것이든.
Haven의 경우 제품 소개, 목표, 대상 사용자 및 역할, 주요 기능 및 MVP 범위, 전체 사용자 여정, 기술 스택, 디자인 방향을 다루는 구조화된 PRD를 붙여넣었습니다. 약 한 페이지 분량입니다. 도구에 실제 컨텍스트를 제공할 만큼 구체적입니다. 올바른 세부 정보를 올바른 화면으로 가져올 만큼 구조화되어 있습니다.
그런 다음 대부분의 사람들이 건너뛰는 작업을 했습니다.
단 하나의 화면도 생성하기 전에 브레인스토밍을 했습니다.
이것이 대부분의 빌더가 놓치는 핵심입니다. 채팅 모드는 전체 PRD 컨텍스트를 보유합니다. PRD를 덤프하고 생성을 누르는 대신, 먼저 제품에 대해 대화합니다. 화면 목록을 확인합니다. 탐색 패턴을 고정합니다. 픽셀이 존재하기 전에 주요 화면의 계층 구조를 미리 정의합니다.
Haven의 경우 이렇게 물었습니다:
→ "이 PRD를 바탕으로, 어떤 화면을 먼저 구축하는 것이 좋을까요? 부동산 앱에 필요한 것이 빠진 것은 없나요?"
→ "기본 탐색은 홈, 검색, 즐겨찾기, 프로필이 있는 하단 탭이어야 할까요? 아니면 다른 방식이 더 나을까요?"
→ "생성하기 전에, 매물 상세 화면의 우선순위를 알려주세요. 사진 먼저, 그다음 이름과 가격, 사양, 편의시설, 에이전트 순서가 맞나요? 확인하거나 개선해 주세요."
→ "좋습니다. 이제 제가 현재 가지고 있는 디자인 시스템을 고수하면서 라이트 모드와 다크 모드 모두에서 이 화면들을 생성해 주세요. 전체 사용자 여정을 완료하고 모든 화면을 만들어야 합니다."
생성을 누를 즈음에는 도구가 이미 대부분의 디자이너가 첫 고객 미팅 후에 알게 되는 것보다 제품을 더 잘 알고 있었습니다.
이제 변형에 대해 간단히 언급하겠습니다. 이 부분을 주의 깊게 읽어주세요.
멋진 기능 중 하나: 화면의 다양한 변형을 만들 수 있습니다. Moonchild에 명시적으로 언급하기만 하면 알아서 처리합니다. Haven의 경우 전체 앱에 대해 세 가지 다른 미적 방향을 원했습니다. 제가 사용한 정확한 프롬프트는 다음과 같습니다:
"Haven을 위한 3가지 완전한 모바일 UI 디자인 컨셉을 생성해 주세요:
컨셉 1 - 따뜻한 에디토리얼: 크림색 배경, 넉넉한 간격, 속성 이름을 위한 세리프 헤드라인, 부드러운 그림자, 매거진 스타일의 이미지 처리.
컨셉 2 - 대담한 모던: 다크 모드, 높은 대비, 전체 산세리프체, 날카로운 모서리, 가장자리에서 가장자리까지 이미지로 이끄는 사진 중심.
컨셉 3 - 프리미엄 미니멀: 중립적인 팔레트(오프 화이트, 차콜, 단일 포인트 색상), 세련된 타이포그래피, 많은 여백, 미묘한 마이크로인터랙션.
연결된 디자인 시스템을 기반으로 사용하되, 각 컨셉이 시스템을 다른 미적 방향으로 이끌도록 하세요. 섹션뿐만 아니라 전체 화면을 생성해 주세요. 어떻게 하시겠습니까?"
마지막에 "어떻게 하시겠습니까?"라는 부분을 주목하세요. 이것이 효과를 내는 작은 세부 사항입니다. 도구가 그냥 맹목적으로 모든 것을 생성하는 대신 계획을 가지고 돌아왔습니다.
컨셉당 5개의 대표 화면을 먼저 만들겠다고 말했습니다. 세 가지 방향을 나란히 검토할 수 있습니다. 원하는 방향을 선택하면 해당 방향으로 전체 앱을 디자인하겠다고 했습니다.
그것은 비용 방정식을 완전히 바꿉니다. 세 개의 전체 빌드 비용을 지불하는 것이 아닙니다. 세 개의 빠른 샘플러 비용을 지불한 다음, 실제로 선택한 방향으로 단일 전체 빌드 비용을 지불하는 것입니다.
저는 따뜻한 에디토리얼을 선택했습니다. 전체 화면 세트가 다음에 돌아왔습니다.
이제 저를 정말 놀라게 한 부분입니다.
Moonchild가 생성하는 모든 화면은 미리보기 모드에서 인터랙티브합니다. 정적 목업이 아닙니다. 실제로 인터랙티브합니다.
입력 필드를 클릭할 수 있습니다. 버튼을 탭할 수 있습니다. 코드가 작성되기 전에 프로토타입을 테스트하는 실제 사용자처럼 화면 사이를 이동할 수 있습니다. Haven의 경우 미리보기에서 두 가지 흐름 문제를 발견했는데, 그렇지 않았다면 Codex로 전송되었을 것입니다. 매물 상세 화면에서 목록으로 돌아가는 명확한 방법이 없었습니다. 에이전트 연락 CTA가 화면 하단에 너무 아래에 있었습니다. 디자인을 Codex에 넘기기 전에 클릭해 보지 않았다면 두 가지 모두 출시되었을 것입니다.
그것이 핵심입니다. 코드가 작성되기 전에 제품을 테스트하는 것입니다.
정제 루프가 마지막 단계입니다.
화면에 수정이 필요할 때, 처음부터 다시 프롬프트하지 않습니다. 화면을 선택하고, 도구에 무엇을 변경할지 말하면, 제자리에 v2를 생성합니다. 더 시네마틱한 히어로를 원하시나요? v2. 카드 레이아웃을 리스트 뷰로 바꾸시겠어요? v3. 변형이 쌓이므로 비교하고 가장 강력한 것을 선택할 수 있습니다.
Haven의 매물 상세 화면의 경우 세 번의 반복을 거쳤습니다. v1은 에이전트 블록이 너무 위에 있었습니다. v2는 계층 구조를 수정했지만 사진 갤러리가 작게 느껴졌습니다. v3는 둘 다 완벽했습니다. 약 8분 동안의 상호작용이었습니다.
빈 슬레이트에서 큐레이션하는 것이 아닙니다. 실제 방향을 정제하는 것입니다. 이것이 시니어 디자이너와 작업하는 것과 가장 가깝게 느껴지는 부분입니다.
3단계: MCP를 통해 Moonchild를 Codex에 연결하기
여기서 워크플로우가 완전 대박이 됩니다.
디자인 시스템은 Codex에 규칙을 제공합니다. MCP 연결은 Codex에 더 강력한 무언가를 제공합니다. 실제 디자인 출력에 대한 직접 액세스입니다. 스크린샷이 아닙니다. 디자인의 텍스트 설명이 아닙니다. Codex가 읽고 재구축할 수 있는 구조화된 디자인 데이터입니다.
설정 방법은 다음과 같습니다:
→ Moonchild 설정, 그다음 MCP로 이동
→ 사용자 설정에 맞는 설치 명령어 복사
→ Codex CLI 열기
→ 설치 명령어 붙여넣기
→ Moonchild 계정으로 인증
→ 완료
연결이 완료되면 Codex는 디자인 시스템과 사용자가 디자인한 특정 Haven 화면을 모두 볼 수 있습니다.
4단계: Codex가 코드를 출시한다
이제 다음과 같이 Codex를 프롬프트합니다:
Moonchild MCP를 사용하여 Haven 부동산 모바일 앱 프로젝트를 가져오고, 그 안에 어떤 화면이 있는지 알려주세요.
이 첫 번째 프롬프트는 두 가지 작업을 수행합니다. MCP가 올바르게 연결되었는지 확인합니다. 그리고 Codex에 사용자가 디자인한 모든 화면에 대한 완전한 가시성을 제공합니다.
Codex가 더 무거운 작업을 수행하기 전에 유용한 팁 하나. 계획 모드로 유지하세요. Codex는 실행하기 전에 무엇을 할 것인지 표시합니다. 매번 계획을 읽으세요. Codex가 원하는 화면, 순서, 정확도를 이해하는지 확인하세요. 이것이 Codex가 실제로 필요한 것을 코딩하는 것과 Codex가 당신이 필요하다고 생각하는 것을 코딩하는 것의 차이입니다.
계획을 검토하고 원하는 화면을 가리키면, Codex는 Moonchild에서 디자인 데이터를 직접 가져와 디자인 시스템을 참조하고 코드를 작성합니다. 호버 상태, 전환, 엣지 케이스 처리까지 추가합니다. 프롬프트에서 추측하는 대신 실제 디자인 데이터를 기반으로 작업하기 때문입니다.
결과는 다음과 같습니다. 실제 코드베이스에 디자인과 정확히 일치하는 프로덕션급 UI가 몇 분 만에 제공됩니다.
@ignytlabs에서는 모든 클라이언트 MVP의 디자인에 2주를 예산으로 책정했습니다. 디자이너가 Figma 파일을 만들었습니다. 개발자가 그것을 해석했습니다. 해석이 어긋났습니다. 수정했습니다. 순환했습니다. 이 워크플로우를 사용하면 전체 루프가 단일 오후 작업으로 축소됩니다. 동일한 품질. 더 높은 마진. 훨씬 적은 컨텍스트 스위칭.
이 워크플로우를 사용해야 할 때
이 워크플로우가 모든 팀에 적합한 것은 아닙니다. 언제 적합한지 솔직하게 판단하세요.
다음과 같은 경우에 사용하세요:
→ 솔로 빌더나 소규모 팀으로 MVP를 출시하는 경우
→ 디자인 일관성이 화면 전체에서 계속 깨지는 경우
→ 별도의 Figma to 디자이너 to 개발자 파이프라인을 유지하고 싶지 않은 경우
→ 이미 디자인 시스템이 있고 모든 곳에서 적용되기를 원하는 경우
다음과 같은 경우에는 건너뛰세요:
→ 규모가 크고 완전한 사내 디자인 팀과 성숙한 Figma 라이브러리가 있는 경우
→ 모든 그림자가 중요한 마케팅 사이트나 브랜드 작업을 위해 픽셀 완벽한 핸드오프가 필요한 경우
→ 코드베이스에 맞춤형 디자인 작업이 필요한 고도로 사용자 정의된 UI 패턴이 있는 경우
MVP와 SaaS 제품을 출시하는 80%의 빌더에게 이 워크플로우는 필요한 모든 것을 다룹니다.
주의할 점
이 작업을 실행하기 전에 몇 가지 솔직한 주의사항입니다.
디자인 시스템의 품질이 출력 품질을 결정합니다. 쓰레기를 넣으면 쓰레기가 나옵니다. 세 가지 색상 토큰이 있는 반쯤 완성된 Figma 파일은 평범한 화면을 생성합니다. 시스템에 처음부터 시간을 투자하세요. 모든 화면에서 그 효과를 볼 수 있습니다.
PRD 품질이 중요합니다. 모호한 브리프는 일반적인 화면을 만듭니다. 사용자 흐름, 엣지 케이스, 명확한 계층 구조가 있는 구체적인 PRD는 유용한 디자인을 만듭니다. 이것은 도구의 한계가 아닙니다. 사고의 한계입니다.
여전히 취향이 필요합니다. 도구는 생산합니다. 당신이 방향을 제시합니다. 올바른 변형을 선택하고 정제하는 것은 당신의 판단이 작용하는 곳입니다. 큐레이션 단계를 건너뛰면, 다시 바이브 디자인으로 돌아갑니다.
일부 컴포넌트는 수동 조정이 필요합니다. 복잡한 애니메이션 상태, 사용자 정의 상호작용 패턴, 디자인 시스템 외부의 모든 것은 Codex에서 수동 패스가 필요합니다. MCP가 90%까지 도달합니다. 마지막 10%는 당신의 취향입니다.
이것이 실제로 의미하는 것
여기 제 솔직한 생각이 있습니다.
AI로 구축된 제품을 출시하는 데 있어 병목 현상은 결코 코드가 아니었습니다. AI는 코드를 작성할 수 있습니다. 병목 현상은 항상 디자인 레이어였습니다. 일관성, 취향, 모든 것을 하나로 묶는 시스템이었습니다.
그 병목 현상이 방금 무너졌습니다.
저희 에이전시에서는 모든 클라이언트 MVP의 디자인에 2주를 예산으로 책정했습니다. 디자이너를 고용합니다. Figma 파일을 기다립니다. 개발자가 그것을 해석하는 것을 지켜봅니다. 순환합니다. 2주가 걸리던 것이 이제 2일이 걸립니다. 동일한 품질. 더 빠른 납기. 더 높은 마진.
이것이 자금을 지원받은 팀이 Figma + 디자이너 + 개발자 파이프라인으로 이미 가지고 있던 워크플로우입니다. 차이점은 이제 솔로 빌더, 인디 에이전시, 소규모 스튜디오가 인력 없이도 동일한 레버리지를 얻을 수 있다는 것입니다.
2026년은 이것을 먼저 알아낸 에이전시와 빌더에게 엄청난 해가 될 것입니다.
TLDR
→ 나쁜 UI 때문에 Codex를 비난하지 마세요. Codex가 문제가 아닙니다. 당신의 워크플로우가 문제입니다.
→ 1단계: Moonchild 내부에서 디자인 시스템을 구축하세요. Figma, GitHub, 또는 라이브 URL에서 가져오세요. 또는 브랜드를 설명하세요. 아니면 제가 Haven을 위해 한 것처럼 Dribbble 영감을 넣으세요.
→ 2단계: PRD를 붙여넣으세요. 생성하기 전에 채팅 모드에서 브레인스토밍하세요. 먼저 화면 목록과 탐색 패턴을 고정하세요.
→ 기본적으로 하나의 변형을 생성합니다. 다른 바이브를 지정하여 히어로 화면에 여러 변형을 명시적으로 요청하세요.
→ 코드가 작성되기 전에 인터랙티브 미리보기를 사용하여 흐름을 테스트하세요. v2, v3 반복으로 화면을 제자리에서 정제하세요.
→ 3단계: MCP를 통해 Moonchild를 Codex에 연결하세요. 이것은 Codex에 스크린샷이 아닌 실제 디자인 데이터를 제공합니다.
→ 4단계: MCP를 사용하여 각 화면을 빌드하도록 Codex를 프롬프트하세요. 프로덕션급 UI가 몇 분 만에 출시됩니다.
→ 디자인 시스템의 품질이 출력 품질을 결정합니다. 거기에 투자하세요.
→ Figma to 핸드오프 to 개발자 사이클은 죽었습니다. 이제 하나의 워크플로우가 디자인과 코드를 함께 실행합니다.
가자.
