나는 사실 코딩 공포증이 있었다. 학교 다닐 때 c언어 과목 학점은 늘 C였다. 코딩을 싫어하고 재미도 못 느꼈다. 학교 다닐 때 코딩 중간고사는 구구단을 짜봐라 이런 내용으로 어렴풋이 기억난다. 그럼 난 코드를 이해하는 대신 암기를 하며 또각또각 글자를 쓰곤 했다. 그렇지만 언제나 학점은 c였고 나는 코딩과 정말 안 맞는 사람이라고 스스로를 단정했다.

그러던 세상이 천지개벽했다. 말만 하면 알아서 코딩을 해주는 시대로 접어들고 있다. 기획자인 나는 AI를 통해 바이브 코딩을 접하고 나니 내 생각들이 실현되는 과정이 너무 재미있다. 좋은 점은 점점 코딩 공포증이 사라지고 있다는 점이다. 나의 두려움 대상이 아니라 내 생각을 실현해 줄 또 다른 도구로서 코딩을 바라보는 중이다.

이 변화가 업무에 적용된 건 4개월 전이었다. 작년 11월 회사 업무로 챗봇 서비스를 만들어야 했다. 이미 개발팀에서 작업을 다 마친 뒤 임원 보고를 했지만 가시성이 떨어지고 강조할 부분이 잘 안 보이는 문제가 있었다. 곧 이미 개발된 작업물을 다시 나에게 수정하라는 지시사항이 내려왔고 기획자로서 고민이 되었다. 그냥 이미지로 수정해서 보여주느니 동작되는 걸 직접 보여줘야겠다고 생각했다. 그래서 뚝딱뚝딱 바이브 코딩을 배우게 되었고 직접 수정해 가져갔다.

반응은 솔직히 좀 놀랬다. "이렇게 바꿔보는 게 어떨까요?"라는 말이나 문서보다 "이렇게 동작해요."라고 보여주니 설득의 시간이 획기적으로 단축되었다. 서로 다른 상상을 하며 소모되던 논쟁이 사라졌다. 눈앞의 결과물을 보며 이야기하니 "왜 진작 처음부터 기획자를 안 붙였냐. 역시."라는 말이 나왔다. 그 경험 이후 나는 아이디어가 떠오를 때마다 반복해서 실현했고 지난 1월 말까지 총 99개의 서비스를 배포했다.

물론 99개가 거창한 사업 아이템은 아니다. 90%는 하루 만에 버려진 '일회용 검증 도구'였고 나머지는 나와 동료의 시간을 아껴주는 '마이크로 서비스'였다. 하지만 이 과정에서 얻은 것은 명확하다. 의사결정 비용이 '0'에 수렴한다는 것이다. 단 한 사람의 개발자 없이 복잡한 코드는 AI에게 맡기고, 오직 문제 해결에만 집중해 본 99번의 실험 기록을 남긴다.

욕심을 줄이면 핵심이 보인다

바이브 코딩을 처음 접했을 때 가장 많이 빠졌던 함정이 '기능 과잉'이었다. 개발 비용이 들지 않으니 머릿속에 생각나는 모든 것들을 다 넣고 싶어졌다. 나의 야심작 드림보드가 대표적인 실패 사례다. 나는 AI에게 작업 지시서를 내리듯 아주 구체적인 프롬프트를 입력했다.

[실제 입력한 프롬프트]
Role: 너는 세계적인 수준의 UX/UI 디자이너이자 프런트엔드 개발자야.
Goal: 나의 꿈과 목표를 시각적으로 관리하는 '드림보드' 웹서비스를 만들어줘.
Design Style: 노션처럼 깔끔하고 여백이 세련된 느낌. 딱딱한 표 대신 핀터레스트처럼 벽돌 쌓기 형태의 'Masonry Layout'을 사용해 줘.
Core Features: 우측 하단 '+' 플로팅 버튼으로 빠른 추가. 진행률이 100%가 되면 'Framer Motion'을 활용해 축하 폭죽 효과를 터뜨려줘. (이게 핵심이야, 도파민 트리거가 필요해!)
Tech Stack: React, Tailwind CSS, Supabase

결과는 놀라웠다. 엔터를 누르고 얼마 지나지 않아 내 머릿속의 막연한 드림보드가 모니터 위에 짜잔하고 나타났다. 미니멀한 드림보드라니. 폭죽이 터지는 애니메이션까지 구현되었다. 문제는 그다음이었다. "어? 이걸 매일 쓰도록 하려면.... 감사 일기 같은 것도 넣어볼까?" 나는 즉시 감사 일기 탭을 추가하고 기능을 덧붙였다. 서비스는 금방 누더기가 되었다. 미니멀은 온데간데 사라지고 정보 구조는 꼬여버렸다. 무엇보다 서비스의 정체성이 흐려졌다. 화면을 보면서 느낀 점은 코딩 비용이 0이라고 해서 사용자가 겪어야 할 복잡함의 비용까지 0이 되는 건 아니구나라는 점이었다.

