프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: 다이나믹 워크플로 - 작업에 맞는 작업 틀을 그때그때 직접 짜는 Claude Code 기능
참고할 것: 오픈AI Codex Sites - 프롬프트만으로 웹앱을 만들어 URL로 공유하는 기능
적용해볼 것: 누구나 만들 수 있게 됐을 때 진짜 차이를 만드는 것 - Figma CPO의 관점

1. 써볼 것: 작업에 맞는 작업 틀을 그때그때 직접 짜는 Claude Code 기능

다이나믹 워크플로(dynamic workflows)는 Claude Code가 맡은 작업에 맞춰 처리 방식을 직접 설계하고, 여러 개의 보조 AI를 동시에 굴려 일을 처리하는 기능입니다. 5월 28일 리서치 프리뷰로 공개됐고요. 이후 Claude Code를 개발하는 Anthropic(앤트로픽)의 Thariq Shihipar가 직접 써본 경험과 활용법을 정리해 공유했습니다. 이는 조회수 230만, 좋아요 8천을 넘기며 개발자들 사이에서 화제가 됐습니다.

원래 이런 일은, 그러니까 여러 AI를 나눠서 부리고 서로 검증시키는 작업은 개발자들이 직접 코드를 짜서 흉내 내고 있었습니다. 여러 Claude를 스크립트로 엮어 돌리는 식이었죠. 그렇게 손수 만들던 걸 이제 Claude Code가 알아서 짜준다는 점에서 반응이 좋았습니다. (InfoQ 등이 정리한 내용입니다)

왜 이런 기능이 필요할까요. AI에게 큰 작업을 한 번에 통째로 시키면, 계획을 세우는 일과 실제로 처리하는 일을 같은 대화 안에서 다 하게 됩니다. 짧은 작업은 이걸로 충분한데, 작업이 길고 복잡해지면 AI가 몇 가지 함정에 빠지거든요.

무슨 문제를 해결해 주나요?

앤트로픽이 짚은 함정은 세 가지입니다.

첫째는 중간에 멈추는 겁니다. 50개를 점검해야 하는 보안 검토에서 20개만 보고 다 했다고 선언해 버리는 식이에요. 작업이 복잡할수록 이런 일이 잦아집니다.
둘째는 자기 결과를 후하게 보는 겁니다. AI에게 자기가 낸 결과를 기준에 맞춰 검증하라고 하면, 자기 답을 더 좋게 평가하는 쪽으로 기웁니다.
셋째는 목표가 흐려지는 겁니다. 대화가 길어지고 중간 요약을 거치면서, 처음에 못 박았던 이건 하지 마 같은 조건이 조금씩 사라집니다.

다이나믹 워크플로는 이걸 구조로 막습니다. 하나의 AI에게 다 시키는 대신, 각자 자기 맥락과 좁은 목표만 가진 여러 AI로 일을 쪼개서 돌립니다. 서로 결과를 검증하게 만들 수도 있고요.

어떻게 쓰나요?

쓰는 법은 어렵지 않습니다. 프롬프트에 작업을 설명하면서 워크플로로 처리해 달라고 하거나, /effort 메뉴에서 ultracode를 켜면 됩니다. ultracode를 켜면 AI가 작업마다 알아서 워크플로를 짤지 판단합니다. 처음 실행될 때는 무엇이 돌아갈지 먼저 보여주고 확인을 받으니, 모르고 큰 작업이 돌아갈 걱정은 없습니다.

Thariq가 든 예시를 보면 쓰임새가 그려집니다.

내 사업계획서를 투자자, 고객, 경쟁사 입장에서 각각 물어뜯게 해줘. → 서로 다른 관점의 AI들이 동시에 약점을 파고듭니다.
이력서 80장을 백엔드 포지션 기준으로 순위 매기고, 상위 10명은 한 번 더 확인해줘.
지난 50개 세션을 훑어서, 내가 반복해서 고치는 지적들을 찾아 규칙으로 정리해줘.
블로그 초안의 기술적 주장을 코드베이스랑 하나하나 대조해서 틀린 게 없는지 확인해줘.

코드 작업에만 해당하는 얘기가 아닙니다. Thariq 본인도 오히려 비개발 업무에서 더 유용할 때가 많다고 했고요. 매출이 3월에 왜 떨어졌는지 원인을 여러 갈래로 나눠 파보는 것처럼요.

