AI주도개발 통합시스템 v3.2.0 with Cursor Rules & Commands
현재 버전
Version
- v3.2.0
- 릴리스일: 2025-09-16
- 주요 변경: 인지과학 기반 최적화를 통한 논리 플로우 재구성
3_solution_design_evaluation/
01-detailed-solution-design.md
경로 : .cursor/commands/3_solution_design_evaluation/01-detailed-solution-design.md
# 상세 솔루션 설계
## 목적
2단계(Phase 2)에서 수립된 **개요 설계**를 기반으로, 실제 구현이 가능한 수준까지 **기술·기능적 세부 설계**를 완성한다.
## 전제 조건
- 솔루션 개요 설계가 완료되어 있음
- Make/Buy 판단 결과 및 근거가 명확히 정의되어 있음
- 기술 및 비즈니스 요구사항이 구체적으로 명세되어 있음
- 구현 조직과 개발 일정의 기본 구조가 확정되어 있음
## 상세 설계 접근 방식
### Make 선택 시 상세 설계
#### 1. 상세 기술 아키텍처 설계
##### 시스템 아키텍처 상세
```markdown
## 마이크로서비스 구성
### API Gateway
- **사용 제품**: AWS API Gateway / Kong / Nginx
- **주요 기능**: 인증·인가, 요청 제한(Rate Limiting), 로깅
- **설정 항목**: JWT 검증, CORS 허용, SSL 종단 처리
### 서비스 분리 구조
```mermaid
graph TB
A[API Gateway] --> B[User Service]
A --> C[Data Service]
A --> D[Report Service]
A --> E[Notification Service]
B --> F[(User DB)]
C --> G[(Data DB)]
D --> H[(Analytics DB)]
E --> I[Message Queue]
```
##### 데이터베이스 상세 설계
```sql
-- 사용자 관리 테이블
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email VARCHAR(255) UNIQUE NOT NULL,
password_hash VARCHAR(255) NOT NULL,
role VARCHAR(50) NOT NULL,
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
-- 데이터 관리 테이블
CREATE TABLE data_records (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES users(id),
data_type VARCHAR(100) NOT NULL,
data_content JSONB NOT NULL,
processed_at TIMESTAMP,
created_at TIMESTAMP DEFAULT NOW()
);
-- 인덱스 설계
CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_data_records_user_id ON data_records(user_id);
CREATE INDEX idx_data_records_type ON data_records(data_type);
```
##### API 상세 설계
```yaml
# OpenAPI 3.0 명세서
openapi: 3.0.0
info:
title: Solution API
version: 1.0.0
paths:
/api/v1/users:
post:
summary: 사용자 생성
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
email:
type: string
format: email
password:
type: string
minLength: 8
role:
type: string
enum: [admin, user, viewer]
responses:
201:
description: 사용자 생성 성공
content:
application/json:
schema:
type: object
properties:
id:
type: string
email:
type: string
role:
type: string
```
#### 2. 상세 기능 설계
##### 프론트엔드 상세 설계
```typescript
// React + TypeScript구성
// src/components/UserManagement.tsx
interface User {
id: string;
email: string;
role: 'admin' | 'user' | 'viewer';
createdAt: Date;
}
interface UserManagementProps {
users: User[];
onUserCreate: (user: Omit) => Promise;
onUserUpdate: (id: string, user: Partial) => Promise;
onUserDelete: (id: string) => Promise;
}
const UserManagement: React.FC = ({
users,
onUserCreate,
onUserUpdate,
onUserDelete
}) => {
// 컴포넌트 구현
};
```
##### 백엔드 상세 설계
```python
# FastAPI + Python구조
# src/api/users.py
from fastapi import APIRouter, Depends, HTTPException
from sqlalchemy.orm import Session
from typing import List
import schemas, crud, models
from database import get_db
from auth import get_current_user
router = APIRouter(prefix="/api/v1/users", tags=["users"])
@router.post("/", response_model=schemas.User)
async def create_user(
user: schemas.UserCreate,
db: Session = Depends(get_db),
current_user: models.User = Depends(get_current_user)
):
if current_user.role != "admin":
raise HTTPException(status_code=403, detail="Permission denied")
db_user = crud.get_user_by_email(db, email=user.email)
if db_user:
raise HTTPException(status_code=400, detail="Email already registered")
return crud.create_user(db=db, user=user)
```
#### 3. 인프라 및 배포 상세 설계
##### Docker구성
```dockerfile
# Dockerfile.backend
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
```
##### Kubernetes구성
```yaml
# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: backend-deployment
spec:
replicas: 3
selector:
matchLabels:
app: backend
template:
metadata:
labels:
app: backend
spec:
containers:
- name: backend
image: solution-backend:latest
ports:
- containerPort: 8000
env:
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: db-secret
key: url
```
##### CI/CD Pipeline
```yaml
# .github/workflows/deploy.yml
name: Deploy to Production
on:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run tests
run: |
npm test
python -m pytest
build:
needs: test
runs-on: ubuntu-latest
steps:
- name: Build Docker images
run: |
docker build -t solution-frontend:${{ github.sha }} ./frontend
docker build -t solution-backend:${{ github.sha }} ./backend
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- name: Deploy to Kubernetes
run: |
kubectl set image deployment/backend-deployment backend=solution-backend:${{ github.sha }}
kubectl rollout status deployment/backend-deployment
```
### Buy 선택 시 상세 설계
#### 1. 선정 제품의 상세 평가 및 계약
##### 최종 제품 선정
```markdown
## 선정 결과
- **제품명**: Salesforce Platform + Custom Apps
- **라이선스 유형**: Enterprise Edition
- **계약 기간**: 3년 (연간 할인 적용)
- **지원 플랜**: Premier Success Plan
## 선정 사유 상세
- **기능 적합도**: 90% (필수 요구사항 전부 충족)
- **커스터마이징성**: Apex 및 Lightning Platform 활용 가능
- **확장성**: AppExchange 및 API 연동 기능 풍부
- **도입 실적**: 동일 산업군에서 다수의 성공 사례 보유
- **지원 품질**: 24/7 지원, 전담 CSM 배정
```
##### 계약 조건 상세
```markdown
## 라이선스 및 비용 구조
- **사용자 라이선스**: 100명 × 월 15,000원
- **데이터 저장소**: 1TB (추가 1GB당 월 200원)
- **API 호출 한도**: 월 100만 건 (추가 1만 건당 500원)
- **커스텀 앱**: 최대 5개 무료 제공
## SLA 및 지원 정책
- **가용성 보장**: 99.9% 업타임 보증
- **지원 체계**: 연중무휴 24시간 (한국어 지원 포함)
- **응답 시간**: 중요도 1 = 2시간 이내 대응
- **전담 CSM**: 분기별 운영 리뷰 및 최적화 제안 제공
```
#### 2. 커스터마이징 및 연동 상세 설계
##### 커스텀 오브젝트 설계
```apex
// Salesforce Apex
// 커스텀 오브젝트: Project__c
public class ProjectController {
@AuraEnabled(cacheable=true)
public static List getProjects(String status) {
return [
SELECT Id, Name, Status__c, Start_Date__c, End_Date__c,
Budget__c, Owner.Name
FROM Project__c
WHERE Status__c = :status
ORDER BY Start_Date__c DESC
];
}
@AuraEnabled
public static void updateProjectStatus(String projectId, String newStatus) {
Project__c project = [SELECT Id FROM Project__c WHERE Id = :projectId];
project.Status__c = newStatus;
update project;
}
}
```
##### 시스템 연동 설계
```javascript
// 외부 시스템 연동 (REST API)
// integration/erpConnector.js
const ERPConnector = {
async syncCustomerData() {
const response = await fetch('/services/apexrest/erp/customers', {
method: 'POST',
headers: {
'Authorization': 'Bearer ' + this.getAccessToken(),
'Content-Type': 'application/json'
},
body: JSON.stringify({
syncType: 'incremental',
lastSyncDate: this.getLastSyncDate()
})
});
return await response.json();
},
async pushOrderData(orderData) {
// ERP 시스템으로 주문 데이터 전송
}
};
```
#### 3. 데이터 이전 및 도입 계획 상세
##### 데이터 이전 계획
```markdown
## 이전 대상 데이터
### 고객 데이터 (10만 건)
- **소스**: 기존 CRM (CSV 출력)
- **변환**: 중복 제거 및 데이터 정제
- **검증**: 이전 전후의 데이터 건수 및 일관성 확인
### 영업(거래) 데이터 (5만 건)
- **소스**: Excel · SFA (API 연동)
- **변환**: 단계 매핑, 금액 단위 정규화
- **검증**: 매출 금액 및 신뢰도 일관성 확인
## 이전 일정
### Phase 1: 테스트 이전 (1주)
- 샘플 데이터 1,000건으로 이전 테스트
- 변환 로직 및 유효성 검증
- 성능 및 품질 문제 식별
### Phase 2: 단계적 이전 (2주)
- 주말 배치로 부서별 순차 이전
- 이전 후 검증 및 수정 대응
- 사용자 수용 테스트(UAT)
### Phase 3: 전체 이전 (1주)
- 전체 데이터 이전 및 최종 검증
- 본격 운영 시작 및 모니터링 체계 구축
```
### Hybrid 선택 시 상세 설계
#### 1. 통합 아키텍처 상세
##### 시스템 통합 설계
```mermaid
graph TB
A[프론트엔드 통합 UI] --> B[API Gateway]
B --> C[SaaS API]
B --> D[자체 개발 API]
C --> E[SaaS 데이터베이스]
D --> F[자체 데이터베이스]
G[데이터 동기화 서비스] --> E
G --> F
H[SSO 인증] --> A
H --> C
H --> D
```
##### 데이터 동기화 설계
```python
# 데이터 동기화 서비스
# sync/data_synchronizer.py
class DataSynchronizer:
def __init__(self, saas_client, custom_db):
self.saas_client = saas_client
self.custom_db = custom_db
async def sync_customers(self):
# SaaS에서 고객 데이터 가져오기
saas_customers = await self.saas_client.get_customers()
for customer in saas_customers:
# 자체 DB의 확장 데이터와 통합
custom_data = await self.custom_db.get_customer_extension(customer.id)
# 통합 데이터 생성
integrated_customer = {
**customer.dict(),
'custom_analytics': custom_data.analytics,
'custom_scores': custom_data.scores
}
# 통합 데이터베이스에 저장
await self.custom_db.upsert_customer(integrated_customer)
```
## 상세 설계 산출물
### 1. 기술 설계서
- **시스템 아키텍처 다이어그램**: 상세 구조 및 기술 스택
- **데이터베이스 설계서**: ERD, 테이블 정의서, 인덱스 설계
- **API 설계서**: OpenAPI 명세 및 엔드포인트 상세
- **보안 설계서**: 인증·인가·암호화 방식
### 2. 기능 설계서
- **화면 설계서**: 와이어프레임 및 UI/UX 정의
- **업무 흐름 설계**: 프로세스 다이어그램 및 예외 처리
- **배치 처리 설계**: 데이터 처리 및 동기화 로직
- **외부 연동 설계**: API 및 데이터 연동 정의
### 3. 구현 계획서
- **세부 개발 계획**: WBS, 일정, 리소스 계획
- **품질 관리 계획**: 테스트 계획 및 코드 리뷰 기준
- **리스크 관리 계획**: 리스크 및 대응 전략
- **운영 계획**: 모니터링 및 유지보수 체계
### 4. 도입 계획서 (Buy/Hybrid)
- **제품 도입 계획**: 환경 구축 및 설정
- **데이터 이전 계획**: 대상·절차·검증 방안
- **교육 계획**: 사용자 및 관리자 교육
- **시스템 전환 계획**: 단계별 전환 및 리스크 대응
## 다음 단계 (구현 단계) 준비
### Make 선택 시
- **개발 환경 구축**: 개발·테스트·운영 환경 구성
- **팀 구성 확정**: 개발자 배정 및 역할 정의
- **품질 기준 수립**: 코딩 가이드 및 리뷰 체계
- **프로젝트 관리 체계**: 진행 상황 및 이슈 관리
### Buy 선택 시
- **벤더 계약 완료**: 라이선스 및 지원 계약 확정
- **환경 구성**: 운영 및 테스트 환경 구축
- **도입팀 구성**: 사내·벤더 혼합팀 구성
- **이전 준비**: 데이터 및 마이그레이션 툴 준비
### Hybrid 선택 시
- **통합 환경 구성**: 개발·연동 환경 통합 구축
- **병행 개발 체계**: SaaS 도입과 자체 개발 병행 관리
- **통합 테스트 준비**: 결합·성능 테스트 환경 확보
- **운영 체계 준비**: 통합 모니터링 및 유지보수 체계
## 실행 체크리스트
### 상세 설계 준비
- [ ] 개요 설계 산출물 검토
- [ ] 상세 요구사항 확정
- [ ] 설계 기준 및 가이드라인 설정
- [ ] 설계 리뷰 체계 확립
### Make 선택 시 상세 설계
- [ ] 시스템 아키텍처 상세 설계
- [ ] 데이터베이스 상세 설계 (ERD, DDL)
- [ ] API 상세 설계 (OpenAPI 명세)
- [ ] 프론트엔드 상세 설계 (컴포넌트, 화면)
- [ ] 인프라 및 배포 설계 (Docker, K8s, CI/CD)
- [ ] 보안 상세 설계
- [ ] 성능 및 가용성 설계
- [ ] 운영·모니터링 설계
### Buy 선택 시 상세 설계
- [ ] 최종 제품 선정 및 계약 조건 확정
- [ ] 커스터마이징 상세 설계
- [ ] 시스템 연동 상세 설계
- [ ] 데이터 이전 상세 계획
- [ ] 도입 및 전개 상세 계획
- [ ] 운영 및 지원 체계 설계
### Hybrid 선택 시 상세 설계
- [ ] 통합 아키텍처 상세 설계
- [ ] 데이터 동기화 및 연동 상세 설계
- [ ] UI 통합 및 SSO 설계
- [ ] 병행 개발 및 도입 계획
- [ ] 통합 테스트 및 품질 관리 계획
- [ ] 통합 운영 및 모니터링 체계 설계
### 산출물 작성 및 승인
- [ ] 상세 설계서 작성 및 리뷰
- [ ] 구현 및 도입 계획서 작성
- [ ] 이해관계자 승인 확보
- [ ] 다음 단계 착수 준비 완료
02-impact-roi-assessment.md
경로 : .cursor/commands/3_solution_design_evaluation/02-impact-roi-assessment.md
# 임팩트·ROI 평가
## 목적
과제 해결을 통해 **구체적으로 창출되는 가치와 비용을 수치화**하여, 투자 판단의 근거를 제시한다.
## 전제 조건
- 과제의 우선순위가 확정되어 있음
- 솔루션의 개요가 정의되어 있음
- 필요한 데이터 및 지표 수집이 가능함
## 임팩트 평가 프레임워크
### 가치 창출의 분류
```markdown
## 1. 직접적 가치 (Direct Value)
### 매출 증대
- **매출 증가**: 신규 고객 확보, 기존 고객 단가 향상
- **기회 창출**: 신규 서비스·신시장 진입
- **가격 최적화**: 가격 전략 개선 및 마진 확대
### 비용 절감
- **운영비 절감**: 인건비, 시스템 운영비 절감
- **업무 효율화**: 작업 시간 단축, 자동화 효과
- **오류 감소**: 실수·재작업 비용 절감
## 2. 간접적 가치 (Indirect Value)
### 경쟁우위 확보
- **시장 포지션 강화**: 브랜드 가치·시장 점유율 상승
- **차별화**: 독자적 기술 및 서비스 경쟁력
- **고객 만족도 향상**: 충성도·추천율 증가
### 리스크 경감
- **컴플라이언스**: 법규 위반 리스크 감소
- **보안 강화**: 정보 유출·시스템 장애 예방
- **비즈니스 연속성**: 장애·재난 시 영향 최소화
## 3. 전략적 가치 (Strategic Value)
### 조직 역량 강화
- **스킬 향상**: 구성원 역량 및 조직 학습 촉진
- **프로세스 개선**: 업무 품질 및 생산성 향상
- **혁신 촉진**: 새로운 가치 창출 역량 확보
### 미래 옵션
- **확장성 확보**: 향후 사업 확대에 대응 가능
- **유연성 강화**: 시장 변화에 빠르게 적응
- **기반 구축**: 차세대 성장 단계의 준비
```
## 정량화 방법
### 매출 임팩트 산출
```markdown
## 매출 향상 효과
### 신규 고객 확보
- **현 상태**: 월 신규 고객 수 × 평균 단가 × 12개월
- **개선 후**: 개선율을 반영한 예측값
- **증가분**: 개선 후 - 현 상태
예시:
- 현 상태: 100명/월 × 100만 원 × 12 = 12억 원/년
- 개선 후: 120명/월 × 100만 원 × 12 = 14.4억 원/년
- 증가분: 2.4억 원/년
### 기존 고객 단가 향상
- **현 상태**: 기존 고객 수 × 평균 단가
- **개선 후**: 업셀·크로스셀 효과 반영
- **증가분**: 단가 상승분 × 고객 수
### 고객 유지율 개선
- **현 상태**: 이탈률 × 고객 수 × 평균 LTV
- **개선 후**: 이탈률 개선 후 손실 절감
- **효과**: 유지된 고객의 LTV 합산
```
### 비용 절감 효과 산출
```markdown
## 인건비 절감
### 작업 시간 단축
- **현 상태**: 대상 업무 총 작업 시간(연간)
- **개선 후**: 효율화 적용 후의 총 시간
- **절감 시간**: 현 상태 - 개선 후
- **금액 환산**: 절감 시간 × 시간당 단가
예시:
- 현 상태: 5명 × 8시간/일 × 250일 = 10,000시간/년
- 개선 후: 자동화로 50% 절감 → 5,000시간/년
- 절감 효과: 5,000시간 × 5,000원 = 2,500만 원/년
### 시스템 운영비 절감
- **현 상태**: 서버·라이선스·유지보수 비용
- **개선 후**: 클라우드 전환·시스템 통합 후 비용
- **절감 금액**: 현 상태 - 개선 후
### 오류 및 재작업 비용 절감
- **현 상태**: 오류 발생률 × 처리비용 × 발생빈도
- **개선 후**: 오류율 감소 적용 후 비용
- **절감 효과**: 현 상태 - 개선 후
```
### 기회손실 회피
```markdown
## 기회손실의 정량화
### 시스템 중단으로 인한 손실
- **영향 범위**: 중단 시 손실되는 매출 규모
- **중단 빈도**: 연간 중단 횟수 및 시간
- **손실 금액**: 시간당 매출 × 중단 시간 × 발생 횟수
### 경쟁사로의 고객 이탈
- **이탈 고객 수**: 경쟁사로 이동한 고객 수
- **이탈 매출**: 해당 고객의 연간 매출 규모
- **회피 효과**: 개선으로 유지 가능한 매출
### 규제 위반 리스크
- **벌금·제재금**: 예상되는 금액
- **신용 손상**: 브랜드 가치 하락
- **영업 정지**: 업무 중단에 따른 손실
```
## ROI 계산 모델
### 기본 ROI 계산
```markdown
## ROI = (이익 - 투자금) / 투자금 × 100
### 이익 계산
- **연간 이익**: 연간 창출 가치 - 연간 운영 비용
- **누적 이익**: 복수년도의 현재가치 합산
- **리스크 조정**: 실현 가능성을 고려한 기대값
### 투자금 계산
- **초기 투자**: 개발·도입·설비 투자
- **운영 투자**: 연간 운영·유지보수·인건비
- **기회비용**: 다른 투자 기회를 포기함으로써 발생하는 손실
```
### 상세 ROI 분석
```markdown
## NPV(순현재가치) 분석
### 연도별 현금흐름 예측
| 연도 | 투자금 | 편익 | 운영비용 | 순현금흐름 | 현재가치 |
|----|--------|------|------------|-------------------|----------|
| 0 | -5,000 | 0 | 0 | -5,000 | -5,000 |
| 1 | -1,000 | 3,000 | -500 | 1,500 | 1,364 |
| 2 | -500 | 4,000 | -600 | 2,900 | 2,397 |
| 3 | -500 | 4,500 | -700 | 3,300 | 2,479 |
### NPV 계산 (할인율 10%)
NPV = -5,000 + 1,364 + 2,397 + 2,479 = 1,240만 원
### IRR(내부수익률)
투자 수익률 = 약 15% (할인율 10% 초과 → 투자 가치 있음)
```
### 민감도 분석
```markdown
## 시나리오 분석
### 낙관 시나리오 (확률 30%)
- 효과: 예측치의 120%
- ROI: 25%
### 기본 시나리오 (확률 50%)
- 효과: 예측치와 동일
- ROI: 15%
### 비관 시나리오 (확률 20%)
- 효과: 예측치의 70%
- ROI: 5%
### 기대 ROI
= 25% × 0.3 + 15% × 0.5 + 5% × 0.2 = 16%
```
## 정성적 가치 평가
### 무형가치의 정량화
```markdown
## 고객 만족도 향상
### 측정 지표
- **NPS (Net Promoter Score)**: 추천 의향
- **CSAT (Customer Satisfaction)**: 전반적 만족도
- **CES (Customer Effort Score)**: 이용 편의성
### 가치 환산
- NPS 1포인트 상승 = 고객 유지율 0.5% 상승
- 고객 유지율 1% 상승 = 연 매출 X% 증가
- 실제 금액으로 환산 가능
## 임직원 만족도 및 생산성
### 측정 지표
- **직원 만족도 조사**: 몰입도·참여도
- **이직률**: 인재 유지율
- **생산성 지표**: 시간당 성과
### 가치 환산
- 이직률 1% 개선 = 채용·교육비 절감
- 생산성 1% 향상 = 매출·이익 증가로 연결
```
## 리스크 고려
### 실현 리스크 평가
```markdown
## 기술 리스크
- **신기술 불확실성**: 30% 확률로 효과 절반 수준
- **시스템 통합 복잡성**: 일정 지연 가능성
- **데이터 품질 저하**: 정확도 저하 리스크
## 조직 리스크
- **변화 저항**: 사용자 채택률 저하 위험
- **기술 역량 부족**: 운영 품질 저하 가능성
- **프로젝트 관리**: 일정·예산 초과 위험
## 시장 리스크
- **경쟁 대응**: 경쟁우위 지속 기간 단축
- **기술 변화**: 솔루션 노후화 리스크
- **규제 변경**: 추가 투자 필요 리스크
```
### 리스크 조정 후 ROI
```markdown
## 리스크 조정 계산
### 기본 ROI: 15%
### 조정 항목
- 기술 리스크: -2%
- 조직 리스크: -1%
- 시장 리스크: -1%
### 조정 후 ROI: 11%
(여전히 투자 기준 10%를 상회)
```
## 산출물
### 임팩트·ROI 평가 보고서
```markdown
# 임팩트·ROI 평가 결과
## 요약 (Executive Summary)
- **총 투자금**: X억 원 (3년 기준)
- **기대 효과**: Y억 원/년
- **ROI**: Z% (리스크 조정 후)
- **투자 회수 기간**: W년
## 가치 창출 내역
### 직접적 가치 (X억 원/년)
- 매출 향상: A억 원
- 비용 절감: B억 원
### 간접적 가치 (정성 평가)
- 경쟁 우위 확보
- 리스크 완화 효과
- 조직 역량 강화
## 투자 판단
- **권장 방안**: 투자 실행
- **근거**: ROI가 기준치를 상회하고 전략적 가치가 높음
- **조건**: 리스크 완화 대책 실행
## 다음 단계
- [ ] 투자 승인 획득
- [ ] 세부 실행 계획 수립
- [ ] 효과 측정 체계 구축
```
## 체크리스트
- [ ] 가치 창출 항목 정리 완료
- [ ] 정량화 가능한 지표 산출 완료
- [ ] ROI 계산 및 민감도 분석 완료
- [ ] 정성적 가치 평가 완료
- [ ] 리스크 평가 및 조정 완료
- [ ] 시나리오 분석 완료
- [ ] 평가 보고서 작성 완료
- [ ] 이해관계자 공유 완료
- [ ] 투자 의사결정 준비 완료
03-interactive-requirements-definition.md
경로 : .cursor/commands/3_solution_design_evaluation/03-interactive-requirements-definition.md
---
# 프롬프트 파일 정보
**파일명**: doc01-requirements.mdc
**버전**: 2.0.0
**최종 업데이트**: 2025-07-05
**변경 유형**: MAJOR
**변경 요약**: LRI 원칙 기반에서 대화형 접근 방식으로의 근본적 전환
## 버전 이력
| 버전 | 날짜 | 변경 유형 | 변경 요약 |
|------|------|------------|------------|
| 2.0.0 | 2025-07-09 | MAJOR | 소크라테스식 대화 중심으로 전환 (672행 → 308행) |
| 1.0.0 | 2025-05-23 | MAJOR | 초기버전 (LRI 원칙 기반) |
---
# 인지과학 기반 대화형 요구사항 정의 시스템 프롬프트
## 목차 (시스템 전체 개요)
```
[대화형 요구사항 정의 시스템의 전체 구조]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 1. 인지과학적 기반: 대화를 통한 단계적 이해 심화
🔍 2. 대화 설계: 소크라테스식 질문으로 인한 통찰 유도
📊 3. 단계적 요구사항 구축: 5단계 협업형 요구사항 정리
🎯 4. 이해도 점검: 각 단계별 인식 공유 및 조정
✅ 5. 지속적 개선: 대화를 통한 요구사항 정밀화
🔄 6. 최종 통합: 대화 결과의 요구사항 명세서화
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```
## 이론적 기반: 대화 중심 인지과학 접근법
### 핵심 이론 체계
- **소크라테스식 대화법**: 질문을 통한 통찰 촉진과 이해의 심화
- **구성주의 학습이론**: 사용자의 자율적 지식 구성 지원
- **분산인지이론**: AI와의 협업을 통한 외부 인지 확장
- **메타인지 지원**: 대화를 통한 사고 및 요구사항 분석 과정의 자각화
### 🚫 **절대 금지사항**
- **한 번에 요구사항 명세서를 완성하는 행위 금지**
- **직접적인 해답 제시 금지** (질문을 통한 인식 유도만 허용)
- **AI가 요구사항을 결정하는 행위 금지** (사용자의 판단이 최우선)
- **대화 과정을 생략하고 결론으로 바로 이동하는 행위 금지**
### 필수 초기화 프로세스
#### 1. 현재 시각 및 날짜 인식
**시작 시 반드시 `date` 명령어를 실행하여 현재 시각과 날짜를 인식해야 함.**
#### 2. 대화형 요구사항 분석 전체 구조도 제시
**요구사항 분석을 시작하기 전, 반드시 다음의 전체 구조를 시각적으로 제시해야 함:**
```
[대화형 요구사항 분석의 전체 구조]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 현재 위치: 대화 시작 - 배경 이해 단계
🎯 대화 목표: 단계적 이해 심화를 통한 진짜 니즈 발견
🗺️ 대화 경로: 배경 이해 → 문제 심층 탐색 → 대안 검토 → 요구사항 구성 → 문서화
⏰ 진행 계획: 각 단계별로 충분한 대화 시간을 확보
📋 [대화 완료 판단 체크리스트]
사용자 스스로 판단하는 이해도 지표:
□ 요구사항1: 배경과 문제의 본질을 스스로 언어로 표현할 수 있다
□ 요구사항2: 여러 해결 방안을 비교·검토할 수 있다
□ 요구사항3: 기술적 제약과 현실적 구현 방법을 이해하고 있다
□ 요구사항4: 우선순위와 단계별 실행 계획을 스스로 결정할 수 있다
🎯 [대화 지속 여부 확인]
각 단계마다 “조금 더 깊이 이야기하고 싶은 부분이 있나요?”를 확인
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```
#### 3. 대화 주도형 요구사항 구축 선언
**중요: 이 시스템은 대화를 통해 사용자의 사고와 이해를 깊게 하는 것을 목적으로 한다.**
**요구사항 명세서는 대화의 마지막 단계에서만 작성된다.**
## 시스템의 목적 및 개요
이 시스템은 **인지과학 기반의 대화 중심 접근법**을 활용해 사용자와 AI가 협업을 통해 단계적으로 요구사항을 정의해 나가는 시스템이다.
기존처럼 “요구사항을 묻고 즉시 문서화하는 방식”이 아니라, **소크라테스식 대화법**을 통해 사용자가 스스로 문제의 본질과 진짜 필요를 인식하도록 돕는다.
### 대화의 기본 원칙
#### 🎯 대화의 목표
1. **이해의 심화**: 표면적인 요구에서 본질적인 니즈로 이동
2. **통찰의 촉진**: 사용자가 인식하지 못한 문제나 기회를 발견
3. **대안의 확장**: 기존 틀을 넘어 창의적인 해결책 탐색
4. **주체성의 유지**: 사용자가 스스로 판단하고 결정
#### 💬 대화의 방식
- **질문 중심**: 답을 제시하지 않고, 사고를 자극하는 질문
- **단계적 심층화**: 한 번에 많은 것을 묻지 않고, 한 가지씩 깊게
- **인식 확인**: 이해한 내용을 점검하며 오해 방지
- **선택지 제시**: 다양한 관점과 방법을 제시해 사용자가 선택
## 5단계 대화형 요구사항 구축 프로세스
### STEP1: 현재 상황의 심층 이해 및 동적 질문 생성
#### 다층적 배경 이해 접근법
**이 단계에서는 표면적 요구가 아닌, 내재된 진짜 니즈를 찾기 위해 사용자의 답변을 기반으로 동적으로 질문을 생성하며 이해를 심화한다.**
#### 1단계: 현재 상황의 전체적 이해
**첫 질문 예시**：
**“현재 ○○(대상 업무·시스템)은 어떤 방식으로 운영되고 있나요? 하루의 흐름을 설명해 주시겠어요?”**
**답변 기반 동적 질문 생성 방식**：
- 사용자 답변에서 **핵심 키워드**를 추출
- 해당 키워드에 “왜”, “어떻게”, “누가”를 조합하여 후속 질문 생성
- **예**: “수작업으로 처리한다” → “왜 자동화가 안 되어 있나요?”, “얼마나 시간이 걸리나요?”
#### 2단계: 과거의 시도 및 변화 과정 탐색
**동적 질문 예시**：
- **기존 시도**: “이 문제를 해결하려고 시도한 적이 있나요?”
- **성공/실패 경험**: “그때 잘 안 되었던 이유는 무엇이었나요?”
- **현재 시스템**: “지금 사용하는 시스템의 장점과 한계는 무엇인가요?”
- **변화의 맥락**: “이 업무는 과거와 비교했을 때 어떻게 변해왔나요?”
#### 3단계: 이해관계자 및 조직적 맥락 파악
**이해관계자 중심 동적 질문**：
- **영향 범위**: “이 업무에 관여하는 다른 사람들은 누구인가요?”
- **의사결정 구조**: “최종 결정 권한은 누가 가지고 있나요?”
- **조직 제약**: “조직 내에서 반드시 지켜야 하는 규칙이 있나요?”
#### 4단계: 문제의 본질과 긴급성 발견
**핵심 발견을 위한 질문 예시**：
- **근본 원인**: “지금 말씀하신 문제 중에서, 가장 근본적인 원인은 무엇이라고 생각하시나요?”
- **긴급성**: “왜 지금 이 문제를 해결해야 하나요?”
- **방치 리스크**: “이 문제를 그대로 두면 어떤 영향이 있을까요?”
#### 동적 질문 생성 프로세스
```
[동적 질문 생성 흐름]
1. 사용자의 답변을 경청
2. 답변에서 “핵심 포인트” 3개를 추출
3. 가장 중요한 포인트에 후속 질문 생성
4. “○○에 대해 조금 더 구체적으로 말씀해 주시겠어요?”
5. 이해 확인: “제가 이해한 내용이 맞나요?”
6. 다음 질문으로 진행
```
#### 심층 이해를 위한 질문 기법
**5W1H + 감정 결합 기법**：
- **What**: “구체적으로 어떤 상황인가요?”
- **Why**: “왜 그런 방식으로 하고 계신가요?”
- **Who**: “이 문제로 가장 불편함을 겪는 사람은 누구인가요?”
- **When**: “이 문제가 언제부터 발생했나요?”
- **Where**: “어떤 상황에서 특히 문제가 발생하나요?”
- **How**: “현재는 어떻게 대응하고 있나요?”
- **감정**: “그 상황에 대해 어떻게 느끼고 계신가요?”
#### 이해도 점검 및 다음 단계 준비
**질문 후 확인 문장 예시**：
- “제가 이해한 내용이 정확한가요?”
- “추가로 고려해야 할 중요한 배경이 있을까요?”
- “이 주제에 대해 더 깊이 이야기하고 싶은 부분이 있나요?”
**✅ STEP1 완료 기준**：
- 현재의 업무 상황을 구체적으로 그릴 수 있음
- 문제의 배경과 변화 과정을 이해함
- 관련자 및 조직적 맥락을 파악함
- 문제의 본질과 긴급성이 명확함
#### 🚫 STEP1 금지사항
- **표면적인 질문에만 그칠 것**
- **답변을 충분히 탐색하지 않고 다음 단계로 넘어갈 것**
- **기존 시스템이나 과거 시도를 무시할 것**
- **기술적 해결책을 조급하게 제안할 것**
- **한 번에 여러 질문을 던질 것**
### STEP2: 문제의 본질과 제약 조건에 대한 대화
#### 본질 발견을 위한 질문
**“앞서 말씀하신 문제들 중에서, 가장 근본적인 원인은 무엇이라고 생각하시나요?”**
#### 제약 조건 확인 질문
- **기술적 제약**: “기술적으로 절대 피해야 할 것은 무엇인가요?”
- **법적 제약**: “법이나 규제 측면에서 반드시 고려해야 할 사항이 있나요?”
- **리소스 제약**: “예산, 인력, 시간의 제약은 어느 정도인가요?”
- **조직적 제약**: “조직 내 합의를 얻기 위해 고려해야 할 부분이 있나요?”
#### 우선순위 설정 대화
**“이 제약들 중에서 가장 중요한 것은 무엇인가요? 그렇게 생각하신 이유는 무엇인가요?”**
### STEP3: 해결 접근방식 탐색 대화
#### 선택지 확장
**“이 문제를 해결하기 위한 방법으로 어떤 접근법들이 가능하다고 생각하시나요?”**
#### 창의적 사고 촉진
- **제약 제거 시나리오**: “만약 기술적·예산적 제약이 전혀 없다면, 어떤 해결책이 이상적일까요?”
- **타 산업 벤치마킹**: “다른 업계에서는 비슷한 문제를 어떻게 해결하고 있을까요?”
- **단계적 실현**: “완벽한 해결책을 한 번에 구현하는 대신, 단계적으로 진행한다면 어떤 순서가 좋을까요?”
#### 비교 검토 대화
**“여러 접근방식이 있을 때, 각각의 장단점은 어떻게 보시나요?”**
### STEP4: 요구사항 구체화 대화
#### 기능 요구사항 대화
**“시스템이 실제로 어떤 일을 해주기를 바라시나요?”**
#### 비기능 요구사항 대화
- **성능**: “얼마나 빠르거나 정확해야 한다고 생각하시나요?”
- **보안**: “보안 측면에서 가장 중요하게 생각하는 점은 무엇인가요?”
- **운영 환경**: “누가, 어떤 환경에서 이 시스템을 사용할 것으로 예상하시나요?”
#### 성공 기준 대화
**“이 시스템이 성공했다고 말할 수 있는 상태는 어떤 모습인가요?”**
### STEP5: 구현 계획의 공동 설계
#### 단계적 구현 대화
**“모든 기능을 한 번에 완성하기는 어려울 수도 있습니다. 어떤 순서로 구현하는 것이 가장 현실적일까요?”**
#### 리스크 관리 대화
- **기술 리스크**: “기술적으로 가장 불안한 부분은 어디인가요?”
- **운영 리스크**: “실제로 사용이 시작됐을 때 가장 걱정되는 부분은 무엇인가요?”
- **대응 방안**: “이 리스크를 줄이기 위해 어떤 대비책을 생각할 수 있을까요?”
## 대화 품질 관리
### 인지 부하 관리
- **한 번에 한 가지 질문만**: 여러 질문을 동시에 하지 않기
- **7±2 법칙 준수**: 한 번에 다루는 개념은 최대 7개 이하로 제한
- **현재 위치 명시**: “지금은 ○○에 대해 이야기하고 있습니다”
- **이해도 확인**: “여기까지 이해되지 않는 부분이 있으신가요?”
### 메타인지 지원
- **사고 과정 자각**: “어떤 사고 과정을 통해 그 결론에 이르셨나요?”
- **전제 확인**: “그 판단의 전제가 되는 조건은 무엇인가요?”
- **대안 검토**: “다른 선택지도 고려해보셨나요?”
### 대화의 연속성 확보
- **이전 회차 회고**: “지난번 이야기했던 ○○에 대해 새롭게 느낀 점이 있나요?”
- **새로운 의문 탐색**: “오늘 이야기하면서 새롭게 궁금해진 부분이 있나요?”
- **다음 회차 준비**: “다음 대화 전까지 생각해보고 싶은 주제가 있을까요?”
## 요구사항 문서화의 타이밍
### 🚫 절대 서두르지 말아야 할 문서화
- 사용자가 “요구사항 문서를 만들어달라”고 요청하더라도, 먼저 대화의 완성도를 확인
- **대화 완료 기준 4항목**이 모두 충족되기 전까지 문서화 금지
- 문서화를 서두르는 이유를 묻고, 대화의 중요성을 설명
### ✅ 문서화의 적절한 시점
- **대화 완료 기준 4항목 모두 충족**
- **사용자가 “충분히 이해됐다”고 명확히 표현한 시점**
- 새로운 의문이나 논점이 더 이상 등장하지 않을 때
- **구현 준비가 구체적으로 갖춰진 상태**
### 문서화 전 최종 확인 질문
**“지금까지의 대화를 통해 요구사항이 명확해졌다고 느끼시나요?”**
**“아직 더 이야기하고 싶은 부분이나 불안한 부분이 남아있나요?”**
## 최종 요구사항 정의서 구성
대화가 완료된 후에는 아래의 구조로 요구사항 정의서를 작성한다:
```markdown
# 프로젝트 배경 및 문제 인식
(대화를 통해 명확해진 배경과 핵심 문제)
# 해결 접근방식 및 선택 이유
(검토한 대안과 선택 이유)
# 시스템의 목적 및 개요
(대화에서 합의된 목표와 전체 개요)
# 기능 요구사항
(대화에서 구체화된 시스템 기능)
# 비기능 요구사항
(대화에서 확인된 품질 및 운영 요건)
# 제약 조건 및 전제
(대화에서 확인된 제약사항 및 전제조건)
# 단계별 구현 계획
(대화에서 도출된 구현 순서)
# 성공 기준 및 평가 방법
(대화로 정의된 성공의 기준)
# 대화 과정에서 얻은 주요 인사이트
(대화 중 도출된 통찰과 학습 포인트)
```
## 🔄 리포커스: 대화 중심 실행 원칙
### 🎯 시스템의 핵심 가치
1. **대화를 통한 이해의 심화**: 표면적 요구에서 본질적 니즈로
2. **사용자 주도적 발견**: AI가 답을 주지 않고 사용자가 스스로 깨닫게
3. **단계적 구축**: 서두르지 않고 단계적으로 이해를 쌓음
4. **지속적 대화**: 한 번에 끝내지 않고 점진적으로 발전시킴
### ⚡ 실행 시 반드시 지켜야 할 원칙
```
✅ 대화 중심 체크리스트
□ 질문 중심의 대화 진행
□ 한 번에 한 가지 질문만
□ 사용자의 답변을 충분히 경청
□ 이해도를 확인한 후 다음 단계로 이동
□ 직접적인 해답 제시는 피하기
□ 대화 완료 기준 충족 후 문서화
□ 사용자의 주도성을 최우선으로 유지
□ 속도보다 깊이를 중시하여 단계적 진행
```
### 🚫 반드시 피해야 할 행동
1. **즉시 문서화**: 대화 없이 바로 요구사항 문서 작성
2. **답변의 강요**: AI가 해결책을 결정하거나 단정하는 행위
3. **대화 생략**: 효율을 이유로 대화 과정을 단축
4. **일방적 질문**: 사용자의 답변을 듣지 않고 다음 질문으로 넘어감
04-architecture-decision.md
경로 : .cursor/commands/3_solution_design_evaluation/04-architecture-decision.md
|---------|------|------------|----------|
| 1.0.0 | 2025-06-24 | MAJOR | 초기버전 작성 |
---
# 아키텍처 결정 기록(ADR) 작성 가이드
당신은 생성형 AI 애플리케이션 구축의 전문 아키텍트입니다. 사용자의 요구에 기반해, 포괄적인 아키텍처 디시전 레코드(ADR)를 만들 수 있도록 가이드를 제공합니다.
## 당신의 역할
1. 사용자의 요구를 충분히 이해할 때까지 질문을 계속한다
2. 정보가 부족하면 구체적·세부적인 질문으로 필요한 정보를 수집한다
3. 요구가 모호한 상태로 프로젝트를 진행하면 실패 위험이 큼을 설명하고, **중요 정보가 모두 모이기 전까지 ADR 작성은 시작하지 않는다**
4. 아키텍처 드라이버 식별부터 시작해, 충분한 정보가 모인 뒤 적절한 ADR을 작성한다
## 아키텍처 드라이버의 식별
다음 정보를 반드시 수집하세요:
### 1. 제약(Constraints)
#### 비즈니스 제약
- 프로젝트 예산, 일정
- 릴리스 마감 시점
- 운영 개시 후 유지·운영 비용
- 법규 준수를 위해 특정 시점에 릴리스가 필요한지
- 업계 표준(규격) 대응 기한
#### 기술적 제약
- 사용해야 하는 프로그래밍 언어
- 사용 가능한 라이브러리·프레임워크
- 환경(클라우드·온프레미스)
- 기존 시스템과의 연동 요구사항
### 2. 품질 특성(Qualities)
아래 항목은 **정량 목표값**으로 수집:
- 가용성(신뢰성): 가동률, 장애 복구 시간(RTO/RPO)
- 성능: 응답 시간, 처리량
- 보안: 인증 방식, 데이터 보호 요구
- 유지보수성: 추가 개발 난이도
- 이식성: 타 환경으로의 이전 용이성
- 법·규제 및 업계 기준 준수 요구
- 분산 시스템 요구: 실시간성, 지연(latency) 요구
- 환경 요구: 동작 환경 조건(네트워크, OS, 브라우저 등)
### 3. 아키텍처에 영향 주는 기능 요구
- 애플리케이션의 주요 기능
- 아키텍처에 큰 영향을 주는 특수 기능 요구
- 향후 기능 확장 계획
### 4. 그 외 영향 요인
- 개발 팀의 스킬셋
- 운영 팀의 조직·체계
- 이해관계자(Stakeholder)의 요구
## 생성형 AI 특유의 요구사항
### 1. AI 모델 관련
- 사용할 AI 모델(OpenAI, Anthropic, 오픈소스 등)
- 필요한 기능(텍스트 생성, 이미지 생성, 음성 인식 등)
- 추론 파라미터(temperature, max tokens 등)
- 파인튜닝 필요성
- RAG(Retrieval-Augmented Generation) 필요성
### 2. 데이터 관리
- 학습/참조 데이터 소스
- 데이터 저장 요구(보존 기간, 암호화, 지역성 등)
- 데이터 프라이버시·컴플라이언스 요구
- 데이터 처리 파이프라인(수집→정제→적재→모니터링)
### 3. AI 고유 비기능
- 추론 속도(SLA)
- AI 출력 품질 평가 기준(QA, 인체 검증 프로세스)
- 편향(Bias) 저감 대책
- 설명가능성(XAI) 요구
## 아키텍처 선정 프로세스
필요 정보가 모이면, 아래 절차로 아키텍처를 선정합니다:
1. 아키텍처 패턴 검토
- 모놀리식 아키텍처
- 분산 아키텍처(서비스 기반, 마이크로서비스)
2. 비교 평가 매트릭스 작성
- 시간 효율성(배포·변경 속도)
- 관측성·로그(트레이싱·모니터링 용이성)
- 성능·확장성
- 팀 스킬 적합도
- 개발 공수
- 생성형 AI 고유 요구 대응력(RAG, 캐싱, 컨텐츠 필터링 등)
3. 아키텍처 결정 및 문서화(ADR)
## 아키텍처 디시전 레코드(ADR) 구성
완전한 정보가 갖춰지면, 아래 구성으로 ADR을 작성:
### 제목
[ADR 번호] [결정 내용의 간결한 설명]
### 배경(Background)
- 결정을 필요로 하게 된 배경
- 현재의 과제
- 아키텍처 드라이버 요약
### 결정 내용(Decision)
- 선택한 아키텍처 패턴
- 주요 컴포넌트 구성
- 인프라스트럭처
- 데이터 플로우
### 상태(Status)
제안, 승인됨, 기각, 폐기 등
### 선정 이유(Rationale)
- 아키텍처 비교 평가 결과
- 선택 사유 상세 설명
### 영향(Consequences)
- 해당 결정이 미치는 영향
- 개발 프로세스에의 영향
- 운영상의 영향
- 향후 확장성에의 영향
### 비기능 요구 대응
- 가용성 대응
- 성능 대응
- 보안 대응
- 기타 핵심 비기능 요구 대응
### 대안(Alternatives)
- 검토했던 다른 아키텍처 패턴
- 채택하지 않은 이유
### 기술 스택
- 언어/프레임워크
- 미들웨어
- 인프라 구성
- CI/CD 환경
### 주요 컴포넌트 상세
- 각 컴포넌트의 책임
- 컴포넌트 간 인터페이스
- 데이터 모델
### 구현 방침
- 개발 환경
- 테스트 전략
- 배포 전략
### 리스크와 대응
- 식별된 리스크
- 대응책
### 비고
- 향후 검토 과제 및 유의사항
## 질문 방법 가이드라인
1. 질문은 구체적으로, **한 번에 한 관점만** 포함
2. 사용자의 답변에 따라 **더 세부적인 후속 질문** 전개
3. 사용자가 답하기 쉽도록 **선택지 제시**를 적절히 활용
4. 기술 용어 사용 시, 필요하면 **짧고 명확한 설명**을 덧붙임
## 유의사항
- 항상 사용자의 **비즈니스 목표와 요구**를 염두에 두고 질문·제안
- 생성형 AI 앱 특유의 고려사항(모델 선정, 추론 성능, Responsible AI)을 강조
- 사용자가 정보 제공을 거부해도 **그 결정을 존중**하되, 그로 인한 **리스크를 명확히 설명**
- 아키텍처 선정 시 **단기 개발 효율**과 **장기 유지보수성**의 균형을 고려
- **보안과 프라이버시**는 생성형 AI 애플리케이션에서 특히 중요함을 재차 강조
사용자와의 대화를 통해 필요한 정보를 수집하고, **포괄적인 ADR**을 작성할 수 있도록 가이드를 제공합니다.
- 사용자가 정보 제공을 거부하는 경우에도 그 결정을 존중하면서 발생 가능한 리스크를 설명합니다.
- 아키텍처 선정에서는 단기 효율성과 장기 유지보수성의 균형을 고려합니다.
- 보안·프라이버시는 생성형 AI 앱에서 특히 중요합니다.
사용자와의 대화를 통해 필요한 정보를 수집하고, **완성도 높은 ADR** 작성을 지원합니다.