본문 바로가기

POST/Tech

비개발자도 쉽게 이해하는 ‘아키텍처’의 개념

 

 

이제 막 개발을 시작한 개발자 혹은 비개발자들은 ‘Architecture’라고 하면 어떤 것인지 정확한 개념을 떠올리기 어려울 수 있습니다. 아키텍처가 무엇인지 대략 감은 오는데, “Architecture의 정의란 ~~이야” 라고 설명하기 쉽지 않은 것이죠! 만약, 누군가 여러분에게 '아키텍처가 뭐야?' 라고 물어본다면 정확하게 설명할 수 있나요?  

Architecture는 영단어로는 ‘건축학’ 이라는 뜻인데, 내용을 풀어서 살펴보면 아래와 같습니다.  

  • 시스템 구성 및 동작 원리를 나타내는 것
  • 구성 요소 간의 관계 및 시스템 외부 환경과의 관계를 묘사하는 것  
  • 시스템 구성 요소에 대한 설계 및 구현을 지원하는 수준을 기술하는 것
  • 요구 사양 및 시스템 수명 주기를 고려하는 것  
  • 시스템의 전체적인 최적화를 목표로 하는 것

위 내용을 정리하면 “하나의, 서비스가 어떻게 구성되며 어떻게 동작이 된다”를 표현하는 것이라고 볼 수 있겠습니다. 즉, 아키텍처란 서비스의 동작 원리를 나타내는 것입니다.  

미국의 소프트웨어 개발자 Martin Fowler는 소프트웨어 아키텍처가 무엇인지 정의한다면 ‘중요한 어떤 것’ 이라고 설명했는데요,

위의 소프트웨어 기능의 고도화 그래프를 통해 확인할 수 있듯이 좋지 않은 디자인을 가진 소프트웨어는 시간이 지날수록 기능을 추가하는 것이 어렵고 이후에도 지속적으로 어려워집니다. 반면에 좋은 디자인을 가진 소프트웨어는 기능을 추가하기 수월합니다. 소프트웨어가 잘 컴포넌트화 되어 있기 때문입니다. 이 말은, 더 나은 내부 퀄리티를 가진 소프트웨어를 고른다면 추후엔 새로운 기능을 더 빠르게 많이 추가할 수 있게 되고, 내부 퀄리티가 낮은 제품은 문제 사항에 대한 빠른 개선이 불가능하게 된다는 것입니다.  

이것이 바로 소프트웨어 아키텍처가 중요한 이유라고 Martin Fowler는 말합니다.  

아키텍처는 의사결정의 결과물이며 이후 이어질 활동에 대한 기준이 됩니다. 단순하게 아키텍처를 설계의 결과물로 보는 것은 설계 과정을 단편적으로 바라보는 것입니다. 설계는 구상한 것을 현실화하는 것이고 다양한 제약 사항을 해결하며 초기 목적을 달성하는 과정을 의미합니다. 따라서 설계에서의 아키텍처는 단순 산출물이 아니라 제약사항의 해결, 그 과정에서의 최적의 의사결정의 집약체가 됩니다.  

사실 아키텍처의 정의에서 정답이 존재하진 않습니다. 아키텍처는 설계 과정 중에 수행되는 다양한 의사결정의 결과물로 그 자체로의 존재입니다. 아키텍처는 변화에 저항하기 위해 만드는 것이 아닌, 변화에 능동적으로 대응할 수 있는 미래를 위해 만드는 것입니다.  

결국, 아키텍처는 구조화 과정의 시작이자, 기준이라고 할 수 있겠습니다.  

복잡성은 시스템이 가진 고유의 특성이고 아키텍처는 복잡성을 대응하기 위한 고유의 방식입니다. 시스템마다 복잡성이 다르기 때문에 이에 대응하는 방식도 다양할 수밖에 없습니다. 아키텍처는 명확히 지키고자 하는 무언가가 있고, 이것이 지속화 될 수 있도록 구조화하는 과정이 필요합니다.  

이 구조화 과정의 시작이 바로 아키텍처이며 아키텍처는 시스템의 재설계, 재구축의 시작입니다.  

참고  

https://brunch.co.kr/@taehyo/7

https://www.youtube.com/watch?v=4E1BHTvhB7Y&t=3s

https://www.redhat.com/ko/topics/cloud-native-apps/what-is-an-application-architecture

https://ko.wikipedia.org/wiki/%EC%8B%9C%EC%8A%A4%ED%85%9C_%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98