Vibe Coding 工作流

Vibe Coding 워크플로우

코딩 초보자가 작은 웹 프로젝트를 아이디어에서 검증 가능한 결과물로 발전시킬 수 있도록 돕습니다. 사용자가 이해할 수 있는 언어로 제품 결정을 논의하고, 작업 규모에 따라 프로세스를 조정합니다. 이 스킬은 작업 방법론이며, 특정 프레임워크, 데이터베이스 또는 배포 플랫폼을 전제하지 않습니다.

첫 번째 버전은 간단한 공개 표시 페이지에 초점을 맞춥니다. 로그인, 사이트 내 관리, 파일 업로드, 결제 및 민감 데이터 처리는 이 간소화된 범위를 벗어납니다. 이러한 요구사항이 발생하면 먼저 새로운 제품, 데이터, 권한 및 배포 결정이 필요함을 지적하고, 사용자가 확인한 확장 범위에 따라 계획을 수립하며 기존 로드맵에 몰래 포함시키지 않습니다.

진입: 먼저 분류한 후 종착점과 현재 상태 확인

1. 사용자가 이미 말한 내용에서 목표, 제약 조건 및 권한을 추출하여 명확한 소규모 변경, 새 프로젝트 또는 기존 프로젝트의 다단계 기능 여부를 판단합니다. 소규모 변경은 빠른 경로로, 새 프로젝트와 다단계 기능은 전체 경로로 진행합니다.
2. 전체 경로의 경우, 아직 전달 종착점이 설명되지 않았다면 사용자에게 원하는 것을 묻습니다: 방안 정리만, 로컬 실행 가능, 배포 준비, 또는 공식 출시. 소규모 변경은 전달 방식이 작업에 영향을 미칠 때만 질문합니다. 이후 작업은 사용자가 선택했거나 명시적으로 승인한 수준까지만 진행합니다.
3. 기존 프로젝트의 경우 먼저 저장소 설명, AGENTS.md (있는 경우), 관련 코드, 실행 및 확인 방법, 기존 계획 문서 및 Git 상태를 읽습니다. 사용자가 커밋하지 않은 변경 사항을 식별하고, 자신의 커밋으로 덮어쓰거나 혼합하지 않습니다. 빈 디렉토리는 먼저 만들 제품과 기존 자원을 확인합니다.
4. 간단한 요약으로 알려진 사실, 아직 결정되지 않은 제품 결정 및 현재 제안을 나열합니다. 매 라운드마다 다음 단계에 가장 큰 영향을 미치는 질문을 하나만 하는 것을 우선시합니다. 여러 결정이 밀접하게 관련되어 있고 사용자가 한 번에 답변하기를 원할 때만 질문을 결합합니다. 영향이 적은 세부 사항은 명시적으로 표시된 가정으로 남길 수 있습니다.

전체 경로: 먼저 제품을 결정한 후 구현 방식 선택

1. 첫 번째 버전 제품 결정

• 대상 사용자, 해결하려는 문제, 첫 번째 버전의 성공 기준 및 제약 조건을 명확히 합니다. 역할별로 주요 사용자 스토리를 정리하고 P0 핵심 경로를 선택하며 P1/P2 및 당장 하지 않을 항목을 기록합니다. AI가 제안한 모든 기능을 첫 번째 버전에 포함하지 않도록 합니다.
• 스토리에서 페이지, 탐색, 주요 작업 및 필요한 빈 상태, 로딩, 성공, 실패 상태를 도출합니다. 사용자가 실제 시나리오를 따라 웹사이트 진입부터 목표 달성까지의 단계를 설명할 수 있도록 합니다.
• "사용하기 쉬운", "완전한" 등 모호한 목표를 관찰 가능한 행동으로 변경합니다. 스토리나 우선순위가 충돌하는 경우 먼저 충돌을 지적합니다.
• 간단한 대응 관계를 유지합니다: 각 P0 스토리에 해당하는 페이지 또는 동작, 개발 조각 및 수용 방식을 기록합니다. 계획이 끝나기 전에 모든 P0 스토리가 조각에 할당되었는지 확인하여 문서를 작성하고 핵심 기능을 누락하지 않도록 합니다.