그 이후 방식을 아예 바꿨다. 아이디어가 생기면 기능을 덧붙이는 대신 새 서비스를 만드는 방향을 택했다. 그게 99개 다작의 비결이자 실패를 최소 비용으로 소화하는 방식이 되었다. 이후 바이브 코딩으로 만든 서비스는 '육아 검진 알리미'였다. 동료와 대화하며 우연히 포착한 불편함이었다.

"또 놓쳤어요. 일일이 육아 건강검진 챙기기 너무 힘들지 않아요?"

엄마 기획자로서의 공감이 시작이었다. 육아 건강검진 서비스는 간단했다. 아기의 생년월일을 입력하면 자동으로 건강검진 날짜를 계산해 주는 것이다. 1차부터 9차 건강검진까지 자동으로 계산되면서 각 차수에 맞춰, 발달 정도를 스스로 체크할 수 있는 서비스였다. 욕심을 부리지 않고 딱 필요한 기능만 프롬프트로 입력하니 1시간도 안 돼서 서비스가 뚝딱 만들어졌다. 내친김에 배포까지 해서 남편에게 공유했다.

기존 프로세스였다면 기획안 쓰고, 디자인하고, 개발 일정 잡느라 며칠이 걸렸을 일이다. 하지만 '구현의 비용'이 0에 수렴하자 나는 '기능의 화려함'보다 '고객(나와 동료)의 결핍'을 해결하는 데에만 온전히 집중할 수 있었다. 실패해도 1시간만 버리면 된다는 가벼움이 오히려 실행력을 극대화했다.

기술이 막힐 때, 기획자는 '우회로'를 뚫는다

남편이 배포한 서비스를 이용하면서 '공유' 기능이 있으면 좋겠다는 피드백을 줬다. 내친김에 카카오톡 연동을 해보려고 했다. 하지만 외부 서비스 연동부터 쉽지 않았다. 카카오톡 연동을 위해서는 API 키를 받아야 하는데, 일단 키를 아무리 발급받아도 연동 테스트는 계속 오류가 발생했다. 비개발자인 내가 해결하기엔 기술적 장벽이 높았다. 복잡한 DB 설계나 대규모 트래픽 처리와 같은 기능 역시 바이브 코딩으로 한계가 있었다.

여기서 기획자의 판단이 중요했다. 이 서비스의 목적을 다시 한번 생각해 보았다. 남편이 원한 건 '카카오톡' 자체가 아니라 '알림을 받는 것'이었다. 나는 과감히 카카오톡을 포기하고 이메일 알림으로 우회했다.

전문 개발자였다면 어떻게든 API 키를 연동해 기술적인 문제점을 찾아냈을 것이다. 그건 개발자만이 할 수 있는 전문적인 능력이다. 하지만 비개발자인 나는 그럴 능력이 부족했다. 대신 '목적'을 다시 생각했다. 남편에게 중요한 건 '카카오톡'이 아니라 '알림' 그 자체였으니까. 나는 빠르게 기술적 씨름을 멈추고 구현이 쉬운 이메일 알림으로 경로를 틀었다. 이것이 내가 깨달은 AI 시대의 기획력이다. 코딩 실력이 부족했기에 역설적으로 기술에 매몰되지 않을 수 있었다. 기술적 장벽 앞에서 '어떻게 뚫을까'를 고민하는 대신, '이게 정말 필요한가?'를 질문하며 문제 자체를 재정의했기 때문이다. '카카오톡'이라는 도구에 얽매이지 않고 목적을 향한 가장 빠른 우회로를 찾아내는 감각이 점점 내가 키워야 할 무기이지 않을까라는 생각을 해보았다.

만드는 것은 쉽다, '누가 쓰는가'가 진짜 문제다

바이브 코딩은 빠르게 테스트하기 위한 용도로 활용하면 매우 좋다. 나는 최근에 습관 트래커를 구현했다. 어렸을 때 잘하면 칭찬 스티커를 받아서 유지하듯 나 스스로 어떤 일을 하면 스티커를 모아가는 프로젝트로 기획했다. 바이브 코딩으로 서비스 배포까지는 수월했다.

무엇보다 나에게 매우 유용한 서비스였다. 회사에서 하는 대부분의 서비스가 최종 고객의 반응까지 알아보기가 어려운 구조였다. 하지만 바이브 코딩으로 만든 서비스들은 그냥 내가 만들고 배포하면 끝이라서 반응도 빨랐다. 문제는 서비스 자체는 적어도 나에게만큼은 유용했지만, 문제는 나만 쓰는 게 문제였다. 즉 알릴 길이 없었다. 내가 지인에게 배포해도 한계가 있었다.

