토요일 아침에 기획이 시작됐고, 일요일 밤에 배포가 끝났어요

Aster.duck에는 CoffeeDuck(커피)과 WineDuck(와인)이 있었어요. 세 번째 서비스로 SakeDuck(사케)을 만들기로 했어요. 주말 동안.

“주말 동안 서비스 하나”라는 게 말은 쉬워요. 기획부터 디자인, 개발, QA, 배포까지 — 보통은 몇 주가 걸리는 프로세스예요. 이번에 다른 건 에이전트 팀이 실행을 병렬로 맡는다는 거였어요. PO 1명은 방향만 잡아도 됐어요.

이 글은 그 48시간의 기록이에요. 무엇을 만들었는지보다, 어떤 순서로 일이 흘러갔는지, 그리고 에이전트 팀에서 누가 무엇을 했는지를 중심으로 정리해요.

타임라인

토요일 오전 — 기획

10:00 — 사케 학습 자료(sake-study)가 이미 10개 문서로 정리돼 있었어요. 기초, 양조, 등급, 테이스팅, 서빙, 페어링, 산지까지. 이걸 기반으로 서비스 설계를 시작했어요.

에이전트 팀에 첫 태스크를 넣었어요: “SakeDuck 서비스 기획 및 디자인. 개발은 제외.”

10:30 — 산출물이 나오기 시작했어요. IA(정보구조), 사용자 플로우, 컬러 토큰, 경쟁 분석, 브랜드 포지셔닝. 약 8개 문서.

IA를 검토하면서 결정을 내렸어요:

온도별 비교 테이스팅(SK-7): v1에서 제외. 사용 빈도 낮고 개발 범위 큼.
향 시각화: D3 Wheel 대신 계층 리스트. 사케 향 분류가 7범주밖에 안 돼서 Wheel로 만들면 허전함.
기록 온도 필드: P0(필수)가 아니라 P1(선택).
사케 등록: 사용자 직접 등록 허용.

이 결정들을 기획서에 반영하고, 추가 수정 요청 4건을 넣었어요.

토요일 오후~저녁 — 기획 검토 + 디자인

기획서를 전체 검토했어요. 5건의 미반영 사항을 발견하고 수정 요청을 넣었어요:

사케 등록 화면이 IA에 없음
온도 관련 잔존 (SK-7 제외했는데 필드가 남아있음)
사진 기능 없는데 이미지 영역이 남아있음
일본어 표기가 원문만 (한글/영어 독음 우선 + 원문 병기로 변경)
브랜드 포지셔닝이 온도 중심 (온도 빼면 재정립 필요)

Sake Study 기획과 디자인도 병렬로 요청했어요.

토요일 밤~일요일 새벽 — 개발 착수

개발 담당이 합류했어요. 에이전트 팀이 만든 코드를 리뷰하고 이슈를 잡기 시작했어요.

에이전트 팀이 만든 코드를 열었어요. 코드 자체는 잘 짜여있었어요. SakeStudy(학습 콘텐츠)는 탄탄하게 구현돼 있었어요.

그런데 사용자가 사케를 직접 기록하고 탐색하는 화면 — SakeDuck 메인 서비스 — 가 없었어요. “기획 + 디자인” 태스크를 줬는데 팀이 자연스럽게 콘텐츠 쪽을 먼저 구현한 거였어요. DB 스키마도 없었어요.

개발 담당이 DB 스키마(테이블 8개 + 아로마 시드 50개)를 만들고, dev DB에 배포했어요. 이슈 3건(허브 카드 누락, 홈 라우트 없음, CSS 충돌)도 수정.

일요일 오전 — QA Round 1–2

QA 담당이 SakeDuck QA를 시작했어요.

Round 1 결과: 크리티컬 2건 — 내 테이스팅/내 사케 API 에러. 원인은 팀이 FE를 만들었는데 BE 엔드포인트를 빠뜨린 거였어요. FE가 먼저 구현되고 BE가 나중에 연결되는 흐름에서 자주 나오는 이슈예요 — 화면은 있는데 데이터가 안 붙는 거요. 개발 담당이 30분 만에 핫픽스.

Round 2 결과: 크리티컬 1건 — 사케 등록 저장 안 됨. 양조장을 직접 타이핑하면 validation 실패인데 에러 표시가 없었음. 사용자 입장에서는 버튼을 눌렀는데 아무 일도 안 일어나는 것처럼 보이는 거예요. 개발 담당이 자동 스크롤 + blur 시 자동 선택으로 수정.

병렬로 다른 QA 트랙도 움직였어요. 한 QA 담당은 WineDuck PRD QA를 Round 4–6까지 돌렸고, 테스트케이스 120개를 작성해 PRD 크리티컬 0건을 확인했어요. 또 다른 QA 담당은 CoffeeDuck QA와 SakeDuck QA Round 1–2, 그리고 최종 PRD Sanity Test까지 맡았어요.

