SaaS를 없애자 기능 요청이 6개월에서 몇 분으로 줄었다

Feature requests went from 6 months to minutes after we killed our SaaS URL: https://www.youtube.com/watch?v=zlD-CkLVKtU 날짜: 2026-10-14 채널: latentspacepod (Latent Space)

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI coding agents는 중간급 업무용 SaaS를 실제 사용자에게 맞게 빠르게 복제할 수 있지만, 제품을 소유하는 순간 구축보다 운영·책임·지속적인 검증이 더 중요한 일이 된다.==

• AI Engineer 컨퍼런스용 행사 소프트웨어의 연간 견적은 네 행사 기준 $43,000이었고, 기능 요청 반영에는 보통 3~6개월 또는 무기한이 걸렸다.
• 72개 팀이 실제 제품을 복제했으며, 최종 평가는 구현 방식이 아니라 비기술적인 행사 운영팀이 실제로 사고 쓸 수 있는지를 기준으로 이뤄졌다.
• 56개 앱을 자동 평가했지만 AI 평가 상위 10개 중 6개는 사람이 약하다고 평가했고, 최종 우승작은 AI 순위 19위였다.

중간급 업무 소프트웨어의 가치는 기능 목록을 복사하는 데 있지 않다. 서로 다른 역할과 포털을 연결하고, 애매한 UI 상태와 실제 운영 흐름을 다루며, 장애가 발생했을 때 사용자에게 책임을 전가하지 않는 전체 시스템을 만들어야 한다. Agents는 이 구축·수정 비용을 크게 낮추지만, 유지보수 책임까지 없애주지는 않는다.

1. $43,000짜리 SaaS를 죽이기로 한 배경

SaaS를 빌리는 비용과 느린 변경 주기가 개인화된 내부 소프트웨어를 직접 소유할 수 있다는 판단으로 바뀌었다.

1.1. 행사 운영 소프트웨어가 만든 비용 구조

1. AI Engineer의 운영 맥락

   1. 사업과 제품: 창업자는 Latent Space와 AI Engineer 두 사업을 운영하며, AI Engineer는 AI 업계 컨퍼런스를 연다.
   2. 기존 구매 방식: 행사와 플랫폼에 따라 수십 달러부터 수십만 달러까지 다양한 소프트웨어를 구매해 왔고, 특정 행사 운영 소프트웨어에는 네 행사 기준 연 $43,000의 견적을 받았다.

2. 변경 요청의 지연

   1. 느린 로드맵: 기성 SaaS에 change request를 넣으면 원하는 기능이 출시되기까지 3~6개월이 걸리거나 영영 반영되지 않았다.
   2. 사용하지 않는 기능까지 구매: 해당 공급자가 판매하는 기능 중 실제로 쓰는 것은 약 3분의 1뿐이었지만, 쓰지 않는 묶음에 대한 할인은 없었다.

1.2. 내부 개발 금기를 깨다

1. 과거의 ‘not invented here’ 방어선

   1. 창업 문서에 명시된 제한: 이미 사서 쓸 수 있는 commodity software를 직접 만드는 데 빠지기 쉽다는 이유로, 내부 소프트웨어 구축에는 창업자의 명시적 승인을 요구해 왔다.
   2. 정책의 전환: 일곱 번의 AI Engineer 행사를 운영하며 해당 소프트웨어 범주의 문제를 충분히 경험한 뒤, 올해는 agents가 개인화 소프트웨어를 만들 만큼 좋아졌다고 판단했다.

2. Kill My SaaS 챌린지

   1. 공개 실험: 특정 제품의 스펙과 jobs to be done을 공개하고 누구나 복제할 수 있는 도전 과제를 열었다.
   2. 실제 구매자 평가: 행사 운영팀은 기술 스택·agent·model·오픈소스 여부에 관심이 없고, 실제로 구매하고 사용할 수 있는지만 판단했다.
   3. 참여 규모: 72명 또는 72개 팀이 제출했고, 대부분의 결과물은 계속 라이브 상태이며 오픈소스로 공개됐다.

