트러블슈팅

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

트러블슈팅은 문제의 원인을 식별하고 해결하기 위한 체계적인 과정이다. 문제 해결의 첫 단계는 문제의 진단이며, 문제 해결사는 증상 기반 진단(사례 기반 추론) 또는 지형 기반 진단(심층 추론)과 같은 다양한 전략을 사용한다. 문제 해결의 기본 원칙은 문제를 재현 가능하게 만들고, 가장 단순한 원인부터 검토하며, 시스템을 단순화하는 것이다. 간헐적인 문제는 재현하기 어려워 해결이 까다롭지만, 열에 민감한 부품이나 경합 조건과 관련될 수 있다. 문제 해결에는 체크리스트, 절차, 전산화된 서비스, 인지 워크스루, 최소 구성, 기본값 설정 및 재설치, 문서화 등이 활용될 수 있다.

더 읽어볼만한 페이지

문제 해결 - 계획
계획은 목표 달성을 위한 방법과 절차를 결정하는 과정으로, 개인적 목록 작성부터 국가적 자원 사용, 토지 이용 규제 등 다양한 형태로 나타나며, 상위-하향식, 하위-상향식, PDCA 사이클 등의 방법론을 활용하여 명확한 목표 설정, 효율적인 자원 관리, 위험 관리, 유연성을 필요로 한다.
문제 해결 - 시행착오
시행착오는 문제 해결을 위해 다양한 시도를 반복하며 실패를 통해 학습하는 과정으로, 계층적인 구조로 확장되어 문제 해결 능력을 향상시키고, 신약 개발, 유전 알고리즘, 생물학적 진화 등 다양한 분야에서 활용되는 해결책 중심적인 학습 전략이다.

트러블슈팅
개요
분야	문제 해결
하위 분야	고장 분석 오류 수정 시스템 복구
문제 해결 단계
정보 수집	문제의 증상, 환경, 영향을 파악함
문제 정의	수집된 정보를 바탕으로 문제의 원인을 특정함
가능한 해결책 식별	문제의 원인을 해결할 수 있는 다양한 방법을 모색함
해결책 평가 및 선택	각 해결책의 장단점을 분석하여 최적의 방법을 선택함
해결책 구현	선택된 해결책을 실제로 적용함
결과 평가	구현된 해결책이 문제를 해결했는지 확인하고, 필요에 따라 추가적인 조치를 취함
문제 해결 전략
문제 분할	복잡한 문제를 더 작고 관리하기 쉬운 하위 문제로 나눔
원인 파악	문제의 근본적인 원인을 찾기 위해 노력함
시행 착오	다양한 해결책을 시도하면서 문제 해결에 접근함
패턴 인식	과거의 경험이나 유사한 사례를 바탕으로 문제 해결에 적용함
가설 검증	문제에 대한 가설을 세우고, 증거를 통해 가설의 타당성을 검증함
문제 해결 도구
소프트웨어 도구	디버거 시스템 모니터 네트워크 분석기
하드웨어 도구	멀티미터 오실로스코프 논리 분석기

2. 진단

일반적으로 문제 해결의 첫 단계는 문제의 진단이다. 문제는 처음에는 오작동의 증상으로 묘사되며, 문제 해결은 이러한 증상의 원인을 결정하고 해결하는 과정이다.^[1] 문제 해결 진단을 수행하는 데 필요한 두 가지 주요 요소는 사전 도메인 지식과 검색 전략이다.^[1] 라스무센^[2]은 장치의 올바른 기능의 특성(지형 전략)에 의해 안내되는 전략과 비정상적인 기능의 특성(증상 전략)에 의해 안내되는 전략이 있다고 제안했다. 두 번째는 실제로 "무엇이 잘못되었는가?"를 묻고 첫 번째는 "무슨 일이 일어나고 있는가?"를 묻는 것이다.

전략은 목표 달성을 위한 그럴듯한 방법을 표현하는 조직화된 활동 집합이다. 전략은 솔루션에 대해 유연하지 않게 따라야 하는 알고리즘으로 간주해서는 안 된다. 문제 해결사는 기회주의적으로 행동하며 전략 내에서 활동을 조정하고 정보와 아이디어에 따라 전략과 전술을 변경한다.^[3]

== 증상 기반 진단 (사례 기반 추론) ==

