표준 vs. 디자인: 삼성과 애플

특허의 본질은 기술의 공개와 공유이고, 그 대가로 배타적 권리를 주는 것인데, 최근의 빠른 기술발전은 배타적 권리를 이용한 기술독점으로 그 기능을 바꾸어놓았고, 이런 세태에 발맞추어 흔히 말하는 일류기업들은 엄청난 특허출원을 해댄다. 이렇다 보니, 서로 특허를 침해하는 일은 비일비재하기 마련이고, 이러면 제품을 만들 수 없게 되다보니, 특허를 서로 허용해주고, 돈을 좀 주는 정도에서 끝나는 경우가 많다. (물론 그냥 돈을 주는 경우도 있고, 소송에서 싸워 이기는 경우도 있다.)

애플과 삼성의 소송을 간단하게 정리하면 다음과 같다.

  • –재판전
  • 삼성: 인피니온에서 라이센스비 안냈으니. 애플 니가 내라.
  • 애플: (황당?! 뭐 인텔이 주겠지) 얼마면 되는데?
  • 삼성: 아이폰 1대당 2.4%내놔.
  • 애플: 뭐?!!!! (이게 미쳤나)
  • — 재판시작
  • 애플: 야. 삼성 니들이 내꺼 베꼈네?
  • 삼성: 야. 애플 니들은 로얄티 안낸거 아님?
  • 판사: 우쭈쭈. 잘 협상해서 다시 오지 마세요.
  • 삼성: 야. 애플 개당 $10 내놔.
  • 애플: 그거 내가 만든 칩셋도 아닌데 왜 그리 줘야함? 그리고, 왜 나한테만 더받음?
  • (결렬)
  • 판사: 아오. 니들 자꾸 그럴래? 함 싸워봐.
  • (양쪽 증거제출)
  • 판사: 어라 삼성이 너는 왜 증거를 늦게 제출함? 이거 쓰지마셈. 왜 늦고 난리냐?
  • (삼성이 증거공개, 즉 하지 말라는 짓을 함)
  • 판사: 야! 하지 말랬지! (이 시점에서 재판부 빡침)
  • 배심원단: 삼성이 베낀거 맞음 ㅇㅇ 애플은 죄없음.

사실 애플 입장에서는 라이센스료라는 돈문제고, 삼성은 개발과정에서의 자존심 혹은 윤리문제다. 이런 상황에서 삼성은 베꼈다는 공인인증을 받아버렸고, 애플은 돈을 챙겼으니 애플의 대승이란 평가는 당연하다. 그리고, 삼성의 스마트폰 매출에 큰 영향일 미치지 않을거다라는 분석이 많은데, 글쎄. 카피캣이란 이미지를 쉽게 벗을수 있을까? 삼성의 휴대폰 UX관련 진보가 거의 아이폰을 베끼면서 발전한 것임을 생각해볼때, 그리 쉬운 일은 아닐거다. 반면에, 삼성이 애플에 앞으로 태클을 걸 수 있을까? 아이폰4S/New iPad부터는 퀄컴칩인데? 퀄컴이 인피니온처럼 라이센스비를 안냈을까? 삼성이 LTE특허를 들먹이던데, LTE특허도 표준특허고 퀄컴과 크로스라이센싱이 되어있을테니 – 안했으면 삼성도 칩을 못만듬 – LTE특허로 애플을 때리는 건 요원해보인다.

이번 소송을 보면서 드는 생각은 이거다. 삼성은 대체 무슨 생각으로 저리 베낀거지? 마이마이의 재림인가?!

ps. 삼성이 어찌 애플을 베껴댔는지는… http://blog.naver.com/konatamoe/20165267804 매우 정리가 잘 되어있군요. ㅎ

 

내가 당신을 왜 뽑아야하죠?

다시 면접철이 다가왔다. 그리고, 면접관으로 들어가서 정말 기초적인 IT지식들을 물어보고 나서 마지막으로 내가 물어보는 것은 이거다.

” 내가 당신을 왜 뽑아야하죠? 우리 회사가 당신을 채용해야 하는 이유는 뭐죠? 열심히 하겠다는 말은 빼고 해보세요.”

