소프트웨어 아키텍처 이론과 실제 : 1장 소개

2007년 8월 18일 토요일 코엑스 반디엔 루인스에 들렀다. 딱히 책을 구입할 목적으로 간건아니다. 한 3년전 부터인가는 소프트웨어 관려된 책을 구입해본적이 없었기 때문이다. 그 전에는 책 수집하는 기분으로 이것 저것 사들이고는 했었다. 거기에는 정보를 늦게 얻게 되면, 뒤쳐질지도 모른다는 약간의 강박관념 비슷한 것도 자리잡고 있었으리라 생각된다.

그러다가 어차피 책을 읽지 않을 바에는 책을 사봤자 아무런 의미가 없다는 것과 모든 소개되는 기술들을 알아야 할필요도 없다는거, 어차피 95%의 기술은 버려진다는 것을 알게된 뒤로는 반드시 필요한 책만 사기로 마음을 먹게 되었다. 게다가 인터넷을 통해서 쉽게 원하는 정보를 얻을 수 있다는 것까지, 이런 저런 이유가 복합적으로 작용해서 책을 구입하지 않게된 이유가 된거 같다.

거기에 왠만해서는 잘 변하지 않는 (매우 보수적인) 유닉스(:12) 시스템/네트워크 프로그래밍 관련된 일을 하다보니, 더더욱 책을 살 필요성을 느끼지 못했던거 같다. 이들 기술은 10년전이나 지금이나 별로 달라진게 없다.

오히려 평소에 많은 관심을 가지고 있던, 자연과학 관련 책들을 주로 구입해서 보았다.

어쨋든 소프트웨어 관련 책을 살 생각은 전혀 없었지만, 간김에 이것 저것 둘러보다가 소프트웨어 아키텍처 이론과 실제라는 책이 눈에 들어오는 거였다. 예전같으면 그냥 지나쳤겠지만, 얼마전에 구입한 건축이 된 그림, 그림이된 건축이라는 책을 통해서 아키텍처(이 책에서 설명하는 아키텍처는 건물에 대한 아키텍처이다)에 관심을 가졌던 터라, 4만원의 거금을 주고 구입하게 되었다. 건축물에서의 아키텍처나 소프트웨어:::아키텍처(:12)나 뭐 거기서 거기 아니겠는가 !?

이제 공부한 내용을 정리해 보려고 한다. 한장씩 읽고 그에 대한 요약과 그동안의 개발경험에 따라서 책의 내용을 재해석한 내용으로 채워보려고 한다.

아키텍처는 건축물에서 유래가 되었다. 16세기 르네상스 시대를 거치면서, 건축물에 대한 미적/수학적/산업적 가치에 대한 눈을 뜨면서 부터다. 그전에 건축관련 설계등을 하던 사람들은 길드에 소속되어서 일당을 받고 일을 처리하는 기능공으로써의 대우를 받았을 뿐이다. 16세기에 이르러서야 이들을 architecture라고 부르게 된다. architecture의 어원은 arkhitekon 이다. 아키텍처의 어원에 대한 자세한 내용은 아키텍처의 유래문서를 읽어보기 바란다.

아키텍처는 기술,비지니스,문화,산업 환경을 아우르는 것으로 서로가 서로에게 영향을 끼친다.

아키텍처에는 넓은 범위를 포괄하므로 다양하며 충돌되는 이해관계자의 요구에서 최선의 해를 찾는 능력이 요구된다. 이해관계자에는 개발조직, 마케팅, 사용자, 유지보수, 고객등이 포진해 있으며, 몇몇 관계자는 전혀다른 요구사항을 내놓는다. 혹은 아키텍처 자신의 요구와 충돌 될 수도 있다.

여기 한명의 아키텍트가 있다. 이 아키텍트는 서버/클라이언트 환경보다는 RPC응용과 같은 묵시적인 호출을 이용한 아키텍처를 이용해서 프로젝트를 성공한 경험이 있다면, 다음 프로젝트에도 비슷한 아키텍처를 수립하려고 할 것이다. 만약 아키텍처가 유닉스(:12)환경을 선호한다면, 유닉스(:12)환경과 분산객체처리와 관련된 경험이 있는 개발원으로 개발조직을 꾸려나가길 원할 것이다.