전문가들은 과거의 경험을 바탕으로 증상과 원인 간의 연관성을 빠르게 파악한다.^[4] 이는 '사례 기반 추론' 또는 '얕은 추론'이라고도 불리며, 숙련된 전문가에게서 주로 나타나는 문제 해결 방식이다.^[4] 전문가는 이전에 유사한 사례를 겪었기 때문에 증상을 통해 문제의 원인을 빠르게 인식할수 있다.^[4] 사례 기반 추론은 가장 강력하고 일반적으로 사용되는 문제해결 전략이다. 하지만, 이 전략은 새로운 문제나 발생하는 모든 문제에 대한 더 깊은 이해가 필요한 경우에는 독립적으로 작동하지 않는다.^[4] 이러한 경우에는 지형 전략과 같은 다른 문제 해결 전략과 함께 사용해야 한다.^[8]

== 지형 기반 진단 (심층 추론) ==

지형 기반 진단은 시스템 구성 요소 간의 관계를 분석하여 문제의 원인을 파악하는 방식이다.^[5] '심층 추론' 또는 '제1원리 추론'이라고도 불리며,^[6] 경험 기반 접근 방식이 실효성이 없을 때, 새로운 결함에 적용된다.^[7] 이는 시스템에 대한 심층적인 지식을 활용하며, 요소 간의 관계를 보여주는 구조화된 엔티티에 대한 설명이나 분석을 포함한다.^[5]

지형 전략은 제1원리 지식을 사용하여 시스템에 대한 보다 근본적인 이해를 바탕으로 사전 도메인 지식과 연결된다. 이러한 지식은 깊고, 인과적이거나 모델 기반 지식이라고 불린다.^[7] 증상적 접근 방식이 지형적 접근 방식에 의해 지원될 필요가 있으며, 그 반대도 마찬가지이다.^[8] 얕은 추론은 지형적 검색에서 인과적 가설을 생성하기 위해 유추적으로 사용될 수 있으며, 이러한 가설을 평가하기 위해 연역적으로 사용될 수 있다.

2. 1. 증상 기반 진단 (사례 기반 추론)

전문가들은 과거의 경험을 바탕으로 증상과 원인 간의 연관성을 빠르게 파악한다. 이는 '사례 기반 추론' 또는 '얕은 추론'이라고도 불리며, 숙련된 전문가에게서 주로 나타나는 문제 해결 방식이다. 전문가는 이전에 유사한 사례를 겪었기 때문에 증상을 통해 문제의 원인을 빠르게 인식할수 있다. 사례 기반 추론은 가장 강력하고 일반적으로 사용되는 문제해결 전략이다. 하지만, 이 전략은 새로운 문제나 발생하는 모든 문제에 대한 더 깊은 이해가 필요한 경우에는 독립적으로 작동하지 않는다. 이러한 경우에는 지형 전략과 같은 다른 문제 해결 전략과 함께 사용해야 한다.

2. 2. 지형 기반 진단 (심층 추론)

지형 기반 진단은 시스템 구성 요소 간의 관계를 분석하여 문제의 원인을 파악하는 방식이다. '심층 추론' 또는 '제1원리 추론'이라고도 불리며, 경험 기반 접근 방식이 실효성이 없을 때, 새로운 결함에 적용된다. 이는 시스템에 대한 심층적인 지식을 활용하며, 요소 간의 관계를 보여주는 구조화된 엔티티에 대한 설명이나 분석을 포함한다.

지형 전략은 제1원리 지식을 사용하여 시스템에 대한 보다 근본적인 이해를 바탕으로 사전 도메인 지식과 연결된다. 이러한 지식은 깊고, 인과적이거나 모델 기반 지식이라고 불린다. 증상적 접근 방식이 지형적 접근 방식에 의해 지원될 필요가 있으며, 그 반대도 마찬가지이다. 얕은 추론은 지형적 검색에서 인과적 가설을 생성하기 위해 유추적으로 사용될 수 있으며, 이러한 가설을 평가하기 위해 연역적으로 사용될 수 있다.

3. 문제 해결의 원칙과 접근법

문제 해결의 첫 번째 기본 원칙은 원할 때 문제를 재현할 수 있어야 한다는 것이다.^[9]^[10] 문제 해결의 핵심 원칙 중 하나는 재현 가능한 문제는 확실하게 격리하고 해결할 수 있다는 것이다. 종종 문제 해결에서는 재현성, 즉 증상이 확실하게 나타나도록 유도하는 절차를 찾는 데 상당한 노력과 중점을 둔다.

