도요타_방식을 읽는 중이다. 읽다보니 그냥 피상적으로 들어왔던 것보다 훨씬 임팩트가 컸다. 정말 대단한 기업이다. 한 편으론 서글픈 생각도 든다. 자동차 기업도 저렇게 진보적인데 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분 토론보고 있는데 진중권 정말 실망이다. 영화에 대한 인식이 저것 밖에 안되나. 나도 참 영화를 모르는 편이지만 평론가라는 사람들이 액션 영화에 대한 전문성이 너무 없다.
난 심형래 정말 대단하다고 생각한다. 무엇보다 그런 대작을 제작할 비용을 조달할 수 있었다는 것이 그가 대단한 사람이라는 강력한 증거다. 많은 실패를 겪었음에도 끊임 없는 열정을 보여줬고 중간 중간에 조금이나마 미래를 볼 수 있는 성과를 보여줬으니까 이만한 큰 작품을 만들 수 있는 투자를 받은 것 아니겠는가.