Flow: AI와 함께하는 체계적인 개발 프레임워크

"뼈대를 먼저 만들고, 그 다음에 살을 붙여라" — Flow Framework

 

GitHub - khgs2411/flow: Iterative development framework combining Domain-Driven Design with Agile philosophy

 

들어가며

AI 코딩 도구를 사용하다 보면 이런 경험 없으신가요?

• 프롬프트를 던지고 기다렸는데, 결과가 엉뚱한 방향으로...
• 어제 ChatGPT와 나눴던 대화 내용을 오늘 다시 설명해야 하는 상황
• AI가 만든 코드가 마음에 안 들어서 결국 전체를 다시 작성
• "왜 이렇게 구현했지?"라는 질문에 답할 수 없는 코드

Flow는 이런 문제들을 해결하기 위한 프레임워크입니다. 핵심 철학은 간단합니다:

👤 사람이 운전하고, 🤖 AI가 실행한다

Flow가 해결하는 문제

문제 1: AI가 아키텍처를 결정한다

기존 방식:

당신: "결제 시스템을 만들어줘"
AI: *마음대로 아키텍처 결정* → MongoDB 사용, REST API 설계
당신: "아니 우리는 PostgreSQL 쓰는데..." → 전체 리팩토링

Flow 방식:

당신: 설계 문서 작성 → PostgreSQL 사용, 이유: 금융 데이터는 ACID 보장 필요
AI: 문서를 읽고 PostgreSQL로 구현
당신: 검증 완료 → 다음 단계

문제 2: 컨텍스트가 사라진다

기존 방식:

어제: "WebSocket으로 실시간 채팅 만들어줘"
오늘: 새 세션 시작 → AI는 어제 대화를 모름 → 처음부터 다시 설명

Flow 방식:

모든 설계가 .flow/PLAN.md에 저장됨
→ 어떤 AI든, 언제든 PLAN.md를 읽고 즉시 작업 재개 가능

문제 3: 반복 구조가 없다

기존 방식:

"완벽한 결제 시스템 만들어줘"
→ AI가 모든 기능을 한 번에 구현 시도
→ 중간에 버그 발견
→ 전체를 다시 만들어야 함

Flow 방식:

V1 (뼈대): 기본 결제 흐름만 (성공 케이스)
V2 (혈관): 에러 처리 추가
V3 (살): 재시도 로직, 웹훅 처리
V4 (섬유): 성능 최적화, 로깅

Flow의 핵심 구조

프로젝트 구조

your-project/
├── .claude/commands/              # 25개의 슬래시 커맨드
│   ├── flow-blueprint.md
│   ├── flow-brainstorm-start.md
│   └── ...
│
└── .flow/
    ├── 👤 YOUR WORKSPACE (당신이 소유)
    │   ├── PLAN.md                 # 당신의 설계 문서
    │   ├── DASHBOARD.md            # 진행 상황 추적
    │   └── phase-1/
    │       └── task-1/
    │           ├── iteration-1-brainstorm.md
    │           └── iteration-1-implementation.md
    │
    └── 🤖 AI REFERENCE (읽기 전용 템플릿)
        └── framework/
            ├── DEVELOPMENT_FRAMEWORK.md
            ├── SLASH_COMMANDS.md
            └── examples/

PLAN.md 예시

# 프로젝트: 실시간 채팅 앱

## Phase 1: 핵심 메시징 ⏳

### Task 1: WebSocket 연결 🚧

#### Iteration 1: 기본 연결 (Skeleton) ✅
- WebSocket 서버 설정
- 클라이언트 연결/해제
- 기본 메시지 송수신

#### Iteration 2: 에러 처리 (Veins) 🚧
- 재연결 로직
- 타임아웃 처리
- 연결 상태 추적

#### Iteration 3: 메시지 큐 (Flesh) ⏳
- 오프라인 메시지 저장
- 메시지 순서 보장
- 중복 메시지 필터링

상태 아이콘:

• ⏳ PENDING: 아직 시작 안 함
• 🚧 IN PROGRESS: 현재 작업 중
• 🎨 READY: 설계 완료, 코딩 준비됨
• ✅ COMPLETE: 완료 및 검증됨

