오픈소스. 유지비용의 감소. (기업편)

오픈소스. 유지비용의 감소. (기업편)

오픈소스. 유지비용의 감소. (사용자편)

오픈소스. 유지비용의 감소. (사회편1)
오픈소스. 유지비용의 감소. (사회편2 – 결론)

0.

function __toggle_hide_zone10()
{
elm = document.getElementById(“hide_zone10”);
if(elm.style.visibility == ‘visible’) __hide_hide_zone10();
else __show_hide_zone10();
}
function __show_hide_zone10()
{
elm = document.getElementById(“hide_zone10″);
elm.style.visibility=’visible’;
elm.style.display=”block”;
}
function __hide_hide_zone10()
{
elm = document.getElementById(“hide_zone10″);
elm.style.visibility=’hidden’;
elm.style.display=”none”;
}


그냥 살아온 부분

해커문화를 접하게 된 건, 고등학교때 읽었던 몇권의 서적에서.

오픈소스를 접하게 된 건, 대학들어와 만난 모씨에 의해서.

처음 접하게 된 오픈소스는 모씨에 의한 영향인지 맑스와 연관되어 생각되기 시작했다.

FSF와 GNU, GPL에 의해 만들어진 신세계는 놀라운 것이었으며, 활발하게 활동하는 수많은 멋진 프로그래머들은 동경의 대상이 되어버렸다.

그리고, 사용.

과서버를 관리하기 시작한 뒤, 리눅스를 사용할 수 밖에 없게 되었고, Social Contract라는 멋진 약속을 표방하는 Debian을 만나게 되었다. (thx to 승준)

대부분이 영어권 사용자인 오픈소스의 세계에서 CJK문제를 만나게 되었고, 이를 해결하기 위한 유니코드를 만나게 되었으며,
w3c와 같은 표준안 제정 단체를 알게 되었다. 표준을 알면 알수록 독점적 지위에 의해 발생하는 안타까움을 알게 되었고, 이
안타까움은 일종의 신념으로 변했다.

CJK문제를 해결하기 위한 버그레포팅, 패치 제안 등을 하면서.

잡히지 않는 랜카드를 잡기 위해 커널소스를 분석하면서, 조금씩 발전하는 모습을 발견하곤 하였으며, 묘한 희열도 느끼게 되었다.


1. 견제.

MS는 이미 독점을 맛보았으며, 독점으로 얼마나 돈을 벌 수 있는지를 알고 있다. 한때, 기업시장(PC급 서버 및 그보다 조금
상위의 장비들)에서 윈도우NT의 비율은 Unix를 누르며 급격히 성장했으며 이 당시 리눅스는 상대도 안되는 것으로 치부하고
있었다. 그러나, 엔터프라이즈 리눅스를 표방한 2.4의 발표와 함께 진입하기 시작한 리눅스의 거센 공격에 MS는 초조함을 감추지
못하고 각종 언론에 노출되는 여러 문서들을 남기게 된다. (정확히 기억은 안나지만, 몇가지 되는 것으로 기억함)

리눅스를 견제하기 시작한 것이다.

얼마전, MS측에서 리눅스의 총소유비용(TCO)이 윈도우에 비해 크다고 주장한 적이 있다.

굉장하다. 핀란드의 한 프로그래머가 시작한 프로젝트가 MS에 의해 견제를 받는 지위까지 올라가다니.

물론, 실제로 발표된 논문은 그런 내용이 아니었다.

ZDNet 관련기사

MS는 자신들의 NT가 사용되고 있는 위치에서 리눅스에게 시장을 빼앗기고 싶어하지 않는다.

2. 기업입장의 유지비용


(1) 개발자를 잡기 위해서.

MS플랫폼 (뿐만 아니라 기타 상용 플랫폼) 을 사용하는 개발자들 중, 상용툴이나 플랫폼들을 돈주고 직접 구입해서 사용하는
개발자는 드물다. 사실 많은 수의 버그들이 개발자들이 개발을 하다가 발견하게 되는 경우가 많은데, 돈주고 사서 쓴게 아니므로
레포팅을 안하게 된다. (걸릴일 있습니까.. 버그 레포팅하게)

