Dr. Woo's epigram

최근 들어서 그동안 묻어두었던 이슈들을 급하게 풀어야 하는 일들이 생겼다.
과거에 시간에 쫒겨서 완벽하게 마무리하지 못하고 넘어갔던 일들 중 몇 가지가 있었다.

커서를 사용해서 지울 때의 커서 포지션 설정 이슈,
가상 테이블을 위한 이터레이터 리팩토링,
커서 세이브 기능의 완전성 이슈,
새로운 벤치마크 작성과 성능 측정, 등등등

욘석들을 한숨 좀 돌릴 때 풀고 싶었지만, 묘하게도 이 바쁜 때에 요놈들을 풀어야만 하게 되었다.
찜찜해서 리스트업만 해 둔 것들이 몽땅 다시 일어나 빨리 풀어달라고 아우성이다. 흑....

역시 공짜 점심은 없는 법이다.
앞으로 일마무리가 뭔가 미흡하다 싶을 때는 꼭 기억해야겠다.
찜찜하게 지나간 일은 언제고 꼭 뒤통수를 갈긴다.

올해 우리는 인덱싱과 질의처리 쪽에서 서울대 심규석 교수님과 co-work을 하고 있다.

심교수님은 DB분야에서는 이미 석학이라 할 수 있는 분이고,

전산학계 전체로 봐서도 그 지명도가 국내의 연구자들 중 탑 텐 안에 들 것으로 생각이 된다.

지난 주에 서울대에서 테뉴어를 받으셨는데, 텐뉴어를 받기까지의 과정이 너무 구구절절하여

참 안타까움이 들었다. 그런 정도의 석학이 테뉴어를 못 받는 걸 걱정하게 만드는 심사시스템이라면

문제가 있어서 정말 단단히 문제가 있는 것이 아닐까.

항상 정성적인 평가에 자신이 없어하고, 정량적이나 의미가 없는 지표를 활용해 평가하는 것은

우리나라 곳곳에서 확인할 수 있는 폐단 중 하나이다. 참 안타까운 일이다.


목요일에 새벽까지 술을 마신 후, 3시간 자고 일어나서 회사에 왔다.

비몽사몽 간에 회사에 왔는데, 회사에 오니 때마침 심교수님이 방문하여 세미나를 하게 되어 있었다.
다행히 보이차 한 잔 마시고 들어갔는데, 시간이 갈수록 정신이 또렷해져서 세미나를 잘 들었다.

세미나 내용이 너무 재밌었는데, 그걸 취해서 못 들었다면 참 큰일일 뻔 했다.


이 산학과제에서는 기존의 알고리즘들을 전혀 다른 environment로 적용시켜야 한다.

Q-gram이나 Suffix Tree에 대해서 서베이 결과를 교환하고 아이디어를 나누었는데,

발표를 듣고 질문을 하면서 토론을 하는데, 너무 재미가 있었다.

이게 재미가 있는 것이, 일단 심교수님이 아주 스마트하셔서 의사소통이 굉장히 빠른 데다가,

산학과제를 수행하는 박사과정인 박형민 씨도 보기드물게 머리회전이 빠른 인재이다.

앞으로 박형민씨가 어떤 경로를 통해서 세상에 자신을 보일 지 모르겠지만, 아주 기대된다.


스마트한 사람들과 대화할 때면 세상을 더 잘 이해하게 되고 새로운 가능성을 발견하게 된다.

이런 미팅은 자주 해도 에너지가 재충전되는 것이라서 아주 좋다. 다음 주의 미팅이 기다려진다.

어제만 해도 참 재미있는 problem들이 여러 개 발견되었다.

잘 풀어서 논문으로 나오면 더할 나위 없이 좋겠다. :)

한 주가 어떻게 지나갔는지를 잘 모르겠다.

월요일 아침에 지천씨, 탄슈씨, 왕쉬씨가 도착했다.
미리부터 업무환경을 구축하는데 필요한 절차들을 알아보고 준비하긴 했지만,
그래도 막상 작업을 개시하고 나니 요청할 것도 많고, 결재 올릴 것도 많고, 알아봐야 할 것도 많다.

올해 들어서는 아무리 바빠도 한 주의 정리가 안 될 정도로 바쁜 주가 없었는데, 금주만큼은 그야말로 하루하루 hand to mouth 의 기분으로 지냈다. 다행히 금요일이 되어서는 모든 절차와 환경이 완비되고, Task 지정도 끝나서 다음 주를 바라보는 마음은 한결 가뿐하다.

이제 좀 한 숨 돌렸다~ 휴~~

금주엔 또 다른 쪽으로부터도 협력이 진행되었는데, 목요일엔 SE팀에서 이미영 책임과 곽태희 선임이 방문하여 올해 어떻게 우리와 Quest를 해 나갈 것인지 회의했었고, SQE 쪽에서는 2Q에 우리 시스템 테스트를 정비해 주기 위해서 조인성을 닮은 미남청년 박완상씨가 월요일에 합류했다.

