Skip to content

모범 사례: 명확한 설명, 체크포인트 활용, 범위 제어 및 반복 기법

학습 완료 후 할 수 있는 것

이 강의를 완료하면 다음을 마스터하게 됩니다:

  • AI가 당신의 아이디어를 이해할 수 있도록 고품질 제품 설명을 작성하는 방법
  • 각 단계의 출력 품질을 제어하기 위해 체크포인트 메커니즘을 활용하는 방법
  • 비목표를 통해 범위 경계를 명확히 하여 프로젝트 확장을 방지하는 방법
  • 단계별 반복을 통해 아이디어를 빠르게 검증하고 지속적으로 최적화하는 방법

현재의 어려움

다음과 같은 상황을 경험한 적이 있나요?

  • "분명히 설명했는데, 왜 원하는 것이 생성되지 않는가?"
  • "한 부분이 마음에 안 들면 뒤쪽이 모두 잘못되고, 수정하기가 고통스럽다"
  • "하다 보니 기능이 점점 많아져서 완전히 마무리할 수 없다"
  • "한 번에 모든 기능을 만들려고 했는데, 결과적으로 아무것도 만들지 못했다"

언제 이 기법을 사용할까

AI App Factory를 처음 사용하든 이미 몇 번 경험이 있든, 이러한 모범 사례는 다음을 도와줍니다:

  • 출력 품질 향상: 생성된 애플리케이션이 기대에 더 부합하도록
  • 수정 시간 절약: 오류 누적 방지, 초기 문제 발견
  • 프로젝트 규모 제어: MVP에 집중하여 빠른 배달
  • 개발 비용 절감: 단계별 검증으로 무효 투자 방지

🎒 시작 전 준비 사항

전제 조건

  • 빠른 시작을 읽어 AI App Factory의 기본 개념 이해
  • 7단계 파이프라인 개요를 읽어 전체 프로세스 이해
  • 최소 한 번의 완전한 파이프라인 실행 완료(각 단계의 출력에 대한 직관적 이해)

핵심 아이디어

AI App Factory의 모범 사례는 4가지 핵심 원칙을 중심으로 합니다:

  1. 입력 품질이 출력 품질을 결정: 명확하고 상세한 제품 설명이 성공의 첫걸음
  2. 체크포인트는 품질 방어선: 각 단계 완료 후 신중히 확인하여 오류 누적 방지
  3. MVP 집중: 비목표를 명확히 하여 범위를 제어하고 핵심 기능을 빠르게 배달
  4. 지속적인 반복: 핵심 아이디어를 먼저 검증한 후 점진적으로 기능 확장

이러한 원칙은 소스 코드와 실전 경험에서 추출한 것으로, 이를 따르면 개발 효율성이 수 배 향상될 수 있습니다.

따라 해보기

기법 1: 명확한 제품 설명 제공

왜 필요한가

AI가 당신의 아이디어를 이해할 때는 제공된 텍스트 정보만 의존할 수 있습니다. 설명이 더 명확할수록 생성된 결과물이 기대에 더 부합합니다.

어떻게 하는가

좋은 제품 설명에는 다음 요소가 포함됩니다:

  • 목표 사용자: 누가 이 제품을 사용할 것인가?
  • 핵심 문제: 사용자가 어떤 어려움을 겪고 있는가?
  • 해결책: 제품이 이 어려움을 어떻게 해결하는가?
  • 핵심 기능: 반드시 포함해야 할 기능은 무엇인가?
  • 사용 시나리오: 사용자가 어떤 상황에서 사용하는가?
  • 제약 조건: 어떤 제한이나 특별한 요구사항이 있는가?

비교 예시

