Upstage × SW마에스트로 · 2026.04

Spec-Driven Vibe Coding 시대,
서비스 기획은 어떻게 달라지는가

코드를 빠르게 쓰는 것보다,
무엇을 쓸지 정하는 게 더 중요해지는 시대

정구봉 · Team Attention

team-attention.com

01 / 23

Hello

저는 누구인가

Team Attention

길드·밋업·해커톤·컨설팅을 운영하는 Attention 집단

AI Native Camp

비개발자 130명이 자기 업무를 AI로 바꾼 7일 부트캠프.
수강생의 65%가 의사결정권자

Ralphthon

1박 2일 AI 자율 해커톤. 서울 검증 → SF에서 150명 규모로 개최, OpenAI 스폰서

deep-thought · 1 레포 · CLAUDE.md 159개 · 스킬 38개 · 커밋 265개 (6개월)

4명이 파일만으로 길드 운영·컨설팅·콘텐츠·커뮤니티를 돌립니다.
오늘 내용은 이 환경에서 수백 명과 함께 검증한 결과입니다.

02 / 23

What You'll Take Home

오늘 가져갈 것 3가지

01

개발의 무게중심

어디로 이동하고 있는가

02

무엇을 만들지 정하는 법

여러분의 3주 프로젝트에서 바로 쓸 도구

03

팀으로 만들 때

5명의 코드가 망가지지 않게 하는 법

이 3개만 들고 돌아가면 됩니다.

03 / 23

Part 1 · 12 min

개발은 어떻게
바뀌고 있는가

무게중심이 어디로 이동하는가

04 / 23

Part 1

AI 도구의 3단계 진화 — 복사·붙여넣기에서 위임으로

단계	방식	대표 도구	사용자 경험	한계
Stage 1	복사 · 붙여넣기	ChatGPT · Claude 웹	질문 → 답변 → 수동 반영	컨텍스트 휘발 · 매번 재입력
Stage 2	버튼 클릭 · 인라인 제안	Cursor · Copilot · v0	IDE 내 Tab으로 수락	파일 단위 · 특정 기능에 한정
Stage 3	위임 (Delegation)	Claude Code · Codex · Ralph · OpenClaw	"이 버그 조사해" → 나가서 다른 일 → PR 준비	하네스·스킬·Context 설계가 승부

에이전트 루프: READ → THINK → WRITE → VERIFY

사람이 일하는 루프와 똑같은 구조. 그래서 "위임"이 진짜 위임이 됩니다. 컴퓨터 전체에 접근해서 환경을 읽고, 판단하고, 실행하고, 스스로 검증합니다.

4% → 20%

GitHub 커밋 중 Claude Code로 작성된 비율. 연말 예상.

7.6배

Vercel의 Claude 사용 팀이 미사용 팀보다 자주 배포. 주당 14% 가속 중.

12.8h · 169K LOC

Ralphthon 1등팀 자율 실행. 사람은 아침에 git log만 열어봤다.

"여러분의 3주 프로젝트는 Stage 3에서 시작합니다. '내가 다 짜야지'가 아니라 '무엇을 맡길지 정하고 결과를 검증'하는 것이 여러분의 일."

05 / 24

Part 1 · Case 1

AI Native Camp — 비개발자 130명이 자기 업무를 바꾼 7일

130+

누적 참가자

500+

누적 지원자

65%

의사결정권자

2기

운영 완료

Before → After · 5명

이름	직군	Before → After
안영학	이벤터스 CEO	인사평가 2주, 시간 50% 투입 → 4단계로 단축, 30시간 절감
정이을	토스 플레이스 데이터	수동 데이터 요청 처리 → Slack에서 자연어 → SQL 자동 실행
최현종	BDR · 영업	인바운드 리드 1시간/건 → 완전 자동화, 월 20시간 절감
이경은	전략가	정산 수동 → 정산 + 고객사 모니터링 + 인플루언서 플랫폼 3개 자동화
예건희	AI 엔지니어	RAG 개선 7일 예상 → 3시간에 완료 · 성능 향상

7일 동안 배운 것

Day 1	CLAUDE.md — AI에게 나를 알려준다
Day 2	MCP · Context Sync — 내 도구를 연결
Day 3	Clarify — 모호성을 명확으로
Day 4	Compound — 인사이트를 문서로 축적
Day 5	콘텐츠 소화 파이프라인
Day 6	GitHub PR — 결과물 공유
Day 7	최종 발표 — Before/After 공유

