2026 스타트업 설문을 읽다가 묘한 숫자 조합을 봤다. 응답자의 61%는 코드 절반 넘게를 AI가 생성했다고 답했는데, 59%는 AI 워크로드를 따로 모니터링하지 않는다고 했다. 만드는 속도는 확실히 빨라졌지만 운영 체계는 그 속도를 따라가지 못한 셈이다.
7월 20일 GeekNews에 올라온 Supabase의 State of Startups 2026는 스타트업 빌더 2,000명의 응답을 정리한 보고서다. 같은 날 12시 16분 KST 확인 기준 GeekNews 소개 글은 신규 목록 3위에 있었다. AI 도구 선호도부터 창업자 구성, 에이전트 운영, 첫 고객 획득까지 한 화면에 붙여 놓으니 모델 발표보다 훨씬 현실적인 풍경이 보였다.
나는 이 설문을 “AI가 스타트업을 얼마나 쉽게 만들었나”보다 “쉬워진 개발 뒤에 어떤 일이 아직 어려운가”를 보여주는 자료로 읽었다. 코드 생산은 이미 기본값에 가까워졌다. 반면 평가, 관측, 프롬프트 관리, 판매는 여전히 사람의 기억과 수작업에 기대고 있다. 작은 팀일수록 이 간격이 빠르게 운영 부채가 된다.
AI 코드가 절반을 넘은 스타트업이 다수가 됐다
61%가 코드베이스의 절반 넘게를 AI가 생성했다고 답했다
보고서에서 코드베이스의 AI 생성 비중이 76~100%라는 응답은 40%, 51~75%는 21%였다. 두 구간을 합치면 61%다. 반대로 AI 생성 코드가 0%라는 응답은 2%에 그쳤다. Supabase가 “AI-written code became the median experience”라고 요약한 이유가 숫자로 보인다.
다만 이 비율을 Git 커밋의 정밀한 계측값처럼 읽으면 안 된다. 설문 응답자가 체감한 코드베이스 비중이고, AI가 초안을 만든 뒤 사람이 크게 고친 코드까지 어떻게 셌는지 공통 정의가 제시되지는 않는다. 그래도 방향은 분명하다. 이제 스타트업에서 AI 코드는 실험 기능이 아니라 일반적인 생산 수단이 됐다.
나는 이 변화가 개발자의 필요성을 없앴다고 보지 않는다. 오히려 무엇을 만들지 정하고, 생성된 변경을 검증하고, 실패를 복구하는 일이 더 비싸졌다. 타이핑 비용이 줄면 제품 가설을 더 자주 시험할 수 있지만, 틀린 가설을 더 빠르게 배포할 수도 있다. 속도 자체는 품질이나 매출을 보증하지 않는다.
에이전트와 MCP도 실험 단계를 넘어가고 있다
AI 에이전트를 만들고 있거나 만들 계획이라고 답한 비율은 52%였다. MCP는 29%가 프로덕션에서 적극 사용 중이고, 28%는 실험 중이라고 답했다. 둘을 단순 합산해 채택률처럼 말할 수는 없지만, 에이전트 도구 연결이 일부 얼리어답터만의 주제는 아니라는 신호는 충분하다.
여기까지 보면 꽤 낙관적이다. 작은 팀도 모델, 데이터베이스, 배포 플랫폼을 조합해 전에는 여러 명이 필요했던 제품을 만들 수 있다. 문제는 다음 화면에서 나온다. 에이전트를 만드는 비율과 에이전트를 운영할 준비가 된 비율 사이가 꽤 벌어져 있다.
AI 운영 공백은 평가와 관측에서 선명했다
프롬프트는 아직 소스 코드와 사람 기억에 묶여 있다
프로덕션 프롬프트를 관리하는 공식 체계가 아직 없다는 응답은 47%였다. 소스 코드에 하드코딩한다는 응답이 26%, 버전 관리되는 프롬프트 파일을 쓴다는 응답이 25%였다. 프롬프트 관리 플랫폼은 11%, 기능 플래그로 변형을 관리한다는 응답은 10%였다. 이 항목은 복수 선택이라 합계가 100%를 넘는다.
작은 팀에서 별도 플랫폼을 당장 사야 한다는 뜻은 아니다. 나도 초기에는 프롬프트 파일과 Git 이력만으로 충분하다고 본다. 대신 최소한 어떤 프롬프트가 어떤 모델·도구·평가 결과와 함께 배포됐는지는 재구성할 수 있어야 한다. “어제는 잘 됐는데 오늘은 왜 이러지?”라는 질문에 버전 하나를 못 찾으면 운영 체계가 없는 것과 비슷하다.
이전에 AI 에이전트 루프 설계가 프롬프트를 대체한다고 쓴 것도 같은 이유였다. 좋은 문장 하나보다 종료 조건, 재시도, 승인, 상태 저장이 결과를 더 크게 좌우한다. 이번 설문은 많은 팀이 에이전트를 만들기 시작했지만 그 루프를 관리하는 기반은 아직 얇다는 걸 보여준다.
평가는 수동이고 AI 전용 관측은 비어 있다
AI 모델 평가 방식은 수동 테스트와 프롬프트 반복이 52%로 가장 높았다. 공식 평가 프로세스가 없다는 응답도 36%였다. 자동 평가 스위트를 자체 구축했다는 응답은 17%, 제3자 평가 도구 사용은 7%였다. 여기서도 복수 선택이 가능하니 각 비율은 서로 배타적인 팀 구성이 아니다.
관측은 더 비어 있었다. AI 워크로드를 별도로 모니터링하지 않는다는 응답이 59%였다. 자체 대시보드 20%, OpenTelemetry 9%, Langfuse와 LangSmith가 각각 7%였다. 에이전트 구축 계획 52%와 나란히 놓으면 어색한 장면이다. 실행 주체는 늘어나는데 실패율, 비용, 지연, 도구 호출을 보는 창은 절반 이상에게 없다.
나는 이 지점이 AI 스타트업의 진짜 병목이라고 본다. 모델이 틀린 답을 한 번 내는 건 제품 문제다. 그 오류가 어느 프롬프트와 도구 경로에서 반복되는지 모르는 건 운영 문제다. 후자는 사용자 신고가 들어올 때까지 조용히 비용과 신뢰를 깎는다.
혼자 만들 수 있다는 말과 혼자 팔 수 있다는 말은 다르다
1인 창업자 61%가 개발 진입 장벽의 변화를 보여준다
현재 스타트업의 창업자가 한 명이라는 응답은 61%였다. 창업자가 기술적이지 않다는 응답도 22%였다. 보고서는 응답자 구성이 더 나이가 들고, 더 1인 중심이며, 스스로를 기술적이라고 말하는 비율이 낮아졌다고 요약한다. AI와 관리형 플랫폼이 아이디어를 작동하는 제품으로 바꾸는 비용을 내린 영향이 분명 있어 보인다.
이건 좋은 변화다. 고객 문제를 오래 겪은 운영자가 개발팀을 꾸리기 전에 작은 제품을 검증할 수 있다. 다만 “혼자 제품을 만들 수 있다”는 사실이 “혼자 지속 가능한 회사를 운영할 수 있다”는 뜻은 아니다. 결제, 보안, 장애 대응, 고객 지원, 세일즈까지 동시에 열리면 절약한 개발 시간이 다른 병목으로 이동한다.
첫 고객은 여전히 네트워크와 직접 영업에서 왔다
초기 유료 고객의 출처는 개인·직업 네트워크가 56%로 가장 높았다. 콜드 아웃리치나 영업이 35%, 소셜 미디어 인바운드가 29%, 블로그·뉴스레터·SEO 같은 콘텐츠가 21%였다. Hacker News나 Product Hunt는 6%였다. 제품을 빨리 만드는 도구가 늘어도 첫 매출은 여전히 사람이 신뢰를 빌리고 대화를 여는 과정에서 나온다.
가장 큰 사업 과제도 고객 획득이 32%로 1위였다. 제품 시장 적합성 14%, 펀드레이징 13%, 기술 복잡성과 번아웃이 각각 11%로 뒤를 이었다. 기술 복잡성보다 고객 획득을 어렵다고 답한 비율이 거의 세 배다. “코드가 병목이 아니다”라는 말이 이제는 과장이 아니라 운영 데이터에 가깝다.
나는 여기서 AI 제품의 우선순위를 다시 잡아야 한다고 느꼈다. 모델을 하나 더 붙이는 일보다 첫 고객 인터뷰를 자동으로 놓치지 않는 CRM 흐름, 배포 뒤 실패를 잡는 관측, 고객이 돈을 내는 행동을 측정하는 이벤트가 먼저다. 제품 기능은 데모를 만들지만 운영 루프는 반복 매출을 만든다.
이 설문을 시장 전체의 정답으로 읽으면 안 된다
Supabase가 만든 설문이라는 해석상 한계가 있다
공식 페이지는 응답자 2,000명을 스타트업 빌더라고 설명하지만, 표본 모집 경로와 구성의 상세 방법론은 공개하지 않는다. Supabase가 만든 벤더 보고서인 만큼 데이터베이스와 백엔드 플랫폼을 적극적으로 고르는 개발자·메이커가 일반 스타트업 모집단보다 많이 포함됐을 가능성도 배제하기 어렵다. 그래서 “모든 스타트업의 61%가 코드 절반을 AI로 만들었다”고 일반화하면 곤란하다.
보고서의 질문 가운데 여러 항목은 복수 선택이고, 일부는 응답자의 자기 평가다. 비율 합계가 100%를 넘는 항목을 시장 점유율처럼 읽으면 안 된다. 또 AI 생성 코드 비중이 높을수록 아직 수익화하지 못한 비율이 커 보인다는 차트가 있지만, 이 자료만으로 AI 코드가 수익화를 방해했다고 말할 수는 없다. 초기 팀일수록 AI를 많이 쓰는 제3의 요인이 있을 수 있다.
나는 그래도 이 설문이 쓸모 있다고 본다. 모집단의 절대 비율을 확정하는 자료가 아니라, AI를 빠르게 받아들인 팀에서 어떤 운영 공백이 먼저 드러나는지 보는 선행 신호로는 좋다. 숫자를 예언으로 읽지 않고 점검표로 옮기면 된다.
발표사의 해석과 원자료를 분리해서 봐야 한다
Supabase는 자사 도구 선택이 늘어난 결과도 함께 강조한다. 벤더가 만든 보고서인 만큼 자연스러운 구성이다. 그래서 도구 순위보다 질문별 분포가 더 유용했다. 1인 창업자 비중, 코드 생성 체감, 평가 방식, 관측 부재, 첫 고객 경로는 특정 제품 홍보와 분리해서 읽을 수 있다.
비슷하게 NFX가 최근 AI 래퍼 이후에는 전체 워크플로와 데이터, 세일즈 파이프라인을 소유해야 한다고 주장한 것도 방향을 보는 참고 자료이지 보편 법칙은 아니다. 결국 각 팀은 자기 고객의 구매 과정과 장애 비용으로 다시 검증해야 한다.
작은 팀이 지금 붙여야 할 최소 운영 루프
모델보다 먼저 여섯 가지 증거를 남긴다
내가 1~3명 팀에서 AI 기능을 운영한다면 거창한 플랫폼부터 도입하지 않을 것 같다. 대신 아래 여섯 가지를 배포 조건으로 고정한다.
1. 프롬프트·모델·도구 버전을 한 배포 단위로 기록한다
2. 실패 사례 20개를 고정 평가 세트로 만든다
3. 요청별 지연·비용·도구 오류·재시도를 추적한다
4. 외부 쓰기와 결제·삭제는 사람 승인 뒤에 실행한다
5. 고객이 돈을 낸 경로와 해지 이유를 같은 주기로 본다
6. 매주 기능 수보다 실패율·전환율·지원 시간을 먼저 리뷰한다
이 정도면 전용 프롬프트 관리 제품이나 대형 관측 스택이 없어도 시작할 수 있다. 중요한 건 도구 이름이 아니라 재현 가능성이다. 문제가 생겼을 때 어느 버전이, 어떤 입력에서, 어떤 비용으로, 어떤 잘못된 행동을 했는지 다시 볼 수 있어야 한다.
개발 속도를 매출과 신뢰로 닫는 순서가 필요하다
첫 주에는 한 고객 문제와 한 성공 지표를 정한다. 둘째 주에는 AI 기능을 붙이되 실패 사례를 함께 모은다. 셋째 주에는 로그와 평가, 승인 게이트를 배포 흐름에 넣는다. 넷째 주에는 새 기능 대신 유료 전환과 지원 시간을 본다. 이 순서를 반복하면 AI 개발 속도가 제품 숫자만 늘리는 쪽으로 새는 걸 막을 수 있다.
이번 설문에서 가장 인상적이었던 숫자는 AI 코드 61%가 아니었다. 응답자의 59%가 AI 워크로드를 별도로 모니터링하지 않는다는 쪽이었다. 생성 속도가 두 배가 되면 검증과 판매도 두 배 빨라질 거라고 기대하기 쉽다. 실제로는 검증하지 않은 변경과 팔리지 않은 기능이 두 배 빨리 쌓일 수도 있다.
그래서 2026년 작은 팀의 경쟁력은 코드를 얼마나 많이 생성하느냐보다 생성된 일을 얼마나 빨리 증거로 바꾸느냐에 달린 것 같다. 테스트 통과, 장애 복구, 고객 대화, 결제라는 증거가 남지 않으면 빠른 개발은 아직 사업 성과가 아니다. AI 코드 뒤에 남은 운영 공백을 먼저 닫아야 속도가 진짜 자산이 된다.