맨위로가기

익스트림 프로그래밍

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

익스트림 프로그래밍(XP)은 소프트웨어 개발 방법론으로, 켄트 백이 개발했다. 이 방법론은 의사소통, 단순성, 피드백, 용기, 존중을 핵심 가치로 삼고, 코딩, 테스트, 경청, 설계를 기본 활동으로 한다. XP는 반복적인 개발, 고객과의 소통, 테스트 주도 개발, 단순한 설계를 통해 소프트웨어 개발의 효율성을 높이는 것을 목표로 한다. 주요 실천 방법으로는 페어 프로그래밍, 계획 게임, 지속적 통합, 리팩토링 등이 있다. XP는 유연성을 강조하며, 현장 고객의 요구에 따라 프로세스를 조정할 수 있다는 장점이 있지만, 요구 사항의 불확실성, 설계 문서 부족, 그리고 팀 구성 방식에 대한 비판도 존재한다.

더 읽어볼만한 페이지

  • 익스트림 프로그래밍 - 워드 커닝햄
    워드 커닝햄은 미국의 컴퓨터 프로그래머로, 최초의 위키 사이트 WikiWikiWeb을 만들고 기술 부채 개념을 창안했으며, 소프트웨어 개발 방법론 발전에 기여했다.
  • 익스트림 프로그래밍 - JUnit
    JUnit은 자바 환경에서 단위 테스트를 위한 프레임워크로, 반복적인 테스트 실행을 통해 버그 수정에 용이하며, 어노테이션 기반의 간편한 테스트 코드 작성과 IDE 통합을 지원하여 개발 효율성을 높인다.
  • 소프트웨어 개발 철학 - 애자일 소프트웨어 개발
    애자일 소프트웨어 개발은 1990년대에 등장하여 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대한 대응을 핵심 가치로 삼고 적응형 계획과 반복적 실행을 통해 시장 출시 속도와 위험 완화를 추구하는 소프트웨어 개발 방법론이다.
  • 소프트웨어 개발 철학 - 유닉스 철학
    유닉스 철학은 단순성, 모듈성, 재사용성을 중시하며, 한 가지 일을 잘하는 프로그램, 협력적인 프로그램, 텍스트 스트림 처리 프로그램을 지향하는 소프트웨어 설계 원칙으로, 현대 운영체제 및 소프트웨어 설계에 영향을 주지만 비판도 존재한다.
익스트림 프로그래밍
개요
정의익스트림 프로그래밍(eXtreme Programming, XP)은 소프트웨어 개발 방법론 중 하나이다.
특징단순성
의사소통
피드백
용기
존중
역사
창시자켄트 백
시초크라이슬러의 C3 프로젝트
C3 프로젝트1990년대 후반 급여 지불 시스템 개발 프로젝트로, 취소되었지만 익스트림 프로그래밍의 기반이 됨
XP의 가치
핵심 가치의사소통
단순성
피드백
용기
존중
XP의 원리
피드백 원리짝 프로그래밍
계획 게임
테스트 주도 개발
전체 팀
지속적인 통합
가정 원리메타포
간단한 디자인
리팩토링
자기 주도 원리40시간 근무
고객 상주
코딩 표준
XP의 실천 방법
계획계획 게임
설계간단한 설계
메타포
리팩토링
코딩짝 프로그래밍
테스트 주도 개발
지속적인 통합
코딩 표준
집단 코드 소유
테스트단위 테스트
릴리즈작은 릴리즈
같이 보기
관련 주제애자일 소프트웨어 개발
스크럼
린 소프트웨어 개발
칸반
참고 문헌
서적익스트림 프로그래밍 도입(원제: Extreme Programming Explained: Embrace Change) - 켄트 백 저

2. 역사

워드 커닝햄은 XP에 큰 영향을 미쳤다.[6] XP는 1990년대 후반부터 2000년대 초반까지 소프트웨어 커뮤니티에서 큰 관심을 받았고, 그 기원과는 매우 다른 환경에서도 채택되었다.