2. 중간급 업무 소프트웨어가 어려운 이유

겉보기에는 평범한 CRUD 제품처럼 보여도, 행사의 생애주기와 복수 역할·복수 포털·일정 제약을 한 시스템으로 엮어야 한다.

2.1. 하나의 행사에 겹쳐 있는 jobs to be done

1. 발표 제안부터 공개 아젠다까지

   1. 심사 흐름: 발표자가 talk를 제출하고, reviewers가 점수를 매기며, review committee가 승인한다.
   2. 발표자 포털: 승인된 발표자는 headshot과 slides를 업로드하고, 미완료 작업에 대한 reminders를 받는다.
   3. 일정 연결: 발표자를 방과 세션에 배치하고, 일정이 바뀌거나 발표 제목이 수정되면 public agenda에도 정확히 반영해야 한다.

2. 역할과 데이터의 중첩

   1. 추가 관계: co-speakers를 붙이고, sponsor·invited speaker·attendee에도 비슷한 흐름을 적용해야 한다.
   2. 복수 역할: 한 사람이 speaker이면서 sponsor·attendee일 수 있고, organizer·volunteer·vendor 같은 역할을 동시에 가질 수 있다.
   3. 즉석 역할: 행사 상황에 따라 미리 정의되지 않은 역할을 현장에서 만들어야 할 때도 있다.

2.2. 실패 비용이 큰 운영 환경

1. 일정 지연의 현실적 손실

   1. 시간 압박: 소프트웨어가 마감일을 일주일 넘기면 참가자가 잘못된 장소로 가거나 컨퍼런스 자체가 열리지 않을 수 있다.
   2. 숨은 비용: rush fee와 union fee를 지불해야 하는 상황이 실제로 발생했고, 티켓을 산 참석자는 모든 운영이 당연히 작동하리라 기대한다.

2. 제품 만족도와 책임

   1. 낮은 기대치: 컨퍼런스 앱을 사랑하는 사람은 드물지만, 행사 현장에서는 작은 오류도 운영팀의 문제가 된다.
   2. 운영자의 기준: 사용자는 구현 기술이 아니라 자신이 맡은 일을 안전하게 끝낼 수 있는지로 제품을 평가한다.

3. 챌린지 설계와 실제 사용자 평가

복제 대회의 핵심은 제품의 외형보다 실제 운영팀의 semi-blind eval에 결과를 맡긴 데 있었다.

3.1. 참가자에게 제공한 입력과 보상

1. 복제에 필요한 자료

   1. 제품 이해 자료: 창업자가 작성한 brief, 실제 제품 walkthrough video, 42장의 screenshots를 제공했다.
   2. 경제적 지원: 우승 상금은 $10,000이었고, 진지하게 시도한 참가자에게 token 비용 최대 $500를 환급했다.

2. 심사 독립성

   1. 최종 결정권: 창업자가 직접 우승자를 고르는 것이 아니라 실제 events team이 최종 판단을 내렸다.
   2. 구현 무관 평가: 비기술 심사자는 어떤 stack·model·agent로 만들었는지보다 실제 구매와 사용 가능성을 봤다.

3.2. 운영팀이 바로 발견한 세 가지 결함

1. Portal의 다중성

   1. 서로 다른 사용자 공간: speakers, invited speakers, sponsors는 각각 자기 포털이 필요하지만, 대부분의 제출작은 유연하지 않은 단일 포털만 만들었다.
   2. Form과 portal의 차이: 일부 제품은 단순 입력 form과 지속적으로 상태를 관리하는 portal을 구분했지만, CFP·sponsor·invited speaker 포털을 관리자가 각기 설정하는 기능은 거의 빠졌다.