하지만, 오픈소스라면 다르다. 작업을 하다 버그사항을 발견하면 이를 직접 고쳐서 사용할 수 도 있고, 자신이 고친 내용을 해당
커뮤니티에 공개하고 다음 버젼에 적용시킬 수도 있다. 개발자에게 "자유"를 주는 것이다. 이 자유는 개발자가 마음대로 개발을 할
수 있는 토양을 제공해주며, 지원하는 해당 기업들에겐 자신들이 자사제품에 사용하고 있는 오픈소스 코드에 대한 관리/개발/유지
비용을 줄일 수 있다.

– 기업의 지원을 받는 많은 오픈소스 프로젝트들이 대부분 컨소시엄형태로 구성된다. 대표적인 사례가 IBM에서 오픈소스로 시작한
자바 개발툴인 Eclipse (http://www.eclipse.org) 프로젝트인데, 이에 참여한 기업들을 보면 손가락이
모자랄 정도의 숫자다. 각 기업들은 Eclipse의 기술을 자사제품에 적용시키고 있다. –

활발한 버그 레포팅과 이에 대한 능동적인 사용자의 패치시도, 적용 등은 오픈소스의 원동력이라고 할 수 있다.

(2) 기술지원 비용의 측면.

MS는 자사 웹서버인 IIS에 대한 기술지원을 위해 기술지원팀을 운영하며, 고객들의 전화에 머리가 아플지도 모르겠다. 대부분 돈주고 산 제품에 대해서는 전화해서 엄청나게 따져댄다. (직접 보고, 겪는 일입니다 ㅡㅜ)

하지만, ASF(Apache Software Foundation)도 그럴지는 의문이다. 아파치를 사용하는 사람들은 알아서 서로
기술지원을 해주기도 하고(주로 IRC?), 책도 사서 보고 공부도 하고, 정중하게 메일링리스트에 질문을 올리기도 한다.

(물론 대형 벤더들에서 만든 리눅스나 기타 유닉스에 포함된 아파치에 대해 각 벤더들에서 기술지원을 해주기는 한다.)

오픈소스 소프트웨어는 기술지원의 측면에서 상당히 자유로운 편이다. 해당 소프트웨어를 어떻게 사용하느냐의 문제는 전적으로
사용자에게 달려있기 때문이다. 물론, 메일링 리스트나, 게시판,매뉴얼 정도의 지원은 이루어진다. 이를 통해 해결되지 않는 것은
사람들끼리 서로 도와주거나, 자신이 직접 해결책을 찾아내야 한다. 이런 문제점은 아주 특수한 경우가 아니라면, 대부분 다수에게
발생하기 마련이고 누군가는 해결책을 찾아낸다. (대부분 개발자일 경우가 많죠.) 그리고, 이는 인터넷이라는 공간을 통해
축적된다. – 구글이 상당히 잘 찾아줍니다. 🙂 –

물론 오픈소스 소프트웨어에 대한 기술지원을 제공하는 회사들도 있다. 이는 어떤 보장을 원하는 대기업에 의해 파생된 부분이라고 볼
수 있는데, 대부분 해당 소프트웨어를 개발한 개발자들이 모여있는 회사에서 담당하는 경우가 많다. (일종의 부가사업?) 이때도,
일반적인 오픈소스 소프트웨어 사용자들의 지식이 농축되어있는 메일링 리스트나 게시판등을 효율적으로 활용할 수 있다.

대부분의 상용소프트웨어는 그 가격의 대부분이 기술지원비용이다. 돈 주고 사서쓰는 가장 큰 이유가 기술지원이기 때문이다. 하지만,
기술지원이 필요없을 정도의 인력이 존재한다면 굳이 기술지원을 받을 필요가 없다. 불필요한 비용이 발생하는 것이다.

회사라는 울타리를 넘어선 개발 – 기술지원의 분리와 협업은 분명 생산성 측면에서도 유리할 것이다.

ps. 다음편엔 사용자측면 – 결론.

오픈소스. 유지비용의 감소. (사회편2 – 결론)

오픈소스. 유지비용의 감소. (기업편)

오픈소스. 유지비용의 감소. (사용자편)

오픈소스. 유지비용의 감소. (사회편1)

오픈소스. 유지비용의 감소. (사회편2 – 결론)

(2) 인력의 문제.

사회적으로 소프트웨어와 관련되어 들어가는 인력을 생각해본다면, 크게 제작/운영/유지에 들어가는 전문인력과 필요한 전문인력을 생산하는데 소모되는 비용을 들 수 있다.

전문인력이 실제로 자신의 능력을 효율적으로 사용하기 위해서는, 반복적인 작업을 줄여야 할 필요성이 강하게 대두된다. 이는
사회적으로 공유되는 공개된 코드의 양과 강한 연관관계를 갖고 있다. 동일한 문제를 놓고 이를 해결하기 위한 공개된 소스코드가
존재한다면, 이는 전문인력이 당면한 문제를 해결하기 위해 소모하는 시간/정신력이 급감한다는 이야기가 되기 때문이다.

그리고, (이것은 반 농담조로 이야기하는 것임;;) 전문인력이 필요한 소프트웨어를 사달라고 회사에 기안서를 내고 인가를 받는데까지 소모되는 시간 역시 줄일 수 있다. 필요하면 소스코드를 다운로드받아 쓰면 되기 때문이다. 🙂

전문인력을 생산하는데 소모되는 비용은 공개된 소스코드의 힘이 강렬하게 발휘되는 분야이다. 초보수준에서 보아야할 어떻게 코드를
작성하는가의 문제에서 부터, 고급개발자로 가기 위한 소프트웨어 아키텍트로서의 지식을 쌓기 위해서는 선배 개발자들이 어떤 고민을
갖고 어떤 코드/아키텍쳐를 만들었는지에 대한 공부가 필요하기 때문이다. 이 공부를 위해 필요한 것이 공개된 소스코드임은 말할
필요조차 없다.

물론 이 모든 것은 공개된 소스코드의 질과 관련되어 있다. 이 질은 상식적으로 볼 때, 공개된 소스코드의 손을 들어줄 수 밖에
없다. 상용과 다를 바 없는 (그리고 실제로 상업용 소프트웨어를 작성할때도 빈번히 사용되는) CVS나 SVN같은 훌륭한 코드
관리 도구에서 출발해서 (MS의 소스세이프에 비할바 아니다. -_-; Rational Rose의 Clear Case는 좀 다른거
같긴 하지만) 기타 제반사항에서 딸릴 것이 없다. 결정적으로 오픈소스 소프트웨어는 개발자를 장인으로 몰아간다. 상용으로 개발되는
소프트웨어는 릴리즈 날짜나 고객의 요구에 맞추어 모종의 "막개발"이 이루어질 수 밖에 없지만, 오픈소스 소프트웨어는 릴리즈
날짜나 고객의 요구에 조금 더 자유롭기 때문이다. 그리고, 회사의 이름으로 나가는 소프트웨어가 아닌 자기 자신의 이름이 더
중요하게 공개되는 소프트웨어란 점은 개발자에게 어떤 책임감을 부여한다.

"남이 읽기 쉬운 코드"라는 책임감을 말이다.

이런 토양을 통해 만들어지는 공개코드들은 (타인에게 귀감이 되지 못하는 코드가 많긴 하지만) 분명 전문인력과 관련된 문제를 해결하는데 있어서 막강한 힘을 발휘할 것이다.

5. 결론

오픈소스의 유지비용은 결코 상용소프트웨어에 비해 큰 것이 아니다. 물론 단기적인 안목에서는 상용소프트웨어가 편하고 저렴할 수
있겠지만, 좀 더 장기적인 안목을 갖고 넓게 본다면 오픈소스가 갖는 장점은 수 없이 많다. MS로 대표되는 독점(상용) 소프트웨어
진영에 의해 공격을 받고 있는 오픈소스는 많은 모함을 받고 저평가를 당하며 좀 더 나은 "컴퓨팅" 환경을 위해 "재미"로
살아가는 일종의 "전선"이다. 이러한 "전선이 승리할 것이냐의 여부는 중요하지 않다. "전선"이 존재한다는 사실 만으로 이미 오픈소스는 승리하고 있다.

지금도 원한다면, 언제라도 상용 소프트웨어에서 멀어질 수 있다. 거리낄 것 없이 공개된, 그리고 장기적으로 자신에게, 회사에게,
사회에게 도움이 되는 오픈소스 소프트웨어는 언제라도 문을 열고 있다. 언제라도 다가갈 수 있다. 남은 것은 의지의 문제이다.

오픈소스. 유지비용의 감소. (사회편1)

오픈소스. 유지비용의 감소. (기업편)

오픈소스. 유지비용의 감소. (사용자편)

오픈소스. 유지비용의 감소. (사회편1)

오픈소스. 유지비용의 감소. (사회편2 – 결론)

4. 사회 입장의 유지비용.

앞부분에서는 기업, 사용자의 측면에서 볼 때 오픈소스가 가져다 줄 수 있는 유지비용의 감소를 알아보았다. 단순한 경제권에서 벗어나 사회전체로 볼때는 어떤 이익이 존재할 수 있는지 알아보기로 하자.

(1) 공공재 소프트웨어의 탄생.

"Write Once, Run Everywhere" 라는 문구가 있다.
Sun사에서 만든 Java라는 언어 혹은 플랫폼의 문구로, 한번 소프트웨어를 작성하면 어디서든(맥이든 WinTEL이든
Solaris등 기타 등등이든) 실행할 수 있게 하겠다는 야심찬 포부이지만, (적어도 클라이언트 쪽에선) 실패한 듯하다.

하지만, (비록 필자의 머릿속에서 나온 말이긴 하지만.)
"Write Once, Own Everywhere" 라는 문구는 현실성을 갖고 있으며, 실제로 구현되고 있다.

한번 작성하고 어디서든 소유한다. 소프트웨어가 가진 특성, 아니 모든 지적 재산(혹은 미디어에 담긴 무엇)이 가진 특성인
재생산비용이 실물 재화에 비해 매우 적다는 특성에 기반한 이 현상은 "공공재 소프트웨어" 라고 부를 수 있을 법한 자유
소프트웨어 혹은 오픈소스 소프트웨어(이하 오픈소스로 통일)로 나타난다.

오픈소스 소프트웨어의 가장 대표적인 상품 중 하나인 리눅스는 경쟁자라 불리는 마이크로소프트의 윈도우즈와는 다르게 오직 커널만을
지칭한다. 그리고, 이 커널을 이용한 실제 사용 가능한 시스템을 배포판이라고 부른다. 배포판들은 흔히 상용으로 개발되고
판매되는데, Red Hat이나 Suse Linux, 한컴리눅스같은 회사들이 대표적이다.

만약, 리눅스가 단지 커널에서 머물러 있었다면, 이런 이야기를 꺼내지도 않았을 것이다. 공공재라고 부를만한 배포판이 있기 때문이다. (그리고 익숙해진다면, 그 어떤 배포판보다도 편하다고 자부하는.)

바로 Debian GNU/Linux 이다. 이 운동(?)의 가장 큰 특징은 이들이
표방하는 Social Contact(우리의 약속)
있다. 공동체로의 환원, 소스코드의 유지를 기조로 하는 이 선언문은 소프트웨어가 공공재로써 어떤 역할을 할 수 있는지 가능성을
강하게 보여준다.

먼저, Debian GNU/Linux는 네트워크를 통한 소프트웨어의 설치(리눅스에서 구동 가능한 대부분의 오픈소스 소프트웨어들을
사용할 수 있다. 물론 "무료"로)를 기반으로 한다. 심지어는 네트워크를 통해 설치할 수 있기도 하다. 이러한 점은 "자본"이
들어간다는 것을 의미하는데, 이 "자본"의 충당을 많은 오픈소스 소프트웨어와 마찬가지로
기여로 해결을 한다. 기여(물적이든 자원봉사이든)를 하는 대부분의
개인 사용자나 회사는 Debian GNU/Linux의 철학에 찬성하거나 실제로 이 프로젝트를 통해 이익을 보는 경우가
대부분이다. 이는 공동체에 의한 소프트웨어 프로젝트의 유지를 의미하며, 그 자체로 하나의 사회를 이루고 있다.

사회 간접 자본이란 이름으로 공공재를 생각한다면 큰일이다. 우리가 접하는 공기나 물 역시 공공재이기 때문이다. 모두의 것이며,
모두가 아껴야 하고, 모두에 의해 관리되는 것을 공공재라고 본다면 Debian GNU/Linux는 최소한 그 사회 내에서는
공공재라고 부를 수 있을 것이다.

이러한 사례가 오직 Debian GNU/Linux에서만 보이는 것은 아니다.

FreeBSD, NetBSD, OpenBSD
같은 386BSD의 후손들의 프로젝트나 또다른 리눅스 배포판인 Gentoo Linux
같은 프로젝트에서도 이런 현상은 나타난다.

자본에서 벗어나, 조금씩의 기여와 자원봉사로 운영되는 이러한 운영체제(윈도우즈 같은) 프로젝트들은 소프트웨어가 공공재로써 어떻게 유지될 수 있는지를 잘 보여준다.

순수한 의미의 오픈소스 소프트웨어 프로젝트들은 기술에 대한 높은 이해도와 상당히 많은 참여도를 요구하는 반면, 운영체제
프로젝트들은 약간의 참여로 높은 효과를 볼 수 있는 것이 장점이다. 패키지 관리나 서버제공, 혹은 홍보활동등 상당히 많은
분야에서 다양한 사람들을 요구하기 때문이다.

한 회사에서 한 운영체제를 유지하는데 들어가는 비용을 생각한다면, 자연스럽게 유지되는 이러한 운영체제의 가치는 비할바가 아닐
것이다. 많은 비용을 들이고도 역사의 뒤안길로 사라진 NextSTEP이나 BeOS등의 운영체제를 생각한다면, 더욱 말이다.

쓸만한 C++ IDE들.

1. Eclipse CDT Project
Eclipse Platform상에서 구현한 C/C++ Tool이다.
Eclipse는 Java로 만든 프로그래밍 개발툴 개발용 플랫폼? (말이 이상하네요;;) 으로 자바에서는 원츄급의 기능을 제공한다.
뭐 C/C++도 괜찮기는 한데… STL에서 자동완성이나 되었으면 좋겠다. (자동완성이 좀 약하다;;)

2. CPPLite
Eclipse와 자바개발툴로 쌍벽? 을 이룬다는 Sun사의 NetBeans 프로젝트 용 C/C++ 플러그인.. 이지만;;
사실 NetBeans보단 Eclipse에 점수를 한참 많이 주고 있으므로 이녀석은 패스.

3. Dev C++
Win32용으로 시작했는데.. 어느새 리눅스도 지원하기 시작한 IDE. 버그가 좀 많다.
(하지만 자동완성 기능은 제일 쓸만한듯 – 오픈소스중에서는;;)

4. Visual C++ .Net

function __toggle_hide_zone15()
{
elm = document.getElementById(“hide_zone15”);
if(elm.style.visibility == ‘visible’) __hide_hide_zone15();
else __show_hide_zone15();
}
function __show_hide_zone15()
{
elm = document.getElementById(“hide_zone15″);
elm.style.visibility=’visible’;
elm.style.display=”block”;
}
function __hide_hide_zone15()
{
elm = document.getElementById(“hide_zone15″);
elm.style.visibility=’hidden’;
elm.style.display=”none”;
}


Microsoft에서 잘 만드는 것은?

마우스와 개발툴;;

정말 마음에 드는 툴이다. (신품가 14만원이다. VC++.Net 말이다. ㅋ)
2005가 기대된다. Class Diagram을 지원한다고 하니. ㅋㅋ
사실 C++ 툴에서는 Class 생성 지원이 자바에 비해 많이 딸리는게 사실이기도 해서리..
Visual Assist X와 함께 쓰면 베리굳.
윈도우용아니냐.. 라시는 분에겐.. 리눅스 어플리케이션 개발에서도 위용을 발휘한다는 이야기를;;
(Samba로 네트워크 드라이브 연결을 해서 썼었지요. 🙂 )

5. GNU Emacs
쓰는 사람은 최고라고 하고, 쓰지 않는 사람은 뭐냐고 이야기하는게 저 Emacs.
스톨만의 역작이죠. Programmer's Kitchen이란 별명도 가진 ㅋㅋ
제대로 써보고 싶은데.. 학습을 통해 생산성을 올리기엔 시간이 모자라네요. 흐윽.

my programming.

대학시절부터.

1. 2000년.

대학에 첫 입학해서 삽질을 시작할 시점이었다. PHP를 처음 만났고, Python을 접하게 되었으며, JSP를 사용하기 시작했다. MySQL과 Oracle을 알게 되었고, EJB에 관심을 가진채 CORBA를 하게 되었으며, 지금은 쓰이는지도 모르겠는 WML과 지금도 즐겨쓰는 XSLT를 사용해 일을 했다. Pro C를 이용하는 데몬을 만들어 보기도 하고, 갑의 입장에서 일을 하기도 했다. 그리고, C++을 이용해 교수님과 프로젝트를 시작했던 때이기도 하다.

 

2. 2001년.

설계에 눈을 떴다. Design Pattern을 공부하고, UML을 사용하기 시작했다. 접근제어에 대해 고민하며, Template가 없는 Java에 대해 불만이 생기기 시작했다. C++과 Java를 혼용해서 일을 했으며, 프로토 타입은 Python으로 작업하는 패턴이 이때부터 생기기 시작. XML DB를 고민하는 것도 이때 시작. MIDP와 Embedded에 치를 떰.

 

3. 2002년.

월드컵에 휩싸인 채 정신없는 학기를 보내며, 쓰기는 편하지만 귀찮은 Arena(SIMAN)와 지금 학과장인 교수님께서 자랑스럽게 생각하실지도 모르는 소프트파워作 ProcessQ의 알수없는 버그와 전쟁을 치룸. Web Service와 EJB를 놓고 씨름하기도 했으며, Python으로 처음 쓸만한 프로그램을 만들어 봄. Java를 가지고 분산처리 프로그램도 만들어 봄. 제출된 텀 프로젝트중에 스펙은 가장 좋았음.

 

4. 2003년.

암흑기이긴 했지만, 잊혀졌던 바이너리 포맷 읽기 실력을 되찾았으며 파이썬으로 돈을 처음 벌어 봄. 가장 큰 수확은 저 2가지로 병특자리를 보장받게 됨.

 

5. 2004년.

현재 일하고 있는 회사에 입사. Apache Module, NSAPI, ISAPI, Servlet Filter의 도를 깨달음. Samba를 이용해 Linux Application을 Visual Studio로 개발하는 기염을 토하기도 함. Win32에 눈을 떴으며, Generic Programming에 빠져든채 열심히 삽질중. Network에 대한 이해도는 300%정도 향상됨.

 

으음. 릴리즈 년도 기준으로 나름대로 쓸만했던 일들을 정리해보면.

 

2000. Motion and Time Study Calculator (설계 및 구현)

2000. 유무선 통합 컨텐츠 시스템 (설계 및 구현)

2000. 단문전송시스템 (설계 및 구현)

2001. Workflow Management System with Document Versioning. (구현)

2001. Collaborative Authoring System (설계 및 구현)

2001. 4thpass WAP Browser Customization & Optimization (설계 및 구현)

2002. Workflow Simulation System with SNUFlow (구현)

2002. Workflow Simulation System with Handy Bizflow (설계 및 구현)

2003. Distributed Web Document Analyzer (설계 및 구현)

2003. Lotus Notes NRPC Protocol Analyzer

2003. KT SACS Prototyping (설계 및 구현)

 

나름대로 그나마 덜 부끄러운 것들.

그냥 정리해 두고 싶었음.

1년에 대략 3개정도씩?

 

에휴..

 

Modern C++ Design 독후감?

안드레 알렉산드레쿠스저.

제목처럼 C++에 관련된 책이고, 부제인 "제네릭 프로그래밍과 디자인 패턴을 적용한" 과 같이 디자인 패턴과 제너릭 프로그래밍을 다룬 책이다.

Generic Programming은 처음 접했을 때는, DataType에서 벗어난 코드를 짤 수 있다는 것에 다만 "신기" 했을 뿐이었고, 실제로는 Python을 접하면서 Dynamic Typing이란 개념으로 사용을 했었다.

Dynamic Typing을 적용한 Python은 정말 "편한" 언어 였지만, 회사에서는 적용하기 힘든 언어였고, 결국은 C++로 할 수 밖에 없었다. 킁. (Dynamic Typing의 단점.. 느리다..)

그러던 와중에 접한 저 책은…
예술이었다. Wow, Art!!!

위에서 언급한대로 DataType에서 벗어난 코딩이 가능한 것 이외에도, 컴파일 타임에 최대한 많은 일을 하여, 좀더 효율적인
프로그래밍이 가능하도록 하는 것. sizeof와 template의 마술과 #define의 적절한 사용은 C++의 새로운 세계를
열어주었다. 히힛.
– 실제로 읽으며 따라서 구현해보면 느낌이 확연히 다르다. –

처음 읽었을 때의 느낌은 "어렵다."
두번째 읽었을 때의 느낌은 "아.. 내가 하던 C++은 C++이 아니구나! 그래도 어렵다"
세번째 읽고있는 지금의 느낌은 "호오. 구현해보니 이런게 있군! 여전히 어렵다"

function __toggle_hide_zone18()
{
elm = document.getElementById(“hide_zone18”);
if(elm.style.visibility == ‘visible’) __hide_hide_zone18();
else __show_hide_zone18();
}
function __show_hide_zone18()
{
elm = document.getElementById(“hide_zone18″);
elm.style.visibility=’visible’;
elm.style.display=”block”;
}
function __hide_hide_zone18()
{
elm = document.getElementById(“hide_zone18″);
elm.style.visibility=’hidden’;
elm.style.display=”none”;
}


3줄요약.

예술이다.
정말 이런 세계가 있는줄은 몰랐다.
그럼 뭐하나.. 어렵다. 쳇;

다 읽고 나만의 템플릿 라이브러리를 만들꺼다! ㅋㅋㅋ

Release Engineering

지금 MSN 대화명이기도 한 제목.

소프트웨어를 설계하고 개발하는 것 까지는 알겠는데..
저 Release Engineering은 도무지 감이 잘 안온다.

어떤 과정과 어떤 체계를 가지고 수행해야 하는 것인지..

첫 alpha release를 해야하는 PlayAction2도 그렇고,
회사 패키지도 그렇고,
작업중인 시민쾌걸 온라인 고스톱도 마찬가지인데다,
할지 안할지도 모르는 블로그 저널도 예외는 아니다. – 블로그 저널은 어쩌면 혼자… ㅡㅜ –

이젠 release engineering을 연구해 볼 타이밍인 것 같다.
물론 (Open Source/Commercial) SW R&D Process라는 개인적 취미 과제에 포함되는 거지만. 🙂

ps. 어디 좋은 책 없을까요?

디지털 뉴딜? 제2의 벤쳐붐?

ZDNet 기사보기

제발 부탁이니, 옛날처럼 엄한데다 돈 팍팍쓰지 말고 좀 제대로 된 곳에 투자 좀 해주길.
98-00년의 그 거품을 다시 보고 싶지는 않으니.

그리고.. 정부발주 프로젝트로 먹고 살게하는 기형적인 기획안따위는 내놓지 않기를.
(거 양쪽다 모두에게 안좋다고..)

12월. 기대해 보아야 하나…
(헛된 희망인라고 생각하곤 있지만… 쩝)