새로운 관계가 형성될 때에는 무수히 많은 할 일들이 발생한다.
그러한 일들을 모두 한 말로 통칭한다면 communication overhead라고 할 수 있을 것이다.

특히 올해는 그 어느 때보다도 더, 무수히 많은 상대방과의 관계 형성에 기반해서 결과를 만들어내야 하기 때문에 communication overhead라는 것이 중요한 이슈이다.
팀 내부적으론 문화와 언어가 다른 외국 인력들을 새로운 AceDB 패밀리로 받아들어오게 된다. 연구소 안에선 SE, SQE 팀과 함께 최적의 프로세스는 무엇일지 고민해야 하고, 연구소 밖에선 서울대, 명지대, KCC 등과 협력해서 deliverable을 만든 다음, 삼성의 다른 사업부들인 무선사, AV사, VD사, 테크윈 등에 넣어주고 지원해야 한다. 파트너의 수도 많고, 관계도 참 다양하다.

그러한 다양한 관계들에서 발생하는 Communication overhead라는 것은 이전엔 없었던 새로운 문제들임에 분명하지만, 동시에 아주 흥미로운 도전거리를 안겨준다.

이런 환경에서는 다음과 같은 두 가지 짜릿한 과실들을 얻을 수 있다.
하나는 물론 그 모든 communication overhead를 극복하고 원래 목적했던 결과를 성취했을 때인 것이고, 둘은 그 communication overhead를 극복하는 최적의 방식을 찾아나가는 일이다. 많은 사람이 모여서 더 큰 일을 해서 더 좋은 성과를 만들어 냈다면 당연히 기분도 더 좋다. 이런 경우 서로 고맙다고, 잘했다고 칭찬해 줄 수 있어서 더욱 좋다. 한편, communication overhead를 극복해 가는 과정도 참 재미가 있는 부분인데, neutral하고 건조했던 관계가 선순환의 관계가 되면서 만나면 기분좋은 관계로 바뀌었을 때의 그 포만감이란~~~

그런데, 그런 좋은 과실을 얻기 위해서 무엇보다도 중요한 것은 좋은 파트너를 만나는 일이다.
그런 면에서 열정이 있는 파트너들을 만나게 되어 올해도 참 행운이다.
역시 나는 운이 좋다는 생각을 하게 된다 쿠쿠쿠

ps. 유일하게 좀 걱정되는 것이 KCC인데, 이번에 평양에 가게 되면 더 잘 알 수 있겠지~

지난 주에 SW Newsletter에서 소개한 글 중 공감이 가는 글이 있어서 다음과 같이 발췌해서 팀에 공유를 했다.

+++++++++++++++++++++++++++++++++++++++++++++++++++++ (이하 전재)

다음은 타일러의 블로그에서 직접 인용한 내용이다. 그의 고백은 내가 3년 전에 루슨트테크놀로지에서 월스트리트로 직장을 옮기면서 느꼈던 심정과 너무 비슷하다. 그런 면에서 타일러의 이야기는 곧, 필자의 이야기이기도 하다.

“내가 첫 직장에서 일을 시작한 1년 뒤에, 우리 회사는 다른 회사와 합병되었다. 나는 갑자기 나보다 훨씬 재능이 많고 경험도 풍부한 사람들에 의해서 둘러싸이게 되었다. 그 상황이 나를 얼마나 큰 열등감과 바보 같은 심정에 휩싸이게 만들었는지 지금도 생생하게 기억한다. 나는 열심히 공부했고, 많은 책들을 읽었지만 그들을 따라잡을 수 없었다. 그들은 나에 비해서 많은 장점을 가지고 있었다. 그렇지만 이제는 뛰어난 사람들과 함께 일하는 것이 나를 슬프게 하지 않는다. 나는 다만 그들로부터 배울 수 있는 기회를 얻었다고 느낄 뿐이다. 나는 동료에게 질문을 던지고 그들이 왜 그러한 결론에 이르렀는지를 이해하기 위해서 머리를 싸매고 고민한다.
(.......중략......)
 당신의 동료를 경쟁자가 아니라 당신의 재산이라고 여길 필요가 있다.”

 ++++++++++++++++++++++++++++++++++++++++++++++(여기까지)

그랬더니 한 팀원이 다음과 같이 답장을 해 왔다.

"맞아요~ 뛰어난 동료들 때문에 매일 스트레스 받고 있지만,
 이젠 이 스트레스가 없어지면 못 살 거 같습니다 ㅎㅎ"

이런 반응이야말로 우리 팀이 건강하다는 산 증거가 될 것이다.

올해에는 산학과제도 참 많이 진행을 한다.

