00:00:00기존 빌드 프로세스에는 이제 더 이상 존재하지 않는 단계가 하나 있습니다.
00:00:03대부분의 팀은 이를 무엇으로 대체해야 할지 아직 파악하지 못해서,
00:00:06여전히 습관적으로 예전 방식을 따르고 있죠.
00:00:08이번 주, 제니 웬(Jenny Wen)이 레니의 팟캐스트에서 인터뷰를 진행했습니다.
00:00:11그녀는 앤스로픽에서 클로드의 디자인 총괄을 맡고 있으며, 그 전에는 피그마의 디자인 디렉터였습니다.
00:00:17이번 에피소드에서 그녀는 기존 디자인 프로세스의 종말과 그것을 실제로 대체하고 있는 것에 대해 이야기했습니다.
00:00:22그래서 우리는 무엇이 왜 바뀌었는지 분석하고, 그 자리를 대신한 정확한 프로세스를 살펴볼 것입니다.
00:00:27무엇으로 대체되었는지 이해하려면, 먼저 그 프로세스가 왜 존재했는지부터 알아야 합니다.
00:00:31기존 프로세스에서는 먼저 요구 사항을 정의한 다음, 디자이너가 이를 피그마로 가져가서
00:00:35앱이 어떻게 보여야 하는지 목업을 만듭니다.
00:00:38그 피그마 파일은 기획 의도와 실제 결과물 사이의 핸드오프(인수인계) 문서 역할을 했습니다.
00:00:43그러면 프론트엔드 엔지니어가 그 파일을 코드로 변환하죠.
00:00:46그동안 백엔드 엔지니어는 병렬로 작업을 진행했습니다. API 사양이 미리 정의되었기 때문에
00:00:51양쪽이 동시에 움직일 수 있었고 마지막에 모든 것이 연결되었습니다.
00:00:55제니는 이 과정을 디자이너들이 마치 의식처럼 여겼던 프로세스라고 설명합니다.
00:00:58이것은 업계 전체의 표준이었습니다.
00:01:00이 변화의 이유를 설명하는 대부분의 사람들은 이 프로세스가 처음에 왜 생겨났는지 그 근본적인 이유를 놓치고 있습니다.
00:01:05이 분야에서 가장 널리 읽히는 기술 블로그를 운영하는 개발자 사이먼 윌리슨(Simon Willison)은
00:01:09지난 1월 제니의 베를린 강연 내용을 정리하며, 그녀의 강연이 시사하지만 직접적으로 언급하지 않은 통찰을 덧붙였습니다.
00:01:16AI를 활용해 개발하면 잘못된 것을 만들었을 때 치러야 하는 비용이 현저히 줄어듭니다.
00:01:19AI 이전에는 방향을 잘못 잡으면 몇 달간의 엔지니어링 시간이 낭비되었습니다.
00:01:23프론트엔드에서의 작은 실수는 구현 과정에서 10배의 작업량으로 돌아왔죠.
00:01:27그래서 팀들은 모든 단계를 정당화했습니다.
00:01:28리서치, 페르소나, 사용자 여정, 와이어프레임, 상세 사양서까지.
00:01:33이 모든 것들이 대규모로 잘못된 제품을 만드는 것을 막기 위한 보호 장치였습니다.
00:01:36그렇다면 프로세스에서 실제로 무엇이 변했을까요?
00:01:38가장 먼저 엔지니어링 속도가 변했습니다.
00:01:40그리고 대다수의 사람들이 인지하는 것보다 훨씬 빠르게 변했죠.
00:01:42제니는 몇 년 전만 해도 디자이너로서 업무 시간의 60~70%를 목업과 프로토타이핑에 썼다고 합니다.
00:01:48지금은 그 비중이 30~40%로 줄었습니다.
00:01:49그녀가 작업 방식을 바꾸기로 결심한 것이 아닙니다.
00:01:51주변 엔지니어들이 여러 AI 에이전트를 동시에 돌리기 시작하면서,
00:01:55더 이상 엔지니어링이 병목 구간이 아니게 된 것입니다.
00:01:58엔지니어링이 먼저 변했고, 디자인은 그 변화를 따를 수밖에 없었습니다.
00:02:00비전의 타임라인도 바뀌었습니다.
00:02:02예전에는 디자인이 2년에서 5년 앞을 내다보는 비전을 제시했습니다.
00:02:04이제는 기술 발전 속도가 너무 빨라 3개월에서 6개월 앞을 내다보는 것이 현실적인 범위입니다.
00:02:09그리고 그것은 반드시 문서 형태일 필요도 없습니다.
00:02:11사람들에게 방향성을 보여주는 프로토타입이면 충분하죠.
00:02:13번역(변환) 단계에서도 같은 일이 일어났습니다.
00:02:15에이전트가 요구 사항 문서를 읽고 실제 작동하는 인터페이스를 구축할 수 있게 되면서,
00:02:19중간 변환 계층이 사라졌습니다.
00:02:20에이전트가 직접 코드를 작성하니까요.
00:02:22번역할 피그마 파일 자체가 존재하지 않으므로 변환 과정도 필요 없게 되었습니다.
00:02:25저희 콘텐츠가 마음에 드신다면 'Hype' 버튼을 눌러주세요. 이런 양질의 콘텐츠를 만들고
00:02:29더 많은 분들께 다가가는 데 큰 힘이 됩니다.
00:02:33클라이언트 프로젝트를 진행할 때, 저희가 바로 이런 변화를 적용해야 했습니다.
00:02:36디자인 프로세스는 변했지만, 변하지 않은 부분은 바로 '요구 사항'입니다.
00:02:40잘못된 요구 사항은 전체 빌드 과정을 낭비하게 만듭니다.
00:02:42대부분의 팀은 곧바로 상세 사양서(spec) 작성으로 넘어가는데,
00:02:44그것은 순서가 잘못되었습니다.
00:02:45프로토타입을 만들 때는 기술 스택이나 API 사양이 당장 필요하지 않습니다.
00:02:48실제 제품처럼 보이고 느껴지는 무언가를 만들 수 있을 만큼만 알면 됩니다.
00:02:52그래야 누군가에게 보여주고 찬성 혹은 반대 의견을 즉시 얻을 수 있으니까요.
00:02:56따라서 프로토타입을 건드리기 전에 '액터(Actor)'부터 시작하세요.
00:02:58액터는 시스템과 상호작용하는 사람을 뜻합니다.
00:03:01특정한 목표를 가진 특정한 사람 말이죠.
00:03:03누가 사용하느냐에 따라 무엇을 해야 할지가 결정됩니다.
00:03:06콘텐츠를 제출하는 사람과 승인하는 사람이 있다면,
00:03:10그것은 첫 화면부터 완전히 다른 두 개의 인터페이스가 됩니다.
00:03:12그다음 뷰(View)가 나뉘는 지점을 살펴보세요.
00:03:13대부분의 제품에서 서로 다른 액터가 같은 URL에 접속하더라도
00:03:18완전히 다른 화면을 보게 되는 지점이 있습니다.
00:03:19관리자는 관리 패널을 보고,
00:03:21일반 사용자는 자신의 대시보드를 보게 되는 식이죠.
00:03:22마지막으로 고려할 것은 '제약 사항(Constraints)'입니다.
00:03:24에이전트에게 어떤 도구를 쓰라고 일일이 지시하지 마세요.
00:03:26대신 무엇을 하면 안 되는지, 비용은 어느 정도를 넘지 않아야 하는지 알려주세요.
00:03:28이렇게 하면 나중에 기술적인 결정을 내리기가 훨씬 수월해집니다.
00:03:32저희는 이러한 구체적인 규칙들을 이 'PRD 생성 프롬프트'에 구현했습니다.
00:03:37이 프롬프트는 PRD 인터뷰어 역할을 하며 정해진 규칙에 따라 사용자에게
00:03:42다양한 질문을 던지며 인터뷰를 진행합니다.
00:03:44그 과정이 끝나면 PRD 마크다운 파일이 생성되는데, 이것이 이후
00:03:48프로세스의 각 단계에서 기반 자료로 사용됩니다.
00:03:49이 PRD 파일은 다른 모든 작업의 토대가 됩니다.
00:03:52다음 단계는 이것을 프론트엔드 구조로 변환하는 것입니다.
00:03:55이를 위해 저희는 '레이어 프롬프트'를 사용합니다. 에이전트에게 PRD를 분석하도록 시키는데,
00:04:00참고로 이 PRD는 모든 기술적 세부 사항이 담긴 복잡한 문서가 아니며, 두 가지를 도출해냅니다.
00:04:04프로토타입에 들어갈 페이지와 모달(Modal), 그리고
00:04:08사용자 흐름(User Flow)을 생성하도록 요청합니다.
00:04:09페이지와 모달은 구조적으로 매우 중요합니다. 에이전트가 프론트엔드에서
00:04:14구현해야 할 모든 것들을 미리 계획할 수 있게 해주기 때문이죠.
00:04:17저희는 실행에 옮기기 전 계획을 세우는 것이 에이전트와 컨텍스트 윈도우(문맥 유지) 측면에서
00:04:21얼마나 중요한지 계속 강조해왔으니, 깊이 들어가지는 않겠습니다.
00:04:24다만 사용자 흐름에 있어서는 각 액터의 행동을 정의하는 것이 핵심입니다.
00:04:28우리가 이미 기능이 아닌 액터에 집중하고 있기 때문에,
00:04:32사용자 흐름을 정의해야만 에이전트가 전체 UI 프로토타입에
00:04:36적절한 상호작용 상태와 내비게이션을 구현할 수 있습니다.
00:04:40결과적으로 앞서 언급한 페이지, 모달, 사용자 흐름이 담긴
00:04:45architecture.md 파일을 포함한 두 개의 파일을 얻게 됩니다.
00:04:46그 후, 저희가 평소에 사용하는 기술 스택인 Next.js 앱을 설치하도록
00:04:50에이전트에게 요청했습니다. (Next.js와 Supabase 조합입니다.)
00:04:53그 결과 실제로 이런 결과물이 나왔습니다.
00:04:55전반적으로 디자인이 훌륭해 보이는데, 여기에는 특별한 이유가 있습니다.
00:04:58아, 아까 말씀 못 드렸는데, 이번에 만든 것은 채널, 제품,
00:05:03그리고 강의가 포함된 커뮤니티 플랫폼입니다.
00:05:04기본적으로 멤버와 크리에이터, 두 가지 액터가 존재합니다.
00:05:08크리에이터는 채널 생성, 제품 추가, 강의 업로드 같은 모든 관리 기능과
00:05:12다양한 통계 데이터를 확인할 수 있는 권한을 가집니다.
00:05:15처음 만들어진 프로토타입 치고는 디자인이 정말 훌륭하다고 생각합니다.
00:05:19하지만 UX 측면에서는 아주 좋지는 않습니다. 보통 이런 방식의 대시보드를 원하지는 않으니까요.
00:05:23그런데 바로 이 점이 핵심입니다.
00:05:24예전에는 이런 수정을 하는 데 며칠이 걸렸지만, 여기서는 단 몇 분이면 충분합니다.
00:05:27AI가 이러한 수정을 매우 빠르게 처리할 수 있기 때문이죠.
00:05:30백엔드가 연결되지 않은 상태이기에 추가적인 복잡함 없이
00:05:34순수하게 프론트엔드 프로토타입만 다루면 됩니다.
00:05:36보통 AI는 처음부터 이렇게 세련된 웹사이트나 인터페이스를 만들어내지 못합니다.
00:05:40이 결과물이 보기 좋은 이유는 앤스로픽이 블로그에서 제공한
00:05:44'범용 프론트엔드 스킬' 프롬프트를 사용했기 때문입니다.
00:05:46UI를 구현하기 전에 이 스킬을 사용하는 것을 강력히 추천합니다.
00:05:50슬래시 명령어(/)나 스킬로 저장해 두면 에이전트가 바로 활용할 수 있습니다.
00:05:53클라이언트와 일한다면, 가상 데이터로 완벽하게 작동하는 이 프로토타입을
00:05:57그대로 보여주기만 하면 됩니다. (아직 데이터베이스까지는 필요 없습니다.)
00:06:02이걸 보여주고 승인을 받으면 되고, 아니라면 수정을 거친 뒤
00:06:06나머지 개발 과정을 진행하면 됩니다.
00:06:08이러한 작업 목록(Task List) 덕분에 이제 에이전트에게
00:06:12완전히 작동하는 프로토타입 제작을 맡길 수 있게 된 것입니다.
00:06:14작업 목록, 작업 지속성, 그리고 모든 것이 구조화되어 있기 때문이죠.
00:06:18architecture.md 파일을 만드는 것이 중요했던 이유는 에이전트가
00:06:23환각 현상(Hallucination) 없이 최적화된 작업 목록을 짤 수 있게 해주기 때문입니다.
00:06:28그다음은 백엔드 구현 단계로 넘어갑니다.
00:06:30보통 두 가지 선택지가 있습니다.
00:06:32프론트엔드는 Next.js로 유지하면서 백엔드를 별도의
00:06:36파이썬(Python) 서비스로 구현하는 방식이 있습니다.
00:06:39하지만 이는 작업 중인 애플리케이션의 유형에 따라 다릅니다.
00:06:42여러분이 만드는 대부분의 프로젝트는 Next.js만으로도 충분할 것입니다.
00:06:46Next.js에서 지원하지 않는 광범위한 라이브러리가 필요하거나,
00:06:50사이트 기능을 최적화하기 위해 정교한 백그라운드 작업 오케스트레이션이
00:06:55필요한 경우에만 별도의 파이썬 백엔드가 필요합니다.
00:06:57그런 특수한 경우가 아니라면,
00:06:59Next.js 백엔드만으로도 필요한 모든 것을 처리할 수 있습니다.
00:07:03백엔드를 건드리기 전에 프론트엔드에서 무엇이 필요한지 알아야 합니다.
00:07:07그래서 에이전트에게 프론트엔드 코드, PRD, 구조 파일을 분석하여
00:07:11API 사양을 작성하게 했습니다.
00:07:12그 후 이 세 가지 문서를 활용해 전체 Supabase 스키마를 생성하도록 요청했습니다.
00:07:17(Next.js 프론트엔드와 Supabase를 함께 사용하기 때문입니다.)
00:07:20앱의 데이터를 담을 스키마를 생성해야 하는 것이죠.
00:07:25일반적으로 에이전트에게 물어보면, 직접 데이터베이스에서
00:07:28API 키를 가져와서 수동으로 SQL 쿼리를 붙여넣어 테이블을 만들라고 할 것입니다.
00:07:33하지만 그렇게 하지 말고 Supabase MCP를 사용해야 합니다.
00:07:36어떤 서비스를 사용하든 항상 MCP를 활용하려고 노력하세요. 많은 과정을
00:07:40자동화해주기 때문입니다.
00:07:41예를 들어, 저희는 프로젝트 설정을 들여다볼 필요조차 없었습니다.
00:07:43에이전트가 자동으로 프로젝트를 생성하고, 스키마 쿼리를 실행하고,
00:07:48마이그레이션까지 알아서 마쳤습니다.
00:07:49말 그대로 저희가 할 일이 전혀 없었죠.
00:07:51데이터베이스 설정이 완료되면 프론트엔드를 데이터베이스에 연결합니다.
00:07:55여기서 한 가지 확실히 짚고 넘어갈 차이점이 있습니다.
00:07:57백엔드를 데이터베이스에 따로 연결할 필요가 없습니다. 이미 프론트엔드에
00:08:00통합되어 있기 때문입니다.
00:08:01프론트엔드가 데이터베이스와 직접 통신하므로 통합 과정이 단순해지고
00:08:06전체적인 복잡성도 훨씬 낮아집니다.
00:08:07저희는 이번 영상에서 Warp와 파트너십을 맺었는데, 그들이 최근 OZ를 출시했습니다.
00:08:11OZ는 다양한 클라우드 에이전트를 위한 오케스트레이션 플랫폼입니다.
00:08:14이러한 클라우드 에이전트는 에이전트가 스스로 완료할 수 있다고 판단되는
00:08:19작업들을 위임할 때 매우 유용합니다.
00:08:21여기까지 오면서 에이전트는 프론트엔드와 데이터베이스를 연결했고,
00:08:26앱은 기본적으로 그에 맞춰 작동하고 있었습니다.
00:08:27하지만 결제 처리, 알림 기능, 처리량 제한(Rate Limiting), 분석 기능 등을
00:08:32추가하려면 이러한 기능들을 통합할 수 있는 전용 백엔드 API 레이어가 필요합니다.
00:08:37이를 위해 OZ를 사용해 환경을 구축하고 클라우드 에이전트를 실행하여
00:08:41전용 백엔드 레이어를 구축하도록 요청했습니다.
00:08:43약 15분 후 작업이 완료되었고 모든 준비가 끝났습니다.
00:08:47실제로 서비스를 가동하고 사용자를 받기 위해 남은 작업은
00:08:51구글 인증, 스트라이프(Stripe) 연동, 그리고 몇 가지 세부적인 수정뿐이었습니다.
00:08:56이제 전체 프로세스를 확인하셨고 사용된 프롬프트들도 화면에 모두 공개되었습니다.
00:09:00만약 이 모든 프롬프트를 여러분의 프로젝트에 바로 적용할 수 있는 단계별 워크플로우로
00:09:04받아보고 싶으시다면, AI Labs Pro에 올려두겠습니다.
00:09:06모르는 분들을 위해 설명해 드리자면, 저희 커뮤니티에서는 이번 영상뿐만 아니라
00:09:10이전의 모든 영상에서 다룬 템플릿들을 프로젝트에 즉시 활용할 수 있도록 제공합니다.
00:09:14저희 콘텐츠가 도움이 되었고 채널을 후원하고 싶으시다면,
00:09:18이것이 가장 좋은 방법입니다.
00:09:19링크는 설명란에 있습니다.
00:09:20오늘 영상은 여기까지입니다.
00:09:22채널을 지원하고 이런 영상을 계속 제작하는 데 힘을 보태고 싶으시다면,
00:09:26아래 'Super Thanks' 버튼을 이용해 주세요.
00:09:28언제나 시청해 주셔서 감사드리며, 다음 영상에서 뵙겠습니다.