오늘 들은 귀동냥들을 종합해서 잠시 개인적으로 이렇게 “생각”해봤다.

• 11월 출시라면 전체적인 엔지니어링 입장에서 지금은 사용자가 사용할 수 있는 퀄리티이어야 하지 않을까. 웬만한 기능들은 개발 정지되고, 버그를 고치는 것에 집중해야한다. 소스 트리에 허가받지 않은 커밋이 쉽지 않은 단계여야 한다. 오늘 한 쑈로는 사용자가 구경도 제대로 못할 상태였다. 그렇다면 예상 되는 시나리오는 급하게 만들고 있는 개발자들의 충혈된 눈이다.
• 이대로라면 제대로 된 테스트 부서를 만들어서 경험 많은 퀄리티 전문가를 영입해야하지 않을까 한다. 그냥 시연을 본 개발자들이 한눈에 이거 퀄리티가 별로 좋지 않을 것 같다는 이야기를 할 정도라면, 뭔가 스케줄에 쫓겨 테스트보다 구현 시간이 훨씬 많았을 것 같다.
• OS는(혹은 소프트웨어는) 구현이 다가 아니다. 학자라면 논문에 쓸 구현이 중요하겠지만, 소프트웨어 개발=구현이 아니기에 다양한 전문가들이 개발에 관여한다. 게다가 이미 시연한 것보다 더 나은 OS들이 존재한다. 선택과 집중의 CrossOver Linux/Games 같은 제품도 있다. 구현이 다라는 생각부터 버려야 개발자들이 노가다로 점철돼서 쓰러지는 일이 없다.
• 더이상 기능 늘리지 말고 되려 Cut해서 날짜 맞추고, 스케줄에 맞는 개발 일정을 제대로 짜야한다. 똑똑한 개발자가 많은데 결과가 문제인 것은 올바른 매니지먼트의 부재일 가능성이 높다. 일정에 맞춰서 할 수 있다 없다를 판단하고 자르는 것은 팀장들의 역할이다. 필요하면 발표한 제품도 Cut해버리는 것도 감수할 수 있어야 한다.
• 여러가지 개발자 고생한 이야기들을 했다고 들었는데, 전체적으로 그런 마인드라면 결과는 뻔하다. 꿈에 부풀어오른 개발자에게 몸바치고 나서 남게 되는 것은 출시의 기쁨이 아니라 사용자의 불만으로 인해 기다리는 야근일 것이다. 발표도 했으니 개발자들에게 강제로 엑스트라 휴가를 주는 투자 정도는 좋지 않을까. 휴가 중이라면 그나마 다행이겠다.  (그 휴가 일수도 스케줄에 고려해서 정해야할 것이다.)
• “뭐뭐뭐 X일이면 만들 수 있다”는 절대 하지 마라. 스케줄을 탑다운으로 정하면 이꼴이다. 매번 경험하면서도 매번 이러는 이유는 뭘까?
• 뭔가 뛰어난 부분에 집중해서 좀 마케팅해라. 새로운 것이라고 광고하면서 브로셔보면 완전 구닥다리식이다. 특별한 것이 하나도 없다. 예를 들어서, 뭐뭐뭐는 다른 OS보다 x배 빠르다거나, 오류가 나면 더 잘 처리한다거나, 그래픽 시스템 설계를 잘해서 3D 데스크탑을 제공한다거나, 특별한 보안 체킹이 구현되어 더 안전하다거나…아무튼 뭔가 다른게 “한개”도 없다.
• 호환성에 집중했다고 들었는데, 몇가지 응용프로그램을 가지고 호환성 테스트를 했을까. 최소한 호환성 테스트를 위한 Lab하나 정도는 있으리라 믿는다. 잘된다 가정해도 이 호환성은 분명 발목을 잡을 것이다. 티맥스에서 된다고 하는 소프트웨어만 쓰라고 사용자에게 이야기한다면 거짓말 한 격일테니.
• 수많은 디바이스들의 드라이버에 대한 대책도 설마 있으리라 생각되고. (여기서 OS 업체는 한번 좌절한다.)
• 빵빵한 법무팀은 있으리라 생각되고. 그냥 잠깐 생각해봐도 예상되는 이슈 목록만도 기다랗다.
• 투자를 4년(?)이나 했다고 했으니 OS 비즈니스를 우습게 본 것은 아니라 생각된다. 문제는 투자 대비 효과(ROI)인데, “투자를 많이 했으니까 좀 봐주라”식이라면 “투자를 많이하고도 이러냐”일테니 그것이 아니라 다음 버젼에는 훨씬 더 나은 ROI를 할 수 있도록 발전했으면 좋겠다. OS 개발이 얼마나 어려운 것인지를 체험했으니, 메이저 OS를 만드는 회사들이 얼마나 대단한 엔지니어링을 하는지 알 것이다. 유치하게 씹으면서 누워 침뱉지 않았으면 좋겠다.
• (추가) 이것이 우리나라 소프트웨어 산업과 무슨 상관인지 제대로 설명해줬으면 좋겠다. 개발자들은 개발해봐야 Windows 응용프로그램이기에 의존성은 그대로다. 사용자들이 티맥스윈도우를 사봐야 티맥스 배불리는 것이지 소프트웨어 산업에 어떤 영향이 갈 수 있는 장치에 대해 설명이 없다. 개발자는 계속 야근이고 똑같은 대우이고, 달라질 근거가 없다. 뭘 가지고 이야기하는걸까.

다시한번, 개인적인 생각이다. (민감한 부분들은 지워버렸다.)

