B2B SaaS 검증, 코딩 전에 해야 할 일: AI 고객 인터뷰 3가지 유즈케이스와 90일 로드맵

한 줄 결론

B2B SaaS 검증에서 가장 먼저 줄여야 할 것은 코드 작성 시간이 아니라, 틀린 고객 문제를 전제로 한 개발 시간이다.
AI는 인터뷰를 대신해 주는 심사위원이 아니라, 메모 정리·반례 탐색·수동 서비스 설계의 반복 작업을 줄이는 보조 도구로 쓸 때 가치가 있다.
다음 90일의 목표는 앱 출시가 아니라 “누가, 어떤 불편 때문에, 어떤 대가를 치를 의향이 있는가”를 증거로 바꾸는 일이다.

개발자는 문제를 발견하면 구현부터 하고 싶어진다. 특히 퇴근 후 몇 시간밖에 없는 1인 창업자라면 더 그렇다. 화면 한 장을 만들고, 인증을 붙이고, 결제를 연결하면 앞으로 나아가는 기분이 든다. 그러나 B2B SaaS 검증에서 가장 비싼 실패는 기능이 부족한 제품이 아니라, 실제 업무 흐름에 들어갈 이유가 없는 제품을 완성해 버리는 일이다.

이 글은 “인터뷰를 많이 하라”는 말에서 멈추지 않는다. AI 고객 인터뷰 분석을 어디에 쓰면 좋은지, 무엇은 사람이 계속 판단해야 하는지, 그리고 코딩을 언제 시작하거나 멈출지를 90일 계획으로 정리한다. 특정 AI 서비스의 사용기는 아니며, 도구의 결과를 직접 검증하지 않고 신뢰해서는 안 된다는 전제에서 썼다.

B2B SaaS 검증에서 왜 코딩보다 증거를 먼저 모아야 하나

문제 검증은 사람들에게 “이 제품이 있으면 쓰시겠어요?”라고 묻는 일이 아니다. 그 질문은 대개 예의 있는 긍정 답변을 얻는다. 더 유용한 질문은 이미 벌어진 일로 향한다. 마지막으로 이 업무가 막힌 시점은 언제였는지, 지금은 어떤 파일·사람·외주·엑셀로 버티는지, 지연되면 누가 어떤 비용을 떠안는지, 예외 상황에서 무엇이 깨지는지를 묻는다.

YC의 인터뷰 가이드는 창업자가 사용자에 대해 무엇을 배웠고 어떤 행동이 예상과 달랐는지 설명할 수 있어야 한다고 본다. Steve Blank의 Customer Development 설명 역시 발견과 검증을 제품 기능이 아니라 비즈니스 모델을 반복해서 시험하는 과정으로 다룬다. 두 자료가 보장하는 것은 성공법이 아니다. 다만 “아이디어를 증명하려는 대화”보다 “현재 행동을 이해하려는 대화”가 먼저라는 기준을 준다.

1인 개발자에게 이 순서는 생존 장치다. 초기에는 코드 품질보다 고객 접근과 업무 맥락이 더 희소하다. 같은 인증·결제·대시보드를 다시 만드는 비용은 예측할 수 있지만, 잘못 고른 구매자와 잘못 고른 문제를 몇 달 뒤에 바꾸는 비용은 훨씬 늦게 드러난다.

먼저 확인할 것	인터뷰에서 찾을 증거	아직 증거가 아닌 것
문제의 빈도	최근 사례, 발생 조건, 관련 담당자	“그런 기능이 있으면 좋겠다”
현재 대안	엑셀·외주·기존 SaaS·수작업의 실제 흐름	경쟁 제품 목록만 수집한 결과
전환 비용	데이터 이동, 승인, 보안, 학습 부담	“가격만 싸면 바꾼다”는 가정
지불 가능성	예산 주체, 구매 절차, 유료 수동 서비스 반응	설문 좋아요나 대기자 수만으로 내린 결론

