Skip to content

Latest commit

 

History

244 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

RooMory

서비스 명: RooMory - "방마다 추억이 쌓이는 공간"

설명: Room + Memory의 합성어로 방마다 추억 게시판, 미션 인증, 편지, 채팅 등의 다양한 콘텐츠의 추억이 쌓이는 공간이라는 의미를 담고 있습니다.

1. 서비스 소개

1-1. 어떤 서비스인가

기록방은 커플, 가족, 학급/동아리처럼 여러 사람이 함께 쓰는 공간입니다. 방 안에서 일상 대화, 사진이 포함된 추억, 미션 인증, 개인 편지를 기록하고, 나중에 필요한 기록만 골라 책 형태의 주문 요청까지 만들 수 있습니다.

1-2. 누구를 위한 서비스인가

타깃 사용 상황
💑 커플 기념일, 여행, 일상 대화를 한 권의 기록집으로 남기고 싶을 때
👨‍👩‍👧‍👦 가족 가족 여행 사진, 편지, 함께한 미션을 모아 보관하고 싶을 때
🏫 학급/동아리 프로젝트, 활동 인증, 구성원 기록을 정리하고 싶을 때

1-3. 주요 기능

🏠 Home 기능

내 정보와 참여 중인 Room의 흐름을 한 화면에서 확인합니다.

  • 👤 프로필

    선택한 사용자의 기본 정보와 프로필 이미지를 확인하고 수정합니다.

  • 🔔 최신 알림 Summary

    채팅, 추억, 미션, 편지의 최근 알림을 요약해 우선 확인할 일을 보여줍니다.

  • 🧭 참여중인 방 Summary

    참여 중인 Room의 핵심 정보와 최근 상태를 요약해 빠르게 이동할 수 있습니다.

  • 🗓️ My Calendar

    날짜별 채팅, 미션, 추억, 편지 기록 흐름을 달력에서 확인합니다.

🚪 Room 기능

함께 기록할 공간을 만들고, 초대와 방별 콘텐츠를 관리합니다.

  • 🧩 방 관리 대시보드

    새 Room 생성, 초대 처리, 참여 중인 Room 목록을 한곳에서 관리합니다.

    • ✨ 새 방 만들기

      방 이름, 유형, 설명을 입력해 새로운 기록 공간을 생성합니다.

    • 📨 초대 받은 방 List

      초대받은 Room을 확인하고 수락 또는 거절할 수 있습니다.

    • 🗂️ 참여 중인 방 List

      현재 참여 중인 Room의 역할, 구성원, 상태를 확인하고 이동합니다.

  • 👥 참여중인 방

    선택한 Room 안에서 대화와 여러 형태의 추억을 함께 남깁니다.

    • 💬 채팅

      방별 메시지를 작성하고 polling 기반으로 새 대화를 확인합니다.

    • 🖼️ 추억 게시판

      사진과 글을 올리고 댓글로 함께 기억을 이어갑니다.

    • ✅ 미션 인증

      기본 또는 커스텀 미션을 사진으로 인증하고 승인·동의·댓글을 관리합니다.

    • 💌 편지

      Room 구성원 한 명에게만 보이는 비공개 편지를 보냅니다.

📚 추억을 책으로 소장 기능

Room에 쌓인 기록을 선택해 템플릿 기반 책으로 구성하고 주문까지 관리합니다.

  • 📖 상품 안내

    지원하는 포토북 상품과 책 제작에 필요한 기본 정보를 확인합니다.

  • ✍️ 책 만들기

    Room, 상품, 기간, 콘텐츠를 선택해 미리보기와 예상 견적을 생성합니다.

  • ⏳ 주문 상태

    주문별 현재 제작 진행 상태와 이력을 확인합니다.

  • 🧾 주문 내역

    주문한 책의 구성, 수량, 금액 등 전체 주문 이력을 조회합니다.

2. 실행 방법 (Docker)

아래 명령은 복사해서 그대로 실행할 수 있는 기준 흐름입니다.

# 저장소 클론
git clone https://github.com/passionryu/assignment-test.git
cd assignment-test

# 환경변수 준비
# 기본값으로도 실행할 수 있지만, 로컬 포트/DB 계정 변경이 필요하면 .env를 수정합니다.
cp .env.example .env

# 실행
docker compose -f service/infra/docker-compose.yml up --build

접속 주소:

항목 주소
Client http://localhost:5173
Server http://localhost:8080
Health check http://localhost:8080/api/health

중지:

docker compose -f service/infra/docker-compose.yml down

3. 완성한 레벨

