문과 출신 기획자가 코딩 강의를 한 시간도 수강하지 않고 달리기 습관 앱 '루티니스트'를 앱스토어에 올렸습니다. 처음 작업을 시작한 날부터 론칭까지 5주가 걸렸습니다. 그가 쓴 도구는 AI 코딩 보조 환경이었고, 그가 한 일은 원하는 것을 말로 설명하고 결과를 확인하는 것이었습니다. 코드는 그 사이에서 자동으로 생성됐습니다.

그는 이 경험을 "신기하고 재미있는 세상"이라고 요약했습니다. 그 감상이 눈에 걸리는 것은 성취감이 아니라 놀라움의 언어로 표현됐다는 점입니다. 자신이 직접 앱을 만드는 일이 가능하리라고 예상하지 않았다는 뜻이기도 합니다. 그 놀라움이 흩어지기 전에, 이 사례가 담고 있는 것을 좀 더 들여다볼 이유가 있습니다.

왜 지금 이 방식이 작동하기 시작했는가

'바이브코딩(Vibe Coding)'이라는 표현은 AI 연구자 안드레이 카파시(Andrej Karpathy)가 2025년 초 소셜 미디어에 올린 글에서 알려졌습니다. 코드를 완전히 이해하려 하지 않고 AI의 제안을 받아들이며 작업한다는 개념이었습니다. 방식은 단순했습니다. 원하는 것을 설명하고, AI가 코드를 생성하고, 작동하지 않으면 오류 메시지를 다시 AI에 붙여 넣고, 결과를 확인하며 다음 요청을 정리하는 것입니다. 개발 지식이 없어도 이 과정만 반복하면 작동하는 소프트웨어가 나온다는 주장이었습니다.

당시 개발자 커뮤니티에서는 회의적인 반응이 많았습니다. 이해하지 못한 코드를 배포해도 되느냐, 오류가 생겼을 때 어떻게 수정하느냐, 보안 취약점이 발생하면 누가 책임지느냐는 질문들이었습니다. 그 질문들은 지금도 유효합니다. 논란은 아직 닫히지 않았습니다.

그러나 논란이 진행되는 동안 도구의 품질이 달라졌습니다. 2024년과 2025년을 거치면서 AI 코드 생성 도구는 실제로 작동하는 코드를 산출하는 비율이 눈에 띄게 높아졌습니다. Cursor, Lovable, Bolt.new 같은 환경은 코드 편집기와 AI 대화창을 통합하는 방식으로 발전했습니다. 오류 메시지를 그대로 AI에 전달하면 수정 코드가 나오는 흐름이 안정화됐습니다. 이 반복 과정이 실제로 제품을 완성하는 수준까지 연결되기 시작했고, 최철용의 '루티니스트'는 그 가능성이 현실화된 사례 중 하나입니다.

이 경험담 안에서 조심해야 할 부분

이 사례를 읽고 "나도 5주면 앱을 만들 수 있겠다"는 결론으로 곧장 이어지면 곤란합니다.

최철용은 기획자였습니다. 앱이 무엇을 해야 하는지, 어떤 흐름으로 사용자가 움직이면 좋은지, 어느 기능이 필요하고 어느 기능이 과한지를 이미 언어로 정리할 수 있는 사람이었습니다. 바이브코딩에서 AI에 전달하는 '설명'의 품질이 결과물의 품질을 결정합니다. 구체적이고 일관된 설명이 들어가면 일관된 코드가 나오고, 모호한 요청이 들어가면 모호한 결과가 나옵니다. 기획력 없이 AI 도구만으로 같은 결과를 재현하기는 어렵습니다. 그가 5주 만에 제품을 완성한 데는 그가 원하는 것을 구체적으로 설명할 수 있었다는 사실이 배경에 있습니다.

