AI Agents for Service Technicians: TK엘리베이터가 출동 브리핑과 작업보고를 에이전트로 바꾼 방식

현장 서비스에서 에이전트의 값은 수리를 대신하는 데 있지 않습니다. 출동 전에 필요한 정보를 한 장으로 모아 주고, 수리 뒤 기술자의 말을 구조화된 기록으로 바꿔 다음 진단에 돌려주는 데 있습니다. TK엘리베이터는 이 두 에이전트를 원격 운영센터의 설비 데이터와 한 순환으로 묶었습니다. 우리 현장에 옮기려면 설비 이력과 매뉴얼을 기종별로 정리하고, 보고에서 꼭 받아야 할 항목을 먼저 정해야 합니다.

요약

Microsoft의 고객 사례 기사(Catherine Bolgar, 2026년 10월 22일, 독일 뒤셀도르프 취재)는 TK엘리베이터(TKE)가 서비스 기술자의 하루를 어떻게 바꿨는지 보여 줍니다. TKE의 서비스 기술자는 약 2만5천 명이고, 이들이 전 세계 140만 대의 엘리베이터와 에스컬레이터를 관리합니다. 기술자가 건물에 들어가기 전, Microsoft Foundry와 Azure OpenAI로 만든 에이전트 앱이 휴대폰이나 태블릿으로 브리핑을 보냅니다. 어느 건물의 몇 층 어떤 설비인지, 정기 점검인지 고장 출동인지, 어떤 공구를 챙겨야 하는지가 담깁니다. 현장에서는 디지털 매뉴얼과 그 설비의 과거 서비스 이력을 검색합니다. 일이 끝나면 voice debriefing agent(음성 작업보고 에이전트)가 무엇을 했는지 묻고, 기술자가 말로 답하면 받아 적고, 빠진 부분은 다시 묻습니다. 손으로 쓸 일이 없습니다.

원문에 나온 규모 숫자(회사 발표). 성과 수치는 원문에 없음

이 두 에이전트 뒤에는 10년 가까이 쌓은 데이터 기반이 있습니다. TKE는 약 10년 전부터 설비에 센서와 클라우드 연결을 달았고, Azure IoT와 Azure Databricks 위에 데이터 플랫폼을 세웠습니다. 9곳의 DOC(Digital Operations Center, 디지털 운영센터)에서는 분석가와 기술 전문가가 머신러닝으로 설비마다 health score(설비 건강 점수)를 계산하고, 문이 계속 열렸다 닫히는 것 같은 반복 이상을 고장 전에 찾아 기술자에게 권고를 보냅니다. 예전에는 IoT 측정값과 기업 시스템 같은 정형 데이터만 쓸 수 있었습니다. 생성형 AI가 들어오면서 매뉴얼과 기술자의 서비스 노트 같은 비정형 자료도 쓸 수 있게 됐습니다. 디브리핑으로 모인 현장의 말은 다시 진단을 다듬는 데 쓰이고, 경력이 짧은 기술자도 동료들의 경험을 빌려 쓰게 됩니다. 기사는 시간 단축이나 재출동 감소 같은 성과 숫자를 밝히지 않습니다. 아래에서는 이 순환을 이루는 네 가지 장치를 풀고, 우리 현장에 옮길 때 필요한 설계와 일정을 덧붙입니다.

TKE의 연결 설비 데이터와 두 에이전트가 하나의 순환으로 이어지는 모습

핵심 메커니즘

Pre-visit Briefing Agent: 출동 전에 한 장으로 모아 주는 에이전트

출동 전 브리핑 에이전트는 작업 지시가 나가면 그 설비에 관한 정보를 모아 기술자 단말에 한 화면으로 보냅니다. 입력은 작업 지시(어느 건물, 어떤 유형), 설비 정보, 최근 이벤트와 에러 코드, 과거 서비스 이력, 매뉴얼입니다. 에이전트는 이를 읽고 위치(건물·층), 증상, 챙길 공구를 정리합니다. 출력은 기술자가 이동 중에 훑어볼 수 있는 브리핑과, 현장에서 이어서 물어볼 수 있는 검색 창입니다.

