AI시대: 바이브 코딩, 제대로 하는 법 — 10가지 원칙

작성자:

얼마 전 선배들과 만난 자리에서 바이브 코딩 이야기가 나왔습니다. 요즘 실제로 써보고 있냐는 질문에, 다들 각자 최근 경험을 꺼내놓았습니다. 저는 채팅 AI와 대화하면서 요구사항과 스펙을 정리하고, 이를 바탕으로 코딩 AI에게 구현을 맡기되 코드는 최대한 직접 보지 않는게 좋다고 설명했고, 그 말에 반응이 엇갈렸습니다.

또, 바이브 코딩으로 만든 코드가 리펙토링이 필요한가에 대해서도 기능 추가 용이성, 유지보수 비용, 코드 가독성 등 여러 이유가 오갔지만 쉽게 정리되지 않았습니다. 이때 저는 “미래의 토큰 비용을 줄이기 위해서” 리팩토링은 필요하다고 이야기를 했고, 다들 고개를 끄덕이며 공감하는 분위기가 되었습니다.

AI 시대에도 기술부채는 존재합니다. 다만, 기술부채를 책임져야 할 주체가 사람에서 AI로 바뀌었다는 점이 중요한거죠. 참석하신 선배들 대부분이 이 점에 크게 공감하였습니다.

그 대화를 정리하다 보니, 즉흥적으로 AI에게 맡기는 것처럼 보이는 바이브 코딩에도 제가 지키고 있는 원칙들이 있다는 걸 깨달았고, 아래와 같이 정리해 봅니다.

목 차

바이브 코딩이란

바이브 코딩(Vibe Coding)은 2025년 2월 Andrej Karpathy가 처음 언급한 개념입니다. 자연어로 의도를 전달하면 AI가 코드를 생성하고, 개발자는 결과를 보고 다시 프롬프트를 던지는 식으로 반복합니다.

원래는 취미 프로젝트나 빠른 프로토타이핑에 어울리는 방식으로 소개됐지만, 지금은 AI를 활용한 개발 전반을 가리키는 말로 의미가 넓어졌습니다. 문제는 그 확장 과정에서 “AI에게 던지고 기다리는 것”이 바이브 코딩의 전부인 것처럼 받아들여지는 경우가 많다는 점입니다. 그렇게 하면 작은 프로젝트에서는 통하지만, 규모가 커지거나 다음 AI가 이어받는 순간 금방 한계에 부딪힙니다.

바이브 코딩이 실제로 작동하려면 구조가 필요합니다.

참고로 여기서 말하는 채팅 AI는 ChatGPT, Claude.ai 처럼 기존의 대화 중심으로 쓰는 AI입니다. 코딩 AI는 OpenAI Codex, Claude Code처럼 코드 생성과 실행에 특화된 코딩 에이전트를 의미합니다. 이 글에서는 두 유형을 역할에 따라 구분해서 씁니다.

원칙 ① AI와 함께 설계하라

소프트웨어 개발에서 요구사항 분석과 설계가 중요하다는 건 예나 지금이나 바뀌지 않았습니다. 바이브 코딩도 예외가 아닙니다. 특히, AI는 전달받지 못한 맥락과 암묵지를 알 수 없습니다. 목적과 요구사항이 명확하지 않으면, AI는 그럴듯해 보이지만 의도와 다른 결과물을 만들어냅니다.

과거에는 요구사항을 분석하고 스펙을 정의하는 데 전문 지식과 충분한 경험이 필요했습니다. 프로젝트 매니저, 시스템 아키텍트, 시니어 개발자 등 전문가가 장시간 분석을 마친 후에야 요구사양서를 완성할 수 있었습니다. 하지만 이제 채팅 AI와 충분한 대화를 하면서 그 과정을 대부분 대체할 수 있습니다.

개발 목적이 무엇인지 러프하게 전달하면, AI는 사용자에게 질문을 던지고, 엣지 케이스를 짚어주고, 가능한 기술 스택과 개발 패턴을 제시해 줍니다. 학습을 통해 모델에 포함된 폭넓은 지식을 바탕으로 더 명확한 Spec을 만드는 데 도움을 줍니다.

흔히 바이브 코딩의 가치를 “AI가 코드를 대신 짜준다”는 뒷단에서 찾습니다. 하지만 저는 이 앞단의 변화가 더 의미 있다고 봅니다. 혼자서도 팀 수준의 설계가 가능해졌다는 점에서입니다.

구현을 시작하기 전에 채팅 AI와 충분히 대화하면서 요구사항과 Spec을 먼저 작성합니다. 채팅 AI를 마치 프로젝트 매니저(PM)처럼 쓰는 것, 이것이 가장 첫번째 원칙입니다.