내부적으로는 여러 패턴을 조합해 작업 틀을 짭니다. 작업을 잘게 나눠 각각 처리한 뒤 합치거나, 같은 작업을 여러 방식으로 시도한 다음 둘씩 비교해 가장 나은 걸 고르거나, 멈춤 조건이 충족될 때까지 반복하는 식입니다. 한 번 실행에 보조 AI를 최대 1,000개까지, 동시에는 16개까지 띄울 수 있습니다.

다만 토큰을 훨씬 많이 씁니다. 앤트로픽도 작은 작업부터 시작하라고 권하고요. 일반적인 코딩 작업 대부분은 굳이 이렇게까지 할 필요가 없습니다. 검토자 다섯 명을 붙일 만한 작업인지 한 번 따져보고 쓰는 게 좋습니다. /goal로 완료 조건을 박아두거나 /loop로 주기적으로 돌리는 것과 묶어 쓰면 더 잘 맞습니다.

누구에게 좋을까요?

한 번에 끝내기엔 너무 크고 여러 갈래로 검증이 필요한 작업을 자주 다루는 분 (대규모 리팩터링, 보안 점검, 대량 분류 등)
AI에게 큰 작업을 시키면 늘 중간에 흐지부지된다고 느꼈던 분
코드뿐 아니라 사업, 분석, 기획 쪽에서 여러 관점으로 검증하고 싶은 분

유료 Claude Code 플랜(Pro, Max, Team, Enterprise)에서 쓸 수 있습니다. Max와 Team은 기본으로 켜져 있고, Pro는 /config에서 직접 켜야 하며, Enterprise는 관리자 승인이 필요합니다. Claude Code 버전이 2.1.154 이상이어야 하니, 안 보이면 업데이트를 해보시길 권장합니다.

공식 안내: claude.com/blog/introducing-dynamic-workflows-in-claude-code
Thariq Shihipar가 공유한 활용법: A harness for every task: dynamic workflows in Claude Code

2. 참고할 것: 프롬프트만으로 웹앱을 만들어 URL로 공유하는 기능

사내에서 간단한 대시보드 하나, 신청 받는 페이지 하나 만들려고 해도 보통은 일이 커집니다. 기획을 정리하고, 개발자에게 요청하고, 서버에 올리고, 주소를 받기까지 며칠이 걸리죠. 비개발자라면 시작할 엄두조차 안 나고요.

OpenAI(오픈AI)가 이 과정을 통째로 줄이겠다고 나섰습니다. 6월 2일 'Intelligence at Work' 행사에서 코딩 도구 Codex의 대규모 업데이트를 공개했습니다. 그중 가장 주목받은 건 Sites라는 기능입니다. 프롬프트로 설명만 하면 인터랙티브 웹사이트나 웹앱을 만들어줍니다. 오픈AI가 호스팅까지 맡아서, URL 하나로 바로 공유할 수 있습니다.

오픈AI가 이렇게 움직인 데는 이유가 있습니다. Codex 주간 사용자는 500만 명을 넘었고, 이 중 분석가, 마케터, 운영, 디자이너, 투자자 같은 비개발자가 약 20%를 차지합니다. 게다가 이 비개발자 사용자가 개발자보다 3배 빠르게 늘고 있고요. 코딩 도구를 업무 전반으로 넓히려는 흐름이 이번 발표의 배경입니다. (Sites 외에도 직군별 플러그인 6종, 결과물의 특정 부분만 골라 수정하는 주석 기능이 함께 나왔습니다)

기존 방식과 무엇이 다른가요?

지금까지 노코드 도구로 웹페이지를 만들 수는 있었습니다. 하지만 보통은 그 도구 안에서만 동작하거나, 만든 다음 어딘가에 따로 올려야 했죠. Sites는 만드는 것부터 호스팅, 공유까지를 한 흐름으로 묶었습니다. 별도의 배포 설정 없이 대화 안에서 만들고 바로 주소를 받는 구조입니다.

만들 수 있는 것도 정적인 페이지에 그치지 않습니다. 대시보드, 플래너, 검토용 작업 공간, 프로젝트 보드, 갤러리, 가벼운 사내 도구, 게임까지 가능합니다. 한 번 만들고 끝이 아니라, 내용이 바뀔 때마다 Codex에게 최신 상태로 유지해 달라고 할 수도 있고요.

어떻게 작동하나요?

쓰는 흐름은 간단합니다. Codex 대화창에서 @Sites를 부르고 만들고 싶은 걸 설명하면 됩니다. 오픈AI가 든 예를 보면 쉽게 이해됩니다. 곧 있을 고객 미팅용 페이지를 만들어 달라고 하면, 그 고객과 관련된 제품 업데이트, 미해결 질문, 사용 추세, 다음 단계를 담은 페이지가 나옵니다. 재무 모델로 시나리오 플래너를 만들어 달라고 하면, 탭을 일일이 넘기지 않고도 여러 가정을 나란히 비교할 수 있는 도구가 나옵니다.

