NEIS 사태에 우는 개발자, 헐 뜯는 언론과 정부

초유의 성적 정정 사태, 업무상 실수로만 보기 힘든 이유들?

나이스(NEIS) 사태를 바라보면서 느끼는 점은 답답함입니다. 우선 SDS의 개발 오류는 그 자체로 비판 받아야 하지만 좀 더 원론적으로 깊이 들여다 보면 SDS나 개발자의 문제로만 치부하기엔 사실 문제가 너무 많은 것 같습니다.

또, 현재 이런 사태를 빌미로 나이스(NEIS) 자체에 대한 반대를 여론이 IT 무용론으로 번지는 것도 우려스럽습니다.

반대와 찬성의 입장을 이야기 하자는 것은 아니고 현재의 사태의 핀트는 이런 문제가 왜? 생겼냐에 집중되어야지 시스템 반대로 기울어서는 안된다는 개인적인 생각때문입니다.

나이스시스템 도입의 문제는 이번 사태와는 다른 논점에서 논의되어야 하고 이야기되어야 된다라는 개인적 관점 때문이며 이번 사태의 핵심을 집어야 IT 업계의 스템을 개선 할 수 있다 생각하기 때문이기도 합니다.

그럼 이야기를 해보도록 할텐데요. 사실 이번 문제는 정부의 안일한 인식과 1000억원이나 드는 행정을 기관의 이기주의와 의사 결정권자의 성과 때문에 발생한 문제라는 측면에 더 무게가 실려야 하는 것은 아닐까 생각됩니다.

그런면에서 초기 언론은 너무 이 사태가 문제 제기에만 그쳤다는 지적을 피할 수 없을 것 같습니다. 제가 평론가도 아니고 정책 비판 할 입장이 아니라 좀 더 IT 관련 일에 집중해 이야기 해보도록 하겠습니다.


나이스(NEIS) 무었때문에 도입되었고 무었이 문제인가?
이 부분을 이야기 하려는 것이 아니라서 간단히 문제를 집고 넘어가겠습니다. 나이스(NEIS)는 원래 1996년 교육행정정보시스템 개발을 위해 시작되었습니다. 초등 및 중등 교육 관련한 학교와 지역 교육청등을 네트워크로 연결해 교무 학사, 인사, 회계 등의 전 교육 행정을 전자적으로 처리하겠다는 목적에 계획 된 것입니다.

자료출처: "교육 행정 정보 시스템"

취지 자체는 좋았지만 문제의 소지도 있었고 여러 이유를 들어서 많은 이들이 반대를 했습니다. 반대 내용은 개인정보 유출, 사생활 침해 등의 이유였습니다. 통합 시스템은 졸업, 재직, 퇴직, 검정 고시 등을 비롯 다양한 개인정보를 축적 할 수 있게 설계 되었는데 이것이 개인정보와 인권 침해등의 법적 문제를 야기 시킨다는 문제 때문 이었습니다.

인권위도 문제가 된 내용에 대해 27개 영역중 기본권 침해 소지가 있는 3개 영역에 삭제 권고를 받았지만 검토만 진행중이라고 합니다. 문제가 되는 부분과 진행 해야 할 부분을 나누어 정부도 보다 깊이있게 고민하고 논의 되었으면 싶네요.


나이스(NEIS) 문제 IT에 집중해 들여다보기..
어설프군은 이 내용중 좀 더 기술적인 요소에 집중해 보려고 합니다 "'단순 개발자 실수?' 나이스 사태 원인 논란" .. 등 여러 기사들을 보면 해당 문제에 대해 검증 절차를 지적하고 있습니다.

문제는 초기 언론에서는 "나이스, 프로그램에 문제… 쓰레기값(컴퓨터 연산과정서 드물게 나오는 엉뚱한 값) 처리 누락" 등을 보면 내용이나 전후 사정을 알아보지도 않고 프로그램을 잘못짰다는 식으로만 이야기 하고 있습니다.

몇몇 다른 글을 봐도 1000억대 교육 행정 정보 시스템이 이런 오류를 범했다는 식이나 7명의 프로그래머로 개발하는데 여러 어려움이 있었다등 이런 소재만을 다루고 있습니다.

