목차

코딩 과정을 몰라도 괜찮습니다. 앞에서부터 한 장씩 읽으면, 무엇을 어떻게 말해야 하는지 자연스럽게 익힐 수 있습니다.

이 시스템은 무엇인가

"만들고 싶다"는 한 문장을, 검증된 프로그램으로 데려가는 것 — 그것이 vibecoding의 목적입니다.

vibecoding은 코딩 지식이 전혀 없는 사람도 평소 말하듯 요청하면, 🧭 파일럿이 그 뜻을 알아채고 16명의 전문 페르소나(기획·디자인·개발·검증 담당자)에게 일을 나눠 맡기는 시스템입니다.

당신은 명령어를 외울 필요가 없습니다

이렇게 말하면, 알맞은 담당자가 받습니다.

작동 원리 — 한 줄로

당신 ──말로 요청──▶ 🧭 파일럿 ──적임자에게 배정──▶ 담당 페르소나 ──실행──▶ 결과 보고

시스템은 항상 "누가 · 무슨 일을 · 어떻게" 하는지 한 줄로 먼저 알려줍니다.
예: 💻 개발자가 /코딩으로 T003 작업만 진행합니다.

목표는 단순히 코드를 뱉는 것이 아닙니다. 기획 → 디자인 → 코딩 → 검증 → 배포의 전 과정을 누락·과잉·범위 이탈 없이 통과시키는 것입니다.

누가 쓰나 — 당신은 'CEO'입니다

이 시스템은 '혼자 만들지만 혼자 판단하기는 불안한 사람'을 위해 설계했습니다.

16명은 어떤 사람들인가

핵심 설계: 만드는 사람 · 가능성을 보는 사람 · 평가하는 사람을 일부러 분리했습니다. 만든 사람이 자기 결과를 스스로 합격시키는 일이 생기지 않습니다.

무엇이 좋은가 — 7가지 특징

같은 작업이라도, 이 시스템은 비개발자가 가장 자주 사고 나는 지점을 구조로 막아줍니다.

① 명령어를 몰라도 된다

평소 말로 하면 파일럿이 알맞은 담당자에게 배정하고, 누가·무슨 명령으로·무엇을 하는지 먼저 한 줄로 선언합니다.

② 혼자 만들지 않는다

16명이 서로 견제합니다. 견제 담당(검수자·반론자·감사관 등)은 읽기만 하고 코드를 고치지 않으며, 거부권도 없습니다 — 압박이 아니라 점검입니다.

③ 수정 범위를 대신 제한해 준다 (모듈 격리)

화면 · 로직 · 데이터를 모듈로 격리하고 요청과 직접 관련된 줄만 고쳐, 비개발자가 가장 두려워하는 "고치다 다 망가뜨림"을 구조로 막습니다.

④ 누락도 과잉도 막는다

과잉은 'YAGNI'로(요청 안 한 건 안 만듦), 누락은 '요구원장'으로(말한 요구를 번호로 박제·추적) 막습니다.

⑤ 멈춰도 이어진다

한도에 걸리거나 "그만"이라고 해도 진행 상태가 저장됩니다. "이어서 해줘" 한마디면 정확히 그 지점부터 재개합니다.

⑥ 모든 결정에 회의록이 남는다

중요한 결정은 회의를 거치고 "회의록 없이 결재 없음"이 원칙입니다. "왜 이렇게 결정했지?"를 항상 되짚을 수 있습니다.

⑦ 쓸수록 당신에게 맞춰 자란다

프로젝트가 끝나면 실수·개선점을 모아 "스킬 업데이트 해줘" 한마디로 시스템 자신을 보강합니다. 쓸수록 당신의 습관과 분야에 맞춰지는 도구가 됩니다. (자세히 → 8장)

명령어 사전 — 15개

외울 필요는 없지만 '누가 무슨 일을 하는지' 알면 더 정확히 요청할 수 있습니다. 각 명령어는 ① 한마디 ② 이렇게 말하면 ③ 실제 예시 ④ 결과로 정리했습니다.

디자인 수정은 '격자 + 이름표'로

"여기 좀 더 크게"처럼 막연히 말하면 여러 번 왔다 갔다 하며 시간·비용이 듭니다. 시스템은 화면에 좌표 격자와 이름표를 얹어, 한 번에 정확히 지시하도록 돕습니다.

화면에 이렇게 표시됩니다

• 격자 가로 = 대문자 (A·B·C … H) / 격자 세로 = 숫자 (1·2 … 5) → 위치는 A4처럼
• 버튼·요소 = 소문자 이름표 (a·b·c …) — 각 버튼 옆에 붙습니다

대문자(위치)와 소문자(버튼)가 자연히 갈려서, 헷갈리지 않습니다.

