바이브 코딩을 배운다 는 무슨 말일까?

오늘도 글감을 찾아서 이리저리 머리를 굴리다가… 문득 요즘 “저도 바이브 코딩을 배우고 싶어요…” 라는 글을 스레드에서 많이 보는 거 같아서, 한 번 생각을 해봤다.

“바이브 코딩을 배운다” 는 무슨 말일까?

1. 바이브 코딩을 하는 법을 배운다? → 하는 법이랄게 있나? 그냥 해줘! 인데
2. 코딩의 기초? → 아님. 그건, 그냥 코딩을 배우는 거니까
3. 바이브 코딩으로 “상품”을 만든다? → 이게 제일 맞는 뉘앙스인 거 같다.
4. 바이브 코딩을 효율적으로 하는 방법 → 이건가..? 싶기도 한데

그래서 오늘은 이 3번과 4번에 대해서 좀 이야기해보려고 한다.

요즘 뜨는 뉴스에 해커톤 수상자가 다 CS를 배우지 않은 비전공자라고 한다.

그만큼 더 이상 코딩 지식은 무언갈 만드는 데 그다지 필요 없는 세상이 됐다는 이야기다.

세상이 참 무섭다. 불과 5년 전까지만 해도 개발자는 무슨 철밥통에 어디든 모셔가는 포지션이었는데…

아무튼, 바이브 코딩으로 무엇이든 러닝 커브 없이, 머리 싸매지 않고 쉽게 쉽게 만들어낼 수 있는데…

하지만 내 생각은 다르다.

무엇이던 딸깍! 하고 만들 수는 있지만, 이걸 “운영” 하고 지속 가능하게 유지보수하는 건 또 다른 영역이다.

내가 하고 싶은 말은, AI 가 딸깍하고 앱을 만들 수는 있지만 아주 기초적인 수준이더라도 이 앱이 돌아가게 하기 위한 서버와 DB 셋팅, 그리고 그 수요를 예측해서 인프라를 셋팅하는 일까지의 전반적인 과정은 결코 딸깍! 으로 되지 않는다는 말이다.

물론 이것도 AI 에게 물어보면서 차근차근한다고 하면 할 수야 있겠지만 기초적인 CS 지식이나 경험이 없이는 쉽지 않다는 것이다.

그래서 “바이브 코딩을 배운다” 는 것은 이러한 전반적인 개발의 생명 주기와 운영 유지보수 방법을 배운다. 는 느낌인 거다.

아, 모르겠다.

요즘 성행하는 “바이브코딩으로 월 1억 버는데..ㅋㅋ 방법 알려드림, 200만원 주셈” 하는 그런 강좌에서 뭘 알려주는지는 아예 신경을 안 써봐서…

다음은 효율적인 바이브 코딩 방법이다.

효율적인 바이브 코딩 = 멀티 에이전트?

찾아보면 답이 거의 정해져 있다.

“Multi-agent 가 답이다.”

“Background agent 로 자동화의 끝을 봐라.”

“10명 시키면 1명보다 10배 빠르다.”

진짜 그런가? 그래서 한 번 셋팅은 해봤다.

며칠 굴려보니까 — 나는 안 쓰겠더라.

찬양 글이랑 실제로 셋팅해서 굴려본 느낌은, 좀 다르더라.

한 번 셋팅해보니까

호기심에 셋팅은 해봤다. Cursor 의 background agent 도 띄워봤고, Claude Code 의 서브에이전트도 정의 파일 만들어서 굴려봤다.

며칠 굴려보니까 — 좋은 점도 있고, 별로인 점도 있었다.

좋았던 점

컨텍스트 분리. 한 작업의 노이즈가 다른 작업으로 안 넘어간다. 메인 세션이 안 무거워진다. 큰 코드베이스 분석할 때 이게 진짜 좋다.

진짜 독립적인 작업 던질 때. 예를 들어 “이 폴더 전체 테스트 커버리지 좀 올려” 같은 거. 본인 메인 작업이랑 충돌 안 하고, 자는 동안 굴려놓으면 아침에 PR 와있는 느낌. 이건 진짜 좋다.