캠프 후 조직에서 AX 실행 중

이동훈 · My Ideal Trip · 안영학 · 이벤터스 · 이혜린 · ServiceNow · 구근우 · 넷마블 · 김민지 · KT AI전략팀 · EO 멤버 다수

관찰 — "터미널 여는 것, 플러그인 설치하는 것만으로도 허들입니다. 하지만 이 허들만 넘으면 훨훨 날아다니는 분들을 다섯 명 넘게 봤어요. 도구가 어려운 게 아니라, 출발선까지 가는 길이 없었던 거예요."

06 / 24

Part 1 · Case 2

Ralphthon — AI가 밤새 코딩한 1박 2일 해커톤

포맷 · 12시간 자율 실행

16:00  인간 셋업 (4h) — 스펙, 하네스 설정
20:00  # 핸드오프 — 노트북 닫기
       만지면 가재옷 착용 🦞
20:00–08:00  자율 실행 (12h)
       # 에이전트 독립, 인간 개입 불가
08:00  개봉 — 데모 · 발표 · 심사

43→13

팀 지원 → 선발

$18K

OpenAI 상금

가재옷 메커닉 — 자율 실행 중 노트북 만지면 가재옷 착용(10분). 인간 개입의 물리적 표식. 처음엔 웃다가, 나중엔 서로 도와주는 협력 동기로 작동.

결과 — 총 501,955 LOC · 543 커밋 · 100% AI 작성

Project	Team	LOC	Done	Prize
houseops (Ouroboros)	이재규·정승아	169,553	95%	🥇 $10K
cyberthug-screenclone	허예찬·하도윤	45,522	85%	🥈 $5K
sansa	황성현	8,483	85%	🥉 $3K
tonica	김우영	122,028	97.6%	—

핵심 발견 3가지

01

HOTL 증명 — 1, 2등이 100% AI 자율

가재옷을 한 번도 입지 않았다

02

설계 > 코딩

1, 2등 모두 Harness 오픈소스를 직접 만들던 분들. "자신만의 관점"이 승부.

03

하네스 복잡도 ↔ 순위

복잡한 하네스가 이겼다. Event Sourcing · 수학적 수렴 · 다단계 평가.

"아무렇게나 하면 절대 밤새 돌지 않아요. 바이브 코딩은 이제 100% 실력입니다. 만들어진 코드의 상당 부분이 자세한 테스트 코드예요 — AI Slop이 아니라 실제로 동작하는 코드라는 뜻이에요."

07 / 24

Part 1 · The Shift

무게중심이 이동한다 — "어떻게"에서 "무엇을"로

예전 · Memo Culture

"이걸 어떻게 구현하지?"

엔지니어링 시간의 대부분이 여기에. 기획서와 덱으로 설득한 뒤 개발 착수.

지금 · Demo Culture

"어느 방향이 맞는가.
무엇을 만들면 해결되지?"

코드가 싸질수록 질문이 비싸진다. 설명하는 사람 → 보여주는 사람.

실행이 공짜가 된 세계에서는, 맥락을 설계하는 사람이 이깁니다.

업계가 같은 방향을 말한다

"코드를 수동으로 작성하는 능력이 퇴화하고 있다."

— Andrej Karpathy

"내 새 주 업무는 AI가 잘못한 것을 알려주는 것."

— Malte Ubl · Vercel CTO

"인간의 역할: '만드는 사람'에서 '방향을 잡는 사람'으로."

— Andrew Chen

SaaS 모트의 재편

기존 해자 (침식)	새 해자 (부상)
침식 데이터 전환 비용	부상 에이전트 친화 문서 · API
침식 워크플로우 락인	부상 도메인 암묵지 · 장기 관계
침식 버튼 기반 UI	부상 하네스 · 스킬 카탈로그

"프롬프트 엔지니어링은 절반. 나머지 절반은 Output을 읽는 능력입니다." — 이게 Taste. 여러분이 3주 동안 가장 많이 써야 할 근육.

08 / 23

Part 2 · 20 min

서비스 기획은
왜 더 중요해지는가

프레임워크보다 본질이 중요한 시대.
— 고객이 무엇을 원하는지 알아내는 것, 그 자체가 기획이다.

09 / 24

Part 2 · Legacy Frameworks