DB 과제를 위해서 서울대 심규석 교수님 쪽, 북한의 KCC 연구소에 위탁과제를 맡겨서 진행하고 있고, 러시아 연구소에도 과제를 맡겨서 진행하고 있는 상태이다. 게다가 중국 연구소와는 아예 공동개발을 하게 되었다. 러시아에, 중국에, 북한까지 들어 있으니 쌍팔년도 식으로 따지자면 북방외교를 하고 있는 셈이다. 연구니까 북방연구인가? 하하하

삼성전자는 세계 곳곳에 연구소를 가지고 있는데, 미국, 중국, 인도, 러시아 등이 대표적인 곳들이다. 이 중에서 나는 미국, 중국, 러시아와 공동연구를 해 봤으니 거의 대부분의 해외 연구소와 같이 일을 해 본 셈이다. 사실 외주의 개념으로 가장 많이 활용되는 것이 인도연구소라서 삼성전자에서 해외 연구소랑 일한다고 하면 대부분 인도 연구소랑 하는 경우가 많으니, 비교적 사람들이 자주 접하지 못한 해외 Branch들과 같이 작업을 해 본 셈이다.

각 지역 연구소들과 우리 연구소는 하나의 조직 아래에 속해있기 때문에, 자연스럽게 우리 연구소는 지역 연구소들의 Headquarter 역할을 하게 된다. 그래서 공동으로 과제를 하는 경우 과제의 승인 절차가 해외 연구소에서 propose를 하면 우리 쪽에서 승인하는 형태를 가지고 있다. 사실 이러한 형태는 소비자에 가까운 쪽에서 Fund를 어떻게 쓸 지 결정한다는 점에서 자연스러운 것인지도 모르겠다. 회사에서 가장 강력한 조직은 소비자를 직접 만나서 돈을 버는 사업부이고, 이 사업부에 연구 결과물을 들이미는 우리 연구소는 사업부의 Fund를 받는다. 그러니 우리보다 더 Product에서 멀리 있는 해외 연구소는 다시 우리 연구소의 Fund를 받거나 연구승인을 받는 것도 당연할 지 모르겠다.

그런데, 그러다 보니 한가지 아쉬운 점은 해외 Branch에서 일하는 연구 파트너들이 과제를 수행할 때에 mutual한 입장보다는 조금 passive한 입장으로 변한다는 점이다. 참 아쉽다. 올해에 같이 일하는 러시아 연구소의 파트너는 PL이 참 똑똑한 사람이다. 말을 많이 하진 않아도, 이쪽에서 하는 말을 정확히 이해한다. 두 번 의견을 말할 필요도 거의 없다. 이 사람이 "I see"하면 그걸로 정말 알아들은 것이다. 확인하기 위한 질문이 없어서 간혹 불안한 때도 있었는데 나중에 보면 어김없이 정확히 의견이 전달된 것으 알 수 있었다.

그런데, 좀 재미가 없다.
원래 연구란 것은 서로간에 좋은 아이디어는 칭찬해 주고, 허점이 있으면 찔러주고, 기발한 아이디어를 서로 경쟁적으로 내려고 하고 해야 재미가 있는 법이다. 그런데 이번 러시아와의 과제에서는 우리가 제시한 보완사항(그 쪽에서 받아들이기로는 HQ의 Comment)을 고쳐서 주는 것으로 대부분의 개발단계들이 끝이 나니 너무 밍숭밍숭하다. 차라리 우리가 미비한 점에 대한 Comment라고 제시한 것들에 대해서 각종 반론을 제시하거나 그랬으면 좋겠다. 예를 들면 "그건 이래서 어렵다" 라든가 "그것도 좋은 생각인데 다른 방식으로도 가능할 것 같다", 혹은 "그건 너희가 잘못 이해한 것이다" 라든가 등등으로 말이다. 그런데 대부분의 경우 "알았다. 보완하겠다."로 interaction이 끝나버린다. 아,, 이건 참 재미가 없다.

각종 문서들의 승인 절차에 우리 쪽의 Approval이 필요한 것도 아마 그 큰 원인이 되는 듯 하다.  처음 프로젝트를 launching할 때에 일부러 절차상으로는 본사의 승인을 계속 받는 형태가 되어도 우리 연구의 진행은 대등하게 적극적으로 아이디어를 내 보자고 했었는데, 아무래도 승인을 받는 입장이 되다 보니 좀 수동적으로 변하게 되는 것이 아닐까 싶다.

그런데, 북한의 김경일 선생 팀과 같은 경우 오히려 더 명확하게 연구 발주자와 연구 수탁자로 나뉘어져 있었음에도 참 열심히 서로 주고 받았다. 미비한 점에 대해서도 이야기할 때도, 새로운 것에 대해서 도전할 때에도 열정이 있는 파트너라는 느낌이 들어서 너무 좋았었다. 러시아 연구소에서 나와 contact하는 PL도 김선생 못지 않게 아주 똑똑한 사람인데, 불꽃튀는 지적 공방전이 벌어지지를 않으니 풍성한 잔치상을 차려놓고는 배탈이 나서 죽만 먹고 있는 듯한 아쉬움이 밀려든다.