게시는 두 단계로 나뉩니다. 먼저 검토용으로 버전을 저장하고, 확인이 끝나면 그 버전만 실제로 배포합니다. 잘못된 걸 그대로 내보내는 일을 막는 장치예요.

데이터를 다루는 방식도 정리돼 있습니다. 신청 기록이나 게임 점수처럼 계속 저장해둬야 하는 정보는 관계형 데이터베이스(D1)에, 이미지나 문서, 영상 같은 파일은 따로 마련된 저장소(R2)에 보관합니다. 로그인도 붙일 수 있어서, 워크스페이스 사용자만 들어오게 하거나 외부 로그인을 연결할 수 있습니다. 누가 사이트에 접근할 수 있는지는 소유자와 관리자만, 워크스페이스 전체, 직접 지정한 사람만, 이렇게 세 가지로 정합니다. 비밀번호 같은 민감한 값은 소스 코드에 같이 올리지 말고 Sites 패널에서 따로 관리하라고 안내합니다.

지금은 프리뷰 단계라, ChatGPT Business 워크스페이스에서는 기본으로 켜져 있고 Enterprise에서는 관리자가 권한을 열어줘야 씁니다.

이 발표가 왜 술렁였나요?

Sites가 나오자 노코드 AI 웹 빌더 쪽이 긴장했습니다. Lovable, Bolt.new, v0처럼 프롬프트로 웹앱을 만들어주던 서비스들이 하던 일을, 오픈AI가 자기 제품 안에 그대로 넣어버린 모양새거든요. 큰 플랫폼이 작은 서비스의 기능을 자기 제품으로 흡수하면, 사람들이 그 서비스를 따로 쓸 이유가 줄어듭니다. 일부 외신은 이번 발표를 두고 여러 분야의 기존 업무용 소프트웨어를 정면으로 겨냥한 움직임이라고 보기도 했습니다.

그런데 이번 건은 그렇게 단순하게 보기 어렵습니다. 오픈AI가 Sites 파트너로 Wix, Base44, Replit, Lovable, Figma, Webflow, Emergent를 명시했거든요. 위협받는다고 거론되는 회사 중 일부가 오히려 파트너로 들어가 있는 겁니다. 그래서 지금은 흡수냐 협업이냐의 경계가 흐릿하다고 보는 게 정확합니다. 모델을 만드는 회사가 그 위에 얹히던 앱 영역까지 끌어안으면서, 어떤 곳은 품고 어떤 곳은 밀어내는 구도가 만들어지고 있습니다.

무엇을 얻어가야 하나요?

Sites는 아직 프리뷰라 대부분의 독자가 당장 써보긴 어렵습니다. 그래서 이건 지금 당장 써볼 것이라기보다 흐름을 읽어둘 소식에 가깝습니다.

읽어둘 포인트는 두 가지입니다. 하나는 소프트웨어를 만드는 사람의 경계가 넓어지고 있다는 점입니다. 코드를 못 짜도 프롬프트로 사내 도구를 만들어 배포까지 끝내는 일이 큰 회사의 기본 기능으로 들어오고 있습니다.앤트로픽의 Claude Cowork도 비슷한 방향입니다.

다른 하나는 도구를 만들어주던 회사들의 위치가 흔들린다는 점입니다. 특정 기능 하나만 잘하는 제품은, 그 기능이 큰 플랫폼에 흡수되는 순간 설 자리가 좁아집니다. 내가 만들고 있는 게 어느 쪽인지 가끔 점검해보면 좋겠습니다.

공식 발표: openai.com/index/codex-for-every-role-tool-workflow

3. 적용해볼 것: 누구나 만들 수 있게 됐을 때 진짜 차이를 만드는 것

앞의 두 소식이 보여주는 건 만드는 일이 점점 쉬워진다는 흐름입니다. 그러면 질문이 하나 따라오죠. 누구나 빠르게 만들 수 있게 되면, 무엇으로 차이를 만들까요.

Figma의 최고제품책임자(CPO) Yuhki Yamashita가 이 질문을 정면으로 다룬 글을 Figma 블로그에 올렸습니다. 그는 우버에서 4년 넘게 라이더, 드라이버 앱 개편을 이끌었고, 그 전에는 구글에서 iOS용 YouTube 앱을 맡았던 사람입니다. 글의 요지는 분명합니다. 속도는 이제 기본 조건이 됐고, 진짜 차이는 방향과 완성도에서 나온다는 거죠.