레벨 상태 구현 내용
Lv1 완료 기록방, 채팅, 추억 게시판, 미션 인증, 편지, 전체 기록 캘린더
Lv2 완료 템플릿 기반 책 만들기, 상품 선택, 미리보기/견적, 주문 생성, 주문 상태/내역, 운영자 주문 관리
Lv3 80% 완료 거시적, 미시적 UI/UX 개선과 README 정리 진행. 최종 E2E Test, 최종 제출 문서 보강 - Mobile UI 대응 미완료

4. 사용자 경험(UI/UX) 설계

4-1. 타깃 사용자

타깃 사용자는 커플/가족/학급&동아리 입니다.

모든 사용자의 Role은 "일반 사용자"로 통일되지만,
각 유저가 생성하거나 참여하는 Room의 Type은 "커플/가족/학급&동아리"로 구분됩니다.

4-2. 핵심 화면/흐름

화면 정의서는 GitHub에서 바로 확인할 수 있도록 PDF 링크를 연결했습니다.

구분 문서
Lv1 화면 정의서 SCREEN-001-main-page-screen-spec.pdf
Lv2 화면 정의서 SCREEN-004-lv2-book-order-screen-spec.pdf

4-3. 의도적으로 넣지 않은 것

제외한 기능 제외 이유
실제 회원가입/로그인 "더미 데이터 포함: 실행 직후 로그인 없이도 서비스를 바로 확인할 수 있는 최소 콘텐츠" 라는제출 요건 충족
WebSocket 채팅 채팅 기능이 Main이 아니므로, Polling으로 빠르게 기능 구현하여 Over Engineering 방지
PDF 직접 업로드 현재 MVP 수준에서 필수 기능은 아니라고 판단하여 구현 범위 제외
실결제/실환불/실배송 과제 안내문 상 구현 범위 아님 - 주문 상태 관리 검증이 목적이므로 mock 상태 전이로 대체
예치금 모델 과제 안내문 상 구현 범위 아님

4-4. 주요 화면 캡처

심사자가 실행 전 핵심 화면 흐름을 빠르게 확인할 수 있도록 데스크톱 기준 캡처를 정리했습니다. 채팅 화면은 최종 캡처 확보 후 추가합니다.

사용자 선택 화면 - 일반 사용자와 운영자 계정을 구분해 체험을 시작하는 화면
데스크톱 화면 캡처
사용자 선택 화면
홈/전체 기록 캘린더 화면 - 참여 기록방 요약과 날짜별 기록 흐름을 함께 확인하는 화면
데스크톱 화면 캡처 추가 화면 캡처
홈 추가 캡처 홈/전체 기록 캘린더 화면
방 관리 대시보드 화면 - 새 방 생성, 초대 수락/거절, 참여 기록방 초대를 관리하는 화면
데스크톱 화면 캡처
방 관리 대시보드 화면
추억 게시판 화면 - 사진과 글을 남기고 댓글로 함께 기록을 이어가는 화면
데스크톱 화면 캡처
추억 게시판 화면
미션 인증 화면 - 방별 미션 인증, 동의 상태, 댓글을 확인하는 화면
데스크톱 화면 캡처
미션 인증 화면
편지 화면 - 특정 멤버에게 보낸 비공개 편지를 확인하고 작성하는 화면
데스크톱 화면 캡처
편지 화면
책 만들기 화면 - 방, 상품, 기간, 콘텐츠를 고르고 템플릿 기반 책 주문으로 이어가는 화면
데스크톱 화면 캡처
책 만들기 화면
주문 상태/주문 상세 모달 화면 - 주문 목록에서 진행 단계와 상태 이력, 주문 상세를 확인하는 화면
데스크톱 화면 캡처 추가 화면 캡처
주문 상태/주문 상세 모달 화면 주문 상세 추가 캡처

5. 기술 스택 및 아키텍처

5-1. 기술 스택

영역 사용 기술
Frontend React 19, TypeScript, Vite 6, lucide-react
Backend Kotlin, Spring Boot 3.3, Spring Web, Spring Data JPA, QueryDSL
Database PostgreSQL 16, Flyway
Infra Docker Compose
Test/QA Gradle test, Vite build, curl smoke test, issue-scoped QA evidence

5-2. 기술 선택 근거

제한된 과제 기간 안에 기능을 빠르게 구현하고 충분히 검증하기 위해, 실무와 학부 프로젝트에서 평소 자주 사용해 온 기술 스택을 중심으로 선택했습니다. 익숙한 개발·테스트·실행 흐름을 활용해 새로운 도구를 학습하는 비용을 줄이고, UI·API·데이터베이스·실행 환경의 완성도와 검증에 집중했습니다.

5-3. 디렉터리 구조

