아이디어를 8년 동안 품고만 있어본 적 있나요? "언젠간 만들어야지"라고 생각하면서, 매번 너무 어렵고, 너무 지루하고, 실패 리스크가 너무 크다는 이유로 미뤄온 그것. Google Perfetto 팀의 시니어 엔지니어 Lalit Maganti가 바로 그랬어요.
그런데 2025년 말, AI 코딩 에이전트를 써보면서 뭔가 달라졌어요. "이번엔 진짜 해볼 수 있겠다." 결과적으로 250시간, 3개월 만에 syntaqlite라는 SQLite 개발자 도구를 출시했어요. 근데 이 이야기가 진짜 흥미로운 건 — 성공 스토리가 아니라 실패와 재시작의 기록이라는 점이에요.
이게 뭔데?
Lalit Maganti는 Google에서 Perfetto라는 성능 분석 도구를 만들어요. 이 도구에는 SQLite 기반 쿼리 언어가 있는데, 사용자들이 점점 포매터, 린터, 에디터 확장을 요구하기 시작했죠. 문제는 기존 SQLite 도구들이 전부 불완전하거나 느리거나 유연하지 않았다는 것.
"그럼 처음부터 제대로 만들자"고 생각할 수 있지만, SQLite 파서를 처음부터 만드는 건 언어에 공식 스펙이 없고, 소스 코드가 극도로 복잡한 C로 작성되어 있어서 사이드 프로젝트로 하기엔 너무 어렵고 지루한 일이었어요. 400개 이상의 문법 규칙을 하나하나 정의해야 하고, 각각에 대한 테스트도 작성해야 하고, 버그도 수정해야 하고... 그래서 8년 동안 "하고 싶지만 못 하겠다"의 상태로 머물렀어요.
왜 이 이야기가 "비개발자"에게도 중요한가
이건 코딩 이야기처럼 보이지만, 본질은 다릅니다. "너무 어렵고 지루해서 미뤄온 프로젝트를 AI로 드디어 시작할 수 있게 됐다"는 이야기예요. 마케터의 자동화 시스템, 디자이너의 디자인 시스템, 기획자의 데이터 파이프라인 — 당신에게도 이런 프로젝트가 있지 않나요?
뭐가 달라지는 건데?
Lalit의 3개월은 크게 두 단계로 나뉘어요. 그리고 이 두 단계의 차이가 이 글의 핵심이에요.
1단계: 바이브 코딩 (1월) — 실패
2025년 크리스마스 연휴 동안 "Claude Code 맥스 플랜(월 200파운드)으로 전부 바이브 코딩할 수 있을까?"를 테스트했어요. 기술적 결정부터 구현까지 거의 전부를 AI에 맡기고, 본인은 "반기술적 매니저" 역할만 했죠.
결과? 기능적으로는 돌아갔어요. 파서, 포매터, 웹 플레이그라운드까지 나왔어요. 500개 넘는 테스트도 생겼고요. 하지만 1월 말에 코드를 자세히 리뷰해보니 — 완전한 스파게티였어요.
함수가 랜덤한 파일에 흩어져 있고, 파일 하나가 수천 줄이 되고, Python 추출 파이프라인은 본인도 이해할 수 없는 상태. 접근 방식이 유효하다는 건 증명했지만, 이 코드로는 절대 실제 사용자를 지원할 수 없었어요.
결국 전부 버리고 처음부터 다시 시작했어요.
2단계: 에이전틱 엔지니어링 (2~3월) — 성공
두 번째 시도에서 완전히 달라진 건 본인의 역할이에요:
| 1단계: 바이브 코딩 | 2단계: 에이전틱 엔지니어링 | |
|---|---|---|
| 인간의 역할 | 반기술적 매니저 | 설계자 + 리뷰어 |
| 설계 결정 | AI에게 위임 | 인간이 직접 |
| 코드 리뷰 | 최소한 | 모든 변경 리뷰 |
| 리팩토링 | "나중에 할게" | 매 배치 후 즉시 |
| AI 용도 | 모든 것 | 구현 + 리서치 + 반복 작업 |
| 결과 | 스파게티 코드 → 전면 폐기 | 출시 가능한 제품 |
Simon Willison이 정리한 에이전틱 엔지니어링 개념이 정확히 이거예요. Andrej Karpathy가 만든 "바이브 코딩"이 코드를 잊어버리는 거라면, 에이전틱 엔지니어링은 AI가 코드를 쓰되, 인간이 설계하고 검증하고 방향을 잡는 것이에요.
핵심만 정리: AI로 미뤄둔 프로젝트 시작하는 법
프로토타입은 바이브 코딩으로, 프로덕션은 절대 안 된다
첫 단계에서 AI에게 "이거 가능해?"를 검증받는 건 훌륭한 전략이에요. Lalit도 바이브 코딩 1개월이 접근 방식의 유효성을 증명해줬다고 말해요. 하지만 그 코드를 프로덕션에 쓰려는 순간 무너져요. 프로토타입 ≠ 프로덕션.
설계는 반드시 인간이 한다
AI는 "이 함수를 이렇게 구현해줘"에는 탁월하지만, "이 API가 사용자에게 좋은 경험을 줄까?"에는 형편없어요. 아키텍처, 공개 API, 사용자 경험 — 이건 "객관적으로 검증 가능한 정답"이 없는 영역이고, AI가 가장 못하는 영역이에요.
리팩토링을 습관처럼 해라
AI가 코드를 산업적 규모로 생성하면, 리팩토링도 산업적 규모로 해야 해요. 안 하면 즉시 통제 불능이 돼요. Lalit는 "모든 대량 생성 배치 후에 ‘이거 못생겼나?’를 자문했다"고 말해요. AI가 못 보는 큰 추상화는 인간이 방향을 잡고, 실행은 AI에게 맡기세요.
AI를 리서치 어시스턴트로 활용해라
Lalit가 AI에서 가장 ROI가 높았다고 말한 건 코드 생성이 아니라 리서치예요. 모르는 알고리즘을 배우는 데 하루 이틀 걸릴 걸 한 시간 대화로 압축. VS Code 확장 API를 처음 배우는 데 걸릴 하루를 1시간으로 단축. 익숙하지 않은 영역의 진입 장벽을 극적으로 낮춰요.
"슬롯머신 중독"을 경계해라
"한 번만 더 프롬프트해볼게" — AI 코딩의 가장 위험한 함정이에요. 피곤할 때 프롬프트는 모호해지고, 결과는 나빠지고, 더 시도하고, 더 피곤해지는 악순환. 이럴 때는 AI 끄고 직접 쓰는 게 빨라요. AI 사용에도 에너지 관리가 필요해요.
METR 연구가 보여주는 불편한 진실
METR의 2025년 RCT 연구에 따르면, 숙련된 오픈소스 개발자가 AI 도구를 사용했을 때 오히려 19% 느려졌어요. 더 놀라운 건? 개발자들은 본인이 20% 빨라졌다고 믿었어요. Lalit의 경험과 정확히 일치해요 — AI는 "빨라진 느낌"을 주지만, 설계 부채와 이해도 상실이라는 보이지 않는 비용이 있어요.
더 깊이 파고 싶다면
Eight years of wanting, three months of building with AI — Lalit Maganti의 풀 회고록. 프로젝트 저널과 커밋 히스토리까지 증거로 제시하는 진솔한 기록.
Agentic Engineering Patterns — Simon Willison이 정리한 AI 코딩 에이전트 활용 패턴. 바이브 코딩과 에이전틱 엔지니어링의 차이를 명확하게 구분해요.
METR: Measuring AI Impact on Developer Productivity — "AI 도구가 숙련 개발자를 19% 느리게 만든다"는 RCT 연구. 체감 속도와 실제 속도의 괴리를 데이터로 보여줘요.
Karpathy's Vibe Coding vs Agentic Engineering — 바이브 코딩을 만든 Karpathy도 인정하는 한계. 재미용 vs. 프로덕션용의 차이.
