제 8 장

개발 일정 및 추진 체계

본 사업은 애자일 스크럼으로 수행한다. 요구사항이 처음부터 확정되지 않고, 특히 매칭 순위와 검증 기준은 제 7 장의 측정 결과에 따라 조정될 여지가 크다. 계획을 한 번에 고정하는 방식으로는 이 조정을 흡수할 수 없다.

1) 단계별 개발 일정

진행 방식

2주 단위 스프린트를 5회 반복한다. 전체 기간은 2026년 8월 20일부터 10월 27일까지 69일이다.

이벤트 주기 시간 산출
스프린트 계획 스프린트 시작일 1시간 스프린트 백로그 확정
데일리 스크럼 매일 15분 보드 갱신, 장애 요인 공유
스프린트 리뷰 스프린트 종료일 1시간 동작하는 결과물 시연
회고 리뷰 직후 30분 다음 스프린트 개선 항목

스프린트 계획

스프린트 기간 목표 주요 산출물
S1 08-20 ~ 09-02 기반 확정 요구사항 확정, 데이터 모델, 개발·배포 환경
S2 09-03 ~ 09-16 구인 흐름 공고 등록·상태 전이, 지원 접수, 영상 업로드·저장
S3 09-17 ~ 09-30 분석과 매칭 프레임 추출·멀티모달 분석·장면 색인, 매칭 에이전트
S4 10-01 ~ 10-14 검증 근거 검색·판정(RAG), 스탯 갱신, 신뢰도 산출
S5 10-15 ~ 10-27 시험과 마감 시험 수행, Hit Rate·Recall@5 측정, 보고서 완성

진행 중인 스프린트는 스프린트 번호를 눌러 일자별 기록을 볼 수 있다. 종료된 스프린트의 기록도 같은 자리에 남긴다.

S1에서 제 2 장~제 6 장에 남아 있는 미확정 값을 함께 결정한다. 이 값들이 정해지지 않으면 S3 이후 작업의 판정 기준이 서지 않는다.

주차별 진행

스프린트 단위 계획을 주차 단위 담당자별 작업으로 펼치면 아래와 같다. 두 주가 한 스프린트를 이룬다(S1 = 1~2주차, S2 = 3~4주차, S3 = 5~6주차, S4 = 7~8주차, S5 = 9~10주차).

주차 기간 스프린트 박민호 (PM) 백성검 (프론트·웹) 정어진 (백엔드·파이프라인) 정상호 (에이전트)
1 8/20~8/26 S1 요구사항 정의 앱 화면 구조 설계 DB 스키마, 자세 추정 검증 프롬프트 설계
2 8/27~9/2 S1 시험 항목 확정 앱 골격·라우팅 API 규격 확정, 전처리 모듈 요청 해석 시안
3 9/3~9/9 S2 보드 운영·범위 점검 업로드 화면 업로드·스토리지, 동작 구간 검출 요약 파이프라인
4 9/10~9/16 S2 S2 리뷰·회고 촬영 가이드 UI 분석 작업 큐, 지표 산출 지표 → 문장 변환
5 9/17~9/23 S3 정답 근거 집합 작성 리포트 화면 벡터 저장·검색, 지표 정밀화 호칭 판정 규칙
6 9/24~9/30 S3 중간 점검·리스크 관리 선수 카드(앱), 웹 골격 이력 스키마, 종목별 파라미터 호칭 문구 생성
7 10/1~10/7 S4 시험 준비·정답 근거 확정 매칭 화면 추천 API, 신뢰도 산출 적합도 산출
8 10/8~10/14 S4 시험 수행·판정 평가 화면, 카드 공개 페이지(웹) 예외 처리 추천 사유 생성
9 10/15~10/21 S5 결함 분류·통합 조율 스쿼드 페이지·통합 통합·수정 통합·수정
10 10/22~10/27 S5 보고서 완성·시연 준비 화면 점검 배포·안정화, 성능 점검 응답 품질 점검

굵게 표시한 항목은 다른 담당자가 기다리는 산출물이다. 2주차의 API 규격 확정이 가장 앞서고 가장 많이 물려 있다 — 이 규격이 늦어지면 3주차 이후 백성검과 정상호의 작업이 함께 밀린다.

정어진의 열에는 매 주 두 갈래(백엔드·파이프라인)가 함께 들어간다. 두 영역을 한 사람이 맡는 구성이므로, 이 열이 밀리면 다른 세 열이 동시에 밀린다. 완화 방법은 아래 영역이 1인에 몰린다에 정리한다.

9주차는 네 사람 모두 통합에 들어간다. 이 주에 새 기능을 넣지 않는다는 뜻이며, 그러려면 8주차까지 기능이 닫혀 있어야 한다.

