익스트림 프로그래밍

익스트림 프로그래밍 책을 읽고 정리한 내용입니다.

익스트림 프로그래밍(eXtreme Programming, XP)의 목표는 뛰어난 소프트웨어 개발이다.

성공을 준비하라. 성공에서 한 발짝 뒤로 물러나 자신을 보호하지 말라. 이것이 극단(extreme)이다. 자신을 노출하라.

가치-원칙-실천방법

4장 가치

XP는 개발을 이끌기 위한 다섯 가지 가치를 포용한다. 그것들은 의사소통, 단순성, 피드백, 용기, 존중이다.

• 피드백: 피드백은 의소사통의 핵심이다. “성능이 문제가 될까요?”, “잘 모르겠는데요. 간단한 성능 프로토타입을 만들어 확인해보죠.” 피드백은 단순성에도 기여한다. 세 가지 해결책 가운데 어떤 것이 가장 단순한 방법일까? 셋다 시도해 보고 판단하라. 똑같은 것을 세 번이나 구현하는 것이 노력의 낭비처럼 보일지도 모르지만, 그렇게 하는 것이 여러분이 만족할 수 있을 정도로 단순한 해결책에 도달하는 가장 효율적인 방법일 수 있다. 동시에, 시스템이 단순할수록 시스템에 대한 피드백도 더 쉽게 받을 수 있다.

가치는 소프트웨어를 개발할 때 무엇을 해야 하는지 구체적으로 충고해 주지는 않는다. 가치와 실천방법 사이에 간극 때문에, 우리는 이 둘 사이를 이어줄 다리가 필요하다. 원칙은 이때 우리가 필요한 도구다.

5장 원칙

자기 팀에서 사용하는 실천 방법들의 지침이 되는 다른 원칙들을 가지고 있을 수도 있지만, 여기에는 XP에 지침이 되는 원칙들이 나와 있다.

• 인간성: 소프트웨어는 인간이 개발한다.
• 경제성
• 상호이익: 내게 지금 이익이 되고, 나중에도 이익이 되고, 내 고객에게도 이익이 되는 실천방법들을 찾는 것이다.
• 자기 유사성
• 개선: 완벽해질 때까지 기다리지 말고 개선을 실천하라. 어떤 것부터 시작하면 좋을지 찾아보고, 일단 시작한 다음 거기서부터 차츰 개선하도록 한다.
• 다양성
• 반성
• 흐름: 소프트웨어 개발에서 흐름이란, 개발의 모든 단계를 동시에 작업함으로써 가치 있는 소프트웨어를 흐르듯이 끊임없이 제공하는 것이다.
• 기회
• 잉여
• 실패: 어떤 스토리를 구현하는 세가지 방법 중 어떤 것을 선택해야 할지 모르겠는가? 셋 다 해보라. 셋 모두 실패하더라도, 분명 귀중한 교훈을 얻을 수 있다. 무엇을 해야 할지 모를 경우, 실패를 감수하는 것이 성공으로 가는 가장 짧고 확실한 길이다.
• 품질
• 아기 발걸음
• 받아들인 책임

원칙을 이용한다면 실천방법들을 더 잘 이해할 수 있다.

6장 실천방법

가치를 통해 목적을 불어 넣지 않은 실천방법은 기계적으로 따르는 규칙일 뿐이다. 예를 들어 짝 프로그래밍을 마치 해야할 일 목록에서 ‘짝 프로그래밍: 했으면 체크표시 하시오.’하는 식으로 실천한다면 아무 의미가 없다.

실천방법은 상황에 따라 달라져야 한다. 상황이 바뀌면 그에 맞추어 다른 실천방법을 골라야 한다.

7장 기본 실천방법

• 함께 앉기: 물리적 가까움이 의사소통을 향상 시킨다.
• 전체 팀: 프로젝트가 성공하기 위해 필요한 기술과 시야를 지닌 사람들을 전부 팀에 포함시켜라. 그리고 ‘팀’에 속한다는 느낌이 필요하다.
• 정보를 제공하는 작업 공간: 예로 벽에 스토리 카드를 붙이는 방법
• 활기찬 작업: 생산적으로 일할 수 있는 정도의 시간만, 그리고 일의 활력을 유지할 수 있는 정도의 시간만 일해라.
• 짝 프로그래밍
  • 리뷰 대상 코드는 작지만 중요한 부분을 선정한다.
  • 코드가 작성되자마자 그 품질에 대해 피드백을 받을 수 있다.
  • 같은 짝 끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 바꾸는 것이 좋다.
