계기

최근 Threads에서 누군가 AI에게 “72시간을 줄 테니 100만 원을 벌어 와”라고 시켰고 실제로 성공했다는 사례가 공유됐다. 그 뒤로 “48시간 안에 50만 원을 벌어 와”처럼 조건을 바꾼 도전이 잇따라 올라왔다.

나도 이 흐름이 궁금했다. ChatGPT Pro를 계속 구독하고 있는 만큼, AI가 단순히 아이디어를 제안하는 수준을 넘어 구독료를 상쇄할 만한 실제 경제적 보상까지 이어질 수 있는지 시험해 보고 싶었다.

다만 처음 공유된 성공 사례에는 이미 AI 분야에서 영향력을 가진 사람의 유통망이 있었다. AI가 전자책을 만들더라도 베타테스터를 모으고 SNS와 메신저로 홍보할 기존 독자가 있었기 때문에 가능한 흐름이었다. 나는 같은 조건을 갖고 있지 않았다. 성공 사례의 결과만 따라 하기보다, 내 조건에서도 반복할 수 있는 구조를 따로 만들어야 했다.

목적

처음 생각한 목표는 짧은 시간 안에 30만 원, 가능하면 그 이상을 버는 것이었다. 하지만 프로젝트를 시작하면서 목표를 둘로 나눴다.

첫 번째는 실제 판매 가능한 결과물을 만드는 것이다. AI가 사업 아이디어 목록만 작성하거나 고객에게 연락하라는 계획을 내놓고 끝나는 것은 성과로 계산하지 않았다.

두 번째는 다음 상품에도 다시 사용할 수 있는 운영 흐름을 만드는 것이다. AI가 조사, 비교, 구현, 테스트, 문서화와 초안 작성을 맡고, 사람은 가격, 라이선스, 환불 정책, 외부 게시와 계정 작업처럼 책임이 필요한 지점을 승인하는 방식이다.

이 실험에서 다음은 서로 다른 상태로 기록한다.

  • 상품을 만들었다.
  • 상품을 공개했다.
  • 누군가 관심을 보였다.
  • 실제 고객이 결제했다.
  • 비용과 환불을 제외한 수익을 받았다.

앞 단계가 끝났다고 뒤 단계까지 성공한 것으로 취급하지 않는 것이 기본 원칙이다.

사고 흐름

처음에는 SaaS, 고객을 정한 뒤 직접 판매하는 서비스, 버그 바운티와 공모전처럼 서로 다른 선택지가 섞여 있었다. 이번에는 그중에서 개발자가 혼자 만들 수 있고, 한 번 만든 뒤 반복해서 판매할 수 있는 작은 디지털 자산을 첫 실험으로 골랐다.

후보를 무한히 늘리지 않고 세 개만 비교했다.

후보 내부 평가
로컬 CSV 검사와 값이 가려진 HTML 보고서 86/100
Python·Node CI 상태 진단 팩 84/100
한국어 LLM 회귀 테스트 도구 75/100

평가에는 권리와 라이선스, 짧은 시간 안의 제작 가능성, 문제 수요의 흔적, 데모의 명확성, 재사용성, 지원 부담과 한국에서의 지급 경로를 사용했다. 이 점수는 시장 수요가 있다는 증거가 아니다. 첫 실험으로 무엇을 선택할지 결정하기 위한 도구다.

DataProof CSV를 고른 이유는 문제와 결과가 좁고 분명했기 때문이다. CSV가 규칙을 지키는지 검사하고, 자동화가 읽을 결과와 사람이 공유할 보고서를 만든다. 합성 데이터로 동작을 재현할 수 있어 실제 개인정보를 사용할 필요도 없었다.

CI 진단 팩은 언어와 도구 버전이 변할 때마다 유지보수할 위험이 더 컸고, LLM 회귀 테스트는 데이터 권리와 API 비용, 결과의 비결정성이 부담이었다. 가장 거창한 아이디어보다 완성하고 검증할 수 있는 범위를 먼저 택했다.

수익을 위한 흐름

상품 하나를 만든다고 자동으로 수익이 생기지는 않는다. 이번 프로젝트에서는 다음 흐름을 한 번 끝까지 연결하는 것을 우선했다.

  1. 개발자가 돈을 낼 수도 있는 좁은 문제를 찾는다.
  2. 후보를 비교하고 하나만 선택한다.
  3. 실제 구매자가 받을 소스, 예제, 테스트와 문서를 만든다.
  4. 기능, 개인정보, 권리, 라이선스와 패키징을 검증한다.
  5. 가격과 외부 공개 범위를 사람이 승인한다.
  6. Gumroad에 상품을 공개한다.
  7. 문제 해결에 도움이 되는 기술 글로 검색 유입 경로를 만든다.
  8. 조회, 체크아웃, 실제 판매, 환불과 순지급액을 분리해 관찰한다.
  9. 관찰 결과에 따라 설명을 바꿀지, 범위를 보완할지, 다음 상품으로 넘어갈지 결정한다.

