[프로젝트 개요] 프로젝트 소개 및 기획

목차

• 프로젝트 소개
• 기획 배경
• 서비스 목표
• 타겟 사용자
• 기능 범위 결정 과정
• 개발 일정 설계
• 주요 기능
• 기술 스택
• Backend
• Frontend
• Infra
• 시스템 아키텍처
• ERD

프로젝트 소개

GitHub 바로가기

 기획 배경

평소 독서를 좋아하고 읽은 책을 기록하는 습관이 있었다. 그런데 막상 꾸준히 기록하려고 하면 마땅한 공간이 없었다. 메모 앱, 노트, 사진 등 여러 곳에 나눠서 적다 보면 어느 순간 흐름이 끊기고 기록 자체를 포기하게 된다. 기록은 있는데 한눈에 보이지 않으니 내가 얼마나 읽었는지, 어떤 책을 좋아하는지도 파악하기 어렵다.

 

그러다 문득 "내가 원하는 대로 직접 만들면 되겠다"는 생각이 들었다. 마침 백엔드 개발자를 목표로 하고 있었고, 내가 실제로 쓰고 싶은 서비스를 만드는 게 가장 좋은 공부라고 생각했다. 읽은 책의 기록과 메모, 월간·연간 독서 목표, 통계 시각화, 도서 추천, 독서 커뮤니티까지 내가 원하는 기능을 하나씩 직접 설계하고 구현한 것이 Booktine이다.

 서비스 목표

독서 기록을 한 곳에서 관리하고, 목표를 설정하고, 얼마나 읽었는지 한눈에 파악할 수 있는 서비스를 만드는 것이 목표였다. 단순한 기록 저장을 넘어 독서 습관을 만들고 유지하는 데 실질적으로 도움이 되는 서비스를 지향했다.

 타겟 사용자

• 독서를 좋아하고 읽은 책을 기록하는 습관이 있는 사람
• 독서 목표를 세우고 꾸준히 관리하고 싶은 사람

---

 기능 범위 결정 과정

기능을 P1 / P2 / P3 세 단계로 나눠 우선순위를 정했다.

 

P1 - 핵심 기능 (반드시 구현)

독서 기록 서비스의 본질에 해당하는 기능들이다. 회원가입·로그인, 게시물 CRUD, 메모 CRUD, 목표 설정, 기본 통계가 여기에 해당한다. 이 기능들 없이는 서비스 자체가 성립하지 않는다고 판단했다.

 

P2 - 보완 기능 (있으면 좋은 기능)

P1만으로는 서비스가 단조롭기 때문에 사용성을 높여주는 기능들을 P2로 분류했다. 키워드 검색, 독서 상태 필터, 장르별 통계, 도서 추천이 여기에 해당한다. 필수는 아니지만 빠지면 아쉬운 기능들이다.

 

P3 - 확장 기능 (시간이 남으면 구현)

커뮤니티, 리마인더, 관리자 기능은 독서 기록 서비스의 핵심과는 거리가 있다고 판단해 P3로 미뤘다. 서비스의 본질적인 기능을 먼저 완성한 뒤 시간이 남을 때 구현하는 방향으로 결정했다. 독서 챌린지는 기획은 해뒀지만 최종적으로 구현하지 않았다.

---

 개발 일정 설계

백엔드를 먼저 완벽하게 구현한 뒤 프론트엔드를 진행하는 것을 원칙으로 잡았다. 백엔드 개발자를 목표로 하는 만큼 백엔드에 시간을 충분히 투자하고, 프론트는 백엔드가 완성된 상태에서 연결에 집중하는 방식이었다.

D1 ~ D9는 백엔드 전체 구현, D9-1은 리팩토링, D10 ~ D12는 프론트엔드 구현, D13 ~ D14는 배포 및 마무리로 일정을 구성했다.

 주요 기능