과거 기획 프레임워크들은 무엇을 해결하려 했나

PO·기획자가 20년간 써온 대표 도구

프레임워크	공식	쓰임
ICE Score	Impact × Confidence × Ease	기능 우선순위
RICE	Reach × Impact × Confidence ÷ Effort	로드맵 순서
Lean Canvas	9-box 1페이지	비즈니스 가설 정리
MoSCoW	Must · Should · Could · Won't	스콥 축소
Impact × Effort	2×2 매트릭스	"Quick Win" 고르기
Kano Model	Basic · Performance · Delighter	어떤 기능을 뺄지

저도 PO 시절 ICE와 Lean Canvas를 가장 자주 썼습니다. 메이아이에서 현대차 PoC를 기획할 때도요.

공통점 — 이 도구들은 전부
"제한된 리소스 안에서
무엇을 포기할지"를 정하는 도구.

이 도구들이 태어난 시대 배경

기능 1개 = 개발자 2명 × 2주 × 수백만원
개발 리소스는 희소 자원
기획의 본질 = "무엇을 안 만들지" 결정
PO의 주 업무 = 개발팀과 고객 요구사항 사이의 교통정리

이 프레임워크들은 훌륭한 도구였습니다. 단지 특정한 시대의 도구였을 뿐이에요. 그 시대가 끝나가고 있습니다.

10 / 24

Part 2 · The Assumption Broke

전제가 무너졌다 — 만드는 비용이 1/100이 됐다

	과거 (프레임워크가 태어난 시대)	지금
기능 1개 만드는 비용	개발자 2명 × 2주 × 수백만원	에이전트 몇 개 × 하루 × 수천원
병목	개발 리소스 (희소 자원)	방향 판단 · 고객 이해
기획의 역할	"무엇을 안 할지" 골라내기	"무엇이 진짜 맞는지" 알아내기
개발자 설득	항상 어려웠다 (비용이 크니까)	훨씬 쉽다 (싸니까 일단 보여주고 설득)

Strong Claim

과거 기획·제품 개발 방법론은
대부분 리소스를 줄여서 잘 분배하기 위해 만들어졌다.

만드는 비용이 비쌀 때 설계된 도구들이다. 지금은 싸졌다.
→ 다 잊어야 한다.

오해하지 마세요 — 이 도구들이 틀렸다는 게 아닙니다. 그 도구들이 풀려던 문제(리소스 부족)가 지금 여러분 앞엔 없다는 얘기예요. 전제가 사라진 도구는 결론도 바꿉니다.

증거 — Ralphthon 1등팀

코드	169,553 LOC
개발자 참여	1박 2일 · 2명
API 비용	$0.55 (커피값)
사람 개입	0회

커피 한 잔 값으로 17만 줄. Lean Canvas로 기능을 깎아낼 이유가 없다.

리소스 분배 도구가 아니라 본질 탐색 도구가 필요한 시대. 다음 슬라이드에서 뭐가 "본질"인지 정리합니다.

11 / 24

Part 2 · Back to Essence

그럼 기획은 무엇인가 — 본질로 돌아가기

정의 · Definition

기획의 본질은
"한 번에 더 많이 생산할 수 있다고 가정하고,
더 본질에 다가가는 것"

본질 = 고객이 무엇을 원하는지 알아내는 것, 그 자체.

축	과거의 기획 (리소스 분배)	새 기획 (본질 탐색)
시작점	"개발팀이 할 수 있는 게 뭐지?"	"고객이 원하는 게 뭐지?"
스콥 결정	만들 수 있는 것 중 우선순위 (ICE/RICE)	문제를 끝까지 푸는 것 (기능 수 상관없음)
병목 대응	기능 축소 · 스콥 삭감	더 많이 만들고 · 더 많이 실험
PO의 일	요구사항 문서 · 교통정리	고객과 대화 · 직접 프로토타이핑
KPI	릴리즈 건수 · 로드맵 이행률	고객과 몇 번 대화했는가 · 문제가 진짜 풀렸는가

학생 여러분께 드리는 숙제 한 줄 — 이번 3주에 "고객과 대화한 횟수"를 매일 기록하세요. 다른 어떤 지표보다 이게 여러분의 기획력을 가장 잘 측정합니다.

12 / 24

Part 2 · B2B

B2B에서 작동하는 방법 — 대화 + 직접 프로토타이핑