일요일 오후~밤 — 수정 + 최종 QA + 배포

남은 이슈들은 성격이 달랐어요. 크리티컬은 아니었지만 UX 레벨의 문제들 — 언어 전환 버튼이 특정 화면에서 안 보이고, 로그인 환영 문구가 영어로만 나오고, QuickTasting 완료 후 리다이렉트 경로가 어색했어요. 하나하나는 작지만, 이런 게 쌓이면 서비스 전체 완성도에서 티가 나요.

개발 담당이 이슈들을 잡는 동안 SakeStudy 라우트도 확인했어요. 처음에 “라우트가 안 된다”고 보고됐는데, 실제로는 slug 차이였어요 (brewing vs brewing-process). 기획서와 코드가 서로 다른 이름을 쓴 거였어요. 3분 만에 해결됐어요.

23:55 — QA 담당이 PRD 전체 Sanity Test를 돌렸어요.

결과: 핵심 라우트와 주요 사용자 흐름 기준 크리티컬 0건.

CoffeeDuck 핵심 라우트 PASS ✅
WineDuck 핵심 라우트 PASS ✅
SakeDuck 핵심 라우트 PASS ✅
SakeStudy 핵심 라우트 PASS ✅
i18n KO/EN/JA 정상 ✅

세부 라우트 수치는 내부 QA 리포트에서 관리했고, 게시 글에서는 “크리티컬 0건으로 PRD Sanity 통과”라는 결론만 남기기로 했어요.

00:11 — SakeDuck PRD 배포 완료.

누가 무엇을 했는가

역할	담당	한 일
PO	콸	방향 결정, OQ 결정(8건), 기획 검토, 최종 승인
오케스트레이터	에이전트1	태스크 발행, 기획 검토, 팀 간 커뮤니케이션, QA 리포트 확인
개발	에이전트2	코드 리뷰, DB 스키마, API 핫픽스, 이슈 수정, 배포
QA A	에이전트3	WineDuck PRD QA, Round 4~6, 테스트케이스 120개 작성
QA B	에이전트4	CoffeeDuck QA, SakeDuck QA Round 1~2, PRD Sanity Test
기획/디자인	에이전트 팀	IA, 사용자 플로우, 개념 정의서, 컬러 토큰, Pencil 디자인, FE 구현

이 분담에서 핵심은 판단 영역이 겹치지 않았다는 거예요. 에이전트 팀은 실행했고, 개발 담당은 코드를 검증했고, QA 담당은 사용자 경험을 검증했어요. PO는 방향을 정했고, 오케스트레이터는 전체를 연결했어요. 각자가 자기 영역에만 집중할 수 있었기 때문에 병렬 실행이 가능했어요.

승인 게이트가 작동한 순간들

이전 글에서 다룬 원칙이 실전에서 어떻게 적용됐는지.

작동한 순간:

OQ 결정 8건 — 에이전트가 기획서를 만들었지만, “온도 비교 빼자”, “향은 리스트로 하자” 같은 결정은 PO가 직접.
PRD 배포 — dev QA 크리티컬 0건 확인 후에만 main 머지. 개발 담당이 “지금 배포할까?”가 아니라 콸이 “배포해줘”로 트리거.
DB 스키마 — 개발 담당이 만들었지만 콸이 “dev에 세팅하고 배포해줘”를 명시적으로 지시한 뒤 실행.

실패한 순간:

오케스트레이터 역할의 에이전트가 콸 확인 없이 에이전트 팀에 태스크를 넣은 적이 있었어요. “확인 → 승인 → 실행” 순서를 어긴 거예요.
왜 일어났냐면 — 오케스트레이터 입장에서는 “기획이 완성됐으니 디자인을 시작하는 건 당연한 다음 단계”처럼 보였을 거예요. 하지만 그 판단 자체가 이미 PO 영역이에요. “자연스러운 흐름”처럼 보이는 순간이 가장 위험해요.
이후 “외부 실행 전 2문장 확인” 규칙을 재확인하고, 예외 없이 지키기로 했어요.

교훈: 규칙은 실패하는 순간에 실체화돼요. 문서에 적혀있는 것만으로는 부족하고, 한 번 어기고 복구하는 경험이 있어야 규칙이 몸에 붙어요.

48시간에서 배운 것

1. 기획 품질이 개발 속도를 결정해요.

IA, 사용자 플로우, 개념 정의서가 탄탄하면 — 개발 팀이 “이게 뭐야?”를 물을 일이 줄어요. 이번에 기획 검토에서 미반영 5건을 잡은 게 나중에 수정 비용을 크게 줄였어요.

그중 가장 중요한 건 브랜드 포지셔닝이었어요. 온도 기반 비교를 뺐는데 포지셔닝은 온도 중심으로 남아있었어요. 기획 검토 단계에서 잡지 않았으면 디자인과 개발이 서로 다른 방향으로 달렸을 거예요. 기획서는 팀이 같은 그림을 보기 위한 도구예요.

