"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."
about
저자
- 소프트웨어 아키텍트에 관한 lesson도 제공한다.
- 홈페이지에서도 볼 수 있지만, 유튜브도 있다.
- Meme Wrangler(밈 랭글러)
- Thoughtworks의 이사여서 책에 관련 내용이 있었나보다.
감상
1번 읽고 바로 이해하기는 내용이 많고 어렵다. 그래서 최대한 인상 깊었던 내용을 위주로 다시 보기 위해 기록했다.
이 책을 읽으면서 바로 든 의문점은 "개발자와 아키텍트의 차이는 무엇일까?"였다.
- 개발자: 나무를 심는 사람, 어떻게 구현할 것인가에 집중. 기술적 문제 해결. 깊이 중요. "이 기능이 올바르게 동작하는가"에 대한 책임.
- 아키텍트: 숲을 설계하는 사람, 시스템의 전체적인 구조를 결정하고 why 이 방식이어야 하는지를 증명. 비즈니스 요구사항과 트레이드오프를 기준으로 결정. 너비 중요. "이 시스템이 변화하는 비즈니스 환경에서도 살아남을 수 있는가?"
그래서 한국에서 아키텍트 라는 직무가 있을까? 고민해 보았을 때, 특별히 직무로 구분된 아키텍트(architect)가 채용사이트에서 두드러지게 보이지 않았다.
그나마 클라우드, 분산처리 관련된 쪽에서 "아키텍처"라는 용어를 사용하거나, 시니어 개발자들에게 암묵적으로 요구하는 사항이 아닐까? 라는 생각이 들었다.
그런 면에서 이 책은 주니어 개발자보다는 더 넓은 시야를 원하는 그 이상의 개발 경력을 가진 개발자들이 읽기 좋은 책이라고 볼 수 있다.
물론, 코드 설계에 대해 고민하는 누구나에게 좋은 책일 것이다.
요즘 들어 트레이드 오프라는 단어를 정말 많이 들었었다. 그래서 이 키워드에 대해 좀 더 알고 싶고 무슨 의미일까 고민했었는데 이 책 덕분에 키워드를 이해할 수 있었다.
바이브 코딩으로 프로그래밍이 대중화되는 이 시대에 개발자들은 어떻게 할 것인가의 답을 이 책에서 제시하지 않았나 싶다.
나무를 심지 말고 숲을 설계하면서 좀 더 효율적으로, 유지 보수가 쉽고 오래 생존할 수 있는 시스템을 설계하는 지혜를 가진 사람이 되라고.
기록
CHAPTER 01 서론
소프트웨어 아키텍트는 AI가 할 수 없는 유형의 결정을 내린다. 복잡하게 변하는 상황에서 여러 선택지를 저울질하여 최적의 균형점을 찾는, 바로 그런 결정 말이다. (p37)
PART 01 기초
아키텍처에서 중요한 트레이드오프들을 이해하려면 개발자는 컴포넌트(component), 모듈성(modularity), 결합도(coupling), 동변성(connascence)과 관련된 기본 개념과 용어를 익혀야 한다.
CHAPTER 02 아키텍처적 사고
architectural thinking란 사물을 설계자의 눈으로 보는 것, 즉 아키텍처의 관점에서 바라보는 것을 뜻한다. 예를 들어 아키텍트는 뭔가를 변경할 때 그것이 전반적인 확장성에 어떤 영향을 미칠지 이해해야 하며, 시스템의 서로 다른 부분이 어떻게 상호작용하는지 주의를 기울여야 한다. (p55)
_2.1 아키텍처와 설계의 차이
결정이 전략(strategy)적일수록 아키텍처에 가깝고, 전술(tactics)적일수록 설계에 가깝다. 보통의 경우 전략적 결정은 장기적이다. 반면에 전술적 결정은 단기적이고, 다른 행동이나 결정과는 별개일 때가 많다.(p57)
_2.2 기술적 너비
개발자가 제몫을 다 하려면 기술적 깊이(technical depth)가 상당히 깊어야 한다. 그와는 달리 소프트웨어 아키텍트에게는 기술적 너비(technical breadth)가 더 중요하다.(p58)
20분 규칙
- 출근하자 마자!!
- 최근 트렌드와 유행어를 꾸준하게 따라잡기 위해 노력하는 시간
- 책에서 추천하는 사이트
_2.3 트레이드오프 분석
아키텍트처럼 사고한다는 것은 모든 해법(기술적이든 아니든)에서 트레이드오프(절충점)을 찾아내고, 그 장단점을 분석해서 최선의 해법을 도출하는 것이다.
아키텍처란 구글이나 LLM에 물어볼 수 없는 것들이다. - 마크 리처즈(p69)
CHAPTER 04 아키텍처 특성의 정의
_4.2 중요한 아키텍처 특성들
구조적 아키텍처 특성
- 코드 품질 보장에는 모듈성, 가독성, 컴포넌트 간 결합의 제어성을 비롯해 여러 내부 품질 속성의 평가가 포함된다.
| 용어 | 정의 |
|---|---|
| 설정성 | 최종 사용자가 인터페이스를 통해 소프트웨어 구성의 측면을 얼마나 쉽게 변경할 수 있는가 |
| 확장 능력 | 아키텍처가 기존 기능성을 확장하는 변경 사항을 얼마나 잘 수용하는가 |
| 설치성 | 모든 필수 플랫폼에 시스템을 설치하는 것이 얼마나 쉬운가 |
| 활용성/재사용 | 시스템의 공통 컴포넌트를 여러 제품에서 어느 정도나 활용할 수 있는가 |
| 현지화 | 데이터 필드의 입력/조회 화면에서 여러 언어를 지원하는 문제에 관함 |
| 유지보수성 | 변경 사항을 적용하고 시스템을 개선하는 것이 얼마나 쉬운가 |
| 이식성 | 시스템을 둘 이상의 플랫폼에서 실행할 수 있는 능력 |
| 업그레이드성 | 서버와 클라이언트에서 새 버전으로 업그레이드하는 것이 얼마나 쉽고 빠른가 |
_4.3 트레이드오프와 ‘가장 덜 나쁜’ 아키텍처
최고의 아키텍처를 추구하지 말고, 가장 덜 나쁜(나쁜 것 중에서 제일 나은) 아키텍처를 목표로 하라(p109)
🤔 법에서도 위와 같은 논리를 중요하게 생각하는데, 여기서 이런 선택을 만나다니..
CHAPTER 08 컴포넌트 기반 사고
_8.3 논리적 아키텍처의 작성
논리적 아키텍처를 새로 만들거나 기존 아키텍처를 본격적으로 뜯어고칠 때 어려운 점은 초기 핵심 컴포넌트를 무엇으로 할지 결정하는 것이다. 흔히 소프트웨어 아키텍트들은 초기 논리적 컴포넌트를 처음부터 완벽하게 만들려고 너무 많은 노력을 기울이는데, 이는 실수이다. 그보다는 시스템의 핵심 기능을 바탕으로 초기 핵심 컴포넌트가 어떤 모습일지 최선으로 추측하고, 점차 개선하는 것이 더 낫다.
다시 말해, 시스템에 대해 아직 아는 것이 거의 없고 구체적인 요구사항들이 거의 밝혀지지 않은 상황에서 모든 것을 완벽하게 하려 하기보다, 시스템에 대해 더 많이 알아가면서 논리적 컴포넌트를 반복적으로 다듬는 것이 더 나은 접근법이다.(p161)
_8.4 컴포넌트 결합
흔히 아키텍트들은 결합이 느슨하도록 시스템을 설계해야 한다는 조언을 듣는다. 실제로, 컴푸넌트나 서비스 간의 결합도가 낮을수록 시스템을 유지보수하기 쉽고 테스트하기 수월하며 배포 위험이 줄어든다. (p173)
느슨하게 결합된 시스템을 만드는 기법
- 테메레르의 법칙(Law of Demeter)/최소 지식의 원칙(Principle of Least Knowledge): 컴포넌트나 서비스는 다른 컴포넌트나 서비스에 대한 제한된 지식만을 가져야 한다.
PART 02 아키텍처 스타일
CHAPTER 10 계층형 아키텍처 스타일
1) 운영체제 일반적인 계층
- 하드웨어 계층: cpu, 메모리, I/O 장치 물리적 하드웨어 포함
- 커널 계층: 하드웨어 추상화, 메모리 관리, 프로세스 스케줄링 기능 제공
- 시스템 호출 인터페이스 계층: 커널과 상호작용해서 시스템 서비스 제공
- 사용자 계층: 사용자가 상호작용하는 app과 유틸리티 포함
2) TCP/IP 계층
- 물리 계층: 데이터를 물리적으로 전송
- 데이터 링크 계층: 오류 검출 및 프레임 동기화 담당
- 네트워크 계층: 라우팅 처리(IP 부분)
- 전송 계층: 신뢰할 수 있는 데이터 전송 보장(TCP 부분)
- 어플리케이션 계층: 이메일(SMTP), 파일 전송(FTP), 웹브라우징(HTTP) 같은 서비스 제공
PART 03 기법과 소프트 스킬
CHAPTER 21 아키텍처적 결정
_21.2 아키텍처적 중요성
중요한 결정: 시스템의 구조, 비기능적 특성, 의존성, 인터페이스, 또는 구축 기법에 영향을 미치는 결정
1) 구조: 사용 중인 아키텍처 패턴이나 스타일에 영향을 미치는 결정
2) 비기능적 특성(non-functional characteristic): 개발하거나 유지보수하는 시스템에 중요한 아키텍처 특성.
소프트웨어가 무엇을 하는가(기능)이 아니라 어떻게 작동하는가(운영 및 품질)에 관한 것.
3) 의존성(dependency): 시스템을 구성하는 컴포넌트들이나 서비스들 사이의 결함점에 대한 것
4) 인터페이스: 시스템이나 사용자 혹은 다른 어떤 요소들이 서비스들과 컴포넌트들에 접근하고 오케스트레이션하는 방식
5) 구축 기법(construction technique): 플랫폼, 프레임워크, 도구, 심지어 프로세스에 관한 결정.