• 스토리: 고객이 볼 수 있는 기능을 단위로 해서 계획을 짜라. 예를 들어 ‘동일한 응답시간에 다섯 배의 통신량을 감당한다.’나 ‘사용자가 자주 사용하는 번호는 두 번 클릭만으로 사용할 수 있게 한다.’처럼. 어떤 스토리를 작성한 다음에는 그것을 구현하기 위해 필요한 개발 노력을 추정해 본다.
• 일주일별 주기: 한 번에 일주일 분량의 일을 계획해라.
  • 지금까지 진행된 상황을 검토하는데, 지난주의 실제 진행 정도가 예상 진행 정도를 달성했는지 역시 검토에 포함한다.
  • 이번 주에 구현할 일주일 분의 스토리를 고객이 고르도록 한다.
  • 스토리를 여러 과업(task)으로 쪼갠다. 팀 구성원들은 자기가 할 과업에 서명을 하고, 얼마나 걸릴지 추정한다.
• 분기별 주기: 팀의 반성을 위한 좋은 시간 간격으로, 이를 통해 모르는 사이에 팀을 갉아먹는 병목을 찾아낼 수 있다. 그리고 장기 실험들을 제안하고 평가하는 데도 분기를 사용할 수 있다.
• 여유: 어떤 계획이든, 일정에 뒤쳐질 경우 포기할 수 있는 비교적 덜 중요한 과업들을 포함시켜라.
• 10분 빌드: 10분 만에 자동으로 전체 시스템을 빌드하고 모든 테스트를 돌려라. 빌드가 10분보다 오래 걸린다면 그것을 실행하는 횟수가 현저히 줄어든다.
• 지속적 통합: 변경한 것은 두 세 시간 만에 통합하고 테스트해라. 통합을 오래 미룰수록 비용이 더 들며 통합 비용을 예측하기도 힘들어 진다.
• 테스트 우선 프로그래밍: 코드를 한 줄이라도 변경하기 전에, 일단 실패하는 자동화된 테스트를 먼저 작성하라.
  • 모듈, 클래스, 함수를 구체적으로 정의하도록 강제하여 일을 점진적으로 진행할 수 있다.
  • 테스트 코드는 잘 정리된 요구사항의 역할도 하기때문에 딱 필요한 만큼만 코딩하도록 유도하여 불필요하게 복잡해지거나 오버 엔지니어링을 하는 것을 줄여준다.
  • 첫 설계 단계에서는 요구사항을 확대 해석하고 미래에 있을지 모를 부가 조건들이 추가되기 쉬워 설계가 커지고 복잡해지는 경향이 있다. TDD는 그렇게 되지 않도록 막아 준다.
• 점진적 설계: 시스템의 설계에 매일 투자하라. 시스템의 설계가 바로 그날 그 시스템이 필요로 하는 것에 훌륭하게 들어맞게 되도록 애써라. 어떤 설계가 가능한 한도에서 최선의 설계인지 더 잘 이해하게 되었다면, 현재 설계가 여러분이 이해한 최선의 설계와 일치하도록 점진적으로 하지만 지속적으로 작업한다.
  • 시스템에서 설계를 개선할 부분을 어떻게 찾느냐다. 내가 유용하다고 생각하는 간단한 휴리스틱은 중복을 제거하는 것이다.

9장 보조 실천 방법

• 진짜 고객 참여
• 점진적 배치
• 팀 지속성
• 팀 크기 줄이기
• 근본 원인 분석: 개발 후에 결함이 발견될 때마다, 결함과 그 원인을 모두 제거하라. 이 실험방법의 목표는 바로 그 결함이 다시 나타나지 않도록 만드는 것이 아니라, 팀이 같은 종류의 실수를 다시는 저지르지 않도록 하는 것이다. XP에서는 다음 단계가 결함에 대응하는 절차다.
  • 결함을 드러내는 시스템 차원의 자동화된 테스트를 작성한다.
  • 가능한 한 범위가 가장 좁은 단위 테스트를 작성한다.
  • 단위 테스트를 통과하도록 시스템을 고친다.
  • 결함을 해결한 후에는 왜 이 결함이 생겼는지, 왜 결함이 이전에 잡히지 않았는지 알아낸다. 앞으로 이런 종류의 결함이 일어나는 일을 막기 위해 필요한 변화를 시작한다.