그나마 검증 문제까지 다룰 정도면 정부의 검증 시스템이나 실제 검증 인력 구축시 그 인력이 검증이 가능한지 이런 문제들이 원론적으로 어디에서 출발 했는지를 지적해야 하는데 그런 걸 지적 못하고 있으니 답답할 노릇입니다.


나이스(NEIS) 정말 1000억원대 시스템 맞나?
정확한 내용은 잘 모르겠지만 실제 1000억원짜리 시스템이라고 해도 대부분의 예산이 소요되는 부분은 하드웨어입니다. 위 기사들을보면 삼성 SDS에 발주한 금액은 90억 정도라고 하는데 좀 과장 된 부분의 기사들도 있는 것 같습니다.

그럼 90억원이 작은 돈이냐란 이야기를 하실 수 있겠지만 작다는 것은 아니지만 이정도 현안을 처리하는데 과연 이정도 금액이 많은 금액일까 하는 생각이 듭니다. 또, 검증이나 테스트란 말은 잘하는데 예산과 검증 시간은 제대로 주어졌는지 지적하는 글은 잘 안보이는군요.

그리고 위키 글을 보면 SDS가 이전 시스템도 설계했기에 이번 업그레이드도 타 기업보다 삼성 SDS가 하는게 더 빠른 결과를 얻기 쉬웠을 것이라고 생각합니다. 그래서 개발시 조금 안일한 생각을 갖고 있었던 것은 아니었는지 이부분에 대해서도 다소 아쉬움이 있습니다.


나이스(NEIS) 사태로 본 한국의 후진적 IT 운영 시스템
이 사태를 정확히 들여다 볼려면 한국 IT 시스템의 후진성을 먼저 살펴야 합니다. 정부 같은 기관에서 나오는 발주는 대부분 조달청의 나라장터 시스템등을 통해 발주됩니다. 문제는 여기서 발주된 금액이 실제 계약이 진행 될 경우 다시 깎이는 문제가 있다는 것입니다.

그것이 담당 공무원의 능력을 증명하는 도구로 활용되서 그런진 몰라도 대부분의 프로젝트가 제 가격에 계약 진행되는 경우가 드뭅니다. 또, 발주 요청이 들어와 RFP를 봐도 전문 인력이 제대로 된 RFP 를 작성한 경우가 드물고 RFP 내용에 비해 발주 금액도 현저하게 소규모로 발주되는 경우도 많습니다.

실제 개발 인력 몇몇이 어떤 시스템에서 기획자 몇명과 몇일동안 어떤 방법으로 어떤과정을 거쳐 개발이 진행될지를 생각하고 예산을 짜야하는데 그렇게 진행되는경우가 거의 없고 발주 마저도 외주 연구 기관에 용역해 진행 되는 경우가 너무 많습니다.

더욱 큰 문제는 개발 진행 전 전체적인 개발 범위를 정하더라도 개발 진행과정에서 여러 요구사항이 추가되면서 개발 내용이 처음 계약 할 때보다도 더 많아진다는 사실입니다. ㅡㅡ;;

그리고 가장 치명 적인 것은 정부의 경우 기관장이 교체되는 경우와 개발 담당을 같이 했던 공무원의 이직이나 부서 이동등의 문제도 간혹 발생하는데요. 이런 경우 개발 일정이 앞당겨지기도하고 다시 재 설계가 진행되는 경우도 있어서 여러 어려움이 있습니다.

실제 모든 내용이 결정되 개발 일정을 3개월로 잡고 개발하기로 했다고해도(실제 3개월 개발 기간 잡히면 정말 밤낮 가리지 않고 개발해야 가능한 일정입니다. 그정도로 타이트하게 요구합니다.) 그런데 여러 요구사항과 개발 완료 직전에 개념 없이 이런저런 개발 내용 변경을 요구하는 경우 답 안나오는 상황이 많습니다.

이런 경우 시스템 발주전 요구조사등이 병행 되는데 이런 문제를 제대로 진행하지 못하는 경우도 있습니다. 물론 이번 같은 경우는 삼성에서 요구조사등을 통해 설계를 했겠지만요.


나이스(NEIS) 사태, 삼성SDS가 저정도면 일반 개발사는 개발도 못했음
말씀드리기 앞서서 저도 한국의 3대 SI 업체 다 싫어합니다. 여러 하청 문제도 있고 등등해서 싫어하는데 이번글이 삼성 SDS를 찬양하기 위한 글이 아니라 한국 IT 시스템에 문제를 지적하려는 글인만큼 다소 삼성 입장에서 쓴글이라도 양해를 부탁드립니다.

