평균 수리 시간(MTTR): 2026년에 실행 가능하게 만드는 방법

귀하의 CMMS는 평균 수리 시간을 45분으로 표시합니다. 귀하의 기술자는 고장 수리에 4시간이 걸렸다는 것을 알고 있습니다. 두 숫자 모두 정확합니다. 서로 다른 것을 측정하고 있으며, 바로 그 차이에서 대부분의 MTTR 개선 프로그램이 실패합니다.

TL;DR

• 🔧 MTTR은 같은 기간의 총 수정 유지보수 시간을 수리 횟수로 나눈 값입니다.
• 📉 대부분의 CMMS 시스템은 수리(Repair) 단계만 기록하며, 감지(Detect)와 진단(Diagnose) 단계는 완전히 보이지 않는 상태로 남겨둡니다.
• ⚙️ MTBF 감소와 함께 MTTR이 감소하는 것은 성공 사례가 아니라 경고 신호입니다.
• 📊 세계 수준의 산업용 MTTR은 2시간 미만이며, 8시간 초과는 불량으로 간주됩니다.
• ✅ 가장 효과적인 MTTR 개선은 렌치 작업 시간을 줄이는 것이 아니라 감지(Detect)와 진단(Diagnose) 단계를 구조화하는 것입니다.
• 🗓️ 자동화를 추가하기 전에 중요도가 가장 높은 자산 10개부터 시작하여 4가지 단계를 모두 기록하세요.

MTTR은 실제로 무엇을 측정합니까?

평균 수리 시간(MTTR)은 고장난 자산을 서비스에 복구하는 데 걸리는 시간을 측정합니다. 이는 항만, 광업, 제조 및 차량 운영에서 사용되는 기본 유지보수 성과 지표입니다. MTBF와 MTTR이 함께 작동하는 방식과 직접적으로 연결되어 자산 신뢰성의 완전한 그림을 제공합니다.

공식을 살펴보기 전에, 약어 혼란을 해소할 필요가 있습니다. MTTR은 분야에 따라 네 가지 다른 의미를 가집니다.

MTTR의 네 가지 변형

약어	전체 이름	분야	측정 대상
MTTR	Mean Time to Repair	산업/유지보수	고장난 자산을 물리적으로 수리하는 시간
MTTR	Mean Time to Recovery	IT/SRE	시스템이 중단에서 복구되는 시간
MTTR	Mean Time to Respond	IT/통신	경보 발생부터 기술자 투입까지의 시간
MTTR	Mean Time to Resolve	IT 서비스 관리	티켓 개설부터 티켓 종료까지의 시간

산업 운영에서는 평균 수리 시간(Mean Time to Repair)이 올바른 정의입니다. 이 문서에서는 해당 정의를 일관되게 사용합니다.

산업 운영에 평균 수리 시간을 사용하는 이유는 무엇입니까?

평균 수리 시간은 유지보수 팀이 고장난 자산을 복구하는 데 걸리는 시간을 측정합니다. 이는 계획되지 않은 가동 중단 비용 및 차량 가용성과 직접 연결됩니다. 현장 중심 산업의 운영 탁월성은 일관되고 합의된 정의를 기준으로 이 숫자를 추적하는 데 달려 있습니다.

MTTR은 어떻게 계산합니까?

MTTR 공식은 간단합니다. 분자에 포함되는 항목에 따라 보고된 결과가 크게 달라질 수 있습니다.

MTTR = 총 수정 유지보수 시간 / 같은 기간의 수리 횟수

MTTR 공식

분자에 포함할 항목: 고장이 확인된 시점부터 자산이 서비스에 복귀할 때까지의 모든 시간입니다. 여기에는 기술자 대기 시간, 부품 대기 시간, 진단 시간, 렌치 작업 시간 및 확인 시간이 포함됩니다.

계획된 PM은 제외하세요. 예정된 유지보수는 별도의 범주입니다. 수정 MTTR에 포함하면 수치가 부풀려지고 실제 수리 팀 성과가 불명확해집니다.

실제 예시: 스트래들 캐리어

컨테이너 터미널에서 1주일간 5건의 스트래들 캐리어 고장을 추적합니다:

