시작하기
프로킷이란
한눈에
프로킷(pro-kit)은 Claude Code나 Codex 같은 AI 에이전트가 일할 개발 환경을 프로젝트에 설치해 주는 키트예요. 설치하면 에이전트가 전문 개발자처럼 정해진 순서와 검사를 지키며 일해요. 사용자는 평소 말로 요청하고 확인 질문에 답하면 돼요.
무엇이 들어 있나요
pro-kit 저장소는 새 프로젝트를 만들어 주는 생성기예요. 안에는 템플릿 두 개와 학습 자료가 있어요.
| 들어 있는 것 | 하는 일 |
|---|---|
| prokit-next-neon(새 탭) | 운영 DB가 Neon인 프로젝트용 템플릿 |
| prokit-next-supabase(새 탭) | 운영 DB가 Supabase인 프로젝트용 템플릿 |
| 튜토리얼 | 코드를 몰라도 프롬프트를 붙여 넣으며 서비스를 만들어 보는 단계별 안내 |
두 템플릿은 앱 코드 구성이 같고 운영 DB만 달라요. 고르는 법은 템플릿 고르기에 있어요.
템플릿은 Better-T-Stack으로 만든 Next.js 풀스택 앱 위에 설치돼요. 설치하면 앱 뼈대에 다음이 더해져요.
프로젝트 전용 스킬 8개
구현 에이전트와 리뷰 에이전트
작업마다 확인 결과를 남기는 dev-cycle
스타일 추천부터
DESIGN.md까지 이어지는 UI/UX 흐름내 컴퓨터의 Vercel CLI로 develop과 운영에 배포하는 스크립트와 절차
에이전트가 쓰는 공식 스킬과 플러그인(그때의 최신판)
필요할 때 더하는 선택 스킬 묶음(
ops,motion,mobile)
코드
projects/ ├── pro-kit/ 이 저장소 (생성기). 여기서 요청한다 └── my-app/ 새 프로젝트. 개발은 여기서 한다
누구나 전문 개발자처럼
전문 개발자와 초보자는 코드를 쓰는 속도보다 일하는 순서와 확인하는 습관이 달라요. AI 에이전트에게 그냥 맡기면 이 단계를 자주 건너뛰어요. 프로킷은 그 습관을 스킬, 에이전트, 자동 검사로 프로젝트에 넣어 두었어요. 사용자가 절차를 몰라도 에이전트가 같은 절차를 따라요.
| 전문 개발자라면 | 프로킷에서 에이전트가 하는 일 |
|---|---|
| 만들기 전에 요구사항과 화면을 정리해요 | 스펙과 화면 설계(브리프)를 먼저 보여 주고 확인을 받은 뒤 구현해요 |
| 디자인 시스템을 정하고 지켜요 | 첫 화면을 만들기 전에 어울리는 디자인 스타일 1~3위를 추천받아 DESIGN.md 파일 하나에 정해 둬요. 새 세션도 이 파일을 따라요 |
| 직접 돌려 보고 나서 끝났다고 해요 | 타입 검사, 테스트, 화면 스크린샷을 실제로 실행한 증거(명령과 결과)가 모여야 audit을 통과해요. 브라우저 콘솔과 서버 로그의 오류는 0개여야 해요 |
| 다른 사람에게 코드 리뷰를 받아요 | 구현에 참여하지 않은 읽기 전용 리뷰 에이전트(prokit-reviewer)가 코드, 보안, DB를 따로 살펴봐요. 필요 이상으로 복잡한 설계는 ponytail-review가 걸러 내요 |
| 보안과 데이터를 지켜요 | 서버에서 로그인과 데이터 주인을 확인하고, 계정 두 개로 남의 데이터에 접근할 수 없는지 테스트해요. DB는 마이그레이션 파일로만 바꿔요 |
| 배포는 확인하며 해요 | 배포 전 검사를 통과해야만 배포해요. 비밀값이 새지 않게 막고, 되돌리는 명령을 알려 줘요 |
| 프로젝트 맥락을 기억해요 | 용어집(GLOSSARY.md)과 프로젝트 소개(docs/domain/project.md)를 작업마다 읽고 고쳐요. 새 세션에서 프로젝트를 다시 설명하지 않아도 돼요 |
사용자는 확인 질문에 답하고 결과를 확인해요. 릴리스와 배포처럼 되돌리기 어려운 일만 직접 결정해요.
그냥 AI에게 맡길 때와 다른 점
| 흔히 생기는 일 | 프로킷에서 |
|---|---|
| 사용자가 결과를 보기도 전에 다음 기능으로 넘어가요 | 대조표의 마지막 행이 사용자 확인이라서 확인해야 라운드가 끝나요. 이 행은 N/A(해당 없음)로 넘길 수 없어요 |
| 테스트를 돌리지 않고 "완료했습니다"라고 해요 | 대조표의 모든 칸에 실행한 명령과 결과가 있어야 audit이 통과해요. 통과하기 전에는 완료라고 하지 않아요 |
| 로그인만 확인하고 다른 사람 데이터를 보여 주는 API | 데이터 주인은 로그인 세션에서만 알아내요. 계정 두 개로 서로의 데이터에 접근할 수 없는지 테스트해요 |
| 운영 DB 구조를 바로 바꿔 데이터를 잃어요 | 마이그레이션 파일을 만들어 로컬에서 먼저 적용해요. 컬럼 삭제와 이름 변경은 두 번에 나눠요. 운영 DB는 요청할 때만 다뤄요 |
| 매번 다른 모양, 기본 컴포넌트 그대로인 화면 | 첫 화면 전에 디자인 스타일을 골라 DESIGN.md로 정해 두고, 코드 전에 화면 설계를 확인받아요. 만든 뒤에는 스크린샷과 디자인·접근성 점수로 검사해요 |
| 자기가 짠 코드를 자기가 검토해요 | 읽기 전용 prokit-reviewer가 따로 검토하고, 리뷰 칸은 그 결과로만 채워요 |
| 새 세션마다 프로젝트를 다시 설명해야 해요 | 시작할 때 AGENTS.md, GLOSSARY.md, docs/domain/project.md를 읽어요. 라운드마다 두 문서에 바꿀 내용이 있는지 확인해 고쳐요 |
| 막힌 단계를 조용히 건너뛰어요 | 실행하지 못한 검사는 blocked: 사유로 남기고 "부분 완료"로 보고해요. 그런 라운드는 사용자가 동의해야 끝나요 |
| 콘솔 오류를 "브라우저 확장 탓"이라며 넘겨요 | 오류 예산이 0이에요. 확장 프로그램 탓처럼 보여도 깨끗한 브라우저에서 원인을 가려내고, 사용자 브라우저에도 보이면 고쳐요 |
| 쓰지 않을 기능과 복잡한 구조까지 만들어요 | 스펙에 "만들지 않는 것" 절을 두고, 계획과 리뷰마다 ponytail-review로 필요 이상으로 복잡한 설계를 덜어 내요 |
| 미룬 리뷰 지적이 닫힌 기록 속에 묻혀요 | 라운드를 닫기 전에 미룬 지적을 tasks/todo.md의 백로그(할 일 목록)로 옮겨요 |
배포하면서 로컬 .env의 비밀값까지 올리거나 .env.production에 운영 키를 적어 둬요 | .vercelignore가 로컬 .env를 빼고, 배포 값은 Vercel 환경변수에만 둬요. 배포 스크립트의 검사를 통과해야 배포해요. 커밋 전에는 pnpm dev-cycle secrets가 커밋할 변경에서 비밀값을 찾아요 |
자세히
지원하는 에이전트: Claude Code, Codex, Antigravity, Grok Build예요. 도구마다 읽는 파일과 여는 명령은 지원하는 에이전트, Claude Code와 Codex의 조작 차이는 Claude Code와 Codex에 있어요.
스킬이 결과를 바꾸나요: 같은 요청을 스킬이 있을 때와 없을 때로 나눠 비교했어요. 규칙을 지킨 비율이 작업 진행(
prokit-dev-cycle)은 27%에서 93%로, 화면 설계(prokit-ui)는 12%에서 100%로 올랐어요. 골라 둔DESIGN.md가 있으면 목표 디자인과 팔레트가 맞는 비율이 71%에서 99%로 올랐어요. 측정 방법은 검증 결과에 있어요.만든 것: 프로킷으로 만든 프리셋 11개(랜딩페이지 4개, 앱 화면 5개, 클론 코딩 2개)를 프로킷 사이트에서 모든 페이지까지 열어 볼 수 있어요.
라이선스: MIT(새 탭)예요. 상업 이용·유료 고객 개발·수정·재판매를 허용하며 저작권 표시와 허가문을 보존해야 해요. 사이트의 홍보용 제작 표시는 선택 사항이고, 외부 구성 요소(새 탭)에는 원래 조건을 적용해요.