No.22 효율적인 업무를 위한 고민, RCA(Root Cause Analysis)

회사에서 업무볼 때, 고민들 많이 하시죠? 왜 이건 또 오류가 날까, 이렇게 하면 어떤 결과가 나올까, 등등 뭐 다양한 고민과 생각들로 가득하실거라 생각합니다. 왜냐면 제가 그러니까요. 그냥 아무 생각없이 수동적으로 업무를 진행한다면, 성과도 내지 못할 뿐더러 성과를 내기 위한 동기부여도 되지 않을 것입니다. 

 

그래서 오늘은 사고의 한 방식인 'RCA(Root Cause Analysis)'라는 근본원인분석 틀에 간단하게 얘기해보려고 합니다. 제가 회사생활 하면서 전환점?이라고 하면 좀 거창하지만 나름 뭔가 사고를 하는 방식을 바꾸게 된 계기가 있는데, 그게 바로 예전 팀장님에게 개인적으로 이 RCA에 대한 조언을 받고나서 부터 입니다. 사실 제가 뭐 이런 이론에 대한 전문가는 아니기 때문에 간단히 해당 내용의 정의와 프로세스를 요약해보고, 제가 업무적으로 접근시켰던 방식을 사례로 말씀드리고자 합니다.

 

 

1. RCA란(Root Cause Analysis)?

- 우선 위키백과에서 나온 사전적 정의를 토대로 먼저 말씀드리면,,,

: In science and engineering, root cause analysis (RCA) is a method of problem solving used for identifying the root causes of faults or problems. It is widely used in IT operations, telecommunications, industrial process control, accident analysis (e.g., in aviation, rail transport, or nuclear plants), medicine (for medical diagnosis), healthcare industry (e.g., for epidemiology), etc. 

출처 : en.wikipedia.org/wiki/Root_cause_analysis

Root cause analysis - Wikipedia

- 뭐 요점은, 과학이나 공학에서 RCA는 오류나 문제의 근본원인을 식별하는 문제해결방식이라는 겁니다. 간단하지요? 이것저것 찾아보면 굉장히 어렵게 설명되고 묘사된 것들이 많지만, 간단하게 그냥 근본원인을 찾아내고자 하는 생각의 툴이라고 보시면 됩니다. 

 

2. RCA 프로세스

 

RCA 5단계

① 문제의 정의

- 지금 현재 무슨 사안이 발생하고 있으며, 구체적인 증상(symptoms)이 무엇인지 파악합니다. 

② 정보 수집

- 문제가 발생한다는 증후가 무엇이 있으며, 얼마나 오래 지속됐는지, 영향은 무엇인지를 파악합니다. 

③ 가능한 인과 요인 식별

- 문제를 일으키는 사건은 무엇이며, 발생할 수 있는 조건, 해당 중심 문제를 둘러싼 또 다른 다른 문제는 없는지 파악합니다. 

- 해당 인과 요인을 파악하기 위한 방법으로 5whys(원인에 도달할 때까지 왜?라고 물어보기), Drill down등의 방법을 사용합니다. 

④ 근본 원인 식별

- 인과요인이 존재하는 이유는 무엇이며, 문제가 발생한 진짜 이유(근본 원인)이 무엇인지 확인합니다. 

⑤ 솔루션 구현

- 문제가 다시 발생하지 않도록 하기 위한 솔루션을 구현하며, 또 다른 위험은 없는지 재차 검토합니다. 

 

간단하지요? 사실 말만 조금 거창할 뿐입니다. 결국 왜 이런 결과가 도출됐는지를 쭉- 검토하고, 근본원인을 찾아내자. 그리고 해결방안을 모색하자. 뭐 이런 겁니다. 근본 원인을 해결하지 못하면 결국 똑같은 문제가 계속 발생하고, 거기서 다른 문제가 또 파생될 것이고, 그러다보면 효율적인 업무를 진행하지 못하기 때문이겠지요. 

 

 

3. 업무 적용 사례(시스템 오류의 원인을 찾아라)

