바이브코딩으로 서비스를 만드실 분들은 꼭 끝까지보세요 | 당근마켓 견적 이야기

1. 핵심 주장 (Core Claims)

1. "바이브 코딩으로 당근마켓 같은 서비스를 만들 수 있나요?"라는 질문은 예/아니오로 답할 수 있는 문제가 아니다. "당근마켓 같은 것"이라는 표현이 뜻하는 범위(단순 카피인지, 실제 몇천억 가치의 대박 서비스인지)와 "누가 만드느냐"(개발자인지 비개발자인지)에 따라 답이 완전히 갈라진다.
2. 바이브 코딩이 대체하는 것은 "기획-개발-테스트" 과정에서 사람이 오랜 시간과 큰 비용을 들이던 개발/엔지니어링 작업이지, 서비스의 성공 여부나 아이디어 자체가 아니다. 기획(아이디어)은 여전히 사람이 해야 한다.
3. 비개발자·비전공자라도 만들려는 의지, 아이디어, 계획이 있는 상태에서 바이브 코딩을 익히고 시도하며 만들어가는 것은 분명히 가능하고, 실제 성공 사례(마케터 출신이 바이브 코딩으로 서비스를 만들어 돈을 번 사례 등)도 있다.
4. "바이브 코딩으로 모두가 대박 서비스를 만들 수 있다"는 과장이고, "모두가 절대 불가능하다"는 것도 지나치게 부정적인 얘기다. 저자는 그 중간, 즉 "충분히 시도해볼 만한 시기와 도구가 갖춰졌다"는 입장을 취한다.

2. 근거와 사례 (Evidence & Examples)

• 댓글 논쟁의 배경: 저자가 바이브 코딩 관련 영상을 올릴 때마다 "바이브 코딩으로 서비스를 다 만들 수 있다는 거냐"는 식의 비판적 댓글이 자주 달린다. 이 영상은 그에 대한 정리된 답변이다.
• 과거 당근마켓 전성기 견적 논쟁: 당근마켓이 한창 잘 나갈 때 "당근마켓 같은 서비스 만드는 데 얼마나 드나요?"라는 질문이 많았고, 답변이 굉장히 다양했다.
  • 이미 기획이 다 되어 있는 서비스를 그대로 카피(복제)하는 조건이라면: 능숙한 사람이 한 달이면 비슷한 기능을 만들 수 있고, 비용은 500만 원 수준부터 얘기됐다.
  • 좀 더 보편적으로는 3~4천만 원, 또는 5천만 원 수준의 견적이 오갔다.
  • 위시켓 등 여러 외주 플랫폼에서 "당근마켓 같은 서비스를 만들어 달라"는 용역 의뢰가 실제로 굉장히 많았다.
• 아는 선배의 "5억이면 만들 수 있냐"는 되물음: 그런 견적 논쟁이 한창일 때, 저자가 아는 회사 선배가 "5억 주면 만들 수 있냐"고 되물었다. 그때까지 5억이라는 숫자를 얘기한 사람은 아무도 없었는데, 저자는 이 질문이 시간이 지나면서 점점 설득력 있게 다가왔다고 말한다. 이는 "당근마켓"이라는 단어가 가리키는 대상(단순 카피본 vs 실제 대박 서비스)에 따라 견적 자체가 무의미할 정도로 달라진다는 것을 보여주는 사례다.
• 실제 의뢰 경험: 저자가 실제로 의뢰를 주고받은 사이에서도 "천만 원"이라는 숫자가 오갔던 적이 있다. 이는 이미 다 만들어진 기획이 있는 상태에서 단순 복제를 전제로 한 견적이었다.
• 개발 프로세스의 구성: 개발에는 기획 → 개발 → 테스트 → 실제 운영의 단계가 있다. 단순히 "똑같은 형태로 만들어 보는 것"이라면 앞의 몇 단계에서 끝나므로 몇천만 원 수준으로 얘기할 수 있지만, "당근마켓"이 실제로 몇천만 명이 쓰고 몇천억 원 가치가 있는 서비스를 의미한다면 5억으로도 어림없고, 사실상 돈으로 해결할 수 있는 문제가 아니다. 대기업들이 막대한 자본을 투입하고도 서비스를 만들었다가 수없이 망하고 접는 이유가, 사용자를 한 명 한 명 모으는 과정이 자본만으로는 안 되는 극도로 어려운 일이기 때문이라고 설명한다.
• 프로토타입 관점에서의 재질문: 질문을 "내가 만들고자 하는 서비스의 프로토타입 정도를 만들 수 있나요? 얼마 드나요?"로 바꾸면 답이 달라진다. 지금은 바이브 코딩으로 화면도 만들고, DB도 설계하고, 서비스를 실제로 오픈하는 것까지 분명히 가능하다.
  • 다만 논쟁이 남는 지점은 (1) 실제 운영이 가능한가, (2) 사용자가 많아졌을 때 대응이 가능한가, (3) 장애 처리 같은 유지보수가 가능한가 하는 부분이다.
  • 저자는 "흉내 내는 정도, 프로토타입 정도"는 분명히 가능하고, 기능 동작·DB·서버 배포까지 다 가능하지만, 그것이 정말 "대박 서비스"가 되느냐는 바이브 코딩의 문제가 아니라고 정리한다.
