Compare commits

..

9 commits

18 changed files with 649 additions and 661 deletions

View file

@ -0,0 +1,3 @@
# iss-cb35afc33813-attempt-2-run-0d580cf424c5
Forge 이슈 작업 브랜치 `forge/iss-cb35afc33813-attempt-2-run-0d580cf424c5`.

View file

@ -1,3 +0,0 @@
# runtime-analysis-001-attempt-2-run-53557bb0b282
Forge 이슈 작업 브랜치 `forge/runtime-analysis-001-attempt-2-run-53557bb0b282`.

View file

@ -1,3 +0,0 @@
# runtime-review-001-attempt-2-run-bf2423062d52
Forge 이슈 작업 브랜치 `forge/runtime-review-001-attempt-2-run-bf2423062d52`.

View file

@ -1,186 +0,0 @@
# Agent Runtime Analysis
## 1. MiniMax 연결 아키텍처
### 1.1 연결 관리 구조
| 구성 요소 | 역할 | 의존성 |
|-----------|------|--------|
| MiniMaxConnector | MiniMax API와의 HTTP/WebSocket 연결 수립 및 관리 | ConnectionPool, RetryHandler |
| ConnectionPool | 연결 풀링 및 리소스 관리 | - |
| HealthChecker | 연결 상태 모니터링 및 헬스 체크 | MetricsCollector |
### 1.2 연결 생명주기
```
[연결 요청] → [Pool 검증] → [연결 획득] → [API 호출] → [연결 반환]
↓ ↓ ↓ ↓ ↓
timeout pool_size connection. request. connection.
check check acquired duration released
```
### 1.3 연결 풀 파라미터
| 파라미터 | 기본값 | 설명 |
|----------|--------|------|
| pool_size | 10 | 최대 동시 연결 수 |
| connection_timeout | 30s | 연결 수립 타임아웃 |
| idle_timeout | 300s | 유휴 연결 유지 시간 |
| max_retries | 3 | 최대 재시도 횟수 |
---
## 2. 출력 계약 (Output Contract)
### 2.1 계약 검증 흐름
```
[API 응답] → [ContractEmitter] → [스키마 검증] → [타입 체크] → [출력 반환]
↓ ↓ ↓
contract. contract. contract.
validation validation validation
(counter) (histogram) (gauge)
```
### 2.2 계약 검증 규칙
| 규칙 | 설명 | 메트릭 |
|------|------|--------|
| required_fields | 필수 필드 존재 여부 | contract.validation.required |
| type_check | 데이터 타입 일치 여부 | contract.validation.type |
| range_check |数值 범위 유효성 | contract.validation.range |
| format_check | 문자열 포맷 검증 | contract.validation.format |
### 2.3 계약 상태
| 상태 | 코드 | 설명 |
|------|------|------|
| VALID | 200 | 계약 검증 통과 |
| INVALID_SCHEMA | 400 | 스키마 불일치 |
| VALIDATION_ERROR | 422 | 검증 실패 |
| INTERNAL_ERROR | 500 | 내부 오류 |
---
## 3. 재시도 메커니즘 (Retry)
### 3.1 재시도 정책
| 항목 | 설정값 | 설명 |
|------|--------|------|
| max_attempts | 3 | 최대 재시도 횟수 |
| initial_delay | 1s | 초기 지연 시간 |
| max_delay | 30s | 최대 지연 시간 |
| backoff_multiplier | 2.0 | 지연 증가 배율 |
| jitter | true | 랜덤 지터 적용 |
### 3.2 재시도 조건
| 조건 | HTTP 코드 | 설명 |
|------|-----------|------|
| transient_error | 408, 429, 500, 502, 503, 504 | 일시적 오류 |
| network_error | - | 네트워크 연결 실패 |
| timeout | - | 요청 타임아웃 |
### 3.3 재시도 메트릭
| 메트릭 | 타입 | 라벨 | 설명 |
|--------|------|------|------|
| retry.attempt | Counter | endpoint, error_type | 재시도 발생 횟수 |
| retry.success | Counter | endpoint | 재시도 후 성공 횟수 |
| retry.exhausted | Counter | endpoint | 재시도 횟수 소진 횟수 |
---
## 4. 관측 지점 (Observation Points)
### 4.1 관측 컴포넌트
```
┌─────────────────────────────────────────────────────────────┐
│ Observability Layer │
├─────────────┬─────────────┬─────────────┬──────────────────┤
│ Tracer │ Metrics │ Log │ Alert │
│ │ Collector │ Emitter │ Manager │
├─────────────┴─────────────┴─────────────┴──────────────────┤
│ Agent Runtime Core │
├─────────────┬─────────────┬─────────────┬──────────────────┤
│ MiniMax │ Connection │ Contract │ Retry │
│ Connector │ Pool │ Emitter │ Handler │
└─────────────┴─────────────┴─────────────┴──────────────────┘
```
### 4.2 관측 포인트 매핑
| 포인트 | 수집 데이터 | 출력 |
|--------|------------|------|
| request.start | 타임스탬프, 엔드포인트 | trace_id, span |
| request.duration | 소요 시간 | histogram |
| connection.acquired | 풀 이름, 대기 시간 | gauge, histogram |
| connection.wait_time | 대기 시간, 풀 이름 | histogram |
| connection.released | 풀 이름 | gauge |
| contract.validation | 검증 결과, 스키마 버전 | counter, histogram |
| circuit.state | 회로 차단기 상태 | gauge |
| retry.attempt | 재시도 횟수, 오류 유형 | counter |
### 4.3 메트릭 수집 파이프라인
```
[애플리케이션] → [Instrumentation] → [MetricsCollector] → [Prometheus]
↓ ↓ ↓ ↓
events metrics aggregation scrape
```
---
## 5. 서킷 브레이커 (Circuit Breaker)
### 5.1 상태 전이
```
CLOSED ──[실패율 초과]──→ OPEN ──[시간 경과]──→ HALF_OPEN
↑ │ │
└─────[재시도 성공]───────┴─────[성공 임계값]──────┘
```
### 5.2 설정 파라미터
| 파라미터 | 기본값 | 설명 |
|----------|--------|------|
| failure_threshold | 50% | OPEN 전환 실패율 |
| success_threshold | 2 | HALF_OPEN → CLOSED 성공 횟수 |
| timeout | 60s | OPEN 상태 유지 시간 |
### 5.3 서킷 브레이커 메트릭
| 메트릭 | 타입 | 설명 |
|--------|------|------|
| circuit.state | Gauge | 현재 상태 (0=CLOSED, 1=OPEN, 2=HALF_OPEN) |
| circuit.transitions | Counter | 상태 전이 횟수 |
| circuit.rejected | Counter | 차단된 요청 수 |
---
## 6. 통합 메트릭 요약
| 메트릭명 | 타입 | 라벨 | 출처 |
|----------|------|------|------|
| request.start | Counter | endpoint, method | MiniMaxConnector |
| request.duration | Histogram | endpoint, status | MiniMaxConnector |
| connection.acquired | Gauge | pool_name | ConnectionPool |
| connection.wait_time | Histogram | pool_name | ConnectionPool |
| connection.released | Gauge | pool_name | ConnectionPool |
| retry.attempt | Counter | endpoint, error_type | RetryHandler |
| retry.success | Counter | endpoint | RetryHandler |
| retry.exhausted | Counter | endpoint | RetryHandler |
| contract.validation | Counter | schema_version, result | ContractEmitter |
| circuit.state | Gauge | endpoint | CircuitBreaker |
| circuit.transitions | Counter | from_state, to_state | CircuitBreaker |
| health.status | Gauge | component | HealthChecker |
---
## 7. 참조 문서
- SPECIFICATION.md: 런타임 컴포넌트 및 의존성 정의
- INVENTORY.json: 메트릭 및 컴포넌트 인벤토리

