"아이디어는 있지만 만들 수 없다"를 끝내다 — AI 개발 서비스 Lovable이 바꾸는 창업의 입구

혼자서 "움직이는 사업"을 만드는 시대가 왔다

"이런 서비스가 있으면 편리할 텐데"라고 생각한 적이 있어도 실제로 창업까지 나아가는 사람은 적다. 그 이유 중 하나는 아이디어와 제품 사이에 큰 개발 비용이 있기 때문이다. 엔지니어를 채용하거나 개발 회사에 의뢰하고, 몇 개월에 걸쳐 요구 사항을 확정해야 한다. 시장에 내놓아 보지 않으면 정답을 알 수 없는 단계에서, 먼저 큰 자금과 시간이 필요하게 된다.

이 순서를 뒤집으려는 것이 스웨덴 발 AI 개발 서비스 "Lovable"이다. 만들고 싶은 웹사이트나 앱을 자연스러운 문장으로 설명하면, AI가 화면, 기능, 데이터베이스 등을 조립하여 브라우저 상에서 작동하는 형태로 만든다. 완성된 것을 보면서 "색을 바꾸다", "로그인 기능을 추가하다", "이 목록을 검색할 수 있게 하다"와 같은 대화를 계속하면 제품을 수정할 수 있다.

기존의 노코드가 준비된 부품을 사람이 배치하는 도구였다면, Lovable은 "의도를 전달하면 AI가 부품 선택과 연결까지 진행하는 공동 작업자"에 가깝다. 프로그래밍을 몰라도 시작할 수 있는 반면, 뒤에서는 실제 코드가 생성된다. GitHub와 동기화하여 코드를 저장하고 리뷰하며, 필요하면 엔지니어가 인계받을 수도 있다. 데이터베이스, 인증, 스토리지, 서버 측 처리는 내장 백엔드나 Supabase를 이용할 수 있다.

Lovable의 공식 사이트에 따르면, 이미 누적 6천만 건의 프로젝트가 만들어졌고, 매주 120만 건이 새로 생겨나고 있다. 이 숫자는 운영 회사에 의해 발표된 수치이며, 모두가 운영 중인 사업이라는 의미는 아니다. 그럼에도 불구하고 소프트웨어를 "전문가에게 의뢰하여 만들어지는 것"에서 "본인이 대화하면서 시도하는 것"으로 변화시키는 기세는 읽을 수 있다.

14년간 잠들어 있던 여행 서비스가 움직이기까지

독일 경제지 한델스블라트가 소개한 상징적인 예가 Nico Wittenberg씨의 여행 플랫폼 "Avara"다. 발상의 원점은 14년 전의 눈보라였다. 파트너의 비행기가 결항되어 대체 수단을 계속 찾은 끝에 겨우 야간 열차를 발견했다. "버스부터 비행기까지 모든 이동 수단을 한데 모아 검색하고, 그대로 예약할 수 있으면 좋겠다"고 생각했다고 한다.

당시 그 구상을 이전 근무지인 Google의 동료에게 이야기하자, 실현하려면 개발 팀과 수백만 유로의 비용이 필요하다고 들었다. 그럼에도 불구하고 Wittenberg씨는 작년에 Lovable을 사용하여 혼자서 Avara를 형상화했다. 본인의 설명에 따르면 125개국 이상에서 이용되고 있으며, 각국의 벤처 캐피탈로부터 문의도 받고 있다.

여기서 중요한 것은 "AI가 하룻밤 사이에 세계 기업을 완성했다"는 경쾌한 이야기가 아니다. 14년간 비용의 벽에 막혀 있던 가설이 제삼자가 만질 수 있는 상태가 되었다는 것이다. 아이디어의 가치는 설명의 능숙함만으로는 검증할 수 없다. 검색 결과가 이해하기 쉬운지, 예약까지 혼란스럽지 않은지, 정말로 이용하고 싶은 사람이 있는지. 움직이는 제품이 있으면 이러한 질문에 현실의 반응이 돌아온다.

