“훌륭한 아키텍처가 소프트웨어의 성공을 보장하지는 않지만, 나쁜 아키텍처는 필연적으로 실패를 가져 온다.” 라는 말로 저자는 이 책을 시작 한다. 그리고 개발자라면 소프트웨어 아키텍처에 대해 꼭 알아야 한다고 한다.

 

p.34 소프트웨어 아키텍트가 하는 일(1.1)


소프트웨어 아키텍트가 하는일
소프트웨어 아키텍트는 모든 이해관계자와 협업 하면서 비즈니스 목표와 요구사항을 만들어 간다. 소프트웨어 시스템을 구현 가능한 작은 조각으로 나누는 동시에 전체 시스템이 일관성 있게 동작 하도록 큰 그림을 그린다. 또한 품질에 영향을 주는 다양한 품질 속성(Quality Attribute)  사이에서 균형을 잡아가며 어쩔 수 없이 늘어나는 기술 부채(Technical Debt) 도 관리 한다.

위에서 이야기한 소프트웨어 아키텍트가 하는일 이라는 문장이 이해가 되지 않는 나 같은 사람에게 반드시 이 책을 추천 한다.

단순히 소프트웨어 아키텍트가 하는일을 소개하는 문장에서 부터 알아들을 수 없는 단어들이 많이 보인다. 특히 품질 속성이라는 굉장히 어색한 단어는 책을 읽는 내내 등장 하는데 (왜냐면 중요하니까!) 초반에는 무슨 말인지 이해하기가 어려웠다. 

품질 속성 정의하기(5.2) 에 가서야 겨우 품질 속성이 무엇인지에 대해서 설명 하고 있고 실제 요소들이 나온다. 그리고  품질 속성 레이다 차트를 만드는 부분(활동 6) 에 가서야 좀더 상세하게 이해 할 수 있었다.

 

p. 268 품질 속성 레이다 차트

중요하게 생각하는 기준에 따라 시스템이 어떻게 다를 수 있는지 시각적으로 비교할 수 있다.

 

책의 구성

책은 아래의 순서로 구성 되어 있다. 1부의 소프트웨어 아키텍트가 하는 일(1.1) 에 대한 설명으로 시작해서 2부에서는 실제로 아키텍처 설계를 위한 전략(3), 핵심 요구사항 알아내기(5) , 주요 패턴 설명(7)  그리고 멋진 다이어그램 그리기 (10.2) 를 통해 다이어그램으로 아키텍처를 사실적으로 시각화 하여 보여주는 방법에 대해 이야기 한다.

 

1부

소프트웨어 아키텍트가 하는 일을 소개, 소프트웨어 아키텍처를 정의

 

2부

본격적으로 아키텍처를 설계, 이해관계자와 소통, 아키텍처 핵심 요구사항을 찾아내 설계에 반영

 

3부

아키텍처를 설계하며 문제 상황을 마주했을 때, 해결책을 찾아야 할 때, 설계를 더 구체화하고 싶을 때 해볼 수 있는 38가지 팀 활동을 소개

 

개발자에서 소프트웨어 아키텍트로

개발자에서 소프트웨어 아키텍트가 되고자 하는 이에 대한 조언은 1.3 팀에서 아키텍트가 되려면 이라는 부분에서 다루고 있다.

 

저자는 개발자에서 아키텍트로 성장하고 있는지 측정해 보고 싶다면 프로젝트 포트폴리오를 만들어 보라고 말한다. 소프트웨어 시스템을 만들 때마다 어떤 역할을 했든지 간에, 참여했던 소프트웨어 시스템에 대해 간략히 정리하고 개발하면서 배운점을 정리 하는 활동은 소프트웨어 아키텍트에게 필수적이다.

 

프로젝트 포트폴리오 정리를 위한 주요 질문사항

  • 이해관계자들은 누구였고 주요 비즈니스 목표는 무었이었는가?
  • 최종적으로 어떤 결과가 나왔는가?
  • 어떤 기술을 사용했는가?
  • 가장 큰 리스크는 무엇이고, 어떻게 극복했는가?
  • 다시 시작할 수 있다면 어떤 점을 다르게 하겠는가?

감상평

두께도 얇은 편이고 편집도 깔끔하여 보기에는 쉬웠지만, 내용은 전체적으로 쉽지 않은 책이다. 

 

하지만, 말로 이해하기 어려운 부분도 책의 그림 이나 다이어그램, 표의 적절한 사용으로 이해하는데 도움이 되었다. 또한 사례연구로 나오는 라이언하트 프로젝트는 뜬구름 잡기 같던 아키텍처 설계를 좀 더 구체화된 시선으로 볼 수 있도록 해주었다.

 

3부의 아키텍트의 은색 도구상자는 충분히 확인 하여 실무에서 사용할 수 있는 방안을 생각해보는 중이다. 특히 고객과의 인터뷰 같은건 매번 하는 작업 이지만, “활동4 이해관계자 인터뷰” 에서 처럼 목표와 질문목록 그리고 실행단계를 구분하여 작업해본적은 없었기에 책의 내용을 실천하여 작업을 수행해 보고 싶다.

 

소프트웨어 아키텍트가 뭐하는 포지션인지 모르는 사람에게 꼭 추천 하는 바이다. 

팀에 아키텍트가 없다면... “네, 축하 합니다. 이제 당신이 하면 됩니다.!”

 

사족

은 탄환은 없다. 라는 말은 그 옛날 소프트웨어공학 수업시간에 맨먼스 미신과 같이 들어본말인것 같은데, 2021년에 와서도 그 통찰력에 감복하는 바이다. 



"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

 

+ Recent posts