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

나는 개발자다.

요즘은 좀 줄어들긴 했지만

주변에서 AI 때문에 개발자 망하는거 아니냐는 말을

아주아주 많이 들어왔다.

그런데 내가 느끼기에는

AI의 발전으로 개발자의 효율성이 좋아졌을 뿐

AI가 개발자를 대체하는 것은 어려울 것 같다.

생성형 AI는 비유하자면 랜덤 가챠와 같다.

유저가 자연어로 간소화된 기능 위주의 요구사항을 이야기하면

AI가 수많은 프로그래밍 언어와 프레임워크 중

적합한 것들을 조합해서 결과물을 내놓는다.

그러면 그 결과물의 구성요소는 말 그대로 랜덤으로 발생한다.

요구사항이 디테일해지면 디테일해질수록

랜덤 요소가 줄어들지만

개발자가 아닌데 기술 스택을 고려하고

아키텍쳐를 구상할 수 있을까?

결국 AI라는 거대한 파도가 닥쳐올때 개발자는

구경만 하는 유저의 포지션이 아니라

파도에 올라타는 주도자의 포지션이 되어야 한다.

그런 의미에서 이 책,

소프트웨어 아키텍처 The Basics는

아주 좋은 지침서가 되어줄 것이다.

소프트웨어 아키텍처에 대한 책들은

이미 시중에 많이 출간되어있다.

하지만 한빛의 OREILLY 시리즈는

개발자들 사이에서는 근본으로 불리는 시리즈다.

그 중에서도 소프트웨어 아키텍처 The Basics의 1판인

Fundamentals of Software Architecture는

교보문고에서 평점 9.7점을 받은 아주 인기있는 책이다.

2판에서는 AI 시대에 발맞춰

AI를 옵션이 아닌 기본 전제로 가정하였다.

또한 다양한 아키텍처 스타일을 추가하여

개발자에게 다양한 선택권을 제공하였다.

이 책에서는 다양한 예시를 통해

아키텍처를 설명하고 있다.

예를 들어 음식 주문 시스템을 개발할 때

포장 손님에게는

음식 수령 시간과 매장 위치 정보를 제공해야 한다.

따라서 외부 지도 서비스를 통합해야 하는데

서드파티 시스템이 고장나면

메인 시스템에의 신뢰성도 떨어지게 되고

따라서 아키텍처 특성을 과도하게 명세하지 않아야

서비스의 쾌적함이 증가하게 된다.

이 예시에서는

아키텍트가 불필요한 취약성을 설계에 도입하는 것을

항상 경계헤야 한다는 이야기를 하고 있다.

혹시 프로덕트를 개발할때

이런 설계적인 요소들을 고민하고 있지 않았다면

이 책이 큰 도움이 될 수 있을 것이다.

혹시 비개발자인데 이 책이 흥미롭다면?

도전해볼 가치가 있다고 생각한다.

비개발자들에게 바이브코딩을 가르쳐보면

신선한 아이디어가 가득하다.

그리고 LLM을 활용한 MVP 개발도 하루면 해낸다.

하지만 늘 문제인게

디버깅과 기능 추가다.

디버깅은 에러 메시지를 복사해서

LLM에게 던져주는 행위를

무한 반복하는 방법으로 해결한다 하더라도

기능 추가는 복잡도가 훨씬 높다.

비개발자들은 단순히 원하는 기능을 AI에게 요청한다.

하지만 아까도 말했듯 요청이 상세하지 않다면

AI의 판단하에 랜덤으로 기능 구현이 이루어지고

기존 코드와의 호환성에 문제가 생기게 된다.

이때 아키텍처에 대한 이해가 있다면

좀 더 원활히 기능을 추가 할 수 있다.

아키텍처는 소프트웨어의 전체적인 설계도이기 때문에

머릿속에 설계도가 들어있다면,

AI에게 설계도를 보여준다면,

유저가 원하는대로 기능의 추가와 제거가 가능하며

당연히 랜덤요소도 줄어들게 된다.

이는 개발자에게도 해당한다.

설계도 없는 프로그램 구현은

언젠가 대참사를 불러일으킨다.

안그런 직업이 있겠냐마는

개발자는 항상 공부해야 한다.

부족한 부분을 채우면서

동시에 새로운 것들을 더해야 한다.

특히 급속히 발전하는 AI시대에 접어들어

새로운 것들을 더해나가는 행위는

선택이 아니라 의무가 되었다.

C언어가 등장했을 때

그것이 근본이 아니라며

