정보의 처리라는 것

정보의 처리라는 것
information과 data의 차이
processing 과 procedure의 차이

정확하게 아십니까?

위의 단어들은 모두 정보와 처리를 뜻합니다
먼저 data와 information의 차이는 결론부터 이야기 하자면
인간에 유용한가 아닌가로 나눌 수 있다고 생각합니다.
data는 단순히 fact들의 집합 이지만 information은 data가
process를 거친 결과 물이라고 생각합니다.
결국엔 둘의 본질은 같지만 인간의 입장에서 어느것이 더 빠르게 유용하게
사용될 수 있는가의 차이입니다.

process와 procedure는
사실 나누기에도 힘듭니다.
process는 처리를 뜻하고 procedure는 절차를 뜻합니다.
결국엔 process안에 procedure가 있다고 보는게 맞을지도 모르겠습니다.
그리고 실제로고 델파이에서 사용하는 오브젝트 파스칼등에서는
다른 언어의 함수(function)가 procedure란 이름으로 존재합니다.
하지만 둘을 떼어서 한 부분씩도 이해할 수 있습니다.
그 대표적인 예로 stored procedure(이하 SP)가 대표입니다.
SP라 불리우는 것들은 대부분 DATABASE안에 존재 합니다.
이것들은 DATABASE라는 거대한 프로세스 안에서 한 가지 기능을 하는 것으로
만들어졌지만 지금에 와서는 SP자체가 하나의 PROCESS가 될 수도 있습니다.
(THREAD에 대한 논의는 좀 미루겠습니다.)
제가 SP를 하나의 프로세스로 보는 이유는 입력과 출력이 명확하며, SP 자신이
작동할 때는 다른 프로세스나 쓰레드의 영향을 적게 받는다고
판단하는 것에서 저는 하나의 PROCESS로 보는것 입니다.

그렇다면 DATA를 PROCESSING해서 infomation으로 만들고 이것을 procedure로 조작한다.
라는 말이 될 수도 있을 것 같습니다.
여러가지 정보를 받아서 가공해서 가치가 있는것으로 만들고 이것을 조작해서
인간이 보기에 편한것으로 만들어낸다 라는것이 결국엔 정보처리라고 이야기 할 수 있을 것
같습니다.

제 생각에는 이것은 어느 어플리케이션이나 튜링 머신이라는 가상의 기계에서 벗어나지 못하는
이상에는 이것이 진리인것 같은 생각을 합니다.

사람이나 컴퓨터의 자동화된 기능으로 DATA를 수집해서
일정량이 수집되면 PROCESSING(처리)합니다.
그리고 그것을 정보(INFORMATION)으로 만들어서 사람이 보기 좋은 형태로 PROCEDURE를 통해서
가공합니다.

머 결국엔..

입력 -> 처리 -> 출력이라는 얘깁니다.

이렇게 간단하게 끝나고 진리인걸 길게 쓰려니까 나름 힘듭니다.

그런데 세상엔

입력보단 처리를 중요시하고 처리보단 출력을 중요시 하는 사람이 많은것 같습니다.

우리 속담에.. 콩심은데 콩나고 팥심은데 팥난다는데..

이걸 잊고 사는게 아닌지..

잠시 그생각을 해봤습니다.

고급인력은 없다.

한국은 IT강국이다.

정말로 접속만 많이 하면 강국인겁니까?
기반기술을 가지고 그것을 활용하며 사람이 편하게 지낼 수 있게 하는게 강국입니까?

지금 블로그 세상은 또 시끌시끌합니다.

개발자의 처우문제라는게 사실 이야기는 오래된 이야기입니다.

현재 한국에서 IT산업이라고 할 때 몇몇 포탈을 제외한 중소 인터넷 업체들은
죽기 일보직전입니다. 서로 나은거 하나없이 간신히 먹고 살고 있습니다.
그럼 눈을 돌려서 SI를 보겠습니다.

