블로그를 만들고 자료를 정리하는 도구를 쓰다 보면 이런 생각이 든다. 내가 겪는 불편을 해결했으니 다른 사람도 돈을 내지 않을까. 하지만 내가 자주 쓰는 기능과 다른 사람이 비용을 지불할 서비스 사이에는 확인할 일이 꽤 많다.
Claude Code로 개발과 문서 작성을 돕게 할 수 있다. 그렇다고 고객 조사, 운영, 판매에 대한 판단까지 저절로 끝나는 것은 아니다. 이 글은 수익을 검증한 사업 후기가 아니라, 작은 AI 서비스를 준비할 때 사용할 작업 설계다. 예시는 자료를 모아 블로그 초안으로 바꾸는 서비스로 통일했다. 월 매출이나 인원 감축 같은 출처 불명 성공담은 판단 근거로 삼지 않는다.
아이디어 목록보다 먼저 확인할 고객의 현재 작업
공개 커뮤니티의 불만은 조사 출발점으로 쓸 수 있다. 다만 추천 수가 많은 글을 곧바로 구매 의사로 해석하면 곤란하다. 불편하다고 말하는 사람과 돈을 지불하는 사람이 다를 수 있고, 관심을 끄는 문제라도 발생 빈도가 낮으면 구독할 이유가 약하다.
미국 중소기업청의 시장 조사 안내도 수요, 대안, 시장 포화도, 기존 지출을 나눠 살펴보도록 설명한다. 공개 자료 조사와 고객에게 직접 묻는 조사를 구분한다는 점을 참고할 만하다. 한국의 특정 시장 수요를 이 문서가 입증하는 것은 아니다. SBA 사업 계획·시장 조사 안내
블로그 초안 서비스를 검토한다면 질문은 구체적이어야 한다. 최근 작성한 글에서 자료 수집에 얼마나 시간이 들었는가. 어디에 저장했고, 출처를 잃어버린 적은 있는가. 이미 쓰는 북마크나 노트 앱에서 무엇을 해결하지 못했는가. 사용자는 자료 정리와 문장 작성 중 어느 쪽을 더 어려워하는가. 답변은 표현 그대로 보관하고, 조사자의 해석은 다른 칸에 적는다.
AI에게는 공개 자료에서 반복되는 작업과 대안을 분류하게 할 수 있다. 각 항목에 원문 링크, 게시 시점, 발언 맥락을 붙이게 한다. 접근 제한을 우회하거나 개인 정보를 긁어모으는 수집은 하지 않는다. 링크 없는 ‘사용자들은 보통 이렇게 생각한다’는 문장은 조사 결과에서 제외한다. 관심이 있다는 답과 실제 사용 약속도 구분해야 한다.
조사 종료 조건도 정해 두면 좋다. 가령 서로 다른 사용자가 같은 작업을 반복하고, 현재 대안과 비교할 수 있으며, 시험 결과물을 받아 보겠다는 동의가 있을 때 첫 시제품을 준비한다. 이것은 통계적 수요 검증 기준이 아니라 작은 실험을 시작할 내부 판단 기준이다. 답이 갈리면 기능을 늘리기 전에 고객 범위를 좁힌다.
첫 제품은 입력 하나와 결과 하나로 설명할 수 있어야 한다
예시 서비스의 첫 흐름을 ‘사용자가 허용한 공개 URL 하나를 받아 출처가 표시된 초안을 만든다’로 잡아 보자. 회원 추천, 예약 발행, 여러 SNS 동시 업로드, 팀 결제까지 한꺼번에 넣으면 실패 원인을 구분하기 어렵다. 첫 결과가 읽을 만한지 확인하기 전에 주변 기능에 시간을 쓰게 된다.
아래 항목은 구현 전 사용할 예시 명세다. 실제 서비스가 제공 중인 기능을 뜻하지 않는다.
| 항목 | 첫 실험에서 정할 내용 |
|---|---|
| 입력 | 사용자가 제공한 공개 문서 한 개, 대상 독자와 질문 |
| 출력 | 원문과 해석을 구분한 초안, 확인한 출처, 확인하지 못한 항목 |
| 성공 | 사용자가 원문을 다시 전부 읽지 않고도 검토할 지점을 찾음 |
| 실패 | 잘못된 인용, 로그인 자료의 무단 수집, 다른 사람의 경험을 작성자 경험으로 표현 |
| 제외 | 자동 공개, 자동 결제, 원문 전체 복제, 무제한 수집 |
성공 조건의 문장도 시험에서 관찰할 수 있게 바꿔야 한다. 사용자가 초안에서 원문으로 이동할 수 있는지, 인용을 찾는 데 막히는지, 수정 후 다시 쓰고 싶어 하는지를 본다. ‘만족도가 높았다’는 말만 남기면 다음 수정의 근거가 약하다. 실제 검토 시간과 수정 이유를 기록하되, 소수 참가자의 결과를 전체 시장의 성과처럼 발표하지 않는다.
AI 호출 없이 해결되는 부분도 구분한다. URL 형식 검사, 중복 입력 방지, 날짜 정규화는 일반 코드로 처리할 수 있다. 복잡한 에이전트 구성이 필요하다고 미리 결론 내릴 이유는 없다. Anthropic도 먼저 단순한 해결책을 찾고 필요할 때 복잡도를 늘리는 접근을 제안한다. Building effective agents
서브 에이전트에는 직함보다 입력과 권한을 준다
Claude Code의 서브 에이전트는 별도 컨텍스트에서 작업하며 도구와 권한을 제한할 수 있다. 그렇다고 여러 에이전트를 켜기만 하면 업무가 정확히 나뉘는 것은 아니다. 무엇을 읽고 어디에 결과를 쓰는지 지정해야 한다. Claude Code 서브 에이전트 문서
작은 시제품에서는 자료 조사 담당에게 공개 문서 읽기와 출처 목록 작성만 맡긴다. 구현 담당은 승인된 명세와 지정한 코드 경로만 수정한다. 검토 담당은 명세와 변경 결과를 받아 예외 처리, 접근 권한, 출처 표시를 확인한다. 세 역할 모두 결제나 외부 게시 권한을 가질 필요는 없다.
동시에 진행해도 되는 일과 순서가 필요한 일은 다르다. 같은 파일을 고치는 두 작업을 무작정 병렬로 돌리면 충돌이 난다. 반면 공개 문서 확인과 기존 코드의 읽기 전용 조사는 독립적으로 진행할 수 있다. 담당자는 수정 경로와 반환 형식을 먼저 합의하고, 통합 시점에 충돌 여부를 확인한다.
반환 보고에는 완료한 파일, 실행한 검사, 실행하지 못한 검사, 미해결 질문이 들어가야 한다. ‘개발 완료’라는 문장만으로 다음 단계에 넘기지 않는다. 로그인 실패를 해결하려고 권한을 넓히거나, 테스트를 통과시키려고 기대 결과를 바꾸는 행동도 막아야 한다. 제한된 작업을 맡기는 이유는 사람을 흉내 내는 조직도를 만들기 위해서가 아니라 결과를 검토할 수 있게 하기 위해서다.
가격을 정하기 전에 실패한 요청의 비용부터 적는다
AI 서비스의 비용을 성공한 호출 한 번의 요금으로만 계산하면 빠지는 것이 많다. 자료를 못 읽어 다시 시도하는 호출, 사람이 고치는 시간, 저장과 백업, 고객 문의, 취소 처리가 모두 운영 시간을 쓴다. 무료 체험 사용자가 늘어도 이 비용은 발생한다.
예시 원가 장부에는 요청별 모델 사용량, 재시도 횟수, 수동 검수 시간, 저장량을 따로 둔다. 고정비는 월 단위로, 변동비는 성공한 결과물 단위로 집계한다. 이 글에는 실제 측정치가 없으므로 특정 가격이나 이익률을 제시하지 않는다. 요금제와 API 단가는 변할 수 있으니 시제품 시험 때의 공급자 가격과 측정 날짜를 함께 남겨야 한다.
지원 요청도 제품 개선 자료다. 사용자가 결과를 지우고 싶다고 했는데 삭제 경로가 없다면 문장 품질보다 먼저 해결해야 한다. 사용 중인 자료를 다른 도구로 가져갈 수 있는지, 서비스가 중단되면 무엇을 내보낼 수 있는지도 설명할 수 있어야 한다. 혼자 운영할수록 기능 설명보다 이러한 예외 처리를 문서로 남겨 둘 필요가 있다.
계속할 기준과 멈출 기준을 나란히 적는다. 재사용하는 사람이 있고 수정 부담이 줄어들면 다음 기능을 검토한다. 반대로 유료 의사가 없는데 검수 비용만 계속 늘거나 민감한 자료가 필수라면 서비스 범위를 바꾸는 편이 낫다. 더 비싼 모델로 바꾸는 결정은 실패 종류를 확인한 뒤에 한다.
마케팅 자동화는 초안 생성과 외부 발행을 분리한다
블로그 글 하나에서 뉴스레터 소개문이나 짧은 SNS 문구를 만드는 작업은 AI가 도울 수 있다. 원문에 없는 성과, 고객 후기, 사용 경험을 덧붙이지 않도록 원고와 확인된 사실 목록을 함께 제공한다. 클릭을 유도하려고 내용을 바꾼 제목은 원문과 다시 대조한다.
첫 실험에서는 외부 발행을 별도 단계로 둔다. 대상 채널, 계정, 발행 시각과 승인한 문안을 확인한 뒤 게시한다. 같은 요청을 다시 실행해도 중복 게시하지 않도록 콘텐츠 식별자와 발행 결과를 저장한다. 인증 오류가 나면 재시도 횟수를 늘리는 대신 중단하고 계정 상태를 확인한다. 구독 의사를 밝히지 않은 사람에게 대량으로 메시지를 보내는 흐름은 넣지 않는다.
성과를 볼 때도 게시물 수만 세지 않는다. 어떤 설명을 읽은 사람이 시험에 참여했고, 어디에서 기대와 결과가 달랐는지 확인한다. 자료 정리가 필요한 독자에게 화려한 완전 자동화 이야기를 하면 잘못된 기대를 만들 수 있다. 제품이 아직 초안 도구라면 검토가 필요하다는 사실을 안내해야 한다.
첫날에 할 수 있는 일은 꽤 명확하다. 대상 작업 하나를 적고, 현재 대안을 조사하고, 시험할 출력 형식을 만든다. 그다음 실제 사용자가 결과를 검토할 약속을 잡는다. 코드를 얼마나 많이 생성했는지는 이후의 문제다. 사용자가 다음번 같은 일을 할 때 이 도구를 다시 찾는지 확인할 수 있어야 사업의 다음 단계를 논의할 수 있다.
참고자료
- Claude Code — Create custom subagents: 컨텍스트, 도구 범위와 서브 에이전트 구성 확인.
- Anthropic — Building effective agents: 단순한 워크플로에서 시작하는 설계 관점.
- U.S. Small Business Administration — Plan your business: 수요, 대안과 직접 조사를 구분하는 시장 조사 안내.