AI 고객 인터뷰 분석은 왜 쓰는가

인터뷰가 늘어나면 병목은 녹음 파일이 아니라 비교다. 서로 다른 직무의 표현을 같은 문제로 묶어도 되는지, 한 명의 강한 불만이 반복 신호인지, 내가 듣고 싶은 말만 표시하고 있지 않은지 판단하기 어려워진다. AI는 이 반복 정리 작업을 빠르게 시작하게 해 준다. 하지만 모델이 붙인 라벨은 증거가 아니라 검토할 가설이다.

구조화 출력은 이 작업에 쓸 수 있는 구현 선택지다. OpenAI의 공식 문서는 JSON Schema 기반 Structured Outputs와 strict 설정을 설명한다. 예를 들어 인터뷰 메모를 문제, 현재 대안, 발생 계기, 구매자, 인용 가능한 원문, 확신도, 추가 질문 필드로 정리하게 만들 수 있다. 형식이 일정해지면 비교는 쉬워진다. 형식이 일정해졌다고 내용이 참이 되는 것은 아니다.

고객의 이름, 계약 내용, 내부 지표, 개인 연락처가 담긴 원문을 외부 AI 서비스에 넣기 전에는 동의·계약·보존 정책을 확인해야 한다. OpenAI는 API와 Business·Enterprise 입력/출력을 기본적으로 모델 개선에 사용하지 않는다고 안내하지만, 이 정책은 각 회사의 법적 의무나 고객과의 약속을 대신하지 않는다. 가장 안전한 시작은 식별자를 지운 짧은 메모, 최소한의 필요한 문장, 사람이 확인할 수 있는 원문 링크다.

AI 고객 인터뷰 3가지 유즈케이스

1. 인터뷰 메모를 ‘문제 카드’로 표준화하기

사용자는 퇴근 후 인터뷰 기록을 정리하는 1인 개발자다. 입력은 동의를 받고 정리한 메모다. AI에는 문제를 해결하라고 시키지 말고, 원문에 있는 사실과 해석을 분리해 정해진 필드로 반환하도록 요청한다. 결과는 문제 카드 초안이다.

카드에는 “무엇이 불편한가” 외에 반드시 마지막 발생 시점, 현재 우회 방법, 영향을 받는 역할, 원문 근거, 확인할 반례를 넣는다. 성공 기준은 카드 수가 늘어나는 것이 아니라, 다음 인터뷰에서 같은 질문으로 비교할 수 있게 되는 것이다. 실패 지점은 AI가 빈칸을 그럴듯한 문장으로 채우는 경우다. 빈칸은 빈칸으로 남겨야 한다.

2. 내 가설을 반박하는 질문을 만들기

창업자는 인터뷰를 하면서 점점 자신의 제품 설명을 잘하게 된다. 그 순간 인터뷰는 조사보다 영업 피치가 되기 쉽다. 두 번째 유즈케이스는 인터뷰 전에 “이 가설이 틀렸다면 어떤 답이 나올까?”를 적고, AI에게 반박 질문·대체 설명·세분화 기준을 제안하게 하는 일이다.

예를 들어 “회계팀은 마감 자동화를 원한다”는 가설이 있다면, 질문은 기능 선호가 아니라 최근 마감에서 실제로 막힌 단계, 현재 승인권자, 오류를 감수하지 못하는 지점으로 바뀌어야 한다. 예상 출력은 다음 대화에서 검증할 질문 목록이다. 성공 기준은 제품 설명을 덜 하고도, 고객의 현재 행동을 더 구체적으로 기록하는 것이다. 제안된 질문은 유도 질문인지 사람이 먼저 걸러야 한다.

3. 코드를 쓰기 전에 수동 서비스 흐름을 설계하기

