AI 앱의 해자는 고객 결과를 닫는 폐쇄회로다

공유
AI 앱의 해자는 고객 결과를 닫는 폐쇄회로다

AI가 제품의 핵심 기능을 거의 공짜로 만들어준다면 그 회사에는 무엇이 남을까.

이 질문은 “앱 레이어가 죽는다”는 선언으로 자주 이어진다. 요약, 분류, 생성, 검색, 상담 같은 기능은 범용 모델에 흡수되고, 모델을 얇게 감싼 앱은 가격을 지키기 어려워진다는 주장이다. 절반은 맞다. 기능을 만드는 비용은 빠르게 내려간다.

그러나 기능이 싸지는 것과 고객의 문제가 해결되는 것은 같은 일이 아니다. AI 앱의 해자는 기능이 아니라 고객 결과를 관찰하고, 개입하고, 측정해 다시 개선하는 폐쇄회로다.

고객은 토큰을 사지 않는다. 매출이 늘고, 해결률이 오르고, 처리 시간이 줄고, 오류와 비용이 내려가는 변화를 산다. 앱이 이 숫자에 가까이 갈수록 모델 교체에는 강해지고, 결과와 상관없는 기능 목록에 머물수록 범용 모델과 직접 경쟁하게 된다.

토큰은 가치가 아니라 투입량이다

기업 AI 시장은 오랫동안 사용량을 성과처럼 말했다. 몇 명이 도입했고, 몇 개의 메시지를 보냈고, 몇 백만 토큰을 처리했는지가 대시보드의 중심이었다. 실험 단계에서는 이 수치도 의미가 있었다. 사람들이 도구를 실제로 만지는지 확인해야 했기 때문이다.

구매가 갱신 단계에 들어가면 질문이 달라진다. 더 많은 토큰을 썼다는 사실이 더 많은 매출, 더 빠른 처리, 더 낮은 위험으로 이어졌는가. 연결되지 않았다면 사용량 증가는 가치가 아니라 비용 증가일 수도 있다.

노동시간도 마찬가지다. 한 팀이 두 배의 시간을 썼다고 고객이 두 배의 돈을 내지는 않는다. 투입은 원가를 설명할 수 있지만 구매 이유를 설명하지 못한다. 토큰당 가격 경쟁만 하면 모델 공급자의 원가 곡선에 사업의 운명을 맡기게 된다.

따라서 AI 앱의 첫 번째 설계 대상은 프롬프트나 모델 라우터가 아니라 고객이 중요하게 보는 결과 숫자다. 지원 제품이라면 자동응답 수가 아니라 실제 해결률과 재문의율, 영업 제품이라면 생성한 이메일 수가 아니라 유효한 기회와 매출, 의료 운영 제품이라면 문서 생성량이 아니라 오류와 대기시간이 기준이 된다.

수직형 해자는 업종 지식보다 예외 처리에 가깝다

“우리는 특정 업종을 안다”는 말만으로는 해자가 되지 않는다. 업종 용어집과 일반적인 업무 절차는 범용 모델도 빠르게 흡수한다. 쉽게 문서화되는 지식은 쉽게 복제된다.

오래 남는 것은 문서에 적히지 않은 예외다. 같은 요청이라도 고객 등급과 계약 조건에 따라 승인 경로가 달라지고, 오래된 시스템의 코드값이 현실의 의미와 어긋나며, 규정상 가능한 일과 조직이 실제로 허용하는 일 사이에 간격이 있다. 담당자는 어느 단계에서 사람이 개입해야 사고가 나지 않는지 경험으로 안다.

범용 모델은 정상 경로를 빠르게 처리한다. 수직형 앱은 정상 경로 밖에서 망가지지 않도록 상태를 읽고, 올바른 시스템을 갱신하고, 예외를 적절한 사람에게 넘기며, 그 결과를 다시 학습한다. 해자는 ‘업종 특화 모델’이라는 명사보다 지저분한 현실을 끝까지 닫는 동사에 있다.

