개발 시작 지침 문서

https://kickoff.jujin.dev/ai/startup/v1.md 와 https://kickoff.jujin.dev/ai/instructions.md 를 읽고, 서비스 요구와 제약에서 프로젝트 기획을 시작해줘. 확정된 결정과 기존 권한은 보존해줘. 버전 관리 시스템과 저장소 호스팅도 기획에 포함하고, 기존 선택을 유지하며 미결정 사항만 다뤄줘. 카탈로그 글은 내가 요청하거나 결정의 이해에 도움이 될 때만 참고해줘. 불확실성·의존 관계·변경 위험·협업·인수인계·기존 작업 방식·설치 비용을 살펴 추가 에이전트 스킬이나 작업 도구가 필요한지 판단해줘. 추가 스킬 없이 시작하기, Spec Kit, 적합한 대안을 비교하고 적합성·장단점을 설명해줘. 내가 선택을 수락하거나 위임하면 기존 설치 승인 범위 안에서 필요한 구성만 외부 AI 에이전트에 설치·설정하고, 사용 가능 여부를 검증한 뒤 지원하는 방식으로 호출해줘. 기존 설치와 기록을 재사용해줘. 도구를 사용할 수 없으면 수동 진행 방법과 미검증 사항을 알려줘. 사용자가 정할 미결정 선택은 현실적인 선택지·장단점과 프로젝트 요구·제약에 근거한 추천안을 함께 질문해줘. ‘알아서 추천대로 해줘’라고 위임하면 해당 문맥 안에서 재확인 없이 결정·기록하고, 기존 승인 범위까지 진행하며 내부 구현은 스스로 처리해줘. 채택한 프로젝트 기준을 Markdown 체크리스트로 유지하고, 수정 전 관련 항목을 읽고 수정 후 실제 결과를 검증해줘. 세부 절차는 AI 행동 지침을 따라줘. 큰 작업은 작업 파일을 갱신하며 단위별 저장·검증 후 기존 금지 규칙을 지켜 자동 로컬 커밋해줘. 원격 작업이나 저장소·쓰기 도구가 없는 경우는 지침을 따라줘. 완료·중단 시 실제 결과, 적용한 디자인·아키텍처와 주요 결정의 이유·절충점, 사용자 확정과 위임받은 선택의 구분, 검증, 작업 문서 위치, 저장·커밋 상태, 남은 작업을 보고해줘.

목적과 적용 범위

개발 시작 지침 문서, provided by kickoff by jujin. 지침 버전: v1. 리비전: 8. 갱신일: 2026-10-08. 영어가 원본이며, 한국어·일본어는 원본 리비전 8에 대응합니다.

서비스 아이디어를 합의된 프로젝트 기획으로 구체화합니다. 이 문서는 입력 수집과 기획을, AI 행동 지침은 질문·위임·근거·작업 기록·커밋·보고를 담당합니다. 시작 시 필수 사이트 문서는 이 두 개뿐입니다. 기존 프로젝트 지침·확정된 결정과 함께 적용합니다. 사용자 언어로 답하고 상위 지침을 우선합니다.

1. 서비스 맥락 수집하기

지침 버전·리비전과 두 문서의 열람 여부를 짧게 알립니다. 하나라도 접근할 수 없으면 URL을 밝히고 본문 제공을 요청하거나 재시도합니다. 읽지 못한 규칙을 적용했다고 하지 않으며, 가능한 맥락 수집은 계속합니다.

이미 받은 답은 재사용하고, 빠진 입력을 함께 묻습니다.

• 서비스(앱) 이름: 사용자가 준 가칭을 쓰거나 미정으로 남깁니다. 확정된 이름을 지어내지 않습니다.
• 서비스 설명: 누가 사용하고, 어떤 주요 행동을 하며, 어떤 결과를 원하는지 받습니다. 거친 한 문장으로 시작해도 됩니다. 대상·MVP·제외 범위·측정 가능한 성공 조건을 구체화한 뒤 아키텍처를 추천합니다.
• 참고사항: 우선순위와 알려진 제약을 묻습니다. 기존 시스템·디자인, 연동, 민감한 데이터, 접근성, 예산·일정·팀·플랫폼·운영 중 관련 항목을 다룹니다. ‘없음’·‘아직 모름’도 허용합니다. 빈칸은 제약 없음이 아닌 추가 확인 대상으로 봅니다. 비밀정보는 요구하지 않습니다.

설명은 대화의 출발점이며 완성된 명세가 아닙니다. 후속 질문은 관련 항목끼리 조금씩 묶고, 낯선 용어는 해당 서비스의 예시로 설명합니다.

2. 프로젝트의 실제 결정 도출하기

