코드를 몰라도 만들고 싶었다: 비개발자의 바이브코딩 회고

소개

2024년 후반부터 2025년 중반까지, 나는 여러 형태의 바이브코딩을 시도했다. 나는 비개발자다. 개발을 업으로 삼아온 사람은 아니지만, 회사 내외부에서 PHP 기반 웹페이지를 구동하기 위해 LAMP 서버를 설치하고 다뤄본 경험은 꽤 있었다.

그래서 처음에는 비교적 익숙한 영역에서 시작했다. LAMP 서버 위에 PHP 기반 웹페이지를 만들었다. PHP는 무료 또는 저렴한 웹서버와 VPS 환경에서도 시작하기 쉽고, 다른 웹개발 스택에 비해 진입 장벽이 낮다고 느꼈다.

하지만 당시에는 Cursor AI 같은 IDE형 AI 개발 도구를 사용하기 전이었다. 개발은 대부분 ChatGPT의 채팅 인터페이스로 진행했다. 이 방식은 초반에는 꽤 신기하고 가능성이 있어 보였지만, 몇 번의 대화 턴이 지나면 이전 문맥을 놓치거나 존재하지 않는 파일을 가정하는 문제가 자주 생겼다.

그때 내가 찾은 해결책은 아주 단순했다.

“AI가 문맥을 잃는다면, 내가 계속 문맥을 다시 넣어주자.”

처음에 프로젝트의 디렉토리 구조를 먼저 계획하고 정리했다. 그리고 그 디렉토리 구조를 매 대화 턴마다, 또는 몇 번의 대화마다 한 번씩 다시 첨부했다. AI가 프로젝트 전체 구조를 계속 떠올릴 수 있도록 일종의 기준 지도를 제공한 것이다.

이 방식으로 텍스트 중심의 LMS 사이트를 만들었다. 간단한 게시판도 포함했다. 개발 방식은 원시적이었다. ChatGPT가 파일 하나를 작성해주면, 나는 그 결과를 VS Code에 직접 복사해서 붙여넣고 저장했다. 그리고 다시 다음 파일을 요청했다.

지금 돌아보면 번거로운 방식이었지만, 당시의 나에게는 분명히 작동하는 방식이었다. 비개발자가 AI와 함께 코드를 만들어가는 첫 번째 워크플로우였다.

진행 방법

1. LAMP와 PHP로 시작한 첫 번째 바이브코딩

첫 프로젝트의 핵심은 “AI에게 한 번에 많은 것을 맡기지 않는 것”이었다.

당시 사용한 방식은 다음과 같았다.

• 먼저 전체 디렉토리 구조를 계획한다.

• 각 폴더와 파일의 역할을 간단히 정의한다.

• ChatGPT에게 한 번에 하나의 파일만 요청한다.

• 응답 결과를 VS Code에 직접 입력하고 저장한다.

• 몇 번의 대화마다 디렉토리 구조를 다시 첨부한다.

• AI가 없는 파일이나 잘못된 구조를 가정하면 다시 구조를 주입한다.

당시 사용했던 프롬프트 방식은 대략 이런 형태였다.

아래는 현재 프로젝트의 디렉토리 구조입니다.
이 구조를 기준으로 작업해주세요.
존재하지 않는 파일을 임의로 만들지 말고, 필요한 경우 먼저 제안해주세요.

/project-root
├── index.php
├── config/
│   └── db.php
├── includes/
│   ├── header.php
│   └── footer.php
├── pages/
│   ├── course_list.php
│   └── course_detail.php
└── board/
    ├── list.php
    ├── view.php
    └── write.php

이번에는 board/list.php 파일만 작성해주세요.

이 방식은 지금 기준으로 보면 투박하지만, 채팅형 AI의 문맥 한계를 보완하는 데 꽤 효과적이었다. AI가 프로젝트 전체를 잊어버릴 때마다 디렉토리 구조를 다시 보여주면, 최소한 파일 간 관계를 다시 잡아낼 수 있었다.

이 프로젝트를 통해 배운 점은 명확했다.

• 바이브코딩에서도 프로젝트 구조는 먼저 잡아야 한다.

• AI에게 “전체를 알아서 해줘”라고 맡기면 쉽게 흔들린다.

