Logical/Analytical Troubleshooting Framework
The Seven-Step Troubleshooting Procedure
Vendor Assistance: Advantages and Pitfalls
Other Troubleshooting Methods
33.1 서론
Troubleshooting 트러블슈팅
트러블슈팅(troubleshooting)은 어떤 것이 제대로 작동하지 않거나 기대한 결과를 제공하지 않는 이유를 파악하기 위한 방법으로 정의할 수 있습니다. 트러블슈팅 방법은 물리적인 문제뿐만 아니라 비물리적인 문제에도 적용될 수 있습니다. 많은 실용적인 기술과 마찬가지로 트러블슈팅은 하나의 기술이자 예술이며, 동시에 분석적 또는 과학적인 기반을 가지고 있습니다. 따라서 기본적인 트러블슈팅은 훈련 가능한 기술이며, 고급 트러블슈팅은 경험, 숙련도, 정보, 그리고 약간의 직관에 기반합니다.
여기서 다루는 내용은 계장 및 제어 시스템의 트러블슈팅에 중점을 두고 있지만, 기본 원칙은 더 넓은 범주의 문제에도 적용될 수 있습니다.
트러블슈팅은 일반적으로 문제가 존재하며 해결이 필요하다는 것을 인식하는 것에서 시작됩니다. 초기 단계는 논리적이고 분석적인 틀을 적용하는 것으로 구성됩니다.
33.2 논리적/분석적 트러블슈팅 프레임워크
프레임워크는 구조의 기반이 됩니다. 논리적 프레임워크는 문제를 트러블슈팅하기 위한 구조화된 방법의 기초를 제공합니다. 그러나 문제를 먼저 충분히 생각해보지 않고 단순히 단계별 방법만을 따르는 것은 종종 효과적이지 않습니다. 우리는 논리적인 절차와 분석적 사고를 결합해야 합니다.
정보를 분석하고 다음 단계로 나아가기 위해서는 논리적 연역(deduction)과 귀납(induction)을 시스템에 대한 지식과 결합한 후, 문제와 관련하여 수집한 정보를 정리해야 합니다. 논리적/분석적 프레임워크는 한 번의 시도로 문제 해결을 제공하지 않는 경우가 많습니다. 일반적으로 여러 번 반복(iteration)을 거치며, 프레임워크의 이전 단계로 돌아갔다가 다시 앞으로 나아가는 과정을 거칩니다. 이러한 방식으로 우리는 문제의 가능한 해결책을 체계적으로 제거해 나가면서 실제 해결책을 찾아낼 수 있습니다.
33.2.1 특정 트러블슈팅 프레임워크
특정 계기, 계기의 종류, 시스템 또는 문제 영역에 적용되는 특정 트러블슈팅 프레임워크들이 개발되어 있습니다. 예를 들어, 특정 브랜드의 분석기(analyzer), 모든 종류의 트랜스미터(transmitter), 압력 제어 시스템(pressure control systems), 접지 문제(grounding problems) 등에 대한 프레임워크가 있을 수 있습니다. 이러한 프레임워크가 사용자의 시스템과 일치할 경우, 트러블슈팅을 위한 명확한 출발점을 제공하게 됩니다.
그림 33-1은 예를 들어 트랜스미터(transmitter)에 대한 특정 문제 영역의 트러블슈팅 흐름도(flowchart) 또는 트리(tree)를 보여줍니다.
33.2.2 일반적인 논리적/분석적 프레임워크(Generic Logical/Analytical Frameworks)
항상 특정한 구조화된 프레임워크를 사용할 수 있는 것은 아니므로, 보다 일반적이고 광범위한 문제에 적용 가능한 프레임워크가 필요합니다. 그림 33-2는 이러한 유형의 프레임워크를 흐름도 형태로 나타냅니다.
그림 33-2에 제시된 프레임워크는 효율적이지만, 트러블슈팅 과정과 관련된 몇 가지 중요한 안전 작업 및 회사의 절차적 요구사항을 생략하고 있습니다. 이에 대해 몇 가지 중요한 사항을 언급하고자 합니다:
• 트러블슈팅은 온라인 시스템(on-line systems), 전원이 공급된 시스템(energized systems), 움직이는 부품(moving parts)을 다루는 작업으로 인해 트러블슈터(troubleshooter)의 안전 위험을 증가시킵니다.
• 자신, 동료 작업자, 그리고 시설에 대해 작업이 안전한지 항상 확인하십시오.
• 회사의 절차를 반드시 준수하십시오.
• 적절한 작업 허가서(permit)를 받고, 그 요구사항을 반드시 준수하십시오.
• 담당 운전자(operator) 및 관련된 모든 사람들과 작업 내용을 항상 공유하십시오.
• 자신의 신체 일부를 정확히 어떤 것이 있는지 모르는 곳에 절대 넣지 마십시오.
• 불필요한 위험은 절대 감수하지 마십시오. 구할 수 있는 생명이 바로 당신일 수 있습니다!
33.3 7단계 트러블슈팅 절차(The Seven-Step Troubleshooting Procedure)
그림 33-2에 나타난 다음의 7단계 절차는 트러블슈팅을 위한 일반적이고 구조화된 접근 방식을 제공합니다.
33.3.1 1단계: 문제 정의(Define the Problem)
문제가 무엇인지 모르면 해결할 수 없습니다. 문제 정의는 트러블슈팅의 출발점입니다. 문제를 잘못 정의하면, 해결을 위한 올바른 경로에서 벗어나게 됩니다.
의사소통(Communication)
문제를 정의할 때는 문제를 보고한 사람의 이야기를 주의 깊게 듣고, 그 사람이 인식한 문제를 충분히 설명할 수 있도록 해야 합니다. 경청의 기술은 트러블슈팅의 핵심 요소입니다. 주의 깊게 들은 후에는 명확하고 간결한 질문을 던지십시오. 모든 정보에는 주관적인 요소가 포함되어 있습니다. 문제를 식별하려면 이러한 주관적인 요소를 제거하고 상황의 핵심을 파악해야 합니다.
고급 기술 용어나 “기술적 수다(technobabble)”는 피하십시오. 트러블슈터는 문제를 보고한 사람의 “언어”를 이해하고 말할 수 있어야 합니다. 이는 공정(process), 플랜트의 물리적 배치, 계장 위치, 플랜트에서 알려진 공정 기능, 그리고 플랜트에서 일반적으로 사용되는 약어, 속어, 기술 용어의 “방언(dialect)”을 이해하는 것을 의미합니다. 이러한 요소 중 일부는 일반적인 공정 플랜트에 공통적이며, 일부는 특정 플랜트에만 해당됩니다.
33.3.2 2단계: 문제에 대한 추가 정보 수집(Collect Additional Information Regarding the Problem)
문제가 정의되면, 그 다음 단계는 추가 정보를 수집하는 것입니다. 이 단계는 1단계와 겹칠 수 있으며, 간단한 문제의 경우 두 단계가 동일하게 진행될 수도 있습니다. 그러나 복잡하거나 정교한 문제의 경우, 정보 수집은 보다 명확히 구분되는 단계입니다.
정보 수집을 위한 전략 또는 실행 계획을 수립하십시오. 이 계획에는 시스템의 어느 지점에서 정보를 수집할 것인지, 어떤 출처를 활용할 것인지, 그리고 정보를 어떻게 정리할 것인지가 포함되어야 합니다. 정보 수집은 일반적으로 일반적인 사항에서 구체적인 사항으로 진행되며, 여러 번 반복(iteration)될 수 있습니다. 즉, 문제 영역을 점점 좁혀가는 작업입니다.
증상(Symptoms)
수집되는 정보는 일반적으로 시스템에서 잘못된 부분뿐만 아니라 정상적으로 작동하는 부분에 대한 증상으로 구성됩니다. 주요 증상(primary symptoms)은 현재 문제의 원인과 직접적으로 관련된 것이며, 2차 증상(secondary symptoms)은 문제의 원인으로부터 직접적으로 발생하지 않은 하위 영향입니다. 주요 증상과 2차 증상을 구분하는 것이 문제의 원인을 국소화하는 데 핵심이 될 수 있습니다.
인터뷰 및 정보 수집(Interviews and Collecting Information)
정보 수집의 대부분은 문제를 보고한 사람 및 관련 정보를 알고 있을 수 있는 다른 사람들과의 인터뷰(interview) 형태로 이루어집니다. 이때 사람과의 소통 능력이 중요합니다. 효과적인 의사소통 능력, 신중한 태도, 판단하지 않는 객관적인 접근 방식은 유용한 정보를 얻는 데 핵심적인 역할을 합니다.
그 다음으로는 제어 시스템의 페이스플레이트(faceplate), 트렌드 기록기(trend recorder), 요약 정보, 운전 로그(operating logs), 알람 로그(alarm logs), 기록 장치(recorder), 시스템 자체 진단(self-diagnostics) 등을 통해 계장 또는 시스템의 성능을 검토합니다. 시스템 도면(system drawings) 및 문서(documentation)도 추가 정보를 제공할 수 있습니다.
점검(Inspection)
그 다음으로는 고장이 의심되는 계장 또는 기타 현장 계장(예: 압력 게이지, 온도 게이지, 사이트 글라스, 현장 표시기 등)을 점검하여 문제를 파악하는 데 도움이 될 수 있는 다른 징후가 있는지 확인합니다.
이력(History)
이력 기록도 유용한 정보를 제공할 수 있습니다. 시설의 유지보수 관리 시스템(Maintenance Management System, MMS)에는 고장난 시스템 또는 유사한 시스템에 대한 정보가 포함되어 있을 수 있습니다. 또한 해당 계장 또는 시스템을 다뤄본 적이 있는 다른 사람들과도 확인해 보십시오.
명확하지 않은 경우(Beyond the Obvious)
명확한 답이 없는 경우에는 시험(testing)이 필요할 수 있습니다. 시험은 안전하게 수행되며, 최소한의 개입으로 필요한 정보를 얻을 수 있도록 계획해야 합니다. 시스템을 조작하여 시험할 경우, 한 번에 하나의 변수만을 시험하거나 조작하도록 계획하십시오. 여러 변수를 동시에 변경하면 문제는 해결될 수 있지만, 어떤 요소가 문제를 해결했는지 알 수 없게 됩니다. 원하는 정보를 얻기 위해 필요한 최소한의 조작만 수행하십시오. 이는 공정에 미치는 영향을 최소화합니다.
33.3.3 3단계: 정보 분석(Analyze the Information)
정보를 수집한 후에는 이를 분석하여 해결책을 제시할 수 있을 만큼 충분한 정보가 있는지를 판단해야 합니다. 먼저 수집한 정보를 정리하는 것부터 시작하십시오.
그 다음에는 기존에 알고 있는 내용과 새롭게 수집한 정보를 검토하면서 문제를 분석합니다. 원인과 결과를 연결하고, 인과 관계를 탐색하며, “만약 ~라면(If/Then)” 또는 “만약 ~가 아니라면(If/Then Not)” 논리를 적용하고, 배제법(process of elimination) 및 기타 관련된 분석적 또는 논리적 방법을 활용합니다.
사례 기반 추론(Case-Based Reasoning)
가장 먼저 사용하게 되는 분석 기법은 과거의 경험일 가능성이 높습니다. 이전에 동일한 문제를 본 적이 있다면, 가능한 해결책을 알고 있을 것입니다. 여기서 “가능한 해결책”이라고 표현한 이유는, 유사한 증상이라도 원인이 다를 수 있으며, 따라서 해결책도 달라질 수 있기 때문입니다.
유사 분석(Similar To Analysis)
현재 작업 중인 시스템을 과거에 작업했던 유사한 시스템과 비교해 보십시오. 예를 들어, 압력 트랜스미터(pressure transmitter), 차압 트랜스미터(differential pressure transmitter), 차압 레벨 트랜스미터(differential pressure level transmitter)는 유사한 계기입니다. 서로 다른 브랜드의 PLC도 상당한 유사성을 지니고 있는 경우가 많습니다. RS-485 통신 링크는 출발지와 목적지 계기가 매우 다르더라도 유사한 방식으로 작동합니다. 유사한 계기와 시스템은 동일한 기본 원리에 따라 작동하며, 유사한 문제와 해결책을 가질 가능성이 있습니다.
“무엇, 어디서, 언제” 분석(“What, Where, When” Analysis)
이러한 유형의 분석은 “스무고개(Twenty Questions)” 게임과 유사합니다. 수집한 정보가 무엇을 말해주는지를 파악하기 위해 질문을 던집니다. 예를 들어 다음과 같은 질문이 있습니다:
• 무엇이 작동하고 있는가?
• 무엇이 작동하지 않는가?
• 어떤 것이 증상(효과)의 원인이고, 어떤 것이 아닌가?
• 무엇이 변경되었는가?
• 무엇이 변경되지 않았는가?
• 문제가 어디에서 발생하는가?
• 문제가 어디에서 발생하지 않는가?
• 문제가 언제 발생했는가?
• 문제가 언제 발생하지 않았는가?
패턴(Patterns)
증상은 때때로 복잡하게 나타나며 시간에 따라 분산되어 발생할 수 있습니다. 증상의 행동이나 행동의 부재, 발생 시점에서의 패턴을 살펴보는 것은 증상 분석에 도움이 될 수 있습니다.
기본 원칙(Basic Principles)
데이터를 분석할 때는 기본적인 과학 원리를 적용하십시오. 예를 들어, 전류는 특정 경로로만 흐를 수 있으며, 오옴의 법칙(Ohm’s Law)과 키르히호프의 법칙(Kirchhoff’s Laws)은 항상 유효합니다. 질량과 에너지는 항상 균형을 이루며, 물리적 특성도 고려해야 합니다.
매뉴얼(The Manual)
의심스러운 경우에는 매뉴얼을 읽으십시오! 회로, 시스템 분석, 트러블슈팅에 대한 정보가 포함되어 있을 수 있으며, 이는 해결책으로 이어질 수 있습니다. 매뉴얼에는 전압, 전류, 표시기(indicator) 판독값, 시험 지점(test points), 분석 절차 등이 포함되어 있을 수 있습니다. 종종 트러블슈팅을 돕기 위한 표나 차트도 제공됩니다.
논리적 방법(Logical Methods)
이제 반복적인 절차를 성공적으로 수행하기 위해 논리적인 접근 방식이 필요합니다. 여러 접근 방식 중 선형 접근법(linear approach)과 “분할 정복(Divide and Conquer)” 방법이 적용될 수 있습니다.
먼저 선형 또는 워크스루(walk-through) 접근법을 시도해 보십시오. 이는 시스템을 따라 단계별로 진행하는 절차이며, 그림 33-3에 설명되어 있습니다. 첫 번째 단계는 진입 지점(entry point)을 결정하는 것입니다. 진입 지점이 정상이라면, 다음 단계로 신호 경로의 하류 지점을 시험합니다. 이 지점이 정상이라면, 그 다음 하류 지점을 선택하여 계속 진행합니다. 반대로 진입 지점에서 이상이 발견되면, 상류 지점으로 이동하여 다시 절차를 시작합니다. 하류 또는 상류로 이동할 때마다 가능한 원인을 좁혀나가게 됩니다. 분기(branch)가 있는 경우에는 분기 이후의 첫 번째 가능성 있는 지점에서 시험을 수행해야 합니다.
두 번째로, “분할 정복(Divide and Conquer)” 방법은 일반적인 접근 방식이며, 이는 그림 33-4에 설명되어 있습니다.
이 방법에서는 시스템의 중간 지점 또는 가능성이 높은 지점을 선택하여 시험합니다. 해당 지점에서 이상이 발견되면, 시스템의 상류 구간에 문제가 있는 것입니다. 이후 상류 구간을 두 부분으로 나누고, 그 분할 지점에서 다시 시험을 수행합니다. 반대로 시험 결과가 정상이라면, 하류 구간에 문제가 있는 것이므로 그 구간을 다시 두 부분으로 나누어 시험을 반복합니다. 이러한 과정을 통해 문제의 원인을 찾아낼 수 있습니다.
33.3.4 4단계: 정보의 충분성 판단(Determine Sufficiency of Information)
정보를 수집하는 과정에서, 어느 시점에 정보가 충분한지를 어떻게 판단할 수 있을까요? 문제의 원인을 파악하고 해결책을 제시할 수 있는지 여부를 판단해야 합니다. 이는 다음 단계인 해결책 제안으로 넘어가기 위한 결정 지점입니다.
33.3.5 5단계: 해결책 제안(Propose a Solution)
문제의 원인을 파악했다고 판단되면, 해결책을 제안하십시오. 실제로는 분석 결과에 따라 여러 가지 해결책을 제시할 수도 있습니다. 일반적으로 제안되는 해결책은 고장난 부품을 제거하고 교체하거나 수리하는 것입니다. 그러나 경우에 따라 제안된 해결책이 문제를 완전히 해결할 수 있다는 확신이 없을 수도 있으며, 이 경우에는 시험이 필요합니다. 가능한 해결책이 여러 개 있을 경우, 성공 가능성이 높은 순서대로 제안하십시오. 성공 가능성이 비슷하거나 운전상의 제약이 있는 경우에는 다른 기준을 적용할 수 있습니다. 예를 들어, 가장 쉬운 방법부터 가장 어려운 방법 순으로 제안하거나, 인건비, 소모품 비용, 생산 손실 등 다양한 비용 요소를 고려하여 가장 비용이 적게 들면서도 실현 가능한 옵션부터 시도할 것을 제안할 수 있습니다.
여러 해결책을 동시에 시도하지 마십시오. 이는 “샷건 방식(Shotgun Approach)”이라고 하며, 일반적으로 문제를 더 혼란스럽게 만들 뿐입니다. 경영진이 시간이나 운전상의 제약으로 인해 샷건 방식을 요구하는 경우도 있지만, 이에 저항해야 합니다. 약간의 분석 작업만으로도 문제를 해결하면서 경영진의 요구사항을 더 낮은 비용으로 충족할 수 있습니다. 샷건 방식으로 문제를 해결하면, 어떤 방법이 문제를 해결했는지 알 수 없게 되며, 이는 단기적으로뿐만 아니라 장기적으로도 더 많은 비용을 초래할 수 있습니다. 문제를 해결한 방법을 알 수 없다면, 같은 문제를 반복하게 될 수도 있습니다.
또한, “위원회”에서 제안한 타협적인 해결책에 성급히 동의하지 마십시오. 이는 잘 알려진 “애빌린 여행(Trip to Abilene)” 이야기에서 나타나는 “집단 사고(group think)” 개념을 보여줍니다. 이 이야기는 아무도 실제로는 원하지 않지만, 모두가 다른 사람이 원한다고 생각하여 결국 애빌린에 가게 되는 상황을 설명합니다. 트러블슈팅에서도 위원회가 트러블슈터를 “지원”하기 위해 모였지만, 결국 애빌린으로 향하는 길에 빠지는 경우가 발생할 수 있습니다.
33.3.6 6단계: 제안된 해결책 시험(Test The Proposed Solution)
해결책 또는 해결책의 조합을 제안한 후에는, 해당 해결책이 문제 분석에 따라 올바른지 확인하기 위해 시험을 수행해야 합니다.
구체적 해결책 vs 일반적 해결책(Specific Versus General Solutions)
보다 일반적인 문제에 대해 구체적인 해결책을 적용할 때는 주의가 필요합니다. 이 단계에서는 제안된 해결책이 보다 일반적인 해결책이 필요한 상황인지 판단해야 합니다. 대부분의 경우, 구체적인 해결책은 고장난 계기를 수리하거나 교체하는 것이지만, 이것만으로 문제가 해결되지 않을 수도 있습니다.
예를 들어, 계기를 교체했지만 새로운 계기도 곧 고장난다면 어떻게 해야 할까요? 신호선이 매우 긴 계기가 낙뢰에 의한 과도 전류(transient)로 손상되었다고 가정해 봅시다. 구체적인 해결책은 계기를 교체하는 것이지만, 일반적인 해결책은 해당 계기에 과도 전류 보호 장치(transient protection)를 설치하는 것일 수 있습니다.
반복적 절차(The Iterative Process)
제안된 해결책을 시험한 결과 올바른 해결책이 아니었다면, 다시 3단계: 정보 분석으로 돌아가십시오. 어디서 잘못되었는지 검토하고, 실수를 찾았다면 새로운 해결책을 제안하십시오. 실수를 찾지 못했다면, 2단계: 정보 수집으로 돌아가 더 많은 정보를 수집하여 실제 해결책을 찾는 데 집중해야 합니다.
33.3.7 7단계: 수리(The Repair)
수리 단계에서는 제안한 해결책을 실제로 실행합니다. 경우에 따라 해결책을 시험하는 과정에서 수리가 동시에 이루어질 수 있습니다. 예를 들어, 트랜스미터를 교체하는 경우, 이는 해결책을 시험함과 동시에 문제를 수리하는 것입니다.
이러한 경우에도 일반적으로 태깅(tagging), 데이터베이스 업데이트, 유지보수 기록 갱신 등 추가 작업이 필요합니다. 수리 내용을 문서화하여 향후 트러블슈팅이 더 쉬워지도록 하십시오.
33.4 공급업체 지원: 장점과 함정(Vendor Assistance: Advantages and Pitfalls)
때로는 트러블슈팅 과정에서 공급업체를 직접 또는 전화로 참여시키는 것이 필요합니다. 제조업체의 서비스 담당자는 매우 유용할 수 있으며, 학습의 기회도 제공할 수 있습니다. 그러나 일부 담당자는 자신의 시스템에 문제가 없다고 판단되면, 다른 시스템 구성 요소에 책임을 돌리는 경향이 있습니다. 어떤 경우에는 자신의 시스템을 점검하기도 전에 그렇게 말하는 경우도 있습니다.
공급업체가 “자신들의 장비 문제가 아니다”라고 말한다고 해서 문제 해결 과정에서 그들을 면책시키지 마십시오. 질문을 던지고, 그들의 입장을 정당화하도록 요구하십시오.
33.5 기타 트러블슈팅 방법(Other Troubleshooting Methods)
논리적/분석적 프레임워크를 보완할 수 있는 다양한 트러블슈팅 방법들이 존재합니다. 대표적인 방법으로는 다음과 같은 것들이 있습니다:
- 대체(Substitution)
- 결함 삽입(Fault Insertion)
- 제거 후 정복(Remove and Conquer)
- 원형 방어(Circle the Wagons)
- 복잡에서 단순으로(Complex-to-Simple)
- 트래핑(Trapping)
- 자문(Consultation)
- 직관(Intuition)
- 창의적 사고(Out-of-the-Box Thinking)
33.5.1 대체 방법(The Substitution Method)
대체 방법은 고장이 의심되는 구성 요소를 정상적인 구성 요소로 교체하여 시험하는 방식입니다. 모듈화된 시스템이나 쉽게 교체 가능한 구성 요소가 있는 경우, 대체를 통해 문제의 원인을 파악할 수 있습니다. 먼저 문제를 정의하고, 정보를 수집하고 분석하는 일반적인 트러블슈팅 프레임워크와 동일한 절차를 따릅니다. 그런 다음, 교체 후보를 선정하고 정상적인 구성 요소로 대체합니다. 여러 구성 요소를 순차적으로 대체하면서 문제를 찾는 방식은, 명확한 고장 후보가 없거나 의심 영역이 모호한 경우에도 효과적일 수 있습니다.
단점으로는 상위 수준의 원인이 교체한 구성 요소를 즉시 손상시킬 수 있다는 점이 있습니다. 예를 들어, 낙뢰에 의한 과도 전류(transient)가 고장을 유발한 경우, 교체한 구성 요소도 동일한 방식으로 손상될 수 있으며, 이 경우 해결책은 일시적인 것에 불과할 수 있습니다. 또한 이 방법은 모듈 비용 및 예비 부품 재고 비용으로 인해 전체 유지보수 비용을 증가시킬 수 있습니다.
33.5.2 결함 삽입 방법(The Fault Insertion Method)
때로는 정상적인 신호나 값 대신 결함을 인위적으로 삽입하여 시스템의 반응을 확인할 수 있습니다. 예를 들어, 소프트웨어 통신 인터페이스가 주기적으로 멈추는 경우, 해당 인터페이스가 I/O 타임아웃에 제대로 반응하지 않는다고 의심할 수 있습니다. 이 경우, I/O 타임아웃이라는 결함을 삽입하여 시험할 수 있습니다.
33.5.3 제거 후 정복 방법(The “Remove and Conquer” Method)
다수의 독립적인 장치로 구성된 느슨하게 결합된 시스템에서는 장치를 하나씩 제거해보는 방식이 특정 유형의 문제를 찾는 데 도움이 될 수 있습니다. 예를 들어, 컴퓨터와 통신하는 10개의 독립 장치가 있는 통신 링크가 제대로 작동하지 않는 경우, 장치를 하나씩 제거하면서 문제가 있는 장치를 찾아낼 수 있습니다. 문제 장치를 감지하고 수리한 후에는 제거했던 장치들을 하나씩 다시 설치하여 추가적인 문제가 발생하는지 확인해야 합니다.
“Remove and Conquer” 기법은 통신 시스템이 잘못 구성되었거나 시스템 설계 사양을 초과한 경우에 특히 유용합니다. 예를 들어, 통신 링크에 장치가 너무 많거나, 케이블이 너무 길거나, 케이블이 맞지 않거나, 케이블 설치가 잘못되었거나, 임피던스 불일치가 있거나, 리피터가 너무 많은 경우 등이 해당됩니다. 이러한 상황에서는 통신 시스템의 일부 구간을 분리하여 어떤 변화가 있는지 확인할 수 있습니다.
유사한 기법으로 “Add Back and Conquer”가 있으며, 이는 모든 장치를 제거한 후 하나씩 다시 추가하면서 문제의 원인을 찾는 방식입니다.
33.5.4 원형 방어 기법(The “Circle the Wagons” Method)
문제의 원인이 장치나 시스템 외부에 있다고 판단되는 경우에는 “Circle the Wagons” 기법을 시도해보십시오. 장치 또는 시스템을 중심으로 가상의 원 또는 경계를 설정한 후, 해당 경계를 넘는 인터페이스(예: 신호, 전원, 접지, 환경 조건, EMI 등)를 확인합니다. 그런 다음 각 경계 교차 지점을 분리하고 시험합니다.
이 기법은 종종 단순한 사고 실험으로 활용되며, 외부 영향에 대해 사고할 수 있도록 도와주고, 결국 해결책을 찾는 데 기여합니다. 그림 33-5 및 그림 33-6은 이 개념을 설명합니다.
33.5.5 트래핑 기법(A Trapping We Shall Go)
문제를 유발하거나 촉발하는 이벤트가 알람으로 설정되어 있지 않거나, 과도(transient) 현상으로 인해 발생하거나, 너무 빠르게 발생하여 시스템이 이를 포착하지 못하는 경우가 있습니다. 이는 마치 집에 쥐가 있는 상황과 비슷합니다. 쥐는 직접 보이지 않지만, 쥐가 남긴 흔적은 볼 수 있습니다. 그렇다면 쥐를 어떻게 잡을까요? 함정을 설치하는 것입니다.
정교한 시스템에서는 추가 알람을 설정하거나 트렌드를 식별하여 문제의 원인을 추적할 수 있습니다. 덜 정교한 시스템에서는 외부 시험 장비를 사용하거나 직접 함정을 만들어야 할 수도 있습니다. 소프트웨어가 관련된 경우에는 과도 현상이나 버그를 감지하기 위한 추가 로직이나 코드를 포함한 소프트웨어 트랩을 구축해야 할 수도 있습니다.
33.5.6 복잡에서 단순으로 기법(The Complex-to-Simple Method)
많은 제어 루프 및 시스템은 다양한 수준의 운전 또는 복잡성을 가지고 있으며, 정교함의 정도도 다릅니다. 한 가지 트러블슈팅 방법은 시스템을 복잡한 구조에서 단순한 구조로 분해하는 것입니다. 이 방법은 전체 시스템을 구성하는 단순한 부분을 찾아내는 것을 포함합니다. 가장 단순한 구성 요소 중에서 작동하지 않는 “부분”을 찾으면, 해당 부분을 평가하거나, 필요한 경우 정상적으로 작동하는 단순한 구성 요소부터 시작하여 시스템을 “재구성”하면서 문제를 찾아낼 수 있습니다.
33.5.7 자문 기법(Consultation)
자문(consultation), 또는 “세 번째 머리(third head)” 기법은 다른 부서의 직원이나 외부 컨설턴트처럼 시스템이나 트러블슈팅 원리에 대해 고급 지식을 가진 제3자를 활용하는 것을 의미합니다. 이 사람이 직접 문제를 해결하지는 않더라도, 문제의 원인을 명확히 해주는 질문을 던지거나 새로운 아이디어를 떠올릴 수 있도록 도와줄 수 있습니다.
이 과정은 문제에 대해 한 걸음 물러서서 바라볼 수 있게 해주며, 때로는 숲 속의 나무가 아닌 숲 전체를 볼 수 있도록 도와줍니다. 핵심은 자신이 조사할 수 있는 한계에 도달했음을 인식하고, 추가적인 도움이나 통찰이 필요하다는 것을 아는 것입니다.
33.5.8 직관(Intuition)
직관은 매우 강력한 도구가 될 수 있습니다. 많은 사람들이 트러블슈팅에서 말하는 “직관”은 경험에 따라 향상됩니다. 문제 해결 과정에서 의식 또는 잠재의식 속에서 여러 가지 사고의 흐름이 형성되며, 그 중 하나가 해결책으로 이어질 수 있습니다.
경험이 많을수록 트러블슈팅 과정에서 더 많은 사고의 흐름이 형성됩니다. 그렇다면 직관을 개발할 수 있을까요? 경험에 따르면 가능하지만, 성공 여부는 사람마다, 그리고 사용하는 기법마다 다를 수 있습니다. 자신에게 맞는 방법을 찾아보십시오.
33.5.9 창의적 사고 기법(“Out-of-the-Box” Thinking)
복잡한 문제는 일반적이거나 전통적인 트러블슈팅 방법을 넘어서는 접근이 필요할 수 있습니다. “Out-of-the-box thinking(창의적 사고)”이라는 용어는 1990년대 조직 컨설턴트들 사이에서 유행한 표현으로, 문제를 새로운 관점에서 바라보고 기존의 사고방식에 얽매이지 않는 접근을 의미합니다.
이러한 접근 방식의 어려움은 우리의 트러블슈팅 “관점”이 일반적으로 실용적인 경험에 기반하여 형성된다는 점입니다. 즉, 과거에 효과가 있었던 방식에 익숙해져 있기 때문에 새로운 방식으로 사고하는 것이 어려울 수 있습니다.
그렇다면 어떻게 창의적 사고를 실천할 수 있을까요? 문제를 해결하기 위한 새로운 관점을 찾기 위해 사고를 전환하려면 다음과 같은 질문들이 도움이 될 수 있습니다:
• 문제를 바라보는 다른 방식이 있을까?
• 문제를 다른 방식으로 나눌 수 있을까?
• 문제를 분석하는 데 다른 원리를 적용할 수 있을까?
• 작동하지 않는 부분이 아닌, 작동하는 부분을 분석함으로써 문제를 해결할 수 있을까?
• 문제를 분석하기 위한 다른 출발점을 사용할 수 있을까?
• 너무 작은 조각만 보고 있는 것은 아닐까? 혹은 너무 큰 범위를 보고 있는 것은 아닐까?
• 분석의 기반이 되는 정보 중 오류가 있거나, 오해되었거나, 다른 방식으로 해석될 수 있는 것은 없을까?
• 문제를 다른 개념으로 바라볼 수 있을까?
• 유사한 특성을 가진 다른 “박스”가 있어 새로운 관점을 제공할 수 있을까?
33.6 요약(Summary)
트러블슈팅은 하나의 기술이자 예술이며, 과학적 원리에 기반하고 경험을 통해 발전하는 훈련 가능한 능력입니다. 성공적인 트러블슈팅을 위해서는 조직적이고 논리적인 접근이 필요하며, 이는 논리적 프레임워크를 따름으로써 가능해집니다. 또한 대체(Substitution), 제거 후 정복(Remove and Conquer), 원형 방어(Circle the Wagons), 창의적 사고(Out-of-the-Box Thinking)와 같은 일반화된 기법들을 보완적으로 활용할 수 있습니다.