❌ 부족한 설명✅ 좋은 설명
피트니스 앱 만들기운동 초보자를 위한 훈련 기록 앱으로, 운동 유형, 시간, 소모 칼로리 기록 및 이번 주 훈련 통계 조회 지원. 목표 사용자는 운동을 시작한 지 얼마 안 된 젊은이들이며, 핵심 기능은 빠른 기록과 진행 상황 확인이고, 소셜 공유나 유료 기능은 포함하지 않음
가계부 앱 만들기젊은이들이 일일 지출을 빠르게 기록할 수 있는 모바일 가계부 앱으로, 주요 기능은 금액 기록, 분류 선택(식비, 교통, 오락, 기타), 이번 달 총 지출 및 분류 통계 조회. 오프라인 사용 지원, 데이터는 로컬에만 저장
작업 관리 도구 만들기소규모 팀이 작업을 관리할 수 있는 간단한 도구로, 작업 생성, 멤버 할당, 마감일 설정, 작업 목록 조회 지원. 팀원 간 작업 상태 공유 가능. 복잡한 워크플로우나 권한 관리는 불필요

체크포인트 ✅

  • [ ] 설명에 목표 사용자가 명확히 되어 있음
  • [ ] 설명에 사용자가 겪는 핵심 문제가 설명되어 있음
  • [ ] 설명에 핵심 기능이 나열되어 있음(5개 이하)
  • [ ] 설명에 제약 조건이나 비목표가 포함되어 있음

기법 2: 체크포인트에서 신중히 확인

왜 필요한가

파이프라인의 각 단계 완료 후에는 체크포인트에서 일시 정지하여 확인을 기다립니다. 이는 품질 방어선으로, 초기에 문제를 발견하여 후속 단계로 오류가 전파되는 것을 방지합니다.

이 단계에서 문제를 발견하면 현재 단계만 재실행하면 됩니다. 마지막까지 기다렸다가 발견하면 여러 단계를 롤백해야 할 수 있어 많은 시간과 토큰이 낭비됩니다.

어떻게 하는가

각 체크포인트 확인 시 다음 내용을 검사:

Bootstrap 단계 체크포인트:

  • [ ] input/idea.md의 문제 정의가 정확함
  • [ ] 목표 사용자 페르소나가 명확하고 구체적임
  • [ ] 핵심 가치 제안이 명확함
  • [ ] 가정 조건이 합리적임

PRD 단계 체크포인트:

  • [ ] 사용자 스토리가 명확하고 수락 조건을 포함함
  • [ ] 기능 목록이 7개 이하(MVP 원칙)
  • [ ] 비목표(Non-Goals)가 명확히 나열됨
  • [ ] 기술 세부사항(React, API, 데이터베이스 등)이 포함되지 않음

UI 단계 체크포인트:

  • [ ] 페이지 구조가 합리적이고 3페이지 이하
  • [ ] 브라우저에서 프로토타입 미리보기 가능
  • [ ] 상호작용 흐름이 명확함
  • [ ] 미적 스타일이 뚜렷함(일반적인 AI 스타일 회피)

Tech 단계 체크포인트:

  • [ ] 기술 스택 선택이 합리적이고 MVP 원칙에 부합함
  • [ ] 데이터 모델 설계가 간단하고 테이블 수가 10개 이하
  • [ ] API 엔드포인트 목록이 완전함
  • [ ] 마이크로서비스, 캐싱 등 과도한 설계가 도입되지 않음

Code 단계 체크포인트:

  • [ ] 프론트엔드 및 백엔드 코드 구조가 완전함
  • [ ] 테스트 케이스가 포함됨
  • [ ] 명백한 any 타입이 없음
  • [ ] 실행 방법을 설명하는 README.md가 포함됨

Validation 단계 체크포인트:

  • [ ] 검증 보고서에 심각한 보안 문제가 없음
  • [ ] 테스트 커버리지 > 60%
  • [ ] 의존성 설치에 충돌이 없음
  • [ ] TypeScript 타입 검사가 통과함

Preview 단계 체크포인트:

  • [ ] README.md에 완전한 실행 설명이 포함됨
  • [ ] Docker 구성이 정상적으로 빌드됨
  • [ ] 로컬에서 프론트엔드 및 백엔드 서비스를 시작할 수 있음
  • [ ] 환경 변수 구성 설명이 포함됨

체크포인트 확인 프로세스

각 체크포인트에서 시스템은 다음 옵션을 제공합니다:

  • 계속: 출력이 기대에 부합하면 다음 단계로 진행
  • 재시도: 출력에 문제가 있으면 수정 의견을 제공하고 현재 단계를 재실행
  • 일시 정지: 더 많은 정보가 필요하거나 아이디어를 조정하려면 파이프라인을 일시 정지

