AI 코딩(Vibe Coding) 마스터하기:
YC 파트너가 전하는 실전 가이드
바쁘신 분들은 스크롤을 쭈욱 – 내려 한줄 요약 먼저 읽어보세요 🙂
INTRO: 바이브 코딩, 정말 중요합니다
안녕하세요, 저는 YC의 파트너 Tom입니다. 지난 한 달 동안 바이브 코딩을 실험하며 몇 가지 사이드 프로젝트를 진행했는데, 이것이 놀라울 정도로 효과적일 뿐만 아니라 연습을 통해 측정 가능할 정도로 실력을 향상시킬 수 있다는 것을 발견했어요. 이 영상에서는 바이브 코딩에서 훌륭한 결과를 얻는 방법들을 공유하고 싶습니다. 이는 1-2년 전의 프롬프트 엔지니어링과 비슷한 상황이에요.
당시에도 사람들이 매주 새로운 것들을 발견하고 소셜 미디어에 올렸죠. 최고의 기법들은 전문 소프트웨어 엔지니어가 사용하는 것과 동일한 기법들입니다. 어떤 사람들은 “그럼 그게 바이브 코딩이 아니지 않나요? 이제 그냥 소프트웨어 엔지니어링이잖아요”라고 말하기도 해요. 저는 그게 요점이 아니라고 생각합니다.
우리는 이런 도구들을 사용해서 최고의 결과를 얻으려고 하는 거거든요. YC 스프링 배치가 몇 주 전에 시작되었는데, 제가 바이브 코딩에 대한 조언을 드리기 전에 파운더들이 오늘날 AI 도구에서 최고의 성과를 얻기 위해 사용하는 팁들을 들어보겠습니다.
바이브 코딩 실전 팁
다양한 플랫폼 활용하기
AI IDE가 구현하거나 디버깅할 수 없어서 무한 루프에 빠지는 상황에 갇히면, 때로는 LLM 웹사이트로 직접 가서 UI에 코드를 붙여넣고 똑같은 질문을 하는 것이 해결책이 될 수 있어요. 어떤 이유에서인지 IDE가 도달하지 못했던 결과를 얻을 수 있고, 그런 식으로 문제를 해결할 수 있습니다.
따라서 같은 프로젝트에서 Cursor와 Windsurf를 모두 실행하는 것을 추천합니다. Cursor는 좀 더 빠르기 때문에 프론트엔드 작업을 많이 할 수 있고, 풀스택처럼 프론트엔드를 백엔드에 연결하는 작업도 가능해요. Windsurf는 좀 더 오래 생각하죠. 예전에는 “이 에이전트를 만들어” 또는 “이 프롬프트를 수정해”라고 타이핑하면서 핸드폰만 스크롤하곤 했는데, 이제는 Windsurf가 생각하는 동안 Cursor로 가서 프론트엔드 업데이트를 시작할 수 있습니다.
때로는 둘 다 동시에 실행해서 같은 컨텍스트를 제공하기도 해요. 프론트엔드를 업데이트하려고 할 때 “저 파일 스타일로 스타일링해줘”라고 하고 둘 다 엔터를 누르면, 둘 다 같은 프론트엔드에 대해 약간씩 다른 버전을 제공하고 저는 더 마음에 드는 것을 선택하면 됩니다.
새로운 프로그래밍 언어로 접근하기
제 조언은 AI를 다른 종류의 프로그래밍 언어로 생각하고, 바이브 코딩을 새로운 유형의 프로그래밍 언어로 생각하는 것입니다. 코드로 프로그래밍하는 대신 언어로 프로그래밍하는 거죠. 따라서 좋은 결과를 원한다면 필요한 컨텍스트와 정보를 매우 상세하게 제공해야 합니다.
테스트 우선 접근법
저는 보통 바이브 코딩을 역방향으로 시작해요. 즉, 테스트 케이스부터 시작하는 겁니다. 테스트 케이스는 손수 만들고, LLM을 사용해서 테스트 케이스를 작성하지는 않아요. 그것이 완료되면 LLM이 코드 생성을 위해 따를 수 있는 강력한 가드 규칙이 생깁니다. 그러면 LLM들이 원하는 코드를 자유롭게 생성할 수 있고, 테스트 케이스에서 초록불이 보이면 작업이 완료된 거예요. 코드베이스를 세세하게 관리할 필요가 없고, 코드의 모듈성에 대해서만 개괄적으로 살펴보면 됩니다.
아키텍처 설계의 중요성
순수 LLM에서 비합리적일 정도로 많은 시간을 들여서 빌드하려는 것의 범위와 실제 아키텍처를 구축한 후에 Cursor나 다른 코딩 도구에 그것을 넘겨서 코드베이스에서 자유롭게 실행하도록 하는 것이 매우 중요합니다. 실제로 작동하지 않는 것들을 무작정 만들어내는 것을 방지하려면, 빌드하려는 것의 실제 목표가 무엇인지 확실히 이해해야 해요.
토끼굴 빠지지 않기
LLM이 질문에 답할 때 토끼굴에 빠지는지 정말 주의 깊게 모니터링하는 것이 제 조언입니다. 계속 코드를 재생성하는데 좀 이상해 보이고, 제대로 파악하지 못하는 것 같다면, 에러 메시지를 계속 복사해서 붙여넣어야 하는 상황이라면 아마도 뭔가 잘못된 것이고 한 걸음 뒤로 물러서야 해요. LLM에게 “잠깐, 한 걸음 뒤로 물러서서 왜 실패하는지 기본적으로 살펴보자”라고 프롬프트하세요.
LLM이 문제를 파악할 수 있도록 충분한 컨텍스트를 제공하지 않았기 때문인지, 아니면 운이 없어서 요청을 수행할 수 없는 것인지 확인해야 합니다. 여기서 전체적인 주제는 LLM이 훌륭한 전문 소프트웨어 개발자가 사용할 프로세스를 따르도록 하는 것이에요.
바이브 코딩 시작하기: 툴 선택
초보자를 위한 도구
코드를 한 번도 작성해본 적이 없다면 Replit이나 Lovable 같은 도구를 추천합니다. 사용하기 쉬운 시각적 인터페이스를 제공하고, 코드로 새로운 UI를 직접 시도해볼 수 있는 훌륭한 방법이에요. 많은 제품 매니저와 디자이너들이 실제로 Figma 같은 도구에서 모크업을 디자인하는 대신 새로운 아이디어를 코드로 직접 구현하고 있습니다. 그만큼 빠르거든요.
제가 시도해봤을 때 UI는 인상적이었어요. 하지만 Lovable 같은 도구들은 순수한 UI 변경이 아닌 백엔드 로직을 더 정확하게 수정하려고 할 때 어려움을 겪기 시작했습니다. 여기에 버튼을 바꾸면 백엔드 로직이 이상하게 변경되는 일이 있었어요.
경험자를 위한 도구
이전에 코드를 작성해본 적이 있다면, 저처럼 조금 녹슬었더라도 Windsurf, Cursor 또는 Claude Code 같은 도구로 바로 넘어갈 수 있을 것입니다.
바이브 코딩 : 코드보다 플랜이 중요
사용할 도구를 선택했다면, 첫 번째 단계는 바로 코드를 작성하는 것이 아닙니다. 대신 LLM과 함께 포괄적인 계획을 작성하는 것이에요. 이것을 프로젝트 폴더 안의 마크다운 파일에 넣고 계속 참조하세요. 이는 AI와 함께 개발하는 계획으로, 전체를 한 번에 시도하는 대신 프로젝트를 구현하면서 단계별로 진행하는 것입니다.
이 계획의 첫 번째 초안을 만든 후에는 검토해서 마음에 들지 않는 것들을 삭제하거나 제거하세요. 특정 기능들을 명시적으로 “너무 복잡해서 하지 않을 것”으로 표시할 수도 있어요. 또한 나중을 위한 아이디어 섹션도 유지하는 것이 좋습니다. LLM에게 “이걸 고려해봤지만 지금은 범위에 포함되지 않는다”고 말하는 거죠.
계획이 준비되면 LLM과 함께 섹션별로 구현하고 명시적으로 “지금은 섹션 2만 하자”라고 말하세요. 그런 다음 작동하는지 확인하고, 테스트를 실행하고 커밋합니다. 그다음 AI가 계획으로 돌아가서 섹션 2를 완료로 표시하도록 하세요.
아직은 모델들이 복잡한 제품 전체를 한 번에 완성하는 것을 기대하지는 않을 것 같아요. 저는 하나씩 조각조각 하면서 각 단계의 작동하는 구현을 확보하고, 중요한 것은 Git에 커밋해서 다음 단계에서 문제가 생기면 되돌릴 수 있도록 하는 것을 선호합니다.
하지만 솔직히 이 조언은 앞으로 2-3개월 안에 바뀔 수도 있어요. 모델들이 너무 빠르게 발전하고 있어서 가까운 미래에 어디까지 갈지 말하기 어렵거든요.
바이브 코딩 : 작업 버전 관리
다음 팁은 버전 관리를 사용하는 것입니다. 버전 관리는 당신의 친구예요. Git을 아주 열심히 사용해 보세요. 도구들에 되돌리기 같은 기능이 있다는 것을 알고 있지만, 아직은 신뢰하지 않습니다. 따라서 새로운 기능을 시작하기 전에 항상 깨끗한 Git 상태에서 시작하도록 해서, AI가 비전 퀘스트를 떠날 때 알려진 작동 버전으로 되돌릴 수 있도록 해요.
작동하지 않는다면 git reset –hard를 하는 것을 두려워하지 말고 다시 주사위를 굴리세요. AI에게 여러 번 프롬프트해서 뭔가 작동하도록 만들려고 할 때 나쁜 결과를 얻었어요. 근본 원인을 정말 이해하기보다는 나쁜 코드 층층이 쌓이는 경향이 있거든요. 4, 5, 6번의 다른 프롬프트를 시도해서 마침내 해결책을 얻었을 수도 있어요. 실제로는 그 해결책을 가져다가 git reset을 하고, 깨끗한 코드베이스에서 그 해결책을 AI에게 전달해서 여러 층의 크래프트 없이 깨끗한 해결책을 구현할 수 있도록 하는 것이 좋습니다.
LLM에게 테스트 시키기
다음으로 해야 할 일은 테스트를 작성하거나 LLM이 테스트를 작성하도록 하는 것이에요. 이 일을 꽤 잘 해줍니다. 보통 매우 낮은 수준의 단위 테스트를 작성하는 것을 기본값으로 하지만, 저는 이런 테스트들을 매우 높은 수준으로 유지하는 것을 선호해요.
기본적으로 누군가가 사이트나 앱을 클릭해서 돌아다니는 것을 시뮬레이션하고 기능들이 엔드투엔드로 작동하는지 확인하려고 합니다. 단위 기반으로 함수들을 테스트하는 것보다는 말이에요. 따라서 다음 기능으로 넘어가기 전에 고수준 통합 테스트를 작성해야 합니다.
LLM들은 관련 없는 로직에 불필요한 변경을 가하는 나쁜 습관이 있어요. 저기 있는 것을 고치라고 말하면 정말 아무 이유 없이 여기 있는 로직을 바꿔버리거든요. 따라서 이런 테스트 스위트들을 두면 이런 회귀들을 일찍 잡아낼 수 있고, LLM이 불필요한 변경을 했을 때를 식별해서 git reset을 하고 다시 시작할 수 있습니다.
비코딩 작업에서의 LLM 활용
LLM들은 코딩만을 위한 것이 아니라는 점을 기억하세요. 이런 사이드 프로젝트들을 빌드할 때 많은 비코딩 작업에 사용합니다. 예를 들어, Claude Sonnet 3.7에게 DNS 서버를 구성하게 했는데, 이는 항상 제가 싫어하던 작업이었고, 명령줄 도구를 통해 Heroku 호스팅을 설정하기도 했어요. 저에게는 DevOps 엔지니어 역할을 해주어서 진행 속도를 10배 가속화했습니다.
또한 ChatGPT를 사용해서 제 사이트의 파비콘용 이미지를 만들었어요. 브라우저 창 상단에 나타나는 작은 아이콘 말이에요. 그다음 Claude가 그 이미지를 가져다가 모든 다른 플랫폼에서 파비콘에 필요한 6가지 다른 크기와 형식으로 리사이즈하는 간단한 일회용 스크립트를 작성했습니다. 이제 AI가 저의 디자이너이기도 해요.
버그 수정 전략, 어떻게 할까요?
이제 버그 수정을 살펴보겠습니다. 어떤 버그를 만났을 때 제가 하는 첫 번째 일은 에러 메시지를 LLM에 바로 복사해서 붙여넣는 것이에요. 서버 로그 파일이나 브라우저의 자바스크립트 콘솔에서 나온 메시지일 수 있습니다. 종종 이 에러 메시지만으로도 AI가 문제를 식별하고 고칠 수 있어요. 뭐가 잘못되었는지 설명하거나 뭐가 잘못되었다고 생각하는지 설명할 필요도 없습니다.
단순히 에러 메시지만으로도 충분해요. 너무 강력해서 곧 모든 주요 코딩 도구들이 인간이 복사해서 붙여넣지 않아도 이런 에러들을 수집할 수 있을 것으로 기대합니다. 생각해보면 복사-붙여넣기 머신이 되는 것이 우리의 가치라는 건 좀 이상하죠? 우리는 사고를 LLM에게 맡기고 있는데 말이에요. 하지만 복사-붙여넣기는 사라질 것이고 이런 LLM 도구들이 로그를 tail하거나 헤드리스 브라우저를 띄워서 자바스크립트 에러들을 검사할 수 있게 될 것이라고 생각해요.
더 복잡한 버그의 경우, 코드를 작성하기 전에 LLM에게 3-4가지 가능한 원인을 생각해보도록 요청할 수 있습니다. 버그 수정 시도가 실패할 때마다 git reset을 하고 다시 시작해서 층층이 쌓이는 것을 피하세요. 리셋 없이 여러 번의 버그 수정 시도를 하지 마세요. LLM이 더 많은 쓰레기 층을 추가할 뿐이거든요. Git reset을 하고 다시 시작하고 로깅을 추가하세요.
로깅은 당신의 친구입니다. 확실하지 않다면, 작동하지 않는다면 모델을 바꿔보세요. Claude Sonnet 3.7일 수도 있고, OpenAI 모델 중 하나일 수도 있고, Gemini일 수도 있어요. 다른 모델들이 다른 것들이 실패한 곳에서 성공하는 경우를 자주 발견합니다.
결국 까다로운 버그의 원인을 찾았다면, 모든 변경사항을 리셋하고 깨끗한 코드베이스에서 그 정확한 버그를 어떻게 고칠지에 대한 매우 구체적인 지시사항을 LLM에게 주어서 층층이 쌓인 쓰레기 코드가 누적되는 것을 피하세요.
LLM을 위한 지시사항 작성
다음 팁은 LLM을 위한 지시사항을 작성하는 것입니다. 이것들을 cursor rules든, windsurf rules든, Claude 마크다운 파일이든 넣어두세요. 각 도구마다 약간씩 다른 명명 규칙이 있어요. 하지만 AI 코딩 에이전트를 위해 수백 줄의 지시사항을 작성한 파운더들을 알고 있는데, 이것이 그들을 훨씬 훨씬 더 효과적으로 만들어줍니다. 이런 지시사항 파일에 무엇을 넣을지에 대한 조언이 온라인에 많이 있어요. 직접 찾아보시길 바랍니다.
문서화 전략
문서화에 대해 이야기해보겠습니다. 이런 에이전트들을 온라인 웹 문서에 가리키는 것은 아직 좀 불안정해요. 어떤 사람들은 이 문서에 접근하기 위해 MCP 서버를 사용하는 것을 제안하는데, 일부에게는 작동하지만 저에게는 과한 것 같아요. 따라서 주어진 API 세트에 대한 모든 문서를 다운로드해서 작업 폴더의 하위 디렉토리에 넣어서 LLM이 로컬로 접근할 수 있도록 하는 경우가 많습니다.
그리고 지시사항에서 “이것을 구현하기 전에 문서를 읽어라”라고 말하면 훨씬 더 정확해요. 참고로, LLM을 선생님으로 사용할 수 있다는 점을 기억하세요. 특히 코딩 언어에 덜 익숙한 사람들에게요. 뭔가를 구현한 다음 AI에게 그 구현을 라인별로 설명해달라고 할 수 있습니다.
새로운 기술을 배우는 훌륭한 방법이에요. 예전에 우리 모두가 하던 Stack Overflow 스크롤링보다 훨씬 나아요.
바이브 코딩으로 복잡한 기능 구현하기
이제 더 복잡한 기능을 살펴보겠습니다. 평소에 AI에게 맡기기에는 너무 복잡한 새로운 기능을 작업하고 있다면, 완전히 깨끗한 코드베이스에서 독립적인 프로젝트로 하는 것이 좋아요. 기존 프로젝트의 복잡함 없이 작은 참조 구현을 작동시키거나, 누군가 작성해서 GitHub에 올린 참조 구현을 다운로드하세요.
그다음 LLM에게 그 구현을 가리키며 더 큰 코드베이스 안에서 다시 구현할 때 그것을 따르라고 말하세요. 놀랍도록 잘 작동해요. 기억하세요, 작은 파일과 모듈성이 당신의 친구입니다.
이는 인간 코더들에게도 마찬가지예요. LLM이 일관된 외부 인터페이스를 유지하면서 작업할 수 있는 명확한 API 경계가 있는 더 모듈화되거나 서비스 기반 아키텍처로의 전환을 볼 수 있을 것 같습니다. 거대한 상호 의존성을 가진 이런 거대한 모노레포보다는 말이에요. 이런 것들은 인간과 LLM 모두에게 어려워요. 한 곳의 변경이 코드베이스의 다른 부분에 영향을 줄지 명확하지 않거든요.
따라서 일관된 외부 API를 가진 이런 현대적 아키텍처는 외부 인터페이스와 테스트가 여전히 통과하는 한 내부를 변경할 수 있다는 의미이고, 아마도 괜찮을 것입니다.
기술 스택 선택
기술 스택 선택에 대한 메모입니다. 저는 제 프로젝트를 부분적으로 Ruby on Rails로 빌드하기로 선택했는데, 주로 예전에 전문 개발자였을 때부터 익숙했기 때문이에요. 하지만 특히 Ruby on Rails 코드를 작성할 때 AI의 성능에 깜짝 놀랐습니다.
이는 Rails가 잘 확립된 관례를 가진 20년 된 프레임워크이기 때문이라고 생각해요. 많은 Rails 코드베이스들이 매우 매우 비슷해 보이고, 경험 있는 Ruby on Rails 개발자에게는 특정 기능이 어디에 있어야 하는지 또는 특정 결과를 달성하는 올바른 Rails 방식이 무엇인지 명백합니다. 이는 온라인에 Rails 코드베이스에 대한 매우 일관되고 고품질의 훈련 데이터가 많다는 것을 의미해요.
온라인에 훈련 데이터가 많지 않은 Rust나 Elixir 같은 언어로는 성공하지 못한 다른 친구들이 있었지만, 그것도 곧 바뀔 수 있어요.
스크린샷과 음성 활용
다음 조언은 스크린샷을 사용하는 것입니다. 요즘 대부분의 코딩 에이전트에 스크린샷을 복사해서 붙여넣을 수 있고, 이는 볼 수 있는 UI 구현의 버그를 보여주거나 프로젝트에서 사용하고 싶은 다른 사이트의 디자인 영감을 가져오는 데 매우 유용해요.
음성은 이런 도구들과 상호작용하는 또 다른 정말 멋진 방법입니다. 저는 YC 회사인 Aqua를 사용하는데, 기본적으로 컴퓨터에 말만 하면 Aqua가 제가 말하는 것을 사용 중인 도구로 전사해줘요.
현재 Windsurf와 Claude Code 사이를 많이 전환하고 있는데, Aqua를 사용하면 분당 140단어로 지시사항을 효과적으로 입력할 수 있어요. 이는 제가 타이핑할 수 있는 속도의 약 두 배입니다. AI가 사소한 문법과 구두점 실수에 매우 관대해서, 전사가 완벽하지 않아도 정말 상관없어요. 실제로 이 전체 발표를 Aqua로 작성했습니다.
자주 리팩토링하기
다음으로, 자주 리팩토링하는 것을 확실히 하세요. 코드가 작동하고 중요하게는 테스트가 구현되면, 테스트가 회귀를 잡아낼 것이라는 것을 알고 마음대로 리팩토링할 수 있어요
LLM에게 반복적으로 보이거나 리팩토링에 좋은 후보가 될 수 있는 코드베이스의 부분들을 식별해달라고 요청할 수도 있습니다. 다시 말하지만, 이것은 모든 전문 소프트웨어 개발자가 따를 팁이에요. 수천 줄이나 되는 파일을 두지 않고, 작고 모듈화된 상태로 유지하세요. 인간과 LLM 모두가 무슨 일이 일어나고 있는지 이해하기 훨씬 쉬워집니다.
OUTRO: 바이브 코딩, 계속해보세요
마지막으로, 계속 실험하세요. 이런 것들의 최신 기술이 매주 바뀌는 것 같아요. 저는 모든 새로운 모델 릴리스를 시도해서 각각 다른 시나리오에서 어떤 것이 더 잘 수행되는지 봅니다. 어떤 것들은 디버깅이나 장기 계획, 기능 구현, 리팩토링에 더 나아요.
예를 들어, 현재 Gemini는 전체 코드베이스 인덱싱과 구현 계획 작성에 가장 좋은 것 같고, Sonnet 3.7은 적어도 저에게는 실제로 코드 변경을 구현하는 데 선두 주자인 것 같습니다. 며칠 전에 GPT 4.1을 시도해봤는데, 솔직히 아직 감명받지 못했어요. 너무 많은 질문을 던져왔고 실제로 구현을 너무 많이 틀렸거든요.
하지만 다음 주에 다시 시도해볼 것이고, 분명히 상황이 다시 바뀌었을 것입니다. 시청해주셔서 감사하고, 이런 모델들에서 최고의 성과를 얻기 위한 팁이나 트릭이 있으시면 아래 댓글에 공유해주시길 바라요.
요약
YC 파트너 Tom이 전하는 AI 코딩(Vibe Coding) 실전 가이드
AI 도구를 활용한 효과적인 코딩 방법론을 체계적으로 정리한 내용인데요.. 초보자를 위한 Replit, Lovable부터 경험자를 위한 Cursor, Windsurf, Claude Code까지 도구 선택법을 제시하고, 코드 작성 전 LLM과 함께 포괄적인 계획을 세워 섹션별로 구현하는 방법을 강조해요. Git을 종교적으로 사용하고, 높은 수준의 통합 테스트 작성, 에러 메시지 직접 복사-붙여넣기를 통한 버그 수정, LLM을 위한 상세한 지시사항 작성 등 실무 팁들을 다루며, 특히 “여러 번 시도해서 실패하면 git reset으로 깨끗하게 시작하라”는 핵심 원칙을 제시합니다. 또한 AI를 디자인, DevOps, 문서 작성 등 비코딩 작업에도 활용하고, 스크린샷과 음성 입력을 통한 효율성 증대, 자주 리팩토링하기, 새로운 모델 지속적 실험 등을 통해 AI 시대의 새로운 프로그래밍 패러다임을 제시하는 종합 가이드예요.