칸반 보드

작업은 아래 다섯 열을 왼쪽에서 오른쪽으로만 이동한다.

열 의미 WIP 제한
백로그 아직 스프린트에 배정되지 않은 항목 없음
이번 스프린트 이번 스프린트에 하기로 한 항목 없음
진행 중 담당자가 지금 붙어 있는 항목 1인 1건
리뷰 구현이 끝나 검토를 기다리는 항목 2건
완료 완료 조건을 모두 만족한 항목 없음

WIP 제한을 두는 이유는 동시 진행 건수를 줄이기 위해서다. 특히 리뷰 열이 쌓이면 구현은 계속 늘어나는데 합쳐지지 않아, 스프린트 종료 시점에 완료가 몰린다.

완료 조건(Definition of Done) — 아래를 모두 만족해야 완료로 옮긴다.

  1. 담당자 외 1인의 코드 리뷰를 통과했다.
  2. 대응하는 시험 항목(TC)이 통과했다. (제 7 장)
  3. 설계가 바뀐 경우 해당 장의 문서에 반영했다.

현재 보드

2026년 8월 20일(S1 시작 시점) 기준이다. 스프린트가 막 시작되어 진행 중·리뷰·완료는 비어 있다. 보드는 데일리 스크럼에서 갱신하며, 스프린트 종료 시점의 상태를 이 절에 누적 기록한다.

백로그 이번 스프린트 (S1) 진행 중 리뷰 완료
S2~S5 항목 전체 SB-01 요구사항 확정 (박민호) — — —
  SB-02 미확정 값 결정 (전원)      
  SB-03 데이터 모델 확정 (정어진)      
  SB-04 영상 저장·색인 구조 설계 (정어진)      
  SB-05 에이전트 도구·프롬프트 설계 (정상호)      
  SB-06 개발·배포 환경 구축 (정어진)      
  SB-07 시험 항목 확정 (박민호)      
  SB-08 정답 근거 집합 설계 (박민호)      
  SB-09 앱 화면 구조·라우팅 설계 (백성검)      

2) 조직 구성 및 역할 분담

역할

담당자 역할 담당 영역 관련 장
박민호 PM 일정·범위 관리, 요구사항 확정, 시험 총괄 2·7장
백성검 프론트 · 웹 앱 화면, 웹 페이지 3장
정어진 백엔드 · 파이프라인 DB·API, 저장소, 작업 큐, 벡터 저장·검색, 프레임 추출·색인, 데이터 모델, 배포 3·4장
정상호 에이전트 개발 영상 분석·매칭·검증 에이전트, 도구·프롬프트, 모델 선정 4·6장

박민호 — PM

프로젝트가 10주 안에 끝나도록 범위를 관리하고, 무엇을 만들지와 무엇을 통과로 볼지를 확정한다.

PM은 구현 영역을 맡지 않는다. 따라서 네 영역 모두 만드는 사람과 판정하는 사람이 갈라져 있다 — 시험 항목과 판정 기준을 정하는 사람이 그 기준으로 평가받는 코드를 쓰지 않는다는 뜻이다. 대신 PM이 구현 상황을 코드로 확인할 수 없으므로, 완료 여부는 시연이 아니라 아래 완료 조건(DoD)의 통과 여부로만 판단한다.

구분 내용
책임 스프린트 운영, 범위·우선순위 결정, 요구사항 확정, 시험 항목과 판정 기준 확정, 시험 수행 총괄
산출물 스프린트 백로그, 요구사항 정의(UR·FR·NFR), 시험 항목(TC·NT)과 판정 기준, 정답 근거 집합, 시험 결과와 보고서
결정 권한 일정이 밀릴 때 무엇을 덜어낼지, 미확정 값이 기한 내 결정되지 않을 때의 잠정값
스프린트별 주 작업 S1 요구사항·시험 항목 확정 → S2~S3 보드 운영·정답 근거 집합 작성 → S4 시험 수행과 판정 → S5 보고서 완성·시연 준비

관련 장은 제 2 장·제 7 장이다.

백성검 — 프론트 · 웹

사용자가 실제로 만지는 면 전체를 맡는다. 앱과 웹은 같은 API 위에 올라가므로, 이 영역은 2주차 API 규격에 가장 먼저 묶인다. 규격이 늦으면 화면은 붙일 데이터가 없다.

구분 내용
책임 앱 화면 구현, 웹 페이지 구현
산출물 앱 화면(업로드·촬영 가이드·리포트·선수 카드·매칭·평가), 카드 공개 페이지, 스쿼드 페이지
받는 것 API 규격(2주차, 정어진으로부터), 호칭·적합도의 출력 형식(정상호로부터)
결정 권한 화면 구성과 이동 흐름 — 단 화면에 표시할 값의 정의는 요구사항을 따른다
스프린트별 주 작업 S1 화면 구조·골격과 라우팅 → S2 업로드·촬영 가이드 → S3 리포트·선수 카드·웹 골격 → S4 매칭·평가·카드 공개 페이지 → S5 스쿼드 페이지·통합