일반적으로 문제 해결은 이전에 작동하던 상태가 계속적인 작동에 대한 기대를 형성하기 때문에 갑자기 작동을 멈춘 대상에 적용된다. 따라서 초기 초점은 종종 시스템이나 시스템이 존재하는 환경에 대한 최근 변경 사항에 맞춰진다. (예를 들어, "거기에 꽂혀 있을 때는 작동"하던 프린터). 그러나, 상관 관계가 인과 관계를 의미하지 않는다는 잘 알려진 원칙이 있다. 따라서, 문제 해결은 마법적 사고보다는 비판적 사고를 요구한다.

문제 해결의 기본 원칙은, 가장 단순하고 확률이 높은 원인부터 검토를 시작하는 것이다. 이것은 "발자국을 발견하면, 먼저 얼룩말이 아닌 말을 찾아라"라는 격언이나 KISS 원칙으로 표현된다.

문제 해결의 두 번째 기본 원칙은 문제를 여전히 보여주는 가장 간단한 형태로 "시스템"을 줄이는 것이다.

문제 해결의 세 번째 기본 원칙은 "무엇을 찾고 있는지 아는 것"이다. 즉, 시스템이 작동해야 하는 방식을 완전히 이해하여 오류가 발생했을 때 "발견"할 수 있다.

문제 해결사는 시스템의 각 구성 요소를 하나씩 확인하여 의심되는 각 구성 요소에 대해 알려진 양호한 구성 요소를 대체할 수 있다. 그러나 이 "직렬 대체" 프로세스는 고장으로 인해 진단되는 증상이 어떻게 발생할 수 있는지에 대한 가설을 고려하지 않고 구성 요소를 대체할 때 변질된 것으로 간주될 수 있다.

단순 및 중간 시스템은 구성 요소 또는 하위 시스템 간의 종속성 목록 또는 트리로 특징지어집니다. 더 복잡한 시스템에는 주기적인 종속성 또는 상호 작용 (피드백 루프)이 포함되어 있다. 이러한 시스템은 "이분" 문제 해결 기술에 덜 적합하다.

또한 알려진 양호한 상태에서 시작하는 것이 도움이 되며, 가장 좋은 예는 컴퓨터 재부팅이다. 인지적 워크스루를 시도하는 것도 좋은 방법이다. 능숙한 기술 작가가 제작한 포괄적인 문서는 특히 주제 장치 또는 시스템에 대한 작동 이론을 제공하는 경우 매우 도움이 된다.

문제의 일반적인 원인은 나쁜 설계로, 예를 들어 적절한 강제 기능(행동 형성 제약)의 부재 또는 오류 허용 설계의 부재로 인해 장치를 거꾸로 또는 뒤집어 넣을 수 있는 나쁜 인간 요소 설계이다.

문제를 해결하기 위해서는 정확한 사실을 파악하고, 문제의 근원을 논리적이고 체계적으로 탐구할 필요가 있으며, 순서대로 해결해 나가는 것이 일반적이다. 트러블슈팅은 문제의 원인을 식별하기 위해 사용된다. 원인으로 생각되는 가장 가능성이 높은 것을 소거법으로 찾아내어, 이를 제거하고 정상적인 상태로 되돌리는 방법이다. 미리 예상된 문제에 대해 해결 방법이 매뉴얼화된 것을 가리키는 경우가 많다^[15]。

예를 들어, 지금까지 작동하던 것이 갑자기 멈춰버린 문제를 생각해 보자. 이 경우, 우선 첫 번째로, 작동하던 때와 멈춘 때에 무엇이 달라졌는지 주목해야 한다.

컴퓨터에서의 트러블슈팅 기법으로 예를 들어,

기기에 올바른 결선 및 사용 환경, 조작을 실시하여 동작을 확인한다(전원을 켠다).
컴퓨터의 리부트 또는 백업으로부터의 리스트어, 또는 복구를 하여 정상적인 상태로 되돌려 정상적으로 기동 가능한지 시도한다.
연속적으로 연결된 기기에 대해서는, 가까운 곳부터 먼저 시도하고, 문제가 없으면 더욱 멀리 있는 기기를 시도한다.(상류에서 하류로)
기기의 동작에 필요한 최소한의 부품 및 기기만을 연결하여 동작을 확인한다(최소 구성).
소프트웨어의 설정 내용을 파악하고 있는 경우, 설정을 일단 기본값으로 하거나, 재설치를 시도한다.