의사결정 원칙:

  • 계속: 모든 검사 항목이 요구사항에 부합함
  • ⚠️ 재시도: 작은 문제(형식, 누락, 세부사항)로 즉시 수정 가능
  • 🛑 일시 정지: 중대한 문제(방향 오류, 범위 통제 불가, 수정 불가)로 재계획 필요

함정 경고

일반적인 오류

"빨리 완료하려고" 체크포인트 확인을 건너뛰지 마세요!

파이프라인이 "단계별 일시 정지 확인"으로 설계된 것은 문제를 적시에 발견하기 위함입니다. 습관적으로 "계속"을 클릭하면 마지막에 문제를 발견했을 때 다음이 필요할 수 있습니다:

  • 여러 단계 롤백
  • 대량의 작업 재실행
  • 많은 토큰 낭비

기억하세요: 체크포인트 확인에 투입하는 시간은 롤백 후 재작업하는 시간 비용보다 훨씬 적습니다.


기법 3: 비목표를 활용한 범위 제어

왜 필요한가

비목표(Non-Goals)는 MVP 개발의 핵심 무기입니다. "무엇을 하지 않을 것인지"를 명확히 나열하면 범위 확장을 효과적으로 방지할 수 있습니다.

많은 프로젝트가 실패하는 근본 원인은 기능이 너무 적어서가 아니라 너무 많아서입니다. 각 새로운 기능은 복잡성, 개발 시간 및 유지보수 비용을 증가시킵니다. 경계를 명확히 하고 핵심 가치에 집중해야 빠르게 배달할 수 있습니다.

어떻게 하는가

Bootstrap 단계에서 비목표를 명확히 나열:

markdown
## 비목표(이 버전에서 하지 않을 기능)

1. 다중 사용자 협업 지원 안 함
2. 실시간 동기화 지원 안 함
3. 서드파티 서비스 통합 지원 안 함(결제, 지도 등)
4. 데이터 분석 또는 보고 기능 제공 안 함
5. 소셜 공유 기능 포함 안 함
6. 사용자 인증 또는 로그인 기능 불필요

PRD 단계에서 비목표를 독립적인 장으로 작성:

markdown
## 비목표(이 버전에서 명확히 하지 않음)

다음 기능은 가치가 있지만 이번 MVP 범위에 포함되지 않음:

| 기능 | 이유 | 향후 계획 |
| --- | --- | --- |
| 다중 사용자 협업 | 개인 사용자에 집중 | v2.0 고려 |
| 실시간 동기화 | 기술 복잡성 증가 | 사용자 피드백이 강력하면 고려 |
| 결제 통합 | 핵심 가치 아님 | v1.5 고려 |
| 데이터 분석 | MVP에 불필요 | v2.0 고려 |

비목표 판단 기준

비목표로 설정해야 하는지 판단하는 방법:

  • ❌ 이 기능이 핵심 아이디어 검증에 필수적이지 않음 → 비목표로 설정
  • ❌ 이 기능이 기술 복잡성을 크게 증가시킴 → 비목표로 설정
  • ❌ 이 기능이 수동 방식으로 대체 가능함 → 비목표로 설정
  • ✅ 이 기능이 제품 존재 이유임 → 반드시 포함

함정 경고

범위 확장 함정

일반적인 범위 확장 신호:

  1. "어차피 간단하니까, 겸사겸사 하나 추가하자..."
  2. "경쟁사에 이 기능이 있으니 우리도..."
  3. "사용자가 필요할 수도 있으니 미리 만들자..."
  4. "이 기능이 재미있어서 제품 하이라이트가 될 수 있을 것 같아..."

이러한 생각이 들 때 자신에게 세 가지 질문:

  1. 이 기능이 핵심 아이디어 검증에 도움이 되는가?
  2. 이 기능을 하지 않으면 제품을 사용할 수 없는가?
  3. 이 기능을 추가하면 배달 시간이 지연되는가?