병렬로 굴러가는 거 보는 것 자체. 처음엔 신기했다. 내가 다른 일 하는 동안 백그라운드에서 코드가 짜지고 있다는 감각.

별로였던 점

셋팅 자체가 일이다. 각 에이전트 역할 정의하고, 권한 설정하고, 언제 트리거할지 정하고, 실패하면 어떻게 할지 정하고. 코드 짜기 전에 셋팅에 한참 매달려야 한다.

자동 위임이 잘 안 된다. 문서에선 “메인 에이전트가 알아서 적절한 서브에이전트 부른다” 고 하는데, 실제로는 거의 안 부른다. 매번 “이거 X 에이전트한테 시켜” 라고 명시해줘야 한다. 그러면 자동화의 의미가 좀 없어진다.

모호한 지시를 못 견딘다. 내가 평소 “이거 좀 깔끔하게 해줘” 같은 모호한 말을 던지면, 한 명한테는 통한다. 본인이 컨텍스트 보고 알아서 한다. 근데 멀티 에이전트는 그 모호함을 다 결정 지점으로 펼친다. “깔끔하게” 가 무슨 뜻이냐, 어디까지 리팩토링하냐, 어떤 컨벤션 따르냐… 다 정해줘야 한다.

멀티 파일 가로지르는 작업이 어색하다. 한 파일 안에서 끝나는 작업은 잘하는데, 여러 파일에 걸친 refactor 같은 건 한 에이전트한테 통째로 시키는 게 차라리 깔끔하다.

그리고 — 에이전트 파일들이 먼지가 쌓인다. 만들어놓고 처음엔 신나서 쓰다가, 한 달 지나면 그냥 메인 에이전트가 다 처리하는 게 빠르더라. 정의 파일들이 안 쓰여서 점점 잊혀진다.

1인 개발자라서 더 안 맞는 이유들

내 일은 거의 시퀀셜이다. 새 기능 하나, 버그 픽스 하나, 디자인 조정 하나. 5개의 모듈을 동시에 만드는 일은 그냥… 없다. 병렬화의 이점을 살릴 일이 거의 없다는 얘기.

토큰도 많이 먹는다. Max 플랜이라 비용은 정액이지만, rate limit 에는 더 자주 걸린다. 작업 중간에 막히는 빈도가 늘어난다.

그리고 가장 큰 이유 — 가시성

위의 단점들은 어떻게든 셋팅으로 해결할 수 있다. 시간만 들이면.

근데 진짜 결정적이었던 건 다른 거였다. 한 화면에서 흐름이 안 보인다.

저번 vibe slop 글에서 짚었던 그 문제 — 내 코드인데 내 코드 같지 않은 감각. 한 세션에서 4명 굴리는 지금도 솔직히 AI 가 뭘 했는지 100% 따라가진 못한다. 보고자가 정리해주니까 큰 그림은 잡지만 코드 한 줄 한 줄까지는 안 본다.

근데 진짜 multi-agent 를 쓰면? 별도 컨텍스트에서 4명이 동시에 일한다. 각자 다른 파일 열고, 각자 다른 결정 내리고.

본인은 결과만 받아서 보는데 — 누가 언제 뭘 했는지의 흐름 자체가 안 보인다.

내 코드인데 내 코드 같지 않은 감각이, 한 단계 더 깊어지는 거.

그래서 며칠 굴려보고 — 메인 작업에선 안 쓰기로 했다. 진짜 독립적인 백그라운드 잡 외에는.

그래서 나는 이렇게 쓴다 — 한 세션 안에 4명

내가 7~8개월 전 Cursor 로 처음 에이전트라는 걸 시작하면서 뭔가… 정신 차리니 이렇게 쓰고 있었다.

한 명의 AI 한테 4가지 페르소나를 갈아끼우면서 시킨다. 같은 세션, 같은 컨텍스트.

순서는 항상 같다: 총괄 → 개발 → 검수 → 보고.

총괄

내가 “X 기능 만들자” 던지면 받아서 정리한다.

