프로그래머의 미래

요즘, 주변 사람들에게 썰을 풀고 있는 프로그래머의 (가까운; 10년내) 미래에 관한 나의 생각. 지식노동자에 관한 허름한 대화는 무시하거나 조언을 해주시길. 좀 시간이 지난 후에 정리해볼께요.

2005년 04월 12일 오후 4:10:10 부터 2005년 04월 12일 오후 4:34:28 까지 한 윤묵형과의 MSN 대화입니다.

최윤묵: 있구려 내가 뭐좀 알아보고 싶어서요
최윤묵: 지식노동자의 종말이 어떻게 될지 이전의 산업노동자들의 경우와 비교해서 알고 싶은데
최윤묵: 이에 관련한 책이나 자료는 없소?
세라비: 이전의 산업 노동자->지식 노동자로의 변환은…
세라비: 그… 미래 예측으로 유명한… 누구지
세라비: 앨런..뭐시기
세라비: 그리고 드러커도 지식 노동자에 대해서 언급 마니 하지 않았나용
최윤묵: 오래되지 않았소? 그책은
세라비: 네 그쵸 지식노동자의 종말에 대해선 모르겠군요 호호
최윤묵: 드러커는 너무 긍정적으로 쓰고 있다고 하던데…요새 상황과 맞지 않다라는 소문을…
세라비: 네 둘다 긍정이죠
최윤묵: 산업노동자들이 어떻게 되었는지는?
세라비: 아마 앨런쪽이 산업노동자쪽도 언급할 듯?
최윤묵: 그렇구려…
세라비: 시대가 변하고 있다 이런식일 듯 안읽어봤지만;
세라비: 지식 노동자의 종말이라. 정말인가요? T_T
최윤묵: 산업노동자도 처음에는 대우를 잘 받고 살지 않았겠소 자동화가 이루어지면서
세라비: 그렇죠
최윤묵: 처우가 안 좋아지고 있을 것이고
세라비: 분업화되고 replacable 해지고;
최윤묵: 현재 IT쪽도 … 이런 부분이 발전해가면서 산업화가 되어갈텐데 이에 대처해야지 않겠소
세라비: 아 software factory;; 크크 아직은 좀 멀었을 것 같긴한데; 하긴 몇십년 내로 … 바뀌려나;
최윤묵: 모를일이요… ^^
세라비: software factory 에 관한 얘기를 좀 살펴보면 나오려나
최윤묵: 아 그런 용어가 있소?
세라비: 네 책도 있죵
최윤묵: 그렇구려 thanks하오
세라비: 아직 지식 노동자의 종말에 대한 얘긴 잘 안보이는 듯? ;
최윤묵: 그렇구려
최윤묵: 아… 벤쳐가서 고생좀 해봤소?
세라비: 무슨?
최윤묵: 곱게자려서…
세라비: 아라에서요? 고생까지는 아닐 듯
최윤묵: 어 그렇군…
세라비: 거의 개발만 하고
최윤묵: 더 늙기전에 해볼만한가…
세라비: 밤샘이야 좀 해봤지만 KT BT 정도 들어가보고; 딱히 maintenance하러 딴 사이트들어가고 한 적은 없음
최윤묵: BT?
세라비: 벤치마크 테스트인가? 음냐;
최윤묵: yes24가 잘 안열리네…
세라비: 그러는 사람들 많고 맨날 늦게 퇴근하는 사람들 많은거보면 호호; 고생하는 사람들도 많은 듯
세라비: knowledge worker란 용어를 드러커가 만들었구나; 덜덜
세라비: http://en.wikipedia.org/wiki/Knowledge_worker
세라비: “can multiply the results of their efforts through soft factors such as emotional intelligence and trust”
세라비: 음 peopleware의 논조랑 같군;
세라비: 후쿠야마의 trust가 그런 내용이었군;;;
최윤묵: peopleware는 또 무엇이요
세라비: 아 그것도 software development에 대한 유명한 책 (저번에 언급했었는데;)
최윤묵: 그렇구려..
세라비: M-MM를 보면 software development는 essential한 부분과… 아닌(용어가;) 부분으로 나뉘는데 essential한 부분은 사람이 개입해서 해야만 하는 부분 – 디자인 같은 부분이고 다른 부분은 그런 디자인을 프로덕트로 변환하는 작업 (코딩?)인데 지금까지 기술의 발전은 essential한 부분이 아닌 다른 부분의 cost를 줄이는 방향으로 발전해왔고 essential한 부분에서는 아직까지 발전이 미비하다는 주장이에요 (10년 내 prediction으로)
최윤묵: 자동화가 되지 않을 부분을 알아두어야겠군 디자인인가 -_-
세라비: (네 그렇죠)
최윤묵: 그림이나 그려야지 췟
세라비: 음… 그게 85년에 쓰여졌고… 95년의 anniversary edition에서도 몇가지 발전 가능성이 있는 건 나왔지만 아직은 멀은 것 같다고 한 거 같아요
세라비: 여하튼 non-essential한 부분은 점점 작아지고 있는게 사실이죵; machine이 빨라지는 것 하나만 봐도;
최윤묵: 그르게
세라비: tool들도 엄청나게 좋아지고 있고 85년 당시에만 해도 cvs 같은 툴이 없어서 사람이 대신 했던 듯 ;;;
최윤묵: ;;;;
세라비: 아 essential한 부분을 해결하는 방법중의 궁극적인 것이 reuse라고 하고 component 기술에 기대를 걸더군요 아 기술이라기보단 component market이려나
세라비: 뭐 장기적인 방향은 확실히 component/service market software factory 뭐 이런 추세인 건 맞겠죠;
세라비: 따라서, 큰 범위의 design을 하는 architect가 되거나 reuse하기 어려운 system/embedded programming 쪽이 그나마 할만하겠죠
세라비: 이것도 뭐 한 10년?;
최윤묵: 허… 아키텍트라…
세라비: 그 이후로는 어떻게 될지 소프트웨어 개발 기술도 계속 싸지는 추세라서; 덜덜; network programming만 해도 옛날에야 드물었지만, 요즘에야 꽤나 많으니
세라비: use case 그리려고 팀원 기다리는 중
최윤묵: 그렇군… 뭐 해먹고 사나
세라비: 다른 분야로 바꾸거나; 빠르게 변화할 수 있도록 하거나; =_=;;; 지식 노동자의 경우엔 ‘재미’라는 부분이 크긴 할 듯 한데 호호
최윤묵: 늙으면 그 재미도…
세라비: 어쨌든 software는 complex system이라…  뭔가 breakthrough가 없는 한, 사람이 개입되어야 하는 건 사실일 듯 그 complexity에 관여하는 사람이 되는 게 좋을 듯 덜덜
최윤묵: 그렇지요…