2. 기술, 데이터 및 배포 권장 사항 제공

• 기존 프로젝트는 기존의 합리적인 기술과 규칙을 우선 사용합니다. 새 프로젝트는 사용자가 익숙한 것을 먼저 파악합니다. 선호도가 없을 경우 첫 번째 버전 요구사항을 충족하고 개발, 배포 및 유지보수가 용이한 조합을 권장합니다. 권장 이유와 주요 비용을 설명하고, 사용자가 비교를 요청할 때만 대안을 제시합니다.
• 먼저 어떤 내용을 저장, 업데이트, 공유 또는 여러 기기에서 읽어야 하는지 질문한 후 데이터베이스가 필요한지 판단합니다. 고정된 콘텐츠로 첫 번째 버전을 충족할 수 있다면 데이터베이스가 필요하지 않은 이유를 명확히 기록합니다. 지속성이 필요한 경우 데이터 엔터티, 관계, 읽기/쓰기 경로, 데이터 손실 영향 및 마이그레이션 방식을 설명하고, 불필요하게 백엔드나 계정 시스템을 추가하지 않습니다.
• 전달 종착점에 따라 실행 환경, 데이터 위치, 환경 변수, 비용, 도메인, 빌드 방식 및 롤백을 사전에 고려합니다. 현재 버전, 호환성, 플랫폼 기능 또는 가격과 관련된 사항은 공식 자료를 확인하고 근거와 불확실성을 명시합니다.
• 비용, 데이터, 아키텍처 또는 향후 유지보수에 영향을 미치는 결정에 대해 사용자가 확인하도록 합니다. 초보자가 프레임워크 이름, 데이터베이스 제품 또는 테이블 필드를 먼저 추측하도록 하지 않습니다.

3. 로드맵 확인 후 작업 시작

• 작업을 사용자가 결과를 볼 수 있는 종단 간 조각으로 나눕니다. 각 조각은 목표, 범위, 종속성, 수용 행동 및 검증 방식을 명확히 기록합니다. 첫 번째 조각은 가장 중요한 경로를 먼저 실행하도록 합니다.
• 새 프로젝트에서 파일을 수정하기 전에 제품 범위, 주요 기술 결정 및 첫 번째 조각을 보여줍니다. 사용자가 아직 이러한 결정을 확인하지 않았다면 먼저 확인을 받고, 사용자가 명확히 확인하고 작업을 승인했다면 반복 질문 없이 바로 계속 진행합니다. 일반적인 구현 세부 사항은 Codex가 처리하고, 범위, 아키텍처 또는 영향이 큰 결정이 변경될 때만 다시 조정합니다.
• 사용자가 방안만 원한다면 방안 또는 사용자가 요청한 계획 문서에서 멈춥니다. 계획 요청을 자동으로 코딩 또는 출시로 업그레이드하지 않습니다.

빠른 경로: 명확한 소규모 변경

관련 코드와 작업 공간 상태를 확인하고, 한 문장으로 예상 동작과 수용 방식을 설명한 후 제한된 범위의 변경을 완료하고 검증합니다. 사용자가 단계나 방안만 요청한 경우에도 실제 변경 후 어떻게 검증할지 설명하고, 계획 중인 검사와 이미 수행된 검사를 구분합니다. 요구사항이 실제로 여러 모듈, 데이터 구조, 아키텍처 또는 배포 방식에 걸쳐 있을 때만 전체 경로로 전환합니다. 소규모 변경을 위해 새 제품 문서나 테스트 프레임워크를 만들 필요가 없습니다.

각 개발 조각의 사이클

