Part2.md

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

4장. 개선을 위한 반복

• 반복(iteration)의 묘한 장점: 똑같은 작업이라도 여러 번 반복 수행하면 정확도와 이해도가 높아지는 효과가 있다. 예를 들어 코드를 한 번에 완벽하게 작성하려 하기보다는, 빠르게 초안을 만들고 고쳐 나가면 더 나은 결과가 나온다. 이러한 반복적인 작업 방식은 작은 실패를 수용하면서 점진적으로 개선할 기회를 제공한다. 한 사이클에서 잘못된 부분을 고치고 배우며, 다음 사이클에서는 더 나은 방향으로 나아갈 수 있다.
• 방어적인 설계 전략으로서의 반복: 처음부터 큰 실패를 하는 것보다, 작게 자주 실패하여 빠르게 교정하는 편이 리스크가 적다. 반복 개발을 하면 매 반복마다 시스템이 동작 가능한 상태이므로, 설령 결함이 있어도 금방 발견하고 수정할 수 있다. 이는 “설계상의 실수를 완전히 없앨 순 없지만, 반복을 통해 그 영향을 최소화” 하는 방어적 개발 전략이다. 실제로 짧은 이터레이션(Iteration)을 돌리는 팀일수록 버그가 생산 단계에 가기 전에 잡힐 확률이 높아 품질이 향상된다.
• “계획”이라는 유혹: 거대한 프로젝트일수록 초기 단계에 모든 것을 계획하고 싶은 유혹이 있다. 그러나 소프트웨어는 복잡하여 초기에 세운 계획대로 되지 않는 경우가 다반사다. 상세 계획을 오래 잡는 동안 요구사항이 바뀌거나, 개발하면서 기술적 어려움이 드러나기도 한다. 계획 수립 자체에 너무 많은 시간과 노력을 쓰면 변화에 대한 대응력이 떨어지며, 오히려 효율적이지 못하다. 완벽한 계획보다는, 적절한 계획 수립 후 빠르게 실행하여 피드백을 얻는 태도가 더 효과적이다.
• 반복 작업의 실제: 애자일 방법론 등에서는 1~2주 단위의 반복 개발(스프린트)을 권장한다. 이를 따르면 매 이터레이션마다 설계 → 구현 → 테스트 → 피드백이 이루어지므로, 계획과 실제의 차이를 즉각 알아차릴 수 있다. 예컨대 6개월 후를 예측하기보다 2주 후를 예측하는 쪽이 정확도가 높으며, 2주의 결과를 보고 다음 2주의 계획을 조정하면 된다. 이렇게 짧은 호흡으로 계획과 실행을 계속 조정하는 것이 현대적 프로세스 개선의 핵심이다.
• 정리: 반복은 변화를 수용하는 개발 방식이다. 한 번에 완벽을 기하기보다 조금 만들어보고, 피드백 받고, 개선하는 주기를 돌리면 결과적으로 더 나은 품질과 생산성을 얻는다. 이러한 반복적 접근은 개발팀이 불확실성을 관리하고, 고객 요구에 더 민첩하게 대응하도록 도와준다.

워터폴 vs 애자일: 전통적 워터폴(Waterfall) 모델은 개념/계획 → 설계 → 구현/배포 → 유지보수 단계를 순차적으로 거친다. 애자일(Agile) 혹은 반복적(Iterative) 개발은 작은 단위로 설계-구현-피드백 사이클을 여러 번 반복함으로써 점진적으로 시스템을 완성하는 과정을 보여준다. 두 접근법의 차이는 피드백 주기에 있다: 워터폴은 후반에 한 번의 큰 피드백(유저 테스트 등)이 있지만, 애자일은 짧은 주기의 지속적인 피드백을 통해 유연하게 방향을 수정한다.

5장. 피드백: 우수한 의사결정을 위한 필수 요소