그런 아쉬움을 낳는 근본적인 원인은 개성의 차이일까? 아니면 본사와 지사라는 특수관계로 인한 Side Effect일까? 아니면 모스크바가 여기서 너무 멀기 때문일까?.. 아무래도 본사와 지사의 무게중심이 본사쪽으로 많이 기울어져 있는 것도 큰 원인 중 하나인 것 같다. 그 쪽 팀원이 3명인데, 한 번쯤은 그 쪽이 한국에 방문하거나 우리가 그 쪽에 방문할 일이 있을 것이다. 그 때가 되면 술을 한잔 하면서, 흥이 나면 러시아 병정 댄스도 춰 보면서,  HQ-Branch의 형식적인 절차를 떠나 최고로 좋은 거 한 번 만들어 보자고 이야기를 하고 싶다.

지난 목요일 저녁에는 간단히 AceDB 회식이 있었다.

원래 회식의 목적은 새로운 Query Processor의 개발 작업을 종료한 홍책임과 진선임을 축하하기 위한 것이었는데, 때마침 권교수가 산학과제 최종발표를 하러 오게 되어서 "올타쿠나" 하고 같이 갔다. 2차할 때에는 신선임까지 합류하여 시끌벅적하게 이야기하면서 회포를 풀었다.

1차로 해물찜 같은 걸 좀 먹어주니 벌써 9시, 2차로 맥주 좀 하다 보니 바로 새벽 2시...
나는 2시에 집에 택시타고 홍책임이랑 집으로 갔는데, 권교수는 집에 가기 싫다고 진선임과 신선임을 꼬셔서 새벽 4시까지 마셨다고... 어쩐지 그 담날 출근해 보니 아침부터 진선임이 자리에 고꾸러져 있었다. 아,, 이건 프리맨인 교수가 비즈니스맨들 완전 농락한 것이여~~ :)

2차에서 권교수의 교수생활 이야기가 나왔었는데, 이래서 좋고 저래서 안 좋고 등등 이야기를 하다가 희규씨가 나에게 중요한 질문을 물어왔다. 그 질문은 다음과 같은 것이었다.

"내가 아는 한 우책임님은 사람을 가장 중요시하는 것으로 알고 있다. 그런데, 권책임, 이책임, 강선임, 이책임 같은 인재들을, 다음 기회에 또 재미있는 일들을 같이 할 수 있는 인재들을, 강력히 잡았어야 하는 것이 아니예요? 오랫동안 같이 일해온 저나 김선임이 나가면 어떻게 하실 거예요?"

나에게는 아주 통렬한 질문이고 민감한 질문이다.
1년 전에 영석씨가 물었던 질문이기도 하며,,
내가 나에게 자주 묻는 질문이기도 하다...

그런데 그 날 충분히 희규씨에게 내 생각을 전달하지 못한 것 같다.
좀 이야기하려고 말꼬는 텄는데, 바로 권교수가 딴 이야기로 화제를 돌리기도 하였고 술도 좀 마셨던 터라 충분히 생각을 전달할 준비가 안 되었었기 때문이다. 지난 목요일에 술자리를 하고 난 이후에 내 머리속에 그 질문이 맴맴 맴돌아서 어떻게든 정리를 하고 싶었다.


이 Post은 희규씨가 물었던 그 치명적인 질문에 대한 솔직한 답글이기도 하며,
수년간 나를 괴롭혔던 고민들에 대한 정리이기도 하다.


음... 사실 그 뛰어난 사람들을 왜 내가 적극적으로 잡지 못했는가는 스스로 아주 잘 알고 있다. 바로 직장과 일에 대해서 내가 나름 가지고 있는 두 가지 믿음 때문이다.

첫번째 믿음은 "사람은 자신의 재능에 맞는 곳에 가서 재능을 꽃피울 때 행복하다"는 것이다.
나는 대학교 때부터 재능이란 무엇인가에 대해서 굉장히 관심이 많았다. 그리고, 회사에 들어와서는 내 재능이 무엇인지를 드디어 각성(?)하게 되었다. 그것이 약 2년 반 쯤 전의 이야기이다. 그 뒤로부터는 다른 이들의 재능을 알아내는 것에도 관심이 아주 많아졌다. 일에 있어서의 나의 코드는 "Fun"이고 나는 팀원들이 모두 즐겁게 살기를 바란다. 그런데 일터에서 행복하고 즐겁게 살려면 재능과 맞아떨어지는 일을 해야 하니 어찌 관심을 안 가질 수 있겠는가.

아무튼 학교로 간 두 사람은 확실히 교수직을 하면서 행복을 느낄 수 있는 재능들이 있었다. 만일 훌륭한 교수가 될 만하지 않은데 학교로 가고 싶다고 했다면 "너 거기 가면 불행해진다" 라고 강력하게 말렸을 것이다. 그러나, 자신의 재능이 꽃 필 수 있는 곳에 가겠다는 이를 막는다면 안 되지 않겠는가... 그것이 내가 적극적으로 두 사람을 막지 못한 이유였다. 그리고 두 사람이 뛰어나게 일해온 만큼 일하기가 참 팍팍해졌지만 보낸 후에 마음이 아주 괴롭거나 그러지는 않았다.

두번째 믿음은 잭웰치의 말처럼 "핵심인재는 영혼과 지갑에 충분한 보상을 받아야 한다"는 것인데, 영혼과 지갑에 충분한 보상을 받지 못하여 이직하는 경우는 재능을 발휘하러 이직한 경우와 달리 지속적으로 마음을 괴롭힌다. 이책임과 강선임의 경우 확실히 그 재능은 학교보다는 회사에서 빛을 발할 만한 것들이었다. 이책임이 미국으로 떠날 때에는 어떤 보상을 더 하여 잡을 수 있는 것이 뭐가 있을 지 알아보았는데, 참 할 수 있는 것들이 별로 없었다. 강선임의 경우도 마찬가지...

돌아보면 정말 구차한 변명 같지만, 이 사람이 회사에 얼마나 뛰어난 일들을 해 줄 수 있는지 뻔히 알면서도 내가 줄 수 있는 것들은 좌절스러우리만큼 너무나 적었다. 금전적인 보상도, 도전할 영역의 선택도, 글로벌한 경험도,,, 너무 많은 부분이 나의 재량 밖에 있는 것들이었다.,

그러나, "내 재량 밖의 일이었다" 라고 생각을 해도 지속적으로 씁쓸한 느낌이 드는 것은  막을 수 없었다. "정말 좋은 팀 리더라면 어떻게 감언이설을 펼쳐서라도 인재유출을 막아야 하는 것은 아닐까, 내가 너무 순진한 리더라서 단편적인 부분만 보고 있는 것은 아닐까, 정말 탁월한 리더라면 이런 상황에서도 나와는 다른 "바른" 길을 알고 있지 않을까?" 그런 생각을 수도 없이 했다.

이건 아직도 잘 모르겠다.  짐 콜린스나 토마스 마킹엄에게 편지라도 한 통 써 봐야 할까나...

다만, 지난 번에 중국에 김용성 책임과 같이 출장을 갔을 때에 와인을 마시면서 나눈 말이 있다.
우리가 얼마나 잘 해야 되나면, 구글이나 MS가 직원을 대하는 것과 삼성전자가 직원을 대하는 것의 차이를 우리가 메꾸어 주어야 하는 것이라고... 그러니 우리가 정말 잘해야 한다고,, 그런 이야기를 하면서 와인을 넘겼었다. 그런데, 적어도 올해만큼은 그런 고민이 해결되었다. 올해에는 충분히 도전할 만한 좋은 목표들이 있고, 그 목표들을 이루는 과정에서 확실한 성장도 기대되고, 잘만 되면 경제적 보상도 있을 것 같다.

한편, 얼마만큼을 롱텀으로 보아야 할 지 잘 모르겠으나, 결국 롱텀으로 생각해 볼 때 내가 할 수 있는 선택은 아주 명쾌하게 둘로 나뉜다.  첫번째는 팀의 인재들에게 최고의 보상과 도전을 할 수 있는 곳으로 나도 직장을 바꾸버리는 것이다. 두번째는 우리 팀의 인재들에게 최고의 보상과 도전을 할 수 있는 환경을 제공하도록 삼성을 바꾸는 것이다(삼성전자 전체가 안 바뀌더라도 그 만큼의 재량권을 확보하든지).

만약 둘 다 이룰 수 없다면, 내 재주의 미천함을 인정하고 보습학원에서 코흘리개들이나 가르치면서 살란다.. 인재를 다 잃은 채로 팀을 리딩하는 것도, 뛰어난 인재들에게 걸맞지 않은 대우를 참고 살라고 말해야 하는 것도 둘 다 참을 수 없으니까... 

과제에 대한 정량적 과제 분석이 지난 1월에 실시되었었다. 어제는 이 결과의 공유회의가 있었다.회의에서 나왔던 각종 discussion 중에서 나름 기록으로 남겨둘 만한 대목이 있어서 잊어버리기 전에 여기에 기록한다.

정량적 과제 분석이란 것은(이 용어가 정확한 지는 모르겠으나) 과제를 수행하면서 산출하는 각종 지표들을 바탕으로 현재의 과제 Status를 확인하고, 통례에 비추어서 과도하거나 과소하게 표출되는 지표들을 보고 과제 위험요소들을 파악하는 도구이다.

특히 분석하는 재료가 되는 지표들 중에서 중요한 것이 각 단계별로 CQ에 입력된 defect의 수들이다. 과제분석을 수행한 곽선임은 이 defect의 수를 보고 어느 stage에서 얼마만큼의 defect 감소 노력이 투입되었는 지를 도식화하였다. 이렇게 CQ defect 통계를 사용하는 것은 어느 정도 타당해 보인다.

