코딩 몰라도 앱 만드는 시대, 진짜일까? 외주 비용·AI·노코드 한계 총정리

저는 코드를 한 줄도 못 짭니다. 그런데 지금 제 손으로 만든 영상 편집 시스템으로 영상을 찍고, 자막을 붙이고, 음악을 깔고 있습니다. 그 시스템을 만드는 데 걸린 시간은 반나절 남짓이었어요. 몇 년 전의 저였다면 상상도 못 했을 일입니다. 그때는 머릿속에 만들고 싶은 게 있어도 직접 손댈 수가 없으니, 늘 누군가에게 돈을 주고 부탁해야 했거든요.

만들고 싶은 게 있는데 못 만든다는 건, 생각보다 답답한 일입니다. 아이디어는 내 머릿속에 또렷한데, 그걸 세상에 꺼내놓으려면 매번 적지 않은 돈과 긴 시간이 들었어요. 그런데 요즘은 분위기가 많이 달라졌습니다. 코드를 모르는 사람도 자기에게 필요한 걸 직접 만들기 시작했어요. 오늘은 그 변화가 진짜인지, 어디까지가 진짜고 어디부터가 함정인지, 그리고 코딩을 모르는 사람이 무엇을 알고 시작해야 안 속는지를 차분히 짚어보려고 합니다.

코딩을 모르면 정말 서비스를 못 만드나요?

예전엔 그랬습니다. 지금은 꼭 그렇지만은 않아요.

불과 몇 년 전까지만 해도, 앱이나 웹 서비스 하나를 세상에 내놓으려면 개발자를 구하거나 외주를 맡기는 것 말고는 길이 거의 없었습니다. 그런데 그 흐름이 빠르게 바뀌고 있어요. 시장조사기관 가트너는 2026년이면 새로 만들어지는 앱의 상당수가 노코드·로우코드 방식으로 만들어질 거라고 내다봤습니다. 그 예측이 지금 현실이 되어가는 중이에요. 코드를 직접 짜지 않아도 화면을 조립하듯 만드는 노코드 도구, 그리고 말로 설명하면 코드를 대신 써주는 AI 코딩이 빠르게 퍼지면서, '만드는 사람'의 자격이 달라지고 있습니다.

여기에 '말로 코딩한다'는 뜻의 바이브 코딩(vibe coding)이라는 말까지 등장했습니다. 전직 오픈AI·테슬라 AI 연구자였던 안드레이 카파시가 붙인 표현인데, 이제는 비개발자도 채팅하듯 자기 제품을 만들어보는 시대가 됐다는 신호예요.

그러니 "코딩 모르면 못 만든다"는 말은, 이제 절반만 맞습니다. 무언가를 '만들어보는 것'까지는 누구나 할 수 있게 됐어요. 다만 '만든 것'과 '진짜 쓰는 것' 사이에는 아직 꽤 넓은 강이 흐릅니다. 그 강 이야기를 이어서 해볼게요.

앱 하나 만드는 데 정말 수천만 원이 드나요?

네, 제대로 쓰는 서비스라면 그렇습니다. 이건 제 경험이자, 데이터가 받쳐주는 사실이에요.

제가 사업할 때 가장 아팠던 게 이 비용이었습니다. 서비스 하나 만들려면 수천만 원이 깨졌거든요. 처음엔 제가 운이 나빴나 싶었는데, 자료를 찾아보니 그게 표준에 가까웠습니다. 외주 개발 중개 플랫폼 위시켓이 7만 건이 넘는 프로젝트 데이터를 정리한 자료를 보면, 국내 앱 외주 개발의 평균 비용은 3,270만 원이었어요. 단순한 정보성 앱은 800만~1,500만 원 선이지만, 결제나 채팅, 예약처럼 '진짜 사업에 필요한 기능'이 들어가면 2,000만~4,000만 원, 플랫폼급으로 가면 그 이상으로 뛰었습니다.

여기서 끝이 아닙니다. 외주의 진짜 비용은 돈만이 아니에요. 3개월이면 된다던 결과물을 9개월이 지나서야 받아 든 창업자의 이야기를 본 적이 있습니다. 막 시작한 회사에게 반년의 지연은 사실상 한 시절을 통째로 날리는 일이죠. 일정이 내 통제 밖에 있고, 우선순위는 외주사 사정에 밀리고, 중간에 담당자가 바뀌기도 합니다. 무엇보다 '내가 왜 이걸 만드는지'에 대한 감각을 외주사는 나만큼 갖고 있지 않아요. 돈은 돈대로 들고, 통제권은 통제권대로 내주는 겁니다.