답이 "필요 없음", "사용 가능", "지연됨"이라면 과감히 비목표로 설정하세요.


기법 4: 단계별 반복, 빠른 검증

왜 필요한가

MVP(최소可行 제품)의 핵심 개념은 아이디어를 빠르게 검증하는 것이지, 한 번에 완벽하게 만드는 것이 아닙니다.

반복 개발을 통해 다음을 할 수 있습니다:

  • 초기에 사용자 피드백 얻기
  • 방향을 적시에 조정
  • 매몰 비용 감소
  • 개발 동력 유지

어떻게 하는가

반복 개발 단계:

1라운드: 핵심 기능 검증

  1. AI App Factory를 사용하여 1차 버전 애플리케이션 생성
  2. 가장 핵심적인 3-5개 기능만 포함
  3. 빠르게 실행 및 테스트
  4. 실제 사용자에게 프로토타입을 보여주고 피드백 수집

2라운드: 피드백 기반 최적화

  1. 사용자 피드백에 따라 우선순위가 가장 높은 개선점 결정
  2. input/idea.md 또는 artifacts/prd/prd.md 수정
  3. factory run <stage>를 사용하여 해당 단계부터 재실행
  4. 새 버전 생성 및 테스트

3라운드: 기능 확장

  1. 핵심 목표 달성 여부 평가
  2. 2-3개의 높은 가치 기능 선택
  3. 파이프라인을 통해 생성 및 통합
  4. 지속적인 반복으로 점진적 개선

반복 실전 예시

시나리오: 작업 관리 애플리케이션을 만들고 싶음

1라운드 MVP:

  • 핵심 기능: 작업 생성, 목록 조회, 완료 표시
  • 비목표: 멤버 관리, 권한 제어, 알림
  • 배달 시간: 1일

2라운드 최적화(피드백 기반):

  • 사용자 피드백: 작업에 태그를 추가하고 싶음
  • PRD 수정하여 "태그 분류" 기능 추가
  • UI 단계부터 파이프라인 재실행
  • 배달 시간: 반나절

3라운드 확장(검증 성공 후):

  • 멤버 관리 기능 추가
  • 마감일 알림 추가
  • 작업 댓글 기능 추가
  • 배달 시간: 2일

체크포인트 ✅

각 반복 전에 확인:

  • [ ] 새로운 기능이 핵심 목표와 일치하는가
  • [ ] 새로운 기능에 사용자 요구가 뒷받침되는가
  • [ ] 새로운 기능이 복잡성을 크게 증가시키지 않는가
  • [ ] 명확한 수락 기준이 있는가

고급 기법

기법 5: 세션 분리로 토큰 절약

왜 필요한가

장시간 파이프라인 실행은 컨텍스트가 누적되어 많은 토큰을 소모합니다. 세션 분리 실행을 통해 각 단계가 깨끗한 컨텍스트를 독점적으로 사용하여 사용 비용을 크게 절감할 수 있습니다.

어떻게 하는가

각 체크포인트에서 "새 세션으로 계속" 선택:

bash
# 새 명령줄 창에서 실행
factory continue

시스템이 자동으로:

  1. .factory/state.json을 읽어 상태 복원
  2. 새 Claude Code 창 시작
  3. 다음 실행할 단계부터 계속
  4. 해당 단계에 필요한 입력 파일만 로드

비교:

방식장점단점
동일 세션 계속간단하고 창 전환 불필요컨텍스트 누적, 토큰 소모 큼
새 세션 계속단계별 깨끗한 컨텍스트 독점, 토큰 절약창 전환 필요

권장 방법

대형 프로젝트나 토큰 예산이 제한된 경우 "새 세션으로 계속"을 강력히 권장합니다.

자세한 설명은 컨텍스트 최적화 튜토리얼을 참조하세요.


기법 6: 실패 처리 및 재시도

왜 필요한가

파이프라인 실행 중 입력 부족, 권한 문제, 코드 오류 등으로 인해 실패가 발생할 수 있습니다. 실패를 처리하는 방법을 이해하면 진행 상황을 더 빨리 복구할 수 있습니다.

어떻게 하는가

