‘계획’이 곧 ‘릴리즈’가 될 때까지 — 네이버랩스 AKI 스마트워치, 7개 제품을 하나의 박자로 묶은 하이브리드 애자일 PMO 13개월

PM 컨설턴트 노트 · 네이버랩스 AKI 하이브리드 애자일 PMO

하드웨어·펌웨어·앱·서버·AI가 한 제품 안에 섞인 아동용 인공지능 스마트워치 AKI. 서로 릴리즈 주기가 다른 7개의 제품을 어떻게 한 박자로 묶어 출시까지 끌고 갔을까요. 프로젝트리서치는 이 프로젝트에 품질관리 조직(QMO)으로 13개월간 상주하며, 통신사(KT) 인증 마일스톤과 애자일 스프린트를 겹쳐 돌리고, 협업 도구를 Github Enterprise에서 Jira로 갈아타 ‘계획이 곧 릴리즈가 되는’ 리듬을 회복시켰습니다. 한 PM 컨설턴트의 시선으로 정리한 하이브리드 제품 관리 현장 백서입니다.

소프트웨어 프로젝트의 애자일은 익숙합니다. 그런데 양산이 걸린 하드웨어 제품을 애자일로 관리하면 이야기가 완전히 달라집니다. 스프린트는 “다음 스프린트에 하면 되지”가 통하지만, 금형·부품·통신사 인증은 한 번 날짜를 놓치면 되돌릴 수 없습니다. AKI 프로젝트는 이 두 세계 — 되돌릴 수 없는 게이트와, 매주 도는 스프린트 — 를 한 관리체계 안에 겹쳐 얹은 하이브리드였습니다. 이 글은 그 겹치기를 현장에서 어떻게 설계했는지에 관한 기록입니다.

Background일곱 개의 제품, 하나의 손목 — 프로젝트의 성격

AKI는 아이 손목에 채우는 인공지능 스마트워치였습니다. 위치를 확인하고(WPS 측위), 음성으로 대화하고(음성 인식), 보호자 앱과 통신하는 제품. 겉보기엔 작은 워치 하나지만, 그 안에는 서로 성격이 완전히 다른 여러 제품이 들어 있었습니다.

그래서 관리의 무게중심은 “기능을 빨리 만든다”가 아니라 “서로 다른 제품을 한 품질 게이트에 정렬시킨다”에 있었습니다. 이 프로젝트에서 애자일은 목적이 아니라 도구였고, 목적은 되돌릴 수 없는 출시 날짜를 안전하게 통과하는 것이었습니다.

The Architecture세 겹으로 돌린다 — 애자일·게이트·기준선의 병렬 관리

AKI 관리체계의 골격은 세 개의 관리 레이어를 동시에 돌린 것입니다. 애자일로 통일하지도, 전통적 워터폴로 통일하지도 않았습니다. 각 레이어가 서로 다른 것을 보증했습니다.

The Product Map7개 제품 × 통합 — 각자의 박자, 하나의 보드

애자일 PMO의 실전은 이 지점에서 시작됐습니다. 7개 제품을 하나의 저장소(repository)×역할 매트릭스로 묶되, 같은 보드 컬럼은 공유하고 릴리즈 주기만 제품별로 달리 준 것입니다. 아래는 각 제품 트랙과, PMO가 통합 시 실제로 점검한 포인트입니다.

릴리즈 케이던스는 제품 성격에서 유래(서버 주간·앱 격주·워치 펌웨어 게이트). 같은 스크럼반 보드 컬럼(Backlog→UI/UX→Dev→QA→Fix→Ready)을 복제하되 릴리즈 주기만 다르게 준 실용적 설계. [트랙·케이던스 구조=관측 · 상세 임계=일반화]

Pace-making ①두 개의 박자 — KT 인증 마일스톤 × AKI 스프린트

이 프로젝트의 페이스는 하나의 박자가 아니었습니다. 바깥에서 오는 큰 박자와 안에서 도는 작은 박자가 겹쳐 돌았습니다.

큰 박자(마일스톤)는 되돌릴 수 없으니 역산으로 못을 박고, 작은 박자(스프린트)는 그 안에서 반복하며 조정했습니다. 9단계 Phase-Gate는 양산일(M0)에서 역산한 마스터 스케줄의 뼈대였습니다.

각 게이트는 “팀 타당성 체크리스트 + 게이트 승인서” 2종을 강제해 형식이 아닌 실제 승인 노드가 되게 함. 하드웨어 라인(설계→DV→PV→양산)과 소프트웨어 라인(코딩→시험→릴리즈)을 한 마스터 스케줄에 병렬로 얹음. [게이트 구조=관측 · 실제 일자=일반화]

