바이브코딩으로 Lovable에 취직했습니다.

Lazar Jovanovic은 채용 인터뷰에서 이력서를 꺼내지 않았습니다. 대신 노트북을 열어서 앱 하나를 보여줬어요. Lovable이라는 바이브 코딩 도구로 만든 프로토타입이었습니다. 코드를 직접 작성한 건 한 줄도 없었어요. 면접관이 물었습니다. "이게 당신이 직접 만든 건가요?" 그 질문이 그의 첫 번째 테스트였고, 그는 통과했습니다. 지금 그의 직함은 Lovable의 첫 공식 바이브 코딩 엔지니어(Vibe Coding Engineer)입니다.

코딩을 한 번도 해본 적 없는 사람이 소프트웨어 엔지니어가 될 수 있을까요? 직함에 '엔지니어'가 붙는 자리를, 코드 한 줄 못 쓰는 사람이 차지할 수 있을까요? 솔직히 말하면, 1년 전의 저였다면 "설마요"라고 했을 겁니다. 그런데 Lenny's Podcast에서 Lazar의 이야기를 듣고 나서 생각이 완전히 달라졌어요. 그가 실제로 하는 일을 보면, 이게 왜 가능한지 답이 보이거든요.

잠깐, "바이브 코딩이 뭔가요?"라고 물어보실 분들을 위해서요. 한 줄로 정리하면 이렇습니다. 코드를 직접 쓰는 게 아니라, AI에게 "이런 걸 만들어줘"라고 말로 설명해서 소프트웨어를 만드는 방식이에요. 마치 요리사한테 "오늘은 가볍고 상큼한 게 당기는데"라고 말하면 메뉴를 제안받는 것처럼요. 코딩을 몰라도, 원하는 걸 언어로 표현할 수 있으면 누구나 시작할 수 있습니다. Lazar는 그 "누구나" 중 한 명이었고, 18개월 만에 그 분야의 전문가가 됐습니다. 18개월 동안 무슨 일이 있었는지, 하나씩 뜯어보겠습니다.

코딩을 몰라서 오히려 할 수 있었던 것들

Lazar의 이야기에서 가장 먼저 눈에 들어오는 건, 기술적 배경이 전혀 없다는 거예요. 보통은 약점이라고 생각하겠죠. 그런데 그가 실제로 해낸 일들을 보면, 오히려 그 빈칸이 무기가 됐다는 걸 알 수 있어요. 개발자들이 "이건 복잡해서 시간이 오래 걸려"라고 멈추는 지점에서, 그는 그냥 AI에게 물어봤습니다. 당연하다는 듯이.

"불가능하다"를 모르니까 시도했다

Lazar가 Lovable을 처음 만진 건 18개월 전이었습니다. 기술 경력은 없었어요. 대신 기술적 선입견도 없었습니다.

크롬 익스텐션, 데스크톱 앱, 네이티브 영상 생성 기능. Lovable에서 이런 것들을 처음 만들어낸 건 전부 "기술자가 아닌 사람들"이었다고 Lazar는 Lenny's Podcast에서 이야기합니다. 개발자였다면 "그건 기술적으로 까다로운 부분이 있어서"라든가 "원래 그렇게 쉽게 되는 게 아닌데"라는 식으로 머릿속에서 먼저 벽을 쌓았을 거예요. 기술적 배경이 없는 사람은 그 벽 자체가 보이지 않으니까, 일단 시도합니다. 그리고 되면 됐고, 안 되면 다른 방법을 물어봅니다. 단순하죠.

