BACKEND_ROADMAP.md

Qello Backend Roadmap

기준일: 2026-08-03 (5주차 시작)

프로젝트 종료: 2026-08-30 (8주차 종료)

1. 제품 범위

Qello는 승인된 사용자별 질문을 바탕으로 사진이나 짧은 글을 작성해 8개 방향 중 하나로 보내고, 해당 방향의 익명 사용자들이 만료 전까지 답하는 방향 기반 소통 서비스다. 팔로우, 사용자 검색, 자유 DM, 전 세계 공개 피드는 제공하지 않는다.

백엔드가 지원해야 할 기능 경계는 다음과 같다.

ID	기능	백엔드 책임
F01	익명 계정·고유 닉네임	인증, 정규화 중복 검사, 변경 제한, 차단 ID 유지
F02	사용자별 오늘의 질문	승인 질문 풀, 재현 가능한 배정, 반복 제외, 알림 설정
F03	질문 제안·검토	상태 전이, 운영 검토, 승인 질문 기반 작성, 멱등 발송
F04	8개 방향·열람 자격	45도 구간, 거리·위치 유효성, 수신자 스냅샷, 만료
F05	지도 활동 마커	권역 집계, 소수 사용자 보호, 열람 가능 개수 분리
F06	피드·답변·댓글·좋아요	접근 제어, 단일 좋아요, 정렬, 삭제·숨김·만료
F07	활동 알림	인앱·푸시 이벤트, 사용자 설정, 중복 억제, 실패 재처리
F08	신고·차단	콘텐츠 신고, 검토 상태, 사용자 차단, 감사 이력
F09	마이페이지	본인 활동 조회, 공개 프로필·인기 지표 제한
F10	콘텐츠 안전 필터	비속어 텍스트와 선정적·폭력적 이미지 검사, 보류·거절

2. 콘텐츠 안전 요구사항

모든 사용자 생성 텍스트는 질문 제안, 방향 글, 답변, 댓글, 닉네임의 맥락별 정책으로 검사한다. 단순 단어 포함 여부만으로 영구 제재하지 않고 정규화, 우회 표기, 오탐 예외, 정책 버전을 기록한다.

이미지는 업로드 직후 격리 상태로 저장하고 EXIF 위치정보를 제거한 뒤 선정성·폭력성 검사를 통과해야 공개한다. 결과는 원본 모델 응답 전체가 아니라 공급자, 정책 버전, 범주별 판정, 임계값, 처리 시각, 재검토 상태만 안전하게 보존한다.

권장 상태:

PENDING_SCAN → APPROVED
             → REVIEW_REQUIRED
             → REJECTED
             → SCAN_FAILED

검사 timeout이나 외부 API 장애 때는 공개를 허용하지 않는 fail-closed 정책을 기본으로 한다. 재시도는 지수 backoff와 멱등 키를 사용하고, 운영자 재검토·이의 제기·감사 이력을 지원한다. 원본 이미지는 최소 보존 원칙과 만료 정책을 적용한다.

3. 5~8주차 스프린트

5주차 · Foundation (2026-08-03~2026-08-09)

목표는 구현 계약과 가장 위험한 기술 결정을 확정하고 개발 가능한 기반을 만드는 것이다.

• Qello 이름과 GitHub 기반 워크플로 전환
• 제품 ERD·도메인 경계 확정
• API·오류·이벤트·멱등성 계약
• Spring Boot 모듈·패키지 및 로컬 개발 기반
• AWS 최소비용 아키텍처와 IaC 선택, 비용 가정
• 텍스트·이미지 안전 필터 공급자/임계값/실패 정책 spike

완료 기준: 핵심 ADR과 API/스키마 계약이 리뷰 가능하고, Week 6 기능을 병렬로 시작할 수 있으며, 인프라는 plan-only 원칙을 유지한다.

6주차 · Core creation (2026-08-10~2026-08-16)

목표는 사용자가 질문을 받고 안전한 방향 글을 발송하는 핵심 쓰기 경로를 완성하는 것이다.

• 익명 계정·고유 닉네임
• 질문 템플릿·사용자별 배정·질문 제안/검토
• 8개 방향 계산과 수신 자격 스냅샷
• 이미지 업로드·EXIF 제거·격리 저장
• 비속어, 선정성, 폭력성 안전 검사 파이프라인
• 방향 글 발송·만료·멱등성

완료 기준: 핵심 쓰기 경로의 단위·통합 테스트가 통과하고 미검사 콘텐츠가 공개되지 않으며 경계각·중복 요청·외부 검사 장애가 검증된다.

7주차 · Interaction (2026-08-17~2026-08-23)

목표는 방향 기반 읽기·상호작용과 안전 운영 흐름을 완성하는 것이다.

• 열람 가능한 방향 피드와 상세 조회
• 답변·댓글·좋아요
• 지역 활동 마커와 소수 사용자 보호
• 활동 알림과 실패 재처리
• 신고·차단·운영 검토

완료 기준: 접근 권한 밖 콘텐츠가 노출되지 않고 만료·차단·숨김이 모든 읽기 및 쓰기 경로에 일관되게 적용되며 알림 중복이 억제된다.

8주차 · Stabilization & release (2026-08-24~2026-08-30)

목표는 마이페이지를 포함한 MVP 범위를 닫고 성능·보안·복구·배포 준비 증거를 확보하는 것이다.

• 마이페이지 활동 기록
• 핵심 사용자 여정 E2E 및 회귀 테스트
• 방향 계산·피드·지도 집계 부하와 쿼리 최적화
• 개인정보·보안·콘텐츠 안전 검토
• AWS IaC plan, CI/CD, 관측성, 백업·복구 runbook
• 버그 수정, API 문서, 릴리스 체크리스트

완료 기준: P0 시나리오가 모두 통과하고 남은 위험이 Issue로 분리되며, apply나 프로덕션 배포 없이도 검토 가능한 plan과 운영 문서가 준비된다.

4. 우선순위 원칙

• P0: Week 8 MVP 데모와 데이터·사용자 안전에 필수
• P1: MVP 품질과 운영 가능성에 중요하나 제한된 대체 경로가 있음
• P2: 종료 후에도 수행 가능한 개선

Priority, Sprint, Status, Work type은 GitHub Project 필드로 관리한다. 백로그는 draft item으로 유지하고 실제 구현을 시작할 때만 repository Issue로 변환한다. 변환된 Issue에는 canonical type: * 하나와 필요한 area: *만 붙인다.

5. 공통 완료 조건

• API와 DB 변경이 문서 또는 마이그레이션으로 추적된다.
• 권한, 만료, 차단, 숨김, 콘텐츠 안전 정책이 서버에서 강제된다.
• 중복 요청과 재시도는 멱등하게 처리된다.
• 단위·통합 테스트가 분리되고 JUnit 5 메타데이터 규칙을 충족한다.
• 로그·보고서에 정확 위치, 원본 민감 콘텐츠, 토큰, 계정 식별자를 남기지 않는다.
• 인프라 변경은 정적 검증과 plan까지만 자동 실행한다.