실전 예제: 결제 시스템 구축

실제로 Flow를 사용하여 결제 시스템을 만드는 과정을 단계별로 살펴보겠습니다.

Step 1: 청사진 작성 (/flow-blueprint)

먼저 요구사항을 정리합니다:

/flow-blueprint "Stripe 결제 게이트웨이 통합: 결제 생성, 
웹훅 처리, 환불 기능, 에러 처리"

AI가 다음과 같은 구조화된 계획을 생성합니다:

# 결제 게이트웨이 프로젝트

## Phase 1: 핵심 결제 흐름

### Task 1: Stripe 통합
- Iteration 1 (Skeleton): 기본 결제 생성
- Iteration 2 (Veins): 에러 처리 및 재시도
- Iteration 3 (Flesh): 결제 상태 추적

### Task 2: 웹훅 처리
- Iteration 1: 기본 웹훅 수신
- Iteration 2: 서명 검증
- Iteration 3: 이벤트 큐 및 재처리

## Phase 2: 환불 및 취소

### Task 1: 환불 로직
- Iteration 1: 전체 환불
- Iteration 2: 부분 환불
- Iteration 3: 환불 이유 추적

여기서 당신이 검토하고 조정합니다. 예를 들어:

• "Phase 1에 보안 검증 Task를 추가해야겠다"
• "Iteration 순서를 바꿔야겠다"

Step 2: 브레인스토밍 (/flow-brainstorm-start)

이제 기술적 결정들을 논의합니다:

/flow-brainstorm-start "결제 흐름 아키텍처, 
웹훅 보안, 재시도 전략"

AI가 의사결정 포인트들을 제시합니다:

## 🎨 Brainstorm Session: Phase 1 - Task 1 - Iteration 1

### Subject 1: 결제 흐름 아키텍처 ⏳

**Options:**
1. **직접 결제 (Direct Charge)**
   - 장점: 단순함, 즉시 완료
   - 단점: 네트워크 장애 시 이중 결제 위험
   
2. **2단계 커밋 (Reserve → Capture)**
   - 장점: 이중 결제 방지, 사기 검증 가능
   - 단점: 구현 복잡도 증가
   
3. **비동기 결제 큐**
   - 장점: 높은 처리량
   - 단점: 결과 지연, 복잡한 상태 관리

**Questions for you:**
- 예상 트래픽은 어느 정도인가요?
- 결제 실패 시 사용자 경험은?
- 사기 방지가 중요한가요?

Step 3: 결정 및 문서화

각 주제에 대해 당신이 결정하고 근거를 문서화합니다:

/flow-next-subject

### Subject 1: 결제 흐름 아키텍처 ✅

**Decision:** 2단계 커밋 방식 (Reserve → Capture)

**Rationale (당신의 결정 근거):**
- 이중 결제 방지가 최우선 (금융 데이터)
- 사기 검증 시간 필요 (reserve와 capture 사이)
- 업계 표준 (Amazon, Shopify도 동일 방식)
- 트래픽이 아직 높지 않아 복잡도 감당 가능

**Implementation Notes:**
- Stripe PaymentIntent API 사용
- Reserve: `create_payment_intent` with `capture_method='manual'`
- Capture: `confirm_payment_intent`

**Action Items (AI가 구현할 내용):**
- [ ] PaymentIntent 생성 엔드포인트
- [ ] Reserve 엔드포인트 (카드 정보 검증)
- [ ] Capture 엔드포인트 (실제 청구)
- [ ] 타임아웃 처리 (24시간 내 capture 필수)

다음 주제로 이동:

### Subject 2: 웹훅 보안 ✅

**Decision:** Stripe 서명 검증 + IP 화이트리스트

**Rationale:**
- 서명 검증만으로는 부족 (replay attack 가능)
- IP 화이트리스트 추가로 이중 보안
- Stripe IP는 고정되어 있음

**Action Items:**
- [ ] Stripe 서명 검증 미들웨어
- [ ] IP 화이트리스트 체크
- [ ] 타임스탬프 검증 (5분 이내)
- [ ] 이벤트 ID 중복 체크 (Redis)

Step 4: 구현 시작 (/flow-implement-start)

