우리는 AI에 반대하는 것이 아닙니다. 우리는 규율 (discipline)을 지지합니다.

바이브 코딩 (Vibe coding)은 속도를 해방합니다. 지도된 바이브 코딩 (Supervised vibe coding)은 신뢰할 수 있는 속도를 해방합니다. 그 차이는 모델이 좋다고 느끼는 무엇이든 수동적으로 검토하는 것이 아니라, 모든 단계에서 개발자가 최종 의사 결정권자로 남는 데 있습니다.

지도된 바이브 코딩 (Supervised vibe coding)은 AI가 생성하는 속도와 의도적인 인간의 감독 (human oversight)을 결합하여, 개발자를 수동적인 검토자가 아닌 최종 의사 결정권자로 위치시키는 개발 접근 방식입니다. 이는 출력을 검토하지 않고 코드 생성을 AI 도구에 완전히 위임하는 것을 설명한 Andrej Karpathy의 2025년 개념인 "바이브 코딩 (vibe coding)"을 기반으로 합니다.

이 선언문은 점진적 인도 (incremental delivery), 테스트 커버리지 (test coverage), 코드 리뷰 (code review), 프롬프트 규율 (prompt discipline), 보안 (security), 문서화 (documentation), 구성 관리 (configuration management), CI/CD 강제 (CI/CD enforcement), 소유권 (ownership), 그리고 의존성 감사 (dependency auditing)를 다루는 10가지 지침 원칙을 개설합니다. 반복되는 주제는 AI가 실행을 가속화하지만 개발자의 판단력, 책임감, 또는 독립적으로 코딩하는 능력을 대체할 수는 없다는 것입니다.

바이브 코딩 (vibe coding)의 기원

2025년 2월 2일, OpenAI의 공동 창립자이자 전 Tesla의 AI 디렉터인 Andrej Karpathy는 소프트웨어 세계가 AI 지원 개발에 대해 이야기하는 방식을 바꿀 짧은 생각을 X에 게시했습니다.

"내가 '바이브 코딩 (vibe coding)'이라고 부르는 새로운 종류의 코딩이 있습니다. 여기서는 분위기 (vibes)에 완전히 몸을 맡기고, 기하급수적인 성장을 받아들이며, 코드가 존재한다는 사실조차 잊어버립니다." Andrej Karpathy, X (구 Twitter), 2025년 2월 2일.

이 게시물은 450만 회 이상의 조회수를 기록하며 바이럴되었습니다. Karpathy는 Cursor Composer와 같은 도구를 Anthropic의 Claude 모델과 결합하여 사용하고, 때로는 SuperWhisper를 통해 음성으로 제어하며 키보드에는 거의 손도 대지 않는 방식을 설명했습니다. 그는 변경 사항 (diffs)을 검토하지 않고 AI가 생성한 모든 변경 사항을 수락했으며, 에러 메시지를 모델에 그대로 다시 붙여넣고, 코드베이스가 자신의 완전한 이해 범위를 넘어서더라도 유기적으로 성장하도록 내버려 두었습니다.

이 문구는 개발자들이 이미 행하고 있었지만 이를 지칭할 단어가 없었던 무언가를 명명했기에 문화적 공감대를 형성했습니다. 2025년 말, Collins Dictionary는 거의 절반의 개발자가 AI 코딩 도구를 매일 사용한다고 보고함에 따라 "vibe coding (바이브 코딩)"을 올해의 단어로 선정했습니다.

Karpathy 본인도 초기에는 한계를 인정했습니다. 그는 AI가 때때로 특정 버그를 고치지 못할 수 있으며, 이로 인해 우회 방법을 찾거나 무언가 작동할 때까지 맹목적으로 프롬프트 (prompt)를 입력해야 하는 상황이 발생한다고 언급했습니다. 그는 이를 "꽤 재미있는" 현상이라 부르며, 비핵심적인 프로젝트에 가장 적합하다고 말했습니다. 하지만 그러한 주의 사항은 열풍 속에서 잊혔습니다.

이제 **Supervised Vibe Coding (지도된 바이브 코딩)**은 규율 있는 엔지니어들이 이미 실천하고 있던 방식을 공식화합니다. AI로부터 얻는 속도, 그리고 인간으로부터 오는 판단력입니다.

10가지 법칙

01

홍수처럼 쏟아내지 말고, 조각내어 배포하라 (Ship in slices, not in floods)

점진적으로 구축하십시오. 각 반복 (iteration)은 그 자체로 검토 가능하고, 테스트 가능하며, 배포 가능해야 합니다. 인간의 검토는 선택 사항이 아닙니다. AI는 기여자 (contributor)이지, 검토자 (reviewer)가 아닙니다. 한 번의 자리에서 검토할 수 없다면, 그것은 너무 큰 단위입니다.

02

테스트는 단계가 아니라 습관이다

단위 테스트 (Unit test), 통합 테스트 (integration test), 그리고 엣지 케이스 (edge case) 테스트가 모든 기능에 수반되어야 합니다. AI가 테스트 파일의 뼈대 (scaffold)를 만들 수는 있습니다. 하지만 모든 어설션 (assertion)이 null, 빈 입력값, 경계값, 동시성 (concurrency), 그리고 실패 경로를 제대로 잡아내는지 확인하는 것은 인간의 몫입니다. 이는 사고 발생 시가 아니라 설계 시점에 이루어져야 합니다.

