[책/IT] 소프트웨어 아키텍처 101 - "닐 포드"

작년 초부터 "닐 포드"의 아키텍처 시리즈를 꼭 읽고 싶었다. 번역서 기준으로 현재 4권이 나와 있는데 그 중 3권을 구입해서 읽어야 겠다고 마음 먹은지 꽤 되었는데, 이제서야 첫 번째 책 "소프트웨어 아키텍처 101"을 읽었다.

(** 애석하게도 그 사이에 소프트웨어 아키텍처 101의 2판인 소프트웨어 아키텍처 베이직이 나왔다. 이전 버전에는 없는 AI와 클라우드 내용이 추가되었다.)

 

이 시리즈는 읽는 순서가 있는데, 대부분 아래의 순서로 읽는다. 이제 첫 시작을 한 샘이다.

 

소프트웨어 아키텍처 101 | 마크 리처즈 | 한빛미디어 - 예스24

소프트웨어 아키텍처 101 | 마크 리처즈 | 한빛미디어 - 예스24

 

진화적 아키텍처 | 닐 포드 | 한빛미디어 - 예스24

진화적 아키텍처 | 닐 포드 | 한빛미디어 - 예스24

 

소프트웨어 아키텍처 The Hard Parts | 닐 포드 | 한빛미디어 - 예스24

소프트웨어 아키텍처 The Hard Parts | 닐 포드 | 한빛미디어 - 예스24

 

책의 순서가 진행됨에 따라 내용이 상세화 되고 구체적이지만 이 중에서 101만 읽어도 충분하다는 얘기도 꽤 있다. 미국 대학교 1학년 교양 필수 과목의 코드 번호가 101이듯이 아키텍트로서 시작하거나 관심 있는 사람에게 기초 교양과도 같은 역할을 한다.

3권 합쳐서 1,284 페이지이고, 소스 코드 예제가 거의 없기에 진도 역시 더딘 편이지만 읽다보니 어느새 첫 번째 책의 472 페이지를 다 읽었다. 이제 812 페이지가 남았다. ㅋ

도서명	난이도	페이지	추천 대상
헤드 퍼스트 소프트웨어 아키텍처	입문	488	- 아키텍처 설계를 처음 배우는 초보 개발자
소프트웨어 아키텍처 101	기본	472	- 아키텍처의 기본 개념과 용어를 명확히 정리하고 싶은 개발자 - 아키텍트 역할을 준비하는 시니어 개발자, 기술 리더
진화적 아키텍처	응용	304	- 배포와 운영 환경이 자주 바뀌는 조직의 개발자/아키텍트 - 아키텍처 이해가 필요한 시니어 개발자
소프트웨어 아키텍처 The Hard Parts	심화	508	- 마이크로서비스나 분산 시스템을 운영 중인 개발자/아키텍트 - 확장성과 성능, 안정성 사이에서 균형을 고민하는 기술 리더

(책 소개 및 비교, 출처 : 한빛미디어 블로그)

 

기억을 잃어버리기 전에 블로그에 단원 별로 인상 깊었던 내용을 기록해 본다.

 

아키텍처에는 정답도 오답도 없다. 오직 트레이드오프만 있을 뿐 - 닐 포드

 

이 책의 내용을 한 마디로 요약한다면 정답도 오답도 없다는 것이다. 아키텍처를 설계하고 기술을 선택할 때 트레이드오프를 판단해서 덜 나쁜 것을 선택하는 과정이라고 책은 설명한다. 그리고 그 내용을 470 페이지에 걸쳐서 상세히 언급하고 있다.

 

01장 : 서론

 

PART 1 : 기초

02장 : 아키텍처 사고

아키텍처 사고 : 아키텍트의 눈으로 사물을 바로보는 것

1. 아키텍처와 설계의 차이를 이해하고 아키텍처 작업을 진행. 개발팀과 어떻게 협력해야 할지 아는 것

2. 어느 정도 기술 깊이를 유지하면서 폭넓은 기술 지식을 확보하는 것 -> 다른 사람이 보지 못하는 해결책과 가능성을 떠올리는 것

3. 다양한 솔루션과 기술 간의 트레이드오프를 이해하고 분석하고 조율하는 것

4. 비즈니스 동인의 중요성을 이해하고 그것을 아키텍처 관심사로 해결할 줄 아는 것

 

03장 : 모듈성

 

