왜 나는 일반적인 길을 가지 않았을까?

Source: Dev.to

무엇이 걸려 있는가

수익 압박, 눈에 보이는 영향, 그리고 현재 트렌드를 타고 싶어 하는 압력이 있습니다. Microsaas는 많은 인디 개발자들에게 지름길이 되었습니다: 가벼운 제품, 구독, 성장. 반면에 AI 에이전트와 에이전시 워크플로우가 주목받고 있습니다 — AI가 단순 보조자가 아니라 코드를 읽고, 기능을 구현하고, PR을 여는 자율적인 인력이라는 개념입니다. 2025‑2026년에는 이것이 단순 실험을 넘어 구체적인 제품 및 포지셔닝 옵션이 되었습니다.

이것이 잘못된 것은 아닙니다. 선택의 문제일 뿐입니다. 제가 명확히 하고 싶은 것은 Schepta의 경우 왜 다른 길을 선택했는가 입니다.

에이전트보다 기반, 가격보다 가치

어느 순간 여러분도 저와 같은 상황을 보았을 것입니다: 개발자들이 microsaas를 출시하고, 다른 사람들은 모든 것을 에이전트로 자동화하며, 이 길에 올라서지 않으면 돈을 놓치고 있다는 느낌을 받게 됩니다.

저는 두 가지 길을 모두 고려했습니다.

• Microsaas는 가치가 입증되기 전에 계약, 가격, 그리고 벤더 락‑인을 요구합니다. 스키마를 실제 UI로 변환하고, 여러 프레임워크에서 안정적으로 동작하게 하는 문제와 같은 경우—이는 아직 시점이 이른 마찰입니다. 가치는 먼저 입증되어야 하고, 비즈니스 모델은 그 뒤에 따라옵니다.
• Agents도 비슷한 매력을 가집니다: 인터페이스 생성을 자동화하는 것이 명백한 다음 단계처럼 보이죠. 하지만 UI를 생성하거나 변경하는 에이전트는 작동하기 위한 안정적인 기반—백엔드, 에이전트, 프론트엔드 사이의 명확하고 감사 가능한 계약—이 필요합니다. 이 기반 없이 에이전트를 먼저 구축하는 것은 취약합니다. 순서가 중요합니다: 먼저 엔진이 잘 동작하고, 그 다음에 에이전트가 의존할 기반이 생깁니다.

하지만 안정적인 기반을 만들려면 비용이 듭니다: 검증이 필요합니다. 폼과 흐름이 깨지면 사용자와 비즈니스에 직접적인 영향을 미치며—이는 미션‑크리티컬 문제입니다. Schepta에 100개가 넘는 유닛 테스트와 E2E 테스트가 존재하는 이유도 바로 이것입니다: 엔진이 충분히 신뢰할 수 있어야 확장·기여·프로덕션 사용 시 놀라움이 없기 때문입니다.

그리고 저는 이 길을 선택했습니다; 올바른 선택인지 아닌지는 시간이 말해줄 것입니다.

이 논의가 여러분에게 의미가 있었다면, Schepta의 문서와 예제는 schepta.org에서 기다리고 있습니다.

여러분은 어떠신가요: microsaas 길을 가고 있나요, 에이전트를 쓰고 있나요, 아니면 다른 무언가를 만들고 있나요? 의사결정에 어떤 기준을 두었나요?

다음 단계

시리즈 다음 글에서는 AI가 인터페이스를 생성할 때: 스키마를 가드레일로 라는 주제로, 생태계(json‑render, A2UI)가 이 접근법을 어떻게 검증하는지, Schepta가 AI의 비결정성 문제에 어떻게 대응하는지, 그리고 코드 보조 단계에서 에이전트를 통한 100 % 자동화 단계까지 어떻게 흐름에 맞춰지는지를 다룰 예정입니다.