세 번째 유즈케이스는 가장 실용적이다. 인터뷰에서 반복된 문제가 보이면, AI에게 앱 화면이 아니라 사람이 수동으로 제공할 서비스 흐름을 여러 개 만들게 한다. 예를 들어 매주 고객의 CSV를 받아 위험 항목을 정리해 주는 서비스, 고객 지원 티켓을 분류하고 우선순위를 제안하는 서비스, 갱신 대상 계정을 사람이 검토하는 서비스가 될 수 있다.

입력은 확인된 업무 흐름과 금지 조건이다. 단계는 “고객이 무엇을 주는가 → 창업자가 무엇을 검토하는가 → 무엇을 돌려주는가 → 고객이 다음에 무엇을 결정하는가”로 쪼갠다. 출력은 한 주 동안 실제로 수행할 운영 매뉴얼이다. 성공 기준은 고객이 결과물을 다시 요청하거나, 그 결과에 시간을 내거나, 유료 전환을 논의하는지다. 성공 기준이 “랜딩 페이지가 예쁘다”가 되어서는 안 된다.

AI가 대신하면 안 되는 판단

AI는 반복된 표현을 묶을 수 있지만, 불편의 강도와 구매의 긴급도를 판정하지는 못한다. 특히 다음 네 가지는 창업자가 원문과 맥락으로 확인해야 한다.

한 고객의 불만이 특정 회사의 내부 절차인지, 같은 역할에서 반복되는 문제인지
사용자는 불편해하지만 구매자는 다른 사람인지
수동 서비스가 실제로 가치 있는지, 단지 창업자에게 친절한 무료 노동인지
개인정보·보안·도입 승인 때문에 제품화 비용이 예상보다 커지는지

최근 B2B SaaS 커뮤니티에서도 기능 요청이 실제 채택으로 이어지지 않는다는 경험과, 먼저 목표 고객에게 도달할 수 있는지 검증해야 한다는 의견이 함께 나온다. 이는 한 Reddit 토론의 경험담일 뿐 통계가 아니다. 그래도 “요청을 받았다”와 “업무 흐름에 들어갔다”를 분리해야 한다는 경고로는 충분하다.

90일 B2B SaaS 검증 로드맵

이 로드맵은 90일 안에 퇴사하거나 매출을 보장하는 계획이 아니다. 개발 시간을 크게 쓰기 전에 다음 결정을 더 정확히 내리기 위한 계획이다. 각 단계의 통과 기준을 충족하지 못하면 기능을 추가하는 대신, 세그먼트·문제·접근 경로를 다시 좁힌다.

1–2주차: 한 역할과 한 업무 장면을 고른다.
– 고객 증거: 같은 직무의 최근 업무 사례를 듣고, 현재 대안과 실패 비용을 기록한다.
– 산출물: 문제 카드와 인터뷰 질문 1세트.
– 비용·위험: 지인에게 피치하는 대신, 기존 네트워크를 소진할 수 있다. 먼저 “제품 판매가 아니라 업무 이해를 위한 짧은 대화”라는 범위를 분명히 한다.
– 통과/중단: 서로 독립적인 대화에서 같은 업무 장면과 우회 방법이 반복되면 다음 단계로 간다. 반복이 없으면 세그먼트를 좁히거나 문제를 바꾼다.
3–4주차: 수동 결과물을 한 번 제공한다.
– 고객 증거: 고객이 실제 자료 또는 실제 상황을 제공하고, 결과물을 업무에 사용해 본다.
– 산출물: 사람이 운영한 한 가지 결과물과 소요 시간 기록.
– 비용·위험: 무상 컨설팅이 길어질 수 있다. 제공 범위·기간·데이터 처리 방식을 한 페이지로 합의한다.
– 통과/중단: 고객이 결과물의 수정·반복·다음 일정에 시간을 쓰면 계속한다. 결과물을 받기만 하고 행동이 없으면 기능보다 문제의 긴급도를 재검토한다.
2개월차: 반복 가능한 한 가지 약속을 판다.
– 고객 증거: 결과물의 가치를 구매자와 함께 정의하고, 유료 또는 유료 전환이 명시된 파일럿을 제안한다.
– 산출물: 단일 고객 세그먼트용 제안서, 운영 체크리스트, 실패 시 환불·중단 기준.
– 비용·위험: 가격을 너무 일찍 일반화하거나, 맞춤 작업을 제품 기능으로 착각할 수 있다.
– 통과/중단: 고객이 예산·계약·결제 중 하나를 실제로 논의하면 제품화 후보로 남긴다. 관심만 반복되면 접근 경로나 약속을 다시 설계한다.
3개월차: 자동화할 한 단계만 고른다.
– 고객 증거: 수동 흐름 중 매주 반복되고 오류 비용이 있는 단계가 확인된다.
– 산출물: 자동화 대상 하나, 수동 대체 경로, 최소 권한·데이터 처리 설계.
– 비용·위험: 로그인·대시보드·설정 화면부터 만들면 다시 제품이 커진다. 고객이 돈을 내는 결과가 아니라 내부 편의부터 자동화하지 않는다.
– 통과/중단: 자동화가 결과물의 품질·속도·신뢰 중 하나를 개선한다는 근거가 있으면 개발한다. 근거가 없으면 수동 운영을 연장하거나 중단한다.

