ACM 논문 무료로 열람할 수 있는 사이트.

www.riss4u.net에 가입하셔서 보시면 됩니다.

ps : 제가 개발했던 메타 검색 엔진은 이 사이트에서 사라졌군요.

제 책이 2007 강컴 어워드에 선정됐습니다.

"비주얼 C# 2005 익스프레스로 배우는 C# 2.0 프로그래밍"과 "비주얼 C++ 2005 프로그래밍"이 2007 강컴 어워드에 선정됐습니다.

많이 읽어주셔서 감사합니다. ^^

개발자가 버려야 할 가정[1] : CPU는 하나의 코어를 갖고 있다.

우리는 지금까지(또는 얼마 전까지) 컴퓨터의 CPU는 하나이며, 또 이 CPU는 하나의 코어만을 갖고 있다는 가정하에 소프트웨어를 개발해 왔습니다. 하지만 더 이상 이는 사실이 아닙니다.

멀티 코어를 효율적으로 다루기 위한 병렬 프로그래밍에 대한 지식 기반은 프로그래머의 필수 자질이 되었습니다. 아래는 ZDNET과 INTEL에서 제공하는 동영상 강좌입니다. 짬 내서 들어보세요.

http://www.zdnet.co.kr/events/2007/intelWB/intelWB_01.htm

병렬 프로그래밍을 (쉽게 하기) 위한 언어의 확장이나 라이브러리, 또는 표준 같은 것들이 어서 나왔으면 좋겠습니다. 닷넷 개발자들은 PFX를 참고하세요.

한 발 밀어넣기.

"내가 과연 이 일을 할 수 있을까?"

"시간이 좀 지나서 나중에 하면 안될까?"

변화를 맞이할 때 항상 하게 되는 고민들, 도전을 피하고 싶어 변명 거리를 만들 때면 하는 생각들입니다.

이런 생각이 들 때 다음과 같은 질문을 자신에게 해보세요.

"내가 과연 이 일을 할 수 있을까?" -> "해보기나 했어?"

"시간이 좀 지나서 나중에 하면 안될까?" -> "시간이 지나면 상황이 그냥 좋아지나?"

어차피 해야 하는 일이라면, 나중에라도 받아들여야 하는 변화라면, 지금 하는 것이 좋습니다.
직접 뛰어들지 않고 정보만 수집하다보면 내 스스로 '안되는' 근거만 자꾸 만들어 낸다는 사실을 알게 될 겁니다. 그러나 변화 속에 한 발을 먼저 밀어 넣으면, 그 일을 '되게 만드는' 정보들만을 찾게 됩니다.

한 발 밀어놓고도 일이 잘 안된다면 어떻게 하냐고요? 그 때는 All-In 해서 일을 풀어야죠. ㅋㅋ

망각의 프로그래머.

팀 단위로 프로젝트를 해본 프로그래머라면 잘 알겠지만, 기억력이 뛰어난 프로그래머와 함게 일한다는 것은 공포 중의 공포입니다.

이들은 여기 저기에 전역 변수를 설정해 놓고 문서화되지 않은 상수를 사용하며, 영역 표시라도 하듯 코드 여기 저기에 깃발(Flag)을 꽂아 놓습니다. 하아, if else 사이에 아름답게 펄럭이는 수많은 깃발들의 향연이란..

이런 코드를 유지 보수하는 프로그래머의 심정은, 영문도 모르고 처음 보는 환자의 심장 수술실에 끌려 들어간 수술의의 마음과 비슷할 겁니다. 어찌됐든 사람은 살려야 하는데, 환자의 상태나 환부는 전혀 모르는 그런 상태 말입니다.

손재주가 나쁜 사람은 도구를 개발하고, 잘 잊어버리는 사람은 기록합니다.
게으른 사람은 자동화 하고, 읽기에 어려움이 있는 사람은 간단하게 씁니다.

차라리 이런 저런 약점을 가지고 있는 편이 프로그래머에게 있어 어떤 면에선 복이 아닐까 하고 생각해 봅니다. 기억력이 나쁘거나 이해력이 나쁜 것 조차도 말입니다.

오랜만에 인사드립니다~

그동안 블로그 및 게시판 관리에 소홀했습니다. 최근 건강이 많이 나빠진데다(어지럼증) 엎친데 덮친 격으로 11월 초에 패키지 릴리즈가 있었습니다. 11월 중반 부터는 또 열심히 블로깅도 하고 독자분들의 질문에 열심히 답변을 달아드릴 수 있을 것으로 보입니다.

미리 사정을 알려드리지 못하고 잠수 타서 죄송합니다.
넓은 아량으로 이해해 주시면 감사하겠습니다. 굽신굽신~

Java에는 왜 전처리기가 없을까?

Java에는 왜 전처리기가 없을까요? 이것 역시 복잡성을 제거하기 위해서라고 합니다.

전처리기를 요구하는 개발자도 상당히 많고, 이를 대신해서 사용할 꼼수(하지만 그 어느것도 궁극적인 해답이 될 수 없음)도 여럿 등장했는데도 왜 고슬링은 전처리기를 넣어주지 않을까요? 전처리기만 있으면 컴파일 매개 변수만 바꿔주면 될 것을, 소스 코드를 일일이 바꾸거나 런타임에서 조건을 체크해야 합니다.

결국 저는 오늘 하루종일 이 궁리 저 궁리를 하다가 Facade 를 만들고 그 안에 기존의 클래스와 새로운 병행 버전의 클래스를 넣기로 했습니다. 그리고 기존 클래스의 레퍼런스를 추적해서 Facade를 거쳐 객체를 사용하도록 바꾸고요.

예쁘고 가지런했던 코드중의 한쪽이 다른 모양으로 바뀌어서 속상하네요. 이럴 때면 "처음부터 다시 만들고 싶다."라는 악마의 속삭임이 시작되지만, 저는 귀차니즘이라는 천사의 도움을 받아 위기를 극복합니다.

그나저나 고슬링, Java 7에서는 전처리기 좀 넣어주지 않겠습니까?

턱받이 선물이 들어왔습니다.

내년에 태어날 아기에게 벌써 선물을 해주는 분들이 있네요. ^^
턱받이가 너무 깜찍해서 찍어봤습니다.

이것이 진정한 공포입니다.

여름에 이런 글을 읽었다면 아주 시원했을 것 같은데...
읽다 보니 제 손의 힘이 빠지고 식은 땀이 나는 군요. ㅋㅋㅋㅋ

UNIX/LINUX 계열에서 터미널을 열어 작업할 때는 정말 정말 정말 조심해야 합니다.
다른 호스트에서 작업하고 있는 것을 잊지 하지 못하는 등 주의력이 흐트러지면
바로 사고가 터집니다.

"오늘 벌인 어이없는 실수(http://kldp.org/node/86961)"

고슬링, 다음 Java 버전에서는 unsigned 좀 부탁해요.

제임스 고슬링 가라사대,
"In programming language design,
one of the standard problems is that the language grows so complex that nobody can understand it.
One of the little experiments I tried was asking people about the rules for unsigned arithmetic in C.
It turns out nobody understands how unsigned arithmetic in C works.
There are a few obvious things that people understand, but many people don't understand it."

요약하면 unsigned 타입은 불필요한 복잡성만 부르기 때문에 자바에 넣지 않았다는 겁니다.

하지만 기존의 C/C++ 소프트웨어들, unsigned 타입을 지원하는 또 다른 언어와 상호 운용성을 제공하기 위해서는 이 점은 치명적인 약점입니다. 간단한 통신 프로그램을 작성하려 그래도 C 언어로 작성한 프로그램에서 unsigned 데이터를 패킷에 담아 보내기라도 하면 요 녀석을 요리하는데 여간 귀찮은 것이 아닙니다.

오, 저기 자바 전문가께서 한 말씀 하시는군요. "그런 건 JNI를 이용하면 되잖아." JNI는 두 가지 이유에서 답이 아닙니다.

   1. Native에서 unsigned로 처리를 한다 해도 이 녀석을 다시 Java의 타입 세계로 불러들이려면 어차피 같은 일을 또 해야 합니다.
  2. 복잡성 때문에 unsigned를 뺐다고 하면서 더 복잡한 JNI를 권하는 것은 모순입니다.

물론, 이런 일을 처리하는 유틸리티 클래스를 만들어서 쓰면 어느 정도 일이 줄기는 합니다만unsigned 데이터를 다루기 위해 원래 데이터의 2배나 되는 타입을 선택해야 하고, 이로 인해 발생하는 계산의 "귀찮음"은 여전히 남습니다. 이런 일은 그렇지 않아도 다른 논리로 복잡한 프로그래머의 머리를 더 피곤하게 만듭니다.

그러니 부탁입니다, 제임스 고슬링.
제발 다음 버전의 Java에서는 unsigned 타입을 넣어주세요.

IYF 회지에 기고한 CPU 이야기

IYF(International Youth Fellowship)이라는 청소년 단체 회지에 기고한 글입니다. 컴퓨터를 잘 모르는 학생들을 위한 IT 이야기를 연재 중입니다.

지난 여름에는 CPU에 대해 썼습니다. 아래의 링크에 글이 있습니다.

http://www.iyf.or.kr/IYFmagazine/mag23/_2k7.sum.IT%EC%9D%B4%EC%95%BC%EA%B8%B0_2.pdf

내 블로그의 존재의 이유

몇년 전까지는 개발자들이 개발자 커뮤니티 사이트에 모여 이야기를 나누는 경우가 많았는데, 이제는 블로그를 통해 소통하는 것이 보통이 됐습니다.

저는 "쓰기"보다는 다른 분들의 블로그를 "읽기"를 더 즐기는 편인데(적어도 지금은 ^^;),
참 대단한 분들이 많다는 생각이 듭니다. 이 블로거 분들은 구루(Guru)로써, 팀장으로써, 대표이사로써 다 나름대로 임하고 있는 자신의 분야의 전문가답게 자신의 색깔이 나타나는 글을 쓰고 있습니다.

이런 분들을 보며 저는 과연 어떤 블로거인가 하는 생각을 해봤습니다. 그래서 제 글들을 보면서 정리를 해 봤지요. 제 글들의 특징은 다음과 같았습니다.

- 기술적으로 깊이 들어가야만 이해할 수 있는 글은 없다(즉, 대부분 쉬운 글들이다).
- 초보자들, 경력 초기에 있는 개발자들을 위한 글들이 대부분이다.
- 내 전문 분야에 대해서는 단 하나의 포스팅도 없다.

이렇게 정리를 하고나니 갑자기 "블로그의 글들도 <클릭하세요 시리즈(대림 출판사의 입문서 시리즈)>에서 벗어나지 못하는 건가" 하는 생각이 들더군요. 하지만 이내 곧 <클릭하세요>류의 글들이면 또 뭐 어떠냐 하는 생각도 들었습니다. 책을 처음 집필할 때 가졌던 마음처럼, 프로그래밍을 모르는 사람들이 이 재미있는 일을 해보도록 하는 것이 현재의 저에게 글로써 할 수 있는 가장 큰 의미가 있는 일이 아닌가 하는 생각도 들었고요.

