5 분 소요

AI_Todo 프로젝트 마스터 테이블

[ AI_Todo 프로젝트 개발기 - #0 ] 개발 계획표

프로젝트 선정 이유와 목표

프로젝트 선정 이유

1. 개발 시너지 극대화를 위한 End-to-End 개발 역량의 필요성

이전 협업 프로젝트들을 통해 백엔드 개발자가 프론트엔드 생태계를 이해하는 것이 얼마나 중요한지 체감했습니다.

API 설계 시 프론트엔드의 데이터 처리 방식을 고려하고, 문제 발생 시 백엔드와 프론트엔드 중 어디가 병목점인지 빠르게 파악하는 능력은 전체 개발 프로세스의 효율을 극대화한다고 확신합니다.

이 프로젝트는 백엔드에 국한되지 않고, 사용자의 화면 클릭부터 데이터베이스 저장까지 전 과정을 직접 설계하고 개발하며 ‘풀스택 관점의 문제 해결 능력’ 을 기르기 위해 기획되었습니다.

2. 과거 경험을 활용한 사용자 중심 서비스 개발

과거 마케터로 활동하며 얻은 사용자 행동 분석 및 니즈 파악 역량을 기술과 접목하고 싶었습니다.

사용자가 가장 직관적으로 가치를 느낄 수 있는 생산성 도구, 특히 ‘Todo 리스트’를 시작점으로 삼았습니다.

이를 통해 단순히 기능을 구현하는 개발자를 넘어, 사용자 경험(UX)을 깊이 고민하고 비즈니스 가치를 창출하는 개발자로 성장하고자 합니다.

3. ‘Todo 리스트’ 를 선택한 전략적 이유

‘Todo 리스트’는 비즈니스 로직이 단순하여 복잡한 도메인 지식 습득에 드는 시간을 최소화할 수 있습니다.

절약된 시간을 아키텍처 설계, 성능 최적화, 테스트 코드 작성, 배포 자동화와 같은 핵심 엔지니어링 역량 강화에 온전히 집중할 수 있고 이런 방법은 기술적 성장을 위한 최적의 ‘훈련장’이라고 판단했습니다.

향후 사용자 인증, 실시간 동기화, 통계/분석 대시보드, 실시간 알림, AI 자동화 등의 기능을 추가하며 서비스를 확장해나갈 계획입니다.

프로젝트 목표

기술적 목표

  • 아키텍처 설계:
    • 확장성과 유지보수성을 고려한 클린 아키텍처(Clean Architecture) 를 프로젝트에 적용하고, 주요 설계 결정과 그 이유를 문서로 기록합니다.
    • AI 기능(FastAPI)과 핵심 비즈니스 로직(Spring Boot) 서버를 분리하여, 각 서버의 독립적인 확장 및 배포가 가능한 구조를 설계합니다.
  • 프론트엔드 역량 강화:
    • 상태 관리 라이브러리(예: Redux, Zustand)를 활용하여 복잡한 상태를 효율적으로 관리하고, 컴포넌트 기반 UI 설계를 체득합니다.
    • 라이브러리 도입 시, 다른 대안과 비교하여 현재 프로젝트에 가장 적합한 이유(Trade-off)를 분석하고 문서화하는 습관을 기릅니다.
  • 백엔드 심화:
    • (데이터베이스 최적화)
      • 대용량 트래픽을 가정하여 DB 스키마를 설계하고, 실행 계획 분석 및 인덱싱, 쿼리 최적화를 통해 API 평균 응답 속도 100ms 이하를 목표로 합니다.
    • (API 및 문서화)
      • Swagger(OpenAPI)를 활용하여 API 명세를 자동화하고, 다른 개발자가 이해하기 쉽도록 명확한 요청/응답 예시를 포함시킵니다.
    • (비동기 처리)
      • RabbitMQ를 이용한 비동기 메시지 큐를 도입하여, 시간이 오래 걸리는 작업(예: AI 피드백 요청) 처리 시 서버의 부하를 분산하고 사용자 응답성을 개선합니다.
    • (캐싱)
      • Redis를 활용하여 자주 요청되는 데이터(예: 사용자 정보)에 대한 캐싱 전략을 수립하고 적용하여 DB 부하를 줄입니다.
  • 데브옵스(DevOps) 및 배포:
    • Docker를 이용해 애플리케이션을 컨테이너화하여, 개발 및 배포 환경의 일관성을 확보합니다.
    • GitHub Actions를 활용한 CI/CD 파이프라인을 구축하여, 테스트 및 배포 과정을 자동화합니다.

혼자서도 체계적으로, 성장과 실전 모두 잡는 프로젝트 관리 전략

  • MVP 단계: 빠르고 실용적인 개발 우선
  • 초기 모놀로식 구조
    • -> 향후 MSA 분리까지 고려한 유연한 설계 디자인 능력이 목표
  • AI 기능의 독립성과 서비스 확장성 확보
  • 각 단계별 모니터링과 성능지표 분석

기술스택 및 선택 이유

  • React 19: 모바일 확장, 대규모 커뮤니티, 최신 생태계
  • Spring Boot 3.2.3: 엔터프라이즈급 성능, 관리 편의성, 확장성
  • FastAPI: 외부 AI gpt 호출에 대한 I/O 고려 -> 비동기 지원, Python 생태계 추후 로컬 AI/ML 연동 고려
  • Swagger(OpenAPI): API 명세 자동화, 협업/소통 비용 절감
  • PostgreSQL: 무료, 표준 SQL, 벡터 DB 마이그레이션 용이
  • GitHub Actions: CI/CD 자동화, 러닝커브 낮음
  • Docker: 환경 일관성, 손쉬운 배포/테스트
  • Grafana/Prometheus: 오픈소스 실시간 모니터링
  • JMeter: GUI 기반, 러닝커브 고려

핵심 기능

  • 유저별 프로젝트 생성/관리
  • 프로젝트별 다수 Task 생성/관리
  • Task 실패 시 AI 기반 피드백 및 개선 플랜 제안
  • OS 와 플랫폼에 제약없이 동일한 서비스 제공공

프로젝트 계획표

  • 초기 계획 단게 완료후 다음 단계는 주요기술의 난이도 및 도입조건을 설정하여 우선순위에 따라 도입예정

초기 계획 단계 : ( 1~ 5 단계 )

  • 목차
  • 1단계 : (진행중)
    • 최종단계를 고려한 아키텍처 설계
    • 모놀로식(Monolithic)으로 MVP(최소기능제품) 구현
      • MVP = 웹 서비스 ( Auth, Todo 기능 )
  • 2단계 :
    • 모니터링 환경 구축
    • 부하테스트 환경 구축
  • 3단계 :
    • CI/CD 구축
  • 4단계 :
    • AI 서버 FsatAPI로 설계 및 별도 분리, 확장성 확보
  • 5단계 :
    • 모바일 환경 구현
    • 웹 & 모바일 실시간 동기화 sameless 연동

초기 계획단계의 전체적인 구조 및 진행 단계

구성 요소 주요 기술/도구 구현 기능 계획 진행상태
프론트엔드 React 서비스 웹 UI 구현 완료
  ReactNative 모바일 UI 구현  
백엔드 Spring Boot
( Spring MVC, Monolithic )		 DDD 아키텍처 -> 도메인별 API 70% 진행
  FastAPI AI 기능 제공  
  Swagger (OpenAPI) API 문서 자동화 완료
  Redis JWT 토큰 기본환경 구축 완료
DB PostgreSQL (RDBMS)    
DevOps GitHub Actions CI/CD, 자동화된 테스트/배포  
  Docker 컨테이너 환경, 일관성 있는 배포  
모니터링 Grafana, Prometheus 서비스 모니터링 및 알림  
  JMeter 부하 테스트  

추후 공부 계획 단계 ( 5단계 이후 )

  • 실시간 동기화: 웹/모바일 seamless 연동
  • DB 고급 튜닝: 부하테스트 200명 동시접속 목표
  • Next.js 15 커뮤니티 기능
    • 메인페이지 렌더링 최적화
    • SEO 적용
  • Redis 캐싱 도입
  • 부하테스트/모니터링 고도화

주요 기술 도입/개선 단계별 정리

단계 기술/주제 이유/효과 난이도 도입 시점 보류 조건
1 DB 튜닝 (슬로우쿼리, 인덱스) 병목 해소, 성능↑ 중급 웹/모바일 동기화 후, 데이터 쌓인 뒤 없음
2 Redis 캐싱 + CDN 부하↓, 속도↑, 비용↓ 낮~중 DB 튜닝 후에도 응답 300ms↑, 트래픽 증가 트래픽 낮음
3 Nginx API Gateway 성능/보안/확장성↑ 낮음 외부 요청 통합 필요 시 단일 서버/소규모
4 HTTP Gzip 압축 트래픽↓, 응답속도↑ 매우 낮음 Nginx 적용 시 바로 없음
5 Next.js 15 (SSR/SEO) SEO/로딩↑, 유지보수↑ 중간 커뮤니티/SEO 필요한 기능 SEO 필요 낮거나 MVP
6 RabbitMQ 알림서버 실시간 알림, 부하 분산 중간 알림 필요, 사용자 100명↑ 우선순위 낮을 때
7 API Gateway (Spring Cloud 등) API 라우팅, 인증/권한, 모니터링 중간 MSA/다수 API 분리 시 단일 서비스/소규모
8 GC 튜닝 JVM 성능↑, 안정성↑ 중간 메모리 80%↑, GC 일시정지 100ms↑ 성능 문제 없을 때
9 Spring WebFlux 비동기/논블로킹, 동시접속↑ 높음 TPS 1000↑, 동시 200명↑, 블로킹 I/O 병목 MVC로 충분할 때
10 gRPC 내부 통신 성능↑, 결합↓ 높음 MSA, 내부 통신 병목 모놀리식/단일 서비스
11 BFF 서버 (WebFlux 등) 클라이언트별 최적화, 트래픽↓ 높음 웹/모바일 데이터 구조 완전히 다를 때, 동시 200명↑, TPS 1000↑ 단일 서비스, 구조 유사
12 CQRS 읽기/쓰기 분리, 확장성↑ 높음 트랜잭션 10만건↑, 복잡 도메인 소규모/단순
13 Electron pc 환경 UI 구현 중간 사용자 트레픽 100명↑ 유저 행동 및 피드백 검토하여 꼭 필요하다는 판단이 들 었을 때

현재 도입 불필요 또는 보류 기술

  • MSA 전환 + API Gateway: 팀 10명↑, 서비스 복잡도↑일 때만
  • BFF 패턴: MSA 전환 후, 외부 API 5개↑, 웹/모바일 데이터 구조 완전히 다를 때
  • CQRS: 트랜잭션 10만건↑, 복잡 도메인 필요할 때
  • gRPC: MSA 환경, 내부 통신 병목 발생 시
  • CDN: 글로벌 사용자/정적 자원 대역폭 50%↑일 때

참고

댓글남기기

참고