작업 지시서	총 수리 시간
WO-1101	3.5시간
WO-1102	2.0시간
WO-1103	6.5시간
WO-1104	1.5시간
WO-1105	4.0시간

총 수정 유지보수 시간: 17.5시간, 수리 횟수: 5회.

MTTR = 17.5 / 5 = 3.5시간

팀이 모든 단계를 포함했다면 이 수치는 타당합니다. WO-1103에는 유압 시일을 위한 90분의 부품 대기 시간이 있었습니다. 해당 대기 시간을 제외하면 보고된 MTTR은 3.0시간으로 줄어듭니다. 동일한 운영, 동일한 주, 다른 수치입니다.

동일한 데이터가 다른 숫자를 생성하는 방법

동일한 운영을 실행하는 두 현장은 크게 다른 MTTR 수치를 보고할 수 있습니다. 원인은 거의 항상 정의의 차이입니다. 부품 대기 시간을 제외하거나 렌치 작업 시간만 기록하는 팀은 올바르게 측정하는 팀보다 항상 빠르게 보일 것입니다. 현장 수준의 벤치마킹에는 숫자를 비교하기 전에 공통된 정의가 필요합니다.

모든 MTTR 내부의 4가지 실제 단계

대부분의 MTTR 개선 프로그램은 렌치 작업 시간을 대상으로 합니다. 작업 지시서에 안정적으로 나타나는 유일한 단계이기 때문입니다. 그러나 대부분의 운영에서 최적화해야 할 잘못된 단계입니다.

모든 수리 이벤트에는 4가지 고유한 단계가 있습니다. 대부분의 CMMS 시스템은 그 중 하나만 일관되게 기록합니다.

4단계: 감지(Detect), 진단(Diagnose), 수리(Repair), 확인(Verify)

감지(Detect): 고장 발생부터 첫 번째 사람이 인지할 때까지의 시간입니다. 이는 무선 통신, WhatsApp 메시지, 또는 운영자가 마당에 유휴 상태로 있는 자산을 발견할 때 발생합니다.

진단(Diagnose): 인지부터 근본 원인을 파악할 때까지의 시간입니다. 기술자가 도착하여 자산을 점검하고, 운영 매뉴얼을 확인하고, 교대 감독자와 상의합니다. 근본 원인 분석에는 이 데이터를 수집하고 구조화해야 합니다. 올바른 수리 방법이 확인되면 이 단계가 종료됩니다.

수리(Repair): 렌치 작업 시간입니다. 기술자가 확인된 진단을 가지고 수리를 실행합니다.

확인(Verify): 시험 가동, 승인, 서비스 복귀 확인입니다.

귀하의 컴퓨터화된 유지보수 관리 시스템은 수리(Repair) 단계에 타임스탬프를 기록하며, 때로는 확인(Verify) 단계도 기록합니다. 감지(Detect)와 진단(Diagnose)은 작업 지시서에 거의 나타나지 않습니다.

유압 고장 사례 연구

오전 6시 30분에 리치 스태커에 유압 고장이 발생했습니다. 운영자가 무선으로 보고했지만 교대 인계 중에 메시지가 누락되었습니다. 두 번째 운영자가 오전 8시 45분에 자산이 중단되었음을 신고했습니다. 기술자가 오전 9시 15분에 진단을 시작하여 오전 10시 45분에 파열된 시일을 발견했습니다. 수리에 45분이 소요되었습니다. 자산은 오전 11시 35분에 서비스에 복귀했습니다.

보고된 MTTR(렌치 작업 시간만): 45분

실제 MTTR(고장부터 서비스 복귀까지): 5시간 5분

’45분 MTTR’ 목표를 추구하는 팀은 실제 수치의 약 9분의 1만 최적화하고 있습니다. 2시간의 미감지 고장 시간과 90분의 진단 시간은 시스템 외부에 완전히 남아 있습니다.

CMMS가 일부만 기록하는 이유는 무엇입니까?