• 피드백의 중요성을 보여주는 사례: 한 스타트업 팀 A와 팀 B가 동일한 제품을 개발했다고 가정하자. 팀 A는 6개월 동안 내부적으로 개발만 하고 나중에 한번에 출시했으며, 팀 B는 2주마다 사용자들에게 기능을 공개하고 의견을 받았다. 그 결과 팀 B는 시장 요구에 더 부합하는 제품을 만들었고 실패 가능성을 줄였다. 이 사례에서 보듯, 적절한 피드백을 주고받는 과정이 우수한 의사결정의 핵심이다. 피드백은 현실과 우리의 생각 사이의 격차를 메워 주므로, 이를 적극 활용하는 팀이 더 나은 결과를 낸다.
• 코딩 단계에서의 피드백: 가장 가까운 피드백은 코드 작성 즉시 받는 피드백이다. 예를 들어 코드를 작성하고 단위테스트를 돌리면, 코드가 의도대로 동작하는지 바로 알 수 있다. 또한 동료 프로그래머의 코드 리뷰도 중요한 피드백이다. 잘못된 구현이나 개선할 부분을 빨리 지적받으면, 버그를 사전에 제거하고 더 나은 코드를 얻을 수 있다. 이처럼 개발자 수준의 즉각적 피드백 루프(테스트 통과 여부, 코드 품질에 대한 동료 의견 등)는 결과물의 품질을 크게 끌어올린다.
• 통합 과정 피드백: 한 명의 개발자 작업이 끝이 아니라, 여러 구성원이 작성한 코드가 합쳐질 때 시스템 수준에서 문제가 없는지 확인하는 피드백이 필요하다. 지속적 통합(CI) 도구는 코드가 중앙 저장소에 커밋될 때마다 자동으로 빌드하고 테스트하여, 통합 과정에서 생기는 오류를 즉각 알려준다. 또한 QA(Test) 팀의 통합 테스트나 스테이징 환경에서의 시험 가동 등을 통해 모듈 사이의 호환성과 종합적인 기능 동작에 대한 피드백을 얻는다. 이러한 통합 단계의 피드백이 빠를수록, 부서 간에 “네 탓 내 탓” 하며 문제를 늦게 발견하는 일을 줄일 수 있다.
• 설계 단계 피드백: 설계에 대한 피드백은 구현 전에 받기 어렵지만, 동료와의 설계 검토(meeting) 나 프로토타이핑을 통해 얻을 수 있다. 예를 들어 UML 다이어그램이나 아키텍처 스케치를 함께 보면서 토론하면, 혼자 놓쳤던 케이스를 동료가 짚어줄 수 있다. 또는 핵심 모듈에 대해 간단한 프로토타입을 먼저 만들어보면, 설계 구상 시에 예상 못한 문제가 드러날 수 있다. 설계 피드백을 미리 받으면 잘못된 방향으로 큰 시스템을 만드는 위험을 줄일 수 있다.
• 아키텍처 수준 피드백: 시스템 아키텍처(예: 마이크로서비스 vs 모놀리식 결정, 기술 스택 선택 등)는 바꾸기 어려우므로 초기 단계의 피드백이 특히 중요하다. 이때 기술 검증(Proof of Concept) 이나 아키텍처 스파이크(spike) 를 통해 핵심 가정을 테스트해볼 수 있다. 가령 새로운 데이터베이스가 요구 성능을 낼 수 있는지 작은 테스트를 해보거나, 한두 개 모듈만 분리 배포해보는 식이다. 또한 과거 유사 프로젝트의 사례를 조사하거나, 사내 아키텍트 리뷰를 받는 것도 좋은 피드백 방법이다. 아키텍처 피드백은 장기적으로 큰 비용 절감을 가져온다 – 잘못된 아키텍처를 초기에 수정하면 되지만, 나중에 바꾸려면 막대한 재작업이 필요하기 때문이다.
• 피드백은 빠를수록 좋다: 위에서 언급한 다양한 피드백 (코드, 통합, 설계, 아키텍처)은 시기와 빈도가 성공의 열쇠다. 피드백이 즉각적일수록 문제를 저렴한 시점에 고칠 수 있다. 예컨대 요구사항 오류를 운영 단계에서 고객에게 듣는다면 이미 늦었지만, 기획 단계에서 사용자 피드백을 받으면 방향 선회를 빨리 할 수 있다. “빠른 피드백, 빠른 개선” 이 우수한 팀과 평범한 팀을 가르는 기준이라고 해도 과언이 아니다.
• 제품 설계 피드백: 소프트웨어 엔지니어링은 코드에만 국한되지 않는다. UI/UX 디자인 시안에 대한 사용자 테스트, A/B 테스트 등을 통해 최종 사용자로부터 제품 자체에 대한 피드백을 얻어야 한다. 고객이 실제로 어떻게 쓰는지를 관찰하면, 우리가 중요하다고 여긴 기능이 사실은 안 쓰인다든가, 예상치 못한 사용 패턴을 발견할 수 있다. 이렇게 제품 설계 단계의 피드백을 통해 소프트웨어 엔지니어는 단순히 “동작하는 소프트웨어”를 넘어 “사용자에게 유용한 소프트웨어” 를 만들 수 있게 된다.
• 조직과 문화 차원의 피드백: 피드백 문화는 조직 전반에 스며들어야 한다. 예를 들어 정기적인 회고 미팅(retrospective) 을 통해 지난 개발 iteration에서 무엇이 좋았고 나빴는지 팀 차원에서 피드백을 주고받는다. 또한 개발 속도, 버그 발생률, 고객 만족도 등의 지표를 통해 프로세스 개선에 대한 피드백을 얻는다. 건강한 조직은 윗사람으로부터의 일방향 지시뿐 아니라 아래로부터의 현장 피드백이 자유롭다. 이런 문화적 피드백이 있을 때 엔지니어링 원칙들도 제대로 실행될 수 있다.
• 정리: 피드백 없이 하는 결정은 불확실성이 크다. 모던 소프트웨어 엔지니어링에서는 가능한 모든 단계에서 피드백을 수집하고 활용한다. 작은 코드 단위의 피드백부터 최종 사용자와 조직 운영에 이르기까지 다각도의 피드백 루프를 구축하면, 잘못된 길로 오래 가는 일이 줄어들고, 최적의 방향으로 의사결정을 지속 조정할 수 있다.