실제로 잘 동작하는 루프

while # 고객이 "됐다"라고 말할 때까지

  1. 고객과 대화
     # 시간 많으니 자주, 길게

  2. 내가 직접 프로토타입
     # AI가 대신 코딩해 주니까 가능

  3. 프로토타입 들고 다시 대화
     # "이렇게 하면 돼요?"

  4. 반박·수정 사항 반영
     # 바로 고쳐서 재방문

end

"과거엔 기획서를 쓰고 → 개발팀에 넘기고 → 2주 기다리고 → 고객에게 보여줌. 이 사이클이 몇 달 걸렸어요. 지금은 며칠."

저의 경험 — 메이아이 PO 시절 현대차 PoC

비전 모델 기반 매장 분석 서비스의 PO였어요. 현대차 PoC를 기획했습니다.

당시엔 ICE · Lean Canvas로 기능 우선순위를 깎아 내렸습니다. 개발팀이 할 수 있는 걸 역산해서 기획서를 축소했어요.

지금 다시 한다면 정반대로 할 거예요. 현대차 담당자와 주 3회 만나서 프로토타입을 제가 직접 만들어 들고 갔을 겁니다. 기획서는 안 씁니다. "이거 맞으세요?"가 기획서를 대체합니다.

Ralphthon 1등팀은 이것의 극단 사례

대화 상대	본인 (룸메이트 청소 분쟁)
대화 방식	AI Socratic 인터뷰 133 라운드
끝낸 시점	Ambiguity 0.05 이하
그 뒤에야	169K LOC 생성 · 사람 개입 0

133 라운드가 길어 보이지만, 고객(본인)과의 대화였습니다. 기획의 본질을 가장 많이 한 팀이 이겼어요.

B2B 기획의 새 공식 — 미팅 횟수 × 프로토타입 횟수.

13 / 24

Part 2 · B2C

B2C에서 작동하는 방법 — 리소스 제약을 제거하고 설계하라

단계	과거 방식 (리소스 제약 시대)	새 방식 (리소스가 거의 무한한 시대)
① 출발	고객 인터뷰 → 요구사항 리스트	고객 관찰 → 진짜 문제 도출
② 필터	개발 리소스 확인 → 할 수 있는 것만 남김	리소스 고민 건너뜀 → 해결의 최단 경로 설계
③ 설계	MVP 스콥 축소 (MoSCoW)	문제를 끝까지 푸는 해결책 설계
④ 검증	개발 후 2–4주 뒤 출시	AI로 프로토타입 → 며칠 안에 고객에게
⑤ 개발자 설득	어려웠다 (비용이 크니까)	쉬워졌다 — 프로토타입 보여주고 "이거 제품화"

버려야 하는 습관

"고객이 원하는 건 A인데, 개발팀이 할 수 있는 건 B와 C. 그럼 B로 가자."
→ 결과물이 고객의 진짜 문제에서 한 발 멀어진다. 예전엔 어쩔 수 없었지만 지금은 아니다.

가져가야 하는 태도

"고객이 원하는 건 A다. A를 직접 만들어서 보여주고, 그걸로 개발자를 설득한다."
→ 만드는 비용이 싸졌기 때문에 개발자 설득이 훨씬 쉬워졌다. 프로토타입이 기획서를 대체한다.

핵심 한 줄 — 과거엔 개발자가 병목이라 개발팀 중심으로 돌아가야 했어요. 지금은 개발 리소스가 거의 무한이에요. 고객 문제를 바로 해결하는 방향으로 설계하고, 개발자는 그 설계로 설득하면 됩니다.

B2C 기획의 새 공식 — 고객 문제의 최단 경로를 먼저 그려라. 개발팀은 그 다음.

14 / 24

Part 2 · Your Deliverable

기획서 템플릿 5섹션 — 본질 탐색 관점으로 채우기

여러분이 실제로 제출할 템플릿. 각 섹션은 "리소스 분배"가 아니라 "고객 본질 발견" 관점으로 작성합니다.

