소프트웨어 공학 100 주제 시리즈의 63번째 글이다. (카테고리: 프로세스와 방법론)

한 줄 요약

XP 는 “짝 프로그래밍 하는 방법론” 이 아니라 가치 → 원칙 → 실천 의 세 층으로 된 체계다. 실천들은 서로의 약점을 메우도록 짜여 있어서, 몇 개만 골라 쓰면 남은 것이 무너진다. 스크럼이 일하는 틀을 준다면 XP 는 그 안에서 코드를 다루는 기술 규율을 준다.

왜 필요한가

애자일과 스크럼 글에서 본 스크럼 가이드에는 테스트, 리팩터링, 통합 같은 엔지니어링 실천이 거의 없다. 일부러 비워 둔 자리다. 그 자리를 비워 둔 채 2주 스프린트만 돌리면 이런 일이 생긴다.

  • 스프린트마다 기능은 “완료” 되는데, 테스트가 수동이라 회귀 확인이 점점 오래 걸린다.
  • 설계를 고칠 시간이 없어 코드가 굳는다. 변경 비용이 스프린트를 거듭할수록 오른다.
  • 통합을 스프린트 마지막 날에 몰아서 해서, 리뷰 데모 직전에 빌드가 깨진다.

애자일 선언의 원칙에는 “기술적 탁월성과 좋은 설계에 대한 지속적 관심이 민첩성을 높인다” 는 문장이 있다. XP 는 그 문장을 구체적인 매일의 습관으로 바꾼 방법론이다.

핵심 개념

기원

Agile Alliance 용어집은 XP 가 1990년대 중반 시작된 Chrysler 의 C3(Chrysler Comprehensive Compensation) 프로젝트에서 처음 구현됐고, Kent Beck 이 이끌었으며 Ron Jeffries 등이 합류했다고 정리한다. 그 프로젝트에 참여했던 Martin Fowler 는 ExtremeProgramming에서 “XP 로 알려지게 된 실천들의 전체 묶음이 함께 쓰인 것은 C3 가 처음” 이라고 쓴다.

공개 문헌으로는 Beck 의 Embracing Change with Extreme Programming(IEEE Computer 32(10), 1999)과 같은 해의 책 Extreme Programming Explained: Embrace Change(Addison-Wesley, 1999)가 출발점이다. 2판(Kent Beck, Cynthia Andres, 2004)은 구성이 크게 바뀌었다. Fowler 는 초기 실무자 상당수가 1판으로 배웠고 두 판 사이에 차이가 꽤 많다고 주의를 준다.

세 층 구조

Fowler 의 요약대로, Beck 은 XP 를 넓고 추상적인 가치에서 원칙을 거쳐 구체적 실천으로 내려가는 순서로 설명한다.

 가치 (왜)      의사소통 · 단순성 · 피드백 · 용기 · 존중
   │
 원칙 (다리)    가치를 상황에 맞는 판단으로 옮기는 지침
   │
 실천 (무엇)    테스트 먼저, 짝, 지속적 통합, 주간 주기 ...

이 구조가 중요한 이유는 실천은 바뀌어도 가치는 남기 때문이다. 1판과 2판 사이에 실천 목록은 크게 바뀌었지만, Agile Alliance 가 정리한 다섯 가치(의사소통, 단순성, 피드백, 용기, 존중) 중 앞의 넷은 1판부터 있었고 존중은 2판에서 명시됐다.

가치 실천에서 드러나는 모습
의사소통 함께 앉기, 짝 프로그래밍, 정보가 보이는 작업 공간
단순성 지금 필요한 만큼의 설계, 쓰지 않을 일반화를 하지 않음
피드백 테스트, 짧은 주기, 지속적 통합, 잦은 릴리스
용기 필요할 때 큰 리팩터링, 안 되는 계획을 일찍 말하기
존중 지속 가능한 속도, 팀원과 고객의 판단 존중

애자일 선언 원칙의 “단순성 — 하지 않아도 되는 일의 양을 최대화하는 기술 — 이 필수다” 는 XP 의 단순성 가치와 같은 뿌리다.

1판의 열두 실천과 2판의 주요 실천

