기능을 부탁하기 전에 `git status`로 기존 변경을 확인하고 기준 커밋을 만드세요.
디지털·제작
바이브 코딩 가이드
작업을 작은 변경으로 나누고 실행·테스트·Git 저장·되돌리기를 반복해 망가지지 않는 프로그램을 만듭니다.
실전 방법5가지 상황별 설명
바로 확인할 기준입력 하나와 결과 하나가 있는 작은 웹 도구를 로컬에서 실행하고 직접 테스트하기
우선 확인할 항목
AI와 대화하며 작은 웹사이트나 프로그램을 만들되, 작동 여부를 직접 확인하고 언제든 이전 상태로 되돌리고 싶은 분을 위한 가이드입니다. 코드 저장소에는 API 키, 비밀번호, 인증서와 실제 사용자 데이터를 넣지 마세요.
한 번에 화면 하나, 동작 하나, 완료 조건 하나만 바꾸세요.
실행 명령, 실제 클릭 순서, 기대 결과를 요청문에 함께 적으세요.
완료 보고보다 `git diff`, 테스트 결과, 브라우저 콘솔을 직접 확인하세요.
필요한 준비물 확인
- 1코드와 결과를 함께 볼 수 있는 개발 환경
- 2한 문장으로 설명되는 작은 기능
- 3수정 전 상태로 돌아갈 Git 또는 복사본
- 4성공·실패 입력을 적은 확인 목록
바이브 코딩 가이드 용어 사전
기본 동작과 도구 이름부터 경험자가 자주 쓰는 전문 표현까지, 뜻과 실제 사용하는 상황을 함께 정리했습니다.
- 01저장소·리포지토리
-
프로젝트 코드와 변경 기록을 함께 보관하는 작업 폴더입니다.
실제로는AI에 수정 범위를 줄 때 저장소와 대상 파일을 명확히 구분합니다.
- 02브랜치
-
기존 코드에서 갈라져 독립적으로 변경을 쌓는 작업 흐름입니다.
실제로는실험 기능은 별도 브랜치에서 확인한 뒤 안정된 변경만 합칩니다.
- 03커밋
-
관련된 파일 변경을 설명과 함께 한 시점으로 기록한 단위입니다.
실제로는서로 다른 목적의 수정은 나눠야 되돌리거나 검토하기 쉽습니다.
- 04의존성
-
프로젝트가 실행되기 위해 가져다 쓰는 외부 라이브러리나 패키지입니다.
실제로는새 패키지를 추가하기 전에 기존 기능으로 가능한지와 보안·용량 영향을 봅니다.
- 05빌드
-
원본 코드를 브라우저나 서버가 배포·실행할 수 있는 결과물로 변환하는 과정입니다.
실제로는코드가 저장됐다는 사실과 빌드가 성공했다는 사실을 따로 확인합니다.
- 06배포
-
검증한 결과물을 실제 사용자가 접속하는 환경에 올리는 작업입니다.
실제로는로컬 성공만으로 배포하지 말고 테스트·롤백 지점·운영 주소를 확인합니다.
- 07워킹 트리
-
현재 컴퓨터에 체크아웃되어 직접 열고 수정하는 프로젝트 파일들의 상태입니다.
실제로는`git status`로 커밋된 기준과 다른 수정·추가·삭제 파일을 먼저 확인합니다.
- 08스테이징
-
다음 커밋에 포함할 파일 내용의 스냅샷을 Git 인덱스에 올리는 과정입니다.
실제로는`git add` 뒤 파일을 다시 고치면 새 수정분은 자동 포함되지 않아 차이를 재확인합니다.
- 09Diff
-
두 파일 상태나 커밋 사이에서 추가·삭제·변경된 내용을 보여 주는 비교입니다.
실제로는AI가 만든 변경도 실행 결과만 보지 말고 diff로 범위와 의도치 않은 삭제를 검토합니다.
- 10머지
-
서로 다른 브랜치의 개발 이력을 하나의 결과로 합치는 작업입니다.
실제로는자동 합쳐졌어도 테스트하고, 충돌 해결 뒤 양쪽 의도가 모두 남았는지 확인합니다.
- 11리베이스
-
한 브랜치의 커밋들을 다른 기준점 위에 다시 적용해 이력을 재구성하는 작업입니다.
실제로는공유한 커밋을 무심코 다시 쓰면 협업이 꼬일 수 있어 팀 규칙과 백업을 확인합니다.
- 12충돌
-
Git이 서로 다른 변경을 자동으로 하나의 결과로 결정하지 못한 상태입니다.
실제로는충돌 표시를 단순 삭제하지 말고 양쪽 코드의 목적을 이해한 뒤 빌드와 테스트를 실행합니다.
- 13풀 리퀘스트·PR
-
브랜치 변경을 검토하고 대상 브랜치에 합치자고 제안하는 협업 단위입니다.
실제로는변경 이유·검증 방법·위험·스크린샷을 적고 리뷰가 가능한 크기로 나눕니다.
- 14이슈
-
버그·요구사항·질문·작업을 추적하는 기록 단위입니다.
실제로는재현 단계·기대 결과·실제 결과·환경을 남기면 AI와 사람 모두 정확히 대응하기 쉽습니다.
- 15환경변수
-
프로그램 코드 밖에서 실행 환경별 설정값을 전달하는 이름 있는 값입니다.
실제로는개발·시험·운영 값을 분리하고 필수 값 누락 시 시작 단계에서 명확히 실패하게 합니다.
- 16시크릿
-
API 키·토큰·비밀번호처럼 노출되면 권한 악용이 가능한 민감한 인증 값입니다.
실제로는저장소와 프론트엔드 번들에 넣지 말고 비밀 저장소에 두며 유출 시 즉시 폐기·교체합니다.
- 17린트
-
코드를 실행하기 전에 정해진 규칙과 흔한 오류 패턴을 정적으로 검사하는 과정입니다.
실제로는포맷터와 역할이 다르며 경고를 무조건 끄기보다 원인과 팀 규칙을 확인합니다.
- 18테스트
-
주어진 입력과 조건에서 코드가 기대한 결과를 내는지 자동 또는 수동으로 확인하는 절차입니다.
실제로는정상 경로뿐 아니라 경계값·오류·권한·모바일·접근성 사례도 포함합니다.
- 19CI
-
코드 변경마다 빌드·테스트·검사를 자동 실행해 통합 문제를 빨리 찾는 체계입니다.
실제로는로컬 성공만 믿지 말고 CI가 사용하는 운영체제·버전·환경값을 재현 가능하게 고정합니다.
- 20롤백
-
문제가 생긴 변경이나 배포를 이전의 알려진 정상 상태로 되돌리는 조치입니다.
실제로는코드만 되돌려도 데이터베이스·캐시·외부 API 변경이 남을 수 있어 복구 절차를 미리 시험합니다.
- 21시맨틱 버저닝
-
버전을 `주버전.부버전.패치`로 표시해 호환성 변화의 의미를 전달하는 규칙입니다.
실제로는팀이나 패키지가 실제로 이 규칙을 따르는지 확인하고 숫자만 보고 호환성을 단정하지 않습니다.
- 22락파일
-
설치된 의존성의 정확한 버전과 해시·의존 관계를 기록한 파일입니다.
실제로는애플리케이션 저장소에서는 함께 커밋하고 패키지 관리자 명령으로 갱신해 재현성을 지킵니다.
- 23API
-
프로그램끼리 기능과 데이터를 요청·응답하도록 정한 규칙과 접점입니다.
실제로는요청 형식·인증·오류 코드·속도 제한·버전 정책을 문서와 실제 응답으로 확인합니다.
- 24스택 트레이스
-
오류가 발생하기까지 호출된 함수와 파일·줄 위치를 역순으로 보여 주는 기록입니다.
실제로는첫 줄만 보지 말고 프로젝트 코드가 처음 등장하는 지점과 원인 오류를 함께 추적합니다.
맞는 용어를 찾지 못했습니다
검색어를 짧게 줄이거나 도구·동작·상황 이름으로 다시 찾아보세요.
상황별 선택 기준
무조건 한 방법을 쓰지 말고 원하는 결과와 현재 조건에 맞춰 고르세요.
아이디어를 빠르게 화면으로 보고 싶다
- 이렇게 선택
- 새 브랜치에서 가짜 데이터로 만드는 정적 시제품
- 선택 이유
- 인증, 결제, 데이터베이스 없이도 사용자 흐름과 화면 구조를 먼저 검증할 수 있습니다.
- 피하거나 바꿀 때
- 첫 시제품부터 실제 결제·로그인·개인정보 저장을 연결하는 것
기존 기능을 고치고 싶다
- 이렇게 선택
- 오류를 재현하는 테스트를 먼저 만들고 가장 작은 파일 범위만 수정
- 선택 이유
- 원래 동작을 증거로 남겨야 수정이 진짜 원인을 해결했는지 확인할 수 있습니다.
- 피하거나 바꿀 때
- 오류 원인을 찾기 전에 관련 파일 전체를 다시 작성하는 것
외부 API를 붙이고 싶다
- 이렇게 선택
- 가짜 응답으로 화면을 먼저 만들고 비밀값은 환경변수, 호출은 서버 측에서 처리
- 선택 이유
- 브라우저 코드에 키를 넣으면 방문자가 그대로 볼 수 있고, API 장애가 화면 전체 장애로 번질 수 있습니다.
- 피하거나 바꿀 때
- 키를 JavaScript, JSON, 예제 파일, 로그 또는 커밋 기록에 넣는 것
AI가 만든 큰 변경을 합치고 싶다
- 이렇게 선택
- 기능별 커밋으로 쪼개고 자동 테스트와 실제 사용자 경로를 각각 확인한 뒤 병합
- 선택 이유
- 작은 커밋은 문제를 찾고 특정 변경만 되돌리기 쉽습니다.
- 피하거나 바꿀 때
- 수백 파일 변경을 한 커밋으로 합치거나 테스트 실패 상태에서 추가 수정을 계속 쌓는 것
상황별 실행 방법
각 항목에 필요한 설정, 실행 순서, 확인 기준과 문제 해결 방법을 정리했습니다.
01 새 작업을 위한 안전한 기준점 만들기AI에게 첫 코드 변경을 요청하기 직전
먼저 맞출 설정·조건
- 버전관리: 기능별 브랜치 1개, 작업 시작 시 깨끗한 `git status`
- 비밀값: `.env`는 `.gitignore`, 저장소에는 `.env.example`의 변수 이름만 보관
실행 순서
- 1프로젝트의 실행, 빌드, 테스트 명령을 직접 한 번 실행해 수정 전 상태를 확인합니다.
- 2`git status`와 `git diff`로 이미 있던 사용자 변경을 확인하고, 내 작업과 섞지 않습니다.
- 3기능 이름의 새 브랜치를 만들고, 필요하면 수정 전 기준 커밋 또는 태그를 남깁니다.
- 4저장소 전체에서 키 패턴과 `.env` 추적 여부를 확인한 다음 AI에 제공할 파일 범위를 지정합니다.
잘됐는지 확인
- 수정 전 빌드·테스트 결과와 기준 커밋을 알고 있습니다.
- 추적 파일과 커밋 기록에 실제 비밀값이 없습니다.
이럴 때는 이렇게
누가 만든 변경인지 확인하고 임의로 지우지 마세요. 내 작업 파일과 겹치면 별도 커밋·브랜치 또는 사용자 확인으로 경계를 정합니다.
패키지 스크립트와 CI 설정에서 실제 명령을 찾고, 기준 상태가 깨져 있음을 먼저 기록한 뒤 기능 작업과 분리합니다.
02 기능을 한 조각씩 구현하기화면과 동작을 실제 코드로 추가하거나 변경할 때
먼저 맞출 설정·조건
- 한 조각: 사용자 진입점 1개, 상태 변화 1개, 눈에 보이는 결과 1개
- 완료 증거: 자동 테스트 + 실제 브라우저·앱 경로 + 콘솔 오류 확인
실행 순서
- 1기능을 '사용자가 어디서 시작해 무엇을 누르면 무엇이 보인다' 형식으로 씁니다.
- 2수정 가능한 파일과 건드리지 않을 파일, 데이터 저장 위치, 실패 시 동작을 요청에 적습니다.
- 3가장 작은 동작을 구현하고 바로 빌드·테스트·실제 클릭 검증을 실행합니다.
- 4`git diff`에서 의도하지 않은 리팩터링, 잠금 파일 변경, 생성 파일과 문구 삭제가 없는지 확인한 뒤 커밋합니다.
잘됐는지 확인
- 사용자 경로 하나가 처음부터 끝까지 작동하며 실패 상태도 설명됩니다.
- 커밋 하나만 되돌리면 이 기능만 제거할 수 있습니다.
이럴 때는 이렇게
수정을 합치지 말고 기준점으로 돌아간 뒤 허용 파일과 변경 상한을 더 좁혀 다시 요청하세요.
DOM 존재 확인이 아니라 실제 클릭 후 상태와 결과를 검사하는 테스트를 만들고 콘솔·네트워크 오류를 함께 확인하세요.
03 사용자가 겪는 경로 그대로 검증하기기능 구현이 끝났다고 판단하기 전
먼저 맞출 설정·조건
- 필수 상태: 초기, 로딩, 비어 있음, 성공, 오류, 재시도, 새로고침
- 화면 폭: 최소 모바일, 일반 모바일, 데스크톱에서 텍스트 넘침과 포커스 확인
실행 순서
- 1새 브라우저 상태에서 실제 공개 진입 URL 또는 앱 시작점으로 들어갑니다.
- 2사용자가 누르는 순서대로 입력·클릭하고, 중간 상태와 최종 결과를 화면에서 확인합니다.
- 3네트워크 실패, 잘못된 입력, 중복 클릭을 재현해 오류 안내와 재시도가 작동하는지 확인합니다.
- 4새로고침하거나 앱을 다시 열어 저장돼야 할 값과 초기화돼야 할 값이 각각 맞는지 확인합니다.
잘됐는지 확인
- 테스트 이름이 실제 시작점, 행동, 결과를 그대로 설명합니다.
- 오류 후 재시도와 새로고침까지 막힘 없이 완료됩니다.
이럴 때는 이렇게
모의 함수 직접 호출 대신 실제 버튼과 라우팅을 거치는 브라우저 테스트를 추가하고 그 테스트를 회귀 기준으로 삼으세요.
임의 대기시간을 늘리기보다 완료 신호를 기다리고, 실패 시 콘솔·요청·현재 DOM 상태를 남기도록 진단을 추가하세요.
04 패키지 추가와 빌드 오류를 안전하게 복구하기새 라이브러리를 설치하거나 업데이트해야 할 때
먼저 맞출 설정·조건
- 의존성 선택: 기존 패키지로 해결 가능한지 먼저 확인하고 정확한 버전과 라이선스 기록
- 변경 범위: 매니페스트와 잠금 파일을 함께 검토하고 설치 전후 취약점·빌드 비교
실행 순서
- 1추가하려는 기능이 표준 기능이나 기존 의존성으로 가능한지 저장소를 검색합니다.
- 2공식 저장소에서 유지보수 상태, 라이선스, 지원 런타임과 최신 안정 버전을 확인합니다.
- 3별도 커밋에서 설치하고 매니페스트·잠금 파일 차이, 번들 크기, 빌드와 테스트를 확인합니다.
- 4문제가 생기면 폴더를 임의 삭제하며 맞추지 말고 해당 커밋을 되돌린 뒤 잠금 파일 기준으로 깨끗하게 재설치합니다.
잘됐는지 확인
- 왜 이 패키지가 필요한지와 제거할 때 지울 파일을 설명할 수 있습니다.
- 새 설치 환경에서도 잠금 파일로 같은 의존성과 빌드 결과를 재현합니다.
이럴 때는 이렇게
잠금 파일까지 이전 커밋으로 되돌려 기준 테스트를 회복한 다음, 호환 버전 범위와 중복 의존성을 확인하세요.
런타임 버전을 고정하고 깨끗한 임시 디렉터리나 CI에서 잠금 설치부터 다시 실행해 숨은 전역 도구 의존성을 찾으세요.
05 검증된 커밋으로 합치고 문제 변경만 되돌리기기능을 기본 브랜치에 합치기 전이나 배포 후 문제가 발견됐을 때
먼저 맞출 설정·조건
- 커밋 단위: 기능, 테스트, 의존성 변경을 가능한 한 분리하고 메시지에 사용자 영향 기록
- 롤백 원칙: 공유 기록은 `git revert`, 미공유 로컬 실험만 기준점 재설정 고려
실행 순서
- 1`git diff`와 커밋 목록에서 기능과 무관한 파일, 비밀값, 생성물 누락이 없는지 확인합니다.
- 2빌드·테스트·실제 사용자 경로를 최종 커밋 상태에서 다시 실행합니다.
- 3문제가 생기면 증상을 재현하고 원인이 된 커밋을 찾은 뒤 `git revert <commit>`으로 반대 변경을 새 커밋에 기록합니다.
- 4되돌린 상태에서 같은 사용자 경로를 재검증하고, 수정 재도전은 새 브랜치에서 더 작은 범위로 시작합니다.
잘됐는지 확인
- 누가 봐도 어떤 변경을 왜 되돌렸는지 커밋 기록에서 알 수 있습니다.
- 롤백 후 이전 정상 기능과 데이터 형식이 그대로 복구됩니다.
이럴 때는 이렇게
즉시 전체 되돌리기가 더 안전한지 판단하고, 그렇지 않으면 별도 브랜치에서 역패치를 검토·테스트한 뒤 적용하세요.
커밋만 되돌리지 말고 비밀값을 즉시 회전·폐기하고 노출 범위를 확인한 뒤 기록 제거 절차를 별도로 진행하세요.
단계별 연습
4번의 핵심 연습
주차보다 순서가 중요합니다. 한 단계가 익숙해지면 다음 단계로 진행하세요.
1단계
환경과 기본 동작
화면 하나, 입력 하나, 결과 하나로 범위를 줄여 첫 버전을 실행합니다.
2단계
같은 기준으로 반복
오류를 재현하는 순서와 기대 결과를 적고 한 문제씩 수정합니다.
3단계
작은 변화 적용
모바일, 빈 입력, 긴 글자, 새로고침에서 깨지는 상태를 확인합니다.
4단계
혼자서 완성하고 기록
작동하는 단위로 커밋하고 배포 전 비밀값과 외부 전송을 검사합니다.
완료한 단계는 다음 방문에도 이어서 볼 수 있으며, 진행 초기화 버튼으로 다시 시작할 수 있습니다.
시간과 컨디션에 맞춘 연습
시간과 컨디션을 선택하면 준비, 핵심 동작과 확인 시간을 나눠 표시합니다.
결과 점검·실수·안전
수정 전 실행·빌드·테스트 상태와 기준 커밋을 확인했다.
한 번에 하나의 사용자 동작과 완료 결과만 변경했다.
API 키와 비밀번호는 저장소 밖 환경변수에만 있다.
실제 클릭·입력 경로로 정상, 실패, 재시도, 새로고침을 확인했다.
`git diff`에서 의도하지 않은 파일 변경을 확인했다.
새 의존성의 버전, 라이선스, 잠금 파일과 제거 방법을 확인했다.
기능 커밋을 단독으로 되돌릴 수 있다.
최종 커밋 상태에서 빌드와 사용자 경로를 다시 검증했다.
처음에 줄이면 좋은 실수
- 실행하지 않은 코드를 완성됐다고 생각하기
- 한 번에 여러 파일을 크게 바꿔 원인을 잃기
- 생성된 설명을 읽지 않고 자격 증명이나 삭제 명령을 실행하기
안전하게 즐기는 기준
- 비밀값은 채팅·코드·저장소에 직접 넣지 말고 서비스의 secret 저장소를 사용하세요.
- 삭제·결제·권한·production 배포는 정확한 대상과 롤백을 확인한 뒤 별도로 승인하세요.
참고한 공식·전문 자료
기기·앱·안전 기준은 바뀔 수 있습니다. 지원 기능과 최신 주의사항은 링크된 원문에서 다시 확인하세요.
- Git — git status Documentation2026-07-25
- Git — git revert Documentation2026-07-25
- GitHub Docs — Push protection2026-07-25
- GitHub Docs — About protected branches2026-07-25
글자 수 세기
비밀번호 생성기
액정 번인 확인