2. Drag-and-drop의 실행 가능성

   1. 상태 확인: 스케줄에서 항목을 놓았을 때 실제로 이동했는지, 저장·업데이트가 확정됐는지, 현재 상태가 애매한지 알 수 있어야 한다.
   2. 도메인 제약: 한 사람이 동시에 두 세션에 들어가거나 한 방이 같은 시간대의 여러 세션에 중복 배정되면 안 된다.
   3. 도움말의 한계: tooltip이 설정 방법을 설명하는 overlay에 그치면 안 되고, 설명한 동작을 바로 실행하는 버튼이어야 한다.

3. CFP를 우회하는 talk 추가

   1. 초대 발표자 흐름: invited speaker나 VIP의 talk를 CFP form을 거짓으로 제출하는 방식 없이 직접 추가할 수 있어야 한다.
   2. 문서화되지 않은 품질: 이 세 가지는 공식 docs나 Sessionboard에서 명확히 지정되지 않았지만, 실제 사용자처럼 제품을 조작하면 즉시 드러났다.

4. AI judge의 효용과 한계

자동 평가는 초기 개선을 위한 hill climbing에는 유용하지만, 사용자 경험의 취향과 전체 제품의 연결성을 대신 판단하지 못한다.

4.1. 20개 시나리오 기반 자동 평가

1. 평가 환경

   1. 목적: AI judge는 우승자를 고르기 위한 장치가 아니라 참가자가 애플리케이션을 작동시키고 개선할 수 있게 하는 sanity check였다.
   2. 구조: Claude가 각 역할로 로그인해 정상적인 user flow 20개를 클릭하고, 다시 Claude가 결과를 채점했다.
   3. 비유: 강화학습(RL) 없이 agent가 점수를 올리는 환경인 ‘RL environment without the RL part’에 가까웠다.

2. 초기 결과

   1. 평가 대상: 56개 앱을 평가했고, 그중 40개는 순위를 매길 만큼 충분한 coverage를 확보했다.
   2. 포화 신호: 상위 7개가 2.3점 안에 몰려 자동 평가상 거의 saturation에 도달했다.
   3. 활용 사례: Lectern과 Curtain Call 같은 팀은 점수가 낮은 영역에 agent를 집중시켜 빠르게 hill climb했다.

4.2. 자동 점수와 인간의 판단이 갈라진 이유

1. 통합 없이 기능만 늘린 문제

   1. 독립 기능의 함정: 여러 팀이 token을 많이 써서 기능을 만들었지만, 전체 앱에 연결하지 않아 서로 중복되고 흐름이 끊겼다.
   2. Dogfooding 부족: 제출 전에 자기 앱을 실제 사용자처럼 써보지 않아 통합 결함을 발견하지 못했다.

2. AI 순위의 불완전한 상관관계

   1. 인간 평가와의 차이: AI judge 상위 10개 중 6개가 events team에게 약한 제품으로 평가됐다.
   2. 우승자의 순위: 최종 우승작 OpenRostrum은 AI judge 순위에서 19위였다.
   3. 의도된 불일치: 스펙을 취향에 맞게 바꿀 자유를 허용했고, 기계적인 복제보다 jobs to be done과 좋은 UX를 정의하는 ‘taste’를 보려 했다.

3. 체크리스트와 taste

   1. 객관성의 한계: 루브릭과 스펙이 완전히 정의된 객관적 대회가 아니며, 체크리스트로 복제할 수 있는 부분과 인간의 취향이 필요한 부분이 공존했다.
   2. AI judge의 사각지대: OpenStash가 자랑스럽게 만든 기능 대부분은 AI judge가 평가하지 않았고, 모든 앱을 사람이 클릭했기 때문에 그 사실이 드러났다.
   3. 채용 신호: 이 대회는 실제 job to be done을 이해하고 taste 있게 코딩하는 사람을 찾는 hiring exercise이기도 했다.

5. 참가자들이 실제로 구축한 방식

빠른 결과를 만든 팀은 프롬프트 하나를 던지고 기다리지 않고, 문제를 조사하고 구조화한 뒤 여러 agent를 검증 루프에 배치했다.

5.1. 규모와 모델 조합

