그동안 기사들을 보니 NEIS에는 교사들의 입력량이 엄청난가 보던데, 그럼 웹 기반으로 만들면 안되죠. 아무래도 NEIS는 교사들이 절대적으로 많이 사용하고 대부분의 데이터를 입력하게 되는데, 교과부의 입장이나 SI 기업의 입장을 우선해서 개발하니 기본적으로 프로젝트의 전제가 거꾸로 갈 수밖에.

자바 기반인 전자정부 프레임워크를 쓰는 대신 RIA를 쓴 건 분명히 그런 부분을 좀이라도 감안했다는 얘기긴 하겠지만, RIA라고 해도 극단적인 입력량에는 별로 효과가 없죠.

이따금씩 사용하는 학부모용 화면들만 웹 포털로 만들고 상시적으로 사용하는 일선 교사들이나 교육청 관계자들이 사용하는 핵심 업무 파트는 네이티브로 개발하는 것이 가장 적절한 선택이라고 봅니다. 외부에서 학부모가 보는 화면들은 입력할 것은 거의 없고 주로 조회 전용이므로 웹 포털로 개발해도 충분하고 효과적이지만, 입력이 주작업인 교사용 화면들은 내부 사용자 전용 시스템이므로 웹으로 개발할 하등의 이유가 없습니다.

델파이 기반의 네이티브로 개발했더라면, 교육 현장에서 많이 사용될 수 있는 입력 형태를 위해 전용으 입력 컨트롤들을 간단히 개발할 수 있으므로 입력의 편의와 시간을 크게 줄일 수 있고, 또 다량의 입력으로 서버 부하가 집중되는 시간에는 교사가 손놓고 퇴근도 못하고 기다리는 대신 로컬 임시 데이터로 저장하고 추후에 자동으로 올라가도록 하는 등의 처리가 간단하죠.

HTML ,웹의 발전은 우리 생활을 편리하게 해준것은 맞지만. 우리나라 만을 봤을때는 부작용도 그에 못지 않기 때문에 무시못하죠..

프로젝트가 어떻게 돌아갔는지 눈앞의 그림처럼 보이는군요. 허허..

네이티브 app가 사용자 측면에서 보면 지훈님 말씀이 일리가 있습니다. 그러나 일을 수행하는 업체에서 보면 수용하기 어렵습니다.

웹기반으로 프로젝트를 수행하는 이유는 비용 때문입니다.

클라이언트를 델파이로 네이티브 개발을 하게 된다면 우선 서버쪽 개발자(미들웨어)와 클라이언트 개발자를 별도로 채용해야 합니다.
더구나...서버가 윈도우만 있을 가능성이 적기 때문에...서버쪽은 자바로 하고 클라이언트는 델파이로 한다해도 인력 채용에서 비용이 웹기반에 비해서 많이 발생하게 됩니다.(웹프로젝트에서는 클라이언트 개발자를 따로 뽑는 경우는 드뭅니다.) 또한 개발시에도 데이터통신을 http를 이용하는 것이 훨씬 간단합니다. 물론 델파이로도 http를 사용하여 통신 할 수 있겠지만 성능상 이유로라도 다른 솔루션을 사용하겠죠.

디버깅때도 시간과 비용이 적게 들 수 밖에 없습니다. 웹은 어떤 domain에 대해 서버쪽과 클라이언트쪽 모두 한 개발자가 개발하게 되므로 테스팅 및 디버깅시 수월한데다가...운영/유지보수인력도 델파이 인력을 따로 두지 않아도 된다는 잇점도 있습니다.

저 역시 html 은 문서작업을 위한 솔루션이지 UI제작 솔루션이라고 생각하지 않습니다. 그러나 업체입장에서는 돈 문제가 항상 제일 크다라는 것이고 적은 금액으로 적절하게(훌륭하진 못하지만) 수행된다면 그 방법을 택할 수 밖에 없습니다.

