본문 바로가기
Homo Architect/Things Every SW Architect Should Know

정량화시켜라

by javauser 2009. 3. 25.

- Keith Braithwaite

비전문가로 많은 햇수가 흐른 뒤에 Keith Braithwaite는 1996년에 소프트웨어를 만들어서 처음으로 벌이를 했다. lex와 yacc로 만들어진 컴파일러를 다루는 첫번째 직업 후에 그는 처음에 GSM 네트워크 계획에 대한 극초단파 전파를 모델링하는 일에 뛰어들어서 그 다음에 C++로 항공 화물 운송에서 계절별 다양한 요구를 처리했다. 컨설팅 (과 자바)으로 옮기면서 CORBA를 접했고 그 다음에는 EJB, 그리고 그 당시 ‘e-commerce’라고 하는 것에 접했다. 그는 현재 Zuhlke에서 수석 컨설턴트로 일하고 Zuhlke의 Centre of Agile Practice를 담당하고 있다.





 “빠름”은 요구사항이 아닙니다. “쉽게 반응”하는 것 역시 요구사항이 아닙니다. “확장 가능함”도 마찬가지입니다. 요구사항이 되지 못하는 가장 근본적인 이유는 그러한 내용들이 충족되는지 말할 객관적인 방법이 없다는 것입니다. 하지만 여전히 사용자들은 그렇게 말하길 원합니다. 아키텍트의 역할은 주로 시스템으로 하여금 이러한 속성들을 가지게끔 도와주고 이 속성들 간에 피할 수 없는 충돌과 불일치성에 대해 균형을 맞추는 것입니다. 객관적인 기준이 없다면 아키텍트는 변덕스러운 사용자와 (“아뇨, 받아들일 수 없어요, 여전히 그렇게 빠르지 않은걸요”) 강박 관념의 프로그래머(“아뇨, 배포할 수 없어요, 여전히 그렇게 빠르지 않은걸요.”)에 의해 좌우됩니다.

모든 요구사항들처럼 이러한 요구사항들을 작성하도록 촉구해야 합니다. 너무나 흔하게 애매모호한 수식어인 “유연성이 있는”, “유지보수가 가능한” 등의 단어들이 나타납니다. 모든 경우에 (물론, “사용 가능한” 경우 조차도) 있어서 이러한 현상들을 정량화시킬 수 있으며, 기준치를 설정할 수 있다는 것이 증명되었습니다. 만일 그렇지 못하다면, 사용자들에 의한 시스템 인수를 위한 근거가 없다는 것이며, 가치 있는 지침은 작업한 사람에 따라 구축한 사람으로부터 무용지물이 되며, 이를 아키텍팅한 사람들에게는 비전이 무의미해지는 것입니다.

다음과 같은 몇가지 간단한 질문을 할 수 있습니다. 얼마나 많이, 얼마 기간 동안, 얼마나 자주, 얼마나 빨리, 증가 혹은 감소, 어떤 속도로 됩니까? 이러한 질문들에 답변을 할 수 없다면 해당 요구사항은 이해되지 않습니다. 그에 대한 답변은 시스템에 대한 비즈니스 사례 속에 있어야 하며 그렇지 않다면 이를 위해 어려운 사고를 요합니다. 아키텍트로 작업을 하고 있고, 비즈니스가 이러한 수치들을 이야기하지 않는다면 여러분 스스로에게 왜 그런지를 물어보십시오. 그런 다음에 그러한 수치들을 얻으려고 하십시오. 다음 번에 누군가가 시스템이 “확장 가능할” 필요가 있다라고 여러분에게 말한다면, 새로운 사용자가 어디에서 나타나며 왜 나타나는지를 그 사람에게 물어보십시오. 얼마나 많이 그리고 언제까지인지도 물어보십시오. 답변으로 “많이” 와 “곧”은 거절하십시오.

확실하지 않은 수량 기준은 최소한, 보통, 최대한과 같은 범위로써 주어져야 합니다. 이와 같은 범위가 주어질 수 없다면, 요구된 행위는 이해되지 못합니다. 아키텍트가 이해할 때, 범위 내에 있는지를 점검하는 이러한 기준들에 대해 체크될 수 있습니다. 특정 기준에 대한 성능은 시간이 지나면서 바뀜에 따라 가치있는 피드백을 얻게 됩니다. 이러한 범위를 찾고 점검하는 일은 시간이 소모되며 비용이 드는 업무입니다. 만일 아무도 기꺼이 성능 측정을 위해 시스템이 “성능이 있는(performant)”(요구사항도 단어도 아닌) 것에 대한 관심을 가지지 않는다면 성능이 중요하지 않을 가능성이 큽니다. 그렇다면 여러분은 대가를 치를 만한 시스템의 측면에 대해 아키텍처적인 노력에 초점을 맞출 필요가 없습니다.

 “사용자 입력은 1,500 밀리초 이상 넘어서면 안됩니다. 일반적인 부하(…로써 정의되는)에서 평균 응답 시간은 750 에서 1,250 밀리초 이어야 합니다. 500 밀리초 이하의 응답 시간은 사용자가 인식할 수 없기 때문에 그 이하에 대해 신경쓰지 않을 것입니다.” 이제 이러한 것이 요구사항입니다.


원문 : 모든 아키텍트가 알아야 하는 97가지 사실 - Quantify

반응형