Pace-making ②도구를 바꾸자 리듬이 돌아왔다 — Github Enterprise → Jira

가장 극적인 페이스메이킹은 협업 도구를 바꾼 것이었습니다. 처음에는 Github Enterprise + ZenHub 기반의 스크럼반으로 시작했습니다. ATDD(인수 테스트 주도 개발) 흐름과 잘 맞았고, 초기엔 잘 돌았습니다. 그런데 규모가 커지자 문제가 드러났습니다.

전환의 방아쇠는 명확했습니다 — 사용자 스토리의 난립이 실제 실패 지점이었습니다. 스토리 단위 관리가 규모를 감당 못 하자, 관리 단위를 피처(Feature)로 올리고 도구를 Jira로 옮겼습니다. 그리고 이 이관을 서비스 중단 없이 해냈습니다.

여기에 교훈 하나가 더 있었습니다 — Jira 버그에 원인·대책을 안 적으면 QC가 부작용(side-effect)을 추정할 수 없어 확인 시험이 낭비됩니다. 그래서 “원인·대책 미입력 시 확인 시험 없이 Fail 처리”를 규약으로 못박았습니다. 도구를 바꾸는 것으로 끝이 아니라, 그 도구를 쓰는 규율까지 설계해야 리듬이 완성됩니다.

Quality Gate품질을 게이트로 — CBT→출시→RC 다단 임계

7개 제품을 한 출시에 묶으려면, 품질도 하나의 게이트 체계로 집계돼야 합니다. AKI의 품질 게이트는 같은 지표의 통과선을 단계별로 올리는 방식이었습니다.

같은 품질 항목이 CBT→출시→RC로 갈수록 통과선이 올라감(예: 측위 성공률을 단계마다 상향). 음성 인식은 정확도·재현율·정밀도 + 혼동행렬(TP/TN/FP/FN)로 정량화. 결함은 유입 단계·심각도·도메인으로 표준 분류. [다단 구조=관측 · 구체 임계 수치=일반화]

멀티플랫폼 시험 — 한 체계로 집계

워치·Android·iOS 각 플랫폼별로 테스트케이스를 별도 워크북으로 관리하되, 집계 시트에서 PASS/FAIL/N/A 비율을 자동 산출했습니다. 그리고 N/A는 반드시 사유를 남겼습니다 — “왜 N/A인지”를 안 적으면 품질 게이트가 무력화되기 때문입니다.

The Workflow스토리가 흐르는 길 — ATDD 스크럼반 7단계

실행 레이어(L1)의 실제 작업 흐름은 ATDD(인수 테스트 주도 개발) + 스크럼반이었습니다. 기능을 만들기 전에 “이 기능이 통과했다고 어떻게 아는가”(인수 체크리스트)를 먼저 정하고, 그 다음 개발했습니다.

인수 테스트가 양방향으로 돌았습니다 — 스토리 작성 → 인수 체크리스트 작성 → 구현 → 인수 시험 → 릴리즈 → 인수 케이스 보강 → 최종 리뷰. 개발이 끝이 아니라, 인수 케이스를 다시 다듬어 다음 릴리즈 품질을 올리는 개선 루프였습니다. 여기에 스크럼(반복·회고·데모)과 칸반(WIP 제한·흐름 관리)을 결합해, 이벤트·요청 기반으로도 대응하면서 리드타임을 지속 최적화했습니다.

Outcomes성과, 그리고 정직한 경계

정직해야 할 경계는 분명합니다.

Playbook재현 노트 — 하이브리드 제품을 애자일로 관리한다면 Do / Don’t

Closing마치며 — 하이브리드는 타협이 아니라 설계다

AKI 프로젝트의 결론을 한 문장으로 줄이면 이렇습니다 — 하이브리드 관리는 애자일과 워터폴의 어정쩡한 타협이 아니라, 서로 다른 리스크를 서로 다른 장치로 막는 정교한 설계라는 것. 소프트웨어의 빠른 반복은 스프린트로, 하드웨어의 되돌릴 수 없는 양산은 게이트로, 계약적 준거는 기준선으로. 그리고 이 세 겹이 어긋나지 않게 묶어준 것이 협업 도구의 리듬이었습니다.

7개의 제품을 하나의 손목 위에 올린 이 경험은, 이후 프로젝트리서치가 다른 하이브리드 제품·플랫폼 프로젝트에서 “애자일 실행 위에 게이트를, 외부 마일스톤에 내부 스프린트를” 재사용하는 토대가 됐습니다. 좋은 방법론은 시장에 많습니다. 드문 것은, 서로 다른 박자를 한 제품 안에서 어긋나지 않게 겹쳐 돌리는 페이스메이킹입니다.