며칠 전에 한계를_넘어서를 다시 읽었다. 그리고 요 며칠 생각을 하다보니 상세한 일정이 왜 나쁜지를 좀더 명확히 설명할 수 있을 것 같다.

보통 일정 관리란 걸 강하게 하는 조직들을 보면 일을 작은 Task로 쪼개고 그 Task별로 사람을 할당하고 Task별 일정을 잡는다. 그래서 Task들이 chain처럼 이어지게 만든다. 이런 식의 일정 압박이 주어지기 시작하면 일정을 지키지 못했을 때 죄인 취급을 당할 수 있기 때문에 자신의 Task를 정해진 시간에 끝마치는데 주력하게 된다. 그러면 두 가지 문제가 발생한다. 하나는 다른 사람의 업무에 관심을 끊게 되는 것이다. 커뮤니케이션 비용도 더 부담이 되기 때문에 커뮤니케이션을 더 하지 않으려는 경향이 생기고 그러다보면 conflict가 커져서 나중에 더 큰 커뮤니케이션 비용을 치르거나, 혹은 결함을 덮어두고 지나가게 된다. 협업이 깨지는 것이다.

또 다른 문제는 원래 일정을 상세하게 잡았던 목적을 달성할 수 없다는 것이다. 보통 일정을 상세하게 잡는 이유는 프로젝트를 빨리 완성하기 위한 것이다. 팀원들이 최선을 다할 것이라는 믿음이 없기 때문에 일정을 압박해서 열심히(?) 일하게 만들면 빨리 끝낼 수 있을 것이라고 기대하는 것이다. 그러나, 이런 일정 압박에 시달리는 팀원들은 개별 Task에 대한 예측에 여유 시간을 많이 포함하게 된다. 이것이 한계를_넘어서에서 말하고 있는 것이다. 예를 들어 어떤 일이 10시간에 끝낼 가능성이 50% 정도라고 하자. 그러면 대개 95%의 확률로 끝낼 수 있는 시간은 30시간 이상이다. 만약 일정을 정하는 것이 아니라 단순히 예측만 하라고 한다면 대부분의 사람들은 50% 지점, 혹은 6~70% 지점 정도로 예측값을 내놓을 것이다. 아마 10~15시간 정도일 것이다. 그런데 일정에 대한 압박이 심하다면 대부분 95% 지점의 예측치, 즉 30시간을 내놓게 된다. 만약 이런 일들이 5개가 chain으로 연결되어 있다고 해보자. 이 일들을 task별로 쪼개서 일정 관리를 하지 않는다면 아마 50%의 확률로 50시간에 끝날 것을 예측할 수 있을 것이다. 하지만 task별로 쪼개서 심한 일정 압박을 넣는다면 다들 30시간으로 예측할 것이고 이 프로젝트는 최소한 150시간이 걸릴 것이다. 각각의 task에서 잡은 buffer가 합쳐지지 않으면 buffer로 기능하지 못하고 실제 작업 시간이 되어 버리는 것이다.

여기에 연관되는 또 하나의 부작용이 있다. 예를 들어 일정이 30일 남았다고 하자. 근데 10일 걸리는 어떤 일이 있다. 근데 이 일은 22일째부터 시작할 수 있을 것으로 예상되지만 더 늦게 시작할 수도, 더 일찍 시작할 수도 있다. 그러면 가장 합리적인 선택은 상황을 봐가면서 22일째를 전후해서 그 10일짜리 일을 하는 것일 것이다. 그러면 아마 일정이 2일 정도 미뤄질 수는 있겠지만 10일 짜리 일이 그만한 가치가 있다면 좋은 선택이 될 것이다. 근데 30일이라는 일정이 못 박혀 있다면 어떻게 될까. 아마도 팀원들은 최악의 경우를 산정해서 22일 이전에 시작할 가능성을 염두에 두지 않을 것이다. 그럼 10일 짜리 일은 다음 텀으로 미뤄진다. 그러면 실제로 여유 시간이 8일치만큼 남더라도 활용할 수 없고 10일 짜리 기능이 고객에게 전달되는 것은 2일이 아니라 10일이 미뤄질 것이다. 아니, 어쩌면 30일이 더 미뤄질 것이다.