실패 처리 모범 사례(failure.policy.md:267-274 참조):

  1. 조기 실패: 문제를 가능한 한 빨리 발견하여 후속 단계에서 시간 낭비 방지
  2. 상세 로그: 문제 해결을 위해 충분한 컨텍스트 정보 기록
  3. 원자적 작업: 각 단계의 출력은 원자적이어야 하며 롤백이 용이함
  4. 증거 보존: 재시도 전 실패 결과물을 보관하여 비교 분석에 활용
  5. 점진적 재시도: 재시도 시 단순 반복이 아닌 더 구체적인 지침 제공

일반적인 실패 시나리오:

실패 유형증상처리 방안
출력 누락input/idea.md가 존재하지 않음재시도, 쓰기 경로 확인
범위 확장기능 수 > 7개재시도, MVP로 간소화 요구
기술 오류TypeScript 컴파일 실패타입 정의 확인, 재시도
권한 문제에이전트가 인증되지 않은 디렉토리에 쓰기능력 경계 매트릭스 확인

실패 복구 체크리스트:

  • [ ] 실패 원인이 명확해짐
  • [ ] 수정 방안이 실행됨
  • [ ] 관련 구성이 업데이트됨
  • [ ] 실패한 단계부터 다시 시작

실패는 정상입니다

실패를 두려워하지 마세요! AI App Factory는 완벽한 실패 처리 메커니즘을 설계했습니다:

  • 각 단계는 자동 재시도를 한 번 허용
  • 실패 결과물은 자동으로 artifacts/_failed/에 보관
  • 가장 최근의 성공한 체크포인트로 롤백 가능

실패를 만나면 침착하게 원인을 분석하고 실패 전략에 따라 처리하세요.


강의 요약

이 강의에서는 AI App Factory의 6가지 모범 사례를 소개했습니다:

  1. 명확한 제품 설명: 목표 사용자, 핵심 문제, 핵심 기능 및 제약 조건을 상세히 설명
  2. 체크포인트 신중 확인: 각 단계 완료 후 출력 품질을 검사하여 오류 누적 방지
  3. 비목표 활용한 범위 제어: 하지 않을 기능을 명확히 나열하여 범위 확장 방지
  4. 단계별 반복: 핵심 아이디어를 먼저 검증한 후 사용자 피드백을 기반으로 점진적 확장
  5. 세션 분리로 토큰 절약: 각 체크포인트에서 새 세션을 만들어 사용 비용 절감
  6. 실패 올바르게 처리: 실패 처리 메커니즘을 활용하여 빠른 진행 상황 복구

이러한 모범 사례를 따르면 AI App Factory 사용 경험이 더 원활해지고, 생성된 애플리케이션 품질이 더 높아지며, 개발 효율성이 수 배 향상될 수 있습니다.


다음 강의 예고

다음 강의에서는 **CLI 명령어 참조**를 학습합니다.

배울 내용:

  • factory init 명령어의 모든 매개변수와 옵션
  • factory run 명령어가 지정된 단계에서 시작하는 방법
  • factory continue 명령어가 새 세션을 만들어 계속하는 방법
  • factory status 및 factory list가 프로젝트 정보를 조회하는 방법
  • factory reset이 프로젝트 상태를 재설정하는 방법

부록: 소스 코드 참조

클릭하여 소스 코드 위치 보기

업데이트 시간: 2026-01-29

기능파일 경로줄 번호
제품 설명 기법README.md186-210
체크포인트 메커니즘agents/orchestrator.checkpoint.md98-112
비목표 제어README.md199-203
실패 처리 전략policies/failure.policy.md267-274
컨텍스트 격리policies/context-isolation.md10-42
코드 표준policies/code-standards.md전문

핵심 상수:

  • MAX_RETRY_COUNT = 1: 각 단계에서 기본적으로 자동 재시도를 한 번 허용

핵심 규칙:

  • Must Have 기능 수 ≤ 7개(MVP 원칙)
  • 페이지 수 ≤ 3페이지(UI 단계)
  • 데이터 모델 수 ≤ 10개(Tech 단계)
  • 테스트 커버리지 > 60%(Validation 단계)