이 장치가 줄이는 것은 수리 시간이 아니라 준비의 마찰입니다. 기사에 나온 12년 차 기술자 Torben Teichmann은 설비를 찾고, 공구를 챙기고, 메모하는 번거로움이 줄었다고 말합니다. 기종이 섞인 설비 포트폴리오일수록 효과가 큽니다. TKE의 기술자는 제어기와 도어 머신이 서로 다른 설비를 오가며 일하고, 매뉴얼은 수백 쪽에 이릅니다. 반대로 설비가 한 기종뿐이고 작업이 단순 반복이면 브리핑의 이득은 작습니다. 가상 예시로, 공조 설비 업체라면 ‘3층 기계실 냉동기, 압축기 고압 경보 3회, 지난달 팬 벨트 교체’를 한 화면에 띄우는 것이 같은 구조입니다.

브리핑 에이전트는 흩어진 정보를 출동 전 한 화면으로 모은다

Voice Debriefing Agent: 말로 보고하면 빠진 것을 되묻는 에이전트

음성 디브리핑 에이전트는 수리가 끝난 뒤 기술자에게 작업 내용을 묻고, 말로 들은 답을 기록으로 바꿉니다. 받아쓰기와 다른 점은 되묻기입니다. 답에 빠진 내용이 있으면 에이전트가 추가 질문을 던져 기록을 채웁니다. 완성된 노트는 그 설비의 서비스 이력에 붙어 다음에 오는 동료가 읽습니다.

현장 기술자에게 작업보고는 가장 미루고 싶은 일입니다. 장갑을 낀 손, 좁은 기계실, 다음 출동 압박 속에서 글로 쓴 보고는 짧아지고 원인은 빠집니다. 말로 하면 부담이 줄고, 에이전트가 되물으면 ‘무엇을 바꿨나’뿐 아니라 ‘왜 그렇게 판단했나’까지 남습니다. Teichmann은 문서는 좋지만 지식의 상당 부분은 동료들에게 있고, 앱이 그것을 전해 줄 수 있다고 말합니다. 디브리핑은 그 지식을 기록으로 옮기는 입구입니다. 반대로 보고 항목이 정해진 체크리스트 몇 개뿐인 작업(예: 법정 점검 서명)이라면 음성 대화보다 체크 폼이 빠릅니다.

디브리핑 에이전트는 받아 적는 데서 끝나지 않고 빠진 것을 되묻는다(대화는 가상 예시)

Health Score와 DOC: 고장 전에 패턴을 찾는 원격 운영센터

health score는 연결된 설비마다 머신러닝으로 계산한 상태 점수이고, DOC는 그 점수와 이벤트를 보는 원격 조직입니다. DOC의 분석가는 설비 상태, 기록된 이벤트, 에러 코드를 추적합니다. 같은 설비의 시간에 따른 변화와 비슷한 설비끼리의 비교를 겹쳐 봅니다. 문이 반복해서 열리고 닫히는 것처럼 아직 고장은 아니지만 고장이 될 수 있는 신호를 찾으면, 해당 층을 짚어 기술자에게 권고를 보냅니다. 점수는 정비 우선순위를 정하는 데도 쓰입니다.

여기서 눈여겨볼 점은 결정권의 위치입니다. DOC는 권고를 보내고, 현장에서 설비를 살펴 무엇을 할지 정하는 사람은 기술자입니다. 독일 디지털 전환을 맡은 Tobias Lüsebrink는 베를린 DOC에서 일하며 여러 출처의 데이터를 시간과 기종에 걸쳐 비교하는 일을 설명합니다. 센서가 붙은 설비가 충분히 많고 이벤트 기록이 쌓여 있을 때 쓸 수 있는 장치입니다. 연결 설비가 몇백 대 수준이면 비슷한 설비끼리 비교하기 어려워 패턴 탐지의 힘이 떨어집니다.

