모던 소프트웨어 엔지니어링

소프트웨어 개발의 복잡함과 난해함 속에서 길을 찾으려는 엔지니어를 위한 필독서

데이비드 팔리 지음 | 박재호 옮김

책만 2025년 06월 02일 출간 국내도서 : 2025년 04월 09일 출간

작품소개

책소개

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

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

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

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

목차

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 메커니즘, 무엇이 더 중요할까
_소프트웨어 공학 원칙은 머신러닝 시스템에도 유효하다
_모던 소프트웨어 엔지니어링의 핵심 아이디어
_정리

책 속으로

[여는 글]
데이브는 우리가 ‘진짜’ 공학에 대해 오해하고 있는 이유를 명확하게 설명한다. 그는 공학이 과학에 기반한 학문이지만 딱딱할 필요는 없다는 점을 보여준다. 과학적인 원리와 공학 기술이 소프트웨어 개발에 어떻게 적용되는지 살펴보고, 우리가 공학이라고 생각했던 생산 기반 기술이 소프트웨어 개발에 적합하지 않은 이유를 이야기한다.
내가 이 책에서 데이브가 작업했던 결과물을 좋아하는 이유는 우리가 작업하는 실제 코드에 적용하기 어려울 수 있는 추상적인 개념을 업무에 도입해 구체적인 문제에 대해 생각하는 도구로 사용하는 방법을 보여준다는 점이다. 이 책은 코드 개발, 아니 소프트웨어 공학의 혼란스러운 현실, 즉 정답이 하나도 없다는 사실을 받아들인다. 상황은 변할 것이다. 어느 시점에 옳았던 내용이 얼마 지나지 않아 매우 잘못된 내용이 될 때도 있다.
이 책의 전반부에서는 이런 현실에서 살아남을 뿐만 아니라 번영하기 위한 실용적인 해법을 제시한다. 후반부에서는 추상적이거나 학문적이라고 여겨질 수 있는 주제를 다루고 이를 더 나은(예: 더 견고하거나 유지보수가 용이하거나 기타 ‘더 나은’) 코드를 설계하는 데 적용되는 방법을 보여준다.
여기서 설계란 절대 어마어마한 분량의 설계 문서나 UML 다이어그램을 의미하는 것이 아니라 ‘코드를 작성하기 전이나 작성하는 동안 코드에 대해 생각하는 것’처럼 단순할 수도 있다(나는 데이브와 함께 프로그래밍을 하면서 그가 실제로 코드를 입력하는 시간이 상당히 적다는 사실을 눈치챘다. 코드 작성에 앞서 코드 작성에 대한 내용을 생각하면 실제로 많은 시간과 노력을 절약할 수 있다는 사실이 밝혀졌다).
데이브는 이런 관례들을 함께 사용할 때 발생할 수 있는 모순이나, 개별적인 관례가 초래할 수 있는 잠재적인 혼란을 회피하거나 변명하려 하지 않는다. 대신 시간을 들여 장단점과 일반적인 혼란의 영역에 대해 이야기하기 때문에 나는 처음으로 이런 관례들 사이의 균형과 긴장이 ‘더 나은’ 시스템을 만든다는 사실을 이해하게 되었다. 흑백 논리나 옳고 그름의 이분법적인 규칙으로 받아들이는 대신에 이런 내용이 지침이라는 사실을 이해하고, 그에 따른 비용과 이점을 파악하며, 이런 내용을 코드/설계/아키텍처를 바라보는 렌즈로 사용하거나, 때로는 조정할 수 있는 다이얼로 생각하는 것이 중요하다.
데이브와 함께 일하는 동안 ‘소프트웨어 엔지니어’로서 우리가 왜 그렇게 성공적이고 만족스러웠는지 이 책을 읽으면서 이해할 수 있었다. 여러분도 이 책을 읽으면서 데이브 팔리를 고용하지 않고도 데이브의 경험과 조언을 여러분의 회사나 팀에 활용할 수 있기를 바란다.
행복한 엔지니어로 발전하기를!
- 트리샤 지(Trisha Gee) / 기술 전도사이자 자바 챔피언

