부분 최적화를 어디서 처음 봤는지 기억이 잘 않나는데, 아마 엘리 골드렛의 The Goal로 생각된다. 아니면 나머지 시리즈 3권중에 있을듯. 거기서 든 예로는 재무팀에서 금액을 절약하기 위해서 품질이 떨어지는 (싼) 물건을 고집해 일정이 지연되고, 전체의 소모 비용은 오히려 증가해 결국 회사에 손해를 끼친다는 내용으로 기억한다.
부분 최적화의 위험은 부분적으로 보면 옳다는데 있다. 위의 예에서 재무팀의 입장만을 생각한다면 보다 싸게 물건을 구입했으니 당연히 자신의 존재 이유에 부합한다. 문제는 범위를 좀 더 넓혀보면 결국 회사에 손해를 끼치는 행동을 했다는 점이다.
이런 일은 우리 주변에 자주있다. 현재 진행하고 있는 프로젝트에서 UI를 GFX scaleform으로 만들고 있는데, 최초의 평가판을 받은 이후에 (한달짜리) 구매를 확정하고도 평가판 기간을 세번이나 연장했다. 구매에 시간이 그토록 오래 걸린건 몇천불 싸게 사보겠다는 처절한 협상 기간때문이었는데, 그 와중에 평가판 기한 만료로인해 2주 이상 작업이 지연됐다. 50명 가까운 팀이 2주를 까먹은 것과 몇천불이 비교할 가치나 있을까.
사실 부분 최적화 얘기가 떠오른 것은 스케일폼 때문은 아니었고, 프로그램팀에서 생긴 일 때문이다. 어제 일을 하면서 진행을 위해 임시 작업(땜빵)을 지시를 해놨는데, 일일회의에서 얘기를 들어보니 결국 맞는 방법을 찾아서 그 방법으로 해결했다고 한다. 왜 그렇게 했냐고 했더니 그게 나중에 수정을 안하는 더 좋은 방법이라고 생각했기 때문이란다. 그걸 해결하느라 그 뒷일을 오늘 처리하겠다는게 일일회의에서 한 얘기였고, 아주 만족스런 표정이었다.
그래 코드의 주인으로서 옳은 일이다. 근데 그로 인해서 그 일이 끝나기를 기다리는 사람들은 어쩔까? 내가 코딩에 대해서 쥐뿔도 몰라서 임시로 만들고 완료를 하라고 시킨건 아니다. 그로인해서 본인에게 나중에 추가 수정이 좀 생기겠지만 여러 팀원이 기다리는 것에 비하면 그 일은 아주 작고 사소한 일이다. 이 점에 대해서 주지시키기는 했지만, 또 이런 일이 발생할 것이다.
우리 대부분은 회사라는 조직에 속해 있어서 가끔은 옳은 일이 옳은 일이 아니게 된다는 점을 생각해봐야한다.
