다섯 번째 손가락 '맥락'은 사실 앞의 모든 기술을 관통하는 원리입니다. 규칙은 한 줄로 요약됩니다 — LLM에게 관련 정보를 많이 줄수록 결과가 좋아집니다. 반대로 정보가 빈약하면, 아무리 똑똑한 AI도 헛다리를 짚습니다.
"안 돼요"는 세상에서 가장 약한 맥락입니다. 무엇이, 어디서, 어떻게 안 되는지가 없으니까요. 좋은 바이브 코더는 '무엇을 안 주었는지'를 늘 의식합니다.
맥락은 여러 모습으로 온다
- 자세한 프롬프트나 PRD — 무엇을 왜 만드는지에 대한 글로 된 설명
- 원하는 모습의 목업(mockup)·스케치·참고 화면 — '이렇게 생기게 해 줘'
- 예시 데이터나 참고 자료 — '이런 형식의 데이터를 다뤄'
- 앱·환경·취향에 대한 정보 — '이건 모바일 우선이고, 색은 이 계열로'
- 디버깅 시: 에러 메시지 전문 + 깨진 화면 스크린샷 + 봐야 할 파일
글로 설명하기 어려운 '느낌'은 이미지로 주세요. 원하는 화면을 손으로 대충 그린 스케치, 마음에 드는 다른 앱의 스크린샷 한 장이 긴 문장 열 개보다 정확하게 전달됩니다.
두 가지 모드 — 지금 나는 어디에 있나
바이브 코딩을 하는 어느 순간이든, 당신은 정확히 둘 중 하나의 모드에 있습니다. (A) 새 기능을 구현하는 중이거나, (B) 에러를 디버깅하는 중입니다. 지금 어느 모드인지 아는 것만으로 '다음에 뭘 해야 하지?'라는 질문이 저절로 풀립니다.
두 가지 모드 — 지금 나는 어디에 있나
(A) 구현 모드 — 새 기능 만들기
- 새 기능의 맥락 제공 (프레임워크·문서·상세)
- 조금씩 나눠 변경
- 자주 체크포인트
(B) 디버깅 모드 — 에러 고치기
- 먼저 프로젝트 구조 파악 (모르면 AI에게 물어봄)
- 무엇이 진짜 문제인지 찾기
- 정보(스샷·에러·파일)를 넘겨 고침
구현 모드에서는 '정보를 주고 조금씩 짓고 저장', 디버깅 모드에서는 '구조 파악 → 원인 찾기 → 정보 넘겨 고치기'. 모드가 곧 행동 지침입니다.
| 구분 | (A) 구현 모드 | (B) 디버깅 모드 |
|---|---|---|
| 목표 | 새 기능을 더한다 | 깨진 것을 고친다 |
| 먼저 할 일 | 기능의 맥락을 준다 | 구조를 파악하고 원인을 찾는다 |
| 작업 크기 | 작게, 조금씩 | 한 번에 하나의 문제 |
| 끝나면 | 반드시 체크포인트 저장 | 고쳐졌는지 확인 후 저장 |
MVP 먼저 — 작게 시작해 키운다
무엇을 만들든, 항상 MVP(Minimum Viable Product, 최소 기능 제품)부터 시작하세요. MVP는 '작동하는 가장 작은 버전'입니다. 처음부터 기능 스무 개가 꽉 찬 꿈의 완성품을 한꺼번에 만들려 하면, 어디서 터졌는지 알 수 없는 에러가 눈사태처럼 쏟아집니다.
MVP 먼저 — 작게 시작해 키운다
나쁨 — 처음부터 꿈의 완성품
- 기능 20개를 한꺼번에 만들기
- 에러 폭탄
- 어디가 문제인지 못 찾음
좋음 — MVP → 반복
- MVP: 일단 작동하는 최소 버전
- +기능 1: 확인·저장
- +기능 2: 확인·저장
- +기능 3 ...: 계속 키움
일단 되게 만들고, 그다음 좋게 만든다
최소 기능부터 만들면, 문제가 생겨도 방금 더한 한 조각만 의심하면 됩니다. 매 단계 작동을 확인하고 저장하며 앞으로 나아갑니다.
과욕(over-scoping)은 초보 바이브 코더의 가장 흔한 실패 원인입니다. 한 번에 많은 것을 요구할수록 문제의 원인을 특정하기 어려워지고, 결국 프로젝트 전체가 손대기 무서운 상태가 됩니다. '지금 꼭 필요한 최소한'이 무엇인지 계속 물으세요.
한 번에 하나씩
고칠 점이나 바꿀 점이 여러 개 떠올라도, 한 번에 하나씩 지시하세요. '이것도 저것도 그리고 그것도'처럼 몰아서 말하면 AI가 우선순위를 잃고 엉뚱한 곳까지 건드립니다. 하나 지시 → 확인 → (필요하면 저장) → 다음 하나. 이 리듬이 사고를 예방합니다.
지금까지 다섯 손가락을 모두 폈습니다. 마지막 레슨에서는 이 좋은 습관들을 매번 되풀이해 말하지 않아도 AI가 알아서 지키게 만드는 장치 — '규칙 파일'과, 비개발자가 반드시 알아야 할 보안 기초를 다룹니다.