[옮긴이의 말]
이 책을 번역하기로 결정하고 처음 읽었을 때 살짝 걱정이 들었다. 소프트웨어 공학과 관련해 기존에 출간된 숱한 서적들보다는 확실하게 실무적인 내용으로 무장하고 있지만, 뭔가 머리 아픈 개발 과정의 문제점을 화끈하게 해소해 줄 만한 강력한 한 방이 약해 보였기 때문이다. 나 또한, 이 책이 사전에 빈틈없이 정해진 규율과 포괄적인 방법론을 설명하고 그에 맞춰 코드 작성 기법을 소개했다면 좋았겠다고 생각했음을 솔직하게 고백하겠다.
하지만 출판사에 원고를 넘기기 전에 퇴고를 위해 다시 한번 읽어 나가자 차츰 이 책의 진면모가 보이기 시작했다. 특히 3부에서 소개하는 훌륭한 소프트웨어 설계 원칙들이 앞쪽에서 공들여 깔아놓은 복선과 어떻게 연결되는지가 눈에 들어오면서, 1부와 2부에서 설명된 다양한 개발 관련 기술과 소프트웨어 설계 원칙의 상호 연관관계가 무척 흥미롭게 다가왔다.
현대적인 소프트웨어 공학이 직면한 가장 큰 문제는 완벽한 이론도, 훌륭한 도구도, 현업에서 검증된 개발 방법론도 아니다. 어떻게 보면 기존 프로덕션 중심의 공학에서 설계 중심의 공학으로 넘어가는 과정 중에 여전히 길을 잃고 방황하는 현실 속에서 비롯된 오해와 충돌이 아닐까 싶다.
이 책에서는 이를 해소하기 위해 과학적인 방식으로 가설을 수립하고 실험하고 여기서 얻은 결과를 토대로 점진적으로 역량을 높여가는 과정인 ‘학습(learning)’을 강조한다. 또한 우리가 직면한 다양한 문제와 이 문제를 풀기 위한 해법의 ‘복잡성(complexity)’을 관리하기 위한 전문가가 되어야 한다고 제안한다. 반복, 피드백, 점진주의, 실험, 경험주의라는 철학을 이해해서 학습의 전문가로 올라서며, 모듈성, 응집성, 관심사 분리, 추상화, 느슨한 결합도를 학습 관점에서 제대로 이해해 복잡성을 관리하는 전문가로 업그레이드한다면, 이 책에서 주장하는 소프트웨어 공학을 실천할 만반의 준비가 갖춰진 셈이다.
이 책은 누구나 실수할 수 있고, 상황은 항상 변화하며, 해법 사이에서 트레이드오프와 긴장감이 감돈다는 사실을 인정하고 들어간다. 앞서 이 책에서 뭔가 화끈한 내용이 펼쳐지지 않았다는 약간의 아쉬움은 바로 여기서 기인한다. 1986년 프레드릭 브룩스가 발표한 「No Silver Bullet - Essence and Accidents of Software Engineering」 논문에서 언급되었듯이 소프트웨어 개발에 대한 본질을 이야기하자면, 소프트웨어 개발에는 획기적인 해결책은 존재하지 않기에 은총알, 즉 어떤 단일 도구나 단일 방법론도 소프트웨어 개발 과정에서 필연적으로 등장하는 복잡함으로부터 개발자를 구원하지 못한다.
그렇다면 만병통치약인 은총알을 기대하지 못하는 상황에서 소프트웨어 개발의 복잡함과 난해함을 풀어내기 위해 우리는 무엇을 할 수 있을까? 한쪽 편에는 레거시가, 다른 한쪽 편에는 신기술이 포위하는 상황에서 진퇴양난에 빠진 개발자들의 공학적인 이해를 돕기 위해, 이 책은 수십 년 동안 살아남아 검증된 가장 핵심적인 아이디어에 집중한다. 즉 즐겁게 기획하고, 즐겁게 개발하고 즐겁게 사용하기 위해 요구사항 정의부터 설계와 개발을 거쳐 배포에 이르기까지, 모든 소프트웨어 개발에 공통적으로 적용되어야 마땅한 최적화 아이디어를 골라내고 이를 현실에서 제대로 활용하기 위해 고려해야 하는 사안을 다양한 소프트웨어 공학의 개념이나 방법론과 연결해 설명한다. 아키텍처 수립과 설계 단계뿐만 아니라 테스트와 구현 단계까지 전방위로 저자의 경험을 바탕으로 핵심적인 아이디어를 집중적으로 파고든다.
한 번쯤 소프트웨어 아키텍처와 설계 책을 읽어봤다면 방법론이나 실천 방안에 대해서는 이미 익숙할 텐데, 이 책은 여기에 다시 한번 의미를 부여함으로써 정적인 소프트웨어 공학 이론을 동적인 소프트웨어 공학 실천 방안으로 뒤바꿔 놓는다.
테스트 가능성과 배포 관점에서 모듈성을 정리하며, DDD(설계 주도 개발)와 TDD(테스트 주도 개발) 관점에서 응집성과 관심사 분리에 의미를 부여하며, 조직적이고 문화적인 문제와 기술이나 설계 문제 사이의 트레이드오프를 고려해 정보 은닉과 추상화 수준을 선택하는 방안을 제시하고, 마이크로서비스 관점에서 결합도의 어려움을 관심사 분리와 연계해 생각할 거리를 제공한다. 기존에 설계와 코드 수준에서 이런 설계 원칙을 접해본 적이 있는 독자라면, 이 책을 통해 한 단계 더 높은 공학적인 측면에서 이런 설계 원칙이 실제로 현실에서 의미하는 바가 무엇이며 어떻게 포용해야 할지를 이해하게 될 것이다.
요즘과 같이 하루가 다르게 변화하는 세상에서는, 처음부터 1분 1초도 어긋나지 않는 주도면밀한 계획을 수립하고 매번 중간 결과물이 제대로 나왔는지 철두철미하게 검증함으로써 최종 완성품을 만들어 나가는 방식으로는 성공을 담보하지 못한다. 그 반대로 소프트웨어 개발을 (애자일 방법론에서 흔히 언급되듯이) 작은 단계로 나눠 반복하면서 실험을 통해 피드백을 수집하고 학습 역량을 강화하면서 시스템에 대한 이해도를 높이는 방법으로 돌다리를 두드려 가면서 안전하고 신중하게 시스템을 확장해 나가는 방법이 우리의 성공 가능성을 더욱 높여준다.
타성에 젖어서 매일 똑같은 방법으로 프로그램을 만들고 몇 달 뒤에 후회하는 대신 당면한 문제를 빠르고 정확하게 풀어내고 이를 토대로 성장하기 위해서는 무엇이 중요할까? 이 책을 처음부터 끝까지 읽고 나서 다시 한번 자문자답해 보기를 바란다.

