김석주의 블로그

Microsoft 입사 초기에 우연히 사내 웹사이트에서 발견하고 나에게 적지 않게 영향을 주었던 “메일”이 있다. 빌 게이츠가 지금부터 10년도 더 전인 1997년에 전체 직원들에게 보낸 메일이다. 자신이 생각하는 “좋은 직원의 10가지 특징(Ten attributes of a good employee)”이 무엇인지를 적은 메일이다. 그동안 혹시 대외비가 아닐까해서 블로그에 쓰지 않았는데, 오늘 보니 어떤 사람이 벌써 블로그에 올려놓았다. 지금은 오피스를 여러번 옮겨 잃어 버렸지만, 초기엔 이 메일을 프린트해 책상 앞에 붙혀 놓곤 했다.

개인적으로 이 10가지 중에서 가장 크게 내 기억에 자리 잡고 있는 것은 첫번째인 “You have to use the products yourself”이다. 어찌 보면 당연한 것이지만, 사실 소프트웨어를 만들다 보면 이 점에 소홀해지기 쉽다. 당장 프로그래밍에 바쁘다 보면 실제 고객들이 사용하는 것처럼 내가 고객이 되기가 쉽지가 않다. 사실 내가 이 블로그에서 마이크로소프트 제품들에 대해 계속 업데이트하는 이유도 이것 때문일 것이다.

내가 먼저 사용해 보지도 않으면서 다른 사람들이 사용하기를 기대할 수 없는 것이다. 그래서 내가 먼저 베타 버전이던 알파 버전이던 먼저 사용해 보는 것이 중요하다. Microsoft 의 전통 중에 “Eat dogfood”라는 것이 있다. 이것은 제품을 공식 발표하기 전에 직원들이 먼저 사용해 보는 것이다. 아직 완성이 되지 않은 버전을 사용하기 때문에 “개밥(Dogfood)를 먹는다”라고 표현한다. 윈도우 7도 그렇고 오피스 2010도 그렇고 오래전부터 벌써 많은 직원들이 설치해 사용하고 있는 것도 그 이유에서다.

그리고 7번째 “a good employee will want to learn the economics of the business” 역시 소프트웨어 엔지니어로써 소홀하기 쉬운 점을 이야기해 주고 있다. 아무리 뛰어난 기술과 멋진 기능을 가진 제품이라 할지라도 경제성이 없으면 오래 가지 않아 제품 개발이 종료될 것이다. 그렇기 현재 일하고 있는 산업의 경제가 어떻게 돌아가고 있는지 경쟁 회사가 어떤 일을 하고 잇는지 그리고 앞으로 경제가 어떻게 될 것인지 항상 신문이나 뉴스를 통해 배우는 자세가 필요하다 할 수 있겠다.

다음은 10가지 특징은 간단하게 번역하게 놓은 것이다. 전체 본문을 보시고 싶으신 분은 링크된 블로그에서 보기 바란다. 사실 각 특징의 맥락을 보려면 전체 본문을 보는 것이 좋을 것이다.

1. 자신의 회사나 그룹의 제품에 대해 호기심을 갖는게 필요하다. 자신이 먼저 제품을 사용하여야 한다.
2. 고객이 어떻게 제품을 사용하는지 논의할 때 고객을 참여시키는 것이 중요하다.
3. 고객의 필요를 파악한 후에는 제품이 어떻게 고객을 도울 수 있을지 생각하는 것을 즐길 수 있어야 한다.
4. 각 직원은 회사처럼 장기적인 계획을 가지고 자신을 개발시켜 나가는 것이 필요하다.
5. 전체적인 안목을 유지하면서 자신만의 특화된 지식이나 기술을 갖는게 중요하다.
6. 새로운 기회에 도전할 수 있는 유연성을 가져야 한다.
7. 좋은 직원은 경제에 대해서도 알기 원해야 한다.
8. 경쟁자에 대해 집중해야 한다.
9. 머리를 사용해야 한다.
10. “정직함”, “윤리”, “Hard working”의 중요성을 간과해서는 안된다.

