2026년 7월 3일, Box는 자사의 내부 IT 지원 사례 분석을 발표했습니다. 여기서 흥미로운 점은 단순히 "답변 생성" 버튼이 아니라, 티켓(ticket)이 종료된 후에 일어나는 과정입니다. Box의 설명에 따르면, 이 시스템은 사이클을 폐쇄(close)합니다. 직원의 요청이 해결책으로 변환되고, 해결책이 검증되며, 검증된 해결책은 지식 베이스(knowledge base)로 다시 돌아가 다음번에 유사한 질문이 들어왔을 때 사람의 개입 없이 더 빠르게 해결될 수 있도록 합니다.

이는 대부분의 "지원 어시스턴트" 데모와는 근본적으로 다른 강조점입니다. 일반적인 어시스턴트는 지식 베이스를 읽고 답변합니다. 하지만 폐쇄 루프(closed loop) 시스템은 지식 베이스에 다시 기록하는 작업까지 수행합니다. 만약 당신이 일주일 동안 세 명의 직원이 VPN에 대해 똑같은 질문을 하는데, Confluence에는 여전히 2년 전 지침이 그대로 남아 있는 상황을 겪어본 적이 있다면, 왜 단순한 읽기 기능이 아닌 역방향 기록(write-back) 기능이 필요한지 이해할 것입니다. 동일한 티켓을 여러 LLM(대규모 언어 모델)에 통과시켜 문구(formulation)를 비교해 보려면, VPN과 해외 카드 없이 여러 모델에 즉시 접근할 수 있는 수단이 있을 때 이러한 루프를 정직한 단계로 나누어 분석하기가 더 쉽습니다.

다음은 Box가 설명한 구체적인 내용, 러시아 기술 스택에서 재현 가능한 부분, 그리고 벤더가 직접 언급한 주의 사항들에 대한 분석입니다.

Box는 정확히 무엇을 했는가?

2026년 7월 3일자 Box의 발표에 따르면, 이 회사는 내부 AI-powered IT support를 위한 closed-loop knowledge system(폐쇄 루프 지식 시스템)을 구축했습니다. 핵심 키워드는 closed-loop, 즉 폐쇄형입니다. Box는 단일 기능을 설명하는 것이 아니라 전체 순환 과정을 설명합니다. 직원이 티켓을 생성하면 시스템이 기존 지식을 바탕으로 해결책을 제안하고, 인시던트(incident)가 해결되면 그 결과가 지식 베이스를 최신 상태로 유지하는 데 사용됩니다.

중요한 것은 사실과 원하는 것을 분리하는 것입니다. Box는 1차 출처이자 이해관계자입니다. 시간 절약이나 사람이 개입하지 않고 해결되는 문의 비율(deflection)에 관한 모든 내용은 자체 시스템에 대한 공급업체의 주장일 뿐입니다. 이 사례의 소스 패키지에는 외부 독립적인 수치가 하나도 없으며, Box의 백분율을 자체 기준선(baseline) 없이 자사 회사에 적용하는 것은 부적절합니다. 이것은 트집 잡기가 아니라, Box 자료에서 직접 인용한 내용입니다: 결과는 그들의 데이터, 서비스 카탈로그, 그리고 그들의 직원들을 기반으로 얻어졌습니다.

분석의 근거가 된 두 번째 Box 자료는 고객 서비스 분야의 '10,000개 질문 문제' 사례입니다. 이는 다른 도메인(내부 IT가 아닌 고객 지원)에 관한 것이지만 논리는 같습니다: 유사한 질문이 너무 많을 때는 인력을 늘리는 것보다 폐쇄된 문의를 통해 학습하는 시스템을 구축하는 것이 더 유리합니다. 이 자료에서 제가 가져오는 것은 오직 명시적으로 언급된 내용, 즉 문제의 공식화로서 10,000개 질문이라는 규모 자체입니다.

이제 메커니즘 수준으로 내려가 보겠습니다. '폐쇄 루프(closed loop)'를 구성하는 것이 무엇이며, 이것이 지식 베이스에 채팅을 연결하는 것보다 왜 더 복잡한지 알아봅시다.

Диагностический маршрут из пяти шагов замкнутого контура знаний Box, где решение возвращается в базу

폐쇄 루프는 어떻게 구성되는가?

'지식 베이스 어시스턴트'와 폐쇄 루프의 차이는 화살표의 방향에 있습니다. 일반적인 방식은 단방향입니다: 지식 베이스 -> 모델 -> 답변. 폐쇄 루프는 과정의 두 번째 절반을 추가합니다: 폐쇄된 티켓 -> 검토 -> 지식 베이스 내 업데이트된 문서. 일반적으로 이 두 번째 절반이 프로덕션 단계까지 도달하지 못하는데, 그 이유는 지식 베이스에서 읽는 것보다 거기에 쓰는 것이 더 위험하기 때문입니다.