• 비개발자일수록 파일 구조, 역할, 작업 단위를 작게 나누는 것이 중요하다.

• 채팅형 AI와 작업할 때는 문맥을 반복적으로 주입하는 장치가 필요하다.

2. Next.js, Supabase, Vercel로 만든 간단한 SNS

2025년 상반기에는 당시 많이 보이던 바이브코딩 스택을 따라가 보았다. Vercel, Supabase, Next.js, Tailwind CSS를 활용해 간단한 SNS를 만드는 프로젝트였다.

유튜브를 통해 PRD 기반 개발 방식을 접했고, 관련 강의를 들으며 예제 프로젝트를 따라 진행했다. 처음에는 “간단한 SNS”라고 생각했다. 하지만 만들다 보니 SNS는 결코 간단하지 않았다.

초기 결과물은 그럴듯했다. 페이지도 있었고, 버튼도 있었고, 게시글도 있었다. 하지만 실제 사용자가 쓸 수 있는 서비스라고 보기에는 부족한 점이 많았다.

가장 먼저 느낀 문제는 인터랙션이었다.

버튼에 hover 상태가 있는지, 클릭 중인지, 비활성화 상태인지, 로딩 중인지, 작은 애니메이션이 있는지 없는지는 사용자가 페이지를 사용할 때 매우 크게 느껴진다. 바이브코딩으로 만든 초기 페이지는 기능과 레이아웃은 있었지만, 이런 상호작용의 감각이 부족했다.

두 번째 문제는 공통 컴포넌트였다.

각 페이지에는 반복되는 요소가 많았다. 버튼, 카드, 입력창, 프로필 영역, 게시글 목록, 모달 같은 것들이었다. 그런데 AI는 이런 요소를 공통 컴포넌트로 정리하기보다 각 페이지에 따로 구현하는 경우가 많았다. 그 결과 비슷하지만 조금씩 다른 코드가 여러 곳에 생겼다.

이때부터 “공통 요소를 분리하고 기존 페이지를 공통 컴포넌트로 대체하는 과정”이 필요해졌다.

예를 들면 이런 식이다.

// components/PostCard.tsx
export function PostCard({ author, content, createdAt }) {
  return (
    <article className="rounded-xl border p-4 shadow-sm hover:shadow-md transition">
      <div className="text-sm text-gray-500">{author} · {createdAt}</div>
      <p className="mt-2 text-gray-900">{content}</p>
    </article>
  );
}

하지만 컴포넌트를 정리하는 과정에서는 오류가 자주 발생했다. 기존에 중복 구현된 코드를 걷어내야 했고, 어떤 페이지는 수정되었지만 다른 페이지는 깨지기도 했다. 이때 절실하게 느낀 것이 Git의 필요성이었다.

Git이 없었다면, 나는 아마 계속 덕지덕지 코드를 덧붙였을 것이다. 잘못 수정한 코드를 되돌리지 못하고, 어디서 문제가 생겼는지 모른 채 계속 새로운 코드를 얹었을 가능성이 높다.

이 프로젝트에서 세 번째로 마주친 문제는 데이터였다.

SNS는 한 명만 사용하는 페이지가 아니다. 여러 사용자가 게시글과 댓글을 만들고, 수정하고, 삭제한다. 그리고 이런 변화는 다른 사용자의 화면에도 반영되어야 한다.

즉, CRUD가 단순히 데이터베이스에 저장되는 것으로 끝나지 않았다.

• 내가 글을 작성했을 때 목록이 갱신되어야 한다.

• 다른 사용자가 댓글을 달았을 때 화면에 반영되어야 한다.

• 관리자가 데이터를 수정했을 때 사용자 화면도 업데이트되어야 한다.

• 권한과 인증, 실시간 반영, 오류 처리까지 고려해야 한다.

처음에는 “간단한 SNS”였지만, 실제 서비스의 문제는 간단하지 않았다.

이 프로젝트는 관리자 페이지를 구축하던 중 중단되었다. AI의 할루시네이션도 잦았고, 나 역시 어느 순간 “이제 그만하고 싶다”는 마음이 커졌다. 하지만 이 프로젝트는 내게 중요한 교훈을 남겼다.

바이브코딩은 화면을 빠르게 만드는 데 강하지만, 실제 사용 가능한 제품으로 다듬는 과정에서는 구조화, 검증, 버전 관리가 필수다.