언제나 그렇다. 3년차 쯤 되면, 혹은 5~6년차 쯤 되면, 혹은 10년차 쯤 되면, 20년차 쯤 되면…유명세를 좀 타면, 인정 조금 받기 시작하면…하여튼 이럴 때 쯤이면 자신이 뭔가 조금 더 좋은 입지를 가지게 되었다고 생각하게 된다. 레벨업이 몸으로 느껴지는 것 같고, 뭔가 다른 사람들의 대접도 이전보다 조금 더 달라진 것 같다. 지금까지 노력해온 것들이 조금씩 빛을 발휘하기도 하고, 나보다 쥬니어인 사람들한테 뭔가를 전수해주고 조언해줄 꺼리들이 생긴다. 노하우도 있는 것 같고, 누가 뭔가 물어보면 신기하게도 척척 대답이 술술 나온다. RPG게임 같은 것에 비유하면 경험치가 쌓이고 렙업(레벨업)을 하게 되는 상황이리라.

게임에서야 렙업에 대한 구분이 숫자로 확연하지만, 사람이란 그렇게 어느 순간 띠리링하고 업그레이드 되는 일은 흔치 않(거나 없)다. 그래서 현실에서 렙업을 하면서 가장 버려야할 익숙해져 있는 습관이 렙업(렙업 기간) 전후의 자세에 대한 것들이다. 렙업 전에는 같은 렙들 사이에서 시니어겠지만, 렙업을 하면 자신과 비슷한 레벨의 캐릭과 경쟁을 해야지, 낮은 레벨을 킬하면서 희열을 느끼는 것은 찌질한 그리고 도움이 별로 안되는 것일터인데, 자신의 렙업으로 인한 변화를 (익숙해져 있는 습관에 묻혀) 수용하지 못하고 있는 것이다. 쉽게 이야기하면 같은 레벨들 사이에서는 이제 갓 렙업을 한 초짜라는 말이다. 레벨이 이정도 되었는데 다시 초짜라니…익숙하지 않을 것이겠지만, 그 레벨이 만렙이라면 모를까 다음 레벨로 더 빠르고 쉽게 가기 위해서는 자신이 다시 초짜가 되었음을 인지해야하는 것이 자신에게 엄청나게 큰 도움이 된다.

게다가, 현실에서는 상대방의 레벨은 커녕 경험치를 볼 수도 없기 때문에, 자신의 레벨을 기준으로 상대방을 가늠하게 된다. 렙업 직전의 습관을 그대로 가지고 있다면 이런 것을 가늠하는 판단력은 꽤나 흐려져있을 가능성이 크다. 대부분 내가 어떤 어드밴티지를 느끼고 있는 상황에서의 인간은 우습게도 그 어드밴티지가 전체 그림에서 얼마나 작은 것인가를 생각하지 않고 어드밴티지에 집착한다. 혹은 모르는 상대라면, “모른다고” 가정해야지 모른다고 “경험치가 낮을 것이라고” 은연중에 가정한다. 망신당하는 케이스도 많이 본다.

항상 초심으로 돌아가자는 따분한 이야기가 아니라, 진실이 렙업때마다 초짜라는 것이다. 큰물에 가고 싶은 것이 아니고 그냥 거기서 편하게 낮은 렙들과 같이 살고자 한다면 그거야 할 수 없는 일일테다. 또, 인간의 속성이 그런 면이 없지 않다(혹은 많을지도). 그 정도는 자신이 판단할 일이겠다. 인생에 만렙이 있는지는 모르겠다. 경험치는 쌓이지만 더이상 렙업이 없는 상태. 그런 경지는 되어봐야 알겠지. 하지만, 그런 바라보며 향할 곳이 있다면 다음 렙업을 위해서 렙업을 했다고 생각되더라도 자신이 어디에 위치한 것인가 정도는 점검하며 사는 것이 좋지 않을까 하고 생각해본다.

오늘은 나에게 또하나의 중요한 날이다. 미국 전근 오퍼(Transfer Offer)를 받아들이기로 한 날이기 때문이다. 그동안 한달여에 걸친 수많은 고민 끝에 정리하는 그런 결정이기에 마음이 가뿐하다. 전근 오퍼는 받았지만, 선뜻 여러가지 이유로 받아들이는데 시간이 걸렸던 것이다.

혹자는, 미국으로 쉽게 전근 갈 기회인데 왜 그걸 고민하느냐는 이야기도 많았다. 하지만, 첫째로 기회는 나중에 만들 수도 있고, 둘째로 – 당연하지만 – 미국에 가는 것이 무조건 좋을 것이라 생각하는 것은 우스운 일이다. 무엇이 되었건 결정적으로 타이밍이 맞아야하고, 그렇지 못하면 좋아도 빛좋은 개살구이고 무리해서 후회하기 쉽상인 것이다. 문제는 후회를 하게 되더라도 그만한 가치가 있는 결정이냐는 것인데, 여기서 확신이 들지 않았었다.

더 넓은 곳에서 더 많은 경험을 하기 위해서라고는 해도 이곳에서의 안정된 생활을 뒤로한 채 무엇이 기다리고 있을지 모르는 곳에 혼자 덩그러니 놓여지게 되는 상황은 아무래도 불편하긴 할 것이다. 업계 14년간 우리나라에서 이뤄 놓은 것들을 그대로 가지고 가는 것도 아니고 대부분 버리고 가는 것일게도. 일은 그렇다 치더라도 다양한 문화가 모여있는 그런 근무 환경에서는 지금은 적당해보일 수 있는 내 행동이 정당화되기도 힘들 것이다. 먹고 자고 마시고 싸고 놀고 아프고 하는 모든 것들을 새로 적응(adjust)해야하는 것도 있을 것이다.

하지만, 그런 것들은 사실 그렇게 큰 변수는 아니었다. 난 언제나 새로운 것에 목말라 있고, 새로운 것을 좋아하는 말하자면, 쌔삥홀릭이거든. 그보다 현재 개인적으로 처한 상황이 가장 큰 문제였다. 가족들과 이곳에 덩굴처럼 얼기설기 엮어져 있는 복잡한 상황말이다. 이런 것들을 뒤로 한채 떠나는 일에 대한 가치를 생각해보면 선뜻 결정은 쉽지가 않았던 것이었다. 계획으로도 내년 이후에 생각해보겠다는 상황이었고 (마음의) 준비도 되지 않은 상황이기도 하고.