델파이가 무료이면서 개발자 풀이 커서 인력수급도 원할하고 저렴한 솔루션들이 많다면 업체에서도 환영하겠지만 현실은 그렇지는 못한 것같습니다.

글쎄, 그렇게 생각되지 않습니다. 요즘 일정 규모 이상의 SI 프로젝트에는 대부분 서버 개발과 별개로 클라이언트 개발이 들어가고 있습니다. 순수 웹으로 했을 때의 극단적으로 낮은 사용성 때문에 대부분 X인터넷 솔루션을 도입하는데, 실제 NEIS의 경우에도 X인터넷을 썼습니다. 그런데 이 X인터넷의 개발 공수가 만만찮게 큽니다. 특히 기능이 미약하기 짝이 없는 X인터넷 솔루션에 대해 갑쪽의 요구사항은 델파이에 필적하는 경우도 흔하기 때문에, 오히려 온갖 말도 안되는 꽁수들이 횡횡하고 결과적으로 화면 하나 개발하는 데에 결코 델파이보다 공수가 줄어들지 않는 데다가 델파이보다 더 많이 들어가는 경우도 많습니다.

그런데 정영훈님이 말씀하신 것처럼 클라이언트 개발은 없는 걸로 간주하는 경우가 적지 않다보니 그럼 공수 계산에도 없는 클라이언트 개발이 더 들어가는 셈이라 프로젝트가 더 꼬이고 개발자들은 더 고달파집니다. 자바 개발자들이 잘 알지도 못하는 X인터넷 화면 개발까지 같이 하면서 초죽음이 된 사례는 수도 없이 많죠.

그리고 순수 웹으로 개발하는 경우라면 클라이언트 개발이 없을 것ㅓ럼 생각될 수도 있겠지만, 사실은 웹 스크립트 개발에서 서버와 클라이언트 개발이 뒤섞여서 들어가기 때문에 오히려 개발 생산성이 더 떨어집니다. 이러나 저러나 클라이언트 개발이 없는 SI 프로젝트는 없습니다.

결국 지난 10년 사이에 SI 프로젝트들의 대세가 C/C++ 등이 자바로 대체되고 클라이언트가 델파이나 VB 등에서 X인터넷 등으로 대체된 것 외에 개발 관행이 바뀐 것은 아무것도 없습니다.

'유지보수 인력을 따로 두지 않아도 된다'라는 게 장점인 듯 말씀하시지만, 거꾸로 말하면 비전문 인력을 투입해서 유지보수를 때운다는 말이 되지요. 실제 요즘 프로젝트 현장들이 대부분 그렇습니다. 경력도 부족한데다 해당 업무도 잘 모르는 인력들이 유지보수 인력이라고 들어가서 자리만 메꾸고 있습니다. 이것도 요즘 프로젝트들이 꼬이는 주요 요인들 중 하나입니다. 프로젝트 수행 인력들도 과거에 비해 평균 수준이 많이 떨어져있는데 유지보수 인력은 그보다도 훨 못한 인력들을 채워놓고 도망나오는 경우들을 수도 수도 없이 봤습니다.

정영훈님의 말씀이 옳은 측면도 있기는 하다고 생각됩니다만, SI 업체를 운영하는 경영진의 입장에서 보는 시각에 많이 가깝습니다. 최저의 임금을 주고 아무 개발자나 대충 이력서만 뽑아 자리를 채워놓고 최단 기간 내에 대충 덮어버린 후에 장기 비용이 들어가는 유지보수 인력은 더 싸구려 인력으로 때웁니다. SI 업체의 고위 관리직들이나 영업들은 이런 게 해피한 상황입니다. 그런데  개발자나 갑 업체의 시각에선 정반대죠. 개발자는 개발 고달프고 대우는 더 떨어지고, 갑 업체의 입장에선 품질은 추락하고 유지보수 과정에서 수도 없이 문제가 생기는 데다가 유지보수 요원이라고 앉아있는 사람은 그냥 본사와 전화만 하는 연락 요원에 불과합니다. 이런 게 가장 최근의 각 SI 프로젝트들의 현실이죠.

경영진(대부분의 업체)의 입장에서 본 것이 정확합니다...si업계가 그렇습니다.
저도 금전적인 면을 떠나서 가장 좋은 방법이 프로젝트에서 통용되었으면 합니다만 윗분들은 결코 그러하지 않더군요.
오로지 금전적인면만을 바라보는 경우가 많습니다. 무엇보다 최저 입찰가를 써 낸 업체가 수주가 되는 경우도 허다하구요.

나이스 사태 뿐만 아니라 si 전반적인 프로젝트가 경영진의 금전적인 논리에 의해서 흘러가는 경우가 부지기수 입니다.
이런 상황에서 계약직으로 선발된 개발자들이 할 수 있는 뾰족한 그 무엇은 없습니다...시키는대로 해야지요.

제가 적고 싶었던 것은 si 관행으로 ...을병정 노가다판 같은 하도급 문제 등이 개선되지 않는한 아무리 네이티브로 개발한다 한들 그다지 변할 것 같아 보이지 않다는 것 입니다.

분명 웹기반이 네이티브 기반의 app보다야 불편하지만...추가 비용 없이 많은 클라이언트 환경을 지원하며 그럭저럭 쓸만합니다. 개발 및 유지 보수 인력수급도 수월하구요...

윗분들은 고객만족도? 보안? 오로지 비용절감에만 촛점이 가있습니다.

우리나라 관공서, 금융권...neis하고 다를 것 하나 없기 때문에 무슨 사고가 터진다한들 그리 놀라운 일은 아닐겁니다.
농협해킹? 과연 북한의 놀라운 해킹 능력에 의해 그리 되었을까요?

아, 정곡을 찌르셨습니다. 지금과 같은 관행에선 실제로 어떤 기술로 개발하든 결과는 별반 차이가 나기 어렵지요. 어찌보면, 배가 침몰하고 있는데 돗대를 참나무로 세울 것이냐 소나무로 세울 것이냐를 따지는 것과 비슷하기도 하네요.

그런데 말로만 웹이지 실제로 요즘 일정규모 이상의 SI 프로젝트들은 X인터넷 클라이언트를 쓰는데... X인터넷 솔루션들의 가격은 좌석수 대비로 볼 때 델파이보다 훨씬 더 비쌉니다. 그리고 문제 없이 개발하도록 일을 맡길 수 있을 정도의 경력자는 오히려 델파이 경력자보다 더 적지요. 국내를 대표하는 몇몇 X인터넷 솔루션 기반으로 개발하는 프로젝트 현장들에서 쓰레기에 가까운 X인터넷 솔루션으로 화면 개발하느라 생쑈를 하는 장면들을 여러번 봤답니다.

국내 점유율 1위인 유명 X인터넷 솔루션 벤더의 개발 관련 고위 경영진 분을 한다리 건너서 아는데요. 그쪽도 원래의 핵심인 솔루션 판매 매출보다는 SI 매출, 즉 나가서 화면을 개발해주는 매출 훨 더 크다고 하더군요. 이것도 일정 규모가 되어야 가능하지 중소 규모에서는 서버 자바 개발자에게 X인터넷 화면 개발까지 떠맡기는 경우가 흔하죠.

또 다른 분께 들은 말로도, 애초의 설계가 개발현장에 잘 맞지 않아서, 대형 프로젝트가 있을 때마다 불려나가서 요구 사항에 맞게 여기저기 뜯어고쳐왔기 때문에 지금은 소스코드가 완전히 누더기가 되어 있다고 합니다. 그런 누더기가 다된 솔루션을 개발툴이라고 가지고 개발해야 하는 개발자들은 정말 고역도 그런 고역이 없죠.