2008. 7. 18. 04:31
하얀말의 미투데이 - 2008년 7월 17일 Computing에 관한 독백2008. 7. 18. 04:31
이 글은 하얀말님의 2008년 7월 17일의 미투데이 내용입니다.
'Computing에 관한 독백'에 해당되는 글 226건
- 2008.07.18 하얀말의 미투데이 - 2008년 7월 17일
- 2008.07.15 IT를 통해 본 인생 고찰... 이랄까요?
- 2008.07.13 V3 사태 피해를 당하면서 드는 단상 1
- 2008.02.29 Java에 대한 보이지 않는 위협 3
- 2008.02.28 SI 업체는 정말 개발자의 적인가?
- 2008.02.25 비운의 낭만 컴퓨터 - NeXTCube 9
- 2008.01.23 Internet의 발달, 말바꾸기를 까발리다.
- 2008.01.11 IBM DeveloperWorks, Grid Computing Zone 중지
- 2008.01.09 하얀말의 미투데이 - 2008년 1월 8일
- 2008.01.03 Silverlight 적용? Web 표준부터 지켜라! 4
2008. 7. 15. 22:53
IT를 통해 본 인생 고찰... 이랄까요? Computing에 관한 독백2008. 7. 15. 22:53
1. '어떻게'보다는 '왜'가 먼저
어떻게 그렇게 했는지를 넘어 왜 그렇게 했는지 깨달았다면 완벽하게 이해했다고 말함에 주저함이 없을 자격이 있습니다.
How보다는 Why를 먼저...
2. 하수와 고수, 군자와 소인배
논어(論語)의 '군자는 자기에게서 구하고 소인은 남에게서 구한다(君子求諸己 小人求諸人)'와 일맥상통합니다.
하수와 고수, 그리고...
어떻게 그렇게 했는지를 넘어 왜 그렇게 했는지 깨달았다면 완벽하게 이해했다고 말함에 주저함이 없을 자격이 있습니다.
How보다는 Why를 먼저...
2. 하수와 고수, 군자와 소인배
논어(論語)의 '군자는 자기에게서 구하고 소인은 남에게서 구한다(君子求諸己 小人求諸人)'와 일맥상통합니다.
하수와 고수, 그리고...
2008. 7. 13. 00:02
V3 사태 피해를 당하면서 드는 단상 Computing에 관한 독백2008. 7. 13. 00:02
V3가 Windows XP SP3의 lsass.exe를 지워 booting이 안되는 사건을 몸소 경험했습니다. 목요일 오후 Windows XP SP3 CD를 넣으라는 대화 상자를 무심코 흘리고 PC 끄고 퇴근했다가 금요일 아침 출근 전 News에서 예의 그 V3 사태를 듣고 '혹시!?' 했더니만, 역시 이런 예감은 안 빗나가는지 그 '혹시'가 '역시'였습니다. 비록 제 PC(제 PC라고는 했지만 실은 제가 다니는 회사가 지급한 Notebook PC입니다. 회사에서 Notebook을 지급 받는 이후로 제 PC를 잘 안 사게 되네요)는 아니고 현재 나가 있는 곳에서 지급한 PC(이곳은 보안 목적으로 외부에서 온 인력에게 자사 자산 PC를 지급합니다)긴 하고, 그 회사의 PC 관리자가 돌아다니면서 조치를 취해서 금방 복구되긴 했지만요. 사실 나름대로 OS patch도 열심히 적용하고 보안에 신경을 쓰는 편이라 Virus나 악성 code 피해는 덜 받고 살았는데 이번 사태를 몸소 겪으며 느낀 점을 좀 적어볼까 합니다.
1. PC의 마비는 개인에게도 타격이 크더군요. 만약 PC 관리자의 조치가 늦었다면 늦는 만큼 난 일을 못했을 것입니다. 만약 중요한 위치의 사람이 쓰는 PC가 먹통이었으면... 회사건 개인이건 이제 computer의 마비는 그대로 업무 마비입니다. 그런데, PC는 보안성이 약하죠. Windows 자체도 보안성이 약한 편이지만 그것을 쓰는 사람의 보안 인식이 형편 없기 때문이기도 합니다. 더군다나 조직에서 중요한 일을 하는 분들은 대부분 또 PC를 잘 모르는 게 더... 크~.
2. Beta Test의 중요성을 절감했습니다. 우리나라에서는 beta test란 말을 online game사들이 open beta라 하며 일종의 marketing 전략으로 쓰고 있지만, 원래 beta test란 어떤 program이 정확하게 동작하는지를 검토하는 기능 test가 아닌, 사용자 computer 환경에서 test해 보는 것을 말합니다. 왜냐햐면 개발자가 개발한 computer에서는 기똥차게 돌지만 그 이외의 computer에서 동작하는 것은 잘 안되는 경우가 수두룩빽빽이거든요. 모르긴 몰라도 지금 안철수연구소, 엄청난 비용을 치르고 있을 것이고, 주가도 많이 떨어졌을 것입니다. 미국 같은 곳이었으면 집단 소송 감이 아닐까요?
3. 약간 성격은 다르지만 이관에 대한 생각도 들었습니다. 저는 회사 전산 system 구축하는 쪽 일을 하고 있고, 따라서 그 회사가 도입한 computer에서만 잘 돌면 되기 때문에 수많은 일반 PC를 상대하는 안철수연구소보다는 사정이 훨씬 낫지만, 그러함에도 개발자들이 개발하는 개발계에서 검수계나 운영계로 이관하는 작업이 한 방에 되는 모습을 한 번도 본 적이 없습니다. 개인적으로 "이관 작업은 사람의 정성을 먹고 된다"고 표현하는데, 문제는 이관을 단순한 file 복사 수준으로만 알다 보니 이관 작업을 껌으로 보는 경우가 허다하다는 것입니다.
4. 대세는 역시 Web Application인가요? Beta test의 중요성 이야기를 했지만, 안철수연구소나 game 제작사들 같은 곳은 그 beta test를 100% 완벽하게 하는 것이 불가능합니다. 이번 안철수연구소 예를 보아도 대충 검사해 봐야 할 Windows의 major version으로만 헤아려 봐도 최소 XP, Vista, 2000 정도는 지원해야 할 것입니다. 그리고 위 세 version별로 32bit, 64bit version이 따로죠? 거기에다 각각의 Service Pack 및 Edition까지 따지면 그 조합은 더 엄청나집니다. 그리고 H/W는 더합니다. 사용자들이 어떤 CPU, 어떤 Graphic Card, main board 등등을 조합해 쓸 지, 그 조합의 총 갯수가 상상이 가십니까? 지금은 단종된 Graphic Card를 쓰는 고물 PC에서만 발생하는 오류라면? Web Application은 최소한 이런 문제는 훨씬 적습니다. 물론 Web Application도 Active X 쓰면 저런 문제 다 겪을 소지가 있는 것이고, Active X를 안 쓴다 해도 Browser 호환성 맞추는 것이 장난이 아니긴 합니다만(특히 아직도 많이 쓰는 IE 6은 Web 표준 안 지키기로 유명하죠. 이 글 보시는 분은 제발 Firefox나 IE 7을 써 주세효~ T.T Web 개발자도 너무 힘듭니다~).
써놓고 보니 안철수연구소가 이해는 간다는 논조가 되었습니다. 그래도 피해자로서 솔직히 짜증나긴 합니다. 금방 복구가 안되고 오전 내내 먹통이었다면 지금 여기에대 욕지기를 해대고 있었을 지도 모릅니다. Service Pack 검사는 해 봐야 하지 않았을까 합니다.
마지막으로 하고 싶은 말,
"Software의 영향력이 이제는 사회를 들썩일 정도로 커졌다"
는 이야기 되겠습니다. 특히 이 이야기는
"IT하면 반도체, 휴대폰, LCD나 들먹거리고, 우리나라가 IT 강국이라 하는 헛 IT 전문가들에게 꼭 해주고 싶은 이야기"
입니다.
2008. 2. 29. 12:15
Java에 대한 보이지 않는 위협 Computing에 관한 독백2008. 2. 29. 12:15
괄목할만한 성공
1995년 Java라는 언어가 생겼고, Web의 부흥과 맞물려 초창기에는 Java Applet, 현재는 Java Platform EE(Enterprise Edition)로 IT의 한 축을 그었다. Applet은 잠깐 반짝 하다 말았지만, 특히 Java Platform EE의 성공은 경이적이어서, 기업 전산 환경의 필수 middleware인 Web Application Server(이하 WAS)는 당연히 Java Platform EE 명세서에 준하는 것으로 생각하고(예전엔 Netscape Application Server라는 C/C++ 기반의 WAS도 있었지만 지금은 모두 Java Platform EE 명세를 따르는 WAS만 있는 것 같다), 따라서 기업/조직 전산 환경에서 Java는 가히 예전의 COBOL의 위치를 차지한다 해도 과언이 아니다. Embedded System 쪽으로는 특히 휴대전화 쪽으로 Java Platform ME(Micro Edition)이 널리 퍼졌고, Desktop이 조금 빈약하지만 Sun Microsystems가 Swing 다듬기에 여념이 없고, 특히 Eclipse의 SWT/JFace, RCP의 출현으로 말미암아, Platform 독립적인 Desktop Application 개발에도 Java가 세를 늘리고 있다(겪어보면 알겠지만 compile도 필요 없이 내가 짠 application이 Windows에서도 돌고 Linux에서도 돈다는 것은 정말 대단히 매력적인 일이다).
분명 Java는 문법이, 특히 C++에 비하면, 깔끔하다. Java 이전에 OOP를 한다고 하면 C++로 coding한다는 이야기였던 때가 있었는데, C도 그렇지만 이 C++도 code 자체가 대단히 난잡하다. 특히 MFC로 짠 Windows program code는 지금 봐도 그 너저분함에 질린다(그래서 개인적으로 C#의 등장을 환영한다. 최소한 Windows program도 깔끔하게 짤 수 있으니까). 그런데 이 Java는 C++에 비하면 상당히 우아한 code가 나올 수 있다. 그러다보니 요새는 'Java로 된 자료 구조', 'Java로 된 algorithm', 'Java로 된 OOP' 등, 학계에서도 교육용 목적으로 Java를 많이 가르치며 S/W 공학 같은 것을 논할 때 예제 code도 Java로 짠 것을 심심찮게 볼 수 있다.
또한, Java는 open source 개발자들에게도 매력적이었는지 Apache 재단, Eclipse 재단 등을 위시한 수많은 곳에서 Java 관련 제품을 개발하고 정보를 교류하고 있으며 이러한 산출물들은 Java 개발을 편리하게 하고, 새내기 개발자들이 참고할만한 교재 역할을 하며, Sun Microsystems 같은 Java 명세에 칼자루를 쥐고 있는 자들이 명세를 재정할 때 idea를 주고, 아울러 독단에 빠지지 않고 실질적으로 개발자들이 원하는 바를 잘 반영하게 하는 일종의 압력으로도 작용하여, 궁극적으로 Java의 세 확산을 일조하는 선순환 구조를 만들어냈다.
즉 현재 Java는 Thomas Kuhn이 '과학 혁명의 구조'라는 책에서 말한 바로 그 Paradigm이다.
Java의 비대화
위에서 살펴본 바와 같이 Java는 정말 성공적인 가도를 달려왔다. 그러나 요즈음 일종의 이상 징후가 나오는 것도 사실이다.
2004년에 나온 Java Platform SE 5는 꽤 큰 문법 추가가 있었다. 하나는 Generics요, 또 하나는 Annotation이다. 그런데 이것이 좀 code를 난잡하게 만들었다. 예를 들면,
public EnumMap(EnumMap<K, ? extends V> m)
java.util.EnumMap이라는 class의 생성자이다. JDK 1.4 이전 code였으면 public EnumMap(EnumMap m)이라고 끝났을 code이다. 물론 Generics를 도입한 결과 Type 확인을 compile 시에 할 수 있게 되어 ClassCastException 꼴은 덜 보게 되어서 결과적으로 program 안정성 향상에 기여한 것은 사실이나 위 code를 보면 "먼 소린지~"다. Java 문법도 간결했던 문법이, 슬슬 사용자의 요구를 수용하다 보니 점점 난잡해지고 있는 한 예라 하겠다. API적인 측면은 더하다. 지금 Java Platform SE 6의 API는 JDK 1.2의 API에 비하면 훨씬 방대하다. 즉, 기술이 복잡해지고 있다. 그리고 이 복잡도를 사용자들이 수용하기 어려울 때, Java는 스스로의 무게에 비틀댈 것이다. 많은 기술들이 그랬었던 것처럼. Java도 entrophy의 증가라는 열역학 법칙에 자유롭지 못한 것은 아닐까.
sciprt 언어들의 도전
Java Platform이 Web 개발에는 거대하고 복잡하여 부적절하다는 말들이 여기저기서 나오고 있다. 이들 주장은 주로 PHP나 Python, Ruby와 같은 script 언어를 좋아하는 사람들에게서 많이 나오는데, 그동안 Java 진영은 그런 언어로 개발한 Web은 고가용성 등에 문제가 있어 mission-critical한 기업 업무 개발에는 부적절하다고 주장했다(재미있는 것은 이러한 주장은 이제는 한 물 간 것으로 취급하는 TP Monitor 진영, 더 한 물 간 것으로 여기는 Mainfram 진영이 Java를 폄하할 때 하는 주장이다). 확실히, script 언어들은 개발 생산성은 좋다. 그러나 Java 진영은 IBM, Sun Microsystems, BEA, Oracle 같은 IT 업계 거물이 버티고 돈은 받지만 동작을 보증함에 비해, 동적 type 언어들은 open source 진영에서 나온 것이다 보니, Do-it-yourself인 이런 open source 결과물을 자신의 업무 환경에 턱 적용했다가 문제 생기면 본인이 스스로 뒷감당을 해야 하므로, 혁신보다 보신이 중요한 (거대) 기업 조직 생리 상 이런 것들을 채용하기는 어렵다. 실제로 그러한 언어로 된 Web 개발은 기업 규모의 전산 환경에서는 underground 취급당했다. 그러나 RubyOnRails로 대표하는 쾌속 Web 개발이 개발자들의 이목을 끌고, Google이나 Wikipedia 같은, 무시무시한 traffic을 견디는 동적 type 언어들로 개발한 site들이 출현하다 보니, 과연 고가용성 때문에 거대함과 복잡함을 감내해야 하는지, 과연 그런 것들이 고가용성에 문제가 있는지에 대한 회의가 많이 늘었다. Java는 이러한 도전에 대한 응전으로 이번 Java Platform SE 6부터 JVM 상에서 script 언어를 돌릴 수 있는 길을 열어놓았다. 하지만 script 언어라는 것이 Java를 제치고 Paradigm의 영예를 순식간에 대체할 수 있는 가능성은 적지 않다.
Java 새 version의 비활성화
요새 Microsoft는 Windows Vista를 열심히 팔고 있다. 그런데
이 Windows Vista 판매의 걸림돌은 Linux나 Solaris 같은 다른 운영체제가 아니라 바로 Windows XP,
Windows 2000 같은 이전 version의 Windows이다. 그런데 이 현상이 Java에도 나타나고 있으니, Java
Platform SE 6가 나오고 Java Platform EE 5가 나왔건만 아직도 현장에서는 JDK 1.4와 J2EE 1.4
기반의 WAS가 판을 치고 있다. 또한 WAS 제작사들도 Java Platform EE 5 인증 받는데 그닥 열의가 없다.
TmaxSoft는 Java SE Platform EE 5 기반 WAS인 JEUS 6을 개발했지만, 현재 그 회사 site는
JEUS 5 위주로 소개하고 있다. BEA는 Java Platform EE 5 기반 WAS로 이제서야 WebLogic
Server 10을 내놓았고, IBM 또한 J2EE 1.4 기반인 WebSphere Application Server 6.1에
머물러 있다. Open Source WAS의 대표 주자인 JBoss Application Server도 J2EE 1.4 명세에
일부 Java Platoform EE 5를 이루는 명세의 구현체 몇 개를 추가 탑재하는 식이다. 즉, 시장의 평가는 어떻게 보면
J2EE 1.4 기반 WAS로도 충분하다는 신호를 보내는 것이다. 또한 J2EE 1.4 명세는 JDK 1.4를 명시하므로
Java Platform SE 6은 고사하고 5도 각광을 덜 받는 것이다(이것은 위에서 언급한 문법 변화를 개발자들이 잘
수용하지 않기 때문이기도 하다).
Paradigm, 그리고 변곡점
아까도 말했듯 Java는 확고한 Paradigm이다. 그러나 현재 이 Paradigm이 현실과의 괴리를 보이는 징후가 여기저기서 포착할 수 있다. 어쩌면 우리는 Intel의 전 CEO였던 Andrew Grove가 쓴 책, "편집광만이 살아남는다(Only Paranoids Survive)"에서 나온 변곡점을 지나는 중인지 모른다. 어떤 미분 가능한 함수에서 변곡점은 기울기가 급변하는 지점인데 재미있는 것은 그 변곡점에 처해서는 그 부분이 변곡점인지 인지하기가 쉽지는 않다. 그러나 함수의 독립변수를 계속 진행시키다 보면 그 기울기가 점점 급변한다.
어차피 Java도 현상의 문제를 타파하기 위한 도구일 뿐이다. 가끔 어떤 computing platform에 대해 종교적인
믿음을 가진 신자들을 볼 수 있는데, 그러한 자세보다는 이러한 잘 드러나지 않는 변곡점을 기민하게 인식하고 새로운
Paradigm에 신속하게 자신을 적응시키 것이 현명하다 보여진다. 즉 적자생존(適子生存)이라는 말은 우리에게도 들어맞는
말이다. 그리고 또 하나, Thomas Kuhn이 과학 혁명의 구조에서 말한 것이 잘 들어맞는지 통사적(通史的)으로 살펴 보는
것도 재미있는 일일 것이다. 그리고 Java가 entrophy의 증대를 언제까지 성공적으로 제어할 지 지켜보는 것도 역시 흥미로울 것이다.
그나저나 Ruby랑 RubyOnRails를 공부해야겠다.
==================예전 블로그에 2007.5.22에 쓴 글
2008. 2. 28. 14:25
SI 업체는 정말 개발자의 적인가? Computing에 관한 독백2008. 2. 28. 14:25
전산과를 나와서, 곧 퇴사할 것이긴 하지만, LG CNS를 7년 6개월 정도 다닌 사람 입장에서 SI는 소프트웨어 개발자의 적인가?라는 글을 보았을 때, 참, 공감 가는 이야기다 싶었다(위 글에 나오는 업체 임원이 혹시 LG CNS?). 이 정도 경력이면 개발자가 바라본 SI 업체에 대해 썰 풀 자격 정도는 있다 싶어 이야기를 해보면...
일 단 SI업체는 기술로 돈 벌어먹는 회사가 절대 아니다. 만약 SI업체가 기술로 돈 벌어 먹는 회사면 개발자들은 그들의 핵심 역량이고, 따라서 기술 인력 양성에 심혈을 기울여야 한다. 그러나 징허니 잘 아시겠지만 그들은 개발자를 인력 파견 업체에서 고용한다. 핵심 역량은 절대로 아웃소싱하는 것이 아님은 경영의 기본이다. 그들이 그런 것을 모를 리 없고, 따라서 기술 및 기술 인력은 그들에게 핵심 역량은 절대 아니라는 사실. 그들이 필요로 하는 기술 인력이란, 아웃소싱한 기술자들과 의사 소통을 하고 작업 지시를 하고 일정 대비 진척률을 측정하여 작업이 처지면 독려하고(이 독려 방법이 참.... 휴가 반납, 끝없는 야근이란 것이지만서도), 문제 때문에 끙끙대면 해결사 역할을 할 수 있는, 대단히 프로젝트 관리자적인 사람을 뜻한다. 이런 일을 하기 위해서 기술 이해가 필요하고, 그래서 사원, 신입 때는 기술을 가르치긴 한다만. 그래서 대부분 SI업체에서 짬밥이 차면 점차 프로젝트 관리자 같은 일을 하게 된다.
미리 말한 것 같은데, SI업체는, 건설 분야로 치면 시공사가 아니라 CM을 하는 회사이고, 따라서 프로젝트 파이넌싱, 인력 소싱, 고객의 요구 사항 분석 및 그에 따른 가격 산정, 공정 및 진척률 관리, 프로젝트 비용을 관리하여 이익을 남기는 것이 핵심 역량이다. 따라서 그들에게 있어 기술 인력은 '언제나 조달 가능한 자원' 이상은 아니다. 그러나 실제 product는 그들 손 끝에서 나오고, product를 만드는 자가 있어야 SI의 핵심 역량도 할 일이 있는 것도 사실인데, 그걸 간혹 모르는 것 같단 말이지.
그들에게 있어 소프트웨어 개발은 공학(Engineering)이고 공학은 자연을 가공하여 유용한 것을 얻기 위함이 목적이고, 특히 산업 공학은 이러한 공학을 효율적으로 관리하기 위함이 목적이다. 공학이나 관리를 하려면 측정부터 시작을 해야 하는데, S/W란 것이 정말 무형의 것이다 보니, 이 측정이라는 것이 쉽지 않다. 정성적인 것을 정량적인 것으로 환산하면서 겪은 어려움이 여기서도 나오는데(이를테면 기업의 브랜드 가치를 돈으로 환산해서 마이크로소프트나 나이키의 브랜드 가치는 얼마내 하긴 하지만, 솔직히 그게 정말 현금 세는 것처럼 정확하다고 자신있게 말할 수 있나? 가격은 시장에서 결정나는데 그런 브랜드는 거래하는 것이 아니니 말이다) LOC(Line of Code), COCOMO, 기능 점수(functional point) 등 가지가지가 나오지만 정말 한 방에 사람들을 '아, 이거다~' 싶은 측정 체계(metric)가 없다. S/W 개발이 과연 공학적인 접근이 가능한 일인가 하는 주제는 이 글의 범위를 후딱 넘어버리니 이쯤하고, 문제는 SI업체들이 S/W 공학의 신봉자들인데 그럴 수 밖에 없는 것이, 그들은 개발사가 아니라 관리하는 회사기 때문이다. 그러니 공학적인 접근으로 S/W를 만드는 관리 체계 및 측정 체계를 제공한다는 방법론이나 S/W 공학에 매달릴 수 밖에.(SI project를 하다보면, 그 일하는 체계가 정말 건설/토목사의 그것과 너무도 흡사하다. 심지어는 시공사, 감리사 같이 사업자와 감리사가 있다).
그러다 보니 그들은 S/W Factory라는 말에 솔깃할 수 밖에 없고, model만 그리면 product가 나온다는 MDA에 혹하며, 마치 그것을 S/W 개발의 미래라고 부르짖게 되는 것이나, 실제 개발해 보신 분은 아시겠지만, 그 변덕스러운 고객의 요구 사항을, ERP도 뜯어고치라고 하는 그 변덕을 과연 그런 것으로? 아울러 MDA라는 것도 웃기는 것이, LISP이나 Scheme 같은 함수형 언어는 어떻게 UML로 표현할 것이며, Python이나 Ruby 같은 언어에 대한 UML Profile은 만들 수 있는겨? 동적 type이라는 이들 언어의 특성은 단순한 객체 지향 관점에서만 커버하기는 쉽지 않을 것이다. UML은 product를 만들기에는 그 표현력이 모자라며, 그 간극을 메꾸기 위해 UML에도 무언가가 마구 추가되긴 하는데, 사람 기를 질리게 한단 말이지. MDA의 허구를 논하면 또 글의 주제를 넘어버리니 이만하고, 여하튼 그들은 말도 안되는 것을 바라고 믿는데, 그 이유는 S/W 개발의 자동화를 간절히 바라기 때문이다. 그렇게만 된다면 S/W 생산 line만 관리하면 되고 개발자는 필요 없기 때문이다(그러나 그 행동이 연목구어임을 알기에 절대 쫄지 않는다. 앞으로도 그들은 계속 인력 구하고 다닐 것이다. 대신 지금과 같이 대우는 안하겠지).
말이 상당히 길어졌는데 결론은 다음과 같다.
SI업체, 전산과 나와서 개발자로 크려면 가지 마라!
단,
대기업 가고 싶어 SI 업체 갈 것이면 사원,늦어도 대리까지만 다녀라.
SI업체, 산공과나 경영과(특히 MIS 전공) 나왔다면 괜찮다!
단,
다 임원 되는 것은 아니라는 것을 명심하라!
(이 과 출신들은 자기가 다 임원하는 줄 안다니깐 --)
=================================
이전 블로그에서 2007.5.30에 쓴 글
일 단 SI업체는 기술로 돈 벌어먹는 회사가 절대 아니다. 만약 SI업체가 기술로 돈 벌어 먹는 회사면 개발자들은 그들의 핵심 역량이고, 따라서 기술 인력 양성에 심혈을 기울여야 한다. 그러나 징허니 잘 아시겠지만 그들은 개발자를 인력 파견 업체에서 고용한다. 핵심 역량은 절대로 아웃소싱하는 것이 아님은 경영의 기본이다. 그들이 그런 것을 모를 리 없고, 따라서 기술 및 기술 인력은 그들에게 핵심 역량은 절대 아니라는 사실. 그들이 필요로 하는 기술 인력이란, 아웃소싱한 기술자들과 의사 소통을 하고 작업 지시를 하고 일정 대비 진척률을 측정하여 작업이 처지면 독려하고(이 독려 방법이 참.... 휴가 반납, 끝없는 야근이란 것이지만서도), 문제 때문에 끙끙대면 해결사 역할을 할 수 있는, 대단히 프로젝트 관리자적인 사람을 뜻한다. 이런 일을 하기 위해서 기술 이해가 필요하고, 그래서 사원, 신입 때는 기술을 가르치긴 한다만. 그래서 대부분 SI업체에서 짬밥이 차면 점차 프로젝트 관리자 같은 일을 하게 된다.
미리 말한 것 같은데, SI업체는, 건설 분야로 치면 시공사가 아니라 CM을 하는 회사이고, 따라서 프로젝트 파이넌싱, 인력 소싱, 고객의 요구 사항 분석 및 그에 따른 가격 산정, 공정 및 진척률 관리, 프로젝트 비용을 관리하여 이익을 남기는 것이 핵심 역량이다. 따라서 그들에게 있어 기술 인력은 '언제나 조달 가능한 자원' 이상은 아니다. 그러나 실제 product는 그들 손 끝에서 나오고, product를 만드는 자가 있어야 SI의 핵심 역량도 할 일이 있는 것도 사실인데, 그걸 간혹 모르는 것 같단 말이지.
그들에게 있어 소프트웨어 개발은 공학(Engineering)이고 공학은 자연을 가공하여 유용한 것을 얻기 위함이 목적이고, 특히 산업 공학은 이러한 공학을 효율적으로 관리하기 위함이 목적이다. 공학이나 관리를 하려면 측정부터 시작을 해야 하는데, S/W란 것이 정말 무형의 것이다 보니, 이 측정이라는 것이 쉽지 않다. 정성적인 것을 정량적인 것으로 환산하면서 겪은 어려움이 여기서도 나오는데(이를테면 기업의 브랜드 가치를 돈으로 환산해서 마이크로소프트나 나이키의 브랜드 가치는 얼마내 하긴 하지만, 솔직히 그게 정말 현금 세는 것처럼 정확하다고 자신있게 말할 수 있나? 가격은 시장에서 결정나는데 그런 브랜드는 거래하는 것이 아니니 말이다) LOC(Line of Code), COCOMO, 기능 점수(functional point) 등 가지가지가 나오지만 정말 한 방에 사람들을 '아, 이거다~' 싶은 측정 체계(metric)가 없다. S/W 개발이 과연 공학적인 접근이 가능한 일인가 하는 주제는 이 글의 범위를 후딱 넘어버리니 이쯤하고, 문제는 SI업체들이 S/W 공학의 신봉자들인데 그럴 수 밖에 없는 것이, 그들은 개발사가 아니라 관리하는 회사기 때문이다. 그러니 공학적인 접근으로 S/W를 만드는 관리 체계 및 측정 체계를 제공한다는 방법론이나 S/W 공학에 매달릴 수 밖에.(SI project를 하다보면, 그 일하는 체계가 정말 건설/토목사의 그것과 너무도 흡사하다. 심지어는 시공사, 감리사 같이 사업자와 감리사가 있다).
그러다 보니 그들은 S/W Factory라는 말에 솔깃할 수 밖에 없고, model만 그리면 product가 나온다는 MDA에 혹하며, 마치 그것을 S/W 개발의 미래라고 부르짖게 되는 것이나, 실제 개발해 보신 분은 아시겠지만, 그 변덕스러운 고객의 요구 사항을, ERP도 뜯어고치라고 하는 그 변덕을 과연 그런 것으로? 아울러 MDA라는 것도 웃기는 것이, LISP이나 Scheme 같은 함수형 언어는 어떻게 UML로 표현할 것이며, Python이나 Ruby 같은 언어에 대한 UML Profile은 만들 수 있는겨? 동적 type이라는 이들 언어의 특성은 단순한 객체 지향 관점에서만 커버하기는 쉽지 않을 것이다. UML은 product를 만들기에는 그 표현력이 모자라며, 그 간극을 메꾸기 위해 UML에도 무언가가 마구 추가되긴 하는데, 사람 기를 질리게 한단 말이지. MDA의 허구를 논하면 또 글의 주제를 넘어버리니 이만하고, 여하튼 그들은 말도 안되는 것을 바라고 믿는데, 그 이유는 S/W 개발의 자동화를 간절히 바라기 때문이다. 그렇게만 된다면 S/W 생산 line만 관리하면 되고 개발자는 필요 없기 때문이다(그러나 그 행동이 연목구어임을 알기에 절대 쫄지 않는다. 앞으로도 그들은 계속 인력 구하고 다닐 것이다. 대신 지금과 같이 대우는 안하겠지).
말이 상당히 길어졌는데 결론은 다음과 같다.
SI업체, 전산과 나와서 개발자로 크려면 가지 마라!
단,
대기업 가고 싶어 SI 업체 갈 것이면 사원,늦어도 대리까지만 다녀라.
SI업체, 산공과나 경영과(특히 MIS 전공) 나왔다면 괜찮다!
단,
다 임원 되는 것은 아니라는 것을 명심하라!
(이 과 출신들은 자기가 다 임원하는 줄 안다니깐 --)
=================================
이전 블로그에서 2007.5.30에 쓴 글
2008. 2. 25. 18:32
비운의 낭만 컴퓨터 - NeXTCube Computing에 관한 독백2008. 2. 25. 18:32
정육면체의 검은색 몸체를 가진, 80년대 후반 ~ 90년대 초반의 꿈의
컴퓨터, NeXTCube입니다. 멋지지 않나요? 본체와 모니터 뿐 아니라 시리즈로 팔리는 레이저 프린터(요새는 레이저 프린터가
개인도 쓸 정도로 대중화된 프린터이지만 당시만 해도 개인들은 지금은 보기도 힘든 9핀 도트 매트릭스 프린터라도 있으면 정말
호화로운 장비의 소유자였답니다. 그러니 레이저 프린터는 가공할만한 꿈의 프린터였죠)까지도 검은 색으로 통일한, 디자인 측면에서
보아도 보석 같이 빛났던 컴퓨터입니다(실제 가격도 당시 달러로 1만 달러가 넘었다 함).
이것을 만든 회사는 지금은 존재하지 않는 NeXT라는 회사입니다. 그리고 이 회사의 설립자는 현재 애플컴퓨터의 CEO인 스티브
잡스(Steve Jobs)입니다. 1980년도에 애플은 존 스컬리(X파일의 스컬리와 무관함. 이사람은 남자입니다 ^^)라는 경영
전문가를 영입합니다. 그런데 이 존 스컬리는 애플의 실적 부진을 이유 삼아 '합법적으로' 애플에서 스티브 잡스를 쫓아냅니다(마치
국회가 '합법적으로' 대통령을 탄핵한 것이 생각나네요). 돈만 아는 경영 전문가와 당시 '꿈의 기계'를 만들 생각만 하는
낭만적인 기술장이 출신인 스티브 잡스가 사사건건 부딪히다, 결국 정치에서 스티브 잡스가 진 거죠, 뭐. 여담입니다만, 이 존
스컬리도 '뉴튼(Newton)'이라는 PDA(이 뉴튼이 바로 PDA라는 개념을 만든 물건입니다. 이것이 있어서 팜파일럿도 나오고
포켓PC도 나올 수 있었습니다. 이 뉴튼 디자인도 정말 죽입니다. 역시 애플의 디자인 감각은 크~)에 올인했다가 뉴튼의 판매
실적 부진을 이유로 쫓겨납니다(선각자의 비애라고나 할까요). 그리고 그 다음 마이클 스핀들러, 길버트 아멜리오라는 차례대로
CEO로 왔다가 쫓겨나고 다시 스티브 잡스를 임시 CEO(Interim CEO)로 부릅니다. 이 이야기는 좀 있다가 다시 하죠.
아무튼 스티브 잡스는 그래도 배운 것이 도둑질이라고, 애플에서 잘린 다음 NeXT사를 설립하고 꿈의 기계를 만들겠다고 작심합니다.
아까도 말했듯 당시의 스티브 잡스는 꿈의 기계를 만들 꿈을 가지고 있었고,
그래서 값 생각은 안하고 그야말로 초호화판 기계를 만듭니다(당시 레이저 프린터가 무지막지하게 비싼 물건이라는 것은 말씀드렸죠?
이런 레이저 프린터를 기본 프린터로 턱하고 채용할 정도였으니 가격 생각은 정말 눈꼽만큼도 안했다고 볼 수 밖에 없습니다).
그것이 바로 이 NeXTCube입니다. 저는 이것을 1988년도 '월간 과학'이라는 과학 잡지에서 사진으로 봤는데(당시 중학교
2학년), 보자마자 뻑이 갔죠. 디자인도 디자인이려니와 당시 개인용 컴퓨터로는 엄청난 성능~ 크~.
그러나 이 컴퓨터의 진가는 하드웨어의 성능에만 있는 것은 아니었습니다. 이 NeXTCube를 쓰도록 사람들을 유혹하는 진짜 이유는
바로, 이 NeXTCube의 운영체제 NEXTSTEP이었습니다(NEXTSTEP을 쓰기 위하여 NeXTCube를 쓴다는 말이
정말로 있었습니다). BSD UNIX를 기반으로 하여 NeXT사가 손을 본 NeXTCube 전용 운영체제였는데, 지금 봐도
그 시절에 이런 것을 구현해 냈다는 것에 경탄할 정도로 진보적인 기술들이 녹아 있는 운영체제였습니다. 그 중 대표적인 것이
DO(Distributed Object)라는 것인데, 이것은 한 때 컴퓨터 업계를 뒤흔들었던 분산 객체 기술입니다. CORBA,
EJB, DCOM 같은 분산 객체 기술이 2000년대 초에 들어 본격적으로 활성화되었다는 점을 고려해 볼 때 이미 10여 년
전에 나온 운영체제에서 분산 객체 기술을 구현했다는 것에는 정말 감탄사를 연발할 수 밖에 없습니다(이 운영체제가 나올 당시
PC용 운영 환경으로 MS가 내놓은 것이 윈도우 3.0 이전 버전이었을 겁니다. 그것을 대비시킨다면 정말 경악할만한
기술력이죠). GUI도 정말 놀라운 수준이었는데 화면 자체를 포스트스크립트(Postscript)를 쓴 디스플레이
포스트스크립트(Display Postscript)를 써서, 완벽한 WYSIWYG을 구현했으며 그 당시 PC들이 256 컬러
가지고 경악한 시절에 요즈음의 트루 컬러에 가까운 색을 내는 엄청난 물건있었습니다. 그리고 이 NEXTSTEP의 UI는 다른
운영체제의 전범이 될 정도로 직관적이고 훌륭했습니다.
그러나 기술적으로 우수한 것이 상업적으로도 성공한다는 보장은 없는 법.
시장에서는 실패했는데 그 이유는 당시 가격으로 1만 달러가 넘는 높은 가격입니다. 스티브 잡스는 이 컴퓨터를 만들면서 교육용
시장을 겨냥했으나 교육용 시장은 애플의 매킨토시 벽을 넘는데 실패했고(미국 이야기입니다), 엔지니어링 워크스테이션으로 팔기에는
프로세싱 파워가 썬이나 아폴로(HP에 흡수된 지 꽤 되었죠)의 엔지니어링 워크스테이션에 비해 딸린 편이면서도(모토롤라
MC68000 계열의 CPU를 썼는데 썬이나 아폴로의 엔지니어링 워크스테이션의 RISC CPU보다는 프로세싱 파워가 딸리긴
했습니다) 값은 비쌌죠. 즉 값은 비싼데 성능이 약간 어정쩡해서 연구소 같은 곳에 조금 파는 정도로 끝나버리고 맙니다.
결국 NeXT사는 일본 캐논의 지분 참여로 근근히 버티다, 결국 하드웨어
사업은 일본 캐논에 팔아버리고, NEXTSTEP 판매에만 주력하기로 합니다. 즉, MS 같은 운영체제 전문 회사로 돌아선
것이죠. 그리고 NEXTSTEP을 인텔 CPU에도 포팅합니다. 제가 대학 2학년 때였나요, 당시 한국에서도 신명시스템즈(지금도
있는지 모르겠지만)라는 회사가 이 인텔 CPU용 NEXTSTEP을 팔았었습니다. 컴퓨터 전문지도 상당히 비중있게 이 사실을
다루었었고요. 제가 다니던 학교에도 신명시스템즈 사람들이 와서 세미나 하고 홍보하고 그랬었고, 그 덕에 저도 당시 꿈의 PC였던
펜티엄(펜티엄 2도 아니고 펜티엄 3도 아닌 펜티엄)에서 돌아가는 아름다운 NEXTSTEP을 침 질질 흘리며 구경했던 기억이
나는군요. 당시 신명시스템즈는 NEXTSTEP의 완벽한 화면 출력 기능을 무기로 하여 DTP 시장을 파고들려 했던 것으로
기억합니다. 매킨토시가 해당 분야를 꽉 잡고 있긴 했지만 NEXTSTEP은 PC에서 도는 운영체제라는 것을 강점으로 생각한
것이겠죠. 그리고 당시 그 비싼 펜티엄 PC를 사서 NEXTSTEP을 돌린 동기 녀석이 있었는데, 친구들의 부러움을 상당히
받았더랬습니다.
그러나 시대를 너무 앞선 탓에 당시 일반적 PC 사양보다 더한 사양을 요구한 NEXTSTEP은 시장에서 실패했고 이에 스티브
잡스는 다시 한 번 재주를 넘습니다. 바로 OPENSTEP이죠. 옆의 OPENSTEP 로고를 잘 살펴보시죠. OPENSTEP
및에 'FOR WINDOWS'라는 문구가 보이시나요? 네, OPENSTEP은 당시 시장을 장악하고 있던 Windows NT나
Solaris 같은 운영체제 위에서 해당 운영체제에서 NEXTSTEP의 진보적인 데스크탑 환경을 구현하는 것으로 전략을 바꾼
것입니다. 당시 많은 이들이 NEXTSTEP의 진보적 데스크탑 환경에 너무도 매료되었기 때문에 이 전략은 일견 타당성이 있는
결정이라 할 수 있죠. GNUSTEP이나 AFTERSTEP이
라는 말을 들어보셨습니까? NEXTSTEP의 진보적 데스크탑 환경에 매료된 오픈소스 개발자들이 리눅스 환경에서 돌아가는
OPENSTEP을 만들어 보자고 나서서 시작한 프로젝트죠. 그만큼 NEXTSTEP은 많은 전산장이들을 매료시켰습니다.
아울러 옆길로 새는 이야기이지만, 이 OPENSTEP을 발표하면서 NeXT사는
또 하나의 혁신적 제품을 출시하는데 바로 'WebObject'라는 제품입니다. 그당시에는 이 제품이 무슨 용도인지를 알지
못했으나 지금 생각해 보니 이것은 바로 요새 말 많은 Web Application Server(이하 WAS)였더군요. 요사의
WAS의 표준처럼 되어 있는 J2EE 기반은 아니지만, OPENSTEP의 객체 기술을 이용하여 90년대 중, 후반에 이미
NeXT사는 WAS를 내놓은 것입니다. 정말 대단한 선견지명이라 아니할 수 없습니다. WebObject는 바로 NeXT사가
OPENSTEP을 기업용 시장에도 진출시키겠다는 전략의 표현인 셈이죠. 그리고 이 WebObject는 현재 애플이 계속 출시하여
애플이 노리는 기업용 시장 진출 중 소프트웨어 분야의 첨병 노릇을 하고 있습니다(현재 기업용 시장 진출의 하드웨어쪽 첨병은
XServe라는 제품).
그러다 애플이 NeXT사를 인수하고 스티브 잡스가 애플의 임시 CEO(Interim CEO) 역할을 맡게 되는 사건이 벌어집니다.
당시 애플은 시대에 뒤떨어진 MacOS를 대체할 새로운 매킨토시 운영체제를 개발 중이었는데 IBM과 합작으로 코드명
'Pink'라는 프로젝트도 하고 'Taligent'
라는 코드명의 운영체제 개발 프로젝트도 수행했지만 모두 실패합니다. 새 운영체제를 개발해야 하는데 시간이 모자란 애플은 당시에
출시된 운영체제를 인수하기로 하고 바로 NeXT사의 NEXTSTEP과, 애플 출신 프랑스계 미국인 '장 루이 가제'가 세운
'Be'사의 'BeBox'라는 하드웨어용 운영체제 'BeOS'를 놓고 저울질을 합니다. 그러다 결국 완성도가 더 높은
NEXTSTEP을 사기로 하죠. 이 일은 애플이 NEXTSTEP이라는 대단한 운영체제의 소유권을 가지게 된다는 것과, 자신이
설립한 애플에서 쫓겨난 스티브 잡스가 임시기는 하지만 다시 애플의 CEO가 된다는(현재는 정식 CEO임) 드라마틱한 요소까지
곁들여져 컴퓨터 업계의 대단한 이슈 거리가 됩니다. 그리고 애플은 MacOS와 NEXTSTEP을 결합하는 프로젝트를
출범시킵니다(그 당시 컴퓨터 잡지 좀 보신 분들은 'Copland', 'Rhapsody'라는 이름을 꽤 보셨을 듯 싶습니다.
모두 이들 프로젝트에 관한 코드명이었죠). 그리고 태어난 것이 바로 MacOS X입니다. MacOS X의 API 중
Cocoa라는 것이 있는데 이 Cocoa는 Objective-C라는 언어를 기반으로 하는데, 바로 이 Cocoa가
NEXTSTEP의 영향을 받은 부분이라고 합니다. 아울러 MacOS X에는 옛날 MacOS 버전에는 있지도 않은 UNIX
터미널이 있는데 이는 NEXTSTEP이 BSD UNIX를 기초로 하는 것의 영향을 받은 것이죠. 사실 MacOS X은 기존
MacOS의 후계자라기보다는 오히려 NEXTSTEP의 후계자라 보는 것이 더 타당할 듯 싶습니다.
1999 년 말에 NeXT 기계를 우연히 본 적이 있습니다(IBM PC에서 NeXTSTEP이 돌아가는 것이 아닌 진짜 NeXT 기계).
NeXTCube는 아니고 NeXTStation이었는데(왼쪽 사진) 대학 4학년 때 교양으로 수학을 들었었거든요? 그 교양 수학
가르치는 교수님 연구실에 들를 일이 있었는데 그 연구실에서 NeXTStation을 보았죠. 1999년 말이었는데 아직도 그
NeXT 기계에서 각종 수학 관련 프로그램을 돌리시더군요. 하드웨어 생산이 중단되어도 한참 전에 중단된, 20세기
컴퓨팅 기술 진보의 상징이었던 기계를 21세기를 코 앞에 둔 세기말에 보니 감회가 정말 새로왔습니다(그 교수님 아직도 그 기계 쓸라나 몰라). '오우, 교수님,
NeXT 쓰시네요?' 하면서 이유없이 반가와했더랬죠. '네가 NeXT를 알아? 이거 나올 때 넌 중고등학생이었 터인데?' 하시던
말씀이 생각납니다.
'Web 창시자가 말하는 WWW의 미래'라는 글은 WWW의 창시자 팀 버너스 리에 대한 글인데, 읽어보면 아시겠지만 WWW이 최초로 구현된 컴퓨터가 바로 NeXTCube였습니다. 만약 당시에 팀 버너스 리가 NeXTCube를 쓸 수 없었다면 아마 WWW은 한참 뒤에나 발명되었을 것입니다. 당시 GUI도 희귀한 시절에, 팀 버너스 리가 명령행 프롬프트나 깜빡거리는 컴퓨터를 썼다거나 후져빠진 윈도우 3.0도 아니던 시절의 윈도우, 혹은 프로그래밍하기 엄청 어려운 X Window(당시엔 GTK+나 QT 같은 것이 아닌 Xlib을 가지고 직접 X Window용 프로그램을 짰던 것을 기억하세요)를 접했다면 제 생각엔 절대 WWW을 발명하지 못했을 것 같습니다.
써 놓고 보니 NeXTCube 이야기보다는 NEXTSTEP 이야기를 더 한 것
같네요. 어찌 되었던 비록 시장에서는 실패한 하드웨어였지만, 이렇게 우연히 NeXTCube는 자신의 진보적인 기능
덕택에 WWW의 자궁 역할을 제대로 하게 되었습니다. 세상은 그래서 참 재미있습니다. 하핫!
----------------------------------------------------------------------
예전 블로그에 2004년 3월 19일에 썼던 글.
2008. 1. 23. 16:42
Internet의 발달, 말바꾸기를 까발리다. Computing에 관한 독백2008. 1. 23. 16:42
누가 그러더군요. 김대중 정부가 대한민국 민주주의 발전에 정말 크게 기여한 것은 IT, 특히 인터넷의 대중화라고요. IT의 발달로 블로그 등을 통해 자신의 생각을 널리 퍼뜨리는 것이 쉬워지다 보니 확실히 기성 언론만 장악하면 되는 세상은 더 이상 아닌 듯 합니다. 물론 IT에 어두워 기존 미디어에만 의존하는 분들도 계시긴 하지만요.
또 하나, IT의 발달 덕에 어떤 일에 대한 기록이 겁날 정도로 잘 되고, 검색 및 열람의 비용이 아날로그적 방식보다 극적으로 싸졌습니다. 그러다 보니 재미있는 현상도 나오는데.... 다음 블로그 글을 보시죠.
http://media.hangulo.net/330
최근 정부 조직 개편안에 대해 노무현 대통령이 거부권 행사를 할 지도 모르겠다는 의사를 표명하자 한나라당 측이 "우리는 10년 전에 안그랬는데 너는 왜 그러니?"라는 말을 한 것이 널리 보도가 되자, 정말 10년 전에 한나라당이 그랬는지를 써 놓은 글입니다. 한나라당 안상수 의원이 10년 전 김대중 정부 출범에 따른 정부 조직 개편안에 대해 어떤 자세를 취했는지, 국회 의안정보시스템 링크까지 걸어가며 상기시키는군요. 이 글을 보니 저도 기억납니다. 당시 김대중 정부의 총리로 김종필씨를 세우려 하자 한나라당 펄펄 뛰던 거요. 그러면서 '그 때 우리는 안 그랬는데, 너는 왜 그러니?'라는 말을 참 잘 하네요. ㅋ. 노무현 대통령의 거부권 시사의 시시비비와는 별개로 자신의 과거 행적을 까먹는 한나라당 관계자들의 부주의함은 실망스럽습니다. 여하튼 의안정보시스템 및 인터넷이 없었다면 이런 블로그 글은 써 질 수도 없었을 것입니다. 정보 통신의 발달 만세~!
오늘 아침 공짜 신문을 보니 100분 토론 같은 프로그램에서 어떤 여성 방청객이 대운하 찬성론자로 나온 패널에게 "3년 전엔 반대하시던 분이 그 3년 만에 어떻게 입장이 바뀌셨죠?"라는 질문을 해서 해당 패널이 얼굴이 속된 말로 쪽팔려서 얼굴이 푸르락 붉으락 했다고 합니다. 그 기사 보니 그 분, 참여하시기 전에 자료 조사를 하신다고 하네요. 요즘 자료 조사 하는데 인터넷이 빠질래야 빠질 수가 없겠죠?
조선일보 같은 신문들의 예전 기사들은 말할 것도 없고, Internet과 정보통신의 발달로 인해 검색이나 정보에 대한 접근 및 개인이 자신의 생각을 퍼뜨리는 것이 손쉬워지면서 말바꾸던 사람들, 속된 말로 쪽을 팔고 있습니다.
언론이나 공인 여러분, 공공에 의사를 표명하기 전에 전에 내가 뭔 말을 했나, 무슨 글을 썼나, 한 번 되새겨 보심이 어떨까요? 개망신 떨기 전에요. 여하튼 정보 통신의 발달로 변하는 우리 생활의 단상을 본 것 같아 흥미로와 글 남겨 봅니다.
여하튼, 요새의 대한민국 국민들은 마냥 예전처럼 순식간에 달아오르고 순식간에 잊어먹는 국민은 더이상 아닌 듯 합니다.
(2008.1.25 추가)
http://iandyou.egloos.com/1334165
10년 전은 그 정도였지만 5년 전 노무현 정부 때는 협조는 커녕 정말 장난 아니었군요. (-_-) 그러고서는 '우리도 협조 잘 했으니 잘 해줘'라고 말을 하다니...... 건망증일까요, 넉살일까요?
또 하나, IT의 발달 덕에 어떤 일에 대한 기록이 겁날 정도로 잘 되고, 검색 및 열람의 비용이 아날로그적 방식보다 극적으로 싸졌습니다. 그러다 보니 재미있는 현상도 나오는데.... 다음 블로그 글을 보시죠.
http://media.hangulo.net/330
최근 정부 조직 개편안에 대해 노무현 대통령이 거부권 행사를 할 지도 모르겠다는 의사를 표명하자 한나라당 측이 "우리는 10년 전에 안그랬는데 너는 왜 그러니?"라는 말을 한 것이 널리 보도가 되자, 정말 10년 전에 한나라당이 그랬는지를 써 놓은 글입니다. 한나라당 안상수 의원이 10년 전 김대중 정부 출범에 따른 정부 조직 개편안에 대해 어떤 자세를 취했는지, 국회 의안정보시스템 링크까지 걸어가며 상기시키는군요. 이 글을 보니 저도 기억납니다. 당시 김대중 정부의 총리로 김종필씨를 세우려 하자 한나라당 펄펄 뛰던 거요. 그러면서 '그 때 우리는 안 그랬는데, 너는 왜 그러니?'라는 말을 참 잘 하네요. ㅋ. 노무현 대통령의 거부권 시사의 시시비비와는 별개로 자신의 과거 행적을 까먹는 한나라당 관계자들의 부주의함은 실망스럽습니다. 여하튼 의안정보시스템 및 인터넷이 없었다면 이런 블로그 글은 써 질 수도 없었을 것입니다. 정보 통신의 발달 만세~!
오늘 아침 공짜 신문을 보니 100분 토론 같은 프로그램에서 어떤 여성 방청객이 대운하 찬성론자로 나온 패널에게 "3년 전엔 반대하시던 분이 그 3년 만에 어떻게 입장이 바뀌셨죠?"라는 질문을 해서 해당 패널이 얼굴이 속된 말로 쪽팔려서 얼굴이 푸르락 붉으락 했다고 합니다. 그 기사 보니 그 분, 참여하시기 전에 자료 조사를 하신다고 하네요. 요즘 자료 조사 하는데 인터넷이 빠질래야 빠질 수가 없겠죠?
조선일보 같은 신문들의 예전 기사들은 말할 것도 없고, Internet과 정보통신의 발달로 인해 검색이나 정보에 대한 접근 및 개인이 자신의 생각을 퍼뜨리는 것이 손쉬워지면서 말바꾸던 사람들, 속된 말로 쪽을 팔고 있습니다.
언론이나 공인 여러분, 공공에 의사를 표명하기 전에 전에 내가 뭔 말을 했나, 무슨 글을 썼나, 한 번 되새겨 보심이 어떨까요? 개망신 떨기 전에요. 여하튼 정보 통신의 발달로 변하는 우리 생활의 단상을 본 것 같아 흥미로와 글 남겨 봅니다.
여하튼, 요새의 대한민국 국민들은 마냥 예전처럼 순식간에 달아오르고 순식간에 잊어먹는 국민은 더이상 아닌 듯 합니다.
(2008.1.25 추가)
http://iandyou.egloos.com/1334165
10년 전은 그 정도였지만 5년 전 노무현 정부 때는 협조는 커녕 정말 장난 아니었군요. (-_-) 그러고서는 '우리도 협조 잘 했으니 잘 해줘'라고 말을 하다니...... 건망증일까요, 넉살일까요?
2008. 1. 11. 12:11
IBM DeveloperWorks, Grid Computing Zone 중지 Computing에 관한 독백2008. 1. 11. 12:11
Grid Computing, 나왔을 땐 참 열광적이었으되 흐지부지된 또 하나의 기술에 이름을 올리려나 봅니다. IBM이나 Oracle이 특히 열정적으로 Grid Computing을 외치고 다녔지만, 사실 일반 사용자들에게 그닥 와 닿는 이야기가 영~ 아니다 보니...... 사실 대규모 과학계산용 computing에서 좀 썼던 것을 사업화한다는 게 어디 쉽겠습니까?
IBM DeveloperWorks에서 Grid Computing Zone이 중단되었습니다. 개발자를 위시한 많은 이들이 별로 관심을 안 가진다는 방증이자, 결국 돈이 안된다는 방증 아닐까 합니다.
아래는 해당 내용을 공지하는 한국 DeveloperWorks screen shot.
아래에서 보시듯 미국 Developerworks도 마찬가지입니다. 즉 IBM 본사 차원의 결정이란 뜻입니다.
역시 기술이란 다 쓸모있는 것은 아닌듯 합니다.
IBM DeveloperWorks에서 Grid Computing Zone이 중단되었습니다. 개발자를 위시한 많은 이들이 별로 관심을 안 가진다는 방증이자, 결국 돈이 안된다는 방증 아닐까 합니다.
아래는 해당 내용을 공지하는 한국 DeveloperWorks screen shot.
아래에서 보시듯 미국 Developerworks도 마찬가지입니다. 즉 IBM 본사 차원의 결정이란 뜻입니다.
역시 기술이란 다 쓸모있는 것은 아닌듯 합니다.
2008. 1. 9. 10:17
하얀말의 미투데이 - 2008년 1월 8일 Computing에 관한 독백2008. 1. 9. 10:17
- Telnet Client Program 뭐 쓰세요? 2008-01-08 10:24:55
- UNIX에서 작업할 일이 있으면 필수적인 것이 Telnet Client이다. SecureCRT를 쓰지만 마음에 쏙 드는 Open Source Telnet Programe은 아직 못 찾았다. 2008-01-08 10:29:24
이 글은 ryudaewan님의 2008년 1월 8일의 미투데이 내용입니다.
2008. 1. 3. 11:55
Silverlight 적용? Web 표준부터 지켜라! Computing에 관한 독백2008. 1. 3. 11:55
이번 달 마소를 보니 Microsoft가 열심히 전도하고 있는 Silverlight 기사가 또 나왔더군요. SBS가 Silverlight를 적용했다 합니다(Oracle이 포철에 ERP 팔고 열심히 성공 사례로 나팔 불던 생각이 났습니다. 이젠 SBS인가...). '차세대 웹은 브라우저를 초월하여...'라는 김국현씨 글도 본 적 있어서, 한 번 실 사례라는 것을 보기로 했습니다.(그런데 이 글은 비판적 견지에서 읽을 필요가 있어 보입니다. 이 분, 현직 Microsoft 부장이거든요.... 쉽게 말해 중립적인 인물은 못된다는 것. 이 글에 대한 반론은 한국모질라커뮤니티의 중요 인물이자 다음커뮤니케이션 직원인 채니님의 '반론: 차세대 웹은 브라우저를 초월하여...'을 읽어보세요. 판단은 여러분 자유!).
보는 관점은 Web 접근성! Microsoft의 그간 행적을 볼 때 또 Windows에서 IE에서만 되는 것은 아닌가 하는 의구심이 듭니다.
결론은..... 검증을 못했습니다. 왜냐하면.... 일단 다음을 보시죠.
SBS Web site의 첫 화면을 Windows용 FireFox 2.0.0.11에서 본 모습입니다. Silverlight는 둘째 치고 첫 화면부터 IE 아니면 이 지경이니...
참고로 IE에서는 아래 그림과 같이 자알 나옵니다.
헉, 그런데 Active X를 설치하려 드네요. (T.T)
Silverlight니 Flex니 RIA니 뭐니 이전에 Web 표준이 우선인 것을 절감한 사례였습니다.
(2008.1.10. 내용 추가)
Microsoft 미국 site에 Firefox로 들어가니 Firefox용 Silverlight runtime을 받게 하네요. 일단 Windows용 FireFox에서 Silverlight를 쓴 site는 접근이 가능하겠습니다. Linux 상의 Browser는? 더 지켜봐야겠지요?
보는 관점은 Web 접근성! Microsoft의 그간 행적을 볼 때 또 Windows에서 IE에서만 되는 것은 아닌가 하는 의구심이 듭니다.
결론은..... 검증을 못했습니다. 왜냐하면.... 일단 다음을 보시죠.
SBS Web site의 첫 화면을 Windows용 FireFox 2.0.0.11에서 본 모습입니다. Silverlight는 둘째 치고 첫 화면부터 IE 아니면 이 지경이니...
참고로 IE에서는 아래 그림과 같이 자알 나옵니다.
헉, 그런데 Active X를 설치하려 드네요. (T.T)
Silverlight니 Flex니 RIA니 뭐니 이전에 Web 표준이 우선인 것을 절감한 사례였습니다.
(2008.1.10. 내용 추가)
Microsoft 미국 site에 Firefox로 들어가니 Firefox용 Silverlight runtime을 받게 하네요. 일단 Windows용 FireFox에서 Silverlight를 쓴 site는 접근이 가능하겠습니다. Linux 상의 Browser는? 더 지켜봐야겠지요?