assignment-test
├── README.md                  
├── docs                       # 기획, QA, 제출 산출물을 모아 둔 문서 영역
│   ├── assets                 
│   │   └── readme
│   │       └── screenshots    # README 주요 화면 캡처
│   ├── agents                 # AI 에이전트 협업 구조와 산출물 근거
│   │   └── assets
│   │       └── agent-system-architecture.png
│   ├── conventions            # 브랜치, 커밋, 작업 흐름 컨벤션 정의
│   │   └── ...
│   ├── plan                   # PM/PO, 화면 정의, 사용자 흐름 기획 산출물
│   │   └── screen-spec
│   │       ├── v1.0           
│   │       │   ├── SCREEN-001-main-page-screen-spec.pdf # LV 1 범위의 화면 설계서
│   │       │   ├── screen-spec.md
│   │       │   ├── user-flow.md
│   │       │   ├── approval-log.md
│   │       │   └── screens/
│   │       ├── v2.0           
│   │       │   ├── SCREEN-004-lv2-book-order-screen-spec.pdf # LV 2 범위의 화면 설계서
│   │       │   ├── screen-spec.md
│   │       │   ├── user-flow.md
│   │       │   └── approval-log.md
│   │       └── v3.0           
│   │           ├── screen-spec.md
│   │           ├── user-flow.md
│   │           └── approval-log.md
│   ├── qa                     # 이슈별 Human QA, 기술 검증, AI QA 결과
│   │   ├── issue-3/
│   │   ├── issue-4/
│   │   │   ├── QA_레포트.md # Human QA 산출물 본문
│   │   │   ├── QA_레포트.html # QA 결과 HTML 뷰어 파일
│   │   │   ├── settings-human-qa-fix.png # UI/흐름 수정 전후 증빙 스크린샷
│   │   │   ├── 보안_에이전트_보안_리뷰.md # 보안 관점 검토 기록
│   │   │   ├── 코드리뷰_에이전트_코드_리뷰.md # 코드 리뷰 이슈/권고사항 기록
│   │   │   ├── 테크리드_에이전트_1차검증.md # 기술 검증 1차 확인 문서
│   │   │   └── evidence/ # 테스트 캡처/로그 등 증빙 파일 모음
│   │   ├── ...
├── service                    
│   ├── client # TypeScript/React 기반 클라이언트 코드                  
│   │   ├── src                
│   │   ├── package.json
│   │   └── vite.config.ts
│   ├── server # Kotlin/Spring Boot 기반 서버 코드                 
│   │   ├── src                
│   │   ├── build.gradle.kts
│   │   └── gradlew
│   └── infra # Docker Compose와 로컬 실행 인프라
│       └── docker-compose.yml

6. AI 도구 사용 내역

6-1. Multi-Agent 기반 Harness Setting

작업의 효율을 위해 6개의 AI Agent들과 함께 작업을 진행했습니다. 각각 Agents들은 다음과 같습니다.

  • 🧭 PM/PO Agent : 개발자와 함께 Agent들을 오케스트레이션 (Agent 총괄, 결과물 점검, 개발자의 과제 수행 과정 어시스트)
  • 🎨 Planning & UI/UX Agent : 서비스 기획 과정 어시스트, UI/UX 점검, 화면 설계서 기획/제작/점검
  • 🏗️ Tech Lead Agent : 요구사항에 대한 기술 설계 전담, Dev Agent의 결과물에 대한 Happy/Edge Case 1차 검증
  • 💻 Full Stack Dev Agent : 설계를 기반으로 구현 전담
  • 🔍 Review/Security Agent : Code Review, 보안 취약점 Check
  • 🧪 AI QA Agent : PM/PO Agent가 분류한 QA Level(Smoke, Focused, Full)에 따라 PlayWright 기반 E2E QA 진행

6-2. Github Kanban Board에 명시된 Work-Flow를 따르는 Agents

Github Kanban Board에 작업 Work-Flow를 사전 정의한 후, 각 단계 별로 Agent들을 할당하여 개발자가 정의한 순서대로 차례대로 Agent들이 작업을 이어 받는 작업 환경을 세팅했습니다.
-> Kanban Board Link : https://github.com/users/passionryu/projects/6
각각 Work-Flow는 다음과 같습니다.

  • 🗒️ Backlog : 체계적인 기획/설계 이전 간단한 아이디어 스케치/기록 (개발자 혹은 PM/PO Agent 개입)
  • 🧠 Plan : Backlog에 있는 Issue에 대한 기획 (Planning & UI/UX Agents 개입)
  • 🛠️ Implement : 기획된 작업에 대한 기술적 설계/구현/1차 검증 (Tech Lead Agent, Full Stack Dev Agent 개입)
  • 🔍 Review : 코드 리뷰/보안 취약점 점검 (Code Review/Security Agent 개입)
  • 🧪 AI QA : PM/PO Agent가 정의한 QA Levet에 따라 E2E QA 진행 (QA Agent 개입)
  • 🧭 PM Final Check : PM/PO Agent의 최종 점검 (PM/PO Agent 개입)
  • 👤 Human QA : 개발자의 최종 QA 및 산출물 점검
  • ✅ Done : 완료 단계 (Main에 merge 후, Issue Close)

