Life Navigation

할 일을 실패한 이유를 분석하고,
다음에 성공할 수 있도록 계획을 다시 설계해주는 AI 기반 TODO 서비스

이 프로젝트는 개인 서비스 형태를 갖고 있지만, 운영 중 웹 서비스에서 발생하는 성능 저하, 트래픽 증가, 운영 비용 문제를 Java/Spring 기반으로 해결한 사례를 담고 있습니다.

📅 개발 기간: 2025.04 ~ 현재 (BE / FE / DevOps 전 영역 담당)

---

🎯 Engineering Snapshot

지표	Before → After	개선율
읽기 p95	975ms → 141ms	-86%
쓰기 p95	1.9s → 126ms	-93%
읽기 RPS	972 → 3,680	+279%
쓰기 RPS	373 → 916	+146%
월 운영 비용	AWS → 0원	홈서버 전환

검증 방식:

• k6 부하 테스트 (500 VU, 32분 프로파일) + Grafana 모니터링
• 실제 운영 서버에서 테스트 전용 DB/프로파일을 분리하여 측정
• HTTP 실패율: 0.0000% (4.7M+ 요청)

본 서비스는 실제 운영 중인 웹 서비스로, 트래픽 증가와 응답 지연 문제를 해결하는 과정에서 재현 가능한 부하 테스트를 통해 성능·비용·운영 복잡도를 비교·확인했습니다.

---

📋 제품 개요

문제

• 기존 TODO 앱은 "기록"만 하고 실패 원인은 다루지 않는다
• 실패한 TODO는 개선 없이 계속 남아있음 → 계속 실패하게 됨

해결

• 사용자의 실패 패턴을 AI가 자동 분석 → 성공 가능한 세부 Task로 자동 재구성
• 과거 성공/실패 이력을 학습하여 개인화된 추천 제공

실제 사용 흐름

---

💡 핵심 가치 (Key Engineering Values)

각 파트별 상세 기술적 의사결정과 성과는 아래 링크에서 확인 가능

🛠️ 핵심 기술 하이라이트 (Engineering Pillars)

⚙️ Backend: "운영 문제 해결 기반 아키텍처 결정"

• 초기 WebFlux 도입 후 운영 복잡도 문제로 MVC + Virtual Threads로 전환
• DDD + Hexagonal Architecture로 유지보수 비용 최소화
• Transactional Outbox 패턴으로 비동기 환경의 데이터 정합성 100% 보장
• 단계적 성능 개선으로 읽기 RPS +279%, 쓰기 RPS +146% 달성
• 👉 Backend 상세 보기

🎨 Frontend: "실제 사용 흐름 재현을 위한 구현"

※ 프론트엔드는 실제 API 사용 흐름과 사용자 요청 패턴을 재현하기 위한 범위로 구현되었습니다.

• Zero-Latency UX: Optimistic UI + UUIDv7 전략으로 비동기 처리 지연을 0ms로 체감
• 개발 생산성 300% 향상: 비즈니스 로직(Core)을 플랫폼 독립적으로 설계하여 웹/앱 로직 100% 재사용
• 품질 및 효율 극대화: Turborepo 빌드 시간 82% 단축
• 👉 Frontend 상세 보기

🚀 DevOps: "비용 0원의 고효율 인프라"

• 이미지 96% 경량화: ML 라이브러리 분리 및 멀티스테이지 빌드로 26GB → 1GB 절감
• 빌드 속도 90% 단축: 레이어 캐싱 및 .dockerignore 최적화로 1004초 → 98초 단축
• 철저한 보안망: WireGuard VPN 전용 SSH 및 Cloudflare Tunnel로 공인 IP 완전 은폐

0원 운영의 리스크 대응:

• 🔒 보안: 외부 SSH 차단 (VPN Only), Cloudflare WAF/DDoS 방어
• 📊 모니터링: Prometheus + Grafana + Slack 알림 (5xx > 5%, p95 > 800ms)
• 🔄 복구: 트래픽 임계점 도달 시 클라우드 재전환 가능한 구조 (Docker Compose 기반)

🤖 AI 코칭 기능

※ AI 기능은 서비스 품질 개선을 위한 분석 파이프라인의 일부로 분리 구성되어 있습니다.

• 외부 LLM 활용 + Qdrant VectorDB로 실패 패턴 구조화 및 개인화 추천 (RAG 준비)
• 👉 Backend README - AI 서비스 분리에서 상세 확인

---

🚀 핵심 의사결정 (Why & How)

1. WebFlux → Spring MVC + Virtual Threads

• 문제: WebFlux + SecurityContext 전파 오버헤드로 순수 MVC보다 느림
• 결정: MVC + Virtual Thread로 전환 → I/O 대기 시간 효율화
• 결과: 읽기 p95 975ms → 141ms (-86%)

2. Redis 캐싱 + @Cacheable 순서 최적화

