• 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학론

2025/4 컴퓨터/IT 14위 | 현재 컴퓨터/IT 58위 |

반디앤루니스 리뷰

AI 열풍이 불어도 개발자의 역량과 지식은 여전히 중요하다. 소프트웨어 엔지니어로 변함없이 살아남아야 할 당신을 위해 단단한 기본기와 힘을 만들어 줄 책이다. 소프트웨어 개발의 복잡함과 난해함에 맞서 싸울 용기와 지혜를 이 책에서 찾아보자. TDD, DDD, MSA를 이해하려면 반드시 알아둬야 할 핵심 소프트웨어 설계 원칙을 현대적으로 재해석하고 풀어서 설명했다.

출판사 리뷰

✔ 과학적으로 가설을 세우고 실험하면서 점진적으로 역량을 높여가는 '학습'에 관한 철학 5가지!
#반복 #피드백 #점진주의 #실험 #경험주의

✔ 당면한 문제, 그리고 소프트웨어의 해법 자체에 존재하는 ‘복잡성’을 ‘관리’하기 위한 소프트웨어 설계 원칙 5가지!
#모듈성 #응집력 #느슨한결합 #관심사분리 #추상화

| 이 책에서 다루는 내용 |
• 자신이 달성하려는 목표를 명확히 정의하자
• 합리적인 기준으로 도구를 선택하자
• 지속적이며 점진적인 발전을 촉진하기 위해 업무와 시스템을 구조화하자
• 그저 ‘레거시 코드’를 양산하기보다는, 지속적으로 발전하는 시스템을 목표로 진행 상황을 평가하자
• 실험주의와 경험주의에서 더 많은 가치를 얻자
• 시스템이 점점 더 복잡해질 경우에도 통제력을 유지하자
• 엄격하고 체계적이되, 유연성 없는 지나친 경직성은 피하자
• 역사와 경험에서 배우자
• 좋은’ 소프트웨어 개발 아이디어와 ‘나쁜’ 소프트웨어 개발 아이디어를 가려내자

| 이 책의 독자 대상 |
소프트웨어 개발의 복잡함과 난해함을 이해하고 다양한 고민과 어려움을 해결해서 자신의 실력을 더욱 드높이고 싶은 개발자, 아키텍트, 엔지니어, 기술 리더, 매니저

| 이 책의 구성 |
1부 ‘소프트웨어 엔지니어링이란 무엇인가’는 소프트웨어라는 컨텍스트에서 공학이 실제로 무엇을 의미하는지를 살펴보면서 시작한다. 공학의 원리와 철학, 그리고 이런 아이디어를 소프트웨어에 적용할 수 있는 방법을 설명한다. 이것은 소프트웨어 개발을 위한 기술 철학이다.
2부 ‘소프트웨어 프로세스 개선을 위한 구체적인 실천 방안’에서는 작은 단계로 진전을 이룰 수 있도록 업무를 구조화하는 방법을 살펴본다. 우리가 좋은 진전을 이루고 있는지, 아니면 그저 내일의 레거시 시스템을 오늘 만들고 있는지를 어떻게 평가할 수 있을지를 알아본다.
3부 ‘소프트웨어 복잡성 관리를 위한 기본 원칙 5가지’에서는 복잡성 관리에 필요한 원칙과 기법을 탐구한다. 여기서는 이런 각 원칙을 자세히 살펴보고, 그 성격이 무엇이든 고품질 소프트웨어를 만드는 데 있어 그 의미와 적용 가능성을 탐구한다.
4부 ‘소프트웨어 엔지니어를 위한 아이디어’는 학습 기회를 극대화하고 작은 단계로 진전을 이루고 시스템이 성장함에 따라 복잡성을 관리할 수 있는 능력을 촉진하는 아이디어와 접근 방식을 설명한다.

1부 | 소프트웨어 엔지니어링이란 무엇인가

1장 소프트웨어 공학의 정의와 역사
_공학이란 과학의 실용적인 응용 분야
_소프트웨어 공학 정의의 재구성
_다시, ‘소프트웨어 공학’
___전진, 앞으로
_소프트웨어 공학의 탄생
_패러다임의 전환
_정리

2장 소프트웨어 ‘공학’의 참뜻
_프로덕션은 우리의 문제가 아니다
_프로덕션이 아닌, 설계를 위한 공학
_실무자를 위한 공학의 정의
___공학 != 코드
_수공예 vs 공학
_‘수공예’의 한계
_정밀도와 확장성
_복잡성을 관리하자
_측정은 반복적이며 정확해야 한다
_공학, 창의성, 장인정신
_우리가 하는 일이 소프트웨어 공학이 아닌 이유
_소프트웨어 제작의 트레이드오프: 결합도가 핵심이다
_기술 발전의 진보라는 환상
_수공예에서 공학으로 가는 여정
_수공예만으로 충분하지 않다
_지금 우리가 고민해야 할 것들은 무엇일까
_정리

3장 소프트웨어 공학을 이해하기 위한 기초 사항
_새것만을 좇는 소프트웨어 업계
_(비기능적인 요소의) 측정은 중요하다
_안정성과 처리량으로 생산성을 높이자
_우리는 어느 분야의 전문가가 되어야 할까
___학습의 전문가
___복잡성을 관리하는 전문가
_정리

2부 | 소프트웨어 프로세스 개선을 위한 구체적인 실천 방안

4장 개선을 위한 반복
_반복적인 작업의 복잡미묘한 장점
_방어적인 설계 전략으로서의 반복
_계획이라는 유혹
___반복 작업의 실제
_정리