출판사 서평

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

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

[추천사 이어서]
이 책은 중요한 주제를 다룬다. 이런 주제를 하나의 패키지로 묶은 개요서가 있다는 사실은 매우 훌륭하다.
- 마이클 나이가드(Michael Nygard) / 『Release의 모든 것』 저자, 전문 프로그래머, 소프트웨어 설계자

검토를 위해 이 책의 사본을 읽어봤는데, 우리에게 꼭 필요한 내용을 담고 있다. 소프트웨어 엔지니어를 꿈꾸는 사람이나 기술을 마스터하고 싶은 사람이라면 반드시 읽어야 할 필독서다. 전문적인 공학에 대한 실용적인 조언이 가득하다. 대학이나 부트캠프에서 반드시 읽어야 하는 책이다.
- 브라이언 핀스터(Bryan Finster) / USAF 플랫폼 원 수석 공학자 겸 가치 흐름 아키텍트

작가정보

저자(글) 데이비드 팔리

(David Farley)
컨티뉴어스 딜리버리 사의 설립자 겸 컨설턴트이며, 현대적인 컴퓨팅의 초기부터 프로그래머, 소프트웨어 엔지니어, 시스템 아키텍트, 성공적인 팀의 리더로서, 컴퓨터와 소프트웨어의 작동 방식에 대한 기본 원칙을 바탕으로 모던 소프트웨어 개발 방식을 바꿔온 획기적이고 혁신적인 접근 방식을 다듬고 있다. 또한 기존의 사고방식에 도전하며 팀을 이끌고 세계적 수준의 소프트웨어를 구축해 왔다. 졸트 상을 수상한 베스트셀러 도서 『Continuous Delivery 신뢰할 수 있는 소프트웨어 출시』를 제즈 험블과 함께 공동 저술했다. 런던 멀티 애셋 익스체인지(LMAX)의 소프트웨어 개발 책임자로서 세계에서 가장 빠른 금융 거래소 중 하나를 구축했으며, 반복적인 개발, 지속적인 통합, 높은 수준의 자동화된 테스트를 포함해 애자일 기법을 가장 먼저 채택한 사람 중 한 명으로서 리액티브 매니페스토(reactivemanifesto.org)를 공동 저술하기도 했다. 지속적인 배포에 관한 유튜브 채널(youtube.com/ContinuousDelivery)도 인기리에 운영하고 있다.

