느닷없는 출장

지난 번에 그랬듯이 이번에도 갑자기 출장 결정이 내려졌다.
비행기만 있었으면 내일이라도 가라고 했으려면 다행히 직항이 모레 있어서 하루를 벌었다. 휴. 내일 직항이 있었으면 상상만 해도 -_-

덕분에 해야 할 일들 몇 가지 정리하고, 출장품의 올리고, 비행기, 호텔, 렌트 예약하고.

Things for iPhone을 이용해서 가기 전에 해야 할 이런 저런 일을 정리해보니 무려 23가지. 사소한 거지만 그래도 이렇게 적어놓지 않았으면 계속 깜빡했겠지?

추가) 결국 출장은 8월 4일 출발하는 걸로 결정됐다. 근데 또 2주나 있다 오라고 하네. 쩝. 1주일이면 딱 좋겠는데.

수두 경과

다행히 첫날 발진으로 하고는(첫 날은 발갛게 부어오른 부위에 약을 바르때마다 아프다고 울었다는) 다음 날 부터는 많이 좋아 졌다.

여전히 몸 군데 군데 포진이 올라왔지만 약을 열심히 발라주니 정말 자고 나면 신기할 만큼 잘 가라않고 있다. 비록 다른 부위에 포진이 올라오지만.

예상대로 머리카락 속에도 발진/포진이 숨어있어 발라주었더니 왠 50년대 아이처럼 머리에 허연 가루(실은 물약이 굳은 거지만)를 군데 군데 하고 노는 모습이란.

그래도 이제는 약 바를 때 간지럽다고 힘들어 하니 아프다고 힘들어 할때보다는 훨씬 좋다.

이번 주만 조금 더 고생하면 다 낫겠지. 목에 생긴 상처가 문제인데…

아빠 노릇하기 힘들어

아이의 잘못을 지적할 때는

– 우선 아이의 감정에 동감을 표시하고
– 아이가 잘못한 점을 지적하고
– 어떻게 해야 하는 지 대안을 제시

해야 한다고 한다.

만일 아이가 지나가다가 컵을 떨어뜨렸다면

– 다치지는 않았니?
– 조심해야지
– 항상 잘 보고 다녀야지

가 정답 이란다.

그런데 이런 반응이 아니라

> 또 떨어뜨렸어? 니가 잘못한 거지

그러면 아이는

> 아닌예요. 그냥 컵이 혼자서 떨어졌어요

라고 한단다. 정말 그렇다.

아까 침대에서 매미를 가지고 놀다가 온 아이가 매미가 침대 밑에 “숨었다고”하길래 싫은 소리를 냈더니 “매미가 스스로 침대 밑으로 들어갔다고” 답을 했다.

직접 혼을 내기 보다 “매미가 침대 밑으로 가게 할 수 있게 만든 상황”에 대해 지적을 했다면 좋았을 텐데.

190페이지 짜리 [아이의 미래를 바꾸는 아빠의 대화 혁명](http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=2121669) 을 보고 있는데 휴.. 너무 너무 양이 많다. 정말 다양한 케이스를 설명하고 있는데 아마도 핵심은 앞에서 정리한 “감정, 지적, 대안 제시”인 듯하다.

하지만, 실제 생활에서는 더욱 더 다양한 경우가 있으니 다양한 예제를 통해 핵심을 파악한 후, 그 핵심을 상황에 맞게 응용해야 하는데 그게 또 어찌 쉽겠는가.

부서 이기주의

이런 걸 부서 이기주의라고 불러야 하는 게 맞는 지 모르겠다. 암튼

지난 주에 있은 가장 큰 이슈를 해결하기 위해 안을 만들어 랩장 리뷰를 통해 개발자에게 구현 요구를 전했다.
비교적 간단한 수정 후에 시험이 완료되어 패치를 내야 하는데, 패치는 크게 두 가지 였다.

– 실제 조건등을 판단해서 동작하는 S/W
– 위 S/W가 제대로 동작하기 위해 수정되어야 할 configuration file

한 가지 목적을 위해 이 두 가지가 수정되어야 하는데 문제는 우습지만 이 두 개를 책임지는 부서가 서로 다른 부서(바로 옆이긴 하지만)라는 것이다. (원래는 하나 였는데 이런 저런 이슈로 분리되었다 – 알고 보면 부끄러운 현실이라 더 이상 언급은 회피)

암튼 이 두 개를 패치해야 하는데 서로 다른 개발자/부서라서 문제가 생겼다. 개인적인 생각에는 위 두 가지 중 첫번째가 핵심이고, 두 번째는 아주 사소한 부분이라 첫번째 패치를 내는 김에 함께 패치를 내줬으면 했다.(여기서 말하는 패치란 동일한 CQ를 이용하여 소스 코드를 수정하고, 검증 부서등에 패치를 제출할 때 파일 리스트에 함께 적어주는 것이다)

