지난 글에서 기획자와 PM이 바이브 코딩에 특히 유리하다고 작성했습니다.

요구사항 정의
스코프 관리
리뷰와 피드백

본체가 되는 능력을 이미 갖고 있으니까요.

그런데 한 가지를 짚고 넘어가야 합니다.

여러분이 가장 자신 있는 기술인 기획서 작성은 AI 앞에서 습관 하나를 바꿔야 합니다.

개발자는 되묻고, AI는 채운다

기획서를 개발자에게 넘겼을 때를 떠올려보세요.

문서에 빈칸이 있으면 어떻게 되던가요.

"파일 용량 제한은 없나요?"
"이름 겹치면 덮어써요, 아니면 막아요?"
"실패하면 유저한테 뭐라고 보여줘요?"

질문이 돌아옵니다. 귀찮았겠지만, 그 질문들이 사실 안전망이었습니다.

여러분의 빈칸을 사람이 막아주고 있었던 것입니다.

십수 년 일하며 우리가 "기획서는 어차피 대화로 완성된다"고 배운 이유죠.

AI는 다릅니다.

AI는 되묻는 대신 홀로 채웁니다.

빈칸을 만나면 멈추지 않고, 가장 그럴듯한 값으로 메꿔서 완성된 결과물을 가져옵니다.

문제는 그 "그럴듯한 값"이 여러분의 의도가 아니라 확률이라는 것입니다.

그리고 결과물이 워낙 매끈해서, 뭐가 채워졌는지 티가 안 난다는 것은 부가적으로 따라오는 이슈입니다.

빈칸이 질문으로 돌아오면 사고를 막을 수 있습니다.

반대로 빈칸이 소리 없이 채워지면, 사고가 나도 사고인 줄 모릅니다.

실제로 겪은 일

강의를 만들면서 AI에게 파일 업로드 기능을 시킨 적이 있습니다.

요구사항을 꽤 자세히 적었다고 생각했습니다.

드래그 앤 드롭으로 올리고,

지원 안 하는 확장자는 거르고,

용량 제한도 걸고.

AI는 깔끔하게 만들어왔습니다.

화면도 예뻤고,

거부 처리도 잘 됐습니다.

그런데 작업 브리핑을 읽다가 한 문장이 걸렸습니다

"이 단계는 서버 왕복 없이 전부 클라이언트 안에서 처리됩니다."

풀어 쓰면 업로드한 파일을 브라우저가 들고만 있고, 어디에도 저장하지 않는다는 뜻이었습니다.

제 기획서에 "파일을 어디에 저장한다"가 없었던 겁니다.

개발자였다면 "이거 저장은 어디로 가요?"라고 물었을 빈칸을

AI는 "일단 안 저장하는 걸로" 채워서 완성해온 것입니다.

겉보기엔 멀쩡히 동작하는 화면과 함께 말입니다.

빈칸은 제 것이었습니다. AI는 시킨 대로 시킨 만큼만 했습니다.

그래서 기획 습관을 이렇게 바꿉니다

이 차이를 알고 나면 고칠 것은 하나입니다.

사람에게 넘길 때는 넘어갔던 것을 AI에게 넘길 때는 기획 단계에서 꼼꼼하게 닫아야 합니다.

제가 AI를 사용하는 방법은 거창하지 않습니다.

작업서를 전달하기 전에 한번 더 검토할 뿐입니다.

"실패하면?"

이 기능이 안 됐을 때 어떻게 할지. (AI 호출이 실패하면? 파일이 너무 크면?)

"중복되면?"

같은 처리를 두 번 하면 어떻게 할지. (같은 이름의 파일이 또 올라오면?)

"끝나면?"

이 기능이 "됐다"의 기준을 적었나. (파일 10개를 올리면 목록에 뜬다)

특히 마지막 질문은 있느냐 없느냐가 검수 가능 여부를 가릅니다.

이건 새로운 기술이 아닙니다.

시니어 기획자들이 주니어 기획서를 리뷰할 때 하는 바로 그 질문들이에요.