프로그래머의 미래 더 읽기"

lighttpd + fastcgi vs. apache + mod_php

네오위즈에 근무하던, 2004년 정도에 이른바 “비용절감” 바람이 불었었다. 직접적인 원인은 아마도 budget의 감소였을 것이다. 하지만, 그동안 성능이나 비용에 크게 신경써오지 않았던 이유도 있으리라고 본다. “필요하다면, 더 많은 기계를 투입하면 된다”는 정책이기 때문인데, 이는 물론 맞는 말이다. 기본적으로 하드웨어는 싸고, time-to-market은 비싸기 때문이다.

어쨌거나 사실 시스템 프로그래머의 입장에서는 자신의 기술이 유용하게 쓰일 수 있다는 점에서, 그런 바람은 달가운 것이었다. 여러 부문에서의 기술적인 검토가 이루어지고, 또 실제로 여러가지 개선이 이루어지게 되었다.

내가 휴직을 위해 인수인계를 시작할 즈음 궁금해 하던 것 중의 하나는, 왜 apache를 대체하는 안은 고려되지 않는가였다. 그도 그럴 것이 네오위즈의 주 서비스인 세이클럽은 웹 어플리케이션이고, 따라서, 웹서버가 PC 서버들 중 상당 부분을 차지하고 있었기 때문이다. 물론 비용의 가장 커다란 부분은 DB 부문이었을테고, PC 서버들이 성능 개선의 요구에서 낮은 priority를 차지하는 것은 당연해보이긴 했지만 말이다.