제 전문 분야는 네트워크 프로그래밍과 분산 컴퓨팅인데, 네트워크 프로그래밍에 대해서는 좋은 책도 많고 분산 컴퓨팅에 대해서는 수요도 별로 없기 때문에 아직까지는 글을 쓰고 싶은 생각이 없습니다. (분산 컴퓨팅은 출판 계획을 세웠다가 출판사에서 수요가 없다고 거절당하기도 했습니다.)

아침에 일어나서 이런 생각이 나서 이렇게 글을 올려 봅니다. 앞으로도 큰 변화가 제게 생기지 않는 한은 지금처럼 글을 쓰게 될 것 같네요. 그럼 오늘 모두들 좋은 하루 보내시기 바랍니다

생각하고 기록하고 코딩하기.

생각을 정리하는 데 종이와 연필만한 것은 없는 것 같습니다.

마인드 맵도 상당히 쓸만합니다만, 마우스와 키보드가 연필만큼 빠르게 생각의 기록을 해내진 못합니다. (마우스가 원래 만들어진 목적이 사용자 입력을 지연시키는 것이었으니 어찌보면 당연하지요.)

연필은 순서도, 클래스 다이어그램, 시퀀스 다이어그램, ER다이어그램 등 그리지 못하는 것이 없습니다. 아주 똑똑하고 숙련된 개발자는 PC 앞에서 슥슥 그려서 모든 설계를 끝내기도 하지만, 저는 이 싸고 좋은 도구를 선호하는 편입니다(물론 팀에 배포할 때는 비지오와 워드를 이용해서 정리를 합니다!).

OMCS 증후군으로 아십니까? OMCS는 One More Compile Syndrom, "한번만 더 컴파일! 증후군"입니다. 코드를 작성하고 나서 컴파일해서 실행해 보고, 컴파일해서 실행해 보는 방식으로 프로그램을 만드는 프로그래머들을 본 적이 있다면, 이 병에 걸려있다고 보시면 됩니다(뜨끔?).

자신이 작성해야 하는 로직을 완벽하게 설계를 해놓지 않고(설계가 필수적인 것은 아닙니다. 당신의 두뇌가 기억을 잃지 않는 비휘발성이라면 말이죠.), 또는 이해가 불충분한 상태에서 프로그래밍을 하게 되면 프로그램은 "당연히" 원하는 결과를 내놓지 않습니다. 설사 운 좋게 원하는 결과가 나온다 하더라도 조금만 파라미터를 달리 주면 엉뚱하게 동작하는 경우가 대부분이죠.

이제 컴파일과 링크가 끝나고 최초의 실행 파일(또는 웹페이지)이 생겼습니다. 프로그래머는 이 프로그램에 입력값을 바꿔 주어가며 테스트를 합니다. 당연히 에러가 나고 프로그램이 죽기도 합니다. 그리고 각 입력값에 대해 If 문으로 예외 처리를 하기 시작합니다. 테스트가 진행되면 진행될 수록 if를 이용한 예외 처리가 늘어납니다. 상황은 악화되어서, 어느 순간부터는 앞에 작성한 코드를 왜 그렇게 만들어 놨는지 기억이 나지 않습니다. 그렇다고 코드를 간소화 하자니 답이 안 나옵니다. (이런 코드는 여러 사람의 만수무강에 지장을 줍니다.)

연필을 이용해서 로직을 설계 해봤다면 어땠을까요? 해당 로직이 가질 수 있는 경계값(최소/최대) 파라미터, 일으킬 수 있는 예외, 호출자가 해당 로직으로부터 알고 싶어할 결과 등등을 노트에 차근차근 기록했다면 말입니다.

사람은 완벽하지 않습니다. "완벽하지 않다"보다 오히려 "실수 투성이다"라는 표현이 더 어울리지요. 따라서 설계에도 실수가 있을 수 있습니다. 하지만 코딩하고 컴파일을 반복하는 횟수(그 절반만이라도)만큼만 설계에 공을 들인다면 설계의 완성도는 올라가고, 코딩의 고통(?)은 훨씬 줄어들 것입니다.

연필이 마음에 안든다고요? 도구는 상관없습니다. 저는 펜보다 HWP가 더 자유로운 행정병 출신 프로그래머들도 여럿 봤습니다(키보드 만으로 사무실 책상 배치도를 그리는 모습을 봤는데, 경악스럽더군요.). 생각하고 코딩하라는 이야기를 보통 많이들 합니다만. 저는 이 말에 뭔가 빠졌다고 생각합니다.

생각은 휘발성이기 때문에 코딩하면서는 그 수많은 생각들이 4차원 세계로 날아가버리지요. 종이든, 파일이든, 또는 양쪽이든, 생각을 기록한 후에 코딩을 시작해 보세요. 매 프로젝트가 끝날 대마다, 여러분은 고민과 사유 과정이 담긴 노트를 하나씩 얻게 될 것입니다.

07.9.17 19:10 추가.
- (거창한)소프트웨어의 설계에 대한 실용성에 의심을 하고 계신 분이나, 거창하게 UML 툴을 열어놓고 고민하는 시간이 많다면, 이 방법을 적극 추천해 드립니다.

- 이 노트는 제가 전에 다니던 회사의 팀장님께 배운(?) 겁니다. 팀장님께서는 항상 노트(이렇게 설계가 담긴 노트를 애지중지 하셨더랬죠. ㅋㅋ)에 소프트웨어 설계를 하셨는데(공유해야 하는 내용은 항상 전자 문서화해서 배포하셨습니다.), 팀장님께서 작성하신 코드는 버그가 드물었던 기억이 납니다. (물론 안전하고 성능이 좋은 코드를 위한 장치를 라이브러리 레벨에서 많이 준비해 놓으신 이유도 한 몫 했을 겁니다.)

C# 3.0 서적 집필에 대한 고민.

여러분들이 책을 많이 읽어주셔서, 집필 의뢰가 계속 들어오고 있습니다. ^^

다름 아닌 내년 초에 출시될 것으로 예상되는 Visual Studio 2008 에 관련한 집필 의뢰인데요,
고민이 상당히 큽니다.

우선 C#에 대한 고민. C# 3.0과 .NET Framework 3.0이 새로 들고 나오는 특징들 때문에 기존의 책 두께를 유지하기가 어렵게 됐습니다. 최소한 300페이지는 더 늘어날 거라는 것이 제 생각입니다. 이 정도 두께가 되면 읽기가 굉장히 부담스러워지지요. 또 책의 예제들이 윈도우 폼을 중심으로 되어 있었는데, WPF로 다시 구성해야 하는가라는 문제도 생겼습니다. 어쩌면 이제 C# 언어와 .NET Framework 부분을 별도의 권으로 나눠 집필해야 하는 때가 온 건 아닌가 하는 생각이 듭니다.

그리고 비주얼 C++에 대한 고민. 얘는 오히려 바뀐 것이 별로 없어서 고민입니다. 현재 VC6로 개발하는 프로그래머들이 많은데 큰 변화(예, 소소한 개선은 있습니다.)가 없는 VC++ 2008 서적이 필요한가? 하는 생각을 하고 있습니다. (물론 새로운 내용이 들어가는 것만이 집필의 의미를 주는 것은 아닙니다. 기존의 내용 자체를 더 알기 쉽게 업그레이드 하는 것도 의의를 줄 수 있습니다.)

마지막으로 타이밍에 대한 고민. 비스타의 보급이 지지부진한 상황에서 VS2008을 선택하는 개발자(또는 회사)가 얼마나 될 것인가. 또 이를 가르치려 하는 학교는 얼마나 될 것인가(비스타를 설치하기 위해 OS와 하드웨어를 새로 구입하는 것은 굉장한 예산을 필요로 합니다.). 제 생각에는 적어도 "지금은 아니다"라는 판단을 하고 있습니다.

이상, 알고리즘 원고를 집필중이어서 일을 미루려는 핑계를 그럴듯하게 만든 프로그래머 박상현이었습니다. ㅋㄷ

IT 업계 빅 3의 빛과 그림자.

아래의 기사를 읽어보시기 바랍니다. 류한석님의 의견처럼,
우리나라에 SW 업계 전면에 걸려있는 족쇄를 풀어내지 않는 한 우리나라에서의
SW 발전은 어려울 것이라 생각합니다.

너무 늦기 전에 바뀌어야 할텐데, 그 시간이 얼마나 우리에게 있는지 모르겠습니다.

http://www.zdnet.co.kr/itbiz/column/anchor/hsryu/0,39030308,39160320,00.htm

호기심 천당

"공부를 해야하긴 하겠는데, 시간도 나지 않고 의욕도 별로 없어요."

어느 프로그래머에게서 들은 이야기입니다. "야근천국 칼퇴지옥"인 우리나라 SW 업계의 모든 종사자들이 겪는 현실일 것입니다. 그래도 어찌합니까, 우리는 계속 공부를 해야하는 사람들인데 말이지요. 시간이 없어도 해야 하고, 의욕이 없어도 해야 하는 것 또한 현실 아니겠습니까?

하지만 생각해 봅시다. 우리네는 사실 "호기심" 빼면 시체이던 인간들이잖아요. 돈도 상대적으로 적게 받고, 노동량과 스트레스는 삶에 충만하며, 정년마저 아주 짧은 SW 업계에서 그나마 버텨나가는 것도 '배운 게 도둑질 뿐'이라서가 아니라 '예전에 가졌던 그 즐거움'이 그리워서는 아닐까요?

전 거창한 공부 대신에 순간 순간 일어나는 호기심을 채워가며 사는 것을 제안합니다. Silverlight가 궁금합니까? 그럼 당장 MSDN 사이트에 들어가서 관련 동영상 세미나와 문서를 읽어보고, Orcas Beta2를 다운 받아 예제 코드를 만들어 보세요. UNIX에서 프로세스 프로파일링을 하고 싶으세요? top 소스를  다운받아 분석해 보세요.

이렇게 조금씩 한발 한발을 옮기다 보면 1년 후, 2년 후에는 재미있게 얻은 지식들이 한가득일 것입니다.또 이것이 제가 일해나가는 방법이기도 하고요. 다음은 E=MC^2 라는 책에서 읽은 글귀입니다. 아인슈타인이 남긴 말이예요.

"중요한 것은 질문을 멈추지 않는 것이다. 호기심은 그 자체만으로 존재할 이유가 있다. 누구라도 영원성과 생명과 놀라운 세상의 신비를 생각하면 경외심에 사로잡힐 수 밖에 없을 것이다. 그러한 신비를 매일 조금씩 이해하려고 노력하는 것만으로도 충분하다. 신성한 호기심을 잃지 말자."  - 알버트 아인슈타인.

Java Profiler 추천 받습니다~

드디어 팀장님께서 Java Profiler를 사주시겠다고 합니다.
디버깅이 한결 쉬워질 것 같습니다. ^^

그런데 혹시 어떤 Profiler가 쓸만한지 추천해주실 분 계세요?

아서라, 아서.

구글이 유투브를 활용한 본격적인 벌이에 나섰습니다. 사용자가 업로드한 영상에
광고 출력하는 방식을 도입했다는데요, 사용자들의 반응은 "분노"수준이라고 합니다.

아.. 옛날 프리챌의 아픈 기억이 새록새록 떠오릅니다. 대한민국 최고의 커뮤니티 사이트였던
프리챌이 유료화 선언 이후로 순식간에 사용자가 이탈하며 풍지박산 됐었죠. 게시물을 다음 까페로 옮겨주는 프로그램까지 돌아다녔던 기억이 납니다.(물론 프리챌은 다른 사업을 이용하여
다시 살아나고 있습니다.)