삼성 SDS 정도의 한국의 SI 업체는 중소 규모 회사에선 갖추기 힘든 시스템을 갖추고 있습니다. 법무팀, 재무팀, 감리팀.. 등 생각보다 잘 구성되어 있고(시스템 자체론 그나마 가장 글로벌 스텐더드에 적합하죠. 그나마...) 제법 체계적으로 운영되는 회사입니다.

예를들면 전자 정부 구축 사업을 했다 칩시다. 그럼 영업(기획 팀이라 해야 할까요?) 암튼 이 팀에 소속된 담당자(상당한 경력 소유자들 입니다.) 가 협상해서 반설계 수준의 개발 범위등을확정하고 실 설계팀에 인계되 DB 설계등이 이루어진 후 개발 인력이 투입됩니다.

개발 인력 투입후 어느정도 알파 테스트와 베타 테스트가 끝나고 고객 감수가 끝나고 나면 실제 테스터 팀이 투입되 테스트가 진행되고 겸해서 문서 작성과 뒷정리 하는 팀이 투입되 말 그대로 개발자는 그나마 개발에만 전념 할 수 있는 환경입니다. (사실 뒷정리하는 팀도 만만치 않습니다. 발주 전단계에 정부에서 요구하는 문서만 수백가지에 양으로 치면 몇천쪽 나오는데 뒷정리 시에도 그에 상응하는 양이 나오거든요 20억원짜리 개발 문서 보세요 죽습니다. ㅠㅠ)

그런데 이런 회사가 위사태를 만들었다는 것은 개발 팀 자체의 문제도 있었을 수 있지만 기본적으로 정부의 시스템에 문제가 없었는지 살펴 볼 필요가 있다는 것이 제 생각입니다.


나이스(NEIS) 검증 한다고 되는건가?
실제 검증 어쩌고 떠드는데.. 논의 단계부터 개발 내용을 깊숙히 들여다 본 인력이 아니면 검증 쉽지 않습니다. 검증 테스트 툴로 검증한다면 안하느니만 못하고 외무 인력이 투입되 검증 한다면 제대로 된 검증을 위해서 수십만 라인의 코드 리스트와 프로그램 리스트를 일일이 확인해야 하는데 시간도 그렇고 불가능한 일입니다.

그럼 실제 이런 사태의 원인이 될 수 있는 요소는 무었일까? 일단, 촉박한 시간일 가능성이 있고(한국은 개발 시간만 고려되거든요. 테스트 시간은 개발 시간에 일부 포함됩니다.), 두번째로 적은 개발 인력이 있었을 수 있습니다. 7명의 개발인력이 투입되었다곤 하지만 하청 인력등을 고려하고 그정도 금액 베이스면 프리랜서까지 최소 10~20명 이상의 인력이 관여 됐을 가능성이 높습니다. (원래는 더 관여되지만 초기 개발이 아닌 업그레이드에 준하고 삼성이 원래 설계했기에 인력이 다소 적게 투입 됬을 가능성은 있습니다.)

이정도 인력과 난이도를 생각하면 초 고급 아키텍처와 개발 인력이 투입되고 DB 설계는 외국등에서 프리랜서를 활용했을 가능성이 있기에 설계상이나 개발상 실수보다 실 데이터 입력을 통한 실 테스트의 문제가 되었을 가능성이 더 높은 것입니다.

더군다나 정보 노출의 우려등으로 3년전 데이터를 활용했고 이마저도 테스트 시간이 부족했다는 이야기들이 흘러나오는 것을 보면 개발 일정이 타이트했다는 것을 짐작할 수 있죠?

이런 문제는 검증 시스템도 시스템이지만 실제 이런 프로젝트를 제대로 이끌고 윗선에서 흔드는 행위에 더 큰 영향을 받을 수 있다는 사실을 알아야 할 것 같습니다. 그리고 이런 시스템 개발은 궁극에는 개발보다 테스트에 더 많은 시간이 소요되는데 이런 사실을 인지하고 있던 정책 결정자가 있었을까? (밑에 사람이야 윗사람 눈치보는 조직이 공무원 조직 아닙니까?)