당시에 내가 작업중이던 reactor framework을 테스트할 target으로 web server로 하면 어떨까 하는 생각도 있었기 때문에, 이러한 요구에 대해서 좀 더 심각하게 고려하게 되었다. 그러다가 같은 팀의 senior 멤버인 윤묵형과 이 주제에 대한 대화를 하게되었다.

윤묵형과 대화하면서 결론 내린 것은, 어느 웹서버를 사용하느냐는 별로 중요하지 않다는 것이었다. 그 이유는, 웹서버 머신 리소스의 대부분을 차지하는 것은 php (알다시피 세이클럽은 php를 사용한다)의 컴파일 및 실행 비용이고, 웹서버의 종류, 즉 apache와 비용은 상관관계가 상대적으로 작을 것이란 것이었다.

그런데, 최근 IRC 채널을 통해서, lighttpd와 php via fastcgi의 조합이 apache와 mod_php의 조합을 능가한다는 고무적인 벤치마크를 발견하게 되었다.

http://www.lighttpd.net/benchmark/

물론 이 벤치마크만으로, 세이클럽에서도 lighttpd + fastcgi의 조합이 apache + mod_php에 비해서 우세하리라고 단정지을 수는 없다. 이 벤치마크에 사용된 php application과 세이클럽에서 사용하는 php application은 다르기 때문이다. 뿐만 아니라, 세이클럽에서 사용하고 있는 apache의 기능이 lighttpd에서도 충분히 구현이 되어있는지, 또 그 기능이 벤치마크에 미칠 영향이 있을 것인지도 중요한 변수가 될 수 있다.

하지만, 이제 나는 회사라는 특정 비즈니스 요구에 한정되는 틀에서 벗어났기 때문에, apache에 비해 성능이 좋은 웹서버를 만드는 것 자체에는 더이상의 설득력 있는 이유가 필요한 것 같지는 않다. 내가 제일 처음 맡았던 job이 고성능 네트워크 서버를 만드는 것이었고, 그 때문인지, reactor + fsm 기반의 네트워크 서버를 위한 library/framework를 만들어야겠다는 조그만 야망을 계속 품어왔었다. 당장은 시간이 나지않지만, 앞으로 시간이 나는대로 작업해보고 싶다.

lighttpd + fastcgi vs. apache + mod_php 더 읽기"

Spring in KAIST

저번 주 금요일 (그러니까 2005년 4월 15일)에 수업을 마치고 점심먹고 날씨가 너무 좋아서, 몇장 찍었다. 사실 그 전에도 몇번 시도는 했었지만, 혼자서 사진 찍고 돌아다니는데에 익숙하지 않아서 대충 찍다보니 괜찮은 사진이 잘 안나왔다. 얼굴에 철판을 두르고서, 약간의 시간을 투자해 몇장 찍어 보았다. 지난주 초에 벌써 벚꽃이 지기 시작하고 있었기 때문에, 더이상 미룰 수 없다고 판단한 것이었다.그렇다고 딱히 멋진 작품이 나온 것은 것은 아니지만, 셀프샷을 그런대로 성공적으로 찍었다는 것에 만족하기로 하자.

덧붙여, 오늘 학교에서 보니, 벚꽃은 거의 진 상태였다. 그날 안찍었으면 약간 후회할 뻔 했다.

A little Madness in the Spring
Is wholesome even for the King

– Emily Dickinson (1830-1886)

인문학부 앞길 벚꽃 (교양도서관 쪽)

인문학부 앞길 벚꽃 (운동장 쪽)

지나가다 만난 메밍군

