뛰어난 개발자
앤디 헌트가 말하는 생산성 높은 개발자
진짜 고수는 방법을 아는 사람이다
앤디 핵심은 사용하는 도구에 능숙한지의 여부가 아닙니다. 도구의 기능을 잘 살려 쓰는 것이 항상 중요하죠. 저는 vi 에디터로 펄펄 날아다니면서 짧은 시간에 일을 처리합니다. 로컬 컴퓨터에서건 다른 곳에서 SSH(보안 터미널 프로토콜)로 접속했든 상관없어요. Emacs를 쓰는 사람들도 많이 봤는데, 그걸로 어떻게 해내는지 저는 정말 모르겠지만 하여간에 그 사람 들은 Emacs의 전문가들이죠.
다들 쓸모 있는 도구들이긴 한데 제 생각에는 그 도구를 능숙하게 사용하는 것이 중요한 것이 아닙니다. 진짜 고수는 Emacs에서 펄펄 날아다니는 그런 사람이 아니라 "이런 상황이 되면 이런 도구를 써서 짧은 시간에 상황을 타개해 나갈 수 있어"라는 것을 알고 있는 사람입니다.
할 수 있는 것, 사용 가능한 것들의 카탈로그가 머릿속에 들어있는 것이 더 중요하다는 것이죠. 그게 알고리즘일 수도 있고 도구나 언어, 제품 뭐든지 될 수 있습니다. 그런 게 있고 적용할 수 있다는 것을 알기만 하면 되는 거죠. 그게 그 어떤 것보다도 생산성의 핵심이 됩니다. 1
울적해하지 않고 정면돌파한다
앤디 제 생각에는 가장 생산성 높은 프로그래머의 핵심은 많은 코드를 쏟아내는 것이나 코드를 빨리 작성하는 것이나 뭐 그런 것과는 상관이 없습니다. 이제까지 이야기한 것과는 모순되는 것처럼 들릴 수도 있겠지만 "울적해" 지지 않는 것이지요. 이런 상황을 생각해 보죠. 사용자가 말하길 이 프로그램은 X와 Y와 Z를 해야 한다고 해서 프로그램을 들 여다보는데 "오~ 여기엔 이런 더 깔끔한 알고리즘을 넣을 수 있어"라던가 "이봐~ 디자인 패턴 4인방(the Gang of Four)의 마지막 다섯 개 패턴은 최근에 써본 적이 없는데 그걸 여기 넣으면 좋겠군." 이런 말을 들으면 심난해지기 일쑤죠. 이런 종류의 "울적함", 더 좋은 표현이 생각나지 않는데 하여간에 그런 상황이 된다는 겁니다. 고객이 말한 한 가지에만 매달려 핵심이 무엇인지 고객에게 정말로 중요한 것이 무엇인지를 놓칠 수도 있고, 맨 처음 떠올랐던 솔루션을 버리지 못하고 정답이 아닌 줄 알면서도 맹목적으로 끈질기게 미련을 버리지 못하고 계속 나아가기도 합니다.
흔히 있는 컨설팅 기법인데, 솔루션을 선택할 때에는 최소한 세 가지는 검토하여 그 중 둘을 버리고 하나를 선택하게 하는 겁니다.
많은 경우 처음 생각해서 진행시킨 아키텍처나 디자인, 아이디어 같은 것들이 희석되곤 하는데 그게 "우울"해지는 거지요.
그래서 "울적해 지지 않음"이라는 말에는 최고의 프로그래머들은 순수하게 문제만을 바라보고 이를 해결할 진짜 솔루션을 갖고 막다른 골목이나 잘못된 출발 같은 것에도 "울적해" 하지 않습니다. 누구나 어려움을 당하게 마련이지만 최고의 프로그래머들은 그런 것들도 정면 돌파합니다. 빠르게 시작할 수도 있고, 시작을 느리게 하더라도 잘못된 방향 전환을 할 가능성은 훨씬 적죠. 1
에릭 브레히너가 말하는 뛰어난 개발자
에릭 브레히너의 마이크로소프트 사내 칼럼으로, 2003년 2월 1일에 작성된 글이다.
뛰어난 개발자는 자신이 무엇을 하는지 안다 뛰어난 개발자에게 "이 행이나 이 변수가 왜 여기 있습니까?" 라고 물어보면 이유를 설명한다. 때로는 ("다른 곳에서 코드를 가져와서 사용했습니다"라는 등) 이유가 다소 부실하다. 그래도 "저런, 저도 모르겠습니다. 코드가 돌아는 가네요." 라고 답하지 않는다.
뛰어난 개발자는 마법을 믿지 않는다 '자신이 무엇을 하는지 안다'와 같은 의미다. 뛰어난 개발자는 블랙박스로 감춰진 API, 컴포넌트, 알고리듬을 불편해 한다. (단순히 문자열을 이어주는 클래스가 \(O(n^2)\) 성능을 자랑하거나 메모리 할당에 실패하는 등) 잘못된 가정이나 '허술한' 추상화로 골탕 먹지 않도록 사전에 코드가 돌아가는 방식을 파악한다.
뛰어난 개발자는 고객과 비즈니스를 이해한다 7장 '인생은 공평하지 않다'라는 칼럼에서 자세히 다룬 내용이다. 뛰어난 개발자는 무엇이 중요한지 안다. 우선순위를 매겨서 적절한 타협점을 찾는다.
뛰어난 개발자는 자신보다 고객과 팀을 우선한다 뛰어난 개발자에게 사소한 업무란 없다. 사소한 고객도 없다. 모든 업무가 중요하고 모든 고객이 중요하다.
뛰어난 개발자는 도덕과 윤리를 타협하지 않는다 개인에 따라 차이는 있지만, 뛰어난 개발자는 업무를 달성하는 방법과 다른 사람을 대하는 태도를 중히 여긴다. 알고리듬을 선택하든 이메일을 작성하든, 자신에게 높은 기준을 적용하고 핵심 가치를 타협하지 않는다.
뛰어난 개발자는 우수한 대인 기술과 의사소통 기술을 보유한다 인기 있는 토크쇼 사회자가 될 만한 개발자는 별로 없지만, 뛰어난 개발자는 다른 사람과 어울려 일하고, 주변 사람을 존중하며, 자신의 의사를 분명하고 적절하며 효과적으로 전달한다. 뛰어난 개발자는 (마음만 먹으면 가능하지만) 남을 괴롭히거나 위협하는 대신 협업한다(8장 '모 아니면 도 협상'이라는 칼럼에서 좀 더 자세히 다룬다).
뛰어난 개발자는 폭넓고 협조적인 인맥을 보유한다 뛰어난 개발자는 다른 사람의 뛰어난 능력을 알아본다. 그래서 위대한 사람들은 서로에게 끌린다. 그들은 서로를 지지하는 인맥을 순식간에 구축해 개인으로 달성하기 어려운 효율을 발휘한다.
그 외에도 뛰어난 개발자는 품질을 중시하고, 멘토로서 다른 사람을 끌어주며, 설계 능력이 탁월하다.
뛰어난 개발자를 정의하는 특성 중 어느 요소도 단순한 숫자 값으로 측정하기란 불가능하다. 2
참고문헌
- HARD CODE / 박재호 역 / 에이콘출판사 / 발행 2009년 06월 30일 / 원제 : I. M. Wright's Hard Code
- 세상을 뒤흔든 프로그래머들의 비밀 / 에드 번즈 저 / 김도균 역 / 정보문화사 / 초판 1쇄 발행: 2010년 02월 19일 / 원제: Secrets of the Rock Star Programmers: Riding the IT Crest