Lovable 밸류 두 배, 우리가 다시 써야 할 채용 기준

숫자가 말하는 것

$13.2B. 6개월 만에 두 배.

Menlo Ventures가 이끄는 $3억 라운드가 성사되면, Lovable은 "자연어로 앱을 찍어내는 도구"로는 역사상 가장 비싼 회사 중 하나가 된다. 이 숫자를 보고 "또 AI 거품"이라고 넘기는 게 편하다. 그러기엔 실제 성장 속도가 너무 이상하다.

Lovable(전 GPT-Engineer)은 런칭 후 수개월 만에 $50M ARR을 달성했다. 전통적인 B2B SaaS라면 5~7년은 걸릴 숫자다. 투자자들이 흥분한 게 아니라, 실제 사람들이 돈 내고 쓰고 있다는 증거다. 비개발자가 자연어로 앱을 만들고, 그 결과물을 실제 서비스에 올리는 경험이 시장에서 수익화되고 있다.

이게 작은 팀인 우리에게 중요한 이유는 하나다. 우리가 지금 채용하려는 역량의 정의가 통째로 바뀌고 있다는 것. 단, 이 변화를 어떤 방향으로 읽느냐에 따라 다음 채용이 자산이 될 수도, 낭비가 될 수도 있다. 함정은 생각보다 미묘하다.

Vibe Coding이 일상이 되면 생기는 일

Andrej Karpathy가 2025년 초 "vibe coding"이라는 단어를 꺼냈을 때, 많은 시니어 개발자가 코웃음 쳤다. 코드는 정밀하게 짜야 하고, AI는 환각을 일으키고, 결국 사람이 다 고쳐야 한다는 논리였다.

그 단어는 이제 기업 전략 문서에 올라가 있다.

개념 자체는 간단하다. 코드를 처음부터 직접 타이핑하지 않는다. 원하는 기능을 설명하고, AI가 생성한 코드의 방향을 잡고, 결과물을 검증한 뒤 배포한다. Lovable 사용자 커뮤니티를 보면 기존 3인 팀 2주 작업을 1인 이틀로 줄였다는 보고가 실제로 나온다. 10배 생산성 향상이 마케팅 과장처럼 들리지만, 프로토타입 수준에서는 달성 가능한 수치다.

여기서 채용 기준이 흔들리기 시작한다. "코드를 잘 쓰는 사람"의 희소성이 줄어든다. 대신 "AI가 만든 코드를 제대로 읽고, 우리 시스템 컨텍스트에서 무엇이 위험한지 포착하는 사람"의 가치가 올라간다. 채용 공고에 "Python 5년 이상"을 적는 것이 곧 의미 없어질 수 있다는 얘기다.

트레이드오프: 빠른 것과 안전한 것

수치를 하나 보자. 2023년 Stanford 연구에서 GitHub Copilot이 생성한 코드의 약 40%에 CWE(Common Weakness Enumeration) 기준 보안 취약점이 포함됐다. Lovable 같은 풀스택 생성 도구는 Copilot보다 훨씬 넓은 영역 — 인증, DB 연결, API 설계, 배포 설정 — 을 한 번에 커버한다. 취약점이 노출될 표면이 훨씬 넓다는 뜻이다.

빠르게 만드는 건 된다. 만들어진 것을 믿을 수 있느냐는 다른 문제다.

이건 "AI가 실수한다"는 얘기가 아니다. 프로토타입과 프로덕션의 요구사항이 근본적으로 다르다는 얘기다. Lovable로 사흘 만에 만든 앱이 그럴듯하게 돌아가더라도, 실제 서비스에 올리는 순간 운영 환경의 제약 — idle connection timeout, 트랜잭션 격리, 예외 처리 — 이 하나씩 터진다. 우리 팀도 이 패턴을 실제로 경험했다. 2026년 6월 kpopdex 서비스에서 DB 연결이 조용히 끊기다 쿼리마다 폭사한 사고가 정확히 이 종류의 문제였다. LLM 호출 사이 수 분 idle 동안 연결이 끊겼는데, 코드는 "돌아가는 것처럼" 보였다.

이 맥락에서 인공지능 윤리 소통채널이라는 개념이 실무적으로 등장한다. AI가 생성한 코드의 책임 소재, 리뷰 프로세스, 이상 발생 시 첫 번째 연락을 받을 사람 — 이것들을 구조화하는 것이다. 도구를 도입하는 결정과 그 도구의 출력을 신뢰하는 결정은 전혀 다른 레이어다. 후자를 팀 내에서 명문화하지 않은 채 Lovable 같은 도구를 쓰기 시작하면, 속도는 올라가되 책임 소재가 안개 속에 있는 상태가 된다.

우리 팀이라면 채용 기준을 어떻게 바꿀까