섹션	본질 탐색 질문	Do ✓	Don't ✗
① 문제 정의 및 프로젝트 개요 한 줄 정의·선정 배경·대상·핵심 가치	"고객이 진짜 원하는 건?" "내가 직접 본 불편인가?"	실제 사용자 이름 + 관찰한 장면 묘사 "룸메이트 현수와 청소 분쟁이 주 3회"	"모든 사용자의 생산성" "MZ세대를 위한..."
② 사용자 · Agent 설계 페르소나·역할·자율성 범위	"그 사람과 몇 번 대화했나?" "에이전트는 어디까지 결정하는가?"	실제 사람 기반 페르소나 자율성 범위 명시 ("정보 수집까지", "실행까지")	MECE 페르소나 표 "적절히 판단한다"
③ 핵심 기능 · 사용자 흐름 시나리오·기능·워크플로우	"고객 문제의 핵심을 직접 치는가?" "기능 수는 줄여도 문제는 끝까지 푸는가?"	문제 → 해결의 최단 경로 1개 "이거만 되면 문제 끝"	기능 10개 나열 (나머지는 "추후") 리소스 제약으로 스콥 축소
④ 기술 구현 설계 스택·아키텍처·프롬프트·메모리·예외	"오늘 중 프로토타입 가능한가?" "대화 사이클에 맞는 속도인가?"	최단 프로토타입 가능한 스택 공통 AGENTS.md에 정리	"최적화" 먼저 고민 "MSA로 확장성..."
⑤ 성과 평가 · 실행 계획 KPI·MVP·로드맵·기대효과	"고객이 '됐다'라고 말할 수 있는가?" "대화 횟수는 어떻게 추적하는가?"	고객 언어로 된 성공 지표 "주 1회 고객 미팅" KPI로	코드 커버리지 95% "DAU 10% 상승" (근거 없이)

이 템플릿을 채울 때 매일 하나씩만 해도 충분한 것

"오늘 실제 사용자와 몇 분 대화했는가?"
이 숫자가 0분인 날은 기획서가 채워지는 게 아니라 멀어집니다. 5명이 팀으로 하니까 — 매일 팀원 중 한 명은 사용자 만나고 오기.

학생이라 유리한 이유 3줄

· 선입견이 적다 — 옛 기획 방식을 "원래"라고 생각 안 함
· 3주 블록이 통째로 있다
· 한국은 AI 유료 구독률 15% (글로벌 0.3%) · 검증자가 가장 많은 시장

이 템플릿의 5섹션은 전부 같은 질문의 5가지 버전입니다 — "고객이 진짜 원하는 게 뭔가?"

15 / 24

Part 3 · 15 min

5명이
함께 만들 때

공통 하네스 · 공통 스킬

16 / 23

Part 3 · The Problem

각자 AI로 짜면 팀 코드가 망가진다 — 합의의 실패

다섯 명이 각자 Cursor를 쓰고,
3주 마감 2일 전에 합치면 — 절반이 안 돈다.

충돌 포인트 · 실제 코드 예시

① 라이브러리 선택이 다르다

// A가 짠 코드
import axios from 'axios';

// B가 짠 코드
const res = await fetch(url);

// C가 짠 코드
import ky from 'ky';

② 컨벤션이 다르다

// A: camelCase
const userName, getUserList()

// B: snake_case
const user_name, get_user_list()

// 파일: user-list.tsx vs UserList.tsx vs user_list.tsx

③ 아키텍처 가정이 다르다

// A: 상태를 Context에
const UserContext = createContext();

// B: 상태를 Zustand에
const useStore = create(...)

// C: 상태를 URL에
useSearchParams()

왜 AI 시대에 특히 심해지는가

원인 1	각자의 에이전트는 "합리적인" 기본값을 각자 고른다. 합리적 × 5 = 비일관
원인 2	코드가 빨리 나오니 합의를 생략한 채 달리기 시작
원인 3	맞춰야 할 분량이 예전보다 수십 배 많다 (같은 시간에 수만 줄)

그래서 3주 마감 2일 전에 벌어지는 일

"절반은 돌아가는데 절반이 깨졌다"
수동 merge에 하루를 통째로 날린다
"차라리 한 명이 다시 쓰자"는 결론 → 5명 중 4명이 놀게 됨
데모 품질이 아이디어보다 1단계 낮아진다

핵심 진단 — 이건 기술 문제가 아니라 합의 문제. AI가 빨라져서 생긴 게 아니라, 팀 AI 워크플로우에 합의 인프라가 없어서 생긴다.

해법은 에이전트에게 공통 규칙을 먼저 박아두는 것.

17 / 24

Part 3 · The Fix

해법 — 팀 레포 루트에 AGENTS.md 하나

