나는 iamlazyck.kr을 만들고 자료 수집과 정리, 블로그 작성에 쓸 자동화를 이어 왔다. OpenClaw와 여러 스킬을 조합하면 개인 작업의 상당 부분을 연결할 수 있다는 점이 재미있었다. 다음에는 이 구성을 다른 사람도 돈을 내고 쓸지 궁금해졌다.
개인에게 편리한 도구를 만들었다는 사실과 고객에게 맡겨도 되는 서비스를 만들었다는 사실은 다르다. 내 문서가 잘못 정리되면 내가 고칠 수 있지만, 다른 사람의 업무라면 입력 조건과 납기, 수정 범위를 약속해야 한다. 나는 아직 이 글에 적은 유료 제안의 성과를 얻었다고 보고하는 것이 아니다. 실제로 제안하기 전에 확인할 조건을 정리한다.
Base44 사례에서 먼저 고칠 사실
초기 메모에는 Base4라는 이름과 직원 한 명뿐인 유니콘이라는 표현이 있었다. 회사 이름은 Base44다. Wix의 2025년 6월 발표는 초기 인수 대가 약 8,000만 달러에 성과 조건에 따른 추가 지급을 더하는 거래를 설명한다. 이 초기 금액을 10억 달러 규모의 유니콘 가치와 같게 볼 수 없다. Wix 공식 인수 발표
발표에는 Base44 직원들에 대한 유지 보너스도 적혀 있다. 한 사람이 창업했다는 말, 지분을 혼자 보유했다는 말, 직원을 한 명도 두지 않았다는 말은 구분해야 한다. 내가 확인한 발표만으로 직원 없이 혼자 만든 사업의 사례라고 단정하지 않겠다.
이 사례가 흥미로운 이유는 남는다. AI를 활용한 제품이 인수 대상이 될 만큼 주목받았다는 것이다. 그러나 거래 하나에서 내 사업의 성공 확률이나 직장을 떠날 시점을 계산할 수는 없다. 나는 그 소식을 실행의 자극으로 삼되, 내 조건에 맞는 첫 고객을 찾는 문제를 별도로 다루고 싶다.
내가 쓰는 자동화에서 문제 하나 고르기
지금의 구성 전체를 제품으로 내놓으면 설명부터 길어진다. 자료를 요약하고, 지식을 저장하고, 회고를 돕고, 글을 쓰는 기능이 한꺼번에 나온다. 다른 사람은 그중 하나의 결과만 필요할 수 있다. 내가 이미 만든 기능의 목록보다 상대가 반복해서 하는 작업부터 확인해야 한다.
가상의 예로 매주 공개 보고서 여러 개를 읽고 내부 회의용 비교표를 만드는 사람을 생각해 보자. 그 사람에게 필요한 것이 요약문인지, 숫자의 차이를 확인한 표인지, 지난주와 바뀐 항목인지에 따라 서비스의 범위가 달라진다. 공개 자료를 읽는 상황을 예로 들었으며, 실제 고객이 있다고 가정하지 않는다.
첫 후보를 고를 때는 내가 접근할 수 있는 자료, 결과의 오류를 확인할 방법, 상대가 지금 쓰는 대안이 있는지를 보겠다. 내가 해결할 수 있어 보인다는 이유만으로 중요한 법률·의료·투자 판단을 대신하는 서비스를 제안하지 않는다. 오류의 영향이 크면 필요한 전문성과 책임도 커진다.
내게 익숙한 자동화를 선택할 수는 있다. 하지만 사용자의 불편과 맞지 않으면 내가 더 잘 만들 수 있다는 장점만 남는다. 원하는 고객을 찾지 못한 상태에서 기능을 더 붙여 그 차이를 해결하려 하지 않겠다.
고객 후보에게는 최근의 실제 작업을 묻기
Paul Graham은 초기 창업자가 사용자를 직접 찾고 가까이 돕는 일을 설명했다. 서비스만 공개해 두면 적합한 고객이 저절로 찾아올 것이라는 기대를 경계하는 글이다. 나는 이를 초기의 작업 이해에 참고한다. 그 글의 성장 사례를 내 서비스의 매출 전망으로 사용하지 않는다. Do Things that Don't Scale
고객 후보와 이야기할 수 있다면 이런 서비스를 쓰겠느냐는 질문만 하지 않겠다. 최근에 해당 작업을 언제 했고, 어떤 자료를 받아 누구에게 무엇을 보냈는지 듣고 싶다. 일이 늦어졌을 때 생기는 불편과 현재 해결 방법도 확인할 수 있다.
예시 결과물을 보여줄 때는 칭찬과 사용 의사를 구분한다. 보기 좋다는 반응만으로 유료 수요를 확인했다고 적지 않는다. 다음 작업에서 실제로 맡겨 볼 의사가 있는지, 어떤 부분을 본인이 다시 확인해야 하는지 물어볼 수 있다. 상대가 답하지 않아도 압박하지 않는다.
대화 내용을 공개 글에 쓰려면 별도의 동의가 필요하다. 업무 문서나 계정 접근을 먼저 요구하지 않고, 설명만으로 확인할 수 있는 범위를 활용한다. 실제 자료를 사용하게 된다면 사용할 목적과 보관·삭제 방법을 미리 정해야 한다.
첫 제안서는 결과물과 제외 범위를 적는다
처음부터 완성된 구독 서비스를 약속하기보다 한 번의 작은 납품을 정의해 볼 수 있다. 다음 표는 제안서에 넣을 항목의 예시다. 가격이나 기간은 고객에게 검증한 조건이 아니며, 실제로는 작업과 합의에 맞게 정해야 한다.
| 항목 | 적을 내용 |
|---|---|
| 입력 | 고객이 제공하거나 사용을 허락한 공개 자료의 목록 |
| 결과물 | 출처 링크가 있는 비교표와 확인하지 못한 항목 |
| 완료 기준 | 누락 자료 확인, 숫자 대조, 읽을 수 있는 형식 |
| 제외 범위 | 원문 접근권 우회, 전문가 판단 대행, 무제한 수정 |
| 수정과 오류 | 수정 요청 기한, 내 오류의 정정 방법, 연락 경로 |
| 종료 | 작업 취소 조건, 남은 데이터의 처리 방식 |
특히 결과물의 미확인 항목을 숨기지 않는 방식이 중요하다. 접근할 수 없는 문서를 읽은 것처럼 채우지 않고, 숫자를 확인하지 못했다면 무엇이 부족한지 남긴다. AI가 작성한 문장이라도 고객에게 전달하는 사람은 그 범위를 설명해야 한다.
수동 작업이 섞여 있다는 사실도 감추지 않겠다. 처음 몇 번은 내가 자료를 확인하고 편집해야 할 수 있다. 전부 자동이라는 홍보를 먼저 해 놓으면 예외가 발생했을 때 약속을 지키기 어렵다. 고객에게 필요한 것은 자동화 비율 자체보다 신뢰할 수 있는 결과와 책임 있는 응답일 수 있다.
비용에는 내 수정 시간을 포함하기
모델 사용료만 계산하면 개인 서비스의 비용을 과소평가하기 쉽다. 입력을 정리하고, 결과를 확인하고, 고객 질문에 답하는 시간도 들어간다. 비용을 적을 때는 실제로 발생한 금액과 임의로 잡은 가정을 분리하고 싶다.
가령 순수한 계산 예시로 한 번의 작업 대가가 5만 원이고, 도구 비용 3천 원, 결제 관련 비용 2천 원을 가정해 보자. 내가 검토와 응대에 한 시간을 썼다면 4만5천 원이 내 시간 비용을 차감하기 전 남는 금액이다. 그 시간을 3만 원으로 평가하면 나머지는 1만5천 원이다. 여기에 세금이나 환불, 영업에 쓴 시간은 포함하지 않았다. 실제 서비스의 수익이나 권장 가격이 아니다.
한 번의 결과를 만들 때보다 반복 주문에서 어떤 비용이 늘어나는지도 봐야 한다. 자료 형식이 매번 다르거나 고객마다 검토 기준이 바뀌면 자동화 가능한 부분이 줄어든다. 같은 제목의 작업이라도 실제로는 다른 용역을 제공하고 있을 수 있다.
처음 실험에서 기록하고 싶은 것은 총매출보다 입력 정리, 생성, 검토, 수정, 응대에 걸린 시간이다. 어느 부분이 반복되는지 알아야 그 부분을 제품 기능으로 만들 이유가 생긴다. 모든 단계를 먼저 자동화한 뒤 고객을 찾는 순서로 돌아가고 싶지는 않다.
직장을 유지하는 동안 정할 경계
지금의 생활을 유지하면서 제안하려면 내가 응답할 수 있는 시간부터 현실적으로 적어야 한다. 평일 낮에 즉시 대응할 수 없는데 실시간 서비스를 약속해서는 안 된다. 처리 주기와 연락 가능한 시간을 상대에게 알려야 한다.
회사에서 쓰는 자료, 계정, 장비, 업무 중 만든 결과물을 개인 사업에 사용할 수 있는지도 임의로 판단하지 않겠다. 겸업과 자료 사용에 관한 회사의 조건을 확인하고 필요한 경우 담당자에게 문의해야 한다. 이 글은 계약이나 법률 검토를 대신하지 않는다.
또한 생활비를 충당해야 하는 압박을 곧바로 첫 실험에 얹지 않으려 한다. 한 번의 거래로 안정적인 반복 수요를 확인했다고 볼 수는 없다. 서비스를 중단하거나 범위를 줄여야 할 때 고객에게 피해를 남기지 않는 마무리 방식도 준비해야 한다.
내가 감당할 수 있는 동시 작업 수와 비용 한도를 정해 두면 거절할 기준이 생긴다. 더 많은 사람에게 팔 수 있을 것 같다는 기대만으로 운영 부담을 늘리기보다, 현재의 약속을 지킨 뒤 다음 범위를 정하고 싶다.
다음 단계로 넘어갈 근거와 멈출 근거
첫 실험을 했다면 상대가 결과물을 어디에 썼는지, 다음에도 같은 작업을 맡길 이유가 있는지 확인하겠다. 무료로 한 번 받아 본 반응과 반복해서 비용을 낼 의사는 같지 않다. 반복성이 확인되면 공통 입력과 출력부터 제품화할 수 있다.
반대로 결과물을 거의 쓰지 않거나, 내 검토 시간 때문에 약속한 조건을 지킬 수 없거나, 자료 접근이 허용되지 않는다면 범위를 다시 정해야 한다. 실패를 숨기려고 새로운 기능을 늘리기보다 어떤 가정이 틀렸는지 남기는 편이 다음 선택에 도움이 된다.
나는 아직 첫 유료 고객의 성공담을 쓸 단계라고 주장하지 않는다. 지금 있는 자동화에서 내가 잘 아는 작업 하나를 고르고, 그 작업을 반복하는 사람이 현재 무엇을 불편해하는지 듣는 것이 먼저다. Base44의 인수 소식보다 이 작은 확인이 내 다음 행동을 더 구체적으로 정해 줄 것 같다.
참고자료
- Wix: Base44 인수 공식 발표 — 초기 인수 대가, 추가 지급 조건, 직원 유지 보너스에 관한 2025년 발표.
- Paul Graham: Do Things that Don't Scale — 초기 고객을 직접 찾고 돕는 일에 관한 창업자의 원문 에세이.