감지(Detect)와 진단(Diagnose)은 대화 속에 존재합니다. 여기에는 무선 통화, WhatsApp 스레드, 기술자와 교대 감독자 간의 통화가 포함됩니다. 대부분의 작업 지시서는 기술자가 현장에 도착한 후에야 생성됩니다. 그 이전의 모든 것은 다크 데이터(dark data)이며, 정보는 존재합니다. 단지 시스템에 도달하지 못할 뿐입니다.

산업별 MTTR 벤치마크

벤치마크 범위는 장비 유형, 자산 중요도, 그리고 각 조직이 MTTR을 정의하는 방식에 따라 크게 다릅니다. 이를 성과 요구사항이 아닌 방향성 참고 지점으로 사용하세요.

일관된 장비 가동 중단 추적은 모든 벤치마크 비교가 의미를 갖기 전에 필요한 기반입니다.

부문별 벤치마크 범위

산업	일반적인 MTTR 범위	비고
제조업(일반)	2~8시간	라인 중요도에 따라 크게 다름
석유 및 가스(육상)	4~24시간	부품 가용성이 주요 요인
광업	8~48시간	원격 위치로 인해 부품 납기 시간이 연장됨
운송 및 물류	2~8시간	차량 유형 및 경로 긴급도가 범위에 영향을 미침
항만 및 터미널	2~8시간	장비 등급(크레인 대 스트래들 캐리어)이 중요함

세계 수준: 2시간 미만, 우수: 2~4시간, 평균: 4~8시간, 불량: 8시간 초과.

이러한 벤치마크가 신뢰하기 어려운 이유는 무엇입니까?

MTTR에서 부품 대기 시간을 제외하는 현장은 항상 포함하는 현장보다 빠르게 보일 것입니다. MTTR을 산업 벤치마크와 비교하기 전에 동일한 정의를 공유하는지 확인하세요. 자산 등급을 정규화하지 않은 현장 수준 비교는 통찰이 아닌 노이즈를 생성합니다.

한 터미널에서 세계 수준의 MTTR이 첫 번째 팀이 모든 부품 대기 시간을 제외한다면 다른 터미널에서는 평균으로 보일 수 있습니다. 정의를 문서화하고 모든 현장, 모든 교대, 모든 장비 등급에 일관되게 적용하세요. 그래야만 현장 간 비교가 의미를 가집니다.

낮은 MTTR이 경고 신호인 경우는 언제입니까?

MTTR 감소는 일반적으로 좋은 소식이지만, 항상 그렇지는 않습니다. 차이를 아는 것이 유용한 유지보수 지표와 허영 지표를 구분합니다.

피상적 수리 함정이란 무엇입니까?

30분 MTTR은 숙련된 기술자들이 근본 원인을 신속하게 해결한다는 것을 의미할 수 있습니다. 또한 5일 후에 다시 고장 나는 임시 수리를 의미할 수도 있습니다. 두 번째 시나리오는 지속적인 사후 대응 작업 지시서를 생성하여 예방 유지보수 소프트웨어에 대한 모든 투자를 무력화합니다.

“사후 대응(MTTR) 전략은 사전 예방(예방) 전략보다 5~10배 더 많은 비용이 듭니다.”

Andrew Lerner, 부사장 및 수석 애널리스트, Gartner (출처)

MTTR이 고장 재작업의 지연 지표가 되기 전에 사전 예방적 유지보수 전략으로 전환하는 것이 올바른 순서입니다. 30분 수리 후 5일마다 고장 나는 자산은 MTTR의 성공이 아닙니다. MTBF의 실패입니다.

MTBF와 함께 MTTR을 어떻게 읽어야 합니까?

가용성 = MTBF / (MTBF + MTTR). MTBF 감소와 함께 MTTR이 감소하는 것은 수리가 빨라지더라도 자산이 더 자주 고장난다는 것을 의미합니다. 이 조합은 기술자 성과 문제가 아닌 유지보수 전략 문제를 나타냅니다. 전체 운영 상황을 파악하려면 OEE 및 가용성 지표와 함께 MTTR을 읽으세요.

MTTR에서 다크 데이터 문제란 무엇입니까?

