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

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

써볼 것: awesome-codex-subagents - Codex 서브에이전트 136개 모음집
참고할 것: Google Stitch - 구글이 새로 꺼낸 AI 디자인 캔버스, 바이브 디자인
적용해볼 것: Anthropic이 내부에서 쌓은 Claude Code 스킬 운용법

1. 써볼 것: awesome-codex-subagents - Codex 서브에이전트 136개 모음집

awesome-codex-subagents는 VoltAgent가 GitHub에 공개한 Codex용 서브에이전트 모음입니다. 백엔드·프론트엔드 개발, 언어별 전문가, 인프라, 보안, 데이터·AI, 비즈니스·프로덕트 등 10개 카테고리에 걸쳐 136개 서브에이전트가 담겨 있습니다. MIT 라이선스로 공개되어 있고, Codex 공식 문서에 맞게 작성된 .toml 포맷을 씁니다.

Codex에 서브에이전트 기능이 3월 16일 정식 출시되면서 바로 주목받았습니다. Simon Willison은 서브에이전트 패턴이 이제 코딩 에이전트의 표준이 되고 있다고 언급했고, Codex 사용자들 사이에서 직접 서브에이전트를 구성하는 방법에 대한 관심이 빠르게 높아졌습니다.

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

Codex 하나에 모든 걸 맡기면 컨텍스트가 섞입니다. 코드 리뷰를 시키면서 동시에 문서화를 시키고, 버그 디버깅까지 요청하면 각 작업에서 집중도가 떨어지고 결과물이 흐릿해지죠. 서브에이전트는 이 문제를 분업으로 해결합니다. 생각해보면 사람도 똑같죠. 한 사람한테 기획, 개발, QA를 동시에 맡기면 결과물이 흐릿해집니다. 에이전트도 다르지 않은 것 같습니다.

각 에이전트가 독립된 컨텍스트 창에서 자신의 역할에만 집중하기 때문에 출력의 집중도와 일관성이 높아집니다. 서브에이전트는 직접 만들 수도 있습니다. 필요한 것만 골라서 설계하면 되고요. 다만 처음 시작할 때 어떤 구조로 만들어야 할지, 어떤 역할을 분리해야 할지 막막한 경우가 많습니다. awesome-codex-subagents는 그 시작점을 낮춰줍니다. 실제 개발 워크플로에 맞게 만들어진 에이전트를 레퍼런스로 참고하거나, 바로 가져다 붙일 수 있습니다.

어떻게 쓰나요?

레포지토리를 클론한 뒤 원하는 .toml 파일을 에이전트 디렉토리에 복사하면 됩니다.

# 전체 프로젝트에서 쓰려면
mkdir -p ~/.codex/agents
cp categories/04-quality-security/reviewer.toml ~/.codex/agents/

# 특정 프로젝트에서만 쓰려면
mkdir -p .codex/agents
cp categories/01-core-development/backend-developer.toml .codex/agents/
```

설치 후 Codex에서 명시적으로 호출해야 합니다. Codex는 서브에이전트를 자동으로 띄우지 않고, 직접 지정해야 작동합니다.
```
이 브랜치를 병렬로 검토해줘. reviewer가 정확성과 보안을 확인하고, docs_researcher가 이 패치가 의존하는 프레임워크 API를 검증하게 해줘. 둘 다 끝나면 결과를 요약해줘.

각 서브에이전트는 역할에 따라 모델이 지정되어 있습니다. 보안 감사나 아키텍처 리뷰처럼 깊은 추론이 필요한 에이전트는 gpt-5.4가, 빠른 탐색이나 문서 조회는 gpt-5.3-codex-spark나 gpt-5.4-mini가 배정되는 식입니다. 물론 .toml 파일에서 직접 바꿀 수 있습니다.

누구에게 좋을까요?

Codex를 쓰고 있는데 반복 작업마다 프롬프트를 새로 짜는 게 번거로운 개발자
코드 리뷰, 디버깅, 문서화를 각각 다른 에이전트에 위임하는 분업 구조를 만들고 싶은 팀
서브에이전트를 처음 써보는데 어디서 시작해야 할지 모르는 사람