서측식당 근처의 오리들과 까리용

갑천 가의 꽃 (무슨 꽃이지?)

접사

휴직 선물로 받은 옷을 입고 셀프샷! (목에 걸고 있는 Shuffle이랑 엄청 잘 어울린다.)

Spring in KAIST 더 읽기"

삼색볼펜초학습법과 소프트웨어 엔지니어링

줄긋기

비문학 서적을 읽을 때는 거의 항상 줄을 그으면서 읽는다. 영어로 된 것일 수록 더욱 그렇게 한다. “책을 읽을 때 줄을 긋는 행위”의 pros/cons는 trivial하게 알 수 있다.

Advantage

  1. 줄을 긋는 행위 자체가 내용의 기억에 도움이 된다. (내용을 요약하거나, 소리내어 읽는 것과 비슷한 행위)

  2. 나중에 읽은 책을 다시 참조할 일이 있을 때, 중요한 정보를 빨리 찾을 수 있다. (역시 요약과 비슷한 효과)

Disadvantage

  1. 시간이 걸린다.

  2. 지하철이나 버스 등 줄긋기가 여의치않은 환경에서 실행하기 힘들다. (나중에 중요한 내용을 회상해내어 줄을 그어야한다.)

삼색볼펜초학습법

삼색볼펜초학습법이라는 것은 얼마전에 deepblue군으로부터 들은 학습법인데, 말그대로 책을 읽을 때 세가지 색의 볼펜을 이용해서, 줄을 그으면서 읽는 방법이다. 자세한 방법을 알고 싶으면 다음 페이지를 참고하라.

어떻게 보면, 삼색볼펜초학습법은, 줄긋기의 이점을 최대화하는 방법이다. 나의 경험으로 미루어봐도, 분명히 가장 중요한 내용과 약간 덜 중요한 부연적인 내용은 구분될 필요가 있어보인다. 게다가, presentation 같은 것을 준비하는 경우에, 자신이 재미있었던 내용을 빨리 찾아볼 수 있다면, 준비시간이 훨씬 줄어들 것은 명백하다.

그럼에도 불구하고, 삼색볼펜초학습법에는 시간이 너무 많이 든다. 물론, 어떤 책들을 매우 빈번하게 참조를 해야해서, 삼색볼펜초학습법의 이점을 최대한 활용할 수 있겠지만, 모든 책이 그런 것은 아니다. 일반적으로 삼색볼펜초학습법은 그다지 좋지못한 cost-effectiveness를 가지고 있다고 생각한다.

그렇다고 해서 완전히 삼색볼펜초학습법을 반대하는 것은 아니다. 책을 읽는 목적이나 책의 종류에 따라, 일색, 이색, 삼색볼펜 초학습법을 유용하게 적용하는 것이 필요하다는 것이다.

Trade-off

솔직히, 최근의 삼색볼펜초학습법 열풍(?)은 일종의 유행이라고 생각한다. 이러한 현상은 비단 삼색볼펜초학습법 뿐만 아니라, 소프트웨어 개발 방법론 쪽에서도 볼 수 있다. 예를 들어, 무조건 XP 방법론의 모든 룰을 따라야만 하고, 당신의 프로젝트는 XP 방법론의 룰들을 제대로 지키지 않았기 때문에 실패했다는 주장을 들 수 있다. 이러한 사람은 제대로 XP 방법론을 이해하고 있기보다는, 그저 XP 방법론의 유행에 편승하고 있다고 밖에는 생각할 수 없다. (물론 삼색볼펜초학습법에 대해 이처럼 offensive한 사람은 아직 본 적이 없다.)

어떤 문제를 풀 건간에, 사람들이 간간히 하게되는 실수가, 유행이나 규칙과 같은 기존의 해결책에 너무 얽매여서, 좀 더 나은 해결책을 생각하지 못하거나, 알려진 더 나은 해결책조차도 거부하는 것이다. 이같은 상황을 피하기 위해서는, 주어진 기존의 해결책에 대해 pros/cons를 파악해보려는 시도를 하는 것이, 일종의 사고 도구가 될 수 있다.

