바이브 코딩(Vibe Coding)의 종말: 내가 구조화된 AI 워크플로우(Structured AI Workflows)로 전환한 이유

나는 3개월 동안 내 SaaS를 "바이브 코딩(vibe coding)"하며 보냈다. 그러다 내가 직접 코드를 작성했을 때보다 AI의 실수를 수정하는 데 더 많은 시간을 쓰고 있다는 사실을 깨달았다. 모든 것을 바꿔 놓은 시스템을 소개한다.

2026년 6월 초, 합계 약 1,300개의 댓글이 달린 두 개의 HN 스레드는 무언가 변화했다는 것을 내게 알려주었다.

스레드 1 (~1,100개 댓글): "생성형 AI(GenAI)를 사용하며 겪었던 '아차(oh shit)' 했던 순간은 언제인가요?"
스레드 2 (~230개 댓글): "AI 등장 이후 자신을 위해 직접 만든 도구는 무엇인가요?"

두 스레드 모두 동일한 패턴을 보였다. 사람들은 여과 없는 흥분("주말 사이에 앱 하나를 통째로 만들었어요!")으로 시작했지만, 곧 벽에 부딪혔다("코드를 처음부터 짜는 것보다 버그를 수정하는 데 더 많은 시간을 쓰고 있어요").

나도 그 기분을 안다. 직접 겪어봤기 때문이다.

바이브 코딩(Vibe Coding)의 함정

AI 기반의 크로스 플랫폼 콘텐츠 도구인 MultiPost를 만들기 시작했을 때, 나는 "바이브 코딩(vibe coding)" 모드에 깊이 빠져 있었다:

나: "더 보기 좋게 만들어줘"
AI: *Tailwind를 추가하고 모든 스타일을 재설정함*
나: "날짜별 필터를 추가해줘"
...

이것이 몇 주 동안 나의 일상적인 리듬이었다. 출력(output)은 빠르지만, 정리(cleanup)는 느렸다. 코드베이스가 커질수록 그 비율은 점점 더 악화되었다.

나는 전달 속도(speed of delivery) 대신 **생성 속도(speed of generation)**를 최적화하고 있었다.

"아차(Oh Shit)" 했던 순간

구조화되지 않은 AI 세션을 통해서만 구축한 기능을 검토했을 때 그 순간이 찾아왔다. 기능은 작동했다. 하지만:

• 코드는 동일한 작업에 대해 3가지 서로 다른 패턴을 가지고 있었다 (한 곳에서는 Auth0 토큰을 처리하고, 다른 곳에서는 하드코딩된 키를 사용함)
• 에러 처리(Error handling)가 일관되지 않았다 — 어떤 함수는 null을 반환하고, 어떤 함수는 예외를 던지며(throw), 또 다른 함수는 Result 타입을 반환했다
• 데이터베이스 쿼리(Database queries)가 리포지토리 레이어(repository layer)에 모여 있지 않고 코드베이스 전체에 흩어져 있었다
• 보안 검토자(security reviewer)가 봤다면 울었을 것이다

AI가 악의적으로 이렇게 행동한 것은 아니다. 내가 구조적인 프레임워크(structural framework)를 전혀 제공하지 않은 채 그저 "이것 좀 고쳐줘", "저것 좀 추가해줘"라고 요청했기 때문에 발생한 일이었다. 모든 세션은 이전의 아키텍처 결정(architectural decisions)에 대한 기억이 없는 새로운 컨텍스트(context)였다.

해결책: 구조화된 AI 워크플로우 (Structured AI Workflows)

저는 "바이브 코딩 (vibe coding)"에서 제가 **구조화된 AI 워크플로우 (structured AI workflows)**라고 부르는 방식으로 전환했습니다. 원칙은 간단합니다:

AI에게 코드를 작성해달라고 하지 마세요. 당신이 함께 설계한 계획을 실행하도록 요청하세요.

제가 실제로 사용하는 시스템은 다음과 같습니다:

1. 생성 전 설계 (Design Before Generate) (15분)

AI가 기능(feature)을 위해 코드 한 줄이라도 작성하게 하기 전에 다음과 같은 과정을 거칩니다:

1단계: AI에게 해당 기능을 평이한 영어(plain English)로 다시 설명하기
2단계: AI에게 구성 요소(components), 데이터 흐름(data flow), 예외 케이스(edge cases)를 나열하도록 요청하기
3단계: 내가 계획을 검토하기 — 코드가 존재하기 전에 아키텍처(architecture)를 수정하기
...

핵심적인 변화는 이것입니다: 저는 코드를 디버깅(debugging)하는 것이 아니라 계획을 검토(reviewing)하고 있습니다. 계획 검토는 2분이 걸리지만, 생성된 코드를 디버깅하는 데는 30분이 걸립니다.

2. 세션당 하나의 관심사 (One Concern Per Session)

이것이 저의 가장 큰 실수였습니다. 저는 한 번에 "인증 시스템(auth system)을 구축해줘"라고 요청하곤 했습니다. 이는 AI가 인증 UI, 백엔드 라우트(backend routes), 데이터베이스 스키마(database schema), 미들웨어(middleware)를 한꺼번에 생성한다는 것을 의미합니다. 검토하기에는 너무 양이 많았습니다.

대신 다음과 같이 합니다:

세션 1: "인증 데이터 모델을 설계하세요. 제약 조건은 다음과 같습니다..."
세션 2: "세션 1의 데이터 모델을 기반으로 인증 API 라우트를 구현하세요"
세션 3: "로그인 페이지 UI를 구축하세요"

각 세션은 제가 5분 이내에 완전히 검토할 수 있는 하나의 명확한 결과물을 가집니다.

3. 프롬프트 템플릿을 통한 구조 강제 (Enforce Structure with Prompt Templates)

저는 일회성 프롬프트를 입력하는 것을 그만두었습니다. 모든 세션은 구조화된 템플릿으로 시작합니다:

컨텍스트 (CONTEXT): [우리가 무엇을 만들고 있는지, 지금까지 내려진 결정 사항들]
작업 (TASK): [단일하고 구체적인 결과물]
제약 조건 (CONSTRAINTS): [기술 스택 (tech stack), 따라야 할 패턴, 피해야 할 사항들]
...

이것만으로도 "AI의 실수를 수정하는" 시간을 약 60% 단축했습니다.

4. "검토 게이트 (Review Gate)" 관행

모든 구현 세션이 끝난 후, 코드를 수락하기 전에 다음을 확인합니다:

1. 계획과 일치하는가? (일치하지 않는다면 거절하세요 — 즉석에서 수정하지 마세요)
2. 에러 경로(error paths)가 처리되었는가? (그렇지 않다면 구체적으로 요청하세요)
3. 기존 코드와 일관성이 있는가? (동일한 패턴, 동일한 컨벤션(conventions))

이것이 많아 보일 수 있습니다. 하지만 세션당 3~5분이 소요될 뿐이며, 나중에 발생할 수 시간의 디버깅 시간을 아껴줍니다.

전과 후 (실제 코드)

제 코드베이스에서 전형적인 바이브 코딩 (Vibe Coding) 방식의 인증 로직이 어떤 모습이었는지 보여드리겠습니다. 세 번의 서로 다른 세션, 세 가지의 서로 다른 패턴이었습니다:

- // 세션 1: "여기에 인증 확인 추가"
- function getUserId(req) {
-   const token = req.headers.authorization?.split(' ')[1]
...

세 가지 접근 방식. 세 가지의 에러 처리 (Error-handling) 스타일. 하드코딩된 비밀값 (Hardcoded secret). 발생하기만을 기다리는 SQL 인젝션 (SQL injection). 각 세션이 이전 세션에 대한 기억이 없었기 때문에 모두 "같은 일"을 하고 있었습니다.

구조화된 워크플로우 (Structured workflow, 세션당 하나의 관심사, 각 세션 사이의 검토 게이트)를 적용한 후에는 다음과 같습니다:

+ // repository/auth.js — 단일 진실 공급원 (Single source of truth), 단일 패턴
+ 
+ export function verifyToken(token) {
...

하나의 파일. 하나의 패턴. 하나의 에러 처리 (Error-handling) 전략. AI는 두 버전 모두 작성했습니다. 차이점은 제가 AI에게 그 안에서 작동할 수 있는 구조를 제공했는지 여부였습니다.

실제 수치: 전 vs 후

특히 MultiPost의 경우:

지표	바이브 코딩 (Vibe Coding)	구조화된 워크플로우 (Structured Workflows)
기능 완성까지 걸리는 시간	4-6시간	3-4시간
...	...	...

흥미로운 점은 구조화된 워크플로우가 당장은 더 느리게 느껴질지라도, 전체적으로는 실제로 더 빠르다는 것입니다. 초기에 투입된 계획 시간은 디버깅 시간을 줄임으로써 그 가치를 충분히 보상합니다.

흐름의 차이

두 접근 방식의 차이를 나란히 비교하면 다음과 같습니다:

바이브 코딩 (VIBE CODING):
  "기능 X 구축" → AI가 500줄 작성 → 배포 → 버그 발생 → 디버깅 → 패치 → 반복
  │                      │                        │
...

바이브 코딩 경로는 결과물이 즉시 보이기 때문에 더 빠르게 느껴집니다. 구조화된 경로는 거의 되돌아가는 일이 없기 때문에 실제로 더 빠릅니다.

더 큰 패턴

약 230개의 댓글이 달린 HN (Hacker News) 스레드를 살펴보면, 여러 사람이 독립적으로 동일한 결론에 도달했습니다:

"제가 지금 작성하는 대부분의 도구들은 API는 있지만 CLI(Command Line Interface)가 없는 다양한 SaaS 제품들을 연결하는 브릿지(Bridge) 역할을 합니다."

"저는 AI의 출력을 규율하기 위한 하네스(Harness)를 만들었습니다. 바이브 코딩(Vibe Coding)의 정반대 개념이죠. 매일 사용하고 있습니다."

"Superpowers는 모델이 신중하고 체계적인 접근 방식을 사용하도록 안내합니다. 다단계 계획(Multi-step planning)에 매우 유용합니다."

커뮤니티는 동일한 통찰력을 중심으로 자발적으로 조직화되고 있습니다: AI는 강력한 주니어 엔지니어입니다. 주니어 엔지니어가 양질의 결과물을 만들어내기 위해서는 구조(Structure)가 필요합니다.

내가 현재 사용하는 것

결국 저는 정확히 이러한 워크플로우(Workflow)를 강제하기 위해 Content Bridge라는 CLI를 구축하게 되었습니다. 이것은 말 그대로 이 글을 도구로 만든 것입니다. 계획을 작성하고, 검토하고, 한 번에 하나의 구성 요소를 구현하면, CLI가 구조를 강제하므로 사용자가 규칙을 일일이 기억할 필요가 없습니다.

하지만 시작하기 위해 어떤 도구가 반드시 필요한 것은 아닙니다. 오늘 바로 한 가지 변화를 통해 시작할 수 있습니다:

다음 AI 세션을 시작하기 전, AI가 무엇을 만들어내길 원하는지 작성하는 데 2분을 투자하세요. '어떻게(How)'가 아니라 '무엇을(What)'에 집중하세요. 무언가를 생성하기 전에 그 계획을 먼저 검토하십시오.

생성(Generation)은 쉬운 부분입니다. 구조를 잡는 것이 진짜 작업입니다.

여러분의 방식은 어떠신가요? 여러분도 바이브 코딩의 함정에 빠진 적이 있나요? 여러분의 워크플로우(또는 공포스러운 경험담)를 댓글로 남겨주세요. 모두 읽어보겠습니다.