빌더 조쉬의 6단계 실험에서 가장 과소평가된 단계는 4번이다. “Hermes도 그냥 AI이기 때문에 코딩 도구가 할 수 있는 거의 모든 작업이 가능하다”는 한 문장이 build-vs-buy 의사결정 구조를 통째로 뒤집는다. 회사는 사내 ERP를 구매하지 않았다. 직접 만들었다. 그것도 그 ERP 데이터를 바탕으로 견적서와 세금계산서 발급까지 연결했다.
이건 단순한 자동화가 아니라 소프트웨어 조달 모델의 변화다. 전통적으로 작은 회사는 ERP·회계·견적 도구를 SaaS로 구독한다. 자기 워크플로우에 맞지 않아도 도구에 회사를 맞춘다. 그런데 깃헙과 Vercel이 연동된 코딩 가능 에이전트가 있으면, 회사가 도구에 맞추는 게 아니라 도구가 매일 회사에 맞춰 다시 만들어진다. “매일 새로운 소프트웨어를 직접 만들 수 있다”는 말은 과장이 아니라 운영 모드의 선언이다.
핵심 전제는 에이전트가 코딩 도구와 동급이라는 점이다. 별도의 노코드 플랫폼이나 SaaS 계약이 필요 없다. 회사 맥락을 이미 적재한 에이전트가 배포 파이프라인까지 손에 쥐면, 내부 도구의 한계 비용이 0에 수렴한다. 작은 회사일수록 이 레버리지가 크다 — 맞춰야 할 레거시도, 통과해야 할 구매 승인 절차도 없기 때문이다.
근거
“Hermes 에이전트도 그냥 AI이기 때문에 사실 코딩 도구가 할 수 있는 거의 모든 작업이 다 가능하다. 깃헙과 버셀이 연동되어 있기 때문에, 매일 새로운 소프트웨어를 직접 만들 수 있다.”
“우선 우리 회사는 사내 ERP를 직접 만들었고, 그 데이터를 바탕으로 견적서와 세금계산서를 발급할 수 있도록 우선했다.”
연결된 생각
- 20260528-ai-native-company-six-experiment-pattern — 이 노트는 그 6단계 중 4단계를 확대한 것
- 20260522-hermes-team-data-integration-pattern — 도구 제작은 데이터 적재가 선행된 뒤에야 의미를 가진다
- 20260515-one-person-company-is-real-when-process-is-programmable — 프로세스가 코드가 되면 도구 구매가 사라진다는 같은 원리
- 20260521-sell-ai-employee-not-ai-agent — 도구를 만드는 AI는 구독 도구가 아니라 직원에 가깝다