Lovable의 최대 효과는 개발비를 제로로 만드는 것이 아니라, "학습을 시작하기까지의 시간"을 단축하는 데 있다.

해외 SNS에서 일어나고 있는 열광——수익화도 확산도 현실로

SNS를 보면, Lovable에 대한 반응은 단순한 칭찬과 비판으로 나뉘지 않는다. 공통된 것은 최초의 성과물이 나타나는 속도에 대한 놀라움이다.

LinkedIn에서는 싱가포르에서 커뮤니티 사업을 운영하는 사용자가 오랫동안 형체가 없던 기획을 하룻밤에 웹 서비스로 만든 경험을 보고하고 있다. 자연스러운 언어로 희망을 전달할 수 있는 것, 수정도 대화로 진행할 수 있는 것을 평가하는 한편, 업데이트된 후에도 오류 표시가 나오는 장면이나, 기능을 추가할수록 크레딧 구매가 필요해지는 점에도 언급하고 있다. 댓글란에는 "원하는 것을 본인이 명확히 이해하고 있었기 때문에 AI가 도움이 되었다"는 지적도 있었다. 이는 본질적이다. AI는 모호한 사업 구상을 자동으로 뛰어난 사업으로 바꾸는 마법이 아니라, 명확한 의도를 고속으로 시제품으로 번역하는 장치이다.

Reddit의 Lovable 커뮤니티에는 초보자로서 만든 지역 서비스가 월 1000~2000달러를 벌어들이게 되었다는 게시물이 있다. 그리스에서는 최저임금으로 몇 개의 피타·기로를 살 수 있는지를 연령별로 나타내는 "Gyronomics"가 SNS에서 확산되어, TV나 현지판 WIRED에도 소개되었다고 한다. 게시자는 아이디어를 빠르게 공개할 수 있었던 것, 시각적으로 정돈된 대시보드를 첫날부터 제시할 수 있었던 것을 성공 요인으로 꼽고 있다.

이들은 자기신고이며, 수익이나 접근을 제삼자가 감사한 사례는 아니다. 성공 사례만이 게시되기 쉬운 편향도 있다. 그럼에도 불구하고, 완성도가 높은 사업 계획서보다 지금 당장 공유할 수 있는 작은 웹 서비스가 사람을 움직이게 한다는 것을 보여준다. Lovable에서 유리해지는 것은 가장 많은 기능을 포함한 사람이 아니라, 사회의 관심이 높아진 순간에 최소한의 형태로 공개하고 반응을 받아들일 수 있는 사람이다.

SNS의 불만이 나타내는 "마지막 20%"의 무게

열광의 이면에서, 같은 커뮤니티에는 구체적인 불만도 나열된다. 눈에 띄는 것은 크레딧 소비다. Lovable은 AI에 대한 의뢰, 클라우드 이용, 앱 내의 AI 기능 등에 크레딧을 사용한다. 공식 요금 설명에서도 단순한 외관 수정과 인증 기능 추가에서는 소비량이 다르다. 이용자들로부터는 이전보다 하나의 작업이 더 비싸졌다는 것, 고쳐지지 않는 결함을 여러 번 AI에 수정시켜 크레딧을 잃었다는 것, 공개 후에 데이터베이스 이용료가 예상 이상으로 증가했다는 목소리가 나오고 있다.

또 하나의 논점은 본격적인 운영이다. 화면이 움직이는 것과 안심하고 고객에게 사용하게 할 수 있는 것은 동일하지 않다. 두 개의 계정을 만들고, 한쪽에서 다른 쪽의 데이터에 접근할 수 없는지. 결제 금액을 브라우저 측에서 변경할 수 없는지. 같은 결제 통지가 여러 번 와도 이중 처리가 되지 않는지. 외부 API가 멈췄을 때 안전하게 실패하는지. 백업에서 정말로 복원할 수 있는지. Reddit에서는 이러한 테스트를 공개 전에 수행해야 한다는 실무적인 조언이 공유되고 있다.