Codex를 쓰지 않는다면 해당 없습니다. Claude Code 사용자라면 같은 VoltAgent가 운영하는 awesome-claude-code-subagents가 따로 있습니다.

Google Stitch 바이브 디자인 — <출처: .google blog>

2. 참고할 것: Google Stitch - 구글이 새로 꺼낸 AI 디자인 캔버스, 바이브 디자인

Google Stitch는 Google Labs가 운영하는 AI 기반 UI 디자인 도구입니다. 3월 18일 대규모 업데이트를 발표하면서 단순한 UI 생성기에서 AI 네이티브 소프트웨어 디자인 캔버스로 전면 재구성됐습니다. 이번 업데이트의 핵심 개념은 바이브 디자인(vibe design)으로, 와이어프레임 없이 비즈니스 목표나 사용자 경험을 자연어로 설명하면 디자인이 생성됩니다. 월 350회까지 무료로 쓸 수 있습니다.

기존 디자인 도구와 무엇이 다른가요?

기존 디자인 프로세스는 보통 와이어프레임으로 시작합니다. 구조를 잡고, 컴포넌트를 배치하고, 색상과 폰트를 고르는 순서죠. Stitch는 이 순서를 뒤집었습니다. 달성하려는 비즈니스 목표, 사용자에게 전달할 감정, 영감을 주는 레퍼런스를 먼저 설명하면 에이전트가 디자인을 만들어냅니다. 수십 가지 방향을 빠르게 탐색한 다음 마음에 드는 걸 골라 다듬는 방식입니다. Figma처럼 직접 조작하는 도구가 아니라, 에이전트와 대화하면서 디자인을 발전시키는 구조입니다.

어떻게 작동하나요?

무한 캔버스 위에 이미지, 텍스트, 코드 등 형태에 관계없이 컨텍스트를 올려놓을 수 있습니다. 디자인 에이전트가 이 컨텍스트를 바탕으로 프로젝트 전체 흐름을 추론합니다. 여러 방향을 동시에 탐색하고 싶다면 Agent Manager를 쓰면 되고, 병렬로 아이디어를 진행하면서 각각을 추적할 수 있습니다.

정적 디자인을 인터랙티브 프로토타입으로 즉시 변환하는 것도 됩니다. 화면들을 연결하고 Play 버튼을 누르면 앱 플로우를 바로 체험할 수 있고, 클릭에 기반해 다음 화면을 자동으로 생성합니다.

음성으로 캔버스에 직접 말하는 기능도 추가됐습니다. 메뉴 옵션 3가지 보여줘, 이 화면을 다른 컬러 팔레트로 보여줘 같은 요청을 실시간으로 처리합니다. 솔직히 이 부분은 아직 얼마나 실용적일지 잘 모르겠습니다. (제가 아직 음성 입력보다, 텍스트 입력이 더 익숙한 사람이라 그런 것 같습니다) 다만 손을 키보드에서 떼지 않고 디자인을 수정하는 그림 자체는 꽤 매력적으로 느껴졌습니다.

무엇을 얻어가야 하나요?

일부에서는 Stitch가 Figma 킬러가 될 거라고 합니다. 구글이 Gemini 모델을 등에 업고 디자인 툴 시장에 본격적으로 들어온 거라는 시각이죠.

개인적으로는 조금 다르게 봅니다. Figma는 완성된 디자인을 정교하게 다듬는 도구고, Stitch는 아이디어 탐색 단계에서 방향을 빠르게 잡는 도구에 더 가깝지 않을까요. 실제로 Figma 내보내기를 지원하기 때문에 둘을 연결해서 쓰는 워크플로가 더 자연스러울 것 같고요. Figma를 대체하기보다는 그 앞 단계를 채우는 쪽에 가깝다는 생각입니다.

더 흥미로운 건 DESIGN.md입니다. 디자인 규칙을 에이전트 친화적인 마크다운으로 내보내고 가져오는 이 포맷은, CLAUDE.md가 코딩 에이전트에 컨텍스트를 구조화하는 것과 같은 방향입니다. 디자인 레이어에서도 컨텍스트를 구조화하는 흐름이 시작됐다는 게 저는 더 주목하게 됩니다.