첫 판매처로는 Gumroad를 사용했다. 외부 유입 경로는 여러 커뮤니티에 같은 홍보 글을 뿌리는 대신 DEV 기술 글 하나로 시작했다.

신규 Reddit 계정으로 바로 제품 링크를 올리는 방식은 피했다. 반면 DEV에서는 새 작성자가 기술 글을 올리는 것이 자연스러웠다. 그래서 상품 광고보다 “CSV 검사 보고서가 실패한 원본 값을 다시 노출하면 안 되는 이유”를 중심으로 영문 기술 글을 작성하고 마지막에만 상품 링크와 제작자·AI 지원 사실을 공개했다.

이 블로그 글도 같은 흐름의 일부다. DEV 글이 제품의 기술적 판단을 설명한다면, 이 글은 왜 이 실험을 시작했고 어떤 순서로 출시까지 갔는지를 기록한다.

제품 설명

DataProof CSV는 UTF-8 CSV를 작은 JSON contract에 따라 로컬에서 검사하는 Python 소스 도구다. 별도 런타임 패키지를 설치하거나 CSV를 외부 서비스에 업로드하지 않고 실행할 수 있다.

주요 결과는 세 가지다.

  • 셸이나 CI가 판단할 수 있는 종료 코드 0, 1, 2
  • 다른 자동화가 읽을 수 있는 JSON
  • 팀원에게 전달할 수 있는 단일 HTML 보고서

필수값, 타입, 범위, 허용값과 중복 같은 규칙을 검사한다. 특히 실패한 셀 값은 기본 보고서에서 숨긴다. 원본 CSV가 로컬에 남더라도 보고서가 이메일 주소나 거래 식별자를 다시 퍼뜨릴 수 있기 때문이다.

구매자 묶음에는 편집 가능한 Python 소스와 보고서 템플릿, 자동 테스트 7개, 정상·실패 합성 예제, JSON·HTML 예시, README, 데모, 라이선스·권리·출처와 SBOM 자료가 들어 있다. 상품은 독점 소프트웨어가 아니라 MIT 비독점 소스 묶음이다.

현재 버전은 Python 3.10+와 메모리에 들어오는 UTF-8 CSV를 전제로 한다. Excel, CP949, TSV, 인코딩 추정, 자동 수정, 대용량 스트리밍, 서명된 Windows 실행 파일과 맞춤 통합은 포함하지 않는다.

출시 전후 검증에서는 정상·실패 합성 예제와 실행할 수 없는 파일을 통해 종료 코드가 구분되는지, JSON과 HTML이 생성되는지, 기본 보고서에서 실패 값이 가려지는지 확인했다. 이 글은 QA 보고서가 아니므로 세부 명령과 해시는 내부 근거 기록에 남겨뒀다.

차후 기다려봐야 하는 부분

현재 확인된 것은 Gumroad 상품과 DEV 글을 공개했다는 사실이다. 출시 직후 저장소 기록에서 실제 구매와 판매액은 0이었다. 무과금 creator test purchase는 실제 판매로 계산하지 않았다.

이제 기다리면서 구분해야 할 것은 다음과 같다.

  • 상품과 글이 검색 또는 외부 링크를 통해 발견되는가
  • Gumroad 상품 페이지까지 방문하는 사람이 있는가
  • 방문은 있지만 체크아웃이나 구매가 없는가
  • 설치, schema 작성, 실행 파일 같은 반복 문의가 생기는가
  • 실제 구매, 환불, 분쟁과 순지급액이 발생하는가

조회가 거의 없다면 제품 기능보다 유통 경로를 먼저 살펴야 한다. 조회는 있지만 구매나 문의가 없다면 제목, 설명, 가격 또는 문제의 중요도를 다시 봐야 한다. Python 설치 문의가 반복된다면 실행 파일 패키지를 검토할 수 있고, schema 작성 요청이 반복된다면 별도 설정 서비스가 다음 자산 후보가 될 수 있다.

반대로 외부 신호가 없는데 기능을 계속 추가하거나 바로 가격을 낮추지는 않을 생각이다. 일정 기간 실제 데이터를 관찰한 뒤 현재 상품을 개선할지, 다음 디지털 자산으로 넘어갈지 결정해야 한다.

지금 단계의 결론은 “AI가 돈을 벌었다”가 아니다.

Threads에서 본 짧은 수익 도전을 그대로 따라 하는 대신, AI가 조사·제작·검증을 맡고 사람이 책임 있는 결정을 승인하는 방식으로 첫 상품을 출시했다. 이제 기다려봐야 하는 것은 이 흐름이 실제 고객 문제와 수익으로 이어지는가이다.