이런 것들을 뒤로 하게 되는 것과 여러가지를 재기 시작한다. 나에게 얼마나 많은 기회가 열려 있을까. 얼마나 많은 세월을 희생해야 어느정도 궤도에 오르게 될까. 적응하지 못하고 온대도 그만한 값어치가 있을까. 무엇을 바라보고 가게 되는 것일까. 저런 질문에 답이 있기는 한 것일까. 툭하면 하는 이야기, 우리 세대는 백살까지 살 확률이 높고 그렇게 보면 아직 먼 인생, 몇년의 도전 정도는 해볼만 한 것이지 않을까.

답은 없다. 실행하거나 실행하지 않거나 실행하지 못하거나다. 실행해서 증명하거나 그냥 영원히 모를 일로 남기는 것이다. 뻔한 이야기라고 해도, 해보지 않고 후회하느니 해보고 후회해봐도 되는 일이지 않겠느냐는 조언은 참 좋은 것이었다. 내가 살면서 추억은 해도, 후회를 한 적이 있던가. 아직은 그냥 앞만보고 가도 되는 나이이긴 하다.

이제 결정은 내렸다. 잡생각은 쓸모 없을 뿐이고, 결정에 대해 책임을 지는 일만 남았다. 오늘은 중요한 날이고, 지난 한달의 쓸데 없이 머리빠지는 고민을 잊는 날이다. 잘돼서 말뚝박거나 금의환향할 날만을 바라본다.

포스팅 안하다가 이런 포스트 적는게 조금 그렇지만, 요즘 국내 블로그계 뜨거운 감자인듯한 건에 물타서 짧은 ActiveX 포스트 하나.

매년 ActiveX를 두고 “똑같은” 잘못된 이야기들을 지적해왔기에 그 글을 구글의 힘을 빌어 링크한다: http://www.google.com/search?ie=UTF-8&q=site:http://charlz.wordpress.com/+activex

ActiveX이외의 다른 것은 이야기하고 싶지 않고, ActiveX에 대한 Fact만 보시면 좋겠다. 아울러 ActiveX에 대한 Fact들을 시간이 또 지났다고 똑같이 전처럼 잘못 이야기하되지 않았으면 좋겠다.

더 긴 이야기이자 Disclosure: 비록 이 블로그는 회사를 대변하지도 않고 나 개인이 좋다는 것을 적기는 하지만, 난 ActiveX라는 마케팅 용어를 만든 회사의 직원이다(그러나 그 기술이나 과정을 만드는데는 전혀 관여하지 않았고, 당시에는 직원이 아니었다). 회사의 의견에 동의하는 내용(기술 자랑 등)도 있고 동의하지 않는 내용도 있지만, 동의하는 경우에 당연히 “넌 직원이니까 그런거지”라는 비난을 받기 쉬운 위치다. 하지만, Fact는 직원이 이야기했다고 귀를 막더라도 Fact다. 필요하다면 Fact가 아닌 의견은 이 Disclosure를 생각하고 판단/이해하시면 될 듯 하다. (전에 밝히지 않았다고 – 여기저기 밝혔지만 글마다 적혀있지는 않다 – 불쾌한 경험을 겪었었기에 언급한다.)

오늘 MIX 09 행사가 시작되면서 여러가지 기술들이 발표되고 있는 와중에…네, 드디어, Silverlight 3 소식입니다. MIX의 129개 세션 중에서 가장 많은 31개의 세션이 Silverlight에 할당되어 있을 정도로 Silverlight는 여전히 집중 과목입니다(국내 HugeFlow 분들이 진행하는 MIX09-T35F 세션도 있네요). Silverlight 2의 점유율도 국내 유저분들이 체감하는 것보다 훨씬 더 높기도 하지만, 이런 내용은 마케팅 분들게 맡기고…

재미난 것은(항상 하는 이야기지만;) Silverlight 1.0이 나온지 1년 반밖에 되지 않았다는 것입니다. Silverlight 1.0이 출시되고, 1.1이 공개되고, 1.1이라는 버젼으로는 설명이 안되기에 Silverlight 2라는 브랜드를 가지고 나왔고, 6개월만에 Silverlight 3의 베타버젼이 공개되었다는 것이죠. 3번째 버젼이 되면 항상 어떤 상황이든 하는 말이 드디어 쓸만해진 제품이 되었다는 말이겠습니다만, 이는 이전의 이야기고, Silverlight은 2부터 쓸만해졌고, 3부터 더욱 파워플 해졌습니다.

처음 계획 단계에서의 이번 업그레이드의 주요 골자는 사실 – 이미 공개해버린 H264/AAC 지원 이외에 – 2번째 버젼에서의 문제점들과 사용자들이 가장 많이 요구하고 불만으로 생각하는 기능들을 수집해서 이를 해결하는 것이었습니다. 문제는 이미 RIA 계의 경쟁자인 Adobe에서 사용자들의 입맛을 굉장히 까다롭게 혹은 좋게 이야기하면 높은 수준으로 만들었다는데 있었습니다. Flash와는 같은 분류에 속하게 되었다고는 해도 방식은 상당히 다름에도 불구하고 사용자분들의 요구는 “Flash/Flex에서는 이게 되는데 여기서는 왜 안돼냐”였습니다. 그렇다고 해서 Flash/Flex에서 지원한다고 무조건 비슷하게 만드는 것은 안될말이고, 최소한 사용자분들이 가장 목소리를 내는 부분에 있어서 높은 우선순위를 두고 버젼업에 박차를 가했습니다.