이 루프(loop)를 역할별로 나누어 보겠습니다. 첫 번째 노드는 요청 수신입니다. 직원이 문제 상황을 말로 설명하면(

여기서 코드 자체보다 더 중요한 세 가지가 있습니다. 첫째: base_url은 프로바이더(provider)에 연결하는 유일한 지점으로, 이를 변경해도 나머지 로직에는 영향을 주지 않습니다. 둘째: 데이터베이스 기록(kb.upsert)은 resolved_by_human 조건 하에 수행되며, 문서는 즉시 프로덕션(prod)으로 가는 것이 아니라 review 상태로 넘어갑니다. 셋째: 모델은 "지식 베이스의 컨텍스트(context)에 따라서만" 답변합니다. 이는 모델이 지어낸 지침을 확신을 가지고 내뱉을 확률을 낮춰줍니다.

여기서 인프라 측면의 비교를 언급하는 것이 적절한데, 러시아 팀에게 가장 큰 장벽은 보통 루프(loop)의 로직이 아니라 모델에 대한 접근 권한이기 때문입니다. provod.ai는 Claude, GPT, Gemini, DeepSeek, Qwen을 하나의 채팅창에 통합하여 제공하며, OpenAI 및 Anthropic SDK와 호환되는 단일 API를 제공합니다. 즉, 키(key)와 base_url만 바꾸면 폐쇄 루프(closed-loop)의 나머지 코드는 건드릴 필요가 없습니다. 결제는 러시아 카드를 통한 단일 루블 잔액, SBP(Faster Payments System) 또는 계좌 이체로 이루어지며, 법인의 경우 계약서, 인보이스 및 정산 서류를 제공합니다. 이는 정확히 한 가지 문제, 즉 VPN과 해외 카드 없이 모델에 접근하는 문제를 해결해 줍니다. 지식 루프(knowledge loop) 자체, 검색(retrieval), 그리고 데이터베이스 기록 규칙은 여전히 직접 구축해야 합니다.

이 루프는 어디에서 깨지는가?

폐쇄 루프는 다이어그램 상으로는 매력적이지만, 운영 측면에서는 교활합니다. 가장 빈번한 실패 사례는 검증 없는 피드백입니다. 만약 시스템이 티켓이 실제로 도움이 되었는지 여부가 아니라, 단순히 티켓이 닫혔다는 사실만으로 "해결됨"이라고 판단한다면, 시스템은 잘못된 신호를 바탕으로 지식 베이스를 학습하기 시작할 것입니다. 예를 들어, 사용자가 스스로 노트북을 재부팅해서 요청을 종료했는데, 루프는 당신의 쓸모없는 조언을 유효한 해결책으로 지식 베이스에 기록하게 됩니다.

두 번째 실패 사례는 지식 베이스 (Knowledge Base) 내의 버전 충돌입니다. 새로 검증된 해결책이 기존의 오래된 문서와 모순될 경우, 검색 (Retrieval) 과정에서 두 가지를 모두 가져오게 됩니다. 모델은 두 소스로부터 모순된 답변을 정직하게 합성해 버립니다. "오래된 문서는 교체된다"라는 명시적인 단계가 없다면, 베이스는 개선되는 것이 아니라 비대해질 뿐입니다. 그렇기 때문에 도식의 다섯 번째 노드는 "문서 추가"가 아니라, 무언가를 폐기 (Deprecate)해야 한다는 점을 고려한 "베이스 업데이트"인 것입니다.

세 번째 실패 사례는 유사한 질문의 규모로, Box는 유사한 사례에서 이를 "10,000개 질문의 문제"라고 부릅니다. 문의 흐름이 클수록 루프의 각 오류 비용은 배가됩니다. 베이스에 있는 단 하나의 잘못된 문서가 수천 개의 미래 답변으로 복제되기 때문입니다. 다행인 점은 하나의 좋은 문서가 주는 이점 또한 복제된다는 것입니다. 이것이 바로 일회성으로 답변하는 것이 아니라 사이클을 폐쇄 (Close the loop)해야 하는 이유입니다.

Визуализация масштаба: число 10 000 вопросов, от которого тиражируется польза или ошибка одной статьи базы

직접 구축해야 할까: 단계별 결정 가이드

Box의 아키텍처를 그대로 따라 하기 전에, 데이터의 성숙도에 대해 솔직하게 자문해 보십시오. 폐쇄 루프 (Closed loop)는 이미 존재하는 것을 증폭시킵니다. 만약 지식 베이스가 빈약하고 모순적이라면, 루프는 그 모순을 열정적으로 복제할 것입니다. 먼저 문서화의 기본 질서를 잡고 티켓 결과에 대한 레이블링 (Labeling)을 수행한 다음, 기록 자동화를 진행하십시오.

그다음은 규모에 따라 결정하십시오. 주당 문의가 수십 건 수준이라면 수동으로 베이스를 업데이트하는 것이 어떤 루프를 구축하는 것보다 저렴합니다. 사람이 티켓을 종료하고, 사람이 문서에 한 단락을 추가하면 됩니다. 폐쇄 루프는 유사한 질문이 실제로 매우 많고, 수동으로 베이스를 관리하는 것이 물리적으로 흐름을 따라잡을 수 없는 지점에서 비로소 가치를 발휘하기 시작합니다. Box는 바로 이 임계점을 "10,000개 질문의 문제"를 통해 보여주고 있습니다.

아래는 봇이나 사람만으로도 충분한 곳에 굳이 루프를 구축하지 않도록 도와주는 요약 표입니다.

지표(Metrics)에 대해 별도로 언급하자면, 언급된 Box의 방어율 (Deflection)과 시간 절약 수치는 Box의 자체 데이터에 기반한 수치입니다. 자신의 실제 규모를 알 수 있는 유일한 방법은 도입 전의 기준점 (Baseline)을 측정하는 것입니다. 즉, 사람의 개입 없이 얼마나 많은 티켓 (Ticket)이 처리되었는지, 그리고 처리 시간은 얼마나 걸렸는지를 측정한 후 비교해야 합니다. 이러한 측정 없이는 타인의 게시물에 나온 그 어떤 백분율도 예측치가 아닌 마케팅 용어일 뿐입니다.

Решающая таблица: когда замкнутый контур знаний оправдан, а когда хватит бота или человека

이것이 해결하지 못하는 것

폐쇄 루프 지식 시스템 (Closed-loop knowledge system)은 만능 해결책 (Silver bullet)이 아닙니다. 자신이나 경영진에게 과도한 기대를 심어주지 않도록 그 한계를 명확히 짚고 넘어가는 것이 유익합니다.

이 시스템은 자동화 플랫폼이나 ITSM 프로세스를 대체하지 않습니다. 루프는 티켓 시스템 (Ticket system) 위의 레이어 (Layer)일 뿐, 시스템 그 자체가 아닙니다. 라우팅 (Routing), SLA, 에스컬레이션 (Escalation)은 여전히 귀하의 ITSM에 남아 있습니다.

오류의 비용이 높은 곳에서 인간의 검토를 생략할 수 없습니다. 권한 관리, 보안, 그리고 되돌릴 수 없는 작업과 관련된 모든 사항은 데이터베이스에 자동으로 기록하는 것이 아니라 확인 절차를 거쳐야 합니다.

이 시스템은 Box와 같은 수치를 제공하지 않습니다. Box의 게시물에 나온 방어율 (Deflection)과 시간 절약 수치는 Box의 것입니다. 귀하의 수치는 이보다 높을 수도, 현저히 낮을 수도 있습니다. 이는 지식 베이스의 품질과 유입되는 흐름의 균일성에 달려 있습니다.

인프라에 대해 별도로 언급하자면: provod.ai와 같은 애그리게이터 (Aggregator)를 통한 모델 접근은 VPN이나 해외 카드 없이 연결 문제를 해결해 주지만, GigaChat, 프라이빗 (Private) 또는 온프레미스 (On-prem) 인프라, 특정 벤더 (Vendor)의 구독 기능 및 실제 구축 작업을 대체하지는 않습니다. provod.ai는 GigaChat를 제공하지 않습니다. 검색 (Retrieval), 데이터베이스 기록 규칙, 그리고 결과 검증은 여전히 직접 구축해야 합니다.

FAQ

지식 베이스 기반의 일반적인 봇과 폐쇄 루프 (closed loop) 시스템의 차이점은 무엇인가요?
일반적인 봇은 지식 베이스를 읽고 답변만 합니다. 반면 폐쇄 루프 (closed loop) 시스템은 검증된 해결책을 바탕으로 지식 베이스를 업데이트하여, 다음에 유사한 티켓 (ticket)이 발생했을 때 더 잘 해결될 수 있도록 합니다. 2026년 7월 3일자 Box의 설명에 따르면, 바로 이 피드백 기록 (feedback loop)이 시스템의 핵심입니다.

Box 사례의 디플렉션 (deflection) 수치를 신뢰할 수 있나요?
참고용으로만 보아야 하며, 전적으로 신뢰해서는 안 됩니다. 이는 벤더 (vendor)가 자사 시스템에 대해 발표한 수치입니다. 도입 전 자체적인 베이스라인 (baseline)을 측정하지 않으면 퍼센트 (percentage)를 그대로 옮겨오는 것은 부정확할 수 있으며, 게시물의 성격 자체가 이에 대해 직접적으로 경고하고 있습니다.

"10,000개의 질문 문제"란 무엇인가요?
Box는 고객 서비스의 인접 사례를 이렇게 명명했습니다. 즉, 유형이 동일한 질문이 매우 많을 때, 인력을 늘리는 것보다 종결된 문의 내역을 통해 시스템을 학습시키는 것이 더 저렴하다는 것입니다. 이는 규모의 경제를 설명하기 위한 예시일 뿐, 보장된 결과는 아닙니다.