코딩 AI는 실행자입니다. 실행자에게 가장 먼저 필요한 것은 명확한 지시입니다.

원칙 ② AI와 함께 리뷰하고 판단하라

아무리 계획을 잘 세우더라도 막상 구현은 계획대로 흘러가지 않습니다.

시작하고 나면 Spec에서 미처 정의하지 못한 선택의 순간들이 계속 등장합니다. 어떤 아키텍처를 택할지, 어떤 라이브러리가 이 맥락에 맞는지, 여러 선택지 중에서 어느 쪽이 나중에 더 유리한지 등 다양한 판단들이 쌓여 구현의 질을 결정합니다.

문제는 이 판단들이 대부분 혼자 결정하기 어렵다는 점입니다. 경험이 부족하면 잘못된 선택을 할 수도 있고, 경험이 많아도 개인의 편향에서 자유롭기 어렵습니다. 기존에는 이런 순간마다 동료나 선배에게 물어볼 수 있었지만, 소규모 바이브 코딩 환경에서는 그 대화 상대를 찾기가 어렵습니다.

이때 이미 요구사양서와 Spec을 충분히 알고 있는 채팅 AI가 이 역할을 대신할 수 있습니다. 프로젝트의 맥락 안에서 일관된 판단을 도와주기도 하고, 사람이 판단한 내용에 대한 검토도 요청할 수 있습니다. 단순히 정보를 제공하는 것을 넘어, Tradeoff를 함께 따져보는 일종의 파트너가 됩니다.

판단뿐만 아니라 리뷰도 AI와 함께할 수 있습니다. 다른 AI가 만든 코드, 동료가 작성한 문서나 설계안을 AI에게 검토하게 하면, 혼자서는 놓치기 쉬운 허점이나 일관성 문제를 짚어줍니다. 코딩 AI가 구현한 결과를 다른 채팅 AI에게 리뷰시키는 방식도 효과적입니다. 사람이 모든 코드를 직접 들여다보지 않아도, AI를 리뷰어로 세워 품질을 한 단계 걸러낼 수 있습니다. 중요한 것은 리뷰의 기준과 관점은 사람이 잡아준다는 점입니다.

구현 과정 중에 막히는 순간마다 혼자 고민하지 말고, 채팅 AI와 함께 판단하십시오.

원칙 ③ 작게 시작해서 점진적으로 확장하라

바이브 코딩에서 한 번에 너무 많은 것을 요청하면 AI는 방향을 잃습니다. 복잡한 요구사항을 한꺼번에 전달할수록 AI의 결과물은 예측하기 어려워지고, 문제가 생겼을 때 어디서 잘못됐는지 파악하기도 힘들어집니다.

작게 시작해서 반복적으로 키워나가는 것이 답입니다. 먼저 핵심 기능만으로 동작하는 MVP(Minimum Viable Product)를 만들고, 환경이 제대로 구성됐는지 확인합니다. 기본 뼈대가 세워지면 그 위에 기능을 하나씩 쌓아갑니다. 각 단계에서 동작을 확인하고, 문제가 있으면 즉시 잡은 뒤 다음으로 넘어갑니다. 외관을 꾸미는 것은 가장 마지막입니다.

예를 들면, 단일 입력을 처리하는 CLI 앱을 먼저 만들어서 잘 동작하면, 다중 입력 처리, 로그 추가, 예외 사항 추가, GUI 버전으로 전환, 웹서비스로 확장 등을 단계적으로 처리할 수 있습니다.

이 방식은 AI와의 협업에서도 훨씬 안정적입니다. 작은 단위로 요청하면 AI의 결과물을 예측하기 쉽고, 피드백을 바로 반영할 수 있습니다. 작게 만들고 확인하고 키워가는 반복이 바이브 코딩의 실질적인 개발 리듬입니다.

원칙 ④ 버전 관리는 더욱 꼼꼼하게 하라

바이브 코딩에서 AI는 한 번의 요청으로 파일 여러 개를 동시에 바꿉니다. 사람이 한 줄씩 수정하는 것과는 차원이 다릅니다. 문제는 그 변경이 예상과 다를 때입니다. 되돌아가야 할 지점이 없으면, 무엇이 언제 바뀌었는지 추적할 수 없습니다.

버전 관리는 이 문제를 해결합니다. 작은 단계마다 커밋을 남기면, 언제든 이전 상태로 돌아갈 수 있습니다. AI가 잘못된 방향으로 코드를 대거 수정해도 부담 없이 되돌릴 수 있고, 그만큼 과감하게 시도할 수 있습니다. 커밋 메시지도 AI에게 작성하게 하면 변경 이력이 자연스럽게 기록으로 남습니다.

바이브 코딩에서 버전 관리는 안전망입니다.