DOC는 패턴을 찾아 권고하고, 현장 판단은 기술자가 한다

Structured와 Unstructured Data: 센서 값에 매뉴얼과 현장 노트를 더하기

TKE 데이터·AI 기반을 이끄는 Christian Jung은 예전에는 IoT 측정값과 기업 시스템 같은 정형 데이터만 다뤘고, 기술 문서나 서비스 노트 같은 비정형 자료는 쓸 수 없었다고 설명합니다. 생성형 AI가 이 벽을 낮췄습니다. 정형 데이터는 ‘무엇이 일어났나’(에러 코드, 이벤트 횟수, 점수)를 말하고, 비정형 자료는 ‘어떻게 고치나’(매뉴얼 절차, 비슷한 사례에서 동료가 한 일)를 말합니다. 둘을 같은 설비 ID로 잇자 기술자에게 수리 방법까지 안내할 수 있게 됐습니다.

순서도 중요합니다. TKE는 에이전트부터 만든 것이 아니라, 10년 가까이 설비를 연결하고 Azure 위에 데이터 플랫폼을 쌓았습니다. 플랫폼은 Microsoft Industry Solutions Engineering(지금의 Microsoft Frontier Company)과 함께 만들었습니다. 설비 ID가 정리돼 있지 않거나 서비스 기록이 종이와 엑셀에 흩어져 있다면, 브리핑 에이전트는 엉뚱한 기종의 매뉴얼을 꺼내게 됩니다.

같은 설비 ID로 두 자료를 이어야 수리 방법까지 안내할 수 있다

Feedback Loop: 현장의 말이 다음 진단을 고치는 순환

마지막 장치는 앞의 셋을 잇는 되먹임입니다. 디브리핑 노트는 TKE의 고장 진단에 다시 들어가 진단을 다듬고 새 패턴을 찾는 데 쓰입니다. DOC가 ‘문 반복 개폐’를 권고했는데 현장에서 원인이 센서 오염이었다면, 그 결과가 다음 같은 패턴의 권고와 다음 기술자의 브리핑을 바꿉니다. 독일에서 배운 것이 다른 지역으로 퍼질 수 있다는 점도 기사는 짚습니다.

이 순환은 숙련의 격차를 줄이는 장치이기도 합니다. Lüsebrink는 숙련 기술자의 판단은 몇 년에 걸쳐 쌓이며, AI가 전 세계 기술자 팀에서 관련 제안을 모아 줄 수 있다고 봅니다. 젊은 기술자일수록 디지털 도구를 당연하게 기대한다는 말도 덧붙입니다. Teichmann은 이 앱을 “my buddy that gives advice”라고 부르면서도, 결국 엘리베이터를 고치는 일은 사람에게 남는다고 말합니다.

디브리핑 결과가 다음 권고와 브리핑을 바꾸는 순서(가상 예시)

통념과 다른 주장

흔히 이렇게 봅니다현장 서비스에 생성형 AI를 쓰려면 매뉴얼을 넣은 검색 챗봇부터 만들면 된다.

기사는 이렇게 봅니다매뉴얼만으로는 부족합니다. 현장 지식의 상당 부분은 문서가 아니라 동료 기술자의 경험에 있고, 그 경험을 말로 받아 기록으로 남기는 디브리핑이 브리핑만큼 중요합니다.

근거12년 차 기술자 Teichmann은 문서는 좋지만 지식은 동료에게 있다고 말하고, TKE는 디브리핑 노트를 진단 개선과 신입 기술자의 경험 공유에 다시 씁니다.

지식을 꺼내 쓰는 장치와 지식을 받아 쌓는 장치를 함께 둔다

흔히 이렇게 봅니다예지 정비는 센서와 모델이 고장을 예측해 정비를 자동으로 지시하는 것이다.

