2장. 최소 팀 셋업과 리뷰 리듬
데일리 10분/주간 30분
혼자서도, 열 명이어도 가능한 구조
프로토타입 중심 기획의 독특한 점은 팀 규모에 구애받지 않는다는 것이다. 1인 기획자가 GPT와 v0 만으로 진행할 수도 있고, 10명이 넘는 대규모 팀이 운영할 수도 있다. 핵심은 규모가 아니라 구조다.
전통적인 기획 조직은 역할이 수직적으로 분리된다. 기획자가 문서를 쓰면 디자이너가 그림을 그리고, 개발자가 코드를 짠다. 각 단계마다 인수인계가 발생하고, 그때마다 정보가 손실된다. 반면 프로토타입 중심 조직은 수평적으로 협업한다. 같은 Figma 파일에서 동시에 작업하며, 실시간으로 피드백을 주고받는다.
이런 구조가 가능한 이유는 도구의 민주화다. v0는 개발자가 아니어도 실제 동작하는 코드를 생성할 수 있게 하고, Figma는 디자이너가 아니어도 디자인과 프로토타입을 만들 수 있게 한다. 기획자가 직접 UI를 생성하고, 개발자가 디자인을 수정하며, 디자이너가 인터랙션 로직을 정의할 수 있다. 역할의 경계가 흐려지면서 협업의 밀도가 높아진다.
4인 코어 시스템의 설계
최적의 팀 구성은 4인이다. 이는 아마존의 "Two Pizza Team" 원칙과도 같다. 의사소통 경로가 6개(4C2)로 관리 가능한 수준이고, 각자의 역할이 겹치지 않으면서도 시너지를 낸다.
기획자 하루
오전 9시, 기획자은 전날 Figma 코멘트를 확인한다. 긴급 표시된 항목을 우선 처리한다. 9시 30분, GPT에 "어제 피드백을 바탕으로 체크아웃 플로우 개선안 3개 제시"를 요청한다. 10시 데일리 리뷰를 진행하며 화면을 공유한다.
오후에는 주로 NOTE 작성과 시나리오 정리에 집중한다. 각 화면의 엣지케이스를 찾아내고, Given-When-Then 형식으로 테스트 케이스를 작성한다. 저녁 6시, 그날의 CHANGE LOG를 정리하고 내일 데모할 항목을 선정한다.
디자이너의 v0 활용법
디자이너는 코드도 다룬다. v0에서 생성한 컴포넌트를 Figma로 가져와 정제하는 것이 주 업무다. "shadow-lg를 shadow-xl로 변경"같은 세부 조정을 v0에 직접 지시한다.
Figma에서는 Auto Layout과 Variants를 설정한다. 버튼 하나도 Default/Hover/Active/Disabled 4가지 상태를 만든다. 컬러 토큰을 정의해 다크모드 전환이 한 번에 되도록 한다. 디자이너의 목표는 "누가 작업해도 일관성이 유지되는 시스템"을 만드는 것이다.
운영의 즉각 결정 원칙
운영자는 회의 중 가장 많이 말하는 사람이다. "실제로는요..."로 시작하는 현실적 제약을 알려준다. 하지만 동시에 가장 빨리 결정하는 사람이기도 하다.
"쿠폰 중복 적용이 가능한가요?"라는 질문에 "원칙적으로 불가하지만, 첫 구매 쿠폰과 카테고리 쿠폰은 예외"라고 즉답한다. 애매한 경우 "일단 불가로 진행하고, 다음 주 정책팀 확인 후 수정"처럼 조건부 결정을 내린다. 운영자의 즉답이 프로젝트 속도를 좌우한다.
QA/리서치의 관찰 기법
QA는 말을 아낀다. 대신 관찰하고 기록한다. 데모를 볼 때 클릭 횟수를 센다. "장바구니까지 7 클릭인데, 경쟁사는 4 클릭입니다"라고 수치로 말한다.
세션 리플레이 도구를 활용해 실제 사용 패턴을 분석한다. "사용자 73%가 필터를 찾지 못하고 스크롤만 반복했습니다"같은 데이터를 제시한다. 주관적 의견이 아닌 객관적 사실로 개선점을 찾아낸다.
1인 체제: 고독하지 않은 혼자 작업
프리랜서나 스타트업 초기에는 혼자 작업하는 경우가 많다. 이때 중요한 것은 '가상의 팀'을 만드는 것이다.
러버덕 디버깅의 기획 버전
개발자들이 고무 오리에게 코드를 설명하듯, 기획자도 가상의 청자에게 설명한다. 녹화 프로그램으로 매일 5분 데모를 녹화한다. "오늘은 장바구니 Empty 상태를 개선했습니다. 기존에는 텅 빈 화면이었는데, 이제 추천 상품을 보여줍니다"라고 말하며 화면을 클릭한다.
녹화를 다시 보면 스스로 문제를 발견한다. "아, 추천 상품이 너무 많네. 4개로 줄여야겠다"같은 깨달음을 얻는다. 이 영상을 Slack 개인 채널에 올려 일종의 일지로 활용한다.
AI를 리뷰어로 활용
GPT나 Claude를 리뷰어로 활용한다. 스크린샷을 올리고 "이 화면의 사용성 문제점 5가지를 지적해 줘"라고 요청한다. "버튼 크기가 모바일 터치 타겟 최소 크기(44px) 보다 작습니다"같은 구체적 피드백을 받을 수 있다.
매일 저녁 "오늘 작업한 내용을 요약하고, 내일 우선순위 3가지를 제안해 줘"라고 요청해 다음 날 계획을 세운다. AI는 지치지 않는 동료가 된다.
10인 이상: 대규모 팀의 소규모 운영
팀이 10명을 넘어가면 전체 회의는 비효율적이다. 이때는 '셀(Cell)' 구조를 도입한다.
3-3-3-1 구조
10명을 3개 셀로 나눈다.
셀 A (3명): FO 홈/카테고리/검색
셀 B (3명): FO 상품/장바구니/결제
셀 C (3명): BO 전체
코디네이터 (1명): 셀 간 조율
각 셀은 독립적으로 데일리를 진행한다. 코디네이터만 모든 데일리에 참여해 정보를 연결한다. 주간 리뷰는 전체가 모이되, 각 셀당 5분씩만 발표한다.
비동기 브리핑 보드
Notion이나 Atlas, 레드마인 등 프로젝트 관리툴을 이용해 '데일리 브리핑 보드'를 만든다. 각 셀이 매일 3줄 요약을 올린다.
오늘 완료: Cart Empty 상태 완성
내일 계획: Cart 수량 변경 UI
도움 필요: 재고 부족 시 UX 정책
다른 셀은 댓글로 의견을 남긴다. 전체 회의 없이도 상황을 파악할 수 있다.
시간대가 다른 글로벌 팀
Follow-the-Sun 모델
한국, 인도, 미국에 팀이 분산되어 있다면 24시간 개발이 가능하다. 한국 팀이 퇴근할 때 인도 팀이 출근하고, 인도 팀이 퇴근할 때 미국 팀이 출근한다.
핸드오프 문서를 표준화한다.
[KR→IN 핸드오프 2025-01-15]
완료: PDP 옵션 선택 UI
진행중: Cart 수량 변경 (70%)
이슈: API 응답 지연 (2초→5초)
요청: Cart Empty 추천 로직 검토
각 팀이 출근하면 먼저 핸드오프 문서를 확인하고 작업을 이어간다.
비디오 메시지 릴레이
텍스트로는 뉘앙스가 전달되지 않는다. 각 팀이 퇴근 전 3분 비디오를 녹화한다. 화면을 공유하며 "여기까지 완료했고, 이 부분이 고민입니다"라고 설명한다.
다음 팀은 출근해서 비디오를 보고, 마치 옆자리 동료가 설명한 것처럼 작업을 이어간다. 시차를 넘어 연속성을 유지한다.
리뷰의 심리학
침묵을 깨는 기법
"괜찮은 것 같습니다"만 반복되는 리뷰는 죽은 리뷰다. 침묵을 깨는 몇 가지 기법.
강제 비판 룰: 모든 참석자가 최소 1개의 개선점을 말해야 한다. 없다면 "색상이 0.5% 더 진하면..."이라도 찾는다. 억지로라도 찾다 보면 문제가 보인다.
역할 스위칭: 디자이너가 기획 관점에서, 기획자가 개발 관점에서 피드백한다. 익숙하지 않은 관점에서 보면 새로운 문제가 발견된다.
극단적 사용자: "80세 할머니라면?", "첫 스마트폰 사용자라면?"같은 극단적 페르소나를 설정한다. 평범한 관점에서 벗어나면 숨은 문제가 드러난다.
피드백의 톤 관리
비판적 피드백을 건설적으로 전달하는 기술.
SBI 모델:
Situation: "장바구니 페이지에서"
Behavior: "수량 변경 버튼이 너무 작아서"
Impact: "실수로 삭제 버튼을 누를 것 같습니다"
샌드위치는 금지: "좋은데... 그런데... 하지만 좋아요"같은 샌드위치 피드백은 혼란만 준다. 차라리 "개선점 3개, 잘한 점 1개"처럼 명확히 구분한다.
번아웃 방지 시스템
금요일 오후 리뷰의 숨은 의도
주간 리뷰를 금요일 오후에 하면 좋은 이유는 주말 동안 무의식적 사고(Incubation)가 일어나기 때문이다. 금요일에 문제를 인식하고 주말을 보내면, 월요일 아침에 해결책이 떠오르는 경우가 많다.
동시에 "주말엔 작업 금지" 규칙을 명확히 한다. 금요일 리뷰 후에는 Figma나 v0를 닫는다. 긴급한 아이디어는 메모만 하고 월요일에 구현한다. 지속가능한 리듬이 단기 스프린트보다 중요하다.
실패 로그 축하하기
매주 '이번 주의 실패' 시간을 갖는다. "모바일에서 버튼이 잘려서 3번 재작업했습니다"같은 실패를 공유한다. 실패를 숨기지 않고 축하하면, 팀은 더 과감하게 실험한다.
실패 로그도 CHANGE LOG처럼 기록한다.
[FAIL] 2025-01-15 | 무한 스크롤 구현 | 성능 이슈 | 페이지네이션으로 롤백 | DO
나중에 비슷한 시도를 할 때 참고가 된다.
성과 측정의 함정
정량 지표의 맹점
"데일리 참석률 100%"가 항상 좋은 것은 아니다. 억지로 참석하느라 작업 흐름이 깨질 수 있다. 오히려 "필요한 사람만 참석률"이 의미 있다. 기획자와 디자이너는 필수, 운영자와 QA는 안건이 있을 때만 참석하는 유연성이 필요하다.
"CHANGE LOG 항목 수"도 마찬가지다. 많다고 좋은 게 아니다. "의미 있는 결정 수"가 중요하다. 폰트 크기 1px 조정을 10번 하는 것보다, 플로우 개선을 1번 하는 게 가치 있다.
정성 지표의 중요성
수치화하기 어렵지만 중요한 지표들.
에너지 레벨: 데일리 시작할 때와 끝날 때 표정이 다른가? 활기가 있는가?
자발적 기여: 담당이 아닌 영역에도 의견을 내는가? 퇴근 후에도 아이디어를 공유하는가?
학습 속도: 같은 실수를 반복하는가? 새로운 시도를 하는가?
이런 지표는 팀장이 일기처럼 기록한다. "오늘 디자이너가 처음으로 API 구조에 대해 질문했다"같은 작은 신호가 팀의 성장을 보여준다.
도구를 넘어선 문화
"No Blame" 문화
문제가 생기면 "왜"가 아니라 "어떻게"를 묻는다. "왜 버튼이 안 보이게 만들었어요?"가 아니라 "어떻게 하면 버튼이 더 잘 보일까요?"로 접근한다.
CHANGE LOG에도 "실수"나 "잘못"이란 단어는 쓰지 않는다. "개선", "수정", "보완"을 쓴다. 언어가 문화를 만든다.
"Yes, And" 원칙
즉흥극의 기본 원칙을 리뷰에 적용한다. "그건 안 될 것 같은데"보다 "그것도 좋고, 이것도 추가하면 어떨까"로 반응한다.
반대 의견도 "Yes, And"로 표현할 수 있다. "모바일 우선도 좋고, 다만 우리 사용자 70%가 데스크톱이니 병행하면 어떨까요?"처럼 긍정의 언어로 방향을 조정한다.
사람이 시스템을 만든다
최고의 도구와 프로세스도 결국 사람이 운영한다. 4인 코어든 1인 체제든, 중요한 것은 리듬을 만들고 지키는 사람이다.
데일리 10분과 주간 30분은 단순한 회의가 아니다. 팀이 하나가 되는 의식이고, 프로토타입이 진화하는 시간이다. 이 리듬 속에서 개인은 성장하고, 팀은 단단해지며, 제품은 완성되어 간다. 긴 회의는 프로젝트가 잘 못 흘러가고 있는 징조이다.
도구는 계속 바뀔 것이다. v0 대신 다른 AI 도구가 나올 수 있고, Figma 대신 새로운 협업 툴이 등장할 수 있다. 하지만 "작게, 자주, 명확하게"라는 원칙과 "데모로 시작해 결정으로 끝내는" 리듬은 변하지 않는다.
