6 분 소요

AI_Todo 프로젝트 마스터 테이블

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

프로젝트 선정 이유와 목표

👉 AI_Todo 프론트엔드 기록 모음
👉 AI_Todo 백엔드 기록 모음
👉 AI_Todo DevOps 기록 모음

프로젝트 선정 이유

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

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

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

이 프로젝트는 백엔드에 국한되지 않고, 사용자의 화면 클릭부터 성능 최적화 그리고 OS 환경까지 전 과정을 직접 설계하고 개발하며 ‘개발 핵심 역량인 문제 해결 능력’ 을 기르는 것을 중점으로 두고 있습니다.

2. 전략적 선택: 왜 ‘Todo 리스트’인가?

이 프로젝트는 두 가지 핵심 목표를 가지고 시작되었습니다.
첫째는 백엔드 개발자로 국한하지 않고 개발자로서 컴퓨터자원으로 문제 해결 역량을 갖추는 것이고, 둘째는 과거 마케터로 활동하며 얻은 사용자 분석 및 니즈 파악 역량을 기술과 접목하는 것입니다.

단순히 기능을 구현하는 개발자를 넘어, 성능최정화 및 사용자 경험(UX)을 깊이 고민하고 비즈니스 가치를 창출하는 안목을 가진 개발자로 성장하기 위해, 사용자가 가장 직관적으로 가치를 느낄 수 있는 생산성 도구이자 개인적으로도 자주 사용하는 ‘Todo 리스트’를 첫 프로젝트로 선택했습니다.

a. 문제 인식: “평범한 Todo 리스트는 매력적이지 않다”

마케터의 관점에서 볼 때, 시중에 출시된 수많은 Todo 리스트는 사용자에게 차별화된 가치를 주지 못하며, 고객의 지갑을 열 만큼 매력적인 서비스는 거의 없다고 판단했습니다. 이는 다음과 같은 핵심 질문으로 이어졌습니다.

“어떻게 하면 ‘Todo 리스트’를 고객의 삶에 없어서는 안 될 필수 서비스로 만들 수 있을까?”

b. 비전: ‘할 일 목록’을 ‘삶의 생산성 파트너’로

저는 이 질문에 대한 답이 ‘기본’을 넘어서는 것에 있다고 생각합니다. 사용자의 삶의 생산성을 실질적으로 높이기 위해, 아래와 같은 가치를 중심으로 서비스를 확장해 나간다면 의미있는 프로젝트가 될 수 있다고 생각합니다.

  • 핵심 기능 고도화: 간편한 사용성을 기반으로 한 루틴 설정, 우선순위 관리, 목표 시각화
  • 지속 가능한 동기부여: 사용자가 지치지 않고 목표를 향해 나아갈 수 있도록 돕는 시스템
  • 생태계 확장성: 캘린더, 이메일, 메신저 등 타 서비스와의 유기적인 연동
  • 완벽한 동기화: 모바일, 웹, 데스크톱 등 모든 OS와 플랫폼을 아우르는 끊김 없는 경험

이처럼 간단해 보이는 Todo 서비스 안에서도 무궁무진한 기술적, 사업적 확장을 시도할 수 있습니다.

c. 전략: 성장을 위한 최적의 ‘훈련장’

개발자의 관점에서 볼 때, 초기 개발 모델로 ‘Todo 리스트’를 선택한 것은 엔지니어링 역량 강화를 위한 최적의 전략이라고 생각합니다.

핵심 비즈니스 로직이 단순하여 복잡한 도메인 지식 습득에 드는 시간을 최소화하고, 절약된 시간을 아키텍처 설계, 성능 최적화, 테스트 코드 작성, CI/CD 구축과 같은 핵심 엔지니어링 역량을 연마하는 데 온전히 쏟아부을 수 있습니다.

즉, 이 프로젝트는 기술적 성장을 위한 최고의 ‘훈련장’ 이라고 생각합니다.
앞으로 사용자 인증, 실시간 동기화, 통계 대시보드, AI 자동화 등의 기능을 순차적으로 추가하며 기술적 깊이와 서비스 가치를 함께 높여나갈 계획입니다.

프로젝트 목표

기술적 목표

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

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

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

기술스택 및 선택 이유

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

핵심 기능

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

프로젝트 계획표

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

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

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

구성 요소 주요 기술/도구 구현 기능 계획 진행상태
프론트엔드 React 서비스 웹 UI 구현 완료
  ReactNative 모바일 UI 구현  
백엔드 Spring Boot
( Spring MVC, Monolithic )		 DDD 아키텍처 -> 도메인별 API 90% 진행
  FastAPI AI 기능 제공  
  Swagger (OpenAPI) API 문서 자동화 완료
  Redis JWT 토큰 기본환경 구축 완료
DB PostgreSQL (RDBMS) DB 튜닝  
DevOps 미니 PC 서버 구축 VPN, 보안설정  
  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%↑일 때

참고

댓글남기기

참고