9월 24, 2009 —

Use Uncertainty as a Driver – 설계의 기준(Driver)으로써 불확실성을 이용해라.

둘 중 하나를 선택해야 한다면. 대부분의 사람들은 해야 될 가장 중요한 것을 선택합니다.  하지만,설계(소프트웨어 또는 다른 것들)에서는 그렇지 않습니다. 두 가지 선택사항의 존재는 당신이 설계 시 불확실성을 고려할 필요가 있다는 것은 알려주는 지표(indicator)입니다.

불확실성을 가능한 마지막 순간에 설계에 자세한 부분(defer commitment[1])을 결정할지, 설계 결정들의 중요성을 감소시키기 위해 분할하고 추상화할지 결정하는 기준으로 이용하십시오. 만약 당신의 마음을 첫 번째(가능한 나중에 결정하는 것 – defer commitment)에 고정시킨다면 이 첫 번째 원칙에 갇히고 종속될 수 있습니다. 그 결과 부수적인 결정이 굉장히 중요해 지고 소프트웨어의 유연성이 줄어듭니다..

아키텍쳐에 있어서 가장 간단하고 구조적인 정의중 하나는 Grady Booch의 말에서 인용됩니다.

“모든 아키텍쳐는 설계지만 모든 설계가 아키텍쳐는 아니다. 아키텍쳐는 시스템을 구체화하는 중요한 설계 결정들을 나타낸다.  여기서 중요한 것은 변화의 비용에 의해서 측정된다.”

이 정의에 따르면 효과적인 아키텍쳐는 일반적으로 설계 결정의 중요성을 감소시키는 것입니다.  비효율적인 아키텍쳐는 설계 결정의 중요성을 확대시킵니다. 설계 결정이 합리적으로 두 가지 방법 중 하나로 진행될 수 있다면, 아키텍트는 한 걸음 물러설 필요가 있습니다.

A와 B 두 가지 선택 중 하나를 결정하려고 시도하는 대신, “ A와 B 사이의 결정을 덜 중요하게 만들기 위해 어떻게 설계해야 할까?” 질문해야 합니다. 가장 흥미로운 것은 실제로 A와 B중 선택하는 것이 아니라, A와 B 사이의 (적절한) 선택이 존재한다는 것입니다. (그리고 적절한 선택은 꼭 필수적으로 명확하거나 안정적일 필요는 없습니다)

아키텍트는 혼란스럽고, 둘 중 하나를 선택해야 되는 상황이 오기 전에 미리 혼란의 상황에 빠져들 필요가 있습니다. 칠판 앞에 서서 열정적으로 동료직원들과 어떤 선택을 해야 할지 논의해야 할까요? 아니면 약간의 코드(code)앞에서 음.. 아.. 와 같은 한숨을 쉬며, 이걸 구현할지 아니면 다른 것을 시도할 지 고민하는 데드락(교착상태)에 빠져야 할까요? 새로운 요구사항이나 요구사항의 설명이 현재 구현방법에 의구심을 갖게 만든다면, 이건 불확실성입니다.

어떤 분할(separation)또는 캡슐화가 (긍극적으로) 결정에 의존적인 코드로부터 결정의 변화를 쉽게 수용할 수 있게 분할 할 수 있는지 알아내어 응수해 보십시오. 이러한 감각 없이 대안으로 나온 답변은, (종종 긴장한 면접자 같이, 다양한 이론적이며, 일반적인 방법으로 불확실성을 상쇄하기 위해 시도하는 웅얼거리는 것 같은) 산만한 코드입니다. 또한 임의로 만들었지만 근거없는 자신감으로 만들어진 답변은, 잘못된 길에서 뒤도 돌아보지 않고 속도를 내는 것과 같습니다.

결정하기 위해서, 결단하라는 압박이 종종 있습니다. 이것은 선택사항들에 대해 생각할 수 있게 도움이 됩니다. 결정을 내리고 결정을 내리지 않는 것은, 시스템 개발 방법이 가지는 (다른 경로보다는) 불확실성에 있습니다. 결정이 좀더 (실제 지식에 근거하여) 신뢰할 수 있게 될 때 까지 실제 결정을 미루십시오. 하지만 결정이 너무 늦어지면, 실제 지식을 이용할 수 없을 가망성이 있습니다.

아키텍쳐와 프로세스는 상호작용합니다. 이것은 아키텍트가 (개발 생명주기, 경험적이며 피드백을 도출해 내는 아키텍쳐적인 접근 방법, 시스템과 스케쥴 둘 다로 구분화기 위하여) 불확실성 사용을 선호하는 큰 이유가 됩니다.

Written by Kevlin Henney

이 자료는 Creative Commons Attribution 3 라이센스를 준수합니다. 또한 책의 내용을 번역한 것이므로 Wiki 내용과는 약간 상이할 수도 있습니다.

1차 번역 : 김 현종

2차 번역 : 손 영수

[1] Defer Commitment – Lean 소프트웨어 방법에서 설명하는 원칙으로 가능하다면 충분한 정보를 얻은 후에 결정을 내리라는 의미이다. 여기서도 세부적으로 7개의 원칙이 있는데, 자세한 내용은 http://agilesoftwaredevelopment.com/blog/pbielicki/seven-principles-lean-software-development-defer-commitment을 참고하길 바란다.