그런데, 발표를 듣고 있던 김영석 선임이 아주 좋은 문제 제기를 하였다.
즉, "현재 설계단계의 경우 inspection이라는 것이 주로 문서가 잘 작성되었는지의 formatting이라든지 기술이 누락된 부분이 있는지라든지 등을 점검하여 미달된 요소들을 CQ에 defect으로 등록하고 있다. 실제 디자인이 잘 되었는지가 inspection 회의에서 검토되는 일은 거의 없는데, 그렇다면 CQ에 입력된 설계 단계의 inspection defect 숫자를 보고 산출 SW의 defect 감소에 얼마만큼의 노력이 투입되었는지를 계산하는 것이 잘못된 것이 아닌가?" 라는 것이다.

이에 대해서 전체적으로 맞다. 실제 설계 내용을 검토했을 때의 논리적 결함을 발견하고 이를 등록해서 지표로 활용하는 것이 옳다. 문서의 경우 심각하지 않은 것들은 오히려 CQ에 입력하지 않는 것이 분석오차를 줄이는 길이다. 등의 의견이 나왔다.

뒤돌아 보니 지금처럼 된 원인 중 하나가 inspection을 수행하기 시작할 시점을 결정하기 어려워서가 아닌가라는 생각이 들었다. 그래서 "inspection이라는 것은 설계 문서 산출 이전에도 이미 개발팀 내에서 수시로 옆자리 사람과의 대화나 설계공유를 통해서 이루어지고 있다고 본다. 그런데, 설계와 inspection 사이의 선을 언제 그어야 할 지 몰랐기 때문에 현재처럼 inspection 시점을 문서산출 뒤로 정한 것 같다. 그렇다면, 언제까지가 논리적 오류가 발견되는 것들에 대해서 어디까지가 설계과정에 포함되고 어디부터가 inspection defect으로 취급되어야 할 지에 대해서 SE쪽에서 새로운 기준을 마련해 주어야 하는 것이 아닐까?" 라고 질문을 하였다.

그랬더니, 고상무님이 "과연 그러한 시점을 제시할 수가 있을까? 설계자 자신도 과연 어디부터가 설계 끝이고 어디부터다 inspection 시작인지 모르지 않는가? 이 문제는 어차피 일정한 시점에 inspection을 하겠다고 한 시점까지 개발자가 열심히 준비하고, 그 이후에 나온 것을 defect으로 셀 수밖에 없다고 본다"는 요지의 말을 하셨다.

듣고 보니 단순하고도 현실적이다. 팀 내의 자체적인 inspection에서도 역시 동일하게 특정 시점을 정해서 그 전과 후를 구분하면 될 것 같다.

사실 회의에 참석한 김상무님의 경우에는 워낙 SE 전문가이시고, 예전부터 조리있게 말씀하시는 것을 익히 알고 있었는데, 고상무님과 Software Engineering이나 개발 프로세스에 대해서 이런저런 의견을 나눌 기회가 거의 없었었다. 그런데, 회의에서 이 이슈 말고도 다른 이슈들에 대한 고상무님 의견도 들어 보니, CISCO 초기 멤버로 참여해서 십수년간 SW 엔지니어로 일해온 관록이 자연스럽게 묻어나고 있었다.

역시 자리의 고저에 상관 없이, 고민한 흔적들은 자연스레 흘러나와서 빛을 발하기 마련이구나.

연휴에 돌입할 때 신정에 못한 결심들을 설에는 세워봐야지 하고 마음을 먹었었다.
설 연휴가 거의 지나가고 있는 오늘, 좀 짬을 내어서 여기에 적어 본다.

첫째, 올해 회사에서 계획한 AceDB 전파 프로젝트를 성공리에 마무리하자.
올해엔 프로젝트 규모가 정말로 전사적이고, 글로벌하게 벌어지게 되었다. 올해의 두 가지 목표인 전사 보급과 기술이전만 성공시킨다면, 뿌듯하기도 할 뿐더러 한 레벨 성장할 것이 분명하다.

둘째, 책을 많이 읽자.
"한달에 두권" 처럼 숫자로 세워야 할 지, "드러커 평전 완독" 같이 특정 토픽을 골라야 할 지 고민을 많이 했는데, 신문을 보니까 즐겁고 흥미로와 보이는 책들이 매주 너무 많이 나온다. 그래서 올해는 일단 한달에 두권이라는 소박한 목표를 세워 보았다. 이거라도 꼭 지키도록 노력해야 겠다.
일단 읽을 책을 많이 사두긴 했으니, 이제 읽기만 하면 된다 >,<

셋째, 허리를 32인치 이내로 복귀시키자.
지난 베이징 출장에서 너무 잘 먹어서 허리가 늘었었는데, 간신히 잡아놓은 것을 이번 설 연휴에 다시 늘려버린 것 같다. 아,,, 이래선 안 되지. 점심시간 운동을 통해서라도 긴급조치 들어가야겠다.
몸무게로 목표를 잡아봐야 근육 다 빠지고 배는 나오는 상태로 목표를 달성해 버리니 -_-, 허리를 기준으로 목표를 설정해야 겠다. 연말까지 32인치 이내로(hopefully 31인치? ^^) 복귀시킨다!!