HEDVION 팀에 다음 개발자를 뽑는다면, JD를 지금 당장 어떻게 다시 써야 할까.

첫째, 코딩 테스트보다 코드 리뷰 테스트를 본다. 알고리즘 최적화 문제를 주는 게 아니라, AI가 짜준 코드 100줄을 주고 "이 중 문제가 있는 부분을 찾고 이유를 설명하라"고 한다. 코드가 돌아가는 것처럼 보이지만 특정 조건에서 터지는 지점을 찾는 능력을 본다.

둘째, AI 도구 사용 이력을 포트폴리오로 요구한다. "Cursor나 Claude Code 써봤나"가 아니라 "어떤 상황에서 AI 도구를 쓰고, 어떤 상황에서 수동으로 짜는가"를 설명할 수 있는지 확인한다. 도구에 맹목적으로 의존하는 사람과, 도구의 한계를 알고 선택적으로 쓰는 사람의 채용 결과는 완전히 다르다.

셋째, 도메인 컨텍스트 흡수 속도를 본다. AI 도구의 역량은 빠르게 범용화되지만, 우리 발행 파이프라인의 구조, 사이트별 콘텐츠 제약, DB 스키마 패턴은 외부 도구가 대체하지 못한다. 이 컨텍스트를 빠르게 흡수해 AI 출력을 우리 시스템에 맞게 검증하는 사람이 실질적으로 가장 생산성이 높다.

실제 시나리오로 말하면 이렇다. 신규 봇을 하나 추가한다고 하자. Lovable이나 Claude Code로 기본 구조를 하루 만에 뽑을 수 있다. 문제는 그 다음이다. 공용 DB 헬퍼 적용, 글자수 게이트 코드 삽입, Discord notify 연결, cron 등록 — 이 중 어느 하나도 우리 컨텍스트 없이는 AI가 제대로 안내하지 못한다. 그 간극을 메우는 사람이 지금 우리에게 필요한 사람이다.

내재화할 것과 채용할 것의 분리

모든 걸 채용으로 해결하려 하면 안 된다. 규모가 큰 팀도 빠지는 함정이다.

Lovable이 $13.2B을 향한다는 건, AI 코딩 도구의 역량이 빠르게 상품화된다는 뜻이기도 하다. 오늘 채용한 "AI 도구 능숙자"의 기술적 우위가 1~2년 안에 반감될 수 있다. Lovable 다음 버전이 나오면, 그 사람이 알던 방법론이 outdated가 된다.

반면 도메인 지식은 그렇지 않다. 발행 파이프라인 구조, DB 연결 패턴, 검수 흐름, 각 사이트의 콘텐츠 제약 — 이건 팀 안에서 쌓고 내재화해야 하는 종류다. 외주나 도구로 빠르게 커버할 수 있는 게 아니다.

그래서 작은 팀의 채용 전략은 양분된다. 도구 사용 역량은 채용 조건으로 보되, 채용 후 기대치를 높게 두지 않는다 — 빠르게 배우고 빠르게 적응하면 된다. 반면 도메인 이해, 시스템 판단력, 코드 리뷰 역량은 채용 단계에서 깐깐하게 봐야 한다. 이건 단기간에 올리기 어렵다.

지금 바로 쓸 수 있는 것들

채용 공고를 당장 고친다면, "Python N년 이상" 조건을 "AI 도구 포트폴리오 + 코드 리뷰 샘플 제출"로 교체한다. 기술 과제에 AI 생성 코드 디버깅 문제를 하나 추가한다. 알고리즘 문제는 그 다음이다.

팀 내 역량을 점검한다면, 현재 팀원 중 AI 도구 없이 평소 속도의 절반을 낼 수 있는지 확인한다. 의존도가 너무 높으면 도구 오류를 잡는 능력도 같이 낮아져 있을 가능성이 크다.

프로세스를 만든다면, AI 생성 코드가 프로덕션에 올라가는 흐름을 명문화한다. "이 코드는 누가 짰고, AI 도움을 어느 수준까지 받았는가"를 추적하는 내부 기준이 지금 우리 팀에 있는가. 없다면, Lovable 같은 도구를 팀에 도입하기 전에 먼저 만들어야 한다. 인공지능 윤리 소통채널은 거창한 개념이 아니다. 사실 이 수준의 프로세스 문서화에서 시작한다.

Lovable이 결국 거품으로 꺼질지, 개발 생태계를 재편하는 인프라로 자리잡을지는 아직 모른다. $13.2B이라는 숫자가 있는 한, 이 방향의 변화는 이미 현실이다. 도구는 계속 바뀐다. 판단은 여전히 사람의 몫이다. 그 판단을 잘 하는 사람을 뽑는 기준을 지금 다시 쓰지 않으면, 다음 채용이 지난 채용의 실수를 반복한다.

원문: AI News & Artificial Intelligence | TechCrunch