근본 원인 분석: 결함을 빠르게 해결하는 4가지 팁

상상해 보세요. 소프트웨어 제품의 다음 메이저 버전을 마무리 하기 위해 팀 전체가 바쁘게 일하고 있습니다. 새로운 기능을 꽤 빠른 속도로 만들고 있습니다. 팀은 QA에서 보고한 버그를 수정합니다. 단위 테스트는 모두 정상입니다. 보다 포괄적인 테스트 모음에서 애플리케이션에 녹색 등이 켜지고 이제 출고할 시간이 되었습니다. 그런데 갑자기! 프로덕션 환경으로 전환하자마자 앱이 크게 충돌합니다. 무엇이 잘못되었을까요?

테스트 환경이 프로덕션 환경과 생각만큼 가깝지 않았던 것으로 밝혀집니다. 인프라 변경은 어떤 종류의 레코드도 없이 환경에 적용되었습니다. 그 결과 환경은 천천히 달라지게 되었습니다.

기술 업계에 종사하는 사람들은 상당 부분의 시간을 결함을 해결하는 데 씁니다. 그리고 결함을 해결하는 데도 많은 시간을 씁니다. 그러나 잘못된 것이 무엇인지 모르면 해결할 수 없습니다. 디버거 앞에서 몇 시간을 쓰는 모든 소프트웨어 개발자는 대부분, 실제로 힘든 부분은 버그를 찾는 데 있다고 말합니다. 문제가 무엇인지 알기만 하면 해결은 오히려 간단할 수 있습니다.

소프트웨어 개발자 또는 IT 작업자가 할 수 있는 가장 좋은 투자 중 하나는 문제를 빠르게 해결하는 방법을 배우는 것입니다.

문제를 빠르게 찾고 더 빠르게 해결하는 방법에 대해 알아봅시다.

근본 원인 분석: 정의 및 중요한 이유

근본 원인 분석(RCA)은 문제 해결에 사용할 수 있는 특정 기술입니다. 이 기술을 사용할 때는 특정 단계를 사용하여 현재의 문제를 분석하고 문제의 주요 원인을 식별합니다. RCA의 기본적인 원칙은 문제의 근원을 무시하면서 증상을 완화하는 작업은 소용이 없다는 것입니다.

RCA를 사용하면 상황을 이해할 수 있습니다. 증상만 관찰하면 전체 그림을 보지 못할 수 있습니다. 그러나 상황 파악은 첫 번째 단계에 불과합니다. 그 다음에는 더 들어가서 상황이 발생한 이유를 드러내야 합니다. 그 지식을 확보한 후에는 재발 확률을 낮추는 계획 또는 전략을 만들어 실제로 적용할 수 있습니다.

이제 ‘정의’와 ‘이유’를 알았으니 RCA를 사용하여 문제를 줄이는 데 도움이 되는 4가지 팁을 살펴봅시다.

고무 오리 접근 방식 사용
이상하게 들릴 수 있지만 고무 오리 접근 방식이라는 것이 있습니다. 고무 오리를 만들지는 않습니다. 고무 오리 디버깅이라고도 하는데 아마 더 많은 이름이 있을 것입니다. 이 방법은 고무 오리에게 문제를 설명하는 것으로 구성됩니다. 고무 오리가 없으신가요? 걱정하지 마세요. 손 닿는 곳에 있는 모든 무생물을 사용할 수 있습니다. 아니면 사람을 상대로 말해도 됩니다!

그렇다면 고무 오리 접근 방식은 실제로 무엇에 대한 것일까요? 이 접근 방식의 기반은 관찰된 효과입니다. 어떤 사람에게 무언가를 설명하면서 강제로 생각을 정리하는 것입니다. 인간의 사고 프로세스는 혼란스럽거나 어지러운 경우가 많습니다. 누군가에게 설명할 일이 생기면 어떻게든 생각을 정리해야 합니다. 유명한 Q&A 사이트인 Stack Overflow의 공동 창립자 Jeff Atwood는 소프트웨어 개발자가 사이트에 새 질문을 올리는 과정에서 직접 답을 찾아 결국 실제로는 질문을 한 번도 올리지 않는 사례가 많다고 말합니다.

고무 오리 접근 방식은 모든 문제를 해결하는 데 충분할까요? 당연히 아닙니다. 그럴 수도 있지만 더 넓은 전략의 첫 번째 단계일 뿐인 경우가 많습니다.

무생물과 대화하는 것을 다른 사람들이 이상하게 볼까 걱정되시나요? 사실, 이 고무 오리 아이디어는 농담과 같은 것입니다. 누구나 기억할 만한 유치한 모형을 예로 든 것이니 너무 진지하게 받아들이지는 마세요. 중요한 것은 머리 속의 생각을 질서 있게 표현하여 문제를 가능한 분명하게 설명하는 데 있습니다.

다음 접근 방식을 사용할 수 있습니다.
1. Stack Overflow 질문을 작성합니다. 아니면 Stack Overflow 질문을 작성하는 척하면서 메모장에 작성해도 됩니다.
2. 상세한 버그 보고서를 제출합니다. 어차피 누군가 해야 하는 일이니 시작한 김에 하는 것이 좋습니다.
3. 동료 직원의 자리로 가서 몇 분간 이야기합니다. 물론, 동료의 승낙을 얻는 것이 먼저입니다. 쓸데없이 방해하지는 마시기 바랍니다.