• 바이브 코딩이 실제로 대체한 것 — 과거 개발 인력 구조: 예전에는 서비스 하나를 만들 때 기획자 1명, 프론트엔드 개발자 1명, 백엔드 개발자 1명(당시엔 풀스택 개발자가 흔치 않았음), 클라우드/서버를 관리하는 엔지니어까지 필요했다. 최소 3~4명의 인력이 최소 3개월, 길면 6개월 정도를 들여야 서비스 하나를 만들 수 있었다. 개발과 테스트에 드는 시간·비용이 전체의 약 80%를 차지했고, 개발자 비용이 특히 컸다. 한 달 만에 만드는 건 기획도 화면도 제대로 안 나오는 수준이었다.
  • 바이브 코딩이 획기적으로 줄여준 부분은 바로 이 "개발/엔지니어링"에 드는 사람과 시간이다. 기획(아이디어 자체)은 여전히 사람이 해야 하는 영역으로 남는다.
• 업계의 현재 상황: 지금 웬만한 개발 회사, 서비스 회사 중 바이브 코딩이나 클라우드를 안 쓰는 곳이 거의 없을 정도다. 일일이 하나씩 개발하는 방식은 효율성과 생산성이 떨어지기 때문에 더 이상 그렇게 하지 않는다. 즉 "바이브 코딩으로 대단한 서비스를 만들 수 있는가"라는 질문에는 "만들고 있고, 실제로 운영도 하고 있다"가 지금의 현실이라고 답한다.
• 단서가 붙었을 때 달라지는 답: 그러나 여기에 "비개발자가 아무것도 모르는 상태에서 바이브 코딩만으로 당근마켓 같은 걸 만들 수 있느냐"는 조건이 붙으면 얘기가 굉장히 어려워진다. 즉 "누가" 만드느냐가 답을 완전히 바꾼다.
• 최근 성공 사례: 마케팅 업무를 하던 사람이 바이브 코딩을 배워서 서비스를 만들고 실제로 돈을 벌었다는 사례가 있다고 언급한다. 개발자와 비개발자의 경계가 예전만큼 뚜렷하지 않아졌다는 근거로 제시된다.
• 주변 반응: 저자 주변에 바이브 코딩으로 "잘 된다"는 사람이 저자 본인이 의심할 정도로 많다고 언급하며, 그럼에도 분명히 실제로 되고 있는 현상이라고 강조한다.

3. 구조화된 시사점 (Structured Insights)

• 바이브 코딩의 본질은 "개발/엔지니어링 비용과 시간의 단축"이지, "아이디어와 기획의 대체"가 아니다. 기획은 여전히 사람의 몫이다.
• "서비스가 성공하는 것"과 "서비스를 만드는 것"은 다른 목표다. 만드는 것은 성공을 향한 과정의 일부일 뿐이다.
• 저자가 아직 "5억도 안 될 수 있다"는 얘기를 초반부터 강하게 하지 않는 이유는, 바이브 코딩으로 막 시작하려는 사람들이 이미 넘어야 할 산이 많은데 처음부터 좌절감을 주고 싶지 않기 때문이다.
• 견적/가능성 논쟁이 소모적인 이유는 "당근마켓 같은 것"이라는 표현 자체가 두루뭉술해서, 사실상 "열심히 하면 성공할 수 있냐"는 수준의 무의미한 질문으로 변질되기 때문이다.

4. 실행 포인트 (Action Points)

1. 서비스 아이디어를 검토할 때 "카피(복제) 수준"인지 "실제 대규모 서비스 수준"인지부터 스스로 명확히 구분하고, 그에 맞는 기대치와 예산을 설정한다.
2. 처음부터 완성형 대박 서비스를 목표로 하지 말고, 바이브 코딩으로 프로토타입(화면, DB, 서버 배포 포함)을 빠르게 만들어보는 것을 1차 목표로 삼는다.
3. 기획(아이디어)은 바이브 코딩이 대신해줄 수 없는 영역이므로, 도구를 익히기 전에 무엇을 만들지에 대한 고민과 계획을 먼저 다진다.
4. 비개발자·비전공자라도 자신의 업무 영역(예: 마케팅)에서 만들 거리가 있다면, 지금이 바이브 코딩을 배우고 시도해볼 만한 시기라고 판단하고 실행에 옮긴다.
5. 프로토타입이 잘 되면 그때 가서 추가 인력을 섭외하거나 더 깊이 공부하는 식으로 단계적으로 확장한다. 처음부터 모든 것(운영, 확장, 장애 대응)을 혼자 해결하려 하지 않는다.
6. "바이브 코딩만으로 모든 게 된다" 또는 "바이브 코딩으로는 아무것도 안 된다"는 극단적 주장에 휩쓸리지 말고, 자신의 상황(의지·계획·시간)에 맞춰 실용적으로 판단한다.