기사는 이렇게 봅니다모델은 패턴을 찾고 권고할 뿐이고, 설비를 직접 보고 무엇을 할지 정하는 사람은 현장 기술자입니다. 그 판단 결과가 다시 모델을 고칩니다.

근거DOC는 health score와 반복 이상 패턴으로 해당 층을 짚어 권고를 보내고, 기술자가 점검 뒤 조치를 정하며, 그 피드백이 고장 진단을 다듬습니다.

권고와 판단을 나누고, 판단 결과를 되돌린다

저자가 든 사례

한 기술자의 출동: 브리핑에서 디브리핑까지

구분	내용
상황	12년 차 서비스 기술자 Torben Teichmann. 기종이 섞인 설비를 오가며, 설비를 찾고 공구를 챙기고 메모하는 일이 번거로웠음
한 일	출동 전 브리핑(설비·층·증상·공구)을 받고, 현장에서 매뉴얼과 서비스 이력을 검색하고, 수리 뒤 음성으로 보고
결과	준비와 기록의 번거로움이 줄었다고 말함. 시간·건수 같은 수치는 원문에서 밝히지 않음
연결	Pre-visit Briefing Agent, Voice Debriefing Agent

한 기술자의 하루에 두 에이전트가 들어간 자리

DOC의 반복 이상 탐지: 문이 계속 열렸다 닫히는 설비

구분	내용
상황	아직 고장은 아니지만 문이 반복해서 열리고 닫히는 설비. 방치하면 고장이 될 수 있는 신호
한 일	DOC가 상태·이벤트·에러 코드를 시간과 동종 설비에 걸쳐 비교해 패턴을 찾고, 해당 층을 짚어 기술자에게 권고
결과	기술자가 점검 뒤 조치를 정하고, 피드백이 진단을 다듬음. 정량 결과는 원문에서 밝히지 않음
연결	Health Score와 DOC, Feedback Loop

고장 전에 패턴을 잡아 현장 판단으로 넘긴 흐름

10년의 데이터 기반: 연결 설비에서 생성형 AI까지

구분	내용
상황	엘리베이터·에스컬레이터는 공항·병원·사무실의 핵심 인프라로, 멈추면 많은 사람이 영향을 받음(TKE 독일 CEO Christian Fongern)
한 일	약 10년 전부터 센서와 디지털 제어기로 설비를 연결, Azure·Azure IoT·Azure Databricks로 플랫폼 구축, 이후 비정형 자료를 생성형 AI로 활용
결과	정형 데이터만 쓰던 데서 수리 방법 안내까지 확장. 구축 비용·기간 세부는 원문에서 밝히지 않음
연결	Structured와 Unstructured Data

연결 → 플랫폼 → 에이전트 순서로 쌓은 기반(구간 길이는 개념 표시)

기술 디테일: 우리 현장 서비스에 이 구조를 옮기려면

아래는 기사에 나온 구조를 우리 설비 서비스 조직에 대입할 때 필요한 설계로, AX Review가 새로 작성했습니다. 필드명과 숫자는 가상 예시입니다.

출동 전 브리핑(Pre-visit Briefing Agent)을 만들려면 출력을 자유 문장이 아니라 정해진 필드로 받습니다. 기술자 화면은 필드 순서대로 그리고, 요약 문장은 맨 위 한 줄만 둡니다. 공구 목록은 모델이 지어내지 않게 작업 유형·기종별 공구 마스터에서만 고르게 하고, 매뉴얼 근거는 문서 ID와 쪽 번호로 남겨 기술자가 바로 열 수 있게 합니다. 호출은 작업 지시 1건당 1회, 출동 30분 전에 만들고 단말에 미리 내려받아 둡니다. 기계실과 승강로는 통신이 끊기는 일이 잦기 때문입니다. temperature는 0~0.2로 낮게 둡니다.

