에이전시 수익으로 AI 제품 만든 창업자: pre.dev가 $500k ARR을 달성한 서비스→제품 전환 공식

VC 투자 없이, 에이전시 수익으로 AI 제품을 만들어 연 $500k(약 7억원) ARR을 달성한 창업자가 있습니다. Arjun Jain과 공동창업자 Adam이 만든 AI 엔지니어링 플랫폼 pre.dev의 이야기입니다. 이 케이스가 주목받는 이유는 숫자 때문만이 아닙니다. 에이전시와 제품을 어떻게 연결했는지, 그 구조 자체가 교과서이기 때문입니다.

 

---

💡 1. 에이전시→제품 플라이휠의 구조

 

Arjun은 개발 컨설팅 에이전시를 운영하면서 두 가지 반복되는 고통을 목격했습니다. 창업자들이 수개월과 수천만 원을 들여 MVP를 만든 뒤 아무도 원하지 않는다는 걸 발견하는 사이클, 그리고 에이전시 내부에서 단 한 줄의 코드도 쓰기 전에 스코핑과 예산 산정에 소모되는 시간. "매번 같은 프로세스였고, 자동화되어야 할 것처럼 느껴졌다."

① 에이전시 운영 → 실제 프로젝트 수행 (수익 발생)

② 내부 효율화를 위한 AI 스코핑 툴 개발

→ R&D 비용: 에이전시 수익이 부담

③ 에이전시 효율 상승 → 더 많은 프로젝트 = 더 많은 학습 데이터

④ AI 정확도 상승 → 독립 제품으로 스핀오프

⑤ 에이전시 고객이 첫 번째 유료 사용자

"에이전시가 R&D 비용을 댔고, R&D가 에이전시를 더 강하게 만들었다.
그 플라이휠이 핵심이다." — Arjun Jain

이 구조의 핵심은 수년간 실제 클라이언트를 위해 실제 프로젝트를 스코핑하고 납품한 데이터가 쌓였다는 점입니다. "그 데이터셋이 우리 에이전트를 시니어 엔지니어처럼 기획하게 만드는 이유다. 그것이 진짜 해자다."

 

---

🤖 2. 바이브 코딩이 아닌 에이전틱 엔지니어링

 

Lovable·Replit·Cursor 같은 도구들은 코드를 생성합니다. Arjun은 이렇게 말합니다. "모든 AI 코딩 툴은 실제 프로젝트가 되는 순간 무너진다. 코드는 생성하지만 아무도 믿거나 배포할 수 없는 코드다. 아무도 '실제 엔지니어'를 만들고 있지 않았다."

바이브 코딩 툴

아이디어 → 코드 (직접)
프로토타입에는 좋음
실제 프로젝트에서 한계 발생

pre.dev (에이전틱)

아이디어 → 아키텍처 스펙 → 코드
컴파일러의 중간 표현(IR) 방식
PR 단위 자율 배포

핵심 기술 인사이트는 "스펙을 컴파일러 패스처럼 다루는 것"입니다. 컴파일러가 소스코드에서 기계어로 직접 가지 않는 데는 이유가 있습니다. 중간 표현(IR)을 거쳐야 최적화와 검증이 가능합니다. pre.dev는 같은 원리를 소프트웨어 개발에 적용했습니다.

또 다른 차별점은 격리된 태스크 컨텍스트 시스템입니다. 전체 코드베이스를 하나의 컨텍스트 윈도우에 넣는 대신, 각 코딩 태스크를 독립된 Docker 컨테이너에서 실행합니다. 에이전트가 자신이 만든 것을 스크린샷 찍어 인수 기준과 대조하고, GitHub 레포에 닿기 전에 모든 것을 검증합니다. 이 덕분에 사람의 개입 없이 수 시간 또는 수일 동안 단일 프로젝트를 작업할 수 있습니다.

 

---

📊 3. 실제 작동한 성장 채널

 

$500k

ARR (월 $42k)

10,000+

사용 창업자 수

36일

초기 제품 배포까지

① 아웃바운드 세일즈 (초기 핵심)

→ 프로젝트 최소 금액이 높은 개발 에이전시 타겟팅. "거칠고 수동이었지만 최고의 고객들이 실제로 필요로 하는 것을 가르쳐줬다."

② 콘텐츠 (복리 채널)

→ "허영을 위한 사고 리더십이 아니다. 우리 세계관을 문서화하는 것이고, 그것을 공유하는 사람들을 끌어당긴다."

③ 입소문 (최근 가장 큰 드라이버)

→ "실제 제품을 배포하는 순간 사람들이 이야기한다. 그 검증은 빠르게 퍼진다."

④ 파트너십

→ Google for Startups Cloud Program으로 Kubernetes 기반 인프라 비용 지원. "자율 에이전저를 스케일하는 것은 비싸다."

 

---

✅ 4. 지금 당장 적용할 수 있는 Arjun의 5가지 조언

 

1. 사람들에게 실제로 결제하게 하라

→ "꼭 사겠다"는 말이 아니라 실제로 신용카드를 꺼내게 하는 것만이 유의미한 검증이다. 단기 프로모 코드로 마찰을 낮추되 결제는 필수로.

2. 당혹스러울 만큼 구체적인 틈새를 선택하라

→ "소프트웨어를 빌드하는 모든 사람"이 아닌 매우 구체적인 고객 프로필로 시작하라. 모호한 포지셔닝의 희석은 되돌릴 수 없다.

3. 몇 달이 아닌 몇 주 안에 배포하라

→ 첫 버전은 거칠었다. 하지만 유료 고객 앞에 있었다. 가상 요구사항 대신 실제 사용 기반으로 매주 더 좋아졌다.

4. 제품 작업 뒤에 숨지 마라

→ "기술 창업자들이 불편하기 때문에 영업을 피한다. 하지만 초기 대화들이 어떤 양의 빌딩보다 더 많은 것을 가르쳐준다."

5. 실제로 자신이 사용하는 것을 빌드하라

→ "우리는 pre.dev를 사용해 pre.dev를 매일 빌드한다. 귀여운 창업자 이야기가 아니다. 우리의 가장 중요한 제품 피드백 메커니즘이다."

 

---

💬 에필로그

 

pre.dev의 성장은 "고객이 R&D 비용을 댔다"는 단순한 구조에서 나왔습니다. 에이전시 수익으로 툴을 만들고, 그 툴이 에이전시를 더 강하게 만들고, 그게 다시 더 좋은 제품을 만드는 플라이휠. VC 자금 없이도 이 구조가 작동했습니다.

에이전시나 프리랜서 업무를 하면서 제품을 꿈꾸는 창업자라면, 지금 반복하는 업무 중에 툴로 만들어볼 것이 없는지 돌아보세요.

 

🔎 원문에서 더 확인하세요

pre.dev 기술 구조, 성장 채널, 한국 시장 시사점까지 원문에서 확인하세요.

👉 전문 보기: 바로가기

📊 데모데이 | 창업 정보 플랫폼

창업·사업정보, BM분석, 펀딩인사이트, 채용공고, 15,000개+ 스타트업 정보까지
창업자와 예비창업자를 위한 모든 정보가 한 곳에.

👉 https://demoday.co.kr