나는 다시 기획을 수정했다. 단순히 습관을 기록하는 게 아니라 '글 쓰는 사람을 위한 습관 트래커'로 타깃을 좁히고 기능을 변경했다. 글 쓰는 사람에게 필요한 건 체크박스가 아니라 한 줄을 쓰게 만드는 동료 같은 반응이라고 봤다. 그래서 AI에게 페르소나를 부여했다.

[변경 프롬프트]
타깃은 글감이 안 떠올라 괴로운 작가야. 사용자가 한 줄을 쓰고 저장을 누르면 너는 그 문맥을 읽고 동기부여를 해줘. 때로는 진지하게 때로는 아재 개그를 섞어서 웃게 만들어줘.

그 순간 서비스가 달라졌다. 단순한 텍스트 생성기가 아니라 썰렁한 농담으로 긴장을 풀어주는 '동료'가 생긴 것이다. 습관 생성기에 대한 기능은 AI가 만들지만, 서비스의 톤과 성격은 기획자가 잡아줘야 한다는 생각을 했다. 삭막한 습관 트래커에 '장난기 넘치는 페르소나'를 입히자, 비로소 코드는 단순한 프로그램을 넘어 사용자와 관계를 맺는 대상이 되었다. 사용자를 머물게 하는 건 뛰어난 기능이 아니라 바로 그 관계의 힘이었다.

실패 비용이 0이 될 때 얻을 수 있는 것

만약 내가 만든 여러 가지 서비스를 3개월 동안 거창하게 만들었다면? 아까워서라도 방향성을 우회하지 못했을 것이다. 하지만 바이브 코딩은 '실패 비용'을 확연히 낮춰주었다. 덕분에 나는 '만드는 방법'을 고민하는 대신, '누가 왜 써야 하는가'라는 기획의 본질적인 질문에 더 깊이 파고들게 되었다.

질문의 무게를 견디는 기획자 99개의 서비스를 만들며 배운 것은 코딩 기술이 아니었다. 기술 장벽이 사라진 시대, 기획자가 집중해야 할 것은 '구현 가능성'이 아니라 '해결해야 할 문제의 정의'라는 점이다. 문서로 설득하는 대신 결과물로 증명하고, 거창한 계획 대신 빠른 실패를 통해 정답을 찾아가는 과정. AI 시대의 기획자는 책상 위가 아니라, 동작하는 서비스 위에서 답을 찾아야 한다. 우리가 던지는 질문의 깊이가 곧 서비스의 깊이가 될 테니까.

C언어 중간고사 시험을 볼 때면 하얀 종이 한편에 코드 대신 편지를 썼다. '공부를 소홀히 해서 죄송합니다 교수님...'이라며 멘트를 썼던 기억이 난다. C언어 학점이 C가 되어 집으로 돌아오면 아빠는 나를 불러 "장학생은 기대도 안 하는데 C는 너무하지 않냐?"라며 하셨던 말씀도 생각난다. 내가 그 시기 힘든 점은 단순히 C 학점이 아니라, 동기들은 재미있는 뭔가를 다 구현하는데 나 혼자 아무것도 하지 못하는 무력감이었다.

세월이 흘러 바이브 코딩이 되면서 C언어를 못 하던 나도 뭔가를 실현할 수 있게 되었다. 그것도 마음껏 원하는 대로 실현할 수 있다는 감각이 생겼다. 누군가는 묻는다. AI가 코드도 짜고 아이디어도 내는데, 이제 기획자는 필요 없는 거 아니냐고. 냉소적인 질문 앞에서 나는 99번 바이브 코딩을 통해 서비스를 구현한 경험을 담아 단호하게 '아니요'라고 답하고 싶다.

AI는 효율적인 코드를 짤 수는 있어도 카카오톡 연동을 과감히 빼거나, 아재개그 같은 피드백을 넣어 서비스의 온도를 조정하는 결정을 하진 못했을 거다. 기술적 논리로는 설명되지 않는 판단과 온기는 여전히 기획자만이 불어넣을 수 있는 영혼이다.

모든 것이 빠르고 실현 가능한 시대다. 마음껏 실현하는 시대일수록 흔들리지 않는 중심을 가진 기획자가 더 특별해진다. 기술의 파도에 휩쓸리지 않고 깊은 생각으로 서비스의 가장 중요한 핵심을 끝까지 밀어붙이는 힘이 중요해진다. 나는 여전히 흔들리지 않는 기획자가 되기 위해 답을 찾아 나가는 중이다. 이때 무기는 코드 몇 줄이 아니라 생각의 깊이면 좋겠다. 그 무기를 갈고 닦는 나의 여정은 99개의 서비스를 지나 이제 막 시작되었다.