하지만 그쪽 부서장은 그걸 반대했다. 잘 이해할 수는 없지만 그래서는 안된다고.
아무도 그걸 걱정하는 듯하다. 그 쪽 부서 내에서도 하나의 블럭/소스를 여러 개발자가 책임지고 있다 보니 code ownership 관련 문제가 많은 걸로 안다. 한 사람이 수정한 후에 소스 코드를 적용하기 전에 다른 사람이 로컬로 작업하고 그러다가 제대로 코드 머지를 안해서 나중에는 이미 수정한 부분이 다른 사람에 의해 삭제되는 등의 문제. 그래서 아마도 소스 코드에 대한 “관리”를 철저히 해야 겠다는 생각을 한 모양이다.

그래서 아주 사소한 거지만 절대로 동일 CQ로 처리할 수 없다는 의견을 제시했다.
그래서 나도 그랬다.
“니들 맘대로 해라”

(검은 색 커튼을 배경으로) 정말 이지 화가 났다.
이번 건은 소스 코드 관리에 문제가 있는 것도 아니고, 또 다른 부작용을 일으킬 염려가 100% 없음에도 그냥 싫단다. 원채 그쪽 부서장이 부서간에 의존성을 갖는 걸 싫어하는 걸 알지만, 그 덕분에 시스템 설계가 엉망이 되어 가고 있고, 실제로 그런 의존성을 제거하는 것이 불가능하고, 오히려 그런 어줍잖은 원칙때문에 시스템 성능이 타사 장비에 비해 떨어지는 걸 모르지 않을 텐데.

그리고 제대로 된 코드리뷰만 한다면 code ownership은 함께 공유해도 문제 없다는 것이 내 생각이기에 그런 “관리” 원칙때문에 저런 결정을 내렸다는 것이 정말 이해되지 않았다.

그냥 말 한마디로 “안 돼”하곤 그냥 달려나간(패치를 먼저 낸) 덕에 검증 부서는 시험도 못하고 시험을 다음 날로 미뤘다.

조직이 커져가면서 부서간에 반목만 늘어나고, “내 꺼”, “니 꺼”, “니 문제”만 입에 달고 다는 행태가 너무 싫다. 유난히 지금 부서가 그렇다는 말을 들으니 어디서 부터 꼬인 건지 참.

놀이터

![](http://cychong.synology.me/wordpress/wp-content/uploads/2008/07/img_58441.jpg)

어쩜.

작품 부연 설명을 좀 하면 모퉁이에는 가로등이 있고, 철봉이 크기 별로 있고, 미끄럼틀도 있고.

그 앞에 있는 것은 놀이터 가면 제일 재밌게 노는 타이어 쿠션. ㅋㅋ

블로그는 관보?

가끔 그런 생각이 든다.

아래 글에도 아이랑 잘 놀아 준 것처럼만 적긴 했지만 실은 그 이후의 일은 또 모르는 거다.

사실 이 새벽(지금 시각 새벽 3시)에 일어나 이 짓(?)을 하고 있는 건 어제 매미를 잡아주고 저녁 6시부터 쓰러져 잠들었다가 새벽 1시 조금 넘어서 일어났기 때문이다.

일어나게 된 것도 좀 웃긴데 침대에서 자고 있다가 핸드폰 진동소리에 일어났다. 근데 알고 보니 진동은 핸드폰에서 발생한 게 아니라 매미가 만들어 낸 것같다. 잠들기 전에 아이가 침대 밑으로 두 마리가 숨었다고 해서 왜 풀어줬냐고 혼을 낸 기억이 났다. -_-

쩌비.

결국 역사가 그렇고, 관보가 그렇듯이 외부에는 말하는 사람이 하고 싶은 내용만 말하게 되어있다.

꼬랑지) 그래서 그들이 인터넷이거나 KBx, YTx를 가질려고 하는 거 겠지.
어제 TV를 보니 이전 정권이 들어섰을 때 정부는 언론이 말하는 가시돋힌 말을 너무 미워하지 말라고 주장하던 사람이 지금은 입각하더니 언론은 정부가 말하는 걸 잘 나팔불어야 한다고 주장하고 있더라.
한 마디로 세상은 요지경이다.

야호 여름이다~

왜?

수영장이 열려서?

맛있는 수박을 먹을 수 있어서?

여름 방학이 있어서? (이건 해당 사항이 없구나 -_-)

아니 왜?

우리 따님은 바로 “매미” 때문이란다.