6장. 점진주의: 조금씩, 조금씩, 앞으로

• 우주선 예시로 보는 모듈성: 우주선을 설계할 때 한 번에 통째로 만들지 않고 모듈별로 나눠서 개발한다. 예를 들어 추진 로켓, 궤도선, 착륙선 등을 분리하고 개별 테스트한 후 조합한다. 소프트웨어도 마찬가지로, 시스템을 기능 모듈 단위로 쪼개서 부분 완성품을 만들어 나가며 전체를 구축할 수 있다. 이렇게 하면 각 모듈이 독립적으로 작동하도록 설계되어 변경이나 장애가 발생해도 전체 시스템에 미치는 영향을 최소화한다. 점진적 개발은 모듈성(modularity) 을 전제로 하며, 이는 앞서 언급한 복잡성 관리에도 유리하다.
• 효율 높은 조직 구성을 위한 비법: 점진주의를 조직에 적용하면 애자일한 조직 구조가 된다. 큰 팀 하나가 모든 걸 한꺼번에 하는 대신, 기능별 작은 팀들이 병렬로 조금씩 진행하는 것이다. 예를 들어 프론트엔드 팀, 백엔드 팀, 데이터베이스 팀이 따로 움직이기보다, 기능별 크로스기능 팀(feature team) 을 구성해 해당 기능의 UI부터 DB까지 작은 vertical slice(수직적 분할)을 끝까지 구현하는 식이다. 이렇게 하면 각 팀이 작은 목표를 독립적으로 완수하고, 전체적으로는 병렬 개발로 속도가 빨라진다. 조직 자체를 모듈화한 셈이며, 이는 큰 조직의 복잡성을 줄이는 핵심 전략이다.
• 점진주의를 적용하기 위한 도구: 점진적으로 개발하려면 환경과 도구의 지원이 필요하다. 버전 관리 시스템(Git) 은 여러 브랜치를 활용해 기능 단위를 병렬 개발하고 머지함으로써 점진적 통합을 돕는다. Feature Toggle(기능 토글) 기법은 코드는 배포하되 기능 활성화는 토글로 제어하여, 미완성 기능도 메인 코드베이스에 점진적으로 포함시킬 수 있게 해준다. CI/CD 파이프라인은 변경이 있을 때마다 자동으로 빌드/테스트/배포해 주어 점진적 릴리스(배포)를 가능하게 한다. 이러한 도구들은 모두 작은 단위의 변경을 빠르게 반영하기 위한 것으로, 점진주의를 현실에 적용하는 기반이라 할 수 있다.
• 변경의 부작용 최소화: 소프트웨어 수정 시 부수효과(side effect) 로 예기치 않은 부분이 망가지는 게 흔한 문제다. 점진주의는 한 번에 한 모듈이나 한 기능씩 변경하므로, 만약 문제가 생겨도 영향 범위가 작다. 또한 테스트 자동화를 갖춰두면 리팩토링이나 기능 추가 시 기존 기능이 망가지지 않았는지 즉각 확인할 수 있다. 분리된 아키텍처(예: 마이크로서비스) 를 채택하면 한 서비스의 변경이 다른 서비스에 영향 주지 않도록 격리할 수도 있다. 핵심은 한 걸음 뗄 때마다 안전망(자동 테스트, 모니터링)을 두고 움직이는 것이다. 이렇게 하면 점진적 변경의 리스크가 통제 가능해진다.
• 점진적인 설계: 소프트웨어 설계도 점진적으로 할 수 있다. 이를 진화적 설계(Evolutionary Design) 라고 하는데, 초기에 모든 세부사항을 설계하기보다 현재 필요한 부분을 설계하고 구현하면서, 새로운 요구나 문제를 발견하면 설계를 개선해나가는 방식이다. TDD(Test-Driven Development) 같은 기법은 코드 구현 전에 테스트를 설계함으로써, 필요 최소한의 인터페이스와 기능을 정의하게 하고, 구현 후 리팩토링을 통해 설계를 다듬게 한다. 이런 식으로 필요에 따라 설계를 점차 구체화하면 YAGNI(You Ain’t Gonna Need It, “당장 필요하지 않은 것은 만들지 마라”) 원칙을 지킬 수 있고, 과설계(over-engineering) 를 피하면서도 유연한 구조를 얻을 수 있다.
• 정리: 점진주의는 “한 번에 모두” 가 아니라 “조금씩, 그러나 끊임없이” 라는 접근이다. 이를 통해 개발 과정 내내 작동하는 소프트웨어를 유지하며, 필요할 때 언제든 방향 전환과 개선을 할 수 있다. 결과적으로 큰 덩어리를 나중에 통째로 검증하는 것이 아니라, 작은 덩어리들을 수시로 검증하고 통합하므로 위험을 줄이고 반응성을 높인다. 현대 소프트웨어 엔지니어링에서 점진주의는 빠른 가치 제공과 탄력적 대응을 위한 핵심 원리이다.