플랫폼부터 만들면 아직 존재하지 않는 사용 패턴을 추상화한다

AI가 모든 업무에 들어갈 것이라는 전망은 플랫폼을 먼저 만들고 싶은 유혹을 준다. 공통 Agent 층, 범용 메모리, 통합 도구 인터페이스, 조직 전체의 오케스트레이션을 설계하면 미래의 모든 앱을 담을 수 있을 것처럼 보인다.

문제는 좋은 추상화가 실제 반복에서 나온다는 점이다. 어떤 데이터가 정말 공통인지, 어느 권한 경계가 자주 충돌하는지, 사용자가 무엇을 결과로 보는지는 킬러 워크플로를 운영해보기 전에는 알기 어렵다. 사용 패턴이 없는데 플랫폼을 만들면 현재의 상상을 미래의 표준으로 굳힌다.

먼저 하나의 중요한 결과를 끝까지 책임져야 한다. 그 과정에서 반복해서 등장하는 데이터, 권한, 예외, 평가 방식을 발견한 뒤 공통 층으로 올리는 편이 낫다. 플랫폼은 야심의 출발점이 아니라 성공한 폐쇄회로가 여러 번 겹친 뒤 남는 부산물이다.

그렇다면 결과를 책임진다는 말은 단순히 성과형 가격을 붙인다는 뜻일까.

아니다. 가격표를 바꾸기 전에 제품이 결과를 관찰할 수 있어야 한다. 결과를 관찰하려면 고객의 실제 시스템에 연결되어야 하고, 개입 전후를 구분해야 하며, 잘못된 최적화를 막을 반대 지표까지 가져야 한다.

폐쇄회로에는 관찰, 개입, 판정, 수정이 모두 필요하다

AI 기능은 입력을 받아 출력을 만든다. 폐쇄회로 제품은 출력 뒤에 무슨 일이 일어났는지 돌아본다. 추천한 리드가 실제로 계약했는지, 작성한 답변이 티켓을 닫았는지, 자동화한 청구가 거절률을 낮췄는지 확인한다.

이 루프는 네 단계로 나뉜다. 먼저 현실의 기준 상태를 관찰한다. 다음으로 AI가 개입한다. 그 뒤 고객이 믿는 숫자로 결과를 판정한다. 마지막으로 실패한 사례와 예외를 다음 개입에 반영한다. 한 단계라도 빠지면 앱은 결과를 책임지는 것처럼 말하면서 실제로는 산출물만 납품한다.

여기에는 불편한 조건이 있다. 고객 시스템의 CRM, 결제, 지원, ERP 같은 정본에 접근해야 한다. 모델이 좋은 문장을 만들었다는 내부 평가는 부족하다. 고객이 돈을 받았는지, 문제가 해결됐는지, 비용이 실제로 줄었는지를 읽어야 한다.

그래서 강한 AI 앱은 모델보다 통합과 운영에 더 많은 품을 들일 수 있다. 화려한 데모에서는 손해처럼 보이지만, 바로 그 연결이 범용 챗봇이 대신하기 어려운 자산이 된다.

결과 지표 하나만 좇으면 새로운 실패를 만든다

결과 중심이라는 말도 위험하게 단순화될 수 있다. 고객지원의 해결률만 높이면 Agent가 대화를 성급히 닫을 수 있다. 매출만 높이면 할인과 과잉 약속으로 환불과 이탈을 뒤로 미룰 수 있다. 처리 비용만 낮추면 어려운 고객을 사람이 떠안는다.

좋은 폐쇄회로는 대표 지표와 함께 방어 지표를 둔다. 해결률 옆에 재문의율과 고객 만족, 매출 옆에 환불과 유지율, 속도 옆에 오류와 사고를 놓는다. AI가 숫자를 개선했는지뿐 아니라 비용을 다른 곳으로 밀어냈는지 본다.

성과 귀속도 정직해야 한다. 시장 수요, 영업팀의 역량, 가격 변경이 함께 작용한 결과를 AI 앱 하나의 공으로 돌리면 폐쇄회로가 아니라 마케팅 서사가 된다. 완벽한 인과 추정이 어렵더라도 전후 비교, 통제 가능한 구간, 사람이 개입한 비율, 실패 사례를 함께 남겨야 한다.