예외 처리, 엣지 케이스, 완료 조건. 여러분이 이미 아는 개념입니다.

달라진 것은 하나입니다.

이 질문을 대신 해주던 개발자가 이제 없다는 것.

그 역할이 여러분 안으로 들어와야 합니다.

그리고 한 가지 더. 다 못 닫아도 괜찮습니다.

저도 저장 위치를 놓쳤으니까요.

대신 결과물을 받으면 검토 단계에서 "내가 안 적은 걸 얘가 뭘로 채웠지?"를 찾습니다.

빈칸을 미리 다 막는 게 아니라,

뭘로 채워졌는지 추적 가능한 상태를 유지하는 겁니다.

그게 안 되는 순간부터가 진짜 사고입니다.

정리

• 개발자는 기획서의 빈칸을 질문으로 돌려주고, AI는 그럴듯한 것으로 채워서 돌려줍니다.
• 그래서 AI에게 넘기는 기획서는 "실패하면 / 중복되면 / 끝나면" 세 질문을 스스로 통과해야 합니다.
• 이건 새 기술이 아니라, 여러분이 리뷰 때 이미 쓰던 질문의 방향을 자기 문서로 돌리는 일입니다.

지난 글의 결론에 한 줄을 보태며 마칩니다.

기획자와 PM은 바이브 코딩의 적임자가 맞습니다.

되물어주는 사람이 사라진 자리에서, 스스로 되묻는 습관까지 갖추면 말입니다.

바이브 코딩 이야기가
나올 때마다 반복되는 문구가 있습니다.
"이제 누구나 만들 수 있다."

저는 이 말이 반만 맞다고 생각합니다. 그리고 반만 맞는 말은 아무도 움직이지 못합니다.

"누구나"는 곧 "내가 어떻게 하는데?"로 읽히니까요.

14년간 개발자로 지내오며 기획자, PM, 아티스트와 일해온 사람으로서, 더 정확한 문장을 제안하고 싶습니다.

"누구나"가 아니라, 기획자와 PM이 특히 잘할 수밖에 없습니다. 개발자보다 유리한 지점이 있습니다.

AI에게 일 시키기 = 여러분이 매일 하는 일

AI로 뭔가를 만드는 과정을 뜯어보면 이렇게 됩니다.

뭘 만들지 정의하고,

범위를 자르고,

나온 결과물을 검토해서 다시 시키는 반복.

이걸 실무자의 언어로 다시 쓰면:

요구사항 정의
스코프 관리
리뷰와 피드백

여러분이 매일 하는 일입니다.

개발자에게 기획서를 넘기고,

"이번 스프린트엔 여기까지만"을 정하고,

나온 빌드를 보고 "의도랑 다른데요"를 짚어내는 일 말입니다.

바이브 코딩은 이 상대가 개발자에서 AI로 바뀐 것뿐입니다.

오히려 AI는 밤에도 일하고, 기분이 상하지 않고, 다시 시켜도 한숨을 쉬지 않죠.

실제로 제가 강의를 만들면서 AI와 주고받은 결정들은 전부 이런 것들이었습니다.

"이 작업 단위가 다른 것들에 비해 너무 뚱뚱하다, 쪼개자."
"이 기능은 이번 범위에서 빼자."
"네가 정리한 계획, 사용자 흐름이 통째로 빠져 있는데?"

코딩 지식으로 내린 결정이 하나도 없습니다.

전부 기획 판단입니다.

그리고 이 판단이 결과물의 품질을 갈랐습니다.

코딩이요? 코딩은 AI가 합니다. 그게 바이브 코딩의 정의입니다.

그런데 왜 다들 막히는가

여기까지 읽으면 반문이 나올 겁니다.

"그렇게 쉬우면 왜 내 주변 사람들은 다 하다가 포기했는데?"

제가 비개발 직군 지인들을 관찰하며 확인한 병목은 두 개였습니다.

그리고 둘 다 능력의 문제가 아니었습니다.