번역 박재호

포항공과대학교 컴퓨터공학과 학부와 대학원을 졸업했다. 임베디드 시스템 개발, 기업용 백업 소프트웨어 개발, 방송국 콘텐츠 수신제한 시스템 개발과 운영 지원, 클라우드에서 동작하는 서비스 개발에 이르기까지 다양한 실무 경험을 토대로 고성능 고가용성 시스템을 설계하고 있다. 코스닥 상장사인 엑셈 CTO로 인공지능과 스마트팩토리 관련 개발을 총괄했으며, 클라우드용 모니터링 시스템을 위한 아키텍처 설계도 주도했다. 지금은 레인보우브레인에서 CTO로 생성형 AI 제품 개발에 힘쓰고 있다. 『클린 코드, 이제는 파이썬이다』, 『마이크로서비스 도입, 이렇게 한다』, 『Clean Code 클린 코드』, 『피플웨어』 등을 번역하고, 『LLM을 활용한 실전 AI 애플리케이션 개발』 등을 감수하는 등 번역, 감수, 집필한 책이 40여 권을 넘는다. 각종 기술 소식을 다루는 블로그 ‘컴퓨터 vs 책’과 개발자를 위한 유튜브 ‘채널 박재호’(youtube.com/c/박재호dev)를 운영하며, 개발자들을 위한 각종 교육과 세미나도 지속적으로 진행하고 있다.

작가의 말

이 책은 ‘소프트웨어 공학’에 다시 ‘공학’이라는 본질을 되돌려 놓는다. 이 책에서 나는 문제 해결에 의식적으로 합리적이고 과학적인 사고방식을 적용하는 소프트웨어 개발에 대한 실용적인 접근 방식을 설명한다. 이런 아이디어는 지난 수십 년 동안 소프트웨어 개발에 대해 배운 내용을 일관되게 적용하는 데서 비롯된다.
이 책을 통해 내가 이루고자 하는 목표는, 공학이 여러분의 생각과는 다르며, 소프트웨어 개발에 적용할 때 완전히 적절하고 효과적이라는 사실을 여러분에게 확신시키는 것이다. 그런 다음 소프트웨어에 대한 이런 공학적인 접근 방식의 기초와 그것이 어떻게 그리고 왜 작동하는지를 설명할 것이다. 이는 프로세스나 기술의 최신 유행이 아니라 무엇이 효과가 있고 무엇이 효과가 없는지 보여주는 데이터를 통해 입증된 실용적인 접근 방식에 관한 내용이다.
작은 단계로 반복적으로 작업하는 경우가 그렇지 않은 경우보다 훨씬 더 효과적이다. 일련의 작고 비공식적인 실험으로 작업을 구조화하고 피드백을 수집해 학습 정보를 얻으면 훨씬 더 신중하게 작업을 진행하고 문제와 해법을 탐색할 수 있다. 각 부분이 집중되고 명확하며 이해하기 쉽도록 작업을 구획화하면 시작하기 전에 목적지를 이해하지 못하는 경우에도 안전하고 신중하게 시스템을 발전시켜 나갈 수 있다. 이런 접근 방식은 심지어 우리가 답을 모를 때도 어디에 집중하고 무엇에 집중해야 하는지에 대한 지침을 제공한다. 이는 우리에게 주어진 과제의 성격이 무엇이든 성공 가능성을 높여준다.
이 책에서는 훌륭한 소프트웨어를 만들기 위해 우리 자신을 구조화하는 방법과 단순한 시스템뿐만 아니라 정말 복잡한 시스템에서도 규모에 관계없이 효율적으로 소프트웨어를 만드는 방법에 대한 모델을 정의한다.