기능	설명
독서 기록 (Book Note)	독서 상태(읽는 중 / 완독 / 일시정지 / 읽고 싶음) 관리, 별점·한줄평·장르 기반 노트 작성
메모 관리	도서 단위로 메모 작성·수정·삭제, 책을 읽으며 남긴 문장·감상·요약 정리
목표 및 통계 (Progress)	월간·연간 독서 목표 설정, 장르 분포·월별 완독·연간 요약 시각화
도서 추천	알라딘 API 연동, 베스트셀러·장르 기반 추천, 저장 및 목록 관리
독서 커뮤니티	게시글 작성·수정·삭제, 댓글·대댓글·좋아요
리마인더	독서 리마인더 등록, SSE 기반 실시간 알림 수신
관리자	사용자·게시글·장르·문의 목록 조회, 장르 추가·삭제

---

기술 스택

 Backend

구분	기술	선택 이유
Language	Java 21 GraalVM	Record, Switch Expression 등 최신 문법 활용, GraalVM 네이티브 이미지로 시작 시간 단축
Framework	Spring Boot 3.3	Spring Security 6, Virtual Thread 등 최신 기능 활용
Persistence	Spring Data JPA QueryDSL	동적 쿼리를 타입 안전하게 작성하기 위해 QueryDSL 도입
Database	MySQL 8 H2	관계형 데이터 구조에 적합, 로컬에서는 H2로 빠르게 검증
Auth	JWT Redis	Stateless 인증 구조, Redis로 Refresh Token 및 블랙리스트 관리
Storage	AWS S3	프로필 이미지, 게시물 표지 이미지 저장
External	Aladin API SMTP	도서 검색·추천 연동, 이메일 인증·비밀번호 재설정

 Frontend

구분	기술	선택 이유
Framework	React 18 TypeScript	컴포넌트 재사용성과 타입 안전성 확보
Styling	Tailwind CSS v3 shadcn/ui	유틸리티 기반으로 빠른 UI 구성, shadcn/ui로 일관된 컴포넌트 관리
HTTP	Axios	인터셉터로 Bearer Token 자동 주입 및 토큰 재발급 처리

 Infra

구분	기술	선택 이유
Compute	AWS EC2 Docker	컨테이너 기반으로 운영 환경 일관성 확보
Database	AWS RDS MySQL 8	관리형 DB로 운영 부담 최소화
Cache	AWS ElastiCache Redis	토큰 저장, 블랙리스트, 인증 코드, 실패/잠금 정보 관리
Storage / CDN	AWS S3 CloudFront	정적 파일 서빙 및 이미지 CDN 처리
Network	ALB HTTPS	도메인 기반 라우팅, SSL 인증서 적용

---

시스템 아키텍처

클라이언트(React)는 CloudFront를 통해 정적 파일을 서빙받고, API 요청은 ALB를 거쳐 EC2의 Spring Boot 컨테이너로 전달된다. 모든 요청은 JwtFilter에서 토큰 검증 및 블랙리스트 확인을 거치고, Spring Security에서 인증·인가를 처리한다. 리마인더 알림은 SSE로 클라이언트와 직접 연결되며, 외부 연동으로 Google OAuth2, 알라딘 API, SMTP, AWS S3를 사용한다.

---

ERD

총 11개 테이블로 구성된다. users를 중심으로 posts, memos, monthly_goals, annual_goals, reminders, recommendations, inquiries가 연결되고, 커뮤니티 기능은 community_posts, community_comments, community_likes로 분리했다. 장르는 genres 테이블로 독립 관리하며 관리자가 추가·삭제할 수 있다.

---

1차 개발 돌아보기

2025년 초에 Java 17, Spring Boot 3.3, React 18로 같은 주제를 한 번 구현한 적이 있다. 당시에는 세션 기반 인증, Thymeleaf 서버 사이드 렌더링, Render 무료 배포를 사용했고, 설계보다 구현에 급했던 코드였다. 1차 코드를 다시 봤을 때 수정으로 해결할 수 있는 수준이 아니라고 판단했다. 그래서 코드를 처음부터 다시 짰다. JWT 인증, AWS 인프라, 도메인 중심 설계, 보안 점검까지 이번 2차 개발에서 달라진 부분들이다.

 

1차 개발 기록은 아래 링크에서 확인할 수 있다. 

1차 개발 기록 보러가기