1판 (12) 2판 주요 실천 (13)
계획 게임 이야기(Stories), 주간 주기, 분기 주기
작은 릴리스 주간 주기
메타포 (주요 실천 목록에 없음)
단순한 설계 점진적 설계(Incremental Design)
테스트 테스트 먼저 프로그래밍
리팩터링 점진적 설계에 흡수
짝 프로그래밍 짝 프로그래밍
공동 소유 (주요 실천 목록에 없음)
지속적 통합 지속적 통합, 10분 빌드
주 40시간 활기찬 작업(Energized Work)
현장 고객 전체 팀(Whole Team), 함께 앉기
코딩 표준 (주요 실천 목록에 없음)
— 정보가 보이는 작업 공간, 여유(Slack)

왼쪽 목록과 오른쪽 목록은 Agile Alliance 용어집에 정리된 것을 그대로 옮겼고, 가운데 대응은 이 글의 해석이다. 눈여겨볼 변화는 두 가지다.

  • 여유(Slack) 가 실천으로 들어왔다. 계획에 일부러 빈자리를 두어, 약속을 지킬 수 있게 하고 개선할 틈을 남긴다.
  • 10분 빌드 가 명시됐다. 지속적 통합이 실제로 돌아가려면 빌드·테스트가 짧아야 한다는 조건을 실천으로 끌어올렸다.

Ron Jeffries 의 What is Extreme Programming?은 실무자 관점의 설명이다. 예를 들어 지속 가능한 속도를 “XP 팀은 장기전을 한다. 열심히 일하되, 무기한 지속할 수 있는 속도로” 라고 쓰고, 코딩 표준은 “시스템의 모든 코드가 한 사람 — 아주 유능한 한 사람 — 이 쓴 것처럼 보이도록” 이라고 쓴다.

실천은 서로를 지탱한다

XP 실천을 하나씩 떼어 보면 위험해 보인다. “설계를 미리 하지 않는다” 는 혼돈처럼 들린다. 하지만 각 실천의 위험은 다른 실천이 덮는다.

 단순한/점진적 설계 ──의지──▶ 리팩터링 ──의지──▶ 자동 테스트
        ▲                         │                    │
        │                         ▼                    ▼
   공동 소유 ◀──의지── 짝 프로그래밍 ◀──── 코딩 표준   지속적 통합
                                                       │
                                                       ▼
                                                  10분 빌드
  • 미리 큰 설계를 하지 않아도 되는 이유는 언제든 리팩터링할 수 있기 때문이다.
  • 리팩터링을 겁 없이 할 수 있는 이유는 테스트가 회귀를 잡아 주기 때문이다.
  • 누구나 아무 코드나 고칠 수 있는(공동 소유) 이유는 짝과 코딩 표준이 지식을 퍼뜨리기 때문이다.
  • 그 변경이 서로 충돌하지 않는 이유는 지속적 통합이 하루에도 여러 번 합치기 때문이다.

그래서 “짝은 비싸니까 빼고, 테스트도 나중에 쓰고, 설계는 안 한다” 는 XP 가 아니라 그냥 무계획이다.

피드백 고리의 시간 척도

XP 의 실천을 피드백이 돌아오는 시간으로 정렬하면 구조가 보인다(이 표는 정리용 해석이다).

시간 척도 실천 돌아오는 정보
초 짝 프로그래밍 옆 사람의 질문, 오타, 설계 의문
분 테스트 먼저 방금 쓴 코드가 의도대로 동작하는가
시간 지속적 통합, 10분 빌드 내 변경이 남의 변경과 맞물리는가
주 주간 주기 이번 주 이야기가 고객 기대와 맞는가
분기 분기 주기 방향·테마가 맞는가, 병목은 어디인가

실무 적용

스크럼 팀에 XP 를 들이는 순서

