초보 팀장을 위한 조언 10

계속적인 개선이, 지연되는 완벽함보다 낫다. - 마크 트웨인

완벽주의를 추구하는 사람들이 있다. 실무자 시절에 꼼꼼하게 일을 잘 하여 성공했던 사람들에게서 흔히 볼 수 있는 증상이다.

하지만 팀장은 실무자가 아니다. 팀장은 주로, 자신이 일을 한다기 보다는 팀원에게 일을 지시하고, 팀원을 세심하게 케어하고, 문제가 발생하였을 때 즉각 트러블 슈팅을 하는 사람이다.

이 지침에는 두가지 관점이 있다.

첫째는 사람의 관점. 팀원들에게까지 완벽성을 요구해서는 안된다. 당신을 만족시킬 수 있는 사람은 결코 없을 것이다.

둘째는 성과의 관점. 완벽하게 하려고 한 나머지 아무것도 못해서는 안된다. 중요한 부분이 명백히 준비되었다면 일단 시작해야 한다. 만일 일부의 결과라도 나온다면, 아무 것도 없었던 때와는 많은 것이 달라져 있을 것이다.

대개의 경우 똑똑함보다는, 행동이 보다 중요하다. 물론 똑똑한 행동이 가장 좋지만.

구글의 식당과 먹을 것들: 음식으로 브랜드를 관리하는 기법

[참고] 구글 한국 블로그에 포스트된 식당 이야기

사실은.. 지난 4월 구글 본사에 업무상 방문할 일이 있었는데, 하필이면 그때 Microsoft MVP Asia Summit이 싱가폴에 있어서 거기를 가느라고 부하직원을 대신 보냈었다.

글쎄, MS 서밋이야 하두 많이 가보아서 별 감흥이 없었는데..

나중에 부하 직원에게 구글에 다녀온 소감을 물어보니 "사무실 분위기가 무슨 테마파크 같아요. 그리고 래리 페이지와 세르게이 브린 방이 오픈되어 있어서 들어가 보았어요.." 등등 호기심을 유발하는 말을!

얼마전 구글 한국 블로그에 포스트된 구글 식당 이야기를 보니 이런 생각이 든다. 이런, 음식으로 브랜드 관리를 하는 기법을.

"음, 역시 사람에게는 먹을 것이 중요해."

일종의 감성 경영인가? 비교적 적은 돈으로 직원들의 로얄티를 극대화하고 있는 것이다. 더불어 이렇듯 입소문 마케팅으로 인한 엄청난 홍보 효과도 함께.

참으로 스마트하군.. 허허

소프트웨어 품질 향상에 있어, 가장 가치있는 행위는 '셀프 코드 리뷰'

이것은 필자의 굳은 믿음이다.

나는 1990년대 초반에 주로 백화점, 호텔 등에서 사용되는 POS 소프트웨어 개발을 했었는데, 그것은 금전을 다루는 것이었다. 바코드를 읽어 상품 가격을 조회하고, 그것들을 모아서 고객의 거래액을 계산하고, 집계된 거래 내역을 서버로 전송하고.

사소한 UI 버그가 아니라, 로직 버그가 발생하게 되면 결국 돈 계산이 잘못된다. 필자의 생각에 가장 품질이 중요한 소프트웨어는 사람의 인명과 관계된 것이고(예를 들면, 국방 또는 의료 소프트웨어), 다음이 돈을 다루는 것이라고 생각한다.

나는 돈을 다루는 소프트웨어 개발을 했기 때문에, 언제나 고객에게 인도되는 소프트웨어의 품질에 대해 많은 신경을 썼다. 그리고 당연하게도 1980년대 초반 중학생때 혼자 프로그래밍을 하면서 깨달은 "셀프 코드 리뷰" 기법을 백분 활용하였는데, 놀라운 점은 해당 작업을 마치고 나면 언제나 첫번째 테스트 케이스를 실행시키기도 전에 버그의 90% 이상을 제거할 수 있었다는 점이다. (사실은 100%였던 적이 거의 대부분이다)

