변화의 충격을 이해하라(Understand Impact Of Change).
뛰어난 아키텍트는 복잡도를 최소한으로 줄일 수 있어야 하며, 단단한 기본 구조를 취하면서도 급변하는 상황에 적절히 대처할 수 있는 실용적인 해결책들을 설계할 수 있어야 합니다.
위대한 아키텍트는 고립된 소프트웨어 모듈에서뿐만 아니라 사람과 사람사이, 시스템과 시스템 사이에서 일어나는 변화의 충격을 이해해야 합니다.
변화는 다양한 형태로 나타날 수 있습니다.
- 기능 위주의 요구 사항 변경
- 확장성 요구의 진화
- 수정된 시스템 인터페이스들
- 팀원의 변동
- 그리고 리스트(해야 할일)의 계속적인 발생
소프트웨어 프로젝트 변화의 광범위함과 복잡함을 미리 추측하는 것은 불가능하며, 변화가 발생하기 전에 모든 잠재적 어려움을 수용하는 시도는 헛된 일입니다. 그러나 아키텍트는 이러한 어려움들이 프로젝트를 망칠지 또는 완수할지를 결정하는 중요한 역할을 해야합니다.
아키텍트의 역할이 반드시 변화를 관리하기 위한 것은 아니지만, 오히려 변화가 관리될 수 있음을 보장해야 합니다.
변화들을 종합하기 위해 많은 애플리케이션에 걸쳐 있고 다양한 미들웨어에 의존하는 고수준의 분산 솔루션[1]을 예로 들어 보겠습니다. 일부 시각적 도구[2]가 제공하는 의존성 집합이 정확히 추적이 되지 않거나, 기술되지 않으면 비즈니스 프로세스에서의 변화는 대혼란을 일으킬 수 있습니다.
변화가 데이터 모델에 영향을 미치거나 존재하는 인터페이스들을 파괴한다면, 다운스트림[3]의 영향은 특히 중요합니다. 프로세스의 구 버전에서도, 존재하는 롱-러닝 트랙잭션들 또는 상태를 가지는 트랙잭션들(long-running, stateful transactions)이 성공적으로 완료되어야만 합니다. 이 같은 예제는 극단적인 듯 하나, 높은 수준의 통합 솔루션들이 현재는 주류를 이룹니다. 통합 표준, 프레임워크, 사용 가능한 패턴을 선택한다는 데서 확인할 수 있습니다.
이러한 외부 시스템 변화가 내포하는 의미를 이해하는 것은 고객에 대한 지원 수준을 지속적으로 보장하기 위해서 대단히 중요한 것입니다.
다행히도, 변화의 충격을 완화할 수 있는 많은 도구와 기법이 있습니다.
- 점증 반복(확장 반복)을 작게 만들기
- 반복 가능한 테스트 케이스를 만들고 자주 실행하기
- 쉬운 테스트 케이스를 만들기
- 의존성 추적하기
- 조직적으로 행동하고 반응하기
- 반복적인 태스크는 자동화하기
아키텍트는 프로젝트 범위의 관점에서 시간, 예산과 같은 변화의 영향을 추산해야만 하고, 길 위에서의 사고와 같은 엄청난 결과를 가져올 수 있는 부분에는 더 많은 시간을 투자할 준비를 해야 합니다. 위험 측정은 어느 부분에 귀중한 시간을 투자해야 하는지 알려주는 유용한 도구입니다.
복잡도를 줄이는 일은 중요하지만, 감소된 복잡도는 단순성과는 다릅니다. 자신의 솔루션에서 변화의 충격과 유형을 이해하기 위한 비용(노력)들을 중장기적으로는 예측 불가능합니다.
1차 번역 : 손 정민
2차 감역 : 손 영수
이 자료는 Creative Commons Attribution 3를 따르며, 웹에서 공개된 내용가 상이할 수 있습니다.
Written by Doug Crawford.
Doug Crawford 는 남아프리카 공화국에서 통신 회사의 미들웨어 개발자 팀을 관리하는, 그는 지난 10년 동안, 사각 못이 둥근 구멍에 적합하게 하는 일을 하며 보냈고 (서로 어울리수 없는 시스템들을 통합 시키는 일을 하며 보냈고), 광고, 법인 은행, 보험, 교육의 분야에서 애플리케이션 통합 프로젝트에 직접적인 영향을 미치고 있습니다.
[1] Xml Web Service, COM+, EJB, CORBA와 같은 분산객체 솔루션을 말한다.
[2] Dependency Structure Matrix 또는 Design Structure Matrix 로 불리며 줄여서 DSM이라고도 하는 도구를 말한다. 소프트웨어의 상호 의존성을 파악하는 도구로 다양한 상용, 오픈소스 퉅들이 DSM을 지원한다. DSM에 대한 자세한 정보는 https://arload.wordpress.com/2009/11/02/dependency-structure-matrix/ 를 참고하길 바란다.
[3] 레거시 시스템이나 이전 시스템과 연동되는 부분
Architecture 101 
변화의 충격 정말 와 닿는 글이어서 공유합니다. 조만간 아키텍트가 알아야할 97가지 나오니 기대해 주세용!!
우오~
정말 충격적이였습니다.^__^;
뭐가 ㅋㅋㅋ. 아 니이름이 나온거 .. 후후. 내가 고맙지 ㅋㅋㅋ 니 블로그 링크 걸어 놓을께…
[…] This post was mentioned on Twitter by HyungTae, Lim, Youngsu Son. Youngsu Son said: 변화의 충격을 이해하라(Understand Impact Of Change).: 뛰어난 아키텍트는 복잡도를 최소한으로 줄일 수 있어야 하며, 단단한 기본 구조를 취… http://goo.gl/fb/6rHt0 […]
매우 단순한 글이면서도 아키텍트가 실천하기 어려운 것을 콕 찝어주는 글이군요.
변화관리(CM) 위험관리(RM)를 해 줄 수 있는 툴은 그동안 일을 해 오면서 많이도 봐 왔던 것 같습니다.하지만 그것을 우아하게 사용하는 아키텍트를 찾아 보는 것도 하늘에 별 따기이죠. 변화에 유연하게 대처할 수 있는 재치와 우아함. 참 여러운 부분이기도 하고요.
DSM관련해서 Java진형에도 매우 많은 툴들이 나와있답니다.:)
– 전 ‘우아함’이라는 단어를 좋아합니다. 딱딱함, 복잡함,분산등을 극복할 수 있는 것은 우아함이라고 그래디가 말한적이 있었죠.
그리고 프레임워크, 사용 가능한 패턴, 그리고 기술은 결국 상황에 따른 선택사항이라는 것에도 공감~~^^
그렇죠 원래 java진영에서 나왔던 것이고,
JDepend를 기반으로, graphic tool로 연계한 것이 NDepend, XDepend, CppDepend 입니다.
다 공유의 정신이 기반이 되어 더 발전할 수 있게 된거죠 🙂
적절한 아키텍쳐를 정한 다는 것은 ㅋㅋ 아주 어려운 거 같습니다.
전 요즘 변화의 전파를 흡수하면서도 사용하기 편한 프레임워크 설계방법에 관심이 많습니다.
이 둘사이에 균형을 잡는다는 것은 정말 어려울거 같애요 🙂
moova님의 다양한 필드에서의 경험이 많이 부럽네요.
전 너무 제조업쪽에 치우쳐서.. 후후.. 좋은 글 잘 보고 있습니다.
좋은 말, 좋은 생각, 좋은 마음가짐 계속해서 블로그에서 보옂세요!!
저도 배우는 것이 굉장히 많네요 🙂
그리고 안 잊고 종종 찾아와 주셔서 감사하구요.
그럼 좋은 주말 되시길!! 충성!
[…] Code Metrics와 같은 다양한 지표를 통해, 특정 Feature가 과도하게 커지거나, Dependency 관계를 잘 제어해야 […]