MCP 서버와 SDK도 공개되어 있어서 Stitch 기능을 다른 도구와 연결하거나 개발 워크플로에 붙이는 것도 가능합니다. 18세 이상, Gemini 지원 국가에서 영어로만 현재 이용 가능합니다.

3. 적용해볼 것: Anthropic이 내부에서 쌓은 Claude Code 스킬 운용법

Thariq는 Claude Code를 만든 Anthropic 팀의 개발자입니다. 최근 X에 Anthropic 내부에서 수백 개의 스킬을 운용하면서 쌓은 노하우를 공개했습니다. 조회수 552만, 좋아요 1.4만을 기록했습니다. 흥미로운 건 새로운 기능을 소개하는 게 아니라는 점입니다. 스킬을 어떻게 분류하고, 어떻게 잘 만들고, 어떻게 팀에 퍼뜨리는지, 실제로 써보면서 생긴 판단 기준을 공유했습니다.

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

스킬은 유연하고 만들기 쉬운 만큼, 잘못 만들기도 쉽습니다. 중복되거나 지나치게 구체적이거나 설명이 빈약한 스킬은 에이전트가 제대로 활용하지 못합니다. Anthropic 내부에서도 이 문제를 겪었고, 수백 개를 운용하면서 어떤 스킬이 실제로 작동하는지 패턴이 생겼습니다.

어떻게 운용하나요?

스킬 유형 9가지

Thariq가 분류한 스킬 유형입니다. 내 조직에서 어떤 스킬이 빠져 있는지 점검하는 기준으로 쓸 수 있습니다.

라이브러리·API 레퍼런스: 내부 라이브러리나 Claude가 실수하는 외부 라이브러리를 올바르게 쓰는 법. 레퍼런스 코드와 주의사항 목록 포함
제품 검증: 코드가 실제로 잘 동작하는지 테스트하는 방법. Playwright나 tmux 같은 외부 도구와 연결. 검증 스킬 하나를 잘 만드는 데 엔지니어 일주일을 쓸 가치가 있다고 했습니다. 처음엔 과하다 싶었는데, 생각해보면 맞는 말입니다. AI가 코드를 빠르게 만들수록 그게 실제로 잘 동작하는지 확인하는 과정이 병목이 되니까요.
데이터 패칭·분석: 데이터와 모니터링 스택에 연결. 자격증명, 대시보드 ID, 공통 워크플로 포함
비즈니스 프로세스·팀 자동화: 반복 워크플로를 명령 하나로. 이전 실행 결과를 로그 파일에 저장하면 다음 실행에서 일관성이 높아집니다
코드 스캐폴딩·템플릿: 프레임워크 보일러플레이트 생성. 순수 코드로 표현하기 어려운 자연어 요구사항이 있을 때 특히 유용
코드 품질·리뷰: 조직 내 코드 품질 기준 적용. Hook이나 GitHub Action으로 자동 실행 가능
CI/CD·배포: 코드 패치·배포 자동화. 다른 스킬을 참조해서 데이터 수집까지 연결
런북: 증상(Slack 스레드, 알림, 에러 시그니처)을 받아 멀티툴로 조사하고 구조화된 보고서 생성
인프라 운영: 루틴 유지보수와 운영 절차. 파괴적 작업에 가드레일을 붙이는 게 핵심

스킬을 잘 만드는 팁

