멋진 그림은 아키텍처가 아니다

소프트웨어를 개발하는 회사라면 아키텍처 설계서라는 걸 가지고 있다. 멋진 도구를 사용해서 그려 놓은 회사도 있고, 그냥 파워포인트 2~3장에 박스 몇 개와 선 몇 개로 그려 놓고 아키텍처라고 말하는 곳도 있다. 아키턱처 설계서의 외향적 멋을 두고 본다면, 당연히 비싼 도구를 사용해서 수 십장의 다이어그램을 그려 놓은 곳이, 파워포인트 몇 장으로 아키텍처라고 주장하는 회사보다, 훨씬 우수해 보인다. 그런데 이런 외향적 우수함이 어떤 회사의 아키텍처를 판가름하는 잣대는 아니다.

소프트웨어 컨설턴트로서 이 회사 저 회사 다니면서 얻은 경험으로, 어떤 회사의 아키텍처 품질의 우수성을 판단할 수 있는 간단한 질문이 있다는 걸 알게 되었다. 멋있는 아키텍처 설계서를 가지고 있느냐, 혹은 아키텍처 설계서가 별로 멋이 없느냐는 어떤 회사의 아키텍처에 큰 영향을 미치지 않는다. 다음과 같은 질문을 해보면 아키텍처 설계서의 멋짐과 관계 없이 아키텍처의 품질을 파악할 수 있다.

그 질문은, 신규 기능을 추가할 때 걸리는 시간을 어떻게 예측하느냐?이다. 아무리 멋있는 아키텍처 설계서를 가지고 있는 회사라도 이게 내실이 없는 문서면, 신규 기능 추가 여부를 묻는 질문에, 모듈별 담당자를 호출한다. 그리고 담당자에게 각 기능을 추가하려면 어느 정도 걸릴지 예측해보라고 한다. 그리고 그 예측치를 질문의 답으로 내놓는다. 말하자면 그 회사는 아키텍처 설계서는 처음에 멋지게 그려놓았다가 파일 서버 한 구석에 잘 보관하고 있던 것이다.

이에 반해서 아키텍처가 설계서가 아키텍처를 충분히 반영하고 있는 회사에서는, 아키텍처 설계서를 펼쳐 놓고 해당 기능을 반영하려고 어떤 모듈을 수정해야 하는지부터 살핀다. 말하자면 변경의 영향도를 모듈 담당자가 파악하는 게 아니라 아키텍처 관점에서 파악한다. 그러고 나서 기능을 반영하기 위해서 가장 효과적인 수정 방향을 결정하고 나서, 하위 모듈로 변경 내역을 전파해서 수정한다. 아키텍처 설계서가 빈약했을 때, 담당자가 알아서 수정하는 부분최적화 오류를 피할 수 있다.

이것 말고도 다양한 질문이 있을 것이다. 길게 썼지만 이 글에선 아키텍처의 파악하는 좋은 질문은 무엇이 있을까,를 말하고자 한 게 아니다. 현실에서 보면 대개 아키텍처 설계서를 잘 만들지 않기 때문에, 그런 설계서라도 있다면 그나마 잘해보려는 개발회사로 평가할 수 있다. 그러나 그런 설계서가 있고 그 설계서가 다른 사람에게 보여주기에 멋있다 하더라도, 아키텍처의 품질이 좋다는 뜻이 아니다. 겉모습보다 내용물이, 아키텍처 설계서가 달성하려는 바를 만족하느냐,가 더 중요하다.

글 : 신승환
출처 : http://bit.ly/15hrbrD