브레인스토밍이 완료되면 구현을 시작합니다:

/flow-implement-start

AI가 문서화된 결정사항을 읽고 구현합니다:

# AI가 생성한 코드 (당신의 결정사항 기반)

from stripe import PaymentIntent
import os

# Action Item 1: PaymentIntent 생성 엔드포인트
@app.post("/api/payments/create")
async def create_payment(amount: int, currency: str):
    """
    결제 의도 생성 (Reserve 단계)
    Decision: 2단계 커밋 방식 사용
    """
    try:
        intent = PaymentIntent.create(
            amount=amount,
            currency=currency,
            capture_method='manual',  # Rationale: 이중 결제 방지
            metadata={
                'created_at': datetime.now().isoformat()
            }
        )
        return {
            'client_secret': intent.client_secret,
            'payment_intent_id': intent.id
        }
    except Exception as e:
        # Iteration 2에서 에러 처리 강화 예정
        raise

# Action Item 2: Reserve 엔드포인트
@app.post("/api/payments/reserve")
async def reserve_payment(payment_intent_id: str):
    """
    카드 정보 검증 및 금액 예약
    """
    intent = PaymentIntent.confirm(payment_intent_id)
    
    if intent.status == 'requires_capture':
        # 24시간 타임아웃 체크 작업 예약
        schedule_capture_timeout(payment_intent_id, hours=24)
        return {'status': 'reserved', 'intent_id': intent.id}
    
    return {'status': 'failed', 'error': intent.last_payment_error}

# Action Item 3: Capture 엔드포인트
@app.post("/api/payments/capture")
async def capture_payment(payment_intent_id: str):
    """
    실제 청구 실행
    """
    intent = PaymentIntent.capture(payment_intent_id)
    return {'status': 'captured', 'amount': intent.amount}

Step 5: 검증 및 완료 (/flow-implement-complete)

구현이 끝나면 당신이 검증합니다:

/flow-implement-complete

체크리스트:

• ✅ 2단계 커밋 방식으로 구현됨
• ✅ 모든 Action Items 완료
• ✅ 결정사항과 구현이 일치함
• ✅ 근거가 명확히 문서화됨

Step 6: 다음 Iteration으로

Iteration 1 (Skeleton)이 완료되었으니, Iteration 2 (Veins)로 넘어갑니다:

#### Iteration 2: 에러 처리 (Veins) 🚧

**Brainstorm Topics:**
- 네트워크 장애 시 재시도 전략
- 타임아웃 처리 방식
- 사용자에게 보여줄 에러 메시지

실전 예제 2: Flutter 앱 개발

당신의 "모바일" 앱에 Flow를 적용해봅시다.

Blueprint 작성

/flow-blueprint "모바일 앱: 걸음 수 추적, 코인 채굴, 
펫 성장 시스템, UI/UX 개선"

# 채굴 앱 개선 프로젝트

## Phase 1: 핵심 기능 안정화

### Task 1: 걸음 수 추적 정확도
- Iteration 1: 센서 데이터 수집 최적화
- Iteration 2: 백그라운드 추적 안정성
- Iteration 3: 배터리 최적화

### Task 2: 코인 채굴 로직
- Iteration 1: 기본 채굴 공식 (steps → coins)
- Iteration 2: 부정 방지 (흔들기 감지)
- Iteration 3: 보너스 시스템 (연속 달성)

## Phase 2: UI/UX 개선

### Task 1: 온보딩 플로우
- Iteration 1: 3단계 소개 화면
- Iteration 2: 펫 선택 애니메이션
- Iteration 3: 권한 요청 개선

### Task 2: 메인 화면 리디자인
- Iteration 1: 펫 상태 표시 개선
- Iteration 2: 코인 채굴 비주얼 피드백
- Iteration 3: 마이크로 인터랙션 추가

브레인스토밍: 코인 채굴 로직

/flow-brainstorm-start "코인 채굴 공식, 부정 방지 전략"

### Subject 1: 코인 채굴 공식 ✅

**Decision:** 단계별 비선형 보상 시스템

