입문 코스의 마지막 글입니다. 앞선 여섯 글에서 배운 조작법을 어떤 태도로 쓸 것인지가 주제입니다. "바이브 코딩"이라는 말은 널리 쓰이지만 뜻이 사람마다 다릅니다. 이 글은 정의를 좁게 잡고, 그 방식이 어디까지 통하고 어디서 무너지는지, 그리고 우리 교육이 왜 "도구가 아니라 시스템"을 가르치는지를 설명합니다.
핵심 요약
- 바이브 코딩은 코드를 읽지 않고 결과만 보며 AI에 맡기는 방식입니다. AI 보조 개발과는 "사람이 코드를 검토하느냐"에서 갈립니다.
- 작고, 혼자 쓰고, 버려도 되는 것에는 잘 통합니다.
- 데이터, 돈, 남의 정보, 오래 유지할 코드에서 무너집니다.
- 안전하게 쓰는 방법은 지침 파일과 검증 게이트, 되돌릴 기준점입니다.
학습 목표
- 바이브 코딩과 AI 보조 개발을 한 문장으로 구분할 수 있다.
- 내가 하려는 작업이 "통하는 조건"에 있는지 "무너지는 지점"에 있는지 판단할 수 있다.
- 무너지는 지점에서도 쓸 수 있게 만드는 세 가지 장치를 안다.
1. AI 보조 개발과 무엇이 다른가
바이브 코딩이라는 말은 2025년 초 안드레이 카파시가 자신의 방식을 설명하며 붙인 이름입니다. 핵심은 "코드를 읽지 않는다"입니다. 오류가 나면 오류 메시지를 그대로 붙여넣고, 결과가 그럴듯하면 다음으로 넘어갑니다. 코드는 존재하지만 사람의 검토 대상이 아닙니다.
AI 보조 개발은 같은 도구를 쓰되 사람이 diff를 읽고 승인합니다. Claude Code의 Manual(default) 권한 모드가 파일 편집마다 승인을 묻는 것이 이 방식을 전제로 합니다. 차이는 AI가 얼마나 많이 쓰느냐가 아니라, 사람이 무엇을 검토하느냐입니다. 교재 1주차의 표현으로는 소프트웨어 3.0, 즉 "의도만 주면 AI의 지능이 나머지를 채운다"가 두 방식의 공통 전제이고, 채워진 것을 확인하느냐가 갈림길입니다.
2. 실제로 어떻게 진행되나
전형적인 하루는 이렇습니다. 원하는 것을 한 문단으로 말합니다. 만들어진 것을 실행합니다. 안 되면 오류를 붙여넣습니다. 되면 다음 기능을 말합니다. 이 루프가 빠르게 돌기 때문에 몇 시간 만에 동작하는 무언가가 나옵니다.
Claude Code로 하면 이 루프가 더 빨라집니다. 파일을 알아서 읽고, 명령을 실행하고, 테스트까지 돌립니다. 공식 문서의 에이전트 루프(컨텍스트 수집, 작업 수행, 결과 검증)가 사람 개입 없이 돌아가는 것입니다. 그래서 더 위험해지기도 합니다. 사람이 읽지 않는 코드가 사람이 보지 않는 사이에 늘어납니다.
3. 언제 통하는가
- 작은 것. 파일 한두 개짜리 도구, 일회성 변환 스크립트, 개인용 화면.
- 혼자 쓰는 것. 남의 데이터를 만지지 않고, 틀려도 나만 손해인 것.
- 버려도 되는 것. 다음 주에 다시 만들어도 되는 시제품.
- 결과가 눈에 보이는 것. 화면이나 파일로 맞고 틀림을 바로 확인할 수 있는 것.
교재 1주차의 첫 실습(공고문 핵심 뽑기, 폴더 정리)이 정확히 이 범위입니다. 첫날은 여기서 시작하는 것이 맞습니다.
4. 어디서 무너지는가
- 데이터. 교재 3주차의 4구간 중 DB는 "손실이 되돌릴 수 없는" 구간입니다. 읽지 않은 코드가 마이그레이션을 실행하면 복구할 기준점이 없습니다.
- 돈과 보안. 결제, 로그인, 키 관리는 "그럴듯하게 동작"과 "안전하게 동작"이 다릅니다. 눈에 보이지 않는 실패입니다.
- 남의 정보. 고객 실명, 연락처가 든 파일은 공개 저장소에 올라가는 순간 사고입니다.
- 쌓이는 코드. 공식 모범 사례가 말하는 "신뢰와 검증의 간격"이 여기서 벌어집니다. 그럴듯하지만 엣지 케이스를 처리하지 않는 구현이 층층이 쌓이면, 어느 날 고칠 수 없는 상태가 됩니다. 교재 5주차의 말로는 "중간 QA 없이 계속 개발하면 코드가 무거워집니다."
5. 안전하게 쓰는 방법
우리 교육의 답은 도구를 바꾸는 것이 아니라 시스템을 두르는 것입니다.
- 지침 파일. 프로젝트의
CLAUDE.md에 "고객 실명 가리기", "DB 변경 전 백업", "기존 기능 삭제 금지" 같은 규칙을 적습니다. 매 세션 시작에 읽히므로 사람이 잊어도 규칙은 남습니다. - 검증 게이트. 테스트, 실행 화면, 로그처럼 Claude가 스스로 확인할 수 있는 신호를 지시에 넣습니다. "정지 규칙은 증거"입니다. 완료는 "됐다"는 말이 아니라 통과 출력으로 판정합니다.
- 되돌릴 기준점. 작업 전 커밋, 큰 변경 전 브랜치, DB 변경 전 백업. 체크포인트(
Esc두 번)는 세션용이고 영구 기록은 Git입니다.
여기에 한 가지를 더하면, 읽지 않더라도 diff의 범위는 봅니다. 시킨 파일만 바뀌었는지, 줄 수가 지시에 비해 과하지 않은지. 코드를 이해하지 못해도 범위는 판단할 수 있습니다.
6. 초보자에게 권할 만한가
시작으로는 권합니다. 첫날부터 동작하는 결과가 나오는 경험이 계속할 동력이 됩니다. 원구연 강사도 비개발자로 이렇게 시작했습니다. 다만 두 가지 조건이 붙습니다. 통하는 범위(작고, 혼자 쓰고, 버려도 되는 것)에서 시작할 것, 그리고 위의 세 장치를 2주 안에 갖출 것. 교재가 1주차에 첫 자동화를 시키고 2주차에 CLAUDE.md, 3주차에 깃허브 백업, 5주차에 QA를 넣는 순서가 그대로 이 조건입니다.
연습 문제
- 지금 만들고 싶은 것 하나를 3절의 네 조건에 대어 보고, 몇 개에 해당하는지 세어 보세요.
- 그 작업이 4절의 네 지점 중 어디에 닿는지 적고, 닿는다면 5절의 세 장치 중 무엇을 먼저 둘지 정하세요.
- 프로젝트 폴더에
CLAUDE.md를 만들고 규칙 세 줄을 적어 보세요. 다음 세션에서 그 규칙이 지켜지는지 확인합니다.
정리
- 바이브 코딩은 코드를 읽지 않는 방식이고, AI 보조 개발은 사람이 검토하는 방식입니다.
- 작고 혼자 쓰고 버려도 되는 것에서 시작하고, 데이터·돈·남의 정보·쌓이는 코드에서는 장치를 둡니다.
- 장치는 지침 파일, 검증 게이트, 되돌릴 기준점 세 가지입니다.
- 입문 코스는 여기까지입니다. 다음은 「핵심 개념」 코스에서 컨텍스트와 도구를 깊이 봅니다.
자주 묻는 질문
바이브 코딩이라는 말은 누가 만들었나요?
2025년 초 안드레이 카파시가 자신의 작업 방식을 설명하며 붙인 이름입니다. 코드를 읽지 않고 AI에 맡기며 결과만 보고 진행하는 방식을 가리켰고, 이후 AI로 코딩하는 것 전반을 느슨하게 부르는 말로 번졌습니다. 이 글은 원래의 좁은 뜻으로 씁니다.
AI로 코딩하면 전부 바이브 코딩인가요?
아닙니다. 사람이 diff를 읽고 승인하고 테스트로 확인하면 AI 보조 개발입니다. 같은 Claude Code를 써도 Manual 권한 모드에서 승인하며 진행하면 보조 개발이고, 결과만 보고 넘어가면 바이브 코딩입니다. 도구가 아니라 검토 여부가 이름을 정합니다.
실무에 써도 되나요?
통하는 범위에서는 됩니다. 내부용 변환 스크립트나 시제품은 좋은 대상입니다. 고객 데이터, 결제, 로그인, 오래 유지할 서비스에는 지침 파일과 검증 게이트, 커밋 기준점 없이 쓰지 않는 것이 우리 교육의 원칙입니다.
코딩을 배울 필요가 없어진다는 뜻인가요?
문법을 외울 필요는 줄었지만, 무엇을 원하는지 정확히 말하고 결과를 검증하는 능력은 더 중요해졌습니다. 교재 1주차의 말대로 성과의 한계는 코딩 실력이 아니라 내 업무를 얼마나 잘 아는가에서 갈립니다. 다만 diff의 범위를 보고 4구간을 구분하는 정도의 이해는 갖추는 편이 좋습니다.
바이브 코딩으로 만든 코드가 쌓이면 어떻게 하나요?
지금부터 세 장치를 둡니다. 현재 상태를 커밋해 기준점을 만들고, CLAUDE.md에 규칙을 적고, "기존 기능을 유지하면서 QA 체크리스트를 만들어 하나씩 검증해 줘"로 상태를 정리합니다. 갈아엎기보다 작은 단계로 나눠 정리하는 편이 안전합니다.