이번 시스템 구축 과정을 겪으면서 개인적으로 많이 아쉽고 답답함을 느꼈습니다. 처음 이 시스템을 만들게 된 것은 제 담당 업무가 아니었음에도 한 팀장님의 요청이 있었기 때문입니다. 과거에 해당 업무를 잠시 담당했던 경험도 있었기 때문에 업무의 흐름과 담당자가 겪는 불편함을 어느 정도 알고 있었습니다. 그래서 단순히 요청받은 기능만 구현하는 것이 아니라, 실제 담당자가 업무를 할 때 어떻게 하면 조금이라도 더 편리하고 효율적으로 사용할 수 있을지를 고민했습니다. 퇴근 후 늦은 시간까지 며칠 동안 시스템을 만들었고, 실제 업무에서 문제가 발생하지 않도록 수십 차례 테스트하며 기능을 수정하고 보완했습니다. 다만 아쉬웠던 점은 정작 이 시스템을 실제로 사용할 담당자는 다른 업무가 바쁘다는 이유로 개발 및 테스트 과정에 충분히 참여하지 못했다는 것입니다. 결국 제가 업무 흐름을 생각하면서 필요한 기능과 개선사항을 판단하고, “이 부분은 이렇게 적용하면 업무가 더 효율적일 것 같다”는 식으로 하나씩 설명하며 시스템을 완성했습니다. 이후 제가 만든 시스템은 별도의 보안성 검토를 받지 않았기 때문에 실제 업무에 적용하기 어렵다는 전산 부서의 의견이 있었습니다. 저 역시 보안성 검토가 필요하다는 점에는 동의합니다. 그래서 보안과 관련된 부분은 전문업체를 통해 검토하거나 필요한 조치를 받으면 되지 않겠느냐고 의견을 제시했습니다. 그러나 현재 우리 기관의 시스템을 관리하는 외주업체에서는 해당 업무를 수행하지 않는다는 답변이 있었고, 다른 전문업체를 선정하려면 별도의 예산 편성과 관리가 필요하기 때문에 현실적으로 어렵다는 이야기를 들었습니다. 저는 바로 이 부분에서도 큰 의문을 느꼈습니다. 우리 조직은 업무상 필요성이 있다면 그에 맞는 예산을 편성하고 집행할 수 있습니다. 그렇다면 시스템 구축의 출발점은 **“어느 업체가 관리하기 편한가”가 아니라 “실제 업무를 어떻게 더 편리하고 효율적으로 만들 것인가”**가 되어야 한다고 생각합니다. 업무에 필요한 시스템의 방향과 기능을 먼저 정하고, 그 목적을 제대로 구현할 수 있는 업체를 선정하고 필요한 예산을 편성하는 것이 자연스러운 순서라고 생각합니다. 그런데 현재의 논리는 오히려 그 순서가 뒤바뀐 것처럼 느껴졌습니다. 다른 전문업체를 선정하면 예산을 새로 편성해야 하고 관리해야 할 업체가 늘어나 불편하다는 이유로, 기존 관리업체에 시스템을 맡기는 것이 우선되는 상황이라면 이는 시스템을 사용하는 담당자의 업무 편의성과 효율성보다 관리의 편의성이 앞서는 결과가 될 수 있습니다. 저는 이 부분에서 상당한 주객전도의 느낌을 받았습니다. 시스템은 관리를 편하게 하기 위해 존재하는 것이 아니라 실제 업무를 더 편리하고 효율적으로 수행하기 위해 존재한다고 생각합니다. 물론 여러 업체를 관리해야 하는 행정적 부담이나 예산 편성의 어려움 역시 고려해야 할 요소입니다. 하지만 그것은 시스템 구축 목적을 달성하기 위한 여러 고려사항 중 하나이지, 실제 사용자의 업무 효율성과 시스템 품질보다 우선되어야 할 목적은 아니라고 생각합니다. 이후 결국 현재 관리업체에 제가 만든 시스템을 보여주고 유사하게 개발하도록 할 것이며, 저는 여기서 빠지라는 취지의 이야기를 들었습니다. 저는 현재 업체에 시스템 개발을 맡기는 것에 대해 우려가 있다고 의견을 밝혔습니다. 그러나 이에 대해 “선을 넘지 말라. 업체 선정은 내가 결정하는 것이다. 그렇게 이야기하려면 네가 담당자가 되어라”는 취지의 말을 들었습니다. 저는 이 부분에서 상당히 불쾌함을 느꼈습니다. 제가 특정 업체를 개인적인 이유로 반대하는 것이 아니기 때문입니다. 현재 해당 업체는 우리 기관 홈페이지를 구축했다는 이유로 여러 업무 시스템을 지속적으로 구축하고 있습니다. 업체가 좋은 품질의 시스템을 만들어 준다면 저 역시 굳이 반대할 이유가 없습니다. 문제는 지금까지 확인한 결과입니다. 실제로 9월 1일 신규 오픈한 서비스만 보더라도 직접 테스트해 본 결과 일부 기능이 정상적으로 작동하지 않았습니다. 사용자의 편의를 위해 만든 기능이 오히려 기존 방식보다 불편한 부분도 있었고, 오픈 이후 며칠이 지나도록 확인된 오류가 수정되지 않은 사례도 있었습니다. 다른 시스템에서도 실제 업무 담당자들이 불편을 호소하는 부분이 적지 않습니다. 그렇기 때문에 제가 해당 업체에 대해 우려를 제기한 것은 업체 선정 권한에 개입하기 위한 것이 아니라, 과거의 구축 결과를 바탕으로 이번 시스템에서는 같은 문제가 반복되지 않았으면 한다는 취지였습니다. 시스템 구축의 목적은 단순히 ‘시스템을 만드는 것’이나 ‘납품을 완료하는 것’이 아니라고 생각합니다. 실제 업무 담당자가 편리하게 사용할 수 있어야 하고, 기존 업무보다 효율성이 높아져야 하며, 충분한 테스트를 통해 오류와 불편사항을 확인하고 개선한 뒤 운영되어야 합니다. 특히 이번 시스템은 제가 직접 며칠 동안 만들고 수십 차례 테스트하면서 업무 흐름과 필요한 기능, 발생할 수 있는 문제점까지 상당 부분 파악하고 있습니다. 그렇기 때문에 외주업체가 새롭게 시스템을 구축한다면 누구보다 적극적으로 테스트하고 문제점을 찾아 개선을 요구할 수 있는 사람 역시 저라고 생각합니다. 제가 반드시 개발에 참여해야 한다거나 제가 만든 시스템을 그대로 사용해야 한다고 주장하는 것이 아닙니다. 보안이나 유지관리 등의 문제로 전문업체를 통해 다시 구축하는 것이 조직의 결정이라면 그 결정 자체는 존중할 수 있습니다. 하지만 이미 업무를 분석하고 시스템을 직접 구현하고 수십 차례 테스트까지 한 사람을 구축 및 검증 과정에서 완전히 배제하는 것이 과연 시스템의 완성도를 높이는 방향인지는 의문입니다. 더욱이 관리가 편하다는 이유로 기존 업체를 우선하고, 실제 시스템을 사용하는 담당자의 업무 편의성과 시스템의 완성도가 그다음 문제가 된다면 저는 그 방향에는 동의하기 어렵습니다. 가장 우려되는 것은 지금까지와 같은 방식이 반복되는 것입니다. 업체에서 시스템을 개발한 뒤 “이렇게 사용하면 됩니다”라고 설명하고 납품을 완료하면, 실제 담당자는 충분한 검증 없이 시스템을 사용하게 될 가능성이 있습니다. 그리고 운영을 시작한 뒤 현장에서 불편사항이나 문제점이 발견되더라도 예산, 계약, 유지보수 범위 등의 문제로 즉시 개선하기 어려운 상황이 다시 발생할 수 있습니다. 결국 불편한 시스템을 실제 담당자들이 계속 참고 사용해야 하는 상황이 반복될 수 있습니다. 제가 문제를 제기하는 이유는 제가 만든 시스템에 대한 개인적인 애착 때문이 아닙니다. 누가 개발하느냐보다 중요한 것은 실제 업무에 도움이 되는 시스템을 만드는 것입니다. 전문업체가 개발하더라도 실제 사용자의 업무를 충분히 분석하고, 개발 과정에서 담당자의 의견을 반영하고, 충분한 테스트와 수정 과정을 거쳐 제대로 된 시스템을 만들어야 합니다. 그리고 그러한 목적을 가장 잘 달성할 수 있는 방법과 업체를 선택한 뒤, 필요하다면 그에 맞게 예산과 관리 방식을 마련하는 것이 순서라고 생각합니다. 제가 원하는 것도 그것뿐입니다. 이미 시간과 노력을 들여 분석하고 테스트한 경험이 있다면 그것을 활용해 더 나은 결과물을 만드는 것이 조직에도 도움이 된다고 생각합니다. 그런 문제 제기까지 단순히 “선을 넘는 행동”으로 받아들여지는 것은 많이 아쉽습니다. 업체 선정의 결정권이 누구에게 있는지를 문제 삼는 것이 아닙니다. 제가 이야기하고 싶은 것은 ‘누가 결정하느냐’도, ‘어느 업체를 써야 하느냐’도 아닙니다. ‘우리가 왜 이 시스템을 만드는가’, 그리고 ‘어떻게 해야 실제 현장에서 제대로 사용할 수 있는 시스템을 만들 수 있는가’가 먼저 논의되어야 한다는 것입니다. 업무를 위해 시스템과 업체가 존재하는 것이지, 특정 업체를 계속 이용하기 위해 업무와 시스템의 방향을 맞추는 것은 아니라고 생각합니다.