오늘 Twitter에 링크된 블로그 중에 “소프트웨어 아키텍트가 알아야 할 97개의 조언(97 things every software architect should know)”라는 것이 있었다. 이미 책으로 발간된 것의 요약을 블로그에 올려 놓은 것이다. 소프트웨어 아키텍트에 관심있는 사람들에게 도움이 될만한 것들이라 연결해 본다.

97 Things Every Software Architect Should Know – The Book

이 중에서 개인적으로 눈에 띄는 몇가지는 다음과 같다.

2. 단순화시켜라.
5. 아키텍처란 균형을 잡는 일이다.
10. 계량화시켜라
12. 모든 것을 만족시키는 한가지 솔루션은 없다.
21. 스케쥴링 실패를 피하라
27. 아케텍처에 “나”란 없다.
40. 퍼포먼스가 전부다
75. 무엇보다도 아키텍트는 개발자이다.
…

소프트웨어 프로젝트를 진행하는데 있어서 가장 어려운 점 중에 하나는 개발 스케쥴을 잡는 것과 프로그램 디자인을 하는 부분이다. 그동안 많은 프로젝트를 진행하면서 느낀 점들이 많았었는데, 요새 읽고 있는 책인 “More Joel on Software”에서 공감가는 글이 있어 인용하고 개인적인 생각들을 써보고자 한다. (참고로 More Joel on Software는 Joel on Software의 속편으로 최근의 글들을 모아 놓은 책이다.) 이것들이 모두 프로젝트의 스케쥴을 정하는데 사용할 수 있는 금과옥조가 될 수는 없지만, 최소한 시행착오를 줄이는데 도움을 줄 수 있을 것이다.

1. 실제 코딩을 하는 프로그래머만이 예상 개발 스케쥴을 정할 수 있다.
   • 관리자 조직에서 만들어내는 스케쥴은 실패로 끝날 확률이 높다. 프로그래머만이 프로젝트에 필요한 여러가지 과정을 찾아내 스케쥴을 정확히 만들어 낼 수 있다.
   • [개인 생각] 조엘이 책에서 이야기 한대로 프로그래머는 태생적으로 스케쥴 잡는 것을 싫어 한다. 본인 역시 스케쥴 잡는 것이 프로젝트 전체 일정 중에서 가장 귀찮아 하는 부분이다. 일단 잘 맞지도 않을 스케쥴을 왜 잡을까 하는 회의적인 생각에서 부터, 요구 사항이 명확하지 않아서, 스케쥴에 쫓기면서 일하기 싫어서, 프로그래머는 코딩만 잘 하면 되지 하는 생각이 들어서, 등등 여러가지 이유 등으로 싫어하는 것이다. 그렇지만 회사로써는 스케쥴이 없는 프로젝트는 밑빠진 독이 불과하다. 그렇기 때문에 프로그래머도 생각을 바꾸어야 한다. 디자인하고 코딩하는 것만이 능력이 아니라 스케쥴을 구체적으로 잘 만들어 내는 것도 프로그래머의 능력이라는 생각을 가져야 한다. 스케쥴링을 잘 한다고 좋은 프로그래머인 것은 아니지만, 능력이 있는 프로그래머는 스케쥴링을 잘 할 수 밖에 없다. 왜냐 하면 자신이 프로젝트에서 해야 하는 부분을 미리 예측할 수 있어서 구체적인 Work Item을 만들어 낼 수 있기 때문이다. 다만 각 Work Item에 소요되는 시간을 정확하게 예측하기는 힘들 수 있다. 그렇지만 최소한 프로젝트를 완료하는데 필요한 모든 Work Item을 도출해 되면, 관리하는 입장에서는 프로그래머들을 재배치하거나 프로젝트 스펙을 줄이는 등의 여러가지 방법을 찾아낼 수 있을 것이다.
2. 버그가 발견되면 버그를 고치는데 사용하는 시간을 스케쥴에 반영하라.
   • 버그는 언제든지 발견될 수 있기 때문에 버그에 대해 스케쥴을 미리 잡아 놓을 수 없다. 그렇지만 버그를 고치되 사용했던 시간은 스케쥴에 반영하도록 한다.
   • [개인 생각] 버그는 스케쥴에 영향을 미치는 가장 큰 요인 중에 하나다. 그렇지만 “Bug is bug”… 그것 역시 스케쥴에 반영해야 한다. 처음부터 디버깅을 위한 시간을 할당해 놓는 것도 좋은 아이디어다. 어짜피 “Code Complete” 후 테스팅에 들어가면 버그가 발견될 수 밖에 없기 때문이다.