현재 한국 IT 산업이라는 거대한 두축 웹과 SI ..
어디에도 솔루션이나 제품을 생산하는 곳은 없습니다.
원청과 하청으로 나누워지고 도급에 하도급. 갑을병정무기.... 내려가게 되는
계약관계 원청과 하청의 노예계약의 실상, 이런것이 IT강국이라고 우기는
한국에서의 진짜 IT계의 모습입니다. 이런 모습은 어딜가나 마찬가지 입니다.

연구소에서도 일반 회사와 연구를 하겠다고 해놓고 연구소 직원 한두명에
회사 직원 열댓명을 데리고 제품을 만들고 결과는 연구소에 돌아갑니다.
회사에서 얻은건 XXX연구소와 공동연구.. 로 끝납니다.
이런식으로 정출연을 먹여살려주고 대형 SI라고 얘기하는 SK,삼성,엘지등의
대기업 계열의 SI업체들은 내부거래로 인한 독점과 매출의 상승
그리고 그 모든 일을 하기 위한 재하청과 그 하청을 받아서 일하는 작은 SI회사들
사실 SI회사라고 하기에도 너무 합니다.

사장한명 , 경리한명, 주요 업무는 인력파견 .. 말이 좋아 인력파견이지
새벽에 공사장 잡부 중개하는거랑 무엇이 다른지 묻고 싶습니다. 똑같습니다.

이런것이 현재 IT강국이라는 한국의 실제 모습니다.

지금도 어디선가 학문적인 연구나 개인적인 연구로 프로그램을 하시는 분들도 많이 있지만
결국엔 당장에 수익이 없다는 이유로 어디에서도 투자받지 못하고 자기돈으로 하거나
외국에서 투자받아서 나중에 외국의 회사로 흡수되거나 합니다.

그분들이 그렇게 외국으로 나가는 이유,.
현업 개발자들이 해외취업을 노리는 이유..
이런것 모두가 이들을 이용해서 돈만 벌면된다는 생각의 대기업SI와 거기에 빌붙어
개발자들 피빨아먹는 일부 몰지각한 중소 SI업체의 대표님들 제발 정신차리고
제대로 해볼 생각 좀 해보세요.

당장의 눈 앞의 이익만 챙기는게 아니라 멀리 내다보고 일을 할 수 있는 나라가
좋은 나라 아닌가요? 서로 시장을 넓히는게 좋은거 아닌가요?
제대로 처우해주고 일해서 그 사람들이 편하게 계속 꾸준히 일을 해서 결국엔
어디에도 없는 고급인력으로 태어나게되고 그들은 그렇게하도록 도와준 사람에게
고마워하며 같이 일할것입니다.
고급인력이 없다고 욕하지말고 그럴 기회를 사람들에게 주었는지 먼저 생각해보십시요

웹 2.0 이란 미친바람

웹 2.0의 광풍..
미친바람이다.

개방, 공유, 협력등은 눈 딱감고.. 생각했을때 옛날부터 대부분의 사람들은
자신의 지식을 검증하는데 다른 이들의 의견을 물어봤었다.
대부분의 과학자들은 편지나 학회지에의 기고를 통해 지인이나 대중의 의견을 수렴하고
자신의 지식을 검증했다.

내가.. 맞다.. 맞아. 내가 정답! 이라고 외친다고 해도 주변인들 모두가 틀려! 라고 하면
틀린거다. 아닌가? 내가 1+1은 3이다라고 우길 때 옆에서 그건.. 이런 증명 때문에 2 라고 하고
반박하지 못하면 틀리는거다. 그래서 예전부터 사람들은 자신들의 지식을 타인과의 공유를 통해서
검증을 받았다.

왜 뜬금없이 이런얘기를 하는가?

개방과 공유가 언제부터 새로운 유행이었나?
인간 사회는 그동안 폐쇄적으로 살았나??
자기만 알아야하고 남들은 몰라야 자신이 유리한가? 그 알고 있는것을 더 발전 시키기 위해선
위에 말한것처럼 공유를 통해서 서로간의 검증을 받아야한다.
하지만 그동안의 웹이라는 시스템이 사실 그리 폐쇄적이지도 않았다.

원론적으로 얘기하자면 너무나 개방적인데 적응을 못해서 폐쇄적으로.. 나간것이다.
내가 무엇인가 올리면 경쟁자가 그걸 보고 배워서 자기를 따라잡지 않을까? 라는 불안감도 있었을테고
공유가 익숙하지 않다보니 창피를 당할까도 두려울테고
여러 이유가 있었을것이다.

하지만 창피를 당하지만서도 사람들이 그걸로 끝까지 무시하거나 창피를 주지 않는다.
오히려 그런 단계를 거듭하면서 인간관계를 넓힌다고 본다.
개방과 공유라는 대전제 앞에서 과연 그것을 개방과 공유를 이끌어내기 위해서

반드시 AJAX를 이용해야하고 RIA 로 개발 해야하며 사용자들은 누구나 UCC라 일컬어지는
동영상을 찍어서 올려야 하는지 의문이다.
사실 UCC를 통한 네트워크 형성에선 예전에도 많았다.. 게시판을 이용한 사진 및 동영상의 공유등이
대표적이며 ajax같은거 안써도 웹서핑 하는데 불편 없었다. RIA는 오히려 자사양컴퓨터에선
독약이다.. (flash 만해도 CPU점유율을 100% 가까이 먹는 경우도 있다.)

네트에서도 부익부 빈익빈을 초래하려고 하는것인가?
사람들의 많은 참여를 바란다면서 윈도우즈가 아니면 하지말라고 하고 컴퓨터가 안좋으면
하지말라고 한다.

이게 과연 진정한 개방과 공유인가?

플랫폼이 달라서 컴퓨터 사양이 안되서 위의 저런 기술로 만들어진 사이트에 못들어가서
정보를 못 얻는다면 그게 개방과 공유인지 묻고 싶다.

Active X 로 도배된 정부 사이트, 온갖 쓰레기들의 모음집인 은행사이트들
윈도우가 아니면 접속못한다. 개인적으로 리눅스를 사용하지만 몇몇
파이어폭스나 네스케이프로의 접근자체를 막아버리는 사이트들 덕분에 나의 접근성은 윈도우에
익스플로러를 사용하고 두손과 눈과 귀가 온전해야만이 양호해진다.

만약에 위에 있는 조건중에 하나라도 없다면 못한다..
서핑 자체가 불가능할 정도다..

이게 웹2.0을 부르짖으며 기술에 환장해서 웹2.0은 개방과 공유라고 외쳐대는 골빈것들이
만들어낸 것들이다..

웹2.0이고 강아지발이고 일단은 웹표준부터 익히고 와서 작업하는게 좋을거 같다.
그 이전엔.. 벌레들의 울부짖음으로 밖에 안들린다.

SI 프로젝트에 대한 단상

SI의 정의는 System Integration 의 약자로 단어대로는 시스템 통합이며
그 내부의 작업들을 들춰보자면 H/W와 S/W를 같이 납품하면서 기존의 시스템과 신규 시스템을
통합하여 기업체의 원할한 비지니스 활동을 유지할 수 있도록 시스템을 구축한다.
라고 생각할 수 있다.

보통의 프로젝트는 분석/기획, 설계, 구현/테스트 , 납품의 단계로 구분 될 수 있으며
각각의 단계는 앞으로 돌아가기엔 (바로 앞단계라 하더라고) 되돌아 가버리면 공정기간을
맞출 수가 없는 프로세스이다.

일단 지나쳐버리면 이전단계의 문제점을 파악하면서 차기 버전에 대한 기획을 해야하며
현재 진행중인 프로젝트에서는 반영하면 안되는 문제점이 있다.
(혹시나 반영하게 되면 프로젝트 완료일은 미뤄져야 하지만 실상은 일정은 그대로고 해야하는
일이 바뀌게 된다 -> 야근의 원인)

