YC의 Pete Koomen은 몇 사람이 쓰는 작은 도구를 구글 문서처럼 공유할 수 있는 클라우드를 제안했다. 사내 앱을 사업으로 키우려는 팀이라면, 만든 뒤 누가 어떻게 쓰게 되는지부터 살펴볼 만하다.
환불 조회 도구를 팀에 건네는 순간
작은 쇼핑몰의 운영 담당자가 AI로 환불 조회 도구를 만드는 가상 상황을 따라가 보자. 주문번호를 넣으면 환불 진행 상태가 뜬다. 담당자는 자기 컴퓨터에서 몇 건을 확인한 뒤 동료에게 링크를 보낸다. 다음 날 동료가 묻는다. 이 화면에서 환불을 승인해도 되는지, 퇴사한 직원도 여전히 접속할 수 있는지, 잘못 바뀐 주문을 되돌릴 수 있는지.
동료에게 도구를 건넬 때는 화면에서 보이지 않던 일들이 드러난다. 처음에는 주문 상태를 읽는 작은 도구였는데, 팀에 건네는 순간 계정과 데이터, 업무 책임이 따라붙는다. 버튼 하나가 실제 환불을 실행한다면 그 간격은 더 커진다.
Y Combinator가 LinkedIn에 공개한 Pete Koomen의 제안도 이 지점에서 출발한다. 그는 한 사람이나 소수의 사용자를 위한 도구를 ‘Small Software’라고 부른다. AI 에이전트로 이런 도구를 만들기는 쉬워졌지만 배포와 공유에는 어려움이 남아 있다는 주장이다. 같은 내용은 YC 공식 Requests for Startups의 ‘A Cloud for Small Software’에서도 확인된다.
구글 문서의 공유 버튼이 가볍게 느껴지는 이유
Koomen이 제시한 목표는 작은 소프트웨어를 동료에게 구글 문서만큼 쉽게 공유하는 것이다. 원문은 회사마다 다른 실행 환경, 인증과 권한, 비개발자가 만든 코드를 안전하게 공유하는 문제를 짚는다.
문서 링크를 보낼 때 우리는 누가 열 수 있는지 정한다. 환불 조회 도구도 이용자가 할 수 있는 일을 정해 줘야 한다. 환불 조회 화면을 열 수 있다는 사실과 환불을 실행할 수 있다는 사실은 권한이 다르다. 로그인한 직원이라고 해서 모든 고객의 주소를 볼 이유도 없다.
그래서 공유 경험을 단순하게 만들려면, 화면 뒤에서 복잡한 결정을 처리해야 한다. 도구를 만든 사람은 읽기 전용으로 공유할 수 있어야 하고, 팀을 떠난 사람의 접근은 끊을 수 있어야 한다. 앱을 수정할 때 이미 쓰고 있는 동료의 작업이 갑자기 깨지는지도 살펴야 한다. 고객 주문을 다루는 도구라면 변경 내역을 확인할 방법도 필요하다.
작은 앱은 사용자가 적다. 그래도 업무가 계속되는 동안 데이터는 쌓인다. 만든 담당자가 휴가를 가거나 업무를 옮겼을 때 다른 사람이 운영을 이어갈 수 있는지가 중요해진다. 앱 목록에 담당자 이름과 최근 수정일이 보이고, 문제가 생겼을 때 멈추는 방법이 정해져 있다면 동료가 링크를 받는 경험도 달라질 수 있다.
먼저 붙잡을 고객은 같은 일을 반복하는 팀
이 제안을 읽고 범용 앱 제작 플랫폼부터 만드는 창업팀도 있을 것이다. 한국에서 작은 팀이 출발한다면 한 업종의 반복 업무를 먼저 붙잡는 접근을 생각해 볼 수 있다. 앞의 쇼핑몰이라면 환불 상태를 확인하고 담당자에게 넘기는 흐름 하나다. 사용자가 주문번호를 복사하는 순간부터 다음 담당자가 처리 결과를 확인하는 순간까지 지켜볼 대상이 뚜렷해진다.
고객에게 물을 내용도 구체적으로 바뀐다. 지난주 실제로 처리했던 주문 한 건을 보여 달라고 요청할 수 있다. 그 과정에서 누가 데이터를 보고, 어느 단계에서 수정하고, 오류가 나면 누구에게 연락하는지 따라간다. 고객 자료를 다룰 때는 동의받은 범위에서 확인해야 한다.
만드는 속도가 빨라졌다는 말만으로 구매 이유를 설명하기는 어렵다. 팀이 이미 쓰는 스프레드시트와 비교하면 더 분명해진다. 새 도구가 주문 상태를 자동으로 가져와도, 접근 권한을 설정하느라 담당자가 매번 개발자를 불러야 한다면 운영 부담이 남는다. 반대로 동료를 추가하고 담당자를 바꾸는 과정이 일상 업무 안에서 끝난다면 팀이 도구를 다시 쓸 이유를 탐색할 수 있다.
제품을 확인할 때도 완성된 화면을 보여주는 데서 멈추지 말아야 한다. 고객이 동료 한 명을 초대하고, 다음 업무에 다시 접속하고, 담당자가 바뀌었을 때 이어서 쓰는 장면까지 보자. 이 과정은 사용 의사를 알아보는 출발점이다. 돈을 낼지, 기존 도구를 바꿀지는 별도로 확인해야 한다. 지금 읽은 YC 글에는 한국 고객의 구매 데이터나 검증된 수익 모델이 제시돼 있지 않다.
작은 도구에도 다음 담당자가 있다
Koomen의 글은 YC가 관심을 둔 창업 문제를 제시한 글이다. 특정 제품의 성공이나 투자 결정을 보증하는 자료로 읽으면 곤란하다. ‘작은 소프트웨어용 클라우드’라는 방향이 흥미로운 이유는 사용자가 적어도 다른 사람에게 도구를 건네는 순간이 생기기 때문이다.
사내 앱을 만드는 팀이라면 먼저 동료에게 링크를 보내는 장면을 그려볼 수 있다. 첫 접속부터 다음 담당자의 인수인계까지 이어지는 길이 제품 안에 있는지 살펴보자. 그 길에서 반복해서 막히는 일이 나온다면, 창업자가 더 깊이 조사할 고객 문제가 된다.
자주 묻는 질문
Small Software는 작은 스타트업이라는 뜻인가요?
이 원문에서는 한 사람이나 소수의 사용자를 위해 만든 목적성 도구를 뜻한다. 회사 규모를 분류하는 표현으로 사용하지 않았다.
YC가 이런 사업의 수익성을 확인했다는 뜻인가요?
관심 있는 창업 문제를 제안한 글이다. 시장 규모나 특정 사업의 매출을 검증한 자료는 아니므로 고객의 사용과 지불 의사는 따로 확인해야 한다.
출처
함께 읽기
GPT-6.1 Sol과 장기 실행 에이전트, AI 스타트업이 검증할 세 가지에서는 도구 안에서 에이전트가 맡을 작업의 완료 조건을 살펴본다.
Lenny가 전한 Molly Graham의 조언, 창업자의 AI 위임 기준은 사람과 AI의 역할을 나눌 때 참고할 만하다.
댓글 남기기