다른 파일을 불러올 수도 있습니다. @README 처럼 @ 뒤에 파일 경로를 쓰면 그 파일 내용이 함께 읽힙니다.
"반드시 매번" 지켜야 하는 검사는 CLAUDE.md보다 훅(hook)이 확실합니다. CLAUDE.md는 안내이고, 훅은 자동으로 실행되는 장치입니다.
4.5바이브공장장 홈페이지의 실제 예
이 홈페이지의 루트 CLAUDE.md는 짧습니다. 핵심만 줄이면 이렇습니다.
코드
@AGENTS.md
# 작업 흐름
- 에이전트: layout-designer(디자인) → frontend / backend(구현) → qa(검증)
- 코드를 바꾸면 보고 전에 qa 에이전트를 자동으로 실행
- 자동 점검 3단계: 응답 끝날 때 / 커밋 전 / 푸시 후
첫 줄 @AGENTS.md 는 다른 AI 도구와 함께 쓰는 안내 파일을 불러옵니다. 그리고 운영자의 개인 전역 파일(~/.claude/CLAUDE.md)에는 "항상 존댓말로 답한다" 한 줄이 들어 있습니다. 그래서 어느 프로젝트를 열어도 AI가 존댓말로 답합니다.
4.6잘 안 지켜질 때
/context 를 입력하면 지금 읽힌 파일 목록이 보입니다. 내 CLAUDE.md가 빠져 있지 않은지 확인하세요.
규칙을 더 구체적으로 바꾸고, 서로 부딪치는 규칙이 없는지 살펴보세요.
/memory 로 파일을 바로 열어 고칠 수 있습니다.
4.7AI에게 이렇게 말해 보세요
person“CLAUDE.md를 한국어로 바꾸고, 우리가 정한 규칙도 추가해 줘”
person“방금 알려 준 규칙을 CLAUDE.md에 추가해 줘”
person“CLAUDE.md에 오래됐거나 서로 부딪치는 규칙이 없는지 점검해 줘”
CLAUDE.md가 "어떻게 일할지"를 알려 준다면, 이제 "무엇을 해 달라고" 잘 말하는 법이 남았습니다. 5장에서는 프롬프트 기본기를 알아보겠습니다.
1부 · AI와 일하기 시작
5장
AI에게 일 잘 시키는 법, 프롬프트 기본기
같은 AI라도 어떻게 부탁하느냐에 따라 결과가 달라집니다. 바로 써먹는 요청의 재료 네 가지.
AI에게 "홈페이지 만들어 줘"라고 하면 그럴듯한 페이지가 나옵니다. 하지만 내가 원하던 것과는 어딘가 다릅니다. AI가 부족해서가 아니라, 내 머릿속 그림을 AI가 볼 수 없기 때문입니다.
프롬프트는 AI에게 하는 부탁입니다.
5.1좋은 요청의 네 가지 재료
1. 목표: 무엇을 만들려는지, 왜 필요한지
2. 맥락: 누가 쓰는지, 지금 어떤 상태인지
3. 조건: 꼭 지켜야 할 것, 하지 말아야 할 것
4. 완료 기준: 어떻게 되면 "끝"인지
예를 들어 볼게요.
코드
아쉬운 요청:
신청 폼 만들어 줘
좋은 요청:
수강 신청 폼을 만들어 줘.
이름, 휴대폰, 이메일을 받고, 모두 필수야.
모바일에서 주로 쓰니까 입력칸을 크게 해 줘.
제출하면 결제 페이지로 넘어가면 완료야.
두 번째 요청은 길지만 AI가 되물을 게 없습니다. 결과도 한 번에 원하는 모습에 가까워집니다.
5.2잘 시키는 요령
한 번에 하나씩: 큰 일은 쪼개서 부탁하세요. 화면 하나, 기능 하나씩 완성해 나가면 문제가 생겨도 어디서 생겼는지 바로 보입니다.
계획 먼저: 복잡한 작업은 "바로 만들지 말고 계획부터 보여 줘"라고 하세요. 계획 단계에서 방향을 고치는 게 다 만든 뒤에 고치는 것보다 훨씬 쉽습니다.
예시 붙이기: 참고할 사이트 캡처, 원하는 데이터 모양(JSON7장 예시), 에러 메시지 원문을 그대로 붙여 넣으세요. 말로 설명하는 것보다 정확합니다.
되묻게 하기: "헷갈리는 게 있으면 먼저 물어봐"라고 덧붙이면, AI가 짐작으로 채우는 대신 질문합니다.
5.3결과가 이상할 때
"다시 해 줘" 대신 무엇이 다른지 말하세요. "버튼이 너무 작아. 화면 폭의 절반 정도로"처럼요.
대화가 길어져 엉키면, 새 대화에서 지금까지의 결론만 정리해 다시 시작하는 편이 나을 때가 많습니다.
AI가 "완료했습니다"라고 해도 직접 눌러 보세요. 확인은 사람 몫입니다.
5.4AI에게 이렇게 말해 보세요
person“내 요청에서 빠진 정보가 있으면 먼저 질문해 줘”
person“이 기능, 바로 만들지 말고 단계별 계획부터 보여 줘”
person“방금 만든 걸 내가 직접 확인하려면 어디를 눌러 보면 돼?”
요청 하나가 아니라 서비스 전체를 설명해야 할 때는 어떻게 할까요? 6장에서는 AI에게 주는 설계도, PRD를 알아보겠습니다.
1부 · AI와 일하기 시작
6장
PRD, 만들 것을 글로 먼저
서비스 전체를 AI에게 맡기기 전에, 무엇을 누구를 위해 어디까지 만들지 한 장에 적어 봅니다.
5장5장에서 좋은 요청에는 목표, 맥락, 조건, 완료 기준이 필요하다고 했습니다. 기능 하나라면 한 번의 요청으로 충분합니다. 그런데 서비스 전체를 만든다면요? 매번 처음부터 설명할 수는 없습니다.
이때 쓰는 것이 PRD(Product Requirements Document), 제품 요구사항 문서입니다. "무엇을, 누구를 위해, 어디까지 만들지"를 한 장에 적어 둔 글입니다.
6.1바이브코딩에서 특히 중요한 이유
AI는 빈칸을 추측으로 채웁니다. 요청이 모호하면 그럴듯하지만 내가 원하지 않은 기능이 생기고, 필요한 기능은 빠집니다.
방향이 흔들리지 않습니다: 대화가 길어져도 PRD로 돌아와 확인하면 됩니다.
쪼개기 쉬워집니다: 핵심 기능 목록이 곧 작업 순서가 됩니다.
"다 됐다"를 판단할 수 있습니다: 완료 기준이 적혀 있으니까요.
6.21페이지 PRD, 다섯 칸이면 충분합니다
1. 문제: 지금 무엇이 불편한가
2. 대상: 누가 쓰는가
3. 핵심 기능: 꼭 있어야 하는 것 (3~5개)
4. 하지 않을 것: 이번엔 만들지 않는 것
5. 완료 기준: 어떻게 되면 "끝"인가
6.3예시: 스터디 모임 출석부
코드
문제: 스터디 출석을 단톡방에서 세다 보니 매번 헷갈린다.
대상: 10명 안팎의 스터디 모임장과 멤버
핵심 기능:
- 모임장이 날짜별 모임을 만든다
- 멤버가 휴대폰으로 "출석" 버튼을 누른다
- 모임장이 날짜별 출석 현황을 본다
하지 않을 것: 회비 결제, 채팅, 앱 설치
완료 기준:
- 휴대폰 브라우저에서 출석 버튼이 동작한다
- 같은 날 두 번 출석하면 한 번만 기록된다
- 배포된 주소로 멤버가 접속할 수 있다
이 정도면 AI가 화면, 데이터 표, 필요한 기술을 스스로 제안할 수 있습니다. 데이터는 Supabase14장에 저장하고, 화면은 Next.js12장로 만드는 식입니다.
6.4AI와 함께 PRD 쓰기
처음부터 잘 쓸 필요 없습니다. 생각나는 대로 말하고, AI에게 정리를 맡기세요.
아이디어를 두세 줄로 말합니다.
AI에게 "PRD 다섯 칸으로 정리하되, 모르는 건 먼저 질문해 줘"라고 합니다.
질문에 답하고, "하지 않을 것"을 함께 정합니다.
완성된 PRD를 docs/prd.md 같은 파일로 저장합니다.
6.5PRD에서 작업으로
PRD가 생기면 다음 단계가 자연스럽게 이어집니다.
작업 목록: "이 PRD를 하루 단위 작업으로 쪼개 줘"
CLAUDE.md4장 연결: CLAUDE.md에 "기능 설계는 docs/prd.md 를 따른다"라고 적어 두면, 새 대화에서도 AI가 설계도를 알고 시작합니다.
한 번에 하나씩: 작업 목록의 첫 줄부터 만들고, 끝날 때마다 Git10장으로 저장합니다.
바이브공장장 수업도 둘째 날 각자 만들 서비스를 정하고 요구사항을 정리합니다. 2주 뒤 무엇이 완성되어 있을지 수업 초반에 정해 두는 셈입니다.
6.6AI에게 이렇게 말해 보세요
person“내 아이디어를 PRD 다섯 칸으로 정리해 줘. 모르는 건 먼저 물어봐”
person“이 PRD에서 첫 버전에 꼭 필요 없는 기능을 골라 줘”
person“이 PRD를 작업 목록으로 쪼개고, 첫 작업부터 시작하자”
이제 무엇을 만들지 정했으니, AI와 대화할 때 계속 마주칠 언어를 배울 차례입니다. 7장에서는 JSON을 알아보겠습니다.
2부 · AI의 언어와 도구
7장
JSON, 바이브코딩에서 가장 먼저 만나는 글자
중괄호와 따옴표가 가득한 그것. 코드를 몰라도 JSON만 읽을 줄 알면 AI와의 대화가 훨씬 쉬워집니다.
이게 JSON(제이슨)입니다. JavaScript Object Notation의 줄임말인데, 이름은 잊으셔도 됩니다.
7.1왜 알아야 하나요?
AI에게 코딩을 맡기면 직접 코드를 쓸 일은 줄지만, JSON은 계속 눈에 띕니다.
설정 파일: package.json, 그리고 다음 장에서 다룰 MCP8장 설정도 JSON입니다.
데이터: 서버가 화면에 보내 주는 데이터, 외부 서비스(API15장)가 돌려주는 응답 대부분이 JSON입니다.
에러 확인: "응답이 이상해요"를 해결하려면 JSON을 읽을 줄 알아야 어디가 틀렸는지 보입니다.
읽을 수만 있으면 AI가 만든 결과를 확인하고, 원하는 걸 정확히 요청할 수 있습니다.
7.2규칙은 딱 여섯 가지
1. { } 중괄호는 "묶음"입니다. 한 가지 대상에 대한 정보를 모읍니다.
2. 안에는 "이름": 값 쌍을 씁니다. 이름은 항상 큰따옴표로 감쌉니다.
3. 쌍과 쌍 사이는 쉼표로 나눕니다. 마지막 쌍 뒤에는 쉼표를 쓰지 않습니다.
4. 값이 글자면 큰따옴표("바이브공장장"), 숫자면 따옴표 없이(2) 씁니다.
5. 참/거짓은 true, false. 값이 없으면 null입니다.
6. [ ] 대괄호는 "목록"입니다. 여러 개를 순서대로 나열합니다.
터미널에서 claude mcp add 명령으로 추가해도 됩니다. 서버마다 설치 방법이 조금씩 다르니, 서비스의 안내 문서를 AI에게 보여 주고 "이거 연결해 줘"라고 하는 게 가장 빠릅니다.
8.4주의할 점
권한: MCP로 연결하면 AI가 그 서비스에서 실제로 행동합니다. 운영 DB처럼 중요한 곳은 읽기 전용으로 연결하거나, 실행 전에 꼭 확인을 거치세요.
출처: 아무 MCP 서버나 설치하지 말고, 서비스 공식 서버나 믿을 만한 곳의 것을 쓰세요.
8.5AI에게 이렇게 말해 보세요
person“Supabase MCP를 이 프로젝트에 연결하는 방법 알려 줘”
person“지금 연결된 MCP 서버와 쓸 수 있는 도구 목록 보여 줘”
person“이 MCP 서버가 공식 서버인지 확인해 줘”
MCP가 AI에게 도구를 준다면, 9장의 Skills는 AI에게 일하는 방법을 가르칩니다.
2부 · AI의 언어와 도구
9장
Skills, AI에게 우리만의 일하는 방식을 가르치기
매번 같은 설명을 반복하고 있다면, 그 설명을 스킬로 만들어 두세요.
AI에게 일을 시키다 보면 같은 말을 반복하게 됩니다. "배포할 때는 이 순서로, 환경변수는 이렇게, 끝나면 이걸 확인해." 매번 설명하기도 번거롭고, 내가 깜빡 빠뜨리면 AI도 빠뜨립니다.
Skills(스킬)는 이런 설명을 파일로 적어 두고, 필요할 때 AI가 스스로 꺼내 읽게 하는 기능입니다.
9.1스킬은 폴더 하나, 문서 하나
스킬의 핵심은 SKILL.md라는 문서 하나입니다. Claude Code에서는 프로젝트의 .claude/skills/스킬이름/SKILL.md 위치에 둡니다.
코드
---
name: deploy
description: 사이트를 배포하거나 배포 설정을 바꿀 때 사용
---
1. 배포 전에 npm run qa 로 테스트를 통과시킨다.
2. 환경변수는 대시보드에서만 바꾼다.
3. 배포 후 주요 페이지가 열리는지 확인한다.
맨 위 --- 사이의 name과 description은 스킬의 이름표이고, 그 아래가 실제 매뉴얼입니다. 필요하면 참고 문서나 스크립트를 같은 폴더에 함께 넣을 수 있습니다.
9.2필요할 때만 꺼내 읽습니다
AI는 평소에 스킬의 이름표만 알고 있다가, 요청이 설명과 맞으면 그때 본문을 읽습니다. "배포해 줘"라고 하면 deploy 스킬을 펼쳐 보고 적힌 순서대로 일하는 식입니다. 그래서 스킬을 여러 개 만들어 두어도 AI가 헷갈리지 않습니다. /deploy 처럼 이름을 직접 불러 실행할 수도 있습니다.
코드는 공유됩니다: GitHub11장에 올리고, 팀원과 나누고, AI에게 보여 줍니다. 키가 코드에 있으면 함께 퍼집니다.
환경마다 값이 다릅니다: 내 컴퓨터에서는 테스트 키, 실제 사이트에서는 진짜 키. 코드는 그대로 두고 값만 바꾸면 됩니다.
교체가 쉽습니다: 키를 바꿔야 할 때 코드를 고칠 필요가 없습니다.
16.3NEXT_PUBLIC_, 공개 표시
Next.js에서 이름이 NEXT_PUBLIC_으로 시작하는 환경변수는 브라우저로 전달됩니다. 누구나 볼 수 있다는 뜻입니다.
공개해도 되는 값: 토스 결제위젯의 클라이언트 키처럼, 원래 브라우저에서 쓰도록 만든 키 → NEXT_PUBLIC_을 붙입니다.
비밀 값: Supabase14장 비밀 키, 결제 시크릿 키, 관리자 비밀번호 → 절대 붙이지 않습니다.
16.4.env.local은 GitHub에 올리지 않습니다
.gitignore 파일에 적힌 파일은 Git이 무시합니다. Next.js 프로젝트는 보통 처음부터 .env 파일들이 여기에 들어 있지만, 꼭 한 번 확인하세요.
코드
# .gitignore
.env*
16.5배포할 때는?
.env.local은 내 컴퓨터에만 있으니, 배포17장 서버에는 따로 알려 줘야 합니다. Vercel이나 Netlify 같은 호스팅 서비스는 대시보드에 환경변수 입력 칸이 있고, 직접 운영하는 서버라면 서버의 환경 설정에 넣습니다. 이름은 .env.local과 똑같이 맞추세요.
16.6자주 하는 실수 세 가지
비밀 키에 NEXT_PUBLIC_: 편하려고 붙였다가 키가 전 세계에 공개됩니다.
코드에 직접 붙여 넣기: "일단 테스트만" 하려다 그대로 올라가는 경우가 많습니다.
.env 파일을 GitHub에: 한 번 올라간 키는 커밋을 지워도 기록에 남을 수 있습니다. 새어 나갔다면 즉시 그 키를 폐기하고 새로 발급하세요.
16.7AI에게 이렇게 말해 보세요
person“이 키는 브라우저에 공개해도 되는 키야?”
person“코드에 직접 들어간 키가 있는지 찾아서 환경변수로 옮겨 줘”
person“.env.local이 GitHub에 올라가지 않게 되어 있는지 확인해 줘”
17장에서는 드디어 내 컴퓨터 밖으로, 사이트를 세상에 내놓는 배포를 알아보겠습니다.
5부 · 세상에 내놓기
17장
배포, 내 컴퓨터 밖으로
localhost에서만 열리던 사이트를 누구나 접속할 수 있게 만드는 과정입니다.
npm run dev를 실행하고 브라우저에서 localhost:3000을 열면 사이트가 보입니다. 뿌듯하지만, 이 주소는 내 컴퓨터에서만 열립니다. 친구에게 링크를 보내도 친구 컴퓨터에는 그 사이트가 없습니다.
배포는 내 사이트를 24시간 켜져 있는 인터넷 서버에 올려서, 누구나 접속할 수 있게 만드는 일입니다.
코드
지금 http://localhost:3000 → 나만 볼 수 있어요
배포 후 https://vibegongzzang.kr → 누구나 볼 수 있어요
17.1배포하는 두 가지 길
1. 호스팅 서비스 이용
Vercel, Netlify 같은 서비스에 GitHub11장 저장소를 연결하면, 코드를 올릴 때마다 알아서 빌드하고 배포해 줍니다. 서버 관리를 신경 쓰지 않아도 되어서 처음 시작하기에 좋습니다.
2. 내 서버에 직접 올리기
클라우드 서버를 빌려 직접 운영하는 방법입니다. Docker로 실행 환경을 통째로 포장하고, Caddy 같은 웹 서버로 HTTPS를 붙입니다. 자유도가 높은 대신 관리할 것이 늘어납니다.
HTTPS 연결: 주소창에 자물쇠가 뜨도록 보안 인증서를 붙입니다. 호스팅 서비스와 Caddy는 대부분 자동으로 해 줍니다.
17.3배포 전 체크리스트
내 컴퓨터에서 npm run build가 성공하는지
필요한 환경변수를 서버에 모두 넣었는지
테스트 키를 실제 키로 바꿔야 하는지 (결제 등)
배포 후 주요 페이지를 하나씩 열어 봤는지
휴대폰으로도 확인했는지
17.4자주 하는 실수 세 가지
환경변수 빠뜨림: 내 컴퓨터에선 되는데 배포하면 안 된다면, 십중팔구 서버에 환경변수가 없는 경우입니다.
빌드를 안 해 보고 배포: 개발 모드에서는 그냥 넘어가던 타입 오류가 빌드에서 걸리기도 합니다. 배포 전에 한 번 빌드해 보세요.
주소를 localhost로 고정: 코드 곳곳에 http://localhost:3000이 박혀 있으면 배포 후 동작하지 않습니다. 사이트 주소도 환경변수로 관리하세요.
17.5AI에게 이렇게 말해 보세요
person“배포 전에 빌드 돌려서 오류 있는지 확인해 줘”
person“이 프로젝트 배포에 필요한 환경변수 목록 정리해 줘”
person“배포된 사이트의 주요 페이지가 잘 열리는지 점검해 줘”
배포가 끝나면 이제 남은 건 이름입니다. 18장에서는 내 사이트에 도메인을 연결하는 방법을 알아보겠습니다.
5부 · 세상에 내놓기
18장
도메인 연결하기
숫자로 된 서버 주소 대신, 기억하기 쉬운 이름을 내 사이트에 붙이는 방법입니다.
배포17장를 마치면 사이트에 주소가 생깁니다. 호스팅 서비스가 준 긴 주소이거나, 서버의 숫자 주소(IP)일 수도 있습니다. 누군가에게 알려 주기엔 불편하죠. 그래서 도메인을 연결합니다.
18.1도메인이 뭔가요?
인터넷 주소록에 등록한 이름입니다. 컴퓨터는 서로를 숫자로 된 IP 주소로 찾는데, 사람이 외우기엔 어렵습니다. 그래서 이름을 붙이고, DNS라는 인터넷 주소록이 이름을 숫자로 바꿔 줍니다.
코드
vibegongzzang.kr
↓ DNS가 찾아 줘요
203.0.113.10 (서버 주소 예시)
18.2연결은 세 단계
1. 도메인 사기: 도메인 판매 업체에서 원하는 이름을 삽니다. 보통 기간 단위로 비용을 내고 연장합니다.
2. DNS 레코드 입력: 도메인 관리 화면에서 "이 이름은 이 서버로 가라"는 기록을 적습니다.
3. HTTPS 확인: 주소창에 자물쇠가 뜨는지 확인합니다. 호스팅 서비스나 Caddy가 보안 인증서를 자동으로 받아 오는 경우가 많습니다.
18.3DNS 레코드, 이것만 알면 됩니다
A 레코드: 도메인 → 서버의 IP 주소. 내 서버에 직접 연결할 때 씁니다.
CNAME 레코드: 도메인 → 다른 도메인 이름. 호스팅 서비스가 준 주소에 연결할 때 자주 씁니다.
TXT 레코드: 메모. "이 도메인 주인이 맞다"를 증명할 때 씁니다.
18.4www는 따로?
vibegongzzang.kr과 www.vibegongzzang.kr은 서로 다른 이름입니다. 둘 다 연결하고, 한쪽으로 모이게(리다이렉트) 설정해 두면 깔끔합니다.
18.5자주 하는 실수 세 가지
값을 추측해서 입력: 한 글자만 틀려도 연결되지 않습니다. 안내 화면의 값을 그대로 복사하세요.
기다리지 않고 계속 수정: DNS 변경이 퍼지는 데는 시간이 걸립니다. 몇 분 만에 되기도 하지만 길면 하루 이상 걸리기도 하니, 입력했다면 잠시 기다려 보세요.
자동 연장을 꺼 둠: 도메인이 만료되면 사이트가 통째로 사라진 것처럼 보입니다. 결제 수단과 자동 연장을 꼭 확인하세요.
18.6AI에게 이렇게 말해 보세요
person“이 DNS 설정 화면 캡처 보고, 뭘 입력해야 하는지 알려 줘”
person“호스팅 안내 문서대로 필요한 레코드 정리해 줘”
person“도메인이 제대로 연결됐는지 확인하는 방법 알려 줘”
도메인까지 연결하면 진짜 내 서비스가 완성됩니다. 6장6장에서 적어 둔 완료 기준을 하나씩 확인해 보세요.
마지막 19장에서는 만드는 내내 만나게 될 친구, 에러 메시지 읽는 법을 알아보겠습니다.
5부 · 세상에 내놓기
19장
에러 메시지 읽는 법
빨간 글씨는 실패가 아니라 힌트입니다. 세 군데만 보면 원인이 보입니다.
바이브코딩을 하다 보면 빨간 글씨를 정말 자주 만납니다. 처음엔 겁이 나지만 걱정하지 마세요.
19.1에러는 이렇게 생겼습니다
코드
TypeError: Cannot read properties of undefined (reading 'title')
at CohortCard (page.tsx:42:18)
at ...
길고 복잡해 보여도, 볼 곳은 세 군데뿐입니다.
19.2세 군데만 보세요
1. 종류: 맨 앞의 TypeError. 어떤 유형의 문제인지 알려 줍니다.
2. 내용: Cannot read properties of undefined (reading 'title'). "비어 있는(undefined) 것에서 title을 꺼내려 했다"는 뜻입니다. 데이터가 아직 안 왔거나, 이름이 틀렸을 가능성이 큽니다.
3. 위치: page.tsx:42:18. page.tsx 파일의 42번째 줄, 18번째 글자입니다. 아래로 이어지는 at 목록 중에서 내가 만든 파일 이름을 찾으세요. node_modules처럼 남이 만든 코드는 대부분 건너뛰어도 됩니다.
19.3어디서 확인하나요?
터미널1장: npm run dev를 실행한 창입니다. 서버 쪽 에러와 빌드 에러가 여기에 나옵니다.
브라우저 콘솔: 화면에서 F12(맥은 Cmd + Option + I)를 누르고 Console 탭을 엽니다. 화면 쪽 에러가 여기에 나옵니다.
네트워크 탭: 같은 개발자 도구의 Network 탭입니다. API 요청과 응답 번호(15장15장 참고)를 볼 수 있습니다.
화면이 하얗게 나오는데 아무 설명이 없다면, 이 세 곳을 차례로 열어 보세요.
19.4자주 보는 에러 몇 가지
Module not found: 파일이나 패키지를 못 찾았습니다. 경로에 오타가 있거나 npm install을 안 했을 때 납니다.
is not defined: 만들지 않은 이름을 썼습니다. 오타를 먼저 의심하세요.
404, 500: 페이지나 API 문제입니다. 응답 번호로 어느 쪽 문제인지 가늠합니다.
19.5자주 하는 실수 세 가지
에러 없이 "안 돼요"만: AI도 사람도 에러 전문이 없으면 추측할 수밖에 없습니다.
여러 곳을 한꺼번에 수정: 무엇 때문에 고쳐졌는지(또는 망가졌는지) 알 수 없게 됩니다. 한 번에 하나씩 고치세요.
읽지 않고 새로고침만: 같은 에러는 같은 이유로 다시 납니다.
19.6AI에게 이렇게 말해 보세요
"이 에러 전문이야. 원인과 해결법 알려 줘" (에러를 통째로 붙여 넣기)
"방금 로그인 버튼을 눌렀더니 이 에러가 났어" (무엇을 하다가 났는지 함께)
person“고친 다음, 같은 에러가 다시 안 나게 테스트도 추가해 줘”
19.7시리즈를 마치며
터미널과 Claude Code로 시작해 CLAUDE.md와 PRD, JSON과 MCP와 Skills, Git과 GitHub, Next.js와 Supabase, 배포와 도메인, 그리고 에러 읽는 법까지 19장을 함께 왔습니다. 하나하나는 작은 개념이지만, 모두 모이면 "AI와 함께 서비스를 만들고 세상에 내놓는" 전체 흐름이 됩니다.
여기까지 따라오셨다면, "코드를 몰라서 못 만든다"는 말은 이제 반만 맞습니다. 나머지 반은 직접 만들어 보면서 채워집니다. 머릿속에만 있던 서비스, 이제 AI와 함께 만들어 보세요.
혼자 하기 막막하다면 바이브공장장에서 함께 만들어요. 2주 동안 아이디어 하나를 실제로 배포되는 서비스로 완성합니다.