관련 장은 제 3 장 4절이다.

정어진 — 백엔드 · 파이프라인

앱과 웹이 올라앉는 서버 쪽과, 경기 영상이 검색 가능한 색인이 되기까지의 경로를 함께 맡는다. 이 영역은 나머지 세 사람의 선행 조건을 둘이나 쥐고 있다 — 백성검이 기다리는 API 규격과, 정상호가 기다리는 장면 색인 스키마다. 스키마가 흔들리면 두 사람의 작업이 같이 멈춘다.

두 영역이 한 사람에게 묶여 있으므로, 구현보다 규격과 스키마를 먼저 내는 순서를 지킨다. S1의 산출 순서가 곧 다른 세 사람의 착수 시점이다.

구분 내용
책임 DB 스키마, API, 영상 스토리지, 분석 작업 큐, 벡터 저장·검색, 프레임 추출, 장면 색인 저장과 검색, 데이터 모델, 배포
산출물 API 규격, 이력 스키마, 업로드·스토리지, 작업 큐, 벡터 검색, 장면 색인 스키마, 색인 검색 도구, 프레임 추출 파이프라인
넘겨주는 것 API 규격(2주차, 백성검·정상호에게), 장면 색인 스키마와 색인 검색 도구(정상호에게), 벡터 검색 인터페이스(정상호에게)
결정 권한 API 형태, 저장·큐 구성, 색인 저장 구조, 추출 구현 방식, 지표 산출 방식
스프린트별 주 작업 S1 DB 스키마·API 규격·전처리 → S2 업로드·작업 큐·지표 산출 → S3 벡터 저장·검색·지표 정밀화 → S4 추천 API·신뢰도 산출·예외 처리 → S5 배포·안정화

관련 장은 제 3 장과 제 4 장 2절이다.

정상호 — 에이전트 개발

모델을 쓰는 모든 지점을 맡는다. 이 영역은 비용과 지연이 곧바로 결정되는 자리이기도 하다. 프레임 추출 간격, 호출 시점, 프롬프트 길이가 NFR-07·NFR-08에 직접 반영된다.

구분 내용
책임 영상 분석·매칭·검증 에이전트, 도구 정의와 프롬프트, 출력 스키마, 모델 선정, 응답 검증 규칙
산출물 프롬프트, 도구 스키마, 출력 스키마, 모델 선정 근거와 실측 비용, 근거 없는 판정 차단 규칙
받는 것 장면 색인 스키마와 검색 도구(정어진으로부터)
결정 권한 프롬프트 구성, 모델과 설정 — 단 NFR-07·NFR-08 목표 안에서
스프린트별 주 작업 S1 도구·프롬프트 설계 → S2 매칭 에이전트 → S3 영상 분석 에이전트 → S4 검증 에이전트 → S5 실측과 조정

관련 장은 제 4 장·제 6 장이다.

책임 배분

한 작업에 대해 실행(R) 은 여럿일 수 있지만 승인(A) 은 한 사람이다. 승인자가 여럿이면 결정이 미뤄진다.

작업 박민호 백성검 정어진 정상호
요구사항·범위 확정 A·R C C C
API 규격 C C A·R C
데이터 모델·색인 스키마 I I A·R C
프레임 추출·색인 파이프라인 I I A·R C
색인 검색 도구 I I A·R C
벡터 저장·검색 I I A·R C
에이전트 프롬프트·도구 I I C A·R
모델 선정과 설정 C I I A·R
매칭 순위 가중치 A I I R
앱 화면 C A·R C I
웹 페이지 C A·R C I
시험 항목·판정 기준 A·R C C C
정답 근거 집합 A I R C
배포·CI I C A·R I
보고서 갱신 A·R R R R

A 승인 · R 실행 · C 협의 · I 공유

매칭 순위 가중치와 정답 근거 집합의 승인을 PM이 갖는 이유는 같다. 둘 다 구현자가 자기 결과를 좋게 만들 수 있는 손잡이라서, 만드는 사람과 정하는 사람을 분리한다. PM이 구현을 겸하지 않으므로 이 분리는 네 영역 모두에서 예외 없이 성립한다.

교차 리뷰

담당 영역 밖의 인원이 리뷰한다. 자기 영역을 자기가 승인하면 리뷰가 형식이 된다. 리뷰어는 그 산출물을 쓰는 쪽에 붙였다 — 쓰는 사람이 보면 계약 위반이 리뷰 단계에서 걸린다.