**Rationale:**
- 초반 사용자: 빠른 보상으로 동기부여 (1-1000걸음: 1걸음 = 1코인)
- 중반 사용자: 점진적 증가 (1000-5000걸음: 1걸음 = 0.8코인)
- 고급 사용자: 대량 보너스 (5000+ 걸음: 추가 보너스)
- 참고: Pokemon GO의 단계별 보상 시스템

**Formula:**
```dart
double calculateCoins(int steps) {
  if (steps <= 1000) {
    return steps * 1.0;  // 1:1 비율
  } else if (steps <= 5000) {
    return 1000 + (steps - 1000) * 0.8;
  } else {
    return 1000 + 3200 + (steps - 5000) * 0.5 + bonusMultiplier();
  }
}

Action Items:

• [ ] CoinCalculator 클래스 생성
• [ ] 단위 테스트 (경계값 검증)
• [ ] 일일 상한선 적용 (20,000걸음 = 10,000코인)

```markdown
### Subject 2: 부정 방지 전략 ✅

**Decision:** 가속도계 패턴 분석 + 속도 임계값

**Rationale:**
- 단순 걸음 수만 체크하면 흔들기로 부정 가능
- 실제 걷기: 0.5-1.5 m/s 속도, 일정한 패턴
- 흔들기: 불규칙한 가속도, 위치 변화 없음
- GPS 체크는 배터리 소모 심함 → 가속도계 우선

**Implementation:**
```dart
class StepValidator {
  bool isValidStep(AccelerometerEvent event, Location? lastLocation) {
    // 1. 가속도 패턴 체크
    if (!isWalkingPattern(event)) return false;
    
    // 2. 위치 변화 체크 (10분마다)
    if (shouldCheckLocation() && !hasLocationChanged()) return false;
    
    // 3. 속도 임계값
    if (calculatedSpeed > 2.5) return false;  // 너무 빠름
    
    return true;
  }
}

Action Items:

• [ ] StepValidator 클래스 구현
• [ ] 가속도 패턴 알고리즘 (FFT 분석)
• [ ] 의심스러운 활동 로깅
• [ ] 일일 검증 실패 상한 (100회 초과 시 경고)

### 구현

/flow-implement-start

```dart
// lib/features/mining/domain/coin_calculator.dart

/// 걸음 수에 따른 코인 계산
/// Decision: 단계별 비선형 보상 시스템
/// Rationale: 초반 사용자 동기부여 + 장기 사용자 유지
class CoinCalculator {
  // 단계별 임계값
  static const int TIER1_LIMIT = 1000;
  static const int TIER2_LIMIT = 5000;
  
  // 단계별 비율
  static const double TIER1_RATE = 1.0;
  static const double TIER2_RATE = 0.8;
  static const double TIER3_RATE = 0.5;
  
  // 일일 상한선
  static const int DAILY_STEP_CAP = 20000;
  static const double DAILY_COIN_CAP = 10000;

  double calculate(int steps) {
    // 상한선 체크
    if (steps > DAILY_STEP_CAP) {
      steps = DAILY_STEP_CAP;
    }
    
    double coins = 0;
    
    // Tier 1: 0-1000 걸음
    if (steps <= TIER1_LIMIT) {
      coins = steps * TIER1_RATE;
    }
    // Tier 2: 1001-5000 걸음
    else if (steps <= TIER2_LIMIT) {
      coins = TIER1_LIMIT * TIER1_RATE;
      coins += (steps - TIER1_LIMIT) * TIER2_RATE;
    }
    // Tier 3: 5001+ 걸음
    else {
      coins = TIER1_LIMIT * TIER1_RATE;
      coins += (TIER2_LIMIT - TIER1_LIMIT) * TIER2_RATE;
      coins += (steps - TIER2_LIMIT) * TIER3_RATE;
      coins += _calculateBonus(steps);
    }
    
    return coins.clamp(0, DAILY_COIN_CAP);
  }
  
  double _calculateBonus(int steps) {
    // 5000걸음 달성 시 10% 보너스
    if (steps >= 5000) return (steps * 0.1);
    return 0;
  }
}

// lib/features/mining/domain/step_validator.dart