등을 실행하여, 원인을 특정하는 기법을 생각할 수 있다.

트러블슈팅에서는, 체계적인 체크리스트, 절차, 플로우차트나 표가 사전에 준비되어 사용되는 경우도 있다. 트러블슈팅 절차 개발을 사전에 수행함으로써, 효율적인 문제 대처가 가능해진다.

3. 1. 문제 재현

문제 해결의 핵심 원칙 중 하나는 재현 가능한 문제는 확실하게 격리하고 해결할 수 있다는 것이다. 종종 문제 해결에서는 재현성, 즉 증상이 확실하게 나타나도록 유도하는 절차를 찾는 데 상당한 노력과 중점을 둔다.

3. 2. 시스템 단순화

3. 3. 이분법 (Half-splitting)

효율적이고 체계적인 문제 해결은 시스템의 예상 동작과 관찰되는 증상에 대한 명확한 이해에서 시작된다. 문제 해결사는 잠재적인 원인에 대한 가설을 세우고, 이러한 예상 원인을 제거하기 위한 테스트를 고안하거나 표준화된 체크리스트를 참조한다.^[11] 이 접근 방식은 종종 "분할 정복"이라고 불린다.

문제 해결사가 사용하는 두 가지 일반적인 전략은 먼저 자주 발생하는 또는 쉽게 테스트할 수 있는 조건을 확인하는 것이다. 예를 들어 프린터의 표시등이 켜져 있고 케이블이 양쪽 끝에 단단히 연결되어 있는지 확인 하는것과 같다. 이는 종종 "전면 패널 확인"이라고 불린다.^[11]

그 다음 시스템을 "이등분"한다. 예를 들어 네트워크 인쇄 시스템에서 작업이 서버에 도달했는지 확인하여 문제의 존재 여부를 사용자 "쪽" 서브 시스템 또는 장치 "쪽" 서브 시스템에서 확인 하는것과 같다. 이 기술은 일련의 종속성 또는 구성 요소 간의 상호 작용이 긴 시스템에서 특히 효율적일 수 있다. 이는 단순히 종속성 범위를 가로지르는 이진 탐색의 적용이며 종종 "반분"이라고 한다.^[12] 이는 "스무고개" 게임과 유사하다. 누구나 대안 세트를 20번 나누어 백만 개 중 하나의 옵션을 격리할 수 있다.(2^10 = 1024이고 2^20 = 1,048,576이기 때문)

3. 4. 다중 문제 고려

재현 가능한 증상을 보이는 단일 구성 요소의 고장을 찾아내는 것은 비교적 쉽다.

하지만, 여러 문제는 다양한 고장 또는 오류로 인해 발생한다. 특히 결함 허용 시스템이나 내장된 중복성을 가진 시스템의 경우에는 더욱 그렇다. 중복성, 결함 감지 및 페일오버 기능도 고장의 대상이 될 수 있으며, 모든 시스템에서 충분히 다른 구성 요소에 고장이 발생하면 시스템은 "다운"된다.

단순한 시스템에서도 문제 해결자는 항상 둘 이상의 결함이 있을 가능성을 고려해야 한다. 직렬 대체 방법을 사용하여 각 구성 요소를 교체하고, 증상이 지속되는 것을 발견하면 각 새 구성 요소를 다시 이전 구성 요소로 교체하는 것은 이러한 경우를 해결하지 못할 수 있다. 더 중요한 것은, 결함이 있는 구성 요소로 교체하면 실제로 문제를 제거하기보다는 문제를 늘릴 수 있다는 것이다.

"구성 요소 교체"라고 하지만, 많은 문제의 해결은 "교체"보다는 조정이나 튜닝을 포함한다. 예를 들어, 도체의 간헐적인 단선, 혹은 "더럽거나 헐거운 접촉"은 단순히 청소하거나 조여야 할 수 있다. 따라서 "교체"에 대한 모든 논의는 "교체 또는 조정 또는 기타 수정"을 의미하는 것으로 간주해야 한다.

4. 문제 해결 전략 및 도구

