익명 1인 개발자의 ERP 연동 SaaS: 직원 제로·광고비 제로로 MRR 약 300만 엔 — 최근 반년간 코드는 한 줄도 직접 쓰지 않았다

MRR 약 300만 엔. 직원 제로, 광고비 제로. 그리고 최근 반년간 코드를 한 줄도 손으로 쓰지 않았다. 2026년 3월 Zenn에 올라온 한 1인 개발자의 글은 이 세 가지 세트로 읽혔다. 소재는 화려한 AI 앱도 소비자용 서비스도 아니고, 레거시 ERP의 “광기 어린 XML 비동기 SOAP 인터페이스”를 현대적이고 스테이트리스한 RESTful JSON으로 변환하는 프록시 서버, 즉 기업 시스템의 배관이다.

먼저 밝혀 두면, 이 사례는 운영자도 서비스명도 공개되지 않은 익명의 자기 신고다. 숫자는 Zenn의 본인 글에 있는 것뿐이고, 외부에서 검증할 수단은 없다. 그럼에도 다루는 이유는, 이 글이 “AI로 코드를 쓰는 1인 개발” 논의에 수익 실수와 운영의 구체성을 갖춘 드문 샘플을 제공하기 때문이다. 이후의 숫자는 그 유보를 전제로 읽어 주기 바란다.

공개된 숫자와 구성

사업의 원형은 수년 전으로 거슬러 올라간다. 본인이 ERP 연동 안건에서 소모된 경험을 바탕으로, 같은 고통을 가진 개발자용 변환 레이어를 잘라냈다. 고객은 전 세계 개발자. 글에는 “미국 서해안의 담당자”가 레거시 ERP 환경의 긴급 대응으로 달려오는 모습이 그려진다. B2B지만 상담은 없고, 월 $30부터의 셀프서브로 판다.

고객 획득은 “에러 메시지” 잠복

광고비 제로로 MRR 300만 엔을 지탱하는 고객 획득은 결국 SEO지만, 노리는 키워드가 독특하다. 본인은 이를 “절망적인 에러 스택 트레이스”에 대한 잠복이라고 표현한다. 레거시 ERP와 씨름하는 개발자가 검색하는 것은 제품명이 아니라 눈앞에 뜬 에러 메시지 그 자체다. 그래서 Dev.to와 영어 블로그에 에러 메시지를 제목으로 삼은 기술 글을 두고, 말미에서 유료 솔루션으로 유도한다.

이 설계가 강한 것은 검색자의 과금 확도가 극단적으로 높기 때문이다. 에러로 업무가 멈춘 기업 담당자에게 월 $30는 의사결정 축에도 들지 않는다. 게다가 “레거시 ERP의 특정 에러”라는 검색 지면에는 경쟁 콘텐츠가 거의 없고, 도메인이 강한 대형 미디어가 진입할 동기도 없다. Microsoft 생태계의 틈새에서 연 $1M을 쌓아 올린 사례와 마찬가지로, 거대 플랫폼의 “아무도 줍지 않는 불편”을 줍는 구조다.

“코드를 쓰지 않는” 운영의 내용

이 글이 널리 읽힌 가장 큰 이유는 AI 운영에 대한 파고든 기술이다. 본인 말로는 최근 반년간 “에디터를 열어 인간이 직접 입력하는 종래의 코딩 작업 따위 1초도 하지 않았다”. 터미널에서 Claude Code를 호출해 요건과 사양을 문장으로 건네고, 테스트 코드 생성과 자동 수정 루프를 돌린다. 에러 감시도 자동화된 봇이 분석과 수정까지 맡는다.

주의할 점은 이것이 “AI가 제로에서 사업을 만들었다”는 이야기가 아니라는 것이다. 프로덕트 자체는 수년 전 본인이 만들었고, 시장과의 접점(어떤 에러가 검색되는가, 고객이 무엇에 돈을 내는가)도 인력의 시행착오로 확립돼 있었다. AI가 대체한 것은 사양이 굳은 성숙 프로덕트의 유지보수·개수라는, AI에 가장 맞는 공정이다. 같은 솔로 SaaS라도 10년째 혼자 운영되는 Healthchecks가 창업자 수작업의 축적으로 성립하는 것과 대조적으로, 이 사례는 “성숙 후의 운영만 AI에 넘긴다”는 분업의 실례로 읽어야 한다.

운영 철학도 일관된다. 문의 폼은 폐지, 해지는 1클릭. 인간이 개입하는 접점을 의도적으로 지우고, 사용자가 스스로 완결할 수 있는 UI에 맞춘다. 서포트에 인력을 쓰지 않는 전제여야 직원 제로의 B2B가 성립한다.

걸러 읽어야 할 점

반복하지만 이 사례의 최대 약점은 검증 불능성이다. 익명·서비스명 비공개인 이상 MRR 300만 엔을 뒷받침할 대시보드도 제3자 보도도 없다. Zenn이라는 기술자 커뮤니티에 공개됐고 기술 구성과 운영 기술에 정합성이 있다는 점은 방증은 되지만 증명은 아니다. 본 미디어의 게재 기준으로는 본인 공개(primary)로 분류되지만, 실명·실서비스로 숫자를 내는 사례보다 한 단계 낮은 확도로 다루는 것이 타당하다.

사업 구조상의 리스크도 본인 기술에서 읽어낼 수 있다. 레거시 ERP 시장은 축소가 완만할 뿐 성장 시장이 아니며, 변환 프록시는 본가가 API를 현대화하는 순간 존재 의의를 잃는다. 고객 획득이 SEO 하나뿐이라는 점은 검색 알고리즘과 AI 검색으로의 노출 변화에 취약하다. “AI가 모든 코드를 쓰는” 운영은 모델과 도구의 가격·품질 변동이라는 신종 의존을 사업에 들여온다. 직원 제로의 가벼움은, 이것들이 현재화됐을 때 상의할 상대도 없다는 것과 동전의 양면이다.

재현의 조건과 한계

다른 솔로 개발자가 가져갈 수 있는 것은 세 가지다. ① B2B의 “고통 주도” 니치, 그것도 담당자가 에러 메시지로 검색할 만큼 구체적인 고통, 는 광고 제로·영업 제로의 셀프서브와 궁합이 가장 좋다. ② AI 코드 생성이 가장 잘 듣는 곳은 신규 개발이 아니라 사양이 굳은 성숙 프로덕트의 유지보수다. ③ 서포트를 인력으로 받지 않는 설계(자기 완결 UI·1클릭 해지)는 솔로 B2B의 전제 조건이다. 개발자 도구를 MRR $50K의 라이프스타일 비즈니스로 키운 사례와도 통하는, “개발자가 개발자에게 파는” 유형의 교과서적 구성이라 할 수 있다.

한계도 명확해서, 이 유형은 “수년 전 자신이 고생한 기업 시스템의 고통”이라는 진입 자산을 가진 사람에게만 열려 있다. 고통의 해상도가 니치 선정과 SEO 글의 설득력을 결정하기 때문이다. 그리고 익명 사례인 이상 숫자 자체를 재현 목표로 삼아서는 안 된다. 여기서 가져가야 할 것은 300만 엔이라는 금액이 아니라, 고통의 구체성·셀프서브·AI 유지보수라는 조합의 설계도다.