이런 일이 반복되다보면 고객의 만족은 뒷전이 될 수 밖에 없다. 아니면 팀원들의 삶이 뒷전이 되거나. 아니, 보통은 둘 다일 것이다. 거기에 더 나쁜 것은 일정에 대한 압박이 일정은 맞추게 하지만 TimeToMarket은 더 커지게 만든다는 것이다.

그래서일까, BUILT_to_LAST에서는 상세한 계획은 반드시 실패한다라고 말하고 있다. 상당히 설득력이 있는 주장인 것 같다.

무릎팍도사에 심형래가 나왔다. 역시 왕년의 개그맨 답게 여전히 웃기기도 잘한다. 심형래, 정말 대단한 사람이라는 생각이 든다. 내가 아직 누군가가 존경할 만하다는 생각을 해본 적이 없는데 심형래는 정말 존경스럽다. 심형래가 [:D-War]를 보면서 두 번 울었는데 한 번은 This is Korean legend. 또 한 번은 마지막에 아리랑 나올 때라고 한다. 나도 사실 그 때 살짝 감동했다. 특히 This is Korean legend. 사실 [:D-War]가 아주 높은 수준의 영화는 아니지만 또 재미 없는 영화는 아니다. 그리고 심형래가 한발 한발 나가는 모습을 보면 다음 작품에는 기대를 더 해도 될 것 같다.

그 동안 창업해서 일하면서 배운 것이 참 많지만 프로그래밍에 대해서도 깨달음이 좀 있었던 것 같다. 사실 내 프로그래밍 실력이 이제 거의 정점에 다다랐다고 자만했던 적도 있었다. 하지만 다시 성장은 끝이 없다는 것을 느끼게 되니까 참 기분이 좋다. 그 동안 얻은 깨달음을 정리해본다면...

1. 멍 테스트
   • 생각 없이 코드를 약간 수정하고 실행해서 목적 의식 없이 이리저리 테스트 해보는 행동. 태근이를 통해서 발견한 패턴이지만 나 스스로도 엄청 자주 빠지는 함정이다. 피로할 때 자주 나타나는 현상이다. 생각하기가 싫으니까 그냥 이리저리 단순 테스트를 하고 생각 없이 코드를 고치면서 우연히 돌아가는 코드가 나오길 비는 심리가 있는 듯하다. 당면 목표에 대한 인식이 잘 안되어 있거나 문제가 잘 안 풀릴 때, 알고리즘을 명확하게 생각하지 않고 코드부터 만들 때 흔히 나타난다. 해결책은 의외로 쉽다. 이런 현상이 자신에게 생긴다는 것을 인지하는 것만으로도 큰 변화가 있다. 나도 이 패턴을 인지하고 나서 문제 해결 능력이 엄청나게 발전한 것 같다. 멍 테스트를 하다가도 금방 깨어난다. 그리고, 몇 가지 수단들이 있다. 가장 훌륭한 도구는 물론 TDD다. 하지만 지금처럼 TDD를 못하는 상황에서도 TDD의 장점을 끌어올 수 있다. TDD에서 테스트를 작성하듯이 이 코드가 맞다면 어떻게 되어야 하는지를 명확하게 정의해두고 출발하는 것이다. 그리고 실행할 때는 그것만 검증하고 다른 버그를 찾기 위한 시도는 따로 안하는 게 좋다. 우연찮게 버그를 찾더라도 그 버그에 대한 대응을 바로 하는 것은 좋지 않다. 문제가 잘 안 풀릴 때 일단 컴퓨터 앞을 벗어나는 것도 좋은 방법이다. 컴퓨터 앞에 앉아 있으면 깊이 있는 생각 없이 기계적인 코드 변경과 테스트만 반복하게 된다.