일반적으로 문제 해결은 이전에 작동하던 것이 갑자기 멈춘 경우에 적용된다. 이 경우, 우선 작동하던 때와 멈춘 때에 무엇이 달라졌는지 주목해야 한다.^[15] 그러나, 어떤 변화가 있었다고 해도, 거기에 인과 관계가 있다고 성급하게 판단해서는 안 된다. 일반적으로 상관 관계와 인과 관계는 같지 않다.

문제 해결의 기본 원칙은, 가장 단순하고 확률이 높은 원인부터 검토를 시작하는 것이다. 이것은 "발자국을 발견하면, 먼저 얼룩말이 아닌 말을 찾아라"라는 격언이나 KISS 원칙으로 표현된다.

다음으로, 구성 요소들을 하나씩 조사해 가며, 의심스러운 것이 있으면 해당 부품을 교체해 본다. 인지 워크스루도 시도해 볼 가치가 있는 방법이다. 또한, 특정 기기나 시스템에 대해 자세히 설명된 문서가 있다면, 매우 도움이 될 것이다.

컴퓨터에서의 트러블슈팅 기법으로 예를 들어,

기기에 올바른 결선 및 사용 환경, 조작을 실시하여 동작을 확인한다(전원을 켠다).
컴퓨터의 리부트 또는 백업으로부터의 리스트어, 또는 복구를 하여 정상적인 상태로 되돌려 정상적으로 기동 가능한지 시도한다.
연속적으로 연결된 기기에 대해서는, 가까운 곳부터 먼저 시도하고, 문제가 없으면 더욱 멀리 있는 기기를 시도한다.(상류에서 하류로)
기기의 동작에 필요한 최소한의 부품 및 기기만을 연결하여 동작을 확인한다(최소 구성).
소프트웨어의 설정 내용을 파악하고 있는 경우, 설정을 일단 기본값으로 하거나, 재설치를 시도한다.

등을 실행하여, 원인을 특정하는 기법을 생각할 수 있다.

그러나 이용 상황에 따라서는 즉시 문제 해결을 위한 기법을 실행할 수 없는 경우가 있으며, 가급적 리스크를 감수하지 않는 구체적인 방책이 요구되는 경우가 있다.(네트워크 기기, 서버 등)

문제의 원인으로 흔히 있는 것은 설계의 부실이다. 예를 들어, 기기를 거꾸로 연결하거나, 카드를 거꾸로 삽입하는 등의 문제에서는, 실수를 하기 어렵게 만드는 인간공학 설계가 부족하다고 생각할 수 있다. 또한, 외래어로 가득한 매뉴얼은 읽기 어렵고 이해하기 어려우며 기억하기 어려우므로, 대부분의 일본인이 한 번도 매뉴얼을 읽지 않고 기기를 사용하는 것도 문제의 큰 원인이 되고 있다. 다른 원인으로는 장애로 인한 불량이나 고장도 있다.

트러블슈팅에서는, 체계적인 체크리스트, 절차, 플로우차트나 표가 사전에 준비되어 사용되는 경우도 있다.^[15] 트러블슈팅 절차 개발을 사전에 수행함으로써, 효율적인 문제 대처가 가능해진다.

4. 1. 체크리스트 및 절차

일반적으로 문제 해결은 이전에 작동하던 대상이 갑자기 작동을 멈춘 경우에 적용된다.^[9]^[10] 초기에는 시스템이나 환경에 대한 최근 변경 사항에 초점을 맞추지만, 상관 관계가 인과 관계를 의미하지 않으므로 비판적 사고가 필요하다.^[9]^[10]

문제 해결의 기본 원칙은 다음과 같다:

문제를 재현할 수 있어야 한다.
문제를 보이는 가장 간단한 형태로 시스템을 축소해야 한다.
시스템 작동 방식을 완전히 이해하여 오류를 발견할 수 있어야 한다.

문제 해결사는 시스템의 각 구성 요소를 하나씩 확인하고, 의심되는 구성 요소를 알려진 양호한 구성 요소로 대체할 수 있다. 단순 및 중간 시스템은 구성 요소 간의 종속성 목록이나 트리로 특징지을 수 있지만, 더 복잡한 시스템은 주기적인 종속성이나 상호 작용(피드백 루프)을 포함하여 이분법적 문제 해결 기술에 덜 적합하다.

