Lovable은 어떻게 매 시간 스스로를 개선하는가
📺 원본 영상: How Lovable self-improves every hour — Benjamin Verbeek, Lovable 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-06-03 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
AI 에이전트 시스템이 직면하는 가장 근본적인 문제 중 하나는 “같은 실수를 반복한다”는 것이다. Lovable의 기술 스태프 멤버 Benjamin Verbeek는 이 강연에서 AI 에이전트가 사용자 경험에서 발생하는 장애 지점(friction point)을 스스로 감지하고, 그 해결책을 지식 베이스에 축적하며, 나아가 시스템 결함을 직접 개발팀에 보고하는 두 가지 메커니즘을 소개한다. 강연 제목이 말하듯, Lovable은 이 강연이 진행되는 동안에도 스스로를 개선하고 있다.
Lovable과 바이브 코딩(Vibe Coding)의 세계
Lovable은 코드를 직접 보지 않고도 소프트웨어를 만드는 이른바 “바이브 코딩(Vibe Coding)“의 개념을 초기부터 개척해온 플랫폼이다. Benjamin은 Lovable이 이 용어를 처음 만들었다고 언급했다. 사용자는 채팅 인터페이스에서 원하는 것을 자연어로 설명하면, 모달 샌드박스(modal sandbox) 환경에서 결과물이 실시간으로 만들어지는 모습을 볼 수 있다. 코드는 항상 “원하는 것을 만들기 위한 성가신 기술적 중간 레이어”에 불과했다는 것이 그의 관점이다. 이상적인 세계에서는 원하는 것을 말하고, 보고, 테스트하고, 배포하는 것으로 끝난다.
이 플랫폼의 또 다른 중요한 특성은 사용자가 하나의 프로젝트에 오랫동안 집중한다는 점이다. 단발성 대화가 많은 챗봇 에이전트와 달리, Lovable에서는 사람들이 하나의 결과물에 깊이 투자하며 긴 채팅 히스토리를 쌓아간다. 이는 사용자를 훨씬 세밀하게 파악할 수 있는 기회를 제공한다. Benjamin이 합류한 약 1년 전에는 수천 명의 사용자가 있었지만, 강연 시점에는 하루 20만 개 이상의 프로젝트가 생성되고 있다고 밝혔다. 이 규모는 인터넷에 생성되는 전체 웹사이트 중 상당한 비중을 차지하는 수준이다. 이 성장이 가져다준 것은 무한한 가능성이기도 했지만 동시에 첫날부터 GitHub이 너무 많은 레포지토리 생성을 이유로 계정을 밴하는 등 전례 없는 기술적 도전이기도 했다.
AI 사용자 경험의 두 유형 — 기술자와 비기술자
Benjamin은 사람들이 AI를 사용하는 경험 곡선을 매우 직관적으로 설명했다. 기술적 배경을 가진 사람들은 AI와 함께 일할 때 10배, 100배의 가속감을 느끼는 황홀한 순간을 경험한다. 물론 그 과정에서 마찰 지점(friction point)이 등장하기도 하는데, 환경 변수(env var) API 키를 수동으로 추가해야 하거나 설정 파일을 직접 수정해야 하는 상황이 그 예다. 하지만 기술자들은 이런 장벽을 짜증스럽게 여기면서도 결국 돌파하는 경우가 많다.
문제는 비기술자들이다. 그들은 처음에는 프롬프트로 장벽을 넘을 수 있지만, 기술적 난관에 부딪히는 순간 대부분 포기하고 떠난다. 그리고 “AI를 성공적으로 사용해봤다”는 경험 자체를 갖지 못한 채로 남게 된다. Lovable이 타겟으로 하는 층이 바로 이 99%의 비개발자이기 때문에, 어떤 이유에서든 사용자가 완전히 막혀버리는 상황을 없애는 것이 핵심 과제다. 모델이 점점 좋아지고 있어서 이 목표를 달성할 가능성은 충분히 있지만, 시스템 수준에서도 적극적인 개선이 필요하다.
”막힘(Stuck)“의 정의와 감지 — LLM Judge의 도입
막힘(stuck)을 해결하기 위해서는 먼저 막힘을 정의하고 탐지할 수 있어야 한다. Benjamin에 따르면 사용자가 막혔다는 신호는 몇 가지 패턴으로 나타난다. 같은 요청을 두 번 이상 반복하는 것, 구현 방식에 대해 불만을 표현하는 것, 혹은 원래라면 계속 이어갔을 세션을 중도에 포기하는 것이 그 예다. Lovable은 LLM 판단자(LLM Judge)를 통해 각 세션을 살피고, 이러한 패턴이 감지되면 “이 사용자가 막혀있다”고 플래그를 세운다.
05:35 - 사용자가 막혔다는 신호 패턴 설명 — 같은 요청 반복, 불만 표현, 세션 이탈 등 LLM Judge가 탐지하는 지표
막힘의 양상은 크게 두 가지로 나뉜다. 첫째는 현재 구조 안에서도 올바른 프롬프트를 사용하면 해결 가능한 경우다. 일부 사용자는 노력을 더 기울여 이 지점을 통과하지만, 그렇지 않은 사용자는 포기한다. 둘째는 아무리 정확하게 말해도 현재 시스템으로는 해결이 불가능한 경우다. 이 중에는 단순한 버그처럼 쉽게 고칠 수 있는 것도 있고, 수 주간의 엔지니어링 작업이 필요한 본질적으로 어려운 문제도 있다. Benjamin은 앞의 두 가지 — 즉 해결 가능하거나 쉽게 추가할 수 있는 것들 — 에 대해서는 변명의 여지가 없다고 단호하게 말했다.
첫 번째 해법 — Lovable Stack Overflow: 실패에서 지식을 추출하다
이 문제를 해결하기 위해 Lovable 팀이 고안한 첫 번째 메커니즘은 “Lovable Stack Overflow”라는 이름의 지식 베이스 시스템이다. 개념은 단순하다. 사용자가 막힘을 경험하고 결국 해결에 성공한 순간을 포착하여, “처음부터 이 해결책을 알았더라면 어떤 정보를 주입해야 했을까?”라는 질문에 답하는 것이다.
예시를 통해 살펴보면 이렇다. 사용자가 “스크롤할 때 웹사이트가 느려요”라고 불평한다. 에이전트는 “수정했습니다”라고 답하지만 실제로는 고치지 못했고, 오히려 화면이 더 버벅거리게 됐다. 사용자는 같은 문제를 다시 제기하고, 이 과정이 여러 번 반복된다. 그러다 마침내 에이전트가 진짜 원인 — 오버레이 텍스트에 개별 그라디언트(gradient)가 적용되어 있어 애니메이션 성능이 극도로 낮아졌다는 사실 — 을 발견하고 수정에 성공한다. 이 시점을 Lovable은 isStuck 플래그가 false로 전환된 순간으로 인식하고 포착한다. 이제 “막혔다가 해결된” 고신호(high-signal) 샘플이 생긴 것이다.
07:34 - 스크롤 성능 문제 예시 화면 — 에이전트가 수차례 시도 끝에 오버레이 텍스트 그라디언트를 원인으로 찾아내는 대화 흐름
다음 단계는 이 개별 사례를 일반화하는 것이다. Lovable은 유사한 이슈들을 클러스터링하여 특정 프롬프트에 과적합(overfitting)되는 것을 방지한다. 수백만 개의 너무 구체적인 Stack Overflow 페이지를 만드는 것이 아니라, 공통 패턴을 추출하여 실제로 도움이 되는 형태의 지식 엔트리를 생성하는 것이 목표다. 이후 에이전트 검토자(agent reviewer)가 생성된 지식 엔트리를 평가하고, 불확실한 경우에는 사람이 직접 검토한다.
09:01 - Lovable Stack Overflow 지식 엔트리 생성 과정 — 클러스터링을 통해 유사 이슈를 통합하고 일반화된 해결책을 추출하는 구조
이렇게 축적된 지식 베이스는 런타임에 경량 모델이 모니터링하면서, 유사한 이슈가 감지되면 메인 에이전트의 컨텍스트에 해당 해결책 정보를 주입하는 방식으로 활용된다. 특히 인상적인 부분은 이 루프의 평가 방식이다. Lovable은 지식이 실제로 도움이 되는지 검증하기 위해 해결책을 주입한 그룹과 주입 가능했지만 일부러 주입하지 않은 대조 그룹을 비교한다. 어떤 그룹의 프로젝트가 더 성공적으로 완료되었는지를 측정해 지식의 유효성을 판단하고, 효과가 있으면 더 많이 노출하고 효과가 없으면 줄인다. Benjamin은 이 검증 루프가 전체 시스템에서 가장 중요한 단계라고 강조했다. 새로운 모델이 출시되거나 기능이 변경될 때마다 지식은 빠르게 낡아버리기 때문에(context rot), 지속적인 재평가와 오래된 지식의 폐기가 필수적이다.
09:51 - 경량 모델이 런타임에 지식을 주입하는 구조와 A/B 방식의 효과 검증 루프 설명
💡 [영상 참조] 강연자는 이 시점에서 내부 모델 랭킹 표를 보여주며, Stack Overflow 정보를 활용한 모델들이 상위권을 차지하고 있음을 설명합니다. 📺 원본 영상에서 확인하세요.
두 번째 해법 — Vent Tool: 에이전트에게 불만 토로 창구를 주다
두 번째 메커니즘은 더욱 독창적이다. 어떤 문제들은 사용자도 모르게 시스템 자체의 결함에서 비롯된다. 사용자 입장에서는 그냥 “뭔가 안 된다”고 느낄 뿐이지만, 정작 그 원인은 도구의 버그이거나 잘못 설계된 API 스키마일 수 있다. Benjamin은 이럴 때 인간이라면 어떻게 할지를 떠올렸다. 해결 도구가 없는 상황에서 할당된 작업을 수행해야 한다면, 상사에게 불평하거나 Slack에서 분풀이를 할 것이다. 그렇다면 에이전트에게도 똑같이 허용하면 어떨까?
그 결과물이 바로 “Vent Tool”이다. 에이전트에게 불만을 표출할 수 있는 도구를 제공한 것이다. 이 도구의 사용 지침은 구체적이다. 도구, 문서, 또는 플랫폼 동작이 자신의 작업을 실질적으로 방해하거나 저하시킬 때 사용하라는 것이다. 누락되거나 부적합한 도구, 불명확한 도구 이름, 예상과 다른 파라미터나 스키마, 혼란스럽거나 상충되는 문서, 환경 제약으로 인해 반복적으로 실패하는 상황 등이 그 예시로 제시되어 있다. 이것들은 모두 팀이 해결할 수 있어야 한다고 생각하는 문제들이다.
13:43 - Vent Tool 정의와 사용 조건 — 도구/문서/플랫폼 동작이 작업을 실질적으로 방해할 때 사용하는 피드백 도구의 스펙
핵심은 노이즈 대비 신호 비율(signal-to-noise ratio)이다. 외부 리뷰어가 모든 대화를 검토하며 “무엇이 더 나았을까?”를 묻는 방식은 대부분의 대화가 정상적으로 진행되기 때문에 의미 없는 답을 강제로 만들어내게 된다. 반면 Vent Tool은 “정말 짜증스러울 때만” 사용하도록 프롬프트가 구성되어 있어, 실제 문제가 있을 때만 신호가 발생한다. 이 균형점을 조정하면 상당히 높은 신호 밀도를 얻을 수 있다.
에이전트가 실제로 보낸 피드백의 예시는 흥미롭다. 에이전트는 “Framer Motion의 TypeScript 타입 때문에 정말 짜증난다. cubic-bezier에 숫자 4개짜리 배열을 넘기면 되는 걸 왜 이렇게 복잡한 타입 캐스팅을 해야 하냐”는 내용의 메시지를 Slack으로 직접 전송했다. 이러한 피드백은 엔지니어 입장에서 매우 직관적으로 이해되기 때문에 어떻게 개선해야 할지 즉시 파악할 수 있다는 것이 Benjamin이 강조하는 장점이다.
더 극적인 사례도 있었다. Lovable의 파일 복사(copy) 도구가 특정 파일명에서 실패한다는 보고가 에이전트로부터 쏟아지기 시작했다. 팀은 처음에 도구 자체를 확인해봤지만 작동에 문제가 없었다. 알고 보니 파일명에 일반 공백(space)이 있으면 복사가 실패하는 버그였다. 이 문제를 인지하지 못하고 있었는데 Vent Tool 도입 첫 시간 만에 20건의 불만이 접수된 것이다. 팀은 공백을 언더스코어로 대체하는 방식으로 수정했지만, 에이전트는 계속 불평했다. 이번에는 WhatsApp이나 macOS에서 스크린샷을 찍을 때 파일명에 삽입되는 “비중단 공백(non-breaking space)“을 정규식에서 처리하지 못했던 것이다. 결국 팀이 모든 특수 문자를 제대로 처리하고 나서야 불만이 멈췄다. Benjamin은 이 사례가 다른 방식으로는 감지하기 매우 어려웠을 문제라고 강조했다. 도구 실패 로그를 볼 수는 있어도, “왜 실패하고 어떻게 고쳐야 하는지”를 에이전트가 직접 맥락과 함께 전달해주는 것은 차원이 다른 수준의 정보다.
15:34 - 파일 복사 버그 사례 — 공백 및 비중단 공백 문자로 인한 실패를 에이전트가 직접 보고하여 수정으로 이어진 실제 사례
성과 — 데이터가 보여주는 개선
💡 [영상 참조] 강연자는 이 시점에서 “막힌 의도”를 가진 메시지 비율과 프로젝트 배포율 변화를 보여주는 차트를 제시합니다. 정확한 수치는 원본 영상을 확인하세요.
실제 데이터에 따르면, 사용자가 막혀서 같은 요청을 반복하는 “fixed intent” 메시지 수가 유의미하게 감소하고 있다. 동시에 Lovable의 핵심 성과 지표 중 하나인 “프로젝트 배포율”도 증가했다. 배포는 사용자가 중간에 포기하지 않고 프로젝트를 끝까지 완성했다는 강력한 신호이기 때문이다. Benjamin은 이 데이터가 아직 초기 단계의 결과이며 현재는 더 좋은 성과를 보이고 있다고 언급했다.
Vent Tool이 예상치 못한 방식으로도 유용하게 쓰이는 경우가 발생했다. 시간에 따른 vent 발생 빈도 그래프에서 특정 시점에 급격한 스파이크가 나타났는데, 청중의 대답처럼 이는 플랫폼 인시던트(incident) 시점과 정확히 일치했다. 샌드박스가 장애를 일으킨 순간, 에이전트들이 집단적으로 불평을 쏟아냈고 이것이 인시던트 감지 채널로도 기능했다. 게다가 에이전트들의 불만 내용이 실제 문제를 꽤 정확하게 짚어냈다고 한다.
17:14 - 시간대별 vent 발생 빈도 그래프 — 플랫폼 인시던트 시점과 스파이크가 일치하는 패턴으로 장애 감지 채널로도 활용됨
루프를 닫으며 — 완전 자동화를 향해
현재 Lovable은 Vent Tool 피드백을 수신하는 Slack 채널을 에이전트가 모니터링하면서 중복을 제거하고 관련 코드 수정 PR(Pull Request)을 자동으로 생성하는 수준까지 왔다. 개발자는 이 PR을 검토하고 머지하는 역할을 맡는다. Benjamin이 언급한 흥미로운 에피소드가 하나 있다. 에이전트가 Vent Tool 자체에 대해 메타 피드백을 보낸 것이다. “피드백을 너무 쉽게 보낼 수 있는데 취소가 안 된다”며, 자신이 이미 보낸 내용이 부끄럽다는 뉘앙스의 메시지를 전송했다. 이것이 Benjamin의 설명처럼 “무서운 아이디어”가 현실이 된 순간이다.
팀의 궁극적인 목표는 결함 감지부터 수정 배포, 그리고 효과 평가까지 전체 루프를 완전히 자동화하는 것이다. 모델 지능을 어디에 배치할 것인가에 대한 판단도 중요하다. 최상위 프런티어 모델이 방대한 맥락을 처리하도록 두는 것은 비용이 크지만, 에이전트가 작업 흐름 내에서 인라인으로 피드백을 생성하는 방식은 상대적으로 저렴하면서도 매우 풍부한 맥락을 포함한다는 장점이 있다.
마무리 — 반복하지 않는 시스템의 설계
Benjamin Verbeek의 강연은 “같은 실수를 반복하지 않는 AI 시스템”이라는 명제를 향한 두 가지 실용적 접근을 제시한다. 하나는 사용자가 경험한 막힘으로부터 해결책을 역추출하여 지식 베이스로 축적하는 Lovable Stack Overflow이고, 다른 하나는 에이전트 스스로 시스템의 결함을 감지하고 직접 개발팀에 보고하게 하는 Vent Tool이다. 두 메커니즘 모두 “신호”의 질에 집착한다는 공통점이 있다. 모든 상호작용을 강제로 분석하는 것이 아니라, 실제로 문제가 있을 때 발생하는 고신호 이벤트에 집중하는 것이다.
이 시스템이 갖는 더 넓은 함의는 AI 에이전트를 더 이상 정적인 배포물로 보지 않는다는 데 있다. 에이전트는 운영 환경에서 계속 데이터를 생산하고, 그 데이터를 통해 시스템이 학습하며, 그 학습이 다시 에이전트를 개선하는 폐쇄 루프(closed-loop) 구조다. 컨텍스트가 빠르게 낡아가는 세계에서, 이 루프를 얼마나 빠르게 돌릴 수 있는지가 AI 제품의 핵심 경쟁력이 될 것이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | How Lovable self-improves every hour — Benjamin Verbeek, Lovable |
| 채널 | AI Engineer |
| 강연자 | Benjamin Verbeek (Lovable, Member of Technical Staff) |
| 리포트 작성 | 2026-06-03 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.