7장. 경험주의: 현실을 자각하자

• 꿈은 높게, 그러나 발은 땅에: 소프트웨어 프로젝트에서는 비전과 열정도 중요하지만, 현재 드러난 사실을 외면하면 안 된다. 아무리 멋진 아이디어도 실제로 구현 가능해야 의미가 있다. 경험주의란 “현실 세계의 데이터와 경험을 바탕으로 의사결정” 하는 태도를 뜻한다. 가령 “이 기능이 사용자에게 엄청나게 유용할 것이다”라고 가정만 하지 말고, 실제 사용자 행동 데이터를 관찰해야 한다. 높게 설정한 목표를 실현하려면 우선 현재 내가 어디에 서 있는지, 주변 환경은 어떤지 객관적으로 인식하는 것이 첫걸음이다.
• 실험과 실제 업무 경험은 구분해야 한다: 개발 과정에서는 종종 새로운 기술이나 방법을 실험적으로 시도해볼 수 있다. 그러나 중요한 마일스톤이나 프로덕션 릴리스에서는 확실히 검증된 것들 위주로 결정해야 한다. 경험주의적 조직은 “실험실 모드”와 “실전 모드” 를 구분짓는다. 예컨대 새로운 프레임워크 도입은 사이드 프로젝트나 시범 서비스로 먼저 해보고, 충분한 경험 데이터가 쌓이면 주요 프로젝트에 적용한다. 이렇게 하면 혁신과 안정 사이에서 균형을 잡을 수 있다.
• “저 이 버그 알아요!”의 함정: 간혹 디버깅 시에 비슷한 증상을 과거에 봤다는 이유로 문제를 단정 지어버리는 경우가 있다. “전에 메모리 누수 때문에 그랬으니 이번에도 틀림없이 그거야”라고 넘겨짚으면, 혹시 다른 원인일 경우 문제를 그르친다. 경험주의는 선입견보다 관찰을 중시하기에, 이전 경험이 있더라도 항상 새롭게 조사하고 검증하는 자세를 취한다. 실제로 같은 현상이라도 원인은 다양할 수 있으므로, 겸손하게 로그와 데이터를 확인하는 것이 옳다.
• 자기기만은 우리의 적: 사람은 보고 싶은 것만 보는 경향이 있다. 소프트웨어 개발에서도 자신이 선호하는 해법을 정당화하려고 데이터 해석을 왜곡하기 쉽다. 예를 들어 “이번 출시 기능, 사용자들이 분명 좋아할 거야”라는 믿음 때문에 부정적인 사용자 피드백을 무시한다면 이는 자기기만이다. 경험주의적인 엔지니어는 냉정하게 사실을 바라보고 불편한 진실도 받아들이는 용기를 가진다. 그래야만 올바른 조치를 취할 수 있기 때문이다.
• 우리의 주장에 맞는 현실을 발명하지 말자: 소프트웨어 프로젝트에서는 종종 정치적인 상황이나 압력 때문에 현실을 있는 그대로 기록하지 않고 미화하는 일이 벌어진다. (예: 진척률 50%인데도 “80% 완료”라고 보고하거나, 성능 지표가 나쁜데도 “문제 없다”고 치부함). 그러나 이런 식으로 가상의 낙관적 현실을 만들어내면 실제 문제 해결은 요원해진다. 경험주의 원칙은 “사실대로 말하고, 사실대로 행동” 하는 것이다. 불편한 데이터도 투명하게 드러내고, 그것을 출발점으로 개선해야 상황이 나아진다.
• 추측보다는 실험: 현실에 입각한 경험주의: 결국 모르면 실험을 통해 알아내는 것이 최선이다. 새로운 기능에 대한 사용자 반응이 궁금하면 일부 트래픽에만 노출(A/B 테스트)해보는 식이다. 성능 튜닝 아이디어가 있으면 작은 부하 테스트를 돌려 효과를 검증해본다. 이런 짧은 사이클의 실험을 생활화하면, 추측에 의존해 시행착오하는 시간을 줄일 수 있다. 경험주의란 의견이나 직감보다 현실에서 얻은 증거를 우선시하는 태도이며, 모던 소프트웨어 엔지니어에겐 필수적인 덕목이다.
• 정리: 경험주의는 “사실에 기반해 배우고 결정한다” 는 뜻이다. 소프트웨어 개발에서 이는 데이터와 실제 관찰을 통한 학습으로 구현된다. 주관적 확신이나 계획에 매몰되지 말고, 언제나 현실 세계(사용자, 시스템)의 목소리에 귀 기울이는 것이다. 그렇게 해야 예상과 다른 상황에도 유연하게 대응하고, 잘못된 길로 깊이 들어가지 않을 수 있다.