3. Python으로 만든 로컬 Whisper 실시간 전사 앱

2025년 중반에는 완전히 다른 유형의 프로젝트를 시도했다. 회의 음성을 실시간으로 전사하는 Python 기반 데스크탑 앱이었다.

Python은 내가 업무상 다뤄본 적이 거의 없는 영역이었다. LAMP나 PHP처럼 서버를 설치하거나 웹페이지를 구동해본 경험도 없었다. 그래서 이 프로젝트는 기획부터 설계, 구현까지 거의 순수하게 바이브코딩으로 진행한 작업이었다.

처음에는 OpenAI의 Whisper API를 활용해 전사 시스템을 만들 수도 있다고 생각했다. 하지만 API 비용을 아끼고 싶었다. 또 가벼운 로컬 모델을 구동할 수 있는 Windows와 Mac 환경이 있었기 때문에, 로컬에서 돌아가는 Whisper 기반 전사 앱을 만들고 싶었다.

핵심 아이디어는 다음과 같았다.

• 회의 음성을 짧은 구간으로 나눈다.

• 각 음성 구간을 순차적으로 모델에 입력한다.

• 전사 결과를 실시간으로 텍스트 파일에 저장한다.

• 사용자는 회의가 진행되는 동안 계속 갱신되는 전사 결과를 확인한다.

이 프로젝트에서는 이전 SNS 프로젝트에서 겪은 문제를 반복하지 않으려 했다. 특히 AI가 중복 파일을 만들거나 불필요한 코드를 생성하는 문제를 줄이고 싶었다.

그래서 매 단위 작업마다 다음 과정을 반복했다.

• 기능 단위를 작게 나눈다.

• 구현 후 lint를 돌린다.

• 오류를 수정한다.

• 불필요한 파일을 정리한다.

• Git에 의미 있는 단위로 커밋한다.

또 하나 새롭게 적용한 것은 Git flow였다.

회사에서 개발 인력이 여러 명이 된다면 적용해보고 싶었던 개념이었고, 이번 개인 프로젝트에서 직접 실험해보고 싶었다.

내가 적용하려 한 흐름은 대략 다음과 같았다.

main
└── develop
    ├── feature/audio-capture
    ├── feature/realtime-transcription
    ├── feature/file-writer
    ├── feature/ui-prototype
    └── release/v0.1.0

Git flow를 사용하면서 좋았던 점은 개발 과정을 세세하게 관리할 수 있다는 것이었다. 어떤 기능을 언제 만들었고, 어디서 문제가 생겼으며, 어떤 시점으로 되돌아갈 수 있는지가 훨씬 분명해졌다.

일반적인 Git flow에서는 하위 브랜치의 개발이 끝나면 상위 브랜치에 병합하고 브랜치를 정리한다. 하지만 나는 의미 있는 브랜치의 경우 대부분 남겨두려고 했다. 이유는 단순했다.

LLM이나 미래의 내가 개발 히스토리를 참조하기 쉽게 만들고 싶었다.

개발 과정에서는 외부 Git 프로젝트를 내 프로젝트 안에 적용하는 일도 있었다. 이때 Git 프로젝트 안에 또 다른 Git 프로젝트를 둘 수 있다는 점, 그리고 이력 관리를 별도로 할 수 있다는 점도 알게 되었다.

전사 앱 프로젝트는 핵심 기능인 실시간 전사까지는 구현했다. 하지만 이후 세부 기능을 다듬는 단계에서 중단되었다.

가장 큰 문제는 메인 파일이 점점 비대해지는 것이었다. 기능이 늘어날수록 하나의 파일에 너무 많은 책임이 몰렸다. 이 구조는 실행 속도와 유지보수성 모두에 부담이 되었다.

그래서 컴포넌트와 모듈 단위로 파일을 분리하려 했다. 하지만 대규모 파일을 읽고, 이해하고, 안전하게 분리하는 작업을 당시 사용하던 모델은 충분히 잘 해내지 못했다. Cursor AI와 GitHub Copilot을 병행했지만, 기본 유료 요금제 수준에서 사용할 수 있는 모델에는 한계가 있었다.