2. Do not extract method

   • 이클립스의 자동 리팩토링 기능 중 가장 프로그래머들이 좋아하는 것이 아마 rename과 extract method일 것이다. 그리고, 가장 남발하는 리팩토링이기도 하다. 나 역시 긴 메소드를 보면 일단 extract method부터 생각한다. 하지만, 이것도 생각 없이 기계적으로 하게 되면 더 나쁜 코드를 만들게 된다. 규영이가 언젠가 말한 바 있는데 메소드는 그 자체가 GoTo의 문제점을 해결한 것이 아니다. GoTo의 문제는 코드의 순서와 실행 순서가 맞지 않아서 사람이 코드를 읽어 내려 가다가 다른 곳으로 점프해서 봐야 하기 때문에 사고의 흐름이 끊긴다는 것이다. 그런데, extract method를 기계적으로 하게 되면 똑같은 문제가 생기는 것이다.

     그럼 이 문제는 어떻게 피할 수 있을까? 사실, 이 문제도 쉬운 문제다. 리팩토링의 기본 원칙에만 충실하면 된다. 중복을 제거하고 의도를 드러내는 것이다. 이 두 가지 목적을 만족시키지 못하는 extract method는 메소드가 아무리 길어도 해선 안된다. 특히 주의해야 할 것은 의도를 드러내는 리팩토링을 해야 한다는 것이다. extract된 메소드는 가서 보지 않고도 무슨 일을 하는지 알 수 있어야 한다. 가서 봐야 하면 GoTo와 똑같은 문제가 생기는 것이다. 이 문제는 메소드 작명과도 상관이 있다. 이벤트 핸들러 이름 짓는 걸 보면 onClick 핸들러의 이름을 _onClick이나 clickHandler 등으로 짓는 경우를 많이 보게 되는데 이것 역시 GoTo의 문제점을 고스란히 안고 있다. 실제로 그 메소드가 하는 일을 메소드 이름에 담아야 한다. 클릭했을 때 다이얼로그를 띄워 준다면 onClick 핸들러의 이름을 showDialog 등으로 지어야 하는 것이다. 결국 의도를 드러낸다는 것은 더 accountable한 코드를 만든다는 것이다. http://c2.com/cgi/wiki?MethodsShouldBePublic , http://jania.pe.kr/wiki/jwiki/moin.cgi/MethodsShouldBePublic 도 도움이 될 것이다.

3. 자동화된 TDD가 정말로 불가능하거나, 비효율적인 경우도 있다. 그러나, 그런 경우에도 TDD의 장점을 활용할 수 있다.
   • 예전에는 어떤 분야든 자동화된 TDD가 가능할 꺼라고 생각했다. 하지만 이제 생각이 좀 바뀌었다. GUI 테스팅에 대해서 여러 가지 이야기가 많은데, 이번에 플래시 애플리케이션 개발을 해보면서 느낀 것은 이 분야를 자동화시키긴 아주 어렵다는 것이다. GUI 툴킷을 이용해서 GUI 애플리케이션을 만드는 거라면 꽤 높은 수준의 자동화가 가능하다. 그러나, GUI 툴킷 자체를 만들어야 한다면? 거의 불가능에 가까운 도전이 될 것이다. 이걸 제대로 해낸 사람이 있다면 가서 한 수 배우고 싶다. 하지만, 지금까지 내가 판단하기로는 이건 정말 쉽지 않다. GUI 튜닝도 마찬가지, TDD의 영역이 아니다. 하지만, 그래도 TDD의 장점은 살릴 수 있다. xUnit 없이도 TDD를 할 수 있다. TDD의 장점은 목표를 먼저 명확히 정의한다는 것(=테스트를 작성하는 것)이다. TDD에 대한 오해 중 하나가 TDD를 하면 별 달리 생각하지 않고도 반복적인 실행을 통해서 코드를 만들어갈 수 있다는 것이 있다. 하지만, 이게 가능한 이유는 테스트를 작성하기 때문이다. 테스트를 작성하려면 문제를 적절한 크기로 쪼개야 하고 또 어떻게 동작해야 하는지를 명확하게 정의해야 한다. 이 과정을 거치기 때문에 이후의 과정이 쉬운 것이다. 그래서 TDD를 할 때 제일 많이 생각하고 시간을 들여야 하는 부분은 테스트를 만드는 시간이다. 이런 면에서 BDD는 유익하다. 이 점만 잘 인지하고 있으면 테스트 자동화 없이도 얼마든지 TDD의 장점을 활용할 수 있다. 물론 자동화되어 있을 때처럼 빠르고 편하지는 않지만 안하는 것보다는 월등히 좋은 결과를 낼 수 있다.