누군가의 위기(또는 몰락)은 누군가에게는 기회입니다. 하지만 구글은 똑똑하니 잘 대처하겠지요?
하지만 "오만"에 씌이기라도 하면 홀린듯이 멍청해지지요. 아래는 관련 기사입니다.

유튜브의 새로운 광고, 일부 사용자들 동요

자기 소개.

직업이 어떻게 되시죠?

프로그래머입니다. 대학에서는 산업공학을 전공했는데,
지금까지 메타 검색 엔진 및 인덱스 기반 검색 엔진, MES(Manufacturing Execution System) 분야에서 다년간 일해 왔고 현재는 통신 장비 개발 업체에서 근무하고 있습니다.

프로그래머시군요. 그렇다면 프로그래밍 언어는 뭘 사용하시죠?

지금은 C와 Java를 사용합니다만, 개인적으로 사용하는 업무용 유틸리티는 C#을 이용해 만들어 쓰고 있습니다. C#은 현재 취미용 언어가 된 셈입니다.

보통 소프트웨어 엔지니어들마다 관심을 갖고 있는 분야가 한 두가지쯤은 있던데, 혹시 관심 분야가 있습니까?

산업공학도라면 항상 관심을 갖는 스케줄링과, 컴퓨팅에서는 HPC(High Performance Computing)에 관심이 많습니다. HPC는 호기심 차원에서 공부하고 있는 수준이고, 이를 제대로 활용해볼만한 기회는 없었습니다. 제대로 해보려면 관련 대학원에 진학해야겠지만 학위에는 뜻이 없는지라... ^^;

좋아하는 음식이 있습니까?

특별히 좋아하는 음식은 없고, 다 잘 먹습니다. 브로컬리 들어간 것만 빼고요.

결혼은 하셨습니까?

예, 2006년 9월 23일부터 마눌님을 모시게 됐습니다. 내년 초쯤에는 아기가 태어날 예정입니다.

IQ가 궁금하네요. 얼마 정도 되는지 말씀해 주실 수 있겠습니까?

중학교 때 선생님의 노트를 몰래 본적이 있는데, 115였습니다. 고등학교 때는 적성 검사 결과가 나오자 선생님께서 '상현아. 네 머리로는 다른 애들보다 잘하기가 어렵다. 하지만 아주 바보는 아니니까, 열심히 해.'라고만 말씀해 주시더군요. 좀 상태가 안 좋았던 모양입니다.

마지막으로 하고 싶은 말씀은?

책 많이 사주세요~.

프로그래머는 프로그래밍 실력이 모자라야 한다.

대개 저와 같은 직업을 갖고 있는 사람들은 자신을 "개발자"라고 표현하는 것을 좋아합니다만,
저는 "프로그래머"라는 표현을 즐겨 사용합니다.

물론 SW 개발은 프로그래밍 뿐 아니라, 고객과의 대화를 통한 요구사항 분석, 동료와의 커뮤니케이션, 비용 관리, 인력 관리 등등 다양한 활동을 포함하는 작업입니다. 제가 저를 프로그래머라 표현하는 것은 어찌보면 다른 활동보다도 컴퓨터와 깊이 대화하고자 하는 하나의 염원이라고도 할 수 있습니다.^^

그런 염원 때문인지는 몰라도 아주 가끔, 아니 어쩌면 꽤 자주 저는 스스로를 괜찮은 프로그래머라고 생각할 때가 있습니다. 이런 현상이 나타날 때는 딱 한 가지 경우입니다. 더 나은 도전을 맛보지 못할 때이지요.

최근에 나 스스로가 무력해 보이는 느낌을 가진 적이 언제인가, 지금 스스로 내 한계에 매일 부딪히고 있는가 등을 따져서 "도전 없는 후한 점수"를 나에게 주고 있다면 그것은 다 무의미한 것입니다. 대학생이 초등학교 3학년 수학시험에서 100점을 맞고 자랑스러워하는 것과 같은 것이지요.

초보가 초보인 것은 죄가 아니지만, 초보가 여전히 초보로 남는 것은 죄입니다. 발전을 하지 않는 것 자체도 문제이지만, "중고 초보"가 이 바닥 물을 흐리며 어지럽히는 것은 공연한 민폐이지요.

횡설수설. 아무튼 프로그래머는 모름지기 늘 자신이 모자람을 느낄 수 있는 도전을 가까이 해야겠다는 생각을 해 봅니다.

휴가 다녀오겠습니다.

8월 14일~8월 17일 휴가를 다녀오겠습니다. 그동안 BMT 준비하느라 쌓였던 스트레스도 털어내고, 집필로 부족했던 수면도 좀 보충하고, 마음의 때도 벗겨내고 오겠습니다.

컴퓨터/이메일 아무것도 안되는 곳으로 다녀올 예정이니 그동안 질문이나 연락하실 일이 있더라도 휴가를 다녀온 후에 연락이 가능할 것입니다.

오늘 SW 검증을 끝내고 나면 또 철야 출장을 가야 해서, 휴가 가기 전에 따로 블로그에 글을 못 올릴 거 같아 지금 글을 올립니다.

부디 그동안 안녕히 계세요 ^^

고요한 밤, 조용한 블로그

오늘 호스팅 업체에 도메인 연장 및 웹 호스팅 연장 신청을 했습니다.
새삼 "본전" 생각이 났습니다.

여러분도 잘 아시는 것처럼, 제가 블로깅을 열심히 하는 것도 아니고 또 지금까지 써 놓은 글 중에서 "기록"으로 남길만한 글들이 몇 편 없잖은가 싶으니까 공연히 그런 생각이 드는 모양입니다.

하지만 한달에 3천원 정도 투자해서 저를 찾아오시는 분들께 근황도 알리고, 독자들과 소통하며, 가끔 이렇게 쓸데 없는 소리도 기록하는 일기장 기능을 잘 수행해주는 것을 생각하면 호스팅 비용에서 본전 이상은 뽑는다고 봐도 될 것 같습니다.

등짝도 뻐근하게 굳어오고, 제 CPU도 제 기능을 못하기 시작했습니다.
글을 쓰다 잠자리에 들기 전에 오랫동안 글을 올리지 못한 블로그에 뭔가를 해야겠다는 생각에 이렇게 글을 올립니다. 이젠 저도 잠자리에 들어야겠네요.

Hasta la vista~

[퀴즈] 118 = 1979711488 ?

상현이는 최신 코어 2 듀오 CPU가 장착된 PC를 새로 구입한 기념으로 C# 프로그램을 하나 작성했습니다.

4바이트 짜리 int 데이터를 Java로 작성된 프로그램에 TCP/IP를 이용하여 보내는
간단한 프로그램('클라이언트'라고 합시다.)이지요. Java로 작성된 프로그램 역시
패킷을 받아 패킷에 담긴 데이터를 콘솔에 출력하기만 하는 단순한 프로그램('서버'라고
합시다.)이고요. 서버는 옛날에 구입한 센트리노 CPU가 장착된 노트북에 설치되었습니다.

상현이는 순식간에 코드를 작성해서 컴파일을 마쳤습니다. 그리고
클라이언트와 서버 프로그램을 띄우고 클라이언트에서 118(10진수)을 보냈습니다.

그런데 믿을 수 없는 일이, 아니 믿고 싶지 않은 일이 일어났습니다. 서버에서는
1979711488(10진수)를 출력한 것입니다.

무슨 일이 일어난 것일까요? (힌트: 118과 1979711488를 16진수로 바꿔 보세요)

닭이 먼저입니다.

오늘 문득 3년전에 하던 프로젝트가 생각났습니다. Kick Off 한지 3달이 지난 LCD 공장 CIM 프로젝트에 소방수로 잠깐 들어갔다가 약 10개월 정도 더 묵여있던 프로젝트입니다.

당시 제가 일하던 회사는 제품 개발 부서와 개발된 제품을 현장에 들고 나가서 엔지니어링을 하는 부서가 나뉘어져 있었습니다. 제품도 상당히 많고, 그 제품의 수만큼 엔지니어(주:개발자)들도 많았지요. 현장에서 일하는 엔지니어들은 고객과 대화하는 능력과 고수준의 개발 능력, 그리고 엄청난 체력을 필요로 했습니다.

그런데 그 프로젝트에는 하필, 우리 회사 엔지니어 수가 모자라서(PL급 1명) 상당 수의 외주 개발자들을 뽑아 써야 하는 상황이 되어 버렸습니다. CIM 분야에 대한 Domain Knowledge를 교육하고 제품을 엔지니어링하기 위한 각 기술을 익히는 데에만 최소 수개월이 걸리는데, 수준을 알 수 없는 개발자를 '일단' 선발해서 투입한 겁니다.
그래서 프로젝트가 설계단계부터 삐걱거리기 시작하고 제품 개발팀에 있던 제가 3~4주 지원을 하는 소방수로 선발된 것입니다.

아뿔싸, 한달만 지원하면 다시 돌아올 수 있을 거라 생각했던 것은 그야말로 '모르는 소리'였습니다. 3개월이 지났는데도 개발자들은 프로젝트를 하기 위한 기초 지식(LCD 공정, 개발에 필요한 메시지 버스 등)도 모르고 있었습니다. (제가 갔을 때는 뭔가를 열심히들 하고 있었지만 그게 뭐였는지는 지금도 모릅니다.)

한달이 지나자 '지원'을 하러갔던 저는 PL이 되어 설계와 스케줄링, 개발자들의 교육과 프로젝트의 진행 임무가 얹혀진 지게를 메게 되었습니다. 하루에 12시간만 더 있었으면 하는 생각을 가졌던 유일한 시기였습니다.

시간이 지나도 좀처럼 나아지지 않는 개발자들, 내가 들어가기 전에 파악했던 요구사항은 완전히 무용지물이었다는 사실(모든 요구사항과 프로세스를 새로 분석해야 했습니다.), 한번도 웹 유저 인터페이스 연동 경험이 없는 제품을 웹 인터페이스를 올려야 한다는 기술적 위험, 무엇보다 이 짐을 같이 지고 나갈 수 있는 사람이 없다는 외로움이 가슴을 짓눌러왔습니다.
( 더 황당한 사실은, 당시 저는 처음 접해본 Java, JSP를 3~4년차 사용했다고 하는 분들이 저한테 물어가며 개발을 했던 것입니다.)

다른 개발자들은 저녁 8시 반이나 9시면 집에 가야 한다고 짐을 싸는데, 저는 그럴 수 없었습니다. 하루 종일 설계만 해도 시간이 모자라는데, 개발자 교육에, 코드 검사(당하는 입장에서는 자존심 상하지만, 품질을 유지하기 위해선 필요합니다. 이 업무는 나중에 영입한 전문가께서 계속 해주셨습니다.), 또 제가 맡은 블럭의 개발을 해야했기 때문이죠.

집에 가면 12시~1시, 잠깐 눈붙이고 출근하기 위해 5시 반에 일어나 6시에 통근 버스를 탔습니다. 이 기간에 몸무게가 5Kg정도 빠졌습니다.