데이터베이스의 인덱스 부족으로 인해 소수의 동시 접근만으로도 CPU 부하가 급증했다는 검증 게시물도 있다. 다른 사용자는 GitHub의 브랜치로 코드를 나누어도 테스트용과 본용의 데이터베이스를 완전히 분리하는 방법에 고민하고 있었다. 이는 Lovable 고유의 결함이라기보다는 소프트웨어 운영의 어려움이 사라진 것은 아니라는 것을 나타낸다. AI는 보이는 부분을 놀라울 정도로 빠르게 만든다. 그 결과, 권한, 모니터링, 장애 대응, 데이터 이전과 같은 "평소에는 보이지 않는 설계"의 중요성이 오히려 빠른 단계에서 나타난다.

Lovable 자체도 기본 스캔과 상세 스캔, API 키 보호, 데이터베이스의 행 단위 접근 제어, 의존 관계 감사 등을 준비하고 있다. 다만 공식 문서는 스캔이 완전한 안전을 보장하는 것이 아니며, 기밀 데이터나 중요한 기능을 다룰 경우에는 전문가에 의한 추가 리뷰를 검토해야 한다고 명시한다. "AI가 만들었기 때문에 위험"도 "보안 기능이 있기 때문에 안전"도 아니다. 다루는 데이터와 피해의 크기에 따라, 사람이 책임을 지고 확인할 필요가 있다.

일본에서는 "개발 회사의 대체"보다 "결재 전"에 효과적

일본에서 보면, Lovable의 가치는 해외의 1인 창업가와는 조금 다른 형태로 나타날 가능성이 있다. 일본 기업의 신규 사업에서는 기획 담당자가 사양서나 슬라이드를 만들고, 정보 시스템 부문이나 개발 회사에 상담하고, 견적과 결재를 거쳐 시제품을 만드는 흐름이 많다. 초기의 가설일수록 모호한데, 만들기 전에 상세한 설명과 예산의 확정을 요구받는다. 그 때문에 고객에게 보여주기 전에 사내 조정에서 힘을 다 써버리기 쉽다.

Lovable은 이 구조의 앞에 들어간다. "만들어 주세요"라고 발주하기 전에, 영업 담당자, 매장 책임자, 마케터, 연구자 등 현장에서 과제를 아는 본인이 시제품을 만들 수 있다. 회의에서 기능 목록을 읽는 대신, 스마트폰으로 화면을 만져볼 수 있다. 불필요한 기능이 하루 만에 파악되면, 정식 개발에서 몇 주간의 낭비를 피할 수 있다.

IPA의 "DX 동향 2025"는 일본 기업의 DX에 대해, 생성 AI 활용, 시스템 개발의 내재화, 인재의 양과 질을 주요 과제로 다루고 있다. Lovable은 엔지니어 부족을 한 번에 해결하는 것은 아니지만, 업무 지식을 가진 사람이 개발의 입구에 참여하기 위한 다리가 된다. 특히, 지역의 중소기업, 전문직, 개인 사업자에게는 예약, 견적, 고객용 진단, 사내 신청, 재고 확인 등, Excel과 이메일로 연결했던 작은 업무를 시험할 여지가 크다.

일본어로 지시할 수 있는 것도 입구를 넓힌다. 다만, 일본어가 통한다는 것과 일본의 상관습을 이해하고 있다는 것은 별개다. 주소·성명의 표기, 일본 연호, 소비세, 청구서, 은행 송금, 스마트폰에서의 세세한 조작, 문의 대응 등은 이용자 자신이 요구 사항으로 전달하고 확인해야 한다. 일본 시장에서는 "대충 작동하는" 것보다, 예외 시에 상대방을 불안하게 하지 않는 것이 신뢰로 이어진다. 문구, 오류 표시, 취소, 환불, 개인정보의 취급까지 다듬는 작업은 남는다.

적합한 사업, 신중해야 할 사업

Lovable과 궁합이 좋은 것은 먼저 고객의 반응을 확인하고 싶은 웹 서비스다. 예를 들어, 특정 업계용 간이 업무 도구, 이벤트 예약, 회원 전용 정보 사이트, 지역 정보의 시각화, 진단 콘텐츠, 사내 한정 관리 화면 등이다. 가치의 중심이 독자적인 알고리즘보다, 업무의 이해나 고객과의 접점에 있는 경우, 창업자의 지식을 직접 제품에 옮기기 쉽다.