유통도 평균이 아니라 한계수익으로 본다

제품이 결과를 숫자로 본다면 유통도 같은 방식으로 운영할 수 있다. “이 채널은 잘 된다”는 평균값은 과거의 지출을 설명한다. 다음 1원을 더 넣었을 때도 같은 고객을 같은 비용으로 얻을 수 있는지는 다른 질문이다.

작은 뉴스레터 한 번, 창업자의 직접 영업, 특정 파트너와의 공동 웨비나처럼 규모는 작지만 높은 수익을 내는 채널이 있다. 반대로 큰 채널은 초기에 잘 작동해도 경쟁과 피로가 쌓이면서 한계수익이 빠르게 떨어진다. 채널 이름이 아니라 추가 지출의 반응 곡선을 봐야 한다.

이 관점은 유통을 제품 밖의 홍보 활동에서 학습 루프로 바꾼다. 어떤 메시지에 어떤 고객이 반응했고, 그 고객이 제품 안에서 어떤 결과를 얻었는지 다시 연결한다. 획득 비용이 낮아도 결과가 나쁘면 좋은 채널이 아니고, 획득 비용이 높아도 장기 가치와 추천이 크면 계속 투자할 수 있다.

유통의 시대에는 고객의 주의가 가장 비싼 자원이다

AI는 코드를 100배 더 만들 수 있어도 고객의 평가 시간과 예산을 100배 늘리지 않는다. Rich Mironov가 지적하듯 병목은 구현의 중간에서 무엇을 만들지 정하는 앞단과, 고객이 가치를 이해하고 채택하게 만드는 뒷단으로 이동한다.

기능 공급이 폭증하면 차이는 더 많은 기능에서 나오지 않는다. 누구의 어떤 문제를 맡을지 고르고, 고객의 언어로 약속하고, 실제 환경에 배치하고, 결과를 증명하는 능력에서 나온다. 유통은 완성된 제품을 알리는 마지막 단계가 아니라 어떤 결과가 돈이 되는지 배우는 첫 단계다.

이 때문에 수직형 앱의 방어력은 데이터, 워크플로, 브랜드, 유통 가운데 하나를 고르는 문제가 아니다. 고객의 중요한 숫자를 중심으로 네 요소가 서로를 강화하게 만드는 문제다. 워크플로가 결과 데이터를 만들고, 데이터가 제품을 개선하며, 제품 성과가 브랜드와 유통을 강화하고, 유통에서 얻은 고객 언어가 다시 워크플로를 바꾼다.

앱 레이어는 죽지 않는다. 책임 없는 앱이 압축된다

범용 모델이 더 좋아질수록 많은 기능은 사라지거나 기본값이 될 것이다. 그러나 기업의 지저분한 현실, 예외가 많은 운영, 결과를 둘러싼 책임까지 모델 제공자가 모두 가져가지는 않는다.

살아남는 앱은 모델보다 똑똑하다고 주장할 필요가 없다. 더 가까운 곳에서 고객의 상태를 보고, 더 안전하게 개입하고, 더 정직하게 결과를 측정하면 된다. 모델은 바꿀 수 있지만 그 폐쇄회로는 쉽게 바뀌지 않는다.

AI 시대의 해자는 기능을 소유하는 데 있지 않다. 고객이 중요하게 보는 숫자가 움직일 때까지 문제를 놓지 않는 데 있다.


주요 출처: TLDR Founders 2026-06-01의 앱 방어력·플랫폼 선행·토큰 가치·한계 채널 큐레이션; Rich Mironov, Code Isn't Product. TLDR 항목 중 상당수는 X 스레드와 2차 요약이므로 개별 수치나 보편 법칙의 근거로 사용하지 않았습니다. 폐쇄회로의 네 단계와 방어 지표, 결과·유통 루프의 연결은 이 글의 분석입니다.