변화를 거부한 사람들은 도태되었다.

나는 AI도 마찬가지라고 생각한다.

LLM이 짜주는 코드는 근본이 없다며 외면할게 아니라

LLM을 효율적인 도구로 받아들이고

새로운 기술로 더함과 동시에

부족했던 부분을 채워주는 도구로 사용하는 것이

올바른 방향이라고 생각한다.

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

책을 신청한 이유

지난 번 리뷰했던 <아키텍트 첫걸음> 책을 읽으면서 아키텍트라는 분야에 대해 관심이 생기고, 대 AI 시대에 나만의 차별점을 갖출 수 있으려면 아키텍처를 사고할 수 있는 힘을 길러야겠다는 생각이 들었습니다. 그러던 도중, 이번에 한빛미디어에서 나온 <소프트웨어 아키텍처 The Basics 2판> 책을 읽게 된다면 아키텍처에 대해 더 깊게 배울 수 있겠다는 생각에 신청하게 되었습니다.

목차

목차는 다음과 같이 구성되어 있습니다. 책의 목차가 매우 자세하게 되어있어, 중분류까지만 작성하겠습니다.

• 서론
• PART 01. 기초
  • 아키텍처적 사고
  • 모듈성
  • 아키텍처 특성의 정의
  • 아키텍처 특성의 식별
  • 아키텍처 특성의 측정과 거버넌스
  • 아키텍처 특성의 범위
  • 컴포넌트 기반 사고
• PART 02. 아키텍처 스타일
  • 아키텍처 스타일의 기초
  • 계층형 아키텍처 스타일
  • 모듈형 모놀리스 아키텍처 스타일
  • 파이프라인 아키텍처 스타일
  • 마이크로커널 아키텍처 스타일
  • 서비스 기반 아키텍처 스타일
  • 이벤트 주도 아키텍처 스타일
  • 공간 기반 아키텍처 스타일
  • 오케스트레이션 주도 서비스 지향 아키텍처
  • 마이크로서비스 아키텍처
  • 적절한 아키텍처 스타일의 선택
  • 아키텍처 패턴
• PART 03. 기법과 소프트 스킬
  • 아키텍처적 결정
  • 아키텍처 위험 분석
  • 아키텍처 도식화
  • 유능한 팀 만들기
  • 협상과 리더십 스킬
  • 아키텍처 교차점
  • 다시 살펴본 소프트웨어 아키텍처 법칙들
• 토론용 질문 모음

책의 특징

다음은 책을 읽으면서 정리해 본 책의 특징입니다.

다양한 아키텍처 스타일을 설명하는 것에 그치지 않고, 쓰면 좋을 때와 쓰지 않아야 할 때를 모두 알려줍니다.

PART 02. 아키텍처 스타일에 정의된 아키텍처 스타일을 보면, 자그마치 9가지의 아키텍처 스타일에 대해 알려주고 있습니다.

그러나, 단순히 이 아키텍처 스타일은 어떤 개념이다 라는 것에 그치지 않고 쓰면 좋을 때와 쓰지 않아야 할 때를 모두 알려줍니다.

흔히 신기술을 발견한 사람들은 모든 상황에서 해당 기술을 적용하면 좋을 것 같다는 착각을 하기 쉬운데, 쓰면 좋을 때와 쓰지 않아야 할 때를 모두 알려줌으로써 이런 실수를 하지 않도록 미리 차단해 주는 것 같아 좋은 점으로 다가왔습니다. 더욱이, 예시와 용례를 함께 덧붙임으로써 이해를 도와주고 있습니다.

아키텍처에 관한 책 답게, 풍부한 그림이 있습니다.

아키텍처에 관한 책들을 보면 구조를 나타내는 것이다 보니 그림이 있어야 하지 않을까라는 생각을 하는데, 이 책은 방대한 양 (약 600p 이상)에 걸맞게 그림 또한 자주 등장하고 있습니다.

거의 한 두장 넘기다 보면 그림이 등장하곤 하는데, 이 그림들 덕분에 책의 설명을 읽으면서 모호하게 느껴지는 부분들에 대해 이해하는 데 도움이 되었습니다.

토론용 질문 모음

부록으로 있는 <토론용 질문 모음>에는 개인적으로 학습하기에도 좋고, 함께 일하는 동료들과 토론해 보기 적합한 질문들이 충실히 제공되어 있습니다. 현업에 계신 분들이라면 함께 일하는 동료들과 서로 생각해 보는 시간을 갖고, 혼자 독서하시는 분께서는 ChatGPT, Claude 등 AI와 함께 논의하며 더 깊게 학습하시는 데 큰 도움이 될 것이라고 생각합니다.