한편, 의료 판단, 금융 거래, 행정 절차, 대량의 개인정보, 어린이의 정보, 생명이나 재산에 관련된 제어 등은 비엔지니어만으로 공개해야 할 영역이 아니다. 개인정보 보호 위원회도 생성 AI 서비스에 개인 데이터를 입력할 때는, 이용 목적의 범위나 제공 사업자에 의한 기계 학습에의 이용 등을 확인하도록 주의를 환기하고 있다. 프롬프트에 실재 고객의 성명이나 상담 내용을 붙여넣는 것, 테스트 환경에 본 데이터를 그대로 복사하는 등의 사용법은 피해야 한다.

판단 기준은 간단하다. "실패해도 사과하고 고칠 수 있는 실험인가" "실패하면 돌이킬 수 없는 피해가 발생하는 구조인가". 전자라면 작게 시도할 가치가 높다. 후자라면, Lovable을 화면의 시제품에 한정하고, 설계, 법무, 보안, 운영을 전문가와 함께해야 한다.

일본의 창업자가 첫 7일간 해야 할 일

첫날에 해야 할 일은 거대한 사업 계획을 쓰는 것이 아니다. "누가, 어떤 순간에, 무엇을 완료할 수 있는 서비스인가"를 한 문장으로 만드는 것이다. 예를 들어 "소규모 음식점이, 전화를 사용하지 않고 대여 예약의 후보일과 견적을 반환할 수 있는 서비스"로 한다. 대상자와 완료 조건이 명확하면, AI에 대한 지시도 흔들리지 않는다.

2일째부터 3일째는 하나의 흐름만을 만든다. 등록, 검색, 결제, 채팅, 분석을 모두 넣는 것이 아니라, 가장 중요한 경험을 하나 선택한다. 외관을 너무 다듬지 않고, 가상 데이터로 작동시킨다. 변경 전에는 GitHub에 동기화하여, 되돌릴 수 있는 상태를 만든다. AI에 한 번에 다수의 수정을 요청하지 않고, 한 번의 변경, 한 번의 확인을 반복하는 것이 결함의 원인과 크레딧 소비를 관리하기 쉽다.

4일째는 예상 고객 3명에서 5명에게 만져보게 한다. 조작 방법을 설명하지 않고, 어디에서 멈추는지를 본다. "원하십니까"가 아니라, "현재 방법과 비교하여 무엇이 편리해지는가" "얼마면 사용할 것인가" "사용하지 않는 최대의 이유는 무엇인가"를 묻는다.

5일째는 늘릴 기능이 아니라, 줄일 기능을 결정한다. 6일째에는 두 개의 테스트 계정을 사용하여, 타인의 정보가 보이지 않는지, 로그아웃 후에도 조작할 수 없는지를 확인한다. 비밀 키를 화면 측에 두지 않고, 외부 서비스가 실패한 경우도 시험한다. 7일째에 제한된 상대에게 공개한다. 이 시점에서는 본격적인 고객의 중요한 정보를 대량으로 넣지 않는다.

반응이 없다면, 그것은 개발의 실패가 아니라, 저렴하게 얻어진 시장의 답이다. 반응이 있다면, 그때 처음으로 전문가를 투입하여, 데이터 설계, 보안, 테스트, 모니터링, 요금을 재검토한다. Lovable로 시제품을 만든 것은 엔지니어와의 협업을 불필요하게 하는 것이 아니라, 무엇을 만들어야 할지를 구체적으로 하여 협업의 질을 높인다.

창업자에게 필요한 것은 코드보다 "질문을 선택하는 힘"이다

소프트웨어 개발의 비용이 낮아지면, 아이디어를 가지고 있는 것 자체의 희소성도 낮아진다. 비슷한 서비스를 누구나 짧은 시간에 만들 수 있다면, 차이가 되는 것은 누구의 어떤 불편을 깊이 이해하고 있는가