기획자가 직접 99개의 서비스를 만들며 배운 것들
원문: 요즘IT — 여행하는 기획자
개요: 이 글이 왜 중요한가
이 글은 단순한 성공 후기가 아니다. ‘코딩 공포증’을 가진 비개발자 기획자가 4개월 동안 99개의 서비스를 혼자 배포하면서 겪은 실험과 실패의 기록이며, 그 과정에서 도출한 AI 시대 기획자의 생존 전략이다. 특히 주목할 점은 이 글의 주인공이 기술을 습득한 것이 아니라, 기술의 한계를 직접 부딪히면서 기획의 본질이 무엇인지를 더 선명하게 깨달았다는 점이다.
바이브 코딩(Vibe Coding)이라는 개념 자체는 2025년 2월 AI 연구자 안드레이 카르파티(Andrej Karpathy)가 처음 제시했다. 그는 이를 “분위기에 완전히 굴복하고, 기하급수적 변화를 받아들이며, 코드가 존재한다는 사실조차 잊어버리는 것”이라고 정의했다. 즉, 구현의 주도권을 AI에게 넘기고 인간은 의도와 방향성에만 집중하는 새로운 개발 방식이다. 이 개념이 등장한 지 1년여 만에 콜린스 사전의 2025년 올해의 단어로 선정되었고, 2026년 현재 개발자의 84%가 AI 도구를 사용하고 있거나 사용할 계획이라는 통계가 나올 만큼 빠르게 주류로 자리 잡았다.
이 흐름 속에서 주목해야 할 것은 바이브 코딩이 단순히 ‘개발자의 생산성 도구’에 머물지 않고, 비개발자 직군까지 서비스 구현의 주체로 끌어들이고 있다는 점이다. 그 최전선에 이 글의 저자인 기획자가 있다.
1장. 코딩 공포증에서 바이브 코딩으로 — 전환의 계기
비개발자의 오래된 좌절
저자는 스스로를 “코딩과 안 맞는 사람”이라고 단정했던 인물이다. 학창 시절 C언어 중간고사 때는 코드 대신 “공부를 소홀히 해서 죄송합니다 교수님”이라는 편지를 시험지에 써낼 정도였고, 학점은 늘 C를 벗어나지 못했다. 당시의 좌절은 단순히 낮은 학점이 아니었다. 동기들은 무언가를 구현해내는데 자신만 아무것도 만들지 못한다는 무력감, 그것이 진짜 상처였다.
이 배경이 중요한 이유는, 저자가 바이브 코딩을 통해 얻은 것이 단순한 생산성 향상이 아니라 오래된 무력감의 해소였기 때문이다. AI가 코딩 장벽을 낮추자, 비로소 자신의 생각을 실현할 수 있다는 감각 자체가 살아났다. 이 경험은 저자 개인의 이야기이면서, 동시에 수많은 비개발자 직군이 AI 코딩 도구를 통해 처음으로 느끼는 해방감이기도 하다.
전환점: 챗봇 서비스 리뷰 현장
전환의 계기는 2025년 11월, 회사에서 챗봇 서비스 개선 업무를 맡으면서 찾아왔다. 개발팀이 이미 완성한 결과물이 임원 보고에서 “가시성이 떨어진다”는 지적을 받았고, 기획자인 저자에게 수정 지시가 내려졌다. 기존 방식이라면 수정 사항을 이미지나 문서로 정리해 다시 설득하는 과정을 거쳤을 것이다. 그러나 저자는 다른 선택을 했다. 직접 바이브 코딩을 배워 동작하는 결과물을 만들어 가져갔다.
결과는 극적이었다. 기획안으로 설득하는 데 2주가 걸리고 수십 번의 임원 리뷰가 필요했던 일이, 동작하는 결과물을 30분 만에 보여주는 것으로 끝났다. “이렇게 바꿔보는 게 어떨까요?”라는 말과 문서보다, “이렇게 동작해요”라고 보여주는 것이 훨씬 강력했다. 서로 다른 상상을 하며 소모되던 논쟁이 사라지고, 눈앞의 결과물을 보며 이야기하는 방식으로 의사결정의 문법 자체가 바뀌었다.
이 경험이 99개 서비스 실험의 시작점이 되었다. 저자는 이후 아이디어가 떠오를 때마다 반복해서 실현했고, 2026년 1월 말까지 총 99개의 서비스를 배포했다.
99개 서비스의 실체
중요한 맥락이 있다. 99개 서비스의 90%는 거창한 사업 아이템이 아니었다. 하루 만에 버려진 ‘일회용 검증 도구’가 대부분이었고, 나머지는 본인과 동료의 시간을 아껴주는 작은 마이크로 서비스였다. 이 구조 자체가 중요한 메시지를 담고 있다. 바이브 코딩의 진짜 가치는 웅장한 서비스를 만드는 것이 아니라, 실패를 극도로 저렴하게 만들어 더 많이, 더 빠르게 시도하게 해준다는 점에 있다.
주요 도구는 제미나이 빌더(Gemini Builder)였으며, 기술 스택은 React, Tailwind CSS, Supabase 조합을 자주 사용했다. 2026년 현재 바이브 코딩 생태계에는 Cursor, Claude Code, Lovable, Replit 등 다양한 도구가 경쟁하고 있으며, 특히 Lovable은 비개발자가 접근하기 가장 쉬운 도구로 평가받는다. 저자는 그 중에서도 웹 기반의 직관적인 인터페이스를 선호했다.
2장. 첫 번째 교훈 — 욕심을 줄이면 핵심이 보인다
‘드림보드’의 기능 과잉 실패
바이브 코딩을 처음 접했을 때 가장 깊이 빠진 함정은 ‘기능 과잉’이었다. 구현 비용이 사실상 0에 수렴하자, 머릿속에 떠오르는 모든 기능을 다 넣고 싶은 충동이 강해졌다. 저자의 표현을 빌리자면, 개발 비용이 없어진다고 해서 사용자가 겪어야 할 복잡함의 비용까지 없어지는 것은 아닌데, 그 사실을 망각한 것이다.
드림보드 프로젝트가 대표적인 실패 사례였다. 저자는 AI에게 아주 구체적이고 정교한 프롬프트를 입력했다.
[실제 사용 프롬프트]
Role: 너는 세계적인 수준의 UX/UI 디자이너이자 프런트엔드 개발자야.
Goal: 나의 꿈과 목표를 시각적으로 관리하는 ‘드림보드’ 웹서비스를 만들어줘.
Design Style: 노션처럼 깔끔하고 여백이 세련된 느낌. 핀터레스트처럼 Masonry Layout 사용.
Core Features: 우측 하단 ‘+’ 플로팅 버튼. 진행률 100%가 되면 Framer Motion으로 폭죽 효과.
Tech Stack: React, Tailwind CSS, Supabase
결과는 놀라웠다. 엔터를 누르자마자 미니멀한 드림보드가 화면에 나타났고, 폭죽 터지는 애니메이션까지 완성되었다. 문제는 그 이후였다. “이걸 매일 쓰게 하려면 감사 일기도 넣어볼까?”라는 생각에 기능을 하나씩 추가하기 시작했고, 서비스는 순식간에 누더기가 되었다. 미니멀한 정체성은 사라지고 정보 구조가 꼬였으며, 무엇보다 서비스가 무엇을 위한 것인지 불분명해졌다.
깨달음: 기능이 아닌 새 서비스를 만든다
이 실패 이후 저자는 방식을 근본적으로 바꿨다. 아이디어가 생기면 기능을 덧붙이는 대신, 새로운 서비스를 만드는 방향을 택했다. 이것이 99개 다작의 핵심 비결이자, 실패를 최소 비용으로 소화하는 방법이 되었다. 하나의 서비스를 완벽하게 만들려는 시도 대신, 각 아이디어를 독립된 단위로 빠르게 실험하고 버리는 방식이다.
이 접근법은 스타트업의 린(Lean) 방법론, 즉 MVP(Minimum Viable Product) 사고방식과 본질적으로 동일하다. 다만 바이브 코딩이 개입하면서 MVP 제작의 시간과 비용이 수 시간 단위로 압축되었다는 점이 다르다. 구현 비용이 0에 수렴할 때, 비로소 기획자는 ‘무엇을 만드는가’보다 ‘왜 만드는가’, ‘누가 쓰는가’라는 본질적인 질문에 집중할 수 있게 된다.
성공 사례: 육아 검진 알리미
이 원칙을 적용한 첫 번째 성공 사례가 ‘육아 검진 알리미’(mysuksuk.com)였다. 동료와 대화하다 우연히 포착한 불편함이 출발점이었다. “또 놓쳤어요. 일일이 육아 건강검진 챙기기 너무 힘들지 않아요?” 엄마 기획자로서의 공감이 서비스의 씨앗이 된 것이다.
서비스의 구조는 단순했다. 아기의 생년월일을 입력하면 1차부터 9차까지의 건강검진 날짜를 자동으로 계산해주고, 각 차수에 맞춰 발달 체크리스트를 제공하는 것이다. 욕심을 부리지 않고 딱 필요한 기능만 프롬프트에 담았고, 1시간도 안 되어 서비스가 완성되어 배포까지 이루어졌다.
기존 프로세스대로라면 기획안 작성, 디자인, 개발 일정 조율에 며칠이 걸렸을 작업이다. 구현 비용이 극도로 낮아지자, 기획자는 기능의 화려함보다 실제 고객의 결핍을 해결하는 데만 온전히 집중할 수 있었다. “실패해도 1시간만 버리면 된다”는 가벼움이 오히려 실행력을 극대화하는 역설이 만들어진 것이다.
3장. 두 번째 교훈 — 기술이 막힐 때, 기획자는 우회로를 뚫는다
카카오톡 연동의 벽
육아 검진 알리미를 배포한 후 남편으로부터 ‘공유 기능’에 대한 피드백이 왔다. 저자는 카카오톡 연동을 시도했다. 그러나 API 키를 발급받아도 연동 테스트는 계속 오류가 났다. 복잡한 DB 설계나 대규모 트래픽 처리와 마찬가지로, 외부 서비스 API 연동은 비개발자인 저자가 바이브 코딩만으로 해결하기에 명확한 기술적 한계였다.
이 시점에서 저자의 선택이 중요했다. 기술적 문제를 어떻게 뚫을 것인가를 고민하는 대신, 한 발짝 물러서서 원래의 목적을 다시 생각했다. 남편이 원했던 것은 ‘카카오톡 연동’이 아니라 ‘알림을 받는 것’이었다. 카카오톡은 수단이고 알림은 목적이다. 이 구분이 명확해지자 해결책은 단순해졌다. 이메일 알림으로 우회하면 된다.
역설적 통찰: 기술 미숙함이 오히려 강점이 된다
이 경험에서 저자가 끌어낸 통찰은 역설적이다. 코딩 실력이 부족했기 때문에, 역설적으로 기술에 매몰되지 않을 수 있었다. 전문 개발자였다면 어떻게든 API를 연동하는 기술적 해법을 찾으려 더 오래 붙잡고 있었을 것이다. 그건 개발자의 전문성이자 강점이다. 그러나 비개발자인 기획자는 기술적 장벽 앞에서 “이게 정말 필요한가?”를 질문하며 문제 자체를 재정의했다.
이것은 단순한 포기가 아니다. 도구에 얽매이지 않고 목적을 향한 가장 빠른 우회로를 찾아내는 능력, 그것이 AI 시대 기획자의 핵심 역량이라는 선언이다. 기술 장벽이 낮아질수록 오히려 ‘무엇을 만들 것인가’와 ‘왜 만들 것인가’의 판단력이 더 중요해진다. 2026년 현재 바이브 코딩 전문가들도 같은 결론에 도달하고 있다. 구현의 장벽은 낮아졌지만, 그만큼 더 많은 맥락 이해와 구조적 판단이 요구되는 환경으로 바뀌었다는 것이다.
4장. 세 번째 교훈 — 만드는 것은 쉽다, ‘누가 쓰는가’가 진짜 문제다
습관 트래커: 타깃 없는 서비스의 한계
저자가 다음으로 만든 것은 습관 트래커였다. 어릴 때 칭찬 스티커를 모으듯, 일정한 행동을 할 때마다 스티커를 쌓아가는 서비스였다. 바이브 코딩으로 배포까지는 수월했다. 저자 본인에게는 분명히 유용했다. 그러나 근본적인 문제가 있었다. 나만 쓰는 서비스였다. 지인에게 배포해도 한계가 있었고, 알릴 방법이 없었다.
이 경험은 매우 중요한 교훈을 담고 있다. 바이브 코딩이 구현의 문턱을 낮췄다고 해서 ‘사용자를 찾는 문제’까지 해결되는 것은 아니다. 오히려 구현이 쉬워질수록, 만든 후에야 “이게 누구를 위한 것인가”를 깨닫는 경우가 많아진다. 이것은 기술 장벽이 낮아진 시대의 새로운 함정이다.
타깃 재정의: ‘글 쓰는 사람을 위한 습관 트래커’로
저자는 기획을 수정했다. 단순히 ‘습관을 기록하는 앱’에서 ‘글 쓰는 사람을 위한 습관 트래커’로 타깃을 좁히고 기능을 재설계했다. 글 쓰는 사람에게 필요한 것은 체크박스가 아니라, 한 줄을 쓰도록 격려해주는 동료 같은 반응이라고 봤다. 그래서 AI에게 구체적인 페르소나를 부여했다.
[변경된 프롬프트]
타깃은 글감이 안 떠올라 괴로운 작가야. 사용자가 한 줄을 쓰고 저장을 누르면 너는 그 문맥을 읽고 동기부여를 해줘. 때로는 진지하게, 때로는 아재 개그를 섞어서 웃게 만들어줘.
이 변경이 서비스의 성격을 완전히 바꿨다. 단순한 텍스트 생성기가 아니라, 썰렁한 농담으로 긴장을 풀어주는 ‘동료’가 생긴 것이다. 저자는 여기서 중요한 원칙을 발견했다. 기능은 AI가 만들 수 있지만, 서비스의 톤과 성격과 관계맺음의 방식은 기획자가 정의해야 한다는 것이다.
삭막한 습관 트래커에 ‘장난기 넘치는 페르소나’를 입히자, 코드는 단순한 프로그램을 넘어 사용자와 관계를 맺는 대상이 되었다. 사용자를 머물게 하는 것은 뛰어난 기능이 아니라 관계의 힘이었다. 이 통찰은 서비스 기획의 오래된 진리—사용자는 제품을 쓰는 것이 아니라 경험을 느낀다—와 정확히 맞닿는다.
5장. 네 번째 교훈 — 실패 비용이 0이 될 때 얻을 수 있는 것
매몰비용 없는 피벗
만약 저자가 각각의 서비스를 3개월씩 공들여 만들었다면 어떻게 되었을까? 투자한 시간과 노력이 아까워서 방향을 바꾸지 못했을 것이다. 이것이 ‘매몰비용의 함정’이다. 바이브 코딩은 이 함정을 해소해 준다. 실패 비용이 1시간 정도로 극소화되면, 방향 전환에 대한 심리적 저항이 사라진다.
이것은 단순한 효율성의 문제가 아니다. 의사결정의 품질 자체가 달라진다. ‘이미 많이 만들었으니까’라는 이유로 잘못된 방향을 고집하는 대신, 언제든 새로운 관점으로 문제를 바라볼 수 있는 유연성이 생긴다. 저자는 이를 통해 ‘만드는 방법’을 고민하는 대신, ‘누가 왜 써야 하는가’라는 기획의 본질적인 질문에 더 깊이 집중하게 되었다고 말한다.
AI 시대 기획자의 무기: 생각의 깊이
99개의 서비스를 통해 저자가 배운 것은 코딩 기술이 아니었다. 기술 장벽이 사라진 시대에 기획자가 집중해야 할 것은 구현 가능성이 아니라 ‘해결해야 할 문제의 정의’라는 점이다. 문서로 설득하는 대신 결과물로 증명하고, 거창한 계획 대신 빠른 실패를 통해 정답을 찾아가는 과정. 저자는 이것이 AI 시대 기획자의 방식이라고 말한다.
6장. “기획자는 여전히 필요하다” — AI가 대체할 수 없는 것
냉소적 질문에 대한 답
AI가 코드도 짜고 아이디어도 내는데, 이제 기획자는 필요 없는 것 아니냐는 질문이 있다. 저자는 99번의 경험을 바탕으로 단호하게 아니라고 답한다.
그 근거는 구체적이다. AI는 카카오톡 연동이 기술적으로 어려울 때 그것을 과감히 빼고 이메일로 우회하는 판단을 하지 못했다. AI는 습관 트래커에 아재개그 페르소나를 입혀 서비스의 온도를 조정하는 결정을 하지 못했다. 기술적 논리로 설명되지 않는 이런 판단과 온기는 여전히 기획자만이 불어넣을 수 있는 영역이다.
AI가 대체하지 못하는 기획자의 역할
저자가 경험에서 도출한 기획자 고유의 역할을 정리하면 다음과 같다.
첫째, 목적과 수단을 구분하는 능력이다. 카카오톡은 수단이고 알림은 목적이다. AI는 수단을 구현하지만, 수단과 목적을 구분하고 더 나은 수단을 찾는 것은 기획자의 판단이다. 둘째, 서비스의 톤과 성격을 정의하는 역할이다. AI가 기능을 만들어도, 그 서비스가 사용자와 어떤 관계를 맺을 것인가를 설계하는 것은 기획자다. 셋째, 문제를 재정의하는 능력이다. 기술 장벽 앞에서 ‘어떻게 뚫을까’를 묻는 대신, ‘이게 정말 필요한가’를 묻고 문제 자체를 재설계하는 것은 기획자만의 영역이다. 넷째, 사용자 공감에서 출발하는 아이디어 발견이다. 육아 검진 알리미가 동료의 불편함에서 시작되었듯, 진짜 결핍을 포착하는 촉수는 현장에 있는 사람만이 가질 수 있다.
7장. 현재 바이브 코딩의 생태계와 한계
2026년 주요 바이브 코딩 도구들
2026년 현재 바이브 코딩 생태계에서 주목받는 도구들은 다양하다. Cursor는 VS Code 생태계를 기반으로 레포지토리 전체를 인덱싱하여 기능 단위로 작업을 처리하며, 가장 많이 사용되는 도구 중 하나다. Claude Code는 터미널 기반으로 동작하며 2025년 기준 가장 뛰어난 성능을 보여준다고 평가받는다. Lovable은 텍스트를 입력하면 브라우저에서 바로 결과물을 확인할 수 있어 비개발자가 접근하기 가장 쉬운 도구로 꼽힌다. Gemini Builder는 저자가 주로 시작점으로 사용한 도구로, Google의 Gemini 모델을 기반으로 한 웹앱 생성 도구다.
바이브 코딩의 명확한 한계
한편 바이브 코딩의 한계도 분명히 존재한다. 저자가 직접 경험한 것처럼, 외부 API 연동이나 복잡한 DB 설계, 대규모 트래픽 처리는 여전히 바이브 코딩만으로 해결하기 어렵다. 보안 측면에서도 심각한 취약점이 나타날 수 있는데, 데이터베이스를 암호화하지 않거나 쿼리 엔드포인트를 노출시키는 사례가 실제로 발생했다.
더 근본적인 한계는 생산성의 착시에 있다. 2025년 7월 AI 평가 기관 METR의 무작위 대조 실험에서, 숙련된 오픈소스 개발자들이 AI 코딩 도구를 사용했을 때 오히려 19% 느려졌다는 결과가 나왔다. 개발자들은 스스로 24% 빨라졌다고 예측했고 실험 후에도 20% 빨라졌다고 믿었지만, 실제 측정 결과는 정반대였다. AI가 코드를 빠르게 작성해주지만, 그 코드를 검증하고 수정하고 이해하는 데 드는 시간이 오히려 늘어난 것이다.
이 연구는 바이브 코딩이 ‘프로토타입 검증’과 ‘아이디어 실현’에는 강력하지만, 복잡한 프로덕션 코드에서는 다른 접근이 필요함을 시사한다. 저자의 99개 서비스 실험이 효과적이었던 이유도 바로 이 점을 정확히 이해하고 있었기 때문이다. 대규모 복잡한 시스템이 아닌, 빠른 검증과 마이크로 서비스에 집중했다.
8장. 시사점 — AI 시대에 기획자는 어떻게 진화해야 하는가
문서에서 실행으로
저자의 경험에서 가장 강렬한 메시지는 “기획자의 무기는 문서가 아니라 실행”이라는 선언이다. 기획안으로 2주 동안 설득하던 것이 동작하는 프로토타입 30분으로 대체될 수 있다면, 기획자의 시간 배분과 역량의 중심이 바뀌어야 한다. 아이디어를 정교한 문서로 표현하는 능력보다, 빠르게 가설을 실행으로 옮기고 검증하는 능력이 더 중요해진다.
빠른 실패를 두려워하지 말 것
99개 중 90%가 버려진 일회용 검증 도구였다는 사실은 실패를 자산으로 만드는 태도를 보여준다. 단 하나의 완벽한 기획을 오래 갈고 닦는 대신, 많은 가설을 빠르게 실험하고 살아남는 것에 집중하는 방식이다. 이것은 스타트업의 린 방법론을 넘어, AI 도구가 구현 비용을 극소화한 시대에 맞는 새로운 기획 방법론이다.
목적과 수단을 분리하는 사고력
카카오톡 연동 실패 사례가 보여주듯, 도구에 집착하지 않고 목적을 끊임없이 재확인하는 능력이 AI 시대 기획자의 핵심 역량으로 부상하고 있다. 구현이 쉬워질수록, 도구에 매몰될 위험도 커진다. 항상 “이것이 사용자가 진짜 원하는 것인가”를 물어야 한다.
서비스의 ‘온도’를 설계하는 역할
AI는 기능을 만들지만, 서비스가 사용자와 어떤 감정적 관계를 맺을 것인가는 기획자가 정의해야 한다. 습관 트래커에 아재개그 페르소나를 입히는 결정, 이것이 기획자만이 할 수 있는 일이다. 알고리즘은 최적화하지만 온기는 기획하지 못한다. 사람을 머물게 만드는 것은 탁월한 알고리즘이 아니라, 그 서비스가 자신을 이해한다는 느낌, 즉 관계의 힘이다.
결론: 생각의 깊이가 서비스의 깊이를 만든다
저자의 이야기는 단순히 “기획자도 이제 코딩을 배워야 한다”는 메시지가 아니다. 오히려 정반대에 가깝다. AI가 코딩을 담당하게 되면서, 기획자는 비로소 기획의 본질—무엇을 만들 것인가, 누구를 위해 만들 것인가, 왜 지금 이것이 필요한가—에만 집중할 수 있게 되었다는 이야기다.
C언어 시험에 편지를 썼던 그 기획자가, 4개월 만에 99개의 서비스를 세상에 내놓았다. 코딩 실력이 늘어서가 아니라, 코딩이 더 이상 장벽이 아닌 도구가 된 세상에서 기획의 본질에 더 집중할 수 있었기 때문이다.
AI 시대의 기획자에게 가장 중요한 것은 코드 몇 줄이 아니라, 던지는 질문의 깊이다. 그 질문의 깊이가 곧 서비스의 깊이를 만든다. 그것이 99개의 실험이 남긴 가장 단단한 교훈이다.
참고 자료
- 원문: 기획자가 직접 99개의 서비스를 만들며 배운 것들 — 요즘IT
- 바이브 코딩 정의: Andrej Karpathy, Twitter, 2025년 2월 3일
- 바이브 코딩 나무위키
- 2026 바이브 코딩 툴 5가지 추천 — 코드트리 블로그
- 8년차 AI 엔지니어는 왜 바이브코딩을 포기했나 — NDS Cloud Tech Blog
- METR 연구: 숙련 개발자 AI 도구 사용 시 생산성 19% 감소 (2025년 7월)
- 한컴테크: AI와 함께하는 소프트웨어 개발 — 바이브 코딩
작성일: 2026-03-11