1. 상당한 규모의 산출물

   1. 코드 양: 중간값 public repo는 91,000 lines of code였고, 참가자들은 며칠 동안 agents를 실행했다.
   2. 모델 사용: Claude Code와 Codex 사용량은 거의 비슷했으며, 66개 제출작 중 40개가 두 도구를 함께 사용했다.
   3. 모델 가족 혼합: 거의 모든 팀이 여러 model family를 섞었다.

2. GPT 계열의 비결정성

   1. 사용 빈도: 세 finalists 모두 GPT-5를 사용했지만 다른 66개 중 50개도 사용했으므로, 단순히 GPT-5를 쓴 것 자체에는 alpha가 없었다.
   2. 핵심 차이: 성능을 가른 요소는 어떤 모델을 쓰느냐보다 모델 사이에서 계획·구현·검증을 어떻게 분리했는가였다.

5.2. 혼합 모델을 나눈 세 가지 패턴

1. 강한 모델의 계획과 저렴한 모델의 실행

   1. 역할 분리: smart model이 할 일을 정하고, cheaper model이 지정된 작업을 대량으로 작성한다.
   2. 사례: Cboard HQ는 Claude가 plan과 review를 담당하고 Codex가 대부분의 코드를 작성하게 했다.

2. 한 모델의 구축과 다른 모델의 점검

   1. 검증 담당: 한 모델이 제품을 만들고, browser를 조작하거나 testing에 더 강한 다른 모델이 결과를 확인한다.
   2. 현재의 강점: 당시 기준으로 browser driving과 테스트에는 GPT Codex가 더 적합하다는 관찰이 나왔다.

3. 자기 작업을 스스로 승인하지 않기

   1. 독립 workspace: Green Room HQ는 Claude team과 Codex team을 별도 worktree에서 운영했다.
   2. 병합 조건: 서로 상대 팀의 결과를 검증하기 전에는 merge하지 않았다.
   3. 검증 원칙: agent는 자기 작업보다 남의 작업을 더 엄격하게 평가하는 경향이 있어, 이는 인간의 peer review와도 닮았다.

5.3. 세 finalists의 사전 작업

1. Marco Kraemer / Trackstage

   1. 선행 설계: UX/UI가 정해진 뒤에도 8시간을 들여 data schema, business logic, pseudo-code를 가장 세밀한 수준으로 계획했다.
   2. 구축 속도: 과거 몇 년 전 사람이 하던 설계 작업을 LLM에 넘기고 2~3시간 기다리면 pixel-perfect에 가까운 제품을 얻을 수 있다고 봤다.

2. Yazin / Conferencer

   1. 전면 조사: Sessionboard의 Google Doc을 Markdown으로 바꾸고, Firecrawl로 Sessionboard help portal 전체와 유사 사이트를 크롤링했다.
   2. 목표: 직접 prompting을 시작하기 전에 가능한 한 많은 제품 정보를 수집해 명세의 빈틈을 줄였다.

3. Valentin de Matos / OpenRostrum

   1. 재사용 가능한 guardrails: 프로젝트마다 반복할 작업을 줄이기 위해 code review와 운영 링크를 포함한 GitHub template을 만들었다.
   2. 전체 흐름 매핑: Codex에게 인터넷의 자료와 YouTube 영상까지 탐색해 모든 feature의 모든 flow를 그리게 했고, 영상은 frame-by-frame screenshot으로 분석했다.
   3. 병렬 계획: feature별 기대 동작을 Markdown 폴더에 정리한 뒤, 병렬 처리 가능한 작업과 순차 처리해야 하는 작업을 나눠 agent 수와 시작 순서를 계획했다.
   4. 실행 환경 수정: 첫 실행에서 agent가 앱을 로컬로 띄우지 않았다는 사실을 발견한 뒤, 로컬 실행을 포함하도록 전체 과정을 다시 돌렸다.