Silverlight 3의 여러가지 고민들 중 다른 큰 것 한가지는 빠른 버젼업으로 인하여 하위 호환성을 해치는 일이 없도록 하는 것이었습니다. Silverlight 2로 응용프로그램을 막 만들고 있는데 갑자기 Silverlight 3이 나와서 안되더라…하는 이야기가 나오면, 누가 개발을 하겠냐는 이야기죠. 이는 사실 WPF와의 호환성을 유지하는 것(WPF는 다음 버젼의 개발과 함께 또 저멀리 앞서 가고 있죠)과는 충돌이 있는 부분이기도 합니다만, 우선순위는 무조건 Silverlight 2와의 하위 호환성으로 정했습니다. 충돌이 있는 WPF와의 호환은 대체가 아닌 추가를 통해서 이뤄지도록 했구요. 일단 베타 버젼이기 때문에 Silverlight 2와 문제가 전혀 없을 것이라고 할 수 없지만, 문제가 발견된다면 무조건 Silverlight 3 정식 버젼에서는 해결을 하는 것이 큰 우선순위입니다. 언제나 그렇듯 Silverlight 3와 병행하여 개발되고 있는 관련 제품들이 여러가지가 있습니다. 모두들 아시는 IE8와 Windows 7이 대표적인데, 이들과의 호환성 테스트 기간도 물론 있었습니다.

1년내에 최대한 처리할 수 있는 이슈들을 모두 스케줄에 넣을 수 있는 한 넣고, 퀄리티를 맞추기 위해서 매주 바뀌는 테스트 스케줄을 감당하면서 베타버젼을 출시하기에 이르른 것이죠. 여러 기능들이 테스트할 시간이 없기 때문에 잘려나간 것을 생각하면 스케줄 때문에 안타까워하실 개발자분들이 있으리라 생각됩니다. 아무튼 그러다보니, 버젼 1.1처럼 Silverlight 3 이전에 2.5였다가 큰 기능들을 .5 버젼으로 커버하기보다는 메이저 업그레이드로 보는 것이 맞기에 3로 바뀌었습니다.

이번 Silverlight 3 베타버젼 공개에 관련된 다양한 제품들은 다음과 같습니다:

• Silverlight 3 Developer Runtime(Beta) (Windows, Mac) – 이번 베타버젼에는 User Runtime이 배포되지 않습니다. 즉 Go Live 라이센스를 제공하지 않고, 개발자분들이 사용해볼 수 있도록 개발자 런타임만을 제공합니다.
• Silverlight 3 SDK(Beta) – SDK에는 이전의 내용들 이외에 다음이 부가적으로 포함됩니다:
• Silverlight Toolkit Update – 새로운 컨트롤들이 소스와 함께 왕창 추가됩니다.
• Silverlight 3 Tools(Beta) – Silverlight 3를 지원하는 내용 이외에 이전 버젼과는 크게 달라진 점은 없습니다.(v2 프로젝트는 지원이 안됩니다.주의요.)
• Expression Blend 3 Preview – Silverlight 3의 지원 이외에 수많은 향상과 새 기능들이 포함되었습니다. 무엇보다 눈에 띄는 점은(전에 답답했던 관계로)…UI가 좀 더 유연해진 점?
• .NET RIA Services(Preview) – LOB 시장을 위해서 준비하던 Framework.
• IIS Media Services Extension 발표
• Silverilght 3 베타용 MSDN 문서와 CHM 문서 – 이전에 SDK에 있던 문서들이 제거되고 MSDN에서 읽거나 별도로 다운로드 받을 수 있습니다.

Silverlight 3는 간략하게 다음의 새로운 기능들을 포함합니다:

• Media – H.264/AAC 지원. Smooth Streaming(Adaptive Streaming), 써드파티 코덱 제작 가능, Silverlight PlayReady DRM, Fullscreen시 GPU Accel, Client logging.
• Rich Graphics – Perspective 3D, Pixel Shader, Writable Bitmap, Cached Composition, Custom Easing, Image 크기 미리보기, 테마 스위칭, 폰트 지원 강화, Style Composition.
• New Controls과 기능들 – TreeView나 MultiSelect ListBox등의 다양한 새 Control들, Deep Linking 지원, Data Validation, Data Forms, Element to Element Binding, Business objects 지원.
• Out-of-Browser 경험 지원 – 온라인 Silverlight 응용프로그램을 오프라인으로 캐싱하여 실행 가능.
• 기타 – Save As 기능, 압축 알고리즘 변경(약 20%향상), .NET Assembly caching(중복 바이너리 별도 다운로드), Accessibility 향상, Local Connection, Binary XML 지원, DeepZoom 향상, 오프라인 이벤트, 등등등등

(이번 베타 버젼은 안타깝게도 영어 이외에 일본어로만 번역이 되었고 제품들의 한글 버젼은 나오지 않습니다.)

이외에도 Silverlight용 Virtual Earth Control이나 WWT(World Wide Telescope) Silverlight 버젼 등의 Silverlight 2에 관한 소식도 있었습니다.

더 자세한 소식은 에반겔리온분들이 지속적으로 블로깅하시리라 믿슈미다~

(cross posted to my msdn blog)

Silverlight 관련 일만 하다가 보니까 본업이었던 Visual Studio에 문외한이 되어가는 듯…ㅜ,.ㅜ;

art.oriented  지금까지 작성한 코드는 총 몇 줄

gimmesilver’s blog  경험이 우리에게 주는 것

art.oriented  경험은 당연히 중요합니다

Random thoughts:

• “경험이 많다.”는 말은 사실 문맥에 따라 엄청나게 다른 말이지 싶습니다만, 아무튼 경험이 중요하다는 말에는 모두가 이견은 없는 것 같습니다. 저도 경험이라는 것은 분명 중요한 것이라 생각합니다.
• 경험(시간)과 실력의 비례 관계는 n이냐 로그n이냐 혹은 무엇이냐는 이야기로 비유 하기가 힘들다 생각합니다. “경험치”처럼 한 수치로 두는 것은 RPG 겜의 이야기지, 현실에서는 확률의 이야기에 되려 가깝지 않을까 생각됩니다. 통념상 일단 “어떤 경험”을 했을 경우, 그것에 좀 더 실력이 있을 가능성이 크다는 확률을 가정한 뒤에(서류) 면접에서 이를 걸러낼 수 있느냐는 싸움을 하게 되는 것이겠죠. 솔직히 5년차 개발자나 10년차 개발자나 얼마든지 또이또이 할 수도 있는 것이고, 혹은 시간이 지날수록 실력이 일취월장하는 개발자도 얼마든지 있지 않을까요.
• “약간 의미 전달이…제 경험에서 나온 말입니다.”(object님)에서 두가지
• “자신이 실수했다고 생각했지만 사실 그건 능력이 부족한 것이죠.” – 이것은 문장상 인과관계가 없어서 요지가 좀 이해가 안갑니다. 실수일 수도 있고 능력이 부족한 것일 수도 있을 것일텐데 왜 능력이 부족한 것일까요.
• 회사에서는 사람을 줄세워놓고 상위 10%, 1%, 0.1% 이렇게 나누기가 힘듭니다. 학교에서야 석차가 나오니까 0.01%가 되는 것이 불가능하(할 수 있)겠지만, 회사에서는 포커스된 능력과 운이면 0.01%에 준하는 댓가를 얼마든지 이룰 수 있고 그 사람이 전에 0.01%는 커녕 10%에도 못든 사람일 수 있습니다. 그리고 그런 것이 실력으로 대응되기도 하죠. 회사에서 실력 좋은 개발자 탑10안에 든다, 혹은 xx계에서 알아주는 개발자…식이라면 가능하겠습니다.
• object님의 구글 예처럼 “신입 개발자”로 제한하는 경우에는 말씀대로 사실 경험이라는 요소를 가장 큰 것으로 치지 않습니다. 하지만 간단하게 예를 들어 코덱을 짜는 역할에 10년동안 비디오 코덱만 짜던 친구와 10년동안 다양한 경험을 한 친구 둘을 놓고 본다면(서류상), 전자가 아무래도 눈에 더 들어오겠죠. 회사가 10년동안 다양한 경험을 한 친구가 뭔가 틀에 벗어나는 멋진 결과를 내놓을 수도 있는 등의 리스크를 떠안겠느냐는 이야기는 다른 이야기겠지요.
• 비슷한 이야기로, 지금 당장 어떤 일을 시켜야하는데, 해본 적이 없고 잘할 능력의 개발자를 뽑을리는 만무합니다. 혹은 Hiring Manager는 최고의 인재로 보이더라도 역할에 과하다면 뽑지 못하고 맞춰서 뽑게 됩니다. 회사생활 1년차 프로그래머와 경력자와는 뽑는 사람의 눈에는 분명 다릅니다.
• 1년차 3년차 10년차 15년차(숫자보다는 늘어난 경험의 양을 생각하면), 똑같은 것을 하더라도 각자 모두가 경험을 통해서 다시 얻을 수 있는 것은 상당히 다릅니다. 간단히 10년차(경력자)가 1년차(비경력자)때 한 것을 다시 봤더니 새로운 점들이 마구 보인다더라하는 이야기는 흔하죠. 사실 굳이 10년이 아니라도 프로젝트가 끝나고 다시 리뷰를 하더라도 똑같습니다.
• 그리고 그런 경험에 따라서 나중에 시니어개발자, 데브매니저나 혹은 아키텍트등의 다른 경험의 직책을 가질 수 있습니다. 서로 막 쉽게 바꿔가면서 오갈 수 있는 직책은 아니라 생각됩니다.
• “아닙니다! 어쩔 수 없다라고 생각하는 바로 그 일이 원래 지금 하고 있는 그 일의 본질입니다.”(agbird님) – 공감합니다. 어딜가나 스케줄의 압박은 어쩔 수 없습니다. 회사의 개발자에게 있어서 “x일동안 xx를 만드시오.”라는 사명은 완벽한 제품을 만들라는 것이 아니기에 삼일을 주던 일주일을 주던 거기에 맞는 코드를 생산해는 역할입니다. 어떤 회사에서 진짜 코딩 잘한 제품(이 무엇인지 모르겠지만)이 시간을 많이 줬기 때문에 나온 결과물이라고 생각치는 않습니다. 제품을 만들어서 사용자에게서 소스코드의 예술성에 따라서 가격을 받을 수만 있다면야, 자기 돈 들여서 예술적인 코드를 충분한 시간을 들여서 만드는 직종도 생기고 하겠지만 말이죠. (다만 문제라면, 삼일이 아닌 불가능한 하루를 주는 경우겠지만, 이는 논지에서 벗어나는 다른 이야기겠죠.)
• “코딩”만을 잘해서는 30년후에도 비슷한 모습일 수도 있겠습니다만, “개발(development)”을 잘하는 경우는 다른 말이겠죠. 개발을 잘한다는 말도 굉장히 광의의 말이겠지만요.
• 삽질을 백만번하면 웬만한 포크레인 수준(agbird님)이겠지만, 똑같은 코딩을 백만줄하면 복사기일 수도 있겠습니다.^^ (Copy&Paste 코딩을 하는 개발자 수도 없이 많죠.) 저도 object님의 이야기처럼 “코딩을 몇줄해봤어”라는 질문은 가쉽이지 실력/경험의 가늠자는 아니라고 생각됩니다. 이유는 좀 다른데, 수많은 경험의 무게를 상상하기에는 부족한 질문이기 때문이죠. 이어지는 질문이 제대로 되었다면야^^

이런 이야기를 많이 합니다. “나 저거 얼마든지 만들 자신 있는데.” “저건 나도 만들겠다.” 예 할 수 있죠. 의심 안합니다. 하지만, 만들 수 있다는 것이 중요한 것이 아니라 “개발”이라는 것은 엔지니어링에 관한 이야기라는 점입니다. 엔지니어링에 있어서 축적된 경험이라는 것은 굳이 소프트웨어에 있어서만이 아니라 전반에 있어서 엄청나게 중요한 것이구요.

잘못 알려진 디자인 패턴의 두번째 원칙 « arload – load to architect

의외로 일반론에서 답을 얻는 것이 더 이해하기 쉬울 수 있다는 생각을 해봤고, 댓글하나 급 적어봅니다.

–

