eXtreme Programming

eXtreme Programming — 보통 그냥 XP — 은 애자일 가족 중 가장 까다로운 구성원입니다. East Agile Tracker는 XP를 우선으로 만들어졌습니다. 그 외의 모든 것은 거기서 따라 나옵니다.

이 페이지는 XP가 무엇인지, 왜 작동하는지, 그리고 트래커를 계획 표면으로 삼아 어떻게 실천하는지를 다룹니다.

XP란

XP는 1990년대 후반 Kent Beck에 의해 만들어졌습니다. 첫 책 — Extreme Programming Explained: Embrace Change — 은 1999년에 출간되었습니다. 많은 것들이 그렇듯, 그것은 Chrysler에서 급여 시스템을 출시하려 애쓰던 좌절한 팀에서 시작되었습니다.

XP의 베팅은 소프트웨어의 불확실성을 다루는 올바른 방법이 작동하는 것들을 하고, 그것들을 더 자주 하는 것이라는 것입니다. 테스트? 항상 테스트하세요. 통합? 매시간 통합하세요. 대화? 끊임없이 대화하세요. 계획? 모든 이터레이션을 계획하고, 배우면서 다시 계획하세요.

“XP는 모호하거나 빠르게 변하는 요구 사항에 직면해 소프트웨어를 개발하는 소규모에서 중규모 팀을 위한 경량 방법론이다.” — Kent Beck

다섯 가지 가치

XP는 다른 모든 것이 매달려 있는 다섯 가지 가치를 명명합니다:

의사소통(Communication) — 팀은 대화합니다. 매일. 작업, 설계, 장애물에 대해. 가능하면 얼굴을 맞대고. 사일로는 적입니다.
단순성(Simplicity) — 작동할 수 있는 가장 단순한 것을 하세요. 실제로 필요하다면 나중에 복잡성을 더할 수 있습니다. 아마 필요하지 않을 것입니다.
피드백(Feedback) — 코드(테스트)로부터, 팀(페어 프로그래밍, 리뷰)으로부터, 사용자(빈번한 릴리스)로부터. 빠르게 얻으세요.
용기(Courage) — 진척, 추정, 설계에 대해 진실을 말하세요. 작동하지 않는 코드는 버리세요. 발목 잡는 것은 리팩터하세요.
존중(Respect) — 팀의 모든 사람 — 그리고 이제는 팀의 모든 에이전트 — 이 가치를 기여합니다. 그에 맞게 서로를 대하세요.

실천법

XP는 네 영역으로 정리된 열두 가지 원조 실천법으로 유명합니다:

계획

Planning Game — 팀과 고객이 함께 계획합니다: 무엇이 다음에 올지, 어떤 순서로, 각 조각은 얼마나 큰지.
Small Releases — 자주 출시하세요. 몇 달이 아니라 며칠. 구체적인 무언가에 대한 피드백을 얻으세요.
User Stories — 요구 사항은 대화이며, 사용자 관점에서 짧은 스토리로 포착됩니다. “사용자로서, 나는 Y를 위해 X를 원한다.”

설계

Simple Design — 테스트를 통과하고 필요한 모든 개념을 표현하는 가장 단순한 설계. 그 이상은 안 됩니다.
Refactoring — 이미 작동하는 코드의 설계를 개선하세요. 끊임없이.
System Metaphor — 설계 결정을 일관되게 만드는 데 사용되는, 시스템이 어떻게 작동하는지에 대한 공유된 이야기.

코딩

Pair Programming — 두 명의 개발자, 한 대의 키보드. 한 명은 운전하고, 한 명은 길을 안내합니다. 자주 바꾸세요.
Collective Code Ownership — 누구든 어떤 코드든 개선할 수 있습니다. 영지(領地)는 없습니다.
Continuous Integration — 하루에 여러 번 코드를 통합하고 테스트하세요. 깨짐을 즉시 잡으세요.
Coding Standards — 코드가 한 사람이 쓴 것처럼 읽히도록 합의된 스타일.

테스트

Test-Driven Development (TDD) — 실패하는 테스트를 먼저 작성한 다음, 그것을 통과시키는 코드를 작성하세요.
Acceptance Tests — 고객이 각 스토리에 대해 “done”이 무엇을 의미하는지를 코드나 실행 가능한 형식으로 정의합니다.

XP가 왜 작동하는가