5장 피드백: 우수한 의사결정을 위한 필수 요소
_피드백의 중요성을 보여주는 구체적인 사례
_코딩 피드백
_통합 과정 피드백
_설계 피드백
_아키텍처 피드백
_피드백은 빠를수록 좋다
_제품 설계 피드백
_조직과 문화 피드백
_정리

6장 점진주의: 조금씩, 조금씩, 앞으로
_우주선 예시로 살펴보는 모듈성
_효율 높은 조직 구성을 위한 비법
_점진주의를 적용하기 위한 실천 도구
_변경의 부작용을 최소화하자
_점진적인 설계
_정리

7장 경험주의: 현실을 자각하자
_꿈은 높게, 그러나 발은 땅에
_실험과 경험은 분리해야 한다
_“저 이 버그 알아요!”
_자기기만은 우리의 적
_우리의 주장에 맞는 현실을 발명하자
_추측보다는 실험: 현실에 입각한 경험주의
_정리

8장 실험주의: 과학적 사고와 실천
_물리학자 파인먼에게 배우는 ‘실험주의’
___피드백: 실험주의를 위한 원칙 1
___가설: 실험주의를 위한 원칙 2
___측정: 실험주의를 위한 원칙 3
___변수 통제: 실험주의를 위한 원칙 4
_TDD에서 배우는 자동화 테스트
_테스트는 새로운 지식을 끌어내는 원천
_품질을 높이는 TDD 적용 사례 하나
_정리

3부 | 소프트웨어 복잡성 관리를 위한 기본 원칙 5가지

9장 모듈성: 분리와 재조합을 위한 기준
_모듈성의 전형적인 특징
_설계는 언제나 중요하다
_TDD의 교훈: 테스트가 어렵다면 설계도 문제다
_TDD로 모듈성을 강화하자
_REST API로 모듈성을 강화하자
_배포 파이프라인으로 모듈성을 강화하자
_모듈성의 규모는 크고 작음이 없다
_고성과 개발 조직의 특징: 모듈형
_정리

10장 응집성: 소프트웨어의 관련 요소들은 한곳에
_모듈성과 응집성: 설계의 기초
_응집성을 개선하기 위한 리팩토링 사례 하나
_DDD의 컨텍스트를 활용한 응집성 개선
_소프트웨어에서 ‘고성능’의 의미란
_결합도와 응집성 사이의 관계
_TDD로 응집성을 높이자
_응집성 있는 소프트웨어를 만들려면
_응집성이 부족할 때 치러야 할 대가
_개발 조직 관점에서 응집성의 중요성
_정리

11장 관심사 분리: 고품질 코드의 가장 중요한 속성
_의존성 주입
_본질적인 복잡성과 우발적인 복잡성을 분리하자
_DDD는 중요하다: 경계 컨텍스트를 활용한 하향식 관심사 분리
_테스트하기 쉬운 코드 = 관심사가 분리된 코드
_육각형 아키텍처: 포트와 어댑터
_포트와 어댑터는 언제 채택해야 할까
_API가 단순한 함수 호출이 아닌 이유
_TDD를 이용한 상향식 관심사 분리
_정리

12장 정보 은닉과 추상화: 우리의 적인가 친구인가
_정보 은닉과 추상화는 한몸이다
_‘큰 진흙탕’이 된 코드의 원인을 찾아서
___조직적이고 문화적인 문제
___기술적인 문제와 설계의 문제
___과도하게 공들인 공학의 우려
_추상화를 높이려면 테스트 코드부터 작성하라
_좋은 추상화가 핵심이다
_구멍 난 추상화
_세계 지도와 지하철 노선도의 비유로 배우는 추상화 기법
_이벤트 스토밍으로 추상화를 달성하자
_추상화된 우발적인 복잡성
_타사 시스템과 타사 코드를 격리하자
_추상화와 구상화 사이의 트레이드오프
_정리

13장 결합도: 소프트웨어 모듈 간의 상호 연관 수준
_너무 느슨해도 너무 긴밀해도 문제
_수직 확장을 위해서는 결합도가 필수
_마이크로서비스: 결합도를 분리하기 위한 효과적인 방법
_느슨한 결합도의 대가: 더 크고 많아진 코드
_결합도 모델은 한 종류만이 아니다
_어쨌든, 느슨한 결합이 긴밀한 결합보다는 좋다
_느슨한 결합과 관심사 분리의 상관관계
_DRY는 너무 단순하다
_느슨한 결합을 위한 비동기식 구현 방법
_느슨한 결합을 위한 설계
_강건한 결합도로 영원히 고통받는 대규모 조직
_정리

4부 | 소프트웨어 엔지니어를 위한 아이디어

14장 실제 사례로 되짚어 본 소프트웨어 공학
_소프트웨어 개발, 그 진실에 대하여
_테스트 가능한 코드 사례 1
_시스템은 반드시 측정 가능해야 한다
_테스트 가능한 코드 사례 2
_테스트: 시스템의 시작
_배포: 시스템의 완성
_피드백의 속도: 더 나은 품질과 결과물을 위한 필수 요소
_시스템의 전 과정에서 변수를 통제하자
_지속적인 배포를 잊지 말자
_소프트웨어에서 고려해야 할 질문들
_정리

15장 모던 소프트웨어 엔지니어가 되려면
_팀이나 조직도 복잡성의 관리대상임을 잊지 말자
_디지털적으로 파괴적인 조직을 추구하자
_결과 vs 메커니즘, 무엇이 더 중요할까
_소프트웨어 공학 원칙은 머신러닝 시스템에도 유효하다
_모던 소프트웨어 엔지니어링의 핵심 아이디어
_정리