귀하의 CMMS에는 구조적인 맹점이 있습니다. 시간 손실이 가장 많은 단계는 작업 지시서가 열리기 전에 발생하는 단계입니다.

측정하지 않는 것을 개선할 수 있습니까?

감지(Detect)와 진단(Diagnose)은 종종 실제 경과 수리 시간의 대부분을 차지합니다. 해당 시간의 모든 분은 기술자와 감독자 사이의 무선 통신과 WhatsApp 스레드 속에 존재합니다.

측정하지 않는 단계는 개선할 수 없습니다. 무선 통신에만 존재하는 단계는 측정할 수 없습니다.

대부분의 MTTR 개선 프로그램은 CMMS가 보고하는 렌치 작업 시간에 집중합니다. 결과적으로 전체 수리 이벤트의 가장 작은 부분에 상당한 노력을 기울이게 됩니다. 일반적인 유압 고장에는 45분의 렌치 작업 시간이 소요됩니다. 그 전에 4시간 이상의 경과 시간이 자주 측정되지 않은 채로 남습니다.

실제 MTTR 레버리지는 어디에 있습니까?

현장 통신을 타임스탬프가 찍힌 이벤트로 캡처하는 것이 감지(Detect)와 진단(Diagnose)을 측정 가능하게 만드는 유일한 방법입니다. 유압 고장에서 진단(Diagnose)이 평균 90분이라면, 맞춤형 운영 매뉴얼을 구축할 수 있습니다. 야간 교대에서 감지(Detect)가 평균 2시간이라면, 에스컬레이션 프로토콜을 조정할 수 있습니다.

다채널 상태 캡처는 무선 통화와 WhatsApp 스레드를 작업 지시서에 포함되어야 할 유지보수 기록으로 전환합니다. 데이터는 이미 존재합니다. 격차는 기술적인 것이 아니라 구조적입니다.

실제로 MTTR을 어떻게 개선합니까?

레버리지 순서대로 정렬하세요. 감지(Detect)와 진단(Diagnose) 먼저, 렌치 작업 시간 마지막. 대부분의 운영은 우선순위가 반대입니다.

1. 먼저 감지(Detect)와 진단(Diagnose)을 캡처하세요

무선 통화와 WhatsApp 메시지를 타임스탬프가 있는 기록으로 구조화하세요. 모든 고장 알림은 타임스탬프, 자산 ID 및 보고된 증상이 포함된 이벤트가 됩니다. 각 알림은 에이전트 기반 디스패치 워크플로우를 통해 자동으로 작업 지시서 이벤트를 생성합니다. 기술자가 현장에 도착하기 전에 작업 지시서가 열립니다.

2. 자산별 운영 매뉴얼 구축

각 고중요도 자산에는 현장에서 모바일 기기로 접근할 수 있는 운영 매뉴얼이 필요합니다. 운영 매뉴얼은 가장 일반적인 고장 모드, 진단 단계 및 필요한 부품을 다룹니다. 유지보수 이벤트의 AI 분류는 과거 작업 지시서 패턴에서 운영 매뉴얼을 채웁니다. 반복되는 고장 모드가 자동으로 표면화되어 현장에 도착하는 기술자에게 출발점을 제공합니다.

3. MTBF 패턴을 활용한 부품 사전 배치

부품 대기 시간은 광업, 원격 현장, 특수 차량에서 주요 MTTR 동인입니다. AI 기반 유지보수 우선순위 데이터는 자산이 베어링 고장 사이에 평균 300 엔진 시간을 가진다는 것을 보여줄 수 있습니다. 280시간 전에 베어링을 재고로 확보하세요. MTBF 패턴이 입력값입니다. 부품 배치가 출력값입니다.

4. 교대 간 기술자 인수인계 평가

교대 경계를 넘는 진행 중인 수리는 감지(Detect)와 진단(Diagnose)에 수 시간을 추가할 수 있습니다. 교대 기술자는 맥락 없이 도착하여 처음부터 다시 진단합니다. 교대 변경이 MTTR을 증가시키는 방법은 유지보수 관리에서 가장 간과된 요인 중 하나입니다. 자산 ID, 고장 설명, 현재 수리 상태가 포함된 인수인계 메모는 재진단 비용을 완전히 제거합니다.

