검증된 비즈니스 플랜(Business Plan)과 개발 팀이 코딩을 시작할 수 있는 시점 사이에는 워크숍, 와이어프레임(Wireframes), 반복 작업(Iterations), 검증 등 수 주간의 디자인 디스커버리(Discovery Design) 과정이 수반되는 경우가 많습니다. 제품을 빠르게 시장에 선보이고 싶은 프리시드(Pre-seed) 단계의 창업자에게 이는 결코 여유가 없는 시간입니다. 저는 이미 구조화된 프로젝트 파일을 제공했을 때 Claude Design이 이 단계를 어떻게 처리할 수 있는지 테스트해 보고 싶었습니다.

« Bouch.ee » 프로젝트는 가상의 교육용 사례입니다

Sprint Fondateur 방법론을 구체적으로 설명하기 위해, 저는 가족용 식단 계획(Meal planning)이라는 가상의 프로젝트에 대한 전체 파일을 구성했습니다. 이는 실제 고객이 아니며, 아래의 목업(Maquettes)들은 도달할 수 있는 디테일과 품질 수준을 보여주기 위한 샘플로 사용됩니다.

컨텍스트: 이미 성숙한 프로젝트 파일

Claude Design을 열기 전, Bouch.ee 프로젝트는 이미 다음과 같은 것들을 갖추고 있었습니다:

• 10개 장으로 구성된 비즈니스 플랜 (Business Plan)
• 10개 모듈로 구성된 상세한 제품 요구 사항 문서 (PRD)
• 경쟁사 분석 (Analyse concurrentielle)
• 검증된 MVP 범위 문서
• 확정된 기술 스택 (모바일용 Expo, 웹용 Next.js, API 측 Symfony)

이 모든 것은 전용 모노레포(Monorepo)에 존재하며, Claude Code 세션이 이 메모리를 인지하고 있습니다. 따라서 목표는 백지 상태에서 시작하는 것이 아니라, 디자인 도구에게 이미 존재하는 것을 읽고 그에 부합하는 일관된 UX를 구체화하도록 요청하는 것이었습니다.

7단계 프로세스

다음은 제가 실제로 수행한 내용입니다. 이론적인 프로토콜이 아니라, 세션 동안 제가 반복하며 진행한 과정입니다.

1. Claude Code에게 프롬프트 작성을 요청하기

첫 번째 단계이자 아마도 가장 중요한 단계는, 제가 Claude Design을 위한 프롬프트(prompt)를 직접 작성하지 않았다는 점입니다. 저는 프로젝트를 파악하고 있는 Claude Code에게 비즈니스 플랜(BP), 제품 요구 사항 문서(PRD), 그리고 코드 측면에서 예정된 디자인 시스템(design system)을 참고하여 브리프(brief)를 준비해 달라고 요청했습니다. Claude Code는 목업(mockup)이 고립된 섬이 되지 않고, 이미 결정된 사항들의 논리적 연장선이 될 수 있도록 **디자인 시스템 (design system)**을 동시에 준비해야 했습니다.

이 첫 번째 버전은 깔끔했지만, 다소 무난했습니다. 그것은 기초였지 최종 결과물은 아니었습니다.

2. 완전히 다른 두 가지 변형 요청하기

그 다음, 저는 Claude Design에게 매우 다른 입장을 취하라는 **명시적인 지시 (explicit instruction)**와 함께 두 가지 새로운 변형(variant)을 제안해 달라고 요청했습니다. 제품의 선택 사항을 변경하거나, 화면을 추가 또는 삭제하거나, 톤을 수정하거나, 내비게이션(navigation)을 재설계할 수 있도록 허용했습니다. 각 변형은 자신만의 디자인 시스템을 가졌습니다.