개발감자의 판단

직접 특정 AI 도구로 고객 인터뷰를 운영해 본 사용기는 아니다. 공개 방법론과 공식 문서를 바탕으로 한 운영 설계다. 그 전제에서 세 가지 판단을 남긴다.

AI는 인터뷰 수를 늘리는 도구보다 비교 가능성을 높이는 도구로 써야 한다. 인터뷰가 부족한 상태에서 요약만 빨라지면 잘못된 가설을 더 빨리 정리할 수 있다.
수동 서비스는 실패한 자동화가 아니다. 고객이 무엇을 사는지, 어디에서 결과를 신뢰하는지, 어떤 데이터가 필요한지를 배우는 가장 값싼 제품 경로가 될 수 있다.
퇴사 목표가 있다면 ‘출시일’보다 증거의 연속성이 중요하다. 반복 독자, 고객 대화, 유료 파일럿, 운영 가능한 주간 리듬은 서로 다른 증거다. 한 가지가 생겼다고 나머지를 건너뛰면 위험이 커진다.

이번 주에 직접 해볼 것

한 업종·한 역할·한 업무 장면만 적는다. “소상공인용 AI”처럼 넓은 문장은 금지하고, 예를 들어 “월말에 여러 채널의 주문 오류를 확인하는 온라인 쇼핑몰 운영 담당자”처럼 쓴다.
제품 설명 없는 질문 다섯 개를 만든다. 마지막 발생 사례, 현재 대안, 지연 비용, 관련자, 예외 상황만 묻는다.
인터뷰 후에는 원문을 지키고, AI에는 식별자를 지운 메모만 준다. 문제 카드의 원문 근거와 확인할 반례 칸은 사람이 채운다.
반복된 문제 하나에 대해 한 주짜리 수동 결과물을 제안한다. 고객이 실제 자료를 줄지, 결과물에 다시 시간을 쓸지 기록한다.
다음 글로는 사이드 프로젝트 생존 공식에서 일과 창업 실험을 병행하는 기준을, 제품 구현을 고민한다면 Lovable vs Bolt MVP 비교에서 구현 도구의 선택 기준을 확인한다.

결론

조건부 추천이다. AI는 B2B SaaS 검증의 기록·비교·수동 운영 설계를 빠르게 만들 수 있다. 하지만 고객 문제의 진실성, 구매자의 존재, 데이터 처리의 책임, 자동화할 순서는 사람이 결정해야 한다. 다음 90일에 만들 것은 거대한 MVP가 아니라, 고객의 실제 업무에 한 번이라도 들어가 본 작은 결과물이어야 한다. 그 결과물이 반복될 때에만 코드는 시간을 절약하는 자산이 된다.