제가 프로젝트에 합류한지 한달 반이 지났을 무렵, 하던 일을 잠시 멈추고 커피 한잔 마시면서 프로젝트를 돌아봤습니다. 무엇이 문제일까, 그 문제를 고치면 더 나아질 수 있을까?
결론은 다음과 같았습니다.

1. 내가 소비하는 시간의 70%는 개발자의 교육과 코드 품질 관리에 소모된다.
  우리 회사의 엔지니어 두사람이면 이 시간을 완전히 절약할 수 있을 것이다.
  다행히 품질 관리는 곧 합류할 전문가가 담당해 줄 것이다.

2. 지난 한달 반동안 현재 같이 일하는 개발자들은 기술적으로도,
   대화 능력도 나아진 것이 없다.

문제는 데려올 본사 엔지니어가 없기 때문에 외주를 줬다는 것입니다. 그래서 저는 전방위 로비(?) 시작했습니다. 그 내용은 말씀드릴 수 없지만 갑측의 프로젝트 담당자 분과 우리 회사의 PM님으로 하여금 인력 교체를 결심하도록 말입니다.

프로젝트 기간의 2/5가 지나간 상황에서 도박과 다름 없는 결정이었지만, 결국 다섯 명을 내보내고 면접을 통해 다른 뛰어난 개발자 네 명을 영입하는 데 성공했습니다. 개발자 교육에는 1주일 정도가 걸렸습니다. 메시지 버스는 지지고 볶는 사이 이미 라이브러리로 만들어 놨기 때문에 특별한 교육이 필요 없었고, LCD 공정과 공장 자동화를 이해하는데 1주일 정도가 소요된 것이죠.

프로젝트는 빠른 속도로 예정된 스케줄을 따라 잡았고, 거짓말처럼 얼마 후에는 5시에 퇴근할 수 있었습니다. 조금 일이 있으면 7시에 퇴근했고요. 저는 시간이 남아서 클러스터링 되어 있는 OS, WAS, DBMS,그리고 우리 제품의 성능을 감시하는 TCP/IP 기반의 리소스 모니터를 처음 써본 Perl 언어로 개발했습니다. (프로젝트는 아주 좋은 케이스로 남아 갑의 담당자 분은 고과를 후하게 받았다는 후문입니다. 회사 입장에서는 프로젝트의 성공으로 유사 프로젝트를 여러 건 수주하게 됐고요.)

이야기는 이렇게 해피 엔딩으로 끝납니다.

소프트웨어 개발.. 1) 충분히 좋은 개발자를 2) 충분한 수로 확보하고, 3) 정확한 스케줄링(또는 이를 위한 노력)에 의해 이루어진다면 얼마든지 좋은 품질의 제품을 만들어 낼 수 있습니다.

쉽지 않은 일이지요? 하지만 저는 좋은 개발자 없는 회사가 성공한 곳을 본 적이 없고, 수퍼 개발자 혼자서 뭘 해낸 곳도 본적이 없습니다(잠깐의 성공을 이야기하는 것이 아닙니다. 고객에게 지속적으로 인정을 받는 것을 의미합니다.).

이야기를 써놓고 보니 달걀이 먼저냐, 닭이 먼저냐 하는 것인데 답은 간단합니다.
"닭이 먼저입니다."

면접의 추억.

요즘 주변에 취업 준비하시는 후배들이 많네요. 다니던 직장을 그만두고 새로운 곳을 알아보는 분들도 많고요. 제가 첫 직장을 구하기 위해 면접을 보러다니던 때가 생각나는 군요.

CTI(Computer Telephone Integration) 개발을 하는 회사(이제는 연 매출이 거의 400억 가까이 되는군요.)였는데, 다른 지원자들을 제쳐두고 저만 따로 하루 먼저 불러 면접을 봤습니다. 이력서가 인상적이었다고 합니다.

좋은 분위기에서 면접이 시작되고, 면접관의 질문에 막힘없이 대답을 해 나갔습니다. 면접을 잘 마치는가 싶었는데, 면접관께서 질문 있으면 해보라고 하시더군요. '이럴 수가! 난 대답만 준비해왔는데, 어쩌란 말이야! 뭔가 멋진 질문을 해야해!' 라는 내면의 외침이 올라왔습니다. 그래서 한 질문이라는 것이...

저, 면접관님께서는 회사 생활에 얼마나 만족하고 계십니까?

이 질문에, 갑자기 면접관께서 헛기침을 몇 번 하시더니 옆에 계시던 다른 면접관의
눈치를 살피시며 이렇게 말씀하시더군요.

"험, 험. 직장 생활이란게 아주 스트레스가 없을 수는 없지만, 그 스트레스란 게
조직 내부에서 온다기 보다도, 대부분이 고객으로부터 오는 것으로써... "

그 분의 이야기를 들으면서 속으로 눈물을 흘렸죠. '떨어졌구나.'를 직감한 겁니다.
역시나 그 회사에서는 연락이 오지 않았습니다. 그 이후에도 두어 차례 미역국을
마시고서야 첫 직장을 잡을 수 있었고요.

직장을 구하고 있는 후배 이야기를 듣다 옛날 생각이 나서 끄적여 봤습니다.

윤창현 교수님 컬럼 모음.

서울 시립대학교 경제학과 교수로 계시는 윤창현 교수님의 <이슈 경제학>이라는 제목으로 연재되는 컬럼이 모여있는 곳입니다.

http://www.hankyung.com/news/app/newslist.php?sid=01012013

이 컬럼은 세간에 이슈가 되고 있는 주제나, 과거의 이슈(연재 컬럼을 쓸만한 이슈들이 정기적으로 일어날 수는 없으므로)를 바탕으로 경제학을 쉽고 재미있게 풀어 쓰고 있습니다.

개발자가 경제에 대한 이야기를 꼭 알아둬야 할 필요가 있나? 예, 저는 경제학이 개발자로써도 알아둘 필요가 있고, 이 세상을 살아가면서도 꼭 필요한 교양이라고 생각합니다.

우리가 하는 소프트웨어 개발은 "사람"에 의해 이루어 지지요? 가령. "이 사람들을 어떻게 대할 것인가?" 하는 물음에 대한 답을  경제학이 줄 수 있습니다. 또 새로운 인터넷 사업을 시작하려 할 때, "어떤 정보가 돈을 만들 수 있는가?"에 대한 답을 구하는 데에도 도움을 받을 수 있고요. 그 뿐인가요? 우리가 소프트웨어 개발에서 은퇴할 때, 새로운 직업을 선택할 수 있는 지혜도 얻을 수 있습니다.

조엘 스폴스키씨도 <대학생들에게 하는 조언>이라는 글에서 미시경제학을 공부해둘 것을 권하는 군요.
http://www.joelonsoftware.com/articles/CollegeAdvice.html

<경제학 콘서트>나 <괴짜 경제학>같은 책도 재미있습니다. 한번 읽어 보세요.^^

Mo' Better Blues

오늘 출근 길에 내리는 비를 보며 이 음악의 멜로디가 생각났습니다. 유명한 곡이지요? 동명의 영화에서 나오는 곡입니다.
정작 영화는 아직 못 봤는데, DVD 대여점에 한번 가봐야겠습니다. ^^

6월의 마지막 주를 과거로 보내며

오늘 일을 마무리 짓고, 이제 퇴근합니다. 6월의 마지막 주를 이렇게 과거로 보내는군요.
더불어 2007년의 상반기도 함께 보냅니다.

여러분은 2007년에 목표한 바에 충실이 다가가고 계십니까? 저는 일부는 그렇고, 일부는 그렇지 않은 것 같군요. 이번 상반기에 얻은 수확 하나가 있다면 인생의 volatility 는 감히 계산할 수 없다는 사실을 알았다는 정도랄까요?

자, 다음 주는 후반기의 시작입니다.
모두들 이 더운 여름에 건강 유의 하시고 즐거운 주말 보내시기 바랍니다 ^^

삶은 고달프나, 프로그래밍은 즐겁다.

"어느 IT 맨의 사직서(http://blog.daum.net/moveon21/5423451)"라는 글이 요즘 큰 반향을 일으키고 있습니다. IT 업계의 전태일이 나오는 것 아니냐는 이야기도 나오고 있네요.

예, 그렇습니다. 부정할 수 없는 대한민국 IT의 현실입니다. 그리고 우리는 한 분야의 절정에 이른 전문가가 되지 않는 한 먹고 살기가 점점 힘들어지는, 이른바 양극화 사회에 살고 있다는 것도 현실입니다.

하지만 우리는 즐거운 프로그래밍을 하고 있습니다. 괴로운 일을 괴롭게 하는 사람들도 있는데,
우리는 즐거운 일을 괴롭게 하니 이 얼마나 축복된 일입니까? 아니면, 더한 저주일까요?

"Life is tough, but programming is fun."

덤벼라 슬럼프.

스포츠 선수들의 뉴스를 듣다 보면 제 이야기라고 느껴질 때가 가끔 있습니다.
제가 그 분들처럼 자신의 분야에서 유명하거나 뛰어나다는 뜻이 아니라, 그 분들이
처한 어려움이 공감된다는 것입니다.

얼마전 이승엽 선수가 4번에서 쫓겨났습니다. 이승엽 선수로써는 마음이 크게 상했을
것입니다. 그는 6번 타자로써 필요에 따라 희생번트를 날려야 하는 위치에 놓였습니다.
한국과 일본에서 홈런왕 타이틀을 거머쥔 바 있는 이승엽 선수와 같은 빅 슬러거에게는
엄청나게 자존심 상하는 일이지요.

하지만 그는 묵묵히 자신의 일을 하고 있습니다. "과거의 홈런왕"에 연연치 않고 "3타석 연속 삼진을 당한 타자"로써 자신을 인정하며 이를 야무지게 물고 연습을 하고 있습니다. 우리 모두 잘 알고 있습니다. 그가 다시 4번 자리에 서리라는 사실 말입니다.
그리고 앞으로도 가끔씩 지금처럼 힘든 시기가 찾아오겠지만, 그 때도 지금처럼 강하게 이겨내리라는 사실도요.

저도 요즘 슬럼프에 있습니다. 그리고 이를 극복하기 위해 저를 바꾸고 있습니다. 누군가가 이렇게 이야기 했다고 합니다. "슬럼프는 실력이 벽 앞에 쌓이는 시간이다."라고요.

이 시간이 빨리 지나갔으면 좋겠지만, 너무 늦게 끝나지만 않는다면 그렇지 않아도 상관없습니다. 앞으로 이런 시간이 왔을 때 이기는 방법을 충분히 배워야 하기 때문입니다. 다음 번엔 슬럼프가 더 강해져서 돌아올지도 모르는 일이니까요.

자, 이제 잡담 끝내고 다시 에디터 앞으로..... ^^

구글 말고

구글은 아주 훌륭한 검색엔진입니다만, 또 다른 검색 엔진에서 자료를 찾고 싶다면
아래의 검색 엔진을 사용해 보세요.

http://www.quintura.com/

컴퓨팅의 미래는 웹일까?

TV를 켰을 때 1분 정도 걸려야 비로소 전원이 들어오고, 리모컨으로 채널을 바꿀 때마다
모래 시계가 나타난다고 상상해 보셨나요?

우리는 "컴퓨터는 이런거야."라고 별 문제없이 사용하고 있지만, 아직도 컴퓨터는 갈 길이 멀었습니다. 궁극적으로는 웹도 답이 아닙니다. 여느 가전제품처럼 간단하고, 빠르며, 견고해야 합니다. MS가 미래의 컴퓨팅에 대해 한가지 안을 제시하고 있습니다.