원칙 ⑤ 코드 대신 결과에 집중하라

바이브 코딩을 하다 보면 어느 순간 코드를 직접 고치고 싶은 충동이 생깁니다. AI가 만든 코드가 마음에 들지 않거나, 작은 부분 하나만 간단하게 수정하면 될 것 같을 때입니다. 하지만 제 생각에는 바로 그 순간이 바이브 코딩이 무너지는 시작점입니다.

코드를 직접 수정하면 두 가지 문제가 생깁니다. 첫째, AI의 컨텍스트가 끊깁니다. AI는 자신이 만든 구조 안에서 일관성을 유지하며 다음 작업을 이어갑니다. 그런데 사람의 패턴이 중간에 섞이면, 다음 AI는 이 코드가 어떤 의도로 작성됐는지 파악하기 어려워집니다. 둘째, 개발자가 코드 수준에 개입하는 순간 추상화 레벨이 내려갑니다. 구조와 방향을 유지해야 할 사람이 구현 세부사항에 발이 묶이는 것입니다.

코드가 마음에 들지 않는다면, 직접 고치는 대신 AI에게 다시 요청하십시오. 결과가 의도와 다르다면, 코드를 보는 대신 동작을 보고 피드백을 주어야 합니다.

개발자의 시선은 코드가 아니라 결과물에 집중해야 합니다.

원칙 ⑥ 매 순간을 기록하라

사람은 맥락을 기억합니다. 어제 어떤 결정을 내렸는지, 왜 그 방식을 선택했는지, 어떤 문제를 고민했는지를 머릿속에 쌓아가며 개발을 이어갑니다. 하지만 AI는 그렇지 않습니다. 새로운 대화가 시작되는 순간, 이전의 맥락은 사라집니다. 아무리 좋은 코딩 AI라도 맥락이 끊긴 상태로 시작하면 프로젝트의 흐름을 이어받기가 쉽지 않습니다.

기록은 이 문제를 해결하는 유일한 수단입니다. 요구사항, Spec 뿐만 아니라 구현 방식, 하네스(테스트와 실행 환경을 구성하는 틀) 구축 과정, 의사결정 과정, 고민거리 등 개발 진행 상황을 최대한 상세하게 남겨두는 것, 이것이 AI에게 맥락을 공급하는 방법입니다. 물론 그 기록 자체도 AI에게 시킵니다. 대화가 마무리될 때마다 AI에게 작업 내용을 정리하게 하면, 기록은 자연스럽게 축적됩니다. 잘 정리된 기록은 다음 AI가 프로젝트에 합류할 때 온보딩 문서가 됩니다.

사람의 기억을 대신하는 기록이 곧 프로젝트의 메모리이고, 이 메모리의 질이 AI 협업의 질을 결정합니다.

바이브 코딩에서 기록은 선택이 아닌 필수입니다.

원칙 ⑦ 테스트, 테스트, 테스트

원칙 ⑤에서 코드 대신 결과에 집중해야 한다고 했습니다. 그런데 결과물이 제대로 동작하는지 보려면 기준이 있어야 합니다. 그 기준이 테스트 케이스입니다. 코드를 직접 확인하지 않은 채로 동작을 확인하는 방법은 테스트가 유일합니다. 테스트 없이 동작을 확인하는 것은 매번 눈으로 직접 훑는 것에 불과합니다.

그리고, AI는 회귀(Regression)를 스스로 인식하지 못합니다. AI가 새로운 기능을 추가하면서 기존 기능이 조용히 깨져도 한참 뒤에야 알게 됩니다. 요청한 것을 완성했다고 판단하는 순간, 그 과정에서 어떤 문제가 발생했는지는 관심이 없습니다.

테스트 케이스는 이를 잡는 안전망이자, 동작을 판단하는 기준입니다. 구현이 진행될 때마다 주기적으로 실행을 해서 문제점을 즉시 감지합니다. 물론 테스트 케이스 작성도 AI에게 맡깁니다. 단, 어떤 것을 테스트할지, 얼마나 자세하게 할지는 사람이 방향을 잡아줘야 합니다. 테스트 케이스를 정의하는 과정 자체가 “내가 원하는 것”을 명세화하는 행위이기 때문입니다. 잘 만들어진 테스트는 Spec의 연장선입니다.

테스트는 AI와 함께 달리기 위한 피드백 루프입니다.

원칙 ⑧ 리팩토링은 여전히 중요하다

도입부에서 나눈 대화로 돌아가 보겠습니다. “어차피 AI가 유지보수할 텐데 리팩토링이 필요한가”라는 질문이었습니다. 결론부터 말하면, 당연히 필요합니다. 이유가 바뀌었을 뿐입니다.