총평 / 추천 대상

본 책은 아키텍처에 대해 다양한 스타일을 알려주고, 풍부한 그림과 사용하기 적절한 시점에 대한 글이 작성되어 있습니다. 뿐만 아니라 아키텍처에 대해 깊은 고민을 할 수 있도록 부록으로 토론용 질문들이 구성되어 있습니다.

다만, 분량이 600p 이상이다보니 아키텍처가 무엇인지 관찰하는 단계에서는 부적합하며 어느 정도 실무를 함께 다져본 개발자 분들이 읽어보시기에 적절한 책일 듯합니다.

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

소프트웨어 아키텍처

"시스템 아키텍처"라는 말보다 훨씬 더 부담스럽고 머리아픈 문구가 아닐까?

아키텍처의 기대 역할

1. 아키텍처적 결정을 내린다.

2. 아키텍처를 지속적으로 분석한다

3. 최신 트렌드를 계쏙 따라간다

4. 결정 사항의 준수를 준수를 보장한다.

5. 다양한 기술을 이해한다.

6. 비즈니스 도메인을 숙지한다.

7. 대인 관계 스킬을 갖춘다

8. 정치를 파악하고 헤쳐 나간다.

여기서 정치는 협상능력을 의미한다.

책은 다양한 아키텍처에 대해 설명한다. 

1. 토폴로지

2. 스타일 세부사항

3. 데이터 토폴로지

4. 클라우드 고려 사항

5. 일반적인 위험

6. 거버넌스

7. 팀 토폴로지 고려 사항

8. 스타일 특성

9. 예시와 용례

일부 소스코드가 있긴 하지만, 그보다는 개념적인 접근에 훨씬 유용하다.

어떤 아키텍처를 선택하고 적용해야 하는지를 고민할 때 큰 도움이 될만한 내용이 포함되어 있는 것이다.

SW 개발자든 인프라 운영자든 보안담당자든, 기본적인 구조, 개념에 대한 이해도가 높으면 큰 도움이 될 때가 있다.

소프트웨어 아키텍처랑 전혀 상관없는 사람일지라도 찾아보고 이해할 수 있는 길잡이 역할로써 이 책은 그 기능을 한다.

Chapter 21은 진짜 흥미롭다. 당연한 얘기를 이렇게 풀어쓴다는 게 재밌지만, 결코 웃고 넘어갈 문제는 아니라는 사실!

아키텍처적 결정의 안티패턴들

1. 보신주의 안티패턴

- 아키텍트가 잘못된 선택을 할까 두려워 아키텍처적 결정을 회피하거나 미룰 때 발생

2. 사랑의 블랙홀 안티패턴

- 왜 아키텍트가 특정 결정을 내렸는지 몰라서 그 결정을 논의만 하고 최종적 결론이나 합의에 이르지 못할때 발생

3. 이메일 주도 아키텍처 안티패턴

- 사람들이 아키텍처적 결정 사항을 놓치거나 잊어버릴 때 발생

그 밖에 위험 분석, 도식화, 협상스킬, 마지막엔 토론용 질문 모음까지.

잘짜여진 각본처럼, 소프트웨어 아키텍처 전문가가 되기 위한 첫걸음 또는 비전문가지만 개념적 이해를 충분히 하고싶은 모든 개발자분들에게 추천하고 싶다.

- 이 리뷰는 IT 현업개발자가, 별도의 광고료 없이 한빛미디어의 책만 제공받아서 작성한 서평입니다. -

소프트웨어 기획 및 개발에 대한 여러 책들을 보면 구체적인 양식 및 사례를 설명하는 책들이 많습니다. 이 책은 왜 그러한 소프트웨어 구조화 원리가 여러개 등장하게 되었는지, 그리고 각각의 내용을 적용하는데 적합한 사례는 어떠한 경우인지에 대한 설명을 하는 책 입니다.

이처럼 물고기 어떻게 잡는지 설명하는 책으로, IT 서비스 기획 및 개발문서에 대하여 평소에 궁금하고 해답을 찾기 원하시는 분들에게 많은 도움이 되어 줄 것입니다.

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

“왜 이 구조여야 하는가”를 끝까지 묻는 책

소프트웨어는 한 번 만들고 끝나는 결과물이 아니다.

