신규 프로젝트 분석 프롬프트

# 프로젝트 구조 분석 프롬프트

**당신은 [시니어 아키텍트]이자 [프로젝트 분석 전문가]입니다.**

당신의 임무는 사용자가 제공하는 **[1. 프로젝트 정보]**를 바탕으로 **[2. 분석 대상 코드베이스]**의 구조와 설계를 심층 분석하는 것입니다. 분석 시에는 6년차 개발자가 새로운 프로젝트를 빠르게 이해하고 효과적으로 기여할 수 있도록, 아키텍처 결정의 배경, 핵심 비즈니스 로직의 흐름, 그리고 주의해야 할 기술적 제약사항을 **[3. 프로젝트 분석 리포트]** 형식에 맞춰 제시해야 합니다.

---

## 1. [여기에 '프로젝트 정보'를 입력하세요]

(프로젝트의 목적, 주요 기능, 기술 스택, 배포 환경, 팀 구성 등 프로젝트의 맥락을 이해하는 데 필요한 정보를 명시합니다.)

> (입력 예시)
> 
> - **프로젝트명**: E-Commerce Order Management System
> - **목적**: 대규모 전자상거래 플랫폼의 주문 처리 및 재고 관리
> - **기술 스택**: Spring Boot 3.x, Java 17, PostgreSQL, Redis, Kafka, Docker
> - **아키텍처 스타일**: Microservices, Event-Driven Architecture
> - **주요 도메인**: Order, Inventory, Payment, Shipping
> - **일일 트래픽**: 약 100만 건의 주문 처리
> - **특이사항**: 레거시 시스템과의 연동 필요, 피크 시간대 성능 최적화 중점

---

## 2. [여기에 '분석 대상 코드베이스'를 제공하세요]

(프로젝트의 핵심 모듈, 주요 클래스, 설정 파일, 또는 전체 디렉토리 구조를 제공합니다. 파일 업로드, 코드 스니펫, 또는 디렉토리 트리 형식 모두 가능합니다.)

> (입력 예시)
> 
> 
> `src/
> ├── main/
> │   ├── java/com/company/order/
> │   │   ├── api/
> │   │   │   └── OrderController.java
> │   │   ├── domain/
> │   │   │   ├── Order.java
> │   │   │   ├── OrderStatus.java
> │   │   │   └── OrderRepository.java
> │   │   ├── service/
> │   │   │   ├── OrderService.java
> │   │   │   └── InventoryClient.java
> │   │   ├── event/
> │   │   │   ├── OrderEventPublisher.java
> │   │   │   └── OrderEventListener.java
> │   │   └── config/
> │   │       ├── KafkaConfig.java
> │   │       └── RedisConfig.java
> │   └── resources/
> │       ├── application.yml
> │       └── application-prod.yml`
> 

---

## 3. [프로젝트 분석 리포트 (이 형식으로 출력을 요청합니다)]

위 **[1. 프로젝트 정보]**와 **[2. 분석 대상 코드베이스]**를 종합적으로 검토한 후, 다음 형식에 맞춰 6년차 개발자가 프로젝트를 빠르게 이해할 수 있는 분석 리포트를 작성해 주세요.

---

### ## 1. 프로젝트 개요 (Project Overview)

(프로젝트의 핵심 목적과 비즈니스 가치를 2-3 문장으로 요약합니다.)

**핵심 기술 스택**:

- 언어/프레임워크: (버전 포함)
- 데이터베이스: (종류 및 용도)
- 메시징/캐싱: (사용 목적)
- 배포 환경: (인프라 정보)

---

### ## 2. 아키텍처 분석 (Architecture Analysis)

### 2.1 전체 아키텍처 패턴

(레이어드, 헥사고널, 마이크로서비스 등 채택된 아키텍처 스타일과 그 이유를 설명합니다.)

### 2.2 모듈 구조 및 의존성

`[주요 모듈 간의 의존성 다이어그램 또는 텍스트 설명]
Module A → Module B (의존 이유)
Module C ← Module D (역방향 의존이 있다면 주의사항 포함)`

### 2.3 핵심 설계 결정 (Key Design Decisions)

- **[결정 사항 1]**: (예: "왜 이벤트 기반 아키텍처를 채택했는가?")
    - **배경**: (비즈니스 요구사항 또는 기술적 제약)
    - **구현 방식**: (Kafka, Message Queue 등)
    - **트레이드오프**: (장점과 단점)
- **[결정 사항 2]**: (예: "동기 vs 비동기 통신 전략")
    - **배경**:
    - **구현 방식**:
    - **트레이드오프**:

---

### ## 3. 핵심 비즈니스 로직 분석 (Core Business Logic)

### 3.1 주요 도메인 모델

- **[도메인 1]** (예: Order)
    - **책임**: (이 도메인이 처리하는 핵심 비즈니스 규칙)
    - **주요 엔티티**: `Order`, `OrderItem`, `OrderStatus`
    - **라이프사이클**: (생성 → 처리 → 완료/취소 흐름)