4. 기술 스택 선택

   1. Marco의 입력: walkthrough video와 Sessionboard API docs를 Claude에 넣고 Convex와 Next.js를 선호 stack으로 지정했다.
   2. Convex의 역할: 실시간 database를 단순한 설정으로 제공해 높은 성능과 자연스러운 사용감을 빠르게 만들 수 있었다.

6. 작동 여부를 확인하는 가장 지루하고 중요한 단계

세 finalists 모두 자기 제품을 실제 사용자처럼 반복해서 사용했고, 이 과정에서 agent가 잘 못 찾는 UX 결함과 데이터 연결 오류가 드러났다.

6.1. 구축과 UX 검증의 차이

1. Agent의 강점과 약점

   1. 구축 능력: agent는 기능을 만드는 데 매우 강했다.
   2. 검증 능력: UX 문제를 발견하는 데는 약했고, headshot 업로드는 성공했지만 public speaker page가 같은 저장 위치를 읽지 않는 독립 구현 오류도 만들었다.

2. Valentin의 5분 테스트

   1. 운영 기준: 사용자가 제품을 처음 접하고 5분 안에 매끄럽게 테스트하지 못하면 무언가 빠진 것으로 봤다.
   2. 원인 추적: 수동으로 ‘이 부분이 싫다’고 고치기보다, trace를 탐색해 지시 부족·기대치 부족·현재 상태를 테스트할 수 없는 구조 중 원인을 찾았다.
   3. 재설계 루프: onboarding 같은 흐름에 좋은 경로와 나쁜 경로의 정의를 조사하는 단계를 추가한 뒤 전체 flow를 다시 수행했다.

6.2. Yazin의 반복 클릭과 UX 목록

1. 운영 흐름의 마찰

   1. 뷰 전환: 여러 view 사이를 이동하려면 매번 sign out과 sign in을 해야 했고, username과 password를 찾거나 추가해야 했다.
   2. 발견된 수정: sign-in, portal switching, resend support 같은 기본 기능을 보완하고 클릭할 때마다 발견되는 UX 문제를 running list로 관리했다.

2. 도메인 전문가가 만든 개선

   1. Deliverables page: content manager는 개별 form에 들어가지 않고 한 페이지에서 모든 상태를 볼 수 있는 구조를 특히 높이 평가했다.
   2. 정보 구조: 메뉴 재배치, icon 추가, 논리적 그룹화를 통해 deliverables와 abstracts 페이지를 단순한 표가 아니라 실제 UI처럼 바꿨다.
   3. 요구 밖의 품질: ‘care’는 명시적으로 요청하지 않은 곳에서도 나타났고, 운영팀은 이런 세부 조정에서 실제 사용성을 체감했다.

7. SaaS를 없애도 사라지지 않는 운영 책임

겉으로 작동하는 복제본을 만드는 일은 쉬워졌지만, 장애 대응과 시스템 전체의 책임을 소유자에게 넘기는 순간 진짜 난제가 시작된다.

7.1. 구축보다 어려운 유지보수

1. 운영자의 24시간 책임

   1. 장애 대응: 누군가는 bug report를 받고 새벽 2시에 수정해야 한다.
   2. 실제 사례: 행사 직전 AI Engineer에서 컨퍼런스가 이미 운영 중인 상황에 Flo가 token billionaires 프로그램을 위해 Codex agent 열두 개를 동시에 돌렸다.
   3. 소유의 양면성: ‘깨지면 책임져야 한다’는 뜻에서 If you break it, you own it이며, 반대로 소유하면 직접 깨뜨릴 수도 있다.

2. 조각난 시스템의 통합 문제

   1. 현재 구조: 여러 시스템이 서로 다른 API로 얼기설기 연결되어 있고, 일부만 다른 시스템과 통신한다.
   2. 원하는 구조: registration data가 sponsor portal로 흐르고, sponsor portal이 즉시 schedule로 연결되는 all-in-one system이 필요하다.
   3. 시간의 부족: 운영팀은 무엇을 더 잘 만들지 알고 있지만, 장애가 발생한 즉시 agent를 호출해 수정할 시간이 없다.