끊김 없이 지속되어야 하고, 수많은 세부 로직과 외부 시스템, 사람과 조직의 관계 속에서 살아 움직이는 거대한 생태계에 가깝다. 그런 점에서 아키텍처는 단순한 설계도를 넘어선다. 코드의 구조이자 팀의 협업 방식이며, 비즈니스의 의사결정이 기술로 번역된 결과다.

"소프트웨어 아키텍처 The Basics 2판”은 이 복합적인 세계를 “정답”이 아닌 “사고 방식”으로 풀어내는 책이다. 이 책이 반복해서 강조하는 메시지는 분명하다.   

소프트웨어 아키텍처의 모든 것은 트레이드오프다.

이 책에서 특히 인상 깊었던 부분은 트레이드오프에 대한 집요한 강조였다.

세상에는 이미 수많은 기술, 프레임워크, 언어, 아키텍처 스타일이 존재한다. 하지만 중요한 것은 무엇을 썼는가가 아니라 왜 그것을 선택했는가다.

솔직히 말하면, 경험이 거의 없는 상태에서 이 책을 읽었다면 다소 추상적으로 느껴졌을지도 모른다. 하지만 온프레미스 환경의 레거시 시스템, 모놀리식 아키텍처부터 클라우드 환경에서의 Well-Architected 설계까지 두루 경험한 입장에서 읽다 보니, 책 속 문장 하나하나가 실제 현장의 장면과 겹쳐 보였다.

“이건 맞다”, “이건 그래서 항상 문제였다”, “결국 여기로 돌아오게 된다” 이런 혼잣말을 하며 페이지를 넘기게 되는 책이다.

PART 01: 기초 – 아키텍처적 사고를 기르는 과정

초반부는 소프트웨어 아키텍처를 정의하는 데서 시작한다.
아키텍처와 설계의 차이, 그리고 단순한 기술 선택을 넘어선 아키텍처적 사고가 무엇인지를 설명한다. 특히 인상 깊었던 점은, 아키텍처를 기술의 문제가 아니라 비즈니스 동인과 제약 조건의 균형 문제로 다룬다는 것이다. 

기술적 너비를 갖되, 모든 것을 깊게 알 필요는 없다.

“좋은 구조”보다 “지금 상황에서 덜 나쁜 구조”를 찾는다

아키텍트는 코딩에서 완전히 손을 떼는 존재가 아니다.

이런 이야기들은 실무에서 역할의 경계를 고민해본 사람이라면 누구나 공감할 만하다.

이후 모듈성(Chapter 3), 아키텍처 특성(Chapter 4~7)을 다루는 흐름은 특히 좋았다. 성능, 확장성, 가용성, 보안 같은 키워드들이 막연한 미덕이 아니라, 서로 충돌하는 특성임을 명확히 드러낸다. 모든 것을 동시에 만족시키는 아키텍처는 존재하지 않으며, 결국 우선순위를 정하고 포기할 것을 선택해야 한다는 점을 끊임없이 상기시킨다.

PART 02: 아키텍처 스타일 – 유행이 아닌 맥락의 문제

이 책의 분량 대부분을 차지하는 PART 02는 다양한 아키텍처 스타일을 다룬다. 계층형 아키텍처, 모듈형 모놀리스, 이벤트 주도, 서비스 기반, 마이크로서비스까지 익숙한 이름들이 대거 등장하지만, 이 책은 결코 “마이크로서비스가 답이다” 같은 식으로 흐르지 않는다.

각 장에서 공통적으로 다루는 구조가 인상적이다.   

토폴로지, 데이터 구조, 클라우드 환경 고려 사항, 일반적인 위험, 거버넌스, 팀 토폴로지와의 관계

이를 통해 독자는 아키텍처가 코드 구조만의 문제가 아니라, 팀 구성과 운영 방식, 조직 문화까지 영향을 미친다는 사실을 자연스럽게 이해하게 된다. 특히 모놀리스 vs 분산 아키텍처를 다루는 부분에서는, 무조건적인 분산 전환이 얼마나 많은 복잡성을 가져오는지도 현실적으로 보여준다.

PART 03: 기법과 소프트 스킬 – 아키텍트는 혼자 일하지 않는다

개인적으로 가장 마음에 들었던 파트는 PART 03이다. 아키텍처 결정 기록(ADR), 위험 분석, 도식화 같은 실무 기법뿐 아니라 협업, 협상, 리더십을 아키텍트의 핵심 역량으로 다룬다는 점이 인상 깊었다.

