diff --git a/.forge/role-pm-001-attempt-1-run-0d2fe2a0ad41.md b/.forge/role-pm-001-attempt-1-run-0d2fe2a0ad41.md new file mode 100644 index 0000000..ab047bb --- /dev/null +++ b/.forge/role-pm-001-attempt-1-run-0d2fe2a0ad41.md @@ -0,0 +1,3 @@ +# role-pm-001-attempt-1-run-0d2fe2a0ad41 + +Forge 이슈 작업 브랜치 `forge/role-pm-001-attempt-1-run-0d2fe2a0ad41`. diff --git a/.forge/role-ta-001-attempt-1-run-9fa6a6b8d5c6.md b/.forge/role-ta-001-attempt-1-run-9fa6a6b8d5c6.md new file mode 100644 index 0000000..41d89a8 --- /dev/null +++ b/.forge/role-ta-001-attempt-1-run-9fa6a6b8d5c6.md @@ -0,0 +1,3 @@ +# role-ta-001-attempt-1-run-9fa6a6b8d5c6 + +Forge 이슈 작업 브랜치 `forge/role-ta-001-attempt-1-run-9fa6a6b8d5c6`. diff --git a/docs/OPERATIONS_HANDOVER.md b/docs/OPERATIONS_HANDOVER.md new file mode 100644 index 0000000..9d680e2 --- /dev/null +++ b/docs/OPERATIONS_HANDOVER.md @@ -0,0 +1,115 @@ +# 런타임 역할 검증 프로젝트 - 운영 인수인계 문서 + +**프로젝트**: runtime-role-smoke-202607140500 +**작성일**: 2025-07-14 +**버전**: 1.0 + +--- + +## 1. 완료 기준 (Definition of Done) + +| 항목 | 기준 | 검증 방법 | +|------|------|----------| +| 역할별 에이전트 동작 | 각 역할(PM, Dev, QA, Security)이 정의된 작업을 자동 수행 | 스모크 테스트 통과 | +| 태스크 완료율 | 할당된 태스크 100% 완료 | 태스크 트래커 기준 | +| 문서 완결성 | README, API 문서, 운영 가이드 포함 | 문서 체크리스트 | +| 테스트 커버리지 | 핵심 기능 80% 이상 | 테스트 보고서 | +| 보안 검증 | 취약점 스캔 통과 (Critical/High 없음) | 보안 스캔 결과 | + +--- + +## 2. 역할별 책임 (Role Responsibilities) + +### 2.1 PM (Project Manager) +- **주요 책임**: 프로젝트 범위 관리, 일정 조율, 이해관계자 커뮤니케이션 +- **핵심 태스크**: + - 백로그 관리 및 우선순위 결정 + - 스프린트 계획 및 리뷰 진행 + - 리스크 식별 및 완화措施 수립 +- **인수인계 항목**: + - [ ] 프로젝트 로드맵 문서 + - [ ] 백로그 및 태스크 현황 + - [ ] 이해관계자 연락처 목록 + - [ ] 의사결정 로그 + +### 2.2 Dev (Developer) +- **주요 책임**: 기능 구현, 코드 품질 관리, 기술 아키텍처 결정 +- **핵심 태스크**: + - 에이전트 런타임 핵심 로직 구현 + - CI/CD 파이프라인 구축 + - 코드 리뷰 및 머지 관리 +- **인수인계 항목**: + - [ ] 소스 코드 저장소 (Git) + - [ ] 빌드 설정 및 스크립트 + - [ ] 기술 설계 문서 + - [ ] API 명세서 + +### 2.3 QA (Quality Assurance) +- **주요 책임**: 품질 검증, 테스트 자동화, 버그 관리 +- **핵심 태스크**: + - 스모크 테스트 시나리오 작성 및 실행 + - 회귀 테스트 관리 + - 품질 지표 수집 및 보고 +- **인수인계 항목**: + - [ ] 테스트 케이스 문서 + - [ ] 테스트 자동화 스크립트 + - [ ] 버그 추적 시스템 접근 권한 + - [ ] 품질 보고서 템플릿 + +### 2.4 Security +- **주요 책임**: 보안 검토, 취약점 관리, 컴플라이언스 +- **핵심 태스크**: + - 보안 리뷰 및 위협 모델링 + - 취약점 스캔 및 패치 관리 + - 보안 정책 준수 확인 +- **인수인계 항목**: + - [ ] 보안 스캔 결과 + - [ ] 취약점 처리 현황 + - [ ] 보안 가이드라인 문서 + +--- + +## 3. 운영 인수인계 체크리스트 + +### 3.1 인프라 +- [ ] 클라우드 리소스 프로비저닝 완료 +- [ ] 네트워크 설정 및 방화벽 규칙 +- [ ] 모니터링 시스템 구성 (Prometheus, Grafana) +- [ ] 로깅 시스템 설정 (ELK Stack) +- [ ] 백업 정책 및 복구 절차 + +### 3.2 애플리케이션 +- [ ] 배포 파이프라인 가동 +- [ ] 환경별 설정 (dev/staging/prod) +- [ ] 서비스 의존성 매트릭스 +- [ ] 장애 복구(runbook) 절차 + +### 3.3 운영 +- [ ]=on-call 로테이션 일정 +- [ ] 인시던트 관리 프로세스 +- [ ] 정기 점검 체크리스트 +- [ ] 성능 벤치마크 기준선 + +--- + +## 4. 주요 연락처 + +| 역할 | 담당자 | 연락처 | 비고 | +|------|--------|--------|------| +| 프로젝트 총괄 | PM Lead | pm-lead@example.com | 1차 에스컬레이션 | +| 기술 리드 | Tech Lead | tech-lead@example.com | 아키텍처/구현 | +| 품질 담당 | QA Lead | qa-lead@example.com | 테스트/릴리스 | +| 보안 담당 | Sec Lead | sec-lead@example.com | 보안 이슈 | + +--- + +## 5. 다음 단계 + +1. **인수인계 미팅**: 모든 이해관계자 참여, 1시간 예정 +2. **문서 리뷰**: 3일 내 피드백 수집 +3. **QA 서명**: 모든 역할별 완료 기준 서명 확인 +4. **운영 전환**: 공식 운영 시작일 공지 + +--- + +**문서 종료** diff --git a/docs/adr/ADR-001-controller-service-repository-boundaries.md b/docs/adr/ADR-001-controller-service-repository-boundaries.md new file mode 100644 index 0000000..af42692 --- /dev/null +++ b/docs/adr/ADR-001-controller-service-repository-boundaries.md @@ -0,0 +1,131 @@ +# ADR-001: Controller-Service-Repository 경계 정의 + +## Context + +본 프로젝트(runtime-role-smoke-202607140500)는 Spring Boot 기반의 역할 관리 시스템이다. +다층 아키텍처에서 각 계층의 책임과 의존성 방향을 명확히 정의하여: +- 코드 유지보수성 향상 +- 단위 테스트 용이성 확보 +- 계층 간 결합도 최소화 + +를 목적으로 한다. + +## Decision + +### 1. Controller 계층 + +**책임:** +- HTTP 요청/응답 처리 +- 입력 검증(Validation) 수행 +- Service 계층 호출 및 결과 매핑 +- 예외를 HTTP 응답으로 변환 + +**금지 사항:** +- 비즈니스 로직 직접 구현 금지 +- Repository 직접 호출 금지 +- @Transactional 선언 금지 + +**구현 규칙:** +```java +@RestController +@RequiredArgsConstructor +public class RoleController { + private final RoleService roleService; + + @PostMapping("/roles") + public ResponseEntity createRole(@Valid @RequestBody RoleRequest request) { + return ResponseEntity.status(HttpStatus.CREATED) + .body(roleService.createRole(request)); + } +} +``` + +### 2. Service 계층 + +**책임:** +- 비즈니스 로직 수행 +- 트랜잭션 관리 +- 도메인 객체 조작 +- Repository 호출 및 결과 가공 + +**금지 사항:** +- HTTP 요청/응답 직접 처리 금지 +- @RequestBody, @RequestParam 등 HTTP 어노테이션 사용 금지 + +**구현 규칙:** +```java +@Service +@RequiredArgsConstructor +@Transactional(readOnly = true) +public class RoleService { + private final RoleRepository roleRepository; + + @Transactional + public RoleResponse createRole(RoleRequest request) { + // 비즈니스 로직 + Role role = Role.create(request.getName(), request.getDescription()); + Role savedRole = roleRepository.save(role); + return RoleResponse.from(savedRole); + } +} +``` + +### 3. Repository 계층 + +**책임:** +- 데이터베이스 접근 +- CRUD 연산 수행 +- 쿼리 메서드 정의 + +**금지 사항:** +- 비즈니스 로직 포함 금지 +- Service 계층 직접 호출 금지 + +**구현 규칙:** +```java +@Repository +public interface RoleRepository extends JpaRepository { + Optional findByName(String name); + boolean existsByName(String name); +} +``` + +### 4. 의존성 방향 + +``` +Controller → Service → Repository → Domain/Entity + ↑ + (Domain Event를 통한 역방향 허용) +``` + +**의존성 규칙:** +- 상위 계층은 하위 계층에만 의존 +- 동일 계층 간 직접 의존 금지 +- Domain 객체는 어떤 계층에도 의존하지 않음 + +## Alternatives + +### 대안 1: Transactional Script 패턴 +- 모든 로직을 Controller에 포함 +- 단점: 테스트 어려움, 코드 중복 +- 채택하지 않음 + +### 대안 2: 도메인 주도 설계(DDD) +- Aggregate, Entity, Value Object 세분화 +- 단점: 과도한 복잡성, 학습 곡선 높음 +- 현재 프로젝트 규모에 과도하여 채택하지 않음 + +## Consequences + +**Positive:** +- 각 계층의 책임이 명확하여 코드 가독성 향상 +- 단위 테스트 시 Mock 객체 사용 용이 +- 향후 MSA 전환 시 서비스 분리 용이 + +**Negative:** +- 간단한 CRUD 연산에도 다중 계층 코드 작성 필요 +-初期開発時に多少のオーバーヘッド + +**Mitigation:** +- Lombok, MapStruct 활용으로 보일러플레이트 감소 +- 공통 응답/예외 처리基础设施建设 diff --git a/docs/adr/ADR-002-error-contract.md b/docs/adr/ADR-002-error-contract.md new file mode 100644 index 0000000..7f5a43e --- /dev/null +++ b/docs/adr/ADR-002-error-contract.md @@ -0,0 +1,132 @@ +# ADR-002: 오류 계약(Error Contract) 정의 + +## Context + +REST API에서 일관된 오류 응답 형식을 제공하여: +- 클라이언트가 오류를 명확히 이해 가능 +- API 버전 간 호환성 유지 +- 디버깅 및 모니터링 용이성 확보 + +를 목적으로 한다. + +## Decision + +### 1. 오류 응답 표준 형식 + +```json +{ + "timestamp": "2026-07-14T05:00:00Z", + "status": 400, + "error": "Bad Request", + "code": "ROLE_001", + "message": "역할 이름은 필수입니다", + "path": "/api/v1/roles", + "details": [ + { + "field": "name", + "rejectedValue": "", + "message": "must not be blank" + } + ] +} +``` + +### 2. 오류 코드 체계 + +| Prefix | 범위 | 설명 | +|--------|------|------| +| `ROLE_` | 001-099 | 역할 관련 오류 | +| `AUTH_` | 100-199 | 인증/인가 오류 | +| `VAL_` | 900-949 | 검증 오류 | +| `SYS_` | 950-999 | 시스템 오류 | + +### 3. HTTP 상태 코드 매핑 + +| 상태 코드 | 사용 시점 | +|----------|----------| +| 400 Bad Request | 입력 검증 실패 | +| 401 Unauthorized | 인증 실패 | +| 403 Forbidden | 권한 없음 | +| 404 Not Found | 리소스 존재하지 않음 | +| 409 Conflict | 리소스 충돌 (중복 등) | +| 500 Internal Server Error | 예상치 못한 서버 오류 | + +### 4. 예외 클래스 계층 구조 + +``` +BaseException (abstract) +├── BusinessException +│ ├── RoleNotFoundException (ROLE_001) +│ ├── RoleAlreadyExistsException (ROLE_002) +│ └── UnauthorizedAccessException (AUTH_001) +├── ValidationException (VAL_001) +└── SystemException (SYS_001) +``` + +### 5. 구현 클래스 + +```java +// BaseException.java +public abstract class BaseException extends RuntimeException { + private final String errorCode; + private final HttpStatus httpStatus; + + protected BaseException(String errorCode, HttpStatus httpStatus, String message) { + super(message); + this.errorCode = errorCode; + this.httpStatus = httpStatus; + } +} + +// ErrorResponse.java +public record ErrorResponse( + Instant timestamp, + int status, + String error, + String code, + String message, + String path, + List details +) { + public record FieldError(String field, Object rejectedValue, String message) {} +} + +// GlobalExceptionHandler.java +@RestControllerAdvice +public class GlobalExceptionHandler { + + @ExceptionHandler(BusinessException.class) + public ResponseEntity handleBusinessException(BusinessException ex, HttpServletRequest request) { + ErrorResponse response = ErrorResponse.of(ex, request.getRequestURI()); + return ResponseEntity.status(ex.getHttpStatus()).body(response); + } + + @ExceptionHandler(MethodArgumentNotValidException.class) + public ResponseEntity handleValidationException(MethodArgumentNotValidException ex, HttpServletRequest request) { + ErrorResponse response = ErrorResponse.ofValidation(ex, request.getRequestURI()); + return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(response); + } +} +``` + +## Alternatives + +### 대안 1: RFC 7807 Problem Details +- `application/problem+json` Content-Type 사용 +- 단점: 클라이언트 라이브러리 지원 제한적 +- 채택하지 않음 (일반 JSON 응답 채택) + +### 대안 2: 단순 오류 메시지만 반환 +- 단점: 오류 코드 부재로 클라이언트 처리 어려움 +- 채택하지 않음 + +## Consequences + +**Positive:** +- 일관된 API 응답으로 클라이언트 개발 편의성 향상 +- 오류 코드 기반 로컬라이제이션 가능 +- 모니터링 시스템 연동 용이 + +**Negative:** +- 오류 응답 클래스 추가 작성 필요 +- 기존 예외 처리 코드 마이그레이션 필요 diff --git a/docs/adr/ADR-003-transaction-boundary.md b/docs/adr/ADR-003-transaction-boundary.md new file mode 100644 index 0000000..ef40a37 --- /dev/null +++ b/docs/adr/ADR-003-transaction-boundary.md @@ -0,0 +1,119 @@ +# ADR-003: 트랜잭션 경계(Transaction Boundary) 정의 + +## Context + +Spring에서 트랜잭션 경계 설정 방식에 따라: +- 데이터 무결성 보장 +- 성능 최적화 +- 격리 수준(Isolation Level) 제어 + +를 적절히 balancing해야 한다. + +## Decision + +### 1. 트랜잭션 전파 정책 + +| 전파 유형 | 사용 시점 | +|----------|----------| +| `REQUIRED` (기본값) | 대부분의 Service 메서드 | +| `REQUIRES_NEW` | 독립적인 작업 단위 (로깅, 알림) | +| `NESTED` | 저장점(savepoint) 기반 부분 롤백 | +| `SUPPORTS` | 읽기 전용 조회 (트랜잭션 없으면 자동 읽기 전용) | + +### 2. 격리 수준(Isolation Level) + +```java +@Transactional(isolation = Isolation.READ_COMMITTED) +``` + +| 격리 수준 | 더티 리드 | 반복 불가능 읽기 | 팬텀 읽기 | +|----------|----------|-----------------|----------| +| READ_UNCOMMITTED | 가능 | 가능 | 가능 | +| READ_COMMITTED | 불가 | 가능 | 가능 | +| REPEATABLE_READ | 불가 | 불가 | 가능 | +| SERIALIZABLE | 불가 | 불가 | 불가 | + +**결정:** `READ_COMMITTED`를 기본값으로 사용 +- 대부분의 비즈니스 시나리오에 적합 +- 동시성 성능과 일관성의 균형 + +### 3. 읽기 전용 트랜잭션 + +```java +@Transactional(readOnly = true) +public List getAllRoles() { + return roleRepository.findAll(); +} +``` + +**적용 규칙:** +- 데이터 조회 전용 Service 메서드에 적용 +- JPA: Hibernate flush mode를 MANUAL로 설정하여 최적화 +- JDBC: 읽기 전용 커넥션 힌트 제공 + +### 4. 트랜잭션 경계 위치 + +``` +[Controller] + ↓ +[Service Layer] ← ★ 트랜잭션 경계 + ↓ +[Repository Layer] + ↓ +[Database] +``` + +**규칙:** +- 트랜잭션은 Service 계층에서 시작 +- Controller에서 @Transactional 사용 금지 +- Repository에서 @Transactional 사용 금지 + +### 5. 롤백 정책 + +```java +@Transactional(rollbackFor = Exception.class) +public void createRole(RoleRequest request) { + // unchecked exception (RuntimeException): 자동 롤백 + // checked exception: rollbackFor 명시 필요 시 사용 +} +``` + +**결정:** +- 기본값(RuntimeException 및 하위 클래스 자동 롤백) 유지 +- 비즈니스 예외는 모두 RuntimeException 상속 + +### 6. 트랜잭션 타임아웃 + +```java +@Transactional(timeout = 30) // 30초 +``` + +**적용 규칙:** +- 대량 데이터 처리 배치 작업에만 명시적 타임아웃 설정 +- 일반 API 요청은 기본값(INFINITE) 유지 + +## Alternatives + +### 대안 1: Programmatic Transaction +- TransactionTemplate 사용 +- 단점: 코드 복잡성 증가, AOP 이점 상실 +- 채택하지 않음 (선언적 트랜잭션 채택) + +### 대안 2: Controller 레벨 트랜잭션 +- 단점: HTTP 요청 단위로 전체 트랜잭션 시야 과도 +- 채택하지 않음 + +## Consequences + +**Positive:** +- Service 메서드 단위로 명확한 트랜잭션 경계 +- 격리 수준 및 전파 정책 세밀한 제어 가능 +- 읽기 전용 최적화 활용 가능 + +**Negative:** +- 잘못된 전파 설정 시 예상 외 동작 가능 +- 다중 데이터소스 환경에서 복잡성 증가 + +**Mitigation:** +- 전파 정책 사용 시 주석으로 의도 명시 +- Integration Test에서 트랜잭션 동작 검증 diff --git a/docs/adr/README.md b/docs/adr/README.md new file mode 100644 index 0000000..6a67737 --- /dev/null +++ b/docs/adr/README.md @@ -0,0 +1,35 @@ +# Architecture Decision Records + +본 디렉토리는 프로젝트의 주요 아키텍처 결정 사항을 문서화합니다. + +## ADR 목록 + +| ADR 번호 | 제목 | 상태 | 날짜 | +|----------|------|------|------| +| ADR-001 | Controller-Service-Repository 경계 정의 | 수락됨 | 2026-07-14 | +| ADR-002 | 오류 계약(Error Contract) 정의 | 수락됨 | 2026-07-14 | +| ADR-003 | 트랜잭션 경계(Transaction Boundary) 정의 | 수락됨 | 2026-07-14 | + +## ADR 템플릿 + +```markdown +# ADR-XXX: 제목 + +## Context +문제의 배경과 동기 + +## Decision +採择한 결정과 그 이유 + +## Alternatives +検討했지만 채택하지 않은 대안들 + +## Consequences +결정의 결과 (positive, negative, mitigation) +``` + +## 가이드라인 + +1. **새 ADR 생성 시:** `ADR-XXX` 형식으로 파일명 지정 +2. **상태 변경:** 수락됨(Accepted), 대체됨(Superseded), 폐기됨(Deprecated) +3. **검토 주기:** 분기별 기존 ADR 검토 및 업데이트