실제 예시 — 첫 미팅 1시간에 정할 것들

# Team Harness · 업스테이지 SWM 우리팀

## Project
룸메이트 청소 분쟁을 해결하는 홈캠 에이전트.
사용자: 김현수 (우리 팀원의 실제 룸메이트).

## Stack
- Frontend: Next.js 14, TypeScript, Tailwind
- Backend: FastAPI, PostgreSQL, pgvector
- Agent: Claude Code + Codex
- Package manager: pnpm / uv

## Conventions
- 파일: kebab-case (user-profile.tsx)
- 함수: camelCase (getUserProfile)
- DB 컬럼: snake_case (user_id, created_at)
- HTTP: axios only (fetch · ky 금지)
- 상태: Zustand only (Context 금지)

## Validation Gate
- pnpm lint && pnpm typecheck && pnpm test
- 위 세 개 통과하지 못하면 커밋 금지
- PR 본문에 "작동 영상" 링크 필수

## Review Checklist
- [ ] Unknown-Unknown 3개 이상 나열했는가
- [ ] Validation Plan이 이 PR을 커버하는가
- [ ] AGENTS.md 위반 없는가

도구가 바뀌어도 이 파일은 그대로

도구	파일명	읽는 시점
Claude Code	CLAUDE.md	매 세션 자동
OpenAI Codex	AGENTS.md	매 세션 자동
OpenClaw	SOUL.md	매 세션 자동
Cursor	.cursorrules	매 세션 자동

이름만 다를 뿐 같은 패턴. 마크다운에 쓴 규칙을 에이전트가 세션마다 로드.

Thin Harness, Fat Skills. 하네스(도구의 껍질)는 200줄짜리 얇은 접착제. 누구에게나 똑같아서 복제된다.
그 위의 Skills와 AGENTS.md가 팀을 구분 짓는다. 가치의 90%가 여기에.

효과 — 다섯 명이 각자 AI를 써도 같은 컨벤션, 같은 스택, 같은 검증 기준의 코드를 생산. 수동 merge 하루가 10분 자동 merge로.

Do — 첫 1시간에 AGENTS.md 합의.
Don't — "Cursor 쓸까 Claude Code 쓸까" 토론. 그건 얇은 레이어 위의 얘기.

18 / 24

Part 3 · Ecosystem

올라탈 수 있는 공통 인프라

처음부터 다 만들 필요 없습니다. 검증된 하네스 위에 여러분의 Skills만 얹으세요.

Foundation · 공식

Claude Code · Anthropic

CLAUDE.md 기반 터미널 에이전트

Codex CLI · OpenAI

AGENTS.md 기반, 장시간 자율 실행

Community · 오픈소스 하네스

gstack · Garry Tan (YC)

23개 전문 역할(PM·QA·Designer…)을 스킬로 고정한 "1인 팀" 하네스

oh-my-claudecode · 허예찬

Teams-first 멀티 에이전트. plan → prd → exec → verify → fix 파이프라인

oh-my-codex · 허예찬

Ralphthon 서울 2등 → 2만+ 스타. tmux 병렬 팀 런타임 + $ralph 루프

oh-my-openagent · 김연규

모델 중립 하네스. Claude·Kimi·GLM·GPT를 라우팅. Hash-anchored edits

OpenClaw

로컬 데몬 + 25개 메신저 채널(Slack·Telegram·WhatsApp·iMessage…) 통합 게이트웨이. "local-first personal agent"

Next Frontier

Hermes · Nous Research

"에이전트가 스킬을 직접 만들고, 쓰면서 고친다." — 사람이 스킬을 쓰던 구도가 뒤집히는 실험.

19 / 24

Part 3 · Compound

공통 스킬 저장소 — 반복을 팀 자산으로 (Compound Engineering)

팀 레포 구조

team-repo/
├── AGENTS.md              ← 공통 규칙
├── skills/                ← 공통 스킬
│   ├── new-endpoint/       API 추가 레시피
│   ├── new-component/      프론트 레시피
│   ├── run-tests/          테스트 실행
│   ├── deploy/             배포 자동화
│   └── weekly-demo/        데모 빌드
├── memory/                ← 팀 축적 지식
│   ├── MEMORY.md           인덱스
│   └── *.md                개별 인사이트
└── src/                   ← 실제 코드

사용 — 한 마디로 표준 결과