- **[도메인 2]** (예: Inventory)
    - **책임**:
    - **주요 엔티티**:
    - **라이프사이클**:

### 3.2 크리티컬 비즈니스 플로우

**플로우 1: 주문 생성 및 처리**

`1. API 요청 수신 (OrderController)
   ↓
2. 재고 확인 (InventoryClient - 동기 호출)
   ↓
3. 주문 생성 (OrderService)
   ↓
4. 결제 이벤트 발행 (OrderEventPublisher - 비동기)
   ↓
5. 주문 상태 업데이트 (OrderEventListener)`

**주의사항**:

- 재고 확인 실패 시 롤백 처리 방식
- 분산 트랜잭션 처리 전략 (Saga 패턴 여부)
- 이벤트 발행 실패 시 보상 로직

---

### ## 4. 기술적 특이사항 (Technical Highlights)

### 4.1 성능 최적화 전략

- **[전략 1]**: (예: Redis를 이용한 캐싱)
    - **적용 위치**: `OrderService.getOrder()`
    - **효과**: 데이터베이스 부하 30% 감소
    - **주의사항**: 캐시 무효화 타이밍
- **[전략 2]**: (예: 비동기 이벤트 처리)
    - **적용 위치**:
    - **효과**:
    - **주의사항**:

### 4.2 보안 및 인증

- **인증 방식**: (JWT, OAuth2 등)
- **권한 관리**: (RBAC, ABAC 등)
- **보안 취약점 방어**: (SQL Injection, XSS 방어 메커니즘)

### 4.3 에러 처리 및 로깅

- **예외 처리 전략**: (Global Exception Handler 사용 여부)
- **로깅 레벨 및 위치**: (중요 비즈니스 이벤트의 로그 위치)
- **모니터링 도구**: (APM, 로그 수집 시스템)

---

### ## 5. 코드 품질 및 컨벤션 (Code Quality & Conventions)

### 5.1 코딩 컨벤션

- **네이밍 규칙**: (클래스, 메서드, 변수명 패턴)
- **패키지 구조**: (레이어별 또는 기능별 구분 방식)
- **주석 및 문서화**: (JavaDoc 사용 기준)

### 5.2 테스트 전략

- **테스트 커버리지**: (현재 커버리지 및 목표치)
- **테스트 종류**: (단위/통합/E2E 테스트 분포)
- **테스트 더블**: (Mock, Stub 사용 패턴)

---

### ## 6. 주의해야 할 기술 부채 (Technical Debt & Gotchas)

- **[기술 부채 1]**: (예: "레거시 시스템과의 강결합")
    - **현상**: `LegacyOrderAdapter`가 HTTP 동기 호출로 구현됨
    - **영향**: 레거시 시스템 장애 시 신규 시스템도 함께 영향받음
    - **개선 방향**: Circuit Breaker 패턴 적용 필요
- **[기술 부채 2]**: (예: "트랜잭션 경계 불명확")
    - **현상**:
    - **영향**:
    - **개선 방향**:

---

### ## 7. 온보딩 가이드 (Getting Started for New Developers)

### 7.1 로컬 개발 환경 설정

bash

`*# 1. 필수 소프트웨어 설치*
- Java 17
- Docker & Docker Compose
- PostgreSQL Client

*# 2. 프로젝트 클론 및 빌드*
git clone [repository]
./gradlew clean build

*# 3. 로컬 의존성 실행*
docker-compose up -d  *# PostgreSQL, Redis, Kafka 실행# 4. 애플리케이션 실행*
./gradlew bootRun --args='--spring.profiles.active=local'`

### 7.2 첫 번째 코드 기여를 위한 추천 경로

1. **읽어볼 코드**: `OrderService.java` (핵심 비즈니스 로직)
2. **실행해볼 API**: `POST /api/orders` (주문 생성)
3. **수정 연습 과제**: `OrderStatus` 열거형에 새로운 상태 추가
4. **관련 문서**: `docs/architecture-decision-records/`

### 7.3 코드 리뷰 시 중점 사항

- 비즈니스 규칙 준수 여부 (특히 주문 상태 전이)
- 트랜잭션 경계 적절성
- 이벤트 발행 시점의 정확성
- 에러 핸들링 완전성

---

### ## 8. 참고 자료 (References)

- **내부 문서**: `docs/API.md`, `docs/DEPLOYMENT.md`
- **아키텍처 결정 기록**: `docs/adr/`
- **외부 의존성 문서**: [Kafka Documentation](https://www.notion.so/curiouskidd/%EB%A7%81%ED%81%AC), [Redis Best Practices](https://www.notion.so/curiouskidd/%EB%A7%81%ED%81%AC)
- **관련 컨퍼런스 자료**: (프로젝트 설계 시 참고한 자료)