먼저 말씀드릴 것은 도구입니다.

바이브 코딩 자료 대부분이 검은 터미널 화면과 마크다운 문서에서 시작합니다.

내용을 배우기 전에 도구에서 이탈하는 거죠. 그런데 이건 우회로가 있습니다.

저는 거의 모든 작업을 노션과 클로드 데스크톱 안에서 진행합니다.

이미 쓰고 있는 도구 두 개만으로도 전체 사이클이 돌아갑니다.

도구 문제는 사실 문제가 아니었던 겁니다.

다음 병목이 진짜입니다. "키워드"

아는 단어만큼만 시킬 수 있다

두 사람이 같은 화면을 만들려고 합니다.

파일을 끌어오면 화면 전체가 살짝 어두워지면서 "여기 놓으세요"가 뜨는,

요즘 흔한 그 업로드 화면이요.

A는 이렇게 시킵니다.

"파일을 끌고 오면 화면이 어두워지고 아무 데나 놓아도 올라가게 해줘."

B는 이렇게 시킵니다.

"창 전체를 드롭존으로 하고, 드래그 진입 시 딤드 처리해줘."

둘 다 같은 걸 원했지만,

결과물의 정확도는 다르게 나옵니다.

B가 코딩을 더 잘해서가 아닙니다.

드롭존과 딤드

그 화면을 부르는 단어를 사용했을 뿐입니다.

AI에게 일을 시킬 때의 냉정한 규칙은 아는 단어만큼만 시킬 수 있다는 것입니다.

머릿속 그림이 아무리 선명해도, 그걸 입력하는 명칭을 모르면 AI와 나 사이에서 뭉개집니다.

반대로 명칭을 정확히 입력하는 순간, AI는 놀랄 만큼 정확해집니다.

이게 기획자와 PM에게 남은 마지막 한 조각입니다.

능력이 아니라 키워드입니다.

키워드는 학습이 아니라 온보딩이다

"결국 뭘 배우긴 해야 하네"라고 느끼실 수 있는데 정확히 말씀드리고 싶습니다.

개발을 배우는 것이 아닙니다.

문법도, 자료구조도 없습니다.

필요한 건 단어 수십 개입니다.

드롭존, 딤드, LNB 같은 쉬운 것들부터

포트, 라우터 같은 기술적인 부분들까지

여러분들이 이미 경험해본 일입니다.

게임 개발을 처음 마주쳤을 때 밸런싱, 빌드, QA라는 단어를 익혔고,

이직할 때마다도 그 팀의 용어를 익혔을 것입니다.

새 직무를 배운 게 아니라 새 팀에 온보딩한 거죠.

개발 키워드도 정확히 그 급의 과제입니다.

낯선 직무가 아니라 낯선 팀.

그리고 여러분은 온보딩을 십수 번 해본 사람들입니다.

모르는 키워드가 나오면 어떻게 하냐고요?

그 자리에서 AI에게 물으면 됩니다.

실제로 저는 강의를 만들다가 학생분들이 모를 것 같은 용어가 나와 작업을 멈추고 클로드에게 물었습니다.

"이게 뭐야? 비개발자도 알아듣게 설명해줘."

설명을 확인하고, 내가 아는 것에 대입해 본 다음, 그 다음에 결정합니다.

키워드 사전을 외우고 시작하는 게 아니라, 현장에서 한 개씩 채우면서 갑니다.

온보딩이란 원래 그렇게 하는 거니까요.

정리

• 바이브 코딩의 본체는 요구사항 정의, 스코프 관리, 검토와 피드백입니다. 이것은 기획자와 PM이 이미 가진 능력입니다.
• 코딩은 AI가 합니다.
• 남은 건 키워드 수십 개이고, 그건 새 직무 학습이 아니라 새 팀 온보딩 수준의 과제입니다.

그래서 "누구나 할 수 있다"는 말을 이렇게 고쳐 쓰고 싶습니다.

여러분이 특히 잘할 일인데, 아직 그 팀의 단어를 못 배웠을 뿐이라고요.