Update: Steve McConnellIEEE Magazine에 기고한 Cargo Cult Software Engineering에서도 이와 비슷한 얘기를 하고 있다. 참고할 것.

삼색볼펜초학습법과 소프트웨어 엔지니어링 더 읽기"

한홍구의 역사이야기

“한홍구의 역사이야기”는 한홍구 교수가 2001년 1월부터 한겨레21에서 연재하기 시작했던 한국의 근현대사에 관한 칼럼이다. 2003년 1월까지 2년간 연재가 되고서 멈추더니, 책 2권 (대한민국사, 대한민국사 2) 으로 묶여나오면서 더이상 나오지 않을 줄 알았는데, 2004년 3월경부터 다시 연재가 시작된 모양이다. 현재까지 책 한권 분량은 나온 것 같으니, 당분간은 즐겁게 읽을 수 있을 듯 하다. (읽으려면 한겨레21 회원 가입이 필요하나, 충분히 가입할만한 가치는 있어보인다.)

http://h21.hani.co.kr/section-021075000/home01.html

한홍구의 역사이야기 더 읽기"

김영하의 "엘리베이터에 낀 그 남자는 어떻게 되었나"

한국의 현대 소설은 잘 읽지않는 편이다. 그렇다고, 이런 저런 소설은 읽지 않아야겠다고 작정할만한 이유가 있는 것은 아니다. 굳이 이유를 찾아본다면, 내가 살을 접하며 살고 있는 현실과 너무 가까운 것은, 날생선을 먹는 것처럼 비린내가 난달까. 나와 같은 언어로 말을 하고, 나와 비슷한 체험을 하는 사람들의 이야기는, 일부러 스스로를 지목하여 촘촘히 들여다보게 만들어서 불편하다. (“불편하다”는, 김영하의 소설들을 읽으며, 그 유용함을 발견한 표현) 기왕이면, 어느 먼 왕국의 이야기가 좋고, 수억광년 떨어진 외딴 별의 이야기가 좋다. “킬킬, 당신도 결국 이딴 종류의 인간일 뿐인거 아냐?”라고 말하는 것보다는, “원래 인간이란게 이런거라네.”라고 하는 소설이 좋다.

본의든 아니든 “문학의 이해”를 수강했던 것은, 내가 복학했던 탓이고, 본의든 아니든, 본의든 아니든 한국 작가의 소설을 읽어야 했던 것은, 내가 숙제를 하기로 마음먹었던 탓이다. 본의든 아니든 김영하를 집어든 것은, 그 사람의 책이 내겐 재미있어 보였던 탓이다.

뭐, 대단찮은 취향을 굳이 지키려고 끙끙댈 필요가 있나, 책 한 권 읽는 것에 무슨 대단한 이유가 필요한가. 사람이 그리워 서울로 향하는 버스 안에서 가볍게 꺼내들었다. 대체 왜 “우등”이라고 이름을 붙이는지 이해할 수 없는, 덜덜 떨리는 버스 안에서 책을 읽은 탓에, 친구와의 만남은 좀 피곤했지만, 책 자체는 재미있었다. 상당히 재미있었다. 대강 때려맞춰봐도, 이 작가 나랑 코드가 맞고, 이야기를 잘한다, 다른 책도 한번 사서 읽어볼까. 책 맨 뒤에 있는, 짤막한 평론은, 당연하고 대단찮은 이야기를, 굉장히 어렵게 써놓은 것 같다. 이게 뭐야. 이럴거면 그냥 붙이지말지. 내가 “문외한”이라서 그런가?