무슨 문제를 해결하려 하나요?

상상과 현실 사이의 거리가 거의 사라졌습니다. 떠올린 걸 바로 만들어볼 수 있으니, 빠른 건 당연한 게 됐죠. 문제는 빠른 속도가 착각을 만든다는 데 있습니다. 방향이 틀렸는데 빠르게 가고 있다면, 그건 진전이 아니니까요.

누구나 빠르게 만들면 결과물이 점점 비슷해집니다. AI는 통계적으로 그럴듯한 기본값을 내놓는데, 보기엔 멀쩡하지만 깊이 고민한 결과는 아니거든요. 그 기본값을 의심 없이 받아들이면 그게 그대로 내 제품이 됩니다. 그렇게 다 거기서 거기인 제품이 쌓입니다. Yamashita는 진짜 실패하는 이유가 능력 부족이 아니라 수동성이라고 봅니다. 첫 제안에 그냥 수긍하고, 그럭저럭 괜찮아 보이니 멈추는 태도요.

어떻게 접근하나요?

Yamashita가 제시하는 건 속도, 방향, 완성도 세 가지입니다.

방향을 잡는 방법부터 보겠습니다. 초보 빌더가 자주 빠지는 함정은 첫 아이디어에 매달려 그 주변만 계속 다듬는 겁니다. 출발점을 의심하지 않은 채로요. 반대로 경험 많은 빌더는 선택지를 넓게 펼쳐보라고 하는데, 이건 너무 추상적인 단계에 머물기 쉽습니다. 2x2 표나 와이어프레임만으로는 이게 진짜 되는 아이디어인지 확신이 안 서거든요.

그가 권하는 방법은 넓게 펼치면서 동시에 깊게 파보는 겁니다. 하나만 고르는 대신 서로 다른 방향 여러 개를 띄워놓고, 각각을 실제로 써볼 수 있는 수준까지 만들어보는 거예요. Figma에서는 같은 문제에 대한 인터랙티브 프로토타입을 여러 개 만들어 나란히 놓고, 팀원과 함께 추상적인 안이 아니라 실제 경험을 비교한다고 합니다. 혼자 순서대로가 아니라 여럿이 동시에 일하는 방식이죠. 1번에서 본 다이나믹 워크플로가 여러 AI로 한 문제를 동시에 파고드는 것과 닮은 데가 있습니다.

완성도는 그다음입니다. Yamashita의 표현으로는, 완성도란 받아들이는 게 아니라 고르는 것이고, 기억에 남는 제품과 그냥 굴러가는 제품을 가르는 지점입니다. 각 결정을 다시 들여다보고, 덜어내고 조이고, 이게 정말 맞나 물으면서 관점이 생길 때까지 밀어붙이는 일이에요. 타고난 안목의 문제가 아니라 반복하면서 안목을 길러내는 과정이라는 게 그의 설명입니다.

물론 Yamashita는 디자인 협업 도구를 만드는 회사의 CPO입니다. 완성도를 강조하는 게 Figma의 사업과 맞아떨어지는 면도 있고요. 그 점을 감안하더라도, 누구나 비슷하게 만드는 환경에서 무엇으로 구별될지를 묻는 질문 자체는 곱씹어볼 만합니다.

적용해볼 질문

지금 파고 있는 이 아이디어는, 여러 방향을 비교해보고 고른 건가요, 아니면 처음 떠오른 걸 그냥 붙들고 있는 건가요?
AI가 내놓은 기본값 중에, 내가 의심 없이 그대로 받아들인 건 어떤 게 있나요?
내 제품에서 사람들이 정성을 알아챌 만한 부분은 어디인가요? 있긴 한가요?

실행해볼 수 있는 것

다음에 새 기능이나 화면을 만들 때, 하나만 만들지 말고 방향이 다른 안을 두세 개 만들어 나란히 놓고 비교해보세요. AI를 쓰면 부담이 크지 않습니다.
AI가 처음 내놓은 결과를 그대로 쓰기 전에, 다른 방식은 없을까를 한 번 더 물어보세요. 첫 답에서 멈추지 않는 습관 하나가 결과를 바꿉니다.
이번 주에 만든 결과물 하나를 골라, 덜어낼 수 있는 부분을 세 군데만 찾아 지워보세요. 더하는 것보다 빼는 게 완성도를 만들 때가 많습니다.

원문: figma.com/blog/what-matters-when-anyone-can-build (Yuhki Yamashita, Figma)

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!