7.2. 사용자에게 책임을 떠넘기지 않는 기준

1. Sponsor bug 사례

   1. 문제: sponsor가 ticket을 unassign할 수 없다는 bug를 신고했다.
   2. 나쁜 지원 루프: chat support가 엔지니어에게 전달하고, 엔지니어가 다시 support로 답하고, support가 운영팀으로 전달하는 과정이 반복됐다.
   3. 부적절한 해결: 결국 ‘cache를 새로고침해 보라’는 답이 돌아왔지만, 운영자는 수백만 달러 규모 회사의 sponsor에게 자기 시스템이 깨진 탓으로 cache를 새로고침하라고 요구할 수 없었다.

2. 소유자가 감당해야 할 mental load

   1. 기대치: 어떻게 고쳤는지는 중요하지 않고, 다시 깨지지 않게 해야 한다.
   2. 책임의 범위: 제품 전체 상태를 이해하고, 오류를 찾아 수정하며, 참가자·sponsor·speaker가 문제없이 사용할 때까지 책임져야 한다.

7.3. 내부 소프트웨어 팀의 다음 단계

1. 자기 제품부터 교체

   1. 우선순위: 새 internal software tools team은 구성원 모두에게 기쁨을 줄 수 있도록 회사가 이미 쓰는 자체 소프트웨어부터 교체해야 한다.
   2. 필요한 인력: 끊임없이 나오는 아이디어를 실제로 즐겨 쓰는 제품으로 바꿀 수 있는 협업자가 필요하다.

2. 부분 도구가 아닌 전체 경험

   1. 깊이 있는 구축: 시스템의 작은 조각 하나가 아니라 전체 slice를 깊게 만들어야 한다.
   2. 통합의 가치: 조각난 SaaS로는 구현하기 어려운 전체 운영 경험을 직접 설계할 수 있다.

8. 결과, 수상작, 그리고 소유와 임대의 교환

72개 제출작 중 다섯 개가 실제 도입을 검토할 수준에 도달했고, AI 비용이 낮아진 만큼 유지보수 책임을 감수하고 소프트웨어를 소유하는 선택지가 현실화됐다.

8.1. 수상 결과

1. 실제 도입 후보

   1. 기준 통과: 다섯 앱이 실제 도입 또는 진지한 구매 검토 기준을 통과했다.
   2. 아이디어 채택: 추가로 12개 프로젝트에서 전체 앱을 쓰지는 않더라도 가져오고 싶은 아이디어를 발견했다.
   3. 공개성: 제출작은 모두 오픈소스로 공개됐다.

2. 3위 — Trackstage

   1. 수상자: Marco Kraemer가 $1,000를 받았다.
   2. 강점: 복잡한 scheduling UI에서 가장 깔끔한 drag-and-drop 경험과 잘 문서화된 repository를 제공했다.
   3. 학습 자료: agent fleet 운영법을 배우려면 Trackstage repository를 읽을 만하며, Marco의 본업 Cortex도 함께 언급됐다.

3. 2위 — Conferencer

   1. 수상자: Yazin이 $5,000를 받았다.
   2. 강점: 모든 deliverable을 한 페이지에 표시하면서 앱 전체를 직관적으로 탐색하는 최고의 clickthrough experience를 만들었다.
   3. 운영 품질: speaker lifecycle 단계마다 실제 email을 보내 transactional email을 즐거운 경험으로 만들었다.

4. 1위 — OpenRostrum

   1. 수상자: Valentin de Matos가 $10,000를 받았다.
   2. 강점: software factory를 만들고 그 factory를 디버깅했으며, 여러 portal과 운영팀이 실제로 쓰고 싶어 한 schedule을 완성했다.
   3. 실제 계획: 2027년 AI Engineer 컨퍼런스 운영에는 OpenRostrum과 Conferencer, 추가 12개 프로젝트의 아이디어를 조합할 가능성이 높다.