다음 URL에서 MS의 새로운 컴퓨팅 인터페이스를 살펴 보시기 바랍니다. 그리고 우리네 소프트웨어 개발자들이 궁극적으로 만들어야 하는 세상이 어떤 것일지도 같이 생각해 봅시다.

http://www.microsoft.com/surface/

동이 터옵니다.

겨울 이 맘때에는 밖이 캄캄한데, 지금은 저 동쪽에서 해가 서서히 올라오고 있습니다.
빌딩만 빽빽히 들어선 이 동네에도 아침을 알리는 새가 노래를 시작합니다.
그리고 졸음은 저에게 이제 그만 쉬라고 속삭이고 있습니다.

집중이 되는 흐름을 깨고 싶지 않아서 밤샘하는 것과, 일이 많아서 밤샘하는 것은 분명히
구분하는 것이 좋다는 것을 오늘 여실히 느꼈습니다. 검토해도 검토해도 고쳐야 할 게 계속 나옵니다. 어떤 후배의 충고처럼, 이젠 나이를 의식해야 하는게 아닌가 하는 생각도 듭니다.(저 멀리에서 어떤 분이 돌들고 달려 오시는 광경이 보이는군요.^^ )

이렇게 정신적, 육체적으로 피로할 때는 무조건 쉬어주는 게 좋습니다. 아무렴요, 쉬는게 장땡이지요.

전 어서 일을 마무리 짓고 들어가야겠습니다. 막판까지 왔는데 제발 수월히 끝나주기를... T-T

공정이 제품을 만듭니다.

요즘 우리나라 소프트웨어 업계에서 "소프트웨어 품질"이라는 주제가 조금씩 이슈화 되고 있습니다. 이전에는 개념조차 없던 것이 이제는 "Good Software"라는 인증이 생기고 업체들도 해당 인증을 받기 위해 노력하는 곳이 많아졌습니다. 어느 정도 규모가 있는 회사에는 품질 관리(Quality Control)또는 품질 보증(Quailty Assurance) 부서를 운영하기 시작했습니다. 굉장히 고무적인 일이지요.

하지만 안타깝게도 이렇게 의욕적으로 품질에 공을 들이는 회사들도 소프트웨어 품질을 어떤 방법으로 향상시켜야 하는지에 대해서는 별 아이디어가 없는 것으로 보입니다. 컴파일러 옵션은 줄줄 꿰고 있어도 핸드폰의 간편 전화번호 검색 기능은 모르는 우리, 바로 소프트웨어 개발자들이 품질 개선의 주역이니 이해가 갈만 합니다.

우리 주위에는 이런 문제에 대해 경험을 가지거나 연구를 해온 선배가 없습니다. 300에 등장하는 스파르타 전사들이 갑옷도 없는 맨몸에 창과 방패 하나씩 들고 페르시안들과 싸웠던 것처럼 우리도 에디터와 컴파일러 하나로 수십년 동안 소프트웨어를 개발해 왔습니다. 버그가 적은 소프트웨어라는 말은 들어봤어도, 품질이 좋은 소프트웨어라는 말은 들어본 적이 없는 것이지요.

결국 우리가 품질을 위해 현재 할 수 있는 일은, 테스트 뿐입니다. 일단 소프트웨어의 개발을 마친 후에는테스트, 디버그, 테스트, 디버그 ... 의 사이클로 버그가 어느 수준 이상으로 발견되기 전까지 반복합니다. 그리고 테스트-디버그 사이클의 비용은 전체 소프트웨어 개발 비용의 40%에서 70%까지 차지하게 됩니다.

"원래 소프트웨어 품질 비용은 비싼거야."라고 넘길 수도 있지만, 이 정도로 많은 비용이 든다는 것은 큰 개선이 가능하다는 뜻도 됩니다.

제조업에서는 "수율(Yield)"이라는 개념이 있습니다. 투입한 자재대비 품질에 이상이 없는 제품을 얻는 비율을 말하는 것이지요. 수율이 높을 수록 낭비되는 비용이 적습니다. 특히 휴대폰과 같은 고부가가치 상품은 애써 만들어 놓은 제품이 출하전 검사 단계에서 불량 판정을 받아 폐기하거나 수리(또는 재작업)를 하는 비용이 만만치 않기 때문에 수율을 높이기 위한 노력을 엄청나게 기울입니다.

제조업에서는 제품을 내보내기 전의 품질 검사/감시 이상으로, 제품을 만드는 공정 내에서의 품질에 대한 감시를 중요하게 여기고 투자를 합니다. 각 생산 공정(Process)의 품질을 측정하고, 품질 저하의 원인을 공정에서 찾아내어 이를 개선합니다. 이렇게 개선된 공정 하나하나는 더 품질이 좋은 제품의 원동력이 되고 결국 원가 절감으로까지 이어집니다.

다시 눈을 돌려, 우리의 소프트웨어 공장을 봅시다. 우리가 만드는 소프트웨어는 그 어느 분야의 제품 못지않게 복잡하고 정교한데도, "공정" 따위는 없습니다. 우리 소프트웨어가 어떤 모습을 하고 있을지도 첫번째 컴파일이 끝나기 전까지는 알지 못합니다. 그 뿐인가요? 제조업에서 제품을 생산하는 것이 작업자의 "손"이라면, 소프트웨어업에서는 작업자의 "정신"이라 할 수 있는데, 많은 개발자들이 집중력이 떨어지는 근무환경에서 잠을 이겨가며 제품을 만들고 있습니다.

제품은 "공정"에서 나오는 것이지 "품질 감시"에 의해 만들어 지는 것은 아닙니다. 테스트 이전에 소프트웨어의 설계, 요구 사항 및 기능 정의, 작업자의 명확한 임무 정의, 일정 계획 등이 정상적으로 이루어지고 있는지를 점검해야 합니다. 지극히 상식적인 일이지만, 잘 지켜지지는 않지요. 마치 건강해지려면 담배를 끊고, 다이어트를 하고, 운동을 하고, 긍정적인 사고를 가지며, 브로컬리와 같은 녹화색 야채를 챙겨 먹어야 하지만 그 어느것 하나 생활에 반영하기가 어려운 것처럼, 이들도 그럴 것입니다.

하지만 한가지 확실한 사실은, 건강을 위한 노력을 하지 않으면 사소한 질병 때문에 대단한 의료비용을 지출하거나 죽을 수도 있다는 것입니다. 우리도 소프트웨어 개발 공정에 대한 개선을 시작하지 않는다면, 언제 죽을지 모르는 일입니다.

성공이냐/실패냐의 결과만을 판정하기 전에, 실패하지 않도록 최선을 기울여야 합니다.

"공정이 제품을 만듭니다."

어떤 Mac을 쓰냐고요?

회사 워크샵 때 상품으로 얻은 iPod 때문에 고객 등록을 애플에 해놨더니 가끔 애플에서 광고 이메일이 옵니다. 오늘은 "어떤 Mac을 쓰십니까?"라는 제목으로 이메일이 왔는데(사실 같은 메일을 몇 주만에 두 번째 받았습니다.), 잔소리를 하려고 이렇게 올립니다.

행사 일시 및 제품 정보는 별도 공지없이 변경될 수 있습니다.

본 이메일은 광고성 정보전송에 대한 정보통신망 법률 등 관련규정에 의거하여 발송되었습니다.

저작권 © 2007 애플컴퓨터코리아. 서울특별시 강남구 삼성동 159 아셈타워 32층 애플컴퓨터코리아(주) 우)135-090
모든 권리 보유 / 문의 / 개인정보 보호정책 / 내 정보

Apple에서 제공하는 이메일 수신을 원하지 않는 경우에는 여기를 방문하세요.

혹시 위 문구를 아래의 그림에서 찾을 수 있습니까? 깨알같이 작은 글씨에 흐릿한 폰트로 메일의 가장 아래 부분에 위치하고 있습니다. 최고의 디자이너들을 갖춘 애플이 이런 식으로 일을 마무리 한다는 사실이 대단히 실망스럽군요. 또한 "수신 거부 방법" 등의 고객이 정확히 알아야 할 정보를 얼버무린다는 느낌을  지울 수 없습니다.

iPod이 많은 결함에도 엄청나게 팔려서인지 몰라도, 애플이 실수에 많이 관대해진 것으로 보입니다. 사람이 하는 일이기 때문에 실수가 없을 순 없지만, 실수를 만들 수밖에 없다는 걸 깨달았다면 실수를 줄이고, 실수를 막을 수 있는 장치를 준비해야 하지 않을까요?

써 놓고 보니 정말 잔소리가 됐네요. 즐거운 주말 보내세요 ^^

사람의 가치는 교양으로 매겨지지 않아.

"사람의 가치는 교양으로 매겨지지 않아. 순수와 겸손으로 매겨지지.
교양은 배우고 나면 잘 안 잃지만, 순수함은 배우기도, 지키는 것도 어려워."

Wanted : .NET Windows Forms Developer

개발자를 구합니다. 하게 될 업무는 C#으로 .NET Windows Forms 어플리케이션을 작성하는 일입니다. 구체적으로 다음 요건을 갖추었다면 당신은 적격자입니다.

1. C# 언어에 능숙하며, OOD/OOP에 대한 이해가 깊다.
2. 커스텀 컨트롤 코딩이 가능하다.
3. 분산 객체 컴퓨팅 경험이 있다.(CORBA, Web Service, .NET Remoting 등)
4. 데이터베이스 프로그래밍에 능하다.
5. SCSF & CAB 에 대한 경험이 있다.(옵션)
6. 자신이 하고 있는 일을 영어로 문서화가 가능하다.(옵션)

제가 예전에 근무하던 회사(www.aim.co.kr)에서 사람을 구한다고 합니다. 국내 회사이긴 합니다만, 일하는 분위기는 외국계 회사에 못지 않습니다. 선진 업무 프로세스와 공장 자동화 분야에서 세계 최고의 역량을 갖춘 인재들과 함께 일할 수 있는 기회를 얻고 싶은 분들은 지원해 보시기 바랍니다.

저에게 이력서를 이메일(steelblue@nate.com)으로 보내주시면 제가 소개를 해드리겠습니다.
(그 회사에서 소개비를 받는다든가 하는 것은 전혀 없으니 오해는 없으시길 ^^)

I Play Music

집에 와보니 아무도 없군요. 집사람은 5월 말에 있을 공연/전시 행사 준비 때문에
잠시 후에 들어온다고 연락이 왔습니다.

지난 주말을 너무 즐겁게 보낸 탓일까요, 오늘은 유난히 힘든 월요일이었습니다.

이제 막 냉장고에서 꺼낸 냉수 한컵을 들고 PC 앞에 앉았는데, 미디어 플레이어의 재생 목록에
처음 보는 음악들이 보입니다. 그 중에서 이것 저것 골라 듣다 보니 기분이 한결 나아졌습니다. 이 음악 파일들의 날짜를 보니 아마 노트북 PC에 번들되어 온 음악인 것 같군요.
아프리카 음악도 몇 곡 있고, 재즈도 몇 곡 있고, 클래식도 있습니다.

무겁지 않은 멜로디가 기분을 풀어주네요. 안마를 받는 기분입니다.