# 팀원 누구나, 같은 명령 → 같은 결과
$ /new-endpoint 사용자 로그인
  ✓ src/api/auth/login.ts
  ✓ src/api/auth/login.test.ts
  ✓ OpenAPI spec 갱신
  ✓ README 업데이트

$ /new-component HeroCard
  ✓ components/hero-card/index.tsx
  ✓ components/hero-card/story.tsx
  ✓ Tailwind 토큰 사용

"코드베이스는 시간이 갈수록
쉬워져야 한다."

— Compound Engineering · GitHub ⭐ 7K+

이게 왜 중요한가

오늘 한 번 고민해 둔 것 → 내일 한 마디로 재활용
복리처럼 쌓이면 새 기능 추가 속도가 점점 빨라진다
AI는 같은 스킬을 반복 실행할수록 더 정확하게 읽는다

사례 — Team Attention 4명 실제 운영

레포	deep-thought · 1개
CLAUDE.md	159개
스킬	38개
6개월 커밋	265개

실제 운영 중인 스킬: /morning-briefing · /weekly-sync · /compound · /ralphthon-ops

좋은 이메일 vs 좋은 파일링 시스템. 하나는 한 번 도움 되고, 다른 하나는 매번 도움이 된다. 공통 스킬 저장소 = 팀의 파일링 시스템.

팀의 집단 지능이 파일로 쌓인다. 사람이 아니라 리포 자체가 일하는 방식을 강제한다. 이게 장기적 해자.

20 / 24

Part 3 · Day One

팀 첫 미팅 3시간에 정할 3가지

#	결정 사항	구체적으로 정할 것	안 정하면 벌어지는 일
01	Service Spec 1페이지 60분 할애	· 실제 사용자 이름 1명 · 대체재 · 10배 나은 1가지 · Unknown-Unknown 3개 이상 · Validation Plan 체크리스트	3주 중반에 "근데 우리 뭐 만드는 거지?" 상황 팀원마다 다른 서비스를 머리에 그림
02	공통 AGENTS.md 60분 할애	· Stack (FE · BE · DB · 패키지 매니저) · 컨벤션 (네이밍 · 파일 구조) · Validation Gate (lint/test 통과) · 어떤 하네스 위에서 시작할지 (Slide 19 목록)	3주 마감 2일 전 수동 merge에 하루 소모 "차라리 한 명이 다시 쓰자" 결론
03	역할 분담 60분 할애	· 기획 리드 1명 · 에이전트 운영 1–2명 · 검증 1명 (Validation Plan 책임) · 데모 1명 (발표·영상) · 문서 1명 (README · memory/)	전원이 코딩만 하다 데모 당일 영상 없음 문서가 없어 심사위원이 뭘 본지 모름

첫 미팅 Agenda 템플릿 (3시간)

0:00–0:15 각자 "내가 만들고 싶은 것" 2분 발표
0:15–1:00 Service Spec 1페이지 합의
1:00–1:10 휴식
1:10–2:10 AGENTS.md 합의 + 하네스 선택
2:10–2:50 역할 분담 + 첫 주 마일스톤
2:50–3:00 레포 생성 · 첫 커밋

AX는 제품이 아니라 사람과 문화

"AI를 쓰는 인터페이스는 빠르게 바뀌어요. 변하지 않는 건 사람과 문화뿐. IDE→CLI→Claw로 계속 이동 중. 인터페이스 쫓지 말고, Skills를 쌓는 사람과 문화에 베팅하세요."

이 세 개 정하는 데 3시간. 안 정하면 3주가 갑니다.

21 / 24

Summary

3줄 요약

01

무게중심은 "어떻게"에서 "무엇을"로 이동했다

실행이 공짜가 된 세계에서는 맥락을 설계하는 사람이 이깁니다. Karpathy · Ubl · Andrew Chen이 같은 방향을 말하고, Ralphthon 1등팀이 169K LOC·0회 개입으로 증명했습니다.

이번 3주 프로젝트에서,
여러분은 무엇을
증명할 것인가?

코드 줄 수가 아니라, 이 질문에
한 문장으로 답할 수 있는 팀이 이깁니다.

"중요한 건 장소가 아니라 문제의 크기입니다.
저는 아직 제 문제의 크기를 모릅니다. 그걸 알아내러 왔습니다."

— SF 체류 기록 중 · 2026.03

22 / 23

Thanks

감사합니다.