디지털예산회계시스템, 누가 책임질 것인가?
디지털예산회계시스템,
누가 책임질 것인가?
지난달 재정경제부가 상반기 재정수지를 17조8000억원이나 잘못 계산해 발표하는 웃지 못할 일이 벌어졌다. 600억원을 들여 개발한 ‘디지털예산회계시스템’이 관리 소홀과 오류로 인해 잘못된 결과를 산출해 낸 것이다. 이를 두고 재경부와 기획예산처가 저마다 책임소재 공방을 벌이고 있는 상황이다. 한편 이 시스템의 개발은 삼성SDS 컨소시엄이 맡았고, 재정수지 프로그램의 유지 보수는 컨소시엄 내 현대정보기술이 하고 있다. 그렇다면 개발자들은 이 사건을 어떻게 보고 있을 까 ‘자바서비스넷’ 게시판에서 벌어진 개발자들의 논쟁을 소개한다.
이번에 문제가 된 ‘디지털예산회계시스템’은 ▶국가재정운용계획 ▶예산총액배분 자율편성 ▶성과관리제도와 함께 4대 재정혁신과제 중 하나로 예산편성부터 집행, 회계·결산, 성과평가의 업무를 하나의 시스템에서 구동하는 통합재정정보시스템이다. 기획예산처는 지난 2004년부터 이 시스템 개발을 추진해왔으며 삼성SDS를 주사업자로 하는 컨소시엄이 구축 사업을 맡아 지난 1월 시스템을 가동했다.
하지만 시스템은 초기부터 말썽을 부려왔던 것으로 알려졌다. 한 인터넷 매체에 따르면 재정정책의 결정과정을 모두 시스템화해 효율적으로 관리하겠다는 기획예산처의 의도와 달리 ‘디지털예산회계시스템’은 홍보부족과 시스템오류, 상담센터 운영미숙 등으로 일선 공무원들이 사용에 큰 혼란을 빚어왔다는 것. 이에 기획예산처 웹사이트에는 시스템 사용의 어려움을 호소하고 개선을 요구하는 불만의 글이 끊이지 않았으며 상담센터에 문의전화가 쇄도했다. 특히 일선 공무원들은 시스템의 잦은 오류 발생과 교육부족으로 시스템을 이용하는 업무에 큰 어려움을 겪었다. 게다가 기획예산처가 이같은 어려움을 해소하겠다며 만든 상담센터는 전화연결이 잘 되지 않을 뿐 아니라 상담 후 조치가 미흡해 일선 공무원들의 비난을 받았다.
IT적 관점에서 접근해 보면 시스템에 대한 오류는 이미 초기부터 있었던 것으로 보인다. 그렇다면 개발자들이 보는 이번 사건의 문제는 무엇일까. 게시판을 통해 개진되는 의견을 살펴보면 열악한 개발환경과 프레임워크 부재에 대한 찬반 의견이 갈리고 있음을 알 수 있다. 특히 주무부처가 이번 사건의 원인으로 개발자의 실수를 지적하고 있는데 대해 개발자들은 목소리를 높이고 있다.
누구의 잘못인가?
(guest) | 책임은 당연히 책임자에게 있지만 원인은 개발자에게 뒤집어 씌우는 게 문제입니다. 그래서 각종 이메일과 문서화가 중요합니다. 고층빌딩 짖는 프로젝트가 건설도중 무너지거나 큰 결함을 발견하면 벽돌공, 전기공, 시멘트기술자 들이 책임인가요? ‘책임’은 그 회사에게 있는 것이고 세세히 원인을 따지면 그 프로젝트를 리드한 사람들의 책임입니다. 벽돌공 등이 실수했다 하더라도 그것을 못 잡아낸 것도 그 위의 능력부실이라 생각 듭니다. 그리고 통계적으로도 큰 프로젝트의 80-90%는 실패하잖아요. 요새도 저렇게 대규모 프로젝트를 진행하는지 실패 리스크가 크다는 것을 다 아는데 말이죠.
A(guest) | 벽돌공이면 물론 부실공사에 책임은 없습니다. 하지만 여기서 생각해봅시다. “시키는 대로 한 것뿐이니 난 책임이 없어요” 하고 하는 벽돌공이 원하는 모습입니까? 벽돌공은 건축분야에서 대우를 못 받습니다. 단순한 일이고 아무나 하는 일이고 책임도 없습니다. 요즘 프로그래머의 현실을 보는 듯 합니다. 대기업들은 말많고 탈 많은 저급 개발자들에 시달리며 불량시스템에 의해 고객에게 원성 받는데 지쳐있습니다. 그들이 힘을 쏟고 있는 부분은 아시는 분들은 아시겠지만 개발방법론, 표준화, 프레임워크입니다. 간단히 말하면 누구에게나 맡겨도 일정 이상의 품질을 적은 비용으로 만들어내는 시스템을 구축하겠다는 의미입니다. 개인의 노하우와 스킬에 의지하는 개발방식을 철저하게 거부하고 표준화에 툴에 의한 적정품질의 결과물을 내겠다는 말이죠. 제가 있는곳을 예를 들겠습니다. 기존 방식이라면 1000명이 2년 정도 걸려 구축하는 규모입니다. 현재 새로운 방식으로 시도중입니다. 표준화에 20명, 프레임워크에 20명 , 업무개발자는 200명 정도입니다. 표준화가 전 공정과 개발범위, 테스트 범위 방법 툴까지 상세하게 규정합니다. 프레임워크에선 개발방식규정, 검증, 프레임워크개발, 개발자용 개발 가이드 작성을 합니다. 모든 문제는 표준화그룹과 프레임워크에서 해결합니다. 철저하게 개발자의 능력과 노하우와 스킬을 무시합니다.
(guest) | 프레임워크을 너무 맹신하시는 거 아닌가 하는 생각이 드는군요. 프레임워크이 일정부분 품질을 보장하기는 하지만 그것도 한계가 분명히 있습니다. 같은 프레임워크을 사용 해도 품질은 천지차더군요. 말씀하시는 바에는 일정부분 동의하는 것도 있지만, 이번 문제에 있어서 개발자들에게 잘못을 뒤집어씌우는 듯한 행태는 결코 옳지 않다고 생각합니다. 물론 해당 개발자들도 잘못이 있는 것은 사실이지만, 과연 관리가 제대로 이루어졌다면 이런 일이 일어났을까 라는 의문이 듭니다. 그리고 얘기를 들어보니 해당 프로젝트가 진행할 때 문제가 많았다고 하던데(분석, 설계가 제대로 이루어지지 않았다는 등), 우리나라의 실정 상 이런 상황에서 좋은 품질을 기대하는 것은 어렵다고 봅니다.
(guest) | 현재 많은 PI프로젝트들에서 CMD 방식으로 공통팀과 업무구현팀으로 나누어서 개발을 합니다만 가만히 생각해보면 현재 2007년인데요 2010년 정도 되면 그냥 업무현업이 WIZWIG 방식으로 자기가 쓸 소프트웨어 제작이 가능해야 될 것 같은 생각이 듭니다. 그런데 3년 후에 그런 미래사회가 될 수 있을지 의문입니다. 공학분야에서 로봇제작기술은 매우 성숙해있지만 인간의 마지막 로망인 가정부 로봇(파티 도우미 같은)은 50년 후에도 만들어 질 수 있을지 의문이라고 합니다. 로봇이 너무 많은 케이스를 다루어야 한다고 하네요. 제가 너무 단순비교인지는 모르지만 프로젝트의 운용모습이 현대 과학의 딜레마처럼 느껴지군요. 현재 금융, 제조업 등에서 이루어지는 SI프로젝트를 노하우와 스킬을 무시한 중국이나, 북한 개발자로 구성해서 과연 제대로 이루어질 수 있을지 의문입니다.
A(guest) | 분명한 것은 업계를 주도하는 세력들이 추구하려고 하는 방향이 개발자 개개인의 능력향상이나 불만해소, 근무환경개선 등이 아니라는 겁니다. 주도세력의 전략과 방향이 어떠한가를 인식하고 개개인이 준비하는 수밖에 없다고 생각합니다. 로봇 말씀을 하셨는데 개념이 다르다고 봅니다. 그들이 하려는 일은 인공지능소프트를 만들겠다는 것도 아니고 단순개발자를 없애겠다는 것도 아닙니다. 단지 개발자를 단순직으로 만들고 싶은 것 뿐입니다. 요즘 말들 많은 실패 프로젝트들의 문제가 뭡니까? 제일 큰 원인은 여러분들이 말씀하시는 것처럼 요구사항분석실패, 규정되지 않은 사양, 지켜지지 않는 공정관리, 미숙련자에 의한 설계, 스케줄 관리의 부실, 범위를 빗나간 테스트 등입니다. 이러한 문제들은 정답이 없습니다. 왜냐하면 시스템마다 특성이 다르고 고객마다 원하는 게 다르고 원하는 결과물이 다르고, 무엇보다도 사람머리에 의존합니다. 스킬에 의존합니다. 정형화되어 있는 게 없습니다. 이러니 해결책은 제가 말씀드린 것처럼 제조공정에 포인트를 둡니다. 견적이 작아도 이익이 나오게 끔. 사양이 바뀌어도 쉽게 고칠 수 있게 끔. 그게 표준화와 프레임워크입니다.
책임 있는 자세가 필요
(guest) | 요새 몇몇 개발자들은 아직도 뭔가를 대단히 착각하지 않나 싶습니다만, C/C++에서 온 사람들 같은 마인드는 버려야 합니다. 당연히 프레임워크과 스탠다드를 씀으로써 더 빠르게 더 저렴하게 문제가 덜 있게 하는 것이죠. 비즈니스(매니지먼트)를 포함, 모든 사람은 모든 것을 efficient, effective하게 하려는 게 당연한 것이고 그것이 살아남는 방법입니다. 언제까지 데이터 스트럭처 기본을 짜고 있나요? 기업에서 자바가 널리 쓰이게 된 이유자체가 공통분모를 마련하였기 때문입니다. Write once, Run Everywhere는 큰 이유가 아닙니다. 기본기를 익히는 것은 물론이지만 그 후로는 높은 레벨로 올라가야지요.
(guest) | 여태껏 모든 개발자 사이트에서 실패한 프로젝트의 원인에 관련한 글 중에 개발자 탓이라는 글을 단 한 건도 본적이 없습니다. 그 수많은 실패 사례 중 개발자들의 인식부족 실력부족 마인드 결핍이 이유가 된 적이 한번도 없을까요? 아무리 팔은 안으로 굽는다지만 실패의 원인을 한가지(주로 을의 관리실패)로 몰아가는 분위기는 좋지 않다고 봅니다 관리 실패했다고 해도 개발자들이 잘못을 지적하고 수정했다면 실패는 없었겠죠. 아무리 봐도 책임회피라고 밖에는 생각할 수 없습니다. 축구경기에서 성의 없는 플레이로 게임에 져도 감독만 바뀌는 것과 비슷하게 느껴지는 건 저만 일까요? 관리감독 못하고 선수들 독려하지 못하고, 전술부재인 감독도 분명 잘못이지만 감독 혼자만의 잘못일까요?
(guest) | 물론 진짜 실력이 없는 사람이 있긴 있습니다. 개발자에게 책임이 있다면 해당 업무 프로세스를 모른다는 것에 있겠지요. 그런데 어떤 개발자든 심지어 10년이 지난 개발자라 하더라도 아니 10년이 지난 개발자면 더욱더 조심스럽게 프로세스에, 특히 산식에 문제가 없는지 확인했을 것입니다. 그런데 600억씩이나 하는 프로젝트에 국가 조세관련 프로젝트를 저따위 날림으로 한 것을 일개 개발자에게 책임을 전가하는 것이 과연 옳은 모습일까요? 감독도 선수 선발권이란 것이 있습니다. 필드에 주전으로 내세울 수 있는 권한이 있습니다. 물론 선수가 페널티킥을 못 넣는다 던지, 자살골 넣는 경우도 분명 존재합니다. 그런데 그때마다 선수잘못만 탓하고 매번 경기에 진다면 그게 감독으로서 할 소리는 아니라 봅니다. 더더군다나 문제가 최초 터진 상황에서의 대처한 것을 보면 더더욱 이해가 안되는 부분이죠. 물론 세세한 정황을 모르는 것으로 인해 함부로 예단한다는 점이 없진 않습니다만, 애초에 잘못 뛰는 선수를 가려내지 못한 책임이 감독에게 없다는 것은 아니라 보아집니다. 그 지위가 있는 만큼 그 책임이 있는데, 그럼 애초에 그런 해당 프로젝트에 왜 적합한 사람을 투입하지 못했는지 알고 싶군요.
김지섭(hl2ajd) ｜ 회계 시스템의 근간은 코드입니다. 예산의 집행 결과 집계가 잘못되었다면 가장 흔한 경우가 코드에 따른 비용의 집계입니다. 따라서 집계 프로그램에서 코드를 잘못 다뤄 다른 계정으로 합산했을 가능성이 크다고 봅니다. 이런 경우라면 다들 잘 아시겠지만 ▶현업에서 제대로 로직을 알려주지 않은 경우 ▶컨설팅업체에서 제대로 설계 및 감리하지 못한 경우 ▶개발자가 잘못한 경우가 있습니다. 하지만 정말 거대한 국세 혹은 대기업의 회계시스템을 하드코딩으로 처리하도록 만드는 건 한심한 수준이고 코드의 범위나 구성 방법에 따라 상위 코드로 금액이 합산 되도록 설계되었을 것으로 가정해 보면 현업에서 잘못된 로직을 전달했거나 운영을 잘못한 것으로 보입니다.
(guest) | 그냥 상식적인 선에서 말하자면 정부, 삼성SDS, 개발자 등 모든 관련자가 팀이었고 팀이 진 겁니다. 팀이 졌는데 그 중에 누가 제일 잘못했는지 따지는 게 무슨 의미가 있겠습니까. 전원 잘못한 거지요. 먼저 600억이라는 개발비 자체가 실패의 시작이 아니었나 싶습니다. 정말 600억 짜리 인력과 시간이 필요한 프로젝트였을까? 이런 질문을 던져 보는 것이 먼저가 아닐까요? 큰 프로젝트는 실패 확률이 아주 높다는 거, 경력 3년 짜리 개발자도 다 압니다. 근데도 끊임없이 저런 프로젝트들이 발주되는 상황, 어쩌면 이게 문제의 핵심인지 모릅니다. 그렇게 본다면 프로젝트란 것에 대한 이해도가 낮은 발주처의 책임이 가장 큰 것이겠지요.
(guest) | 당연히 책임은 발주사와 수행사에 있는 것입니다. 개발자는 단순한 노동자일 뿐입니다. 책임을 지는 사람은 그만큼 많은 권한을 갖게 됩니다. 프로젝트 전체에 대해 통제하고, 관리하고, 협상하는 권한이 있는거죠. 그런 사람들이 개발자의 능력을 가늠하고, 필요한 만큼 뽑아서, 개발을 시키는 겁니다. 그리고, 그 개발은 설계자가 던져준 문서에 따라 그대로 코딩을 하게 됩니다. 코딩이 끝나면 테스트계획에 따라 테스트를 끝내고 통과하면 끝입니다. 개발자라는 존재가 엄청나게 대단한 어떤 그런 존재가 아닙니다. 혼자 시스템 전체를 좌지우지 할 능력도 안될뿐더러, 문제가 있다고 해서 그 문제를 제기해도 괜히 미운털만 박히게 되는 게 지금의 현실입니다. 600억이라면, 당연히 설계자와 개발자가 분리되어 일하는 것이고, 개발자는 설계자가 던져주는 설계문서에 따라 그대로 코딩을 하는 것 뿐입니다. 이 현실을 무시하고, 마치 개발자들이 무슨 대단한 철학과 이상을 가진 기술자인양 얘기하시는걸 보면, 이 업계의 현실을 너무 모르는 것 같은 생각이 듭니다. 개발자가 단순노동자로 되어가는 건 시대의 흐름입니다. 프로젝트는 갈수록 대형화 되어가고 있고, 그 과정에서 마치 자동차 공장처럼 개발자들은 자신이 맡은 파트에서 열심히 나사를 돌리고 있는 것 뿐입니다.
(guest) | 여러 사람의 잘못이다라는 부분 공감합니다. 그런데 현재의 문제의 핵심이 무엇입니까? 개발자만 잘못이 있다고 호도하니 문제인 것입니다. 업무의 프로세스를 정리하는 부분에서 그 설계나 로직 담당을 일개 개발사에게 턴키로 넘기는 경우가 대부분입니다. 말 그대로 얼굴마담이지요. 그런데 문제가 생기니 발을 빼고 이리저리 책임 회피하는 것입니다. 실제로 프로젝트 해보신 분들도 알지만 빡빡한 일정을 줍니다. 현업 이야기 하셨는데 현업 중에서도 자기 일 정확하게 아는 사람 솔직히 있으면 정말 해피(Happy)한 프로젝트입니다. 두루뭉실하게 어떻게 해달라는 담당자 부지기수입니다. 위에 개발자들의 실력으로 은근히 몰고 가려는 분들이 간혹 계시는데 호도하지 말기를 바랍니다. 어떤 시스템이건 문제가 있기 마련입니다. 불완전한 사람이 만든 프로그램이 완전하다고 믿지는 않으시겠지요. 단지 그 불완전함을 보완하기 위해 이런 저런 방법과 테스트와 검증을 계속 하는 것입니다. 자 그럼 빡빡한 일정은 무엇을 이야기합니까? 당연히 테스트하거나 검증할 기간이 태부족하다는 것입니다. 개발자들의 고민은 단순히 웹페이지 몇 장 만드는데 있지 않고 그것이 과연 제대로 된 로직인가에 항상 조바심을 느낍니다. 그런데 시간이 없다면 어떻게 하겠습니까? 그야말로 여러 케이스에 대한 검증을 수행 못합니다. 물론 능력과 경험으로 해당되는 부분을 커버할 수는 있을지도 모릅니다만, 큰 규모의 프로젝트에서는 몇몇의 사람만으로는 안됩니다. 이번의 경우 1차적으로 문제의 징후가 보였습니다. 어느 시스템이나 문제의 징후는 보이기 마련입니다. 그런데 대처한 형태를 보면 우습기 그지없습니다. 이번의 문제의 원인 중에서 국가예산 관련된 전문성이 현저히 떨어진 것으로 보입니다.
출처 : 경영과컴퓨터 [2007년 10월호]
다음 디지털예산회계시스템
디지털예산회계시스템, 누가 책임질 것인가? 2007.10.25
디지털예산회계시스템, 누가 책임질 것인가? 지난달 재정경제부가 상반기 재정수지를 17조8000억원이나 잘못 계산해...600억원을 들여 개발한 ‘디지털예산회계시스템’이 관리 소홀과 오류로 인해 잘못된 결과를 산출해 낸 것이다. 이를...
http://blog.naver.com/nugu99 .