이렇게 말하면 됩니다

다른 예시: "p를 더 크게" / "c를 g 뒤로" / "i를 C2로"

회의 명령어 3개 (상세 사용법은 5장)

명령어는 보통 이 순서로 흐릅니다

외울 필요는 없지만, 큰 그림을 알면 "지금 어디쯤인지" 감이 옵니다.

"○○ 만들고 싶어"
  ↓ 📋 기획자  /아이디어 → /기획  (확인1: 기획 확정)
  ↓ 🎨 디자이너  /디자인  (확인2: 화면 확정)
  ↓ 💻 개발자  /코딩  (모듈 골격 먼저!)
  ↓ 🔧 수리공  /오류수정  (필요할 때)
  ↓ 🕵️ 감사관  /코드리뷰  →  🧹 정리담당  /리팩토링
  ↓ ✅ 검수자  /테스트  →  🗂️ 관리인  /주석
  ↓ ✅ 검수자  /배포
완성 🎉  (멈추면 언제든 "이어서")

회의 참여법

회의는 '결과 중 하나를 고르는 것'이 전부가 아닙니다. 회의 도중 채팅으로 새 기능을 제안하고, 논의를 넓히고, 반대 의견을 낼 수 있습니다. 당신은 관객이 아니라 참여자입니다.

회의는 3종류입니다

회의는 이렇게 흘러갑니다 — 3라운드 토론

• 1라운드 — 초기 입장: 각 담당자가 자기 관점에서 입장을 밝힘 (서로 공격 안 함)
• 2라운드 — 직접 반박: "기획팀, 방금 그 부분은…" 하고 근거를 들어 반박
• 3라운드 — 방어·수정: 반박이 타당하면 부분 수용, 약하면 입장 유지
• 본부장 종결: ⚖️ 수석이 합의/미합의를 정리하고 회의 결과 블록(결정·제외·다음 버전·업무분장) 출력

회의 중 채팅으로 의견 내기

회의는 정해진 보기에서 고르는 설문이 아닙니다. 채팅창에 평소 말로 끼어들면 됩니다. 아래 3가지가 대표적입니다.

상황 ① — 회의 중에 새 기능이 떠올랐다

킥오프 회의 도중

(권장안 도출 후 당신이 결정)

상황 ② — 논의를 더 넓히고 싶다

설계 질문에 답하다가

상황 ③ — 결정에 반대한다

결재 회의에서 본부장이 '배포 승인'을 낸 직후

(반대는 기록되고 다뤄집니다)

반대 의견에 대한 정직한 안내

당신이 가진 3가지 권한

주의할 점 — 꼭 알아둘 경계선

시스템을 잘 쓰려면 '시스템이 안 하는 것'과 '당신이 해야만 하는 것'을 알아야 합니다.

당신이 직접 해야 하는 일

• 결정: 목적·방향·범위·최종 확정은 당신만 할 수 있습니다. 시스템은 추측하지 않고 묻습니다.
• 설계 질문 답하기: 새 기능 착수 시 3~5개 질문이 옵니다. 이건 '승인'이 아니라 설계 입력입니다. AI가 임의로 채우지 않습니다.
• 실제로 한 번 봐주기: "테스트했다"는 보고를 받으면, 진짜 돌아가는지 한 번은 직접 확인해 주세요.

시스템이 일부러 안 하는 것

흔한 오해

완성도를 높이는 노하우 10가지

같은 시스템이라도, 이렇게 쓰면 결과물이 확 좋아집니다.

1. 처음에 "안 만들 것"을 분명히 말하라

   핵심기능 3개만큼이나 "이건 안 만든다"가 중요합니다. 범위가 흐리면 끝이 안 납니다. "이번엔 ○○까지만, 나머지는 다음 버전"이라고 못 박으세요.

2. 모호하면 정의부터

   "멋지게", "잘 되게" 같은 말은 시스템이 다시 묻습니다. 헷갈리는 용어(예: '회원' = 가입자? 결제자?)는 기능으로 바꾸기 전에 뜻을 확정하세요. 미루면 나중에 큰 수정이 됩니다.

3. "알아서 다 해줘"는 신중하게

   전자동은 편하지만, 확인 게이트 2곳과 설계 질문이 당신 입력 지점입니다. 완전 위임하면 AI가 임시 답으로 채우고 'AI 추정'으로 기록합니다 — 중요한 프로젝트일수록 직접 답하는 게 완성도를 높입니다.

4. 에러는 '증상'이지 원인이 아니다

   "이 줄 지워주세요"가 아니라 증상을 그대로 말하세요. "느려요"도 근본 원인을 진단합니다. 당황해서 코드를 직접 지우라고 하면 오히려 더 망가질 수 있습니다.