/// 걸음 수 유효성 검증
/// Decision: 가속도계 패턴 분석 + 속도 임계값
/// Rationale: 흔들기 부정 방지, 배터리 효율적
class StepValidator {
  static const double MAX_WALKING_SPEED = 2.5; // m/s
  static const double MIN_WALKING_SPEED = 0.3;
  static const int LOCATION_CHECK_INTERVAL = 600; // 10분
  
  final List<double> _accelerationHistory = [];
  DateTime? _lastLocationCheck;
  Location? _lastLocation;
  
  bool isValidStep(AccelerometerEvent event, Location? currentLocation) {
    // 1. 가속도 패턴 체크
    if (!_isWalkingPattern(event)) {
      logger.warn('Invalid walking pattern detected');
      return false;
    }
    
    // 2. 주기적 위치 검증 (10분마다)
    if (_shouldCheckLocation()) {
      if (!_hasLocationChanged(currentLocation)) {
        logger.warn('No location change detected');
        return false;
      }
    }
    
    // 3. 속도 검증
    double speed = _calculateSpeed(currentLocation);
    if (speed > MAX_WALKING_SPEED || speed < MIN_WALKING_SPEED) {
      logger.warn('Speed out of walking range: $speed m/s');
      return false;
    }
    
    return true;
  }
  
  bool _isWalkingPattern(AccelerometerEvent event) {
    // 가속도 크기 계산
    double magnitude = sqrt(
      pow(event.x, 2) + pow(event.y, 2) + pow(event.z, 2)
    );
    
    _accelerationHistory.add(magnitude);
    if (_accelerationHistory.length > 50) {
      _accelerationHistory.removeAt(0);
    }
    
    // 실제 걷기는 일정한 주기성을 보임
    // 흔들기는 불규칙한 패턴
    if (_accelerationHistory.length >= 20) {
      double variance = _calculateVariance(_accelerationHistory);
      // 분산이 너무 크면 흔들기로 판단
      return variance < 2.0;
    }
    
    return true;
  }
  
  bool _shouldCheckLocation() {
    if (_lastLocationCheck == null) return true;
    
    Duration elapsed = DateTime.now().difference(_lastLocationCheck!);
    return elapsed.inSeconds >= LOCATION_CHECK_INTERVAL;
  }
  
  bool _hasLocationChanged(Location? currentLocation) {
    if (currentLocation == null || _lastLocation == null) {
      _lastLocation = currentLocation;
      _lastLocationCheck = DateTime.now();
      return true;
    }
    
    // 최소 10미터 이상 이동했는지 확인
    double distance = _calculateDistance(
      _lastLocation!.latitude,
      _lastLocation!.longitude,
      currentLocation.latitude,
      currentLocation.longitude,
    );
    
    _lastLocation = currentLocation;
    _lastLocationCheck = DateTime.now();
    
    return distance >= 10; // 10미터 이상
  }
  
  double _calculateSpeed(Location? location) {
    // 간단한 속도 계산 로직
    // 실제로는 더 정교한 알고리즘 필요
    return location?.speed ?? 0;
  }
  
  double _calculateVariance(List<double> values) {
    double mean = values.reduce((a, b) => a + b) / values.length;
    double sumSquares = values
        .map((x) => pow(x - mean, 2))
        .reduce((a, b) => a + b);
    return sumSquares / values.length;
  }
  
  double _calculateDistance(double lat1, double lon1, double lat2, double lon2) {
    // Haversine 공식
    const double R = 6371000; // 지구 반지름 (미터)
    double dLat = _toRadians(lat2 - lat1);
    double dLon = _toRadians(lon2 - lon1);
    
    double a = sin(dLat / 2) * sin(dLat / 2) +
        cos(_toRadians(lat1)) * cos(_toRadians(lat2)) *
        sin(dLon / 2) * sin(dLon / 2);
    
    double c = 2 * atan2(sqrt(a), sqrt(1 - a));
    return R * c;
  }
  
  double _toRadians(double degrees) => degrees * pi / 180;
}

Flow vs 기존 개발 방식 비교

측면 기존 AI 개발 Agile/Scrum Flow