04장 : 아키텍처 특성 정의

 

05장 : 아키텍처 특성 식별

아키텍처 카타 : 아키텍처를 식별하는 연습

 

06장 : 아키텍처 특성의 측정 및 거버넌스

아키텍처 특성의 측정 : 목표 수치를 정하고 측정하는 것으로 수치화가 명확한 것도 있지만 그렇지 못한 것도 많이 있다. 그리고 팀의 상황에 따라 그 값이 유동적일 때도 많다.

거버넌스 : 아키텍트가 담당하는 중요한 업무이며 아키텍트의 수고를 덜수 있는 많은 자동화된 소프트웨어들이 있다.

피트니스 함수 : 어떤 아키텍처 특성의 객관적인 무결성을 평가하는 모든 메커니즘

 

07장 : 아키텍처 특성 범위

커플링과 커네이션스 : 두 컴포넌트 중 한쪽이 변경될 경우 다른 쪽도 변경해야 전체 시스템의 정합성이 맞는다면 이들은 커네이선스를 갖고 있다.

아키텍처 퀀텀 : 독립적으로 배포 가능, 높은 기능 응집도, 동기적 커네이선스

 

08장 : 컴포넌트 기반 사고

아키텍트는 아래 일을 수행해야 한다.

• 아키텍처 내부의 컴포넌트를 정의, 개선, 관리, 통제하는 일을 한다.
• 아키텍처 특성과 시스템의 요구사항을 종합하여 비즈니스 분석가, 분야별 전문가, 개발자, QA, 운영자, 엔터프라이즈 아키텍트와 함께 소프트웨어 초기 설계를 한다.

 

PART 2 : 아키텍처 스타일

09장 : 기초

모놀리식 대 분산 아키텍처 -> 분산 컴퓨팅의 오류

• 오류 #1 : 네트워크는 믿을 수 있다
• 오류 #2 : 레이턴시는 0이다
• 오류 #3 : 대역폭은 무한하다
• 오류 #4 : 네트워크는 안전하다
• 오류 #5 : 토폴로지는 절대 안 바뀐다
• 오류 #6 : 관리자는 한 사람 뿐이다
• 오류 #7 : 운송비는 0원이다
• 오류 #8 : 네트워크는 균일하다

주의사항 : 아키텍처 싱크홀 -> 요청이 한 레이어에서 다른 레이어로 이동할 때 각 레이어에가 아무 비즈니스 로직도 처리하지 않고 그냥 통과시키는 안티패턴. 불필요한 객체 초기화 및 처리를 빈번하게 유발하고 쓸데 없이 메모리를 소모하여 성능에도 부정적인 영향을 끼침

 

10장 : 레이어드 아키텍처 스타일

가장 흔한 아키텍처 스타일 중 하나이다.

단순하고 대중적이면서 비용도 적게 들어 모든 애플리케이션의 사실상 표준 아키텍처이다.

만약 개발자, 아키텍트가 어떤 아키텍처 스타일을 사용하는 게 좋을지 확신이 없거나 애자일 개발팀이 '일단 코딩을 시작' 해보기로 했다면 레이어드 아키텍처는 좋은 선택지가 될 가능성이 높다.

 

11장 : 파이프라인 아키텍처 스타일

다수의 파이프와 필터를 이용해서 기능을 연결하는 스타일이다.

EDI, ETL 등 추출 변환 적재 하는 도구 등에서 쓰인다. 예) 아파치 카프카

 

12장 : 마이크로커널 아키텍처 스타일

플러그인 아키텍처라고 부르며 대부분의 IDE나 제품 기반 애플리케이션에 널리 쓰이고 있다.

애플리케이션에 플러그인을 추가해서 기능을 확장한다.

 

13장 : 서비스 기반 아키텍처 스타일

마이크로서비스 아키텍처 스타일의 일종으로 아키텍처가 유연해서 가장 실용적인 스타일 중 하나이다. 

분산 아키텍처이지만 비교적 덜 복잡하고 비용이 많이 들지 않는다.

마이크로서비스 아키텍처와는 다르가 중앙 공유 데이터베이스를 사용한다.

 

14장 : 이벤트 기반 아키텍처 스타일

확장성이 뛰어난 고성능 애플리케이션 개발에 쓰이는 비동기 분산 아키텍처 스타일이다. 

 

15장 : 공간 기반 아키텍처 스타일

