빌더는 늘었고, 코드는 AI가 짠다
2026년 스타트업 빌더의 풍경이 달라졌다. Supabase가 2,000명의 스타트업 빌더를 조사한 결과, 1인 창업자 비율은 1년 새 53%에서 61%로 뛰었고, 비기술 창업자 비율은 22%까지 올라왔다. 코드베이스의 절반 이상을 AI가 작성한다는 응답은 61%에 달했고, 76~100% 전부를 AI로 생성한다는 팀도 40%나 된다. 혼자서도 빠르게 제품을 만들 수 있는 시대가 실제로 왔다.
AI 도구 시장의 판도도 뚜렷하게 재편됐다. Claude Code는 AI 코딩 도구 사용률 63%로 1위를 차지했고, Anthropic/Claude 모델 사용률은 64%로 올라선 반면 OpenAI는 69%에서 52%로 내려왔다. 유료 Claude 구독은 1년 사이 28%에서 59%로 거의 두 배가 됐다. 한때 압도적이었던 Cursor는 19%포인트나 하락했다. 시장의 무게중심이 이동하는 속도가 체감 이상으로 빠르다.
만들기는 쉬워졌는데, 운영 기반은 비어 있다
그런데 데이터의 뒷면이 더 흥미롭다. AI 코드 비중이 높은 팀일수록 아직 수익화하지 못했을 가능성이 크고, 고객 확보를 가장 큰 과제로 꼽는 경향이 강하다. '기술적 복잡성'은 24%에서 11%로 조사 전체에서 가장 큰 하락폭을 기록했다. 그 자리를 채운 건 고객 확보(32%), 제품-시장 적합성(14%), 그리고 번아웃(11%)이다. 구축의 문턱이 낮아진 만큼, 진짜 병목이 선명하게 드러난 셈이다.
더 눈에 띄는 건 운영 기반의 공백이다. AI 워크로드를 별도로 모니터링하지 않는 팀이 59%에 달한다. 프로덕션 프롬프트를 관리하는 공식 체계가 없는 팀은 47%이고, AI 모델 평가를 수동 테스트와 프롬프트 반복에만 의존하는 팀은 52%다. 에이전트를 프로덕션에서 운영하는 팀의 24%는 멀티 에이전트를 돌리고 있는데, 그중 절반 이상이 정식 평가 절차 없이 운영한다. 만들기는 어느 때보다 쉬워졌지만, 에이전트가 지금 무슨 상태인지 파악하는 팀은 극소수다.
에이전트 상태를 모른다는 건, 어떤 의미인가
코딩 에이전트 모니터링에 관한 실용 가이드는 이 공백이 왜 위험한지를 구체적으로 설명한다. 에이전트의 프로세스가 살아있다고 해서, 세션이 진행 중인 것은 아니다. 파일 수정 이벤트가 발생했다고 해서, 의미 있는 작업이 이루어진 것도 아니다. 개발자 도구가 각각의 신호를 그대로 상태 배지로 바꿔버리면, 이미 완료된 턴을 '대기 중'으로, 조용히 멈춘 작업을 '성공'으로 표시하게 된다.
신뢰할 수 있는 모니터는 관찰 증거와 사용자에게 보여주는 시간 한정 결론을 분리해야 한다. 실용적으로 유효한 최소 상태 집합은 일곱 가지다: inactive, running, waiting_for_user, completed, blocked, stalled, unknown. 여기서 핵심은 stalled와 unknown의 구분이다. stalled는 실행 중이던 턴이 침묵 임계값을 초과했지만 종료 이벤트가 없는 상태이고, unknown은 증거 자체가 없거나 모순된 상태다. 침묵은 stalled를 추론하는 데 쓸 수 있지만, 절대로 completed를 만들어낼 수 없다.
completed는 가장 많이 오해되는 상태다. 이 상태는 현재 턴의 종료 이벤트가 존재하고, 그것을 무효화하는 이후 활동이 없을 때만 유효하다. 코드가 정확하다는 의미가 아니고, 프로젝트 수준의 작업이 끝났다는 의미도 아니다. 이 차이를 이해하지 못한 채 에이전트를 프로덕션에서 돌리는 팀은, 조용한 실패를 성공으로 읽고 있을 가능성이 높다.
빠른 프로토타이핑 다음, 무엇을 직접 잡을 것인가
Supabase 조사가 드러낸 풍경과 에이전트 상태 모니터링 가이드는 같은 지점을 가리킨다. AI가 코드를 빠르게 생성할수록, 개발자가 직접 설계해야 할 영역이 더 선명해진다는 것이다. 세 가지 영역이 특히 중요하다.
첫째, 에이전트 상태 관찰 구조. 지금 에이전트가 실행 중인지, 기다리는지, 막혀 있는지, 아니면 조용히 멈춘 건지를 구분하는 체계가 없으면 프로덕션은 블랙박스다. 로그와 훅 이벤트를 그대로 뱃지로 바꾸는 도구는 오히려 위험하다. 증거 레이어와 상태 레이어를 분리하는 구조가 필요하다.
둘째, 프롬프트 관리와 평가 파이프라인. 프로덕션 프롬프트를 소스 코드에 하드코딩하거나 관리 체계 없이 운영하는 팀이 여전히 다수다. 프롬프트는 코드와 같은 방식으로 버전 관리되어야 하고, 변경의 영향을 측정하는 평가 체계가 병행돼야 한다. 수동 테스트와 감으로 운영하는 팀은, 모델이 조용히 달라지는 순간을 감지하지 못한다.
셋째, AI 워크로드 모니터링. AI 코드 생성이 보편화된 만큼, AI가 생성한 코드와 에이전트가 수행하는 작업 역시 일반 워크로드와 동일한 수준으로 관찰되어야 한다. Langfuse, LangSmith, OpenTelemetry 같은 도구의 도입률이 아직 한 자릿수에 머무는 건, 이 공백이 얼마나 큰지를 보여준다.
유통과 관찰 가능성이 다음 격차를 만든다
조사는 또 하나의 패턴을 보여준다. 커뮤니티를 구축한 스타트업(전체의 10~11%)은 그렇지 않은 팀보다 오픈소스와 개발자 채널에서 첫 고객을 훨씬 많이 확보했다. Discord·Slack·Reddit 비중은 커뮤니티 있는 팀이 38%, 없는 팀이 7%다. 누구나 제품을 출시할 수 있는 환경에서는, 구축 능력이 아니라 유통 경로가 격차를 만든다.
기술적 복잡성이 더 이상 최대 과제가 아닌 세계에서, 다음 레버는 두 가지다. 고객이 제품을 발견하게 만드는 유통 설계, 그리고 에이전트가 무엇을 하고 있는지 실시간으로 파악하는 관찰 가능성 구조. AI가 코드를 짜주는 만큼, 개발자가 직접 붙잡아야 할 것의 무게는 오히려 이쪽으로 옮겨오고 있다. 빠르게 만드는 능력은 이미 평준화됐다. 다음 차별점은 무엇을 관찰하고, 무엇을 운영하는가에서 나온다.