5. 만든 다음 꼭 거쳐야 할 3단계

   /테스트(실제 돌려보기) → /코드리뷰(기획 일치율 점검) → /배포(출고 게이트). 보고만 받지 말고, 테스트는 한 번 직접도 확인하세요.

6. 멘토의 노트를 무시하지 마라

   멘토는 프로그램이 아니라 당신의 습관을 봅니다. 검증·보안 노트는 비개발자가 가장 자주 사고 나는 지점입니다.

7. "이어서"를 믿어라 — 무리해서 끝내지 마라

   피곤하거나 한도에 걸리면 "그만"이라고 하세요. 무리하게 한 번에 욱여넣다 흐름이 꼬이는 것보다, /이어서로 깔끔히 재개하는 게 완성도가 높습니다.

8. 기록 자산을 신뢰하라

   문서	역할
   requirements.md (요구원장)	당신이 말한 게 빠졌는지 추적하는 기준 — 가끔 열어보세요
   errors.md (오류리포트)	같은 에러 재발 방지
   roadmap.md (확장로드맵)	지금은 안 하지만 버린 건 아닌 아이디어 보관함
   state.json	중단·재개의 원천

9. 기획 전 '사용자 대표'를 정확히 말하라 필수

   "이 프로그램을 쓸 사람은 ○○입니다" 한 줄이 검증 정밀도를 바꿉니다. 👤 사용자대표가 그 눈높이로 테스트·회의에서 판단합니다. 지정 없으면 AI 추정으로 대체됩니다.

10. 전문 분야라면 '자문가·정보원' 투입을 요청하라 필요시

    복지·교육·의료처럼 도메인 지식이 설계를 좌우할 때 "전문가 자문 요청해줘"라고 말하세요. 🔎 자문가(해석·판단) · 📚 정보원(자료 수집)이 자문합니다. 결정권은 없습니다.

쓸수록 당신에게 맞춰 자랍니다

이 시스템의 가장 큰 장점 — 프로젝트를 끝낼 때마다 도구 자체가 당신에게 맞게 개선됩니다. '남이 만든 도구'가 아니라 '나에게 맞춰지는 도구'가 됩니다.

무엇인가요?

프로젝트를 만들다 보면 실수·헷갈린 점·"다음엔 이렇게 하자" 싶은 교훈이 쌓입니다. 흘려보내지 않고, "스킬 업데이트 해줘" 한마디만 하면 시스템이 그 교훈을 vibecoding 자신의 규칙·절차에 반영합니다. 쓸수록 당신의 습관과 분야에 맞춰지는 도구로 자랍니다.

언제 하나요?

① 배포·결재가 끝난 뒤 (가장 자연스러움) / ② 회고를 쓸 때 / ③ 같은 에러가 3번 반복될 때 / ④ 그냥 "스킬 정비하자"고 할 때.

이렇게 진행됩니다

프로젝트 배포를 마친 뒤

이론에 근거해 판단합니다

최근 업데이트로, 시스템이 기술 결정을 '감'이 아니라 내장된 지식 베이스에 근거해 내립니다. "왜 이렇게 만들었나"가 항상 근거에 연결됩니다.

3종류의 내장 지식

이 내용을 당신이 알 필요는 없습니다. 담당자들이 이 근거 위에서 일하므로 결과가 더 일관되고 설명 가능해집니다.

회사 배포·유지보수 수준으로 강화

• 보안·개인정보 우선: 이름·연락처·건강 같은 민감정보를 다루면 최소 수집·접근 통제·저장 보호를 설계 전제로 못 박습니다. (개인정보 취급은 CEO 결재 사안)
• 서버 오류 플레이북: 통신·서버 오류를 한 단계씩 헤매지 않고 전 구간(화면→통신→서버→DB)을 한 번에 추적해 같은 오류 재발을 막습니다.
• 핵심 모듈 패턴: 로그인·DB·대시보드는 검증된 표준 골격을 재사용합니다.

한눈에 보기 · 부록

전형적인 한 사이클

"○○ 만들고 싶어"
  ↓ 📋 /아이디어 → /기획 (확인1)  →  🎨 /디자인 (확인2)
  ↓ 💻 /코딩 → 🔧 /오류수정 → 🕵️ /코드리뷰 → 🧹 /리팩토링
  ↓ ✅ /테스트 → 🗂️ /주석 → ✅ /배포  →  완성 🎉
  ↓ 멈추면 → "이어서" / 큰 결정은 → 회의(/킥오프·/점검·/결재) / 끝나면 → "스킬 업데이트"

부록 A — 명령어 빠른 표

기억할 단 3가지