오늘 아침에 기사를 뒤져보다가 우연히 형사사법정보시스템 KICS의 문제점을 지적하는 기사를 보게되었습니다. KICS는 법무부에서 지난해 5월에 오픈, 운영하고 있는 경찰, 검찰, 법원, 법무부가

사법 관련 정보를 운영하는 형사사법정보시스템이자 동시에 대국민 포털입니다.
http://www.kics.go.kr/

그런데 일선 경찰관들로부터 이 KICS에 대한 불만이 속출한다고 합니다.
“절도사건 전산 입력에만 4시간… 속 터진다 “

뒤져보니, 지난해 5월 KICS가 개통된 직후부터 이와 같은 문제점을 지적하는 기사가 여럿 나오더군요.
‘종이없는 수사’ 정신없는 경찰… KICS 시행 1주일 시스템오류등 빈번 내부 불만 목소리 (2010.5.18)
경찰, 형사 사건 전자문서 작성 진땀 (2010.5.19)
일선 경찰 ‘KICS’ 업무가중·수사간섭 호소 (2010.5.12)
형사사법정보시스템 ‘사용 불안’ (2010.9.28)

형사사법정보시스템에 대해 공개된 문서들을 살펴본 결과, 이 KICS는 대민 서비스용 포털 뿐만 아니라 업무용 정보시스템까지 포함해서 전면적으로 웹 기반으로 개발된 것으로 보입니다. 데이터 표현 방식 항목에 대해 HTML 전면 적용으로 되어 있고, 컨텐츠에 대해 DHTML, CSS 등이 전면 적용으로 명시되어 있고, 외부에서 접근하는 장치로 웹브라우저를 지정해놓은 것을 보면 아예 처음부터 웹 이외에 대해서는 고려 자체를 하지 않은 것으로 보입니다. 특히 초기 사업계획서에 WAS, CBD, X-Internet 등이 명시된 것을 보면 아예 자바를 박고 시작한 거네요. 자바 + X인터넷… 요즘 가장 유행하는 묻지마 시스템 구성이군요.

제가 보기에, 여러 기사들에서 거론된 문제의 핵심은 사용자 편의성, userbility입니다. (userbility는 단순히 편의만 따지는 개념이 아니기 때문에 보통 ‘사용성’이라고 번역하지만… 사용성이라는 단어는 너무 추상적이어서 오히려 듣기에 의미가 왜곡되는 면도 있어서, 저는 사용자 편의성이라고 쓰겠습니다)

X인터넷이나 플래시, 실버라이트 등도 보기좋은 정도를 제외하면 실질적인 사용자 편의성에서는 웹과 별반 차이가 없습니다. 온갖 디자인을 갖다붙이더라도 실제 사용자의 편의성과는 무관합니다. 즉, UX에서는 뛰어날 수 있어도 userbility가 떨어집니다. 여러 차이가 있지만, 가장 근본적으로는, 이런 RIA 솔루션들에서는 해당 시스템에 적합한 새로운 입력/출력 컴포넌트를 새로 만들거나 수정하는 것이 거의 불가능하거나 아주 어렵고 번거로워 현실적이지 못하기 때문입니다.

정보시스템에 어쩔 수 없이 입력량이 많고 업무상 줄일 수 없는 경우, 예쁜 화면이나 유행 등을 떠나 사용자 편의성에 대한 고려가 최우선이 되어야 합니다. UI, UX는 궁극적으로 사용자 편의성을 지향해야지, 사용자 편의성을 도외시한 예쁘고 화려한 것은 오히려 사용자 편의성을 떨어뜨립니다. 그러려면 해당 시스템에 가장 적절한 최적의 UI 컴포넌트를 사용하고 전체 입력 제어에 대한 아키텍처가 설계 단계에서 충분히 고려되어야 하는데요. 웹이나 RIA에서는 이런 설계는 커녕 기본 기능 구현조차 어렵습니다.

예를 들어 몇년 전 제가 전산실장으로 근무했던 모 결혼정보회사의 경우, 최초 회원 가입시에 입력할 정보가 필드 갯수로만 400개가 넘었는데요. 기존의 웹 기반 시스템에서 제가 신규 회원 1명의 가입신청서를 입력하는 데에 40분 가량 걸리더군요. 저보다 키보드에 덜 익숙한 커플매니저들이 입력하는 데에는 1시간 이상 걸리기 때문에, 입력 담당자를 따로 아르바이트로 고용해서 입력했습니다만, 그래도 20~30분이 걸렸습니다. 우여곡절 끝에 저와 팀원들이 델파이 기반으로 새로운 시스템을 개통한 후, 제가 입력하는 시간 기준으로 입력 시간이 20분 가량, 즉 절반으로 줄어들었습니다.

더욱이, 커플매니저의 경우와 마찬가지로, 일선 경찰관들도 전산 전문가나 입력 전문가가 아닌 만큼, 이런 비전문가들이 자주, 그리고 오래 사용해야 하는 시스템의 입력 편의성은 더욱 높아야 합니다. 그런데 이런 고도의 입력 편의성은 웹과 RIA에서는 흉내를 내기조차 어렵죠.

정보시스템에서는 입력 외에도 정보의 출력, 즉 디스플레이도 최종사용자의 생산성에 큰 영향을 주는데요. 정보 출력에 있어서는 두가지 면이 특히 중요한데, 표시 속도와 표시 방법입니다. 버튼이나 메뉴를 클릭해서 새로운 정보나 추가 정보를 보려고 할 때마다 몇초 이상씩 딜레이가 된다면 업무 생산성은 당연히 크게 떨어지게 됩니다.

특히 한 건당 필드 입력량이 많았다면 당연히 출력량도 많을 수밖에 없는데, 그런 경우 더욱 더 속도가 느려집니다. 여러 페이지나 창으로 나눈다고 해도 절대적인 소요 시간이 줄어들지 않습니다. 웹이라는 기술의 기본 아키텍처 자체가 속도를 전혀 고려하지 않은 것이기 때문에 웹 기반 시스템들은 당연히 느립니다. 여기에 속도를 높이기 위한 클러스터링이나 CDN 등의 부가적인 방법을 끼워넣는다고 해도 확률을 높여줄 뿐 응답성을 근본적으로 개선시켜주지는 못합니다.

웹이 기존에 비해 가져다준 장점은 배포 편의성입니다. 누구나 웹브라우저를 통해 접속할 수 있다는 거죠. 하지만 요즘엔 UI 개선을 위해 기본 웹보다는 RIA가 대세가 되고 있는데, RIA는 많은 파일들을 다운로드하여 백그라운드로 설치를 하기 때문에, 이름만 웹일 뿐 실제로는 웹이 아니죠. 한편 배포 편의성이라는 한가지 장점을 제외하면, 웹에는 기술적인 제한이 압도적으로 더 많습니다. 즉, 정보시스템에 있어서는 웹이라는 기술은 족쇄일 뿐 뭔가 혁신이 아닙니다.

게다가, 웹은 애초부터 업무시스템에 필요한 스펙들을 고려하지 않고 만들어진 기술입니다. 최근에 HTML5에서 이를 보완하기 위한 시도들이 있기는 하지만, 여전히 업무시스템을 위한 기술로서는 갈 길이 너무나 멀고 방향도 다릅니다. HTML5의 발전 방향은 UX 쪽이지 Userbilty 쪽을 지향하고 있지 않습니다.

최근에 웹이나 플래시 등에서 Userbilty를 향상시키기 위한 여러 논의들이 있기는 하지만, 웹이나 RIA 기술들의 깊이가 너무나 얕아서 의미 그대로의 Userbilty를 제대로 구현하기 보다는 조금 나은 UX를 모색하는 정도에 그칩니다. 사실 웹이나 RIA에서 Userbilty를 논하는 자체가 좀 어불성설이죠. 더욱이 웹과 RIA 기술에서 Userbilty나 UX를 약간이라도 높이기 위해서 추가로 들어가는 비용이 너무나 큽니다.

예를 들면 Ajax와 같은 기술을 넣어서 Userbilty 혹은 UX를 향상시키려고 하면 개발 비용도 크게 뛸 뿐만 아니라 성능도 크게 떨어집니다. 구글 독스는 웹 오피스 중에서는 나름 빠른편인데도 불구하고 저사양 PC에서 돌리려면 짜증이 확 솟구칩니다.

 