결과는 제 기대 이상이었습니다. 변형 B는 매우 어두운 배경을 채택했으며, 거의 전적으로 대화형 모듈을 중심으로 구성되었습니다. 즉, 앱을 채팅처럼 만든 것입니다. 반면 변형 C는 정반대의 방향을 택했습니다. 종이 느낌의, 촉각적이며 거의 수공예적인 느낌의 어시스턴트였습니다. 동일한 문제에 대해 서로 상반된 두 가지 철학이 나타났으며, 각각 실제적인 내부 일관성을 갖추고 있었습니다.

3. 시니어 UX 디자이너에게 피드백을 주듯 대하기

여기서 방법론의 전환이 일어납니다. 저는 변형 C의 UI(user interface)가 더 마음에 들었지만, 변형 B의 여러 아이디어도 파고들 가치가 있다고 생각했습니다. 저는 시니어 디자이너에게 하듯이 피드백을 주었습니다. 무엇이 잘 작동하는지, 무엇이 작동하지 않는지, 그리고 각 경우에 왜 (why) 그런지를 전달했습니다. 저는 두 버전의 장점을 모두 취하면서 모바일과 데스크톱(desktop) 모두에서 작동하는 네 번째 변형을 요청했습니다.

이러한 태도는 타협할 수 없는 핵심입니다. 만약 여러분이 Claude Design을 이미지 생성기처럼 다룬다면, 여러분은 이미지를 얻게 될 것입니다. 하지만 여러분이 이를 협업자(collaborator)로 대한다면, 여러분은 디자인을 얻게 될 것입니다.

Maquette mobile écran de connexion variante D-2

4. 화면별 파일 요청하기

Claude Design은 최신 기술입니다. 모바일과 데스크톱을 포함한 30개의 화면을 한꺼번에 쌓아 보여주는 전체 보기(global view)는 매우 빠르게 느려지고 읽기 어려워집니다. 그래서 저는 각 화면을 별도의 파일로 분리해 달라고 요청했습니다(모바일과 데스크톱을 나란히 배치). 또한 각 화면의 세부적인 상호작용(interaction)을 설명하는 주석을 포함하고, 초기 디자인과 비교하여 차이가 나는 모든 부분을 나열한 별도의 마크다운(markdown) 파일을 함께 요청했습니다.

이러한 분할 방식은 두 가지 장점이 있습니다. 각 화면을 집중해서 다시 검토할 수 있고, 마크다운 파일은 나중에 코드로 넘어갈 때 사양서(spec) 문서로 활용할 수 있습니다.

Maquette mobile écran de conversation avec Camille

5. 구현을 위해 Claude Code로 넘어가기

저는 네 번째 변형(variant)을 zip 파일로 내보낸 뒤 Claude Code 워크스페이스에 넣었습니다. 그리고 Claude Code에게 작업물을 검토하게 하고, 적절하다고 판단되는 경우 **Claude Design의 선택에 이의를 제기(challenge)**하며 구현 계획을 제안하도록 요청했습니다. 실제로 네다섯 번의 이의 제기가 있었습니다. 디자이너가 내린 결정이 코드로 구현했을 때 취약하거나 과도한 부분이 있었기 때문입니다. 매번 이의 제기가 있을 때마다 제가 최종 결정을 내렸습니다.

그 후, 구현 작업은 스프린트(sprint) 단위로 서브 에이전트(subagents)들에게 위임되었으며, E2E(End-to-End) 테스트 하네스(harness, 총 50개 이상의 여정/journeys)가 동반되었습니다. 이는 « 51 stories, 4 sprints, 0 regression »에서 설명된 패턴입니다.

Maquette desktop fiche détail d'une recette

6. 새로운 디자인 반복 (Iteration)을 통한 루프 형성

코드가 배치된 후, 저는 Claude Code에게 Claude Design을 위한 새로운 프롬프트를 준비해 달라고 요청했습니다. 구현 선택 사항들을 반영하여 목업(Mockups)을 업데이트하고, 작업 도중 생각났던 회원가입(Signup) 관련 몇 가지 기능을 추가하기 위해서였습니다. 이는 사양 정의(Specification) → 검토(Review) → 개발(Development) → 반복(Iteration)으로 이어지는 전형적인 단계이지만, 두 당사자 모두 인간이 아니라는 점이 다릅니다.