첫번째로 나오는 소설이 (얘기안했던가? 이건 단편소설집이다.) “사진관 살인 사건”이다. 제목이 말해주듯 추리소설이라는 감이온다. 실제로 추리소설의 형태를 하고 있다. 중간쯤 가면 흥미진진하다. 그런데, 이 소설에서는, 김전일 만화였다면 “범인은 바로 이 중에 있다!”라고 외치며, 의외의 인물을 지목해야하는 시점에서, 그만 시시해져버린다. 거기가 아니라, 이어지는 수사관의 후일담이 나오는 지점이 바로 독자들이 무릎을 탁쳐야하는 지점이다. 연애를 한번이라도 해본 사람은, 특히 짝사랑인지 사랑인지 모를 중간쯤의 연애을 해본 사람은, 이 단편 전체에 흐르는 두 용의자의 미묘한 감정의 흐름에 쾌감을 느낄 수 있을 것이다. 졸졸 흐르던 감정이 결말에 가서는 엄청난 양으로 증폭되어 쏟아져나온다. 그만큼 긴 여운. 그런데, 그것은 수사관 얘기처럼, 신문에 흔하디흔하게 오르내리는 추잡한 감정 놀이였을 뿐인데. 그 두사람에게는 또는 독자에게는 그만큼 드라마틱하지 않을 수 없었을 것이다. 당신이 소중하게 생각하는 연애담을 인터넷 게시판에 올리거나, 술자리 선배에게 얘기를 한번 해봐라. 다른 사람들에게는 그저 흔하디흔하고 너절한 연애 얘기에 지나지 않는다. 영화 “엽기적인 그녀”를 보면, 탈영한 군인에게 인생 강좌를 해주며, 사랑보다 인생이 중요하지 않냐고 한다. 자기네들은 사랑가지고 울고 불고 지지고 볶으면서 말이다. 지하철에서 토한 여자를 여관에 업어다 줄만큼 엽기적이고, 맞선 보는 자리에서 헤어진 여자친구를 만날 정도로 드라마틱하지 않으면, 그런 생각은 절대 않는게 좋을 것이다. 결국, 치정살인사건이 아니었다는 건, 그다지 중요하지 않다. 치정살인사건이어도 아무것도 이상할 것이 없었다는 것이 우리들이 하는 감정 놀이의 진수다.

“흡혈귀”에 나오는 흡혈귀는 멋있다. 삶과 죽음을 초월하고, 사랑을 초월하고, 시간을 초월하고, 덤으로 아는 것도 많다. 한가지라도 빠졌으면 덜 멋있었을 것이다. 내 이상형이라고 해도 나쁘지않다. “정말로 그런 멋있는 사람이 있는거야? 어떻게 그럴 수 있지?”라는 물음에, “별거 아냐, 그 사람, 흡혈귀라서 그런거아냐?”라는 느낌이다. 숨겨진 한마디는, “그런데, 뭐 어쩌라고, 제 멋대로 살겠다는데.” 정도일까.

“피뢰침”은 벼락을 맞아본 사람의 모임을 소재로 한 소설이다. 진짜로 그런 동호회가 있나하고 찾아봤지만, 그 동호회 이름인 “Adad”가 고대 오리엔트의 뇌신이라는 것 정도만 알아냈다. 주인공이 그 동호회의 회장인 J에게 대체 왜 위험을 감수하면서 다시 벼락을 맞으려하는지 묻자, J는 그 이유를 예술적 희열에 비교한다. 간단하게, 예술적/종교적 희열을 벼락 맞기의 희열로 비유한 것을 유추해볼 수 있다. 나처럼 예술이나 종교와 거리가 먼(?) 사람들에게, 명화을 그리면서 느끼는 희열이 뭔지, 신을 섬기면서 느끼는 희열이 뭔지를 말로, 글로 설명해봤자 이해할 사람은 별로 없다. 하지만, 발기한 피뢰침으로는 설명이 되는 것 같다.