다량의 로그 데이터 수집(그리고 효율적으로 조사)

확실한 방법으로 문제를 성공적으로 설명했음에도 불구하고 근본 원인을 알 수 없다면 더 들어가야 합니다. 이제 필요한 일은 문제에 대한 데이터를 수집하고 거기에서 인사이트를 추출하는 것입니다.

이때 로깅 및 모니터링이 유용할 수 있습니다. 충돌 로그, 애플리케이션 및 서버 로그와 가지고 있는 로그를 사용합니다. 문제가 발생했다는 증거를 수집해야 합니다. 또한 가능하면 발생한 기간과 빈도를 찾아야 합니다.

여기서 멈추면 안 됩니다. 많은 데이터를 수집하는 것도 중요하지만 필요한 특정 조각을 충분히 빠르게 찾을 수 없다면 모든 데이터가 무용지물이 됩니다. ‘모래 속에서 진주를 찾는’ 상황에 빠지면 재미도 없고 생산적이지도 않습니다.

수집한 모든 로그 데이터를 실시간으로 검색하고 분석한 후 문제의 신속한 진단 및 해결에 유용한 인사이트로 전환하는 도구를 사용해야 하는 이유가 여기에 있습니다.


5개의 ‘왜’ 기법 사용
정보를 수집한 후에는 유발 요인을 식별하는 방법으로 정보를 사용해야 합니다. 여기서 ‘유발 요인’은 문제의 직접적인 원인을 의미합니다. 유발 요인 1개를 식별한 후 멈추면 안 됩니다. 더 들어가야 합니다. 여기에 가장 많이 사용되는 기법 중 하나가 5개의 ‘왜’ 기법입니다.

이 기법에서는 문제의 근원에 도달할 때까지 ‘왜?’라고 반복적으로 질문합니다. 간단한 예제를 살펴봅시다.

문제: 웹 사이트에 오류 500이 표시됩니다.
1. 왜 그럴까요? 웹 프레임워크의 라우팅 구성 요소에 작동 오류가 있습니다.
2. 왜 그럴까요? 다른 구성 요소가 필요한데 그 자체에 작동 오류가 있습니다.
3. 왜 그럴까요? 웹 프레임워크의 이 구성 요소에는 intl 확장자가 필요한데 이 확장자가 작동하지 않습니다.
4. 왜 그럴까요? 서버 소프트웨어를 업데이트한 후 실수로 비활성화되었습니다.

보시다시피 5라는 숫자는 설명을 위한 것입니다. 더 적은 단계로 근본 문제에 도달할 수 있습니다. 아니면 더 많은 단계가 필요할 수도 있습니다.

5개의 ‘왜’ 기법은 완벽하지 않습니다. 비판도 받았고 한계가 있는 것도 맞습니다. 하지만 해결책에 가까워지는 첫 번째 징후에서 멈추는 대신 문제의 근본 원인에 대한 조사를 장려하는 측면에서는 유용할 수 있습니다.


두 번째 눈
제가 소프트웨어 개발자로 일하면서 진가를 인정하는 작업 방식 중 하나는 코드 검토입니다. 편견이 없는 다른 사람에게 코드를 보여주면 이전에는 찾지 못한 아주 많은 문제가 드러날 수 있다는 놀랍고도 단순한 사실이 있습니다. 시간이 지나면, 다른 사람이 코드를 볼 것이라는 예상만으로도 코드에 더 신경을 쓰게 됩니다. 오히려 더 많은 주의를 기울이게 됩니다.

그렇다면 코드 검토를 수행하는 것이 좋을까요? 예. 하지만 코드 검토가 두 번째 눈을 얻는 유일한 방법은 아닙니다. 엔지니어가 수행하는 거의 모든 태스크에 검토와 유사한 프로세스를 사용할 것을 제안합니다. 쌍으로 하면 더 좋습니다. 페어 프로그래밍, 페어 서버 구성, 피어 디버깅 및 동종 고객 지원을 수행하세요. 짧게 말해, 문제 해결을 쌍으로 수행하는 것입니다.

과학과 예술의 경계

결함 해결은 과학보다 예술에 가까운 단계에 있습니다. 그렇다고 해서 효율성을 개선하는 기술 및 도구의 사용을 멈춰서는 안 됩니다.

그러니 RCA를 수행할 때는 이러한 도구를 사용하세요.
1. 고무 오리 접근 방식 사용
2. 다량의 로그 데이터를 수집하고 적절한 도구를 사용하여 검색하고 분석
3. 5개의 ‘왜’ 기법 사용
4. 두 번째 눈

이제 고무 오리를 잡고 문제의 근본 원인 분석을 시작해 보세요.

Amazon OpenSearch Service 요금에 대해 자세히 알아보기

요금 페이지로 이동하기
구축할 준비가 되셨습니까?
Amazon OpenSearch Service 시작하기
추가 질문이 있으십니까?
문의하기