같은 AI SaaS 스택을 반복해서 연결하는 것이 지겨워서 — 그래서 나는 그 순환을 끊었다

Source: Dev.to

AI 제품을 만들 때 모두가 겪는 문제

대부분의 텍스트‑투‑이미지 데모는 겉보기엔 간단해 보입니다: 프롬프트를 보내면 됩니다.
하지만 이를 실제 SaaS로 전환하려고 하면 상황이 금방 복잡해집니다:

• 오래 실행되는 작업이 요청을 차단함
• 전통적인 요청/응답 방식에 맞지 않는 모델 실행
• 생성물을 저장할 깔끔한 장소가 없음
• 자동화 로직이 여기저기 흩어짐
• 마지막에 이메일 워크플로우를 억지로 붙임

결과적으로 제품 로직보다 글루 코드에 80 % 정도의 시간을 소비하게 됩니다.

내가 선택한 다른 길

다시 처음부터 시작하는 대신, 이렇게 스스로에게 물었습니다:

“이 문제를 한 번만, 제대로 해결한다면 어떨까?”

다음 몇 가지 원칙에 집중했습니다:

• AI 생성은 비동기‑우선으로 다루기
• 모델 실행을 완전히 분리된 형태로 유지하기
• 데이터베이스 + 자동화를 옵션이 아닌 기본으로 만들기
• 이메일과 워크플로우는 첫날부터 필요하다고 가정하기

이 사고방식을 잡고 나니 모든 것이 자연스럽게 맞아떨어졌습니다.

작지만 중요한 기술적 전환

모델 실행을 요청이 아니라 작업으로 다루세요.

// pseudo example
await enqueueGeneration({
  prompt,
  model,
  userId
});

UI는 기다리지 않습니다. 이 한 가지 결정만으로도 복잡성이 크게 줄어들었습니다.

오늘 다시 시작한다면 다르게 할 점

AI‑기반 무언가를 만들고 있다면:

• 프로덕션이 비동기라면 동기 흐름으로 프로토타입을 만들지 말 것
• “이후에 이메일을 추가한다”는 생각을 버릴 것 — 이메일은 항상 필요함
• 인프라 반복 작업에 드는 시간을 과소평가하지 말 것
• 영리함보다 반복 속도를 최적화할 것

대부분의 번아웃은 제품 자체가 아니라 같은 기반을 반복해서 재구축하는 데서 옵니다.

마무리 생각

나는 또 다른 스타터 킷을 만들고 싶어서 이걸 만든 것이 아닙니다.
보이지 않는 같은 부분을 계속 재구축하는 것이 지겨워서 만들었습니다.

공개적으로 AI 제품을 만들고 있다면, 언제든지 의견을 나눠요 👋