문제 해결에는 알려진 양호한 상태에서 시작하는 것(예: 컴퓨터 재부팅)과 인지적 워크스루를 시도하는 것이 도움이 된다. 또한, 포괄적인 문서는 작동 이론을 제공하는 경우 특히 유용하다.

문제의 일반적인 원인은 나쁜 설계나 인간 요소 설계이다. 예를 들어, 적절한 강제 기능(행동 형성 제약)이 없거나 오류 허용 설계가 부족한 경우가 있다.

문제 해결은 체계적인 체크리스트, 문제 해결 절차, 흐름도 또는 표 형태를 취할 수 있다. 이러한 절차를 미리 개발하면 문제 해결을 효율적으로 구성할 수 있다. 전산화된 문제 해결 서비스는 상위 솔루션을 보여주고, 기술자는 추가 질문에 답하여 솔루션 목록을 좁힐 수 있다.

4. 2. 전산화된 문제 해결 서비스

일부 전산화된 문제 해결 서비스는 기본 문제를 해결할 가능성이 가장 높은 상위 10가지 해결책을 즉시 제시한다.^[9]^[10] 기술자는 문제 해결 절차를 진행하기 위해 추가 질문에 답하고, 각 단계에서 해결책 목록을 좁히거나 문제를 해결할 것이라고 생각되는 해결책을 즉시 구현할 수 있다.^[9]^[10] 이러한 서비스는 기술자가 문제 해결 후 추가 단계를 수행하여 실제로 문제를 해결한 솔루션을 보고하면 리베이트를 제공하기도 한다.^[9]^[10] 컴퓨터는 이러한 보고서를 바탕으로 특정 증상 집합을 해결할 가능성이 높은 솔루션에 대한 추정치를 갱신한다.^[9]^[10]

4. 3. 인지 워크스루 (Cognitive Walkthrough)

인지 워크스루는 사용자의 관점에서 시스템을 단계별로 검토하며 잠재적인 문제점을 발견하는 방법이다.^[9]^[10] 이는 사용자가 시스템을 어떻게 사용하는지, 그리고 그 과정에서 어떤 어려움에 직면할 수 있는지를 이해하는 데 도움이 된다. 능숙한 기술 작가가 제작한 포괄적인 문서는 특히 주제 장치 또는 시스템에 대한 작동 이론을 제공하는 경우 인지 워크스루에 매우 도움이 될 수 있다.

4. 4. 최소 구성

4. 5. 기본값 설정 및 재설치

5. 간헐적 문제

가장 어려운 문제 해결 문제 중 일부는 간헐적으로 발생하는 증상과 관련이 있다. 전자 제품에서 이는 종종 열에 민감한 구성 요소의 결과이다.(회로의 저항은 회로 내 도체의 온도에 따라 다르기 때문이다). 압축 공기를 사용하여 회로 기판의 특정 지점을 냉각할 수 있으며, 히트 건을 사용하여 온도를 높일 수 있다. 따라서 전자 시스템의 문제 해결은 종종 이러한 도구를 사용하여 문제를 재현하는 것을 수반한다.^[13]

컴퓨터 프로그래밍에서 경합 조건은 종종 재현하기가 극도로 어려운 간헐적 증상으로 이어진다. 다양한 기술을 사용하여 특정 기능 또는 모듈이 정상 작동보다 더 빠르게 호출되도록 강제할 수 있으며(하드웨어 회로에서 구성 요소를 "가열"하는 것과 유사) 다른 기술을 사용하여 다른 모듈 또는 상호 작용 프로세스 내에서 더 큰 지연을 도입하거나 동기화를 강제할 수 있다.

간헐적인 문제는 다음과 같이 정의할 수 있다.

:간헐적 문제는 증상을 일관되게 재현하기 위한 알려진 절차가 없는 문제입니다.^[13]

특히 그는 발생 빈도와 문제의 "일관되게 재현하기 위한 알려진 절차" 사이에 구별이 있다고 주장한다. 예를 들어, 간헐적 문제가 특정 자극 또는 이벤트 '''"내"'''에 발생한다는 것을 아는 것... 그러나 때로는 5분 안에 발생하고 다른 때는 거의 1시간이 걸리지만... 자극이 관찰 가능한 증상 발생 빈도를 증가시키더라도 "알려진 절차"를 구성하지 않는다.