기본적으로 시장주의내에서는 자신을 팔 수 있어야 하는거고, 그 시장중 가장 큰 시장이 인력시장이다. 그 인력시장에서 구매자로서 가장 원초적인 질문은 저거다. 물론, 면접의 과정을 통해서 구매의 포인트를 짚어내는 것이 면접관의 할일이긴 하지만, 면접을 보다 보면, 자신의 장점을 전혀 어필하지 못하는 사람들이 있다. 심지어, 내 눈에는 보이고 그 장점을 어필하도록 유도해도 못한다.

이건 뭐, 지금 다니는 회사가 작아서 저런 질문에 멋지게 답할 수 있는 사람이 안오는 건지.. 아니면, 정말로 저런 질문에 답할 수 있는 사람이 드문건지.. 모르겠다. 에휴.

 

Trace. Trace? Trace!

0. Trace.
원래 개발자란 족속들은 게으르고 게으르고 또 게으른 관계로 족적을 잘 남기지도 않고, 문서는 잘 쓰지도 않으며, 재미있는 개발이 끝나고 나면 한없이 늘어지기 마련이다. 이거야 뭐. 인간이란 원래 그런 족속이니까.

1. Trace?
그럼에도 불구하고, 개발자란 족속들은 언제나 족적을 남기기 마련이다. 코드에 남기기도하고, 주석에 남기기도 하고, 문서를 쓰기도 하고, 무려 코드를 저장할때마다 커밋로그라는 것도 남긴다. 사실 지금 직장에서 Subversion + 커밋로그강제스크립트를 도입한지도 어언 6년반정도 되었다. 처음에 다들 싫다고 징징거리던 것을 억지로 우겨넣어서 지금의 상태인 것인데, 커밋로그를 강제하니 뭔가 족적을 하나씩 -그나마 쓸만하게- 남기긴 한다. 다들 커밋로그가 좋다는 걸 나중에야 알게된 것이겠지.

2. Trace!
그래서 든 생각이 이런거다. ‘왜 개발자만 족적을 남기는가?’, ‘요즘같이 빠른 세상에 정중하게 하나하나 맞추어 문서를 쓰기란 뭐같이 힘든 일이니, 빠르게 족적이라도 남기면 좋지 않겠는가?’

하지만, 연구소에서나 가능한 일을 전사에 강제하기란 그리 쉬운일은 아니다. 하아.

구인-구직: 최근의 면접(관)후기.

일하면서 동료들과 농담삼아 하던 이야기가 있다.

버텨야해! 몸값은 오를꺼야!

IT를 밥줄로 먹고산지도 햇수로 12년째다. 정규직 붙밖이로 일을 시작한 것이 2004년이니 흔히 말하는 경력으로 치자면 벌써 8년차 개발자인가. 이렇게 일하면서 느끼는 사실이지만, 갈수록 같이 일할 사람을 구하는 것이 힘들다. 흔히 말하는 ‘스펙’은 신규 인력의 가능성을 간접적으로 보는데는 유용하지만, 이 스펙을 쌓느라 기본적인 지식들이나 경험이 부족한 인력들을 양산하는 주된 원인이 된다. 특히 프로그래밍은 재미를 붙이는 사람들이 필요한데, 학점을 올리고 영어점수를 신경써야하는 스펙공장에서 과연 재미를 붙일 수 있을까. 한줄의 코드가 자신의 재미가 아니라 학점의 도구가 되어버렸는데.

최근 면접을 보면서 느끼는 점이 바로 스펙의 폐해다. 이미 스펙향상의 도구가 되어버린 대학교육에서 면접자들이 배워오는 것은 점수와 이력서에 적힌 몇줄의 경력사항들. 전공에서 배웠을 가장 기초적인 것들을 물어보았을때 우물쭈물하고 가능성을 보기위해 가벼운 문제들을 내었을때 당황해하는 모습들을 보면서 참 씁쓸할 따름이었다. 그나마 순발력을 보여주는 면접자들은 다행스럽지만, 그도 보여주지 못하는 면접은 솔직히 시간낭비라는 생각이 들 정도다. 사실 여유가 많다면 왕창 뽑아서 인턴을 돌리며 테스트를 하는 것도 좋겠지만, 중소기업에서 이게 쉬운 일인가. 인턴을 몇번 받아서 일을 해보았지만, 인턴을 관리하고 일을 시키는 것도 상당한 부하를 발생시킨다. 여유가 있으면 모르겠지만, 이럴 여유가 되는 회사가 과연 얼마나 될까?