{
  "work_order_id": "WO-2026-118203",
  "unit_id": "EL-KR-04417",
  "site": { "building": "OO타워", "floor": "3", "access_note": "지하 2층 방재실에서 열쇠 수령" },
  "job_type": "callout",
  "equipment": { "controller_model": "CTRL-A7", "door_machine_model": "DM-22" },
  "symptom": { "error_codes": ["E31"], "events_7d": 46, "health_score": 58 },
  "last_visits": [{ "date": "2026-09-14", "action": "도어 레일 조정", "note_id": "N-88120" }],
  "tools": ["TL-DOOR-ALIGN", "TL-MULTIMETER"],
  "manual_refs": [{ "doc_id": "DM-22-SVC", "pages": "112-118" }],
  "summary": "3층 도어 반복 개폐, 9월에도 레일 조정 이력"
}

조회와 검색은 코드가, 정리는 모델이 맡는 브리핑 파이프라인(가상 예시)

기종이 섞인 설비에서 검색을 맞추려면 매뉴얼을 쪽 단위로 잘라 넣지 말고 기종(제어기·도어 머신 모델)과 절차 단위로 나눈 뒤 메타데이터를 붙입니다. 검색은 먼저 controller_model, door_machine_model로 걸러 내고, 그 안에서 의미 검색을 합니다. 이 필터 하나가 엉뚱한 기종의 절차를 꺼내는 사고를 가장 많이 막습니다. 과거 서비스 노트도 같은 설비 ID와 기종으로 묶어 ‘같은 기종, 같은 에러 코드에서 동료가 한 일’ 상위 3건을 브리핑에 붙입니다.

음성 디브리핑(Voice Debriefing Agent)을 만들려면 대화가 채워야 할 슬롯을 먼저 정합니다. 예를 들어 observed_symptom, root_cause, action_taken, parts_replaced, unit_status, follow_up_needed 여섯 개입니다. 음성은 STT(speech-to-text, 음성 인식)로 받아 텍스트로 바꾸고, 모델이 슬롯을 채운 뒤 비어 있는 슬롯에 대해서만 되묻습니다. 되묻기는 최대 3회로 제한하고, 마지막에 요약을 읽어 주어 기술자가 ‘맞다’고 확인하면 저장합니다. 기계실 소음에 대비해 부품 번호와 에러 코드는 숫자를 다시 불러 확인하고, 확인되지 않은 슬롯은 unconfirmed로 표시합니다. 원본 음성과 받아쓴 텍스트는 노트 ID로 묶어 보관합니다.

빈 슬롯에만 되묻고 최대 3회로 끝내는 규칙(가상 예시)

되먹임을 진단 개선에 연결하려면 디브리핑의 root_cause를 자유 문장으로만 두지 말고 원인 코드 목록(예: 센서 오염, 레일 마모, 제어 설정)에 맞춰 모델이 분류하게 합니다. 그래야 DOC의 권고 ID와 현장 결과를 짝지어 ‘이 패턴의 권고가 실제로 무엇이었나’를 셀 수 있습니다. 같은 노트를 3회 분류해 결과가 엇갈리면 사람 검토로 보냅니다. 매주 권고 대비 실제 원인의 일치율을 패턴별로 집계하고, 일치율이 낮은 패턴은 DOC 분석가가 규칙을 고칩니다.

실패하는 경우와 대응. 첫째, 설비 ID가 작업 지시와 IoT 시스템에서 다르면 브리핑이 다른 설비의 이력을 끌어옵니다. 시작 전에 ID 대응표를 만들고, 일치하지 않는 건은 브리핑을 보내지 않습니다. 둘째, 모델이 매뉴얼에 없는 절차를 만들어 낼 수 있습니다. 절차 안내에는 반드시 manual_refs를 붙이고, 근거가 없으면 ‘근거 없음’으로 표시합니다. 셋째, 디브리핑이 너무 길어지면 기술자가 건너뜁니다. 대화 길이를 2분 안팎으로 잡고, 길어지면 필수 슬롯만 받고 끝냅니다. 넷째, 보고 내용에 고객사 건물 정보와 개인 이름이 섞입니다. 저장 전에 개인정보를 가리는 단계를 둡니다.