구할 수 있다면 이 음악을 들어 보세요. Rosie Thomas의 <I Play Music>입니다.

어린이날을 앞두고...

우리가 보지 못하고 있는 세상의 저편에서는 상상도 못할 슬픈 일들이 많이 벌어지고 있습니다.
운동장에서 축구공과 함께 뛰놀아야 할 어린 소년들이 총을 들고 전쟁에 뛰어드는가 하면, 어느 곳에서는 우리가 맛있게 먹는 초콜렛의 원료인 카카오를 재배하는 농장에선 맛은 커녕 허기도 달래지 못할 음식물을 위해 새벽 5시부터 일해야 하는 아이들이 있습니다.

사진 속의 저 아이는 어디선가 얻은 빵 한조각을 들고 공습으로 숨진 부모를 찾아 울고 있다고 합니다. 저 아이가 원하는 것은, 또 필요로 하는 것은 XBOX 게임기도 아니고 디즈니랜드도 아닙니다. 어머니의 품이라면 손에 든 빵조각이 없어도 든든하고 포근할텐데, 이제 저 아이를 안아줄 어머니는 세상에 없습니다. 저 아이를 누가 안아줄 수 있을까요?

내일은 어린이 날입니다. 아이들의 욕구를 채우는 선물 대신, 마음을 채우는 선물을 해주면 어떨까 하는 생각을 해 봅니다. 예를 들어, 같은 세상에 살지만 보이지 않는 곳에서 슬퍼하고 있는 친구들에게 어떤 도움을 줄 수 있을까를 같이 생각해보는 것 말입니다.

30분 +

정렬 이야기를 올리기로 약속했는데, 늦어지고 있습니다. 기다리고 계신 분들께 정말 죄송합니다. 공교롭게도 해당 내용이 집필을 시작하게 된 알고리즘 책의 내용 중 일부에 해당하게 되어, 책의 기획(건물로 치면 설계에 해당합니다.)이 끝난 후에 샘플 원고 삼아 글을 다시 쓰려 합니다.

회사 일과, 블로깅과, 알고리즘 서적 집필, IYF 회지 여름호 원고, 기타 등등에 걸친
일들을 우선 순위 및 긴급도에 의해 스케줄링을 하다보니 블로깅이 가장 뒤로 밀리는군요. ^^

처칠은 하루 4시간만 자고도 2차 대전중에 있던 영국을 승리로 이끌었는데, 저는 6시간을 자도 하루가 벅찹니다. 언제쯤 저도 "4시간의 경지"에 이를 수 있을까요?

집사람이 얼마전에 사준(돌 날라올라) <Professional 소프트웨어 개발>을 어제부터 읽기 시작했습니다.(그 유명한 스티븐 맥코넬의 책입니다. 여러분의 직업이 프로그래머라면, 꼭 읽어보시길 권합니다.) 일단 읽기 시작하면 빨리 끝을 봐야 하는 성미라 어제 밤부터 아주 조금이라도 짬이 나면 책을 붙들고 읽었는데, 아직도 조금 남았습니다. 이 책 때문에 오늘 점심에는 산책을 포기하기도 했습니다. 산책을 포기한 대신 중요한 소득을 하나 얻었습니다. 바로 책을 읽을 수 있는 아지트와 30분의 독서 시간입니다.

회사가 입주해 있는 건물의 비상구 계단은 사람이 거의 다니지 않는 곳이라, 제가 사적인 통화를 할 때나 머리를 식힐 때, 또는 알고리즘을 생각할 때 찾는 곳입니다. 오늘은 점심먹고 유난히 잠이 쏟아지는데, 한편으론 책이 읽고 싶어 커피를 한잔 타서 그곳으로 갔습니다.

점심시간이 끝나기 전까지 30분 동안 그곳에서 서서 책을 읽었습니다. 30분이 언제 흘렀는지도 모르게 금방 지나가더군요. 그만큼 몰입했다는 것이죠. 앞으로는 다른 사람은 거의 드나들지 않는 이 비상구 계단을 "나만의 공간"으로 삼아 잘 사용하려 합니다.(마의 1시를 넘기면, 잠은 사라집니다. 더 졸리면 순도 높은 초콜렛 한 조각이나 커피를 한잔 더 마십니다.)

24시간 뿐인 하루에 30분을 더 얻은 것 같아 기분이 좋습니다. 잠도 더 줄일 수 있으면 정말 좋겠는데... 혹시 누구 좋은 방법 알고 계세요?

Language Matters

다들 좋은 주말 보내고 계신가요?

전 요즘 새로운 책의 집필을 기획하고 있습니다. 알고리즘을 주제로 준비하고 있는데,  여러가지 결정해야 하는 일들이 있어서 고민하고 있습니다.

그 중의 하나가 책에 사용할 프로그래밍 언어를 고르는 일입니다. 이것 참 고민스러운 일입니다. 이에 대한 결정을 내리기 위해 여러가지 통계 자료를 구글링하고 하던 중,
세계 최고의 IT 출판사, Oreilly 의 회장 Tim Oreilly 의 블로그에서 좋은 자료를 발견했습니다.

Programming Language Trends

프로그래밍 언어는 C#을 기본으로 하되, 충분한 근거와 타당성 검토를 거쳐 필요하다고 판단되면 Java나 C++를 같이 넣는 방향으로 하려 합니다.

혹시 이에 대해 의견이나 아이디어가 있으시면 덧글을 달아 주시거나, 제게 이메일(steelblue@nate.com)을 주시기 바랍니다. 좋은 아이디어가 있으면 제가 훔쳐 쓰려 하거든요.

프로그래밍 언어와 컴퓨터의 발달(링크)

예전에 올렸던 포스트를 기반으로 해서 IYF(International Youth Fellowship) 회지의 지난 봄호에 기고한 글입니다. 심심하신 분들은 한번 읽어보세요.

http://www.iyf.or.kr/IYFmagazine/mag22/_2k7.spr.IT%EC%9D%B4%EC%95%BC%EA%B8%B0_1.pdf

이번 여름 호에도 글을 보내야 하는데, 일이 많아 걱정입니다. ^^;

푸념 & 자랑

오늘은 놀토지만, 일이 많아 출근해서 코드를 만지고 있습니다. 일이 많은 것은 괜찮은데, 식대를 청구할 생각을 하니 앞이 다 캄캄해 집니다. 식대 청구가 뭐 대단하다고 그렇게 엄살을 부리냐고요? 영수증을 스캔해서 전자 결재를 올린 다음, 전자 결재 받은 것을 인쇄해서 실 영수증을 붙여 경리에게 청구하고, 스캔한 영수증은 따로 인쇄해서 첨부해야 합니다. 전자 결재를 도입하면 편해질 줄 알았더니 이제는 결재를 받으려면 곡예를 한바탕 해야 하니 이게 뭔가 싶습니다. (그래도 다행인 것은, 회사의 이러한 행정적인 부분은 여럿이 의견을 모아 더 좋은 안을 제시하면 변경할 수 있다는 것입니다.)

이 꿀꿀한 기분을 전환할겸, 자랑을 좀 하겠습니다. 

신혼집으로 이사오면서 그 전에 쓰던 Intuous2 타블렛의 펜을 잃어버려 타블렛이 무용지물이 되어 버렸습니다. 덕분에 컴퓨터로 그림 그리는 것도 거의 쉬고 있었죠.

그림을 자주 그리는 것은 아니지만, 블로그의 대문 그림 정도는 한번씩 바꿔 주고 싶은데 조금 답답하더군요.

그런데 바로 어제, 마눌님께서 Graphire 4 타블렛을 사주셨습니다. 다시 그림을 그릴 수 있게 된 것이죠.
기념으로 오늘 아침 일찍 일어나 타블렛으로
<- 이 그림을 그렸습니다.

예상헀던 것처럼 성능이 좋군요. Intuous2보다 가격은 저렴한데, 성능은 더 좋아진 것 같습니다. 집사람도 써보더니 좋아하는군요. (Intuous 시리즈는 계속 나오고 있습니다. Grpaphire는 Intuous보다 저성능의 모델입니다.)

여보, 고마워요. 잘 쓰겠습니다~

2007년의 1/3이 다 지나갔습니다.

아직도 "새해에는..." 하면서 다짐을 하고 있는데, 벌써 2007년의 1/3이 지나갔습니다.
저기에서 5월이 오고 있는 모습이 보이네요. 그 뒤에 6월도 열심히 5월의 뒤를 따라오고 있습니다.
도대체 시간은 왜 저렇게 급히 가고, 또 어디로 가는 걸까요? 시간이 혼자 가는 것은 괜찮은데 시간에 갇혀 있는 우리도 급하게 살아야 하니 그 숨가쁨을 말로 다 할 수 없군요.

자, 실망하기엔 이릅니다. 남아 있는 2/3가 있잖아요. 시간과 사이좋게 지낸다면 시간은 우리 편이 될 것입니다. 그동안 무심했던 시간에게 관심을 쏟아~봅시다.

내가 그의 이름을 불러주기 전에는

내가 그의 이름을 불러주기 전에는
그는 다만
하나의 몸짓에 지나지 않았다.

내가 그의 이름을 불러주었을 때
그는 나에게로 와서
꽃이 되었다.

내가 그의 이름을 불러준 것처럼
나의 이 빛깔과 향기에 알맞는
누가 나의 이름을 불러다오.
그에게로 가서 나도
그의 꽃이 되고 싶다.

우리들은 모두
무엇이 되고 싶다.
너는 나에게 나는 너에게
잊혀지지 않는 하나의 눈짓이 되고 싶다.                                          - 김춘수

이 글을 읽는 분 중 E=MC²라는 상대성 이론 공식을 아는 분들이 계실 겁니다. 그렇다면 E=MC²의 의미를 한마디로 설명할 수 있습니까? 그렇지 못하다면 E=MC² 가 의미하는 바를 모르는 것입니다.

만약 누구라도 이 아름다울 정도로 단순한 공식의 의미를 안다면, 이 공식으로부터 많은 것을 생각해 낼 수 있을 것입니다. 예, 예컨대 핵무기 같은 것 말입니다.

E=MC²는 “질량(M)이 곧 에너지(E)이다.”라는 의미를 갖습니다. C의 제곱은 변환 상수라 생각하면 됩니다. 1,000,000,000를 1G(기가)로 표현하는 것처럼, 엄청난 에너지량을 질량에 C의 제곱이라는 단위 상수를 곱해 표현하는 것입니다.

예를 들어 수십 그램의 질량이 순수하게 에너지로 변환된다면, 작은 도시 하나를 일순간에 지도에서 없애버릴 수 있는 위력을 갖게 됩니다. 이 사실에 착안해 만들어진 것이 바로 핵무기지요. 반대로, 이 질량을 아주 느린 속도로 에너지화할 수 있도록 제어할 수 있다면, 더 없이 좋은 에너지원으로도 사용할 수 있을 것입니다.

김춘수님의 시와 상대성 이론을 들먹이며 이야기하는 이유가 궁금하실 겁니다.

여러분이 갖고 있는 기술을 쉽게 설명할 수 있습니까? 그것이 듣는 사람(동료, 후배, 또는 고객)에게 의미로 남습니까? 그렇지 않다면 여러분이 그것의 본질을 진정으로 이해하고 있는지를 돌아보시기 바랍니다.

