2024-03-29 05:20 (금)
차세대 골칫거리 ‘나이스’, 무엇이 문제였나
상태바
차세대 골칫거리 ‘나이스’, 무엇이 문제였나
  • 길민권
  • 승인 2011.07.26 11:27
이 기사를 공유합니다

나이스 사태는 열악한 한국 개발환경이 낳은 산물
개발자에게 모든 책임전가 말고 개발환경이 어떤지를 보라
부동수소점 사용이 문제…근본적 오류수정안되면 재발 가능성 커
지난 7월 22일, 사상 초유의 2만 9,000명에 달하는 학생들의 성적처리 오류사태가 발생했다. 삼성SDS가 담당한 차세대 나이스(NEIS. 교육행정정보시스템)가 문제였다. 8월 1일부터 있을 대입 수시모집 직전에 발생한 사태라 학생과 학부모들의 충격이 큰 상태다. 신속한 처리와 재발방지대책 마련은 교과부에서 알아서 할 일이지만 왜 이런 문제가 발생했는지, 다른 시각에서 봐야 할 점은 없는지 살펴볼 필요가 있다. (사진출처. www.flickr.com / by Mers)
 
일부 언론보도에 따르면, 한국교육학술정보원에서 23일 “차세대 나이스 프로그램 개발 업체인 삼성SDS 프로그래머들의 실수가 있었다” “나이스에서 성적과 관련된 프로그램은 삼성SDS의 프로그래머 7명이 맡아 제작했는데 프로그램을 정밀하게 짜지 못했다” 등으로 발표했다. 모 교과부 관계자는 “일단 문제 해결하는 것이 급선무지만 개발자에게 원초적 책임이 있다”고 말했다. 즉 모든 책임은 프로그램을 개발한 개발자에게 있다는 논리다.
 