'루티니스트'의 기능 범위도 함께 봐야 합니다. 달리기 습관 트래킹이라는 단일 목적에 집중된, 비교적 단순한 구조의 앱입니다. 금융 거래를 처리하거나 대규모 사용자 데이터를 다루는 서비스라면 이야기가 달라집니다. 이해하지 못한 코드가 보안 취약점이 되거나 사용자 데이터 손실로 이어지는 상황에서는 바이브코딩이 충분한 방법이 아닙니다. 그 맥락에서는 개발자를 통해 코드를 검토받거나 별도 보안 점검이 필요합니다.

3D 프린터 기술이 보급됐을 때와 비슷한 논의가 있었습니다. 누구나 물리적 객체를 직접 출력할 수 있게 됐지만, 의료 기기나 하중이 걸리는 구조물처럼 안전이 중요한 영역에서는 여전히 전문 설계 공정이 필요했습니다. 인쇄 기술이 확산됐다고 해서 모든 출판물이 동일한 신뢰를 받지 않는 것과 같습니다. 쉽게 만들 수 있게 됐다는 것과, 어떤 목적으로도 만들어도 된다는 것은 다른 문제입니다. 바이브코딩도 마찬가지로, 진입 장벽이 낮아진 것과 그 장벽이 사라진 것은 다릅니다.

1인 사업자가 이 흐름에서 실질적으로 건질 것

그렇다면 이 방법이 실제로 의미 있게 작동하는 맥락은 어디일까요.

내부 도구나 자기 자신을 위한 프로젝트가 가장 현실적인 출발점입니다. 외부에 공개되지 않거나 사용자 범위가 본인과 소수에 그치는 경우라면, 완성도보다 작동 여부가 더 중요합니다. 반복 수작업을 줄이는 자동화 스크립트, 여러 플랫폼의 데이터를 한곳에서 보는 간단한 대시보드, 자신의 작업 리듬에 맞는 추적 도구 같은 것들이 여기에 해당합니다. 이런 도구를 외주에 맡기면 수십만 원에서 수백만 원이 들고, 수정을 요청할 때마다 커뮤니케이션 비용이 발생합니다. 직접 만들면 그 비용 구조가 바뀝니다.

시장 반응을 확인하기 위한 초기 프로토타입에도 유효합니다. 최소 기능으로만 구성된 버전을 빠르게 만들어 실제 사용자에게 써보게 하는 단계라면, 완성도보다 속도가 훨씬 중요합니다. 그 단계에서 바이브코딩은 개발자를 기다리는 것보다 빠르게 움직일 수 있는 방법입니다.

실제로 시작하려는 분들에게는 기능 목록을 쓰기 전에 시나리오를 먼저 써두는 것이 도움이 됩니다. 사용자가 앱을 켜면 무엇을 보고, 어디를 누르고, 무엇을 원할 것인지를 이야기 형식으로 정리해두면 AI에 전달하는 설명의 밀도가 달라집니다. 기능 목록은 완성 후 정리해도 늦지 않습니다.

오류가 나오는 것을 두려워하지 않는 태도도 중요합니다. 바이브코딩 과정에서 오류는 피해야 할 사고가 아니라 AI와 함께 해결하는 반복의 일부입니다. 오류 메시지를 그대로 복사해 "이런 오류가 났는데 어떻게 고쳐야 하느냐"고 상황과 함께 전달하면 대부분 방향이 나옵니다. 이 과정 자체가 바이브코딩의 작업 흐름입니다.

누군가는 이 흐름을 가리켜 "이제 모두가 개발자"라고 말합니다. 저는 그 표현이 이 변화를 정확하게 담지 못한다고 생각합니다. 코딩이 보편화됐다기보다는, 기획자가 코드를 쓰는 사람을 기다리지 않아도 되는 맥락이 하나 생겼습니다. 만들고 싶은 것을 설명할 수 있는 사람이 직접 제품을 내놓을 수 있는 가능성이 열렸고, 최철용이 5주 만에 앱스토어에 올린 '루티니스트'는 그 가능성이 실제로 작동한다는 확인입니다.