5. KPI를 단계별 지표에 연결하세요

단계별 분석 없이 총 MTTR을 보고하면 시간이 실제로 어디로 가는지 숨겨집니다. 단계 수준에서의 자동화된 MTTR 및 MTBF 계산은 유지보수 관리자에게 하나 대신 네 개의 숫자를 제공합니다. 감지(Detect) 2.3시간, 진단(Diagnose) 1.4시간, 수리(Repair) 0.8시간, 확인(Verify) 0.3시간을 볼 수 있으며, 이 분석은 실행 가능합니다. 단일 4.8시간 합계는 그렇지 않습니다.

엔터프라이즈 시스템 통합은 단계별 데이터를 기존 CMMS, SAP 또는 Maximo에 연결합니다. 시스템 교체는 필요하지 않습니다. 현재 시스템 외부에 있는 신호 소스가 이미 보유한 유지보수 기록으로 확장됩니다.

MTTR은 인접 지표와 어떻게 비교됩니까?

MTTR은 유지보수 KPI 패밀리 중 하나의 지표이며, 각각은 다른 질문에 답합니다. 잘못된 결정에 잘못된 것을 사용하면 유지보수 팀이 잘못된 방향으로 이끌립니다.

비교 표: MTTR, MTBF, MTBR, MTTF

지표	측정 대상	최적 용도
MTTR	고장난 자산 복구 시간	유지보수 팀 성과
MTBF	고장 사이의 평균 시간	자산 신뢰성 추적
MTBR	부품 교체 사이의 평균 시간	소모품 및 마모 부품 계획
MTTF	첫 번째 고장까지의 시간(수리 불가 자산)	베어링, 전구, 일회용 부품
가용성	MTBF / (MTBF + MTTR)	SLA 약정 및 차량 계획
신뢰성	일정 기간 동안의 무결함 운영 확률	자산 투자 결정

수리 불가 부품에는 MTTF를 사용하세요. 수리 가능한 장비에는 MTBF를 사용하세요. 유지보수 팀 성과에는 MTTR을 사용하세요. 운영 약정에는 가용성을 사용하세요.

이러한 지표 간의 관계가 중요합니다. 높은 MTBF는 신뢰할 수 있는 자산을 나타냅니다. 낮은 MTTR은 유능한 유지보수 팀을 나타냅니다. 높은 가용성은 두 가지가 함께 작동하고 있음을 의미합니다. 자산 신뢰성이 저하되면 탁월한 MTTR에도 불구하고 낮은 가용성을 가질 수 있습니다. 다섯 가지를 함께 추적하면 완전한 유지보수 그림을 얻을 수 있습니다.

올바른 자산 관리 소프트웨어는 CMMS가 기본으로 표시하는 지표만이 아닌 이 모든 것을 함께 추적합니다.

일반적인 MTTR 측정 실수

대부분의 팀은 최소 두 가지 방법으로 동시에 MTTR을 잘못 측정합니다. 다음은 가장 일반적인 5가지 왜곡입니다.

팀이 MTTR 데이터를 왜곡하는 5가지 방법

1. 계획된 PM을 분자에 포함하는 것. 예정된 유지보수는 수리 이벤트가 아닙니다. PM 준수율로 별도로 추적하세요. 수정 MTTR에 혼합하면 계획되지 않은 수리 성과에 대한 신호 없이 수치가 부풀려집니다.

2. 부품 대기 시간 제외. 유압 시일 대기는 가동 중단 이벤트의 일부입니다. 체계적으로 제외하면 실제 수리 시간이 과소평가되어 부품 재고 결정이 어려워집니다. 유지보수 및 신뢰성 전문가 협회(SMRP) 표준에는 고장부터 서비스 복귀까지의 모든 가동 중단 시간이 포함됩니다.

3. 자산 등급을 정규화하지 않고 현장을 비교하는 것. 80% 대형 크레인을 운영하는 터미널은 가벼운 차량을 운영하는 터미널보다 높은 MTTR을 가질 것입니다. 정규화 없는 현장 수준 비교는 노이즈를 생성합니다.