XP는 불편합니다. 페어 프로그래밍은 여러분이 소리 내어 생각하도록 강제합니다. TDD는 코드를 작성하기 전에 성공이 어떤 모습인지 알도록 강제합니다. 지속적 통합은 여러분이 좋아하는 오래 사는 브랜치를 죽입니다. 작은 릴리스는 6개월 로드맵 뒤에 숨을 수 없음을 의미합니다.

이것이 작동하는 이유는 이 모든 것이 피드백 루프를 단축하기 때문입니다. 틀렸다는 것을 더 빨리 알아낼수록, 교정은 더 저렴합니다. XP는 근본적으로 피드백 루프를 가능한 한 빡빡하게 만드는 것에 관한 것입니다.

그것은 또한 용기와 존중에 관한 것입니다. 여러분은 소리 내어 틀릴 만큼 서로를 신뢰하는 팀에서만 XP를 할 수 있습니다.

규율 있는 스토리 모델

East Agile Tracker는 특정한 계획 이론을 인코딩합니다. 이 섹션을 데이터 모델이 왜 지금의 모습인지에 대한 운영 설명서로, 그리고 실천에서 무엇을 하고(하지 말아야 할지) 위한 현장 가이드로 다루세요.

네 가지 스토리 유형이 왜 중요한가

모든 것이 스토리이지만, 네 종류가 있으며 그 구분이 바로 핵심입니다:

Features는 포인트를 가지며 속도를 향해 “셈해지는” 유일한 것입니다. 이것이 작업을 사용자가 관찰 가능한 가치로 쪼개도록 강제합니다.
Bugs는 포인트가 없습니다(0). 결함은 점수를 얻지 못하므로, 재작업 비용을 보상하는 대신 가시화합니다.
Chores도 포인트가 없습니다 — 직접적인 사용자 가치가 없는 필요한 작업(인프라, 리팩터, 설정). 그것들을 0으로 유지하면 가치 프레이밍이 정직하게 유지되도록 팀이 가능한 한 그것들을 기능에 묶어 넣도록 압박합니다.
Releases는 마일스톤을 고정하고 도구가 날짜를 예측하게 하는 포인트 0 마커입니다.

중요한 것은 행동적 효과입니다: 버그와 잡무가 점수를 받지 못하면, 팀은 자연스럽게 작업을 사용자 지향적 기능으로 표현하도록 밀어붙이게 되고, 결함 비용을 예민하게 인식하게 됩니다. 그것은 데이터 모델에 인코딩된 계획 규율입니다.

단일 정렬된 백로그

세 영역, 하나의 규칙.

Icebox는 우선순위가 정해지지 않은 아이디어 풀입니다.
Backlog는 엄격하게 정렬된 단일 우선순위 목록입니다 — 동률 없음, “P1/P1/P1” 없음.
Current 영역은 활성 이터레이션을 담습니다.

제품 책임자가 위에서 아래까지 순서를 소유하며, 불변식은 백로그의 맨 위가 항상 가장 중요하고 가장 잘 명세되어 있다는 것입니다. 아래로 내려갈수록 명확성이 정당하게 감소합니다. 상단 근처의 스토리가 모호한 수락 기준을 가지고 있다면 그것은 계획 버그입니다. Icebox는 무덤이 되어도 괜찮습니다. Backlog는 안 됩니다.

속도 기반 자동 계획

이것은 대부분의 팀이 다른 곳에서 형편없이 다시 구현하는 부분입니다. 트래커 방식의 계획은 최근 수락된 포인트에서 이동 평균 속도를 계산하고, 그만큼의 포인트의 스토리를 다음 이터레이션으로 자동으로 끌어옵니다 — 여러분이 수동으로 스프린트에 “약속”하는 것이 아니라 경험적 데이터가 대신 해 줍니다. 보존할 가치가 있는 두 가지 결과:

여러분은 시간이 아니라 상대 포인트(Fibonacci 1/2/3/5/8 또는 우리의 더 빡빡한 0/1/2/3)를 사용해 기능만 추정합니다. 추정은 약속이 아니라 크기를 정하는 대화입니다.
여러분은 속도를 조작하지 않습니다. “빨라 보이려고” 포인트를 부풀리거나 잡무를 포인트화하면, 전체 시스템을 정직하게 만드는 예측이 깨집니다. 속도는 측정 도구이며, 여러분은 자신의 도구를 조작하지 않습니다.