3. 관리자가 스케쥴을 줄이도록 만들지 말라.
   • 신참 매니저들은 자신이 프로그래머들에게 동기 부여를 주어서 프로젝트를 좀더 빨리 끝내도록 만들 수 있다고 믿는다. 그렇지만 이것은 멍청한 짓이다. 스케쥴에 쫓기게 되면 프로그래머는 우울증에 빠지고 동기 부여가 실패하게 되어 있다. 프로그래머는 스케쥴에 비해 빨리 진행된다고 느낄 때 좀더 생산적이 되고 활기가 넘치게 된다.
   • [개인 생각] 동감하는 내용이다. 항상 관리자는 자신의 권한을 이용하여 프로그래머에게 압력을 행사하여 스케쥴을 줄이고 싶어하는 유혹에 빠지기 싶다. 그리고 그것이 자신의 능력이라고 생각한다. 그렇지만 이는 프로젝트의 Quality와 프로그래머의 생산성에 영향을 주게 되며, 결정적으로 프로그래머가 정해 놓은 스케쥴을 믿지 못하겠다는 것을 선언하는 것과 마찬가지이다. 프로젝트 스케쥴 재조정은 항상 이루어질 수 있지만, 항상 프로젝트 구성원이 이해할 수 있는 근거(내부적이든 내부적이든)를 가지고 있어야 하며, 관리자의 공명심에서 시작하면 안된다고 생각한다.
4. 개발 스케쥴은 나무 블록을 담는 상자와 같다.
   • 나무 블록이 너무 많으면 상자를 늘리던가 나무 블록을 줄여야 한다.
   • [개인 생각] 프로젝트에서 가장 어려운 부분 중에 하나이다. 프로젝트에 필요한 Work Item을 모두 만들어내고 시간도 산출해 내었는데, 처음 원했던 프로젝트 기간을 초과하는 경우 어떻게 해야 할까? 이때부터 관리자의 능력을 보여주어야 한다. 고객과 다시 의논해 Work Item을 줄이거나, 프로그래머를 재배치하거나, Work Item의 우선 순위를 정해서 스케쥴을 다시 만들어야 할 것이다.

(From More Joel on Software, “Evidence Based Scheduling” P. 167-158)

PS. 마지막으로 여기에 한가지 덧붙이고자 하는 것은… 이 조언들이 효과를 발휘하기 위한 기본 조건들이 있다. 그것은 프로그래머의 능력과 정직성이다. 프로그래머는 자신이 할 수 있는 일과 할 수 없는 일을 정확히 알고 있어야 하며, 그것을 솔직하게 이야기할 수 있어야 한다. 프로젝트가 마지막에 어려움에 빠지는 여러가지 이유 중에 하나는 프로그래머가 막판에 일을 마무리 짓지 못하고 계속 시간을 잡아먹는다는 것이다. 물론 처음부터 예상치 못한 문제를 만날 수 있다. 그런 경우 프로젝트 중간 중간에 관리자에게 솔직하게 이야기해야 한다. 물론 해결하기 위해 계속 노력해야겠지만, 처음 예상했던 시간을 넘어선 경우에는 솔직하게 다른 사람에게 도움을 요청해야 한다. 그게 바로 팀웍인 것이다.

또한 프로그래머는 처음 스케쥴을 정할 때 너무 추상적으로 잡거나, 너무 넉넉하게 시간을 잡아서는 안된다. 너무 추상적으로 잡으면 스케쥴에 문제가 생긴 경우 관리자가 인력을 재배치하거나 스펙을 줄일 수 없게 된다. 프로그래머 본인도 일의 영역이 애매해져서 막판에 가서 시간에 쫓기게 된다. 그리고 프로그래머는 정직하게 자신의 능력으로 할 수 있는 각 Work Item의 시간을 정해야 한다. 그러한 정직함은 관리자와 신뢰를 쌓을 수 있게 하며, 관리자로 하여금 프로그래머의 스케쥴에 대한 전적인 믿음을 갖게 한다.