지난 글에서 기획자와 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가 합니다.
• 남은 건 키워드 수십 개이고, 그건 새 직무 학습이 아니라 새 팀 온보딩 수준의 과제입니다.

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

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

Know-how의 시대가 저물고
What & Why를 정의하는 시대가 온다.

개발자의 시대

 2015년부터 시작된 개발자 붐이 갑작스레 막을 내리고 있습니다. 그 당시 게임업계 대기업 3사(3N)의 연봉인상 릴레이부터 네카라쿠배까지 경험했던 저로서는 놀라울 따름입니다. 2년전 쯤 딥러닝을 통한 LLM의 등장을 단순한 가십거리로 치부했던 2년 전의 판단은 보기 좋게 빗나갔습니다. 기술의 발전 속도는 우리의 상상력을 항상 앞서갑니다.

 2025년, 바이브 코딩을 처음 접해봤습니다. 바이브코딩을 통해 백엔드, 프론트엔드 기능도 작성해보고 언리얼엔진 코드도 작성해보았습니다. 그리고 전체적으로 훑어봤죠. 프롬프트와 테스트케이스만 잘 꼬집어주면 흠잡을 구석이 없었습니다. 2026년을 시작하는 지금도 얼마나 빠른 속도로 발전하고 있을지 모르겠습니다.

 그것을 보면서 저는 시니어 개발자에서 개발 AI 시대의 새로운 아키텍트를 양성하는 교육자로 전향하게 되었습니다. 개발 교육으로 전향한 저로써 왜 이런 선택을 했는지, 그리고 제가 생각하는 앞으로의 미래를 말씀드려보겠습니다.

지식의 보편화와 상향 평준화

 과거에는 전문가가 안 된다고 하면 안되는 세상이었습니다. 개발자가 구현 안 된다고 하면 개발이 안되는 것이었고, 디자이너가 안어울린다고 하면 디자인되지 않았습니다. 하지만 AI가 디자인도 뽑아주고, 개발하는 세상이 도래했습니다. 심지어 사소한 의학지식이나 법률지식은 AI를 통해 찾아볼 수 있게 되었습니다. 간단한 레벨은 AI가 해줄 수 있고, AI가 발전함에 따라 그 레벨이 점점 올라갈 것이라는 점입니다.

 물론 인터넷이 등장하고, 유튜브 영상이 범람하면서 방구석 전문가라는 타이틀도 생겨났습니다. AI 또한 마찬가지로 할루시네이션이 있고, 할루시네이션을 극복한다고 하더라도 전문가를 통해 정보를 선별하거나 적어도 프롬프트를 작성 및 개선하는 노력이 필요할 것입니다.

 요약하자면 지식이 보편화되었고 그로 인해 사람들의 능력도 상향 평준화 된다는 것 입니다. 전문가가 되는 난이도는 낮아지고, AI 활용 능력은 중요해지죠. 제가 집중했던 포인트는 AI를 통한 업무 효율화는 마치 IT의 개발 Workflow와 비슷하다는 부분이었습니다. 이 것을 깨닫는데에 다양한 도메인(엔터테인먼트, 세무/회계, 자율주행)에서 개발해본 경험이 많은 도움을 주었습니다.

개발 Workflow
[요구사항 분석 => 설계 => 코드 구현 => 테스트/검증 => 배포]

AI를 통한 업무 효율화
[요구사항 분석 => 설계 => 프롬프트 작성 => 테스트/검증 => 사용]

 우리는 이것을 코딩의 종말이라 부르지만, 저는 이를 구현의 민주화(Democratization of Implementation)라고 정의하고 싶습니다. 이제 '만드는 기술'이 권력이던 시대는 끝났습니다.

어떻게(How)보다는 왜(What & Why)

 How(어떻게 구현하는가)를 아는 전문가의 시대는 저물고 있습니다. 이제 그 영역은 AI가 더 빠르고 정확하게 수행합니다. 앞으로 살아남는 개발자는 Why(왜 만들어야 하며, 무엇이 문제인가)를 정의할 수 있는 '설계자'뿐입니다. 그리고 우리에게는 전문가로 성장중인 AI가 주어졌습니다. AI는 시키는 대로만 합니다. 할루시네이션 또한 프롬프트에서 비롯하여 많이 발생하게 됩니다. 이것은 무엇을 의미할까요? AI에게 정확한 지시를 내리는 것이 중요하니 파이프라인에 대한 이해가 중요해질 것입니다. 각 파이프라인의 시작은 무엇을 만들지 정의하고 끝은 왜 그것을 만드는지 정의하는 것으로 정리될 것 입니다.

 그렇게 "현장 감독관"이 되실 많은 사람들을 교육하는 교육자가 되려고 마음 먹었습니다. 아무래도 한국은 90~00년대에 주입식 교육이 강했고 획일화 된 과정을 거쳤다보니 이런 부분에 약한 것 같습니다. 그래서 다양한 도메인에서 쌓은 파이프라인 설계 지식으로 이끌어갈 수 있지 않나 생각해봅니다.

끝으로

 AI가 매트릭스를 넘어서든 아니든 중요하지 않습니다. 중요한 건 '핸들'을 쥔 사람은 여전히 인간이어야 한다는 점입니다. 제가 왜 국비지원 과정에서 'Cursor'를 적극적으로 사용했는지, 그 구체적인 이야기를 다음 편에서 들려드리겠습니다.

다음글