AI 기능을 기획할 때 가장 먼저 받는 질문은 대개 "어떤 AI를 붙일까"다. 어떤 모델을 쓸지, UX는 어떻게 할지, 언제 출시할지를 논의하다 보면 정작 중요한 질문이 뒤로 밀린다. 사용자가 왜 ChatGPT 대신 이 제품의 AI를 써야 하는가.
이 질문에 답을 못 한 채 출시된 AI 기능은 대부분 비슷한 경로를 밟는다. 초기에는 신기하다는 반응이 나오지만, 사용자는 몇 번 써보고 나서 같은 결과를 범용 AI에서도 얻을 수 있다는 사실을 안다. 그때부터 기능은 쓰이지 않는다.
실패가 생기는 지점은 기술이 아니라 설계 순서다
AI 기능 도입 실패의 패턴은 기술 선택의 문제가 아닌 경우가 많다. 더 정확히는, 차별성을 만들어줄 자산을 확보하기 전에 기능 구현부터 시작했을 때 발생한다.
채용 플랫폼이 자기소개서 생성 기능을 만든다고 가정해보자. 경력과 지원 직무를 입력하면 초안이 나오는 구조다. 기능 자체는 분명히 편리하다. 하지만 사용자 입장에서 같은 내용을 ChatGPT에 붙여 넣으면 비슷한 결과가 나온다는 걸 알게 되는 순간, 그 기능은 경쟁력을 잃는다.
조기 신호는 사용률 데이터보다 먼저 나타난다. 기획 단계에서 "우리 AI가 범용 AI보다 더 잘 할 수 있는 근거가 무엇인가"라는 질문에 누구도 명확히 답하지 못한다면, 그 기능은 출시 전부터 이미 위험 상태다. 반면 같은 채용 플랫폼이라도 실제 서류 통과 이력, 직무별 합격 자기소개서의 구성 패턴, 특정 기업이 요구하는 역량 키워드처럼 플랫폼 내부에만 존재하는 데이터를 반영할 수 있다면, 범용 AI가 흉내 낼 수 없는 기능이 된다.
차이는 기술 스택이 아니라, 어떤 자산을 기능에 연결하느냐에서 온다.
도메인 자산의 세 가지 종류
요구사항 단계에서 확보해야 할 도메인 자산은 크게 세 범주로 나뉜다.
첫째, 행동 데이터. 사용자가 플랫폼 안에서 실제로 남긴 흔적이다. 어떤 콘텐츠를 클릭했는지, 어떤 순서로 행동했는지, 어디서 이탈했는지가 여기에 해당한다. 범용 AI는 이 데이터에 접근하지 못한다. 이 데이터를 AI에 연결하면 "일반적으로 좋은 결과물"이 아니라 "이 플랫폼 사용자에게 실제로 통한 결과물"을 만드는 기반이 된다.
둘째, 성과 연결 데이터. 단순히 콘텐츠가 생성됐다는 사실이 아니라, 그 콘텐츠가 사용자의 목표 달성에 어떤 영향을 미쳤는지를 추적한 데이터다. 채용 플랫폼이라면 특정 형식의 자기소개서가 서류 통과율에 어떤 관계를 보였는지, 매칭 플랫폼이라면 어떤 구조의 포트폴리오가 실제 고용으로 이어졌는지가 이에 해당한다. 이 데이터가 없으면 AI는 그럴듯한 글을 생성하는 도구에 그치고, 있으면 사용자의 목표에 더 가까워지게 하는 도구가 된다.
셋째, 도메인 맥락. 해당 산업이나 서비스 영역에서만 의미를 갖는 용어, 판단 기준, 제약 조건이다. 의료 플랫폼에서 환자-의사 간 소통에 쓰이는 표현, 법률 서비스에서 계약서 작성에 요구되는 형식, 특정 업종에서 통용되는 평가 기준 같은 것들이 여기에 포함된다. 이런 맥락은 범용 AI에 프롬프트로 전달해도 완전히 재현하기 어렵다. 플랫폼이 수년간 축적한 운영 경험에서만 나오는 판단이기 때문이다.
요구사항 단계에서 확인해야 할 질문들
도메인 자산 확보를 요구사항 단계에 포함시키려면, 기능 정의보다 앞서 아래 질문에 답해야 한다.
우리 플랫폼에만 있고 범용 AI가 접근할 수 없는 데이터는 무엇인가. 지금 당장 활용 가능한 상태인지, 아니면 수집 또는 정제 과정이 필요한지도 함께 확인해야 한다. 데이터가 존재하더라도 정제되지 않은 상태라면 AI에 바로 연결하기 어렵고, 이는 일정과 범위에 직접 영향을 준다.
사용자가 AI 기능을 통해 궁극적으로 도달하고자 하는 성과가 무엇인지도 명확히 해야 한다. 글쓰기 시간 단축이 목적인지, 실제 전환이나 고용, 구매 같은 결과 개선이 목적인지에 따라 AI에 연결해야 할 데이터와 평가 지표가 완전히 달라진다. 이 차이를 요구사항 단계에서 구분하지 않으면, 나중에 "기능은 만들었는데 효과가 없다"는 결론을 피하기 어렵다.
마지막으로, 지금 확보한 도메인 자산이 경쟁자가 6개월 안에 복제할 수 없는 것인지 따져봐야 한다. 데이터 자체보다 그 데이터를 축적하는 데 걸린 시간, 사용자 신뢰, 운영 노하우가 진입 장벽이 된다. 기능 자체는 복제될 수 있지만, 실제 성과 이력은 복제되지 않는다.
도메인 자산이 없을 때 어떻게 시작할 것인가
도메인 자산이 아직 충분하지 않다면, AI 기능을 후순위에 두고 자산을 먼저 쌓는 구조를 설계하는 편이 낫다. 예를 들어, AI 기능을 출시하기 전에 사용자가 남기는 행동 데이터를 체계적으로 수집하는 과정을 선행 요구사항으로 정의할 수 있다. 성과 연결 데이터도 마찬가지다. 어떤 행동이 어떤 결과로 이어졌는지를 추적하는 구조가 먼저 있어야, 나중에 AI가 그 패턴을 학습하거나 반영할 수 있다.
이 접근은 출시를 늦추는 것처럼 보일 수 있다. 하지만 도메인 자산 없이 먼저 출시한 AI 기능은 사용자에게 "ChatGPT와 다를 게 없다"는 인식을 심어준다. 그 인식을 바꾸는 데는 기능을 새로 만드는 것보다 더 많은 비용이 든다.
현실적인 절충안은 작은 범위에서 도메인 자산을 먼저 검증하는 것이다. 플랫폼 내부 데이터 중 일부를 AI에 연결했을 때 범용 AI 대비 실제로 다른 결과가 나오는지를 먼저 확인한다. 차이가 드러나면 그 자산을 중심으로 기능 범위를 확장하고, 차이가 없다면 어떤 자산을 더 확보해야 하는지를 다시 정의하면 된다.
AI 기능의 성패는 모델 선택보다 이 단계에서 갈린다
좋은 모델을 쓰고, 프롬프트를 잘 설계하고, UX를 정교하게 다듬어도, 기능이 연결하는 데이터가 범용 AI와 다르지 않으면 사용자는 그 차이를 느끼지 못한다. AI 제품 기획에서 요구사항 단계가 중요한 이유는 이 때문이다. 어떤 도메인 자산을 확보하고, 어떤 성과에 연결할지를 이 단계에서 정하지 않으면, 이후 모든 개발 비용은 대체 가능한 기능을 만드는 데 쓰이게 된다.
기획자가 요구사항 단계에서 던져야 할 핵심 질문은 결국 하나다. 이 AI 기능이 우리 플랫폼에만 있는 무언가를 쓰지 않으면 만들 수 없는 것인가. 그렇다면 그 무언가가 지금 확보되어 있는가. 이 두 질문에 명확히 답하는 것에서 차별성 있는 AI 제품 기획이 시작된다.