8장. 실험주의: 과학적 사고와 실천

• 물리학자 파인먼에게 배우는 ‘실험주의’: 리처드 파인먼은 “첫 번째 원칙은, 스스로를 속이지 말라. 그리고 당신은 속이기 가장 쉬운 사람이다”라고 말했다. 이는 소프트웨어 엔지니어링에도 통하는 말로, 자신의 아이디어가 옳다고 가정하지 말고 실제로 검증하라는 뜻이다. 실험주의란 말 그대로 과학 실험하듯 개발에 임하는 자세다. 가설을 세우고, 실험(코드나 테스트)으로 검증하고, 관찰된 결과로부터 결론을 내리는 과학적 방법론을 의미한다. 실험주의를 실천하기 위한 네 가지 핵심 원칙을 살펴보자:
  1. 피드백 – “결과를 빨리 확인하라”: 어떤 변경이나 시도를 했다면 그 효과를 바로 확인하는 체계를 갖춘다. 예를 들어 코드를 수정했다면 즉시 테스트를 돌려 결과(성공/실패)를 보고, 새로운 기능을 배포했다면 사용자 행동이나 모니터링 지표를 빨리 수집한다. 빠른 피드백은 실험의 생명이다. 피드백이 빨라야 실험을 자주 할 수 있고, 시행착오 속에서도 빠르게 옳은 방향을 찾아갈 수 있다.
  2. 가설 – “명확한 예측을 수립하라”: 실험주의에서는 무작정 해보기보다 “이 변경을 하면 ~한 효과가 날 것이다” 라는 구체적인 가설을 먼저 세운다. 그래야 결과가 나왔을 때 성공/실패를 판정할 수 있다. 예를 들어 “함수 알고리즘을 X로 바꾸면 처리속도가 20% 빨라질 것이다”라는 가설을 세운 뒤 코드를 수정해 측정한다. 이렇게 가설이 있으면 실험 결과를 해석하기 쉽고, 학습도 체계적으로 이루어진다.
  3. 측정 – “정확한 데이터를 모아라”: 실험 결과는 느낌이 아니라 데이터로 측정해야 한다. 인간은 주관적 편향이 있어서 원하는 방향으로 해석하기 쉽기 때문이다. 따라서 성능 개선 실험을 했다면 실제 처리량이나 응답시간 숫자를 수집하고, UI 변경 실험을 했다면 사용자 클릭률이나 이탈률 변화를 기록한다. 정량적 측정은 실험의 근본이며, 이러한 데이터 누적이 곧 지식 자산이 된다. 또한 측정은 반복 가능하고 정확해야 한다 – 동일 조건에서 같은 결과가 재현되는지 확인해야 실험의 신뢰성이 확보된다.
  4. 변수 통제 – “하나씩 바꿔라”: 과학 실험에서 한 번에 여러 변수를 바꾸면 어떤 변화가 결과에 영향을 주었는지 알 수 없듯이, 소프트웨어 실험에서도 한 번에 하나씩 변경하는 것이 원칙이다. 성능 개선을 한다고 코드도 바꾸고 DB도 바꾸면, 좋아져도 뭐 때문인지 모른다. TDD의 테스트도 마찬가지: 한 테스트는 한 가지 기능만 검증해야 무엇이 잘못됐는지 알 수 있다. 변수 통제는 실험에서 원인과 결과를 명확히 연결해 주기 때문에, 여러 개선안을 시도할 때는 순차적으로 하나씩 적용하고 평가하는 것이 바람직하다.