그럼 그 대안은 무엇일까요. 오직 네이티브 개발 뿐입니다. 네이티브 개발 방법에는 C++, 델파이, VB 등이 있는데요. 먼저 가장 많이 알려져 있는 C++의 경우에는, 가장 세밀한 제어가 가능하고 속도도 극도로 빠르지만, 대신 개발 생산성이 극도로 떨어집니다. 패키지 소프트웨어가 아닌 정보시스템의 개발에서는 개발 일정도 대단히 중요하기 때문에, 한마디로 C++은 정보시스템 개발에 적합하지 않습니다.

VB의 경우에는 C++의 정반대입니다. 개발 생산성은 대단히 높습니다만 C++과 같은 세밀한 제어나 속도가 전혀 나오지 않습니다. 사실 웹이나 거기서 거기죠. MS가 비주얼 C++은 계속 업그레이드하면서도 VB는 기존의 VB를 제외하고 C#과 닮은 VB.NET으로 바꿔서 사실상 웹으로 전환시켜버린 이유가 여기 있습니다. MS가 보기에도 C++과 달리 VB는 웹이 대세인 시대에 독자적인 가치가 별로 없다는 얘기죠.

C++은 제어성과 속도가 높지만 개발 생산성이 떨어지고, VB는 개발 생산성이 높지만 제어성과 속도가 떨어진다. 정확하게 이 두가지 장점을 모두 가진 것이 델파이입니다. 델파이는 C++과 거의 동일한 수준의 저수준 제어 기능들을 갖추고 있고, 속도는 오히려 C++보다 더 빠릅니다. 그러면서도 VB 수준의 개발 생산성을 가지고 있죠. 다만 델파이의 벤더가 MS 등에 비해 마케팅 파워가 적다보니 실제로 델파이를 써본 경험이 있는 개발자 외에는 이런 측면을 잘 모르고 있다는 것이 안타깝죠.

(여기서 제가 편의상 델파이로 통칭하지만.. C++빌더도 포함한 것입니다. C++빌더는 델파이보다 덜 알려져 있지만, 비주얼 C++ 등 전통적인 코딩 기반 C++ 컴파일러에 비해 C++ 언어 기반이면서도 델파이와 동일한 개발 방식을 가지고 있어 훨씬 빠른 개발 속도를 낼 수 있습니다)

따라서, 이미 나온 기사들로 미뤄봤을 때, KICS의 대안은 델파이 기반으로 재개발하는 것입니다. 물론 포털 부분은 제외하고, 경찰, 검찰 등이 사용하는 정보시스템 부분만 재개발하는 거죠. 자바로 개발한 서버는 그대로 두더라도, 최소한 클라이언트 시스템은 느려터지고 기능도 조잡한 X인터넷류 시스템들은 완전히 걷어내고 재개발해야 합니다. 대국민 서비스인 포털 부분에서는 일반인 사용자들이 많은 입력을 할 일도 없고, 대단히 빠른 속도가 요구되지도 않으므로 웹으로 가는 것이 당연합니다. 하지만 정보시스템의 클라이언트 부분은 많은 정보 입력과 출력이 필요한 업무용 시스템인 만큼, 획기적으로 빠른 속도와 획기적으로 향상된 입력 편의성을 위해서는 델파이 기반으로의 재개발 이외에는 대안이 없습니다.

델파이로 클라이언트를 재개발하면, 정보의 입력 및 출력에서 X인터넷 따위와는 비교도 되지 않는 획기적인 개선을 할 수 있을 뿐만 아니라, 웹에서 불가능한 것을 억지로 흉내내기 위해 함께 도입한 수많은 잡다하고 느린 소프트웨어들을 상당부분 걷어낼 수 있게 됩니다. 따라서 입력 및 업무 처리 속도 뿐만 아니라 시스템의 업무 처리 속도가 비약적으로 올라가게 되죠. 대표적으로, 웹의 취약성 때문에 웹 기반에서는 반드시 쓸 수밖에 없는 웹방화벽의 경우 전체 시스템의 속도를 상당히 크게 떨어뜨리는데, 델파이 기반 클라이언트에서는 이게 전혀 필요하지 않죠.