이 문제 해결을 위해 필요한 시스템 개혁은 검증이 아닌 사회자체를 개선해야
문제 해결을 위해 검증 시스템을 구축해야 한다고 하는데.. 실제 그런 검증을 시스템 단위로 제대로 해낼 인력이 몇이나 있는지 모르겠습니다.

시스템 설계를 한눈에 꽤뚫어 볼 정도 능력자가 있어야 하는데 기업도 아니고 정부에 그런 인력을 수급 할 능력이 되는지 모르겠습니다. 그정도 인력이면 연봉도 연봉이고 실제 사회 시스템상 현업에 있을 가능성이 거의 없기 때문에 단가도 그렇고 IT 수요가 많은 정부에서 몇몇이나 고용 할 수 있을지 의문입니다. ㅡㅡ; (결국 고용해도 한명이 수십가지 일을해야 겠지요. 공무원이라 이핑계 저핑계대고 안하려나?)

또, 이런 문제의 발단은 정부에서 개발사에 발주 요청을 하기 전부터 문제가 발생합니다. 제대로 된 RFP를 통해 정확한 일정과 단가 후려쳐 깍는 행위가 아니라 개발이 원만하게 진행되기 위한 글로벌 스텐다드에 행하는 발주가 이루어져야 문제가 그나마 줄어들 수 있습니다.

또, 금액 베이스로 중소 규모 업체도 이런 프로젝트 참여를 할 수 있게 금액과 범위에 따라 개발사 역량에 따라 컨소시엄형태, 대형사 단독 형태, 중/소형사 단독 형태등 다양한 형태 발주가 이루어지고 발주 비용의 정삭적 분배가 가능한 시스템을 만들어야 중/소 개발사등이 육성되고 생태계가 정상화 되 개발 인력을 제대로 육성 할 수있는 길이 생깁니다.

이런 생태계를 만들어야 제대로된 감리/감수가 이루어 지고 검증 가능한 인력이 만들어져 검증 시스템이 제대로 동작하는 것이지요.


사태 심각하지만, 원론적인 문제를 접근해야 앞으로 재발 방지 가능하다.
이런 문제는 결국 후진적 IT 인프라와 정부 시스템에서 나오는 문제들 하나하나가 모여 크게 터진 일이라 볼 수 있습니다.

대기업의 하청 행태를 지적하기에 앞서 정부부터 스스로의 시스템에 문제가 없는지 살펴야 하는 것은 아닐까요? 자연적인 생태계 구축을 위해서 1인개발자 육성과 같은 말도 안되는 단기적 정책에 치중하지 말고 시스템부터 개발자 육성에 이르는 시스템 전반을 고민하고 대책을 내놔야 실효성이 있다고 생각합니다.

또, 이런 프로젝트는 무었보다 테스팅이 중요한데 실 데이터를 활용해 얼마나 테스트했고 테스트 할 환경은 얼마나 잘 구축되어 있는지 의심스럽습니다.

결국 기초와 기본에 충실할때 이런 문제가 해결 될 수 있다는 사실을 깨우치는 계기가 되었으면 좋겠습니다.


결론, 정부 IT 전담 조직이나 부서 만들어야
MB 정부가 집권초기 작은 정부를 만든다는 이유로 정통부를 해체하며 IT 컨트롤 타워가 없어지면서 이런저런 부서로 흩어졌죠? 정통부 자체도 여러 문제가 있긴 했지만 해체함으로 인해 발생한 인재가 상당하다고 전 분석하고 있습니다.

이번 사태도 이런 문제를 같이 연구하고 이런 문제를 효과적으로 컨트롤함은 물론 각 기관이 협력해 일을 진행 시킬 수 있는 컨트롤 타워가 필요하다 생각합니다.

여기에 각 부서별로 나뉘어 있는 IT 육성책을 하나로 모아서 개발자 육성, 기업 육성, 사회적 시스템 육성, 정부의 각종 IT 담당팀 역량 강화화 인력 수급 계획 구측등 장기적 로드맵이 필요하다 생각되고 이런 일을 담당 할 조직이 필요하다 생각되네요.

기술 트랜드만 생각해 하위 연구 기관과 기업에 하청 주는듯한 일만 하지말고 제대로 된 시스템을 만드는 일에도 이젠 눈을 떠주었으면 좋겠다는 생각과 이번 사태를 통해 원론적인 문제를 좀 더 집어내는 지혜를 바라며 이번글을 마무리 할까 합니다.