요즘 공부를 하며 일을 하며 느끼는 생각입니다.
결국 열심히 공부해 보자는 이야기입니다. 모두 즐프합시다!

(예고)정렬 이야기

정렬과 탐색은 프로그램에서 가장 많이 사용하는 알고리즘들 중 하나입니다.
누구나 다 생각하는 단순한 정렬 알고리즘부터 컴퓨터 과학자들이 개발한
성능이 뛰어난 정렬 알고리즘까지 쭉 훑어볼 계획입니다.

항상 해야지, 해야지 마음만 먹고 있다가 이렇게 글을 올려 공포(?)를 합니다.
이렇게 해서 제 자신을 재촉하는 것이지요.

글도 올라오지 않는 제 블로그에 항상 관심을 가져 주셔서 죄송하고, 감사합니다.
꾸벅~ (__)(--)

Never try, never fail.

예전에 <The Robot>이라는 애니메이션을 본 적이 있습니다. 수학적인 기법을 잘 활용해서
짠 곳곳의 장면들이 인상적이었죠. <The Robot>에서는 로봇들도 인간처럼 "태어나기도 하고", "죽기도" 합니다. 병들기도 하고, 집과 먹을 것을 필요로 합니다.

그곳에는 "가난"도 있고 "악당"도 있습니다. 그리고 "영웅"과 그의 친구들이 있지요.
자세한 내용은 영화를 보지 않으신 분들 때문에 더 이야기 하지 않겠습니다. 주인공이 악당에 맞서 싸우려 할 때, 그 친구중의 하나가 주인공을 말리며 이렇게 이야기 합니다.

"Never try, Never fail."

시도도 하지 말고, 실패도 하지 말자는 것이죠. 만약 이 친구의 말대로 스토리가 전개됐다면
영화의 끝은 비극이었겠죠? 주인공은 이 친구도 설득해서 악당과 싸우고, 결국 물리칩니다.

작년에 저희 교회 목사님께서 하신 말씀이 생각납니다.

"하나님께서 왜 메뚜기를 정하다 하셨는지 아느냐? 메뚜기는 자유롭게 비행할 수는 없지만, 뛸 수 있는 다리를 갖고 있다. 어디로 떨어질지 모르지만, 메뚜기는 뛰어 오른다. 그것을 하나님께서 정하다고 하셨다. 메뚜기는 풀 위에 떨어질지, 도로 위에 떨어질지, 물 위에 떨어질지, 결과는 모르지만 뛰어 오른다."

저도 가끔 갈 길이 멀어 보이거나 목표가 너무 멀어 보이면 속에서 "Never try, never fail"이라는 속삭임이 들려옵니다. 하지만 지금까지 걸어온 길을 생각해보면 절대 그럴 수 없겠다는 마음을 다시금 먹게 됩니다. 저도 나비나 잠자리처럼 멋진 날개를 가지진 못헀지만, 메뚜기처럼 힘껏 뛰렵니다. 어디에 떨어지든, 그렇게 살도록 내 인생이 되어 있다면 뛰어야지요.

"Try. Faith never fails."

UrCode 게시판을 열었습니다.

Ur Code(Your Code) 게시판을 새로 생성했습니다.
우리가 만든 프로그램의 소스 코드를 올리고, 같이 공부하자는 취지에서 만들었습니다.
가끔 제가 만든 코드도 보실 수 있을겁니다.(제가 약간의 성실함을 더 확보할 수 있다면 말이죠 ㅋㅋ)

게시판 운영 원칙은 UrCode 게시판의 공지란에 올렸으니 이용에 참고하시기 바랍니다.

모두들 즐프하세요~

봄인가... 아닌가 봅니다.

지난 주말에 내리는 비를 봄비라고 생각했는데, 겨울로 돌아가는 겨울비였나봅니다.

집 앞의 개구리하고 인사까지 했는데, 갑작스레 닥친 추위때문에
많이들 얼어 죽었을 것 같습니다. 삼가 고와(故蛙)의 명복을 빕니다.

감기 조심하시고, 즐거운 하루 되시기 바랍니다.

이상 블로그가 너무 썰렁해서 글을 하나 남겨본 주인장이었습니다.

전문 연구 요원 모집 공고

블로그를 운영하면서 이런 글은 처음 올려보는 군요.

지금 제가 일하고 있는 회사에서 2007년 병특 요원을 모집합니다.
근무지는 서울 아니면 대전입니다.(대전에 근무하게 되면 회사에서
기숙사를 마련해줄 수 있습니다.)

C 언어가 필수입니다. 문법만 겨우 아는 것으로는 부족하고,
능숙하게 다룰 수 있어야 합니다. 석사 과정까지 열심히 공부했다면
별(?) 문제 없이 면접을 통과하실 수 있으리라 생각합니다.