• 코드 공유
• 코드와 테스트: 오직 코드와 테스트만 영구 산출물로 유지하라.
• 단일 코드 기반: 고객 일곱 명마다 서로 다른 코드 기반을 하나씩 가지지 않도록 하라.
• 매일 배치
• 범위 협상 계약: 소프트웨어 개발 계약을 작성할 때 시간, 비용, 품질은 확정해도 시스템의 정확한 범위는 계속 협상해 나가자고 요청하라. 긴 계약 하나에 서명하기보다 짧은 계약 여러 개를 여러 번에 걸쳐 서명함으로써 위험도를 낮추어라.
• 사용별 지불: 시스템이 사용될 때마다 돈을 청구한다. 돈은 궁극적인 피드백 수단이다.

11장 제약 이론

‘제약 이론(Theory of Constraints)’은 전체로서의 시스템 처리능력을 살펴보는 접근방법 가운데 하나다. 제약 이론에 따르자면 시스템에는 한 시점에 제약 지점이 하나(가끔은 두개) 존재한다. 전체 시스템의 처리 능력을 키우려면 먼저 제약 지점을 찾은 다음, 그 지점이 확실히 현재 가능한 최대 속도로 가동하도록 한 다음에, 제약 지점의 성능을 향상시키거나 그것의 작업량 중 일부를 다른 비 제약 지점으로 덜어주거나 제약 지점을 완전히 제거할 방법을 찾아야 한다. 시스템에서 어떻게 제약 지점을 찾을 수 있을까? 작업들은 제약 지점 앞에 쌓이기 마련이다.

제약 이론은 미시적 최적화가 아니라 전반적인 처리 능력에 맞추어야 한다는 가정을 공유한다. 만약 모든 사람이 자기가 하는 기능은 제약이 아닌 것처럼 보이게 노력한다면, 어떤 변화도 일어날 수 없다. 만약 개발자가 “맞아요, 자동화된 테스트를 작성하는 것은 분명히 좋은 일이겠지만, 그걸 하면 내가 일하는 속도가 느려질 텐데 나는 지금도 업무가 밀려있단 말이에요.”처럼 말한다면 변화가 조직에 얼마나 큰 이익을 가져다주는지, 그에 따라서 개인에게도 얼마나 이익이 돌아가는지 상관없이 아무것도 변화시킬 수 없다. 변화가 뿌리내리려면 보상 체계와 조직 문화를 개인의 생산성 대신 전체적인 처리량에 맞출 필요가 있다.

12장 계획 짜기: 범위를 관리하기

XP의 계획 짜기는 현재 있는 목표, 가정, 사실을 분명히 드러내는 일부터 시작된다. 명시적인 현재 정보가 있다면 무엇을 범위에 넣을지, 무엇을 범위에서 뺄지, 다음에 할일은 무엇인지 서로 동의를 끌어내는 작업을 할 수 있다.

우리가 할 수 있는 수많은 일 가운데 다음에 할 일이 무엇인지 결정하는 것도 계획 짜기의 일부다. 계획 짜기가 복잡한 까닭은 스토리의 비용과 가치가 불확실하기 때문이다. 여러분이 결정을 내린 시점에서 근거로 삼은 정보들은 변한다. 우리는 추정치를 개선하기 위해 피드백을 이용하며, 가장 좋은 정보를 근거로 결정을 내릴 수 있도록 결정 시기를 최대한 늦춘다. 이것이 XP에서 계획 짜기를 매일, 매주, 매분기 해야 하는 이유다. 새로운 사실이 튀어나올 때마다 그에 맞도록 계획을 변경할 수 있다.

계획의 시간 단위가 어떻게 되든 다음 네 단계를 통해 계획을 짜라

