Skip to content

Instantly share code, notes, and snippets.

@shane-shim

shane-shim/martin-fowler-the-new-methodology-summary.md

Created April 16, 2026 15:06
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save shane-shim/5fb08fb9ed5b57845890ef598491a624 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save shane-shim/5fb08fb9ed5b57845890ef598491a624 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
martin-fowler-the-new-methodology-summary.md

Martin Fowler — "The New Methodology" 요약 정리

2005년 마틴 파울러가 정리한 애자일 방법론의 등장 배경과 핵심 철학 원문: martinfowler.com/articles/newMethodology.html

1. 핵심 문제의식: 왜 기존 방법론은 실패하는가

공학 메타포의 오류

기존 소프트웨어 방법론은 토목·기계 공학처럼 '설계'와 '시공'을 엄격히 분리하려 했다.

토목 공학 소프트웨어 개발
설계 비용 전체의 ~10% 전체의 50% 이상
시공 비용 전체의 대부분 15%에 불과 (코딩+단위 테스트)
설계도 검증 수학적 분석 + 공학 코드 동료 리뷰에만 의존 (UML)

마틴 파울러의 핵심 논증: "소스 코드가 곧 설계도"

잭 리브스(Jack Reeves)의 통찰을 인용하여:

  • 소프트웨어에서 실제 '시공'에 해당하는 것은 컴파일러/링커 구동뿐 (사실상 무료)
  • 코드 작성을 포함한 모든 과정은 창의적이고 예측 불가능한 '설계' 과정
  • 따라서 전통적 공학 메타포를 소프트웨어에 적용하는 것은 근본적으로 잘못됨

예측형(Plan-driven) 방식의 문제

  • 요구사항을 사전에 완벽히 확정하고 서명받으려 함
  • 비즈니스 환경은 급변하고, 소프트웨어는 직접 써보기 전까지 가치를 알기 어려움
  • 현실과 계획이 어긋나면 프로젝트 후반부에 끔찍한 결과 초래

2. 대안: 예측(Predictive)에서 적응(Adaptive)으로

애자일의 핵심 전환

전통적 (예측형) 애자일 (적응형)
변화를 막으려 함 변화를 환영하고 기회로 활용
계획 준수가 성공 기준 비즈니스 가치 제공이 성공 기준
프로세스가 사람을 통제 프로세스가 사람의 작업을 지원
개발자 = 대체 가능한 부품 개발자 = 책임 있는 전문가
고정 범위 계약 고정 시간/예산 + 유연한 범위

"늦은 요구사항 변경은 경쟁 우위다"

변화를 문제로 보지 않고, 고객이 진정으로 필요한 것을 학습하여 빠르게 반영하는 것을 경쟁력으로 삼아야 한다.

3. 사람 중심(People-Oriented) 철학

테일러주의 vs 애자일

테일러주의 (과학적 관리법) 애자일
사람 = 대체 가능한 리소스 사람 = 대체 불가능한 전문가
관리자가 계획하고 통제 실무자에게 권한 위임
측정 기반 관리 위임형 관리

측정 기반 관리의 한계

  • 소프트웨어 개발은 복잡하고 지식 중심적인 작업
  • 잘못된 측정은 **'측정 기능 장애(Measurement Dysfunction)'**를 유발
    • 측정 지표에 맞추려고 실제 효율성을 희생하는 현상
  • 실무자에게 권한을 위임하는 것이 훨씬 효율적

개발자의 역할

  • 기술적인 결정을 스스로 내릴 권한
  • 작업 일정을 스스로 추정할 권한
  • 비즈니스 전문가와 동등한 위치에서 지속적으로 소통

4. 적응형 프로세스가 작동하기 위한 전제 조건

4-1. 반복적 개발 (Iterative Development)

  • 짧은 주기마다 통합되고 테스트를 거친 '작동하는 소프트웨어' 배포
  • 문서 검토가 아닌 실제 작동하는 시스템에서 피드백 획득
  • 요구사항과 버그에 대한 현실적이고 정직한 피드백을 지속적으로 수집

