Extremely Agile

오늘 뉴스를 보다보니 후쿠시마 원전 건설 과정에 참여했던 분의 글이 화제가 되고 있더군요. http://www.viewsnnews.com/article/view.jsp?seq=73255 여기서 원문을 보실 수 있습니다. 글을 읽다보니 참으로 많은 생각이 떠올랐습니다. 그 분의 말이 사실이라고 가정합시다. 우리는 뭔가를 만들면서 비슷한 실수를 저지르지 않고 있다고 할 수 있을까요?

왜, 이러한 일이 일어난 것일까요. 그 근본적인 원인은 오로지 도면상의 설계에만 중점을 두고, 현장에서의 시공, 관리를 소홀히 했기 때문입니다. 비단 그것이 직접적인 원인이 아닐지라도, 이러한 사고는 발생할 것입니다.

우리도 마찬가지 실수를 종종 저지르고 있는 건 아닐까요? 설계를 너무 중요하게 생각한 나머지, 개발은 '돌아가게만 하면 된다'고 생각하는 오류를 저지르고 있는 건 아닐까요?

십여 년 전 까지는, 현장작업에 보신(봉심)이라 부르던 전문 기술자, 현장의 젊은 감독자 이상의 경험을 쌓은 전문가가 반장으로서 반드시 있었습니다. 전문가는 자신의 일에 자부심을 갖고 있어, 사고나 하자가 발생하는 것을 수치스럽게 여기며, 사고의 두려움도 잘 알고 있었습니다. 그러던 것이 10년 쯤 전부터, 현장에 전문가가 사라졌습니다. 비전문가들을 경험 불문이라는 형태로 모집하고 있습니다. 비전문가인 사람들은 사고의 무서움을 모르며, 어떤 것이 부실 공사인지, 어떤 것이 하자인지도 전혀 모르고 작업을 하고 있습니다. 그것이 현재 원전의 현실입니다.

우리는 어떻습니까? 지금 프로그래밍을 하고 있는 현장에 전문가는 존재하나요? 프로젝트 완료를 위해 경험 없는 개발자들이 낮은 임금에 개발과 교육을 동시에 진행하도록 강요받으며 투입되고 있지는 않나요? 현장에 있었던 전문가를 '더 훌륭한 일을 하도록' 다른 곳에 배치하고 있지는 않나요?

현장에 전문 기술자가 줄어들면서, 비전문가들도 건설, 제작을 할 수 있도록, 공사 과정이 설명서(manual)화되었습니다. 설명서화라 함은, 도면을 보며 건설을 하는 것이 아닌, 공장에서 어느 정도 조립된 부품을 가져와서, 현장에서 1번이면 1번, 2번이면 2번 하는 식으로, 그저 나무 블럭을 쌓아 올리듯 짜 맞추는 것을 말합니다. 그렇게 하면, 지금 자신이 무엇을 하고 있는 것인지, 얼마나 중요한 일을 하고 있는 것인지, 전혀 알지 못한 채 조립을 하게 됩니다. 이러한 것도, 사고나 고장이 빈번히 일어나는 원인 중 하나입니다.

여러분이 테스터라면, '이렇게 저렇게 테스트하라'고 지시하는 스크립트의 지령대로, 기계화된 테스트를 하고 있지는 않습니까? 그 과정에서 여러분의 창의력을 발휘할 기회는 혹 박탈되고 있지는 않나요? 무엇을 하고 있는지도 모른 채, 오직 테스트를 위한 테스트만을 하고 있지는 않습니까?

검사관이 용접이면 용접을, ‘그게 아니지. 잘 봐요. 이렇게 하는 거지.’라고 스스로 실연(實演)해서 보여줄 기량이 없다면, 진정한 검사는 이루어지지 않습니다. 그러한 기량이 없는 검사관이 착실한 검사를 할 수 있을 리가 없습니다. 건설사나 시공주의 설명을 듣고, 서류만 갖추어져 있으면 합격을 시키는, 이것이 현재의 관청 검사의 실태입니다.

이 외에도 원문에는 참으로 많은 이야기들이 적혀 있습니다. 

이 세상에는 규정을 지키는 것 만으로 막을 수 없는 많은 위험 요인들이 존재합니다. 그래서 '시장은 천천히 좋아질 것이다'라는 낙관적인 관점의 투자자가, '언젠가는 911같은 사태가 또 일어날 것이다'라고 가정하는 비관적 투자자에게 패배하기도 하고, 규정을 '엄격히' 지켜 만들었다고 생각하는 우주 왕복선이 대기권을 벗어나 보지도 못하고 폭발하기도 합니다. 

규정은 사람이 만드는 것이기 때문에 규정 자체가 얼마나 안전한지, '허용 가능한 위험'의 위험성에 대해서 얼마나 고려하고 있는지에 대해서는 규정 자체에 대한 관리 감독이 없이는 알 수가 없습니다. 문제는 이런 규정의 헛점이 사태가 벌어진 다음에야 밝혀지게 된다는 데 있습니다.

그런 일을 방지하려면 규정-설계-실행 사이에 선순환 피드백 고리가 만들어져야 하는데, 현재 대부분의 생산 현장이나 건설현장에서 그런 피드백을 찾아보기는 힘듭니다. 

그나마 소프트웨어 개발을 하고 있는 우리들은 다행인 셈입니다. 우리는 문제가 생기면 '그다지 큰 부담 없이' 문제를 보고하고 그 해결책을 논의할 수 있습니다. 어쩌면 그것이 '소프트웨어'의 진정한 '소프트'함이 아닐까 싶기도 합니다. 

하지만 이미 쌓아올린 원전이나 다리, 건물같은 구조물에 이르면, 이야기가 조금 달라집니다. 그런 구조물들은 그야말로 '하드'한 구조물이기 때문입니다. '하드'한 구조물을 안전하게 구축하려면 그 구축과정의 윗 부분과 아랫 부분을 연결하는 피드백 고리가 가능하면 짧아야 합니다. '다 만들고 감사받는다'로는 부족하다는 이야기입니다. 

우리는 소프트웨어 개발 분야에서 우리가 얻은 교훈들이, 앞으로 더 늦기 전에 많은 분야에 반영되기를 희망합니다. 그렇지 않으면, 이런 재앙은 막기 어려울 것입니다. 

또한, '낙관적'으로 가정할 수 있는 부분은, 오직 '인간이 본질적으로 선함' 이상도 이하도 아니라는 점을 모두가 깨닫게 되기를 소망합니다. 그리하여 좀 더 철저하고, 좀 더 보수적인 개발과 구축 문화가 뿌리내리기를 희망합니다.

그리고 가능하면, 원전과 같이 재앙의 리스크가 너무나 높은 기술은 가급적인 도입을 자제할 수 있게 되기를 희망합니다. 많은 분들이 '리스크는 관리 가능하다'고 생각하십니다. 네. 물론 관리할 수 있겠지요. 하지만 인간의 '실수'는 대개 관리가 불가능합니다. 스리마일 섬의 사고도 그런 식으로 일어났습니다. 관리가 불가능한 실수가 연이어 터질 때, 그리고 그 실수의 결과가 인간이 통제 가능한 범위 밖에 있을때, 그 실수는 '관리가 가능하다'고 믿었던 리스크를 재앙으로 돌변시키고 맙니다.

그리고 마지막으로, 지금도 일본에서 일어나고 있는 모든 고통스러운 상황들이 곧 끝날 수 있기를 기원합니다.