클로드 디자인과 클로드 코드로 앱 만드는 법: AI 네이티브 제품 개발 6단계 정리

핵심 메시지

• AI로 앱을 만들 때는 전체 시간의 최소 절반을 코드가 아니라 기획과 디자인에 써야 한다.
• 참고할 앱 화면을 캡처해 넣고 색·타이포그래피·여백 원칙을 담은 design.md를 먼저 만든다.
• 제품 요구사항·디자인·기술 스펙을 한 파일에 모으고, 컴포넌트 라이브러리와 데이터 스키마를 반드시 포함시킨다.
• AI는 한 번에 완성품을 내놓지 않으며, 만든 사람이 직접 화면을 고치고 피드백을 반복해야 품질이 올라간다.
• 코드로 넘어간 뒤에도 스펙·디자인 파일을 함께 갱신해 세 가지가 어긋나지 않게 유지해야 한다.

쉽게 이해하기

제품 매니저이자 뉴스레터 운영자인 피터 양이 영화·드라마·게임 취향을 한 페이지에 모아 보여주는 '테이스트메이커'라는 개인용 웹 서비스를 처음부터 끝까지 만드는 과정을 공개했다. 그는 피그마에서 시작하는 전통적인 순서 대신, 문제 정의부터 빌드까지를 여섯 단계로 나눈 자신의 AI 네이티브 작업 흐름을 따랐다. 첫 단계는 사용자 문제를 정의하는 일이다. 그는 수천 편의 영화와 드라마를 IMDb로 관리해 왔지만 단순한 목록 화면이 아쉬웠다고 말한다.

두 번째는 영감을 모아 design.md를 만드는 단계다. AI에 그냥 맡기면 흔한 보라색 톤이나 특정 도구 특유의 느낌이 나오기 때문에, 그는 마음에 드는 앱의 화면을 캡처해 붙여 넣고 '인터페이스는 조용하게 두고 포스터 이미지가 색을 담당하게 하라'는 식의 방향을 함께 지시했다. 결과물은 색·타이포그래피·여백 같은 원칙을 적은 짧은 마크다운 문서다.

세 번째는 클로드 디자인으로 핵심 화면 두 개를 시안 두 벌씩 만들어 비교하는 단계다. 그는 도구가 먼저 되묻는 질문들이 요구사항을 구체화하는 데 도움이 된다고 평가했고, 마음에 들지 않는 요소는 화면에서 직접 지우거나 채팅으로 피드백을 주는 두 가지 방식을 함께 썼다. 그럴듯한 결과와 실제로 좋은 결과를 가르는 것은 결국 디테일에 대한 집착이라는 것이 그의 결론이다.

네 번째와 다섯 번째는 제품 요구사항(PRD)·디자인·기술 스펙을 한 HTML 문서로 묶고, 그 스펙을 근거로 나머지 화면을 모두 설계하는 단계다. 그는 컴포넌트 라이브러리를 함께 만들게 하지 않으면 AI가 제각각인 요소를 남발해 화면이 지저분해진다고 경고했고, 운영 중에는 바꾸기 어려운 데이터 스키마도 이 시점에 정리하게 했다. 빈 화면 상태와 예외 상황, 온보딩 흐름까지 이때 설계한다.

마지막 단계에서야 클로드 코드로 실제 앱을 만든다. 그는 스펙과 디자인 파일을 함께 첨부하고 '시작 전에 모호한 점을 먼저 물어보라'고 지시했으며, 이후에도 스크린샷을 붙여 가며 수십 차례 피드백을 주고받았다. 최종적으로 데이터베이스와 로그인 기능까지 붙은 서비스가 몇 시간 만에 완성됐지만, 한 번에 끝나는 마법은 없었다는 점을 그는 여러 번 강조했다.

주요 인사이트

• 빌드가 쉬워질수록 병목은 코드가 아니라 '무엇을 만들 것인가'로 옮겨간다. 그가 이 과정을 'AI로 속도를 낸 워터폴'이라고 부른 이유다.
• 스펙보다 화면을 먼저 만드는 순서가 핵심이다. 시각적인 결과물이 있으면 기본 상태와 예외 상황을 훨씬 구체적으로 따질 수 있기 때문이다.
• 데이터베이스 구조처럼 나중에 바꾸기 비싼 결정일수록 HTML 파일 몇 개만 고치면 되는 초기 단계에서 확정하는 편이 싸게 먹힌다.
• AI가 만든 요구사항 문서를 사람이 끝까지 읽고 다듬지 않으면, 불필요한 기능을 설계하느라 토큰과 시간을 그대로 낭비하게 된다.
• AI가 코드에서 제품을 바꾸기 시작하면 기획서와 디자인이 금세 낡는다. 변경 사항을 문서에 되돌려 쓰게 하는 습관이 필요하다.

자주 묻는 질문

관련 AI 소식