스프린트 플래닝 포커카드 - 100-hours-a-week/16-Hot6-wiki GitHub Wiki
Teddy
| 스프린트 | 우선순위 | 업무명 | 플래닝 포인트 | 사람 | 부여 이유 |
|---|---|---|---|---|---|
| 1 | 1 | 서비스 아이디어 구체화 | 4 | teddy | 기획 초기 단계에서 전체 서비스 방향성을 정하는 중요한 작업으로, 다양한 아이디어를 구조화하고 핵심 기능으로 도출해야 하므로 상대적으로 높은 시간이 필요함. |
| 1 | 2 | 핵심 기능 도출 및 화면설계 | 5 | teddy | 사용자의 주요 행동 흐름(UI/UX)을 도출하고 전반적인 구조를 시각화해야 하므로 반복적 논의 및 Figma 정리가 병행되어야 함. |
| 2 | 1 | 데이터 모델링/ERD 설계 | 3 | teddy | 화면에서 정의된 기능 흐름을 기반으로 DB 설계를 구체화하는 단계로, 모델링 및 테이블 관계 정의에 일정한 시간 소요 예상. |
| 2 | 2 | API 설계 | 3 | teddy | 도출된 기능을 실제 API 명세로 설계하며, 프론트와 백 간의 요청/응답 스펙 정리 및 예외 상황 고려가 필요함. |
| 2 | 3 | 테스트 설계 (TC / TS) | 2 | teddy | 기획된 기능을 테스트 가능한 케이스로 분해하는 과정으로, 필수지만 업무 복잡도는 중간 수준. |
| 2 | 4 | 기술 스택 선정(라이브러리, 프레임워크) | 0.5 | teddy | 이미 고려된 범위 내에서 결정되며 의사결정만으로 비교적 짧은 시간이 소요됨. |
| 2 | 5 | Git 브랜치 전략 & 커밋 규칙 문서 | 0.5 | teddy | 개발 초기 세팅의 일환으로 팀 내 개발 컨벤션 정리이며, 회의 1~2회와 문서화로 충분. |
| 3 | 1 | 개발환경 및 프로젝트 세팅 | 2 | teddy | 로컬 환경 통일성과 초기 빌드 테스트 중심으로 복잡도는 낮으나, 정확한 환경설정이 중요함. |
| 3 | 2 | OAuth 로그인 및 회원가입 기능 | 2 | teddy | 소셜 로그인 구현은 외부 라이브러리 연동으로 구현 가능하지만, 리디렉션 처리 및 토큰 처리 등 약간의 학습 필요 존재. |
| 3 | 3 | 이미지 생성 | 2 | teddy | AI 모델 연동 또는 생성형 API 연동 여부에 따라 복잡도가 갈리지만, 기본 이미지 처리 기능 구현과 결과 시각화에 최소 2일 소요 예상. |
| 3 | 4 | 커뮤니티 기능(CRUD) | 2 | teddy | 게시글 등록/조회/수정/삭제의 기본 기능으로 재사용 컴포넌트 구조 시 효율적으로 구현 가능. |
| 3 | 5 | 포인트 적립 | 1 | teddy | 사용자의 특정 행동에 따라 포인트를 적립하는 간단한 연산 로직으로, 비교적 구현이 단순함. |
| 4 | 1 | 1차 업데이트 출시 | 0.5 | teddy | |
| 3 | 2 | 특가 아이템 리스트 제공 | 2 | teddy | 상품 정보를 필터링하거나 추천할 수 있도록 리스트 데이터 가공 로직이 포함되며, 검색 조건 설정 등 UI 연동 고려 필요. |
| 4 | 3 | 사용자 피드백 수집 및 분석 | 3 | teddy | 피드백 입력 기능과 DB 저장 및 단순 조회 구현이 주가 되며, 분석은 기본 통계 수준에서 시작. |
| 4 | 4 | 유지보수 | 6 | teddy | |
| 4 | 5 | 사용자 반응 분석, 유지보수 계획 공유 및 회고 | 0.5 | teddy | |
| 5 | 1 | 2차 업데이트 개발 방향 논의 | 0.5 | teddy | |
| 5 | 2 | 특가 제품 판매 | 2 | teddy | 장바구니, 결제(모의), 재고 연동 등 복합 기능이 포함되며, 각 단계마다 세심한 UX 고려 필요. |
| 5 | 3 | 요일별 다른 컨셉의 이미지 생성 | 2 | teddy | 요일 조건에 따라 이미지 생성 조건이 달라지는 기능으로, AI 연동 및 UI 로직 제어 복잡도 존재. |
| 5 | 4 | 사용자 선호도 기반 인기 상품 추천 | 2 | teddy | 사용자 행동 분석 기반 추천 기능으로, 추천 알고리즘은 간단한 rule 기반으로 시작하더라도 기초 설계가 요구됨. |
| 5 | 5 | 일간/주간 게시판 게시글 순위 | 2 | teddy | 일정 시간 단위로 정렬되는 데이터 처리 및 캐싱 전략이 필요하며, 동시성 고려 필요. |
| 5 | 6 | 2차 개발 결과 공유 및 보완사항 도출 | 0.5 | teddy | |
| 6 | 1 | 2차 업데이트 출시 | 0.5 | teddy | |
| 6 | 2 | 사용자 피드백 수집 및 분석 | 3 | teddy | |
| 6 | 3 | 유지보수 | 6 | teddy | |
| 6 | 4 | 사용자 반응 분석, 유지보수 계획 공유 및 회고 | 0.5 | teddy | 스프린트 4와 동일 내용 반복 혹은 상세 기능 확장 가능성 있음. |
| 7 | 1 | 3차 업데이트 개발 방향 논의 | 0.5 | teddy | |
| 7 | 2 | 특가 알림 서비스 | 3 | teddy | 푸시/이메일/웹 알림 등 이벤트 기반 메시지 전달 기능으로, 트리거 로직과 큐 처리 고려됨. |
| 7 | 3 | 프롬프팅 추가된 이미지 생성 | 2 | teddy | 마이페이지 및 프로필 정보 관리 기능으로, 이미지 생성 기능과의 연동이 필요함. |
| 7 | 4 | 클린 봇 | 2 | teddy | |
| 7 | 5 | 관리자 페이지 | 2 | teddy | 전체 사용자, 상품, 게시물 등을 관리할 수 있는 별도 권한 기능 구현이 필요하며, 뷰가 복잡할 수 있음. |
| 7 | 6 | 3차 개발 결과 공유 및 보완사항 도출 | 0.5 | teddy | |
| 8 | 1 | 3차 업데이트 출시 | 0.5 | teddy | |
| 8 | 2 | 사용자 피드백 수집 및 분석 | 2 | teddy | |
| 8 | 3 | 유지보수 | 2 | teddy | |
| 8 | 4 | 사용자 반응 분석, 유지보수 계획 공유 및 회고 | 0.5 | teddy | |
| 9 | 1 | 부하테스트(7/14~7/18) | 5 | teddy | |
| 9 | 2 | 3차 업데이트 후 서비스 유지보수 | 0.5 | teddy | 사용성 개선, 버그 수정, 사용자 피드백 반영 등 반복적이고 예측 가능한 작업. |
| 9 | 3 | 랜덤 특가 타임 | 2 | teddy | 일정 시간 조건에 따른 특가 활성화 로직 구현으로, 타이머, 상태 전환, 사용자 알림 등 다양한 요소가 포함됨. |
| 9 | 4 | 맞춤형 깜짝 특가 이벤트 | 2 | teddy | 사용자 조건에 따라 개인화된 특가 제공 기능으로, 분기 처리 및 사용자 분석 로직이 포함됨. |
| 9 | 5 | 데스크 성향 진단 및 공유(데스크 MBTI) | 2 | teddy | 설문 기반 로직 또는 간단한 로컬 데이터 분석에 따라 결과를 제공하며, 시각화 결과 공유 기능 포함. |
| 9 | 6 | 구매 인증 기능 | 1 | teddy | 인증 이미지 업로드, 검증 로직, 상태 관리 등 파일 처리 및 보안 고려가 포함된 기능임. |
| 9 | 7 | 4차 개발 결과 공유 및 보완사항 도출 | 0.5 | teddy |
합계 작업일수: 84일(플래닝 포인트의 총합)
Ethan
| 스프린트 | 우선순위 | 업무명 | 플래닝포인트 | 담당자 | 이유 |
|---|---|---|---|---|---|
| 1 | 1 | 아이디어 선정 | 4 | ethan | |
| 1 | 2 | 기획 및 문서화 | 5 | ethan | |
| 2 | 1 | 아키텍처 구조 설계 | 1 | ethan | |
| 2 | 2 | ERD 생성 | 2 | ethan | ERD 설계 |
| 2 | 3 | API 명세서 작성 | 2 | ethan | 풀스택 및 AI 통신을 위한 API 명세서 작성 |
| 2 | 4 | 테크 스펙 작성 | 2 | ethan | |
| 2 | 5 | 코드 컨벤션 | 1.5 | ethan | 풀스택끼리 개발을 위한 코드 컨벤션 의논 필요 |
| 2 | 6 | 인터페이스 | 1.5 | ethan | 풀스택끼리 개발을 위한 인터페이스 의논 및 작성 필요 |
| 3 | 1 | 개발 환경 및 프로젝트 세팅 | 0.5 | ethan | 웹 서버, 웹 애플리케이션 서버, DB 환경, 라이브러리, 버전 등 동일하게 설정 |
| 3 | 2 | OAuth 소셜 로그인 구현 | 0.5 | ethan | 보다 편한 사용자 접근성을 위해 자체 회원가입 대신 카카오톡 OAuth 적용 |
| 3 | 3 | 이미지 생성 | 1.5 | ethan | AI에서 생성한 이미지 받아 사용자에게 전달 |
| 3 | 4 | 네이버 쇼핑 API 연동 | 1.5 | ethan | 제품 구매를 위한 리스트 생성 |
| 3 | 5 | 커뮤니티 제작 | 1.5 | ethan | 사용자 간의 데스크 환경을 공유하며 서비스 활동을 활발하게 하기 위해 |
| 3 | 6 | 포인트 적립 | 1.5 | ethan | 초반 사용자 유입을 위해 활발한 포인트 지급 필요 |
| 3 | 7 | 테스트 | 1 | ethan | 각 스프린트 마지막 단계로 단위 및 통합 테스트 진행 |
| 4 | 1 | 특가 상품 구매 | 2 | ethan | 포인트를 통해 서비스 자체 특가 제품 구매로 서비스 홍보 및 사용자 유입 유도 |
| 4 | 2 | 인기 추천 상품 리스트 | 2 | ethan | |
| 4 | 3 | 인기 게시글 | 2 | ethan | 좋아요, 스크랩과 같은 가중치를 통해 인기글 등극 및 포인트 지급으로 커뮤니티 활동 활성화 |
| 4 | 4 | 생성 이미지 컨셉 프롬프트 | 2 | ethan | 사용자 개인 성향이 적용된 데스크 이미지 생성을 위한 프롬프트 입력 기능 제공 |
| 4 | 5 | 테스트 | 2 | ethan | 각 스프린트 마지막 단계로 단위 및 통합 테스트 진행 |
| 5 | 1 | 특가 알림 | 2 | ethan | 알림을 통해 사용자에게 서비스를 상기시키고 실제 접속 유도 |
| 5 | 2 | 가격 알림 | 2 | ethan | |
| 5 | 3 | 관리자 페이지 | 3 | ethan | 서비스 자체 특가 운영을 위해 |
| 5 | 4 | 테스트 | 2 | ethan | 각 스프린트 마지막 단계로 단위 및 통합 테스트 진행 |
| 6 | 1 | 데스크 성향 MBTI | 3 | ethan | 개인 데스크 성향을 파악하여 조금 더 개인화된 서비스를 제공하기 위해 |
| 6 | 2 | 랜덤 특가 | 3 | ethan | 서비스 내에서 진행하는 랜덤 특가 이벤트 진행 |
| 6 | 3 | 미완료 기능 진행 | 3 | ethan | 스프린트 기간 내 완료되지 못한 기능 진행 |
| 6 | 4 | 테스트 | 1 | ethan | 각 스프린트 마지막 단계로 단위 및 통합 테스트 진행 |
| 7 | 1 | 컨셉 추천 | 4 | ethan | |
| 7 | 2 | 클린봇 | 3 | ethan | |
| 7 | 3 | 테스트 | 3 | ethan | 각 스프린트 마지막 단계로 단위 및 통합 테스트 진행 |
| 8 | 1 | 기능 유지보수 | 3 | ethan | |
| 8 | 2 | 테스트 | 2 | ethan | |
| 9 | 1 | 맞춤형 특가 | 3 | ethan | |
| 9 | 2 | 제품 구매 인증 | 3 | ethan | 생성된 이미지에서 추천한 제품을 구매 인증하면 포인트 지급 |
| 9 | 3 | 기능 고도화 | 4 | ethan | |
| 9 | 4 | 테스트 | 3 | ethan | 각 스프린트 마지막 단계로 단위 및 통합 테스트 진행 |
합계 작업일수: 84일(플래닝 포인트의 총합)
Guinness
| 스프린트 | 우선순위 | 업무명 | 플래닝포인트 | 담당자 | 이유 |
|---|---|---|---|---|---|
| 1 | 1 | 아이디어 선정 및 구체화 | 4 | guinness | 사용자를 꾸준히 확보할 수 있으면서도 특정 시간에 트래픽이 몰리는 아이디어를 선정하기 위해 |
| 1 | 2 | 기획 및 문서화 | 5 | guinness | 제대로 기획하여 계획의 변경을 최소화하고 최대한 개발에 집중하기 위한 시간이다 |
| 2 | 1 | 클라우드 비용 산정 | 2 | guinness | 다양한 클라우드 서비스별로 소요되는 비용을 정리하여 어떻게 구축해야 비용을 최소화할 수 있는지 파악할 수 있음 |
| 2 | 2 | 클라우드 기술 스택 정리 및 검토 | 1 | guinness | 사용할 기술들을 검토하고, 정말 필요한 것인지, 구현 가능한 것인지 검토 |
| 2 | 3 | 빅뱅 배포 아키텍처 설계 | 0.5 | guinness | 최초로 배포할 형태를 설계 |
| 2 | 4 | 데이터베이스 배포 설계 및 구축 | 1 | guinness | 꾸준히 사용할 데이터베이스를 구축 |
| 2 | 5 | 컨테이너 배포 아키텍처 설계 | 1.5 | guinness | 컨테이너 사용 배포 형태 설계 |
| 2 | 6 | CI/CD 아키텍처 설계 | 2 | guinness | CI/CD 추가 하는 것 자체는 플래닝 포인트 입장에서 큰 소요가 아닐 것으로 예상 |
| 2 | 7 | MVP 아키텍처 설계 | 2 | guinness | MVP 버전에서는 안정성을 더 높여 구축할 계획 |
| 3 | 1 | 빅뱅 배포 | 1 | guinness | 서버 구축 자체는 하루도 안 걸리지만, 배포하는 데에 인력이 들 것으로 예상 |
| 3 | 2 | Shared 영역 구성 | 2 | guinness | 꾸준히 사용할 Shared 영역을 초기에 구축 |
| 3 | 3 | CI/CD 배포 | 3 | guinness | 환경 별, 아키텍처 별로 다를 것이므로 그것에 대한 비용 산정 |
| 3 | 4 | MVP 단계 배포 | 2 | guinness | prod 서버를 새로 만드는 것이므로, 빠르게 진행할 수 있다 |
| 3 | 5 | 알람 구축 | 2 | guinness | 스스로 문제가 생겼음을 인지하는 것은 아주 중요하다만, 배포보다 중요하지는 않다. 자동화까지 고려하면 이틀 이상 소요될 가능성도 있다. |
| 4 | 1 | 장애대응/트래픽 대응 | 2 | guinness | 단발성으로 대응하는 것은 큰 시간 소요를 가져오진 않지만, 컨텍스트 적인 측면과 발생 빈도를 고려하였다. |
| 4 | 2 | 모니터링 구축 | 2 | guinness | 이전 알람 설정에 이어 모니터링 대시보드를 구축하여 시스템 자원의 흐름 파악 |
| 4 | 3 | 테스트 시나리오 작성 | 2 | guinness | 미리 테스트에 대한 고민을 하고 시나리오를 확보 |
| 4 | 4 | 오토스케일 아키텍처 설계 | 2 | guinness | MVP 이후의 더 유연한 아키텍처를 설계 |
| 4 | 5 | 시크릿 관리 및 보안 설계 | 3 | guinness | 휴먼 에러 제거 및 효율적인 시크릿 관리를 위해 설계 |
| 5 | 1 | 테스트 시나리오 작성 및 실행 준비 | 2 | guinness | 이전 스프린트에 이어 다시 테스트 시나리오 점검 및 계획. 또한 실제 실행이 가능하도록 환경 세팅 |
| 5 | 2 | 테스트 수행 및 결과 분석 | 3 | guinness | 테스트를 진행하고 결과를 분석해 병목지점 등 문제점 파악 |
| 5 | 3 | 아키텍처 재수립 및 구축 | 4 | guinness | 파악한 문제를 기반으로 아키텍처를 개선하고 바로 적용 |
| 6 | 1 | 장애대응/트래픽 대응 | 2 | guinness | 단발성으로 대응하는 것은 큰 시간 소요를 가져오진 않지만, 컨텍스트 적인 측면과 발생 빈도를 고려하였다. |
| 6 | 2 | 최종 아키텍처 설계 | 3 | guinness | 쿠버네티스를 활용하는 아키텍처 구축 |
| 6 | 3 | 추가 기술(DB 등) 아키텍처 반영 및 구축 | 4 | guinness | 캐시 서버, 추가 DB 등 다른 파트에서 요구하는 사항들을 반영하여 구축 |
| 7 | 1 | 최종 아키텍처 구축 | 5 | guinness | 쿠버네티스 활용 아키텍처 본격적 구축 |
| 7 | 2 | 최종 아키텍처 테스트 | 2 | guinness | 기존에 확보한 시나리오를 변경된 아키텍처에 적용하여 문제점 파악 |
| 7 | 3 | 최종 아키텍처 재구축 | 4 | guinness | 파악한 문제점을 반영하여 최종 아키텍처 구축 |
| 8 | 1 | 장애대응/트래픽 대응 | 2 | guinness | 단발성으로 대응하는 것은 큰 시간 소요를 가져오진 않지만, 컨텍스트 적인 측면과 발생 빈도를 고려하였다. |
| 8 | 2 | 최종 아키텍처 고도화 설계 | 2 | guinness | 장애/트래픽 대응에서 발견한 문제점들을 개선하거나 최종 추가 기능을 반영한 아키텍처 설계 |
| 9 | 1 | 부하테스트 | 5 | guinness | 반드시 승리 |
| 9 | 2 | 최종 고도화 아키텍처 구축 | 5 | guinness | 고도화된 최종 아키텍처 구축 |
| 9 | 3 | 발표 준비(도식, 문서화 등) | 2 | guinness | 아키텍처 등 발표 준비 지원 |
합계 작업일수: 85일
Evan
| 스프린트 | 우선순위 | 업무명 | 플래닝포인트 | 담당자 | 이유 |
|---|---|---|---|---|---|
| 1 | 1 | 아이디어 도출 및 방향성 설정 | 4 | evan | 지속적인 사용자 유입이 가능하면서도 트래픽 집중 시간대가 명확한 아이템을 선정하고 구체화하는 단계 |
| 1 | 2 | 전체 구조 기획 및 문서 정리 | 5 | evan | 개발 중 불필요한 변경을 줄이고 일관된 방향으로 진행할 수 있도록 사전에 명확하게 정리 |
| 2 | 1 | 클라우드 리소스 비용 예측 | 2 | evan | 다양한 클라우드 옵션에 대한 요금을 파악하고, 효율적인 비용 구조 설계를 위한 기반 마련 |
| 2 | 2 | 클라우드 구성 요소 검토 | 3 | evan | 사용할 기술들을 목록화하고, 실제로 필요한지와 구현 가능성을 중심으로 판단 |
| 2 | 3 | 초기 배포 아키텍처 기획 | 0.5 | evan | 첫 릴리스를 위한 시스템 구조를 간단히 설계 |
| 2 | 4 | DB 설계 및 배포 환경 구축 | 2 | evan | 지속적으로 활용될 데이터베이스를 설정하고 운영환경을 구성 |
| 2 | 5 | 컨테이너 환경 설계 | 0.5 | evan | 컨테이너 기반 배포 전략을 설정하고 실행 계획 수립 |
| 2 | 7 | MVP 버전 구조 설계 | 1 | evan | 최소 기능 제품을 안정적으로 운영하기 위한 기술적 기반 마련 |
| 3 | 1 | 초기 배포 실행 | 1 | evan | 서버 구축은 간단하나, 실제 배포 과정에 인력이 필요한 만큼 일정 고려 |
| 3 | 2 | 공통 리소스 영역 설정 | 2 | evan | 프로젝트에서 공통으로 사용될 영역을 미리 구성해 반복 작업 최소화 |
| 3 | 3 | 컨테이너 기반 서비스 배포 | 1 | evan | 사전에 구성된 서버에 배포하는 작업이므로 비교적 빠르게 수행 가능 |
| 3 | 4 | 자동화 배포 구성 | 2 | evan | 환경 및 구조에 따라 달라질 수 있어, 예상 소요시간 반영 |
| 3 | 5 | 프로덕션 초기 배포 | 2 | evan | 새로운 운영 환경을 구축하므로 빠르게 작업할 수 있는 범위 내에서 진행 |
| 3 | 6 | 알림 시스템 설계 | 2 | evan | 시스템 이상을 빠르게 인지할 수 있도록 경고 및 알람 설정을 구성 |
| 4 | 1 | 긴급상황 및 트래픽 대응 체계 | 2 | evan | 빈번하지는 않지만, 상황 발생 시 빠른 판단을 위해 최소한의 준비 필요 |
| 4 | 2 | 모니터링 환경 구축 | 2 | evan | 이전의 알림 설정과 연계해 자원 흐름을 시각적으로 파악 가능하도록 대시보드 구성 |
| 4 | 3 | 테스트 전략 수립 | 2 | evan | 실제 테스트 전 시나리오를 사전에 정의하고 설계 |
| 4 | 4 | 유연한 확장 구조 설계 | 2 | evan | 향후 트래픽 증가를 고려한 자동 확장 구조 설계 |
| 4 | 5 | 보안/시크릿 관리 체계 구성 | 3 | evan | 실수 방지 및 접근 제어를 위한 시크릿 관리 방식 도입 |
| 5 | 1 | 테스트 실행 준비 | 2 | evan | 기존 시나리오를 바탕으로 환경 설정과 실행을 위한 마지막 점검 |
| 5 | 2 | 테스트 실행 및 피드백 정리 | 3 | evan | 실제 테스트 진행 후 데이터 기반으로 시스템 상태 및 병목 지점 분석 |
| 5 | 3 | 구조 개선 및 반영 | 4 | evan | 문제점을 바탕으로 구조를 다시 설계하고 직접 개선 작업까지 수행 |
| 6 | 1 | 트래픽 이슈 및 오류 대응 | 2 | evan | 긴급 대응은 자주 필요하진 않지만, 시스템 전반에 미치는 영향은 커서 충분한 준비 필요 |
| 6 | 2 | 최종 인프라 설계 | 3 | evan | 전체를 아우를 수 있는 구조로 쿠버네티스를 활용한 통합 아키텍처 구축 |
| 6 | 3 | 추가 기술 반영 및 구성 | 4 | evan | 캐시, 보조 DB 등 협업 파트의 요청을 반영해 인프라 재정비 |
합계 작업일수: 57일(플래닝 포인트의 총합)
Brix
| 스프린트 | 우선순위 | 업무명 | 플래닝포인트 | 담당자 | 이유 |
|---|---|---|---|---|---|
| 1 | 1 | 아이디어 선정 | 4 | brix | 지속적인 사용자 유입이 가능하면서도 트래픽 집중 시간대가 명확한 아이템을 선정하고 구체화하는 단계 |
| 1 | 2 | 기획 및 문서화 | 5 | brix | 개발 중 불필요한 변경을 줄이고 일관된 방향으로 진행할 수 있도록 사전에 명확하게 정리 |
| 2 | 2 | OpenAI API 설계 | 2.5 | brix | 백엔드와 클라우드의 개발 투입을 빠르게 하기 위해 |
| 2 | 2 | DALL-E 3 API 설계 | 2.5 | brix | 백엔드와 클라우드의 개발 투입을 빠르게 하기 위해 |
| 2 | 2 | Fast API 설계 | 2 | brix | 백엔드와 설계한 API와의 송수신을 원활히 하기 위함 |
| 2 | 1 | 통신규약협의 | 1.5 | brix | 백엔드와 설계한 API와의 송수신을 원활히 하기 위함 |
| 2 | 1 | 설계구조 검토 및 회의 | 1.5 | brix | 설계구조가 백엔드와 잘 맞는지 확인 및 검토를 하기 위함 |
| 3 | 1 | 개발 환경 및 프로젝트 세팅 | 0.5 | brix | 개발을 원활히 하기 위함 |
| 3 | 2 | desk_classify.py | 0.5 | brix | desk 판단, 서버의 부담을 줄이기 위함 |
| 3 | 2 | img2txt.py | 1 | brix | 이미지를 텍스트로 변환하기 위함 |
| 3 | 3 | txt2img.py | 1 | brix | 텍스트를 이미지로 변환하기 위함 |
| 3 | 3 | naverapi.py | 0.5 | brix | 추천된 아이템의 링크를 받기 위함 |
| 3 | 3 | main.py | 0.5 | brix | 모듈화 된 각종 기능을 FastAPI로 연동하기 위함 |
| 3 | 3 | Local Test | 0.5 | brix | 백엔드와 합치기 전, 서버에 올리기 전 디버깅을 위한 테스트 |
| 3 | 3 | Debugging | 1 | brix | 버그와 오류를 해결하기 위함 |
| 3 | 4 | 초기 개발 결과 공유 및 보완사항 도출 | 0.5 | brix | 해당 결과를 바탕으로 백엔드와의 송수신을 위함 |
| 3 | 4 | SAM 2.1 모델 연구 | 0.5 | brix | MVP 모델 이후 사용자 경험을 끌어 올리기 위함 |
| 3 | 4 | 보완사항 추가 | 1 | brix | 해당 결과의 피드백을 수용하기 위함 |
| 4 | 1 | 배포 일정 정리 및 1차 업데이트 출시 | 0.5 | brix | 배포 일정을 구체적으로 협의하여 일정을 맞추기 위함 |
| 4 | 1 | 원본 이미지 유지 모델 연구 방안 모색 | 1 | brix | img2txt → txt2img 는 원본 이미지 유지를 잘 못하므로 |
| 4 | 2 | SAM 2.1 모델 + Auto Labeling 연구 | 6 | brix | Auto Labeling을 통해 생성형 이미지 학습을 부가적으로 하기 위해서 |
| 4 | 3 | 연구 모델 탑재 | 1 | brix | 실제 GPU서버에 올려 테스트 하기 위해 |
| 4 | 3 | Local Test 및 v1과 성능비교 | 1 | brix | MVP모델과 성능을 비교하기 위함 |
| 4 | 4 | 모델 성능 결과 공유 | 0.5 | brix | 모델의 성능을 팀원들과 공유하여 일정과 배포 기획을 협의하기 위함 |
| 5 | 1 | 2차 업데이트 개발 방향 논의 | 0.5 | brix | 2차 업데이트의 개발 방향을 논의하기 위함 |
| 5 | 1 | 요일별 다른 이미지 생성 고도화 | 2 | brix | 사용자가 해당 서비스를 여러 번 이용하기 위함 |
| 5 | 2 | 이미지 내 좌표 생성 방안 논의 | 5 | brix | 추천된 아이템을 직관적으로 확인할 수 있도록 |
| 5 | 3 | 2차 성능 테스트 | 1 | brix | 모델 2차 테스트 |
| 5 | 3 | 2차 개발 결과 공유 및 보완사항 도출 | 0.5 | brix | 2차 개발 결과를 공유하고 보완사항을 도출하여 업데이트를 할 수 있도록 |
| 6 | 1 | 배포 일정 정리 및 2차 업데이트 출시 | 0.5 | brix | 배포 일정을 구체화하여 2차 업데이트를 완벽하게 할 수 있도록 |
| 6 | 2 | DeepSeek janus pro 7b 고도화 | 5 | brix | 해당 모델이 서비스 특화 AI가 될 수 있도록 고도화 |
| 6 | 3 | 3차 성능 테스트 | 1 | brix | Stable Diffusion과 Janus, DALL-E3 모델 3차 테스트 |
| 6 | 3 | 모델 선택(diffusion vs janus) | 0.5 | brix | 3차 테스트까지 완료한 자료를 토대로 Diffusion과 Janus 중 모델 서비스 특화 AI를 하나만 골라 개발하기 위함 |
| 6 | 3 | 모델 개발 방향 논의 | 0.5 | brix | 모델이 서비스 특화 AI가 될 수 있도록 고도화하기 위함 모델 개발 방향을 논의 |
| 6 | 4 | 선택된 모델 Local Test | 2 | brix | 선택된 모델이 실제 서버에 탑재되기 위한 사전 점검 |
| 6 | 4 | 모델 개발 결과 공유 및 회고 | 0.5 | brix | 모델의 결과를 팀원들과 공유함으로써 앞으로의 업데이트 내역 구체화 |
| 7 | 1 | 3차 업데이트 개발 방향 논의 | 0.5 | brix | 3차 업데이트를 구체화하기 위함 |
| 7 | 3 | 선택된 모델 고도화 | 3 | brix | 선택된 모델을 좀더 고도화하여 사용자들에게 좋은 경험을 선사하기 위함 |
| 7 | 2 | 클린봇 설계 및 개발 | 5 | brix | 불건전한 이미지 등이 커뮤니티에 올라기지 않도록 자동화하기 위함 |
| 7 | 2 | 클린봇 Test 및 디버깅 | 1 | brix | 모델의 결과를 팀원들과 공유함으로써 앞으로의 업데이트 내역 구체화 |
| 7 | 4 | 3차 개발결과 공유 및 보완사항 도출 | 0.5 | brix | 3차 업데이트를 구체화하기 위함 |
| 8 | 1 | 배포 일정 정리 및 3차 업데이트 출시 | 0.5 | brix | 3차 업데이트 출시하기 전 배포일정을 구체적으로 맞추기 위함 |
| 8 | 2 | 유지보수 및 디벨롭 | 4 | brix | 사용자들에게 좋은 경험을 선사하기 위함 |
| 8 | 3 | 사용자 반응 분석, 유지보수 계획 공유 및 회고 | 0.5 | brix | 반응을 분석하여 최종 4차 업데이트를 잘 마무리 하기 위함 |
| 9 | 1 | 부하테스트 주간 | 5 | brix | 서버의 내구도를 확인하기 위함 |
| 9 | 2 | 4차 업데이트 개발 방향 논의, 발표 준비 계획 수립 | 0.5 | brix | 마지막 4차 업데이트를 출시하기 전 배포일정을 구체적으로 맞추기 위함 |
| 9 | 3 | 데스크 성향 진단 등 | 5 | brix | 사용자 경험을 높일 수 있는 서비스를 출시하기 위함 |
| 9 | 3 | AI 기능 발표 자료 정리 | 2 | brix | 마지막 최종 발표 준비를 하기 위함 |
| 9 | 4 | 4차 개발 결과 공유 및 보완사항 도출 | 0.5 | brix | 4차 업데이트 출시 직전 사전 점검 |
합계 작업일수: 83일(플래닝 포인트의 총합)
Woody
| 스프린트 | 우선순위 | 업무명 | 플래닝포인트 | 담당자 | 이유 |
|---|---|---|---|---|---|
| 1 | 1 | 아이디어 선정 및 구체화 | 4 | woody | |
| 1 | 2 | 기획 및 문서화 | 5 | woody | |
| 2 | 1 | Open AI API | 1 | woody | |
| 2 | 2 | DALL E API | 5 | woody | 이미지 생성 모델을 사용하여 데스크 이미지 생성 |
| 2 | 3 | API 명세서 작성 | 4 | woody | 모델을 사용하기 위한 API 명세서 작성 |
| 3 | 1 | 생성형 이미지 프롬프트 엔지니어링 | 3 | woody | img2txt + txt2img 설계 |
| 3 | 2 | GCP 연결 | 1 | woody | 백엔드와 통신하여 진행 |
| 3 | 3 | SAM 2.1 모델 + Auto Labeling 연구 | 2 | woody | 객체 검출 및 라벨링 연구 |
| 3 | 4 | 디버깅 | 2 | woody | GCP 연동 후 벡엔드와 통신하며 진행 |
| 4 | 1 | 배포 일정 정리 및 1차 업데이트 출시 | 0.5 | woody | |
| 4 | 2 | Diffusion Model 구현 + Fine tuning | 5 | woody | Stable Diffusion 모델 구현 시작 |
| 4 | 3 | 모델 test | 3 | woody | Stable Diffusion 모델 테스트 |
| 4 | 4 | test 회고 및 회의 | 1 | woody | brix와 테스트 결과 공유 및 팀원과 회의 |
| 4 | 5 | 사용자 반응 분석, 유지보수 계획 공유 및 회고 | 0.5 | woody | 필요한 기능들 체크해서 구현일정 정리하기 |
| 5 | 1 | 2차 업데이트 개발 방향 논의 | 0.5 | woody | |
| 5 | 2 | 요일 별 다른 컨셉의 이미지 생성 | 1 | woody | |
| 5 | 3 | DB 설계 | 2 | woody | 다른 컨셉 이미지 생성에 필요한 DB 설계 |
| 5 | 4 | 추가한 기술 test | 3 | woody | |
| 5 | 5 | 디버깅 | 1 | woody | 테스트 결과 보고 회의 후 기능 추가 |
| 5 | 6 | 2차 성능 test | 1 | woody | |
| 5 | 7 | 2차 개발 결과 공유 및 보완사항 도출 | 0.5 | woody | |
| 6 | 1 | 배포 일정 정리 및 2차 업데이트 출시 | 0.5 | woody | |
| 6 | 2 | 3차 배포를 위한 모델링 테스트 | 5 | woody | Diffusion 모델 성능 비교(정밀 프롬프트 엔지니어링) |
| 6 | 3 | 3차 성능 test | 2 | woody | 테스트 결과 보고 회의 후 기능 추가 |
| 6 | 4 | 모델링 성능 회고 및 개발 방향성 체크 | 2 | woody | |
| 6 | 5 | 사용자 반응 분석, 유지보수 계획 공유 및 회고 | 0.5 | woody | |
| 7 | 1 | 3차 업데이트 개발 방향 논의 | 0.5 | woody | |
| 7 | 2 | 3차 출시 회고 및 수정사항 모델링 | 4 | woody | 모델 배포를 위한 마지막 정비 |
| 7 | 3 | 성능 test | 4 | woody | 모델 배포를 위한 마지막 테스트 |
| 7 | 4 | 생성 이미지 컨셉 추천 확인 | 1 | woody | 생성형 이미지가 잘 작동하는지 확인하기 |
| 7 | 5 | 3차 개발 결과 공유 및 보완사항 도출 | 0.5 | woody | 팀원 회의 후 기능 추가 |
| 8 | 1 | 배포 일정 정리 및 3차 업데이트 출시 | 0.5 | woody | |
| 8 | 2 | 홍보, 사용자 피드백 수집 및 분석, 유지보수 | 4 | woody | 배포 후 피드백 받으면서 일정 확인하기 |
| 8 | 3 | 사용자 반응 분석, 유지보수 계획 공유 및 회고 | 0.5 | woody | 사용자가 원하는 기능 피드백 |
| 9 | 1 | 부하테스트 | 5 | woody | 과도한 트래픽 발생시 어떻게 할 것인지 시나리오 작성하기 |
| 9 | 2 | 4차 업데이트 개발 방향 논의, 발표 준비 계획 수립 | 0.5 | woody | |
| 9 | 3 | 데스크 성향 진단 및 공유(데스크 MBTI) | 1 | woody | 데스크 사진을 통해서 MBTI 유추하는 기능 추가 |
| 9 | 4 | 기존 서비스 유지보수 | 4 | woody | 피드백 받은 부분 보수하기 |
| 9 | 5 | 발표 자료 정리 | 2 | woody | 최종 발표 |
| 9 | 6 | 4차 개발 결과 공유 및 보완사항 도출, 프로젝트 전체 회고 및 발표 피드백 공유 | 0.5 | woody | 팀 프로젝트 회고 |
합계 작업일수: 84일(플래닝 포인트의 총합)