자세한 내용은 홈페이지(http://www.newgrid.com)를 참조하세요.

비스타, 비스타!

요즘 비스타 때문에 난리도 아닙니다.

신문에선 연일 비스타 관련 기사가 오르고 있고, 전자 매장엔 비스타를 설치한 PC들이 즐비합니다. 데브피아에 가보니 .NET Framework 3.0를 열심히 공부하는 개발자도 상당히 많네요. 각 소프트웨어 업체들은 비스타에 대응할 버전을 준비하느라 분주합니다. 당장은 비스타와 호환되는 버전을 내놓겠지만, 6개월~1년 정도 후면 비스타의 강력한 기능을 적극 활용한 소프트웨어들이 쏟아져 나올 것입니다.

예전의 윈도우 95에서와는 달리, 많은 업체에서 다양한 제품들을 빠른 속도로 출시할 것으로 예상됩니다. 열악한 개발 도구만을 가지고 있었던 과거와는 달리 .NET Framework 3.0이라는 걸출한 API 세트와 VS, Delphi 등을 비롯한 화려한 개발 도구들이 준비되어 있기 때문입니다.

여기서 잠시 생각해 봅시다.
그렇다면 지금 우리가 해야 하는 공부는 무엇일까요? 비스타처럼 나날이 쏟아지는 신기술을 어떻게 받아들여야 하는 것일까요? C# 언어와 C++ 언어를 제대로 구사하도록 하는 것도 쉽지 않은데, 신기술들은 또 언제 익혀야 할까요?

과학은 건물을 세울 때 필요한 암반과 같은 것이고, 기술은 건물과 같은 것입니다. 암반은 튼튼하게 어떤 건물이든 세워질 수 있도록 하지만, 건물은 오래되면 해체해서 새로 짓곤 합니다.

암반도 중요하고, 건물도 중요합니다. 우리나라의 태극기를 보면, 가운데에 음과 양의 기운이 서로 조화를 이루는 태극 문양이 보입니다. 빛과 어두움이 어우러지듯, 과학과 기술 역시 개발자에게 융합되어 있어야 합니다. (이는 "C# 2.0 프로그래밍"과 "VC+ 2005 프로그래밍"이 지향하는 바이기도 합니다.)

뭐, 결국 둘 다 필요하다는 이야깁니다. 너무 피곤하지요? 기술은 과학을 기초로 해서 맺어지는 열매와 같은 것입니다. 즉, 내가 프로그래머로써의 기초를 단단히 하고 있다면 새로 쏟아지는 기술도 어렵지 않게 소화할 수 있다는 이야깁니다. 프로그래밍 언어, 파일 처리, 알고리즘, 데이터 베이스 등은 과학입니다. COM, ActiveX, WCF, WPF 등은 기술이라고 할 수 있지요.

쏟아지는 기술들에 당황하지 말고 차근차근 현재 하고 있는 공부를 하시기 바랍니다. 여러분이 기초를 잘 닦고 나면, 어떤 기술이든 두렴없이 받아들일 수 있게 될 것입니다.

어느 학생의 질문을 받았는데, 많은 분들이 같은 고민을 하시리라는 생각에 이렇게 포스트로 답변을 합니다. 도움이 되셨기를...

Hasta la vista~

그라시아스 합창단 8기 오디션 포스터

아래의 그림은 그라시아스 합창단 8기 단원 오디션 공고 포스터입니다.
포스터의 사진은 뉴욕 메디슨 스퀘어 가든 공연 모습을 촬영한 것인데, 여기에
저도 끼여 있습니다. 얼굴 알아보기 힘들죠? 남성 성악부 앞렬 중 왼쪽에서 4번째가 접니다.

오디션은 끝났습니다. 좋은 단원들이 많이 영입되었다는 소식입니다.

휴가 다녀오겠습니다.

제가 오늘 저녁부터 25일까지 휴가를 다녀옵니다.

그 사이에 올리신 질문들에 대해서는 휴가를 다녀와서 답변을 드리도록 하겠습니다.

그럼 다녀오겠습니다~~~

난 어디에 있나?

나 자신은 cutting-edge(최첨단)에 있을까? 아니면 niche(틈새)에 있을까?

최신이 최첨단인가?(mp3가 재생되는 전자사전이 최첨단은 아니지 않은가?)

난 내 분야에서 선진에 있는가? 후진에 있는가?

그것을 측정할 yardstick이 있을까? 없다면 어떻게 만들지?

내가 후진에 있다면, 어떻게 선진을 따라잡으며, 추월할수 있을까?

질투는 나의 힘!!!!

스티브 잡스와 애플, 그리고 MS

요 몇 달동안 iPhone 때문에 IT 업계가 시끌시끌했습니다. iMac, iPod의 성공의 후광을 입고 있기에 iPhone에 대한 기대가 엄청나게 커졌기 때문이지요. 결국 몇 일 전에 iPhone이 그 모습을 드러냈습니다.

뉴스를 통해 특징을 정리해본 결과, iPod를 담은 PDA 전화기라는 판단을 했습니다. 이런 물건때문에 사람들을 그렇게 기다리게 헀나 싶기도 해서 조금 허탈해지기도 헀습니다. 하지만 그 디자인만큼은 상당히 산뜻했는데(할 뻔했는데), 그마저 LG의 프라다 폰을 베낀게 아니냐는 의혹을 받고 있습니다.

야구에서 타자가 3할 정도를 치면 아주 잘한다고 할 수 있습니다. 투수가 던지는 공 10개 중 3개를 안타로 만들기만 해도 우수한 선수가 되는데, 스티브 잡스는 NeXT와 같은 뼈저린 실패를 경험하기도 했지만, 상당히 우수한 타율을 자랑하고 있습니다. 그것도 아주 대형 홈런으로 말이죠. 이번에도 iPhone을 가지고 iPod처럼 만루홈런을 만들어낼 수 있을지 귀추가 주목됩니다.

잡스가 자신이 창업한 애플에서 몇년 쫓겨나 있긴 했어도, 그는 애플의 아이콘과 같은 존재입니다. 청바지를 입고 신제품 런칭 쇼를 하는 스티브 잡스가 없는 애플은 상상할 수 없습니다. 그런 점에서 MS의 변화는 아주 주목할만 합니다.

소프트웨어 업계의 제왕으로 군림하고 있는 MS는, 자사의 아이콘이라 할 수 있는 빌 게이츠를 많이 지워내고 있습니다. 이미 유능한 후계자 후보가 MS에서 활약하고 있고, 그의 친구이자 現 회장인 스티브 발머가 MS를 앞에서 이끌고 있습니다. 빌 게이츠는 현재 기술 부문만을 이끌고 있고 몇 년 후엔 은퇴할 것임을 공식적으로 발표하기도 했습니다.

놀랍게도 MS가 내놓고 있는 주요 제품들은 개발 과정에서 빌게이츠의 반대를 무릅쓴 아이디어들을 채택하고 있습니다. 대표적인 것이 바로 인터넷 익스플로러입니다. 넷스케이프가 전 세계 웹 브라우저를 거의 독점하고 있다시피 했을 때, MS는 인터넷 시대의 사업에 대해 준비되어 있는 것이 없었습니다. 이미 인터넷 시대가 도래했음을 깨달았을 때는 시간이 많이 흐른 뒤였죠. 그런데 그 때 이미 회사 몰래 인터넷 응용 프로그램을 준비해오던 이들이 있었고, 이들에 의해 인터넷 익스플로러가 탄생합니다. 지금은 넷스케이프 웹 브라우저는 찾아보기가 어렵죠.
그 외에도 Xbox 게임기에서 윈도우를 제거한 일이나, 쥰 Mp3 플레이어를 내놓는 일 등을 보면 MS는 포스트 빌게이츠들이 준비되어 있는 것으로 보입니다.

제가 하고 싶은 이야기는 애플이 향후 몇년 동안 현재와 같은 비즈니스를 이어갈 수 있을 것인가 하는 점입니다. 스티브 잡스가 또 홈런을 만들어 낼 수 있을까요? 설령 만들어 낸다 하더라도 그 다음 타석에서 NeXT와 같은 끔찍한 실패를 저지르지 않을 수 있을까요?

iPhone을 보면서 든 생각이었습니다.


즐프하세요~

프로그래밍의 역사

섭씨 50도의 열과 소음이 가득 채운 커다란 방에서, 한 여자 연구원이 노트를 들고 30 미터에 이르는 방 한 면을 가득 메운 상자들에 꽂혀 있는 전기 케이블의 배선을 바꾸고 있었다. 노트에는 대포의 탄도 계산에 필요한 방정식이 기록되어 있고, 연구원은 그 노트에 따라 꼼꼼하게 케이블을 점검해 나갔다. 6000개에 이르는 전기 케이블을 점검한 후, 계산에 사용할 실험 수치가 기록된 카드들을 기계에 밀어 넣고 스위치를 올렸다. 잠시 후 한쪽에 설치된 천공기(punching machine)가 계산 결과를 카드에 출력했다.

이 광경은 최초의 컴퓨터, 에니악(ENIAC)을 운용하던 모습이다.  한 쪽 벽면을 가득 메우고 있던 상자들은 에니악(ENIAC)이었고 전기 배선은 에니악(ENIAC)이 계산할 때 사용하는 "논리"로써, 현대의 컴퓨터로 치자면 "프로그램"이었다. "프로그래밍"이 프로그램을 제작하는 일을 뜻하니, 연구원이 전기 배선을 하던 그 모습은 바로 프로그래밍이었다고 할 수 있다.

에니악은 당시 엄청난 계산 능력을 갖고 있었지만(286 PC와 비슷했다.), 단점 또한 그 덩치만큼이나 대단했다. 진공관 발열 문제로 인해 거의 매일 반나절은 운영을 멈춰야 했고,  무엇보다 프로그램을 변경하려면 6000개에 이르는 배선을 교체해야 했다. 이후에 이 괴물은 맨해튼 프로젝트에도 참여했던 천재 과학자 존 폰 노이만(John von Neumann)의 마법을 거쳐 조금 더 신뢰성 있는 컴퓨터인 에드박(EDVAC)을 탄생하게 했고, 에드박은 중앙 프로세서, 기억장치, 프로그램, 데이터로 구성된 현대 컴퓨터의 구조를 갖춘 현대 컴퓨터의 조상이 되었다.

노이만 이후 컴퓨터의 발전은 가속도를 더해갔으며, 프로그래밍 방식 또한 컴퓨터의 발전에 발맞춰 나아가게 됐다. 전선으로 구성됐던 프로그램이 이제 거대한 방에서 조그만 상자로 그 "장소"를 옮기게  된 것이다. 
트랜지스터와 이 트랜지스터를 하나의 칩에 집적한 마이크로칩이 개발되면서 컴퓨터는 운영 체제와 기본적인 프로그램, 그리고 명령어들을 자체 내장했다. 그리고 프로그래머는 CPU가 제공하는 기본적인 명령어를 조합하여 보다 효율적인 방법으로 프로그램을 작성할 수 있었다.

이 명령어들이 바로 어셈블리어이다. 프로그래머가 어셈블리어를 이용하여 프로그램 원천 코드를 작성하면,  컴파일러(Compiler)라는 소프트웨어를 이용하여 실행 파일을 만들어 냈다. 그리고 이 실행 파일이 바로 프로그램이었다.

컴퓨터가 보급되면서, 사람들은 보다 많은 업무들을 컴퓨터에 맡기고자 했다. 그러나 필요한 프로그램들은 늘어나는데, 기호와도 다름없는 어셈블리어로는 그 속도를 맞춰나갈 수 없었다. 예를 들어 5+1 식을 계산하는 코드는 어셈블리어로 하면 다음과 같다. (이해하지 못해도 좋다. 아니, 여러분이 이해 못한다면 필자가 아래의 코드를 보여주고자 한 의도가 성공한 것이다.)

data
var1 DWORD 1
var2 DWORD 5
.code
mov eax, var1
add eax, var2 ;

(위 코드는 물론, 그 때 당시에 사용하던 코드는 아니다. 이것은 현재 우리가 많이 사용하고 있는 인텔 계열의 80X86 CPU에서 동작하는 코드이며, 50년 전에 사용되던 코드 샘플은 필자는 안타깝게도 구할 수 없었다.)
프로그래밍 언어가 이렇게 어렵게 생겼으니, 프로그래밍은 전문 과학자나 아주 똑똑한 사람들의 전유물이었다. 하지만 존 배커스(John Backus) 때문이 상황이 달라졌다. 그는 수많은 학교에서 퇴학당한 문제아였지만, 좋은 스승을 만나 컬럼비아 대학을 마치고, 이후 IBM에 입사하게 된다. IBM에 입사하면서 그는 IBM에서 개발이 진행 중이던 일종의 어셈블리어 번역기인 스피드 코딩(Speed Coding) 프로젝트에 참여하고, 이 경험을 기반으로 1957년에는 사람의 언어에 가까운 최초의 프로그래밍 언어, 포트란(Fortran) 언어와 컴파일러를 개발했다. 포트란은 연구소와 과학 기술자를 중심으로 엄청난 인기를 얻어 나갔다. 어떻게 인기를 얻었냐고? 잠시 후에 알게 된다.

포트란 언어의 덧셈 코드는 다음과 같다.

a = 5 + 1

어셈블리 코드와 비교해 보라. 이 이상 단순해질 수 없을 정도로 단순해졌다. 프로그래밍 코드답게 생긴 것은 앞에서 선보인 어셈블리어 쪽이지만, 이해하기에는 포트란 쪽이 어셈블리어보다 100배는 더 낫다. 우리가 수학 시간에 배운 덧셈과 등가 기호만으로 덧셈 연산이 가능하지 않은가?

포트란 이후, 1천여가지가 넘는 프로그래밍 언어들이 수 없이 탄생하고 사라져갔다. 그러던 중 1964년, 베이직(BASIC : Beginner's All - Purpose Symbolic Instruction Code) 언어가 미국 다트머스 대학의 존 케머니(John Kemeny)와 토마스 쿠르츠(Thomas Kurtz) 교수에 의해 탄생됐다. 이들은 컴퓨터 프로그래밍이 더 이상 과학자나 엔지니어의 전유물로 남지 않길 바랬다. 그래서 학생부터 청소부까지 누구라도 배워 사용할 수 있는 언어를 고안해 냈고, 그것이 바로 베이직이다.

이 베이직 언어는 너무 사용하기 쉬웠기 때문에 수많은 컴퓨터 광들을 프로그래밍의 세계로 끌어들일 수 있었다. 레이크사이드 스쿨에 다니던 앳된 중학생 빌 게이츠(Bill Gates)와 폴 앨런(Paul Allen)도 예외는 아니었다. 당시 컴퓨터는 엄청나게 비싼 기계였지만, 레이크사이드 스쿨은 재정적으로 풍부한 사립 학교였고, 어머니회의 후원으로 컴퓨터와 터미널을 보유할 수 있었다. 게이츠와 그의 친구들은 그야말로 하루종일 베이직 프로그래밍에 빠져들었다. 빌 게이츠는 학교를 졸업하고 하버드에 진학하지만, 얼마가지 않아 중퇴하고 마이크로소프트를 창업한다(많은 사람들이 빌 게이츠가 공부에 염증을 느꼈다고 생각하지만, 그것은 사실이 아닌 것으로 보인다. 그저 앞으로 도래할 미래가 뻔히 보이는 상황에서 기회를 놓치고 싶지 않았기 때문에 학교를 포기했던 것이다.). 그리고 마이크로소프트의 첫 번째 제품이 바로 베이직 인터프리터(BASIC Interpreter)였다.

컴파일러와 인터프리터

앞서 어셈블리 언어와 포트란 언어에서는 "컴파일러"라는 단어를 사용했고, 베이직 언어에서는 "인터프리터"라는 단어를 사용했다. 프로그래밍 언어에는 크게 두 가지 종류가 존재한다. 하나는 소스 코드에서 실행 파일로 변환하는 과정을 거치는 컴파일 방식의 언어이고, 또 다른 하나는 소스 코드를 실시간으로 읽어 해석하여 프로그램을 실행하는 방식의 인터프리트 방식의 언어이다.  컴파일 언어의 장점은 작고 효율적인 실행 파일의 생성에 있고, 인터프린트 언어의 장점은 소스 코드를 작성해서 바로 실행해 볼 수 있기 때문에 프로그램 개발이 용이하다는 데 있다.

마이크로소프트의 베이직은 IBM이 개발한 PC(그렇다. 우리가 사용하고 있는 그 PC)에도 이식되었고, PC의 수많은 응용 프로그램을 탄생시킬 수 있도록 했다. 이 베이직 언어는 이후에도 마이크로소프트가 윈도우를 출시 했을 때 비주얼 베이직(Visual Basic)으로 새롭게 거듭나면서 윈도우 응용프로그램을 보급하는 일등 공신이 된다.

* 이 포스트에는 오류가 있을 수 있으며, 추후 고증 검증 절차에 의해 변경될 수 있습니다.
* 제 블로그의 글들은 모두 저작권의 보호를 받습니다. 무단 복사 및 전제를 금합니다.

새 해 복 많이 받으세요~

다들 힘찬 2007년 시작하고 계시죠?

연초부터 정신이 없어 새해 인사도 늦었습니다. 모두들 새해 복 많이 받으시고, 건강하시기 바랍니다. ^^

지금 가벼운 글을 한편 준비하고 있습니다. 어떤 청소년 단체 회지에 기고할 글인데, 블로그에도 곧 포스팅 할테니 기다려 주시기 바랍니다. 이번 주나 지나야 제대로 된 블로그를 관리를 재개할 수 있을 듯 합니다. 이해해 주세요 ^^;

이만 줄이겠습니다. 그럼 모두들 즐프~~