농협 사태와 한복 사건, 그리고 수많은 가이드들

조직마다 규약과 제도를 통해서 업무 프로세스를 수행하게 되며, 이는 조직 구성원들의 행동을 제한하게 됩니다. 이런 규제나 제약에 관련되어서 조직의 특성마다 어떻게 이를 규약할 것인지는 다릅니다. 이번 농협 사태와 한복 사건을 계기로 IT 개발시에도 동일한 문제들이 발생되는 경우들이 있어서 몇가지를 거론하고자 합니다.

조직이 가지는 규약은 최초에 특정한 이유와 사건으로 인해서 생겨난 것이며, 이는 그 시대상을 어느 정도 반영하고 있습니다. 한복 사건의 경우, 어떠한 이유로 인해 생겨났을 것이며, 명시적으로 문서화되어 있지는 않았지만 (혹은 지침과 같은 형태로 문서화가 되었을 수도 있겠지만) 조직 구성원들에게 행동이나 업무 수행을 제약했을 것입니다. 아무튼 이러한 규약을 알고 있고, 마치 모든 기준을 이러한 규약을 통해서 지켜져야 한다고 생각하는 업무들은 행위의 정당성을 부여하게 됩니다. IT 개발 역시 수많은 제약들과의 싸움과 타협을 해야하며, 이러한 수고는 가이드나 템플릿이라는 이름으로 덜어주고자 만들어져 사용되고 있습니다. 하지만, 이러한 가이드나 템플릿을 지키지 않음으로써 손해를 보는 것은 당장 이를 업무에서 수행하는 개인이 됩니다. 만일, 특정 가이드나 템플릿과는 동떨어진 문서를 만들어내면 당장 감리나 인스펙션에서 손해를 보는 것은 뻔합니다.

가이드나 템플릿이 필요없거나 나쁘다는 얘기는 아닙니다. 한복 사태에서도 보듯이 예전의 특정 사건이나 사례로 인해(아마도 전체를 통틀어서 그리 자주 일어나지는 않았겠지만 전체 업무 프로세스에 지대한 영향을 미칠 수도 있는) 한번 정해진 규약의 틀은 조직에 빠르게 확산되고 정착되기 마련입니다. 그리고, 이러한 규약의 틀은 한번 정착되면 이에 대한 인식을 바꾸거나 틀을 없애는 것은 훨씬 더 어렵습니다. 만일, 최초의 규약이나 규제가 그리 강력하지 않은 권고의 수준이거나, 조직이 이해할 수 있고 동의할 수 있는 수준의 규정이었다면, 이를 적용하는데 있어서 다소 유도리가 있게 반응했을 것입니다. (조직이 상명하복식의 특성이 강하면 강할수록 유연성 있는 행동지침을 만들어내기가 어려울 것입니다.) 또한, 그로 인한 손해도 조직 차원에서 흡수하고 이를 융통성있게 받아들일 수 있는 특성을 가진다면 좀 더 매끄러운 업무 처리를 할 수 있을 것입니다. 가이드나 템플릿 역시 모든 프로젝트 관여자들이 지키지 않으면 안되는 것, 혹은 이외에는 아무것도 받아들이지 말아야 할 것으로 인식하게 되는 순간 한복 사태와 같은 일들이 비일비재하게 발생하게 됩니다. 업무 프로세스에 대한 발전이나 다양성을 인정하지 않는 형태의 가이드나 템플릿은 사실 없느니만 못합니다. 오히려 이를 만드는 사람에게 더 많은 고통과 경직성을 가지고 올 뿐입니다.

또한, 관리 조직에서는 가이드나 템플릿이 있다는 것만으로도 관리에 대한 부담을 경감시킨다는 인식을 갖게 합니다. 이는 마치 법이나 규제만이 모든 행동을 규약할 수 있다고 생각하는 위정자와도 같습니다. 법이나 규제가 필요한 부분은 최소로 하고, 교육과 문화를 바꾸어서 인식의 전환을 하게끔 하는 것이 최선이지만, 빠른 시간 안에 효과를 보고 그러한 법과 규제를 만드는 것이 마치 많은 일을 한 것인 양 착각하는 관리 조직으로 인해 더 많은 희생자들이 발생하게 됩니다. 이는 엄격하게 말하면 관리 조직으로써 책임을 그 조직 구성원들에게 미루는 행위와도 같습니다. 그러한 환경에서는 조직 구성원들은 가이드나 템플릿이 없으면 업무를 진행하지도 못하고 거기에 쓰여져 있는 대로 쫓아가는데 바쁘기만 할 뿐 전혀 창조적이거나 새로운 것들을 만들 능력을 점점 소멸하게 됩니다.

이번 농협 사태는 그 결과와 파장이 주목되는 부분입니다. 어떠한 이유로 인해서 문제가 발생되었는지는 자세하게는 알지 못하지만, (그리고 그 안에 얽혀있는 갈등과 문제가 무엇인지도 정확하게 드러나지도 않았지만) 앞으로 그러한 사태를 방지할 수 있는 농협의 대처 방법과 이를 주시하고 영향을 받는 다른 조직의 대처 방법에 대해 상당히 주목이 가는 부분입니다. 사실, 특정 개발자에 의한 데이터 삭제는 (의도적이든 그렇지 않든 간에) 가능한 일입니다. 이는 다른 규제나 가이드, 혹은 아주 비싼 장치(혹은 솔루션/패키지 등)를 통해서 아예 없어질 행위나 업무가 아닙니다. 벌써부터 개발 조직의 노트북 규제가 입방아로 돌고 있는 상태입니다. 이러한 규제가 농협 사태를 막아줄 것이라고 믿는 사람은 아무도 없을 것입니다. 가능한 일을 막는 방법은 그러한 일이 발생했을 때에 (물론 사전에 강압적이거나 일률적인 방법이 아닌 다양한 방법을 통해서 만에 하나 일어날 수 있는 일을 방지해야 겠지만) 이를 얼마나 빨리 그리고 효율적으로 원상태로 되돌릴 수 있는가에 달려 있습니다. 만일 이번 농협 사태로 모든 개발자에게 데이터 삭제 명령어를 금지한다고 강력하게 규제한다면, 어느 개발자가 이를 순순히 규제대로 하겠습니까? 어떤 방법을 동원해서라도 데이터 삭제를 하는 사람들도 분명 있을 것이며, 그냥 난잡하게 데이터를 쌓아놓아 시스템에 더 큰 문제를 발생시킬 수도 있을 것입니다. 

실수나 실패는 어느 누구도 겪으며, 이는 조직에게도 해당됩니다. 이를 어떻게 극복하고 더 나은 상태로 갈 것인지, 혹은 실수나 실패를 용납하지 못하고 아예 그런 일이 없게 강력하게 규제를 할 것인지는 조직이 결정할 사항입니다. 다만, 그러한 결정이 내부 구성원들의 합의와 공감대를 형성한 것인지, 단순히 책임을 전가하기 위한 관리 조직의 일방적인 견해인지가 다를 뿐입니다. 얼마 만큼의 자유를 조직 구성원들에게 부여할 것인지에 대한 해답은 조직이 구성되고 유지되는 한 늘 찾아야하는 합의점입니다. 그리고, 그러한 자유에 대해서 어떻게 책임을 부여하고, 침범된 자유에 대해 어떻게 보상할지에 대한 부분도 늘 고민해야할 부분입니다. 규제나 규약, 가이드나 템플릿은 이러한 노력과 고민을 한번에 해결할 수 있다는 착각을 만드는 신기루와 같습니다.