소프트웨어 아키텍처와 시스템 아키텍처는 무엇이 다른 것일까? 거의 20년? 훨씬 전부터 논해져오던 주제일 것이다. 하지만 모놀로식 시스템 구성에서 보다 복잡한 event driven이나 queue나 구독과 같은 다양한 요소들이 결합되어 시스템이나 서비스가 만들어지는 지금 이 경계는 보다 확실하게 선이 그어졌다고 봐도 과언이 아닐 것이다.
첫째로 시스템 아키텍처는 특정 시스템 혹은 컴포넌트의 성질에 한하여 구성된 아키텍처를 의미한다. 즉, 하나의 특정 성질을 기반으로 한 기능이 있다면 그 기능에 한한 아키텍처를 말하는 것이다.
둘째로 소프트웨어 아키텍처는 이러한 시스템 아키텍처로 이뤄진 다양한 요소들의 결합으로 이뤄진 전체 아키텍처를 의미한다. 어찌 보면 시스템 아키텍처의 상위 버전이라고 봐도 무방할 것이다.
그렇다면 소프트웨어 아키텍처는 시스템 아키텍처와 달리 어떤 해안을 가져야 할까?
그들은 무엇을 바라볼 줄 알아야 하고 어떤 능력을 갖춰야 할까? 확실한 것은 특정 도메인 한정적으로 지식을 보유하고 있어선 안된다는 점일 것이다.
소프트웨어 아키텍처는 나무보단 숲을 바라봐야 하는 사람이다. 그렇다고 시스템 아키텍처가 나무만 바라본다는 것은 아니다. 좀 더 포괄적인 범위에서 문제를 해결하기 위한 안목을 가져야 함을 의미한다.
이번에 출간된 "소프트웨어 아키텍처 101"이 바로 그런 소프트웨어 아키텍처가 가져야 하는 안목과 함양해야 할 능력이 무엇인지 잘 정리해둔 책이라 생각되며 소프트웨어 개발을 지향하는 사람들이라면 한 번쯤 꼭 읽어보길 권장하는 도서이다.
【책의 구성】 '소프트웨어 아키텍처 101'의 책의 구성은 어떠한가.
이 책은 총 세 개의 파트로 구성되어 있으며 총 24개의 챕터로 이뤄져 있다. 책의 두께는 제법 있는 편이다. 450pg 정도 되는 양인데, 책의 구성과 내용이 좋아 쉽게 읽히는 편이므로, 두꺼운 책을 읽는데 어려움을 느끼는 독자라면 책을 여러 부분으로 나눠 조금씩 꾸준히 읽어가시길 권장한다.
이 책은 다양한 사례들이 소개되어 있고, 또한 그 사례 스터디를 통해 소프트웨어 아키텍처가 함양해야 할 능력과 자질에 대해서 잘 설명하고 있다.
첫째로 소프트웨어 아키텍처는 전달받은 명세를 기반으로 설계를 시작할 때, 쓰여있는 명세 내용 외에도 훨씬 멀리 내다볼 수 있는 해안을 가져야 한다.
가령 대학 수강 신청 시스템을 독자들이 구현하다고 생각해 보자. 이때 이 시스템이 가져야 할 가장 중요한 사항은 무엇이겠는가? 바로 탄력성이다.
탄력성을 갖춰야 하는 이유는 간단하다. 대학교에서 수강신청을 해본 사람은 알겠지만, 접속 5분 이내로 주요 신청 과목 (특히나 좋은 시간대의 수강 항목)은 수강 신청 시작과 동시에 엄청난 트래픽이 몰리게 되어있다. 그렇기에 이러한 탄력적인 트래픽을 감당할 수 있는 아키텍처가 사전에 준비되어 있어야 한다.
즉, 소프트웨어 아키텍처는 큰 배를 이끄는 선장이라 할 수 있다. 선장은 조타수와 갑판장 등의 모든 일을 디테일하게 알 순 없다. 그리고 알 필요도 없다. 단지, 큰 그림을 그리기 위한 지식으로써 넓은 지식에 대한 해안을 가지며 된다.
다음의 내용들은 이번 도서를 리뷰하면서 인상 깊었던 챕터 위주로 정리해 보았다. (어쩌다 보니, 앞장 위주가 되었다.)
1챕터 : 서론
보통은 서론 내용은 책의 핵심으로 뽑지 않는 편이다. 왜냐하면 전체 내용을 포괄하여 설명하는 데에 그치는 것이 바로 서문이기 때문이다. (어찌 보면 가장 중요한 부분이라고도 할 수 있다.)
하지만 이번에 서문을 리뷰에 포함한 이유는 다음과 같다.
- 소프트웨어 아키텍처로써 함양해야 할 덕목과 능력에 대해서 논하고 있다
- 소프트웨어 아키텍처가 무엇인지에 대해서 설명하고 있다.
- 엔지니어링과 소프트웨어 아키텍처 링 위 차이가 무엇인지 논하고 있다.
- 이러한 사항들을 실제 한국의 개발 환경에 적용할 수 있을지 생각해게 한다. 정도를 꼽을 수 있다.
소프트웨어 업계에서 일한다는 것은 한시도 빠지지 않고 계속 공부를 해야 함을 의미한다. 솔직히 어느 분야가 되었건 산업 환경은 계속 변화한다. 변화는 환경 속에서 도태되지 않고 나아가는 방법은 더디더라도 꾸준히 학습하여 부족한 부분을 채워가는 것일 것이다.
세상은 변하지 않는다고 하는데. 세상에 변하지 않는 것은 없다. 엔트로피는 끊임없이 증가하는 방향으로 나아가고 있고 같은 뉘앙스의 문제를 대면할지라도 그 디테일한 내용은 어느 하나 같은 것이 존재할 수 없는 것이 세상의 이치이기 때문이다.
그렇기에 당면한 숙명을 받아들이고 꾸준히 학습하고 변해가는 세상에 적응하기 위해 분투할 줄 아는 덕목 역시 소프트웨어 아키텍처라면 당연히 지니고 있어야 할 덕목 중 하나이다.
또한 소프트웨어 아키텍처는 선장의 역할을 하는 포지션이다. 물론 한국 IT 업계에서 소프트웨어 아키텍처라는 직군은 따로 정해져 있지 않다. 보통 TL이나 leader 급 혹은 시니어 개발자들이 이러한 역할을 대신하거나 겸직하고 있다.
그렇기에 관련 포지션이 되면 보통 한 기술을 깊이 알기보단, 두루 넓게 아는 형태로 학습 형태와 기술 파악 형태를 바꾸게 된다. 이유는 간단하다. 보다 넓은 범위에서 기술의 접목점을 생각하기 위함이다. 소프트웨어 아키텍처는 기술을 두루 알아야만 한다. A라는 서비스를 만들 때 기술 도메인이 굉장히 한정적이라면 다양한 상황에서 탄력성과 내구성 그리고 확장성을 갖춘 소프트웨어를 설계하는 것이란 불가능에 가깝기 때문이다.
그 밖에도 기술의 최신 트렌드 파악, 비즈니스 도메인 지식 획득, 대인 관계 기술의 이해도의 전문화, 사내 정치와 형국에 대한 적절한 대응 능력 등을 책에서 손꼽고 있다.
이 중에 필자도 강조하고 싶은 부분이 있다면 "사내 정치와 형국에 대한 적절한 대응"을 손꼽고 싶다. 소프트웨어 아키텍처가 된다면 단연 사내의 흐름을 잘 이해해야 한다.
좋은 제품은 회사의 결정에 의해서 출시되게 되어있다. 아무리 제품이 좋아도 회사가 출시하지 않으면 말짱 꽝임을 명심하도록 하자.
8챕터 : 컴포넌트 기반 사고
이 파트에서는 컴포넌트 기반의 사고의 중요성에 대해서 설명하고 있다. 컴포넌트를 어떤 식으로 구성하는 것이 옳은 일일지, 그리고 아키텍처라면 어떤 입장에 의거하여 명세의 흐름을 이해해야 하는지에 대해서 말이다.
가령 여러분은 실리콘밸리의 작은 IT 벤처를 운영하고 있다고 하자. 어느 날 실리콘 샌드위치라는 회사에서 연락이 왔다. 명세는 간단하다. 샌드위치를 실리콘밸리에 팔려고 한다. 주문과 제고를 컨트롤할 수 있는 시스템을 설계해 달라.
이제 여러분은 실리콘밸리에 있는 수많은 불쌍한 개발자에게 저렴한 샌드위치를 판매하기 위한 시스템을 개발하는 사명을 지게 되었다.
명세만 보아선 간단하다. 주문 및 제고 파악 시스템을 만들면 된다.
하지만 생각해야 할 지점은 수도 없이 많다.
주 고객은 누구일까? 어느 시간대에 트래픽이 몰릴까? 사용자들은 주로 어떤 플랫폼 상에서 주문을 진행할까? 이 시스템은 추후 전 세계로 확장할 것인가? 최대 동접은 어느 정도로 하는 것이 좋을까? 등등이 이에 속한다.
명세는 정말 간단했다. 한 줄이었다.
그런데 생각해야 할 포인트는 상당히 많았다. 위에 열거한 것만 들여다보아도 최소 5가지는 넘는다. 그렇다 소프트웨어 아키텍처는 명세를 받아들고 명세에 맞는 기술들과 상황을 해안을 가지고 분석한 후, 본인의 팀원들에게 제각각 맡는 역할에 따라서 일을 분배해야 하는 선장의 역할을 해야 한다.
이때 기술적 해안을 가지고 어떤 기술로 관련 상항 혹은 명세에 대해서 접근하면 좋겠다고 구성원들에게 전달할 수도 있다. 하지만 한 가지 명심할 점은 본인의 의견이 항상 정답은 아니라는 점이다.
소프트웨어 아키텍쳐링은 최악들 중에서 가장 차악을 꼽는 것임을 책에서 강조하고 있다. 맞는 말이다. 세상에 옵티멀한 설루션은 없고, 설령 그런 것이 있다 한들 우리 인간은 다루지 못할 것이다. (생각해 보라, 이 세상에 존재하는 문제는 모두 제각각이다. 이것을 동시에 모두 해결할 설루션은 신 외엔 아무도 이해하지 못할 것이다.)
즉, 이것저것 모두의 니즈를 만족하기보단. 최소한의 그리고 반드시 만족해야 하는 우선순위의 컴포넌트를 정하고 이를 최우선으로 아키텍쳐링하는데에 집중해야 한다. 그 외의 일은 그다음에 생각해 봐도 늦지 않는다.
2파트 : 아키텍처 스타일
파트 2에서는 아키텍처링 스타일에 대해서 정리하고 있으며 그 목록은 하기와 같다.
모놀리식
- 레이어드 아키텍처
- 파이프라인 아키텍처
- 마이크로커널 아키텍처
분산형
- 서비스 기반 아키텍처
- 이벤트 기반 아키텍처
- 공간 기반 아키텍처
- 서비스 지향 아키텍처
- 마이크로 서비스 아키텍처
위의 것들이 대표적인 아키텍처들이다. 정말 이 업계에 몸담고 있다 보면 한 번쯤은 다들 들어봤을 법한 아키텍처들이다. 특히 레이어드 아키텍처와 이벤트 기반 아키텍처는 정말 많이 들어본 아키텍처이다.
이중 요즘 가장 인기 있는 아키텍쳐링을 꼽으라면 "마이크로 서비스 아키텍처"가 그것일 것이다.
각각의 아키텍처와 관련된 자세한 내용은 책을 참고하시길 바란다.
다만, 책에서 정말 친절하게도 각 아키텍처별 장단점을 별점으로 정리하고 있으니, 신규 서비스의 적용이나 혹은 본인이 요즘 관심 있어 하는 기술은 어떤 특성을 갖추고 있는지 등을 파악하는 데에 좋은 팁과 방향성을 얻을 수 있을 것으로 보인다.
하지만 반드시 이점은 알아두도록 하자. 모든 아키텍쳐링은 장단점이 있다는 사실을 말이다.
아키텍처의 역할은 장단점 사이에서 가장 트레이드오프가 적은 아키텍처를 선택하는 역할임을 말이다.
【 "소프트웨어 아키텍처 101"를 읽고서…….】
한때 소프트웨어 구성에 있어서 모놀리식만큼 뛰어난 구성은 없다고 생각한 적이 있었다. 한 파일에 모든 코드들을 집어넣고 같은 코드라 할지라도 가독성은 둘째치고 조금의 리소스라도 더 절약하면 최고의 코드라고 각광받던 시절에 말이다.
하지만 시대가 많이 변했다. 이제는 위와 같은 구성과 코드를 짠다면 코드에서 스멜이 지독하게 나는 악취 코더로 전략하게 된다.
많은 것들이 복잡해지고 많은 것들이 세분화된 지금. 한 명이 모든 것을 해낸다는 것은 어찌 보면 지독한 욕심이고 말도 안 되는 일을 도모하는 것일지 모른다.
그렇기에 소프트웨어 아키텍처라는 새로운 직군도 생겨나고 전에 없던 데이터 아날 리스트, FE 개발자, BE 개발자와 같이 세분화되어 나누어 가는 것일지 모르겠다는 생각이 든다.
혼자서 뛰어나면 1M를 뛰어가는 데에 참으로 쉬울지 모른다. 하지만 100명이 협업하여 한 가지 일을 도모한다면 인당 50CM만 걸어가도 5000CM 즉 50M를 갈 수 있게 된다.
따라서 개인의 역량만큼 중요한 것이 협업에 대한 태도이고 작은 나무를 보는 것 대신 큰 안목을 가지고 자신을 끊임없이 쇄신하여 큰 숲을 그릴 줄 아는 개발자 나아가 아키텍처가 더 주목받고 높게 평가되는 시대가 바로 지금의 시대이지 않나 싶다
#본 도서는 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.
