2025년 04월 09일 출간 | ISBN : 1189909855 | 336쪽 | 규격外

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 플랫폼 원 수석 공학자 겸 가치 흐름 아키텍트