2025/07/05 AI Factory 기반 Flutter 개발 룰

AI Factory 기반 Flutter 개발 룰

핵심 원칙: Fix Inputs, Not Outputs

"출력물은 일회용이고, 계획과 프롬프트는 복합적이다"

코드를 직접 수정하지 말고, 계획과 프롬프트를 개선하여 다음 실행에서 올바른 코드가 생성되도록 한다.

---

새로운 기능 구현 룰

1단계: PRD.md 작성 및 요구사항 분석 (Planning Phase)

PRD.md (Product Requirements Document) 작성 필수

# PRD.md - [기능명] 제품 요구사항 명세서

## 프로젝트 개요
### 프로젝트명
[구체적인 프로젝트명]

### 목표 및 목적
- 비즈니스 목표
- 사용자 목표
- 기술적 목표

### 성공 지표
- 정량적 지표
- 정성적 지표

## 사용자 정의
### 타겟 사용자
- 주요 사용자
- 사용자 페르소나
- 사용 환경

### 사용자 여정
1. 진입점
2. 핵심 플로우
3. 종료점

## 기능 요구사항
### 핵심 기능
- 기능 1
  - 상세 설명
  - 예상 동작
  - 성공 조건
- 기능 2
  - 상세 설명
  - 예상 동작
  - 성공 조건

### 부가 기능
- 우선순위 높음
- 우선순위 중간
- 우선순위 낮음

## 사용자 경험 요구사항
### UI/UX 가이드라인
- 디자인 원칙
- 플랫폼별 가이드라인
- 반응형 디자인

### 사용성 요구사항
- 학습 용이성
- 효율성
- 에러 방지

## 기술적 요구사항
### 플랫폼 지원
- Android
- iOS
- Web

### 성능 요구사항
- 응답 시간
- 메모리 사용량
- 배터리 사용량

### 보안 요구사항
- 데이터 보호
- 권한 관리
- 암호화

## 플랫폼별 고려사항
### Android 특이사항
- 권한
- 백그라운드 제한
- 알림

### iOS 특이사항
- 권한
- 백그라운드 모드
- App Store 정책

## 통합 요구사항
### 기존 시스템과의 연동
- 연동 지점
- 데이터 흐름
- 의존성

### 외부 서비스 연동
- API
- SDK
- 패키지

## 테스트 요구사항
### 테스트 범위
- 단위 테스트
- 통합 테스트
- UI 테스트

### 테스트 환경
- 개발 환경
- 스테이징 환경
- 운영 환경

## 배포 및 운영
### 배포 계획
- 단계별 배포
- 롤백 계획
- 모니터링

### 운영 고려사항
- 로깅
- 에러 추적
- 성능 모니터링

## 일정 및 마일스톤
### 개발 일정
- Phase 1 ~ 4

### 주요 마일스톤
- M1 ~ M4

## 위험 요소 및 대응 방안
### 기술적 위험
- 위험 요소
  - 발생 가능성
  - 영향도
  - 대응 방안

### 비즈니스 위험
- 위험 요소
  - 발생 가능성
  - 영향도
  - 대응 방안

## 검토 및 승인
### 검토 사항
- 비즈니스 요구사항
- 기술적 요구사항
- 리소스 및 일정
- 위험 요소

### 승인
- Product Owner
- Tech Lead
- Project Manager

PRD.md 기반 요구사항 분석 체크리스트

• PRD.md 작성 완료
• 비즈니스 목표 명확화
• 사용자 여정 정의
• 핵심 기능 우선순위 결정
• 플랫폼별 요구사항 확인
• 기술적 제약사항 파악
• 성공 지표 정의
• 위험 요소 및 대응 방안 수립

2단계: 아키텍처 설계 및 기존 코드 분석

// 기존 코드 중복 체크 필수
// 1. 비슷한 기능을 하는 클래스/함수가 있는지 확인
// 2. 재사용 가능한 유틸리티 함수가 있는지 확인
// 3. 동일한 패턴의 서비스 클래스가 있는지 확인

/// 올바른 예: 기존 함수 재사용
class LocationService {
  Future<Position> getCurrentLocation() => _commonLocationHelper.getLocation();

  Future<void> startBackgroundLocationTracking() async {
    // 구현 로직
  }
}

/// 잘못된 예: 중복 함수 생성
class NewLocationService {
  Future<Position> getLocation() => ... // 중복!
}

 

3단계: Sequential Thinking으로 TaskList.md 생성

• PRD.md 요약
• MSA 단위별 구현 계획
• 단계별 Task 분리 및 체크리스트
• PRD.md 기반 성공 지표 추적 및 이슈 기록

4단계: TDD 개발 방식 적용

void main() {
  group('LocationService 테스트', () {
    late LocationService locationService;

    setUp(() {
      locationService = LocationService();
    });

    test('현재 위치를 정상적으로 가져와야 한다', () async {
      final position = await locationService.getCurrentLocation();

      expect(position, isNotNull);
      expect(position.latitude, isA<double>());
      expect(position.longitude, isA<double>());
    });

    test('백그라운드에서 위치 추적이 시작되어야 한다', () async {
      await locationService.startBackgroundLocationTracking();

      // 백그라운드 서비스 시작 여부 확인
    });
  });
}

 

5단계: 단위별 구현 및 커밋

git add .
git commit -m "feat: Phase 1.1 완료 - 의존성 분석 및 패키지 선정"

 

디버깅 및 수정 룰

원칙: 증상 치료가 아닌 원인 치료

디버깅 시 금지 사항

• 출력된 코드를 직접 수정
• 임시 조건문 추가
• UI 임의 변경
• 함수 로직 무단 변경
• 에러 무시 및 try-catch로 덮기

디버깅 워크플로우

1. 문제 분석
   • 에러 로그 분석
   • 재현 조건 파악
   • 플랫폼 차이 확인
   • 전체 코드 맥락 파악
2. 근본 원인 식별
   • 설정 문제 여부 확인
   • 권한 문제 여부 확인
   • 플랫폼 차이 여부 확인
   • 라이브러리 사용법 확인
3. Input(계획/프롬프트) 수정
   • TaskList.md 반영
   • 공식 문서 재확인
   • 설정 가이드 업데이트
   • 에러 재현 방지
4. PR 재생성
   • 수정된 PRD 기반 코드 재생성
   • 테스트 통과 여부 확인
   • 커밋 및 배포

 

2025년 7월 5일 현재 커서에서 사용하고 있는 룰을 공개합니다.
최적화한 바이브 코딩 룰을 만들때까지 계속 공개를 하겠습니다.