도요타_방식을 읽는 중이다. 읽다보니 그냥 피상적으로 들어왔던 것보다 훨씬 임팩트가 컸다. 정말 대단한 기업이다. 한 편으론 서글픈 생각도 든다. 자동차 기업도 저렇게 진보적인데 IT 기업들은 왜 이런가하는 생각에... 아니면 훨씬 오래된 산업이기 때문에 더 진보적인 것일까?

건질 만한 내용이 많다.

문제가 생기면 즉각 멈추고 문제를 해결하라. 이건 내 스타일하고도 맞는 것 같다. 이번 프로젝트 하면서도 문제가 느껴지면 언제든지 즉극 중단하고 문제 해결에 나서려고 노력했다. 늘 호응이 좋았던 건 아니지만 성과는 꽤 있었던 것 같다.

결정은 천천히, 실행은 신속히. 도요타에서는 어떤 의사결정을 내릴 때 모든 대안을 철저히 검토한 후에 결정을 내린다고 한다. 그냥 신중히 결정하는 정도가 아니라 모든 대안을 검토하는 것이다. 대신 결정을 내리면 신속하게 진행한다. 스프링노트를 하면서도 이런 필요성을 좀 느꼈었다. 당시 우리는 결정의 신속성을 지나치게 중요하게 생각해서 의견이 대립하면 그냥 시간에 쫓긴 결정을 내리곤 했다. 그리고 이상한 것은 일단 이렇게 해보고 나서 다시 생각하자라고 했던 결정들은 별다른 검토도 없이 그냥 그대로 가면서 이제 이건 이렇게 결정하고 제발 다시 이야기하지 말자라면서 내렸던 결정들은 얼마 안가서 뒤집혔다. 언젠가 권일이가 해준 말, 임시로 내린 결정이 제일 오래 간다라는 말이 와 닿는다.

이렇게 된 데는 Agile에 대한 오해가 많이 작용했다. Agile은 안 쓸 기능을 미리 생각해서 만드느라 시간 낭비하지 말자는 것이고 예측할 수 없는 부분까지 Design Up Front를 하지 말자는 것이지 대안 검토를 대충하고 일단 실행에 옮겨보자는 아니다. XPE2에도 이 부분을 한 장을 할애해서 설명하고 있는데 실행이 필요한 이유는 경험 없이 제대로 설계할 수 없는 경우가 있기 때문이다. 그런 경우에 일단 조악하게 디자인해서 실행에 옮겨 본 후에 redesign을 하는 것이 더 좋은 결과를 낳는다는 것이다. 그래서 만약 이미 경험이 쌓여 있거나 직관 등을 통해 좋은 설계를 해낼 수 있는 경우에는 이런 진화적인 과정을 거칠 필요 없이 바로 DesignUpFront로 갈 수 있는 것이다. BigDesignUpFront의 반대는 NoDesignUpFront가 아니라 SmallDesignUpFront가 될 수 있는 것이다. 이미 높은 확률로 예상되는 위험이 있고 그 위험을 피해갈 방법도 있다면 그걸 쓰지 않을 이유가 무엇인가. 종종 Agile 주의자들이 극단에 빠지는 경향이 있고 또 그로 인해 반 Agile 진영(?)으로부터 비판도 많이 받는데 실제 Agile 고수들(?)의 책이나 메일링, 위키등에서의 발언을 보면 무언가 중용을 지향하는 듯한 느낌이 든다.