당연한 내용은 쓰지 마세요. Claude는 이미 코드베이스를 많이 알고 있습니다. 스킬에는 Claude가 기본적으로 생각하지 않는 방향으로 밀어내는 정보만 담아야 합니다. Anthropic 내부의 frontend-design 스킬은 Inter 폰트나 보라색 그라디언트 같은 AI가 자주 쓰는 기본 패턴을 피하도록 만들어졌습니다.
Gotchas 섹션을 만드세요. 스킬에서 신호 대비 밀도가 가장 높은 부분입니다. Claude가 실제로 실수한 지점을 모아서 계속 업데이트하는 게 좋습니다.
스킬은 파일 하나가 아닌 폴더입니다. 마크다운 파일 하나로 끝내지 말고, references/api.md로 상세 함수 시그니처를 분리하거나, assets/에 결과물 템플릿을 넣거나, 스크립트 폴더를 포함하세요. Claude가 필요할 때 읽을 파일을 미리 알려주면 컨텍스트를 효율적으로 씁니다.
description 필드는 사람이 아닌 모델을 위해 씁니다. Claude Code가 세션 시작 시 모든 스킬 목록을 보고 이 요청에 맞는 스킬이 있는지 판단합니다. description은 언제 이 스킬을 쓸지를 모델이 이해할 수 있게 써야 합니다.
Claude를 너무 좁게 가두지 마세요. 스킬은 재사용되기 때문에 지나치게 구체적으로 지시하면 상황에 맞게 적응하지 못합니다. 필요한 정보를 주되 판단의 여지를 남기세요.

팀에 스킬 배포하기

소규모 팀이라면 레포지토리 .claude/skills에 체크인하는 게 간단합니다. 팀 규모가 커지면 내부 플러그인 마켓플레이스를 만드는 게 효과적입니다. Anthropic은 중앙에서 관리하지 않고, 유용한 스킬을 만든 사람이 GitHub 샌드박스 폴더에 올리고 Slack으로 공유하는 방식으로 스킬이 퍼집니다. 충분히 쓰이면 마켓플레이스 PR을 올립니다.

적용을 위해 실행해볼 수 있는 것

지금 Claude Code나 Codex를 쓰고 있다면, 가장 자주 반복하는 작업 하나를 골라서 스킬로 만들어보세요. 처음부터 완벽하게 만들려 하지 말고, 몇 줄과 Gotchas 하나로 시작하는 게 좋습니다. 대부분의 좋은 스킬은 그렇게 시작했다고 Thariq는 말합니다.
이미 스킬을 쓰고 있다면 description 필드를 다시 읽어보세요. 사람이 이해하는 설명인지, 아니면 모델이 언제 이걸 써야 할지 판단할 수 있는 설명인지 다르게 느껴질 겁니다.
팀 단위라면 가장 많이 쓰이는 스킬 세 개를 골라 Gotchas 섹션을 업데이트해보세요. 실제 실패 사례가 쌓일수록 스킬의 신호 밀도가 높아집니다.

정리

세 소재가 각각 다른 레이어를 건드립니다. Stitch는 디자인 레이어에서 아이디어를 자연어로 탐색하는 방법을 바꾸고 있고, awesome-codex-subagents와 Claude Code 스킬은 실행 레이어에서 에이전트를 어떻게 구조화하느냐를 다룹니다.

공통점이라면 셋 다 범용 AI 하나에 모든 걸 맡기는 방식은 아니라는 거죠. Stitch는 DESIGN.md로 디자인 컨텍스트를 구조화하고, 서브에이전트는 작업별로 독립된 컨텍스트를 분리하고, Claude Code 스킬은 조직의 노하우를 에이전트가 쓸 수 있는 형태로 압축합니다. AI를 잘 쓰는 것과 AI에게 구조를 주는 것은 다른 이야기입니다.

이렇게 적용해보세요

Codex를 쓰고 있다면 awesome-codex-subagents에서 지금 가장 자주 하는 작업 카테고리 하나를 골라 에이전트 두세 개를 설치해보세요. 병렬로 돌리기 전에 각 에이전트가 단독으로 어떻게 동작하는지 먼저 확인하는 게 좋습니다.
Claude Code 스킬을 만들고 있다면 description 필드를 먼저 다시 써보세요. 스킬 자체보다 모델이 언제 이 스킬을 써야 하는지 판단하는 기준이 더 중요합니다.
Stitch를 써볼 생각이라면 와이어프레임부터 시작하기보단, 달성하려는 목표와 사용자에게 전달하고 싶은 느낌을 먼저 써보세요.

이번 주 세 소재를 정리하면서 든 생각은, AI에게 구조를 주는 사람과 그냥 쓰는 사람 사이의 격차가 생각보다 빠르게 벌어지고 있는 것 같다입니다. 여러분은 어떻게 느끼시나요?

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