8.2. 2006년식 소프트웨어에서 2026년식 소프트웨어로

1. 사용자 집단이 직접 만드는 도구

   1. 새로운 제작자: 가장 많이 코딩하는 사람은 engineers가 아니라 designers, domain experts, operations people일 수 있다.
   2. 피드백 속도: 실제 업무를 하는 사람이 bug report와 feature request를 분 단위로 처리받으며 제품을 개선할 수 있다.

2. 비용과 책임의 교환

   1. 구축 비용: 중간급 소프트웨어 복제에는 subscription token 비용 약 $1,000와 AI engineering expertise 비용 약 $10,000가 들 수 있다.
   2. 인력 전환: 제출자 중 일부는 이후 소프트웨어 구축 인력으로 고용할 수 있다.
   3. 소유의 대가: 이후에는 직접 소유하는 대신 유지보수 책임도 직접 져야 한다.
   4. 달라진 경제성: agents 덕분에 12개월 전보다 팀에 맞춘 소프트웨어의 유지·커스터마이징이 훨씬 가능해졌다.

8.3. 다음 Kill My SaaS를 위한 교훈

1. 평가 운영도 제품이다

   1. 지연 원인: 두 개의 컨퍼런스를 동시에 운영하고 New York 행사 현장에서 녹화하면서 정규 업무 위에 실험을 얹어 평가 회신이 늦어졌다.
   2. 다음 계획: 다음 대회는 혼자 진행하지 않고 더 체계적으로 설계해 참가자에게 빠르게 회신한다.

2. 회의적인 운영팀의 전환

   1. 태도 변화: 팀은 AI로 만든 앱을 의심하던 상태에서 이를 요구하고 기대하는 상태로 바뀌었다.
   2. 절감액의 사용처: 목표는 단순한 비용 절감이 아니라, 그 절감액을 참석자·sponsor·speaker가 실제로 좋아할 소프트웨어 개선에 다시 투자하는 것이다.

주요 발언 모음

“Every few weeks, someone on my timeline declares that AI killed SaaS. Then someone else replies that you can't vibe code your way out of a real business problem.”

“If you break it, you own it.”

“I don't care how you fix it. I need it to not break.”

“Nobody said they typed one prompt and walked away.”

“Taste is what we really are looking for from humans that are manipulating the coding agents.”

“I would much rather pay for tokens and use my time to build software that all of my attendees, my sponsors, my speakers actually enjoy using and deserve.”

핵심 데이터 & 수치

• $43,000/년: 네 행사에 필요한 기존 행사 운영 SaaS의 견적.
• 3~6개월 또는 무기한: 기성 SaaS의 change request가 반영되는 데 걸리는 기간.
• 7회: 이미 운영한 AI Engineer 행사 수.
• 72개 팀: Kill My SaaS 제출 팀 수.
• $10,000 / 최대 $500: 우승 상금과 진지한 참가자 token 환급 한도.
• 42장: 참가자에게 제공된 실제 제품 screenshots 수.
• 20개: AI judge가 수행한 정상 user-flow 시나리오 수.
• 56개 / 40개: 자동 평가 앱 수와 충분한 coverage로 순위화된 앱 수.
• 2.3점: AI judge 상위 7개 앱 사이의 점수 차이 범위.
• 91,000 lines: 제출작 public repository의 중간 코드 규모.
• 40/66: Claude Code와 Codex를 함께 사용한 제출작 비율.
• 19위: 최종 우승작 OpenRostrum의 AI judge 순위.
• 5개 + 12개: 실제 도입 검토 기준을 통과한 앱과 아이디어를 채택할 추가 프로젝트 수.
• $1,000 / $5,000 / $10,000: Trackstage·Conferencer·OpenRostrum의 수상 금액.
• 약 $1,000 + 약 $10,000: token subscription과 AI engineering expertise로 추정한 복제 비용.

결론 및 시사점

