linu***
2021-11-22

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'개발자가 아키텍트\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'로 전향하는 데 실질적인 도움을 주는 실무 지침서다. 아키텍처 기초(패턴, 사고, 특성)와 아키텍처 스타일(레이어드, 파이프라인, 마이크로커널, 이벤트, 서비스, 오케스트레이션), 그
아키텍처.
'건축양식'이란 의미지만, 소프트웨어 업계에서는 흔히 설계자란 의미로 쓰이고 있다.
초창기 소프트웨어 산업이 만들어지면서 '만든다'는 의미에서 건축업계 용어를 많이 사용하고 있다.
IT 산업이 발전되면서 점점 그 색채가 옅어지기는 하지만 아직 큰 구조적 맥락에서는 이미 굳어져버린 용어라 계속해서 쓰이고 있다.
'아키텍처'라고 하면 개발자들의 마지막 커리어라고 할 수 있다.
프로덕트 매니저, 프로덕트 오너는 기획, 디자인 파트에서도 가능하지만 아키텍처는 대부분 기술 기반의 개발자 출신들이 많다.
기술에 대한 이해가 풍부해야만 가능한 영역이기도 하다.
아키텍처란 직책에 기술적 정의도 모호하고 업무 범위 또한 그러하다.
예전에는 백앤드, 프론트앤드, 그리고 시스템에 대한 지식과 경험이 있는 개발자가 가능한 영역이였지만, 요즘은 별도의 영역으로 전문 인력들이 나오고 있다.
아키텍처에 대한 책이 그리 많지는 않다.
더구나 지금까지의 책들은 최근의 변화를 제대로 담고 있지 못하고 있다.
기술의 변화는 1년에도 몇 번씩 바뀌는데 그 기술을 담아야 할 아키텍처 분야라고 바뀌지 않을까?
위에서 말한바와 같이 아키텍처는 업무와 기술범위가 조직마다 조금씩 다르기에 표준화된 문서나 책을 만나보기 어려웠다.
그래서, 이 책 '소프트웨어 아키텍처 101'이 너무 반가웠다.
저자들의 풍부한 경험과 최근의 트랜드를 이 책 한 권에 잘 담았다.
책은 크게 3부로 나누어져 있다.
1부에서는 아키텍처란 무엇인지를 설명하고 있다.
어떤 기술과 사고방식을 갖추고 있어야 하는지에 대해 말해주고 있다.
2부에서는 다양한 아키텍처 스타일을 보여준다.
왠만큼 다양한 도메인 경험이 있지 않고서는 이런 다양한 아키텍처를 모두 만나 볼 기회가 없을 것이다.
그리고 자신이 편안하게(?) 느끼는 분야에서만 일하기에 이 모두를 접하기 어렵다.
(나만 그런가?)
3부에서는 아키텍처가 갖추어야 할 자질과 기술에 대해 말하고 있다.
최근의 기술들도 소개하고 있기에 바로 실무에 접목할 수 있는 방법들을 만나볼 수 있다.
워낙 관심이 많은 분야였기에 모두가 흥미로웠지만, 가장 좋았던 부분은 1부였다.
2부의 아키텍쳐 스타일은 계속 추가될 것이고, 3부의 기술들은 변형되거나 새로운 것들로 대체될 수 있다.
하지만 '아키텍처'에 대한 본질적 정의와 의의는 변하지 않고 계속될 것이다.
특히 '트레이트오프'에 대한 정의가 너무 좋았다.
소프트웨어 아키텍처 제 1법칙으로 소개하고 있다.
무언가를 얻기 위해서는 다른 것을 희생할 수 있어야 한다.
제한된 자원-시간, 돈 등-으로 모든 것을 충족시킬 수 없다.
한정된 자원으로 가장 효율적인 방법을 찾는 것이 아키텍처이다.
우리는 트레이드오프 분석이라는 중대한 이슈도 다루었습니다.
소프트웨어 개발자는 어떤 기술이나 접근 방식에 마음을 빼앗기기 쉽지만, 아키텍트는 언제나 모든 선택의 좋고 나쁨을 냉졍하게 평가해야 합니다.
실로 이 세상에는 모 아니면 도 식으로 간편하게 결정할 수 있는 건 하나도 없습니다.
만사가 다 트레이드오프죠.
어느 직종이나 일종의 직업병이 있겠지만 소프트웨어 개발자들에게는 '기술'이 그러하다.
자신이 만들어 온 기술과 방법, 프로그래밍 언어에 대한 맹목적인 믿음이 대표적인 예라고 할 수 있다.
제대로 만들었고 정상적으로 작동하기에 문제가 없다.
다만 시간이 지나면서 더 나은 기술, 더 좋은 방법이 있음에도 기존의 것을 고집한다면 문제가 되는 것이다.
금융기관의 예를 들자면 예전의 코볼이 그랬고, 현재의 자바가 그러하다.
IT 강국이라고 하는 우리나라지만 다양성의 면에서 보면 결코 그렇지 않다.
그렇기에 '트레이드오프'가 주는 의미가 무척 깊게 다가온다.
역할, 직책, 직무에 상관없이 소프트웨어 아키텍트에게 바라는 핵심적인 요구사항은 다음 여덟가지로 정리할 수 있습니다.
- 아케텍처 결정을 내린다.
- 아키텍처를 지속적으로 분석한다.
- 최신 트랜드를 계속 유지한다.
- 아키텍쳐 결정의 컴플라이언스를 보장한다.
- 다양한 기술과 경험에 노출된다.
- 비즈니스 도메인 지식을 보유한다.
- 대인 관계 기술이 뛰어나다.
- 정치를 이해하고 처세를 잘한다.
저자들은 불투명한 아키텍트의 업무를 위와 같이 정의했다.
마지막 '정치를 이해하고 처세를 잘한다'가 좀 이질적으로 느껴지지만 아키텍처의 업무를 생각한다면 어쩌면 가장 필요한 자질일지로 모른다.
실제로 아키텍처의 업무 중 가장 많은 시간을 차지하는 것인 회의다.
다양한 부서와의 협업이나 조율이 필수적이기에 정치와 처세, 대인 관계 기술은 필수라고 할 수 있다.
아키텍처라는 업무가 생기기 전에는 시니어 개발자가 그 업무를 맡아왔다.
다양한 경험과 깊은 지식을 바탕으로 기술적 조언을 한 것이다.
하지만 아키텍처는 '좁고 깊은 지식'이 아니라 '넓고 얕은 지식'이 있어야 한다.
'어떻게'가 아니라 '무엇을' 결정하는 자리이기 때문이다.
망치만 들고 있는 사람은 벽에 옷을 걸기 위해 못을 박으려고 하지만, 간단하게 접착식 옷걸이로 해결할 수도 있다.
아키텍처는 문제를 해결할 수 있는 다양한 방법을 알고 있어야 하고, 그것을 제시할 수 있어야 한다.
아카텍트는 아키텍처와 설계 원칙을 결정하고 팀, 부서뿐만 아니라 회사 전체의 기술 결정을 가이드하는 사람입니다.
아키텍트는 기술 선택을 가이드하는 사람이지, 정해주는 사람이 아닙니다.
가장 오해가 많은 부분이 아닐까 싶다.
아키텍트는 '가이드'를 하는 사람이지 '정하는' 사람이 아니다.
현장에서 많이 오해하고, 잘못 실행되고 있는 부분이다.
아키텍쳐가 경험이 많기에 정해주길 원하거나, 정한대로 개발해 주길 원한다.
책을 보면서 그동안 잘못 알고 있었던, 그리고 몰랐던 아키첵처의 세계에 대해 많이 배울 수 있었다.
아키텍처가 되기 위해서는 깊은 경험보다는 다양한 경험과 폭넓은 지식이 있어야 한다.
그리고 언제든지 '트레이드오프'를 할 수 있는 용기도 필요하다.
최근의 기술과 트렌드를 보여주는 아주 오랫만에 흥미진진하게 볼 수 있는 아키텍처 책이다.
이 책으로 아키텍처 분야도 기술 분야처럼 최신화 되었으면 하는 바램이다.