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

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

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

데이비드 팔리 지음 | 박재호 옮김 
336쪽 | 28,000원 | 2025년 4월 9일 출간 | 172*225*17 | ISBN 9791189909857 (93000)

판매처 | [교보문고] [YES24] [알라딘] [영풍문고] + 전국 교보/영풍문고 매장
전자책 판매처 | [교보문고] [YES24] [알라딘] [리디북스] | 2025년 6월 출간 예정

원서명: Modern Software Engineering: Doing What Works to Build Better Software Faster

정오표: https://www.onlybook.co.kr/entry/modern-software-errata (아직 등록된 정오표가 없습니다)

AI 열풍이 불어도 개발자의 역량과 지식은 여전히 중요하다. 
소프트웨어 엔지니어로 변함없이 살아남아야 할 당신을 위해 단단한 기본기와 힘을 심어 줄 책!

소프트웨어 개발의 복잡함과 난해함에 맞서 싸울 용기와 지혜를 이 책에서 찾아보자.
TDD, DDD, MSA를 이해하려면 반드시 알아둬야 할 핵심 소프트웨어 설계 원칙을 현대적으로 재해석하고 풀어서 설명했다!

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

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

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

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

이 책의 구성

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

추천의 글

AI가 코드를 작성하는 시대에는 단순 코딩 노동자는 더 이상 살아남기 어렵습니다. 소프트 엔지니어는 애플리케이션 개발부터 배포 그리고 운영까지 수많은 단계에 참여해야 합니다. 특히 애플리케이션 개발은 설계부터 구현까지 효율적으로 만들어져야 합니다. 그러므로 ‘소프트웨어 엔트로피(시스템의 무질서, 복잡도)’에 대한 끝없는 고민이 이어집니다. 우리는 매번 새로 소프트웨어를 작성할 수는 없으며, 방치되어 있는 레거시 소프트웨어도 우리가 품고 가야 할 자산입니다. 이에 이 책은 두 가지를 강조합니다. ‘프로세스 개선’과 소프트웨어 ‘복잡성 관리’입니다.
이 책은 소프트웨어를 개발하는 전반적인 프로세스나 개발 방법론을 활용하는 방법을 설명합니다. OOP, TDD, DDD 같은 개발 방법론을 어떻게 프로젝트에 활용할지 이야기를 풀어나가며, 단순한 정보 전달이 아닌 저자의 경험을 바탕으로 이야기합니다. 따라서 처음 프로젝트에 참가하는 초보 개발자나 혹은 애플리케이션 개발 경험이 적은 개발자보다는, 어느 정도 개발 경험이 있는 개발자들에게 추천하고 싶습니다.
“시간과 기능에 비례해서 커져가는 내 소프트웨어의 복잡성을 어떻게 풀어야 할까?”, “방치된 코드를 어떤 식으로 최신 기술로 변경해야 할까?” 같은 고민을 하시는 분들에게 소중한 실마리를 제공할 책입니다.
- 김병부 / Line+ 소프트웨어 개발자

혹시 ‘기도 메타’라는 얘기를 들어본 적이 있을까요? 배포 때마다 배포가 실패하면 믿음과 기도가 부족해서 실패한 것이니 기도를 통해 운에 모든 것을 맡기겠다는 표현입니다.
장애가 발생하면, 이전의 경험에서 해당 문제를 확인하려고 하지는 않나요? 소프트웨어 개발이라는 것은 공학적인 접근이 필요합니다. 공학적인 접근을 위해서는 여러 가지 방법이 있지만, 현재 상태의 관찰, 가설 수립, 예측, 실험, 측정의 단계로 접근할 필요가 있습니다. 이런 각 단계는 절대로 길어서도 안 됩니다. 모든 단계에서는 빠른 피드백이 필요합니다.
단순히, 코딩, 설계, 통합의 관점에서뿐만 아니라 소프트웨어 공학이라는 관점에서 조직과 문화에 대해서도 피드백이 필요합니다. 지금까지 우리의 소프트웨어 개발은 소프트웨어 공학을 적용한다고 생각해 왔지만, 정말로 올바르게 소프트웨어 공학을 적용하고 있었을까요? 이 책에서는 이에 대한 답으로, 빠르게 바뀌는 세상에서 우리는 ‘학습의 전문가’가 되어야 한다고 말합니다. 또한 지속적으로 계속 과학적이고 공학적인 관점에서 소프트웨어 개발을 바라보게 해줍니다.
- 강대명 / 소프트웨어 엔지니어, 전 레몬트리 CTO

