바이브 코딩시작 A to Z
설치 → 계획 → 실행 → 오류 해결 → 확장
초보자도 따라가는 실전 개발 루프
한눈에 보는 실전 루트맵
초보자가 오늘 해야 할 핵심 과정
노드 설치부터 Cursor 실행, 계획 수립, 오류 해결, 운영 확장까지 “내가 지금 뭘 해야 하는지”를 먼저 잡고 본문으로 들어갑니다.
카드 펼치기 → 해야 할 일 요약 확인
시작01목표 정하기
작게 만들 앱 1개를 고른다
눌러서 요약 보기 ↓
목표 정하기
처음부터 로그인·결제·대형 서비스를 만들지 말고, 브라우저에서 바로 확인할 수 있는 작은 웹앱 목표를 한 문장으로 적습니다.
본문에서 자세히 보기환경02Node.js 설치
npm이 되는지 먼저 확인한다
눌러서 요약 보기 ↓
Node.js 설치
Windows 터미널에서 npm -v가 나오는지 확인하고, 안 되면 Node.js LTS를 설치한 뒤 터미널을 새로 열어 재확인합니다.
본문에서 자세히 보기도구03Cursor 준비
설치·로그인·폴더 열기
눌러서 요약 보기 ↓
Cursor 준비
Cursor를 설치하고 프로젝트 폴더를 소문자 영문 경로로 만든 뒤, 채팅·파일·터미널 위치를 익힙니다.
본문에서 자세히 보기설계04계획 먼저
Plan으로 작업 순서를 잡는다
눌러서 요약 보기 ↓
계획 먼저
바로 만들라고 하지 말고 README나 작업 계획을 먼저 만들게 해서, 파일 구조와 변경 범위를 사람이 확인합니다.
본문에서 자세히 보기실행05Agent 실행
Keep/Undo로 결과를 고른다
눌러서 요약 보기 ↓
Agent 실행
AI가 만든 변경을 무조건 믿지 말고 Keep/Undo 흐름으로 저장할 것과 되돌릴 것을 나눕니다.
본문에서 자세히 보기검증06실행 확인
npm install → dev → 화면 확인
눌러서 요약 보기 ↓
실행 확인
터미널 명령으로 앱을 띄우고 브라우저에서 직접 확인합니다. 포트 충돌이나 오류는 원문 그대로 다시 전달합니다.
본문에서 자세히 보기수정07오류 해결
로그를 복사해 다시 요청한다
눌러서 요약 보기 ↓
오류 해결
빨간 오류 화면, 터미널 로그, 어떤 버튼을 눌렀는지까지 함께 전달하면 AI가 훨씬 정확하게 고칩니다.
본문에서 자세히 보기운영08확장·운영
DB·배포·데이터를 붙인다
눌러서 요약 보기 ↓
확장·운영
작은 앱이 돌아간 뒤에 데이터베이스, 배포, 자동화, 운영 루틴을 붙여서 실제 서비스에 가깝게 키웁니다.
본문에서 자세히 보기이 가이드에서 다루는 내용
시작 전략
무엇부터 만들지
개발 환경
Node.js·npm·Cursor
AI 작업 루프
Plan·Agent·Allow List
터미널/실행
npm install·dev·build
오류 해결
로그·재현·검증
확장/운영
DB·배포·데이터 주권
⚠️ 안내: Cursor·Node.js·Next.js·AI 코딩 도구의 화면과 정책, 요금제는 수시로 바뀔 수 있습니다. 본문은 2026년 기준 초보자용 실전 가이드이며, 실제 설치·배포 전에는 공식 문서를 함께 확인하세요.
비개발자가 239개 앱을 만든 출발점
이 글은 “AI에게 코드를 맡기면 끝”이 아니라, 비개발자가 질문·계획·실행·오류 해결을 반복해 실제 웹앱을 쌓는 방법을 정리하는 출발점입니다.
189종 이상의 공개 앱과 239개 이상 제작 경험을 “대단한 결과”가 아니라 초보자가 따라 할 수 있는 반복 시스템으로 해석합니다. 이 섹션을 끝내면 왜 웹앱부터 시작해야 하는지, 앞으로 어떤 실습 루프를 확인할지 설명할 수 있어야 합니다.
실전 맥락: 큐레이터 단비는 자신의 큐레이터 단비 사이트와 24시간 30분마다 AI 이미지가 올라가는 사례, 유튜브 채널 분석기 같은 실제 결과물을 먼저 보여주며 “하루아침에 된 것이 아니다”라고 전제합니다.
핵심 개념
- 1바이브 코딩은 코드를 외워 치는 공부가 아니라, 내가 원하는 결과를 말하고 AI가 만든 결과를 검토한 뒤 오류를 다시 전달하는 협업 방식입니다.
- 2큐레이터 단비 사례의 신뢰 근거는 단순 숫자가 아니라 이미지 자동 업로드, 유튜브 분석기, 메모 앱, 정리 페이지처럼 서로 다른 앱을 같은 루프로 계속 만든 경험입니다.
- 3초보자가 처음 얻어야 할 능력은 멋진 코드를 쓰는 능력이 아니라 “현재 상태를 말하고, AI 결과를 확인하고, 다음 질문을 만드는 능력”입니다.
- 4이 글의 목표는 화면 조작을 따라 하는 것에 그치지 않고, 글을 읽은 뒤에도 스스로 문제를 헤쳐 나갈 운영 습관을 만드는 것입니다.
근거와 판단 포인트
- •작은 성공을 반복해 수익과 사업으로 연결하는 관점까지 초반에 제시해야 완성도 높은 가이드의 방향이 선명합니다. 첫 앱은 돈 버는 앱이 아니라 사업 실험을 가능하게 하는 작은 성공이어야 합니다.
- •진행 흐름에는 “비개발자”, “앱 239개 이상”, “웹앱이 가장 쉽다”, “트러블슈팅”, “추천 프로그램”이 초반부터 반복됩니다.
- •큐레이터 단비는 자신의 사이트에 올라간 약 189종 앱과 30분마다 AI 이미지가 업로드되는 기능을 보여주며 실행 결과의 방향을 먼저 제시합니다.
- •“하루아침에 된 것이 아니다”라는 표현은 깊이 있는 포스팅에서 특히 중요합니다. 구매자는 마법이 아니라 누적 가능한 훈련법을 배워야 합니다.
적용 순서와 확인 기준
- 1결과물부터 확인하기
실행
큐레이터 단비가 보여주는 실제 사이트·앱 사례를 기능 단위로 적습니다. 예: 자동 이미지 업로드, 유튜브 채널 분석, 메모 저장.이유
초보자는 기술명보다 “내가 만들 수 있는 결과물”을 먼저 알아야 실행 동기가 생깁니다.정상 확인
내가 만들고 싶은 앱을 최소 3개 기능명으로 말할 수 있습니다. - 2웹앱을 첫 목표로 고정하기
실행
모바일 앱, 데스크톱 앱, 자동화 스크립트가 아니라 브라우저에서 열리는 웹앱을 첫 프로젝트로 선택합니다.이유
웹앱은 Cursor, Next.js, localhost, Vercel 배포 흐름이 연결되어 결과 확인이 빠릅니다.정상 확인
“처음에는 내 컴퓨터 브라우저에서만 보이고, 배포 후 외부 공개된다”를 이해합니다. - 3작업 루프를 문장으로 외우기
실행
계획 요청 → 파일 생성 → Keep/Undo → 실행 → 오류 복사 → 수정 요청 → 브라우저 확인을 노트에 적습니다.이유
이 루프가 뒤 섹션 전체의 공통 골격입니다.정상 확인
막혔을 때 “다시 처음부터”가 아니라 어느 단계에서 멈췄는지 말할 수 있습니다. - 4기대치를 조정하기
실행
첫날 목표를 “완벽한 서비스”가 아니라 “내 컴퓨터에서 실행되는 작은 앱”으로 잡습니다.이유
초보자는 기대치가 너무 크면 오류 한 번에 포기합니다.정상 확인
오늘의 완료 기준을 한 문장으로 적었습니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 첫 목표 | 로컬에서 실행되는 작은 웹앱 1개를 완성 | 처음부터 로그인, 결제, 모바일 앱, 대규모 서비스를 한 번에 요구 |
| AI 활용 | AI가 제안한 결과를 사람이 검토하고 다음 질문으로 개선 | AI가 완료라고 하면 화면 확인 없이 믿기 |
| 작업 태도 | 오류와 질문 로그를 작업 자산으로 저장 | 오류를 실패로 보고 창을 닫기 |
막히기 쉬운 지점과 해결
“나는 비개발자라 못 한다”
원인: 코딩을 문법 암기로 오해합니다.
해결: 문법보다 결과 설명, 오류 전달, 검증 루프를 먼저 훈련합니다.
첫 프로젝트가 너무 큼
원인: 보여준 사례를 한 번에 따라 하려 합니다.
해결: 메모 앱처럼 입력·저장·목록·수정이 있는 작은 앱부터 시작합니다.
읽기만 하고 끝남
원인: 자기 프로젝트에서 직접 실행하지 않았습니다.
해결: 각 섹션마다 적용 완료 기준을 체크하고 다음 단계로 갑니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓내가 왜 웹앱부터 시작하는지 설명할 수 있다.
- ✓내 첫 앱의 기능을 입력, 저장, 목록, 수정 같은 작은 단위로 쪼갰다.
- ✓AI에게 줄 첫 요청문과 오늘의 완료 기준을 적었다.
- ✓오류가 나와도 오류 원문을 복사해 질문하는 과정이라는 것을 이해했다.
적용 과제: 나의 첫 웹앱 목표 정리
진행
- •만들고 싶은 웹앱 이름을 임시로 정합니다.
- •필수 기능 3개만 적습니다.
- •오늘 완료 기준을 “localhost에서 화면 확인”처럼 검증 가능한 문장으로 씁니다.
확인
- •기능 범위가 3개 이하입니다.
- •외부 공개가 아니라 로컬 실행을 첫 목표로 잡았습니다.
- •다음 섹션에서 npm 확인으로 넘어갈 준비가 되었습니다.
첫 요청 예시 나는 비개발자이고 Cursor로 첫 웹앱을 만들고 싶어. 목표는 [앱 이름]이고 필수 기능은 [기능1], [기능2], [기능3]이야. 처음에는 내 컴퓨터 localhost에서 실행되는 수준까지만 만들고 싶어. 바로 코딩하지 말고 필요한 준비물과 전체 진행 순서를 초보자 기준으로 먼저 설명해줘.
왜 첫 프로젝트는 웹앱이 좋은가
웹앱은 설치 부담이 적고 브라우저에서 바로 결과를 볼 수 있어 비개발자가 AI 코딩의 성공 경험을 만들기 가장 좋은 출발점입니다.
웹앱·로컬 실행·배포의 차이를 구분하고, 왜 첫 프로젝트를 브라우저에서 확인되는 작은 앱으로 제한해야 하는지 이해합니다.
실전 맥락: 진행 흐름에서 큐레이터 단비는 웹앱이 가장 쉽고 빠르게 결과를 볼 수 있다고 말하면서도, localhost는 내 컴퓨터에서만 보인다는 제한을 후반에 다시 설명합니다.
핵심 개념
- 1웹앱은 주소를 열어 UI를 확인하므로 “코드가 돌아가는지”를 눈으로 판단하기 쉽습니다.
- 2처음에는 localhost에서만 보이는 앱을 만들고, 나중에 Vercel 같은 배포 서비스를 통해 외부 공개로 넘어갑니다.
- 3버튼, 입력폼, 목록, 상세 페이지, DB 저장처럼 웹앱 기능은 작은 조각으로 나누기 쉬워 AI에게 지시하기 좋습니다.
- 4모바일 앱보다 앱스토어 심사, 기기 설정, 빌드 환경 부담이 적어 초보자가 오류 루프를 배우기 좋습니다.
근거와 판단 포인트
- •웹앱은 브라우저에서 즉시 피드백을 받기 쉽기 때문에 버튼 클릭, 입력, 새로고침 결과를 보며 개선할 수 있습니다.
- •큐레이터 단비는 “웹앱이 초보자에게 가장 쉽다”는 취지로 시작합니다.
- •후반 진행 흐름에서는 localhost:3000을 다른 사람에게 보내도 접속할 수 없고 배포가 필요하다고 설명합니다.
- •Next.js, React, SQLite를 첫 스택으로 잡은 것도 브라우저 기반 실습을 빠르게 만들기 위한 선택입니다.
적용 순서와 확인 기준
- 1웹앱의 결과 화면 상상하기
실행
내 앱을 브라우저에서 열었을 때 보일 첫 화면을 한 문장으로 씁니다.이유
AI는 추상적인 “좋은 앱”보다 화면에 보일 요소를 더 잘 구현합니다.정상 확인
제목, 버튼, 입력칸, 목록 중 최소 2개를 말할 수 있습니다. - 2로컬과 배포 구분하기
실행
노트에 “localhost=내 컴퓨터 전용”, “배포 URL=외부 공유 가능”이라고 적습니다.이유
초보자가 가장 자주 착각하는 부분입니다.정상 확인
카톡으로 localhost를 보내도 친구가 못 본다는 점을 이해했습니다. - 3첫 기능을 CRUD 중 하나로 줄이기
실행
처음 만들 기능을 저장(Create), 보기(Read), 수정(Update), 삭제(Delete) 중 하나나 둘로 제한합니다.이유
범위가 작아야 오류 원인을 찾을 수 있습니다.정상 확인
기능 요구가 한 화면 안에 들어갑니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 확인 방식 | 브라우저에서 버튼 클릭, 입력, 새로고침까지 직접 확인 | 코드가 생성됐다는 말만 듣고 완료 처리 |
| 공유 방식 | 로컬 검증 후 Vercel 등으로 배포 | localhost 주소를 실제 서비스 주소처럼 공유 |
| 첫 범위 | 랜딩 페이지 + 작은 앱 1개 | 관리자, 로그인, 결제, 모바일 앱을 동시에 요구 |
막히기 쉬운 지점과 해결
친구가 내 localhost에 접속하지 못함
원인: localhost는 내 컴퓨터 자신을 가리키는 주소입니다.
해결: 배포 섹션에서 Vercel URL을 만든 뒤 공유합니다.
AI가 너무 많은 파일을 만듦
원인: 첫 요구가 넓고 추상적입니다.
해결: “한 페이지, 한 기능, 로컬 DB”처럼 제한합니다.
결과가 맞는지 판단 못 함
원인: 정상 화면 기준을 미리 정하지 않았습니다.
해결: 실행 전 기대 화면을 간단히 적습니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓웹앱과 모바일 앱의 시작 난이도 차이를 설명할 수 있다.
- ✓localhost와 배포 URL 차이를 이해했다.
- ✓첫 기능을 한 화면에서 테스트 가능한 범위로 줄였다.
- ✓다음 섹션에서 개발 환경 확인으로 넘어갈 준비가 됐다.
적용 과제: 첫 웹앱 화면 설계
진행
- •앱 첫 화면 제목을 정합니다.
- •사용자가 누를 버튼 1개와 입력할 값 1개를 적습니다.
- •로컬에서 확인할 정상 결과를 적습니다.
확인
- •브라우저에서 확인할 요소가 명확합니다.
- •외부 공개는 나중 단계로 미뤘습니다.
- •AI에게 설명할 화면 문장이 준비됐습니다.
웹앱 목표 설명 템플릿 첫 화면 제목: [예: 나만의 링크 메모장] 사용자 입력: [예: 제목, 메모, URL] 버튼: [예: 저장하기] 정상 결과: 저장 후 아래 목록에 제목과 링크가 보인다. 제한: 처음에는 localhost에서만 실행하고 배포/로그인/결제는 하지 않는다.
Windows에서 npm 동작 확인
개발 시작 전 필수 선행 작업은 CMD에서 npm 명령이 정상 출력되는지 확인하는 것입니다. npm이 안 되면 Cursor가 코드를 만들어도 앱을 실행할 수 없습니다.
CMD를 열어 npm 설치 상태를 확인하고, 정상 출력과 실패 출력을 구분합니다. 실패하면 Node.js 설치 단계로 넘어가야 한다는 판단을 스스로 내릴 수 있어야 합니다.
실전 맥락: 진행 흐름에서 큐레이터 단비는 Windows 검색창에서 CMD를 열고 npm을 입력합니다. npm 안내가 나오면 다음 단계로 가고, 안 되면 Node.js 설치가 필요하다고 설명합니다.
핵심 개념
- 1npm은 Node Package Manager로, Next.js와 React 프로젝트에 필요한 패키지를 설치하고 실행 스크립트를 돌리는 도구입니다.
- 2CMD는 Windows 기본 명령 프롬프트이며, Cursor 터미널을 쓰기 전 시스템에 npm이 잡히는지 확인하는 가장 단순한 창입니다.
- 3정상일 때는 npm 사용법이나 버전 관련 안내가 길게 나오고, 실패할 때는 “npm을 인식할 수 없습니다”류의 메시지가 나옵니다.
- 4이 확인은 선택이 아니라 입장권입니다. 여기서 실패하면 이후 npm install, npm run dev가 모두 막힙니다.
근거와 판단 포인트
- •npm 확인은 무조건 필수 선행 점검이며, 오류 예시는 npm is not recognized 또는 command not found처럼 명령이 인식되지 않는 상태입니다.
- •진행 흐름에는 CMD 검색 → 명령 프롬프트 실행 → npm 입력 → npm 안내 확인 순서가 나옵니다.
- •큐레이터 단비는 npm이 Windows 기본 도구가 아니며 Node.js 설치가 필요할 수 있다고 설명합니다.
- •초보자에게 “지금 화면이 정상인지 실패인지 구분”시키는 것이 뒤의 오류 해결보다 먼저입니다.
적용 순서와 확인 기준
- 1CMD 열기
실행
Windows 검색창에 cmd를 입력하고 “명령 프롬프트”를 실행합니다.이유
Cursor 내부 문제가 아니라 컴퓨터 전체에서 npm이 되는지 먼저 확인하기 위해서입니다.정상 확인
검은 창에 C:\Users\... 형태의 입력 대기 줄이 보입니다. - 2npm 입력
실행
프롬프트에 npm을 입력하고 Enter를 누릅니다.이유
npm 명령이 PATH에 연결되어 있는지 확인합니다.정상 확인
npm usage/help 안내가 여러 줄 나오면 정상입니다. - 3버전도 확인
실행
가능하면 npm -v, node -v도 입력해 숫자 버전을 확인합니다.이유
버전 숫자는 설치가 정상적으로 잡혔다는 가장 짧은 증거입니다.정상 확인
10.x.x, v20.x.x 같은 숫자가 출력됩니다. - 4실패 메시지 저장
실행
실패했다면 오류 문장을 그대로 복사하거나 캡처합니다.이유
다음 Node.js 설치 또는 PATH 문제 해결 때 AI에게 줄 증거가 됩니다.정상 확인
오류 원문을 메모에 붙여넣었습니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| npm 정상 | usage 안내나 버전 숫자를 확인하고 다음 단계로 이동 | 정상 출력인지 모른 채 창을 닫기 |
| npm 실패 | Node.js LTS 설치 후 새 CMD에서 재확인 | Cursor를 먼저 설치하고 무작정 프로젝트 생성 |
| 오류 질문 | 오류 원문 전체를 AI에게 붙여넣기 | “안 돼요”만 입력하기 |
막히기 쉬운 지점과 해결
npm is not recognized
원인: Node.js가 설치되지 않았거나 PATH가 반영되지 않았습니다.
해결: Node.js LTS를 설치하고 CMD를 완전히 닫았다가 새로 엽니다.
설치했는데도 npm 안 됨
원인: 기존 CMD 창이 설치 전 환경을 그대로 들고 있습니다.
해결: 새 CMD를 열고 필요하면 Windows를 재부팅합니다.
PowerShell에서는 오류가 나는데 CMD는 됨
원인: PowerShell 실행 정책과 npm.ps1 이슈일 수 있습니다.
해결: 초보자는 먼저 CMD에서 확인하고, 이후 오류 원문을 Cursor에 전달합니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓CMD를 직접 열어 npm을 입력했다.
- ✓정상 출력과 실패 출력을 구분했다.
- ✓npm -v 또는 node -v 버전을 확인했다.
- ✓실패 시 Node.js 설치 단계로 가야 함을 이해했다.
적용 과제: npm 상태 증거 남기기
진행
- •CMD에서 npm을 입력합니다.
- •npm -v와 node -v를 입력합니다.
- •결과를 한 줄 메모로 남깁니다.
확인
- •npm 또는 버전 숫자 출력이 확인됐습니다.
- •실패했다면 오류 원문을 저장했습니다.
- •다음 설치/검증 단계로 넘어갈 판단이 섰습니다.
확인 명령 npm npm -v node -v AI에게 물어볼 문장 CMD에서 npm 확인을 했는데 아래 결과가 나왔어. [결과 전체 붙여넣기] 이게 정상인지, 아니라면 Node.js 설치/PATH/터미널 재시작 중 무엇을 해야 하는지 초보자 기준으로 알려줘.
Node.js 설치와 터미널 재시작
npm이 없다면 Node.js LTS를 설치하고 새 터미널에서 다시 확인해야 합니다.
Node.js 공식 사이트에서 LTS Windows Installer를 선택하고, 설치 후 CMD를 새로 열어 npm/node 버전을 검증합니다.
실전 맥락: 실제 진행 흐름은 Google에서 Node.js 설치 검색 → 다운로드 페이지 → LTS → Windows Installer MSI → 다운로드 폴더 실행 → Next/Agree/Install → CMD 재확인입니다.
핵심 개념
- 1LTS는 안정 지원 버전이므로 초보자는 Current보다 LTS를 선택하는 편이 안전합니다.
- 2Windows Installer(.msi)는 Windows에서 가장 표준적인 설치 파일입니다.
- 3설치 후 기존 CMD를 그대로 쓰면 PATH가 반영되지 않아 실패처럼 보일 수 있습니다.
- 4Node.js 설치는 npm 설치를 포함하므로 둘을 따로 찾지 않아도 됩니다.
근거와 판단 포인트
- •설치 후에는 기존 터미널을 닫고 새 CMD로 재실행해야 PATH 반영 여부를 정확히 확인할 수 있습니다.
- •실제 진행 흐름은 Google에서 Node.js 설치 검색 → 다운로드 페이지 → LTS → Windows Installer MSI → 다운로드 폴더 실행 → Next/Agree/Install → CMD 재확인입니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1공식 사이트 찾기
실행
Google에서 Node.js를 검색하되 공식 nodejs.org 다운로드 페이지인지 확인합니다.이유
광고/비공식 설치 파일을 피하기 위해서입니다.정상 확인
주소가 nodejs.org이며 LTS 다운로드 버튼이 보입니다. - 2LTS MSI 다운로드
실행
Windows Installer(.msi) LTS 버전을 다운로드합니다.이유
초보자 환경에서 안정성과 호환성이 가장 중요합니다.정상 확인
Downloads 폴더에 .msi 파일이 생겼습니다. - 3기본값 설치
실행
Next, Agree, Install을 기본값으로 진행합니다.이유
PATH 설정 등 필요한 옵션이 기본으로 포함됩니다.정상 확인
설치 완료 화면이 나옵니다. - 4새 CMD 검증
실행
모든 CMD를 닫고 새 CMD에서 node -v, npm -v를 실행합니다.이유
새 환경 변수를 반영해야 합니다.정상 확인
두 명령 모두 버전 숫자를 출력합니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 버전 선택 | LTS 안정 버전 | 이유 없이 Current/실험 버전 선택 |
| 검증 | 새 CMD에서 node -v와 npm -v 확인 | 설치 완료 화면만 보고 다음 단계 진행 |
| 실패 대응 | 터미널 재시작→재부팅→오류 원문 질문 | 같은 창에서 계속 npm만 반복 |
막히기 쉬운 지점과 해결
설치 후 npm이 여전히 안 됨
원인: 터미널이 설치 전 PATH를 사용 중입니다.
해결: CMD를 닫고 새로 열거나 재부팅합니다.
어떤 다운로드를 받을지 헷갈림
원인: LTS/Current, zip/msi 옵션이 많습니다.
해결: 초보자는 LTS Windows Installer MSI를 선택합니다.
권한 확인창이 나옴
원인: 프로그램 설치에는 관리자 권한이 필요할 수 있습니다.
해결: 공식 사이트 파일인지 확인한 뒤 승인합니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓공식 사이트에서 LTS MSI를 받았다.
- ✓설치 후 새 CMD를 열었다.
- ✓node -v와 npm -v가 숫자를 출력한다.
- ✓실패 시 오류 원문을 저장했다.
적용 과제: Node.js 설치와 터미널 재시작 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
Node.js 설치 후 확인 node -v npm -v 질문 템플릿 Node.js LTS를 설치했는데 아래처럼 나와. [결과 붙여넣기] CMD 재시작, 재부팅, PATH 확인 중 무엇부터 해야 하는지 순서대로 알려줘.
Cursor 설치와 프로젝트 열기
Cursor는 AI 채팅, 파일 수정, 터미널 실행을 한 화면에서 다루게 해주는 초보자용 작업대입니다.
Cursor를 공식 사이트에서 설치하고 로그인한 뒤, 영어 소문자 프로젝트 폴더를 열어 AI가 올바른 위치에 파일을 만들도록 준비합니다.
실전 맥락: 진행 흐름에는 Cursor를 C-U-R-S-O-R로 검색하라는 안내, Windows 다운로드, 바탕화면 바로가기, 체크박스, Google 로그인, Claude Code보다 Cursor GUI가 쉽다는 설명이 나옵니다.
핵심 개념
- 1Cursor는 VS Code 계열 편집기에 AI Agent가 결합된 도구로, 비개발자가 파일과 오류를 눈으로 확인하기 좋습니다.
- 2검색 결과가 헷갈리면 C-U-R-S-O-R처럼 영어 철자를 명확히 검색해 공식 사이트를 찾습니다.
- 3설치 옵션은 초보자에게 편의 기능이므로 바탕화면 바로가기와 기본 체크 옵션을 켜는 편이 좋습니다.
- 4프로젝트 폴더는 영어 소문자와 하이픈을 권장합니다. 한글/공백/대문자는 나중에 경로 문제를 만들 수 있습니다.
근거와 판단 포인트
- •초기 Start Building 화면이 보이면 당황하지 말고 건너뛰거나 Editor Mode로 이동해 프로젝트 폴더 열기에 집중합니다.
- •진행 흐름에는 Cursor를 C-U-R-S-O-R로 검색하라는 안내, Windows 다운로드, 바탕화면 바로가기, 체크박스, Google 로그인, Claude Code보다 Cursor GUI가 쉽다는 설명이 나옵니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1공식 Cursor 찾기
실행
Cursor 또는 C-U-R-S-O-R로 검색해 cursor.com 공식 다운로드를 엽니다.이유
비슷한 이름의 다른 프로그램을 피합니다.정상 확인
Cursor AI Code Editor 다운로드 화면이 보입니다. - 2Windows 설치
실행
Windows용 설치 파일을 받아 실행하고 기본 옵션을 선택합니다.이유
같은 Windows 기준 환경에서 시작하면 오류 대응이 쉽습니다.정상 확인
바탕화면 또는 시작 메뉴에서 Cursor가 실행됩니다. - 3로그인
실행
Google 로그인 등 익숙한 방식으로 계정을 만듭니다.이유
AI 기능과 요금제 사용량 관리에 계정이 필요합니다.정상 확인
Cursor 메인 화면에 진입합니다. - 4프로젝트 폴더 생성
실행
New/Open Project에서 my-first-webapp 같은 소문자 폴더를 만들고 Create/Open 합니다.이유
AI가 파일을 만들 기준 위치를 고정합니다.정상 확인
왼쪽 탐색기에 빈 프로젝트 폴더가 보입니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 검색 | 공식 cursor.com 확인 | 광고/비공식 다운로드 클릭 |
| 폴더명 | my-first-webapp, memo-app | 한글, 공백, 대소문자 혼합 경로 |
| 도구 선택 | 초보자는 Cursor GUI로 시작 | CLI 도구부터 시작해 터미널에서 막히기 |
막히기 쉬운 지점과 해결
AI가 엉뚱한 위치에 파일 생성
원인: 프로젝트 폴더를 제대로 열지 않았습니다.
해결: 왼쪽 탐색기의 최상위 폴더명을 확인하고 다시 Open Folder 합니다.
로그인/요금제 화면에서 멈춤
원인: 계정 생성과 사용량 정책 확인이 필요합니다.
해결: 무료로 시작하거나 Pro 체험 여부를 판단한 뒤 진행합니다.
폴더 경로 오류
원인: 한글/공백/특수문자가 섞인 경로입니다.
해결: 영어 소문자 폴더를 새로 만들어 시작합니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓Cursor 공식 설치 파일을 사용했다.
- ✓Google 등으로 로그인했다.
- ✓프로젝트 폴더명이 영어 소문자 중심이다.
- ✓왼쪽 탐색기에 올바른 폴더가 열려 있다.
적용 과제: Cursor 설치와 프로젝트 열기 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
프로젝트 폴더명 추천 memo-app curator-danbi-practice my-first-webapp AI에게 확인 지금 Cursor에서 열린 최상위 폴더가 [폴더명]이야. 이 위치에 Next.js 웹앱을 만들어도 되는지, 폴더명이나 경로에 문제 될 부분이 있는지 확인해줘.
Auto Mode와 요금제 판단
AI 코딩은 많이 묻고 많이 고치는 과정이므로, 초보자는 모델 성능뿐 아니라 질문량·비용·제한을 함께 봐야 합니다.
Cursor 요금제와 Auto Mode를 작업 전략 관점에서 판단하고, 무료/Pro/고급 모델을 언제 선택할지 기준을 세웁니다.
실전 맥락: 진행 흐름에는 Hobby 무료, Pro, Pro Plus, Ultra, 월 20달러, 연간 192달러, Claude Code 비용 부담, Auto Mode의 무제한성에 가까운 장점이 나옵니다.
핵심 개념
- 1초보자는 질문을 아끼면 적용 속도가 떨어지므로 처음에는 Auto Mode로 많이 묻는 환경이 중요합니다.
- 2무료 Hobby로 시작할 수 있지만 작업 중 제한이 오면 오류 해결 흐름이 끊길 수 있습니다.
- 3Pro는 큐레이터 단비가 추천하는 현실적인 기본 선택이며, Pro Plus/Ultra는 사용량이 큰 사람에게 맞습니다.
- 4Auto Mode는 쉬운 작업은 가벼운 모델, 어려운 작업은 더 적절한 모델로 보내는 식의 비용·속도 균형 장치로 이해하면 됩니다.
근거와 판단 포인트
- •Cursor 실습에서는 소문자 폴더명, Composer/Agent 입력 영역, Auto Mode 사용량을 함께 확인해야 합니다. 요금제 선택은 기능 구현 속도와 질문량을 보장하기 위한 작업 투자 판단입니다.
- •진행 흐름에는 Hobby 무료, Pro, Pro Plus, Ultra, 월 20달러, 연간 192달러, Claude Code 비용 부담, Auto Mode의 무제한성에 가까운 장점이 나옵니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1무료로 시작 가능성 확인
실행
Hobby/Free로 설치와 간단 질문이 가능한지 먼저 확인합니다.이유
결제 전 내 환경에서 도구가 맞는지 봅니다.정상 확인
간단한 질문에 Agent가 응답합니다. - 2Pro 필요성 판단
실행
하루 실습 시간, 오류 질문 빈도, 프로젝트 수를 적습니다.이유
고가 실전 예시에서는 질문량이 많아 제한이 작업 흐름에 직접 영향을 줍니다.정상 확인
한 달 체험이 필요한지 기준을 적었습니다. - 3Auto Mode 켜기
실행
모델 선택 영역에서 Auto Mode를 사용합니다.이유
모델 선택 고민보다 반복 실습에 집중합니다.정상 확인
채팅 입력창 근처에 Auto Mode 사용 상태를 확인합니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 처음 시작 | 무료로 설치·간단 질문 확인 | 도구도 안 맞는데 장기 결제 |
| 집중 작업 | Pro 한 달로 질문량 확보 | 제한 때문에 오류 질문을 아끼기 |
| 모델 선택 | Auto Mode 우선, 복잡한 작업만 고급 모델 검토 | 이름만 보고 비싼 모델 고정 |
막히기 쉬운 지점과 해결
중간에 사용량 제한
원인: 무료 플랜 한도에 도달했습니다.
해결: 실습량이 많다면 Pro 체험 또는 작업 범위 축소를 검토합니다.
AI 답변이 부족함
원인: Auto Mode가 쉬운 모델로 처리했거나 지시가 모호합니다.
해결: Plan Mode로 요구사항을 더 구체화합니다.
비용 불안
원인: 외부 API Key/고급 모델 사용량 구조를 모릅니다.
해결: 초보자는 Cursor 기본 Auto Mode 중심으로 시작합니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓내 플랜과 사용량 제한을 확인했다.
- ✓Auto Mode가 켜진 상태를 확인했다.
- ✓무료로 충분한지 Pro가 필요한지 기준을 적었다.
- ✓외부 API Key 입력은 지금 하지 않아도 됨을 이해했다.
적용 과제: Auto Mode와 요금제 판단 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
요금제 판단 질문 나는 하루 [시간] 정도 Cursor로 실습할 예정이고, 목표는 [프로젝트]야. 무료 플랜으로 시작해도 되는지, Pro 한 달을 써야 하는지, Auto Mode를 어떻게 쓰면 좋은지 비용 관점에서 판단해줘.
Cursor 화면 구조 익히기
Cursor의 왼쪽 파일, 중앙 편집/미리보기, 하단 터미널, 우측 AI Agent 영역만 익히면 초보자 실습은 시작할 수 있습니다.
Cursor 첫 화면에서 Start Building을 건너뛰고 New Project/Open Project, 새 폴더, Create Project Here, Editor Mode까지 화면 기준으로 이해합니다.
실전 맥락: 진행 흐름에는 Start Building 스킵, New Project/Open Project, 새 폴더 생성, 소문자 폴더명, Create Project Here, 상단 메뉴는 거의 안 쓴다는 설명이 나옵니다.
핵심 개념
- 1왼쪽 Explorer는 AI가 만든 파일이 실제로 생겼는지 확인하는 영역입니다.
- 2우측 Agent는 질문과 작업 지시를 하는 곳이며 Ask/Plan/Agent 모드가 연결됩니다.
- 3하단 터미널은 npm install, npm run dev, 오류 로그가 나오는 곳입니다.
- 4초보자는 상단 메뉴 전체를 외우지 말고 프로젝트 열기, 파일 확인, 터미널, AI 채팅 네 영역에 집중합니다.
근거와 판단 포인트
- •Cursor 화면은 Explorer, Chat, Terminal, README 파일, Add to Chat 버튼을 서로 연결해서 이해해야 합니다. 파일을 Add to Chat으로 넘기면 AI가 해당 Context를 보고 더 정확히 답합니다.
- •진행 흐름에는 Start Building 스킵, New Project/Open Project, 새 폴더 생성, 소문자 폴더명, Create Project Here, 상단 메뉴는 거의 안 쓴다는 설명이 나옵니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1화면 네 구역 이름 붙이기
실행
왼쪽/중앙/하단/우측을 각각 파일, 코드/문서, 터미널, AI라고 메모합니다.이유
오류 설명 때 “어디에 무엇이 보인다”를 말할 수 있어야 합니다.정상 확인
각 구역의 역할을 한 문장씩 설명합니다. - 2새 프로젝트 열기
실행
New/Open Project에서 폴더를 선택하고 Create Project Here를 누릅니다.이유
AI 작업 기준 폴더를 고정합니다.정상 확인
왼쪽 Explorer 최상단에 내 폴더명이 보입니다. - 3Editor Mode 확인
실행
초기 선택 화면이 나오면 Editor Mode로 들어갑니다.이유
파일 수정과 AI Agent 사용에 집중하기 위함입니다.정상 확인
파일 탐색기와 채팅 입력창이 보입니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 초기 화면 | Skip 또는 Editor Mode로 빠르게 진입 | Start Building이 뭔지 몰라 오래 멈추기 |
| 파일 확인 | 왼쪽 Explorer에서 생성 파일 확인 | AI 말만 듣고 파일 생성 여부 미확인 |
| 메뉴 학습 | 필수 영역만 먼저 익히기 | 상단 메뉴 전체를 익히느라 시작 미루기 |
막히기 쉬운 지점과 해결
어디에 입력해야 할지 모름
원인: 채팅, 터미널, 코드 편집 영역을 구분하지 못합니다.
해결: AI에게 하는 말은 우측, 명령어는 하단 터미널로 구분합니다.
파일이 안 보임
원인: 폴더가 닫혔거나 다른 경로를 열었습니다.
해결: Open Folder로 프로젝트 폴더를 다시 엽니다.
초기 화면에서 막힘
원인: 온보딩 옵션이 많습니다.
해결: Skip 후 New/Open Project로 진입합니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓왼쪽/중앙/하단/우측 영역명을 말할 수 있다.
- ✓내 프로젝트 폴더가 Explorer 최상단에 있다.
- ✓AI 채팅과 터미널 입력 위치를 구분한다.
- ✓상단 메뉴를 몰라도 실습을 시작할 수 있다.
적용 과제: Cursor 화면 구조 익히기 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
화면 설명 질문 지금 Cursor 화면에서 왼쪽에는 [보이는 파일], 하단에는 [터미널 상태], 우측에는 [AI 창 상태]가 보여. 내가 다음에 어디에 무엇을 입력해야 하는지 초보자 기준으로 알려줘.
터미널 기본 조작
터미널은 무서운 검은 화면이 아니라 컴퓨터와 AI가 명령을 주고받고 오류 증거를 남기는 창입니다.
Ctrl+J, Ctrl+Shift+백틱, 새 터미널, Kill/휴지통, CMD와 Cursor 터미널의 관계를 직접 조작합니다.
실전 맥락: 진행 흐름에는 Ctrl+J로 터미널 열기/닫기, Ctrl+Shift+`로 새 터미널, Kill Terminal, 여러 터미널 관리 설명이 나옵니다.
핵심 개념
- 1Ctrl+J는 터미널 패널을 열고 닫는 가장 중요한 단축키입니다.
- 2Ctrl+Shift+`는 새 터미널을 만들어 꼬인 실행 상태와 분리할 때 유용합니다.
- 3터미널에는 명령 결과와 오류 원문이 남으므로 AI에게 줄 증거 창입니다.
- 4여러 서버가 켜지면 포트가 꼬일 수 있어 Ctrl+C 또는 휴지통으로 정리하는 습관이 필요합니다.
근거와 판단 포인트
- •작업 중 터미널은 명령 입력창이면서 동시에 작업 기록장입니다. 어떤 명령을 언제 실행했고 어떤 출력이 나왔는지 남겨야 다음 오류 해결이 빨라집니다. 이 기록은 나중에 README나 정리 페이지에 복사해 정리 자료로 남길 수 있습니다.
- •터미널 출력은 우클릭 복사나 선택 복사로 AI에게 전달할 수 있고, npm install과 npm run dev는 가장 자주 반복되는 반복 명령입니다. 서버 실행 중에는 입력이 안 될 수 있으니 Ctrl+C로 멈춘 뒤 다시 명령을 넣습니다.
- •진행 흐름에는 Ctrl+J로 터미널 열기/닫기, Ctrl+Shift+`로 새 터미널, Kill Terminal, 여러 터미널 관리 설명이 나옵니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1Ctrl+J 연습
실행
Ctrl+J를 눌러 터미널을 열고 다시 닫아봅니다.이유
오류가 날 때 즉시 로그를 확인해야 합니다.정상 확인
하단 패널이 보였다가 숨겨집니다. - 2새 터미널 만들기
실행
Ctrl+Shift+`를 눌러 새 터미널을 엽니다.이유
기존 명령이 꼬였을 때 깨끗한 입력창이 필요합니다.정상 확인
터미널 탭이 새로 생깁니다. - 3터미널 종료
실행
휴지통/Kill Terminal 또는 Ctrl+C를 사용해 실행 중 프로세스를 정리합니다.이유
서버가 계속 켜져 있으면 포트 충돌이 납니다.정상 확인
입력 대기 상태로 돌아옵니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 열고 닫기 | Ctrl+J로 자주 확인 | 오류가 나도 터미널을 보지 않기 |
| 새 터미널 | 꼬이면 새 터미널 생성 | 같은 창에서 명령을 계속 덮어쓰기 |
| 종료 | Ctrl+C/Kill로 서버 정리 | 창만 닫고 프로세스 방치 |
막히기 쉬운 지점과 해결
명령을 입력했는데 반응 없음
원인: 개발 서버가 실행 중이라 입력 대기가 아닙니다.
해결: Ctrl+C로 서버를 멈춘 뒤 다시 입력합니다.
포트가 3001, 3002로 늘어남
원인: 이전 서버가 종료되지 않았습니다.
해결: 기존 터미널을 찾아 Ctrl+C 또는 Kill 합니다.
PowerShell/CMD 차이 혼란
원인: 터미널 종류가 다릅니다.
해결: 처음에는 Cursor 기본 터미널과 CMD 결과를 구분해 기록합니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓Ctrl+J로 터미널을 열고 닫았다.
- ✓Ctrl+Shift+`로 새 터미널을 만들었다.
- ✓실행 중 명령은 Ctrl+C로 멈출 수 있음을 안다.
- ✓오류 원문은 터미널에서 복사해야 함을 이해했다.
적용 과제: 터미널 기본 조작 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
터미널 상태 질문 Cursor 하단 터미널에 아래 내용이 보여. [터미널 내용 붙여넣기] 지금 명령 입력이 가능한 상태인지, 서버가 실행 중인지, Ctrl+C가 필요한지 알려줘.
Ask·Plan·Agent 모드 구분
모드는 AI에게 맡기는 책임 범위를 정하는 스위치입니다. 모르면 Ask, 만들기 전엔 Plan, 실제 수정은 Agent가 기본입니다.
Agent, Plan, Debug, Ask와 Auto Mode/모델 선택/Context Window를 초보자 기준으로 구분합니다.
실전 맥락: 진행 흐름에는 Agent/Plan/Debug/Ask, Auto Mode, 모델 선택, Context Window, API Key 영역이 등장하고, 대부분 Agent를 쓰되 후반 새 앱 계획에는 Plan Mode가 중요하게 쓰입니다.
핵심 개념
- 1Ask는 파일을 바꾸지 않고 개념을 물어볼 때 안전합니다.
- 2Plan은 여러 파일을 바꿀 가능성이 있을 때 먼저 설계와 범위를 확인하는 모드입니다.
- 3Agent는 파일 생성·수정·터미널 명령 제안을 실제로 수행할 수 있는 작업 모드입니다.
- 4Debug는 오류 상황에서 원인 추적에 도움을 주지만, 초보자는 Agent에 오류 원문을 넣어도 충분히 시작할 수 있습니다.
근거와 판단 포인트
- •진행 흐름에는 Agent/Plan/Debug/Ask, Auto Mode, 모델 선택, Context Window, API Key 영역이 등장하고, 대부분 Agent를 쓰되 후반 새 앱 계획에는 Plan Mode가 중요하게 쓰입니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1모드 위치 확인
실행
우측 AI 입력창 주변에서 Ask/Plan/Agent/Debug 모드 선택 영역을 찾습니다.이유
지금 AI가 파일을 바꿀 수 있는지 알아야 합니다.정상 확인
현재 선택된 모드를 말할 수 있습니다. - 2Ask로 개념 질문
실행
“Next.js가 뭐야?”처럼 파일 변경 없는 질문을 Ask에 입력합니다.이유
도구와 용어를 안전하게 익힙니다.정상 확인
파일 diff 없이 설명만 받았습니다. - 3Plan으로 범위 확인
실행
새 기능을 만들기 전 “먼저 계획만 세워줘”라고 요청합니다.이유
기존 앱 훼손을 막습니다.정상 확인
수정할 파일과 단계가 먼저 제시됩니다. - 4Agent로 구현
실행
계획을 이해한 뒤 “이 계획대로 진행해”라고 지시합니다.이유
구현은 파일 변경 권한이 있는 Agent가 처리합니다.정상 확인
파일 변경 diff와 Keep/Undo가 나타납니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 개념 질문 | Ask | 개념만 궁금한데 Agent로 파일 수정 |
| 새 기능/여러 파일 | Plan으로 계획 먼저 | 수정 범위 모른 채 진행 |
| 실제 구현 | Agent + Keep/Undo 검토 | Run Everything/Auto Keep 무비판 사용 |
막히기 쉬운 지점과 해결
AI가 갑자기 파일을 바꿈
원인: 질문을 Agent 모드에서 했습니다.
해결: 개념 질문은 Ask로 전환합니다.
기존 앱이 사라짐
원인: Plan 없이 새 기능을 요청했습니다.
해결: “기존 앱 유지, 신규 폴더 추가”를 명시합니다.
모델 선택에서 시간 낭비
원인: 처음부터 최적 모델을 고르려 합니다.
해결: Auto Mode로 시작하고 부족하면 지시를 구체화합니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓Ask/Plan/Agent 차이를 말할 수 있다.
- ✓파일 변경 전 Plan을 요청할 수 있다.
- ✓Auto Mode를 켜고 모델 선택 고민을 줄였다.
- ✓기존 기능 유지 조건을 프롬프트에 넣는다.
적용 과제: Ask·Plan·Agent 모드 구분 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
모드 선택 프롬프트 아직 파일을 바꾸지 말고 Plan 모드처럼 먼저 계획만 세워줘. 목표: [기능] 유지해야 할 것: 기존 [기능/페이지]는 그대로 둔다. 알려줄 것: 수정할 파일, 예상 위험, 검증 방법.
README 기반 계획 승인
README는 프로젝트의 기획서이자 AI와 사람이 같은 목표를 보는 설계도입니다.
AI에게 바로 만들라고 하기 전에 README에 목표, 기술 스택, 라우팅, DB, MVP, 완료 기준을 쓰게 하고 읽은 뒤 승인·수정합니다.
실전 맥락: 진행 흐름에는 GenSpark 언급, README 작성, 사이트명 자동 제안, Next.js 16.2.4, React 19, SQLite, TypeScript, Tailwind, 라우팅, DB 테이블, Definition of Done이 등장합니다.
핵심 개념
- 1README는 나중에 AI가 길을 잃지 않도록 하는 기준 문서입니다.
- 2기술을 몰라도 Next.js, React, SQLite 같은 이름과 역할은 읽고 넘어가야 합니다.
- 3계획을 읽고 모르는 단어를 다시 묻는 과정 자체가 수업입니다.
- 4완료 기준이 있어야 AI가 “완료”라고 했을 때 사람이 검증할 수 있습니다.
근거와 판단 포인트
- •README 계획에는 나중에 데이터 주권까지 이어질 저장 위치와 완료 후 “진행해”라고 승인할 기준이 포함되어야 합니다.
- •진행 흐름에는 GenSpark 언급, README 작성, 사이트명 자동 제안, Next.js 16.2.4, React 19, SQLite, TypeScript, Tailwind, 라우팅, DB 테이블, Definition of Done이 등장합니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1화면 흐름 확인
실행
해당 섹션에서 큐레이터 단비가 실제로 누르거나 입력한 대상을 먼저 적습니다.이유
추상 설명을 실제 화면 조작으로 바꾸기 위해서입니다.정상 확인
버튼, 파일, 명령, 오류 중 최소 하나를 정확히 기록했습니다. - 2내 프로젝트에 적용
실행
같은 작업을 내 Cursor 프로젝트에서 작은 범위로 적용합니다.이유
예시 화면과 내 환경은 다를 수 있어 직접 검증이 필요합니다.정상 확인
파일 변경, 터미널 출력, 브라우저 화면 중 두 가지 이상을 확인했습니다. - 3막히면 원문 전달
실행
오류나 헷갈리는 화면을 요약하지 말고 그대로 복사해 AI에게 줍니다.이유
원문이 있어야 AI가 원인을 정확히 추적합니다.정상 확인
질문에 오류 원문과 원하는 결과가 포함됐습니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 진행 전 | 계획/범위/유지할 기능을 먼저 말함 | 바로 전체 구현 요청 |
| 진행 중 | 파일 diff와 명령 의미를 확인 | 권한 요청을 무조건 승인 |
| 진행 후 | 브라우저와 터미널로 정상 결과 확인 | AI의 완료 메시지만 믿기 |
막히기 쉬운 지점과 해결
AI가 엉뚱한 작업을 함
원인: 목표와 제한 범위를 말하지 않았습니다.
해결: 기존 유지, 수정 범위, 완료 기준을 프롬프트에 넣습니다.
오류가 반복됨
원인: 오류 원문이나 실행 순서가 누락됐습니다.
해결: 터미널/브라우저 오류 전체와 방금 한 일을 함께 전달합니다.
배운 내용이 남지 않음
원인: 질문과 해결 과정을 기록하지 않았습니다.
해결: README나 정리 페이지에 오늘의 오류와 해결을 남깁니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓실제 화면 조작을 내 말로 설명할 수 있다.
- ✓내 프로젝트에서 같은 단계의 정상 결과를 확인했다.
- ✓실패 시 복사할 오류 원문과 질문 템플릿이 준비됐다.
- ✓다음 단계로 넘어가기 전 Keep/Undo 또는 브라우저 검증을 완료했다.
적용 과제: README 기반 계획 승인 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
README 파일 하나 만들어서 계획을 짜. 랜딩 페이지 플러스 간단한 앱이 동시에 돌아가는 웹페이지와 웹앱을 만들 거야. 기술 스택은 Next.js, React 19, TypeScript, Tailwind, SQLite를 우선 검토해줘. 사이트명은 임시로 추천해주고, 라우팅 구조, DB 테이블, MVP, 완료 기준까지 써줘. 아직 코드는 만들지 말고 README 계획만 작성해줘.
Keep·Undo로 변경 관리
Cursor가 만든 변경은 사람이 승인해야 진짜 내 코드가 됩니다.
Keep, Keep All, Undo, Undo All, Auto Keep의 의미와 위험도를 파일 종류별로 판단합니다.
실전 맥락: 진행 흐름에는 AI가 만든 README/코드 diff, Keep/Undo, Keep All/Undo All, 변경 줄 수, Auto Keep/Disable Inline Diffs가 나옵니다.
핵심 개념
- 1Keep은 해당 변경을 확정하는 버튼이고 Undo는 되돌리는 안전장치입니다.
- 2README만 바뀐 경우와 package.json/DB 스키마가 바뀐 경우는 위험도가 다릅니다.
- 3Auto Keep은 편하지만 초보자에게는 원치 않는 대량 변경을 놓치게 만들 수 있습니다.
- 4변경 파일명, 변경 줄 수, 변경 목적을 확인한 뒤 승인해야 합니다.
근거와 판단 포인트
- •특히 package.json, DB 스키마, 삭제가 포함된 diff는 README 문서 수정과 같은 수준으로 승인하면 안 됩니다. 변경 전후 화면을 비교한 뒤 Keep합니다.
- •Keep과 Undo는 되돌리기 안전장치입니다. 큰 변경을 한 번에 승인하지 말고 작은 단위로 검토해야 어떤 변경이 문제였는지 추적할 수 있습니다.
- •진행 흐름에는 AI가 만든 README/코드 diff, Keep/Undo, Keep All/Undo All, 변경 줄 수, Auto Keep/Disable Inline Diffs가 나옵니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1화면 흐름 확인
실행
해당 섹션에서 큐레이터 단비가 실제로 누르거나 입력한 대상을 먼저 적습니다.이유
추상 설명을 실제 화면 조작으로 바꾸기 위해서입니다.정상 확인
버튼, 파일, 명령, 오류 중 최소 하나를 정확히 기록했습니다. - 2내 프로젝트에 적용
실행
같은 작업을 내 Cursor 프로젝트에서 작은 범위로 적용합니다.이유
예시 화면과 내 환경은 다를 수 있어 직접 검증이 필요합니다.정상 확인
파일 변경, 터미널 출력, 브라우저 화면 중 두 가지 이상을 확인했습니다. - 3막히면 원문 전달
실행
오류나 헷갈리는 화면을 요약하지 말고 그대로 복사해 AI에게 줍니다.이유
원문이 있어야 AI가 원인을 정확히 추적합니다.정상 확인
질문에 오류 원문과 원하는 결과가 포함됐습니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 진행 전 | 계획/범위/유지할 기능을 먼저 말함 | 바로 전체 구현 요청 |
| 진행 중 | 파일 diff와 명령 의미를 확인 | 권한 요청을 무조건 승인 |
| 진행 후 | 브라우저와 터미널로 정상 결과 확인 | AI의 완료 메시지만 믿기 |
막히기 쉬운 지점과 해결
AI가 엉뚱한 작업을 함
원인: 목표와 제한 범위를 말하지 않았습니다.
해결: 기존 유지, 수정 범위, 완료 기준을 프롬프트에 넣습니다.
오류가 반복됨
원인: 오류 원문이나 실행 순서가 누락됐습니다.
해결: 터미널/브라우저 오류 전체와 방금 한 일을 함께 전달합니다.
배운 내용이 남지 않음
원인: 질문과 해결 과정을 기록하지 않았습니다.
해결: README나 정리 페이지에 오늘의 오류와 해결을 남깁니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓실제 화면 조작을 내 말로 설명할 수 있다.
- ✓내 프로젝트에서 같은 단계의 정상 결과를 확인했다.
- ✓실패 시 복사할 오류 원문과 질문 템플릿이 준비됐다.
- ✓다음 단계로 넘어가기 전 Keep/Undo 또는 브라우저 검증을 완료했다.
적용 과제: Keep·Undo로 변경 관리 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
변경 승인 전 확인해줘. 변경된 파일 목록: [붙여넣기] 내 목표: [목표] 각 파일이 왜 바뀌었는지, Keep해도 되는지, Undo해야 할 위험한 변경이 있는지 표로 판단해줘.
Allow List 권한 판단
AI가 터미널 명령을 실행하려 할 때 허용 범위를 정하는 것은 보안과 안정성의 핵심입니다.
Use Allow List, Ask Every Time, Run Everything 차이를 이해하고 명령 위험도를 보고 승인합니다.
실전 맥락: 진행 흐름에는 ls, npm install, npm run dev 같은 명령 승인 요청과 Use Allow List 설명이 나옵니다.
핵심 개념
- 1ls/pwd/dir 같은 조회 명령은 비교적 안전하지만 삭제·권한·외부 전송 명령은 위험합니다.
- 2npm install은 프로젝트 의존성 설치라 필요하지만 package.json 변경과 함께 확인해야 합니다.
- 3Run Everything은 초보자에게 위험하므로 명령 뜻을 모르면 설명부터 요구합니다.
- 4Allow List는 반복 허용이므로 1회 실행보다 더 신중해야 합니다.
근거와 판단 포인트
- •초보자는 허용 버튼을 누르기 전에 명령의 목적, 수정 대상, 되돌리는 방법을 세 문장으로 설명받는 습관을 들여야 합니다.
- •Allow List는 편의를 주지만 권한 범위가 넓어질 수 있으므로 조회, 설치, 삭제, 외부 전송 명령을 나눠 판단합니다. 위험한 명령은 1회 승인도 하지 말고 설명을 먼저 받아야 합니다.
- •진행 흐름에는 ls, npm install, npm run dev 같은 명령 승인 요청과 Use Allow List 설명이 나옵니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1화면 흐름 확인
실행
해당 섹션에서 큐레이터 단비가 실제로 누르거나 입력한 대상을 먼저 적습니다.이유
추상 설명을 실제 화면 조작으로 바꾸기 위해서입니다.정상 확인
버튼, 파일, 명령, 오류 중 최소 하나를 정확히 기록했습니다. - 2내 프로젝트에 적용
실행
같은 작업을 내 Cursor 프로젝트에서 작은 범위로 적용합니다.이유
예시 화면과 내 환경은 다를 수 있어 직접 검증이 필요합니다.정상 확인
파일 변경, 터미널 출력, 브라우저 화면 중 두 가지 이상을 확인했습니다. - 3막히면 원문 전달
실행
오류나 헷갈리는 화면을 요약하지 말고 그대로 복사해 AI에게 줍니다.이유
원문이 있어야 AI가 원인을 정확히 추적합니다.정상 확인
질문에 오류 원문과 원하는 결과가 포함됐습니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 진행 전 | 계획/범위/유지할 기능을 먼저 말함 | 바로 전체 구현 요청 |
| 진행 중 | 파일 diff와 명령 의미를 확인 | 권한 요청을 무조건 승인 |
| 진행 후 | 브라우저와 터미널로 정상 결과 확인 | AI의 완료 메시지만 믿기 |
막히기 쉬운 지점과 해결
AI가 엉뚱한 작업을 함
원인: 목표와 제한 범위를 말하지 않았습니다.
해결: 기존 유지, 수정 범위, 완료 기준을 프롬프트에 넣습니다.
오류가 반복됨
원인: 오류 원문이나 실행 순서가 누락됐습니다.
해결: 터미널/브라우저 오류 전체와 방금 한 일을 함께 전달합니다.
배운 내용이 남지 않음
원인: 질문과 해결 과정을 기록하지 않았습니다.
해결: README나 정리 페이지에 오늘의 오류와 해결을 남깁니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓실제 화면 조작을 내 말로 설명할 수 있다.
- ✓내 프로젝트에서 같은 단계의 정상 결과를 확인했다.
- ✓실패 시 복사할 오류 원문과 질문 템플릿이 준비됐다.
- ✓다음 단계로 넘어가기 전 Keep/Undo 또는 브라우저 검증을 완료했다.
적용 과제: Allow List 권한 판단 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
아래 명령을 Cursor가 실행하자고 해. 명령: [명령 붙여넣기] 이 명령이 하는 일, 위험도, 허용해도 되는 조건, 거절해야 하는 경우를 초보자 기준으로 설명해줘.
AI 코딩 반복 루프
바이브 코딩은 “계획 짜줘 → 진행해 → 확인해 → 오류 붙여넣기 → 다시 고쳐줘”를 정확히 반복하는 기술입니다.
README 확인부터 Allow List, npm install, 파일 생성, Keep, npm run dev, 오류 전달까지 실제 순서로 반복 루프를 체득합니다.
실전 맥락: 전체 흐름은 설치 → 프로젝트 열기 → 계획 작성 → 진행 → 권한 승인 → 실행 → 오류 전달 → 수정 → 브라우저 확인으로 반복됩니다.
핵심 개념
- 1반복 루프는 단순하지만 각 단계의 증거가 필요합니다.
- 2AI가 만든 파일은 Explorer와 diff로 확인하고, 실행 결과는 터미널과 브라우저로 확인합니다.
- 3오류가 나면 실패가 아니라 다음 프롬프트의 재료가 생긴 것입니다.
- 4한 번에 큰 목표를 요구하지 말고 현재 막힌 한 단계를 해결합니다.
근거와 판단 포인트
- •좋은 반복은 속도가 아니라 관찰의 정확도에서 나옵니다. 파일이 바뀌었는지, 서버가 다시 켜졌는지, 브라우저 오류가 바뀌었는지를 매번 확인합니다.
- •반복 루프 중 꼬이면 터미널 재시작, 서버 재시작, 브라우저 새로고침처럼 상태를 초기화한 뒤 같은 오류가 재현되는지 봅니다.
- •전체 흐름은 설치 → 프로젝트 열기 → 계획 작성 → 진행 → 권한 승인 → 실행 → 오류 전달 → 수정 → 브라우저 확인으로 반복됩니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1화면 흐름 확인
실행
해당 섹션에서 큐레이터 단비가 실제로 누르거나 입력한 대상을 먼저 적습니다.이유
추상 설명을 실제 화면 조작으로 바꾸기 위해서입니다.정상 확인
버튼, 파일, 명령, 오류 중 최소 하나를 정확히 기록했습니다. - 2내 프로젝트에 적용
실행
같은 작업을 내 Cursor 프로젝트에서 작은 범위로 적용합니다.이유
예시 화면과 내 환경은 다를 수 있어 직접 검증이 필요합니다.정상 확인
파일 변경, 터미널 출력, 브라우저 화면 중 두 가지 이상을 확인했습니다. - 3막히면 원문 전달
실행
오류나 헷갈리는 화면을 요약하지 말고 그대로 복사해 AI에게 줍니다.이유
원문이 있어야 AI가 원인을 정확히 추적합니다.정상 확인
질문에 오류 원문과 원하는 결과가 포함됐습니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 진행 전 | 계획/범위/유지할 기능을 먼저 말함 | 바로 전체 구현 요청 |
| 진행 중 | 파일 diff와 명령 의미를 확인 | 권한 요청을 무조건 승인 |
| 진행 후 | 브라우저와 터미널로 정상 결과 확인 | AI의 완료 메시지만 믿기 |
막히기 쉬운 지점과 해결
AI가 엉뚱한 작업을 함
원인: 목표와 제한 범위를 말하지 않았습니다.
해결: 기존 유지, 수정 범위, 완료 기준을 프롬프트에 넣습니다.
오류가 반복됨
원인: 오류 원문이나 실행 순서가 누락됐습니다.
해결: 터미널/브라우저 오류 전체와 방금 한 일을 함께 전달합니다.
배운 내용이 남지 않음
원인: 질문과 해결 과정을 기록하지 않았습니다.
해결: README나 정리 페이지에 오늘의 오류와 해결을 남깁니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓실제 화면 조작을 내 말로 설명할 수 있다.
- ✓내 프로젝트에서 같은 단계의 정상 결과를 확인했다.
- ✓실패 시 복사할 오류 원문과 질문 템플릿이 준비됐다.
- ✓다음 단계로 넘어가기 전 Keep/Undo 또는 브라우저 검증을 완료했다.
적용 과제: AI 코딩 반복 루프 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
현재 상태: [README 작성/파일 생성/npm install/npm run dev/브라우저 오류 중 하나] 내가 본 증거: [파일 목록 또는 오류 원문] 다음 목표: [한 단계] 위험 제한: 기존 기능 삭제 금지, 필요 파일만 수정. 지금 해야 할 1단계만 알려주고 진행해줘.
npm 명령 체인 이해
npm install, npm run dev, npm run build는 웹앱을 설치·실행·검증하는 최소 명령어 체인입니다.
node_modules, package.json, package-lock.json, .gitignore, .next, src/app, data 폴더의 의미를 실제 프로젝트 구조로 연결합니다.
실전 맥락: 진행 흐름에는 npm install, npm run dev, npm run build, node_modules, package.json, package-lock.json, .gitignore, .next, src/app, data 폴더 설명이 나옵니다.
핵심 개념
- 1npm install은 필요한 부품을 node_modules에 내려받는 과정입니다.
- 2npm run dev는 개발 서버를 켜고 localhost 주소를 제공합니다.
- 3npm run build는 배포 전 더 엄격하게 오류를 찾는 검증 명령입니다.
- 4node_modules와 .next는 직접 수정하는 폴더가 아니라 설치/실행 결과물입니다.
근거와 판단 포인트
- •package.json의 dependencies와 devDependencies는 의존성 목록이며 npm install은 이 의존성을 node_modules로 내려받는 과정입니다.
- •진행 흐름에는 npm install, npm run dev, npm run build, node_modules, package.json, package-lock.json, .gitignore, .next, src/app, data 폴더 설명이 나옵니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1화면 흐름 확인
실행
해당 섹션에서 큐레이터 단비가 실제로 누르거나 입력한 대상을 먼저 적습니다.이유
추상 설명을 실제 화면 조작으로 바꾸기 위해서입니다.정상 확인
버튼, 파일, 명령, 오류 중 최소 하나를 정확히 기록했습니다. - 2내 프로젝트에 적용
실행
같은 작업을 내 Cursor 프로젝트에서 작은 범위로 적용합니다.이유
예시 화면과 내 환경은 다를 수 있어 직접 검증이 필요합니다.정상 확인
파일 변경, 터미널 출력, 브라우저 화면 중 두 가지 이상을 확인했습니다. - 3막히면 원문 전달
실행
오류나 헷갈리는 화면을 요약하지 말고 그대로 복사해 AI에게 줍니다.이유
원문이 있어야 AI가 원인을 정확히 추적합니다.정상 확인
질문에 오류 원문과 원하는 결과가 포함됐습니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 진행 전 | 계획/범위/유지할 기능을 먼저 말함 | 바로 전체 구현 요청 |
| 진행 중 | 파일 diff와 명령 의미를 확인 | 권한 요청을 무조건 승인 |
| 진행 후 | 브라우저와 터미널로 정상 결과 확인 | AI의 완료 메시지만 믿기 |
막히기 쉬운 지점과 해결
AI가 엉뚱한 작업을 함
원인: 목표와 제한 범위를 말하지 않았습니다.
해결: 기존 유지, 수정 범위, 완료 기준을 프롬프트에 넣습니다.
오류가 반복됨
원인: 오류 원문이나 실행 순서가 누락됐습니다.
해결: 터미널/브라우저 오류 전체와 방금 한 일을 함께 전달합니다.
배운 내용이 남지 않음
원인: 질문과 해결 과정을 기록하지 않았습니다.
해결: README나 정리 페이지에 오늘의 오류와 해결을 남깁니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓실제 화면 조작을 내 말로 설명할 수 있다.
- ✓내 프로젝트에서 같은 단계의 정상 결과를 확인했다.
- ✓실패 시 복사할 오류 원문과 질문 템플릿이 준비됐다.
- ✓다음 단계로 넘어가기 전 Keep/Undo 또는 브라우저 검증을 완료했다.
적용 과제: npm 명령 체인 이해 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
프로젝트 구조를 설명해줘. 아래 파일/폴더가 각각 무엇인지, 직접 수정해도 되는지, Git에 올리는지 알려줘. node_modules, package.json, package-lock.json, .gitignore, .next, src/app, data
오류 원문 복사와 해결 흐름
오류는 요약하지 말고 원문 전체를 복사해 AI에게 전달해야 빠르게 해결됩니다.
터미널 오류, 브라우저 Next.js 오류, Add to Chat, Ctrl+L, Copy 버튼, 재실행 순서를 실제로 구분합니다.
실전 맥락: 진행 흐름에는 npm run dev 실패, 터미널 오류 드래그, Add to Chat/Ctrl+L, Next.js 오류 화면 Copy 버튼, 방법 1로 해결 요청이 나옵니다.
핵심 개념
- 1터미널 오류는 명령 실행 실패의 원인이며 드래그하거나 Add to Chat으로 보냅니다.
- 2브라우저 오류 화면은 Next.js가 제공하는 Copy 버튼을 이용하면 원문을 쉽게 복사할 수 있습니다.
- 3PowerShell 실행 정책, better-sqlite3 네이티브 모듈 같은 오류는 원문 없이는 원인 추정이 어렵습니다.
- 4AI에게는 원인, 수정 파일, 실행 명령, 재검증 순서를 요구해야 합니다.
근거와 판단 포인트
- •에러 원문은 요약하지 말고 카피 버튼, Add to Chat, 드래그 복사 중 가능한 방법으로 전체를 전달합니다. 파일명, 라인, stack trace가 빠지면 해결 품질이 크게 떨어집니다.
- •진행 흐름에는 npm run dev 실패, 터미널 오류 드래그, Add to Chat/Ctrl+L, Next.js 오류 화면 Copy 버튼, 방법 1로 해결 요청이 나옵니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1화면 흐름 확인
실행
해당 섹션에서 큐레이터 단비가 실제로 누르거나 입력한 대상을 먼저 적습니다.이유
추상 설명을 실제 화면 조작으로 바꾸기 위해서입니다.정상 확인
버튼, 파일, 명령, 오류 중 최소 하나를 정확히 기록했습니다. - 2내 프로젝트에 적용
실행
같은 작업을 내 Cursor 프로젝트에서 작은 범위로 적용합니다.이유
예시 화면과 내 환경은 다를 수 있어 직접 검증이 필요합니다.정상 확인
파일 변경, 터미널 출력, 브라우저 화면 중 두 가지 이상을 확인했습니다. - 3막히면 원문 전달
실행
오류나 헷갈리는 화면을 요약하지 말고 그대로 복사해 AI에게 줍니다.이유
원문이 있어야 AI가 원인을 정확히 추적합니다.정상 확인
질문에 오류 원문과 원하는 결과가 포함됐습니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 진행 전 | 계획/범위/유지할 기능을 먼저 말함 | 바로 전체 구현 요청 |
| 진행 중 | 파일 diff와 명령 의미를 확인 | 권한 요청을 무조건 승인 |
| 진행 후 | 브라우저와 터미널로 정상 결과 확인 | AI의 완료 메시지만 믿기 |
막히기 쉬운 지점과 해결
AI가 엉뚱한 작업을 함
원인: 목표와 제한 범위를 말하지 않았습니다.
해결: 기존 유지, 수정 범위, 완료 기준을 프롬프트에 넣습니다.
오류가 반복됨
원인: 오류 원문이나 실행 순서가 누락됐습니다.
해결: 터미널/브라우저 오류 전체와 방금 한 일을 함께 전달합니다.
배운 내용이 남지 않음
원인: 질문과 해결 과정을 기록하지 않았습니다.
해결: README나 정리 페이지에 오늘의 오류와 해결을 남깁니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓실제 화면 조작을 내 말로 설명할 수 있다.
- ✓내 프로젝트에서 같은 단계의 정상 결과를 확인했다.
- ✓실패 시 복사할 오류 원문과 질문 템플릿이 준비됐다.
- ✓다음 단계로 넘어가기 전 Keep/Undo 또는 브라우저 검증을 완료했다.
적용 과제: 오류 원문 복사와 해결 흐름 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
아래 오류 원문을 보고 해결해줘. [오류 전체 붙여넣기] 원하는 답변 형식: 1. 원인 한 문장 2. 수정할 파일 또는 실행할 명령 3. 내가 직접 승인해야 할 위험 명령 여부 4. 다시 실행할 검증 명령 5. 브라우저에서 확인할 정상 화면
포트와 localhost 습관
localhost:3000은 내 컴퓨터 전용 주소이며, 개발 서버를 직접 켜고 끄는 습관이 포트 꼬임을 막습니다.
npm run dev, Ctrl+Click, Ctrl+C, 포트 3000/3001/3002, 접속 거부, 외부 공유 불가를 실습합니다.
실전 맥락: 진행 흐름에는 npm run dev 직접 실행 권장, AI에게 맡기면 포트가 계속 늘어날 수 있음, Ctrl+Click, Ctrl+C, localhost는 남에게 공유 불가라는 설명이 나옵니다.
핵심 개념
- 1npm run dev가 성공하면 터미널에 localhost 주소가 나옵니다.
- 2Ctrl+Click으로 주소를 열고, Ctrl+C로 서버를 종료합니다.
- 33000이 사용 중이면 3001/3002로 밀릴 수 있어 이전 서버 종료가 중요합니다.
- 4친구에게 보여주려면 localhost가 아니라 Vercel 같은 배포 URL이 필요합니다.
근거와 판단 포인트
- •포트가 이미 사용 중이면 Next.js가 3001 또는 3002로 밀리거나 실행을 멈춥니다. 어떤 포트가 열렸는지 터미널 로그에서 확인해야 합니다.
- •진행 흐름에는 npm run dev 직접 실행 권장, AI에게 맡기면 포트가 계속 늘어날 수 있음, Ctrl+Click, Ctrl+C, localhost는 남에게 공유 불가라는 설명이 나옵니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1화면 흐름 확인
실행
해당 섹션에서 큐레이터 단비가 실제로 누르거나 입력한 대상을 먼저 적습니다.이유
추상 설명을 실제 화면 조작으로 바꾸기 위해서입니다.정상 확인
버튼, 파일, 명령, 오류 중 최소 하나를 정확히 기록했습니다. - 2내 프로젝트에 적용
실행
같은 작업을 내 Cursor 프로젝트에서 작은 범위로 적용합니다.이유
예시 화면과 내 환경은 다를 수 있어 직접 검증이 필요합니다.정상 확인
파일 변경, 터미널 출력, 브라우저 화면 중 두 가지 이상을 확인했습니다. - 3막히면 원문 전달
실행
오류나 헷갈리는 화면을 요약하지 말고 그대로 복사해 AI에게 줍니다.이유
원문이 있어야 AI가 원인을 정확히 추적합니다.정상 확인
질문에 오류 원문과 원하는 결과가 포함됐습니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 진행 전 | 계획/범위/유지할 기능을 먼저 말함 | 바로 전체 구현 요청 |
| 진행 중 | 파일 diff와 명령 의미를 확인 | 권한 요청을 무조건 승인 |
| 진행 후 | 브라우저와 터미널로 정상 결과 확인 | AI의 완료 메시지만 믿기 |
막히기 쉬운 지점과 해결
AI가 엉뚱한 작업을 함
원인: 목표와 제한 범위를 말하지 않았습니다.
해결: 기존 유지, 수정 범위, 완료 기준을 프롬프트에 넣습니다.
오류가 반복됨
원인: 오류 원문이나 실행 순서가 누락됐습니다.
해결: 터미널/브라우저 오류 전체와 방금 한 일을 함께 전달합니다.
배운 내용이 남지 않음
원인: 질문과 해결 과정을 기록하지 않았습니다.
해결: README나 정리 페이지에 오늘의 오류와 해결을 남깁니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓실제 화면 조작을 내 말로 설명할 수 있다.
- ✓내 프로젝트에서 같은 단계의 정상 결과를 확인했다.
- ✓실패 시 복사할 오류 원문과 질문 템플릿이 준비됐다.
- ✓다음 단계로 넘어가기 전 Keep/Undo 또는 브라우저 검증을 완료했다.
적용 과제: 포트와 localhost 습관 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
localhost가 헷갈려. 현재 터미널 로그: [붙여넣기] 열어야 할 주소, 서버 종료 방법, 포트가 늘어난 이유, 다른 사람에게 보여주려면 무엇이 필요한지 설명해줘.
프롬프트로 기능 확장하기
기능 추가는 전문 용어보다 “지금 불편한 점”을 정확히 말하는 것에서 시작합니다.
메모 앱에 HTTP 링크 필드, 부가 옵션, 수정 기능을 추가하는 과정을 DB 변경·화면 테스트·Context와 연결합니다.
실전 맥락: 진행 흐름에는 메모 앱 생성 후 HTTP 링크를 클릭하고 싶다, 필드를 더 추가해 메모/링크/옵션 저장, 수정 기능이 없네 같은 요청이 등장합니다.
핵심 개념
- 1불편함을 자연어로 말해도 AI는 기존 코드 Context를 보고 구현 방향을 제안할 수 있습니다.
- 2링크 필드 추가는 UI만이 아니라 DB 컬럼/저장 로직/목록 렌더링이 함께 바뀌는 작업입니다.
- 3기능 추가 후에는 저장, 새로고침, 링크 클릭, 기존 데이터 유지, 수정 버튼 동작을 직접 테스트해야 합니다.
- 4“기존 앱은 유지”와 “필요한 필드만 추가”를 말하면 범위가 안전해집니다.
근거와 판단 포인트
- •메모 앱 기능 확장은 SQLite 저장 구조와 함께 봐야 하며, 단순 텍스트뿐 아니라 생각과 느낌, HTTP 링크, 상태값처럼 사용자가 실제로 기록할 필드를 설계해야 합니다.
- •진행 흐름에는 메모 앱 생성 후 HTTP 링크를 클릭하고 싶다, 필드를 더 추가해 메모/링크/옵션 저장, 수정 기능이 없네 같은 요청이 등장합니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1화면 흐름 확인
실행
해당 섹션에서 큐레이터 단비가 실제로 누르거나 입력한 대상을 먼저 적습니다.이유
추상 설명을 실제 화면 조작으로 바꾸기 위해서입니다.정상 확인
버튼, 파일, 명령, 오류 중 최소 하나를 정확히 기록했습니다. - 2내 프로젝트에 적용
실행
같은 작업을 내 Cursor 프로젝트에서 작은 범위로 적용합니다.이유
예시 화면과 내 환경은 다를 수 있어 직접 검증이 필요합니다.정상 확인
파일 변경, 터미널 출력, 브라우저 화면 중 두 가지 이상을 확인했습니다. - 3막히면 원문 전달
실행
오류나 헷갈리는 화면을 요약하지 말고 그대로 복사해 AI에게 줍니다.이유
원문이 있어야 AI가 원인을 정확히 추적합니다.정상 확인
질문에 오류 원문과 원하는 결과가 포함됐습니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 진행 전 | 계획/범위/유지할 기능을 먼저 말함 | 바로 전체 구현 요청 |
| 진행 중 | 파일 diff와 명령 의미를 확인 | 권한 요청을 무조건 승인 |
| 진행 후 | 브라우저와 터미널로 정상 결과 확인 | AI의 완료 메시지만 믿기 |
막히기 쉬운 지점과 해결
AI가 엉뚱한 작업을 함
원인: 목표와 제한 범위를 말하지 않았습니다.
해결: 기존 유지, 수정 범위, 완료 기준을 프롬프트에 넣습니다.
오류가 반복됨
원인: 오류 원문이나 실행 순서가 누락됐습니다.
해결: 터미널/브라우저 오류 전체와 방금 한 일을 함께 전달합니다.
배운 내용이 남지 않음
원인: 질문과 해결 과정을 기록하지 않았습니다.
해결: README나 정리 페이지에 오늘의 오류와 해결을 남깁니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓실제 화면 조작을 내 말로 설명할 수 있다.
- ✓내 프로젝트에서 같은 단계의 정상 결과를 확인했다.
- ✓실패 시 복사할 오류 원문과 질문 템플릿이 준비됐다.
- ✓다음 단계로 넘어가기 전 Keep/Undo 또는 브라우저 검증을 완료했다.
적용 과제: 프롬프트로 기능 확장하기 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
기존 메모 앱은 유지하고 기능만 확장해줘. 원하는 기능: HTTP 링크를 저장하고 목록에서 클릭 가능하게 만들기. 추가 필드: 제목, 메모, 링크 URL, 링크 설명. 주의: 기존 저장된 메모가 사라지면 안 됨. 먼저 DB/UI/서버 액션 중 무엇을 바꿀지 계획을 보여주고, 승인 후 구현해줘.
DB 확장과 배포 준비
로컬 SQLite에서 시작해 Supabase, Turso, MongoDB 같은 온라인 DB로 넘어가는 기준을 알아야 데이터가 사라지지 않습니다.
data 폴더의 SQLite 파일, src/app 구조, 로컬 DB와 원격 DB의 차이, 백업과 배포 준비를 이해합니다.
실전 맥락: 진행 흐름에는 SQLite, data 폴더, .next, node_modules, src/app, Supabase, Turso, MongoDB, 벡터 검색, Vercel 운영 이야기가 나옵니다.
핵심 개념
- 1SQLite는 내 컴퓨터 파일로 저장되는 가벼운 DB라 첫 실습에 좋습니다.
- 2data/database.sqlite 같은 파일 위치를 알아야 백업과 데이터 주권이 가능합니다.
- 3Supabase/Turso/MongoDB는 외부 접속과 배포 운영에 유리하지만 계정, 비용, 권한 관리가 필요합니다.
- 4DB 구조 변경 전에는 백업과 마이그레이션 계획을 AI에게 요구해야 합니다.
근거와 판단 포인트
- •로컬 SQLite에서 원격 DB로 넘어갈 때는 연결 문자열, 백업, 개인정보, 마이그레이션 순서를 문서화해야 하며 배포 전 비용과 장애 대응도 확인합니다.
- •진행 흐름에는 SQLite, data 폴더, .next, node_modules, src/app, Supabase, Turso, MongoDB, 벡터 검색, Vercel 운영 이야기가 나옵니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1화면 흐름 확인
실행
해당 섹션에서 큐레이터 단비가 실제로 누르거나 입력한 대상을 먼저 적습니다.이유
추상 설명을 실제 화면 조작으로 바꾸기 위해서입니다.정상 확인
버튼, 파일, 명령, 오류 중 최소 하나를 정확히 기록했습니다. - 2내 프로젝트에 적용
실행
같은 작업을 내 Cursor 프로젝트에서 작은 범위로 적용합니다.이유
예시 화면과 내 환경은 다를 수 있어 직접 검증이 필요합니다.정상 확인
파일 변경, 터미널 출력, 브라우저 화면 중 두 가지 이상을 확인했습니다. - 3막히면 원문 전달
실행
오류나 헷갈리는 화면을 요약하지 말고 그대로 복사해 AI에게 줍니다.이유
원문이 있어야 AI가 원인을 정확히 추적합니다.정상 확인
질문에 오류 원문과 원하는 결과가 포함됐습니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 진행 전 | 계획/범위/유지할 기능을 먼저 말함 | 바로 전체 구현 요청 |
| 진행 중 | 파일 diff와 명령 의미를 확인 | 권한 요청을 무조건 승인 |
| 진행 후 | 브라우저와 터미널로 정상 결과 확인 | AI의 완료 메시지만 믿기 |
막히기 쉬운 지점과 해결
AI가 엉뚱한 작업을 함
원인: 목표와 제한 범위를 말하지 않았습니다.
해결: 기존 유지, 수정 범위, 완료 기준을 프롬프트에 넣습니다.
오류가 반복됨
원인: 오류 원문이나 실행 순서가 누락됐습니다.
해결: 터미널/브라우저 오류 전체와 방금 한 일을 함께 전달합니다.
배운 내용이 남지 않음
원인: 질문과 해결 과정을 기록하지 않았습니다.
해결: README나 정리 페이지에 오늘의 오류와 해결을 남깁니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓실제 화면 조작을 내 말로 설명할 수 있다.
- ✓내 프로젝트에서 같은 단계의 정상 결과를 확인했다.
- ✓실패 시 복사할 오류 원문과 질문 템플릿이 준비됐다.
- ✓다음 단계로 넘어가기 전 Keep/Undo 또는 브라우저 검증을 완료했다.
적용 과제: DB 확장과 배포 준비 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
내 프로젝트 DB 구조를 설명해줘. 현재 목표: 로컬 SQLite로 시작하되 나중에 Supabase/Turso 배포 가능성을 열어두기. 확인할 것: DB 파일 위치, 백업 방법, 테이블 구조, 원격 DB로 옮겨야 하는 시점, 개인정보 주의사항.
데이터 주권과 지속 가능한 운영
내 앱과 데이터가 어디에 저장되는지 아는 순간, 단순 실습이 사업·콘텐츠·자동화 자산으로 바뀝니다.
로컬 DB 파일 위치, GitHub 코드 버전, Vercel 배포, Turso/Supabase 운영, 유튜브·웹사이트·제휴·제품 연결을 큰 그림으로 정리합니다.
실전 맥락: 후반 흐름에는 메모가 외부 서비스가 아니라 내 컴퓨터에 저장된다는 설명, 데이터 주권, Vercel/Turso/Supabase 운영, 유튜브 수익만으로는 어렵고 웹사이트·제휴·제품과 연결해야 한다는 메시지가 나옵니다.
핵심 개념
- 1데이터 주권은 철학이 아니라 “내 데이터 파일 위치를 알고 백업할 수 있는 상태”에서 시작합니다.
- 2코드는 GitHub에, 사이트는 Vercel에, 운영 데이터는 SQLite/Turso/Supabase에 둘 수 있습니다.
- 3질문 로그, 오류 해결 과정, README, 기능 추가 기록은 다음 프로젝트의 지식 자산입니다.
- 4입문자가 오래 써먹을 최종 목표는 앱 하나가 아니라 스스로 만들고 고치고 운영하는 반복 시스템입니다.
근거와 판단 포인트
- •데이터 주권은 백업뿐 아니라 비용 구조를 아는 것까지 포함합니다. Vercel, Turso, Supabase 같은 서비스는 무료 한도와 요금 전환 기준을 함께 관리해야 지속 운영이 가능합니다.
- •후반 흐름에는 메모가 외부 서비스가 아니라 내 컴퓨터에 저장된다는 설명, 데이터 주권, Vercel/Turso/Supabase 운영, 유튜브 수익만으로는 어렵고 웹사이트·제휴·제품과 연결해야 한다는 메시지가 나옵니다.
- •이 단계는 설명으로 끝내지 말고 실제 화면·터미널·파일 변화까지 확인해야 합니다.
- •화면 조작 순서를 정상 결과와 실패 대응 기준으로 정리했습니다.
적용 순서와 확인 기준
- 1화면 흐름 확인
실행
해당 섹션에서 큐레이터 단비가 실제로 누르거나 입력한 대상을 먼저 적습니다.이유
추상 설명을 실제 화면 조작으로 바꾸기 위해서입니다.정상 확인
버튼, 파일, 명령, 오류 중 최소 하나를 정확히 기록했습니다. - 2내 프로젝트에 적용
실행
같은 작업을 내 Cursor 프로젝트에서 작은 범위로 적용합니다.이유
예시 화면과 내 환경은 다를 수 있어 직접 검증이 필요합니다.정상 확인
파일 변경, 터미널 출력, 브라우저 화면 중 두 가지 이상을 확인했습니다. - 3막히면 원문 전달
실행
오류나 헷갈리는 화면을 요약하지 말고 그대로 복사해 AI에게 줍니다.이유
원문이 있어야 AI가 원인을 정확히 추적합니다.정상 확인
질문에 오류 원문과 원하는 결과가 포함됐습니다.
판단표: 이렇게 하면 안전합니다
| 상황 | 권장 | 주의 |
|---|---|---|
| 진행 전 | 계획/범위/유지할 기능을 먼저 말함 | 바로 전체 구현 요청 |
| 진행 중 | 파일 diff와 명령 의미를 확인 | 권한 요청을 무조건 승인 |
| 진행 후 | 브라우저와 터미널로 정상 결과 확인 | AI의 완료 메시지만 믿기 |
막히기 쉬운 지점과 해결
AI가 엉뚱한 작업을 함
원인: 목표와 제한 범위를 말하지 않았습니다.
해결: 기존 유지, 수정 범위, 완료 기준을 프롬프트에 넣습니다.
오류가 반복됨
원인: 오류 원문이나 실행 순서가 누락됐습니다.
해결: 터미널/브라우저 오류 전체와 방금 한 일을 함께 전달합니다.
배운 내용이 남지 않음
원인: 질문과 해결 과정을 기록하지 않았습니다.
해결: README나 정리 페이지에 오늘의 오류와 해결을 남깁니다.
실행 패널
바로 실행할 것만 모았습니다
완료 기준
- ✓실제 화면 조작을 내 말로 설명할 수 있다.
- ✓내 프로젝트에서 같은 단계의 정상 결과를 확인했다.
- ✓실패 시 복사할 오류 원문과 질문 템플릿이 준비됐다.
- ✓다음 단계로 넘어가기 전 Keep/Undo 또는 브라우저 검증을 완료했다.
적용 과제: 데이터 주권과 지속 가능한 운영 실습
진행
- •예시 흐름을 내 컴퓨터에서 같은 순서로 따라 합니다.
- •정상 결과와 오류 메시지를 각각 기록합니다.
- •모르는 용어는 Cursor Ask 또는 채팅에 바로 질문합니다.
확인
- •정상 결과 기준을 직접 확인했습니다.
- •실패했을 때 붙여넣을 오류 원문을 확보했습니다.
- •다음 단계로 넘어가도 되는 상태를 스스로 말할 수 있습니다.
내 앱의 데이터 주권 점검표를 만들어줘. 확인할 것: 코드 위치, DB 파일 위치, 백업 방법, GitHub에 올리면 안 되는 파일, 배포 시 필요한 환경변수, 사용자 데이터/개인정보 주의사항. 초보자가 실행할 순서대로 정리해줘.
복사해서 쓰는 바이브 코딩 지시문
초보자가 가장 자주 쓰는 요청을 그대로 붙여넣을 수 있게 모았습니다.
사용 원칙
- - 좋은 지시문은 목표, 범위, 완료 기준, 검증 방법을 함께 담습니다.
- - Cursor Agent에게 바로 구현을 맡기기 전 Plan 모드로 수정 파일과 위험 지점을 먼저 확인하면 실패 비용이 줄어듭니다.
- - "이 파일만", "디자인 유지", "기존 데이터 유지"처럼 지켜야 할 조건을 문장 앞쪽에 배치하세요.
작업 전 계획 요청
파일을 바꾸기 전에 AI가 먼저 범위와 순서를 말하게 만드는 기본 프롬프트입니다.
지금부터 이 프로젝트를 초보자 기준으로 같이 만들 거야. 먼저 코드는 수정하지 말고 아래를 정리해줘. 1. 현재 폴더 구조에서 어떤 파일을 봐야 하는지 2. 내가 만들려는 기능을 작은 단계로 나눈 계획 3. 각 단계가 끝났는지 확인하는 방법 4. 실수하면 되돌릴 수 있는 지점 내가 "진행해"라고 말하기 전까지 파일은 수정하지 마.
README 기반 설계
Cursor가 프로젝트 방향을 잃지 않게 만드는 문서 우선 요청입니다.
README.md를 먼저 읽고, 현재 프로젝트의 목표와 실행 방법을 요약해줘. 그 다음 내가 만들 기능을 README 기준으로 자연스럽게 붙일 수 있는 위치를 제안해줘. 출력 형식: - 현재 프로젝트 한 줄 요약 - 주요 실행 명령어 - 수정 후보 파일 - 위험한 변경과 안전한 변경 - 추천 작업 순서
범위 제한 프롬프트
원하지 않는 파일 변경을 막는 안전장치입니다.
이번 작업에서는 아래 파일/폴더만 수정해줘. 수정 허용 범위: [여기에 경로 입력] 규칙: - 허용 범위 밖 파일은 읽기만 하고 수정하지 마. - 새 파일도 허용 범위 안에만 만들어. - 변경 전 어떤 파일을 수정할지 먼저 목록으로 보여줘. - 작업 후 실제 수정 파일 목록을 다시 보고해줘.
오류 원인 분석
에러를 그냥 붙여넣는 대신, AI가 원인-수정-검증으로 나누게 합니다.
아래 오류를 해결해줘. 바로 수정하지 말고 먼저 원인을 분류해줘. 내가 실행한 명령어: [예: npm run dev] 오류 원문: [터미널 오류 전체 붙여넣기] 원하는 답변: 1. 가장 가능성 높은 원인 3개 2. 확인해야 할 파일/설정 3. 최소 수정안 4. 수정 후 다시 실행할 명령어 5. 같은 오류를 줄이는 습관
디자인 유지 보강
기존 레이아웃을 보존하면서 내용만 풍부하게 만들 때 씁니다.
기존 디자인과 레이아웃은 유지하고 정보량만 늘려줘. 요구사항: - 색상/카드/간격/반응형 구조는 최대한 그대로 유지 - 섹션 제목에는 번호를 직접 붙이지 않기 - 초보자가 따라할 수 있는 체크리스트 추가 - 복사 가능한 예시 프롬프트 또는 코드 추가 - 바꾼 이유를 마지막에 요약
기능 추가 요청
메모 앱, 링크 필드, 수정 버튼처럼 작은 기능을 붙일 때 적합합니다.
현재 앱에 [기능 이름]을 추가해줘. 현재 상태: - 이미 있는 기능: [예: 메모 작성/목록 보기] - 추가할 기능: [예: 링크 필드와 수정 버튼] 완료 기준: - 입력 화면에서 새 값을 받을 수 있어야 함 - 목록 화면에서 값이 보여야 함 - 기존 데이터는 깨지면 안 됨 - npm run dev에서 직접 확인할 수 있어야 함 먼저 수정 파일과 데이터 흐름을 설명한 뒤 진행해줘.
수업 실습을 앱 구조로 다시 보기
메모 앱, 링크 필드, 상태 변경, 아이디어 발상을 실제 코드 패턴으로 연결합니다.
실습을 따라갈 때 보는 순서
- 먼저 화면에 무엇이 보이는지 정합니다. 예: 제목, 메모 입력, 링크 입력, 목록 카드.
- 그 다음 저장할 데이터 이름을 정합니다. 예: title, memo, link_url, status.
- 마지막으로 생성, 수정, 삭제, 상태 변경을 각각 작은 함수로 분리합니다.
메모 앱 DB 테이블 뼈대
실전 예시처럼 로컬 SQLite로 먼저 시작하면 데이터 주권을 유지하면서 빠르게 앱을 만들 수 있습니다.
CREATE TABLE IF NOT EXISTS items ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, memo TEXT, link_url TEXT, extra_option TEXT, status TEXT NOT NULL DEFAULT 'todo', created_at TEXT NOT NULL, updated_at TEXT NOT NULL );
아이템 생성 로직 패턴
입력값을 받은 뒤 created_at/updated_at을 함께 저장하는 가장 기본적인 서버 로직입니다.
export function createItem(title: string, memo: string, linkUrl: string, extraOption: string): void {
const now = new Date().toISOString();
const safeMemo = memo || null;
db.prepare(`
INSERT INTO items (title, memo, link_url, extra_option, status, created_at, updated_at)
VALUES (?, ?, ?, ?, 'todo', ?, ?)
`).run(title, safeMemo, linkUrl || null, extraOption || null, now, now);
}상태 변경 로직 패턴
todo, doing, done처럼 허용된 값만 저장하게 하면 초보 프로젝트도 안정성이 올라갑니다.
const VALID_STATUSES = ['todo', 'doing', 'done'] as const;
type ItemStatus = typeof VALID_STATUSES[number];
export function updateItemStatus(id: number, status: ItemStatus): void {
if (!VALID_STATUSES.includes(status)) {
throw new Error('Invalid status value.');
}
db.prepare('UPDATE items SET status = ?, updated_at = ? WHERE id = ?')
.run(status, new Date().toISOString(), id);
}링크 필드 추가 요청
수업에서 다룬 링크 필드 확장처럼 UI, DB, 목록 표시를 한 번에 연결해야 합니다.
메모 앱에 링크 필드를 추가해줘. 반영 위치: - 작성 폼에 URL 입력칸 추가 - DB에는 link_url 컬럼으로 저장 - 목록 카드에서는 링크가 있으면 "열기" 버튼 표시 - 클릭하면 새 탭으로 열기 주의: - 기존 메모 데이터는 유지 - 비어 있는 링크는 저장하지 않아도 됨 - 모바일에서도 버튼이 줄바꿈되지 않게 처리
홈페이지 제목 변경 요청
처음에는 작은 텍스트 변경부터 성공 경험을 만드는 것이 좋습니다.
홈페이지 상단 제목을 "나의 첫 바이브 코딩 앱"으로 바꿔줘. 조건: - 제목만 바꾸고 레이아웃은 유지 - 모바일에서 줄바꿈이 어색하지 않게 확인 - 변경한 파일명을 알려줘
유튜브 채널 분석기 아이디어 요청
아이디어 발상도 개발 작업입니다. 먼저 기능을 작게 쪼개야 실제 구현으로 이어집니다.
유튜브 채널 분석기 웹앱을 만든다고 가정하고 MVP 기능을 설계해줘. 초보자용으로 나눠줘: - 첫 화면에 필요한 입력값 - 분석 결과 카드 3개 - 나중에 붙일 수 있는 고급 기능 - 실제 구현 전 더미 데이터로 먼저 만들 방법 - 배포 전에 확인할 체크리스트
바이브 코딩 용어 사전과 프로그램 URL
수업을 따라가며 자주 만나는 단어와 공식 사이트를 한곳에 모았습니다.
읽는 법
처음부터 모든 용어를 외울 필요는 없습니다. npm, Cursor, Agent/Plan, localhost, build만 먼저 익히고, DB와 배포 용어는 메모 앱이 실제로 동작한 뒤 확장 단계에서 다시 보면 충분합니다.
Cursor
AI 채팅과 코드 편집기가 합쳐진 개발 도구. 초보자는 먼저 프로젝트 폴더 열기, 채팅, 터미널 위치를 익히면 됩니다.
Agent Mode
AI가 파일을 읽고 수정하고 명령까지 실행하는 모드. 구현을 맡길 때 쓰되 변경 범위를 제한하는 문장이 중요합니다.
Plan Mode
코드를 바로 바꾸기 전에 설계와 작업 순서를 먼저 받는 모드. 큰 변경, 여러 파일 수정, 초보자 설계에 특히 유리합니다.
Auto Mode
모델 선택을 도구가 자동으로 처리하는 방식. 처음에는 비용과 복잡도를 낮추는 선택지입니다.
Allow List
AI가 반복적으로 실행해도 되는 명령을 허용하는 목록. npm install, npm run dev처럼 영향 범위를 이해한 명령부터 허용합니다.
Keep / Undo
AI가 제안한 변경을 유지하거나 되돌리는 승인 흐름. 한 번에 큰 변경을 시키면 Undo 판단이 어려워집니다.
Add to Chat
파일이나 코드 조각을 채팅 맥락에 넣는 기능. AI가 엉뚱한 파일을 추측하지 않도록 근거를 제공하는 행동입니다.
Context
AI가 현재 대화에서 참고할 수 있는 정보 묶음. 파일, 에러, 목표, 제약조건을 같이 주면 정확도가 올라갑니다.
npm
Node.js 패키지 설치와 실행 스크립트를 담당하는 도구. npm install, npm run dev, npm run build가 기본입니다.
node_modules
설치된 패키지가 들어가는 폴더. 직접 수정하지 않고 package.json과 npm install로 관리합니다.
package.json
프로젝트 이름, 실행 명령어, 의존성을 적는 파일. 초보자는 scripts 영역을 먼저 보면 됩니다.
Dev Server
개발 중 확인하는 로컬 서버. localhost 주소는 본인 컴퓨터에서만 열립니다.
Build
배포 가능한 결과물로 앱을 점검/변환하는 단계. 개발 서버에서 되던 것이 build에서 실패할 수 있어 반드시 확인합니다.
SQLite
파일 하나로 시작할 수 있는 로컬 데이터베이스. 메모 앱, 개인 도구, 개인 연습용 앱에 적합합니다.
Supabase
Postgres 기반 백엔드 서비스. 로그인, DB, 스토리지까지 필요할 때 확장 후보입니다.
Turso
SQLite 계열을 서버리스로 확장하는 DB 서비스. 로컬 SQLite에서 운영형 구조로 넘어갈 때 고려할 수 있습니다.
Vercel
Next.js 앱 배포에 많이 쓰는 플랫폼. GitHub와 연결하면 배포 자동화가 쉬워집니다.
Environment Variable
API 키나 DB 주소를 코드 밖에서 주입하는 값. 보통 .env 파일을 쓰며 공개 저장소에 올리면 안 됩니다.
공식 사이트 모음
| 도구 | URL |
|---|---|
| Cursor | https://cursor.com |
| Node.js | https://nodejs.org |
| npm | https://www.npmjs.com |
| Next.js | https://nextjs.org |
| React | https://react.dev |
| TypeScript | https://www.typescriptlang.org |
| Tailwind CSS | https://tailwindcss.com |
| GitHub | https://github.com |
| Vercel | https://vercel.com |
| Supabase | https://supabase.com |
| Turso | https://turso.tech |
| SQLite | https://www.sqlite.org |
| MDN Web Docs | https://developer.mozilla.org |
| Playwright | https://playwright.dev |
| shadcn/ui | https://ui.shadcn.com |
| Radix UI | https://www.radix-ui.com |
운영 현실·장기 지속 전략·FAQ
도구 선택보다 중요한 것은 반복 가능한 실행 루프를 만드는 것입니다.
대본 근거 요지
- - 대본 후반부에서 운영 시간 대비 수익 구조와 지속성 문제를 현실적으로 설명했습니다.
- - 질문 반복과 작은 개선 누적이 장기적으로 가장 강한 성장 전략이라고 정리했습니다.
운영 전략 비교
| 구분 | 권장 | 주의 |
|---|---|---|
| 읽는 방식 | 질문-구현-검증 루프를 고정 | 한 번에 완벽 구현을 목표로 과부하 |
| 운영 관점 | 시간/비용/지속 가능성 함께 판단 | 기능만 늘리고 유지비 고려 누락 |
| 작업 전략 | 작은 개선을 누적해 품질 상승 | 대규모 변경을 한 번에 밀어넣기 |
장기 지속 전략
- - 계획, 구현, 검증을 분리해 작업 피로를 줄입니다.
- - 기능 추가는 작은 단위로 쪼개고 매번 동작을 확인합니다.
- - 수익화/운영 목표와 운영 목표를 분리해 관리합니다.
처음부터 Plan 모드를 써야 하나요?
기능이 2개 이상이거나 파일이 여러 개 바뀌면 Plan 모드가 유리합니다. 단순 텍스트 수정 정도는 Agent 모드로 바로 진행해도 됩니다.
오류가 나면 어떤 순서로 질문해야 하나요?
오류 원문 전달 -> 원인 요약 요청 -> 최소 수정안 요청 -> 재실행 검증 순서가 가장 안정적입니다.
AI가 만든 코드를 다 신뢰해도 되나요?
아니요. Keep/Undo 기준을 유지하고, 핵심 파일은 반드시 직접 읽어 확인해야 장기적으로 안정적인 프로젝트를 유지할 수 있습니다.
지속적으로 실력을 올리려면 무엇을 반복해야 하나요?
질문 품질 개선, 작은 기능 반복 구현, 오류 해결 로그 축적 이 3가지를 계속 반복하면 실전 속도가 빠르게 올라갑니다.
오토 모드만 쓰면 충분한가요?
초기에는 충분하지만, 복잡한 작업에서는 Plan 모드로 설계를 먼저 확정한 뒤 실행하는 방식이 품질과 안정성에 더 유리합니다.
로컬호스트 주소를 다른 사람에게 보내도 되나요?
안 됩니다. localhost는 본인 컴퓨터에서만 열립니다. 외부 공유가 필요하면 배포 플랫폼을 통해 공개 URL을 만들어야 합니다.
오류가 연속으로 발생하면 어떻게 정리해야 하나요?
최근 실행 명령, 에러 원문, 현재 목표를 한 번에 정리해 AI에 전달하세요. 맥락이 정리되면 해결 속도가 확실히 빨라집니다.
AI가 만든 구조를 어디까지 그대로 써도 되나요?
초기 뼈대는 활용하되, 핵심 로직과 데이터 흐름은 직접 이해하고 유지보수 가능한 형태로 점진적으로 정리하는 것이 좋습니다.