정확한 질문은 “왜 삶의 여러 지층 중 하나가 개발자인가?” 겠지요.
문득, 미사를 드리러 가려고 샤워를 하는 도중에 이런 생각이 들었습니다. 음악을 하고 그림을 그리고 글을 쓰면서 프로그래밍으로 밥을 벌어먹고 있는데, 왜 하필이면 개발자로 먹고 살고 있는가? 그냥 잘하기 때문에? 가진 능력중 가장 경제적으로 뛰어난 것은 사실이고, 실제로 경제적인 부분은 전적으로 이쪽에 의지하고 있는 것도 사실입니다. 이쯤 되니 갑자기 이건 아니다라는 생각이 들더군요. 그러면서, 아 나도 서른이구나. 7년차구나. 라는 생각도.. (퍽)
가장 감명깊었던 책제목은 (내용말구요. 제목!) Just for fun입니다. 라이너스 토발즈씨의 자서전 제목이죠. 요즘 잃고 있었던 초심이 Just for fun이었던 것 같습니다. 대부분의 개발자들이 재미로 시작하지만, 어느새 그 재미를 잃고 있는게 아닌가 싶습니다. 이런 의구심이 드는 시점임에도, 일은 재밌습니다. 문제는 일이 재밌는 것이지 일을 재밌게 만들고 있지는 않다는 점이죠. 제 초심은 일을 재밌게 만드는 것이었으니까요. 잃었던 것을 찾은 이 기쁨은 뭐… 이루 말할 수 없습니다.
재미있는 일을 더 재밌게 만드는 것. 개발자로 오래 살아남는 가장 즐거운 방법이 아닐까 생각해봅니다.
그리고, 이 곳에 오신 당신은. 왜 지금의 직업을 갖고 계십니까?
네. 이사간다는 이야기는 아닙니다. 정리하면서 사라졌던 분류의 글들을 쓰기 위해 공간을 하나 더 만들었습니다. 사실, 이 블로그에 쓰는 글들이 지적 허영이가득 찬 글들이기도 하거니와, 그냥 무거워진 이 공간말고, 가벼운 공간이 하나 더 필요하다는 요구와 즉흥적인 지름에 하나 더 만든겁니다. 인생 뭐 있나요.
어쩌면, 포스트의 절대적인 수로는 역전현상이 나타날지도 모르겠습니다만. 과거 블로그의 제목이 ‘Crow’s Maniacal World’이던 시절에서 Devspace@Crow로 넘어오면서 사라져버린 다른 제 자신을 적어내는 공간이니 당연한 것일지도 모릅니다.
여전히, 이 곳은 쓰던 글들과 써야할 글들이 올라옵니다. 지금 쓰고 있는 글만 3개정도 되는군요. (개요잡고 고민하는 글을 이야기하는 겁니다. 제목과 주제만으로 치면 더 많… orz) 하지만, 이 곳과 텀블러에 쓰지 않던 글들이 올라오겠지요. 워낙에 관심분야도 넓고 하는 짓도 많아서 어쩔 수 없나봅니다.
그럼. 돌아온 Crow’s Maniacal World를 소개합니다. 씨익-
워우… 역시나 워드프레스 앱이있군요.. 꺄악. 이걸로 저도 모바일블로거???
제한적인 것 같긴하지만 상당히 유용할 듯 하긴합니다. 으흣-
일단은 태그같은 걸 때려박기는 힘들듯하고.. 간단힌 포스트를 올리는 정도로는 유용할 듯…
애플에서 만든 iMac. 즉, Mac OS X을 처음 써보고 꽤 큰 쇼크를 먹었다. 그냥, 컴퓨터로 하고 싶은걸 하면 되었다. 하드웨어나 드라이버 같은건 신경쓰지 않아도 되었다. 그냥 하고 싶은걸 하면 된다. 컴퓨터 가격이 아깝지 않은 최초의 순간이었다. (물론 쓰다 불편한 건 이것 저것 깔아서 바꾸긴 하지만.. 지금 내 맥에는 그런 류의 유틸리티는 없다고 봐도 된다. 그냥 필요한 것만 깔려있다.) PC를 쓸때 했던, 각종 OS관련 설정이나 삽질은 없었다.
내가 위키를 쓰지 않는 이유 역시 CN의 그것과 동일하다. personal wiki가 유용해지는 시점은 강의노트를 정리할때 뿐이다. 강의노트는 특성상 링크가 유용할 때가 많은데다가, 책의 내용을 요약하는 경우가 많으므로 대다수의 위키에서 제공하는 Table of Contents 기능이 “매우” 유리하다. 또한, 강의노트는 작성 시간에 크게 상관없다. 생각나는 것들을 정리하는 블로그. 블로그의 어원이 Web Log라는 점을 돌이켜보자. 블로그는 어떤 사람의 생각 혹은 행동의 로그다. 일기를 백과사전처럼 쓰는 사람이 없듯이, 몇몇 아티클을 쓰기위해 위키를 쓸 필요는 없는거다.
그냥, 원하는 것을 찾아서 있으면 쓰고, 없으면 만들면 된다. 자연스럽게 쓰면 된다. 시스템에 의해 불필요한 행동이 늘어나는 것 만큼 짜증나는 일이 또 있으랴. Mac과 PC의 차이는 “생각대로 하면 되고”에 존재한다. “아는대로 하면 되고”가 아니다.
이럴땐 이걸 쓰고 저럴땐 저걸 쓰면 된다. 구글Docs도 혁명적으로 생각하는 사람들이 있는데, 마찬가지다. 그냥 구글Docs가 필요할때 쓰고, MS Office가 필요할때 쓰고, Open Office가 필요할때 쓰면 된다. 그 필요의 정당성에 대해서는 당연히 고민해보아야 하겠지만.
지난번의 투정을 버리고, 아이폰을 구매한 이유도 마찬가지다. 결국은 귀찮았다. WM기반의 핸드폰을 구매할 경우의 삽질, 아이팟터치를 샀을 때의 삽질을 생각해보니, 막막했다. -_-;
어떤 시스템을 사용하기 위해 필요한 Learning Curve와 사용자가 유지해야 하는 Brain Clock수가 문제인거다. 그냥, 최대한 간단하게 원하는 기능을 쓸 수 있게 해달라. 인간의 뇌는 해야할 일이 굉장히 많으므로. 
네. 그래서 아이폰 샀다구요. (아니잖아 이건!!)
사건의 발단은 VC9으로 테스팅하던 코드를 VC7.1로 포팅하면서 발생했습니다. 이상한 점은 VC7.1이 더 빠른겁니다. ?! 그것도 무려 60%정도였습니다. VC7.1은 STLPort를 사용하고 있었고, VC9은 MS에서 제공하는 녀석을 쓰고 있었지요.
일단, 코드부터 봅시다.
C++:
-
// STLPort 5.2.1 _vector.h:121
-
typedef _Tp value_type;
-
typedef value_type* pointer;
-
typedef const value_type* const_pointer;
-
typedef value_type* iterator;
-
typedef const value_type* const_iterator;
C++:
-
// MSVC 2008 vector:1886
-
// 줄바꿈은 제가 한겁니다. @_@
-
typedef _Vb_const_iterator<size_type, difference_type, _Myt>
-
const_iterator;
-
typedef _Vb_iterator<size_type, difference_type, _Myt>
-
iterator;
-
-
..(생략)..
-
-
typedef iterator pointer;
-
typedef const_iterator const_pointer;
-
typedef std::reverse_iterator<iterator>
-
reverse_iterator;
-
typedef std::reverse_iterator<const_iterator>
-
const_reverse_iterator;
두둥. iterator의 타입이 포인터가 아니라.. iterator라는 클래스로 되어 있습니다. 뿐만 아니라, pointer도 iterator클래스로 되어있습니다. 내부를 파고 들어가보니 이렇습니다.
C++:
-
// MSVC 2008: vector:114
-
// 역시 줄바꿈은 제가..
-
_Myt& operator++()
-
{ // preincrement
-
_SCL_SECURE_VALIDATE(this->_Has_container());
-
_SCL_SECURE_VALIDATE_RANGE(
-
_Myptr <((_Myvec *)(this->_Getmycont()))->_Mylast
-
);
-
-
#if _HAS_ITERATOR_DEBUGGING
-
if (
-
this->_Mycont == 0 ||
-
((_Myvec *)this->_Mycont)->_Mylast <= _Myptr
-
)
-
_DEBUG_ERROR("vector iterator not incrementable");
-
#endif /* _HAS_ITERATOR_DEBUGGING */
-
++_Myptr;
-
return (*this);
-
}
_SCL_SECURE_VALIDATE라는 Macro를 장렬하게 호출합니다. (.. ) 이 매크로는 _SECURE_SCL 매크로에 의해 제어가 가능한데, 현재 상태가 제대로 된 상태인지 검사해주는 역할을 합니다. 잘못되면 예외를 발생시킵니다. ;;
일반적으로 vector는 T*를 반복자로 사용해도 문제가 없는 스펙을 갖고 있습니다. STLPort에서 T*를 반복자로 사용하는 이유도 그렇게 써도 되기 때문이지요. (표준안이 바뀌었을지는 모르겠습니다만..) 포인터를 반복자로 사용할 수 있다는 점은 시사하는바가 큽니다. 바로, 성능문제이지요. native타입인 T*는 컴파일러가 최적화 할 수 있는 소지도 많을 뿐더러, 인라인처리가 될까 말까 고민할 필요도 없으니까요. 대신, T*를 사용하게 되면, 이를 악용하는 프로그래머의 실수와 함께, range check와 같은 디버깅 관련 기능을 추가할 수 없다는 단점이 존재합니다.
MSVC 9.0은 단점을 위해 장점을 버린 케이스라고 할 수 있겠습니다. 뭐 성능문제는 _SECURE_SCL매크로를 끄니 5%내외로 낮아지긴 했습니다만.. 왠지 찜찜하군요. 결국 STLPort를 VC9용으로 빌드해버렸습니다. STLPort도 STLP_DEBUG모드로 사용하면, 저런 range check를 해주거든요.
사실 놀랐습니다. 저런 assertion관련 기능은 Release모드에서 별도로 켜주어야 작동하는게 맞는거 같은데 말이죠. 참고로 _SECURE_SCL을 켜두면 set에서 나는 차이는 더더욱 커집니다. 아무리 CPU가 발달해서 넘쳐나는 세상이라지만, 이건 좀 심하네요. -_-
물론, 개발툴입장에서 개발자의 편의를 추구하는 것은 당연하지만, 이런류의 편의성을 채택할거면 C#이나 Java를 쓰지 누가 C++을 쓰겠습니까. -_-; 디버깅할때나 필요할 법한 기능을 Release모드에 때려박다니.. 무슨 숨은 뜻이라도 있는걸까요. 
뭐 저는 STLPort를 쓰기때문에 딱히 상관은 없습니다만.
ps1. 표준 관련 호환성은 많이 좋아지긴 한듯 합니다.
ps2. 그냥 STLPort에 투자하면 안되겠니 MS... -_-
ps3. 사고싶어요 징징.