• 기획: 무엇을 어떻게 만들 건지
• 분석: 기존 코드 구조, 어디에 손대야 하는지
• 잠재 위험: 깨질 수 있는 것들
• 데이터 구조: DB / API / 모델 변경 필요 여부

핵심은 — 내 말을 그대로 코드로 옮기지 않고, 한 번 통역한다는 거다. 내가 던지는 말은 보통 거칠고 모호하다. 총괄이 그걸 실행 가능한 작업 단위로 쪼개준다.

개발자

총괄이 정리한 거 받아서 코드 짠다.

1명. 더 필요 없다. 코드 작성은 본질적으로 순차적이고, 동시에 두 명이 같은 파일 건들면 머지 지옥이다.

검수자

개발 끝나면 검수자가 네 가지 본다.

• 보안: 인증, 권한, 입력 검증, SQL Injection, XSS
• 메모리 릭: 클린업 안 된 리스너, useEffect 의존성 누락
• 성능: N+1 쿼리, 불필요한 리렌더, 과도한 알고리즘
• Dead end: 호출 안 되는 함수, 죽은 분기, 안 쓰이는 import

저번 글에서 review fatigue 얘기했는데, 검수자가 따로 있으면 그게 안 온다.

보고자

검수 끝나면 보고자가 정리한다.

• 오늘 한 작업 요약
• 변경된 파일 / 함수 리스트
• 적용 방법 (env 변수 추가? 마이그레이션?)
• 다음 작업 후속 아이템

이게 왜 중요하냐면 — 본인이 결과를 읽게 만들기 때문이다.

AI 가 “다 했어요” 로 끝나면 본인은 코드 안 본다. 그게 자동화 편향이다. 근데 보고자가 정리한 보고서를 본인이 한 번이라도 읽으면 — 그 편향이 한 단계 깨진다.

근데 사실 표준 orchestrator-workers 는 아니더라

처음엔 이게 Anthropic 이 공식 문서로 정리한 orchestrator-workers 패턴인 줄 알았다.

찾아보니까 — 엄밀히는 아니다.

진짜 orchestrator-workers 는:

1. 별도 LLM 인스턴스 (worker 마다 자기 컨텍스트)
2. 병렬 실행
3. 동적 위임 (작업 보고 worker 수 그때그때 결정)

내가 하는 건:

1. 한 LLM 인스턴스
2. 순차 실행
3. 고정된 4명

영감은 같은데, 구현이 완전히 다르다. Anthropic 분류로는 사실 Prompt chaining + Evaluator-optimizer + Role prompting 의 조합에 가깝다. 한 세션 안에서 작업을 순차로 쪼개고, 검수자가 평가하고, 각 단계에 페르소나를 부여한 거.

진짜 orchestrator-workers 의 가벼운 버전이라고 할 수 있다.

마치며

처음으로 돌아가서 — “바이브 코딩을 배운다” 가 뭘까?

뭐, 이건 당연하게도 공부를 하고자 하는 사람의 기본적인 지식 수준에 따라 다른 거겠지.

아예 기초적인 개발 지식이 하나도 없는 사람한테는 — 바이브 코딩으로 서비스를 만들어서 운영하는 방법이 될 수도 있고,

바이브 코딩을 하긴 하는 거 같은데 이게 맞는 지 모르겠는 사람한테는 — 그 방법론일 수도 있고,

하긴 하는데 효율이 떨어지거나 자꾸만 컨텍스트가 꽉 차서 이상한 방향으로 가는 거 때문에 개발을 못하겠는 사람한테는 — 오케스트레이션 방법일 수도 있겠지.

뭐가 됐던 — 어디에 속하든, 며칠 직접 굴려보고 본인한테 맞는 답을 찾는 게 결국 답이긴 하다.

내 경우엔 — 위에 페르소나를 4개 쓰니 뭐니 그럴싸하게 늘어놨지만,

결국엔 이거다.

바이브 코딩을 하지만, 바이브 코딩을 안한 것처럼 하는 방법

AI 가 짠 코드를, 내가 짠 코드처럼 알고 있다는 거. 난 이걸 지키려고 노력하는 거 뿐인 거 같다.

마침.