모든 것을 한 번에 바꾸면 실패한다. 의존 관계의 바닥부터 들인다.

  1. 빌드 시간 측정과 단축. 10분이 목표다. 느린 통합 테스트를 분리하고 캐시를 쓴다.
  2. 새 코드는 테스트 먼저. 레거시 전체에 테스트를 붙이려 하지 말고 바꾸는 곳부터(TDD 참고).
  3. 하루 여러 번 메인에 통합. 긴 브랜치를 없앤다(트렁크 기반 개발은 SE100 #052 에서 다룬다).
  4. 리팩터링을 이야기 안에 포함. 별도 “리팩터링 스프린트” 를 만들지 않는다.
  5. 어려운 작업부터 짝·몹. 모든 작업에 짝을 강제하기보다, 설계 결정이 큰 작업부터(SE100 #038 에서 다룬다).
  6. 계획에 여유를 넣는다. 용량을 꽉 채워 약속하지 않는다.

완료 정의(Definition of Done)에 XP 를 새기기

definition_of_done:
  - 새/변경 동작은 실패하는 테스트로 먼저 표현됐다
  - main 에 통합됐고 파이프라인이 녹색이다 (목표 10분 이내)
  - 이번 변경으로 생긴 중복·냄새를 정리했다 (리팩터링)
  - 코딩 표준 검사 통과 (포매터/린터)
  - 고객(PO)이 인수 테스트 결과를 확인했다

Jeffries 가 설명하는 고객 테스트는 마지막 줄에 해당한다. 고객이 기능마다 자동화된 인수 테스트를 정의해 기능이 동작함을 보인다.

흔한 오해와 함정

  • “XP = 짝 프로그래밍.” 짝은 열두(또는 열셋) 실천 중 하나일 뿐이다. 짝만 하고 테스트·통합이 없으면 두 사람이 같이 부채를 쌓는다.
  • “설계를 하지 않는다.” XP 는 설계를 계속 한다. 미리 한 번에 하지 않을 뿐이다. 단순한 설계는 “아무렇게나” 가 아니라 “지금 요구를 만족하는 가장 단순하면서 항상 충분한” 설계다(Jeffries).
  • 실천을 골라 쓰기. 실천 간 의존 관계를 무시하고 리팩터링만 장려하면, 테스트 없는 리팩터링이 회귀 결함을 만든다.
  • 지속 가능한 속도를 복지 항목으로 본다. 피로는 결함과 나쁜 판단으로 돌아온다. 이것은 품질 실천이다.
  • 1판 기준으로만 안다. 메타포처럼 2판 주요 실천 목록에 없는 것도 있고, 여유·10분 빌드처럼 새로 명시된 실천도 있다.

확인 문제

  1. XP 의 세 층 구조를 쓰고, 왜 이 구조가 실천 목록의 변화에도 방법론의 정체성을 유지시키는지 설명하라.
  2. 2판에서 실천으로 명시된 “10분 빌드” 는 어떤 다른 실천을 가능하게 하기 위한 것인가?
  3. “미리 설계하지 않는다” 가 무계획이 되지 않으려면 어떤 실천들이 함께 있어야 하는가?
  4. 스크럼과 XP 는 경쟁 관계인가? 각자 무엇을 다루는지로 답하라.
  5. 계획에 “여유” 를 두는 것이 생산성 손실이 아닌 이유는?

풀이

  1. 가치 → 원칙 → 실천. 실천은 상황에 따라 바뀔 수 있지만 그것을 고르는 기준인 가치(의사소통, 단순성, 피드백, 용기, 존중)는 유지되기 때문이다.
  2. 지속적 통합. 빌드·테스트가 길면 하루 여러 번 통합하는 것이 비현실적이 되어, 통합 주기가 길어지고 충돌이 커진다.
  3. 리팩터링(설계를 계속 개선), 자동 테스트(리팩터링의 안전망), 지속적 통합(변경을 자주 합침). 공동 소유와 코딩 표준도 누가 고치든 일관성을 유지하게 돕는다.
  4. 보완 관계다. 스크럼은 역할·이벤트·산출물이라는 작업 틀을, XP 는 테스트·리팩터링·통합 같은 엔지니어링 실천을 다룬다.
  5. 여유가 있어야 추정 오차를 흡수해 약속을 지킬 수 있고, 리팩터링·도구 개선 같은 개선 작업을 할 틈이 생긴다. 꽉 찬 계획은 작은 변동에도 일정을 깨고, 개선을 영원히 미룬다.

더 읽을거리 (References)