2. QA는 사람이 해야 해요.

QA 담당 둘이 발견한 이슈들 — API 에러, 패딩 불일치, validation 무반응 — 은 자동 테스트로는 잡기 어려운 것들이에요. “실제로 눌러보고, 이상하면 말하는” 과정이 핵심이었어요.

자동 테스트가 커버하는 건 “정상 경로”예요. 하지만 이번에 발견된 건 대부분 예상치 못한 경로였어요 — 양조장 입력창에서 blur가 일어날 때 에러 없이 저장이 안 되는 것처럼요. 이런 건 사람이 직접 써봐야 잡혀요.

3. 핫픽스 속도가 프로젝트 속도예요.

QA에서 크리티컬이 나왔을 때, 개발 담당이 30분 안에 원인 찾고 수정하고 푸시한 게 — 48시간 안에 끝낼 수 있었던 결정적 이유예요.

핫픽스 속도는 기술 부채의 반대말이에요. 코드 구조가 명확할수록 원인을 빨리 찾아요. 에이전트 팀이 만든 FE 코드가 읽기 쉽게 구성돼 있었기 때문에 개발 담당이 빠르게 찾아 들어갈 수 있었어요.

기획 검토하는 동안 디자인이 진행되고, CoffeeDuck/WineDuck FAQ 다국어(i18n) 작업이 SakeDuck 기획과 같은 날 병렬로 돌아가고, SakeDuck QA 하는 동안 WineDuck QA도 함께 진행됐어요. PO 1명이지만, 에이전트 팀 덕에 동시에 여러 트랙이 움직여요.

이게 가능하려면 각 트랙이 서로의 결과를 기다리지 않아야 해요. SakeDuck 기획과 WineDuck i18n은 의존성이 없었어요. 의존성 없는 작업을 식별해서 병렬로 보내는 것 자체가 PO의 역할이에요.

이 구조가 반복될 수 있는 이유

CoffeeDuck이 먼저였고, WineDuck이 두 번째였어요. SakeDuck은 세 번째예요.

세 서비스를 만드는 동안 프로세스가 비슷하게 흘렀어요. PO가 방향을 잡고, 에이전트 팀이 기획/디자인/개발을 실행하고, 개발 담당이 코드를 검증하고, QA 담당이 QA를 돌려요. 이 구조가 반복될 수 있는 건 — 각 역할이 서로를 기다리지 않아도 되기 때문이에요.

개발 담당이 DB 스키마를 만드는 동안 QA 담당이 QA를 준비했어요. QA 담당이 WineDuck QA를 돌리는 동안 SakeDuck 핫픽스가 진행됐어요. 이 병렬성은 의존성이 명확하게 끊겨 있어야 가능해요. 의존성을 끊는 판단 — “이건 저거 끝나기 전에 시작할 수 있다” — 이 PO의 실질적인 일이에요.

정리

SakeDuck은 토요일 아침에 기획이 시작돼서 일요일 밤에 프로덕션에 올라갔어요.

PO가 방향을 정하고, 에이전트 팀이 기획/디자인/개발을 실행하고, 개발 담당이 코드를 잡고, QA 담당이 QA를 돌리고, 오케스트레이터가 전체를 오케스트레이팅했어요.

주말 전체 발행된 태스크 11개(SakeDuck 직접 8 + 병렬 작업 포함), QA 라운드 복수 회(SakeDuck 2 + WineDuck 다수 + Sanity 1), PRD 라우트 39/42 PASS.

“주말 동안 서비스 하나”가 가능하냐는 질문은 사실 기술 문제가 아니었어요. 의사결정 속도와 실행 분리가 얼마나 잘 돼있냐의 문제였어요. PO가 결정해야 할 것들을 빠르게 결정하고, 나머지를 에이전트 팀에 맡기고, 품질은 검증으로 잡는 — 이 구조가 작동하면 48시간은 충분한 시간이에요.

이번에 가장 어려웠던 건 기술이 아니었어요. 태스크 스코프를 명확하게 전달하는 거였어요. “기획 + 디자인”이라고 줬는데 팀이 학습 콘텐츠를 먼저 만들어버린 것처럼 — 에이전트 팀은 모호한 스코프를 나름대로 해석해요. 다음에는 “메인 서비스 먼저, 학습 콘텐츠는 별도 태스크”를 명시적으로 분리하기로 했어요. 태스크 설명의 정밀도가 실행 품질을 결정해요.

PO 1명 + 에이전트 팀으로 서비스 하나를 만들 수 있다는 걸 직접 확인한 주말이었어요.

이 시리즈의 이전 글: 에이전트에게 뭘 맡기고, 뭘 직접 승인할 것인가

주말에 서비스 하나 완성 — PO 1명과 에이전트 팀의 사케덕 48시간