대상 리뷰어 리뷰어를 그렇게 둔 이유
백엔드·API 백성검 API를 화면에서 소비하는 쪽
파이프라인·색인·데이터 모델 정상호 색인을 에이전트 입력으로 쓰는 쪽
에이전트·프롬프트 정어진 에이전트 응답을 서버에서 받는 쪽
앱 화면·웹 페이지 정상호 담당 영역 밖이면서 표시 값의 근거를 아는 쪽
요구사항·시험 항목·보고서 백성검 또는 정어진 PM 산출물은 PM 외 1인이 본다

영역이 1인에 몰린다

네 영역을 각각 한 사람이 맡는다. 담당자가 빠지면 그 영역이 멈추며, 10주 일정에서는 인수인계에 쓸 시간이 없다.

특히 백엔드와 파이프라인이 정어진 한 사람에게 묶여 있다. 원래 두 사람이 나눠 맡던 범위이며, 여기에 백성검(API 규격)과 정상호(장면 색인 스키마)의 착수 시점이 함께 걸려 있다. 이 열이 밀리면 세 사람이 동시에 밀린다는 뜻이므로, 아래를 지킨다.

  • 설계 판단은 코드가 아니라 이 보고서의 해당 장에 남긴다.
  • 코드 리뷰는 위 교차 리뷰 표를 따른다.
  • 영역 간 인터페이스(파이프라인 → 장면 색인, 색인 → 검색 도구, 에이전트 → 서버 응답)는 구현보다 스키마를 먼저 합의한다.
  • 인터페이스 합의는 S1 안에 끝낸다. 뒤로 밀리면 두 영역이 서로를 기다린다.
  • 정어진 영역은 규격·스키마를 구현보다 먼저 낸다. 구현이 덜 끝나도 규격이 확정되면 백성검과 정상호는 착수할 수 있다.
  • 일정이 밀릴 때 PM이 가장 먼저 덜어내는 대상은 이 영역과 물린 항목이다.

협업 규칙

항목 규칙
브랜치 작업 단위로 분기, 리뷰 후 main에 병합
리뷰 담당자 외 1인 승인 필수 (교차 리뷰 표)
인터페이스 변경 보드에 항목으로 올리고 관련 담당자 합의 후 반영
결정 기록 승인이 필요한 결정은 결정자와 근거를 해당 장에 남긴다
보고서 갱신 설계 변경과 같은 스프린트 안에 반영

3) 위험 관리 방안

ID 위험 영향 대응 담당
R-01 S1에서 미확정 값이 결정되지 않는다 S3 이후 판정 기준이 서지 않아 시험이 밀린다 S1 리뷰의 종료 조건에 포함, 미결 시 잠정값을 정하고 근거를 기록 박민호
R-02 시험용 영상과 정답 근거 집합이 부족하다 Hit Rate·Recall@5를 측정할 수 없다 S2부터 영상 확보와 근거 표시 작업 착수, 규모와 한계를 함께 기록 박민호
R-03 영상 분석 비용·소요 시간이 목표를 넘는다 NFR-07·NFR-08 미달 2단계 프레임 추출과 캐시 적용, S3에서 실측 후 간격·해상도 조정 정상호
R-04 경기 영상이 올라오지 않아 근거가 모이지 않는다 스탯이 미검증에 머문다 업로드된 경기의 참여자가 매칭에서 유리해지는 구조로 유도 정상호
R-05 담당자 이탈·부재 해당 영역 중단 설계를 문서로 남기고 리뷰를 영역 밖 인원이 수행 박민호
R-06 범위가 늘어난다 10주 안에 완주하지 못한다 기간을 고정하고 범위로 조정, 제외 범위는 제 1 장에 명시 박민호
R-07 영상 화질·촬영 각도가 나빠 인물 식별이 안 된다 근거 장면을 스탯 산출에 쓰지 못한다 식별 저신뢰 장면을 산출에서 배제하고, 촬영 가이드를 제공 정어진
R-08 2주차 API 규격이 확정되지 않는다 3주차 이후 백성검·정상호의 작업이 함께 밀린다 규격 초안을 1주차에 회람하고 2주차 안에 합의를 끝낸다 정어진
R-09 백엔드와 파이프라인이 한 사람에게 몰려 처리량이 모자란다 두 영역이 함께 밀리고, 선행 산출물을 기다리는 두 사람도 멈춘다 규격·스키마를 구현보다 먼저 내고, 밀릴 때 이 영역과 물린 항목부터 범위에서 덜어낸다 박민호

기간은 고정 조건이다. 일정이 밀리면 기간을 늘리는 것이 아니라 범위를 줄이고, 줄인 항목은 제 9 장의 향후 과제로 넘긴다.