
거대 테크 기업에 도태되지 않기 위한 AI 전략──승부를 가르는 「데이터 플라이휠 (Data Flywheel)」
요약
거대 테크 기업의 AI 기능 통합 위협 속에서 스타트업이 생존하기 위한 '데이터 플라이휠' 전략을 제시합니다. 단순 AI 호출을 넘어 사용 과정에서 발생하는 데이터를 축적하고 서비스 개선으로 연결하는 선순환 구조의 중요성을 강조합니다.
핵심 포인트
- 단순 AI API 호출 서비스는 거대 테크 기업의 표준 기능 탑재 시 도태될 위험이 높음
- 데이터 플라이휠: 사용 데이터가 축적되어 서비스가 스스로 개선되는 선순환 구조 구축
- 단순 결과 생성을 넘어 업무 전체 프로세스와 그 결과 데이터를 확보하는 것이 핵심
- 데이터의 양보다 데이터를 고객 가치로 변환하는 구조적 설계가 중요함
「이 기능, 다음 ChatGPT에 표준 탑재되면 끝 아닌가?」
AI 서비스를 만드는 사람이라면, 한 번쯤은 이런 불안을 느껴본 적이 있을 것입니다.
문장 생성, 요약, 검색, 이미지 인식, 음성 입력.
어제까지 스타트업의 독자적인 기능이었던 것이, 어느 날 갑자기 OpenAI나 Google의 신기능으로 발표된다. 게다가 더 높은 정밀도로, 더 저렴하게, 이미 많은 사용자가 사용하고 있는 서비스 안에 통합되어 있다.
정면으로 싸운다면 승산이 낮다.
그렇다면, AI 서비스를 만드는 기업은 거대 테크 기업에 삼켜지기를 기다릴 수밖에 없는 걸까요?
그렇지 않습니다.
다만, AI를 호출하여 결과만을 표시하는 서비스는 위험합니다.
살아남기 위해 필요한 것은 거대 테크 기업보다 똑똑한 AI를 만드는 것이 아닙니다.
사용될 때마다, 자사만의 학습이 쌓이는 구조를 만드는 것.
그 구조가 바로 데이터 플라이휠 (Data Flywheel)입니다.
예를 들어, 문의 내용을 입력하면 AI가 답변 초안을 작성해 주는 서비스가 있다고 가정해 봅시다.
문의를 입력한다
↓
AI가 답변을 생성한다
...
확실히 편리합니다.
하지만 이것만이라면 ChatGPT로도 가능합니다. 경쟁 기업도 같은 모델을 사용한다면 유사한 기능을 단기간에 만들 수 있습니다.
AI 모델의 성능이 올라가면 자사 서비스도 똑똑해집니다.
하지만 경쟁사도 똑같이 똑똑해집니다.
즉, 모델의 진화에 의해 일시적으로 가치는 올라가더라도 경쟁상의 차이는 벌어지지 않습니다.
오히려 모델 제공 기업이 그 기능을 표준 탑재하는 순간, 자사 서비스를 사용할 이유가 사라져 버립니다.
문제는 AI를 사용하고 있다는 것이 아닙니다.
사용되어도 자사에 아무것도 남지 않는다는 것입니다.
여기서 관점을 바꾸어 보겠습니다.
고객 지원(Customer Support) 담당자는 정말로 「AI가 작성한 답변 문장」을 원하는 것일까요?
아닙니다.
정말로 원하는 것은 문의가 빠르고 정확하게 해결되는 것입니다.
문의를 접수한다
↓
내용을 이해한다
...
답변 문장의 생성은 이 흐름의 일부분에 불과합니다.
그럼에도 불구하고 많은 AI 서비스는 「답변을 생성한 시점」에서 업무를 끝냅니다.
그 후 담당자가 어느 부분을 수정했는지.
고객에게 무엇을 보냈는지.
문제가 해결되었는지.
다시 문의가 왔는지.
그때까지 추적하지 않으면 AI의 답변이 정말로 도움이 되었는지는 알 수 없습니다.
여기에 거대 테크 기업과 싸우지 않고 살아남을 길이 있습니다.
AI 기능이 아니라, 업무 전체와 그 결과까지 프로덕트(Product)에 담아내는 것입니다.
데이터 플라이휠 (Data Flywheel)이란, 프로덕트가 사용될수록 데이터가 축적되고, 그 데이터에 의해 프로덕트가 개선되며, 다시 이용이 늘어나는 순환을 말합니다.
이용된다
↓
데이터가 생성된다
...
이름은 어려워 보이지만 생각하는 방식은 단순합니다.
사용될 때마다 그 서비스가 조금씩 똑똑해진다.
다만 데이터를 저장하는 것만으로는 의미가 없습니다.
액세스 로그(Access Log)를 대량으로 가지고 있어도 아무도 분석하지 않고 서비스에도 반영되지 않는다면, 그것은 창고에 쌓인 골판지 상자와 같습니다.
필요한 것은 다음의 순환입니다.
데이터
→ 발견
→ 개선
...
데이터 양이 아니라, 데이터를 고객 가치로 변환하는 구조가 중요합니다.
문의 대응 AI를 답변 생성에서 끝내지 않는다고 가정해 봅시다.
문의를 접수한다
↓
내용을 자동 분류한다
...
여기까지 업무에 들어오면 서비스에는 다음과 같은 데이터가 남습니다.
- 어떤 문의가 왔는가
- AI가 어떤 자료를 참조했는가
- 어떤 답변을 생성했는가
- 담당자가 어느 부분을 고쳐 썼는가
- 최종적으로 무엇을 전송했는가
- 문제가 해결되었는가
- 재문의가 발생했는가
- 대응에 몇 분이 걸렸는가
이 데이터는 다음 개선에 사용할 수 있습니다.
예를 들어, 담당자가 매번 같은 표현을 고쳐 쓰고 있다면 프롬프트 (Prompt)를 수정할 수 있습니다.
어떤 매뉴얼을 참조한 답변만 재문의가 많다면 매뉴얼 자체에 문제가 있다는 것을 알 수 있습니다.
특정 문의에서 해결률이 낮다면 인간에게 인계하는 조건을 바꿀 수 있습니다.
이용될수록 답변 정밀도뿐만 아니라 검색, 분류, 매뉴얼, 화면, 업무 흐름(Workflow)까지 개선되어 갑니다.
이것이 데이터 플라이휠 (Data Flywheel)입니다.
AI 서비스에서는 입력과 출력만을 저장하기 쉽습니다.
{
"input": "비밀번호를 변경할 수 없습니다",
"output": "설정 화면에서 변경해 주세요"
...
하지만 이 기록만으로는 답변이 좋았는지 알 수 없습니다.
고객이 설정 화면을 찾지 못했을 수도 있습니다.
계약 플랜에 따라 조작 방법이 달랐을 수도 있습니다.
답변 후에, 동일한 고객으로부터 다시 문의가 왔을 수도 있습니다.
필요한 것은, 그 다음입니다.
"generatedAnswer": "AI가 생성한 답변",
"finalAnswer": "담당자가 수정한 답변",
...
데이터의 가치는, 아래로 내려갈수록 높아집니다.
생성했다
↓
채택되었다
...
AI가 무엇을 생성했느냐보다, 그 생성물로 인해 무엇이 일어났는가가 더 중요합니다.
거대 테크 기업은 일반적인 질문에 답하는 능력에서는 압도적입니다.
하지만, 당신의 고객 문제가 실제로 해결되었는지까지는 통상적으로 알 수 없습니다.
이 결과 데이터야말로, 업무에 스며든 AI 서비스의 자산이 됩니다.
매뉴얼, FAQ, 제품 페이지, 법률, 논문.
AI에 읽히는 정보는 중요합니다.
하지만 공개되어 있는 정보라면, 경쟁사도 같은 것을 취득할 수 있습니다.
공개 정보를 대량으로 모으는 것만으로는, 장기적인 차별화가 되기 어렵습니다.
반면, 다음 데이터는 외부에서 모을 수 없습니다.
- 담당자가 AI의 답변을 어떻게 수정했는가
- 어떤 답변이 승인되었는가
- 어떤 답변으로 문제가 해결되었는가
- 어떤 답변 후에 재문의가 발생했는가
- 어떤 문의가 해지로 이어졌는가
경쟁력이 되는 것은, 공개 정보 그 자체가 아닙니다.
공개 정보와 인간의 판단, 그리고 최종적인 결과가 결합된 데이터입니다.
데이터 플라이휠 (Data Flywheel)은 문의 대응만의 이야기가 아닙니다.
송장을 읽는 것뿐이라면, 범용 AI로도 할 수 있습니다.
하지만 AI가 계정 과목을 제안하고, 경리 담당자가 수정하며, 승인 결과까지 기록한다면, 기업 고유의 회계 규칙이 축적됩니다.
송장을 읽는다
↓
계정 과목을 제안한다
...
제품 이미지에서 상처를 찾는 것뿐이라면, 이미지 인식 모델의 성능 싸움이 됩니다.
하지만 검사원의 최종 판단, 제조 설비, 재료, 온도, 불량 원인까지 연결하면, 어떤 조건에서 불량이 발생하기 쉬운지를 배울 수 있습니다.
AI가 이상을 검출한다
↓
검사원이 판정한다
...
코드를 생성하는 것뿐이라면, 범용적인 코딩 AI와의 차이는 작아집니다.
하지만 수정 차분 (diff), 리뷰 코멘트, 테스트 결과, 운영 장애까지 취득하면, 그 회사에 최적화된 개발 지원으로 진화합니다.
AI가 코드를 생성한다
↓
개발자가 수정한다
...
공통점은, AI의 출력에서 끝나는 것이 아니라, 인간의 판단과 실행 결과까지 취득하고 있다는 것입니다.
데이터 플라이휠이라는 말을 들으면, 대규모 데이터 기반이나 모델의 재학습 (re-training)을 상상할지도 모릅니다.
하지만 처음부터 그렇게까지 만들 필요는 없습니다.
예를 들어, 다음의 순환만으로도 충분합니다.
AI가 답변안을 만든다
↓
담당자가 수정한다
...
사람이 분석해도 상관없습니다.
프롬프트 (Prompt)를 고치는 것만으로도 상관없습니다.
매뉴얼이나 UI를 개선해도 상관없습니다.
중요한 것은, 자동화의 정도가 아닙니다.
이용 데이터가 다음 개선으로 이어지고 있는가입니다.
흔한 오해가 있습니다.
"이용자가 늘어나면 데이터가 늘어나고, AI는 자연스럽게 똑똑해진다"
안타깝게도, 그렇게 단순하지 않습니다.
성공과 실패를 구별하고 있지 않으면, 학습할 수 없습니다.
담당자마다 입력 규칙이 다르면, 비교할 수 없습니다.
결과 데이터와 결합되어 있지 않으면, 무엇이 좋았는지 알 수 없습니다.
분석하여 개선하는 담당자가 없다면, 아무것도 변하지 않습니다.
데이터 플라이휠이란, 단순한 데이터 수집이 아니라 조직의 개선 활동입니다.
수집한다
↓
분석한다
...
강한 기업은 반드시 가장 많은 데이터를 가진 기업은 아닙니다.
데이터를 가장 빠르게 개선으로 바꿀 수 있는 기업입니다.
파운데이션 모델 (Foundation Model)의 진화를 멈출 수는 없습니다.
정밀도는 올라가고, 가격은 내려가며, 다룰 수 있는 데이터는 늘어납니다.
자사의 가치가 AI 모델 그 자체에 의존하고 있다면, 이는 위협입니다.
하지만 자사의 가치가 업무 흐름 (workflow)과 독자적인 데이터에 있다면, 이야기는 반대가 됩니다.
더 뛰어난 모델로 교체하는 것만으로, 자사 서비스도 똑똑해집니다.
추론 (Inference) 가격이 내려가면, 원가도 내려갑니다.
이미지나 음성에 대응하면, 새로운 업무도 자동화할 수 있습니다.
거대 테크 기업이 거액의 비용을 투입해 모델을 진화시키고, 그 성과를 자사 프로덕트의 개선에 이용할 수 있는 것입니다.
파운데이션 모델은 적이 아닙니다.
교체 가능한 엔진입니다.
자사가 보유해야 할 것은 엔진이 아니라, 다음의 설계입니다.
누구의, 어떤 문제를 해결할 것인가
어느 업무까지 담당할 것인가
어떤 데이터를 취득할 것인가
...
거대 테크 기업에 도태되기 쉬운 것은, AI 서비스 그 자체가 아닙니다.
도태되기 쉬운 것은, 이용되어도 아무것도 축적되지 않는 서비스입니다.
AI를 호출한다
↓
결과를 표시한다
...
반면, 시간이 흐를수록 강해지는 서비스는 다음과 같은 순환을 가지고 있습니다.
이용된다
↓
판단과 결과가 축적된다
...
AI 시대의 경쟁력은 어떤 모델을 사용하고 있는가만으로 결정되지 않습니다.
고객의 업무에 어디까지 깊숙이 관여하고, 어떤 결과 데이터를 취득하며, 그것을 얼마나 빠르게 개선으로 전환할 수 있는가.
그것을 결정하는 것이 데이터 플라이휠 (Data Flywheel)입니다.
모델은 머지않아 진부해집니다.
기능 또한 금방 모방됩니다.
하지만 고객의 업무 속에서 쌓아 올린 판단과 결과, 그리고 개선을 지속하는 메커니즘은 쉽게 복제할 수 없습니다.
거대 테크 기업에 도태되지 않기 위해 필요한 것은, 그들보다 더 큰 AI를 만드는 것이 아닙니다.
그들에게는 보이지 않는 현장의 데이터를, 누구보다 빠르게 가치로 바꾸는 것입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기