각 Agent들은 할당된 역할과 위치가 존재하며, 개발자는 설계/검증 위주로 개입하고 중간 단계는 PM/PO 에이전트가 주도하여 Agent들과 상호작용합니다.

AI Agent System

AI 도구 활용 내용
Codex Multi-Agent 시스템 가동, 기획, 설계, 구현, 코드 리뷰, 보안 검증, QA, 문서화
Perplexity 자료 조사, 기존 서비스 벤치마킹
GPT 기타 AI 작업

7. 설계 의도

7-1. 왜 이 서비스 아이디어를 선택했는가

[벤치마킹 과정]

기획을 시작하기 전, GitHub에 공개된 유사 과제 레포지토리 7개를 분석했습니다. 단순히 화면의 구성만 비교하지 않고 서비스 주제, 사용자가 기록을 남기는 계기, 콘텐츠 구조, 그리고 기록이 인쇄 주문으로 이어지는 흐름을 중심으로 살폈습니다.

커플, 팬, 독서, 여행처럼 하나의 관심사나 관계를 중심으로 설계한 사례들이 많았습니다.
이를 보며, 하나의 특정 집단에 집중하는 서비스도 가치가 있지만, 조금 더 다양한 특징의 집단이 범용적으로 사용할 수 있는 서비스를 기획해보고자 기존 커플 관련된 서비스에서 다양한 집단으로 확장하는 서비스를 기획했습니다.

[서비스 확장 및 커스터마이징]

Roomory는 특정 주제를 별도 서비스로 나누지 않고, 사람들이 함께 기록을 쌓는 단위인 Room을 공통 기반으로 삼았습니다. 커플, 가족, 학급, 동아리처럼 관계와 목적은 달라도 대화·사진·미션·편지처럼 함께 남기는 기록의 형태는 유사하다는 판단입니다.

각 Room은 구성원과 목적에 따라 이름, 설명, 기본 미션, 기록 내용이 달라집니다. 이를 통해 커플의 기념일 기록, 가족 여행 앨범, 학급 또는 동아리의 프로젝트 아카이브처럼 동일한 제품 구조 안에서 서로 다른 사용 맥락을 수용할 수 있도록 기획했습니다.

[최종적으로 선택한 기획 방향성]

최종 방향은 “방마다 추억이 쌓이고, 필요한 순간 한 권의 책으로 소장하는 공간”입니다. 사용자는 일상적으로 채팅, 추억 게시글, 미션 인증, 편지를 남기고, 이후 원하는 Room과 기간의 기록을 골라 템플릿 기반 책으로 구성합니다.

따라서 Roomory는 단순 게시판이나 단순 포토북 주문 서비스가 아닙니다. 함께 남긴 기록을 축적하고, 다시 읽기 좋게 정리하며, 실물로 소장하는 경험까지 하나의 흐름으로 연결하는 범용 협업 기록 서비스로 정의했습니다.

7-2. 사업 가능성을 어떻게 보는가

본 서비스는 “기록을 남기는 동기”와 “기억을 실물로 남기고 싶다는 수요”를 동시에 노린다. 사용자는 이미 매일 기록 콘텐츠를 생성하고 있지만, 이를 구조화해 정리·보관·소장하는 흐름이 분산돼 있어 상품화할 접점이 필요하다.
Roomory는 이 접점을 ‘방 단위 협업 기록 → 추려 담기 → 책 제작 주문’으로 단순화한 점이 핵심이다.

  • 시장성: 커플/가족/학급/동아리처럼 협업형 기록 소비자는 규모가 작지 않고, 기념일·여행·프로젝트 등 이벤트 기반 수요가 꾸준히 발생한다.
  • 수익화 가능성: 초기에는 주문형 수익(책 제작 요청) 중심으로 시작하고, 추후 커스텀 템플릿·고급 편집 옵션·선물 기능으로 확장이 가능하다.
  • 확장성: 현재은 MVP이지만, 재구매/재발행 UX와 시즌별 캠페인(졸업, 기념일, 입학/입대, 송별회 등)로 재구매 흐름을 만들 수 있다.

7-3. 더 시간이 있었다면 추가할 기능

  • Mobile/Tablet 화면 UI 대응
  • PDF 업로드 방식의 제품 제작 방식
  • 제품 미리보기 기능 고도화

About

(Full-Stack 개발자) 구현 과제 전형

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages