AI 에이전트가 처리할 수 없는 부분은 아직 구축하지 않은 비즈니스입니다

IKEA의 챗봇은 일자리를 창출했습니다.

더 많은 일을 수행함으로써가 아니라, 그것이 할 수 없는 일이 무엇인지 밝혀냄으로써 말입니다.

IKEA의 고객 서비스 에이전트인 Billie는 2021년부터 인간의 개입 없이 유입되는 요청의 47%를 해결해 왔습니다. 320만 건의 상호작용, 1,300만 유로(€13M)의 비용 절감, 그리고 이제 유럽의 모든 비즈니스 트랜스포메이션(Business Transformation) 발표 자료에는 이에 관한 슬라이드가 포함되어 있습니다. 이 47%라는 수치는 너무나 많은 피치 덱(Pitch Deck)에 복사되어 붙여넣어져서, 기본적으로 AI 비즈니스 사례의 "내 컴퓨터에서는 잘 돌아가요(it works on my machine)"와 같은 존재가 되었습니다. 모두가 이를 인용하지만, 그 밑에서 실제로 무엇이 돌아가고 있는지는 아무도 확인하지 않습니다.

하지만 아무도 다른 쪽 열(column)은 다루지 않았습니다.

**Billie가 처리할 수 없었던 53%**는 재교육(Reskilling) 프로그램으로 이어졌습니다. 8,500명의 콜센터 직원들이 원격 인테리어 디자인 어드바이저로 재교육되었습니다. 이 채널은 2022 회계연도(FY22)에 13억 유로(€1.3B)의 매출을 창출했습니다. 이 수치가 무엇을 의미하는지 정확히 말하자면, 이 수치는 Ingka의 전체 원격 판매 운영을 포괄하며, 그 매출의 일부는 재교육 프로그램이 시작되기 전부터 존재했습니다. 인과관계가 완벽하게 깔끔하지는 않습니다. 하지만 규모의 단위(Order of magnitude)는 유지되며, 전략적 통찰력은 인과관계가 완벽할 필요가 없습니다. 이것은 인사(HR) 이야기가 아닙니다. 이것은 모두가 거꾸로 읽어버린 **제품 신호(Product Signal)**입니다.

아무도 보고하지 않은 비율

비즈니스 언론은 IKEA 사례를 다루며 즉시 이를 인력 전환 이야기로 프레임화했습니다. "AI는 일자리를 파괴하는 것이 아니라 창출한다." 멋진 헤드라인입니다. 심지어 사실이기도 합니다. 하지만 이는 경영진(C-suite)이 AI 예산과 인력 외관(Optics)에 대해 동시에 안도감을 느끼도록 설계된 안심시키는 서사 아래 실제 통찰력을 묻어버렸습니다.

IKEA는 더 나은 챗봇을 만듦으로써 13억 유로를 찾아낸 것이 아닙니다. 그들은 챗봇이 할 수 없는 것이 무엇인지 질문하고, 그 답변을 비즈니스 기회로 취급함으로써 그것을 찾아냈습니다. 53%는 실패 지표가 아니었습니다. 그것은 아무도 읽을 생각을 하지 못했던 수요 지도(Demand Map)였습니다.

Billie가 대화를 넘길 때마다, 그것은 제품이 아직 충족할 수 없는 고객의 니즈를 나타내고 있었습니다. 고객 상호작용의 53%는 로그 파일에 잠자고 있는 미충족 수요(Unsatisfied demand)였습니다. 미충족 수요는 우회해야 할 문제가 아니라, 가격표가 붙은 제품의 격차(Product gap)입니다. 그리고 나머지 47%를 최적화하는 데 더 많은 시간을 할애할수록, 대시보드는 시스템이 잘 작동하고 있는 것처럼 보여주기 때문에 53%는 점점 더 보이지 않게 됩니다.

당신은 잘못된 대시보드를 보고 있습니다

제가 아는 모든 AI 에이전트 팀은 **방어율 (Deflection rate)**을 모니터링합니다. 이는 매우 명백한 지표입니다. 에이전트가 에스컬레이션(Escalation) 없이 얼마나 많은 요청을 해결하는지를 나타냅니다. 높을수록 좋습니다. 이를 최적화하고, 보고하고, 월간 검토 자료에 넣습니다. 곡선이 상승하면 모두가 이번 분기에 만족감을 느낍니다.

문제는 방어율이 쓸모없다는 것이 아닙니다. 에이전트가 중단한 대화에서 사용자가 실제로 무엇을 원했는지에 대해 구조적으로 눈이 멀어 있다는 점입니다. 이 지표는 무엇이 성공했는지를 측정합니다. 무엇이 실패했는지에 대한 형태에 대해서는 아무것도 알려주지 않습니다.

Google Analytics를 생각해 보세요. 페이지 뷰(Page views)는 무엇이 잘 작동하는지 알려줍니다. **이탈 페이지 (Exit pages)**는 제품의 어디가 고장 났는지를 알려줍니다. 다음에 무엇을 만들지 결정하는 데 있어서는 이탈 페이지가 거의 항상 더 가치 있습니다. (한번은 GA4에서 이런 일을 겪었습니다. 사람들이 가장 오래 머무는 페이지를 기반으로 6개월 동안 기능을 개발했는데, 알고 보니 고객들이 관심이 있어서가 아니라 혼란스러워서 가격 페이지에 오래 머물렀던 것이었습니다. 전형적인 사이드 퀘스트(Side quest)였죠. 저는 완전히 잘못된 몹(Mob)을 사냥하고 있었습니다. 뼈아픈 경험이었습니다.) 결제 페이지의 이탈률이 38%라고 해서, 결제를 완료한 62%를 축하하며 문제를 해결할 수는 없습니다. 사람들이 어디에서 떠났는지를 보고 그 이유를 물어야 합니다.

에이전트 로그도 마찬가지로 작동합니다. 당신은 47%를 최적화하고 있습니다. 53%를 읽고 있는 것이 아닙니다.

시작해야 할 이유가 하나 더 있습니다. 만약 당신의 에이전트가 CLI 네이티브 (CLI-native) 아키텍처에서 실행된다면, 해당 로그들은 구조화된 형태로 출력됩니다. 대화형 텍스트의 덩어리가 아니라, 데이터를 정제하는 데 오후 시간을 허비할 필요 없이 감사 프롬프트 (audit prompt)로 바로 파이프라이닝 (piping) 할 수 있는 실제 기계 판독 가능 (machine-readable) 출력물입니다. 저는 왜 CLI 네이티브 에이전트가 더 활용 가능한 로그를 생성하는가에 대한 전체 논거를 작성해 두었으니, 지저분한 로그를 대상으로 감사를 시도했다가 클러스터링 (clustering) 결과가 왜 쓸모없는지 의문을 갖기 전에 읽어볼 가치가 있습니다.

당신의 실패 로그는 수요 지도입니다

에이전트가 거부하는 모든 것이 기회인 것은 아닙니다. 이 점을 먼저 명확히 해야 합니다. 의도적인 차단, 제3자 인증 장벽, 파괴적인 작업, 정책상 범위 외의 사항들: 이것들은 정상적으로 작동하고 있는 것입니다. 이것들은 제품의 공백이 아닙니다. 필터링 기준은 간단합니다. 빈도(frequency)와 재구성(reformulation)이 결합되면 실제 신호(signal)가 됩니다. 단 한 번의 발생은 아마도 노이즈 (noise)일 것입니다.

에이전트가 포기하는 지점에서 읽어볼 가치가 있는 4가지 신호를 가장 강력한 것부터 가장 미묘한 것 순으로 소개합니다.

신호 1: 반복되는 거부된 질문들. 30일의 기간 동안 서로 다른 사용자들이 동일한 유형의 질문으로 같은 장벽에 부딪힌다면, 그 장벽은 표본 크기가 포함된 기능 요청 (feature request)입니다. 당신은 혼란스러워하는 사용자 한 명을 보고 있는 것이 아닙니다. 당신이 아직 충족시키지 못한 수요를 보고 있는 것입니다.

신호 2: 세션 내 반복되는 재구성. 유용한 응답을 얻지 못한 채 동일한 요청을 3~4번씩 다시 표현하는 사용자는 제품이 어떻게 작동하는지 몰라서 혼란스러워하는 것이 아닙니다. 그들은 필요가 실재하고 다른 곳에서는 그 기능을 찾을 수 없기 때문에 끈질기게 시도하는 것입니다. 루프 횟수 (Loop count)는 그들이 그것을 얼마나 원하는지를 나타내는 척도입니다.

신호 3: 체계적인 폴백 (fallback) 패턴. 개별 요청이 아니라, 어떤 카테고리의 요청이 지속적으로 폴백에 걸리는지 살펴보세요. "사용자들은 두 가지 옵션을 직접 비교하고 싶어 한다." "사용자들은 예약된 후속 조치를 원한다." 이것들은 무작위적인 실패가 아닙니다. 이것들은 당신이 구축한 것과 대비하여 사용자들이 실제로 원하는 것이 무엇인지 보여주는 윤곽선입니다.