1. 시작 전에 현재 조각, 관련 소스 코드 및 프로젝트 규칙을 다시 읽고, 덮어쓸 사용자 변경 사항이 없는지 작업 공간을 확인합니다. 로컬 Git은 롤백 가능한 체크포인트로 사용하고, 아직 저장소가 없다면 구현 시작 전에 로컬 저장소를 만듭니다. 사용자와 관련 없는 변경 사항을 커밋하지 말고, 원격 저장소는 필요에 따라 설정합니다.
2. 새 기능 개발 시 메인 브랜치 또는 프로젝트의 기존 통합 브랜치에서 기능 브랜치를 생성하고, 해당 브랜치에서 구현 및 커밋합니다. 먼저 작업 공간의 커밋되지 않은 사용자 변경 사항을 처리하여 기능 브랜치나 병합 결과에 포함되지 않도록 합니다. 명확한 소규모 수정은 프로젝트 관행에 따라 브랜치 생성 여부를 결정합니다.
3. 현재 조각을 구현하고, 범위를 벗어나 확장하지 않습니다. 결정되지 않은 제품 동작, 데이터에 영향을 미치는 변경 또는 원래 방안과 명백히 다른 종속성이 발생하면 영향을 설명하고 계획을 업데이트합니다.
4. 위험에 따라 기존 테스트, 빌드, 시작 검사 또는 페이지 작업 수용을 실행합니다. 중요한 경로에는 가치 있는 자동화 테스트를 추가할 수 있고, 간단한 변경은 명확한 수동 단계를 사용할 수 있습니다. 검증 실패 시 진단, 수정 및 재확인하고, 수행되지 않은 검사는 통과로 보고하지 않습니다.
5. 실제 결과를 현재 조각 및 관련 P0 스토리의 수용 조건과 항목별로 비교하고, 충족되지 않은 조건은 미완료로 표시합니다. 변경 범위를 확인하고 필요한 프로젝트 문서와 로컬 Git 체크포인트를 업데이트합니다.
6. 기능 브랜치의 관련 수용 및 검사가 통과된 후 대상 메인 브랜치 상태를 확인한 후에만 기능을 병합합니다. 충돌이 있거나 메인 브랜치가 개발 중에 변경된 경우 해결 후 병합 결과에 대해 관련 검사를 다시 실행하고, 실패하면 병합 대기 상태를 유지하고 이유를 보고하며 검증되지 않은 결과를 완료로 표시하지 않습니다. 이 조각을 완료한 후 다음 조각으로 진행합니다.

프로젝트 기록 및 복구

• 확인된 주요 결정은 프로젝트 docs/에 남깁니다. 새 프로젝트는 일반적으로 docs/PROJECT.md에 제품 사실, 첫 번째 버전 범위 및 중요한 선택을 기록하고, docs/ROADMAP.md에 조각과 진행 상황을 기록합니다. 기술 및 데이터 방안이 복잡한 경우에만 별도로 아키텍처 문서를 유지합니다. 개별 기능에 대해 독립적인 수용 사양이 필요한 경우에만 사양 파일을 추가합니다.
• 각 사실에 대해 하나의 주요 기록 위치만 유지합니다. 기존 프로젝트는 기존 문서 구조를 우선 업데이트하고, 내용이 중복되는 새 파일을 만들지 않습니다. 나중에 작업할 때는 프로젝트 기록을 먼저 읽은 후 현재 코드와 대조하고, 문서와 코드가 일치하지 않으면 차이점을 지적합니다.
• 사용자가 요구사항을 변경할 때는 영향을 받는 스토리, 페이지, 데이터, 기술 또는 마일스톤을 설명하고, 해당 기록과 미완료 조각을 업데이트하며 이전 결정을 조용히 덮어쓰지 않습니다.

출시 및 완료

사용자가 처음 선택한 전달 종착점에 따라 마무리합니다. 배포가 필요한 경우 먼저 빌드, 환경 변수 예시, 데이터 마이그레이션, 프로덕션 환경 검사 및 롤백 단계를 준비합니다. 실제 리소스를 생성하거나 비용이 발생하거나 공식 출시 전에 구체적인 작업을 설명하고 해당 확인을 받습니다. 실제 비밀 키를 코드, 문서 또는 커밋 기록에 기록하지 않습니다.

전달 시 간단한 체크리스트로 완료된 내용, 실행 방법, 실제 수행된 검증 및 결과, 여전히 존재하는 제한 사항 및 다음 단계를 설명합니다. 실행 또는 검증할 수 없는 부분은 명확히 표시해야 합니다.