익스트림 프로그래밍
익스트림 프로그래밍(eXtreme Programming, 이하 XP)은 소프트웨어 품질 개선과 변화하는 고객 요구사항에 대한 적응력을 극대화하기 위해 고안된 애자일(Agile) 소프트웨어 개발 방법론이다. 1990년대 후반 미국 소프트웨어 엔지니어 켄트 벡(Kent Beck)이 크라이슬러 종합 보상 시스템(Chrysler Comprehensive Compensation System) 프로젝트를 수행하며 창안했다.
XP는 기존 개발 방법론에서 입증된 모범 사례(Best Practices)들을 극한(Extreme)의 수준까지 끌어올려 적용한다는 철학을 바탕으로 한다. 개발 과정에서 의사소통(Communication), 단순성(Simplicity), 피드백(Feedback), 용기(Courage), 그리고 존중(Respect)이라는 5가지 핵심 가치를 지향한다.
이를 실현하기 위해 XP는 기술적인 실천 방안(Practices)을 엄격하게 적용할 것을 요구한다. 대표적인 실천 방안으로는 앞서 설명한 테스트 주도 개발(TDD), 두 명의 개발자가 하나의 워크스테이션에서 함께 코드를 작성하는 짝 프로그래밍(Pair Programming), 코드를 원격 저장소에 지속적으로 병합하는 지속적 통합(Continuous Integration, CI), 잦은 소규모 배포(Small Releases), 그리고 시스템에 대한 구조적 이해를 공유하는 코드 공동 소유(Collective Code Ownership) 등이 있다.
대중적으로 널리 쓰이는 또 다른 애자일 프레임워크인 스크럼(Scrum)과 XP의 구조적 차이점 비교는 다음과 같다.
| 비교 항목 | 익스트림 프로그래밍 (XP) | 스크럼 (Scrum) |
|---|---|---|
| 주요 목적 및 초점 | 엔지니어링 실천 방법 (코딩 기술 및 소프트웨어 내부 품질 향상) | 프로젝트 관리 및 개발 프로세스 통제 |
| 반복 주기 (Iteration) | 1~2주 (매우 짧고 잦은 배포) | 2~4주 (스프린트 단위 진행) |
| 작업 중 요구사항 변경 | 반복 주기 진행 중에도 요구사항 우선순위 변경 및 교체 허용 | 스프린트가 시작되면 해당 기간 내 목표 및 요구사항 변경 불가 |
| 팀 구성 및 구조 | 상주 고객(On-site Customer)의 직접적인 참여, 개발자 간 교차 작업 강조 | 프로덕트 오너(PO), 스크럼 마스터, 개발 팀으로 역할 명확화 |
| 엔지니어링 기법 강제성 | TDD, 짝 프로그래밍, CI 등 특정 소프트웨어 엔지니어링 기법 적용 명문화 | 특정 엔지니어링 기법을 강요하지 않음 (팀 자율성 보장) |
XP는 엄격한 엔지니어링 규율을 요구하므로 초기 도입 시 개발 팀의 높은 숙련도와 적응 비용을 필요로 하지만, 빈번하게 요구사항이 변경되는 불안정한 비즈니스 환경에서 소프트웨어의 구조적 결함을 최소화하는 데 효과적이다. 현재 산업계에서는 XP의 엔지니어링 기법(TDD, CI 등)을 스크럼의 관리 프레임워크와 결합하여 사용하는 하이브리드 형태가 표준으로 자리 잡았다.
출처(Sources):
- Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley Professional.
- Martin, R. C. (2002). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall.
- Kniberg, H. (2007). Scrum and XP from the Trenches. InfoQ.