시그널 4: 높은 노력의 재시도 (High-effort retries). 사용자가 단일 세션 내에서 매번 구체성을 높여가며 동일한 요청을 5번 반복한다면, 그것은 혼란에 빠진 사용자가 아닙니다. 그것은 다른 어디에서도 자신이 필요한 것을 찾을 수 없는 사람입니다. 재시도 횟수는 지불 의사 (willingness to pay)의 대리 지표입니다. 노력이 높을수록, 현재 제품 내에서는 해결되지 않는 프리미엄 티어 (premium-tier) 수준의 니즈를 마주하고 있을 가능성이 높습니다.

한 가지 주의할 점은 다음과 같습니다: 시그널 자체는 실제입니다. 하지만 그 시그널에 대한 당신의 해석은 틀릴 수 있습니다. 감사를 수행하되, 최소한의 비공식적인 검증 없이 출력 결과만 보고 바로 제품을 구축하지는 마세요. 사용자 2명과의 30분간의 통화가 높은 신뢰도를 가진 AI 클러스터링 (AI clustering)보다 언제나 더 낫습니다.

실패 로그(failure log)는 사용자들이 실제로 작성한 유일한 제품 사양(product spec)입니다.

3.5 GB의 로그가 나에게 알려준 것

나는 Claude Code 트랜스크립트(transcripts) 3.5 GB를 대상으로 감사를 실시했습니다: 2,801개의 파일, 30일간, 101개의 프로젝트.

가장 수치화하기 쉬운 패턴은 대시보드가 나에게 말해주던 것과 정확히 일치했습니다: 서드파티 (third-party) 패널에서의 112건의 인증 폴백 (auth fallbacks). 눈에 보이고, 예상 가능하며, 완전히 실행 불가능한(unactionable) 문제였습니다. 왜냐하면 해결책이 나의 사용 사례(use case)에 신경 쓸 이유가 없는 벤더(vendors)들에게 달려 있기 때문입니다. 나는 이미 몇 달 전부터 그 사실을 알고 있었습니다.

그것이 나의 47%였습니다.

다른 열에 숨겨져 있던 것은 다음과 같았습니다. 재구성 루프(reformulation loop)가 약 20회 정도 발생했는데, 이는 해당 세션의 내부를 들여다보기 전까지는 노이즈처럼 들릴 수 있습니다. 하지만 세션당 "pareil(마찬가지임)" 또는 "still broken(여전히 고장 남)"이라는 응답이 2~5회씩 반복된다는 점을 깨닫고 나면 이야기가 달라집니다. 매번 동일한 시퀀스가 반복되었습니다: 에이전트가 UI 기능을 전달하고 완료되었다고 선언하면, 제가 모바일에서 수동으로 테스트했을 때 무언가 고장 나 있었고, 에이전트는 다음 턴에 약간 다른 각도에서 다시 시작했지만, "완료(done)"라는 말이 세션 중에 접근 가능한 샌드박스(sandbox)뿐만 아니라 모든 환경에서 작동해야 함을 여전히 인지하지 못했습니다. 4번째 루프에 도달했을 때, 저는 기술적으로 이미 두 번이나 "해결(resolved)"했다고 간주된 문제에 대해 계획에 없던 시간을 허비하고 있었습니다. 4번째 루프쯤 되니, 마치 누군가 화톳불(bonfire)을 패치로 없애버린 Dark Souls 게임을 플레이하며, 똑같은 보스에게 똑같은 회피 패턴을 시도하고 있는 기분이었습니다. (적어도 Dark Souls는 "YOU DIED"라고 알려주기라도 하니 언제 멈춰야 할지라도 알 수 있죠.)

실패 로그(failure log)는 특정한 무언가를 인코딩하고 있었습니다: 실질적인 엔드 투 엔드(end-to-end) 증거 없이 턴을 종료하는 것을 거부하는 차단 훅(blocking hook)이 필요했습니다. 선언이 아닌 테스트가 필요했고, 데스크톱과 모바일 모두를 아우르는 검증이 필요했습니다. 구축하는 데 하루면 충분할 작업이었지만, 이는 아무도 읽지 않는 20줄의 로그 속에 숨겨져 있었습니다.

그다음은 질적으로 다른 7개의 사례였습니다: AI 냄새가 나는 콘텐츠, 즉 라이프스타일 사이트에 올라오자마자 사람이 쓰지 않았음을 즉각적으로 알 수 있는 전형적인 태그라인(taglines)이나 페르소나에서 벗어난 카피(copy) 같은 것들이었습니다. (저는 그런 일이 발생할 때 항상 알아챌 수 있습니다. 모델이 처음으로 수용 가능한 문구를 찾고 거기서 멈춰버린 것 같은 특유의 평면적인 느낌이 있거든요.) 이것은 외부 사용자의 요구가 아니었습니다. 그것은 내부적인 스펙 격차(spec gap)였습니다: 사이트별로 명시적인 안티 패턴(anti-patterns)과 페르소나 제약 조건(persona constraints)을 갖춘 콘텐츠 품질 게이트(content quality gate)가 없었던 것입니다. 실패 로그는 사용자의 기능 요청을 드러낸 것이 아니었습니다. 제가 한 번도 공식화하지 않았던 '부재(absence)'를 드러낸 것이었습니다. 루프 패턴과는 메커니즘이 다르지만, 근원은 동일했습니다.

대시보드에는 112건의 인증 폴백 (auth fallbacks)이 집계되고 있었습니다. 실제 비용은 루프 (loops)와 7건의 톤이 맞지 않는 전달 (off-tone deliveries)에서 발생했습니다. 만약 2,800개의 파일 중 7개가 너무 적어 신경 쓸 가치가 없다고 느껴진다면: 각각의 사례는 저에게 완전한 수동 재작성 (manual rewrite) 세션 비용을 발생시켰습니다.

로그에 대해 53% 감사 (Audit) 실행하기

3개의 프롬프트 (prompts)가 있습니다. 에이전트 로그와 함께 Claude에 복사하여 붙여넣으세요. 순서대로 실행하거나, 시간이 부족하다면 프롬프트 1번부터 시작하세요.

프롬프트 1: 거절된 요청 클러스터링 및 재구성 루프 탐지 (신호 1+2)

이 에이전트 로그를 분석하여 다음을 수행하세요:

1. 에이전트가 거절했거나, 처리할 수 없었거나, 폴백 (fallback)으로 넘긴 모든 요청을 추출하세요.
...

프롬프트 2: 재구성 루프 격리 (신호 2 심층 분석)

이 에이전트 로그에서, 사용자가 성공적인 응답 없이 동일한 요청을 2회 이상 재구성 (reformulated)한 모든 세션을 찾으세요.

...

프롬프트 3: 빈도 x 노력에 따른 점수 산정 (신호 3+4)

이 에이전트 로그를 바탕으로 각 실패 패턴의 점수를 매기세요:
빈도 (Frequency) x 사용자 노력 (User effort) = 우선순위 점수 (Priority score)

...

프롬프트 2는 더 넓은 관점에서 읽어볼 가치가 있는 내용을 구체적으로 드러냅니다. 반복되는 세션 루프 (session loops)는 단순히 "에이전트가 반복적으로 실패했다"는 의미를 넘어, 당신의 에이전트가 무엇이 되도록 요구받고 있는지를 나타내는 신호입니다. 저는 반복되는 세션 루프가 당신의 에이전트에 대해 무엇을 시사하는지를 자세히 풀어냈으며, 이 프레임워크는 여기서도 직접적으로 적용됩니다.

동일한 로그, 두 번의 읽기

IKEA는 더 나은 챗봇을 만든 것이 아닙니다. 그들은 이탈 대기열 (abandonment queue)을 읽고, 그것이 아직 구축하지 못한 비즈니스에 대해 무엇을 말해주고 있는지 질문했습니다.

당신에게도 동일한 로그가 있습니다. 당신은 아마도 그것을 읽고 있지 않을 것입니다 (제가 틀렸을 수도 있고, 아마 당신의 팀은 이미 매 스프린트마다 이 감사를 실행하고 있으며 실패 대기열이 비어 있고, 사용자가 어디에서도 찾을 수 없는 바로 그것을 구축하고 있을지도 모릅니다). 다양한 제품과 파이프라인에서 에이전트를 운영해 온 3년 동안, 저는 그런 설정을 본 적이 없습니다. 제가 보는 것은 대시보드상의 방어율 (deflection rate)과 아무도 열어보지 않는 로그 폴더뿐입니다.

로그를 Prompt 1에 붙여넣으세요. 잠재적 가치 (potential value) 열을 읽어보세요. 드러나는 내용이 당신이 몇 달 동안 알고 있었지만 아직 구축하지 않은 것인지 확인하십시오.

만약 대답이 '예'라면, 그것이 바로 눈앞에 숨겨져 있는 13억 유로의 기회입니다.

출처

• Ingka Group. AI and Remote Selling bring IKEA design expertise to the many. Ingka Newsroom, 2023.
• Clancy, Will. How IKEA turned a €13 million chatbot into a €1.3 billion activity. CIO.com, 2026년 6월.
• Robertson, Scott. How IKEA Turned 8,500 Call Centre Workers Into Interior Design Advisors Using AI. Substack, 2026년 4월.

이 포스트에는 제휴 링크가 포함되어 있을 수 있습니다. 링크를 클릭하시면 저에게 소정의 수수료가 지급될 수 있습니다 (귀하에게는 비용이 발생하지 않으며, 제가 매일 여러분의 즐거운 독서를 위해 양질의 기사를 계속 발행하는 데 도움이 됩니다).