03

실행하기 전에 읽어라

코드를 수락하기 전에 모든 코드 조각 (snippet)을 이해하십시오. API가 존재하는지, 함수가 더 이상 사용되지 않는 (deprecated) 것은 아닌지, 그리고 패키지가 환각 (hallucination)된 것은 아닌지 확인하십시오. 코드가 무엇을 하는지, 그리고 무엇에 의존하는지 설명할 수 없다면, 그것은 병합 (merge)할 준비가 되지 않은 것입니다.

04

의도를 가지고 프롬프트를 작성하고, 모델을 고정하라

나쁜 프롬프트는 나쁜 코드를 생성합니다. 모든 프롬프트에서 언어 버전, 제약 조건, 패턴, 그리고 보안 요구 사항을 명시하십시오. AI의 동작이 코드베이스 전체에서 일관되도록 팀과 프롬프트 컨벤션 (prompt conventions)을 공유하십시오.

모델 드리프트 (Model drift): 패키지 버전을 고정하는 것과 동일한 방식으로 CI/CD에서 모델 버전을 고정(Pin)하십시오. 버전이 지정되지 않은 AI 의존성(dependency)은 언제든 발생할 수 있는 소리 없는 결함(breaking change)입니다. 동일한 프롬프트라도 모델 버전에 따라 다른 출력을 생성할 수 있으므로, 모델 업그레이드를 의존성 업그레이드처럼 다루십시오: 의도적이고, 테스트를 거치며, 검토되어야 합니다.

05

보안, 성능, 그리고 UX는 동일한 우선순위를 가집니다

데이터를 유출하거나, 부하 상황에서 느려지거나, 사용자를 혼란스럽게 한다면 그 기능은 완성된 것이 아닙니다. 이것들은 모든 티켓(ticket)에서 최우선 요구사항입니다. 고객 데이터, 개인정보(PII), 자격 증명(credentials) 또는 비밀 정보(secrets)를 AI 도구에 절대 붙여넣지 마십시오. 프롬프트는 샌드박스(sandbox)가 아니라 전송(transmission)입니다.

06

떠날 때가 아니라, 진행하면서 문서화하십시오

AI는 코드 작성을 가속화하지만 보이지 않는 기술 부채(technical debt)를 축적합니다. 결정 사항, 가정, 그리고 AI가 생성한 섹션들을 동일한 커밋(commit)의 일부로 문서화하십시오. 미래의 유지보수자들은 코드가 무엇을 하는지, 그리고 왜 이런 방식으로 작성되었는지 알 권리가 있습니다.

07

설정(Configuration)은 코드입니다. 그에 맞게 취급하십시오

비밀 정보(secrets), 환경 변수(environment variables), 타임아웃(timeouts), 그리고 피처 플래그(feature flags)는 버전이 관리되고 검증되어야 하며, 절대 하드코딩해서는 안 됩니다. 설정은 계약의 일부입니다. 코드가 아무리 깔끔해 보이더라도, 잘못 설정된 배포는 여전히 실패한 배포입니다.

08

파이프라인이 문지기입니다

코드가 다음 환경에 도달하기 전에 린트(Lint), 테스트, 보안 스캔, 그리고 빌드 게이트(build gates)를 모두 통과해야 합니다. 관찰 가능성(Observability)과 로깅(logging)은 기능 구현 후에가 아니라 기능과 함께 배포되어야 합니다. 프로덕션 환경에서 코드가 무엇을 하고 있는지 볼 수 없다면, 당신은 아직 그 코드를 소유하고 있는 것이 아닙니다.

09

당신은 감독관이지, 관찰자가 아닙니다

피처 플래그(feature flags), 롤백 계획(rollback plans), 카나리 배포(canary deployments), 그리고 상태 확인(health checks)은 모든 릴리스를 통제 가능하고 되돌릴 수 있는 행위로 만듭니다. 무언가 고장 났을 때 누가 코드를 책임질지 미리 결정하십시오. AI는 새벽 2시에 호출(paged)되지 않습니다. 소유권은 사고 발생 후가 아니라, 배포 전에 명확히 정의되어야 합니다.

기술 퇴보 (Deskilling)는 조용한 위험입니다: 정기적으로 AI 없이 의도적으로 문제를 해결하십시오. 함수를 처음부터 직접 작성하십시오. 모델에게 묻지 않고 디버깅(Debug)하십시오. 이 선언문이 의존하고 있는 판단력은 당신이 그것을 전혀 연습하지 않는다면 퇴화합니다. 지도된 바이브 코딩 (Supervised Vibe Coding)은 실제로 코딩을 할 수 있는 감독자 (Supervisor)를 필요로 합니다.

10

의존성 목록 (Dependency list)을 소유하십시오

AI가 가져오는 모든 패키지 (Package)는 당신이 감사(Audit)하고, 버전을 고정(Pin)하며, 유지 관리해야 할 책임이 있습니다. AI는 구식(Outdated)이거나 취약점이 있거나, 혹은 존재하지 않는 패키지를 자신 있게 제안할 것입니다. 지식재산권 (IP) 준수를 위해 라이선스 (License)를 검토하십시오. AI의 참여 사실을 팀, 고객, 그리고 필요한 경우 고용주에게 공개하십시오. 코드는 모델의 이름이 아닌, 당신의 이름을 달고 있습니다.