이렇게 세 가지 목표만 올해 달성해도, 연말에는 대단히 뿌듯할 것 같다.

연말까지 새로운 과제까지 기획하다가 AceDB 전파만으로 할 일이 한정된 후로, 올해를 시작하는 마음이 좀 심드렁했었다. AceDB의 추가 개발 및 사업부 전파가 물론 중요한 일이지만, 너무 눈 앞에 빤히 보이는 일이고 평범하고 무난하게 한다면 잘 굴러갈 일으로 보였기 때문이다. 신규 사업의 경우 해야 할 가치도 물론 타당하게 있지만, 잘 하려면 굉장히 많은 난관을 뚫고 헤쳐나가야 한다는 것이 더 매력적이었었다.

그런데, 1월 들어서 상황이 급변하더니, 이게 정말 도전적이고 매력적인 일로 확 바뀌었다.

내게 있어서 그 이유는 크게 다음의 두 가지가 있다.

첫번째는 AceDB 메인터넌스 작업을 내년부터 해외 연구소로 이관하게 되어서 올해에 필연적으로 해외 인력들과 공동개발을 하게 된 것이다(게다가 올해 안에 실제 AceDB 내에 넣어서 사용할 코드를 타기관과 협력개발하는 건도 두 건이 계획되어 있다).

두번째는 AceDB의 전사보급에 있어서 이제 정말로 공이 우리 손에 넘어왔다는 점이다. 자세한 상황은 블로그에 올릴 수 없겠지만 한 가지 분명한 것은, 올해 우리가 전사 기기들에 AceDB를 다 심어두지 못한다면 그것은 전적으로 우리 자식인 AceDB의 제품 Quality가 모자란 탓이 될 것이란 점이다.

결국 올해에는 (1) 해외 연구소 인력들 및 타 기관들과 한 팀으로 공동 개발을 하되 Communication Overhead로 일정 차질이나 Quality 저하가 없도록 해야 하며, (2) 동시에 기존의 방대한 문서들과 코드들을 차후 해외 인력들이 self maintenance할 수 있는 상태로 만들어야 하고, (3) 또 사업부 플랫폼들 별로 해당 사업부 인력들과 다양한 적용이슈들을 같이 해결해 나가야만 한다.

아,, 이런 생각을 하면 할 수록 곳곳에 숨어 있는 위험요소들이 계속해서 떠오른다.
또, 어떤 전략으로 풀어 나가야 최선일까, 하고 답이 없는 고민들을 계속해서 해야 한다.

그래서,,, 아주 피가 끓는다.
이런 도전거리들을 어떻게 하면 잘 해결해 나갈까를 생각하니,
마치 AceDB를 처음 개발하던 때처럼 피가 끓는다.

하나씩 하나씩 잡아서 아주 멋지구리하게 해결해 주마. 후후훗~~

More Challenge, More Fun.
No Challenge, Life sucks. ^^

그리스 신화에 보면 판도라가 상자를 열 때 온갖 종류의 나쁜 놈들이 세상에 나왔다.
그러나 제우스가 상자에 남겨준 선물이 하나 있었으니 바로 "희망"이었다.


신은 또한 정신없이 변하는 현대의 회사원들을 위해서 드러커 할아버지를 선물로 주셨다.
자신의 삶을 잘 경영하고 싶은 모든 이들에게 신의 선물이었던 드러커 할아버지는,
인류와 함께 거의 100년을 함께하다가 2005년 11월 11일 95세의 나이로 귀천하시었다.

그러커 할아버지는 다음과 같이 말하곤 했다.
이하 Professional의 조건에서 인용.
________________


웃으며 대답하긴 하지만 결코 농담은 아니다.
나는 베르디가 여든 살이라는 나이에도 늘 자신을 피해 달아나는 완벽을 추구하면서 오페라를
작곡했던 그때 심정으로 대답한 것이다. 비록 지금 내 나이가 폴스타프를 작곡할 당시의 베르디보다 많긴 하지만, 나는 여전히 앞으로 몇 권의 책을 더 쓸 계획을 갖고 있다.


________________

드러커 할아버지는 평생을 저렇게 말을 하면서 살았다.
더 중요한 것은 90세가 넘은 나이에도 자신이 하는 말을 정말로 믿으며 살았다는 것이다.

과거를 돌아보면 항상 Up and Down이 있고, 유난히 일이 잘 되어 마음에 들었던 해도 있다.
그러나 나이 30이나 40이나 50이나 60에, "그 때가 내 인생의 절정이었다" 라고 말하게 되지
않기를 나는 소망한다. 매년 연초에 "올해는 정말 최고의 한 해가 될 것 같은데요?" 라고 말할 수 있기를 바란다.