• 해야 할 일을 목록으로 작성한다.
• 각 항목의 작업 시간을 추정한다.
• 지금 계획 중인 주기를 위한 예산을 세운다.
• 해야 할 일들을 예산 내 범위에서 합의한다. 협상할 때, 추정치나 예산을 변경하면 안 된다.

13장 테스트: 일찍, 자주, 자동화

결함은 신뢰를 깨뜨린다. 하지만 모든 결함을 제거하는 일은 불가능하다. 평균 실패 간격(mean time between failures, MTBF)을 한 달에서 일 년으로 늘리려면 엄청난 비용이 든다. XP 실천 방법들은 명료한 의사소통에 목표를 둔다. 그렇게 해서 애초에 결함이 발생하지 않도록 하고, 설사 발생하더라도 그 팀이 결함을 이용해서 미래에 유사한 문제를 피하는 방법을 학습하도록 한다.

결함은 언제나 존재할 것이다. 예상치 못한 상황은 발생하기 마련이다.

XP에서 테스팅은 결함 문제에 직접 대응하는 기술적 활동이다. XP는 테스트의 비용 효율을 높이기 위해 두 가지 원칙을 적용한다. 재확인(double-checking)과 결함 비용 증가(Defect Cost Increase, DCI)가 그 두 원칙이다. 결함 비용 증가는 결함을 일찍 찾을 수록, 고치는 비용이 적게 든다는 것이다. DCI에는 피드백의 순환이 긴 소프트웨어 개발은 비용이 많이 들고 잔여 결함도 많으리라는 의미가 들어 있다.

재확인의 이익을 전부 얻기 위해 XP에는 테스트 집합이 두 개 있다. 첫째 집합은 프로그래머의 시각에서 작성된 테스트들로 시스템의 구성요소들을 철저히 검사하며, 둘째 집합은 고객 또는 사용자의 시각에서 작성된 테스트들로 전체 시스템의 작동을 테스트한다. 두 테스트 집합은 서로를 재확인한다. XP에서 테스트의 즉각성은 테스트가 반드시 자동화되어야 한다는 점을 역시 의미한다.

베타 테스트는 테스트의 실천이 약했고, 고객과 의사소통이 나빴다는 증표다. 팀의 목표는 개발 후 테스트를 모두 없애고 테스트에 소요되는 자원을 개발의 생애에서 자원의 투입 효과가 더 좋은 부분으로 옮기는 것이다. 스트레스 테스트나 부하(load) 테스트처럼 개발이 ‘완료된’ 다음에 결함을 찾아보는 테스트 형태가 있다면, 그것들을 개발 주기 안으로 끌어들인다. 부하 테스트와 스트레스 테스트도 꾸준히 그리고 자동화해서 돌린다.

코드와 테스트들은 어떤 순서로 작성해도 상관없다. XP에서는 가능하다면 테스트를 구현보다 먼저 작성하라. 테스트를 먼저 작성하는 것에는 여러가지 좋은 점이 있다. 나는 실패하는 테스트를 오직 한 번에 하나씩 다루려고 노력한다. 실패하는 테스트를 하나 작성한 다음 그것을 통과하게 만들고, 다시 다음 실패하는 테스트를 작성한다. 첫 번째 테스트를 통과하게 만들면서 생긴 경험이 종종 두 번째 테스트 작성에서 무엇을 어떻게 할지 알려준다.

14장 설계하기: 시간의 가치

점진적 설계(incremental design)는 고객에게 기능을 빨리 전달하고 프로젝트의 생애 내내 매주 계속 기능을 제공하기 위한 방법이다. XP는 설계의 점진성을 극한까지 밀어붙여, 설계가 매일 업무의 일부가 될 때 프로젝트가 더 순조롭게 진행되리라고 주장한다.

소프트웨어에서 점진적 설계가 가치 있는 이유 가운데 하나는 우리가 어떤 애플리케이션을 최초로 작성하는 경우가 많다는 것이다. 비록 현재의 애플리케이션이 동일 주제에 대해 무수히 많은 변주를 시도한 후에 나온 것이라 해도, 소프트웨어를 설계하는 데는 언제나 더 나은 방법이 존재한다.