또, Agile에서 무언가를 실행에 옮긴다는 것은 꼭 그것이 결정되었음을 의미하진 않는다. 오히려 해보고 결정한다는 의미가 강한 것이다. 그런데 개발 기간 중에는 그런 여유를 찾을 수 있는 사람이 많지 않다. 보통 의견이 대립되는 문제를 만나서 이야기하다가 일단 한 번 해보고 결정합시다라고 하고 나면 나중에 그 실행이 일차로 완료되었을 때 그 문제를 다시 논의하는 것이 아니라 다음 기능을 이야기하게 된다. 그러면 개선은 물 건너 가는 것이고 실험은 결정이 되버리고 agile은 실종된다. 그러면 완성도도 완성도이거니와 자신이 제시한 대안을 검토해볼 기회를 갖지 못한 사람들은 사기도 떨어지고 불만이 쌓인다. 그래서 스프링노트는 가장 자신의 의견을 많이 반영한 사람조차 만족해하지 않는 상황으로 갔었던 것일 테고.

사실 agile을 fast로 이해하는 사람이 많은데 이게 많은 부작용을 가져오는 것 같다. agile은 fast가 아니라 early와 often이다. 빨리라는 말 자체를 좀 자제할 필요가 있다. 이런 agile에 대한 오해들, 그리고 일정 압박 등이 복합적으로 작용하다보니 의사 결정을 빨리 해야 한다는 압박을 이기지 못한 것이다.

그런 면에서 결정을 빨리 내려야 한다는 압박이 분명히 있을 텐데도 신념을 갖고 모든 대안을 검토하는 도요타의 문화는 분명 쉽지 않은 것이고 그만큼 대단한 가치를 가지는 것 같다. 그리고 그럼에도 불구하고 다른 어떤 자동차 회사보다도 짧은 시간에 신차를 설계하고 생산한다.

실제로 사람들이 결정이 늦어지면 초조해하고 시간 낭비로 느끼는 이유는 회의 때문이다. 회의 시간이 길어지면 점점 지치고 시간 낭비로 느끼면서 우리는 결정에 시간을 낭비하고 있다. 이러느니 차라리 뭔가 대충이라도 결정하고 일단 가 보자.라는 생각을 하게 되는 것이다. 하지만 의사결정이란 건 길게 봐야 한다. 꼭 한 번의 회의에 결정을 모두 내려야 한다는 생각을 떨쳐 버릴 필요가 있다. 당장 문제가 되는 그 결정을 내리지 않아도 틀림 없이 이미 결정되서 실행해야 할 다른 할 일이 많이 쌓여 있다. 일단은 그 일들을 하면서 중간 중간에 실험들을 하고 생각을 하면 되는 것이다. 그리고 다시 모여서 검토한 대안들을 이야기하고 또 결론이 안나면 다음 회의로 미루면 된다. 결정을 연기한다고 해서 회의를 길게 할 필요는 없다. 회의는 짧게 하면서 결정은 계속 미룰 수 있고 낭비되는 시간은 줄일 수 있다. 이것은 의사결정을 빨리 하느냐 아니냐의 문제가 아니라 회의 기술의 문제인 것이다.

이건 부분 최적화의 문제이기도 하다. 사람들은 보통 일을 할 때 하나하나의 task에 들어가는 시간을 절약하면 전체 시간도 절약될 꺼라고 생각한다. 그래서 의사 결정을 빨리 하면 결국 개발 기간도 단축될 것이라고 가정하는 것이다. 하지만 이것은 사실이 아니다. 잘못된 의사 결정의 대가는 그 의사 결정에 들어간 시간을 훨씬 상회할 수 있다. 실제로 많은 프로젝트가 잘못된 의사 결정의 대가를 호되게 치른다. 우리도 이번 프로젝트 초기의 잘못된 의사 결정이 끝까지 우리를 괴롭히고 있다. Django Template 따위 쓰지 말았어야 했는데--; 이 부분에 우리가 한두 시간만 더 공들여서 의사 결정을 했다면 지금 10여 차례 반복된 10분~1시간의 시간 낭비를 완전히 없앨 수 있었을 것이다. 실상 그 때 충분히 검토할 만한 근거가 있었음에도 일단 가보자라는 생각에 나도 과감한 결단을 내리지 못했었다. 이런 일은 대부분의 프로젝트에서 비일비재할 것이다. 어쨋건 중요한 것은 전체 시간이지 개별적인 task에 들어가는 시간이 아니라는 것을 인식해야 한다.

