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 라는 책에서 읽은 글귀입니다. 아인슈타인이 남긴 말이예요.

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