건축에 적합한 활동 순서는 소프트웨어에는 적합하지 않다. 문제는 설계를 하느냐 마느냐가 아니라 언제 설계를 하느냐다. 최초 구현을 시작할 수 있는 정도만 설계하면 된다. 그 이상의 설계는 구현이 자리를 잡고 설계의 진짜 제약들이 분명하게 보일 때 하도록 한다. ‘아무것도 설계하지 말라’와 정반대로, XP의 전략은 ‘언제나 설계하라’다.

지금 직면한 코드가 마치 커다란 진흙 덩어리 같다 해도, 여전히 설계 개선을 시작하는 것은 가능하다. 코드를 수정하면서, 조금씩 깔끔하게 만들라. 설계 개선을 멀리까지 앞서 나가게 하고 있은 유혹에 저항하라. 오늘 여러분에게 영향을 미치는 설계만 개선하는 습관을 길러라. 오랜 시간에 걸쳐 건드려야 할, 더 큰 개선들의 목록을 만들고 공개하라.

요약하자면, XP 방식 설계로 옮겨가는 것은 설계 결정을 내리는 시점을 옮기는 것이다. 경험을 바탕으로 설계할 수 있을 때까지 그리고 결정 내용을 즉각 사용할 수 있을 때까지 설계를 미룬다. 이렇게 하면 팀은 다음과 같은 일을 할 수 있다.

• 소프트웨어를 더 빨리 배치할 수 있다.
• 확신을 가지고 결정을 내릴 수 있다.
• 잘못된 결정을 계속 끌어안고 사는 일을 피할 수 있다.
• 처음 설계할 때 내린 가정들이 다른 것으로 대체되더라도 개발 속도를 유지할 수 있다.

20장 XP 적용하기

조직의 변화를 시작하는 방법은 여전히 여러분 자신부터 변화를 시작하는 것이다. 자신의 변화는 언제나 여러분의 힘 아래 놓여있다. 먼저 자기 기술을 발전시킨 다음, 그 기술로 다른 사람을 도우라. 기술을 배운 다음, 그 기술로 다음 사람을 돕는 전략은 여러 차원에서 통한다.

• 여러분이 ‘테스트 우선 프로그래밍’을 익힌 다음, 그것을 팀과 공유한다.
• 여러분 팀이 스토리 단위로 추정하고 개발하는 법을 익힌 다음, 내부 고객을 초대해서 스토리들을 고르라고 한다.
• 여러분 조직이 탄탄한 소프트웨어를 예측가능하게 배치하는 법을 익힌 다음, 외부 고객을 초대해서 계획 짜기의 일부가 되라고 한다.

여러분은 어떤 변화를 만들고, 그 결과를 관찰한 다음, 변화를 소화해서 탄탄한 습관으로 바꾼다. 그러다가 언젠가는 개선의 진도가 잘 나가지 않는 상태에 빠질 텐데, 그때에는 더 많은 피드백을 흡수하면서 다음 도약 기회를 모색하라. 어떤 경우에는 새로운 실천방법을 시도했더니 여러분의 수행능력이 오히려 떨어지는 것을 발견할 수도 있다. 그렇게 되었다고 해서 개선이 불가능하다거나, 여러분이 시도한 실천방법이 본래부터 나쁜 것은 아니다. 이 현상은 여러분이 아직 그것을 써볼 충분한 경험을 쌓지 못했음을 의미한다. 새 실천방법을 잘 하는데 필요한 숨겨진 선행 조건을 여러분이 아직 갖추지 못했기 때문에 아직 그것을 할 준비가 되지 않은 것일지도 모른다. 다시 뒤로 돌아가 숨어있는 문제들을 해결한다.

25장 결론

나는 XP를 적용하는 사람들이 그들의 소프트웨어 개발과 삶에 다시 한번 희망을 찾는 것을 보았다. 여러분은 이제 XP를 시작하기에 충분한 지식을 지녔다. 지금 시작하길 권한다. 여러분의 가치들을 생각해보라. 그 가치들과 조화되는 삶을 살겠다고 의식적인 결정을 내려라. 여러분의 길을 따라 걸아가기 위해 실천방법을 하나 골라라. XP는 당신의 이상에 대해 생각하고, 행동을 취하는 방법이다.