이게 어쩌면 AI에게 가장 쉬운(?) 프로젝트일꺼 같습니다. 가장 효율적이기도 한거 같아요.
기존에 운영하던 서비스인데 곳곳에 난무하던 하드코딩/예외처리를 AI로 수정 및 재개발 해봤습니다.
PHP 모놀리식을 Java MSA로: AI와 함께한 14일의 기록
1,499개 PHP 파일, 65,048줄의 레거시 시스템을 12개 마이크로서비스로 리팩토링하는 데 걸린 시간 — 14일.
이것이 가능했던 이유를 데이터로 증명합니다.
1. 프로젝트 개요
무엇을 만들었나
젤로텍(Zelotek) — 196개 매장, 6개 업종(스터디카페, 독서실, 사우나, 식당 등)을 지원하는 무인 키오스크 시스템.
기존 PHP 모놀리식 시스템을 Java Spring Boot 기반 MSA로 전면 리팩토링했습니다.
Before → After
| 항목 | PHP 레거시 | Java MSA |
|---|---|---|
| 아키텍처 | 모놀리식 | 12개 마이크로서비스 |
| 언어 | PHP | Java 17 + Spring Boot 3.2 |
| DB 전략 | 단일 DB | Database per Service |
| 통신 방식 | 직접 함수 호출 | REST + RabbitMQ 이벤트 |
| 프론트엔드 | PHP 렌더링 | React + Electron |
| 배포 | FTP 수동 배포 | Docker Compose → AWS EKS |
2. 최종 산출물 규모
전체 코드 통계
| 구분 | 파일 수 | 코드 라인 수 |
|---|---|---|
| Backend (Java) | 639 | 43,900 |
| Kiosk Desktop (Electron/React) | 62 | 12,318 |
| Admin Dashboard (React) | 34 | 8,741 |
| DB Migrations (SQL) | 106 | 9,142 |
| PDCA 문서 | 61 | 43,892 |
| Docker/Infra 설정 | 14+ | 448+ |
| 기타 (config, scripts 등) | 226 | - |
| 합계 | 1,142+ | 118,441+ |
참고: node_modules, build, .gradle 등 자동 생성 파일 제외 기준
서비스별 상세 규모
| 서비스 | 역할 | Java 파일 | 코드 라인 |
|---|---|---|---|
| Payment | 결제 처리, PG 연동, 환불 | 150 | 9,893 |
| Store | 가맹점 관리, 키오스크, 원격제어 | 85 | 6,500 |
| Member | 회원, 포인트, 마일리지 | 76 | 5,053 |
| Seat | 좌석 관리, 실시간 상태 | 76 | 4,809 |
| Auth | JWT 인증, 3-Tier RBAC | 66 | 4,661 |
| Reservation | 예약 처리, 이벤트 소비 | 36 | 3,578 |
| Goods | 상품 관리, 번들, 쿠폰 | 52 | 3,234 |
| Notification | SMS, 카카오 알림톡 | 35 | 2,445 |
| Analytics | 매출 통계 (MongoDB) | 20 | 1,415 |
| File | 파일 업로드 (S3) | 12 | 858 |
| Board | 게시판 | 17 | 806 |
| Config | 설정 서버 | 14 | 648 |
| 합계 | 12개 서비스 | 639 | 43,900 |
아키텍처 구성요소 수
| 구성요소 | 수량 |
|---|---|
| JPA/MongoDB Entity | 75 |
| Repository | 70 |
| Service | 67 |
| REST Controller | 59 |
| DTO (Request/Response) | 143 |
| RabbitMQ 이벤트 파일 | 25 |
| Feign Client | 10 |
| 스케줄러 | 10 |
| Strategy/Conditional 패턴 | 16 |
| Flyway Migration | 106 |
| Dockerfile | 14 |
3. 시스템 아키텍처
전체 아키텍처
┌─────────────────┐
│ Eureka Server │
│ (8761) │
└────────┬────────┘
│ Service Discovery
┌───────────────────────┼───────────────────────┐
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ Auth │ │ Payment │ │ Store │
│ (8081) │ │ (8084) │ │ (8088) │
│ JWT/RBAC │ │ PG/결제 │ │ 가맹점 │
└───────────┘ └─────┬─────┘ └───────────┘
│
┌──────────────────────┼──────────────────────┐
│ payment.confirmed │ payment.cancelled │ payment.refunded
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│Reservation│ │ Seat │ │ Member │
│ (8086) │ │ (8085) │ │ (8082) │
│ 예약 자동 │ │ 좌석 배정 │ │ 포인트적립 │
└───────────┘ └───────────┘ └───────────┘
│ │
│ │
┌─────┴─────┐ ┌───────────┐ ┌─────┴─────┐
│ Goods │ │ Analytics │ │Notification│
│ (8087) │ │ (8090) │ │ (8089) │
│ 상품/쿠폰 │ │ MongoDB │ │ SMS/카카오 │
└───────────┘ └───────────┘ └───────────┘
│ │
┌─────┴─────┐ ┌─────┴─────┐
│ File │ │ Board │
│ (8091) │ │ (8092) │
│ S3 스토리지│ │ 게시판 │
└───────────┘ └───────────┘서비스 통신 패턴
┌─────────────────────────────────────────────────────────┐
│ 동기 통신 (REST/Feign) │
│ │
│ Payment ──→ Member (회원 조회) │
│ Payment ──→ Store (매장 정보) │
│ Store ──→ Member (회원 검증) │
│ Notification ──→ Member (연락처 조회) │
│ Member ──→ Store (매장 정보) │
│ Reservation ──→ Goods, Payment, Seat (예약 처리) │
│ Goods ──→ Store, Payment (상품-매장 연계) │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ 비동기 통신 (RabbitMQ) │
│ │
│ [payment.events] Exchange │
│ ├─ payment.confirmed → Reservation (예약 자동생성) │
│ ├─ payment.confirmed → Seat (좌석 배정) │
│ ├─ payment.confirmed → Member (포인트 적립) │
│ ├─ payment.confirmed → Analytics (매출 집계) │
│ ├─ payment.confirmed → Notification (결제 알림) │
│ ├─ payment.cancelled → Seat (좌석 해제) │
│ └─ payment.refunded → Member (포인트 차감) │
│ │
│ [store.events] Exchange │
│ ├─ store.updated → Goods, Notification │
│ ├─ kiosk.registered → Store (자동 프로비저닝) │
│ └─ kiosk.command.* → Kiosk (원격 명령) │
│ │
│ [member.events] Exchange │
│ ├─ member.registered → Notification (가입 알림) │
│ └─ member.mileage_expiring → Notification (만료 알림) │
│ │
│ [auth.events] Exchange │
│ ├─ auth.login → Analytics (로그인 통계) │
│ └─ auth.logout → Analytics (세션 통계) │
└─────────────────────────────────────────────────────────┘기술 스택 다이어그램
┌─────────────────────────────────────────────────────────┐
│ 클라이언트 계층 │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Electron + │ │ React │ │ 브라우저 │ │
│ │ React │ │ Admin │ │ (고객용) │ │
│ │ (키오스크) │ │ Dashboard │ │ │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 인프라스트럭처 계층 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Eureka │ │ Nginx │ │ Docker │ │
│ │ Discovery│ │ Gateway │ │ Compose │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 서비스 계층 (12개) │
│ │
│ Java 17 + Spring Boot 3.2.1 + Spring Cloud 2023.0.0 │
│ Clean Architecture (API → App → Domain → Infra) │
│ JWT + RBAC (SUPER_ADMIN / FRANCHISE_ADMIN / STORE_ADMIN)│
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 데이터 계층 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │PostgreSQL│ │ MongoDB │ │ Redis │ │RabbitMQ│ │
│ │ (11 DB) │ │(Analytics)│ │ (Cache) │ │(Events)│ │
│ └──────────┘ └──────────┘ └──────────┘ └────────┘ │
└─────────────────────────────────────────────────────────┘Clean Architecture (각 서비스 내부)
┌─────────────────────────────────────┐
│ API Layer │
│ Controller, DTO (Request/Response) │
├─────────────────────────────────────┤
│ Application Layer │
│ Service, Scheduler, Event Handler │
├─────────────────────────────────────┤
│ Domain Layer │
│ Entity, Repository Interface, │
│ Enum, Value Object │
├─────────────────────────────────────┤
│ Infrastructure Layer │
│ JPA Repository Impl, Feign Client, │
│ RabbitMQ Publisher/Listener, │
│ Security (JWT, RBAC), Gateway │
└─────────────────────────────────────┘4. 개발 타임라인
| 날짜 | 작업 내용 | 주요 산출물 |
|---|---|---|
| 1/27 (Day 1) | PDCA 문서 작성, 서비스 설계 | Plan 5개, Design 8개, 43,892줄 문서 |
| 1/27~2/3 (Day 1-8) | 12개 서비스 기본 구현 | 639 Java 파일, 43,900줄 |
| 2/5 (Day 10) | Multi-Brand UI 설계 | 6업종 테마 시스템 |
| 2/6 (Day 11) | v5.0 Gap 분석 + 보완 | 설계-구현 일치율 93% |
| 2/7 (Day 12) | Docker 통합 + API 테스트 | 8/8 서비스 Up, 전체 API PASS |
| 2/8 (Day 13) | 결제 검증 + 디바이스 포팅 + Admin Dashboard | 56/56 테스트, 시드 데이터 |
| 2/9 (Day 14) | v6.0 완성도 향상 + MongoDB Analytics | 98%+ 일치율, 0 TODO |
버전별 설계-구현 일치율 추이
v4.0 (Day 8) ████████░░░░░░░░░░░░ 82%
v5.0 (Day 11) █████████████████░░░░ 93%
v5.1 (Day 12) ███████████████████░░ 95.3%
v6.0 (Day 14) ████████████████████░ 98%+5. 효율 비교: AI 없이 vs AI와 함께
5-1. 작업별 시간 추정 비교
기준: 시니어 Java 개발자 1명 + 시니어 프론트엔드 개발자 1명 (2인 팀)
| 작업 | AI 없이 (전통 방식) | AI와 함께 (실제) | 단축률 |
|---|---|---|---|
| 요구사항 분석 + 설계 문서 | 3~4주 | 1일 | 95% |
| 12개 서비스 프로젝트 세팅 | 1~2주 | 0.5일 | 93% |
| DB 스키마 설계 + Migration | 2~3주 | 2일 | 86% |
| 도메인 엔티티 75개 | 3~4주 | 2일 | 93% |
| REST API 59개 컨트롤러 | 4~6주 | 3일 | 90% |
| 비즈니스 로직 67개 서비스 | 6~8주 | 4일 | 88% |
| RabbitMQ 이벤트 통합 (12서비스) | 3~4주 | 1일 | 95% |
| Feign Client 10개 | 1~2주 | 0.5일 | 93% |
| JWT + RBAC 인증/인가 | 2~3주 | 1일 | 90% |
| 결제 시스템 (6수단+환불+영수증) | 4~6주 | 2일 | 92% |
| Admin Dashboard (React) | 3~4주 | 2일 | 88% |
| Electron 키오스크 앱 | 4~6주 | 3일 | 88% |
| Docker 통합 (16 컨테이너) | 1~2주 | 0.5일 | 93% |
| 통합 테스트 + 디버깅 | 2~3주 | 2일 | 85% |
| 합계 | 40 |
~14일 | ~95% |
5-2. 핵심 수치 비교
┌─────────────────────────────────────────────────────────┐
│ 개발 효율 비교 요약 │
├─────────────────┬──────────────┬─────────────────────────┤
│ 항목 │ 전통 방식 │ AI 협업 │
├─────────────────┼──────────────┼─────────────────────────┤
│ 총 개발 기간 │ 10~14개월 │ 14일 │
│ 투입 인력 │ 2~3명 │ 1명 + AI │
│ 코드 라인 (Java) │ 43,900줄 │ 43,900줄 (동일 품질) │
│ 문서 작성 │ 4~6주 │ 1일 │
│ 설계-구현 일치율 │ 70~80%* │ 98%+ │
│ TODO 잔여 │ 수십~수백 개 │ 0개 │
│ 인건비 (추정) │ 1~2억원 │ ~200만원 (AI 구독료) │
│ 일일 코드 생산량 │ 200~400줄 │ ~3,100줄 │
└─────────────────┴──────────────┴─────────────────────────┘
* 전통 방식의 설계-구현 일치율은 프로젝트 규모가 클수록 낮아지는 경향5-3. 인력 비용 비교 (한국 기준)
전통 방식 (10~14개월)
| 역할 | 월 단가 | 투입 기간 | 소계 |
|---|---|---|---|
| 시니어 백엔드 개발자 | 900만원 | 12개월 | 1억 800만원 |
| 시니어 프론트엔드 개발자 | 850만원 | 10개월 | 8,500만원 |
| DevOps 엔지니어 (겸임) | 900만원 | 3개월 | 2,700만원 |
| PM/아키텍트 (겸임) | 1,000만원 | 12개월 | 1억 2,000만원 |
| 합계 | ~3억 4,000만원 |
AI 협업 방식 (14일)
| 항목 | 비용 |
|---|---|
| 개발자 1명 (14일) | ~650만원 |
| Claude Pro 구독 (월) | ~3만원 |
| 합계 | ~653만원 |
비용 절감: 약 98% (3.4억 → 653만원)
물론 이는 극단적 비교이며, 전통 방식에서도 효율화가 가능합니다.
AI 협업 시에도 도메인 지식을 가진 개발자의 판단이 반드시 필요합니다.
6. AI가 특히 강력했던 영역
6-1. 반복적 보일러플레이트 생성
75개 Entity, 70개 Repository, 143개 DTO — 구조가 유사한 코드를 일관된 패턴으로 대량 생성.
전통 방식: Entity 1개 작성에 30~60분
AI 협업: Entity 75개를 패턴 일관성 유지하며 하루 만에 생성6-2. 서비스 간 통합 설계
12개 서비스의 RabbitMQ 이벤트 라우팅, Feign Client 연결 — AI가 전체 아키텍처를 메모리에 유지하며 일관된 통합을 수행.
실제 사례: Payment → Reservation 라우팅 키 불일치 (payment.completed vs payment.confirmed)
AI가 12개 서비스의 이벤트 흐름을 전수 분석하여 발견 (사람은 놓치기 쉬운 부분)6-3. PDCA 문서 자동 생성
43,892줄의 설계 문서를 하루 만에 작성. 설계서가 코드와 98% 일치하는 수준의 정밀도.
6-4. Gap 분석 + 자동 수정
37개 TODO를 발견하고, 각각의 컨텍스트를 파악하여 올바른 구현으로 교체.
v5.1: 95.3% 일치율, TODO 37개
↓ AI 자동 분석 + 수정 (단일 세션)
v6.0: 98%+ 일치율, TODO 0개7. AI가 못하는 것 (사람이 반드시 필요한 영역)
| 영역 | 설명 |
|---|---|
| 도메인 지식 | 196개 매장의 업종별 비즈니스 로직은 현업 경험 필수 |
| 의사결정 | "MongoDB vs PostgreSQL" 같은 기술 선택의 최종 판단 |
| UX 감각 | 키오스크 사용자 동선, 터치 인터페이스 최적화 |
| 보안 검증 | 실제 PG 연동, 결제 보안 인증 (PCI DSS 등) |
| 운영 판단 | 프로덕션 배포 전략, 장애 대응, 모니터링 임계값 설정 |
| 이해관계자 소통 | 고객사 요구사항 조율, 일정 협의 |
8. 개발 방법론: PDCA + AI
┌────────────────────────────────────────────┐
│ PDCA Cycle with AI │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Plan │───→│ Design │ │
│ │ AI: 문서 │ │ AI: 설계 │ │
│ │ 자동 생성 │ │ 자동 생성 │ │
│ └──────────┘ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Act │←───│ Do │ │
│ │ AI: 자동 │ │ AI: 코드 │ │
│ │ 수정/개선 │ │ 자동 생성 │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ │ ┌────┴─────┐ │
│ └──────────│ Check │ │
│ │ AI: Gap │ │
│ │ 자동 분석 │ │
│ └──────────┘ │
│ │
│ 사람의 역할: 각 단계의 검증과 최종 승인 │
└────────────────────────────────────────────┘PDCA 각 단계에서 AI의 역할
| 단계 | AI 역할 | 사람 역할 |
|---|---|---|
| Plan | 요구사항을 구조화된 문서로 변환 | 비즈니스 요구사항 정의 |
| Design | 상세 설계서 + API 스펙 자동 생성 | 아키텍처 의사결정 승인 |
| Do | 설계서 기반 코드 자동 생성 | 코드 리뷰 + 도메인 검증 |
| Check | 설계-구현 Gap 자동 분석 | 품질 기준 설정 |
| Act | Gap 기반 자동 수정 | 수정 방향 판단 |
9. 기술적 도전과 해결
도전 1: 레거시 상태값 매핑
PHP: FAIL → SUCCESS → INUSE → COMPLETE → REFUND
Java: PENDING → CONFIRMED → INUSE → COMPLETE → REFUNDED
CANCELLED
FAILEDAI가 PHP 코드를 분석하여 상태 전이 맵을 자동 생성하고, DB CHECK 제약조건까지 확장.
도전 2: 이벤트 라우팅 일관성
12개 서비스가 6개 Exchange를 공유하며, 각 서비스가 발행하는 이벤트와 구독하는 큐의 라우팅 키가 정확히 일치해야 함.
발견된 CRITICAL 버그:
Payment 발행: payment.confirmed (routing key)
Reservation 구독: payment.completed (queue binding)
→ 결제 후 예약이 절대 자동 생성되지 않는 치명적 버그AI가 전 서비스의 이벤트 흐름을 크로스체크하여 발견.
도전 3: 6개 업종 × 6개 결제수단
6개 업종(스터디카페, 독서실, 사우나, 식당, 코인빨래방, 무인편의점)별로 결제 후처리 로직이 다르고, 6개 결제수단(카드, 현금, 포인트, NFC, 쿠폰, 마일리지)별 처리가 달라 36가지 조합을 Strategy Pattern으로 해결.
10. 결론
숫자로 보는 결과
┌──────────────────────────────────────┐
│ AI 협업 개발 성과 요약 │
│ │
│ 개발 기간: 14일 (vs 10~14개월) │
│ 코드 규모: 118,000+ 줄 │
│ 서비스 수: 12개 마이크로서비스 │
│ API 수: 59개 컨트롤러 │
│ DB 테이블: 106개 마이그레이션 │
│ 이벤트 통합: 12/12 서비스 (100%) │
│ 설계 일치율: 98%+ │
│ TODO 잔여: 0개 │
│ 테스트: 56/56 PASS (100%) │
│ 비용 절감: ~98% (3.4억 → 653만원) │
│ │
│ 개발 속도: 약 20~30배 향상 │
│ 일일 코드: ~3,100줄 (vs 200~400) │
└──────────────────────────────────────┘핵심 인사이트
AI는 도구이지 대체재가 아닙니다. 도메인 지식을 가진 개발자가 방향을 잡고, AI가 실행력을 제공하는 구조가 최적입니다.
PDCA + AI의 시너지. 설계 → 구현 → 검증 → 개선의 사이클을 AI가 빠르게 순환시켜 품질 98%+를 달성했습니다.
반복 작업에서 AI의 가치는 압도적입니다. 75개 엔티티, 143개 DTO, 106개 마이그레이션 — 패턴이 있는 대량 작업에서 AI는 수십 배의 생산성을 보여줍니다.
AI의 진짜 강점은 일관성입니다. 12개 서비스 간 이벤트 라우팅, 패키지 구조, 코딩 컨벤션 — 사람이 놓치기 쉬운 일관성을 AI가 유지합니다.
비용 구조가 근본적으로 바뀝니다. 10명이 1년 할 일을 1명이 2주에 끝내는 것은, 단순한 효율 개선이 아니라 개발 방식의 패러다임 전환입니다.
이 글에서 언급된 모든 수치는 실제 프로젝트 데이터 기반이며, 코드 라인 수와 파일 수는 자동 측정 도구로 검증되었습니다.
작성: Kim Wan Ki | 프로젝트: Zelotek (휴니크) | 날짜: 2026-02-09
AI 도구: Claude Code (Anthropic) | 개발 방법론: PDCA + AI Native
'AI' 카테고리의 다른 글
| 주말에 심심해서 만든 부동산 분석앱 (1) | 2026.02.13 |
|---|---|
| Claude Code 로 거래소 만들기(2) (0) | 2026.02.13 |
| Claude Code 로 거래소 만들기(1) (0) | 2026.02.11 |
| 앱+서버 만들때 Claude code 효율 비교 (2) | 2026.01.19 |
| 주니어 개발자 3명 vs Claude Code 1인 개발: 실제 프로젝트로 비교해본 효율성 (0) | 2026.01.19 |