4-2. 적응형 고객 (Adaptive Customer)

  • 전통적 고정 가격/고정 범위 계약은 불안정한 환경에서 모두에게 피해
  • 시간과 예산은 고정, 시스템 범위는 유연하게 조절
  • 매 반복 주기마다 고객이 진행 상황을 점검하고 방향 수정
  • 진정한 비즈니스 파트너십 필요

4-3. 비즈니스 전문가와의 지속적 협력

  • 일회성 소통이 아닌 프로젝트 내내 긴밀한 협력
  • 신뢰할 수 있는 비즈니스 전문가와 동등한 위치에서 피드백 교환

4-4. 자발적이고 역량 있는 팀

  • 팀 스스로 애자일 방식을 원해야 함 — 강압적 도입은 근본정신에 어긋남
  • 팀원은 플러그처럼 교체 가능한 부품이 아님
  • 기술적 결정과 일정 추정 권한을 가진 전문가로 대우

4-5. 자기 적응형 프로세스 (Self-Adaptive Process)

  • 고정된 방법론을 맹목적으로 따르지 않음
  • 매 반복(Iteration) 종료 시 무엇을 잘했는지, 무엇을 개선할지 스스로 리뷰
  • 프로세스 자체를 팀에 맞게 지속적으로 수정하고 튜닝

5. 다양한 애자일 방법론 (Flavors of Agile)

2001년 '애자일 선언(Agile Manifesto)'을 통해 여러 경량 방법론들이 '애자일'이라는 우산 아래 모임.

XP (Extreme Programming)

  • 1990년대 후반 애자일 인기를 이끈 대표 방법론
  • 5가지 가치: 의사소통, 피드백, 단순성, 용기, 존중
  • 14개 원칙, 24개 실천법
  • 핵심 특징: 강력한 엔지니어링 실천법 강조
    • 테스트 주도 개발 (TDD)
    • 지속적 통합 (CI)
    • 페어 프로그래밍
    • 리팩토링

Scrum

  • 프로젝트 관리 측면에 집중
  • 30일 주기의 '스프린트(Sprint)'
  • 일일 스크럼 미팅을 통한 모니터링 및 통제
  • 종종 XP의 엔지니어링 실천법과 결합하여 사용

Crystal

  • 앨리스터 코오번(Alistair Cockburn) 개발
  • 팀 규모와 오류 치명도에 따라 다른 접근법을 취하는 프레임워크 제품군
  • '거주성(Habitability)' 중시 — 개발자가 견딜 수 있는 환경
  • 인간의 규율 수준이 낮음을 인정, XP보다 훨씬 적은 규율로 성공할 수 있는 최소한의 프로세스 지향

Lean Development

  • 도요타(Toyota)의 린 생산 방식에서 영감
  • 메리와 톰 포펜딕 부부가 주도
  • 제조업의 린 철학을 소프트웨어에 접목
  • 낭비를 줄이고 가치를 극대화하는 도구와 아이디어 도입

RUP (Rational Unified Process)

  • 유스케이스 주도적, 반복적, 아키텍처 우선
  • 정해진 단일 프로세스가 아닌 '개발 케이스'를 팀이 직접 구축
  • 무한한 변형 가능 — 폭포수부터 완전한 애자일까지
  • 단점: 너무 유연해서 어떤 것이든 "RUP"라고 부를 수 있음

6. 애자일 도입 시 주의사항

  1. 모든 곳에 적합하지는 않다 — 상황과 맥락을 고려해야 함
  2. 팀의 자발성이 가장 중요 — 원치 않는 팀에게 강요하면 근본정신에 어긋남
  3. 고객의 동의 필요 — 협력적 작업 방식에 고객도 참여해야 이점을 누림
  4. 작게 시작하라 — 규모가 작은 프로젝트부터 시작
  5. 멘토를 구하라 — 경험이 풍부한 멘토의 도움이 매우 중요
  6. 실수를 예상하라 — 도입 초기에는 많은 시행착오가 발생

핵심 한 줄 요약

"어떤 훌륭한 프로세스도 개발 팀의 역량을 대체할 수 없다. 프로세스는 사람을 통제하는 것이 아니라, 팀의 작업을 지원하는 역할을 해야 한다."

Source: Martin Fowler, "The New Methodology" (2005) NotebookLM 기반 요약 정리

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment