이 글을 읽는 사람의 대부분은 코딩이라고는 전혀 모르고, 바이브 코딩을 듣기는 했으나 시도할 엄두도 안 날 사람들이 많을 것으로 생각합니다.
하지만, 저도 코딩을 아예 모르는 사람이지만 바이브 코딩을 통해서 많은 것들을 실체화 시키는 과정에 있습니다. 제가 겪었던 시행착오들을 여러분들이 빠르게 넘길 수 있도록, 제가 배운 것들을 정리해서 알아보는 시간을 가지겠습니다.
AI 시대, 이제 코딩을 개발 지식이 전무하다고 포기하는 것은 핑계입니다. 이제는 코딩을 몰라도, 전략만 있다면 충분히 가능합니다. 바이브 코딩이라는 것을 한마디로 정의하자면, 내가 직접 키보드를 두드리는 노동이 아니라, 내 머릿속의 기획을 AI에게 위임하여 결과값을 도출해내는 '설계의 영역'입니다.
우리는 이 구조를 명확히 이해해야 합니다. LLM(생각하는 AI)는 기획자이자 PM으로서 전체적인 아키텍처와 리스크를 설계하고, 코딩 에이전트(Cursor, Windsurf, Claude, Codex etc...)는 그 설계를 바탕으로 실제 구현을 담당하는 개발팀입니다. 즉, 바이브 코딩의 본질은 '코딩 실력'이 아니라 요구사항을 얼마나 정교하게 설계하여 지시하느냐에 달려있습니다. 말로 일을 시키는 능력이 곧 개발력이 되는 것입니다.
즉, 우리는 ‘코딩’을 하는 게 아니라 AI가 개발자처럼 움직이도록 만드는 ‘전략적 지시’에 집중해야 합니다. 이를 위해 확률 높게 성공하는 바이브 코딩 전략을 13가지로 정리해 보았습니다.
1. 리서치가 먼저듯, 프로젝트 구상은 'LLM'에게 시켜야 합니다.
무턱대고 코딩 에이전트부터 켜는 건, 리서치 없이 프로젝트에 올인하는 것과 같습니다.
코딩 에이전트는 ‘구현’에 최적화되어 있지, ‘사고’에 최적화된 도구가 아닙니다.
자동매매 시스템을 만든다고 가정할 때, 바로 코드를 짜는 게 아니라 LLM에게 먼저 설계를 시켜야 합니다.
같은 질문을 하더라도 나오는 결과물은 미세하게 다를 수 있습니다. 최대한 병렬적으로 많이 확인하십시오.
구성 요소, 필터링 조건, 데이터 소스, 리스크 분석 등 ‘설계 질문’을 던져서 구조를 잡는 것이 우선입니다. 놓치는 부분이 없도록 집요하게 확인하고 발상시키는 것, 그게 LLM의 몫입니다.
연결적으로
발산적으로
유연하게
꼼꼼하게
누락하지말고
...
와 같은 프롬프트 표현을 포함시키는 것이 프롬프트 엔지니어링에서의 엣지입니다.
2. ChatGPT의 프로젝트(Project) 기능/Gemini의 Gems 기능을 통해 변수를 통제해야합니다.
챗GPT나 Gemini의 프로젝트/Gems 기능을 활용해 독립된 작업장을 만드십시오.
대화창이나 프로젝트를 기능이나 서비스 단위(예: 밈코인 터미널, 자동매매 등)로 쪼개야 합니다. 이곳을 'AI 전용 구상 작업실 + 규칙집 + 자료실'로 만들어야 변수들로부터 자유로워집니다.
전용 지침과 메모리를 할당하여 작업의 일관성을 유지하는 것이 핵심입니다.
또한, 각 분할된 대화창과 프로젝트 간의 내용 공유가 원활하게 되어야하며, 결국 전체를 통제하는 최종 판단 대화창/프로젝트가 있어야합니다.
3. 지침 프롬프트 설정은 작업을 효율적으로 만들어줍니다.
프로젝트 설정의 지침은 AI가 반드시 따라야 할 규율입니다. '출력 형식 고정', '단계적 진행'과 같은 명확한 프로토콜을 설정해야 합니다. 그래야 대화가 길어려도 AI가 흔들리지 않고 우리가 설정한 전략대로 퍼포먼스를 냅니다.
4. 모델 선택: 속도보다는 ‘생각(Thinking)’의 깊이입니다.
ChatGPT 기준 Pro 사용자라면 ChatGPT 5.2 Pro (Extended Thought) 모델을, Plus 사용자라면 ChatGPT 5.2 Thinking (Heavy Thought) 모드를 켜야 합니다. '코딩은 빨리'가 아니라 '정확하게'가 이득입니다. 설계나 아키텍처 단계에서 생각을 깊게 한 결과물은 나중에 갈아엎는 매몰비용과 토큰을 획기적으로 줄여줍니다.
5. 프롬프트를 나누십시오.
스텝 바이 스텝으로 접근하십시오. 한 번에 6~7개의 요구사항을 던지면 LLM의 집중도가 분산됩니다.
핵심 목표 1~2개를 먼저 설계하고, 결과를 검증한 뒤, 기능을 하나씩 덧붙이는 ‘점진적 설계’가 정석입니다. 완성도를 단계적으로 높여가는 것이 가장 확률 높은 방법입니다.
한 채팅에 모든 것을 다 적어넣지 마십시오.
6. 이해가 안 되면 Gemini를 활용하여 이해해야합니다.
LLM의 답변이 어렵다면, Gemini 등을 이용해 '초등학생도 이해할 수 있게' 재가공하십시오.
이 과정이 필요한 이유는 명백합니다. 사용자(본인)가 이해하지 못하면 다음 지시를 정확하게 내릴 수 없기 때문입니다. 방향이 틀어지는 것을 방지하기 위해선 내가 내용을 조금이라도 이해하고 있어야 합니다.
Gemini Dcinside Gems ([초등학생도 이해하게, 실생활 비유를 많이 넣어서 dcinside 식으로 알려줘.]라고 붙여넣고, 밑에 내용을 붙여넣으십시오.)
7. 단일 작업보다는 병렬 처리(Branch)로 리스크를 헷징하십시오.
AI의 강점은 직렬이 아닌 병렬 처리에 있습니다. 하나의 기획안을 두고 채팅창을 여러 개(Branch) 복제하여 관점을 달리하십시오.
A창은 개발, B창은 보안, C창은 비용, D창은 UX 관점 등... 각기 다른 관점에서 분석하게 하고, 그중 좋은 것만 합쳐서 최종안을 도출하는 것이 바이브 코딩을 제대로 하는 운영법입니다.
챗 지피티의 답변 아래쪽 점 3개를 누르면 Branch가 나옵니다.
8. 교차 검증과 토론으로 내구성을 높이십시오.
초안 설계를 바로 믿지 마십시오. 다른 세션(Branch)에서 '반박/비판' 역할을 맡겨 공격하게 하고, 그 반박을 원본에 반영해 수정하는 루프를 돌려야 합니다. 설계를 한 번에 믿는 안일함을 버리고, 검증과 비판을 통해 논리를 단단하게 만드는 과정이 필수적입니다.
9. Gemini Canvas로 가시적인 테스트를 하십시오.
Gemini Canvas는 웹디자인, 프로덕트 테스트와 같은 측면에서 매우 큰 자산입니다.
일단 LLM과 구축한 내용을 Gemini Canvas 기능을 이용해 테스트해보고, 내가 구상한 것과 동일한 것인지 확인해보십시오.
보고 이해하는 것과 텍스트를 읽고 이해하는 것은 근본적으로 큰 차이가 있습니다.
10. 구현 단계: 설계가 끝났다면 코딩 에이전트로 이관하십시오.
설계와 검증이 끝난 후에야 비로소 코딩 에이전트를 투입합니다. LLM에게 현재 상황과 내 개발 환경(VS Code, Cursor. 사용하는 모델 등)을 설명하고, '코딩 에이전트에게 내릴 명령문(작업 지시서)'을 작성하게 하십시오.
이 지시서를 그대로 복사하고 에이전트에게 붙여넣어 구현을 맡기는 구조입니다.
11. 문서는 곧 보험입니다 (Agent.md / Work.md).
에이전트가 실수하거나 구조를 무너뜨릴 확률은 항상 존재합니다.
이를 방지하기 위해 Agent.md(최상위 규칙)와 Work.md(업무 일지)를 반드시 작성하게 하십시오.
작업 내역이 기록되어 있어야 에이전트가 길을 잃었을 때 복구할 수 있습니다. 이는 선택이 아니라 필수적인 리스크 관리 수단입니다.
Agent.md는 LLM에게 작성해달라고 하시면 됩니다.
제가 추후 기본적으로 Agent.md에 넣으면 좋은 내용을 추후 업로드하겠습니다. (Work.md, adr 파일 남기기, 깃허브 커밋 자동화)
12. GitHub 커밋은 유일한 ‘세이브 포인트’입니다.
코딩 에이전트가 코드를 완파해버리는 최악의 시나리오를 피해야 합니다.
작업 단위마다 GitHub에 커밋(Save)하도록 시키십시오. 일이 틀어졌을 때 이전 시점으로 되돌릴 수 있는 수단이 없다면, 그건 청산과 다를 바 없습니다.
이건 하이레버리지 매매가 아닙니다.
에이전트에게 작업이 끝나면 항상 커밋하라고 지시하십시오. 혹은 Agent.md 파일에 해당 내용을 포함하십시오.
13. 오류는 당연한 변수입니다.
반복을 통해 수렴시키십시오. 실제로 돌려보면 오류가 터지는 건 정상입니다.
AI는 실사용 환경의 모든 변수를 예측할 수 없습니다. 문제가 되는 지점을 사람이 확인하고, 다시 에이전트에게 수정하게 만드는 반복 과정이 필요합니다.