잃는 것과 얻는 것

예전에 정보화사업을 진행할 때였다. 내 옆에는 커다란 서랍의 위아래 두 칸을 차지하고 있는 산출물들과 그 데이터 CD들이 놓여있었다. 그 산출물을 사업담당부서에서 모두 검토할 것은 아니었다. 하지만 정보화사업 담당부서는 그것이 정보화의 일환이라는 이유로 그것 모두를 주도적으로 검토해야하는 입장에 처해있었다. 즉 그 업체가 사용자들의 요구사항을 제대로 정리했는지, 업무 프로세스를 제대로 이해했는지, 사용자와 접속층을 제대로 분석했는지부터 시작하여 테스트 케이스를 제대로 만들었는지, 개발 중 발생할 수 있는 위험요소를 예측하고 있는지, 제안서대로 장비와 인력을 구성했는지, 인계인수 계획을 제대로 이행하는지, 심지어 사용자 교육 일정과 사용설명서의 구성에 부족함은 없는지까지. 이렇게 열거한 것들은 사업 진행상의 작은 일부분이었으므로 그 모든 일들을 모두 완벽하게 처리할 수는 없었다. 어떨 때는 사용자측의 도움이 필요했고, 어떨 때는 개발사의 도움이 필요했으며, 어떨 때는 장비업체의 도움이 필요했다. 물론 중요한 것은 내가 얼마나 많이 알고 있느냐 하는 것이었다. 관리자로써 여러 공문을 통해 사업을 진행해나가는 것도 중요했고 또 기술적 검토를 하는 것도 중요했지만, 무엇보다도 나는 사용자의 업무에 대해 많이 알아야만 했다. 정보화사업이란 결국 사용자의 편리를 위한 것이었고, 따라서 그 중심엔 사용자가 있어야만 했었다.

사업예산을 얻기 위해 기획재정부에 찾아갔을 때 예산담당 과장은 이것을 계속 물었다. "그래서, 이 사업을 통해 우리가 얻은 이익이 무엇입니까?" 그는 이익이 없거나 불투명한 사업, 성과지표에 맞는 결과를 정량적으로 도출하지 못하는 사업은 예산을 감축할 수 밖에 없다고 으름장을 놓았고, 우리는 그에 만족할만한 대답을 잘 하지 못했다. 여러 가지 이유가 있었지만 가장 큰 이유는 그 어느 누구도 말단에서 정부부처에 이르는 업무흐름, 사용자의 업무를 완벽히 알지 못했기 때문이었다. 업무의 부분부분에서 얻는 이점은 제대로 이야기하지 못하고 오히려 문서업무를 전산화하면서 나타나는 문제점이 부각되자 정보화의 장점마저도 단점처럼 여겨지기 시작했다. 문서업무를 전산화하는 과정에는 진통이 발생할 수 있다. 문서처리 시에는 주먹구구식으로 넘어갔던 것들, 즉 업무 담당자들이 그때그때 수정하던 자료 자체의 비통일성, 또는 업무지시 체계에서의 모순 등이 전산화 과정에서 드러날 수 있는 것이다. 이런 것들이 정보화담당자들의 문제라고 하기는 어렵다. 하지만 이런 문제들은 정보화사업의 실패로 이어지고 정보화를 불필요한 것으로 여기게 만든다. 그리고 이것 또한 사용자측만의 문제는 아니었다. 사업부서와 개발사는 그런 오류를 알려주고 개선시켜줄 의무가 있기 때문이었다. 그리고 그것은 곧바로 사용자의 편의, 사업의 필요성과 이득으로 연결되었다.

따라서---심지어---'업무담당자'를 '업무적'으로 교육시킬 수 있는 능력, 그것이 필요했다. 하지만 빠르게 발전하는 정보기술을 따라가고 또 여러가지 결과에 대한 기술적 검토를 하기도 바쁜 그때에 사용자들의 업무지식까지 쌓는 것은 사실 어려워보였다. 그래서 분명히, 난 사용자의 업무에 대해 알지 못했다. 어쩌면 알고 싶지 않아했는지도 모른다. 하지만 지금은 '그때 그들의 업무에 대해 더 잘 알았더라면', 하는 그런 아쉬움을 생각한다. 그들이 업무의 어떤 부분에서 어려움을 겪고 또 어떤 점을 정말 필요로 하는지 정확히 알았다면. 만일 그랬다면 그 시스템은 더 효율적이고 더 편의적이었을 것이다. 그래서 난 지금 이곳에서 생각한다. 잃는 것이 있다면 얻는 것이 있다고, 내가 지금 여기에 있음으로 해서 얻을 수 있는 것에 무척 감사해야 한다고 말이다.