XP의 배경, 원리, 실천에 대한 정보는 커닝햄의 위키위키웹(최초의 위키)에서의 토론을 통해 더 넓은 세상에 퍼졌다. 다양한 사람들이 아이디어를 확장했으며, 애자일 소프트웨어 개발을 비롯한 몇 가지 파생 방법론이 생겨났다. 또한, 1999년경부터 XP 웹사이트(http://www.extremeprogramming.org)의 하이퍼텍스트 시스템 맵을 사용하여 XP 개념이 수년 동안 설명되었다.

하지만, 원래 XP에서 요구했던 높은 수준의 규율은 종종 약화되었다. 이 때문에 너무 엄격하다고 여겨졌던 실천 사항 중 일부는 각 사이트에서 권장되지 않거나, 축소되거나, 미완성인 채로 남겨지기도 했다. 예를 들어, 특정 프로젝트에서 매일 통합 테스트를 실시하는 대신, 주간 일정으로 변경하거나, 상호 합의된 날짜에 테스트를 진행하는 것으로 축소될 수 있었다.

한편, 다른 애자일 개발 방법론도 정체되지 않았으며, XP는 현장 경험에서 더 많은 교훈을 얻고 다른 방법론을 활용하면서 계속 발전하고 있다. 켄트 백은 초판 발행 5년 후인 2004년 11월에 출판된 ''익스트림 프로그래밍 설명''의 두 번째 판에서 더 많은 가치와 실천 사항을 추가하고, 주된 방법론과 부수적인 방법론을 구분했다.

Thoughtworks는 60명 규모의 분산된 XP 프로젝트에서 상당한 성공을 거두었다고 주장했다.

2004년에는 XP의 발전된 형태인 산업적 익스트림 프로그래밍(IXP)[14]가 소개되었다. IXP는 대규모 분산 팀에서 작업할 수 있는 능력을 제공하기 위한 것으로, 23가지 실천 방법과 유연한 가치를 가지고 있다.

2. 1. 기원

켄트 백은 크라이슬러 종합 보상 시스템(C3) 급여 프로젝트에서 일하면서 익스트림 프로그래밍을 개발했다.[5] 1996년 3월, 백은 C3 프로젝트 리더가 되어 프로젝트에 사용된 개발 방법론을 개선하기 시작했고, 이 방법론에 대한 책(''익스트림 프로그래밍 설명'', 1999년 10월 출판)을 썼다.[5] 다임러-벤츠가 회사를 인수한 후 크라이슬러는 7년 만인 2000년 2월 C3 프로젝트를 취소했다.[6]

익스트림 프로그래밍의 많은 관행은 이전부터 존재해 왔으며, 이 방법론은 "모범 사례"를 극단적인 수준으로 끌어올린 것이다. 예를 들어, "각 마이크로 증분 전에 테스트를 계획하고 작성하는 테스트 우선 개발 관행"은 1960년대 초 NASA의 머큐리 계획에서 이미 사용되었다. 총 개발 시간을 단축하기 위해, 일부 공식 테스트 문서(예: 인수 테스트)는 소프트웨어가 테스트를 위해 준비되기 직전 또는 그와 동시에 개발되었다. NASA의 독립적인 테스트 그룹은 프로그래머가 소프트웨어를 작성하고 하드웨어와 통합하기 전에 공식 요구 사항과 논리적 한계를 기반으로 테스트 절차를 작성할 수 있었다. XP는 이 개념을 극단적인 수준으로 끌어올려, 더 큰 기능만 테스트하는 것이 아니라 소프트웨어 코딩의 작은 부분의 작동을 검증하는 자동화된 테스트(때로는 소프트웨어 모듈 내부)를 작성한다.

1990년대 소프트웨어 개발에 영향을 미친 두 가지 주요 요인은 다음과 같다.

  • 내부적으로는, 일부 개발자들 사이에서 객체 지향 프로그래밍이 절차적 프로그래밍을 대체하며 선호되는 프로그래밍 패러다임으로 자리 잡았다.
  • 외부적으로는, 인터넷의 부상과 닷컴 버블이 시장 출시 속도와 기업 성장을 경쟁력 있는 비즈니스 요소로 강조했다.


빠르게 변화하는 요구 사항은 더 짧은 제품 수명 주기를 요구했으며, 이는 종종 전통적인 소프트웨어 개발 방법과 충돌했다.

크라이슬러 종합 보상 시스템(C3)은 크라이슬러의 급여 시스템을 연구 대상으로 삼고, 언어는 스몰토크, 데이터 액세스 레이어는 젬스톤을 사용하여 객체 기술을 최적으로 사용하는 방법을 결정하기 위해 시작되었다. 크라이슬러는 스몰토크 전문가인 켄트 백을 영입하여 시스템의 성능 튜닝을 수행했지만, 그는 개발 프로세스에 몇 가지 문제점을 발견하고 역할이 확대되었다. 그는 이 기회를 이용하여 그의 오랜 협력자인 워드 커닝햄과의 작업을 바탕으로 개발 관행에 대한 몇 가지 변경 사항을 제안하고 구현했다. 백은 이 방법론의 초기 개념을 다음과 같이 설명한다.

> 처음 팀 리더를 맡았을 때, 테스트나 리뷰 등, 제가 합리적이라고 생각하는 것들을 조금만 해달라고 부탁했습니다. 두 번째는 훨씬 더 많은 것을 부탁했습니다. 저는 "지뢰는 신경 쓰지 말자, 적어도 이건 좋은 시스템이 될 거야"라고 생각했고, [그리고] 팀에게 제가 필수적이라고 생각하는 모든 부분을 10으로 올리고 나머지는 모두 생략해 달라고 요청했습니다.

백은 론 제프리스를 프로젝트에 초대하여 이러한 방법론을 개발하고 개선하는 데 도움을 주었다. 이후 제프리스는 C3 팀에서 이러한 관행이 습관이 되도록 코치 역할을 했다.

XP 뒤에 숨겨진 원칙과 관행에 대한 정보는 커닝햄의 WikiWikiWeb인 원래 위키에서의 토론을 통해 더 넓은 세상에 전파되었다. 다양한 기여자들이 아이디어를 논의하고 확장했으며, 몇 가지 파생 방법론이 생겨났다 (애자일 소프트웨어 개발 참조). 또한, XP 개념은 1999년경부터 XP 웹사이트(http://www.extremeprogramming.org)의 하이퍼텍스트 시스템 맵을 사용하여 수년 동안 설명되어 왔다.

백은 자신의 저서인 ''익스트림 프로그래밍 엑스플레인드'' (1999)를 시작으로 XP에 관한 일련의 책을 편집하여 그의 아이디어를 훨씬 더 많은 청중에게 전파했다. 이 시리즈의 저자들은 XP와 그 관행에 참여하는 다양한 측면을 다루었다. 이 시리즈에는 관행을 비판하는 책도 포함되었다.

2. 2. 현황

켄트 백은 크라이슬러 종합 보상 시스템(C3) 급여 프로젝트에서 일하면서 익스트림 프로그래밍(XP)을 개발했다.[5] 1996년 3월, 켄트 백은 C3 프로젝트 리더가 되었고, 프로젝트에 사용된 개발 방법론을 개선하기 시작했다. 그는 이 방법론에 대한 책(''익스트림 프로그래밍 설명'', 1999년 10월 출판)을 썼다.[5] 크라이슬러는 7년 후인 2000년 2월, 다임러-벤츠가 회사를 인수하면서 C3 프로젝트를 취소했다.[6]

많은 익스트림 프로그래밍 관행은 이전부터 존재해 왔다. 이 방법론은 "베스트 프랙티스"를 극단적인 수준으로 끌어올렸다. 예를 들어, "테스트 주도 개발, 각 마이크로 인크리먼트 전에 테스트를 계획하고 작성하는" 관행은 1960년대 초 NASA의 머큐리 계획에서 이미 사용되었다. 총 개발 시간을 단축하기 위해 일부 공식 테스트 문서 (인수 테스트 등)는 소프트웨어 테스트 준비와 병행하여 (또는 약간 앞서서) 개발되었다. NASA의 독립 테스트 그룹은 프로그래머가 소프트웨어를 작성하고 하드웨어와 통합하기 전에 공식 요구 사항과 논리적 한계를 기반으로 테스트 절차를 작성할 수 있었다. XP는 이 개념을 극단적인 수준으로 끌어올려, 큰 기능만 테스트하는 것이 아니라 소프트웨어 코딩의 작은 부분에서도 동작을 검증하는 자동화된 테스트 (때로는 소프트웨어 모듈 내부)를 작성한다.

1990년대 소프트웨어 개발에 영향을 미친 두 가지 주요 요인은 다음과 같다.

  • 내부적으로는 일부 개발자들 사이에서 객체 지향 프로그래밍이 절차적 프로그래밍을 대체하며 선호되는 프로그래밍 패러다임으로 자리 잡았다.
  • 외부적으로는 인터넷의 부상과 닷컴 버블이 시장 출시 속도와 기업 성장을 경쟁력 있는 비즈니스 요소로 강조했다.


빠르게 변화하는 요구 사항은 제품 수명 주기 단축을 요구했으며, 이는 종종 전통적인 소프트웨어 개발 방법과 충돌했다.

크라이슬러 종합 보상 시스템(C3)은 크라이슬러의 급여 시스템을 연구 대상으로 삼고, 언어는 스몰토크, Data access layer|데이터 접근 계층영어은 젬스톤을 사용하여 객체 기술을 최적으로 사용하는 방법을 결정하기 위해 시작되었다. 크라이슬러는 스몰토크 전문가인 켄트 백을 영입하여 시스템의 Performance tuning|성능 튜닝영어을 수행했지만,[24] 개발 프로세스에 몇 가지 문제점을 발견하고 역할이 확대되었다. 그는 이 기회를 이용하여 그의 오랜 협력자인 워드 커닝햄과의 작업을 바탕으로 개발 관행에 대한 몇 가지 변경 사항을 제안하고 구현했다. 켄트 백은 방법론의 초기 개념을 다음과 같이 설명했다.[26]

켄트 백은 Ron Jeffries|론 제프리스영어를 프로젝트에 초대하여 이러한 방법론을 개발하고 개선하는 데 도움을 주었다. 이후 제프리스는 C3 팀에서 이러한 관행이 습관이 되도록 코치 역할을 했다.

XP 뒤에 숨겨진 원칙과 관행에 대한 정보는 커닝햄의 WikiWikiWeb인 원래 위키에서의 토론을 통해 더 넓은 세상에 전파되었다. 다양한 기여자들이 아이디어를 논의하고 확장했으며, 몇 가지 파생 방법론이 생겨났다 (애자일 소프트웨어 개발 참조). 또한, XP 개념은 1999년경부터 XP 웹사이트(http://www.extremeprogramming.org)의 하이퍼텍스트 시스템 맵을 사용하여 수년 동안 설명되어 왔다.

켄트 백은 자신의 저서인 ''익스트림 프로그래밍 엑스플레인드'' (1999)를 시작으로 XP에 관한 일련의 책을 편집하여 그의 아이디어를 훨씬 더 많은 청중에게 전파했다. 이 시리즈의 저자들은 XP와 그 관행에 참여하는 다양한 측면을 다루었다. 이 시리즈에는 관행을 비판하는 책도 포함되었다.

XP는 1990년대 후반과 2000년대 초반 소프트웨어 커뮤니티에서 상당한 관심을 받았으며, 그 기원과는 근본적으로 다른 여러 환경에서 채택되었다.

원래의 방법론에서 요구되는 높은 수준의 규율은 종종 사라졌고, 이로 인해 너무 엄격하다고 여겨지는 일부 방법론은 개별 사이트에서 폐지되거나 축소되거나 심지어 미완료 상태로 남게 되었다. 예를 들어, 특정 프로젝트에 대한 통합 테스트를 매일 하는 관행은 주간 일정으로 변경되거나, 단순히 상호 합의된 날짜에 테스트하는 것으로 축소될 수 있었다. 이처럼 더 유연한 일정은 사람들이 매일 테스트를 통과하기 위해 인위적인 스텁을 생성하느라 서두르는 것을 피할 수 있게 해주었다. 덜 엄격한 일정은 대신 복잡한 기능을 며칠에 걸쳐 개발할 수 있게 해준다.

한편, 다른 애자일 개발 방법론도 정체되지 않았으며, XP는 현장의 경험에서 더 많은 교훈을 얻고 다른 방법론을 활용하면서 계속 발전하고 있다. 첫 번째 판 발행 5년 후인 2004년 11월에 출판된 ''익스트림 프로그래밍 설명''의 두 번째 판에서 벡은 더 많은 가치와 방법론을 추가했으며, 주된 방법론과 부수적인 방법론을 구분했다.

Thoughtworks는 60명 규모의 분산된 XP 프로젝트에서 상당한 성공을 거두었다고 주장했다.

2004년에 XP의 발전된 형태인 산업적 익스트림 프로그래밍(IXP)[14]가 소개되었다. 이는 대규모 분산 팀에서 작업할 수 있는 능력을 제공하기 위한 것이었다. 현재 23가지 실천 방법과 유연한 가치를 가지고 있다.

3. 가치

익스트림 프로그래밍(XP)은 소프트웨어 개발의 효율성과 품질을 높이기 위해 고안된 방법론으로, 다음의 다섯 가지 가치를 기반으로 한다.


  • 의사소통:

소프트웨어 시스템 구축에는 시스템 요구 사항을 개발자에게 전달하는 것이 중요하다. 익스트림 프로그래밍에서는 문서 대신, 개발팀 구성원 간의 직접적인 의사소통을 통해 지식을 빠르게 공유하고 전파한다. 모든 개발자가 사용자의 관점과 일치하는 시스템에 대한 공유된 관점을 갖도록 하는 것을 목표로 한다. 이를 위해 단순한 디자인, 공통된 비유(메타포), 사용자와 프로그래머의 협업, 빈번한 구두 의사소통, 피드백을 중요하게 생각한다.

  • 단순성:

가장 단순한 해결책에서 시작하여, 추가 기능은 나중에 추가한다. 현재 필요한 기능에 집중하여 설계하고 코딩하는 것을 강조하며, 이는 "정말 필요할 때까지는 추가하지 않는다" 접근 방식으로 요약된다.[9] 미래의 불확실한 요구 사항에 미리 대비하는 대신, 현재의 문제 해결에 집중하는 것이다.

  • 피드백:

시스템 개발의 다양한 측면에서 피드백을 활용한다.

  • 시스템으로부터의 피드백: 단위 테스트를 작성하고 주기적인 통합 테스트를 실행하여, 프로그래머는 코드 변경 후 시스템 상태에 대한 직접적인 피드백을 받는다.
  • 고객으로부터의 피드백: 고객과 테스터는 인수 테스트를 작성하여 시스템의 현재 상태에 대한 구체적인 피드백을 얻는다. 2~3주마다 검토를 계획하여 고객이 개발 방향을 쉽게 이끌 수 있도록 한다.
  • 팀으로부터의 피드백: 고객이 새로운 요구 사항을 제시하면, 팀은 구현에 걸리는 시간을 추정하여 피드백을 제공한다.

켄트 백은 "낙관주의는 프로그래밍의 직업적 위험입니다. 피드백은 치료법입니다."라고 언급했다.[10]

  • 용기:

미래가 아닌 현재를 위해 설계하고 코딩하는 것을 강조한다. 이는 설계에 얽매여 다른 기능을 구현하는 데 많은 노력이 들어가는 것을 방지하기 위함이다. 또한, 필요할 때 코드를 리팩토링(프로그래밍)하고,[5] 쓸모없어진 코드를 제거하는 것을 포함한다. 끈기를 가지고 복잡한 문제에 직면하는 것도 용기의 중요한 부분이다.

  • 존중:

타인에 대한 존중뿐만 아니라 자기 존중도 포함한다. 프로그래머는 다른 사람의 작업을 방해하는 변경 사항을 적용하지 않아야 한다. 팀원들은 항상 높은 품질을 추구하고, 리팩토링을 통해 최선의 설계를 추구함으로써 자신의 작업을 존중한다. 팀 내 모든 구성원은 서로 존중하며, 이는 높은 동기 부여와 팀 목표에 대한 충성심으로 이어진다.

4. 원칙

익스트림 프로그래밍(XP)의 원칙은 앞서 설명한 가치에 기반하며, 시스템 개발 프로젝트에서 의사 결정을 돕기 위해 만들어졌다. 이 원칙은 가치보다 구체적이고, 실제 상황에서 지침으로 더 쉽게 적용할 수 있도록 의도되었다.

익스트림 프로그래밍은 피드백이 빠르고 빈번하게 이루어질 때 가장 유용하다고 본다. 행동과 피드백 사이의 지연 시간을 최소화하는 것이 학습과 변화에 매우 중요하다고 강조한다. 전통적인 시스템 개발 방법과 달리, XP에서는 고객과의 접촉이 더 빈번하게 반복된다. 고객은 개발 중인 시스템을 명확하게 이해하고, 필요에 따라 피드백을 제공하며 개발 방향을 조정할 수 있다. 고객의 빈번한 피드백을 통해 개발자가 잘못된 설계 결정을 내렸을 경우, 많은 시간을 들이기 전에 신속하게 발견하고 수정할 수 있다.

단위 테스트는 빠른 피드백 원칙에 기여한다. 코드를 작성할 때 단위 테스트를 실행하면 시스템이 변경 사항에 어떻게 반응하는지에 대한 직접적인 피드백을 얻을 수 있다. 여기에는 개발자의 코드를 테스트하는 단위 테스트뿐만 아니라, 단일 명령으로 시작할 수 있는 자동화된 프로세스를 사용하여 모든 소프트웨어에 대한 모든 단위 테스트를 실행하는 것이 포함된다. 개발자의 변경 사항이 시스템의 다른 부분에서 오류를 발생시키는 경우, 자동화된 전체 단위 테스트 스위트가 즉시 오류를 표시하여 개발자에게 변경 사항이 시스템의 다른 부분과 호환되지 않음을 알린다. 전통적인 개발 방식에서는 자동화되고 포괄적인 단위 테스트 스위트가 없었기 때문에, 개발자가 무해하다고 생각한 코드 변경이 통합 테스트 중에만 나타나거나, 심지어 실제 운영 환경에서만 나타나는 경우가 있었다. 통합 테스트 이전 몇 주 또는 몇 달 동안 모든 개발자가 수행한 변경 사항 중에서 어떤 코드 변경이 문제를 일으켰는지 파악하는 것은 매우 어려운 작업이었다.

XP에서는 모든 문제를 "극도로 단순하게" 해결하는 것처럼 다룬다. 전통적인 시스템 개발 방법론은 미래를 계획하고 재사용성을 고려하여 코드를 작성하라고 하지만, XP는 이러한 생각을 거부한다. XP 지지자들은 한 번에 큰 변화를 주는 것은 효과가 없다고 말한다. XP는 점진적인 변화를 적용한다. 예를 들어, 시스템은 3주마다 소규모 릴리스를 가질 수 있다. 작은 단계를 많이 거치면 고객은 개발 과정과 개발 중인 시스템에 대한 더 많은 통제권을 갖게 된다.

변화 포용의 원칙은 변화에 저항하지 않고 이를 받아들이는 것이다. 예를 들어, 반복 회의 중 고객의 요구 사항이 크게 변경된 것으로 보이면, 프로그래머는 이를 수용하고 다음 반복을 위해 새로운 요구 사항을 계획해야 한다.

익스트림 프로그래밍에서 피드백은 시스템 개발의 다양한 측면과 관련이 있다.


  • 시스템으로부터의 피드백: 단위 테스트를 작성하거나[24], 정기적인 통합 테스트를 실행함으로써 프로그래머는 변경 후 시스템 상태로부터 직접 피드백을 얻을 수 있다.
  • 고객으로부터의 피드백: 기능 테스트(일명: 인수 테스트)는 고객과 테스터가 작성한다. 그들은 시스템의 현황에 대한 구체적인 피드백을 얻을 수 있다. 이 리뷰를 2~3주에 한 번 간격으로 계획함으로써 고객은 쉽게 개발의 방향을 잡을 수 있다.
  • 팀으로부터의 피드백: 고객이 계획 게임에서 새로운 요구 사항을 제시하면 팀은 직접 구현에 소요되는 시간을 추정한다.


피드백은 의사소통과 단순성에 밀접하게 관련되어 있다. 시스템의 결함은 특정 코드가 깨지는 것을 증명하는 단위 테스트를 작성함으로써 쉽게 전달된다. 시스템으로부터의 직접적인 피드백은 프로그래머에게 이 부분을 재코딩하도록 전달한다. 고객은 ''사용자 스토리''[24]로 알려진 기능 요구 사항에 따라 정기적으로 시스템을 테스트할 수 있다. 켄트 백은 "낙관주의는 프로그래밍의 직업적인 위험이다. 피드백이 치료법이다."라고 언급했다.[30]

5. 실천 방법

XP는 소프트웨어 개발 과정에서 네 가지 기본 활동인 코딩, 테스트, 경청, 설계를 제시한다.[8]


  • 코딩: XP는 코드를 시스템 개발의 핵심 결과물로 간주한다. 코드는 문제 해결 및 의사 전달에 사용될 수 있으며, 명확하고 간결해야 한다.
  • 테스트: XP는 테스트 주도 개발을 핵심으로 여기며, 단위 테스트와 인수 테스트를 통해 코드 품질을 보장한다.[8]
  • 경청: 프로그래머는 고객의 요구사항, 즉 비즈니스 로직을 경청하고 이해해야 한다.
  • 설계: 복잡한 시스템의 의존성을 명확하게 하기 위해 설계 구조를 생성하여 시스템 변경의 유연성을 확보한다.


XP는 아래와 같이 4가지 영역으로 그룹화된 12가지 실천 방법을 제시한다.

XP의 규칙은 계획, 관리, 설계, 코딩, 테스트 범주로 나뉜다. 예를 들어 코딩 규칙에는 고객 상시 대응, 단위 테스트 우선, 최적화 지양, 초과 근무 금지 등이 있다. 테스트 규칙에는 모든 코드에 대한 단위 테스트 수행, 릴리스 전 모든 단위 테스트 통과, 버그 발견 시 테스트 작성, 인수 테스트 빈번한 실행 및 결과 공개 등이 있다.

5. 1. 주요 실천 방법

XP는 2주 주기로 계획을 세우고 프로토타입을 만들어 최종 사용자나 의뢰인과 함께 개발 상황을 검사한다.[5] 기한 안에 프로토타입 개발을 완료해야 하며, 그렇지 못하면 추가 비용 및 시간 손실이 발생한다.[5] 이는 소프트웨어 개발의 투명성을 확보하며, 기업에게는 실력 및 가능성을 보여줄 기회를, 의뢰인에게는 프로젝트 취소 및 다른 개발팀을 찾을 기회를 제공한다.[5]

XP는 반복적인 커스토머 테스트를 통해 의뢰인의 요구에 부합하는 소프트웨어를 만든다.[5] 개발자는 주기적으로 프로토타입을 의뢰인에게 보여주고, 의뢰인은 데모 모델을 통해 추가 요구사항을 제시할 수 있다.[5] 이는 개발 상황이 올바른 방향으로 가고 있음을 확인시켜 준다.[5]

XP는 KISS 원칙에 따라 모든 코딩을 가능한 간단하게 한다.[5]

테스트 기반 개발은 XP의 핵심 실천 방안으로, 테스트를 거치고 코딩하며 프로젝트를 개발한다.[5]

두 명 이상의 프로그래머가 함께 코딩하며, 한 명은 코딩, 다른 한 명은 품질 보증(Quality Assurance) 역할을 맡을 수 있다.[5]

XP의 주요 실천 방법은 다음과 같다.

5. 2. 전체 팀 (Whole Team)

애자일 방법론과 XP 방법론이 많이 사용되기 이전에는 팀 기반 소프트웨어 개발이 흔치 않았다. 그렇기 때문에 개발자들과 프로젝트에 참여하는 관리자 모두 이러한 방법론에 대해 진지하게 생각하지 않았다. 그래서 폭포수 모델과 나선 모형 같은 고전적인 소프트웨어 개발 방법론은 수많은 소프트웨어 개발 실패를 불러오기도 했다. 하지만 애자일 방법론 및 XP 방법론이 유명해지면서 팀 기반 협동적인 개발 방법론이 강조되기 시작했다. 그러므로 첫 번째 실천 방법인 Whole Team은 모든 프로젝트에 참여하는 팀원들을 가리키며, 개개인이 각자 역할이 있고 그 역할의 중요성을 이야기한다. XP에서 말하는 Whole Team은 일반적으로 테스터, 인터랙션 디자이너, 아키텍트, 프로젝트 매니저, 제품 매니저, 경영진, 기술 작가, 프로그래머, 사용자로 구성된다. 이들 중에서 가장 중요한 팀원은 사용자인데, 왜냐하면 그들이 프로젝트의 키를 가지고 있을(stakeholder) 뿐만 아니라 그들을 통해 요구사항을 파악할 수 있기 때문이다.[5]

6. 논란 및 비판

XP의 관행은 많은 논쟁을 불러일으켰다.[5] 익스트림 프로그래밍 지지자들은 현장 고객[5]이 비공식적으로 변경을 요청함으로써 프로세스가 유연해지고 공식적인 간접비용을 절감할 수 있다고 주장한다. 반면 XP 비판자들은 이로 인해 비용이 많이 드는 재작업이 발생하고 프로젝트 범위 확장이 이전에 합의되거나 자금 지원을 받은 범위를 넘어설 수 있다고 주장한다.

변경 관리 위원회는 여러 사용자 간의 프로젝트 목표와 제약 조건에 잠재적인 갈등이 있음을 나타낸다. XP의 신속한 방법은 프로그래머가 통합된 클라이언트 관점을 가정할 수 있는지에 다소 의존하므로, 프로그래머는 타협 목표 및 제약 조건에 대한 문서화보다는 코딩에 집중할 수 있다.[13] 이는 여러 프로그래밍 조직이 관련된 경우, 특히 프로젝트의 점유율을 놓고 경쟁하는 조직에도 적용된다.

익스트림 프로그래밍의 잠재적으로 논란의 여지가 있는 다른 측면은 다음과 같다.


  • 요구 사항은 사양 문서가 아닌 자동화된 인수 테스트로 표현된다.
  • 요구 사항은 모든 요구 사항을 미리 얻으려고 시도하는 대신 점진적으로 정의된다.
  • 소프트웨어 개발자는 일반적으로 쌍으로 작업해야 한다.
  • 사전 대규모 설계는 없다. 대부분의 설계 활동은 즉흥적으로 점진적으로 진행되며 "가장 간단한 것"부터 시작하여 테스트 실패에 의해 필요할 때만 복잡성을 추가한다. 비평가들은 이를 "시스템을 디버깅하여 외관을 만드는 것"으로 특징지으며, 이는 요구 사항이 변경될 때만 재설계하는 것보다 더 많은 재설계 노력을 초래할 것이라고 우려한다.
  • 고객 대표가 프로젝트에 참여한다. 이 역할은 프로젝트의 단일 실패 지점이 될 수 있으며 일부 사람들은 이를 스트레스의 원인으로 간주했다. 또한 비기술적인 대표가 기술적인 소프트웨어 기능 및 아키텍처의 사용을 지시하려는 세부 관리의 위험이 있다.


비평가들은 불안정한 요구 사항, 사용자 간의 갈등에 대한 문서화된 타협 부족, 전반적인 설계 사양 또는 문서의 부족을 포함하여 몇 가지 잠재적인 단점을 지적했다.[5]

2003년, 매트 스티븐스와 더그 로젠버그는 《익스트림 프로그래밍 리팩토링: XP에 반대하는 사례》를 출판하여 XP 프로세스의 가치에 의문을 제기하고 개선 방법을 제시했다.[6] 이 책의 핵심 주장은 XP의 실천 사항들이 상호 의존적이지만, 실제로 모든 실천 사항을 채택하려는 조직은 거의 없거나 불가능하며, 따라서 전체 프로세스가 실패한다는 것이다. 또한 이 책은 다른 비판을 가하며, XP의 "집단 소유" 모델을 부정적인 방식으로 사회주의에 비유한다.

《익스트림 프로그래밍 리팩토링》 출판 이후 XP의 특정 측면이 변경되었다. 특히 XP는 필수 목표가 여전히 충족되는 한 실천 사항의 수정을 수용한다. XP는 또한 프로세스에 대해 점점 더 일반적인 용어를 사용한다. 어떤 사람들은 이러한 변경 사항이 이전의 비판을 무효화한다고 주장한다. 다른 사람들은 이것이 단순히 프로세스를 약화시키는 것이라고 주장한다.

다른 저자들은 XP를 이전 방법론과 조화시켜 통합된 방법론을 형성하려고 시도했다. 이러한 XP는 폭포수 방법론과 같이 대체하려는 대상이었다. JPMorgan Chase & Co.는 XP를 능력 성숙도 모델 통합 (CMMI) 및 식스 시그마의 컴퓨터 프로그래밍 방법과 결합하려고 시도했다. 그들은 세 시스템이 서로 잘 강화되어 더 나은 개발로 이어졌고, 서로 모순되지 않는다는 것을 발견했다.[15]

극단적 프로그래밍의 초기 화제와 페어 프로그래밍 및 지속적 설계와 같은 논란이 많은 원칙은 특히 맥브린,[16] 뵘과 터너,[17] 맷 스테판과 더그 로젠버그[18]의 비판을 받았다. 그러나 많은 비판은 애자일 실무자들에 의해 애자일 개발에 대한 오해로 여겨진다.[19]

특히 극단적 프로그래밍은 맷 스테판과 더그 로젠버그의 ''Extreme Programming Refactored''에 의해 검토되고 비판받았다.[6]

참조

[1] 간행물 "Human Centred Technology Workshop 2006 " http://citeseerx.ist[...] 2006
[2] 간행물 Design Patterns and Refactoring http://www.cis.upenn[...] University of Pennsylvania 2003
[3] 간행물 Extreme Programming http://www.cs.usfca.[...]
[4] 웹사이트 Manifesto for Agile Software Development http://agilemanifest[...] Agilemanifesto.org 2019-03-26
[5] 뉴스 Extreme Programming http://www.computerw[...] Computerworld 2001-12
[6] 서적 Extreme Programming Refactored: The Case Against XP https://archive.org/[...] Apress
[7] 서적 Interview with Kent Beck and Martin Fowler http://www.informit.[...] 2001-03-23
[8] 서적 Testing Extreme Programming Addison-Wesley Professional 2003
[9] 뉴스 "Everyone's a Programmer" Technology Review 2003-11
[10] 서적 Extreme Programming Explained: Embrace Change Addison-Wesley
[11] 웹사이트 Extreme Programming Rules http://www.extremepr[...]
[12] 웹사이트 Ken Auer http://www.rolemodel[...]
[13] 서적 Agile Project Management in easy steps, 2nd edition https://books.google[...] In Easy Steps 2015-07-29
[14] 웹사이트 Industrial XP: Making XP Work in Large Organizations - Cutter Consortium http://www.cutter.co[...] 2019-03-26
[15] 간행물 Extreme Programming (XP) Six Sigma CMMI http://www.sei.cmu.e[...]
[16] 서적 Questioning Extreme Programming Addison-Wesley
[17] 서적 Balancing Agility and Discipline: A Guide for the Perplexed Addison-Wesley
[18] 서적 The irony of extreme programming http://www.drdobbs.c[...] Dr Dobbs journal
[19] 웹사이트 sdmagazine http://www.sdmagazin[...]
[20] 간행물 "Human Centred Technology Workshop 2006 " http://citeseerx.ist[...] 2006
[21] 간행물 Design Patterns and Refactoring http://www.cis.upenn[...] University of Pennsylvania 2003
[22] 간행물 Extreme Programming http://www.cs.usfca.[...]
[23] 웹사이트 Manifesto for Agile Software Development http://agilemanifest[...] Agilemanifesto.org 2019-03-26
[24] 뉴스 Extreme Programming http://www.computerw[...] Computerworld 2001-12
[25] 서적 Extreme Programming Refactored: The Case Against XP https://archive.org/[...] Apress
[26] 서적 Interview with Kent Beck and Martin Fowler http://www.informit.[...] 2001-03-23
[27] 서적 Proceedings of the 10th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement - ESEM '16 https://www.research[...]
[28] 서적 Testing Extreme Programming 2003
[29] 뉴스 "Everyone's a Programmer" Technology Review 2003-11
[30] 서적 Extreme Programming Explained: Embrace Change Addison-Wesley
[31] 웹사이트 Extreme Programming Rules http://www.extremepr[...] 2019-03-26
[32] 웹사이트 Ken Auer http://www.rolemodel[...]
[33] 서적 Agile Project Management in easy steps, 2nd edition https://books.google[...] In Easy Steps 2015-07-29
[34] 웹사이트 Industrial XP: Making XP Work in Large Organizations - Cutter Consortium http://www.cutter.co[...] 2019-03-26
[35] 간행물 Extreme Programming (XP) Six Sigma CMMI http://www.sei.cmu.e[...]
[36] 서적 Questioning Extreme Programming Addison-Wesley
[37] 서적 Balancing Agility and Discipline: A Guide for the Perplexed Addison-Wesley
[38] 서적 The irony of extreme programming http://www.drdobbs.c[...] Dr Dobbs journal
[39] 웹사이트 sdmagazine http://www.sdmagazin[...] 2006-03-16


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com