의사 결정의 핵심은 타이밍

개발자로서 일을 하다 보면 의사 결정을 해야 하는 상황이 정말 자주 생긴다. 이번에 코드를 리팩토링 해야 할지, 자동화를 해야 할지, 업무 프로세스에 절차를 추가해야 할지, 등 다양한 의사 결정을 한다.

의사 결정을 할 때 어떤 것을 가장 중요하게 고려하는지 내게 묻는다면 타이밍이라고 답하고 싶다. 어떤 의사 결정을 하느냐에 따라 시간이라는 자원을 포함한 비용이 들고, 상황이 시간이 지남에 따라 달라지기 때문이다. 따라서, 먼 미래에는 올바른 결정이 지금은 그렇지 않을 수 있고, 거꾸로 지금은 맞는 결정이 나중에는 틀리기도 한다.

최근에 우리 조직에서 시스템 아키텍처를 변경하기로 의사 결정했다. 이에 한 팀원 분께서 자신이 1년도 더 전에 아키텍처를 바꿔야 한다고 주장했었는데 이제야 하게 돼서 무척 아쉽다고 말씀하셨다. 그분께 나는 “그때는 아직 때가 아니라고 판단했고, 이제는 때가 됐다고 생각해서 하기로 했습니다.”라고 말씀드렸다.

내가 이와 같이 판단한 이유는 당시에 아키텍처 변경은 반드시 해야 하는 일보다는 하면 좋은 일에 가까웠고, 나중에 하더라도 특별히 노력이 더 많이 들지 않으며, 작업에 많은 노력이 드는데 다른 반드시 해야 하는 일들도 많은 상황이었기 때문이었다. 하지만 이제는 아키텍처 변경이 반드시 해야 하는 일이 되었기 때문에 우선순위를 높여 진행하기로 결정했다. 이제 와서야 그 일을 하게 됐지만 과거에 잘못된 결정을 했다고 생각하진 않는다. 잘못된 결정을 했다고 생각하지 않는 이유는 예전에 아키텍처 변경 작업을 나중에 하겠다는 결정을 내렸던 이유와 비슷하다. 아키텍처 변경 작업을 하지 않는 대신 반드시 해야 하는 다른 일들을 할 수 있었고, 지금 작업을 하기 위해 훨씬 더 노력을 많이 들여야 하는 것도 아니기 때문이다.

먼 미래가 되면 올바른 결정이 되는 의사 결정들은 너무나도 많다. 리팩토링을 해서 나중에 유지보수하기 더 용이하게 만드는 건 유지보수하는데 드는 시간이 누적됨에 따라 언젠가는 올바른 결정이 된다. 문제는 투자 대비 효용이 더 커지는 시점이 언제냐는 것이다. 리팩토링을 하는 데는 시간이 드는데 어떤 경우에는 그렇게 리팩토링을 해둬도 다시 유지보수할 일이 없어지는 경우도 있다. 시간이라는 가장 소중한 자원을 낭비한 꼴이다.

그렇기 때문에 나는 의사 결정을 할 때 지금이 정말 적절한 타이밍인지에 대한 고민을 많이 한다. 그리고 많은 사람들이 그러할 것이다.

위 예시의 팀원 분과 같이 의사 결정에 충돌을 경험하는 분들이 많을 것이다. 그런 분들에게 타이밍 관점에서 스스로의 판단이 올바른지 생각해 보시라. 지금 내가 주장하는 일이 왜 중요하고, 왜 다른 일들보다 지금 우선해야 하는지, 지금 하면 언제쯤이면 노력 대비 효용 가치가 더 커질 거라고 생각하는지, 지금 하지 않으면 나중에 어떤 어려움이 생기는지 등을 생각해 보고 만약 올바르다면 그 근거들을 잘 정리하여 논의하시길 권해드리고 싶다. 분명 좋은 결과가 있지 않을까 한다.