그래서 저는 어느 순간부터 생각을 바꿨습니다. 매번 수천만 원을 들여 남에게 부탁하는 대신, 필요한 걸 내 손으로 만들 수는 없을까. 영상 편집 시스템을 직접 만든 게 그 시작이었어요. 지금 이 글과 함께 나가는 영상의 자막과 음악도, 전부 그 시스템이 만든 결과물입니다.

ChatGPT로 만든 건 왜 자꾸 멈출까요?

'그럴듯한 것'과 '진짜 작동하는 것'은 완전히 다르기 때문입니다. 여기가 가장 중요한 대목이에요.

코딩을 모르는 분들이 AI한테 "이런 기능 만들어줘" 하면, AI는 정말 그럴듯한 코드를 척척 내놓습니다. 화면도 보기 좋게 뽑아주고요. 그런데 막상 돌려보면 자꾸 멈추고 에러가 납니다. 이게 운이 나빠서가 아니에요. AI가 만든 코드에는 '환각'이라는 고질병이 있습니다. 존재하지도 않는 함수나 기능을 마치 진짜인 것처럼 자신 있게 써넣는 거예요. AI 코드 생성을 다룬 학술 분석(arXiv)과 IEEE 같은 기술 매체의 보고를 보면, 특정 조건에서는 AI가 지어낸 라이브러리 비율이 절반 가까이 치솟기도 합니다. 문제는, 코딩을 모르는 사람은 그게 가짜인 줄도 모른 채 계속 에러와 씨름하게 된다는 겁니다.

노코드 도구도 비슷한 천장이 있습니다. 흔히 '80 대 20'이라고 불러요. 보기 좋은 화면을 만들고 기본 흐름을 짜는 80%까지는 놀랍도록 쉽게 갑니다. 그런데 사업을 사업답게 만드는 마지막 20%, 그러니까 결제 연동, 로그인 보안, 예외 상황 처리 같은 데서 무너지는 경우가 많아요. 노코드로 결제를 붙이려다, 차라리 코드를 직접 짜는 것보다 더 위태로운 임시방편에 의지해야 했다는 후기도 흔합니다. 마지막 20%는 도구가 대신 책임져 주지 않거든요.

그래서 업계에서 자주 나오는 말이 "데모는 되는데 프로덕션은 안 된다"는 겁니다. 보여주기용 시제품은 금방 나오는데, 실제로 사람들이 매일 쓰는 제품으로 가는 마지막 고비를 못 넘는 경우가 많다는 거예요. "90%는 됐고 몇 군데만 고치면 된다"고 느낄 때, 사실 그 남은 10%가 인증·결제·검증처럼 제일 어려운 부분인 경우가 많습니다. 데모를 만드는 것과, 멈추지 않고 돌아가는 진짜 제품을 만드는 것은 다른 일이라는 거죠.

그럴듯함에 안 속으려면 무엇을 봐야 하나요?

만들기 전에 딱 몇 가지만 짚고 가면, 속는 일이 확 줄어듭니다. 저장해두고 다음에 외주를 맡기거나 AI·노코드로 직접 만들 때 그대로 꺼내 쓰실 수 있게 정리했어요.

외주를 맡기기 전에 스스로 던질 자문 체크

이 기능이 정말 지금 필요한가, 아니면 '있으면 좋은 것'인가 (없어도 핵심이 도는 기능은 일단 뺀다)
결제·로그인·개인정보처럼 한 번 잘못되면 위험한 부분은 누가, 어떻게 책임지는가
다 만든 뒤에 내가 직접 작은 수정이라도 할 수 있는 구조인가, 아니면 매번 다시 돈을 줘야 하는가
일정이 밀릴 때 내가 손쓸 수 있는 여지가 계약에 있는가
만든 사람이 떠나도 다음 사람이 이어받을 수 있게 정리되어 있는가

AI·노코드로 직접 만들 때 '그럴듯함'을 거르는 판별 기준

화면만 멀쩡한지, 아니면 실제 데이터를 넣고 끝까지 한 바퀴 도는지 직접 눌러본다 (데모와 작동은 다르다)
AI가 써준 기능 이름·라이브러리가 실재하는 것인지 한 번은 검색해 확인한다 (환각 거르기)
결제·로그인 같은 민감한 부분은 "되는 것 같다"가 아니라 "실패할 때도 안전한가"까지 본다
내일·다음 달에 이걸 또 고칠 수 있는지, 만든 과정이 나한테 남는지 확인한다
"90% 됐다"는 느낌이 들 때 오히려 의심한다 — 남은 10%가 제일 어려운 부분일 때가 많다