인간이 수용할 수 있는 복잡성에는 한계가 있다. 그 한계는 관점에 따라서 다양한 편차를 보인다. 감성과 같은 복잡성은 컴퓨터가 인간을 따라올 수가 없다. 하지만, 반대로 컴퓨터는 연산장치지만 인간의 뇌는 연산장치가 아니다. 보통 사람이 암산으로 처리할 수 있는 연산의 한계는 컴퓨터의 그것에 비하면 아주 초라하다. 정확성을 요구하는 연산과 같은 관점에서는 인간이 수용할 수 있는 복잡성의 한계치는 아주 낮다. 어느 시점에서 컴퓨터의 지능이 인간의 지능을 뛰어넘게 되는 Singularity(특이점)이 발생한다고들 하지만, 이는 감성의 복잡성을 뛰어넘는 지점을 이야기하는 것은 아닐 것이다.

우리의 몸은 우리가 사는 이런 한계를 보이는 물리적인 세상에 적응/순응된 상태로 존재한다. 때로는 몸은 새로운 도구에 적응하고, 반대로 몸을 보조하기 위해서 도구가 만들어지고, 이렇게 펜듈럼처럼 왔다 갔다 한다. 마샬맥루한이 주장했던 것처럼 모든게 몸의 확장(Extension)이자, 칼세이건이 주장했던 것처럼 사는데 필요한 방향으로 우리의 뇌가 진화해 온 것이다. 팔이 필요에 의해서 4개가 되는 등의 급진적인 변화는 아니지만, 파충류의 뇌에서 언어를 사용할 수 있는 뇌로 자라온 진화(혹은 적응)말이다. 혹은 작게는 문자메시지를 보내는데 어려움이 없는 세대와 있는 세대간의 적응 말이다.

인간은 영적인 존재가 아니다. 텔레파시로 교신하고, 텔레포트하는 존재가 아니다. 물리적인 세상과 아주 가깝게 엮여서 익숙해져 있기 때문에 상상력의 나래를 펼쳐서 기가차게 멋진 것을 구상해도 이 물리적인 한계에 부합하지 않으면 실패하기 쉬울 수 밖에 없다. 아무도 이해하지 못하는 세기를 뛰어넘는 생각을 하는 사람을 천재로 분류하지만, 근대에는 이 물리적인 세상과 타협할 수 있는 새로운 변화를 캐치하는 사람도 천재로 분류하기도 한다. 사람을 연구하는 학문들이 다양한 과학기술과 융합하는 것은 점차 흔한 현상이 되어가고 있는 점도 인간의 물리적인 한계를 접목하는 트렌드와 상관이 없다 할 수 없을 것이다.

서론이 좀 뜬금없었을지 모르지만, 요는 사람이 이해하기 위해서는 물리적인 현실에 가까운 복잡성으로 관리되는 방향이 좀 더 현실적인 방향이라는 것이다.

프로그래밍의 OO(Object Oriented, 객체지향)의 역사에 있어서 클래스 상속(Inheritance)이 예상보다 선전하지 못하고(overrated) 컴포넌트라는 가지치기를 하게 된 이유도 이런 복잡성에 기인할 것이라 생각된다. 컴포넌트라고 하는 “결과가 immutable한 엔티티”를 사용하는 것은 설계시의 계약(Contract)을 통해 만든, 물리적으로 우리가 사용하는 (프로토타입을 포함하는) 부품을 대변한다. 현실에서는 설계시에 상속의 속성을 사용할지언정 물리적인 부품들을 모핑(Morphing)하는 것은 불가능하고, 대체(Replace/Reuse)를 한다. 즉 부품을 갈아끼운다는 이야기다. 부품을 갈아끼우는 것과 비현실 속에서 모양을 마구 바꿔대는 것과의 복잡성의 차이는 꽤 크다. 최소한 일반적인 종사자들이라도 이해하기 쉬운 것이 아니란 것이다. 아버지가 바뀌었다고 자식이 바로 바뀌는 것은 물리적인 현실의 이야기가 아니란 것이다. 그것이 가능했다면 사람들이 이해하는 것이 더 쉬웠고 복잡성을 관리하는 것에도 문제가 없지 않았을까. 한마디로 다양한 복잡성은 물리적인 현실과 가까울수록 관리가 쉬워진다는 것.

초기 OO의 복잡성을 그나마 간직한 C++을 일반 프로그래머들이 제대로 활용하지 못하는 것도 그런 연장선상에 있을 것이다. 이런 저런 예외 상황과 장치와 테두리(규칙)을 만들어서 상속의 복잡성을 관리(Managing)하려고 한 시도들은 이런 것을 배우는 사람에게 있어서 장벽이 될 수 밖에 없지 않을까. 물론 잘 관리된 진화로 훌륭한 언어임에는 틀림 없지만 말이다. (물론 계속 진화하면서 Best Practice를 만들어가면서 사람들의 수준을 높이고 있기 때문에 점차 장벽은 낮아진다고 할 수 있겠다.) 그러니 현실에서는 (이해하기 힘들거나 복잡할 수 있는) 상속을 활용하는 것이 필요한 부분은 이를 이해하고 사용하는 일부 전문가들에게 맡기고 거기서 나온 결과물(프레임웍, 제품, 컴포넌트)를 사용하는 방향으로 권장을 하는 것이라 생각된다. 상속을 잘못 사용하여 벌받는(문제가 생기는) 경우가 조합(Composition)을 잘못 사용하여 벌받는 것보다 아마도 페널티가 많을 확률이 높을 것이란 의미로 말이다.

초보 개발자들이 인스턴스(Instance)라는 개념이 확고히 머릿속에 들어가기 위해서 무단한 노력을 해야되는 것도 물리적인 현실에 있어서는 인스턴스와 객체는 다른 것이 아니기 때문일 것이다. 혹은, 다중 상속은 정말 필요한 경우가 아니면 되도록이면 사용하지 말라고 권장했던 조언들도 물리적인 현실과는 사뭇 다른 그 복잡성을 이해하지 못하면 쓰지 말라는 말일게다. 복잡성만 놓고 보면, 이전 EJB vs POJO의 도래도, 너무 다양해진/맹신되는 패턴에 대한 저항도, 혹은 더 넓게 나아가 애자일이라는 움직임도, 다수가 모두 수용하고 교신할 수 있는 복잡성의 정도가 한계에 다다르면 저항이 생기는 그런 예일 것이다.