요구사항과 제약에서 필요한 결정 목록을 도출하고 의존 순서대로 다룹니다. 사이트 수록 여부와 관계없이 아키텍처·도구·시각 디자인·운영 방식을 검토합니다. 프로젝트 적합성을 기준으로 동등하게 평가합니다. 카탈로그 분류별 검토표, 전체 색인, 분류마다 하나씩 선택하는 절차는 요구하지 않습니다. 양립 가능한 선택은 함께 쓸 수 있습니다.

버전 관리를 기획에 포함합니다. 변경 이력의 필요를 확인하고 버전 관리 시스템과 저장소 호스팅을 구분하며, 요구사항이 변경을 뒷받침하지 않으면 기존 선택을 유지합니다. 오프라인 작업, 협업·검토, 파일 특성, 연동, 접근 권한·공개 범위, 비용, 운영·백업 책임을 비교합니다. Git과 Git 저장소 호스팅은 함께 쓸 수 있으며, 새 계정이나 공개 저장소를 기본 전제로 삼지 않습니다. 선택한 조합과 이유, 또는 보류·해당 없음의 이유를 기록합니다. 기존 저장소의 소유권·접근 권한·승인 범위를 존중합니다.

사용자가 정할 미결정 항목에는 직접 선택 / 추천받기 / 해당 범위 위임 / 해당 없음 / 보류를 제공합니다. 행동 지침에 따라 현실적인 선택지·장단점과 요구·제약에 근거한 추천안을 함께 질문합니다. ‘알아서 추천대로 해줘’는 해당 문맥의 선택 위임입니다. 재확인 없이 결정·기록하고 기존 승인 범위까지 진행합니다. 사용자가 모르겠다고 하면 일관된 추천 조합을 제안하며, 불확실함이나 침묵은 위임으로 해석하지 않습니다. 보류·해당 없음에는 이유와 재검토 조건을 기록합니다. 승인 범위 안의 내부 구현은 스스로 처리합니다.

카탈로그는 선택적으로 읽는 학습 자료입니다. 사용자가 지정하거나 결정의 이해를 도울 때 특정 글을 참고하며, 인용 전에는 읽습니다. llms.txt·catalog.json·분류 페이지·연결된 모든 글의 조회는 필수가 아닙니다. 선택 자료에 접근하지 못했다는 이유만으로 기획을 중단하지 않습니다. 부족한 근거는 행동 지침에 따라 처리합니다.

3. 소프트웨어 경계 계획하기

합의된 프로젝트 선택 안에서 모듈 책임, 의존 방향, 도메인·데이터 소유권, 공개 계약, 외부 경계, 복구 책임을 정합니다. 프로젝트 규모에서 합의된 요구사항과 품질 기준을 충족하는 가장 단순한 아키텍처를 선택합니다.

SOLID·GRASP를 프로그래밍 방식에 맞게 사용해 응집된 책임, 낮은 결합도, 의존 방향, 명확한 계약을 검토합니다. 이 원칙은 탄탄한 구현과 추후 유지보수를 위한 판단 기준이며, 필수 계층·패턴·클래스 목록이 아닙니다. 구체적인 책임, 위험한 경계, 근거 있는 유지보수 필요가 있을 때만 추상화나 서비스를 추가하고 이점과 비용을 설명합니다. 추측에 의한 복잡성을 피하며 객체지향이나 특정 아키텍처를 강제하지 않습니다.

입력 검증, 권한, 비밀정보 관리, 데이터 수명, 복구 가능한 실패, 운영 관측을 필요한 만큼 계획합니다. 합의된 예산·중단 시간·복구·운영 책임에서 빌드·테스트·릴리스·호환성·롤백·유지보수 절차를 도출합니다. 검증은 요구사항과 위험 경계에 연결합니다.

4. 사용자 경험 계획하기

주요 사용자 흐름, 정보 위계, 탐색 구조, 레이아웃, 서체, 색상·간격, 컴포넌트, 상호작용을 필요한 만큼 정의합니다. 물려받은 디자인 제약을 존중합니다. 초기·로딩·빈 상태·성공·오류·비활성·복구 상태를 포함합니다.

반응형 읽기 순서, 레이블, 키보드 조작, 보이는 포커스, 대비, 대체 텍스트, 동작 감소를 계획합니다. 웹은 WCAG 2.2 AA를 목표로 적용할 검증을 정하고, 네이티브는 플랫폼 지침을 포함합니다. 검증 없이 준수를 선언하지 않습니다. 시각 스타일은 핵심 작업을 지원해야 합니다.

읽기 쉬운 콘텐츠, 명확한 위계, 일관된 컴포넌트와 피드백, 서비스에 맞는 정체성을 갖춘 시각 체계를 만듭니다. 중요한 디자인 선택은 스타일 이름만으로 설명하지 않고 사용자 작업·사용성·기존 제약을 근거로 설명합니다. 디자인의 구체화 수준은 프로젝트 규모에 맞춥니다.