결정권자	AI가 결정	팀이 결정	당신이 결정
컨텍스트	세션마다 소실	티켓/문서	PLAN.md 영구 보존
반복 구조	없음 (매번 재작성)	스프린트 (2주)	V1→V2→V3→V4
AI 활용	전체 (결정+구현)	없음	구현만
문서화	선택 사항	회의 후 작성	필수 (결정 전)
근거 추적	없음	JIRA 코멘트	Rationale 필드

Flow의 25가지 슬래시 커맨드

계획 단계 (3개)

• /flow-blueprint - 요구사항을 구조화된 계획으로 변환
• /flow-migrate - 기존 프로젝트를 Flow 구조로 마이그레이션
• /flow-plan-update - PLAN.md 업데이트

구조 관리 (9개)

• /flow-phase-create - 새 Phase 생성
• /flow-phase-complete - Phase 완료 처리
• /flow-task-create - 새 Task 생성
• /flow-task-complete - Task 완료 처리
• /flow-iteration-create - 새 Iteration 생성
• /flow-iteration-complete - Iteration 완료 처리
• 기타 phase/task/iteration 관리 커맨드

브레인스토밍 (5개)

• /flow-brainstorm-start - 브레인스토밍 세션 시작
• /flow-next-subject - 다음 의사결정 주제로 이동
• /flow-subject-decide - 현재 주제에 대한 결정 문서화
• /flow-subject-skip - 주제 건너뛰기
• /flow-brainstorm-complete - 브레인스토밍 완료

구현 (2개)

• /flow-implement-start - 구현 시작 (AI가 코드 작성)
• /flow-implement-complete - 구현 완료 및 검증

네비게이션 (6개)

• /flow-status - 현재 진행 상황 확인
• /flow-next - 다음 작업으로 자동 이동
• /flow-summarize - 프로젝트 요약
• /flow-verify-plan - PLAN.md 일관성 검증
• /flow-dashboard - 대시보드 생성
• /flow-help - 도움말 표시

설치 및 시작하기

1. Flow 설치

cd /path/to/your/project

# Flow 스크립트 다운로드
curl -O https://raw.githubusercontent.com/khgs2411/flow/master/flow.sh
chmod +x flow.sh

# 설치 실행
./flow.sh

이 명령어는 다음을 수행합니다:

• .claude/commands/ 폴더에 25개의 슬래시 커맨드 설치
• .flow/framework/ 폴더에 참조 문서 복사
• .flow/PLAN.md, .flow/DASHBOARD.md 템플릿 생성

2. 첫 번째 프로젝트 시작

# Claude Code를 열고
/flow-blueprint "당신의 프로젝트 설명"

# 예시:
/flow-blueprint "Next.js 블로그: MDX 포스팅, 
다크모드, 검색 기능, RSS 피드"

3. 브레인스토밍

/flow-brainstorm-start "주요 기술 결정사항들"

# 예시:
/flow-brainstorm-start "SSG vs SSR, 
마크다운 파서 선택, 검색 엔진 (Algolia vs 자체 구현)"

4. 구현 및 반복

/flow-implement-start    # AI가 구현
/flow-implement-complete # 검증 완료
/flow-next              # 다음 작업으로

다른 AI 도구와 함께 사용하기

Flow는 Claude뿐만 아니라 ChatGPT, Gemini 등 다른 AI와도 사용할 수 있습니다.

ChatGPT에서 사용하기

1. 프레임워크 다운로드:

git clone https://github.com/khgs2411/flow.git ~/flow-framework

1. ChatGPT에 프롬프트:

나는 Flow Framework를 사용한 반복 개발을 하고 있습니다.
~/flow-framework/SLASH_COMMANDS.md를 읽고,
/flow-brainstorm-start 커맨드의 지침을 따라서
"WebSocket 아키텍처 결정사항"에 대한 브레인스토밍을 도와주세요.

1. 수동으로 PLAN.md 관리:

• ~/flow-framework/examples/PLAN.md를 템플릿으로 사용
• Phase → Task → Iteration 계층 구조 유지
• 상태 마커 사용 (⏳ 🚧 🎨 ✅)

실전 팁

1. 작게 시작하기

처음부터 완벽한 계획을 세우려 하지 마세요:

나쁜 예:

## Phase 1: 전체 시스템 구축
### Task 1: 모든 기능 구현

좋은 예:

## Phase 1: 핵심 기능 (MVP)
### Task 1: 사용자 인증 (소셜 로그인만)
- Iteration 1: Google 로그인만
- Iteration 2: 에러 처리

2. 결정 근거를 명확히

나쁜 예:

**Decision:** PostgreSQL 사용
**Rationale:** 좋아서

좋은 예:

**Decision:** PostgreSQL 사용

**Rationale:**
- 금융 데이터 → ACID 보장 필수
- 복잡한 조인 쿼리 필요 (리포트 기능)
- 팀의 5년 PostgreSQL 경험
- 참고: Stripe도 PostgreSQL 사용

**Alternatives Considered:**
- MongoDB: 유연하지만 ACID 보장 약함
- MySQL: 괜찮지만 JSON 지원 부족

3. Pre-Implementation Tasks 활용

코딩 전에 해결해야 할 것들을 먼저 파악하세요:

### Pre-Implementation Tasks

#### Task 1: 레거시 결제 모듈 리팩토링
**Why:** 현재 코드가 Stripe에 강하게 결합됨
**What:** PaymentProvider 인터페이스 추출
- [ ] 인터페이스 정의
- [ ] StripeProvider 구현
- [ ] 컨트롤러 업데이트
- [ ] 테스트 작성

#### Task 2: 데이터베이스 스키마 업데이트
**Why:** 새 결제 상태 추가 필요
**What:** 마이그레이션 작성
- [ ] payment_status 열 추가
- [ ] 인덱스 생성
- [ ] 기존 데이터 마이그레이션

4. 브레인스토밍 완료 후 검증

/flow-verify-plan

이 커맨드는 다음을 확인합니다:

• 모든 결정에 Rationale이 있는가?
• Action Items가 구체적인가?
• Phase/Task/Iteration 구조가 올바른가?
• 상태 마커가 일관적인가?

Flow가 적합한 경우

✅ Flow를 사용하면 좋은 경우

1. 복잡한 아키텍처 결정이 필요할 때
   • 예: 마이크로서비스 설계, 상태 관리 패턴 선택
2. 장기 프로젝트
   • 예: 3개월 이상 지속되는 프로젝트
   • 여러 세션에 걸쳐 작업
3. 팀 협업
   • 예: 다른 개발자가 컨텍스트를 이해해야 할 때
   • PLAN.md를 읽으면 즉시 파악 가능
4. 기술 부채 최소화가 중요할 때
   • 예: 핀테크, 헬스케어 등 안정성이 중요한 도메인

❌ Flow가 과한 경우

1. 간단한 스크립트나 유틸리티
   • 예: 데이터 변환 스크립트 (50줄 미만)
2. 프로토타입이나 실험
   • 예: 기술 검증용 PoC
   • 빠른 실험이 더 중요
3. 1회성 작업
   • 예: 일회성 데이터 마이그레이션

마치며

Flow의 핵심은 **"AI는 도구이지, 의사결정자가 아니다"**입니다.

AI가 코드를 작성하는 것은 훌륭합니다. 하지만 아키텍처 결정, 기술 선택, 트레이드오프 판단은 여전히 사람의 몫입니다. Flow는 이 경계를 명확히 하고, 두 가지를 모두 최적화합니다:

• 👤 당신의 전문성: 설계, 결정, 검증
• 🤖 AI의 속도: 구현, 패턴 적용, 반복 작업

다음 단계

1. 프로젝트에 Flow 설치: 5분이면 충분합니다
2. 작은 기능으로 시작: 기존 프로젝트의 한 기능에만 적용
3. 브레인스토밍 습관: 코딩 전에 5분만 투자하여 결정 문서화
4. 반복하며 개선: V1→V2→V3 흐름에 익숙해지기

참고 자료

• GitHub 저장소
• 전체 개발 프레임워크 문서
• 슬래시 커맨드 레퍼런스
• 예제 모음

---

"뼈대를 먼저 만들고, 그 다음에 살을 붙여라"

이 한 문장이 Flow의 모든 것을 담고 있습니다. 한 번에 완벽을 추구하지 말고, 단계적으로 검증하며 발전시키세요. Flow가 그 여정을 함께합니다. 🚀