뭐. 몸값이 오르겠지. 몸은 피곤해지겠지만. 후아.

왜 개발자로 살고 있는가?

정확한 질문은 “왜 삶의 여러 지층 중 하나가 개발자인가?” 겠지요.

문득, 미사를 드리러 가려고 샤워를 하는 도중에 이런 생각이 들었습니다. 음악을 하고 그림을 그리고 글을 쓰면서 프로그래밍으로 밥을 벌어먹고 있는데, 왜 하필이면 개발자로 먹고 살고 있는가? 그냥 잘하기 때문에? 가진 능력중 가장 경제적으로 뛰어난 것은 사실이고, 실제로 경제적인 부분은 전적으로 이쪽에 의지하고 있는 것도 사실입니다. 이쯤 되니 갑자기 이건 아니다라는 생각이 들더군요. 그러면서, 아 나도 서른이구나. 7년차구나. 라는 생각도.. (퍽)

가장 감명깊었던 책제목은 (내용말구요. 제목!) Just for fun입니다. 라이너스 토발즈씨의 자서전 제목이죠. 요즘 잃고 있었던 초심이 Just for fun이었던 것 같습니다. 대부분의 개발자들이 재미로 시작하지만, 어느새 그 재미를 잃고 있는게 아닌가 싶습니다. 이런 의구심이 드는 시점임에도, 일은 재밌습니다. 문제는 일이 재밌는 것이지 일을 재밌게 만들고 있지는 않다는 점이죠. 제 초심은 일을 재밌게 만드는 것이었으니까요. 잃었던 것을 찾은 이 기쁨은 뭐… 이루 말할 수 없습니다.

재미있는 일을 더 재밌게 만드는 것. 개발자로 오래 살아남는 가장 즐거운 방법이 아닐까 생각해봅니다.

그리고, 이 곳에 오신 당신은. 왜 지금의 직업을 갖고 계십니까?

이글루스에 개설했습니다.

네. 이사간다는 이야기는 아닙니다. 정리하면서 사라졌던 분류의 글들을 쓰기 위해 공간을 하나 더 만들었습니다. 사실, 이 블로그에 쓰는 글들이 지적 허영이가득 찬 글들이기도 하거니와, 그냥 무거워진 이 공간말고, 가벼운 공간이 하나 더 필요하다는 요구와 즉흥적인 지름에 하나 더 만든겁니다. 인생 뭐 있나요.

어쩌면, 포스트의 절대적인 수로는 역전현상이 나타날지도 모르겠습니다만. 과거 블로그의 제목이 ‘Crow’s Maniacal World’이던 시절에서 Devspace@Crow로 넘어오면서 사라져버린 다른 제 자신을 적어내는 공간이니 당연한 것일지도 모릅니다.

여전히, 이 곳은 쓰던 글들과 써야할 글들이 올라옵니다. 지금 쓰고 있는 글만 3개정도 되는군요. (개요잡고 고민하는 글을 이야기하는 겁니다. 제목과 주제만으로 치면 더 많… orz) 하지만, 이 곳과 텀블러에 쓰지 않던 글들이 올라오겠지요. 워낙에 관심분야도 넓고 하는 짓도 많아서 어쩔 수 없나봅니다.

그럼. 돌아온 Crow’s Maniacal World를 소개합니다. 씨익-

Let me free: 생각대로 하면 되고.

애플에서 만든 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수가 문제인거다. 그냥, 최대한 간단하게 원하는 기능을 쓸 수 있게 해달라. 인간의 뇌는 해야할 일이 굉장히 많으므로. 🙂

네. 그래서 아이폰 샀다구요. (아니잖아 이건!!)

MSVC 2008 STL vector

사건의 발단은 VC9으로 테스팅하던 코드를 VC7.1로 포팅하면서 발생했습니다. 이상한 점은 VC7.1이 더 빠른겁니다. ?! 그것도 무려 60%정도였습니다. VC7.1은 STLPort를 사용하고 있었고, VC9은 MS에서 제공하는 녀석을 쓰고 있었지요.

일단, 코드부터 봅시다.

// 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;
// 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클래스로 되어있습니다. 내부를 파고 들어가보니 이렇습니다.


// 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); } [/cpp] _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. 사고싶어요 징징.