현장 서비스 에이전트에서 먼저 막아야 할 네 가지(가상 예시)

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	6주 동안 하는 일
스폰서	서비스 사업 총괄 임원	대상 지역·설비군과 판정 기준 승인
현장 대표	숙련 기술자 2명, 신입 기술자 2명	브리핑 필드와 디브리핑 슬롯 검토, 실제 출동에서 사용
서비스 운영	배차·작업 지시 담당 1명	작업 지시와 설비 ID 정리, 출동 30분 전 전송 확인
원격 진단	원격 모니터링 분석가 1명	권고 ID 부여, 원인 코드 목록 작성, 일치율 집계
엔지니어	백엔드·모바일 개발자 각 1명	조회·검색·생성 파이프라인, 음성 앱, 오프라인 보관
지식 관리	기술 문서 담당 1명	매뉴얼을 기종·절차 단위로 나누고 메타데이터 부여
보안·법무	담당 1명	음성 녹음 동의, 고객 건물 정보와 개인정보 처리

시작 전 준비물: 대상 설비군(예: 한 도시의 300대)의 설비 마스터와 기종 정보, 최근 12개월 작업 지시와 서비스 기록, 기종별 매뉴얼 원본, 작업 유형별 공구 목록, IoT 이벤트·에러 코드 이력, 현재 출동 1건의 준비 시간과 보고 작성 시간 측정값, 기술자 노조나 직원 대표와의 녹음 사용 합의.

주차	할 일	산출물
1주	대상 설비군 선정, 설비 ID 대응표, 현재 준비·보고 시간 측정	ID 대응표, 기준선
2주	브리핑 필드와 디브리핑 슬롯 확정, 매뉴얼 기종별 분할	필드 정의서, 검색 색인
3주	디브리핑부터 4명이 실제 출동에 사용	디브리핑 노트 50건 이상
4주	브리핑 추가, 원인 코드 분류 시작	브리핑 사용 기록
5주	권고 대비 실제 원인 일치율, 기술자 인터뷰	일치율 표, 인터뷰 기록
6주	판정 회의, 확대 여부와 다음 설비군 결정	판정 보고서

디브리핑을 먼저 돌리고 브리핑을 한 주 뒤에 붙이는 6주 일정(가상 예시)

기술자 인터뷰 질문: 출동 전에 가장 오래 찾는 정보는 무엇입니까? 현장에 가서야 공구나 부품이 없다는 걸 안 적이 최근 한 달에 몇 번입니까? 같은 기종의 같은 고장을 다른 동료는 어떻게 고쳤는지 지금은 어떻게 알아냅니까? 작업보고에서 가장 자주 빠뜨리는 항목은 무엇입니까? 말로 보고할 때 주변 소음이나 고객 앞이라는 점이 문제가 됩니까?

진행 판정 기준(예시): 디브리핑 사용률이 출동의 80% 이상, 필수 슬롯이 모두 채워진 보고가 90% 이상, 기술자 4명 중 3명 이상이 계속 쓰겠다고 답하면 다음 설비군으로 넓힙니다. 브리핑의 공구 누락으로 재방문한 건이 기준선보다 늘었거나, 엉뚱한 기종의 매뉴얼을 꺼낸 건이 한 건이라도 나오면 검색 필터와 공구 마스터를 고쳐 4주차부터 다시 돌립니다.

6주차 판정 회의에서 쓰는 기준(가상 예시)

