직장 다니며 혼자 SaaS, 주말 배치와 에이전트 4역

본업이 있는 엔지니어 한 명이 멀티테넌트 AI 에이전트 플랫폼을 혼자 만들어 운영한 과정을 공개했다. 서비스 이름은 아울링크(Aulinq). 8월 1일 공개된 이 회고에서 저자가 강조한 것은 코딩 속도가 아니라 작업을 시간대별로 나누고 AI 에이전트에게 역할을 쪼개 맡긴 운영 방식이다.

무슨 일인가 / 배경

아울링크는 텔레그램·왓츠앱·웹챗에서 고객 문의에 응답하고, 대화를 실제로 처리할 수 있는 가장 저렴한 모델로 라우팅하며, 테넌트별로 토큰을 센트 미만 단위까지 과금하고, 각 테넌트의 데이터와 비밀키를 서로 격리한다. 그 위에 세 갈래 제품이 얹힌다. 대행사가 고객사에 되파는 화이트라벨, 스타트업이 자사 제품에 끼워 넣는 API, 그리고 인프라 지식 없이 봇 하나만 원하는 1인 창업자를 위한 단일 테넌트 진입로다. 운영 구성은 여러 개의 Go 서비스와 포스트그레스 하나, 레디스 하나, 낫츠 제트스트림(NATS JetStream) 메시지 버스다.

저자는 "SaaS는 포화됐고 AI가 해자를 없앴다"는 진단에는 대체로 동의하면서 결론에는 반대한다. 가장 먼저 죽는 것은 모델 위에 예쁜 랜딩 페이지를 얹은 껍데기이며, 남는 것은 지루하고 베끼기 어려운 하부 인프라라는 것이다. 멀티테넌시, 과금, 비용 통제, 비밀키 처리, 재전송 상황에서의 멱등성 같은 작업은 모델이 똑똑해졌다고 해서 싸지지 않았다.

핵심 짚어보기

혼자서 이걸 어떻게 굴리느냐는 질문에 저자는 두 가지를 든다. 첫째, 혼자 코딩하기를 그만두고 계획·구현·리뷰·검증 네 역할의 에이전트 팀을 지휘하는 방식으로 바꿨다. 각 역할은 자기 컨텍스트와 자기 도구를 갖는다. 둘째, 하루 한 시간씩 쪼개는 방식을 버렸다. 평일 밤 한 시간은 변경분을 검토하거나 계획을 승인하거나 검증이 도는 것을 지켜보기에는 충분하지만, 기술 스택을 조사하거나 아키텍처를 설계하거나 어긋난 서비스를 되돌리기에는 부족하다. 그런 일에는 끊기지 않는 시간 덩어리가 필요했고, 저자에게 그것은 토요일이었다. 주말 배치는 사고하는 작업, 평일 밤은 확인하고 병합하는 작업. 이를 섞으면 화요일 밤 11시에 덜 조사된 기술 결정을 내리게 된다는 것이 그가 피하려던 실패 모드다.

기술 선택의 기준도 통상과 다르다. AI 코딩 도구에 스택을 물으면 가장 인기 있는 답이 돌아오지만, 사람에게 읽기 쉬운 것과 에이전트에게 읽기 쉬운 것은 다르다. 에이전트는 튜토리얼이 많은 생태계에서 이득을 보지 않는다. 이미 다 읽었기 때문이다. 대신 실수를 거부하는 타입 시스템, 시끄럽게 실패하는 런타임, 잘못될 여지가 적은 배포 산출물에서 이득을 본다. 그래서 Go가 선택됐다. 에이전트가 이벤트 구조체에 필드를 추가하고 소비자 쪽 갱신을 잊으면 빌드가 깨진다. 파이썬이었다면 소비자가 조용히 빈 값으로 역직렬화하고 문제는 운영 환경에서 발견된다. 대가도 명확하다. 파이썬 머신러닝 생태계에 직접 접근하지 못하고 모든 모델 호출이 HTTP를 거친다.

같은 기준이 아래층에도 적용됐다. 메시지 버스는 카프카 대신 낫츠 제트스트림을 골랐는데, 주제 기반 라우팅은 에이전트가 추론할 수 있는 문자열인 반면 스키마 레지스트리를 낀 방식은 에이전트가 틀리기 쉬운 빌드 단계이기 때문이다. 저장소는 도메인별 스키마를 둔 포스트그레스 한 대로 통일했다. "에이전트가 통째로 읽을 수 있는 데이터베이스 하나"가 각자 마이그레이션 도구를 가진 열 개보다 낫다는 판단이다. 중요한 결정마다 그는 한 번의 질문이 아니라 네댓 번의 조사 루프를 돌렸다. 넓게 훑고, 살아남은 두세 개로 좁히고, 각각을 정독하고, 다른 모델로 교차 검증하는 순서다.

1인기업 실전 적용 포인트

• 주중과 주말의 작업 종류를 아예 분리하라. 평일 밤에는 승인·검토·발행처럼 30분이면 끝나는 일만 배치하고, 조사와 설계는 주말 한 덩어리로 몰아라. 일정표에 '토요일 오전 = 결정하는 시간'을 고정 블록으로 넣는 것만으로 밤 11시의 즉흥적 결정이 줄어든다.
• 역할별 프롬프트를 네 개 만들어 두라. 하나의 만능 지시문 대신 계획용·실행용·검토용·검증용 프롬프트를 파일로 저장해 두고 순서대로 호출하면, 같은 모델로도 결과 품질이 달라진다.
• 중요한 결정은 다른 모델로 교차 확인하라. 도구 선택이나 가격 정책처럼 되돌리기 비싼 결정은 한 모델의 답을 다른 모델에게 반박시켜 보는 절차를 넣는다. 한 번 묻고 끝내는 것보다 느리지만, 넉 달 뒤 다시 만드는 것보다 빠르다.
• 팔리는 것은 껍데기가 아니라 배관이라는 점을 가격에 반영하라. 자동화 상품을 만들 때 눈에 보이는 화면보다 과금·중복 방지·실패 재시도·권한 격리 같은 부분에 시간을 쓰고, 그 부분을 설명 자료의 앞쪽에 배치하는 편이 유리하다.

전망 / 주의점

이 회고는 만능 처방이 아니다. 저자 스스로 "이미 유능한 엔지니어임을 전제한다"고 못 박았고, 에이전트는 판단을 대체하지 않고 증폭할 뿐이며 나쁜 판단도 똑같이 빠르게 증폭한다고 경고한다. 기술 스택 역시 LLM 라우팅 플랫폼이라는 성격에 맞춘 선택이라, 로컬 추론이나 무거운 전처리가 필요한 팀에는 그대로 적용되지 않는다. 다만 시간을 자산으로 쓰는 1인 사업자에게 참고할 지점은 분명하다. 문제는 도구가 몇 개냐가 아니라, 생각하는 시간과 확인하는 시간을 섞지 않는 규율이다.

출처: Aulinq 블로그 (https://www.aulinq.com/en/blog/build-distributed-saas-from-scratch-with-ai-agents)