여하튼 상속은 최대한 그 복잡성을 관리할 수 있는 한도내에서 사용하도록 진화했고 계속 진화하고 있다. 전에 이해하던 방식의 틀을 벗어나는 복잡성이라면 혼자 이해하면 되는 경우라면 상관 없지만 여러 사람들이 사용하는 어떤 것을 만들고 있는 경우라면(이 시대에는 다수의 경우겠지), 이해에 도움이 되는 방향으로 프로그래밍을 하는 것으로 권장을 하는 것은 당연한 것이지 않을까?

…하는 생각.

내가 마련한 무식한 올해 계획이다.

• 악기하나.
• 수학공부재개.
• 프로그래밍언어2개.
• 그림(스케칭)연습재개.
• Tactile문화생활.
• 독서집중력향상.
• 제2외국어재개.
• 스터디2개이상참여.
• 이외의개인적인몇가지목표상향조정.

완전 지키지도 못할 막무가내군. 내년의 나이와 내가 계획한 30대의 성취율에 맞추려면 이런 계획일 수 밖에. 보이즈 비 앰비셔스!

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html

이 논문에 나온 “철지난 기존 지식(Outdated Conventional Wisdom)”들을 옮겨본다:

• 전원은 공짜지만, 트랜지스터는 비싸다.
  New – “파워 장벽(Power Wall)”. 공급할 수 있는 전원보다 많은 트랜지스터를 집적할 수 있다.
• 전원에 대해서 걱정할 것은 동적 전원(Dynamic Power)이다.
  New – PC나 서버에서 샐 수 있는 정적 전원(Static Power)는 40%나 된다.
• 실리콘 Monolithic 유니프로세서는 내부적으로 안정적이고 문제는 핀에서 온다.
  New – 칩의 집적도가 65nm 이하가 되면서 높은 소프트/하드 에러율이 발생할 것이다.
• 기존 성공 위에 새로운 추상화를 얹어서 하드위어 디자인의 크기를 증가시킬 수 있다.
  New – Wire delay, noise, cross coupling (capacitive and inductive),
  manufacturing variability, reliability, clock jitter, design validation등등으로 65nm이하의 큰 디자인의 개발시간과 비용이 커지게 된다.
• 연구자(Researcher)들은 칩을 만들어서 새로운 아키텍쳐를 시연한다.
  New – 65nm이하의 공정 마스크의 비용, 이런 칩 디자인을 위한 설계(eCAD) 소프트웨어의 비용 그리고 GHz 클럭을 위한 디자인 비용등으로 인해 연구자들은 더이상 믿을만한 프로토타입을 만들기 힘들어졌다. 아키텍쳐를 시험해볼 새로운 접근이 개발되어야 한다.
• 퍼포먼스 향상은 낮은 레이턴시(latency)와 높은 대역폭(bandwidth)를 가져온다.
  New – 많은 기술들에 있어서 대역폭은 최소한 레이턴시(latency) 향상의 제곱 이상 향상된다.
• 곱셈연산(multiply)는 느리고, 적재(load)/저장(store)은 빠르다.
  New – “메모리 장벽(Memory Wall)”. load/store는 느리고 multiply는 빠르다. 모던 마이크로프로세서에서 DRAM 접근은 200클럭까지 걸릴 수도 있지만 부동소수점(floating-point) 곱셈 연산은 4클럭이면 된다.
• 컴파일러와 아키텍쳐 이노베이션으로 ILP(instruction level parallelism, 연산 레빌 병렬성)을 높일 수 있다. (branch prediction, out-of-order execution, speculation, Very Long instruction Word system사용 등)
  New – “ILP 장벽”. 더 많은 ILP를 찾는게 점차 힘들어지고 있다.
• 유니프로세서의 퍼포먼스는 18개월마다 2배가 된다. (무어의 법칙은 유니프로세서는 아님)
  New – “전원 장벽”+”메모리 장벽”+”ILP 장벽”=막다른길. 1986년부터 2002년까지는 18개월마다 2배가 되었지만, 이제는 유니프로세서가 2배가 되기위해서 5년이나 걸릴 수 있다.
• 병렬화할 필요 없이 좀 기다리면 결국 컴퓨터가 빨라져서 병렬화할 필요가 없어진다
  New – 직렬 컴퓨터의 속도 향상은 길어지고 있다.
• 프로세서의 퍼포먼스를 향상시키는 가장 좋은 방법은 클럭주파수를 늘리는 것이다.
  New – 병렬성을 늘리는 것이 프로세서 퍼포먼스를 향상시키는 가장 좋은 방법이다.
• 멀티프로세스 응용프로그램의 선형 스케일링 이하는 실패 요소다
  New – 병렬 컴퓨팅으로의 이전한다면, 병렬성을 사용한 속도 향상은 성공 요소이다.

2006년 논문이지만, 그래도 생각할 꺼리는 흡족할만큼 있다. 일부는 최근 논문을 찾아보고 Revise해봐야겠다.

2005년의 이런 글이 있긴 하지만, 소프트웨어에 있어서 병렬성의 잠재성은 아직도 걸음마 수준이고 새로운 패러다임을 찾고 있는 알파상태다. 병렬성이 이런 이유는 그 복잡성 더하기 예측불가의 불확실성일테지.

그래도 마치 모뎀이 전화선으로는 2400이 마지막이라느니 2400MNP가 최고라느니 14400은 넘을 수 없다느니, 56k가 끝이라느니 계속되는 배리어깨기처럼 인간이라는 녀석은 뭔가를 찾아 배리어를 깰 것이라는 생각을 한다. 자야겠다.