아이디어를 프로토타입으로 만드는 데 걸린 시간은 4시간이었습니다(Lenny's Podcast 인터뷰 기반). 기존 방식대로라면 기술팀에 말로 설명하고, 이해시키고, 우선순위를 조율하는 데만 1-2주가 걸릴 작업이었어요. 단순히 빠르다는 이야기가 아닙니다. 이 속도 차이는 "일단 해보자"와 "나중에 해보자" 사이의 차이입니다. 전자는 실행이고, 후자는 대부분 포기로 끝나요.

저도 호기심에 비슷한 도구를 만져봤거든요. "이런 것도 돼?" 싶은 순간이 진짜 오더라고요. 완벽하진 않았지만, 뭔가 작동하는 걸 눈앞에서 보는 순간은 짜릿해요.

"이런 아이디어, 접어두셨던 거잖아요"

Lovable 같은 도구로 만들 수 있는 것들을 나열해 볼게요. 웹사이트, 모바일 앱, 크롬 익스텐션, 간단한 데이터베이스가 연결된 서비스, 특정 업무를 자동화하는 도구. 기술적인 설명을 다 걷어내면 결국 이런 것들입니다. "우리 팀 회의록을 자동으로 정리해주는 도구", "내가 읽은 책을 기록하고 친구랑 공유할 수 있는 페이지", "우리 가게 예약을 받을 수 있는 간단한 사이트". 이런 아이디어, 한 번쯤 있어보셨죠? 근데 "만들 수 없으니까"라고 접어두셨던 거잖아요.

Lazar도 그런 사람이었습니다. 차이가 있다면, 그는 "만들 수 없으니까"라는 전제 자체를 의심했다는 것이에요. 개발자에게 아이디어를 설명하면 "그거 복잡한 거예요"라는 말을 들었던 경험이 있지 않나요. 진짜 복잡한 건지, 그냥 시간이 오래 걸리는 건지, 아니면 우선순위가 밀린 건지. Lazar는 구분할 수 없었어요. 그래서 그냥 AI에게 직접 물어봤습니다. 복잡하다는 말을 듣기 전에.

지금은 Lazar가 아는 범위에서 S&P 500 기업 중 상당수가 어떤 형태로든 Lovable을 쓰고 있다고 해요(Lenny's Podcast 인터뷰, Lazar 본인 추정치). 익명을 요청한 한 대기업은 기존 CRM과 CMS 시스템을 Lovable로 전면 이전하면서 전담 바이브 코더 3명을 따로 두고 있다고 했어요. 리드쉐어링, 통신, 헬스케어, 금융 같은 업종의 선도 기업들이 엔터프라이즈 플랜을 쓰고 있고요.

채용 시장에서도 변화가 일어나고 있습니다. 이력서 대신 Lovable로 만든 앱을 제출해서 합격하는 사례가 나오기 시작했어요. Lazar 자신이 그 첫 번째 사례였고, Lovable의 머치 스토어도 그가 직접 바이브 코딩으로 만들었습니다. Shopify 연동까지 포함해서요. 개인의 이야기에서 산업의 이야기로 번지기 시작한 거죠.

그런데 여기서 솔직한 이야기를 하나 해야 할 것 같습니다.

"누구나 만들 수 있다"는 말에는 함정이 하나 숨어 있었습니다.

명확하지 않으면, 쓰레기를 더 빠르게 만들 뿐이다

여기까지 읽으면서 "나도 당장 시작해야겠다"는 생각이 드셨을 수 있어요. 그 감각은 좋은 겁니다. 그런데 Lazar가 Lenny's Podcast에서 털어놓은 이야기를 들으면, 조금 다른 그림이 보이기 시작합니다. "누구나 만들 수 있다"는 건 사실이에요. 하지만 "누구나 잘 만들 수 있다"와는 완전히 다른 문장입니다.

저도 이 부분에서 "아차" 싶었어요.

지니에게 소원을 빌 때 생기는 일

Lazar는 이런 비유를 씁니다. 지니에게 소원을 빌 때 "키가 커지고 싶다"고 하면 어떻게 될까요. 지니는 당신을 4미터 키로 만들 수 있습니다. 소원은 들어줬지만, 당신이 원한 건 그게 아니었겠죠. 정확히는 "모델처럼 보이고 싶다", "자신감 있게 보이고 싶다", 아니면 "좋아하는 사람 앞에서 더 돋보이고 싶다"였을 텐데, 그 진짜 의도를 표현하지 못했으니까요.

AI가 정확히 이렇게 작동합니다. 원하는 것을 정확하게 표현하지 못하면, AI는 엉뚱한 답을 빠르고 자신 있게 내놓아요.

실제로 어떤 느낌인지 상상해볼게요. "화면이 예뻤으면 좋겠어"라고 말하면, AI는 배경색을 분홍색으로 바꾸거나 폰트를 크게 만들 수 있어요. 하지만 당신이 원한 건 아마 "사용자가 처음 들어왔을 때 신뢰감이 느껴지는 디자인"이었겠죠. 그 차이가 결과물을 완전히 갈라놓습니다. Lazar가 세련된 배경 하나를 만들기 위해 레이어를 50개까지 쌓고 각각에 다양한 불투명도를 적용한다는 이야기를 들었을 때(Lenny's Podcast 인터뷰 기반), 저는 취향이라는 게 이렇게까지 복잡한 건가 싶었어요. 근데 그게 바로 "예쁘게 해줘"와 "이 정도 수준의 완성도로 만들어줘" 사이의 차이입니다.

두 가지 벽, 하나만 우리가 넘을 수 있다

바이브 코딩에는 벽이 두 개 있습니다. 첫 번째는 기계적 한계예요. AI가 한 번에 기억할 수 있는 양이 제한돼 있거든요. 대화가 길어질수록 AI가 초반에 한 설명을 잊어버립니다. 이건 지금 기술로는 어떻게 할 수 없어요. 두 번째는 인간적 한계, 즉 명확성(Clarity)의 부족입니다. 이건 100% 우리가 통제할 수 있어요.

Lazar 본인도 이 함정에 깊게 빠진 적이 있습니다. 오픈AI 이미지 API를 활용한 기능을 만들려다 1주일을 통째로 낭비한 일이 있었어요(Lenny's Podcast 인터뷰 기반). 매일 시도하고, 실패하고, 다시 방법을 바꿔보고. 그러다 알고 보니 그 시점에는 아직 해당 API 자체가 공개되지 않은 상태였습니다. 먼저 "이게 지금 가능한가?"를 한 번만 확인했다면 1주일을 다른 데 썼겠죠. 잘못된 방향으로 빠르게 달리는 것만큼 허탈한 일이 없네요. Lazar는 이 경험을 두고 "불가능은 가능의 타이밍 문제"라는 교훈을 얻었다고 했어요.

비슷한 경험 있으신 분 있을 거예요. 저도 한번 AI한테 "이거 만들어줘" 하고 3시간을 날린 적이 있거든요. 알고 보니 제가 원하는 게 뭔지 제대로 설명을 안 한 거였어요.

명확성이 없던 시절의 Lazar는 AI를 그냥 '빠른 도구'로 썼습니다. 아이디어가 떠오르면 바로 입력하고, 결과가 마음에 안 들면 또 입력하고. 그 루프가 생각보다 훨씬 많은 시간을 잡아먹었더라고요. 지금의 Lazar는 달라요. AI를 쓰기 전에 먼저 생각하는 시간을 삽니다. 뭘 만들고 싶은지, 왜 만들고 싶은지, 어떤 상태가 되면 완성인지를 먼저 적어둬요. 그 차이 하나가 전부를 바꿔놓은 거죠.

솔직히 저도 이 이야기를 들으면서 좀 쫄렸어요. 바이브 코딩을 해보려다가, 명확성 없이 달려들면 시간만 날리는 거잖아요.

그렇다면 명확성은 어떻게 만들어지는 걸까요.

Lazar가 빠져나온 방법을 들으면, 고개를 끄덕이게 됩니다.

실행 전에 80%를 생각에 씁니다

근데요, 이게 처음엔 반직관적으로 느껴집니다. 빠르게 만드는 게 바이브 코딩의 핵심 아닌가요? 그런데 Lazar의 시간 배분은 정반대예요. 계획과 대화에 80%, 실제 실행에 20%를 씁니다(Lenny's Podcast 인터뷰 기반). 왜냐하면 준비가 부실할수록 수정이 늘어나고, 수정이 늘어날수록 AI가 맥락을 잃어버리기 때문입니다. 처음부터 정확하게 말할수록 결과가 처음부터 맞게 나와요. 그러면 수정 루프가 짧아지고, 전체 시간이 줄어듭니다.

이 80%의 시간을 어디에 쓰는 걸까요. Lazar가 처음부터 체계적인 시스템을 갖고 있었던 건 아닙니다. 오히려 반복된 실패에서 하나씩 깨달은 거예요.

입력부터 치던 시절

솔직히 저도 이 부분 들으면서 찔렸습니다. 저는 보통 생각나면 바로 입력부터 치거든요. Lazar도 처음엔 그랬대요.

처음에는 아이디어가 떠오르면 바로 AI에게 입력했습니다. "이런 앱 만들어줘." 결과물이 나왔는데, 어딘가 어긋난 거예요. 수정을 요청하면 AI가 이전에 합의한 내용을 까맣게 잊어버리더라고요. 대화가 길어질수록 방향이 흐려졌습니다.

그래서 Lazar는 처음부터 전체적인 그림을 하나의 문서로 적어두기 시작했습니다. 이 앱이 존재하는 이유, 누가 쓸 건지, 완성됐을 때 어떤 느낌이어야 하는지. 그는 이걸 마스터플랜이라고 불러요. 나침반 같은 역할이죠.

마스터플랜이 생기니까 다음 문제가 보이기 시작했죠. 한 번에 전부 만들려고 하면 AI도, 자기도 헷갈리더라고요. 어떤 순서로 만들 건지 정리하는 게 필요했습니다. "먼저 로그인 화면, 그 다음 메인 페이지, 마지막으로 저장 기능"처럼 작은 단위로 쪼개서 순서를 매기는 구현계획이 두 번째 문서가 됐어요.

그런데 순서대로 만들어도 결과물이 뭔가 안 예뻤습니다. "심플하고 깔끔하게"라고 말하면 AI가 알아서 해주지 않더라는 거예요. "애플 웹사이트처럼 여백이 많고, 버튼 색은 짙은 남색, 폰트는 이 정도 크기"라고 구체적으로 말해야 원하는 수준이 나왔어요. 그래서 CSS 참조까지 포함한 디자인 가이드라인이 세 번째 문서가 됐습니다.

마지막으로 Lazar가 깨달은 건, 만드는 사람의 시각과 쓰는 사람의 시각이 다르다는 거였어요. 누군가 처음 들어와서 뭘 보고, 어디를 누르고, 결국 어떤 행동을 하는지를 시나리오처럼 적기 시작했습니다. 사용자 여정이라는 네 번째 문서가 만들어진 이유입니다. 이 문서 하나로 "이 버튼이 여기 있으면 안 되겠다"는 판단을 실행 전에 할 수 있게 됐어요.

이 네 가지 문서, 즉 PRD(Product Requirements Document)가 모이면 AI에게 할 말이 정리됩니다. 그러면 AI는 이 문서들을 읽고 작업 목록을 알아서 만들어줘요. 그 상태가 되면 Lazar가 해야 할 일은 하나뿐입니다. "다음 작업 진행해." 에이전트가 알아서 순서대로 진행해요.

뭔가 깨졌을 때 Lazar가 하는 일

시스템이 갖춰져도 문제는 생기잖아요. 뭔가 잘못 만들어졌을 때, Lazar는 무작정 새로운 방법을 시도하지 않더라고요. 나름의 순서가 있었습니다.

먼저 AI에게 직접 고치도록 요청합니다. "이 부분이 이상한데, 원인을 찾아서 고쳐줘." 이게 안 되면 "어디서 문제가 생겼어?"라고 물어보면서 AI가 추적할 수 있도록 콘솔 로그를 추가하게 합니다. Lazar에 따르면 이 단계에서 99%가 해결돼요(Lenny's Podcast 인터뷰 기반). 로그를 채팅에 붙여넣기만 하면 AI가 원인을 찾아서 고쳐주거든요.

그래도 안 되면 다른 AI 도구로 코드 전체를 진단해봅니다. 마지막 수단은 문제가 생기기 전 버전으로 되돌린 뒤 프롬프트를 재정의하는 거예요. 기술 지식이 아니라 문제를 구체화하는 능력이 핵심인 겁니다.

디버깅 얘기는 여기까지고요. Lazar한테 하나 더 배운 게 있어요. 병렬 프로젝트 접근법입니다. 아이디어가 떠오르면 그냥 흘려보내지 않습니다. 그날 떠오른 생각을 짧게라도 적어두는 습관, Lazar는 이걸 브레인덤프라고 불러요. 생각의 조각들이 쌓이다 보면 어느 순간 하나의 프로젝트로 이어질 만큼 내용이 모입니다.

한 프로젝트에서 막히면 다른 프로젝트로 넘어가면 돼요. 막혀 있던 문제가 다른 프로젝트를 하다가 갑자기 풀리는 경험을 하게 되거든요. 뇌가 백그라운드에서 계속 돌아가고 있기 때문이에요. Lazar는 이 방식이 초반에 크레딧을 더 쓰는 것처럼 보이지만, 장기적으로는 비용을 크게 절약한다고 하더라고요(Lenny's Podcast 인터뷰 기반).

PRD를 만들고, 디버깅 순서를 밟고, 병렬 프로젝트를 돌리고. 결국 다 하나로 모이더라고요. 도구의 문제가 아니라, 사람의 문제라는 것.

더 좋은 AI가 나와도 달라지지 않는 것

많은 사람들이 "AI 모델이 더 똑똑해지면 이런 문제들이 다 해결될 거야"라고 생각합니다. 모델의 지능이 올라가면 명확하게 말하지 않아도 의도를 알아서 파악할 거라고요. Lazar의 생각은 달라요. 그가 팟캐스트에서 소개한 말이 하나 있습니다. "AI 모델의 천장은 모델의 지능이 아니라, 모델이 행동하기 전에 무엇을 보느냐다." 쉽게 말하면, 아무리 똑똒한 AI라도 잘못된 정보를 받으면 잘못된 결과를 낼 수밖에 없는 거네요.

그래서 Lazar는 코딩 실력보다 명확성과 판단력을 기릅니다. 이건 더 넓은 흐름과도 맞닿아 있어요. 엔지니어, 디자이너, PM이라는 세 역할의 경계선이 점점 흐려지고 있습니다.

예전에는 각각이 뚜렷하게 구분된 전문 영역이었죠. 코드는 엔지니어, 화면은 디자이너, 방향은 PM이 맡았습니다. 그런데 AI가 코드 작성과 디자인 실행을 도와주기 시작하면서, 세 역할의 경계가 뒤섞이기 시작했어요. Lazar가 정확히 그 겹치는 영역에 서 있는 사람이에요. 코드를 쓰지 않지만 제품을 만들고, 디자이너는 아니지만 50개 레이어의 배경을 쌓고, PM은 아니지만 사용자 여정을 설계합니다.

Lazar는 코딩이 앞으로 캘리그라피 같은 예술 영역으로 옮겨갈 거라고 보더라고요(Lenny's Podcast 인터뷰 기반). 코딩이 사라진다는 게 아닙니다. 누구나 하는 일상적인 기술에서, 고도의 전문성을 가진 예술의 영역으로 옮겨간다는 뜻이에요. 대신 모든 사람에게 더 중요해지는 건 감성 지능, 취향, 그리고 사람과 사람 사이의 상호작용입니다. AI가 아무리 발전해도 대체할 수 없는 것들이죠.

누구나 "그럭저럭 괜찮은" 결과물을 만들 수 있는 시대가 됐어요. 그렇기 때문에, 진짜 차이를 만드는 건 "월드클래스"를 만들 줄 아는 사람의 명확성과 판단력입니다. 그리고 그건 코딩 능력이 아니라, 자기 자신과 먼저 대화하는 습관에서 시작돼요.

이 말이 무섭기도 하고 설레기도 하더라고요. 결국 도구는 누구나 쓸 수 있으니까, 차이를 만드는 건 사람의 판단력이라는 거잖아요.

명확성, 판단력, 취향. 18개월 동안 쌓아올린 것들의 이름이에요.

이력서를 열지 말고, 아이디어를 여세요

다시 그 면접 장면으로 돌아가 볼게요. 면접관 앞에 앉아 Lovable 앱을 켜던 그 순간, 그가 무서웠을까요. 아마도요. 하지만 그는 이미 몇 달 동안 이 방식으로 살아왔기 때문에, 두려움보다 확신이 더 컸습니다. 수십 개의 아이디어를 시도했고, 여러 번 실패했고, 뭐가 되고 뭐가 안 되는지를 몸으로 익혔어요. 면접장에서 내민 앱 하나가 그 18개월의 압축이었습니다.

처음부터 완성도 높은 걸 만들려고 했다면, 그는 아직도 시작 못 했을 겁니다. 기술을 제대로 배우고, 코딩을 완전히 익히고, 포트폴리오를 쌓고, 그다음에 지원하려고 했다면요. 그 "준비가 끝난 다음에"는 보통 영원히 오지 않습니다.

솔직히 말하면, 이 말이 처음엔 조금 뻔하게 들렸습니다. 그런데 그의 이야기를 끝까지 듣고 나면 달라져요. 그가 말하는 "시작"은 거창한 게 아닙니다. 오늘 떠오른 아이디어를 두 줄로 적는 것도 시작이에요. 바이브 코딩 도구에 접속해서 뭔가를 입력해보는 것도 시작이고, 어설프게 만들어진 첫 번째 버전을 보는 것도 시작입니다. 그 작은 시작들이 쌓여서, 어느 날 면접장에서 앱을 꺼낼 수 있는 사람이 됩니다.

지금 머릿속에 아이디어 하나가 있다면, 오늘 브레인덤프를 해보시겠어요? 저도 어제 처음 해봤는데, 두 줄 적는 데 5분도 안 걸리더라고요. 거창하지 않아도 됩니다. 이런 게 있으면 좋겠다 싶었던 것 하나면 충분해요. 무엇이고, 누가 쓰면 좋을 것 같은지. 그 두 줄이 마스터플랜의 시작이에요. 적을 때, 뭘 만들고 싶은지보다 왜 만들고 싶은지를 먼저 적어보세요. 그게 Lazar가 18개월 동안 배운 것의 핵심이니까요.

제가 이 이야기에서 가장 오래 남은 말로 마무리할게요.

이 말이 위협이 아니라 초대처럼 들렸으면 합니다. 만드는 능력은 더 이상 코드를 아는 사람만의 것이 아니에요. 아이디어를 언어로 표현할 수 있는 사람, 원하는 것을 명확하게 설명할 수 있는 사람이라면 누구든 시작할 수 있습니다. 이력서 대신 앱 하나를 제출할 수 있는 사람이라면, 누구든 그 자리에 앉을 수 있어요.

이 글은 Lenny's Podcast — Lazar Jovanovic 인터뷰를 바탕으로 작성되었습니다.

정보 격차를 해소하기 위한 오픈채팅방을 개설했습니다.

유익한 정보를 전달드립니다. 😀 

https://open.kakao.com/o/gtzeeMji