AX 적용 제언. 이 구조는 설치 기반(installed base)이 크고 기술자가 현장을 도는 모든 사업에 맞습니다. 승강기 외에 공조·냉동 설비, 산업용 로봇과 공작기계, 반도체·디스플레이 장비 서비스, 통신 기지국, 의료기기 유지보수가 대표적입니다. 순서는 디브리핑 먼저, 브리핑 다음, 원격 진단 연결 마지막을 권합니다. 디브리핑은 연결 센서가 없어도 오늘 시작할 수 있고, 몇 달만 모아도 브리핑에 붙일 ‘동료가 한 일’이 생깁니다. 센서와 원격 진단이 이미 있는 회사라면 권고 ID와 현장 원인 코드를 짝짓는 일부터 하십시오. 그 짝이 없으면 예지 모델이 맞았는지 영영 알 수 없습니다. 스폰서는 IT가 아니라 서비스 사업 책임자가 맡아야 기술자의 사용이 따라옵니다.

원문 사례

항목	내용
발표처	Microsoft Source EMEA 고객 사례 기사(2026.10.22), Catherine Bolgar, 독일 뒤셀도르프 취재. 벤더 발표
회사	TK Elevator(TKE). 서비스 기술자 약 2만5천 명, 관리 설비 140만 대, 하루 이용 승객 15억 명(회사 발표)
브리핑 에이전트	Microsoft Foundry · Azure OpenAI in Foundry Models. 설비·층·증상·작업 유형·공구 안내, 매뉴얼·서비스 이력 검색
디브리핑 에이전트	음성으로 작업 내용을 묻고 받아 적으며 필요하면 추가 질문, 노트를 서비스 기록에 추가
데이터 기반	약 10년 전부터 설비 연결. Azure · Azure IoT · Azure Databricks. Microsoft Industry Solutions Engineering(현 Microsoft Frontier Company)과 구축
DOC	9곳. 머신러닝 health score, 이벤트·에러 코드를 시간과 동종 설비에 걸쳐 비교, 반복 이상(문 반복 개폐) 탐지 후 권고
되먹임	디브리핑 노트가 고장 진단 개선과 새 패턴 발견에 쓰이고, 신입 기술자의 경험 공유로 이어짐
등장 인물	Christian Fongern(TKE 독일 CEO), Christian Jung(디지털 데이터·AI 기반 총괄), Tobias Lüsebrink(TKE 독일 디지털 전환, 베를린 DOC), Katherina Kahle(세일즈 서비스 팀장), Torben Teichmann(12년 차 기술자)
성과 수치	원문에서 밝히지 않음

핵심 개념

DOC(Digital Operations Center): 연결된 설비의 상태와 이벤트를 원격으로 보고 기술자에게 권고를 보내는 운영센터. TKE는 9곳을 운영한다.
health score: 설비마다 머신러닝으로 매긴 상태 점수. 정비 우선순위를 정하는 데 쓴다.
Microsoft Foundry: Microsoft의 AI 앱·에이전트 개발 플랫폼. Azure OpenAI 모델을 Foundry Models로 제공한다.
Azure Databricks: Azure에서 돌아가는 데이터 처리·분석 플랫폼. TKE 설비 데이터 플랫폼의 한 축.
installed base: 고객 현장에 설치돼 서비스 계약으로 관리하는 설비 전체. 현장 서비스 사업의 바탕이다.
STT(speech-to-text): 음성을 글로 바꾸는 음성 인식. 디브리핑의 첫 단계.
slot filling: 대화에서 미리 정한 항목(슬롯)을 하나씩 채워 가는 방식. 빈 항목만 되묻는다.

내 메모

TODO: 내 생각 추가

원문: Catherine Bolgar, “Data and AI agents give a lift to TK Elevator service technicians”(Microsoft Source EMEA, 2026.10.22). Microsoft가 발행한 고객 사례 기사로, 규모 숫자는 회사 발표이며 성과 수치는 원문에 없습니다. 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 기사의 내용을 AX Review가 다시 정리했습니다. 기술·현업 디테일, JSON 예시, 디브리핑 슬롯, 실패 대응, 6주 일정과 판정 기준, 인포그래픽은 새로 작성했으며 필드명과 숫자는 가상 예시입니다. 원문 전체는 Microsoft Source EMEA에서 볼 수 있습니다.