4. 트리아지 필터링으로 인한 MTTR 감소를 축하하는 것. 유지보수 팀이 비중요 수리를 후속 작업 지시서로 연기하여 작업 지시서를 더 빨리 마감하면 MTTR이 감소합니다. 아무것도 개선되지 않았습니다. 백로그만 증가했습니다.

5. 단계별 분석 없이 총 MTTR을 측정하는 것. 단계 수준의 가시성 없이는 개선 이니셔티브가 잘못된 단계를 대상으로 합니다. 단계 수준에서 MTTR을 추적하는 CMMS는 이제 더 유능한 플랫폼에 존재합니다. 귀하의 플랫폼에서 제공하지 않는다면 보고 레이어를 업그레이드해야 합니다.

30일 구현 로드맵

전체 차량으로 시작하지 마세요. 10개의 자산으로 시작하여 확장하기 전에 방법론을 검증하세요.

중요도 상위 10개 자산부터 시작하세요

1~2주차: 운영에서 중요도가 가장 높은 자산 10개를 식별하세요. 각각에 대해 4가지 MTTR 단계를 수동으로 계측하세요. 각 고장 이벤트에 대한 무선 녹취록과 WhatsApp 로그를 가져오세요. 작업 지시서 타임스탬프와 대조하세요. 감지(Detect), 진단(Diagnose), 수리(Repair) 및 확인(Verify)을 포함하는 4열 로그를 구축하세요.

3~4주차: 단계별 분석을 검토하세요. 시간이 실제로 어디로 가고 있습니까? 대부분의 운영에서 감지(Detect)와 진단(Diagnose)이 경과 시간의 대부분을 차지합니다. 해당 10개 자산에 대한 단계별 보고 뷰를 구축하세요.

30일간의 기준선 데이터 이후에만 우선순위 로직이나 예측 도구를 추가해야 합니다. 첫 번째 목표는 가시성이지, 자동화나 예측이 아닙니다.

30일 수동 작업은 또한 CMMS의 데이터 품질 문제를 드러냅니다. 가장 가까운 시간으로 반올림된 작업 지시서 타임스탬프, 누락된 진단 메모, 서비스 복귀 시간이 없는 수리가 모두 재구성 중에 표면화됩니다. 4단계 분석은 이러한 데이터 격차를 가시화합니다.

Opsima는 이 그림에 어떻게 맞습니까?

Opsima 자체가 MTTR을 낮추지 않습니다. 이는 직접 명시할 가치가 있습니다. 많은 CMMS 벤더들이 다크 데이터 문제를 해결하지 않고 ‘MTTR을 위한 AI’를 판매합니다. 그 문제가 대부분의 시간 손실을 야기합니다.

보이지 않는 단계를 가시화하기

Opsima의 운영 데이터 백본인 EquipmentOS는 현장 통신 채널(무선, WhatsApp, 이메일)을 유지보수 기록에 연결합니다. 감지(Detect)와 진단(Diagnose)은 문서화되지 않은 대화 대신 타임스탬프가 찍힌 이벤트가 됩니다. Agent Builder는 48시간 내에 4단계 MTTR 캡처 워크플로우를 구축할 수 있습니다. 워크플로우는 팀의 기존 무선, WhatsApp 및 CMMS 연결에 대해 실행됩니다.

실제에서 신호 밀도가 어떻게 보이는가

주요 컨테이너 터미널에서 상태 이벤트가 월별로 약 10배 증가했습니다. 차량 가용성은 5% 증가했고 자산 신뢰성은 15% 향상되었습니다. 레버는 신호 밀도였습니다. 이전에는 시스템에 도달하지 못했던 무선 통화와 WhatsApp 스레드를 캡처한 것입니다.

해당 밀도에서의 실시간 자산 상태 및 KPI 가시성은 유지보수 계획을 재편성합니다. 팀은 부품, 인력 배치 및 교대 관리에 대해 더 나은 결정을 내립니다.

MTTR을 올바르게 측정하고 실제로 가동 중단을 초래하는 단계를 단축하려면 15분 탐색 통화를 예약하세요.