요즘 AI에게 시켜서 홈페이지나 앱을 만드는 것을 바이브 코딩이라고 부릅니다. 그리고 제가 보기엔, 10명이 시작하면 9명은 끝을 못 봅니다. 통계 기관의 숫자가 아니라 직접 만들고 출시하고 상담하면서 쌓인 현장 감각입니다만, 아마 시작해 보신 분이라면 짚이는 데가 있으실 겁니다. 첫날에는 '어, 이게 되네?' 하고 신났는데, 사흘만 지나면 손이 안 가고, 폴더만 남긴 채 조용히 접게 되는 경험 말입니다.
이 글의 결론을 먼저 말씀드리면, 멈추신 것은 실력 문제가 아닙니다. 진짜 벽은 전부 만들기 뒤에 서 있기 때문입니다. 이 글은 그 벽을 마음·기술·서류·빌더의 딜레마라는 4개의 지도로 그리고, 벽마다 바로 쓸 수 있는 해결책을 하나씩 짝지어 놓았습니다.
아래 영상에 전체 내용이 담겨 있고, 글은 영상의 순서 그대로 정리했습니다.
만드는 데 3, 만들고 난 다음이 7
먼저 수치 하나부터 보여드리겠습니다. 저희가 코딩 없이 만든 차트 공부 앱을 애플·구글 심사까지 통과시키면서 실측한 시간 정산인데, 만들기에 들어간 시간이 3이라면 만들고 난 다음이 7이었습니다. 그 7의 내역이 약관, 개인정보 처리방침, 스크린샷 규격, 심사 제출, 대기, 구글의 여러 단계, 검색 등록입니다. 전부 코딩이 아니라 만들기 밖의 일들입니다.
그래서 이 글은 벽을 네 개로 나눕니다. 마음의 벽, 기술의 벽, 서류의 벽, 그리고 빌더의 딜레마입니다. 하나씩 넘는 법까지 같이 갑니다.
마음의 벽 — 사흘이 지나면 손이 안 갑니다
첫 번째 벽은 기술이 아니라 마음입니다. 처음엔 AI가 눈앞에서 뚝딱 만들어 주니까 재밌습니다. 문제는 그 열정이 시간이 지날수록 줄어드는 게 당연하다는 점입니다. 내가 가진 현재 상태와 이루고 싶은 원대한 목표 사이의 간격이 좁혀지지 않을수록 뇌는 실망하고, 사흘 뒤에는 손이 안 가고, 일주일 뒤에는 폴더가 잠듭니다. 의지가 아니라 목표의 크기 문제입니다.
해결은 결승선을 사흘 안으로 옮기는 것입니다. 사흘 안에 '링크를 보낼 수 있는 상태'를 1차 결승선으로 잡고, 메인 기능 딱 하나만 넣습니다. 나머지는 업데이트로 갑니다. 저희 차트 앱도 60점짜리로 먼저 냈고, 지금도 스토어에 살아 있습니다. 근거도 있습니다. 하버드 비즈니스 리뷰에 실린 연구(Amabile & Kramer, 2011)가 직장인 일지 약 12,000건을 분석했는데, 동기를 가장 크게 끌어올리는 단 하나의 요인은 '의미 있는 일에서의 작은 진전'이었습니다.
두 번째 마음의 벽은 비교입니다. 만들다가 SNS를 보면 나랑 비슷한 아이디어를 더 쿨한 도구로 잘하고 있는 사람이 보이고, 내 방법이 틀린 것 같아 갈아타고 싶어집니다. 그런데 도구를 바꿀 때마다 배우는 시간이 다시 시작됩니다. 심리학 연구(Rubinstein·Meyer·Evans, APA, 2001)가 측정한 작업 전환의 비용은 생산 시간 최대 40% 손실입니다. 해결은 단순합니다. 완주 전까지 도구를 바꾸지 않는 것. 새 도구는 '다음 프로젝트 목록'에 적어 둡니다. 어차피 쓰는 사람은 여러분이 뭘로 만들었는지 모르고, 관심도 없습니다.
세 번째는 완벽주의입니다. 60점으로 내겠다고 다짐해 놓고 '이것만 바꾸고, 폰트만 바꾸고, 다음 주에 올려야지'가 무한 반복됩니다. 저도 유튜브 영상 하나를 붙잡고 2주를 못 올린 적이 있습니다. 해결은 공개 기준을 완벽에서 '작동'으로 바꾸는 것입니다. 돌아가면 공개합니다. 공개 전 딱 한 단계만 둡니다. 지인 세 명에게 돌려 보고, 크리티컬한 문제가 없으면 올립니다. 다듬기는 공개 후에도 할 수 있습니다. 어차피 공개해서 욕을 먹는다는 건 내 결과물에 관심이 있다는 뜻이고, 혹평은 개선으로 호평으로 바꿀 수 있습니다. 무관심이 더 큰 문제입니다.
기술의 벽 — '해줘'만으로는 안 되는 순간이 옵니다
코딩을 안 해도 되는 줄 알았는데, 벽은 다른 데서 옵니다. 만들 때는 '이거 해줘, 저 기능 만들어줘'로 충분했는데, 막상 내보내려니 판단할 게 생깁니다. 도메인은 어디로 배포할지, 호스팅은 어떻게 할지, 환경 변수는 뭐고 DNS 설정은 뭔지. 비전공자라면 모르는 게 당연한 용어들이 한꺼번에 쏟아지고, 판단 기준이 없으면 '해줘'는 여기서 멈춥니다.
그렇다고 코딩을 배워야 한다는 얘기가 아닙니다. 코딩은 몰라도 역할은 알아야 한다는 것입니다. 사용자에게 보이는 화면이 프론트엔드, 화면 뒤의 계산과 규칙이 백엔드, 데이터가 사는 창고가 데이터베이스, 세상에 여는 문이 서버·배포. 이 정도 역할만 알면 '해줘'가 '이 역할을 이렇게 맡겨줘'로 바뀌고, AI가 해 놓은 설계가 내 서비스에 맞는지 판단할 눈이 조금씩 생깁니다. 모르는 용어가 나오면 그 자리에서 AI에게 '이게 무슨 역할이야?'라고 물어보면 됩니다.
기술의 벽에는 눈에 안 보이는 두 번째 얼굴이 있습니다. 보안입니다. 만든 사람 눈에는 안 보이는데, 노리는 사람 눈에는 제일 잘 보입니다. GitGuardian의 2026년 집계에 따르면 2025년 한 해 동안 공개 GitHub에 노출된 열쇠(시크릿 키)가 2,865만 건으로, 전년보다 34% 늘어 역대 최대 증가 폭이었습니다. AI 코딩 확산과 함께 급증한 수치입니다. API 키 같은 열쇠를 코드에 그대로 두고 올리는 것, 바이브 코딩에서 가장 흔한 보안 사고입니다.
출시 전에 세 가지만 점검하면 최악은 막습니다. 열쇠는 서버에만 두고 코드에 넣지 않기, 데이터베이스를 누구나 읽고 쓸 수 있는 상태로 열어 두지 않기, 개인정보는 최소한만 모으기. 셋 다 5분이면 확인할 수 있습니다. 마지막으로 클로드의 security-review 같은 보안 점검 기능으로 출시 전에 한 번 훑게 하면, 사람이 놓친 걸 잡아 줍니다.
서류의 벽 — 만드는 건 제일 쉬운 단계였습니다
세 번째 벽이 제일 깁니다. 앞서 본 3 대 7의 7이 전부 여기입니다. 잘 돌아가는 결과물을 세상에 내보내는 일이 통째로 남아 있습니다. 웹이라면 서버 배포와 도메인 구매, 약관·개인정보 처리방침(없으면 법 위반입니다), 카톡 미리보기 이미지, 구글·네이버 검색 등록과 상위 노출. 앱이라면 스크린샷 규격과 심사용 안내, 카테고리 선택, 그리고 긴 심사 대기. 이 목록에서 하나라도 빠지면 출시가 멈추거나, 링크 하나 보냈을 때 어딘가 어색한 서비스가 됩니다.
솔직히 이 벽에는 지름길이 없습니다. 결국 하나하나 해결해야 하는 일들이고, AI가 대신 눌러 주지 않는 버튼들이 있습니다. 다만 위 목록이 곧 지도입니다. 뭐가 남았는지 알고 시작하는 것과 모르고 부딪히는 것은 다릅니다. 그리고 이 벽의 끝에서 알게 되는 사실이 하나 있습니다. 출시는 결승선이 아니라 개장일이라는 것. 올리고 나면 문의가 오고(답할 창구가 필요합니다), 버그 신고가 오고(고칠 손이 필요합니다), 폰이 업데이트되면서 가만히 있어도 깨집니다. '만들어 놓고 끝, 자동으로 월 천만 원' 같은 그림이 현실에서 잘 성립하지 않는 이유입니다.
빌더의 딜레마 — 만들면 팔릴 거라는 착각
마지막 벽은 심리도 기술도 서류도 다 넘은 사람 앞에 섭니다. 그 어렵다는 출시까지 해냈는데 수익이 0원인 경우입니다. 만드는 것과 사업이 되는 것은 다른 문제이기 때문입니다. CB Insights가 실패한 스타트업들의 사후 부검 리포트를 집계한 결과(복수 응답), 실패 원인 1위는 기술이 아니라 '시장에 필요가 없어서'로 42%였습니다. 자금 부족 29%, 팀 문제 23%, 경쟁 19%가 그 뒤입니다. 나는 이게 꼭 필요할 거라 생각했지만, 그 시장 조사가 사실 구글 몇 번 검색해 보고 내 니즈에서 출발한 것이었다면, 부족한 건 만들기 실력이 아니었던 겁니다.
그래서 순서를 바꿔야 합니다. 기술이 아니라 문제에서 시작하는 것입니다. 사용자가 지금 겪고 있는 진짜 불편을 찾고, 내 결과물이 그 불편을 없애 주면, 해결되니까 사람들이 알아서 찾아오고, 계속 해결받고 싶으니까 돈을 냅니다. 돈은 이 순서로만 돕니다. 대한민국에서 크게 성공한 토스도 '송금이 귀찮다'는 작은 불편에서 시작했습니다. 그래서 만들기 전에 한 줄이면 됩니다. 누가, 어떤 문제 때문에, 왜 돈을 내는가. 이 답이 기술보다 먼저입니다. 혼자 답하기 어려우면 AI와 대화하면서라도 냉정하게 문제를 정의해 보시길 권합니다.
여기까지 읽고도 어렵게 느껴진다면 — 그게 정상입니다
여기까지가 혼자 넘는 지도입니다. 그런데 여기까지 읽고도 여전히 어렵고 귀찮게 느껴지실 수 있습니다. 그게 정상입니다. 원래 문제를 정의하고, 해결책을 찾고, 시장에 내보내고, 구매를 일으키는 일은 각 분야 전문가들이 팀으로 며칠 밤낮을 들여 하던 일입니다. 그걸 혼자, 집에서, 며칠 만에 전부 대체하길 바라는 건 과한 욕심일 수 있습니다.
그래서 저희 린디 스튜디오는 이 4개의 벽을 기준으로 외주를 합니다. 마음의 벽은 개발을 저희가 맡으니 중간에 멈출 일이 없고, 기술의 벽은 '해줘'가 안 되는 지점부터가 저희 일입니다. 서류의 벽은 약관·개인정보 처리방침 작성 지원과 검색 등록·미리보기·심사 규격까지 확인하고 납품합니다. 저희 차트 앱에 전부 직접 적용해서 심사를 통과시켜 본 항목들입니다. 그리고 빌더의 딜레마는, 시장 반응을 보고 나서 만들어도 될 기능이라면 만들기 전에 말씀드립니다. 그래서 과도한 추가 견적이 없고, 착수 후 인상 없음은 계약 조항으로 넣습니다. AI가 딸깍해 주지 못하던 시절부터 개발자·PM 실무 3.5년과 외주 납품 2년을 지나온 팀이 합니다.
직접 가실 분은 이 글의 지도 그대로, 벽이 보일 때마다 해당 섹션으로 돌아와서 하나씩 넘으시면 됩니다. 맡기실 분은 만들고 싶은 것만 적어서 보내 주세요. 어떤 걸 만들지부터 같이 잡아 드립니다. 꼭 저희가 아니어도 됩니다. 상담에서 방향만 잡아 가셔도 좋습니다.