그리하여,,,

오랫만에 코딩을 다시 하고 있다.

조만간 예상되는 인력 보강 전까지 우리 팀은 가난한 모드로 가고 있는 중이다.

1월 말에 급하게 릴리스할 것이 있었는데, 예상치 못한 이슈가 돌출했다.

가난한 모드라 일손은 딸리고, 내가 예전에 맡던 부분이기도 하고 해서 부득이하게 나를 투입했다.

그래서 지난 6개월 전 쯤에 간단한 bug fix한 일 이후로 처음 CC에서 소스를 checkout하였다.

사실, 나는 개발팀의 규모가 6명 단위를 넘어가면서부터는 직접 모듈 코딩하는 것을 포기하였다.

상세 설계 정도의 레벨이라면 몰라도, 내가 코드에 손을 대는 것 자체가 전체적으로 바로

지연으로 직결되어 버렸기 때문이었다. -_-;

팀 리더가 직접 코딩할 때의 위험요소는 사실 코드 작성을 위한 절대적인 시간부족 때문이 아니라,

전체적인 플래닝이나 기획, 혹은 문서작업이나 협력안 처리 등으로부터 코딩 컨텍스트로 올 때의

컨텐스트 스위칭 타임이 너무 많이 걸린다는 점으로부터 발생한다.

그리고 팀 리더의 코딩으로 인한 지연이 프로젝트에 정말 심각한 위협요소가 되는 이유는,

리더의 작업에 지연이 발생하는 경우 전체적인 작업의 위험요소를 알면서도 제대로 관리할

수 없는 상황이 발생하기 때문이다. 즉, 자신의 모듈에 지연이 발생하는 상황에서는 다른 팀원들의

모듈이 어떻게 되어야 한다라고 일정이나 품질 면에서 높은 기준을 제시하기가 어려운 것이

인지상정이다. 리더는 어떻게 해서든 자신의 모듈을 끝내고 나서 그런 이야기를 하고 싶기 때문에

리더의 작업이 끝나기까지 다른 모듈에 대해서 지켜져야 할 기준들이 제대로 지켜지지 않을

가능성이 높아진다. 그리고 이렇게 되면, 결국 프로젝트는 그 기간만큼 낮은 품질의 Deliverable을

산출하게 되든지, 아니면 산출 일정이 망가지든지, 그러한 운명에 빠지게 된다.


코딩이란 기본적으로 코딩 수행 기간 동안에 머리 속에 가공의 건축물을 짓는 행위나 마찬가지이다.

작업 중에 망치는 어디다 두었었는지, 1층에서는 미장 처리를 다 끝냈는지, 꼭대기의 굴뚝에 올릴

벽돌은 어느 사이즈로 주문해야 맞는 것인지, 그러한 수많은 사항을 머리 속에 담아두어야 한다.


어려운 책을 읽을 때 가능한 한 짧은 기간에 완독할 수록 얻는 게 많은 것처럼,

코딩 역시 머리속 가공의 건축물의 형체가 희미해지기 전에,

그 형상이 생생할 때에 작업을 진행해야 효율이 높은 법이다.

코딩은 다른 어떤 분야보다도 그러한 몰입이 중요한 작업이다.


머리속에 잡생각이 많으면 몰입이 잘 안 되는 것은 당연지사.

이런 저런 생각을 하다가도 순식간에 코딩하는 컨텍스트로 쉽게 몰입하는 사람이 있다면

이런 사람이야 말로 아주 좋은 developer의 자질을 가지고 있다고 할 수 있다.

내가 이제까지 살면서 본 많은 사람들 중, 코딩으로의 context switching시간이 가장 짧은 사람은

지금 미국에 가서 성파형, 성훈이와 같이 일하고 있는 "위니 더 Pooh" 태원이.

한 시간 전에 사업부에 가서 열띤 토론을 하고 와서도 컴퓨터 앞에 앉으면 순식간에 몰입한다.

곁에서 지켜보기만 해도 참 부러운 적이 많았다.


나는 코딩으로의 컨텍스트 스위칭이 그보다는 한참 느려서 다른 업무들을 하다가 코딩하는 경우,

한참을 꼼지락대다가 발동이 걸리는 편이다. 어제는 한참 딴짓거리를 하면서 작업을 했었는데

오늘은 그래도 이틀 째라 훨씬 수월하고, 이런 저런 요소들이 손에 잡혀온다.

가끔씩 이렇게 코딩을 하고 잘 돌아가는 것을 확인할 때면 참 즐거운 기분이 든다.

아마도 코딩하는 동안 순수한 몰입을 경험할 수 있기 때문이 아닐까?

그래서 드는 생각이 가끔씩 코딩을 하는 것은 팀 리더의 정신건강에도 좋다는 것. ^^


단지, 내일하고 모레에 별다른 회의 요청이나 문서 인터럽트가 없기만을 기원할 뿐이다.