올바른 프로세스가 올바른 결과를 만든다. 많은 사람들이 사람이 프로세스보다 중요하다는 말을 한다. 하지만 그런 사람들이 조직을 개선시키는 모습은 본 적이 없다. 어쨋든 사람은 잘 뽑아야 하는 것이지만 이미 뽑은 사람들에게 능력 발휘를 하게 해주는 것은 프로세스다. 도요타가 특별한 것은 프로세스를 개선시키는 주체가 경영진이 아니라 모든 직원이라는 사실이다. NHN의 경우는 끊임 없이 조직 개편을 하고 프로세스 개선을 추진하지만 그 과정은 경영진이 독점하고 평사원은 의견을 개진할 공간조차 주어지지 않는다. 이런 상황에서 제대로 된 프로세스 개선이 이루어질 리 없다. 그런 점을 생각하면 도요타는 정말 탁월하다.

아, 100분 토론보고 있는데 진중권 정말 실망이다. 영화에 대한 인식이 저것 밖에 안되나. 나도 참 영화를 모르는 편이지만 평론가라는 사람들이 액션 영화에 대한 전문성이 너무 없다.

난 심형래 정말 대단하다고 생각한다. 무엇보다 그런 대작을 제작할 비용을 조달할 수 있었다는 것이 그가 대단한 사람이라는 강력한 증거다. 많은 실패를 겪었음에도 끊임 없는 열정을 보여줬고 중간 중간에 조금이나마 미래를 볼 수 있는 성과를 보여줬으니까 이만한 큰 작품을 만들 수 있는 투자를 받은 것 아니겠는가.

금발이 너무해2. 몇 번을 봐도 너무 재미있다. 특히 마지막 엘 우즈의 연설은 몇 번을 봐도 감동이다. 부당한 행위를 보면서 그 과정에 개입하지 않는다면, 자신의 목소리를 내지 않고 누군가 대변해주길 기대한다면 자신의 신념마저 잃어버리고 만다는 이야기. 목소리를 내야 한다는 말. 시민의 한 사람으로 국회에 나가서 연설하고 법안까지 통과시켜버린 이 에피소드가 실화에 기반한 것이라는 걸 생각하면 가끔 난 뭐하고 있나 하는 생각이 들기도 한다.

나도 신념이 있다. 민주적인 조직일수록 성공 가능성이 더 높다는 것이 내 신념이다. 기업도 마찬가지다. 정치 체체에서 가장 효율적인 체제로 민주주의를 채택했는데 기업이라고 다른 체제를 선택해야할 이유는 별로 없다. 실제 사례에서도 성공한 기업일수록 권력이 더 평등하게 분배되어 있는 경우가 많다. 이 점은 이미 많은 경영 서적에서 지적하고 있다. 그럼에도 불구하고 왜 그런 기업은 이토록 찾아보기 힘든 것일까.

꽤 오랫동안 이런 신념을 소리 내어 말하지 못했다. 실상 오픈마루에는 이런 생각에 공감하는 사람이 별로 없는 것 같다. 그러니 몇 번 목소리를 낸 적은 있지만 그 때마다 커다란 차이를 확인했을 뿐이다. 전반적으로 조직이 굴러가는 모습에서도 그 간격이 느껴졌고. 어쩌면 더 심각한 차이는 지금도 충분히 민주적이라고 생각하는 사람이 많다는 것인지도 모른다. 그러다보니 이젠 내 목소리를 내기가 힘들다. 내 목소리를 다시 찾으려면 어떻게 해야 할 것인가.