파일을 분리하는 과정에서 핵심 기능이 깨지거나, 실제로는 메인 파일이 충분히 분리되지 않는 문제가 반복되었다. 긴 시간 동안 이 문제를 붙잡고 있다가 개인 일정이 겹쳤고, 결국 자연스럽게 프로젝트는 멈추게 되었다.

하지만 이 프로젝트는 나에게 또 다른 질문을 남겼다.

AI에게 코드를 맡기는 것과, AI에게 개발 과정을 맡기는 것은 다르다.

결과와 배운 점

이번 주에는 그동안의 작업을 되돌아보았다. LAMP와 PHP로 시작했던 첫 바이브코딩, Next.js와 Supabase 기반 SNS, Python 로컬 Whisper 전사 앱까지 돌아보니, 프로젝트마다 내가 배운 것이 조금씩 달랐다.

처음에는 “AI가 코드를 만들어주는가?”가 궁금했다.

그다음에는 “AI가 만든 코드를 실제 서비스처럼 다듬을 수 있는가?”가 궁금해졌다.

그리고 지금은 “AI에게 더 긴 작업 단위를 위임하려면 어떤 워크플로우가 필요한가?”가 궁금하다.

IDE형 AI 도구는 어느 정도 다뤄봤다. Cursor AI, GitHub Copilot처럼 내가 코드를 보면서 지시하고, 결과를 확인하고, 다시 피드백하는 방식에는 익숙해졌다. 하지만 Claude Code처럼 CLI 방식으로 동작하고, 더 긴 시간과 더 큰 작업 단위를 위임하는 도구는 아직 낯설다.

내가 이번 스터디에서 확인하고 싶은 것은 단순히 Claude Code 사용법이 아니다.

더 정확히는 이런 질문들이다.

• CLI 방식의 AI 개발 도구와 일하려면 작업 지시를 어떻게 설계해야 할까?

• 긴 시간 AI에게 작업을 위임할 때 중간 검증 지점을 어떻게 만들 수 있을까?

• Git flow를 Claude Code 작업 방식에 맞게 어떻게 다듬을 수 있을까?

• AI가 만든 결과물을 내가 일일이 검토하던 방식에서 벗어나려면 어떤 자동 검증 절차가 필요할까?

• 비개발자인 내가 프로젝트를 끝까지 완성하려면 어느 수준까지 구조를 직접 통제해야 할까?

지금까지의 경험을 통해 내가 얻은 가장 큰 교훈은 이것이다.

바이브코딩의 핵심은 “AI에게 맡기는 것”이 아니라, “AI가 길을 잃지 않도록 작업 환경과 기준을 설계하는 것”이다.

2024년의 나는 디렉토리 구조를 반복해서 붙여넣으며 ChatGPT의 문맥을 붙잡으려 했다.

2025년 상반기의 나는 SNS 프로젝트를 만들며 공통 컴포넌트, 인터랙션, 실시간 데이터, Git의 필요성을 배웠다.

2025년 중반의 나는 Python 전사 앱을 만들며 lint, 브랜치 전략, Git flow, 모듈 분리의 중요성을 배웠다.

그리고 이제는 Claude Code를 통해 한 단계 더 나아가고 싶다.

이번 스터디 과정에서 나는 반드시 하나의 프로젝트를 완성할 것이다. 완성이라는 목표를 통해 CLI 방식의 AI 도구를 익히고, Git flow를 더 견고하게 다듬고, AI에게 긴 작업을 위임하는 나만의 워크플로우를 만들어가고 싶다.

이전 프로젝트들이 중단되었다고 해서 실패였다고 생각하지는 않는다. 오히려 각각의 중단 지점은 다음 프로젝트에서 내가 조심해야 할 부분을 알려주었다.

• LAMP 프로젝트는 문맥 관리의 중요성을 알려주었다.

• SNS 프로젝트는 실제 서비스 수준의 디테일과 Git의 필요성을 알려주었다.

• 전사 앱 프로젝트는 구조 분리와 자동 검증의 필요성을 알려주었다.

이번에는 그 배움을 모아, 끝까지 가보려 한다.

도움 받은 글

• Anthropic Claude Code 공식 문서

• Atlassian Gitflow Workflow 가이드

• OpenAI Speech to Text 및 Whisper 관련 문서

• Supabase Realtime / Postgres Changes 공식 문서