저에게는 무척 감동적인 책입니다. 모든 개발자가 읽어야 합니다. 
직업 프로그래머로 일하면서 생각대로 개발이 진행되지 않아 소프트웨어 공학에서 답을 찾으려고 무척 노력했습니다. 하지만 당시 소프트웨어 공학은 답이 아니었습니다.
애자일과 관련 실천법에서 답을 찾은 저는 이 실천법을 ‘공학’ 대신 ‘기예’라고 부르며 소프트웨어 공학을 비판하는 입장을 유지했습니다. 이런 저에게 어떤 분이 이 ‘기예’들이야말로 우리가 소프트웨어 공학이라고 부를 수 있는 것이 아니냐는 의견을 주셨고, 비로소 저는 다시 소프트웨어 공학이라는 단어를 사용하기 시작했습니다.
이 책은 우리 업계가 오랫동안 노력해 찾은 ‘올바른 소프트웨어 공학’을 설명합니다. 제가 늘 추천하는 『구글 엔지니어는 이렇게 일한다』가 실증된 엔지니어링을 구체적으로 설명한다면 이 책은 그 책과 짝을 이루어 이론적 배경을 설명합니다.
우리가 다시 길을 찾았습니다.
- 박성철 / 컬리 CTO, 『Release의 모든 것』 역자

다양한 방면에서 활용되는 소프트웨어가 첨단 공학의 집약체임을 부인할 사람은 없을 것입니다. 하지만 역설적이게도 이런 소프트웨어를 만드는 과정은 공학보다는 예술이나 개인기로 여겨지곤 합니다. 저자는 소프트웨어 개발도 공학의 한 분야이며, 따라서 인류가 쌓아온 공학의 지식을 활용해 충분히 개선할 수 있다고 설득합니다.
이 책에서 다루는 실천 방안과 기본 원칙들은 널리 알려지고 검증된 내용이라 새롭지 않을 수도 있습니다. 하지만 이렇게 머릿속에 떠다니던 지식들을 공학의 틀에 잘 녹여, 우리의 프로젝트에 적용할 용기를 낼 수 있도록 설득력 있게 전파하고 있다는 점이 이 책의 매력이라고 생각합니다.
좋은 소프트웨어를 잘 만들기 위해 고민하는 분들에게 좋은 지침이 될 것이라고 생각합니다.
- 안세원 / 카카오모빌리티 안드로이드 개발자

내가 소프트웨어 공학에 관심을 가지게 된 건 아무래도 내 전공이 수의학이다 보니, 개발을 하면서 느끼는 학술적 목마름에 대한 이유가 가장 컸다. 하지만 교과서 같은 『Software Architecture in Practice』 책과 디자인 패턴 같은 것들보다 당시의 내게 더 와닿았던 건, 애자일이라고 불리기 한참 전의 익스트림 프로그래밍(XP)이었다. 모범 관행들은 내 개발 과정에 영감을 주기에 모자람이 없었지만, 나는 결국 그렇게 몇 년을 보낸 뒤 『Software Architecture in Practice』를 다시 정독하고 비로소 소프트웨어 공학에 많은 시간을 보내며 공부했던 기억이 있다.
이 책은 10년이 넘는 개발자로서의 내 방황에 대한 모든 이유를 너무나도 잘 설명하는 글이 가득하다. 특히 2부 ‘소프트웨어 프로세스 개선을 위한 구체적인 실천 방안’에는 정말 보석 같은 내용이 실려 있다. 내가 관행으로만 인식하고 있던 것들에 공학적 뒷받침을 살려준 명문들이다. 공학에 선입견을 가진 분들이라면 꼭 읽어보길 추천 드린다. 우리가 걸었던 길들은 필시 틀린 길이 아니었다.
- 양수열 / 크라우드웍스 CTO, 한국인 최초의 자바 챔피언