• TDD에서 배우는 자동화 테스트: 테스트 주도 개발(TDD)은 소프트웨어 분야에서 실험주의를 적용한 대표 사례다. 개발자는 코드를 작성하기 전에 기대되는 동작을 가설 삼아 테스트 케이스(실패할 상황)를 만들고, 그 테스트를 통과시키기 위해 코드를 작성한다. 빨간막대(실패) -> 초록막대(성공) -> 리팩터의 사이클은 곧 가설 -> 실험 -> 결과 분석의 사이클과 유사하다. TDD에서는 테스트가 일종의 실험 장치 역할을 하여, 새로운 코드를 추가할 때마다 자동으로 피드백을 제공해준다. 이는 개발자가 안전한 실험 환경에서 자유롭게 리팩토링(설계 개선)할 수 있게 해, 시스템 품질을 유지한 채로 진화를 거듭할 수 있게 한다.
• 테스트는 새로운 지식을 끌어내는 원천: 어떤 기능에 대해 테스트를 작성하다 보면, “만약 이 함수에 이상한 입력이 들어오면 어떻게 해야 하지?” 등 미처 생각지 못한 시나리오를 발견하게 된다. 이런 테스트 작성 과정은 곧 요구사항을 구체화하고 시스템에 대한 이해를 높이는 실험 과정이라고 볼 수 있다. 또한 테스트 결과는 개발자에게 시스템 동작에 대한 사실 기반의 피드백을 준다. 반복되는 테스트 실패는 설계의 문제점을 알려주고, 테스트 통과는 구현이 요구를 만족함을 증명한다. 이렇게 테스트를 통해 우리는 코드에 대한 새로운 지식을 계속 얻어나간다.
• 품질을 높이는 TDD 적용 사례: 예를 들어 한 팀이 복잡한 금융 계산 모듈을 개발할 때 TDD를 도입했다고 하자. 처음에는 개발 속도가 더딘 듯했지만, 시간이 지날수록 해당 모듈의 버그 발생률이 현저히 낮았고, 요구 변경에도 유연하게 대응했다. 왜냐하면 TDD로 촘촘한 테스트망을 갖춰둔 덕분에, 자신 있게 리팩토링하며 설계를 개선할 수 있었기 때문이다. 결과적으로 다른 모듈보다 유지보수 비용이 낮아지고 신뢰성이 높았다. 이 사례는 TDD라는 작은 실험주의적 실천이 장기적으로 제품 품질과 개발 효율을 모두 향상시킨 예이다.
• 정리: 실험주의는 소프트웨어 엔지니어링을 경험적 학문(empirical discipline) 으로 만들어준다. 추측이 아닌 증거, 독단이 아닌 재현 가능한 실험으로 방향을 잡는 것이다. 빠른 피드백, 명확한 가설, 정량적 측정, 변수 통제를 통해 개발을 하나의 과학 실험처럼 접근하면, 실패를 두려워하지 않고도 지속적으로 학습하고 개선할 수 있다. 이러한 실험 문화는 곧 더 나은 소프트웨어를 더 빠르게 만드는 모던 소프트웨어 엔지니어링의 밑거름이 된다.