보상은 릴리스 날짜 예측이 협상이 아니라 계산이 되고, 이해관계자와의 대화가 “금요일까지 X를 약속할 수 있나요”에서 “현재 속도라면 이 릴리스는 대략 날짜 Y에 도착합니다 — 여기 범위/날짜 트레이드오프가 있습니다”로 바뀌는 것입니다.

스토리 라이프사이클과 수락 루프

상태 기계는 Start → Finish → Deliver → Accept / Reject입니다. 핵심 상태는 Deliver입니다: 엔지니어가 스토리를 delivered로 표시하지만, 제품 책임자가 수락 기준에 비추어 명시적으로 수락할 때까지 — 또는 거부하여 되돌려 보낼 때까지 — 완료된 것이 아닙니다. 이것은 수락을 스프린트 종료 시연으로 미루는 대신 모든 단일 스토리에 고객 피드백 루프를 새겨 넣습니다.

수락 기준은 스토리가 시작되기 전에, 이상적으로는 수락 테스트에 직접 매핑되도록 Given/When/Then 형식으로 스토리에 속해야 합니다. INVEST는 스토리가 잘 구성되었는지에 대한 점검 기준입니다:

Independent — 다른 스토리 없이 릴리스할 수 있음.
Negotiable — 동결된 명세가 아니라 의도를 포착함.
Valuable — 사용자나 이해관계자에게.
Estimable — 팀이 크기를 정할 수 있음.
Small — 이터레이션에 편안하게 들어맞음.
Testable — 실행할 수 있는 수락 기준을 가짐.

케이던스

계획 의식은 가볍고 정기적입니다:

새 스토리를 포인트화하고 백로그 상단의 수락 기준을 확정하는 주간 Iteration Planning Meeting.
흐름과 블로커에 초점을 맞춘 짧은 daily standup.
프로세스를 조정하는 이터레이션별 retrospective.

이터레이션은 보통 1주나 2주입니다 — 잘못된 추정을 발견하는 것이 저렴할 만큼 짧습니다.

계획이 작동하게 만드는 엔지니어링 실천법

트래커 방식의 계획은 XP의 가시적인 절반입니다. 그것은 엔지니어링 절반 없이는 무너집니다.

Test-first / TDD와 진짜 수락 테스트 스위트가 “delivered”가 무언가를 의미하게 만드는 것입니다.
지속적 통합과 작고 빈번한 릴리스가 사이클 타임을 짧게 유지하여 속도가 들쭉날쭉하지 않고 안정되게 합니다.
페어 프로그래밍(또는 강한 리뷰)이 진행 중인 작업을 낮게 유지합니다 — 시작하기 전에 끝내라 — 이는 사이클 타임에 대한 가장 큰 단일 지렛대입니다.
가용한 제품 책임자가 수락/거부 루프가 멈추지 않게 유지하는 것입니다.

주의할 안티패턴

반복되는 실패:

Backlog를 진짜 우선순위 순서가 아니라 주차장으로 취급하기.
속도를 더 좋아 보이게 만들려고 버그와 잡무를 추정하기.
이터레이션 안에 끝낼 수 없는 거대한 스토리를 가지고 가기. 각각이 독립적으로 전달 가능해질 때까지 쪼개세요.
아무도 수락하지 않아 스토리가 Delivered에 쌓이게 두기.

이 중 어느 것이든 경험적 시스템을 조용히 희망적 계획으로 되돌립니다. 트래커는 여러분이 그것들을 하는 것을 막을 수 없습니다. 다만 그것들을 가시화할 수 있을 뿐입니다. 모든 이터레이션 끝에 Delivered 열을 보세요 — 늘어나고 있다면, 그것이 여러분의 신호입니다.

XP with East Agile Tracker

트래커는 XP 팀이 Pivotal Tracker 시절부터 원해 온 계획 표면입니다. 모든 개념이 직접 매핑됩니다:

User Stories → Stories

XP 사용자 스토리는 East Agile Tracker 스토리입니다. Feature 유형으로 작성하세요. 대화에는 설명을 사용하고, 진행 중인 논의에는 댓글을 사용하세요. 수락 기준은 설명에 속합니다.

Planning Game → The board

XP의 Planning Game은 우선순위와 크기에 대한 비즈니스와 팀 사이의 대화입니다. East Agile Tracker에서:

제품 담당자가 Backlog에 스토리를 작성하고 우선순위로 정렬합니다.
팀이 기능을 포인트로 추정합니다(Fibonacci 또는 East Agile 척도).
시스템이 속도로부터 이터레이션을 자동 계획합니다.
팀이 Current 열의 맨 위에서 스토리를 시작합니다.

그것이 전부입니다. “게임”은 대화 속에 있고, 트래커는 단지 점수를 기록합니다.

Small Releases → Releases (the story type)

XP는 자주 릴리스하라고 말합니다. Release는 East Agile Tracker의 네 가지 스토리 유형 중 하나입니다. 모든 출시 마일스톤마다 릴리스를 만드세요. 출시하는 이터레이션으로 드래그하세요. 릴리스는 Started/Finished/Delivered를 건너뛰고 출시할 때 곧장 Accepted로 갑니다.

Continuous Integration → Story state machine

상태 기계 자체는 CI가 아닙니다 — 그것은 여러분의 빌드 시스템입니다 — 하지만 Finished → Delivered → Accepted 경로는 XP가 설명하는 고객 수락 루프를 반영합니다. 작업을 끝내고, 고객에게 전달하고, 작동이 확인되면 수락하세요.

Velocity → “Yesterday’s weather”

XP는 그것을 어제의 날씨라 부릅니다: 지난 이터레이션에 얼마나 끝냈는지가 이번에 얼마나 끝낼지에 대한 최고의 예측입니다. East Agile Tracker는 속도를 자동으로 계산하고 — 최근 이터레이션의 평균, 설정 가능한 전략 — 다음 이터레이션의 용량을 자동 계획하는 데 사용합니다.

Acceptance Tests → Reviews

트래커의 스토리 리뷰는 수락에 매핑됩니다. 리뷰어(고객, 제품 책임자, 또는 그 역할을 하는 에이전트조차)를 배정하세요. 그들이 승인하거나 거부합니다. 거부는 스토리를 Started로 되돌립니다.

Pair Programming → Co-ownership

XP 팀은 코드를 페어로 작업합니다. 트래커에서 이는 스토리의 여러 소유자로 나타납니다. 두 페어를 모두 스토리에 배정하세요. 두 이름 모두 카드에 나타납니다.

XP with agents — the new practice

XP는 AI 에이전트가 소프트웨어에 의미 있게 기여할 수 있게 되기 전에 작성되었습니다. 우리는 이것이 25년 만에 XP에 대한 가장 중요한 업데이트라고 생각합니다.

우리의 실천에서 — 그리고 트래커가 만들어진 목적에서 — 에이전트는 이름을 가진 XP 팀원입니다. 자신의 역할, 자신의 페어 파트너(사람 또는 에이전트), 자신의 감사 추적을 가집니다. 그것은 계획 표면 안에서 사람 팀원이 할 수 있는 모든 것을 할 수 있습니다: 추정, 스토리 소유, 댓글, 전환, 리뷰 수락.

XP 가치는 여전히 유효합니다. 의사소통: 에이전트는 이벤트 스트림을 읽고 댓글을 게시하여 소통합니다. 단순성: 에이전트는 여러분이 부여한 역할로 제약됩니다. 피드백: 모든 에이전트 행동은 감사 로그에 있어 즉시 검토 가능합니다. 용기: 여러분의 에이전트가 무엇을 옳게 했고 무엇을 못 했는지에 대해 정직하세요. 존중: 에이전트 동료는 가치를 기여합니다 — 그것을 인정하세요.

우리는 에이전트를 트래커 안에 넣어 코딩을 시키지 않습니다. 우리는 계획 표면을 함께 일하는 사람 과 에이전트에게 줍니다. 코딩 에이전트는 여러분이 가져오세요 — Claude Code, Codex, 여러분 자신의 것 — 그리고 API를 통해 트래커에 연결하세요. 에이전트가 스토리를 집어 들고, 작업을 하고, 댓글을 달고, 전환합니다. 여러분은 흔적을 검토하고 수락합니다.

이것이 *포용적 애자일 계획(Inclusive Agile Planning)*입니다. 그것은 실제로 가진 팀과 함께하는 XP입니다.

더 읽을거리

Extreme Programming Explained — Kent Beck의 기초 저서, 1999.
애자일 선언 — 가족이 시작된 곳.
애자일 개발 — 더 넓은 그림.
사용 안내 — 트래커에 대한 실용 가이드.
API 가이드 — 여러분의 코딩 에이전트 연결하기.