- 입사 후, 제가 맡았던 하나의 업무 영역 중 사업부 시스템 관리가 있었습니다.

전사에서 사용하는 큰 시스템(A)이 있었고, 해당 데이터를 받아가서 저희 사업부에서만 사용하는 레거시 시스템(C)이 또 하나 있었습니다. 그리고 또 그 중간에 있는 시스템(B)도 있었죠. 하나의 실적을 보여줄 수 있는 시스템이 무려 3개가 있었습니다.

사실 이건 제 생각이긴 하지만, 같은 것을 보여줄 수 있는 시스템이 다양하게 있는 것은 좋지 않다고 생각합니다. 각각의 시스템 사용률 및 유지보수로 발생하는 비용(공수) 때문인 것도 있지만, 그것보단 오류로 인해서 발생하는 정합성의 문제 때문입니다. 조회하는 사람마다 그 관점의 차이로 인해 발생하는 것들은 설명과 교육으로 커버가 가능하지만, 실제 시스템 오류로 인해 추출값의 차이가 발생했을 시에는 시스템 신뢰도까지도 책임져야 하는 상황이 발생합니다. 

① 문제의 정의

- 아무튼 위에서 말씀드린 것처럼 3가지+α의 시스템이 있었는데, 그 때 당시 전사 시스템 통합 작업으로 인해서 저희가 사용하는 시스템이 지속적으로 오류가 발생했습니다. 당연히 A가 오류가 나니, B도 C도 전부 오류가 났었습니다. 정작 저희 사업부에 있는 사람들은 C만 사용하는데 말이죠.

② 정보 수집

- 그래서 이걸 고치기 위해 많은 노력을 했었습니다. 헌데 제가 입사를 하고 얼마 지나지 않은 시점이다보니 A-B-C의 관계를 잘 몰랐고 그것을 파악하는데 참 오랜 시간이 걸렸더랬습니다. 그래서 관련된 모든 상황을 파악하는데 시간이 오래 걸렸습니다. 하루는 저희 팀장님이 절 불러서 앉혀놓고 같이 고민하다 이 RCA얘기를 하셨습니다. 업무를 할 때는 항상 이걸 머릿속에 염두에 두고 진행하라고 하시면서요.

③ 가능한 인과 요인 식별

- 그때 자리에 들어와서 RCA 다이아그램을 혼자 그려봤습니다.

④ 근본 원인 식별

- 그러다가 해당 문제가 계속 발생하고 있는 이유가 A 안의 오류라는 것을 알게 되었고, 그 안에서 짜잘하게 발생하는 세부 오류를 전부 해결하지 않으면 지속적으로 문제가 발생할 수 밖에 없었죠. 마침내 다 해결했습니다.

⑤ 솔루션 구현
- 근본원인을 알아냈으니 싹 고쳐야죠. 그리고 해당 오류 재발을 방지할 수 있는 솔루션을 시스템 차원에서 하나, 프로세스 차원에서 하나 세웠습니다. 

 

잘 읽어보셨나요? 내용이 좀 재미가 없죠. ㅎㅎ 제가 딱히 똑똑하지도 않고, 뛰어난 인재도 아니지만 제가 맡은 바 업무를 진행할 때는 남들에게 지적질 당하지 않고자 열심히 노력하고 있습니다. 그리고 그 기본이 되는 것 중에 이 RCA가 있습니다. 사실 저희가 하는 모든 사고 방식이나 업무 처리 프로세스는 모두 이 RCA의 이론대로 디폴트 셋팅되어있다고 생각합니다. 그럼에도 불구하고, 근본원인 탐색을 위해 많은 노력을 기울이는 것은 쉬운 일이 아니죠. 

 

오늘 저의 글은 아마 막 회사에 들어간 신입사원 분들이시라면 더 유익할 거 같습니다. 다음엔 조금 더 가볍고 재밌는 글로 돌아오겠습니다. 항상 감사드리며, 오늘도 조금이나마 도움이 됐으면 좋겠습니다. :)

 

이번 주도 화이팅입니다!