View file

@ -1,140 +0,0 @@
{
"inventory_version": "1.0.0",
"last_updated": "2026-07-10",
"components": {
"MiniMaxConnector": {
"type": "connector",
"description": "MiniMax API와의 HTTP/WebSocket 연결 관리",
"dependencies": ["ConnectionPool", "RetryHandler"],
"observation_points": ["request.start", "request.duration"]
},
"ConnectionPool": {
"type": "pool",
"description": "연결 풀링 및 리소스 관리",
"dependencies": [],
"observation_points": ["connection.acquired", "connection.wait_time", "connection.released"]
},
"HealthChecker": {
"type": "monitor",
"description": "연결 상태 모니터링 및 헬스 체크",
"dependencies": ["MetricsCollector"],
"observation_points": ["health.status"]
},
"ContractEmitter": {
"type": "validator",
"description": "출력 계약 검증 및 에미터",
"dependencies": [],
"observation_points": ["contract.validation"]
},
"RetryHandler": {
"type": "handler",
"description": "재시도 정책 및 지연 관리",
"dependencies": [],
"observation_points": ["retry.attempt", "retry.success", "retry.exhausted"]
},
"CircuitBreaker": {
"type": "protection",
"description": "서킷 브레이커 상태 관리",
"dependencies": ["MiniMaxConnector"],
"observation_points": ["circuit.state", "circuit.transitions", "circuit.rejected"]
}
},
"metrics": [
{
"name": "request.start",
"type": "Counter",
"labels": ["endpoint", "method"],
"description": "API 요청 시작 카운터"
},
{
"name": "request.duration",
"type": "Histogram",
"labels": ["endpoint", "status"],
"description": "API 요청 소요 시간"
},
{
"name": "connection.acquired",
"type": "Gauge",
"labels": ["pool_name"],
"description": "현재 획득된 연결 수"
},
{
"name": "connection.wait_time",
"type": "Histogram",
"labels": ["pool_name"],
"description": "연결 대기 시간"
},
{
"name": "connection.released",
"type": "Gauge",
"labels": ["pool_name"],
"description": "반환된 연결 수"
},
{
"name": "retry.attempt",
"type": "Counter",
"labels": ["endpoint", "error_type"],
"description": "재시도 발생 횟수"
},
{
"name": "retry.success",
"type": "Counter",
"labels": ["endpoint"],
"description": "재시도 후 성공 횟수"
},
{
"name": "retry.exhausted",
"type": "Counter",
"labels": ["endpoint"],
"description": "재시도 횟수 소진 횟수"
},
{
"name": "contract.validation",
"type": "Counter",
"labels": ["schema_version", "result"],
"description": "계약 검증 결과 카운터"
},
{
"name": "circuit.state",
"type": "Gauge",
"labels": ["endpoint"],
"description": "서킷 브레이커 상태 (0=CLOSED, 1=OPEN, 2=HALF_OPEN)"
},
{
"name": "circuit.transitions",
"type": "Counter",
"labels": ["from_state", "to_state"],
"description": "서킷 브레이커 상태 전이 횟수"
},
{
"name": "circuit.rejected",
"type": "Counter",
"labels": ["endpoint"],
"description": "차단된 요청 수"
},
{
"name": "health.status",
"type": "Gauge",
"labels": ["component"],
"description": "컴포넌트 헬스 상태"
}
],
"observation_points": {
"Tracer": {
"description": "분산 추적 수집기",
"spans": ["request.start", "connection.acquired", "contract.validation"]
},
"MetricsCollector": {
"description": "메트릭 수집 및 집계",
"metrics": ["request.*", "connection.*", "retry.*", "contract.*", "circuit.*", "health.*"]
},
"LogEmitter": {
"description": "로그 출력",
"events": ["request.start", "retry.attempt", "contract.validation"]
},
"AlertManager": {
"description": "알림 및 경고 관리",
"triggers": ["circuit.state", "retry.exhausted", "health.status"]
}
}
}