균형 있게 말씀드리면, AI와 노코드가 만능은 아닙니다. 복잡한 로직, 큰 규모로의 확장, 그리고 시간이 지난 뒤의 유지보수에서 한계가 분명히 드러나요. AI로 급하게 만든 앱이 몇 달 안에 방치되는 경우도 적지 않다고 합니다. 데이터가 낡고, 연동한 외부 서비스가 바뀌고, 정작 만든 사람은 그 코드를 이해하지 못해서요. 그러니 '직접 만든다'가 '검증 없이 던진다'가 되면, 빠르게 만든 만큼 빠르게 무너집니다. 핵심은 속도가 아니라 '진짜 작동하는 데까지, 그리고 계속 굴러가는 데까지' 가는 거예요.

그래서, 만들고 싶은 게 있다면

정리하면 이렇습니다. 코딩을 몰라도 만들 수 있는 시대가 온 건 맞습니다. 다만 '만들어보는 것'과 '진짜 쓰는 것'은 다르고, 그 차이가 곧 '그럴듯함'과 '작동함'의 차이예요. 위에 적어둔 자문 체크와 판별 기준 — 정말 필요한 기능인지, 민감한 부분은 실패할 때도 안전한지, 내가 계속 고칠 수 있는지, 90% 됐다는 느낌을 의심하는지 — 이 몇 가지만 손에 쥐고 있어도, 돈과 시간을 헛되이 쓰는 일이 확 줄어듭니다.

거창하게 시작하지 마세요. 살면서 "이게 있으면 참 좋을 텐데" 싶은 것 딱 하나만 골라, 그걸 그럴듯한 데모가 아니라 실제로 작동하는 데까지 한번 가보시는 겁니다. 작은 것 하나라도 끝까지 돌아가게 만들어보면, 그 다음은 훨씬 쉬워져요.

저는 코드를 한 줄도 못 짜는 사람입니다. 그런데 지금은 필요한 걸 제 손으로 만들고 있어요. 그 작은 아이디어가 데모에서 멈추지 않도록, 무엇을 만들지만 정하면 화면과 기능을 잡아주고, 결제나 로그인처럼 안 무너져야 하는 부분까지 실제로 돌아가게 만들어 넘겨주는 것 — 코드를 못 짜던 제가 직접 건넌 그 강을 다른 분은 좀 더 수월하게 건넜으면 해서 만든 게 VUILD입니다. 이름 그대로 'Value(가치)를 Build(구현)로' 옮긴다는 뜻이에요. 만들고 싶은 게 마음속에 있다면, 한번 그걸 세상에 꺼내보세요.

자주 묻는 질문 (FAQ)

Q. 앱 외주 개발, 평균 비용이 정말 3,000만 원이 넘나요? 외주 중개 플랫폼 위시켓이 7만 건 넘는 프로젝트를 집계한 자료에서 국내 앱 외주 개발 평균이 3,270만 원이었습니다. 단순 정보성 앱은 800만~1,500만 원 선이지만, 결제·채팅·예약 같은 기능이 들어가면 2,000만~4,000만 원, 플랫폼급은 그 이상으로 올라갑니다.

Q. 코딩을 전혀 몰라도 직접 서비스를 만들 수 있나요? '만들어보는 것'까지는 노코드 도구와 AI 코딩으로 누구나 할 수 있게 됐습니다. 다만 결제·로그인·예외 처리 같은 마지막 20%에서 막히는 경우가 많아서, '데모'와 '진짜 작동하는 제품' 사이에는 아직 거리가 있습니다.

Q. 바이브 코딩이 뭔가요? '말로 코딩한다'는 뜻으로, 채팅하듯 AI에게 설명하면 코드를 대신 써주는 방식을 가리킵니다. 전직 오픈AI·테슬라 AI 연구자 안드레이 카파시가 붙인 표현입니다.

Q. AI가 만든 코드는 왜 자꾸 에러가 나나요? AI는 존재하지 않는 함수나 라이브러리를 진짜처럼 지어내는 '환각' 문제가 있습니다. 특정 조건에서는 지어낸 라이브러리 비율이 절반 가까이 되기도 합니다. 코딩을 모르면 그게 가짜인 줄 모른 채 에러와 씨름하게 됩니다.

Q. 노코드 도구로는 어디까지 만들 수 있나요? 화면을 만들고 기본 흐름을 짜는 80%까지는 매우 쉽습니다. 하지만 결제 연동, 보안, 예외 처리 같은 마지막 20%에서 한계가 드러나는 경우가 많아, 본격적인 사업용 서비스는 보완이 필요합니다.

Q. 외주를 맡기기 전에 꼭 확인할 건 뭔가요? 정말 지금 필요한 기능인지, 결제·개인정보 같은 위험한 부분의 책임 소재, 나중에 내가 직접 수정할 수 있는 구조인지, 일정 지연 시 대응 여지, 담당자가 떠나도 이어받을 수 있는 정리 — 이 다섯 가지를 먼저 점검하세요.