Sprint‐Planning - 100-hours-a-week/2-hertz-wiki GitHub Wiki
스프린트 작업일수
| 스프린트 이름 | 날짜 | 작업일수 | 비고 |
|---|---|---|---|
| 스프린트 1 플래닝 | 2025년 3월 31일 | 0.5 | 서비스 기획 |
| 스프린트 1 | 2025년 3월 31일 → 4월 10일 | 8 | 4/11[휴강] |
| 스프린트 1 리뷰&회고 | 2025년 4월 10일 | 0.5 | |
| 스프린트 2 플래닝 | 2025년 4월 14일 | 0.5 | 서비스 설계 |
| 스프린트 2 | 2025년 4월 14일 → 4월 25일 | 9 | API 명세, 화면 디자인,ERD, 아키텍처 설계 |
| 스프린트 2 리뷰&회고 | 2025년 4월 25일 | 0.5 | |
| 스프린트 3 플래닝 | 2025년 4월 28일 | 0.5 | MVP 개발 |
| 스프린트 3 | 2025년 4월 28일 → 5월 9일 | 7 | 유저 서비스,매칭,쪽지 (5/5[어린이날], 5/6[대체공휴일]) |
| 스프린트 3 리뷰&회고 | 2025년 5월 9일 | 0.5 | |
| 스프린트 4 플래닝 | 2025년 5월 12일 | 0.5 | 1차 배포 및 출시 |
| 스프린트 4 | 2025년 5월 12일 → 5월 23일 | 9 | CI/CD, 이벤트 뉴스 발송, 알림창 |
| 스프린트 4 리뷰&회고 | 2025년 5월 23일 | 0.5 | |
| 스프린트 5 플래닝 | 2025년 5월 26일 | 0.5 | 2차 배포 준비 |
| 스프린트 5 | 2025년 5월 26일 → 6월 5일 | 8 | 기사 피드, 1:N 채팅, 반응 달기, Docker 기반 배포 (6/6[현충일]) |
| 스프린트 5 리뷰&회고 | 2025년 6월 5일 | 0.5 | |
| 스프린트 6 플래닝 | 2025년 6월 9일 | 0.5 | 2차 배포 및 업데이트 |
| 스프린트 6 | 2025년 6월 9일 → 6월 20일 | 9 | 이메일 인증, 클릿 챗팅 봇, terraform 기반 배포 |
| 스프린트 6 리뷰&회고 | 2025년 6월 20일 | 0.5 | |
| 스프린트 7 플래닝 | 2025년 6월 23일 | 0.5 | 3차 배포 준비 |
| 스프린트 7 | 2025년 6월 23일 → 7월 4일 | 9 | 모니터링,로깅, 헬스체크 ,EKS 기반 배포 |
| 스프린트 7 리뷰&회고 | 2025년 7월 4일 | 0.5 | |
| 스프린트 8 플래닝 | 2025년 7월 7일 | 0.5 | 3차 배포 및 업데이트 |
| 스프린트 8 | 2025년 7월 7일 → 7월 18일 | 9 | 부하테스트, 장애 대응 시나리오, 유지보수. (7/14~7/18[부하테스트]) |
| 스프린트 8 리뷰&회고 | 2025년 7월 18일 | 0.5 | |
| 스프린트 9 플래닝 | 2025년 7월 21일 | 0.5 | 4차 배포 및 업데이트 |
| 스프린트 9 | 2025년 7월 21일 → 8월 1일 | 7 | 아키텍처 고도화, 유지보수(7/28~7/29[휴강]) |
| 스프린트 9 리뷰&회고 | 2025년 8월 1일 | 0.5 |
합계 작업일수: 84일
스프린트 플래닝 포커 카드
풀스택
| 스프린트 | 우선순위 | 업무명 | 플래닝 포인트 | 사람 | 이유 |
|---|---|---|---|---|---|
| 1 | 1 | 아이디어 브레인 스토밍 | 5 | ALL | 프로젝트 주제와 팀 아이덴티티 설정 |
| 1 | 1 | 서비스 기획 | 5 | ALL | 프로젝트 방향과 전체 로드맵, 핵심 개념 정의 |
| 1 | 2 | 기술 선정 및 검토 | 3 | ALL | 서비스에 부합한 최적의 기술 선택 |
| 2 | 1 | 화면 설계 및 와이어 프레임 구체화 | 4 | daisy.kim | |
| 2 | 1 | 모바일 웹 반응형 디자인 대응 / PWA 구현 | 4 | daisy.kim | |
| 2 | 1 | ERD 설계 | 2 | daisy.lee / alex.lee | 기능 전반과 연동되는 구조로 설계되어 있어, 오류 발생 시 파급력이 큼 |
| 2 | 1 | api 명세서 작성 | 3 | daisy.lee / alex.lee | 모든 기능과 프론트엔드의 연결 지점이므로, 세심한 설계가 필요함 |
| 2 | 1 | V1 페이지 퍼블리싱 | 4 | daisy.kim | |
| 3 | 1 | 카카오 OAuth 회원가입/로그인 기능 구현 | 1 | daisy.kim / daisy.lee / alex.lee | 소셜 로그인 연동임으로 복잡성이 낮고 시간이 덜 필요함 |
| 3 | 1 | 1:1 매칭 요청 기능 구현 | 4 | daisy.kim / daisy.lee / alex.lee | 알고리즘 구현과 튜닝 로직에 대한 수학적 사고 필요 |
| 3 | 1 | 추천 목록 기능 구현 | 4 | daisy.kim / daisy.lee / alex.lee | 핵심 기능으로 시간이 필요함 |
| 3 | 1 | MySQL 연동 및 스키마 생성 | 3 | daisy.lee / alex.lee | 서비스 전체 기능과 연결되는 기반 작업으로, 초기 설계 정확도가 중요하며 설계 및 검증에 시간이 필요함 |
| 3 | 2 | 쪽지 송수신 기능 구현 | 2 | daisy.kim / daisy.lee / alex.lee | 소켓을 사용하지 않고 HTTP를 이용한 쪽지 형태의 대화 기능임으로 복잡도가 낮음 |
| 3 | 2 | JWT 갱신 로직 및 만료 처리 구현 | 3 | daisy.lee / alex.lee | 토큰 만료/갱신 흐름 제어를 위한 인터셉터 설계 및 검증이 필요해 난이도가 다소 있고 시간이 필요함 |
| 3 | 2 | 환경변수 정리 및 .env 분리 | 1 | daisy.lee / alex.lee | 보안성과 협업 효율을 높이기 위한 단순 구성 작업으로 복잡성이 낮고 시간이 덜 필요함 |
| 3 | 3 | 단위/통합테스트 코드 작성 | 2 | daisy.lee / alex.lee | 기능 개발의 완성도를 높여주기 위해 필요 |
| 4 | 1 | v2 페이지 퍼블리싱 | 2 | daisy.kim | |
| 4 | 1 | 알림창 기능 구현 (Web Push 알림 및 브라우저 기기 알림 구현) | 3 | daisy.kim / daisy.lee / alex.lee | 실시간 이벤트 안내 및 사용자 피드백을 위한 알림창(모달/토스트) 기능 구현에 시간이 필요함 |
| 4 | 1 | 대화 내용 암호화 기능 구현 | 2 | daisy.lee / alex.lee | 개인 정보 보호 및 보안 강화를 위해, 메시지 송수신 시 암호화 처리 로직이 필요함 |
| 4 | 1 | 유저 정보 암호화 기능 구현 | 2 | daisy.lee / alex.lee | 개인 정보 유출을 방지하고 보안 수준을 높이기 위해, 유저 정보에 대한 암호화 처리가 필요함 |
| 4 | 1 | 매칭 성공 시 뉴스 기사 생성 기능 구현 (커뮤니티) | 5 | daisy.kim / daisy.lee / alex.lee | 매칭 결과를 커뮤니티 내에서 자연스럽게 공유하고, 사용자 참여를 유도하기 위해 자동 기사 생성 기능이 필요함 |
| 4 | 2 | RT(Refresh Token) 도입 | 3 | daisy.lee / alex.lee | 보안 강화를 위한 토큰 재발급 구조 설계로 인해 복잡성이 높고 설계/구현에 시간이 필요함 |
| 4 | 2 | Redis 기반 세션/매칭 상태 캐싱 | 3 | daisy.lee / alex.lee | 빠른 상태 접근 및 확장성 확보를 위해 Redis 연동 및 캐시 구조 설계가 필요해 복잡성과 구현 난이도가 있음 |
| 4 | 3 | 카테부 전용 회원가입 QR 기능 구현 | 3 | daisy.kim / daisy.lee / alex.lee | 특정 사용자 그룹(카테부)만을 대상으로 하는 회원가입 진입점이기 때문에, 인증 조건 분기 및 QR 처리 로직 설계가 필요함 |
| 4 | 3 | 예외 처리 세부화 | 4 | daisy.lee / alex.lee | 다양한 예외 케이스 대응을 위한 분기 처리로 인해 복잡성이 있으며 시간이 필요함 |
| 4 | 3 | 코드 리팩토링/ 성능 향상 | 4 | daisy.lee / alex.lee | 전체 구조 분석과 개선이 필요해 복잡성이 높고 시간이 많이 필요함 |
| 5 | 1 | (뉴스 기사)이벤트 피드 페이지 구현 | 4 | daisy.kim / daisy.lee / alex.lee | 자동 생성된 기사를 피드 형식으로 나열하는 구조 설계로 인해 복잡성이 다소 있으며, UI 구성에 시간이 필요함 |
| 5 | 2 | 이벤트 외부 공유 기능 구현 (카카오톡) | 2 | daisy.kim / daisy.lee / alex.lee | 이벤트 참여율을 높이고 외부 확산을 유도하기 위해, 카카오톡을 통한 손쉬운 공유 기능이 필요함 |
| 5 | 3 | 사용자 상세 정보 페이지 기능 구현 | 3 | daisy.kim / daisy.lee / alex.lee | 개별 사용자의 정보를 직관적으로 확인할 수 있도록, 프로필 기반의 상세 페이지 구성이 필요함 |
| 5 | 3 | 1:N 방 개설 기능 구현 | 5 | daisy.kim / daisy.lee / alex.lee | 다수 사용자와의 실시간 연결을 위한 방 생성 로직 설계로 인해 구현 난이도가 높고, 복잡성도 크며 시간이 필요함 |
| 5 | 3 | 1:N 방 입장 기능 구현 | 5 | daisy.kim / daisy.lee / alex.lee | 다수 사용자 입장 제어 및 실시간 연결 처리로 인해 복잡성이 중간 정도이며 시간이 필요함 |
| 5 | 4 | 로깅 시스템 구축 | 5 | daisy.lee / alex.lee | 에러 추적 및 주요 이벤트 기록을 위해 로그 수집/전송 구조를 설계해야 하므로 복잡성이 다소 있으며 시간이 필요함 |
| 5 | 4 | 이벤트(뉴스)에 반응 달기 기능 구현 (커뮤니티) | 2 | daisy.kim / daisy.lee / alex.lee | 단순 인터랙션 UI로 구현 난이도가 낮고 시간이 덜 필요함 |
| 6 | 1 | 조직 이메일 인증 기능 구현 | 4 | daisy.kim / daisy.lee / alex.lee | 이메일 도메인 검사 및 인증 처리 로직이 필요하여 복잡성이 다소 있고 시간이 필요함 |
| 6 | 2 | 알림 허용 설정 기능 구현 | 2 | daisy.kim / daisy.lee / alex.lee | 단순한 설정 UI와 상태 저장 처리로 구현 난이도가 낮고 시간이 덜 필요함 |
| 6 | 3 | 매칭 통계 기능 구현 | 4 | daisy.kim / daisy.lee / alex.lee | 데이터 집계 및 시각화를 위한 로직 설계로 인해 복잡성이 있으며 시간이 필요함 |
| 7 | 1 | 리펙토링/유지보수 | 3 | daisy.kim / daisy.lee / alex.lee | |
| 8 | 1 | 부하테스트 수행 | 4 | daisy.lee / alex.lee | 예상 트래픽에 대한 시스템 안정성을 확인하기 위한 작업으로, 복잡성은 낮지만 시나리오 설계 및 반복 테스트에 시간이 필요함 |
| 9 | 1 | 리펙토링 유지보수 | 3 | daisy.kim / daisy.lee / alex.lee |
인공지능
| 스프린트 | 우선순위 | 업무명 | 플래닝 포인트 | 사람 | 이유 |
|---|---|---|---|---|---|
| 1 | 1 | 아이디어 브레인 스토밍 | 5 | ALL | 프로젝트 주제와 팀 아이덴티티 설정 |
| 1 | 1 | 서비스 기획 | 5 | ALL | 프로젝트 방향과 전체 로드맵, 핵심 개념 정의 |
| 1 | 2 | 기술 선정 및 검토 | 3 | ALL | 서비스에 부합한 최적의 기술 선택 |
| 2 | 1 | 화면 설계 및 와이어 프레임 구체화 | 4 | daisy.kim,khloé,alex.lee, toby.kim | 사용자 흐름과 UI 구성 시각화 |
| 2 | 1 | 모델 조사 및 선정 | 3 | khloé, noah | 서비스에 적합한 AI 모델 조사 및 비교 테스트 |
| 2 | 1 | 모델 API 설계 | 2 | khloé, noah | 엔드포인트 및 스키마 정의, 역할 및 연동관계 정리, 호출/응답 예시 작성 |
| 2 | 2 | 모델 추론 성능 최적화 | 3 | khloé, noah | 성능 지표 확립, 병목 요소 분석, 최적화 기법 및 적용 계획 수립 |
| 2 | 2 | 서비스 아키텍쳐 모듈화 | 2 | noah | 아키텍처 설계, 모듈별 책임 및 기능 정리 |
| 2 | 3 | LangChain 기반 멀티스텝 AI | 2 | khloé | 추론 흐름도, 도입 근거 마련 |
| 2 | 3 | RAG 적용 설계 | 1 | khloé | 데이터 흐름도, 외부 소스 정리, 도입 근거 마련 |
| 2 | 3 | MCP 활용 설계 | 3 | noah | MCP 설계도 및 포맷, 도입 근거 마련 |
| 2 | 4 | 서비스 인프라 확장성 및 모니터링 설계 | 1 | khloé | 배포 아키텍처, 인프라 기술 정리, 모니터링 대상 지표 및 수집/시각화 방법 정리 |
| 2 | 5 | 최종 통합 설계 및 회고 | 1 | khloé, noah | 전체 아키텍처 정리 및 요소별 정리 |
| 3 | 1 | 개발 환경 구축 | 1 | khloé, noah | 본격적인 개발 환경 세팅/ 협업과 유지보수를 위한 기반 마련 |
| 3 | 1 | 시스템 아키텍처 구축 | 2 | noah | FastAPI 기반 RESTful API 엔드포인트 설계, 라우터 구조 정의 |
| 3 | 2 | 벡터검색엔진 시스템 설계 | 3 | khloé | 유저등록, 임베딩, 매칭 로직 구현 |
| 3 | 3 | 유사도 계산 최적화 | 2 | noah | 비즈니스 로직 리팩터링 |
| 3 | 3 | 벡터검색엔진 저장 최적화 | 2 | khloé | chromaDB 정보 저장 최적화 및 양방향 유사도 처리 로직 |
| 3 | 2 | API 동작테스트 | 2 | noah | 비즈니스 로직 제외 Swagger 테스트 |
| 3 | 4 | 모니터링 및 로깅 구축 | 2 | noah | 응답시간 및 메모리 사용량 측정 |
| 3 | 4 | v1 통합 테스트 | 2 | khloé, noah | BE와의 연동 테스트, 로직 정상 동작 확인 |
| 4 | 1 | v1 API 최적화 | 5 | khloé, noah | 유사도 계산 및 매칭 추천 최적화, 응답시간 최소화 등 |
| 4 | 1 | GPU 서버 구축 | 2 | khloé, noah | Colab 연동/GCP 등 GPU 모델 테스트 환경 구축 |
| 4 | 1 | v2 API 기능 구현 | 3 | khloé, noah | 튜닝 리포트 생성 기능 구현 |
| 4 | 1 | MCP 적용 | 3 | noah | MCP 서버 및 클라이언트 구현 테스트 |
| 5 | 1 | GPU 모델 테스트 | 3 | khloé, noah | GPU 모델 선정 및 CPU/GPU 환경 비교 |
| 5 | 1 | 모델 서빙 프레임워크 테스트 | 3 | noah | Ollama/vLLM 비교 테스트 |
| 5 | 2 | 모델 최적화 | 3 | noah | 양자화, 배치처리 시스템 등 적용 |
| 5 | 2 | 프롬프트 튜닝 | 3 | khloé | Chain-of-Thought, few-show 등 |
| 5 | 3 | v2 로깅 및 모니터링 | 3 | khloé | 응답시간, VRAM 사용량 측정 |
| 5 | 3 | 재시도 로직 및 에러처리 개선 | 3 | khloé | 생성 실패시 재시도 및 에러처리 강화 |
| 6 | 1 | 성능 평가 데이터셋 구축 | 2 | khloé, noah | 평가 지표 수립 및 평가 데이터셋 확보 |
| 6 | 1 | LLM 평가 프롬프트 튜닝 | 3 | khloé, noah | LLM을 통한 SLM 평가 기법 적용, 평가 유사도 일치 테스트 |
| 6 | 2 | LLM 평가 파이프라인 구축 | 3 | khloé, noah | 생성 - 평가 - 튜닝 파이프라인 구축 |
| 6 | 3 | 리포트 생성 프롬프트 튜닝 | 2 | khloé, noah | 사용자 경험성 증가 및 리포트 생성 품질 향상 |
| 6 | 4 | 프롬프트 버전 관리 | 2 | khloé, noah | 프롬프트 개선에 따른 평가 지표 개선 여부 확인 |
| 7 | 1 | 채팅 클린 봇 모델 개발 | 5 | khloé, noah | 비속어 필터링 등 안전 채팅 환경 구축 및 사용자 경험 최적화 |
| 7 | 1 | 클린봇 속도개선 및 고도화 | 5 | khloé, noah | 실시간 대응을 위한 처리 속도 향상 |
| 7 | 2 | 성능 최적화 및 유지보수 | 4 | khloé, noah | 안정적 운영 위한 성능 유지 관리 |
| 8 | 1 | 부하 테스트 고도화 | 5 | khloé, noah | 사용자 증가 대비 안정성 확인 및 유지 보수 |
| 8 | 2 | 경량화 및 속도 최적화 | 4 | khloé, noah | 개선 사항 체크 및 성능 향상 |
| 8 | 3 | AI 데이터 백업 및 복구 체계 강화 | 4 | khloé, noah | 유실 방지, 운영 안정성 확보 |
| 9 | 1 | 부하테스트 | 5 | khloé, noah | 교육 내 자체 부하테스트 |
| 9 | 2 | 리팩토링 및 유지보수 | 2 | khloé, noah | 코드 품질 향상과 기술 부채 해소 |
| 9 | 2 | 최종 모델 성능 정리 | 1 | khloé, noah | 응답 품질, TPS, 비용 등 |
| 9 | 2 | 모델 서빙, 튜닝 등 문서화 | 2 | khloé, noah | 티켓 및 위키 문서 정리 |
클라우드
| 스프린트 | 우선순위 | 업무명 | 플래닝 포인트 | 담당자 | 이유 |
|---|---|---|---|---|---|
| 1 | 1 | 아이디어 브레인 스토밍 | 5 | ALL | 프로젝트 주제와 팀 아이덴티티 설정 |
| 1 | 1 | 서비스 기획 | 5 | ALL | 프로젝트 방향과 전체 로드맵, 핵심 개념 정의 |
| 1 | 2 | 기술 선정 및 검토 | 3 | ALL | 서비스에 부합한 최적의 기술 선택 |
| 1 | 3 | 1차 아키텍처 구성도 설계(EC2 기반) | 2 | toby.kim, zero.lee | 초기 백엔드, DB, AI 서버를 단순히 EC2서버에 빅뱅 배포를 하기에 난이도가 낮음 |
| 2 | 1 | 전반적인 아키텍처 구상도 작성(v1,v2,v3) | 4 | toby.kim, zero.lee | 아키텍처 구성도를 기반하여 EC2 서버 구성 및 배포를 하기 때문에 포인트가 높음 |
| 2 | 2 | IaC 모듈 개발 | 5 | toby.kim, zero.lee | 최종 배포까지 가져가는 아키텍처이고, 복잡도가 높기 때문에 난이도가 높음 |
| 3 | 1 | AWS 콘솔로 EC2 서버 구성(백엔드, DB, AI) | 2 | toby.kim, zero.lee | 생성해야 하는 리소스가 적기 때문에 콘솔로 빠르게 구성 가능 |
| 3 | 1 | 개발 환경 및 프로젝트 세팅 | 3 | toby.kim, zero.lee | 본격적인 개발 환경 세팅/ 협업과 유지보수를 위한 기반 마련 |
| 4 | 1 | 1차 아키텍처 기반 배포(빅뱅) | 4 | toby.kim, zero.lee | 각 서버간의 연결과 Cors 등의 네트워크, 보안 문제도 신경 써야 함. 빅뱅 배포이기 때문에 코드를 수정하고 배포하는데 오래 걸림 |
| 4 | 1 | 2차 아키텍처 구성도 설계(도커 기반) | 4 | toby.kim, zero.lee | 달리지는 아키텍처의 명확한 구성도가 있어야 다음 단계에 문제가 없음 |
| 4 | 2 | CI/CD 구축 | 5 | toby.kim, zero.lee | 각 레포지토리에 CI코드를 작성하고 파이프라인을 구축하는 것이 오래 걸림 |
| 4 | 2 | AWS에 도커 컨테이너 기반 배포 구성 | 3 | toby.kim, zero.lee | 콘솔을 통해 비교적 간단히 세팅 및 배포를 할 수 있음 |
| 5 | 1 | 아키텍처 문서화 (도메인 주소, IP 주소, CI/CD 파이프라인) | 4 | toby.kim, zero.lee | 해당 부분에 해당하는 문서는 CI/CD를 제외하고 그대로 쓰이기 때문에 꼼꼼히 작성해야 됨. |
| 5 | 2 | 2차 아키텍처 기반 배포(도커 기반) | 4 | toby.kim, zero.lee | 아키텍처 구성도를 기반하여 도커 기반의 서버 구성 및 배포를 하기 때문에 포인트가 높음 |
| 6 | 1 | 3차 아키텍처 구성도 설계(EKS, Terraform 기반) | 5 | toby.kim, zero.lee | 최종 배포까지 가져가는 아키텍처이고, 복잡도가 높기 때문에 난이도가 높음 |
| 6 | 2 | 아키텍처 문서화(네트워크 구성, Tagging 규칙) | 4 | toby.kim, zero.lee | 네트워크 구성을 잘 설계해야 보안적으로 안전하고, Tagging 규칙을 미리 작성해야 리소스 관리가 용이함 |
| 6 | 2 | terraform 작성 | 5 | toby.kim, zero.lee | 모듈화를 활용하여 모든 리소스를 자동화 하는데 난이도가 높음 |
| 6 | 3 | CI/CD 수정 | 3 | toby.kim, zero.lee | CI 부분은 크게 변하지 않고, CD 부분만 K8S 환경에 맞춰 변경하기 때문에 그리 어렵지는 않음 |
| 7 | 1 | Health-check API 개발 | 4 | toby.kim, zero.lee | Lamda를 활용하여 각 리소스 접근 헬스 체크를 구현하는데 난이도가 높음 |
| 7 | 1 | terraform 기반 배포 | 5 | toby.kim, zero.lee | 트러블슈팅 하는데 난이도가 높고 시간이 오래 걸림 |
| 7 | 2 | 로깅 시스템 구축 | 5 | toby.kim, zero.lee | S3 서비스, 로그 경로 설정 등 리소스, 테라폼에 대한 변경사항이 많음 |
| 7 | 3 | 3차 아키텍처 기반 배포(eks, terraform) | 5 | toby.kim, zero.lee | 배포환경을 K8S로 바뀌면서 복잡성이 높아지고, 트러블슈팅이 많아질 것으로 예상됨 |
| 8 | 1 | 부하 테스트 고도화 | 5 | toby.kim, zero.lee | 부하테스트에 따라 리소스 확장, DB 스케일링 등을 파악해야하기 때문에 포인트가 높음 |
| 8 | 1 | 장애 대응 및 문서화 | 5 | toby.kim, zero.lee | 서비스를 안정화하고 실전에서도 사용할 수 있는 환경을 만들기 위한 과정으로 난이도와 중요도가 높음 |
| 8 | 2 | 부하테스트 수행 | 5 | toby.kim, zero.lee | 예상 트래픽에 대한 시스템 안정성을 확인하기 위한 작업으로, 복잡성은 낮지만 시나리오 설계 및 반복 테스트에 시간이 필요함 |
| 9 | 1 | 4차 배포(아키텍처 고도화) | 5 | toby.kim, zero.lee | 아키텍처 고도화를 하는데 시간과 난이도가 높음 |
| 9 | 2 | 리팩토링/유지보수 | 3 | toby.kim, zero.lee | 스프린트 8에 이어 하는 과정으로 난이도가 높지 않음 |
| 9 | 3 | 최종 문서 작업 | 5 | toby.kim, zero.lee | 프로젝트의 중요한 결과물이므로 플래닝 포인트가 높음 |
플래닝 포인트: 5