변화의 주창자

결정하기 전에 시도하라(Try Before Choosing) 본문

교육,공부/SW Architecture

결정하기 전에 시도하라(Try Before Choosing)

allsolution allsolution 2009. 7. 15. 03:44

사용자 삽입 이미지
어플리케이션을 만드는 것에는 많은 결정을 필요로 한다. 몇몇은 프레임워크나 라이브러리를 선택하여 포함할 것이고 또 다른 이들은 특정 디자인 패턴 사용에 집중할 것 이다. 모든 경우에 결정의 책임은 팀의 아키텍트에게 있다. 진부한 아키텍트는 수집할 수 있는 모든 정보를 수집한 후 잠시 숙고하여 마침내 상아탑에서 개발자들로부터 적용될 솔루션을 발표할 것이다. 놀랄 것도 없이 여기에 더 좋은 방법이 있다.

Mary와 Tom Poppendieck는 개발에 편향된 그들의 업무에서 의사결정을 위한 기술을 설명했다. 이들은 아키텍트가 마지막 순간까지 책임의 의무를 다해야 한다고 주장한다. 팀이 쉽게 되돌릴 수 없는 결과가 예상되는 결정으로 인해 결정하지 못해 아무 일도 못 할 때 그들을 위해 결정해 줘야 한다는 것이다. 더 많은 정보는 결정 기반 위에 가능하고 뒤의 결정은 이 정보에 의해 만들어지기 때문에 신중할 수밖에 없다. 그러나 많은 경우 더 많은 정보가 충분한 정보를 의미하지는 않는다. 그리고 우리는 최고의 결정이 뒤늦게 만들어 진다는 것을 안다. 이것이 좋은 아키텍트에게 어떤 의미를 갖게 하는가?

아키텍트는 곧 이뤄야 할 결정을 지속적으로 감시해야 한다. 주어진 팀이 소수의 개발자보다 많고 축적된 코드 소유권을 수행한다면 그와 같은 결정지점이 다가올 때 아키텍트는 다양한 개발자에게 문제의 해결점 제시를 물어보고 잠시 이를 수행할 수 있다. 마지막 결정의 순간이 다가올 때 팀은 이점에 대해 평가하고 다른 솔루션의 약점에 대해 알게 된다.

소 잃고 외양간 고치는 격이지만 일반적으로 문제의 최고의 솔루션은 누구에게나 아주 명백하다. 아키텍트는 선택할 필요도 없다. 그냥 의사 결정 프로세스만 조정하면 될 뿐이다.

이 접근방식은 큰 선택뿐 아니라 작은 선택에도 작용한다. 이는 팀에게 스프링 프레임워크에서 제공된 하이버네이트 템플릿을 사용할지 안 할지를 팀이 알아내도록 할당할 수 있을 뿐 아니라 어떤 자바스크립트 프레임워크를 쓸지에 답해줄 것이다. 다른 접근방법들이 나타내는 지속기간은 명백히 선택의 복잡성에 매우 의존한다.

같은 문제에 둘 혹은 더 많은 접근방법을 시도하는 것은 먼저 결정 내리고 하나를 적용해 보는 것 보다는 더 많은 노력이 요구된다. 하지만 앞선 결정은 나중에 차선으로 인식된 솔루션을 이끌기에 아키텍트에게 딜레마를 남긴다. (팀이 현재 수행하는 일을 취소하거나 그대로 남겨서 결과를 감수하는 것 양쪽 결과 모두 노력을 낭비하는 결과를 낳기에) 더 나쁜 경우는 아무 대안들이 조사되지 않았기 때문에 그 접근의 선택이 최선이 아님을 팀의 누구도 인식 못할 가능성이 있다는 것이다. 이와 같은 경우에 노력은 어떠한 방향의 기회 없이 쓰레기로 버려진다. 그렇기에 다양한 접근들을 시도하는 것이 최소한의 자원낭비 일 수 있다는 것이다.

Written by Erik Doernenburg
Erik Doernenburg는 ThoughtWorks, Inc.의 기술고문으로 대규모 기업 솔루션의 설계와 구현부분의 고객지원을 하고있다.
0 Comments
댓글쓰기 폼