5. 필요한 수익화와 운영 계획하기

수익화가 목표인지 확인합니다. 목표라면 누가 어떤 가치에 비용을 지불하는지, 가격과 무료·유료 범위, 관련 수익·운영 비용 가정, 결제 책임을 정합니다. 수입과 함께 전환·유지율·사용자 신뢰를 고려합니다. 해당하는 경우 명확한 가격·광고 안내, 구매 상태, 결제 실패, 해지, 환불, 지원을 계획합니다. 대안을 비교하고 가정과 확인된 제공업체 조건·법적 요구사항을 구분하며 근거 규칙을 따릅니다. 무료·비상업적 서비스에는 유료 모델을 강요하지 않고 관련 재원·지속 운영 제약을 기록합니다.

6. 필요에 맞는 AI 작업 방식 선택하기

스킬이나 작업 도구를 추천하기 전에 불확실성, 의존 관계, 변경 위험, 협업, 인수인계, 기존 작업 방식, 설치·유지 비용을 평가합니다. 프로젝트 크기만으로 판단하지 않습니다. 기존 방식이 충분한 큰 프로젝트에서도 추가 스킬 없이 시작하는 선택을 동등하게 검토합니다. 작은 변경도 위험이 크면 체계적인 절차가 필요할 수 있습니다.

사이트 안팎에서 관련 선택지만 비교합니다. 예를 들어 Spec Kit은 명세부터 구현까지 추적할 때, Superpowers는 반복 가능한 개발 스킬이 필요할 때, OpenSpec은 변경 제안과 명세의 차이를 기록할 때 검토합니다. 이는 적합성에 대한 가설이며 품질 순위나 필수 설치 목록이 아닙니다. 이점, 절차 비용, 호환성, 재검토 조건을 설명합니다. 채택한 도구를 유지하고 겹치는 작업 방식을 조합하기 전에 역할과 기록의 소유권을 정합니다.

채택·위임된 선택, 승인된 설치, 활성화·호출, 사용할 수 없는 도구는 AI 행동 지침을 따릅니다. 선택한 도구의 산출물을 기획·작업·채택 기준의 기록으로 재사용하며, 필수 내용과 점검을 유지하고 경쟁하는 문서를 만들지 않습니다.

7. 기획 제시 후 개발하기

프로젝트 규모에 맞춰 AI가 기획을 작성합니다.

• 입력받은 이름·설명·맥락, 번호가 있는 요구사항, MVP·비목표, 측정 가능한 완료 조건.
• 관련 제품·소프트웨어·디자인·수익화·운영 결정과 대안·이유·가정·영향·재검토 조건. 제안·채택·거절·대체·보류 상태, 결정 주체, 정확한 위임 범위.
• 채택한 프로젝트 기준과 적용 범위·확인 방법을 담은 Markdown 체크리스트. AI 행동 지침에 따라 유지하고 점검합니다.
• 위험·미확정 질문·차단 사항, 의존 순서에 따른 작업 목록, 요구사항에 연결된 검증 계획.
• 지침 버전·리비전과 실제 참고한 자료만 기록. 카탈로그 조회일·글 ID 목록·카탈로그 사본은 필수가 아닙니다.

전체 기획안을 보여주고 확정받습니다. 개발을 막는 선택은 해결하고, 차단하지 않는 보류 항목도 명시합니다. 기획 승인과 명시적인 개발 요청 후 개발합니다. 기존 승인과 개발 권한은 해당 범위 안에서 유효하므로 다시 묻지 않고 실행합니다. 기획이나 기획 위임만으로 개발·배포·공개·지출이 허가되지는 않습니다.

큰 작업에서는 행동 지침에 따라 작업 파일 갱신, 재개 확인, 단위별 저장·검증과 기존 금지 규칙을 지키는 자동 로컬 커밋을 진행합니다. 완료·중단 시 실제 결과, 적용한 디자인·아키텍처와 주요 결정의 이유·절충점, 결정 주체, 검증, 작업 문서 위치와 저장·커밋 상태, 남은 사항과 다음 작업을 보고합니다.

8. 함께 개선하기

표현 개선, 빠진 주제, 반례, 번역을 이슈나 PR로 제안할 수 있습니다. 선택 참고자료인 기여 지침에 예시·시나리오 검토·버전 정책이 있습니다. 이번 출시 전 개선은 v1 리비전 8로 유지하며, 기존 v1/latest URL과 API schemaVersion 1은 바꾸지 않습니다. 이 문서는 AI를 안내하지만 준수를 보장하지는 않습니다.