7. 코드로 재주입

마지막 라운드: Claude Design이 목업을 업데이트하면, 제가 이를 읽고 검토(Comment)한 뒤, 다시 Claude Code에게 전달하여 구현하도록 합니다. 각 스토리(Story)를 검증하는 E2E(End-to-End) 테스트와 함께 말이죠.

수치로 보는 결과

전체 과정에 투입된 저의 개인 시간은 약 2~3시간 정도였으며, 거의 대부분의 시간은 두 Claude 인스턴스 사이에서 검토(Review)하고 복사-붙여넣기를 하는 데 사용되었습니다. 누적된 머신(Machine) 시간은 이보다 더 긴 4~5시간 정도이며, 주로 구현 단계에서 소요되었습니다. 이를 Bouch.ee 정도의 복잡성을 가진 제품을 전통적인 프로세스(UX 워크숍, 와이어프레임(Wireframes), 검증, 에이전시 또는 내부 팀의 반복 작업 등)로 진행했을 때 소요되었을 **수 주(Several weeks)**의 시간과 비교해 보십시오.

그리고 결과물은 단순한 평면 목업이 아닙니다. 문서화된 디자인 시스템(Design System), 모바일/데스크톱 변형을 포함한 30개의 화면, 그리고 초기 계획과의 모든 차이점을 설명하는 변경 이력(Changelog)이 포함되어 있습니다.

→ Bouch.ee 목업 보기 (D-2 변형)

관찰된 한계점

시작하기 전에 알아두어야 할 세 가지가 있습니다.

첫째, Claude Design은 자율적이지 않습니다. 이미 구조화된 프로젝트 메모리(BP, PRD, 범위(Scope))가 없다면 일반적인(Generic) 목업만을 생성합니다. 결과물의 품질은 입력값(Input)의 품질과 직접적으로 상관관계가 있습니다.

둘째, 이 정도 규모의 프로젝트에서 도구의 유연성(Fluidity)은 여전히 개선의 여지가 있습니다. 현재 화면별로 파일을 나누는 방식은 반복 작업(Iteration)을 감당할 수 있는 수준으로 만들기 위한 임시 방편(Workaround)입니다.

마지막으로, 인간 측면에서는 제작자(Producer)이자 디자이너(Designer)의 안목이 필수적입니다. 그림을 그리기 위해서가 아니라, 여러 변형(Variants) 사이에서 의사결정을 내리고, 어색한 부분을 찾아내며, 탐색(Exploration) 단계에서 수렴(Convergence) 단계로 언제 전환해야 할지를 알기 위해서입니다. 20년의 경력이 진정으로 힘을 발휘하는 지점은 생산(Production)이 아니라 바로 이곳입니다.

결론

이 파이프라인(메모리와 코드를 위한 Claude Code, UX를 위한 Claude Design, 그리고 이를 조종하는 숙련된 인간)은 제가 오랫동안 사용해 본 방식 중 가장 생산적인 체인 중 하나입니다. 이 방식이 장기적인 복잡한 제품을 다루는 시니어 UX 디자이너(Senior UX Designer)를 대체할 수는 없습니다. 하지만 프리시드(Pre-seed) 단계 창업자의 MVP(Minimum Viable Product)를 빠르게 구체화하는 데 있어서는, 무시하기 어려울 정도로 시간 대비 품질의 비율을 변화시킵니다.

창업자 스프린트(Sprint Fondateur): 2개월 만에 디자인 + 코드 완성

이 디자인 파이프라인은 이제 저의 창업자 스프린트(Sprint Fondateur) 서비스에 통합되었습니다. 2개월 안에,
여러분은 기능적인 MVP, 비즈니스 플랜(Business Plan), 자금 조달 전략, 그리고 구현 가능한 목업(Mockups)이 포함된 완전한 디자인 시스템(Design System)을 가지고 시작할 수 있습니다.