표준에 대한 철학적 주제는 매우 포괄적이고 광범위합니다.
횡단보도로 건너지 않고 무단횡단을 한다는 것은 빠르게 길을 건너는 방법이긴 하지만 법을 무시한 부작용은 그 댓가를 반드시 치러야 합니다.(적게는 벌금, 크게는 사망)
표준을 지키지 않고 개발을 한다는 것도 빠르게 개발하는 방법이긴 하지만 그 댓가는 반드시 치릅니다.(물론 동네의 작은 길을 무단횡단 하듯이 일정관리 프로그램같은걸 비표준으로 개발해도 문제는 적을 것입니다. 하지만 8차선 대로를 무단횡단 하듯이 100억이 넘어가는 프로젝트를 비표준으로 개발한다는 것은 자살행위입니다.)
물론 리눅서중에는 개인의 자유를 내세우는 분들도 계십니다. 저도 그런 자유주의자이고요. 하지만 개인의 자유는 다른사람과의 접점에서 당연히 제한받아야 합니다. 내 자유를 위해 다른 사람의 자유를 침범할 수 없으니까요. 그 제한이 일상생활에서 나타나는 법이죠. 그리고 정보기술쪽에서 나타나는 표준입니다. 당연히 다른 시스템과 상관없는 시스템에서 비표준개발을 한다고 뭐라 할 사람은 절대 없습니다. 혼자 가지고 노는 시스템을 아무렇게나 관리한다고 뭐라 할 사람 당연히 없구요. 하지만 다른시스템과의 접점이 생기는 시스템은 그 자유를 당연히 제한하여야 합니다. 그것이 표준의 정의이구요.
IT분야에서 반드시 알아야 될 개념으로 시스템과 소프트웨어의 차이, 정보와 데이터의 차이, 엔지니어링과 프로그래밍의 차이, Procument와 Acquisition의 차이 그리고 개방형 시스템(Open System)등이 있습니다.(설령 게임이나 Embedded Linux 프로그래머라 할 지라도 기본적으로 이해해야 할 개념이라 생각됩니다.)
일반적인 코더라 할지라도 저런 개념을 이해하지 못하는 상태라면 거대한 프로젝트를 수행하기 어렵습니다.(정말 경제적인 관점에서 그런 사람은 30세 이후에 쓸 곳이 없지요.)
특히 시스템 엔지니어링분야에서는 표준에 대한 기술아키텍처가 가장 중요한 부분이구요.(시스템 엔지니어링은 시스템 소요분석, 개념연구, 시스템 규격정의, 시스템 개발계획수립, 시스템 분석/설계, 시스템 개발, 시스템 시험, 시스템 평가, 시스템 감리, 시스템 도입등의 라이프사이클을 가지고 있으며 각 단계 단계의 요소가 다 아키텍팅과 엔지니어링의 대상이 됩니다. 시스템 개발안에는 당연히 소프트웨어 엔지니어링이 포함되지요. 시스템엔지니어링에서의 표준이란 시스템 인터페이스를 의미합니다. 인터페이스가 맞지 않는 시스템은 실패한 시스템을 의미하지요. 정의된 시스템 인터페이스는 당연히 소프트웨어 엔지니어링의 형상항목 - Configuration Item 이 되고 구현대상이 됩니다.) - 이런거 잘 규정해 놓은 표준이 IEEE 12207입니다. 반면 저런 절차를 시키는 대로 잘 할수 있는지 업체 평가하기 위해 만든 것이 CMM(Capacity Maturity Model)이구요.
표준을 지키지 않았을때 가장 크게 잃어버리는 댓가는 시스템간 상호운용성(Interoperability)입니다. 상호운용성도 Inter-Oper-Ability를 어근으로써 이해하는 미국넘들은 단번에 이해하는 개념인 반면 우리나라에서 상호운용성은 3박4일짜리 개념입니다.(단적으로 Operation은 운영이라고 번역되지만 유지보수의 개념이 강한 운영이란 단어로 절대 설명이 불가능한 개념이죠. 군에서는 작전의 개념으로 사용합니다.) 웹상에서 브라우저 접근성도 시스템간 상호운용성의 실패로 이해할 수 있습니다. 클라이언트 시스템과 서버 시스템간의 표준 언매칭이 나타나는 결과이죠.(실제 시스템간 상호운용성의 문제는 이것보다 훨씬 심각합니다.) 그리고 시스템간 상호운용성을 확보하기 위한 개념으로 발전된 개념이 EA(Enterprise Architecture: 전사적 아키텍처)/ITA(Information Technology Architecture: 정보기술 아키텍처)/C4ISRAF(Command, Control, Communication, Computer, Intelligence, Surveillance, and Reconnaissance Architecture Framework: 지휘,통제,통신,전산,첩보,조사,인지 아키텍처 프레임워크)이죠.
이런걸 미국넘들은 이해하고 있기 때문에 표준에 따른 개발을 잘 수행하는 것이고, 우리나라 개발자들은 비표준 개발을 남발하는 것 아닐까요?
제가 일전에 정리한 이공계 위기의 문제점은 너무나 상식적인(철학은 상식의 기준입니다.) 위의 개념들을 가지고 있지 못한 엔지니어들(스스로 엔지니어라 착각하고 있는 프로그래머나 코더들도 많겠죠?)이 너무나 떳떳하게 자기 주장을 하고 있었기 때문입니다.(위에서 언급했듯이 규모가 커지는 프로젝트를 감당하지 못하는 개발자는 당연히 시장원리에서 도태되어야 정상이 아닐까요?)
공(工)이란 엔지니어링입니다. 엔지니어링의 의미를 모른채 공(工)의 위기를 부르짖는건 문제가 있지 않을까요? 제가 철학적 문제라 한 부분은 그런 점입니다.
이(理)에 대해서는 제가 잘 모르고, 어떤 물리학자가 좋은 글을 남겼더군요.(전 이공계 위기를 理의 문제와 工의 문제로 분리했으면 합니다. 서로의 문제점과 해결방법은 전혀 다르거든요.)
전 공학박사, 이학박사란 말도 마음에 들지 않는 군요. Ph.D(Philosophy of Doctor)처럼 모두 철학박사라고 해야 맞을 것 같네요.
리눅스에 표준이 왜 필요한가에 대한 논쟁에 엔지니어의 입장에서 위의 쓴 글이 답이 될 수 있을까요?
리눅스 표준화 싸이트인 http://www.linuxbase.org/ 이곳도 관심있게 보고 있습니다. De Facto표준(레드햇, 데비안등의 사실표준)과 De Jure표준(표준기관에 의한 공인 표준)의 파괴력은 하늘과 땅차이거든요.
공공기관에서 같은 곳에서는 De Facto표준을 따르기는 무척 어렵습니다. 특혜시비도 걸리고... 당연히 De Jure 표준이 있어야 Acquisition 절차가 가능하지요...
http://kldp.org/node/30905
'project' 카테고리의 다른 글
| SI 프로젝트에서 JOB분류 명칭 (0) | 2012.10.25 |
|---|---|
| subversion 설치 (0) | 2012.04.02 |
| Samsung network Result code (0) | 2011.12.28 |