소프트웨어 아키텍처 101

병특시절에 개발했던 3티어 구조의 서버부터 세월을 그대로 맞으면서 겪었던 아키텍처들이 책의 파트 2에 하나씩 소개되어 있다. 코드는 거의 없고, 각 아키텍처가 등장한 배경과 용도 그리고 장단점을 거시적으로 잘 설명해준다. 깊이 내려가지는 않는다 싶었는데, 아직 읽어보지 않아서 모르겠지만, 최근에 출간된 '소프트웨어 아키텍처 The Hard Parts'라고 심화편에서 더 깊이 설명하는가 보다. 책의 후반부에도 재미난 내용이 많다. 덕분에, '체크! 체크리스트' 책을 읽어보고 싶어졌다.

 

아래에서 강조하는 것처럼, 트레이드 오프에 대한 설명이 많이 나온다. 은탄환은 없다.

아키텍처 특성을 선택하는 문제에 있어서 정답은 없으며 오직 (마크가 한 유명한 말처럼) 잘못된 선택만 있을 뿐이라는 점을 명심하세요.아키텍처에서는 틀린 답은 없고 값비싼 답만 있습니다!
...
개발자가 구현하는 방법이 유일한 소프트웨어 시스템은 없습니다. 모든 설계는 서로 다른 트레이드오프 조합이 반드시 뒤따릅니다. 요구사항을 충족하는 설계안은 무수히 많이 나올 수 있으므로 아키텍트는 하나의 진짜 설계를 발견하느라 집착해선 안 됩니다. 각 설계 결정의 트레이드오프를 객관적으로 판단하고 트레이드오프가 나쁜 것 중에서 제일 나은 것을 선택하도록 노력하세요.

어디까지 고려할 것인가? 무게 중심을 어디에 두고 균형을 맞출지는 중요한 문제다.

 

책에서 설명하는 커네이선스, 퀀텀 등의 용어들 외에도, '~성'이라고 소개하는 아키텍처 특성들은 현업을 하다 보면 접하게 되는 것들이면서 또 표준은 없는 애매한 용어들이 많은데, 세부적으로 잘 설명하고 있다. 나도 애매하게 이해하고 있던 것들을 다시 한번 정리할 수 있었다.

이 세상에 완벽한 표준 목록은 없습니다. 국제 표준 기구International Organization for Standardization(ISO)가 발표한 기능별 목록7만 보아도 지금까지 우리가 나열한 특성들과 중복되거나 카테고리 목록이 불완전한 편입니다.

 

다만, 맡은 역할이 다를 뿐인 아키텍트를 개발자의 상위 레이어로 묘사하는 부분들은 공감하지 않는다. 책에서도 아키텍트가 무엇을 하는 사람인지 정의하기 어렵다고 하는데, 아키텍처를 설계하고 개발팀의 컨벤션을 협의하고 관리하는 역할이 필요하겠지만, 그 역할이 아키텍트만의 것은 아닐 것이다. 책의 후반부에 '아키텍트 성향' 챕터에서 주의할 내용을 언급하면서 경계하고 있지만, 아키텍트라는 명칭은 애매한 면이 있다.

아키텍트의 가치는 대부분 기술에 대한 폭넓은 이해와 그 기술을 사용해서 특정한 문제를 해결하는 것입니다. 즉, 아키텍트는 어느 한 가지 문제만 해결 가능한 한 가지 전문 지식보다는, 문제를 해결할 수 있는 다섯 가지 솔루션을 알고 있는 게 더 중요합니다.

방향을 가이드 할 수 있다는 것은 중요하다. 뭐가 문제인지 어디를 봐야 하는지 인지할 수 있는 통찰력이 필요하다. 그렇다고, 너무 큰 방향성만 제시하고 나 몰라라 할 수는 없다.

아키텍트 입장에서는 커플링 정도보다 모듈이 어떻게 커플링되어 있는지가 더 궁금하기 마련입니다. 이를테면, 아키텍트는 동기 통신이냐, 비동기 통신이냐를 고민하지, 그것을 어떻게 구현할지는 별로 관심이 없습니다.

관심을 가져야 한다고 생각한다. 단순히 동기, 비동기로 퉁치기에는 그 아래 블로킹, 논 블로킹의 조합 등 가려진 사항들이 많다. 아래 내용처럼, 세부 구현까지 내려가지 않더라고 코드의 구성에 관심을 가져야 한다.

아키텍트는 개발자가 코드를 어떻게 패키징하는지 반드시 알아야 합니다. 아키텍처에 중요한 영향을 미치기 때문입니다. 여러 패키지가 서로 단단히 커플링되어 있으면 그 중 하나를 다른 작업에 재사용하기가 아주 어려워집니다.

 

그리고, 맞는 말일 테지만...

‘아키텍트는 기업의 정치 기류를 이해하고 처세를 잘 해야 한다’

일은 일로써 풀었으면 하는 소망이 있다.

 

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=283018961

[전자책] 소프트웨어 아키텍처 101

아키텍트는 이전 시대에서 물려받은 가정과 공리에 의문을 제기할 중요한 책임이 있습니다.
...
소프트웨어 개발자는 어떤 기술이나 접근 방식에 마음을 빼앗기기 쉽지만, 아키텍트는 언제나 모든 선택의 좋고 나쁨을 냉정하게 평가해야 합니다. 실로 이 세상에서 모 아니면 도 식으로 간편하게 결정할 수 있는 건 하나도 없습니다. 만사가 다 트레이드오프죠.
...
소프트웨어 아키텍트는 이렇게 끊임없이 변하는 생태계 안에서 뭔가 결정을 내리는 사람들입니다. 그렇게 결정한 기반을 비롯해 모든 것이 다 변하므로 아키텍트는 과거 소프트웨어 아키텍처에 관한 글에서 강조한 핵심 원칙들도 다시 검토해봐야 합니다.
...
진짜 기술 리스크와 리스크처럼 보이는 기술 리스크의 차이를 이해하는 것은 아키텍트가 평생 학습해야 할 주제입니다. 아키텍트답게 생각하려면 꽁꽁 언 원시인의 사고 방식과 경험을 극복하고 다른 솔루션을 찾아보면서 더 적절한 질문을 해야 합니다.
...
우리는 모든 아키텍트가 코딩을 하면서 어느 정도의 기술 깊이는 유지해야 한다고 굳게 믿습니다(2.2절).
...
도메인 이해관계자와 협력해서 주요 아키텍처 특성을 정의하는 한 가지 팁은, 최종 목록을 가능한 한 짧게 하는 것입니다. 아키텍처에서 가장 흔한 안티패턴 중 하나가, 모든 아키텍처 특성을 지원하는 제네릭 아키텍처generic architecture를 설계하려는 것입니다.
...
초기 식별한 컴포넌트들만으로 제대로 된 설계가 나올 가능성은 거의 없으니 아키텍트는 컴포넌트 설계를 이터레이션하면서 조금씩 개선해야 합니다.
...
기술 의존도가 낮은 도구를 사용하면 팀원들이 옳지 않은 것은 버리고 자유롭게 실험, 개선, 협력, 토론함으로써 아티팩트의 진정한 특성을 발현시킬 수 있습니다.
...
균형을 유지하는 기술로 20분 규칙20-minute rule이 있습니다. 아키텍트로서 커리어를 유지하기 위해 새로운 것을 배우거나 특정 주제를 깊이 파고드는 시간을 매일 최소 20분은 할애하라는 규칙입니다.

-알라딘 eBook <소프트웨어 아키텍처 101> (마크 리처즈.닐 포드 지음, 이일웅 옮김) 중에서