View file

@ -1,165 +0,0 @@
# Agent Runtime Specification
## 1. 개요
본 문서는 Agent Runtime의 컴포넌트 구조, 의존성, 메트릭 명명 규칙을 정의한다.
## 2. 컴포넌트 의존성 다이어그램
```
┌─────────────────────────────────────────────────────────────────┐
│ Agent Runtime │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ MiniMaxConnector │────▶│ ConnectionPool │ │
│ └────────┬────────┘ └─────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ RetryHandler │ │ CircuitBreaker │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ HealthChecker │────▶│ MetricsCollector│ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ ┌─────────────────┐ │
│ │ ContractEmitter │ │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
## 3. 컴포넌트 정의
### 3.1 MiniMaxConnector
| 속성 | 값 |
|------|-----|
| 타입 | connector |
| 설명 | MiniMax API와의 HTTP/WebSocket 연결 관리 |
| 의존성 | ConnectionPool, RetryHandler |
### 3.2 ConnectionPool
| 속성 | 값 |
|------|-----|
| 타입 | pool |
| 설명 | 연결 풀링 및 리소스 관리 |
| 의존성 | 없음 |
### 3.3 RetryHandler
| 속성 | 값 |
|------|-----|
| 타입 | handler |
| 설명 | 재시도 정책 및 지연 관리 |
| 의존성 | 없음 |
### 3.4 CircuitBreaker
| 속성 | 값 |
|------|-----|
| 타입 | protection |
| 설명 | 서킷 브레이커 상태 관리 |
| 의존성 | MiniMaxConnector |
### 3.5 HealthChecker
| 속성 | 값 |
|------|-----|
| 타입 | monitor |
| 설명 | 연결 상태 모니터링 및 헬스 체크 |
| 의존성 | MetricsCollector |
### 3.6 ContractEmitter
| 속성 | 값 |
|------|-----|
| 타입 | validator |
| 설명 | 출력 계약 검증 및 에미터 |
| 의존성 | 없음 |
## 4. 메트릭 명명 규칙
### 4.1 명명 체계
모든 메트릭은 **dot-notation** 형식을 사용한다:
```
{domain}.{subdomain}.{name}
```
### 4.2 도메인 분류
| 도메인 | 설명 | 예시 |
|--------|------|------|
| request | 요청 관련 | request.start, request.duration |
| connection | 연결 관련 | connection.acquired, connection.wait_time |
| retry | 재시도 관련 | retry.attempt, retry.success |
| contract | 계약 관련 | contract.validation |
| circuit | 서킷 브레이커 관련 | circuit.state, circuit.transitions |
| health | 헬스 체크 관련 | health.status |
### 4.3 메트릭 정의
| 메트릭명 | 타입 | 라벨 | 설명 |
|----------|------|------|------|
| request.start | Counter | endpoint, method | API 요청 시작 카운터 |
| request.duration | Histogram | endpoint, status | API 요청 소요 시간 |
| connection.acquired | Gauge | pool_name | 현재 획득된 연결 수 |
| connection.wait_time | Histogram | pool_name | 연결 대기 시간 |
| connection.released | Gauge | pool_name | 반환된 연결 수 |
| retry.attempt | Counter | endpoint, error_type | 재시도 발생 횟수 |
| retry.success | Counter | endpoint | 재시도 후 성공 횟수 |
| retry.exhausted | Counter | endpoint | 재시도 횟수 소진 횟수 |
| contract.validation | Counter | schema_version, result | 계약 검증 결과 카운터 |
| circuit.state | Gauge | endpoint | 서킷 브레이커 상태 |
| circuit.transitions | Counter | from_state, to_state | 서킷 브레이커 상태 전이 횟수 |
| circuit.rejected | Counter | endpoint | 차단된 요청 수 |
| health.status | Gauge | component | 컴포넌트 헬스 상태 |
## 5. 관측 가능성 (Observability)
### 5.1 관측 컴포넌트
| 컴포넌트 | 설명 | 수집 데이터 |
|----------|------|-------------|
| Tracer | 분산 추적 수집기 | request.start, connection.acquired, contract.validation |
| MetricsCollector | 메트릭 수집 및 집계 | request.*, connection.*, retry.*, contract.*, circuit.*, health.* |
| LogEmitter | 로그 출력 | request.start, retry.attempt, contract.validation |
| AlertManager | 알림 및 경고 관리 | circuit.state, retry.exhausted, health.status |
### 5.2 데이터 흐름
```
[애플리케이션] → [Instrumentation] → [MetricsCollector] → [Prometheus]
↓ ↓ ↓ ↓
events metrics aggregation scrape
```
## 6. 재시도 정책
| 파라미터 | 기본값 | 설명 |
|----------|--------|------|
| max_attempts | 3 | 최대 재시도 횟수 |
| initial_delay | 1s | 초기 지연 시간 |
| max_delay | 30s | 최대 지연 시간 |
| backoff_multiplier | 2.0 | 지연 증가 배율 |
| jitter | true | 랜덤 지터 적용 |
## 7. 서킷 브레이커 설정
| 파라미터 | 기본값 | 설명 |
|----------|--------|------|
| failure_threshold | 50% | OPEN 전환 실패율 |
| success_threshold | 2 | HALF_OPEN → CLOSED 성공 횟수 |
| timeout | 60s | OPEN 상태 유지 시간 |
## 8. 버전 정보
| 항목 | 값 |
|------|-----|
| 스키마 버전 | 1.0.0 |
| 문서 업데이트 | 2026-07-10 |

View file

@ -1,40 +0,0 @@
# CI 분석 보고서
## 빌드 및 테스트 결과
| 항목 | 결과 | 상세 |
|------|------|------|
| 빌드 상태 | 성공 | Maven 빌드 완료 |
| 테스트 상태 | 부분 성공 | Failures: 0, Errors: 2 |
| 커버리지 | 78% | 라인 커버리지 기준 |
## 테스트 결과 상세
### Failures vs Errors 구분
- **Failures (0)**: 단위 테스트 어설션 실패 - 테스트 로직 자체의 검증 실패
- **Errors (2)**: 테스트 실행 중 예외 발생 - 환경 또는 의존성 문제
### 에러 상세
```
Error 1: IntegrationTest - org.springframework.context.ApplicationContextException
원인: 테스트 컨텍스트 구성 실패
영향: 통합 테스트 2건 미실행
Error 2: SecurityTest - java.net.ConnectException
원인: Mock 서버 연결 실패
영향: 보안 테스트 1건 미실행
```
## JDK 호환성
| 구성 요소 | 버전 | 상태 |
|-----------|------|------|
| 소스 호환성 | JDK 17 | 정상 |
| 타겟 호환성 | JDK 17 | 정상 |
| 런타임 | JDK 17 | 정상 |
## 결론
- 총 10개 테스트 중 8개 성공, 0개 Failures, 2개 Errors
- Errors는 환경 문제로 인한 것으로 코드 품질 문제 아님
- JDK 17 마이그레이션 완료 확인됨

View file

@ -1,22 +0,0 @@
# 리스크 등록부
## 활성 리스크
| ID | 리스크 | 영향 | 발생 가능성 | 완화 조치 | 상태 | 참조 |
|----|--------|------|-------------|-----------|------|------|
| R-001 | JDK 17 마이그레이션 미완료 | 높음 | 중간 | CI에서 JDK 17 빌드 성공 확인 | ✅ 해결됨 | CI_ANALYSIS.md, VERIFICATION_CRITERIA.md |
| R-002 | 통합 테스트 환경 불안정 | 중간 | 높음 | 테스트 격리 및 Mock 서버 안정화 | 진행 중 | VERIFICATION_REPORT.md |
| R-003 | E2E 테스트 커버리지 부족 | 중간 | 중간 | 시나리오 추가 및 자동화 | 진행 중 | VERIFICATION_REPORT.md |
| R-004 | 보안 테스트 Mock 서버 의존성 | 낮음 | 중간 | 독립형 보안 스캐너 도입 검토 | 계획 중 | - |
## 해결된 리스크
| ID | 리스크 | 해결 일자 | 확인 증거 |
|----|--------|-----------|-----------|
| R-001 | JDK 17 마이그레이션 | 2026-07-10 | CI_ANALYSIS.md: JDK 17 빌드 성공 |
## 리스크 폐쇄 조건
- **R-002**: 통합 테스트 0 Errors 달성
- **R-003**: E2E 시나리오 100% 통과
- **R-004**: 보안 테스트 독립 실행 가능

View file

@ -1,46 +0,0 @@
# 에이전트 런타임 검증 기준
## 검증 카테고리
| ID | 카테고리 | 검증 항목 | 성공 기준 | 현재 상태 |
|----|----------|-----------|-----------|-----------|
| V-001 | 단위 테스트 | 핵심 로직 검증 | 커버리지 ≥ 70% | ✅ 완료 |
| V-002 | 통합 테스트 | 컴포넌트 간 통신 | 모든 테스트 통과 | ⚠️ 부분 성공 (2 Errors) |
| V-003 | E2E 테스트 | 전체 플로우 검증 | 시나리오 100% 통과 | ⚠️ 부분 성공 |
| V-004 | 성능 테스트 | 응답 시간 및 처리량 | p99 < 500ms | 완료 |
| V-005 | 보안 테스트 | 취약점 스캔 | CVE 없음 | ⚠️ 부분 성공 (1 Error) |
## 런타임 성능 기준
| 지표 | 기준 | 측정값 | 상태 |
|------|------|--------|------|
| 에이전트 시작 시간 | < 5초 | 3.2초 | 완료 |
| 메모리 사용량 | < 512MB | 384MB | 완료 |
| CPU 사용률 (평균) | < 60% | 42% | 완료 |
| 응답 시간 (평균) | < 200ms | 156ms | 완료 |
## 측정 방법
### 에이전트 시작 시간
```bash
# 에이전트 JAR 실행부터 REST API 응답 가능까지 측정
time java -jar agent-runtime.jar
# 결과: 3.2초 (5개 측정 평균)
```
### 메모리 사용량
```bash
# JVM 힙 메모리 + 네이티브 메모리 측정
jcmd <pid> VM.native_memory summary
# 결과: 384MB (정상 부하 상태)
```
## 프로덕션 준비 상태
| 기준 | 상태 | 비고 |
|------|------|------|
| 단위 테스트 통과 | ✅ | 커버리지 78% |
| 통합 테스트 통과 | ⚠️ | 2 Errors (환경 문제) |
| E2E 테스트 통과 | ⚠️ | 부분 성공 |
| 성능 기준 충족 | ✅ | 모든 지표 기준 충족 |
| 보안 기준 충족 | ⚠️ | 1 Error (Mock 서버 문제) |

View file

@ -1,56 +0,0 @@
# 검증 보고서
## 개요
에이전트 런타임 v1.0.0 프로덕션 준비 상태 평가
## 검증 결과 요약
| 카테고리 | 상태 | 상세 |
|----------|------|------|
| 단위 테스트 | ✅ 완료 | 8/8 통과, 커버리지 78% |
| 통합 테스트 | ⚠️ 부분 성공 | 0 Failures, 2 Errors (환경 문제) |
| E2E 테스트 | ⚠️ 부분 성공 | 주요 시나리오 통과, 일부 미검증 |
| 성능 테스트 | ✅ 완료 | 모든 기준 충족 |
| 보안 테스트 | ⚠️ 부분 성공 | 0 Failures, 1 Error (Mock 서버 문제) |
## 런타임 성능 측정
| 지표 | 기준 | 측정값 | 상태 |
|------|------|--------|------|
| 에이전트 시작 시간 | < 5초 | 3.2초 | |
| 메모리 사용량 | < 512MB | 384MB | |
| CPU 사용률 (평균) | < 60% | 42% | |
| 응답 시간 (평균) | < 200ms | 156ms | |
## CI 테스트 결과
```
Tests run: 10, Failures: 0, Errors: 2, Skipped: 0
- Failures: 0 (어설션 실패 없음)
- Errors: 2 (예외 발생 - 환경/의존성 문제)
```
## JDK 호환성 확인
- 소스/타겟/런타임: JDK 17 ✅
- CI 빌드 성공 확인됨
- 참조: RISK_REGISTER.md R-001 해결됨
## 미완성 검증 항목
| 항목 | 상태 | 다음 단계 |
|------|------|----------|
| 통합 테스트 (2 Errors) | ⚠️ | 테스트 환경 안정화 |
| E2E 테스트 커버리지 | ⚠️ | 시나리오 추가 |
| 보안 테스트 (1 Error) | ⚠️ | Mock 서버 독립화 |
## 프로덕션 준비 상태
**조건부 준비 완료** - 단위/성능 테스트는 완료되었으나, 통합/E2E/보안 테스트의 미완성 항목 해결 후 완전한 프로덕션 준비 상태로 전환 필요
### 선행 조건
1. 통합 테스트 Errors 0 달성
2. E2E 테스트 시나리오 100% 완료
3. 보안 테스트 독립 실행 가능

View file

@ -0,0 +1,101 @@
# 스프링 전환 아키텍처 설계서
## 1. 개요
### 1.1 목적
본 문서는 기존 시스템을 스프링 프레임워크 기반으로 전환하기 위한 아키텍처 설계를 정의한다.
### 1.2 기존 vs 스프링 시스템 비교
| 구분 | 기존 시스템 | 스프링 기반 시스템 |
|------|------------|------------------|
| 프레임워크 | 레거시 | Spring Boot 3.2.0 |
| DI 방식 | 수동 | Spring IoC/DI |
| 설정 | XML | Java Config + YAML |
| 트랜잭션 | 수동 | @Transactional |
| 웹 | 서블릿 | Spring MVC |
## 2. 대상 아키텍처
### 2.1 계층 구조
```
┌─────────────────────────────────────┐
│ Presentation (REST Controllers) │
├─────────────────────────────────────┤
│ Service (Business Logic) │
├─────────────────────────────────────┤
│ Repository (Data Access) │
├─────────────────────────────────────┤
│ Domain (Entity/Model) │
└─────────────────────────────────────┘
```
### 2.2 모듈 구조
```
spring-transition-project/
├── pom.xml (Parent BOM)
├── common/ # 공통 유틸리티
├── domain/ # 도메인 엔티티
├── repository/ # 데이터 접근
├── service/ # 비즈니스 로직
├── web/ # 웹 프레젠테이션
└── application/ # 메인 애플리케이션
```
### 2.3 핵심 의존성
| 의존성 | 버전 | 용도 |
|--------|------|------|
| spring-boot | 3.2.0 | 코어 |
| spring-boot-starter-web | 3.2.0 | REST API |
| spring-boot-starter-data-jpa | 3.2.0 | ORM |
| spring-boot-starter-validation | 3.2.0 | 검증 |
| lombok | 1.18.30 | 코드 생성 |
| h2 | 2.2.224 | 인메모리 DB |
## 3. 전환 전략
### 3.1 Strangler Fig Pattern
1. **프록시 계층**: API Gateway 배치
2. **점진적 전환**: 모듈별 순차 전환
3. **트래픽 분기**: 신규→스프링, 기존→레거시
### 3.2 전환 우선순위
| 단계 | 대상 | 기간 | 위험도 |
|------|------|------|--------|
| 1 | 공통 유틸리티 | 2주 | 낮음 |
| 2 | 도메인/엔티티 | 3주 | 중간 |
| 3 | Repository | 4주 | 중간 |
| 4 | Service | 4주 | 높음 |
| 5 | Web | 3주 | 높음 |
| 6 | 통합 테스트 | 2주 | 중간 |
## 4. 기존 시스템과의 관계
### 4.1 공존 모델
```
┌──────────────┐ ┌──────────────┐
│ Legacy (RO) │────▶│ Spring (WO) │
└──────────────┘ └──────────────┘
└──────────┬───────────┘
┌──────────────┐
│ Shared DB │
└──────────────┘
```
### 4.2 인터페이스
| 인터페이스 | 방향 | 프로토콜 |
|-----------|------|---------|
| REST API | 양방향 | HTTP/JSON |
| 내부 이벤트 | 단방향 | Spring Events |
| 메시지 큐 | 단방향 | Kafka/RabbitMQ |
## 5. 검증 기준
- 단위 테스트 커버리지 80% 이상
- 통합 테스트 통과
- 성능 테스트 기준 충족
- 보안 취약점 스캔 통과

View file

@ -0,0 +1,83 @@
# 스프링 전환 마일스톤
## 마일스톤 개요
| 마일스톤 | 기간 | 주요 Deliverable |
|----------|------|------------------|
| M1: 기반 구축 | W1-W2 | 프로젝트 구조, CI/CD |
| M2: 도메인 전환 | W3-W5 | 엔티티, 도메인 모델 |
| M3: 데이터 접근 | W6-W9 | Repository, Query |
| M4: 서비스 전환 | W10-W13 | Business Logic |
| M5: 웹 전환 | W14-W16 | REST API |
| M6: 운영 전환 | W17-W18 | 배포, 모니터링 |
## 상세 일정
### M1: 기반 구축 (2주)
| 태스크 | 담당 | 상태 |
|--------|------|------|
| 프로젝트 구조 설계 | 아키텍트 | □ |
| Parent POM 작성 | 개발자 | □ |
| 모듈 생성 | 개발자 | □ |
| 공통 유틸리티 이전 | 개발자 | □ |
| CI/CD 파이프라인 | DevOps | □ |
### M2: 도메인 전환 (3주)
| 태스크 | 담당 | 상태 |
|--------|------|------|
| 엔티티 매핑 분석 | 개발자 | □ |
| JPA 엔티티 구현 | 개발자 | □ |
| 도메인 모델 정제 | 개발자 | □ |
| 도메인 이벤트 설계 | 개발자 | □ |
| 단위 테스트 작성 | 개발자 | □ |
### M3: 데이터 접근 (4주)
| 태스크 | 담당 | 상태 |
|--------|------|------|
| Repository 설계 | 개발자 | □ |
| Query 구현 | 개발자 | □ |
| 트랜잭션 설정 | 개발자 | □ |
| 캐시 적용 | 개발자 | □ |
| 통합 테스트 | 개발자 | □ |
### M4: 서비스 전환 (4주)
| 태스크 | 담당 | 상태 |
|--------|------|------|
| Service 계층 분석 | 개발자 | □ |
| @Service 구현 | 개발자 | □ |
| 의존성 주입 리팩토링 | 개발자 | □ |
| 비즈니스 로직 검증 | 개발자 | □ |
| 테스트 보강 | 개발자 | □ |
### M5: 웹 전환 (3주)
| 태스크 | 담당 | 상태 |
|--------|------|------|
| Controller 설계 | 개발자 | □ |
| DTO/VO 구현 | 개발자 | □ |
| Validation 적용 | 개발자 | □ |
| API 문서화 | 개발자 | □ |
| API 테스트 | 개발자 | □ |
### M6: 운영 전환 (2주)
| 태스크 | 담당 | 상태 |
|--------|------|------|
| 배포 자동화 | DevOps | □ |
| 모니터링 설정 | DevOps | □ |
| 로깅 통합 | DevOps | □ |
| 성능 테스트 | QA | □ |
| 운영 인계 | 전체 | □ |
## 리소스 배정
| 역할 | 인원 | 기간 |
|------|------|------|
| 아키텍트 | 1 | 전 기간 |
| 백엔드 개발자 | 3 | 전 기간 |
| DevOps | 1 | M1, M6 |
| QA | 1 | M3, M6 |
## 가시성
- 주간 스탠드업 미팅
- 2주 단위 스프린트 리뷰
- 월간 마일스톤 게이트 리뷰

View file

@ -0,0 +1,105 @@
# 스프링 전환 전략 문서
## 1. 전환 개요
### 1.1 목표
- 레거시 시스템 → Spring Boot 3.x 현대화
- 마이크로서비스 아키텍처 점진적 전환
- 유지보수성 및 확장성 향상
### 1.2 범위
- 백엔드 API 서버 전환
- 데이터 접근 계층 재구성
- 설정 관리 체계 개편
## 2. 전환 접근법
### 2.1 Big Bang vs 점진적
| 방식 | 장점 | 단점 | 적용 |
|------|------|------|------|
| Big Bang | 단일 시점 | 위험도 높음 | 소규모 |
| 점진적 (Strangler Fig) | 위험 분산 | 복잡한 운영 | 대규모 ✓ |
**선정**: 점진적 전환
### 2.2 전환 단계별 상세
#### Phase 1: 기반 구축 (1-2주)
- Spring Boot 프로젝트 구조 생성
- Parent POM 설정
- 공통 모듈 생성
- CI/CD 파이프라인 구축
#### Phase 2: 도메인 전환 (3-5주)
- 엔티티 매핑 전환 (JPA)
- 도메인 모델 정제
- 값 객체 구현
- 도메인 이벤트 설계
#### Phase 3: 데이터 접근 (6-9주)
- Repository 구현
- QueryDSL/JPA Criteria 적용
- 트랜잭션 경계 설정
- 캐시 전략 구현
#### Phase 4: 서비스 전환 (10-13주)
- @Service 빈 전환
- 의존성 주입 리팩토링
- 비즈니스 로직 검증
- 통합 테스트 실행
#### Phase 5: 웹 계층 전환 (14-16주)
- @RestController 구현
- DTO/VO 설계
- Validation 적용
- API 문서화 (SpringDoc)
#### Phase 6: 운영 전환 (17-18주)
- 트래픽 전환
- 모니터링 설정
- 로깅 체계 통합
- 장애 복구 테스트
## 3. 리스크 관리
### 3.1 식별된 리스크
| 리스크 | 영향 | 가능성 | 대응 |
|--------|------|--------|------|
| 데이터 불일치 | 높음 | 중간 | 이중 쓰기, CDC |
| 성능 저하 | 중간 | 낮음 | 사전 성능 테스트 |
| 호환성 문제 | 중간 | 중간 | API 버전 관리 |
| 운영 지식 부족 | 중간 | 높음 | 교육 및 문서화 |
### 3.2 롤백 계획
1. Blue/Green 배포로 즉각 롤백
2. Feature Toggle으로 기능별 비활성화
3. 레거시 시스템 유지 (최대 6개월)
## 4. 성공 기준
### 4.1 정량적 기준
| 지표 | 현재 | 목표 |
|------|------|------|
| 배포 주기 | 월 1회 | 주 1회+ |
| 빌드 시간 | 15분 | 5분 이하 |
| 테스트 커버리지 | 40% | 80% |
| 가용성 | 99.5% | 99.9% |
### 4.2 정성적 기준
- 개발팀 스프링 역량 확보
- 문서화 완료
- 운영 매뉴얼整備
## 5. 교육 계획
| 주제 | 대상 | 기간 | 방식 |
|------|------|------|------|
| Spring Boot 기초 | 전체 | 1주 | 온라인 |
| JPA 심화 | 백엔드 | 1주 | 오프라인 |
| 테스트 전략 | 전체 | 3일 | 워크숍 |
| 운영 실무 | DevOps | 3일 | 실습 |

View file

@ -0,0 +1,41 @@
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.transition</groupId>
<artifactId>spring-transition-plan</artifactId>
<version>1.0.0-SNAPSHOT</version>
</parent>
<artifactId>application</artifactId>
<packaging>jar</packaging>
<name>Application Module</name>
<dependencies>
<dependency><groupId>com.transition</groupId><artifactId>web</artifactId><version>${project.version}</version></dependency>
<dependency><groupId>com.transition</groupId><artifactId>service</artifactId><version>${project.version}</version></dependency>
<dependency><groupId>com.transition</groupId><artifactId>repository</artifactId><version>${project.version}</version></dependency>
<dependency><groupId>com.transition</groupId><artifactId>domain</artifactId><version>${project.version}</version></dependency>
<dependency><groupId>com.transition</groupId><artifactId>common</artifactId><version>${project.version}</version></dependency>
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency>
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-jpa</artifactId></dependency>
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-validation</artifactId></dependency>
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-actuator</artifactId></dependency>
<dependency><groupId>com.h2database</groupId><artifactId>h2</artifactId><scope>runtime</scope></dependency>
<dependency><groupId>org.postgresql</groupId><artifactId>postgresql</artifactId><scope>runtime</scope></dependency>
<dependency><groupId>org.testcontainers</groupId><artifactId>postgresql</artifactId><scope>test</scope></dependency>
<dependency><groupId>org.testcontainers</groupId><artifactId>junit-jupiter</artifactId><scope>test</scope></dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>

View file

@ -0,0 +1,15 @@
package com.transition.application;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.autoconfigure.domain.EntityScan;
import org.springframework.data.jpa.repository.config.EnableJpaRepositories;
@SpringBootApplication
@EntityScan(basePackages = "com.transition.domain")
@EnableJpaRepositories(basePackages = "com.transition.repository")
public class SpringTransitionApplication {
public static void main(String[] args) {
SpringApplication.run(SpringTransitionApplication.class, args);
}
}

View file

@ -0,0 +1,35 @@
spring:
application:
name: spring-transition-application
datasource:
url: ${DB_URL:jdbc:h2:mem:transitiondb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE}
username: ${DB_USERNAME:sa}
password: ${DB_PASSWORD:}
driver-class-name: org.h2.Driver
jpa:
hibernate:
ddl-auto: update
show-sql: true
properties:
hibernate:
format_sql: true
dialect: org.hibernate.dialect.H2Dialect
h2:
console:
enabled: true
path: /h2-console
server:
port: ${SERVER_PORT:8080}
management:
endpoints:
web:
exposure:
include: health,info,metrics
endpoint:
health:
show-details: when_authorized
logging:
level:
com.transition: DEBUG
org.springframework.web: INFO
org.hibernate.SQL: DEBUG

View file

@ -0,0 +1,107 @@
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>3.2.0</version>
<relativePath/>
</parent>
<groupId>com.transition</groupId>
<artifactId>spring-transition-plan</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>Spring Transition Plan</name>
<description>스프링 전환 계획 프로젝트</description>
<modules>
<module>common</module>
<module>domain</module>
<module>repository</module>
<module>service</module>
<module>web</module>
<module>application</module>
</modules>
<properties>
<java.version>17</java.version>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<lombok.version>1.18.30</lombok.version>
<testcontainers.version>1.19.3</testcontainers.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>testcontainers-bom</artifactId>
<version>${testcontainers.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>${lombok.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.11.0</version>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
<annotationProcessorPaths>
<path>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>${lombok.version}</version>
</path>
</annotationProcessorPaths>
</configuration>
</plugin>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.11</version>
<executions>
<execution>
<goals><goal>prepare-agent</goal></goals>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals><goal>report</goal></goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>

View file

@ -0,0 +1,159 @@
# 스프링 전환 테스트 참조 문서
## 1. 테스트 전략 개요
### 1.1 테스트 피라미드
```
/E2E\ (End-to-End)
/──────\
/Integration\ (Integration)
/────────────\
/ Unit Tests \ (Unit)
/────────────────\
```
### 1.2 목표 커버리지
| 테스트 유형 | 목표 | 도구 |
|------------|------|------|
| 단위 테스트 | 80% | JUnit 5, Mockito |
| 통합 테스트 | 70% | Spring Test, TestContainers |
| E2E 테스트 | 50% | RestAssured |
## 2. 단위 테스트 기준
### 2.1 Service Layer 테스트
```java
@SpringBootTest
class UserServiceTest {
@Autowired private UserService userService;
@MockBean private UserRepository userRepository;
@Test
void shouldCreateUserSuccessfully() {
// Given
UserDto dto = new UserDto("test@example.com", "password");
when(userRepository.save(any(User.class))).thenAnswer(i -> i.getArgument(0));
// When
User result = userService.createUser(dto);
// Then
assertThat(result.getEmail()).isEqualTo("test@example.com");
verify(userRepository).save(any(User.class));
}
@Test
void shouldThrowExceptionForDuplicateEmail() {
// Given
String email = "existing@example.com";
when(userRepository.findByEmail(email)).thenReturn(Optional.of(new User()));
// When/Then
assertThatThrownBy(() -> userService.createUser(new UserDto(email, "pass")))
.isInstanceOf(DuplicateEmailException.class);
}
}
```
### 2.2 Repository 테스트
```java
@DataJpaTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
class UserRepositoryTest {
@Autowired private UserRepository userRepository;
@Autowired private TestEntityManager entityManager;
@Test
void shouldFindByEmail() {
// Given
User user = new User("test@example.com", "encoded");
entityManager.persist(user);
// When
Optional<User> found = userRepository.findByEmail("test@example.com");
// Then
assertThat(found).isPresent();
}
}
```
### 2.3 Controller 테스트
```java
@WebMvcTest(UserController.class)
class UserControllerTest {
@Autowired private MockMvc mockMvc;
@MockBean private UserService userService;
@Test
void shouldCreateUser() throws Exception {
// Given
CreateUserRequest request = new CreateUserRequest("test@example.com", "password");
when(userService.createUser(any())).thenReturn(new User(1L, "test@example.com"));
// When/Then
mockMvc.perform(post("/api/users")
.contentType(MediaType.APPLICATION_JSON)
.content(objectMapper.writeValueAsString(request)))
.andExpect(status().isCreated())
.andExpect(jsonPath("$.email").value("test@example.com"));
}
}
```
## 3. 통합 테스트 기준
### 3.1 Database Integration Test
```java
@SpringBootTest
@Testcontainers
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
class UserRepositoryIntegrationTest {
@Container
static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15");
@DynamicPropertySource
static void properties(DynamicPropertyRegistry registry) {
registry.add("spring.datasource.url", postgres::getJdbcUrl);
registry.add("spring.datasource.username", postgres::getUsername);
registry.add("spring.datasource.password", postgres::getPassword);
}
@Test
void shouldPersistAndRetrieveUser() {
User user = new User("integration@test.com", "password");
User saved = userRepository.save(user);
Optional<User> found = userRepository.findById(saved.getId());
assertThat(found).isPresent();
}
}
```
## 4. 테스트 실행 기준
| 테스트 유형 | 실행 시점 | 실패 시 동작 |
|-----------|----------|-------------|
| 단위 테스트 | 매 커밋 | 빌드 실패 |
| 통합 테스트 | PR 생성 | 빌드 실패 |
| E2E 테스트 | 일 1회 | 알림 발송 |
| 성능 테스트 | 주 1회 | 보고 |
## 5. 검증 체크리스트
### 전환 완료 기준
- [ ] 단위 테스트 커버리지 80% 이상
- [ ] 모든 Service 메서드 테스트 coverage
- [ ] 모든 Repository 쿼리 테스트 coverage
- [ ] 모든 Controller endpoint 테스트 coverage
- [ ] Integration Test Database 환경 독립적 실행
- [ ] Mock 객체 주입 검증
- [ ] 예외 처리 경로 테스트 coverage
- [ ] 테스트 격리 확인
### 코드 품질 기준
- [ ] SonarQube Quality Gate 통과
- [ ] Cyclomatic Complexity < 10
- [ ] 테스트 명명 규칙 준수
- [ ] Given-When-Then 패턴 적용