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

손쉬운 방법은 이후에 이자가 붙어서 되돌려 받게 된다.

by javauser 2009. 8. 19.


- Scot Mcphee

Scot Mcphee는 어플리케이션 코딩과 설계에 15년 이상의 경험을 가진 호주의 소프트웨어 개발자/아키텍트이다. 지난 8년 동안 그는 거의 J2EE 분야에서 종사해왔다.




유지보수하려는 시스템을 아키텍팅할 때 결국 프로젝트의 초기 개발보다 더 많은 자원이 소모될 것이라는 사실을 기억하는 것은 중요합니다. 프로젝트의 개발 초기 단계 기간 적용되었던 손쉬운 방법은 이후에 심각한 유지보수 비용을 발생시킬 수 있습니다.

예를 들어, 단위 테스트가 직접적인 가치를 부여하지 않는다는 정보를 들은 적이 있어서 여러분은 개발자들에게 단위테스트에 대한 엄격한 적용을 건너뛰도록 전달합니다. 이는 인도된 시스템이 향후 미래에 변경을 더 어렵게 하는 원인이 되며, 그러한 변화를 수용할 때 신뢰를 떨어뜨리게 됩니다. 시스템은 자그마한 변화에 훨씬 더 많은 수작업 테스팅을 요하게 되며, 쉽게 깨지고 유지보수 비용이 증가할 뿐만 아니라 완전하게 테스팅된 설계(테스트 우선 설계는 말할 것도 없고) 에 적합하지 않은 설계를 만들게 됩니다.

심각한 아키텍처의 실수는 어찌되었든 간에 비용을 절감한다는 이유로 기존 시스템을 사용한다는 근거 하에 목적이 적합하지 않은 기존 시스템을 변경하는 것입니다. 예를 들어, 비동기 메시징 시스템에 전달하기 위해 데이터베이스 트리거를 사용하는 BPEL  아키텍처 컴포넌트를 사용하는 경우가 있습니다. 이와 같이 설계를 할 수도 있거나 편이에 의해 설득될 수 있거나 여러분이나 고객에게 알려진 아키텍처라는 이유일 수 있습니다. 하지만 메시징 아키텍처가 요구사항이 명확해진 후에 첫번째 단계에게 선정되었어야 했다면 이는 필요한 컴포넌트였을 겁니다. 프로젝트 초기에 이루어지는 쓸모없는 결정이 새로운 요구사항을 충족하기 위해 시스템을 재아키텍처링하는데 더 많은 비용을 유발시킵니다.

개발 초기 기간 동안 손쉬운 방법의 유혹을 뿌리치는 것 이외에 설계 결정 사항이 발견되는 순간 재빨리 빈약한 결정사항을 수정하는 것 또한 중요합니다. 빈약하게 결정된 기능은 이후 더 많은 비용을 들이는 교정 작업을 수반하는 미래 기능의 단초를 제공할 수 있습니다.

예를 들어, 어떤 내부 기능에 적합하지 않은 라이브러리를 선택했다는 사실을 여러분이 발견했다면, 이 라이브러리는 가능한 한 빨리 교체되어야 합니다. 그렇지 않다면, 요구사항 변경에 맞춰서 이를 반영하려는 노력은 추가 추상화 레이어를 요하며, 이들 각각의 레이어가 이전 레이어의 빈약한 적용에 숨겨진 형태로 설계됩니다. 여러분은 스스로가 여러분이 추가한 모든 레이어와 함께 한데 꼬여진 실타래, 압정, 끈적끈적한 테이프가 범벅이 된 공을 만들고 있는 중이며, 이는 풀기가 더 어렵습니다. 이러한 결과는 변화에 저항하는 시스템으로 나타나게 됩니다.

아키텍트로서 여러분이 아키텍처 문제나 설계 결함을 부딪힐 때마다 교정 비용이 가장 쌀 때 지금 바로잡도록 주장하십시오. 여러분이 계속해서 이를 안고 갈수록 이자 지불은 더 많이 들게 됩니다.


원문 : 모든 아키텍트가 알아야 하는 97가지 사실 - Shortcuts now are paid pack with interest later
반응형