만약 만들어져 있는 개발조직이 서버/클라이언트 환경을 선호한다면, 충돌이 불가피할 것이다. 분명히 아키텍트는 경험이 없는 서버/클라이언트 환경하에서의 수립을 달가워하지 않을 것이다. 위험부담이 있기 때문이다. 결국 아키텍처는 개발조직을 설득해야 할것이다. 최악의 경우에는 설득당해서 서버/클라이언트 환경으로 아키텍처를 수립해야 한다.

이 경우는 그나마 양호하다. 만약 개발조직이 윈도우즈 환경에 익숙하다면, 아키텍처를 수립하는데 더 큰 어려움을 겪게 될 것이다.

이러한 문제가 발생하지 않기 위해서, 아키텍트는 다양한 개발환경에 대한 풍부한 경험을 가지고 있어야 할 것이다. 혹은 개발조직을 그렇게 만들 수 있는 권한을 가지고 있어야 할 것이다. 가자 좋은 상황은 풍부한 경험과 권한 모든것을 가진 경우가 될 것이다.

이러한 경험과 권한외에도 현재 산업의 기술적인 환경이 아키텍처의 수립에 영향을 끼친다. 웹서비스를 제작한다고 하면, (국내환경의 경우)2년전만 해도 아키텍처의 수립시 웹표준을 심각하게 고려할 필요는 없었다. 그러나 Web2.0(:12)과 표준을 무기로한 글로벌 기업이 시장에 진입하면서 지금은 웹서비스를 위한 아키텍처에서 웹표준은 중요한 고려사항이 되고 있다.

마찬가지로 과거에는 웹서비스에서의 미들웨어, 플랫폼 적용등이 중요한 요소가 아니였지만 Ajax(:12)와 이를 이용한 MashUp 서비스의 등장으로 웹기반에서의 미들웨어, 플랫폼이 필수 고려사항이 되고 있다.

아키텍처는 유독 개발조직과 다른 이해관계자들 사이에서 발생하는 충돌을 잘 조절해서 아키텍처를 수립할 필요가 있다.

• 마케터는 빠른시간에 완벽한 기능을 가진 제품이 나오길 원한다.
• 개발시간이 단축되면 제품의 품질이 떨어진다.
• 고객의 다양한 요구에 모두 대응할 수 있는 유연한 제품을 만들길 원한다.
• 그럴 경우 개발기간이 길어지기 때문에, 개발조직은 고객의 요구를 한정시키길 원한다.
• 마케터는 인공지능을 가진 제품을 원한다. 대게가 이론적으로는 가능하다.
• 그러나 개발조직은 시스템과 기술적인 한계와 시간의 부족함을 느낀다.

결국 아키텍트는 모든 이해관계자의 환경과 요구사항을 분석해내야지만, 훌륭한 아키텍처를 수립할 수 있다.

아키텍처의 수립을 위한 활동요소에는 다음과 같은 것들이 있다.

1. 비지니스 기회 창출
2. 요구사항 이해
3. 아키텍처의 선택 혹은 수립
4. 아키텍처 문서화 의사소통
5. 아키텍처 분석과 평가
6. 아키텍처 기반시스템 개발
7. 아키텍처 준수 여부 확인

위의 활동요소는 아키텍처의 수준이 아니더라도 마케팅 프로세스 혹은 개발 프로세스 수준에도 통용될 수 있는 사항들이다.

필자는 인터넷 플랫폼의 품질의 보증을 위한 QOS(:12) 시스템을 구축하고 있다. 위의 아키텍처 수립활동에 따른다면 다음과 같이 QOS 아키텍처의 수립을 진행할 수 있을 것이다.

1. 비지니스 기회 창출

QOS 시스템은 현재의 서비스 품질과 분석가능한 데이터를 이용해서 미래의 서비스를 예측할 수 있도록 만들어져야 할 것이다.

1. 요구사항 이해

요구사항은 단기/중,장기로 나눌 수 있을 것이다. 단기적으로는 현재의 플랫폼의 신뢰성을 확보할 수 있는 모니터링과 관련된 요구사항들이다. 중,장기 적으로 간다면 서비스와 네트워크 그리고 시스템 정보를 분석해서 서비스의 품질을 예측하고 서비스 정책결정을 하는데 도움을 줄 수 있는 분석/예측 시스템을 제공할 수 있어야 한다.

1. 아키텍처의 선택과 수립