1. 중간급 SaaS는 기능 목록보다 역할·상태·일정·데이터 연결을 포함한 전체 운영 경험이 핵심 자산이다.
2. 자동 평가를 공개하면 참가자가 약한 영역을 빠르게 hill climb할 수 있지만, 인간의 taste와 도메인 맥락을 대체할 수 없다.
3. 모델 선택보다 계획·구현·검증의 역할 분리, 독립 workspace, 상호 검토가 결과 품질을 좌우한다.
4. 실제 사용자처럼 반복해서 dogfood하고 5분 테스트를 통과시키는 과정이 prompt보다 중요하다.
5. AI로 구축 비용이 낮아져도 소유자는 새벽 장애 대응, 통합, 데이터 일관성, 사용자 책임을 떠안는다.
6. 소프트웨어를 사랑하지도 소유하지도 못한 채 임대하는 비용이 크다면, tokens와 전문성에 투자해 도메인 팀이 직접 개선 가능한 시스템을 소유할 수 있다.
7. 비용 절감은 최종 목적이 아니라, 기존 SaaS가 제공하지 못한 사용자 경험과 기능 개선을 재원으로 삼을 때 의미가 생긴다.

핵심 요약 20줄

AI coding agents는 중간급 업무용 SaaS를 며칠 안에 실제로 작동하는 복제본으로 만들 수 있다. AI Engineer는 네 행사에 필요한 행사 운영 SaaS에 연간 43,000달러를 지불할 상황에 놓였다. 기성 SaaS의 기능 요청은 3~6개월 뒤 또는 영영 반영되지 않아 운영팀의 병목이 되었다. 72개 팀이 제품 brief와 walkthrough video, 42장의 스크린샷을 바탕으로 대체 제품을 제출했다. 최종 평가는 기술 스택이 아니라 비기술 행사 운영팀이 실제로 사용할 수 있는지를 기준으로 진행됐다. 대부분의 복제작은 발표자·초대 발표자·스폰서를 위한 여러 portal을 유연하게 분리하지 못했다. 일정의 drag-and-drop은 이동·저장·충돌 여부를 명확하게 보여줘야 하는 고난도 UX였다. 초대 발표자의 talk를 CFP 제출 없이 추가하는 흐름은 공식 문서보다 실제 사용에서 먼저 드러났다. AI judge는 Claude가 20개 정상 user flow를 수행하고 다시 결과를 채점하는 자동 평가 환경이었다. 56개 앱 중 40개가 순위화됐고 상위 7개가 2.3점 안에 몰려 자동 평가가 포화됐다. 자동 평가 상위 10개 중 6개는 인간 운영팀에게 약한 제품으로 평가됐고 우승작은 19위였다. 자동 평가는 독립 기능을 빠르게 개선하는 hill climbing에 유용하지만 전체 앱의 연결성을 보장하지 못했다. 좋은 팀은 한 모델이 계획하고 다른 모델이 구현·브라우저 테스트·검증을 맡도록 agent 역할을 나눴다. 세 finalists 모두 프롬프트보다 먼저 제품 조사와 data schema, business logic, flow 설계에 시간을 썼다. 실제 사용자처럼 반복해서 제품을 dogfood해야 headshot 저장 위치와 public page의 불일치 같은 결함을 찾을 수 있었다. 5분 안에 매끄럽게 테스트되지 않는 제품은 요구사항·기대치·현재 상태 검증 중 하나가 빠진 제품이었다. 복제본을 소유하면 기능 요청은 빨라지지만 새벽 장애 대응과 전체 시스템 유지보수 책임도 함께 소유한다. Trackstage는 복잡한 일정 UI, Conferencer는 전체 탐색과 transactional email, OpenRostrum은 software factory가 강점이었다. 중간급 소프트웨어 복제 비용은 약 1,000달러의 tokens와 약 10,000달러의 AI engineering expertise로 추정됐다. 절감한 SaaS 비용은 도메인 팀이 참석자·스폰서·발표자를 위해 더 나은 자체 소프트웨어를 만드는 데 재투자할 수 있다.