어제는 Silverlight 2의 첫 Servicing 업데이트를 Sign off했다. Servicing이라 함은 정식 버젼 출시 이후의 문제들을 해결하는 업데이트라고나 할까, Windows로 치면 서비스 팩이나 보안 패치등이라 할 수 있겠다. 어떤 제품이든지 메이저 업그레이드와는 별도로 마이너 업그레이드와 패치등이 모두 Servicing에 해당된다. 소프트웨어가 아닌 물리적인 제품이라면 A/S에 해당할 것이지만, 소프트웨어라는 특성상 꽤 다르다.

Servicing은 예산에 굉장히 민감한 부분이기 때문에 항상 빡빡하고 욕도 많이 먹는 부분이기도 하다. Servicing이라고는 하지만, 세상에는 완벽한 제품도 없고 사용자의 요구는 무한대기 때문에, 이를 조절하는 것은 골치아픈 일이다. 예산과 리소스에 맞게 고치고 업데이트할 부분들을 잘 갖춰서 밸런싱해야하고, 어쩔 수 없이 해결하지 못한 부분에 대한 리스크를 감수해야하는 것이다. (예를 들어, 저쪽에서는 용어 하나 바꾸는 것으로 인한 기존 제품/문서 수정 비용으로 몇주째 논의…) 사용자가 천만명인데 그 중에서 십만명이 골치를 썩는 문제와 만명이 골치를 썩는 문제 두개 중에서 한개 밖에 해결할 수 없는 리소스가 어쩔 수 없이 할당되었다면, 어느 것을 고칠까? 무조건 십만명? 다양한 이유로 그렇지는 않다.

아무튼 Silverlight 2도 출시된지 좀 지났고, 중요한 버그들이 있었고 몇몇을 고치고 시장의 요구를 귀담은 수정을 내놓게 되는데 이에 대한 소프트웨어 준비가 완료되었다. Sign off를 뭐라고 번역해야할까. 사전을 찾아보면 대충 비슷한 의미의 숙어로:

《美속어》[계획 등]을 서명하지 않고 비공식적으로 승인하다.

가 있는데 이렇게 생각하면 될 것 같다. (국내 업체들에는 각 기업마다 다른 용어를 사용하겠지, 검수 혹은 결재 등) 릴리스(Release)가 있기 전에 계획(기획) 단계에서 어떤 팀들과 사람들이 최종적으로 Sign off를 하게 되는가를 정하고 이에 담당자를 할당하게 되고, 마지막 기한까지 자신이 책임진 부분에 있어서 Sign off를 하면 되는 것이다. 팀마다 제품마다 다르게, 어떤데는 툴을 사용하여 Sign off를 하기도 하고, 이메일을 많이 사용하기도 한다. Windows같은 복잡한 제품은 제품 기능별 뿐만 아니라 엔지니어링에 관련된 Sign off와 퍼포먼스/안정성/UX등의 속성들에 대해서도 각기 다른 담당자가 모두 Sign off를 해야 출시할 수 있다. 물론 나는 Loc팀의 일환으로 Sign off를 했다(Silverlight같은 제품은 글로벌 마켓의 순위가 높기 때문에 다행히 인식이 조금 높은(높아진) 편이니 다행이다).

여담] Sign off라는 말도 내가 생각한 것과 용법이 다르다. “A is signing off on B.”가 맞을 것 같지만, 내가 Sign off하는 것이기 때문인지 “A signs off on B.”라고 적더라.

모든 팀들이 Sign off를 완료하면 전체를 책임진 owner가 “Ship it” 승인을 하고, 이를 바탕으로 RTM(공장등에 CD를 만들도록 보내는 등)을 하거나 RTW(웹에 다운로드 할 수 있도록 스테이징을 하는 등)를 하게 되기 때문에 Sign off 스케줄과 출시와는 다르다. 그러니까 Sign off를 했다더라…라고 뉴스가 혹여 나오더라도 항상 바로 받아 사용할 수 있는 것은 아니다. RTW를 했다더라는 뉴스라면 그렇겠지만.

Sign off를 한 팀이라도 하지 못하고 스케줄을 정지시킬 일이 발생하면 Redmond는 난리가 난다. 모든 담당자가 모여서 우선 해결하고 임팩트를 생각한 뒤에 모든 Sign off를 취소할 것인지 결정한 뒤에 취소되면 다시 테스트 기간을 가지게 된다. 물론 팀별로 테스트 양은 책임지고 조절한다, 자기 Sign off이기 때문에. 돌려서 사악하게(?) 이야기하면 (물론 정당한 이유로) 내가 Sign off하지 않으면 출시는 미뤄질 수 있다.ㅎㅎㅎ (나는 특정 제품 그룹이 아니라 글로벌 마켓에 해당하기 때문에 한달에 Sign off를 많게는 열댓게, 적게는 한두개하니 지금까지 얼마나 많이 했을랑가ㅎㅎㅎ)

Servicing의 경우 아무런 이야기 없이 조용히 출시하는 경우도 많기 때문에 뭐가 언제 어떻게 나오느냐에 대해서는 언급하면 안되지만, 그것에 아니더라도 요즘에는 다음 버젼의 Visual Studio인 VS2010을 버즈로 마케팅 중이기 때문에 당분간은 조용히 있으리라 생각된다.

이번 테스트에서는 (우리나라와 상관 없는) 큰 변화가 있었기 때문에 그 업무량이 좀 많아져서 조금 골치가 아프긴 했다. 테스팅은 중국 테스팅 벤더와 우리나라의 팀 양쪽에서 테스팅해야되기도 하고, 원격 벤더와 일할때는 작은 디테일까지 모두 전달을 해줘야 하기 때문에 일의 양이 많으면 배가되기 때문이다. 다음 테스팅 기간에는 설 연휴가 겹친데다가 중국은 설이 엄청나게 길기 때문에 여기에 맞추는 것도 골때리는 일이다. (이에 대해서는 다음에 기회가 있으면 해볼지도)

아무튼 Sign off를 하는 것은 뭐래도 속시원한 일이다.