“당신의 나무”는 앙코르 사원으로의 여행과, 히스테리아를 앓는 여성과의 연애를 소재로 하고 있다. 개인적으로는 히스테리아라는 단어에는 묘한 감정을 가지고 있다. 거기에는 비정상 자체가 정상인의 권력이 낳은 횡포라는 인식도 작용하고 있고, 요즘 시대에 히스테리아에 대해서 좀 알고 있으면 유식하게 보이는 것도 있고, 더욱 근본적으로는, 히스테리아를 앓는 여성을 사랑한 적도 있었기 때문일 것이다. 나도 그런 시절의 어느쯤엔가는 “당신의 나무”가 되고 싶었던 적이 있었고, 이성으로 설득하려고도 해보았고, 감정을 내세워 달래보기도하고, 정신의학 입문서나 프로이트도 읽어보았다. 결론은, 난 “당신의 나무”가 될만한 능력따위는 애초부터 없다는 것이었고, 포기할 수 밖에 없었다. (어쩌면 그러한 포기 자체가 그 점을 입증하는 걸지도 모른다.) 내가 그녀에게 “당신의 나무”가 아닌 것은 확실하지만, 그녀는 나에게 “당신의 나무”인가? 글쎄, 별로. 소설에서처럼 앙코르에라도 가봐야 깨달음을 얻을려나.

친구들이 이 책에 대해서 어떻게 생각하느냐고 묻는다면, “글쎄, 읽어볼 만 하긴 하다” 정도가 될 것 같다. 덧붙인다면, “매우 재미있다. 김영하를 한권 정도 더 사볼 생각이다.”가 될 것 같다. 한가지 아이러니는, “친구”는 보통 접근성이나 신뢰의 정도에 의해서 결정되고, 정작 책을 추천해줄 때 중요한 기준이 되는 취향에 의해서 결정되지는 않는다는 점이다. 그래서, 이 글은 별로 쓸모가 없는 것 같다.

김영하의 "엘리베이터에 낀 그 남자는 어떻게 되었나" 더 읽기"

예비군 교육훈련 소집

병역특례를 마치자마자, 첫번째 교육훈련 소집이 나왔다. 학교에 예비군 군대가 없으므로, 갈마 2-2동대 소속이 되었다. 따로 신고를 안해도 바로 지역 예비군에 편입되어버리는 것 같다.

교육훈련 소집 통지서랑 병력동원지정해제 안내문이 같이 날아왔는데, 이건 동원훈련을 가지 않아도 된다는 얘기다. 동원부대가 있어서, 평상시에도 현역들이 상주(?)하고 있는데, 동원훈련이란 동원된 예비군들이 현역들과 함께 2박 3일 정도로 훈련하는 것을 말한다.

나같은 1년차 동원미지정자의 경우, 동미참훈련이라고 해서 24시간 훈련이 1년에 한번씩 있는 것 같고, 이번에 나온 것 같은 6시간 짜리 향방작계훈련이 1년에 2번 있는 것 같다. 1년에 3번씩이나 정체성을 버리고 군인이 되어야하다니, 상당히 스트레스 받을 것 같다. 어떻게보면 동원훈련 가는게 더 나을 것 같기도 하고.

어쨌든, 다행히도 대학생(복학생)은 훈련을 보류할 수 있다. 재학증명서를 가지고 소속 동대에 가서 보류신청을 하면 된다. 모든 훈련이 보류되는지는 모르겠지만, “교수님, 예비군 훈련때문에 저번 시간에 못나왔습니다.”라고 할 상황이 없길 바란다.

나같은 사람이 졸업한 이후에 예비군 훈련을 하지않으려면, 외국으로 6개월 이상 나가있는 수 밖에 없다. 국회위원, 법관, 검사가 되든가, 사회안전에 관련된 직업들(경찰관, 소방관), 아니면 교수가 되는 방법도 있긴 하지만, 내가 해당되는 건 없을 것 같다. 고급인력이 외국으로 유출되는 큰 원인 중의 하나가 예비군이 아닐까…하는 생각도 든다..농담.

자세한 것은, http://www.yebigun.or.kr/ 참고.

 

예비군 교육훈련 소집 더 읽기"

Exceptional C++ Style

Exceptional C++ Style by Herb Sutter

