Skip to main
무엇이 재앙을 만드는가
- 스리마일섬은 사고 분석 이야기에 상당히 자주 나오는 이야기인데, 정상 사고도 이 사고에서 영감을 얻어 썼다고 알려져있다.
- 당시 스리마일섬 원자력 발전소는 최신식 시설이었다.
- 따라서 사고가 일어난것도 놀랍지만, 그 사고가 고작 “밸브 고장"과 “인력 교대시 전달사항을 빠뜨린 것” 그리고 “계기판이 고장난 것"으로 인해서 그 거대한 시스템이 무력화된 것이 충격적이었던 것 같다.
- 찰스 페로는 “사소한 것들의 시너지가 일어나면서 수많은 안전장치를 무력화시키고 거대한 시스템을 고장나게 만들었다"라고 평가했다.
이 대목에서 장상 사고의 핵심이 드러난다. 그것은 직접적인 작동 순서에 속하지 않은 다발적 장애의 상호작용이다. p. 38
- 정상사고라는 단어는 “사고의 발생이 이상한 것이 아닌 정상적인 것"이라는 의미로 사용된다.
상호 작용성 복잡성과 긴밀한 연계성이라는 시스템의 속성에 따라 불가피하게 발생하는 사고를 "정상 사고" 혹은 "시스템 사고"라고 한다. 정상 사고라는 개념은 언뜻 이상하게 보이지만 시스템의 속성상 예상치 못한 다발적 장애의 상호작용이 불가피하다는 의미를 담고 있다. p.14
- 즉 시스템 자체가 가지고 있는 속성으로 인해 발생하는 장애를 의미한다.
- 다만 사소한 장애를 정상사고라 부르지는 않는다.
- 찰스페로는 사소한 사고의 경우 “요소 장애 사고"라고 불렀다.
- 요소 장애 사고가 모여 예상치 못한 상호작용을 하고, 이로 인해서 상위 시스템이 맛이 가는 경우 “정상 사고"가 된다
개별적 장애는 사소하고 비상수단이나 여분 경로를 지니지만 다른 장애와 상호작용을 일으킬 경우 문제가 악화된다. 사고는 다발적 장애의 상호작용에 기인한다. (...) 그러나 이 모든 일들이 한꺼번에 일어나리란 예상은 못한다. p.17
이러한 사고의 발생이 정상인 이유는 잦거나 예측 가능하기 때문이 아니다. 정상 사고는 드물게 일어나고 예측하기 어렵다. 그래서 정상 사고가 발생하면 혼란에 빠질 수밖에 없다. 이러한 사고는 시스템의 내재적 속성이 때로 일정한 상호작용을 일으킨다는 점에서 정상이다. p.17
- 운석이 떨어졌다면 이것은 정상 사고가 아니다.
- 계기판이 고장나서 잘못된 판단을 하는 것은 다분히 “정상적"이다.
- 정상 사고를 일으켰던 공통적 요소들
- 연계성
- 요소 A와 B가 서로 연관되어 있다면 연계성이 성립된다.
- 만약 B가 A의 동작에 의존적이라면 (A가 고장났을때 B도 고장난다면) “긴밀한 연계"라고 부른다 p.137 ~ p.139
- 긴밀한 연계는 언제나 동일한 결과를 내며 변동성이 적다.
- 좋게 말하면 안정적이지만, 나쁘게 말하면 변화에 취약하다
- 긴밀한 연계는 공정의 순서가 바뀌지 않으며 한방향으로만 진행된다
- 긴밀한 연계는 느슨한 부분이 없다.
- 한 부분을 바꾸기 위해서는 전체 부분에 대한 고민이 필요하다
- 긴밀한 연계는 시간에 의존적이다.
- 시간에 따라서 동작이 바뀌어야 한다.
- 컨베이어 벨트위의 제품은 시간에 의존적이다.
- 만약 B가 A의 동작에 의존적이지 않다면 “느슨한 연계"라고 부른다
- 느슨한 연계에서는 B없이 제품이 완성될 수 있다.
- 나쁘게 보면 미완의 제품이 나올 수 있지만, 반대로 유연함을 가진다.
- A가 지연된다고 해도 B의 동작에 문제가 없다
- 입력값이 바뀌어도 전체 시스템을 바꾸지 않고 동작한다
- 화력 발전소는 석탄이나 석유나 그 인터페이스만 교체하면 동작한다.
- 원자력 발전소에 석유를 쓰기 위해서는 상당한 고민이 필요하다.
- 한 부분이 고장나더라도 다른 부품으로 교체될 수 있다.
- 전통적인 Server-DB의 관계는 “긴밀하다"라고 할 수 있으며, Message queue를 사용해서 구현한 경우 “느슨한 연계의 성격"을 띄게 될 것이다.
- 상호작용의 복잡성
- 구성 요소들이 늘어나면서 복잡성도 늘어난다.
- 복잡성이 늘어나는것은 문제가 아니지만, “예측할 수 없는 복잡성"이 언제나 정상 사고의 원인이 된다.
단선적 상호작용은 정상적인 생산 순서에 따라 근접한 시스템의 요소들 사이에 발생하고, 복잡한 상호작용은 정상적인 생산 순서를 벗어난 요소들 사이에 발생한다. p.116
- 책에서의 설명은 “파이프가 고장나 물이 새는데 하필 그 옆에 있던 전선을 누전시키는 경우"와 같은 상황을 설명한다.
- 하지만 SW에서도 동일한 상황은 언제나 생기기 마련이다.
- 예를들어서 복구 스크립트를 만들어 두었지만, 하필 그게 꺼진 서버에 있었다면?
이 모든 일들이 한꺼번에 일어나리란 예상은 못한다. p.17
- 이번 카카오의 상황도 충분히 정상사고의 범주에 속한다고 설명할 수 있다.
- 상호작용의 복잡성은 사람의 실수를 유발하기도 좋다.
저는 우리가 훈련받은 것과 다른 상황에 직면했다는 것을 깨달았지만 매번 이미 알고 있는 대로 결정을 내렸습니다. 가령 압력이 낮았지만 증기 발생기의 급수 밸브를 신속하게 열었습니다. 지금 돌이켜보면 잘못된 판단임을 알 수 있지만 당시에는 대부분의 행동이 나름의 논리를 따른 것이었습니다. p.44- 당시 가지고 있던 정보만 보면 밸브를 여는것은 올바른 판단이었지만, 나중에 전체 상황을 보면 잘못된 판단이었다.
- 원전의 복잡한 상호작용으로 인해 정상 사고 도중 누구도 “현재 상황"을 파악하지 못해서 벌어진 일
- 따라서 상호작용의 복잡성은 지양해야 한다.
결과적으로 우리가 복잡한 시스템을 만드는 이유는 단선적 시스템을 통해 필요한 생산물을 얻는 방법을 모르기 때문이다. 그러나 복잡한 시스템이 참사를 일으킬 위험을 안고 있다면 다른 방법을 찾거나 생산물을 완전히 포기하는 것을 고려해야 한다. p.131
- 정상사고를 줄이기 위해서는 “느슨한 연계"와 “단선적인 상호작용"을 달성해야 한다.
- 느슨한 연계에서는 시간에 의존적이지 않기 때문에, 사고가 전파되지 않는다.
- 즉 잠시 장애가 나도 전체 시스템에는 문제가 생기지 않는다
- 이 시간을 통해서 사고를 해결할 여유를 가질 수 있게된다
- 단선적인 상호작용에서는 “예상치 못한 상호작용"을 막을 수 있다
- C에서 포인터가 얼마나 많은 오류를 불러 일으키는지, 반대로 러스트가 왜 메모리 safe한 방식을 취했는지 생각해보면 이해가 된다
- 정상 사고는 절대로 운용자의 오류로 결론지어져서는 안된다
그렇다고 해도 운용자 오류는 너무나 쉽게 사고 원인으로 지목된다. 진정한 문제는 생산이 중단되어서는 안 된다는 압력 때문에 위험을 감수해야만 하는 작업 환경에 있다. p.361실수 유발 시스템이라는 개념 자체가 복잡성과 연계성에서 도출되었다. p.259- 정상 사고로 결론지어지면 근본적인 원인을 분석할 수 없고, 이로인해서 “실수 유발 시스템"이 그대로 유지된다.
- 문제 없다는 자신감과 여전히 실수를 유발하는 시스템 그리고 더 빡빡해진 관리 절차로 인해 우리는 더 위험한 시스템을 운영하게 된다.
- 정상 사고의 한 가운데서는 그 무엇도 알수 없기 때문에 정상 사고를 최대한 약화시켜야한다.
운용자가 예상치 못한 다발적 장애 사이의 상호작용과 마주칠 경우 사후에야 올바른 대처법을 파악할 수 있다. 정상 사고의 와중에는 누구도 어떤 일이 벌어지는지, 어떻게 대처해야 하는지 알 수 없다. p.19- 이는 “느슨한 연계"를 통해서 달성할 수 있다.
- 시간에 대한 의존성이 없기 때문에, 일부 시스템이 멈추어도 전체 시스템에는 큰 영향이 없다.
- 긴밀한 연계에서 느슨한 연계로 이어지는 이 흐름은, 마치 절차지향에서 객체 지향으로, 모노리딕에서 MSA로 이어지는 느낌이다.
- MSA 혹은 객체지향을 단순히 지향해서는 안될 것이다.
- 이 개념들에 매몰되었을때 발생하는 폐해는 생각보다 크다.
- 그러니 “느슨한 연계"를 달성하기 위해 MSA와 객체지향이 사용되어야 하는 느낌이다.
정상 사고,
블로그,
무엇이 재앙을 만드는가?,
독후감,
Published