높은 확장성, 탄력성, 동시성 및 이와 관련된 문제를 해결하기 위해 설계되었다.

시스템에서 동기 제약조건인 중앙 데이터베이스를 없애는 대신, 복제된 인메모리 데이터 그리드를 활용하여 확장성, 탄력성, 성능을 높인다.

인 메모리 데이터 그리드에서 비즈니스를 처리하고 데이터베이스에는 메세지 큐를 이용해서 비동기 저장한다.

 

16장 : 오케스트레이션 기반 서비스 지향 아키텍처 스타일

13장 서비스 기반 아키텍처 스타일을 확장판이다. 취지는 좋았지만 결과는 좋지 않았다.

비즈니스 서비스와 엔터프라이즈 서비스 사이에 오케스트레이션 엔진을 두어서 연계하도록 한 스타일이다. 비즈니스 서비스를 서로 역어주며 트랜잭션 조정과 메시지 변환 등의 기능을 수행한다. -> 아키텍처가 한층 복잡해 지는 결과를 가져왔다.

 

17장 : 마이크로서비스 아키텍처 스타일

마이크로서비스는 명칭 (Label) 이지 명세 (Description)이 아니다.

명칭에 집착해서 서비스를 지나치게 세분화하는 오류를 범해서는 안된다.

 

18장 : 최적의 아키텍처 스타일 선정

10장~17장까지 설명한 8가지 아키텍처 스타일 중 최적의 스타일을 선택해야 한다.

스타일 선정시 도메인 설계 구조의 원인이 될 만한 모든 요소를 종합적으로 고려해서 설계해야 한다.

만약 스타일 선정이 어렵다면 레이어드 아키텍처로 처음 시작하고 분산 아키텍처 형태로 변형을 하는 것도 좋은 접근이다.

 

PART 3 : 테크닉과 소프트 스킬

 

19장 : 아키텍처 결정

아키텍트의 핵심 가치 중 하나는 아키텍처 결정을 내리는 것이다. 

아키텍처 결정을 하려면 충분한 정보를 수집하고, 결정을 정당화, 문서화한 다음 이해관계자들과 효과적으로 소통해야 한다.

안티 패턴

• 네 패를 먼저 보여주지마 : 잘못된 선택을 두려워 해서 아키텍처 결정을 회피하거나 미루는 현상
• 무한반복 회의 : 어떤 결정을 왜 했는지 모르고 주구장창 회의만 계속하는 것 -> 아키텍트가 결정을 정당화하는데 실패한 경우 발생
• 이메일 기반 아키텍처 : 결정한 것을 이해 못하거나 잊어버려서 이메일로 계속 공지만 하는 현상

 

20장 : 아키텍처 리스트 분석

모든 아키텍처는 리스크를 가지고 있다. 리스크를 꾸준히 분석하여 아키텍처의 내부 결함을 바로 잡고 리스크를 줄여야 한다.

 

21장 : 아키텍처 도식화 및 프리젠테이션

아키텍트의 핵심 소프트 스킬

• 도식화 : 언제나 다이어그램을 작성하는 기술을 갈고 닦아야 한다.
• 프레젠테이션 : 파워포인트, 키노트 같은 도구로 효과적인 프레젠테이션을 하는 능력을 길러야 한다.

 

22장 : 개발팀을 효율적으로

기술 아키텍처를 정립하고 결정하는 것 뿐만 아니라, 개발팀이 아키텍처를 올바르게 구현하도록 안내할 책임이 있다.

• 빡빡한 아키텍처 : 개발팀이 겁 먹고 포기한다
• 느슨한 아키텍처 : 개발팀이 갈팡 질팡한다.
• 효율적 아키텍처 : 개발팀이 아키텍처를 잘 구현하도록 적절한 지침과 제약 조건을 제공한다.

 

23장 : 협상과 리더십 스킬

개발자들에게 명령하고 지시하기 보다는 협력하고 존경심을 이끌어 내야 한다.

4C : 커뮤니케이션 Communication, 협동 Collaboration, 명료함 Clarity, 간결함 Conciseness를 실천해야 한다.

 

24장 : 커리어패스 개발

끊임 없이 커리어패스를 개발하기 위해 노력해야 한다. 하루에 20분 이상 새로운 것을 배우고 익히는데 시간을 투자해야 한다.

커리어패스를 개발할 때 깊이 보다는 넓이를 넓히기 위해 노력하라.