한 번 만들고 영원히 돌아가는 Async AI 자동화
대부분의 AI 자동화 데모는 즉각적인 결과를 보여준다. 버튼 클릭, LLM이 2초 안에 응답, 마법처럼 보인다.
실제 프로덕션 시스템은 그렇게 작동하지 않는다.
AI 자동화 파이프라인을 출시하면 실제로 일어나는 일: rate limit, API timeout, edge case에서 LLM hallucination, 새벽 3시에 아무도 모르는 사이 쌓이는 queue. "마법"이 깨지고, 새 기능 만드는 대신 주말을 디버깅에 쓴다.
해결책은 더 좋은 프롬프트가 아니다. 아키텍처다.
Sync vs Async: 잘못된 기본값
대부분의 개발자는 동기 AI 파이프라인을 기본으로 선택한다. 추론하기 쉽기 때문이다.
유저 요청 → LLM 호출 → 응답 → 완료
단순하다. 깔끔하다. 취약하다.
하루 수백 개의 요청, 배치 작업, 스케줄 작업 같은 실제 부하가 더해지는 순간 sync가 무너진다. LLM API에는 rate limit이 있다. 네트워크 호출은 실패한다. 복잡한 작업은 10-30초가 걸린다.
Async 파이프라인은 모델을 뒤집는다:
유저 요청 → Queue → Worker가 처리 → LLM 호출 → 결과 저장 → 유저 알림
초반엔 더 복잡하다. 하지만 프로덕션에서 훨씬 탄탄하다.
Micro-SaaS에 Async가 선택이 아닌 이유
AI 위에 Micro-SaaS를 만든다면 async는 선택이 아니라 비즈니스 모델이다.
콘텐츠 리퍼포징 도구를 생각해봐라. 유저가 블로그 포스트를 올리면 5개의 플랫폼별 출력물을 기대한다. LLM 호출 5번, 각각 10-20초. 총 최대 100초.
Sync 방식: 유저가 100초 동안 로딩 스피너를 본다. 30%가 탭을 닫는다. 서버는 그동안 블락된다.
Async 방식: 유저가 제출하고 "처리 중... 완료되면 알려드릴게요"를 본다. 서버가 job을 queue에 넣는다. Worker가 자체 속도로 처리하고, 완료되면 webhook이나 이메일을 보낸다. 유저가 돌아오면 결과가 기다리고 있다.
같은 컴퓨트 비용. 하지만 10배 더 좋은 경험이고, 무한히 확장되고, API 문제가 생겨도 유저가 모른다.
최소한의 Async 스택 구축
Kafka나 분산 메시지 브로커가 없어도 된다. Micro-SaaS 규모에서 작동하는 lean 스택:
Queue: BullMQ 같은 Redis나 AWS SQS 같은 managed queue. Redis는 월 100만 job 미만에 좋다. SQS는 무한정 확장된다.
Worker: queue를 폴링하고 job을 실행하는 단순한 Node.js나 Python 프로세스. 웹 서버와 별도 서비스로 실행한다.
Storage: job 결과를 데이터베이스 (Postgres, SQLite)에 job ID와 함께 저장한다. 유저가 폴링하거나 webhook/이메일로 알림을 받는다.
Retry 로직: 모든 job이 실패 시 재시도해야 한다. LLM API 호출은 실패한다. 네트워크는 끊긴다. exponential backoff로 자동 재시도하면 사람 개입 없이 일시적 에러의 95%를 처리한다.
실패 모드와 처리 방법
LLM rate limit: 429 응답을 catch하고 delay를 줘서 job을 재queue해라. 유저에겐 invisible하게.
나쁜 LLM 출력: 모든 LLM 호출 후 validation을 실행해라. 출력이 품질 체크를 통과 못 하면 수정된 프롬프트로 재시도해라. 실패를 로깅해서 프롬프트를 지속적으로 개선해라.
Queue 적체: Worker가 뒤처지면 job이 쌓인다. 모니터링을 추가하고 (queue 깊이 100개 이상에서 알림) Worker를 수평 확장해라.
24/7 매출 기계
Async가 가능하게 하는 비즈니스 인사이트가 있다.
파이프라인이 사람 개입 없이 안정적으로 돌아갈 때, Micro-SaaS는 내가 자는 동안 돈을 번다.
서울 시간 새벽 2시에 베를린 유저가 job을 제출한다. Queue가 받는다. Worker가 처리한다. 유저가 결과와 함께 이메일을 받는다. 개입 없이.
그게 Micro-SaaS의 꿈이고, async 아키텍처로만 가능하다. Sync 시스템은 실패를 감시하는 사람이 필요하다. Async 시스템은 우아하게 실패하고 자동으로 복구한다.
진화 경로
첫날부터 완벽한 async 시스템을 만들 필요 없다:
- MVP: Sync 파이프라인, 10명 유저, 깨지면 수동으로 재시작
- 초기 제품: Job queue 추가, 기본 retry 로직, 이메일 알림
- 확장: 모니터링, 여러 Worker, 품질 검증, 알림
- 성숙: 수평 확장, dead letter queue, SLA 보장
대부분의 Micro-SaaS는 3단계 전에 죽는다. 초기에 오버엔지니어링하지 마라. 하지만 경로를 이해하고 그쪽으로 만들어라.
Async 마인드셋은 AI 도구에 대한 생각을 바꾼다. "얼마나 빠르게 응답하는가"에서 "얼마나 안정적으로 완료하는가"로. 안정성이 복리로 쌓인다. 안정성이 유지율이다. 유지율이 매출이다.