대부분의 소프트웨어 프로젝트에서 요구사항 도출, 프로그램 설계와 구현, 디버깅은 모두 동적인 과정이며 반복적인 과정이다. 전체 소프트웨어 개발은 이런 요구분석부터 디버깅에 이르는 과정을 여러 번 반복해 가면서 도메인과 개발 중인 소프트웨어에 대한 지식을 축적해 나가면서 우리가 원하는 소프트웨어의 최종적인 모습을 발견해 나가는 과정에 가깝다고 생각한다.
박재호 님이 깔끔하게 번역한 이 책은 이런 반복적 과정에서 우리가 관심을 가져야 할 요소를 학습 관리와 복잡성 관리라는 두 분야로 나눠 설명하면서, 우리가 더 나은 개발자가 되고 프로젝트를 더 잘 마무리하기 위해 필요한 마인드셋을 갖춰나갈 수 있게 해주는 원칙을 제시한다.
물론 소프트웨어 개발에는 은총알은 없지만, 이 책에 담긴 내용을 마음에 담고 이 책의 지침을 자신의 프로젝트에 구체적으로 적용할 방법을 찾아나가다 보면 더 나은 개발자로 성장하고 프로젝트를 성공으로 이끌 수 있을 것이다.
- 오현석 / (주)모빌리티42 CTO, 기술번역가

AI가 빠르게 만들어 주는 코드를 그대로 받아들이는 ‘바이브 코딩’ 방식이 확산되면서, 소프트웨어 개발은 더욱 편리해졌지만 역설적으로 이전에는 없던 새로운 차원의 복잡성을 마주하게 되었습니다. 동작 여부에만 집중한 나머지 장기적인 관리와 유지보수에 어려움을 겪는 사례가 늘고 있습니다.
이 책은 이렇게 심화되는 소프트웨어 복잡성을 ‘공학적 접근’으로 다루는 법을 명쾌하게 제시합니다. 점점 복잡해지는 시스템을 체계적으로 관리하고 발전시킬 역량을 키우고 싶은 개발자라면, 이 책에서 깊은 즐거움을 느끼게 될 것입니다.
- 이일민 / 이프릴 대표, 『토비의 스프링』 저자

많은 개발자가 소프트웨어를 개발하면서도 자신이 ‘엔지니어링’을 한다고 느끼지 못합니다. 그 이유는 소프트웨어 공학은 물리적 실체가 없어 다른 공학 분야와 다른 특성이 많고 하드웨어의 눈부신 발전으로 인해 소프트웨어의 많은 문제가 저절로 풀리는 경험을 했기 때문이라고 생각합니다.
이 책은 그런 개발자들의 고민을 정확히 짚어내며, 소프트웨어 공학의 본질을 문제 해결의 절차와 방법론으로 새롭게 정의합니다. 특히 저자는 학습과 복잡성 관리의 중요성을 강조하며, 구체적인 5가지 학습 방법과 소프트웨어 복잡성을 다룰 수 있는 5가지 핵심 특성을 명료하게 제시합니다. 소프트웨어 개발자로서 자신의 업무를 좀 더 공학적으로 접근하고, 체계적이고 효율적으로 문제를 해결하고자 하는 모든 이들에게 이 책을 강력히 추천합니다.
- 허정준 / (주)크몽 AI 엔지니어, 『LLM을 활용한 실전 AI 애플리케이션 개발』 저자

이 책은 오늘날 숙련된 실무자가 실제로 소프트웨어를 공학적으로 만드는 방식을 제대로 파악해서 설명한다. 이 책에서 제시하는 기술은 엄격하거나 규범적이거나 선형적이라기보다는 소프트웨어에 필요한 방식, 즉 경험적, 반복적, 피드백 중심, 경제적, 코드 실행에 초점을 맞춘 방식으로 규율을 갖추고 있다.
- 글렌 밴더버그(Glenn Vanderburg) / 누뱅크 공학 디렉터

특정 소프트웨어 공학 관례를 따르는 방법을 알려주는 책은 많지만 이 책은 다르다. 데이브는 이 책에서 소프트웨어 공학을 정의하는 본질과 그것이 단순한 기술과는 어떻게 다른지를 설명한다. 소프트웨어 공학을 마스터하기 위해 학습과 복잡성 관리의 달인이 되어야 하는 이유와 방법, 이미 존재하는 관례가 이를 지원하는 방법, 소프트웨어 공학 관점에서 다른 아이디어의 장점을 판단하는 방법을 설명한다. 소프트웨어 개발을 이제 막 시작했든, 수십 년 동안 소프트웨어를 구축해왔든, 소프트웨어 개발을 진정한 공학 분야로 진지하게 여기는 모든 사람을 위한 책이다.
- 데이브 하운슬로(Dave Hounslow) / 소프트웨어 엔지니어

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

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

여는 글

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

지은이 데이비드 팔리 David Farley

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

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

옮긴이 박재호

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

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

차례

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