셀프 코드 리뷰(self code review, 또는 self code inspection)란 오류를 찾기 위해 자신의 소스 코드를 엄격하게 검사하는 것이다. 쉽게 말해, 자신의 코드를 계속 읽는 것이다. 아주 단순하다.

이것의 가치는 로버트 L. 글래스도 자신의 저서에서 언급한 바 있다. 필자와 동일한 주장을 하는 것을 보고, 무척이나 반가웠던 기억이 난다.

모니터 상에서 계속 코드를 읽는 것에 불과하지만, 이것은 사실 엄청난 집중력을 요하기 때문에 무척 피곤한 작업이기도 하다. 하지만 그러한 집중력이야말로 소프트웨어스러운 것이며, 자신이 만든 코드와의 깊은 교감을 의미한다. 그러한 과정을 거치면 코드에 내재된 문제점들이 대부분 발견되며, 첫번째 테스트 케이스를 실행하기도 전에 거의 완벽한 코드가 완성되는 것이다.

경험이 많지 않는 사람이라면 이것이 무척 신기하게 생각될 수도 있을 것이다. 신기할 거 없다. 자신이 집중하고 애정을 쏟은 만큼 보상받는, 당연한 진리일 뿐이다.

그래서 필자는 어차피 완벽할 수 없는 테스트 케이스보다, 코드를 만든 프로그래머의 집중력과 영성(靈性)을 우선시하는 '셀프 코드 리뷰'를 강력 추천한다. 그리고 셀프 코드 리뷰후 '피어(peer) 코드 리뷰'를 한다면, 그 또한 도움이 될 것이다. 물론 코드 리뷰 후에 테스트 케이스를 실행하는 것은 당연히 필요하다. 코드 리뷰를 통해 걸러지지 않는 버그가 발견될 수도 있고, 또한 코드 리뷰의 성과를 검증해야하지 않는가? ^^

그 중요성에도 불구하고 코드 리뷰가 강조되지 않는 이유는, 벤더가 이것을 제품화할 수 없고 수행 과정이 가시화되기 힘들기 때문이다. 하지만 제대로 해 본다면, 반드시 그것의 가치와 재미를 발견하게 될 것이다.

무엇보다 중요한 것은, 자신이 만든 코드와의 깊은 교감이 아니겠는가.
프로그래머인 당신은 창조자로서 자신의 피조물을 통제할 수 있다. 창조자로서의 권리를 듬뿍 누리기를.

그의 자화자찬이 역하게 느껴졌다

남들에게 인정받기 위해 자신을 자랑하는 사람들이 많다. 필자도 그렇다. 그것에는 두가지 측면이 있다.

첫째. 경쟁 사회에서 자신을 자랑하지 않고서, 어떻게 자신의 가치를 증명할 것인가? 그것은 필수적인 것이다.

둘째. 자화자찬은 자신을 정당화하는 대신, 자신의 품위를 떨어뜨린다. 프랑스의 사상가인 볼테르가 이와 비슷한 얘기를 했었다.

왜 스스로를 자랑해야만 하는 걸까?

그것은 아마도 욕심, 열등감, 불안감 때문일 것이다. 자신을 자랑하는 것은 저급함의 발로이며, 또한 인간 본성이기도 하다. 자신을 자랑함으로써, 인간은 스스로의 존재감을 확인하려고 한다.

도시의 꼭대기에서 사람들을 내려다보면, 모든 사람들은 그러한 공허한 메아리를 일방적으로 소리쳐 외쳐대고 있는 것이다. 잡음이 난무한다.

나 또한 마찬가지이다. 나는 그러한 스스로의 통속성과 추함에 눈물을 흘리며, 그 언젠가 욕심과 열등감과 불안감을 떨쳐낼 그 날을 위해 열심히 기원하며 수양을 쌓지만..

점점 더 통속화 되어가는 모습에 가련함을 느낄 뿐이다.