머 사실 국내에서 애자일 방법론을 도입하기엔 프로젝트시에 요구하는 문서가 너무 많고
돈을 주고 받고 납품하는 일이기 때문에 결과는 성능이나 프로그램 자체가 아니라 문서가 되는
경우도 있다.

제품의 질이나 성능보다는 당장 눈에 보이는 일시적인 성능과 돈들여서 프로젝트를 진행했다는 증거로
사용할 문서들이 중요시 되는 경향에 대해서 개발자들은 어떻게 생각하는지
혹은 현재 개발되는 프로세스에 대해서 얼마나 이해를 했는지에 따라서 완료시의 프로그램의
품질은 물론 문서의 품질도 달라지게 되는건 분명한 사실이다.

업무를 10%밖에 이해하지 못한 사람이 만든 프로그램 전체의 10%만 대처를 할 수 있을것이며
100%를 이해한 사람은 요구하는것에 무엇인지 확실히 알기 때문에 전체적인 면으로 프로그램을
작성할 것이며 그렇게 된다면 프로그램은 물론 문서의 품질도 올라가게 되는것이다.

배경 : 무엇이 문제인가.
위에 있는 말들은 원론적이고 누구나 알고 저렇게 해야한다고 느끼면서 안한다.
아니 못한다.. 왜 못하는걸까??
능력이 없어서?? 학벌이 딸려서?? 돈이 안되서??
나는 이문제의 시작은 발주처라고 생각한다.
신규 시스템을 도입하건 기존의 시스템을 개선하던 가장 필요한건 해당업무.. 즉 전산화 대상 업무 및
기존의 개선대상 업무에 대해서 명확한 구분을 정의하고 기존의 업무의 담당자가 편하더라도 비효율
적이라면 과감히 새로운 방법을 재정의 할 수 있는 결단성이 필요하다.
하지만 대부분의 프로젝트는 어떤가??
가장 많이 듣는 말이.. "하던대로 해주세요" 이말이다.
어쩌라는건가?
기존의 프로세스를 그대로 쓸거면 어째서 돈 아깝게 전산시스템을 도입하고 개선 프로젝트를 진행하나?
그룹계열사 매출 올려주려고? 아니면 다른 회사가 하니까 자기들도 해야할거 같아서?

이런식으로 프로젝트 진행하면 돈은 돈대로 날리고 업무는 업무대로 복잡해지고
프로그램은 쓰지 않게 된다.. (결과가 같은데 굳이 새로 배울 필요가 있을까? 하던대로 일하면되지)

결론 : 신규/개선 프로젝트의 목적을 생각해야한다.
이윤을 추구 하는 기업이라면 프로젝트의 진행을 결정하기 전에 필요성을 먼저 생각해서
추진하기 바란다..
다들 말할때 SI 개발자가 수준이하라고 하면서 자기들의 수준은 생각하지 않는거 같다.
발주자의 수준부터 확인해보고 싶다. 프로젝트 진행전에 관계자들하고 면담을 하면서
기존의 업무를 체계적으로 정리해보고 정리해서 신규 프로세스를 만들던지
아니면 기존의 내용을 기초로 진행을 하던지 결정해야할 것이다.

엔터프라이즈라 일컬어지는 대규모 시스템에서는 DB의 한 테이블에 있는 같은 컬럼에 대해서
서로 다른 부서에서 다른 값으로 정의해서 쓰는 경우도 있고 같은 역할을 하는 중복된 두개 이상의
컬럼을 쓰는곳도 있다. 이런 것을 모두 막기 위해서 업무를 담당하는 부서의 장이 회의를 하는게
아니라 실무자가 해야한다고 생각한다. 각 팀의 실무자들이 모여서 서로의 업무를 알아야 자신의
업무도 더 이해할 수 있다고 생각한다. 그러면 프로젝트시에 고쳐야 할 점도 눈에 확 보일테니까
견고한 설계과 그에 따른 고품질의 프로그램과 도움되는 문서를 바랄 수 있지 않을까..