• 문제: 읽기 병목 (TODO는 읽기:쓰기 = 10:1 이상)
• 결정: Redis Cache-Aside + @Cacheable → @Transactional 순서 조정
• 결과: 캐시 히트 시 DB 커넥션 점유 제거, 읽기 RPS +279%

3. API/Worker 분리 + RabbitMQ 배치 처리

• 문제: 동기 DB 저장이 응답 시간 병목
• 결정: API → Redis Pending → MQ → Worker → DB (비동기)
• 결과: 쓰기 p95 1.9s → 126ms (-93%)

📊 성능 테스트 결과 상세 (성능 검증에 관심 있는 경우)

읽기 성능 테스트 (500 VU)

• RPS: 3,680 / Latency: Avg 106ms, p95 141ms

쓰기 성능 테스트 (500 VU)

• RPS: 916 / Latency: Avg 101ms, p95 126ms

극한 상황 테스트 (2,000 VU)

지표	읽기	쓰기
RPS	4,310	2,820
p95	633ms	610ms
HTTP 실패율	0.0045%	0.0002%

👉 7단계 상세 분석 및 k6 테스트 결과 확인

현재 구조의 한계와 다음 단계

• 단일 노드 홈서버 기반으로, 대규모 트래픽에는 수평 확장이 필요
• 이벤트 수 증가 시 MQ 파티셔닝 및 Consumer Group 분리가 필요
• 실제 사용자 행동 데이터 기반 튜닝은 향후 과제

---

📚 Deep Dive

영역	문서	핵심 내용
성능 개선	Backend README	단계적 성능 개선 과정, k6 테스트 결과, Grafana 대시보드
아키텍처	Backend README	DDD + Hexagonal, Outbox 패턴, CQRS
운영/보안	Dev README	CI/CD 자동화, VPN 보안, Cloudflare Tunnel
프론트엔드	Frontend README	Optimistic UI, 모노레포 구조, Turborepo

---

🏗️ 전체 시스템 아키텍처

프론트엔드부터 인프라까지 전체 데이터 흐름을 시각화

graph TD
    subgraph Client [사용자 환경]
        User[사용자]
        Browser[웹 브라우저]
        Mobile["모바일 앱 (개발예정)"]
    end

    subgraph Infrastructure ["DevOps & Network (Dev)"]
        LB[Nginx 로드밸런서]
        CDN[CloudFlare CDN]
        SSL[SSL/TLS 인증서]
    end

    subgraph FE [Frontend Monorepo]
        Web["Web App (React)"]
        RN["Mobile App (React Native) 개발 예정"]
        Core["Core 패키지 (비즈니스 로직)"]
    end

    subgraph BE [Backend System]
        subgraph Spring ["Spring Boot (동일 이미지, 설정으로 역할 분리)"]
            direction TB
            space1[ ]
            API["API Server (Spring Boot)<br/>(MQ_ENABLED=false)"]
            Worker["Worker Server (Spring Boot)<br/>(SERVER_PORT=0)"]
        end
        AI[FastAPI AI 서비스]
        DB[(PostgreSQL)]
        Cache[(Redis)]
        MQ((RabbitMQ))
    end
    
    space1 ~~~ API

    User --> Browser
    User --> Mobile
    Browser --> CDN
    Mobile --> CDN
    CDN --> LB
    LB --> Web
    LB --> API

    Web --> Core
    RN --> Core

    API --> DB
    API --> Cache
    API --> MQ
    
    MQ --> Worker
    Worker --> DB
    Worker --> AI
    
    style space1 fill:none,stroke:none

Loading

🔄 데이터 흐름 및 기술 스택

Frontend <-> Backend 통신

• REST API: 기본적인 CRUD 작업 및 실시간성이 필요한 조회 통신
• WebSocket (예정): 실시간 알림 및 상태 업데이트
• Optimistic UI: 비동기 처리를 위한 프론트엔드 낙관적 업데이트 지원

Backend 처리 흐름

1. API 요청 수신: Nginx를 거쳐 Spring Boot API 서버로 도착
2. 인증/인가: JWT 기반 인증 및 AOP 기반 권한 검증
3. CQRS: 읽기 요청은 Redis 캐시 또는 DB 조회, 쓰기 요청은 트랜잭션 처리
4. 비동기 작업: 오래 걸리는 작업이나 부가 작업을 RabbitMQ로 발행하여 Worker (spring boot) 처리

DevOps 인프라

• Docker Compose: 전체 서비스의 컨테이너 오케스트레이션
• CI/CD: GitHub Actions를 통한 자동 빌드 및 배포
• Monitoring: Prometheus & Grafana를 통한 시스템 상태 관제

---

이 문서는 의사결정의 요약이며, 각 선택의 맥락과 비용은 면접에서 설명할 수 있습니다.

※ 보안 및 운영 환경 특성상 소스 코드는 비공개로 운영하고 있으며,
면접 과정에서 아키텍처/성능/의사결정에 대한 설명과 질의응답은 가능합니다.