1. 학습 흐름을 하나의 데이터 구조로 설계
습관 기록, 집중 타이머, 포인트 보상을 각각의 기능으로 분리하지 않고, "행동 → 기록 → 보상 → 커뮤니티 공유"로 이어지는 단일 흐름으로 설계했습니다.
ERD를 직접 분석·설계하며 엔티티 관계와 정합성을 점검했고, 확장성을 고려한 구조로 데이터 무결성을 확보했습니다.
공부의 숲은 자기주도 학습 과정에서 반복적으로 발생하는 습관 유지 실패와 동기 저하 문제를 해결하기 위해 기획한 학습 관리 서비스입니다.
기존 학습 서비스는 기록 기능에 머무르는 경우가 많았고, 학습을 지속하게 만드는 구조적 장치가 부족하다고 판단했습니다.
이에 학습 기록·습관·집중·보상을 하나의 흐름으로 연결하고, 커뮤니티 기반 상호작용을 결합해 학습 지속성을 높이는 구조를 설계했습니다.
습관 기록, 집중 타이머, 포인트 보상을 각각의 기능으로 분리하지 않고, "행동 → 기록 → 보상 → 커뮤니티 공유"로 이어지는 단일 흐름으로 설계했습니다.
ERD를 직접 분석·설계하며 엔티티 관계와 정합성을 점검했고, 확장성을 고려한 구조로 데이터 무결성을 확보했습니다.
API 스펙을 Swagger로 문서화해 프론트엔드와의 연동 오류를 최소화했습니다.
스터디·포인트 영역에서 발생한 응답 스키마 불일치를 직접 수정하며 구조를 정리했습니다.
단순히 "연동되도록 수정"하는 것이 아니라, 향후 기능 확장 시에도 충돌이 발생하지 않도록 응답 포맷을 재정의했습니다.
Render(BE) · Vercel(FE) 기반 배포 환경을 직접 구성하고 환경 변수, 마이그레이션, 시딩 절차를 문서화했습니다.
로컬 DB와 서버 DB 마이그레이션 불일치 문제가 발생했으나, 서버 DB 초기화 → 마이그레이션 재적용 → 시딩 재실행 과정을 통해 짧은 시간 내 복구했습니다.
이 경험을 통해 배포는 단순 업로드가 아니라 데이터 상태를 함께 관리하는 과정임을 체감했습니다.
Prettier·ESLint 도입으로 팀 전체 컨벤션 통일, 공통 함수·커스텀 훅 정의로 중복 코드 제거, 로딩/에러/404 페이지 구현으로 UX 완성도 개선을 진행했습니다.
기능 구현 이후에도 구조를 정리하며 유지보수성을 개선했습니다.
로컬 DB와 서버 DB 마이그레이션 상태가 달라 배포 후 오류가 발생했습니다.
서버 DB에 실제 데이터가 없음을 확인했고, 초기화 리스크가 허용 가능하다고 판단했습니다.
서버 DB 초기화 → 마이그레이션 재적용 → 시딩 재실행 순서로 진행했습니다.
짧은 시간 내 정상화했고, 일정 지연 없이 프로젝트를 완주할 수 있었습니다.
이 경험을 통해 배포는 코드 문제가 아니라 "상태 관리 문제"라는 것을 처음 체감했습니다.
핵심 기능을 기한 내 구현하며 프로젝트를 완주했고, 배포 이슈 및 연동 오류를 구조적으로 해결했습니다.
팀 내부 평가에서 리더십·일정 관리·소통 역량에 대한 긍정적 피드백을 확보했습니다.
이번 프로젝트는 저에게 "기술 선택은 익숙함이 아니라 상황에 대한 판단의 결과여야 한다"는 기준을 만들어준 경험이었습니다.
또한 초기 단계에서 데이터 구조와 협업 규칙을 명확히 정의하는 것이 프로젝트 후반 리스크를 크게 줄인다는 점을 체감했습니다.
팀원들이 실제로 작성해준 피어 리뷰입니다.
React (JavaScript)
컴포넌트 기반 구조로 UI를 설계하고, 상태 흐름을 명확히 관리하기 위해 사용했습니다.
SCSS (module.scss)
스타일 범위를 컴포넌트 단위로 제한해, 전역 충돌 없이 유지보수 가능한 구조를 만들기 위해 적용했습니다.
Node.js / Express
경량 미들웨어 구조를 기반으로 API 정책을 명확히 설계하고, 빠른 기능 구현이 가능하도록 선택했습니다.
Prisma ORM
스키마 기반 데이터 모델링을 통해 ERD 설계를 코드로 명확히 관리하고, 타입 안정성을 확보하기 위해 도입했습니다.
PostgreSQL
관계형 데이터 구조를 명확히 정의하고, 학습 기록·포인트·스터디 간 관계를 안정적으로 관리하기 위해 사용했습니다.
Vercel (Frontend)
React 기반 프론트엔드 배포에 최적화된 환경으로, 빠른 빌드 및 배포 반복을 위해 선택했습니다.
Render (Backend)
Node 기반 서버를 간편하게 운영할 수 있는 환경으로, 초기 프로젝트 규모에 적합하다고 판단해 사용했습니다.
ESLint / Prettier
팀 전체 코드 컨벤션을 통일하고, 코드 리뷰 시 불필요한 스타일 논쟁을 줄이기 위해 도입했습니다.