핵심 요약 (20줄, 완전한 문장으로)

1. 기술노트with 알렉 채널의 저자는 영상마다 "바이브 코딩으로 서비스를 다 만들 수 있냐"는 비판적 댓글이 달려서, 이에 대한 정리된 답을 이 영상에서 제시한다.
2. 예전 당근마켓 전성기 때도 "당근마켓 같은 서비스를 만드는 데 얼마나 드나요?"라는 질문이 많았고, 답변은 500만 원부터 3~4천만 원, 5천만 원까지 천차만별이었다.
3. 위시켓 등 외주 플랫폼에서 "당근마켓 같은 서비스를 만들어 달라"는 용역 의뢰가 실제로 많았다.
4. 저자가 아는 회사 선배가 "5억 주면 만들 수 있냐"고 되물었을 때, 그전까지 아무도 5억이라는 숫자를 얘기한 적이 없었지만 그 질문은 시간이 지날수록 저자에게 점점 설득력 있게 다가왔다.
5. 핵심은 "당근마켓 같은 것"이라는 표현이 단순 카피본을 의미하는지, 실제 몇천만 명이 쓰는 몇천억 가치의 서비스를 의미하는지에 따라 답이 완전히 달라진다는 점이다.
6. 이미 기획이 다 되어 있는 서비스를 그대로 복제하는 조건이라면 바이브 코딩으로 저렴하고 빠르게 만들 수 있고, 저자의 실제 의뢰 경험에서도 천만 원이라는 견적이 오간 적이 있다.
7. 하지만 실제로 몇천만 명이 쓰고 몇천억 원 가치가 있는 서비스를 의미한다면 5억을 들여도 만들기 어렵고, 이는 돈으로 해결할 수 있는 문제가 아니다.
8. 대기업들도 막대한 자본을 투입해 서비스를 만들었다가 수없이 망하고 접는 이유는, 사용자를 한 명 한 명 모으는 과정이 자본만으로는 되지 않는 극히 어려운 일이기 때문이다.
9. 질문을 "내가 만들고자 하는 서비스의 프로토타입을 만들 수 있나요?"로 바꾸면, 지금은 바이브 코딩으로 화면, DB 설계, 서버 배포까지 실제 서비스 오픈이 분명히 가능하다.
10. 다만 실제 운영, 사용자 증가 대응, 장애 처리 같은 유지보수가 가능한지는 별개의 논쟁 지점으로 남는다.
11. 바이브 코딩이 대체한 것은 과거 기획-개발-테스트 과정에서 사람이 들이던 막대한 시간과 비용, 특히 개발/엔지니어링 부분이며, 기획(아이디어) 자체는 여전히 사람이 해야 한다.
12. 예전에는 서비스 하나를 만들려면 기획자 1명, 프론트엔드 개발자 1명, 백엔드 개발자 1명(풀스택은 흔치 않았음), 클라우드/서버 관리 엔지니어까지 최소 3~4명이 필요했다.
13. 이 인력들이 최소 3개월, 길면 6개월 정도의 시간을 들여야 서비스 하나가 완성됐고, 개발과 테스트에 드는 시간과 비용이 전체의 약 80%를 차지했다.
14. 지금은 웬만한 개발 회사, 서비스 회사 중 바이브 코딩이나 클라우드를 안 쓰는 곳이 거의 없을 정도로 효율성과 생산성 때문에 보편화됐다.
15. 그래서 "바이브 코딩으로 대단한 서비스를 만들 수 있냐"는 질문에는 "만들고 있고 실제로 운영도 하고 있다"가 지금의 현실이라고 답할 수 있다.
16. 그러나 여기에 "비개발자가 아무것도 모르는 상태에서 바이브 코딩만으로 당근마켓 같은 걸 만들 수 있느냐"는 조건이 붙으면 답은 훨씬 어려워진다.
17. 결국 이 질문은 예/아니오로 답할 수 있는 문제가 아니라, 표현이 가리키는 범위와 만드는 주체가 누구냐에 따라 천차만별로 갈린다.
18. 최근에는 마케팅 업무를 하던 사람이 바이브 코딩을 배워 서비스를 만들고 실제로 돈을 번 사례가 있을 정도로 개발자와 비개발자의 경계가 흐려졌다.
19. 저자는 "바이브 코딩으로 모두가 대박 서비스를 만들 수 있다"는 과장이고 "모두가 절대 안 된다"도 지나치게 부정적이라며, 의지와 계획이 있는 사람이라면 바이브 코딩을 익히고 시도해볼 만한 시기와 도구가 갖춰졌다고 정리한다.
20. 저자는 조만간 단순 지식 강의가 아니라 서비스 하나를 함께 기획하고 만들고 오픈하는 것까지 다루는 소규모 강의를 준비 중이라고 예고하며 영상을 마친다.