그럼에도 불구하고 문제 해결사는 때때로 통계적 방법에 의존해야 하며... 일련의 대체 또는 다른 기술이 실행 가능한 지점까지 증상 발생을 증가시키는 절차만 찾을 수 있다. 이러한 경우 증상이 훨씬 더 오랫동안 사라지는 것처럼 보일 때조차도 근본 원인이 발견되었고 문제가 실제로 해결되었다는 낮은 신뢰도가 있다.

또한, 특정 구성 요소가 고장났는지 확인하기 위해 해당 구성 요소에 스트레스를 주기 위한 테스트를 실행할 수 있다.^[14]

5. 1. 정의

간헐적 문제는 증상을 일관되게 재현하기 위한 명확한 절차가 없는 문제로 정의할 수 있다.^[13] 간헐적 문제는 특정 자극이나 이벤트 발생 후 나타나기도 하지만, 발생 빈도가 일정하지 않아 문제 해결을 어렵게 만든다.

전자 제품에서 간헐적 문제는 주로 열에 민감한 구성 요소 때문에 발생한다.^[14] 회로의 저항은 도체의 온도에 따라 달라지기 때문이다. 이러한 문제는 압축 공기나 히트 건을 사용하여 특정 지점을 냉각 또는 가열하여 재현을 시도해 볼 수 있다.

컴퓨터 프로그래밍에서 경합 조건은 재현하기 매우 어려운 간헐적 증상을 유발하는 대표적인 예시이다.

5. 2. 접근 방식

가장 어려운 문제 해결은 간헐적으로 발생하는 증상과 관련이 있는데, 이는 전자 제품에서 종종 열에 민감한 구성 요소 때문에 발생한다.^[13] 압축 공기나 히트 건을 사용하여 특정 지점을 냉각 또는 가열하여 문제를 재현할 수 있다. 컴퓨터 프로그래밍에서 경합 조건은 재현하기 어려운 간헐적 증상을 유발한다. 특정 기능 호출을 빠르게 하거나, 다른 모듈에 지연을 도입하거나, 동기화를 강제하는 기술을 사용할 수 있다.

간헐적 문제는 "증상을 일관되게 재현하기 위한 알려진 절차가 없는 문제"로 정의할 수 있다.^[13] 문제 해결사는 통계적 방법에 의존하거나, 증상 발생 빈도를 높이는 절차를 찾기도 한다. 이 경우 근본 원인이 발견되어 문제가 해결되었다는 신뢰도가 낮다.^[13]

또한, 특정 구성 요소에 스트레스를 주어 고장 여부를 확인하는 테스트를 실행할 수 있다.^[14]

6. 기타

6. 1. 설계 문제

6. 2. 문서화의 중요성

참조

_[1] 논문 A review of process fault detection and diagnosis: Part II: Qualitative models and search strategies 2003
_[2] 서적 Information processing and human-machine interaction. An approach to cognitive engineering North-Holland 1987
_[3] 논문 Complex problem solving in electronics 1991
_[4] 논문 Cognitive psychology and medical diagnosis 1990
_[5] 서적 American Heritage Dictionary
_[6] 논문 Reasoning from first principles in electronic troubleshooting 1983
_[7] 논문 Strategies for diagnosis 1987
_[8] 논문 A method to describe human diagnostic strategies in relation to the design of human-machine cooperation 2000
_[9] 간행물 Troubleshooting at your fingertips Electronics Servicing and Technology magazine 1982-06
_[10] 간행물 Issues of Fault Diagnosis for Dynamic Systems
_[11] 웹사이트 Hewlett Packard Bench Briefs http://www.hparchive[...] Hewlett Packard 2011-10-14
_[12] 뉴스 Secrets of a super geek: Use half splitting to solve difficult problems http://www.techrepub[...] 2000-11-15
_[13] 웹사이트 December 98 Troubleshooting Professional Magazine: Intermittents http://www.troublesh[...] 2020-10-14
_[14] 웹사이트 How to Troubleshoot a Computer Problem – joyojc.com http://joyojc.com/20[...] 2018-04-09
_[15] 웹사이트 トラブルシューティング http://www.sophia-it[...]
_[16] 간행물 Troubleshooting at your fingertips Electronics Servicing and Technology magazine 1982-06
_[17] 간행물 Issues of Fault Diagnosis for Dynamic Systems

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com