소프트웨어는 개발 초반에 설계를 잘 해도 시간이 지날수록 구조가 나빠집니다. 요구사항 변경, 기능 추가, 기술 스택 교체 등 다양한 이유로 처음의 설계는 조금씩 변질됩니다. 바이브 코딩은 개발 속도가 빠른 만큼 이 변질의 속도도 빠릅니다. 구조가 무너진 코드 위에 AI가 계속 기능을 쌓아가면, 어느 순간 아무도 전체 구조를 파악하지 못하는 상태가 됩니다.

이 상태를 방치하면 결국 기술부채(Technical Debt)가 쌓입니다. 그런데, AI 시대의 기술부채는 사람의 시간이 아니라 토큰으로 청구됩니다. 즉 비용이 더 듭니다. 구조 없는 코드는 노이즈가 많은 입력이고, 노이즈가 많을수록 AI의 추론 정확도는 떨어집니다. 나쁜 코드는 결국 나쁜 결과물로 돌아옵니다.

과거에는 사람이 잘 관리하기 위해 리팩토링을 했습니다. 지금은 AI가 더 잘 처리하기 위해 합니다. 리팩토링의 목적이 바뀐 것이지, 사라진 게 아닙니다.

미래의 토큰을 줄이는 것, 이것이 리팩토링의 새로운 이유입니다.

원칙 ⑨ 검증기준을 만들어라

테스트와 검증은 다릅니다. 테스트는 “코드가 깨지지 않았는가”를 확인합니다. 검증은 “내가 원하는 것이 만들어졌는가”를 확인합니다. 이 둘은 목적이 다르고, 테스트를 통과했다고 검증이 완료된 것이 아닙니다.

AI는 주어진 조건을 충족하는 데 최적화되어 있습니다. 하지만 그 조건이 처음 의도를 완전히 담고 있는지는 보장하지 못합니다. 무엇을 검증할지, 어떤 기준으로 완료를 판단할지는 반드시 사람이 정의해야 합니다. 동시에 그 기준은 AI가 실행할 수 있는 형태로 설계되어야 합니다. 사람만 이해할 수 있는 모호한 기준은 결국 사람이 직접 확인해야 하는 수작업으로 돌아옵니다. 명확하게 정의된 검증 기준은 AI가 반복 실행할 수 있고, 그만큼 검증의 일관성도 높아집니다.

바이브 코딩에서 개발자가 끝까지 놓지 말아야 할 것이 있다면, 바로 이 검증입니다.

원칙 ⑩ 특정 AI에 집착하지 말라

하나의 AI에만 의존하는 것은 한 사람의 판단에만 의존하는 것과 같습니다. 모든 AI 모델은 각자의 강점과 약점, 학습 데이터의 편향이 있습니다. 특정 모델이 잘 못하는 영역이 있고, 같은 질문도 모델에 따라 다른 관점으로 답합니다. 심지어 버전 별로 능력이 달라지기도 합니다.

여러 AI를 함께 쓰면 이 한계를 보완할 수 있습니다. 설계 단계에서 채팅 AI를 여러 개 써서 관점을 교차 검토하고, 구현에서는 코딩 AI를 상황에 따라 교체하거나 병행합니다. 한 AI가 막히는 문제를 다른 AI가 풀기도 하고, 한 AI의 결과물을 다른 AI가 검토하게 할 수도 있습니다. AI의 한계를 AI로 보완하는 것입니다.

특정 AI에 종속되지 않는 유연성을 유지하십시오.
더 나은 모델이 나왔을 때 갈아탈 수 있어야 하고, 작업의 성격에 따라 가장 적합한 AI를 선택할 수 있어야 합니다.

맺음말

10가지 원칙을 관통하는 하나의 대전제가 있습니다.

AI는 맥락을 주지 않으면 모릅니다.

Spec은 목표, 기록은 진행, 커밋은 변경에 관한 맥락입니다. 리팩토링은 코드 맥락을 정리하는 일입니다. 테스트는 품질 기준을 맥락으로 만드는 과정입니다. 검증은 의도가 맥락으로 전달됐는지 확인하는 행위입니다.

바이브 코딩의 10원칙은 결국 맥락 관리입니다. 개발자의 역할은 코드를 직접 짜는 것에서, AI가 제대로 일할 수 있도록 맥락을 설계하고 공급하는 것으로 바뀌고 있습니다.

사람들은 바이브 코딩에서 “바이브”만 봅니다.
하지만, 고민의 대상이 코드에서 목적과 결과로 바뀌었을 뿐 바이브 코딩도 결국 “코딩”입니다.

ChulJoo Kim (김철주)

ckarch.kr © 2026 is licensed under CC BY-NC-SA 4.0 CC BY NC SA

댓글 남기기