물론 뛰어난 최적의 개발툴에 더하여 그 개발툴을 제대로 쓸 수 있는 개발자들도 필요할 것입니다. 당연한 것이긴 하지만, 웹이나 RIA에서는 개발자가 아무리 뛰어나봤자 개발툴의 기능이 전혀 받쳐주질 못하니까 개발자의 실력과 경험 자체가 별로 중요하지 않습니다. 하지만 델파이와 같은 고급 개발툴은 개발자가 누구냐에 따라 실제 결과물이 크게 달라집니다.

예를 들면 국세청에서는 지금도 대량입력을 위해서 델파이 기반의 시스템들을 운영하고 있습니다만, 올해초 부가세 납부를 위해 실제로 해당 시스템을 써보니, 웹보다는 훨씬 낫기는 했지만 입력 편의성이 크게 떨어졌습니다. 부가세 납부를 위해서는 상당히 많은 양의 입력을 해야 하는데, 전혀 최적의 입력 시스템이 아니더군요. 대법원과 한국은행에서도 웹으로 전환된 시스템들 외에 델파이 기반의 업무시스템들을 운영하고 있습니다만 역시 비슷한 수준인 것으로 생각됩니다. 제가 방문해본 여러 대기업들도 비슷했구요.

하지만 상대적으로 델파이 기반 시스템이 적다보니, 델파이의 기능을 제대로 사용하여 최적의 업무시스템을 만들어낼 수 있는 검증된 개발자들의 수도 역시 적습니다. 지난해까지 2년간 델파이 벤더의 총책임자로서 수많은 크고 작은 델파이 사용 기업들을 방문했었는데, 그 대부분이 업무시스템에 숙련된 고급 델파이 개발자들을 구하기 어렵다고 호소하더군요. 델파이라는 툴에서는 그냥 화면 만들고 기존의 컴포넌트들 적당히 배치하고 약간의 기본적인 코드를 더한 후 컴파일하면 시스템이 만들어지는데, 경력 연수가 많든 적든 대단히 많은 델파이 기반 업무 개발자들이 이런 정도의 초보적인 수준에 머물러있습니다.

그래서, 델파이 개발자들도 더 높은 스킬과 아키텍처, 최신의 대세 기술에 대해 더 많이 익히고 적용해볼 필요가 있습니다. 더 체계적인 아키텍처를 고민하고, 웹 등 다른 기술들과의 연동도 시도하고 해봐야 합니다. 업무 시스템에 있어 델파이는 다른 개발 기술들이 가지지 못한 전천후의 특장점을 가지고 있는 만큼, 지금도 기회는 얼마든지 넘쳐납니다.

최고의 개발자는 어떤 개발자일까요. 많은 업무 개발자들과 개발회사들은 고객사로부터 주어진 스펙대로 기간 내에 개발하는 것이 최선입니다. 물론 개발자와 개발회사 자신의 당장의 생존을 위해서는 최선일 수 있겠지만, 그에 그쳐서는 미래가 없습니다. 그리고 그런 정도는 웬만큼의 경험만 있으면 다들 웬만큼 합니다.

제가 보기에, 최고의 개발자란, 개발 비전문가인 고객사 담당자의 뷰에서 나올 수밖에 없는 요구 스펙에 갖히기보다는, 고객사의 To Be 시스템에 대해 개발 전문가의 시선으로 해당 담당자보다 더 뛰어난 대안을 제시해줄 수 있어야 한다고 봅니다. 누가 만들어도 거기서 거기인 시스템이 아니라, 고객사의 업무 형태에 더욱 잘 맞고 최적화된 시스템으로 차별화하는 전략이 필요하다는 것입니다.

또한, 요즘 사실상의 대세인 자바 기반의 업무 개발자 및 개발업체들과의 차별화를 하고 생존하기 위해서라도 더욱 그렇습니다. 자바 및 X인터넷 기반에서는 하려고 해도 불가능한 것들인 만큼, 델파이 개발자, 개발회사에서는 프로젝트를 그저 그렇게 개발해서 대충 마무리하는 관행에서 벗어나 델파이 기반 개발 방식의 강점을 제대로 살릴 수 있도록 해야 그만큼 경쟁 우위를 가지게 되지 않겠습니까.