Exceptional C++, More Exceptional C++에 이은 세번째 gotw 책이다. gotw (Guru of the Week)란, C++ 프로그래밍에 관한 Herb Sutter의 연재물이다. Herb Sutter의 홈페이지에 잘 정리되어있으면서, CUJ에 가끔 실리기도 하고, 책으로도 출간된다. 현재까지 87번까지 나와있는데, #1~#30은 Exceptional C++에, #31~#62는 More Exceptional C++에, #63~#86은 바로Exceptional C++ Style이다.

주변이나 커뮤너티에서 C++ 관련 질문을 하면, 내가 자주 언급하는 것은 바로 gotw다. 그만큼 C++ 프로그래머가 자주(언젠가는?) 접하게되는 문제들을 gotw가 다루고 있기 때문이다. (Effective 시리즈들도 비슷한 성격을 갖고 있지만, C++ 프로그래머들이 보편적으로 읽는 필수서라서 굳이 언급하게 되는 기회는 없는 것 같다.) 굳이 책을 사서 읽지 않더라도, 시간날 때마다 웹에서 gotw item 하나씩 읽어보는 것도 괜찮을 것이다.

기존 Exceptional 시리즈의 형식이나 내용의 질을 그대로 유지하고 있기 때문에 기존의 글에 덧붙여서 별다른 설명은 필요하지 않을 듯 하다. 아쉽게도, 아직 번역은 되지 않았다.

 

Exceptional C++ Style 더 읽기"

Writing Solid Code

Writing Solid Code by Steve Maguire

번역판을 읽었다. 원제는 ‘Writing Solid Code: Microsoft’s Techniques for Developing Bug-Free C Programs’. 대체로 C/C++ Programmer를 대상으로 한 버그를 줄이기 위한 프로그래밍 기술에 관한 유명한 책이다. 하지만, programming language에 한정되지않는 조언들도 있다. Steve Maguire의 Microsoft에서의 실제 경험을 바탕으로 지어진 책이고, 실제로 그의 경험들이 예시로 등장한다.

이 책에는 다음과 같은 조언들이 등장한다.

– Enable compiler warnings and pay attention to them.
– Use assertions to validate your assumptions.
– Don’t quietly ignore error conditions or invalid input.
– For a complicated, critical algorithm, consider using a second algorithm to validate the first. (e.g. validate binary search with a linear search).
– Don’t write multi-purpose functions such as realloc (it can grow memory, shrink memory, free memory, or allocate new memory — it does it all).
– Check boundary conditions carefully.
– Avoid risky language idioms.
– Write code for the “average” programmer. Don’t make the “average” programmer reach for a reference manual to understand your code.
– Fix bugs now, not later.
– There are no free features; don’t allow needless flexibility (like realloc).
– Ultimately the developer is responsible for finding bugs; he shouldn’t write sloppy code and hope that QA will find all his bugs.

[from Paul J. Mantyla’s comments in Amazon]

대체로 programming을 1-2년 정도 한 경험이 있는 사람이라면, 이러한 충고들은 대체로 스스로 익힐 수 있다. 시행 착오를 피하기 위한 책 정도가 될까. 오래된 책이라서 (1993년에 출판), 설명을 위한 예들 역시 오래된 감이 있지만, 충고들 자체는 여전히 유효하다. C/C++ programming job을 얻기 전의 학생들은 한번씩 읽어보면 좋을 듯한 책이다. 어느 정도 숙련된 programmer라면 부담없이 읽어볼만한 책이라서, 화장실에 두고 심심풀이로 읽는 것도 나쁘지는 않을 듯하다.

번역은 몇가지 용어의 번역이 모호해서, 원서를 찾아보기도 했지만, 무난한 편이었다. 번역서다 보니, 1-2일 정도만에 다 읽을 수 있었다.  조판 자체가 깔끔하지 못해서, 딱히 소장하고 싶은 마음이 들지 않는다. 번역서는 누군가에게 줘버리고, 원서만 가지고 있을 생각이다.

Writing Solid Code 더 읽기"