◇개발자에게만 책임 전가해서는 안돼=이경문(네트워크 개발자)씨는 자신이 운영하는 홈페이지(http://www.gilgil.net/)를 통해 이번 나이스 사태와 관련해 모든 것을 힘없는 말단 개발자에게만 책임을 전가해서는 안된다고 주장하고 몇 가지 교과부와 언론의 잘못된 내용발표에 대해 기술적 설명을 추가했다. 
 
그는 “SW개발은 코딩에서부터 무수히 많은 에러가 발생할 수 있다. 그러한 에러를 보정하기 위해 무수히 많은 단계를 거치게 된다.. unit 테스트, 통합 테스트, QA 및 QC, 등등. 그리고 NEIS정도의 규모라면 단순 개발 단위의 테스트뿐만 아니라 전문적인 인력을 동원해 감리 과정까지 거쳤을 것이다. 그런데 개발자에게 원초적인 책임이 있다는 말은 이해가 안된다”고 말했다.
 
또한 SI업체에 대한 문제도 지적했다. “언론에서는 삼성SDS 프로그래머들의 실수가 있었다고 나오는데 삼성SDS가 언제 설계와 코딩작업을 했는지 모르겠다. 대부분 하청을 주기 때문에 나이스 코딩 작업도 외부 하청업체에서 했을 것”이라고 추정했다. 이런 상황에서 하청업체 개발자에게 모든 책임을 덮어씌우는 것은 터무니 없는 소리라는 것. 정치바닥에서 발생하는 여러 사건들에서 몸통은 잡지 못하고 애꿎은 꼬리만 잡아 처벌하는 것과 같은 이치라는 것이다.
 
그는 또 언론을 통해 보도된 여러 잘못된 기술적 부분에 대해서도 지적했다. 모 언론사에서 <소수점 이하 자릿수 가운데 평가 결과와 상관없는 '1'이란 숫자가 느닷없이 표시되는 현상이 발생해 고교생 2만9,000명의 내신석차가 틀렸다>는 보도에 대해 그는 “컴퓨터는 Garbage In Garbage Out이다. 쓰레기 값이 들어 가면 쓰레기 처리가 된다는 말. 즉, 다시 말해서 올바른 입력이 되었다면 올바르게 나올 수 밖에 없다는 것이다. ‘느닷없이’가 아니라 기술적인 측면에서 정확한 원인을 파악해야 한다”고 강조했다.
 
또 <통상 컴퓨터가 숫자를 처리하는 과정에선 이처럼 엉뚱한 수치(이른바 '쓰레기값')가 나오는 경우가 드물게 발생하는데 이를 잡아주는 작업을 실수로 빠뜨렸다는 것이다. 관계자는 "쓰레기값은 소수점 이하 16개 자릿수 중 일정한 자리에서 발생한 것이 아니라 불규칙적으로 여러 자리에서 나왔다"고 했다.>는 언론보도에 대해서도 지적했다.  
 
그는 “말이 안나온다. HW 고장이 아닌 이상, 컴퓨터는 거짓말을 하는 법이 없다. 쓰레기값이라니. 근본 원리를 모르기 때문에 이러한 변명이 가능하다고 생각한다”고 말했다.
 
또 <문제는 컴퓨터가 소수점 32번째 자리까지 인식을 하고 마지막 자리에는 임의의 숫자를 붙인다는 점. 이에 따라 프로그램 개발자는 통상 소수점 16번째 자리까지만 값을 인식하도록 인위적으로 계산 방식을 보정해야 한다. 이번 사태는 이 보정 과정을 빼먹으면서 일어난 것>이라는 보도내용에 대해 그는 이렇게 말했다.
 
“혹시나 했는데, 해당 기사를 보고 확실히 알게 됐다. 역시나 점수 처리에 부동소수점을 사용하고 있다는 것이다. 할 말이 없다. 정확한 수치 표현을 해야 하는 곳에서 부동소수점을 이용한 것”이라며 “요즘에는 64bit CPU가 보급이 되었지만, 아직까지도 32bit CPU를 많이 사용한다. 숫자를 표현하는 데 있어서 float와 같은 32bit형 부동소수점 타입을 사용한다는 말을 가지고 소수점 32번째라고 표현을 한 것”이라고 설명했다.
 
◇부동소수점 사용이 화근=그에게서 보다 기술적인 설명을 들어봤다.  그는 “컴퓨터에서는 숫자를 표현하는데 있어서는 BCD(binary-coded decimal)방식이라는 게 있다. 지금은 거의 쓰지는 않지만 예전 프레임워크에서는 종종 볼 수가 있다. BCD 방식은 하나의 십진수를 표현하기 위해서 4개의 bit를 사용하는 방식이다. 예를 들면 ‘64’를 표현하기 위해서는 ‘0110 0100’이라고 표기하는것이다. 이 방식(BCD 방식)은 정수뿐만 아니라 부동소수점을 표현할 때에서도 초기에는 BCD 표기법이 채택이 되었었다. 왜냐하면 인간에게 익숙하기 때문이다. 하지만 BCD는 bit의 낭비를 가져 오고 CPU 디자인이 복잡해 지는 단점들이 있다. 그래서 요즘에는 대개가 정수나 소수 모두 BCD를 사용하지 않고 순수 2진수 기반으로 처리를 하는 것이 일반화되었다”고 설명했다.
 
즉 부동소수점에서 숫자의 표현은 1/2, 1/4, 1/8... 등의 조합으로 숫자를 표현을 한다는 것이다.
 
그는 “쉽게 말하면, 컴퓨터는 1/2(0.5), 1/4(0.25), 1/8(0.125), 1/16(0.0625)과 같은 숫자들은 컴퓨터로 정확하게 표시를 할 수 있다. 0.75는 0.5와 0.25의 덧셈으도 쉽게 표현할 수 있다. 하지만 0.6과 같은 숫자는 정확히 표현할 수가 없다. 이는 십진수에서 1/5는 0.2로 정확히 표현할 수 있는 반면에 1/3은 0.3333…으로 정확하게 표시를 하지 못하고 근사값(0.3333)으로밖에 표시를 하지 못하는 것과 동일한 원리”라고 덧붙였다.
 
다시 말해서 인간은 10진수에 익숙해 있는 반면에 컴퓨터는(정수 표현이든 소수 표현이든) 2진수 기반으로 처리를 하고 있으며 10진수로 쉽게 표현할 수 있는 숫자가 2진수로 표현하려면 정확하지 못할 수도 있다는 것이다. 그 현상을 "쓰레기값이 나온다"라고 언급하는 것은 무리라고 그는 주장한다.
 
좀더 자세히 살펴보면 이렇다. 위에서 말했듯이 컴퓨터는 0.25를 정확히 표현을 할 수가 있다고 했다. 0.25를 만번 더해 보고 그에 대한 결과를 보자.

 
결과는 2500으로 정확하게 나온다. 
 
자, 이제는 0.25가 아닌 0.6(컴퓨터가 정확히 표현하지 못하는 숫자)을 만번 더해 보자. 위의 코드에서 0.25를 0.6으로만 바꾸어 실행을 해보자.


 
결과는 6000.58이 나온다. 6000이라는 정확한 결과가 도출되지 않는다는 것. 
 
이렇게 나오는 이유는 간단하다. 이경문씨의 설명에 따르면, 십진수에서 2/3은 0.666666..(무한대)이 되어야 하는데 자리수 표현의 한계가 있다 보니 0.66667 정도로만 표시를 하고 이 값을 가지고 연산을 하다 보면 엉뚱한 값이 나올 수 있는 것과 마찬가지라는 것. 다시 말해서 십진수에서 무리수를 표현하지 못하는 한계를 알고 있다면 2진수에서도 똑같은 현상이 나타날 수가 있고, 인간에게 익숙한 십진수의 특정 숫자(예 0.6)가 컴퓨터로 표현을 하게 되면 정밀하지 못할 수 있다는 것은 상식적으로 알고 있어야 한다고 그는 말한다.
 
그는 “그런데 기사를 보면 웃음만 나온다. 이것은 프로그래머의 실수가 아니라 소수를 표현하는 데 있어서 100% 정밀하지 못한 타입을 사용했기 때문”이라며 “보정을 해야 한다고 하는데, 이것은 보정한다고 해서 해결될 일이 아니다. 숫자의 범위가 커지면, 또 언제 발생할 지도 모르는 일이기 때문이다. 그리고 설령 보정을 했다 하더라도 이러한 근본 원리를 모르는 상태에서 보정 후 결과가 제대로 나온 것을 case by case별로만 확인하고 넘어 간다면, 이번과 같은 실수가 또 발생하지 않을 것이란 보장은 없다”고 강조했다.
 
◇근본적 수정없이는 또 다시 문제발생할 것=그는 이번 문제 해결 방안은 점수를 표현할 때 처음부터 부동수소점을 사용하지 않아야 한다고 강조했다. 그는 “성적처리를 하는데 정수로 처리를 하도록 전체 설계 방식을 바꾸거나, 굳이 소수점을 사용해야 한다면 BigFloat와 같이 무한대의 정밀도를 지원하는 클래스를 설계해서 사용을 해야 한다”며 “이에 따른 DB처리 방식도 바꿔야 한다. 결국 시스템의 많은 부분을 바꾸어야 한다는 것이다. 상식적으로 이러한 일은 하루 이틀에 끝날 일도 아니고, 최소한 몇개월 작업을 해야 하는 것인데 당장 수시접수 처리를 해야 하는 마당에 근본적인 해결 없이 땜빵으로 처리를 하지 않을까 걱정이다. 이렇게 되면 결국 잠재적인 버그를 항상 가지고 가는 시스템을 계속해서 가지고 갈 수 밖에 없고 문제가 발생하면 또 프로그래머가 모든 잘못을 뒤집어 써야 하는 상황이 발생할 것”이라고 안타까워했다.
 
이경문씨는 “최소한의 전산 지식이 있는 사람이 프로젝트 진행 도중에 이러한 잠재 버그의 가능성을 강조했었다면 발생하지 않아도 되는 버그였다. 왜 그런 부분을 지적하지 않았을까 의문”이라며 “근본 원인을 가정해보면 이러한 현상(부동소수점은 정확한 숫자 표현을 하지 못한다)을 프로젝트 참여자들 중에 한명도 모랐다는 것은 말이 안된다. 그것보다도 무리한 일정에 빨리 기능 구현을 해야 하는 시간적 압박감 그리고 잠재적 버그라고 계속 강조해서 말하면 소위 찍힐 수도 있는 개발문화가 개발자들에게 큰 부담감으로 작용했을 가능성이 크다. 답답한 현실이고 바뀌어야 할 부분”이라고 말을 맺었다. [출처. www.gilgil.net / 데일리시큐=길민권 기자] 
■ 보안 사건사고 제보 하기

▷ 이메일 : mkgil@dailysecu.com

▷ 제보 내용 : 보안 관련 어떤 내용이든 제보를 기다립니다!

▷ 광고문의 : jywoo@dailysecu.com

★정보보안 대표 미디어 데일리시큐 / Dailysecu, Korea's leading security media!★