QOS는 EMS와 비슷한 활동이 될 수 있으며, 몇개의 아키텍처와 아키텍처가 구현되어 있는 제품 - Zenoss(:12)와 같은 - 을 찾아낼 수도 있다. 그렇다면 기존의 아키텍처중 어느 것을 선택할 것인지를 결정해야 한다. 만약 기존의 아키텍처중 만족할 만한 것이 없다면, 새로 수립해야 할 것이다. 아키텍처를 선택했다고 해서 끝나는 것이 아니다. 아키텍처가 이해된 모든 요구사항을 만족하는 경우는 없기 때문에, 선택한 아키텍처를 다시 분석하고 재구성하는 활동을 해야 한다. 예로든 Zenoss(:12)의 경우는 분산 모니터링 요소가 아키텍처에 포함되어 있지 않다. 또한 분석/예측과 관련된 요소도 포함되어 있지 않다. 이들 요소를 포함할 수 있도록 아키텍처를 수정해야 할 것이다.

1. 아키텍처 문서화 의사소통

QOS 시스템의 가질 수 있는 가장 큰 문제점은 막상 만들어 놨는데 사용하지 않는것이다. 힘들게 모니터링 환경을 구축해놨더니, 전혀 사용하지 않거나 극히 일부만 사용하는 경우를 흔히 찾아볼 수 있다. 그러므로 필요한 사항들을 문서화 해두고 이를 이용해서 이해당사자들과 꾸준히 의사소통을 해야 한다.

1. 아키텍처 분석과 평가

선택된 아키텍처가 합리적인 것인지를 평가할 수 있어야 한다. 품질요소와 시나리오를 통한 평가라든지, ATAM, CBAM 등의 평가 결정방법이 있다고 한다. 이것은 나중에...

1. 아키텍처 기반 시스템 개발

개발조직과 관련된 영역이다. 입출력 데이터, 시스템 환경등을 명확히 이해하고 구축할 수 있어야 한다. 많은 시간을 개발자와 협업하면서 명확한 시스템이 될 수 있도록 해야 한다.

1. 아키텍처 준수 여부 확인

프로젝트가 진행되다 보면, 시간, 개발능력 기타 여러가지 이유로 아키텍처 정책을 따르지 않는 경우가 발생한다. 예를 들어 시스템의 이벤트 처리를 snmp(:12) trap을 이용하기로 결정했다고 가정해 보자. 만약 개발자가 snmp에 대한 충분한 이해를 하지 않고 있을 경우, snmp 대신 사용하기 편리한 syslog(:12)를 대신 사용할 수 있을 것이다. 당장 기능을 구현하는데에는 문제가 없겠지만, 분산 모니터링 환경을 위해서 이벤트를 OID로 통합하고, 이를 잉요해서 계층적 Event Class를 만들도록 계획했다면 구현막바지에 분명히 문제가 발생할 것이다.

최고의 아키텍처는 존재하지 않는다. 최선이라고 생각되는 아키텍처가 존재할 뿐이다. 어떤 제품은 성능을 우선시 할 수 있다. 이런 제품에 3Tier 클라이언트/서버 아키텍처는 적합하지 않다. 3Tier 클라이언트 / 서버 아키텍처는 유연하고 확장성이 용이한, 그렇지만 성능은 그다지 중요하지 않은 엔터프라이즈 환경에 적합한 아키텍쳐다.

그렇지만 좋은 아키텍처를 위한 일반적인 권고사항들은 있다.

1. 아키텍트는 소수의 그룹으로 유지되어야 한다.
2. 이해관계자의 요구사항을 수집 분석해야 하고, 이들 요구사항에 대한 우선순위를 정해야 한다.
3. 아키텍처의 모든 내용은 이해관계자가 쉽게 이해할 수 있도록 문서화 되어야 한다.
   • 현재 만들고 있는 QOS 시스템은 이러한 문서화가 부실한 것으로 생각된다. 내일부터 제대로된 문서를 만들어야 할거 같다.
4. 아키텍처와 관련된 내용은 협업차원에서 이해관계자에게 배포되어야 한다.
5. 성능, 확장성, 운용성등과 같은 것들은 수치로 정량화 될 수 있어야 한다.
6. 일반적으로 좋은 아키텍처는 최소한의 기능을 포함하도록 하고, 후에 유연하게 다른 기능들을 포함시킬 수 있는 방향으로 설계될 필요가 있다.
7. 소프트웨어개발은 한정된 시간과 자원을 가지고 이루어진다. 그러므로 이들 사이에 균형을 맞출 필요가 있다. 얼마만큼의 네트워크 자원을 소비하는지, 얼마만큼의 CPU 혹은 메모리 자원을 소모할지를 예상할 수 있어야 한다.