덕분에 작년에는 한꺼번에 무려 매미를 30마리를 잡은 적이 있는데, 오늘도 15마리를 잡았다(2 마리는 잠자리채를 들고 있는 나에게 어떤 학생이 오더니 주고 갔다. 집 모기장에 붙어서 너무 시끄럽게 울어서 잡았다나)

암튼 딸아이는 그나마 매미를 핑게로 같이 놀아주는 게 신나나 보다. 매미를 잡았더니

“우리 아빠가 잡았어요~”

라고 소리를 동네방네 질러댔다. -_-

한 2시간 투자해서 열심히 쫒아 다니다 보니 내가 재밌어서 더 하게 됐다는. ㅋㅋ

"Linux is evolution, not intelligent design"

내가 아는 거의 모든 S/W manager들이 이 말을 들으시면 기겁을 하겠지만 Open source 개발의 대표 중의 하나인 리눅스 커널은 그분들이 보기엔 정말 엉망인 S/W 개발 과제다.

> The Kernel has no obvious design

커널은 설계부터 시작한 것이 아니라(물론 처음에 토발즈씨가 할 때는 그랬을 지도 모르지만) 진화하는 방식이고, 무수히 많은 사람들이 함께 개발하는 거라 오히려 설계, 설계 리뷰, 구현, 시험의 통상적인 개발 process 를 지키기 어렵다.

차라리 (개인적인 수준의 설계), 구현, commit, 다수에 의한 리뷰/시험, 수정의 개발 process가 더 효과적이다.

> Open-source development violates almost all known management theories.

혹시나 이글에서 언급하고 있는 내용을 말씀드리면 그런 말을 하지 않으실까?

> 그 S/W 개발자랑 우리 개발자는 다르잖아.

개발자의 역량이 다른 것도 사실이지만, 다른 점 측면에서는 그런 점은 새발의 피가 아닐까?

재밌는 글이다.

> Documentation/stable_api_nonsense.txt

리눅스 커널의 경우 필요하다면 user application에 제공하는 API까지 바꿔버린다고 한다. 이 점에 대해서는 논쟁 거리가 많을 듯하다. 호환성을 중시할 것인지(MS Windows나 99% 이상의 S/W manager가 그렇듯이) 아니면 S/W 코드를 심플하게 유지하고, 개발자들을 늘 긴장하게 하여 커널 변경에 따라 코드를 함께 수정하게 할 것인지.

일단 코드 변경은 불안정성을 발생시킨다는 통념에 따르면 이 역시 관리자 입장에서는 말도 안되는 생각이라고 할 것이다.

재밌는 글이다.

– [리눅스 커널에 대한 신화, 거짓, 그리고 진실] (http://barosl.com/blog/entry/myths-lies-and-truths-about-the-linux-kernel) – [원문](http://www.kroah.com/log/linux/ols_2006_keynote.html)

Nikon D700

[D300](http://sosa0sa.com/2008/05/11/1712/) 이란 녀석이 나온 지 얼마 됐다고 정말로 니콘에서 중급형(?) FF 바디를 내 놨다.

[D300](http://cychong.synology.me/wordpress/wp-content/uploads/2008/07/nk0000549-image21.jpg)

그 전작인 D3와 D300의 장점을 고루 갖추고 나와 구미가 당긴다. 니콘의 바디가 좋다는 소리는 많이 들었지만 캐논의 AF를 더 이상 고민해도 된다는 소리에 솔깃하지만 가격이 너무 비싸다.

하지만 FF에 ISO를 6400까지 올려도 노이즈를 걱정할 필요가 없다고 하니 우왕.

문제는 가격도 있지만, 무게도 있다. 지금 쓰고 있는 350D와 다른 제품 간의 무게 차이를 보면 무려 2배의 무게를 자랑(?)한다.

* 350d : 485g
* 40D : 740g
* 5D : 810g
* d80 : 585g
* d300 : 825g
* d700 : 995g

그리고 D700은 FX 포맷의 렌즈만 지원하기 때문에 내가 꿈(?)꾸고 있는 18-200 VR 2 렌즈를 사용할 수 없다. -_-

쩌비.

[SLR club 사용기 하나](http://www.slrclub.com/bbs/vx2.php?id=user_review&page=2&sn1=&sid1=&divpage=4&sn=off&sid=off&ss=on&sc=off&select_arrange=headnum&desc=asc&no=26781)

할때는 확실하게

주중에는 열심히 회사 일을
주말에도 열심히 가정에

집중하자.

주중에도 열심히 하는 건 퇴근시간까지만 그랬어야 하는데 이번 주에는 퇴근이 너무 늦었다.
담주부터는 다시 원래대로..