하드웨어 역시 이해해야 한다.

- Kamal Wickramanayake
- 블로그 : http://www.swview.org/

Karnal Wickramanayke는 스리랑카에서 IT와 소프트웨어 아키텍트를 수행하고 있다. 그는 The Open Group에서 TOGAF 인증을 받았다.






많은 소프트웨어 아키텍트들에게 하드웨어 용량 산정은 결코 마음 편히 작업할 수 있는 영역이 아닌 곳에 위치한 주제이지만, 아키텍트 작업의 중요한 부분으로 남아 있습니다. 왜 소프트웨어 아키텍트가 하드웨어를 적절하게 고려하는데 자주 실패하는지에 대한 수많은 원인이 있지만, 아키텍트 대부분이 하드웨어 이해에 대한 부족과 불명확한 요구사항과 관련이 있습니다.

하드웨어 고려사항을 무시하는 주요한 원인은 아키텍트들이 소프트웨어만 초점을 맞추고 하드웨어 요구에 대해서는 무시하려는 경향이 있다는 것입니다. 게다가, 아키텍트들은 높은 수준의 언어와 소프트웨어 프레임워크를 통해 하드웨어와는 사실 격리되어 있습니다.

불명확한 요구사항 역시 그 한 요소로, 요구사항은 변할 수 있거나 혹은 미흡하게 이해될 수 있기 때문입니다. 아키텍처가 발전함에 따라 하드웨어 고려사항 역시 변하게 됩니다. 또한, 우리의 고객들은 자신들의 사용자 DB나 시스템 용량 변화에 대한 크기에 대해 이해하지 못하거나 예측할 수 없기도 합니다. 결국 하드웨어는 끊임없이 진화하고 있습니다. 과거에 하드웨어 대해 알았던 사실은 지금 적용되지 않습니다.

하드웨어 전문가 없이 개발할 시스템에 대한 하드웨어 설정을 설계한다는 것은 매우 오류가 발생할 위험이 있습니다. 이러한 위험을 대비하기 위해 어떤 소프트웨어 아키텍트들은 대용량 안전 장치를 사용합니다. 그러한 안전 장치들은 일반적으로 객관적인 기준에 근거하지 않거나 어떠한 접근 방법에서도 발견되지 않은 것입니다. 대부분의 경우, 이것은 피크 요청 기간 조차에도 사용되지 않는 초과된 기반구조 용량으로 나타납니다. 결국 고객의 돈이 시스템이 필요로 하는 것 이상 더 많은 하드웨어에 낭비됩니다.

빈약한 하드웨어 산정에 대한 최선의 대비책은 기반구조 아키텍트와 밀접하게 작업하는 것입니다. 소프트웨어 아키텍트와 달리 기반구조 아키텍트는 하드웨어 용량 산정에 전문가이며, 아키텍트 팀의 일원이 되어야 합니다. 하지만, 모든 소프트웨어 아키텍트가 기반구조 아키텍트와 일할 수 있는 환경이 되지 못합니다. 그러한 경우에 소프트웨어 아키텍트는 하드웨어를 산정할 때 오류를 범할 수 있는 가능성이 있습니다.

여러분 자신의 과거 경험을 도입하는 것은 도움이 될 수 있습니다. 과거에 여러분들은 시스템을 구축했었고, 따라서 그 경험이 그 당시 재고했었다고 하더라도 하드웨어 용량 산정에 대한 지식을 가지고 있습니다. 여러분은 또한 고객과 그러한 주제에 대해 논의할 수 있으며 하드웨어 용량 산정에 대한 추가 비용에 대해 납득시킬 수 있습니다. 용량 산정에 대한 비용은 여러분이 필요로 하는 것보다 더 많은 하드웨어를 구매하는 것보다 더 많은 비용이 들 수 있습니다. 이 경우, 수평 확장(horizontal scalability) 이 그 답이 됩니다. 즉, 처음부터 넘치게 구매하는 것이 아니라 필요할 때마다 하드웨어를 추가하는 것입니다. 수평 전략을 수행하기 위해 소프트웨어 아키텍트는 지속적으로 용량을 측정하고 성능이 예측가능한 환경에서 실행되는 소프트웨어 컴포넌트를 격리할 필요가 있습니다.

하드웨어 용량 산정은 소프트웨어 아키텍처 만큼 중요하며, 여러분에게 기반구조 아키텍트가 있던 없던 간에 제일 우선적으로 고려해야 하는 우선순위를 부여할 필요가 있습니다. 아키텍트가 비즈니스 요구와 소프트웨어 솔루션 사이의 관계를 구성하는데 책임이 있는 것처럼 마찬가지로 하드웨어와 소프트웨어 간의 구성을 구상하는데 책임이 있습니다.


원문 : 모든 아키텍트가 알아야 하는 97가지 사실 - You have to understand Hardware too