아키텍트는 모든 걸 결정하는 사람이 아니라, 사람과 사람 사이에서 맥락을 조율하고, 기술과 비즈니스 사이를 번역하는 역할에 가깝다. 이 책은 그 사실을 숨기지 않는다.

“안다는 것은 설명할 수 있다는 것”

무언가를 진짜로 안다는 것은, 그것을 다른 사람에게 설명할 수 있을 때다. 소프트웨어 역시 하나의 function이나 특정 기술로만 존재하지 않는다.  이 책은 소프트웨어 아키텍처의 A부터 Z까지를 다루지만, 일부러 깊게 파고들지 않는다. 대신 큰 그림을 그리고, 사고의 지도를 제공한다.

실무에 바로 적용하기엔 다소 막막할 수도 있다. 하지만 이 책을 읽고 나면, 머릿속에 있던 아키텍처의 미니맵에서 안개가 조금씩 걷히는 느낌을 받게 된다. 그리고 다음 선택의 순간에서, “왜 이걸 선택했는가”를 이전보다 분명하게 설명할 수 있게 된다.

“소프트웨어 아키텍처 The Basics 2판”은 아키텍트가 되고 싶은 사람보다는, 이미 고민하고 있는 사람에게 더 잘 맞는 책이다. 정답을 주기보다는 질문을 던지고, 기술보다 맥락을 이야기하며, 유행보다 이유를 묻는다.

경험이 쌓일수록 다시 펼쳐보게 될 책.
 그리고 “왜”를 잊지 않게 만들어주는 책이다.

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

《소프트웨어 아키텍처 The Basics(2판)》 는 개발자가 아키텍트로 성장하는 데 필요한 개념과 실무 감각을 균형 있게 다룬, 구조가 잘 잡힌 입문·실무서라는 점이 가장 큰 장점이다. 특히 최신 클라우드·생성형 AI 환경까지 반영해 “요즘 아키텍처”를 고민하는 엔지니어에게 실질적인 기준점을 제공한다.
책이 다루는 핵심 내용
이 책은 『소프트웨어 아키텍처 101』 개정판으로, 아키텍처 특성, 스타일, 컴포넌트 설계, 도식화, 진화적 아키텍처까지 아키텍처 전 영역을 한 권에 담는다.

계층형, 마이크로서비스, 모듈형 모놀리스, 마이크로커널 등 주요 아키텍처 스타일을 실제 선택 기준과 함께 비교해주어, “언제 무엇을 쓰느냐”를 고민할 때 실질적인 가이드가 된다.

장점: 실무 지침서로서의 강점
추상적인 이론보다 “특성 식별 → 스타일 선택 → 컴포넌트 분할 → 거버넌스·팀 구조 고려”처럼 의사결정 흐름을 보여줘서, 현업에서 바로 적용 가능한 프레임을 제공한다.

생성형 AI, 클라우드 배포, 데이터·팀 토폴로지, 거버넌스 등을 새로 반영해, 1판보다 훨씬 현실적인 설계 관점을 제시한다.

인상적인 지점: ‘스펙트럼’과 제3법칙
2판에서 새로 추가된 소프트웨어 아키텍처 제3법칙은 대부분의 설계 결정이 이분법이 아니라 스펙트럼 위의 연속선이라는 점을 강조한다.

이 스펙트럼 관점 덕분에 “마이크로서비스 vs 모놀리스”처럼 흑백 논쟁에 빠지지 않고, 비즈니스와 팀 상황에 맞춰 적절한 지점을 찾는 사고방식을 훈련하게 해준다.

아쉬운 점과 읽기 난이도
클라우드·데이터·팀 토폴로지·거버넌스까지 다루다 보니, 실무 경험이 적은 주니어에게는 처음 읽을 때 다소 정보량이 많게 느껴질 수 있다.

반대로 일정 이상 경험이 있는 개발자나 리드 개발자라면, “이미 알고 있던 개념을 아키텍처 언어로 재구성”해주는 구조라서 사고를 정리하는 데 큰 도움을 받게 된다.

누구에게 추천할지
마이크로서비스나 모듈형 모놀리스 전환을 고민하는 팀 리드, 혹은 중급 이상 개발자 중 “아키텍트 커리어를 고려하는 사람”에게 특히 유용하다.

특정 기술 스택 튜토리얼이 아니라, 기술 선택을 넘어 비즈니스·조직·운영까지 포괄하는 아키텍처 사고법을 체계적으로 정리하고 싶은 독자에게 권할 만한 책이다