익스트림 프로그래밍
1. 개요
Extreme Programming. 줄여서 XP(eXtreme Programming).
1999년 켄트 벡이 발표한 프로그램 개발 방식으로, 빠르게 고객과 소통하며 개발할 수 있는 방법이다. 의사소통, 단순성, 피드백, 용기, 존중을 가치로 내세우고 있다.
2. 기본 원칙
기본 원칙은 다음과 같다.
1. 조금씩, 하지만 자주 발표한다.
2. 사이클을 반복해서 돌리면서 개발한다.
3. 스펙에 없는 것은 절대 집어넣지 않는다.
4. 테스트 코드를 먼저 만든다.
5. 야근은 하지 마라. 항상 정규 일과 시간에만 작업한다.
6. 기회가 생기는 족족 언제 어디서든 코드를 개선한다.
7. 모든 테스트를 통과하기 전에는 어떤 것도 발표하지 않는다.
8. 조금씩 발표하는 것을 기반으로 하여 현실적인 작업 계획을 만든다.
9. 모든 일을 단순하게 처리한다.
10. 두 명씩 팀을 편성하고 모든 사람이 대부분의 코드를 알 수 있도록 돌아가면서 작업한다.
근데 말이 좋아 이런 거지, 극단적으로 보면
1. 짜증나게 자주 업데이트한다.[1]
2. 셔틀 돌린다.
3. 말한 것만 짠다.
4. 코드 짜기도 전에 테스트한다.
5. 근로기준법을 준수하라!
6. 시도때도 없이 고친다.
7. 허들 넘기
8. 안 될 계획은 아예 세우지도 않는다
9. 단순
10. 파트너와 함께
아무튼 이러한 이유로 처음 등장했을 때 충격과 공포를 안겨주었지만 현재는 프로그래머들 사이에서 큰 인기를 얻고 있다.
3. 성공 이유
우선, 기본적으로 '''프로그래머는 프로그래밍을 좋아한다.''' 비프로그래머를 위해 설명하자면 프로그래밍도 일종의 창작 과정이기 때문에 그 결과를 얻을 때 희열을 얻는 것은 마찬가지다. 작가가 시 한편을 써 낸 후의 기쁨을 생각해보면 쉬울 듯싶다. XP는 이런 성향을 이용해 프로그래머가 프로그래밍의 압박과 고통보다는 희열과 기쁨을 더 누릴 수 있게 했다.
또한 정신적으로 강도 높은 노동인 코딩을 하는 동안 다른 한 사람이 아이디어도 주고 알고리즘도 찾아 보고 하는 것 역시 효율적이다.
의문의 '테스트 코드를 먼저 만든다.' 부분은, 먼저 출력이 어떻게 되어야 할 지 테스트 코드를 쓴 다음 그것을 만족하게 프로그램을 만든다는 것이다. 테스트를 통과하면 이제 다시 테스트 코드를 개선한다. 이런 식으로 반복한다. 이 방법은 테스트 주도 개발이라는 다른 개발 방법론으로 넘어간다.
주의할 점 : 1+1 >= 3 이 되지 못할 거라면 하지 않는 것이 더 낫다.
2 가 아니라 3 인 이유는 2~3 사이라면 과연 효율적인가? 라는 불필요한 의문점이 제기되고, 이는 곧 비효율을 만들기 때문이다.
4. 현실적 익스트림 프로그래밍이 가능하려면
30년 동안 대규모 금융권 SI사업을 전문적으로 수행해 온 동양네트웍스에 따르면, “지금까지의 Waterfall Model 방식으로 프로젝트를 진행 할 경우 개발이 완료되기 전 까지 사용자가 실제 구동하는 화면을 볼 수 없다. UI/UX 정의 단계에서 사용자와 설계자 간의 합의를 이루는 과정의 매개체로 PowerPoint와 같은 정적 문서를 주로 활용하는 실정이다. 이러한 정적 문서는 UI 구성요소의 배치 위치 등을 표현하기에는 적절하나 실제 동작 방법을 텍스트와 그림으로만 표현하기에는 한계가 있다. 이러한 한계로 인하여 사용자와 설계자는 같은 문서를 보고 다른 UI/UX를 상상하게 되고 결국 오해를 한 상태로 개발까지 진행되게 된다.
Waterfall 방식에서 사용자와 설계자는 이러한 오해를 개발이 완료된 후 테스트 단계에 와서야 실제 구동하는 화면을 보고 난 후 인지할 수 있다. 뒤늦게 발견한 요구정의 오류에 따라 개발된 내용에 수정이 필요하게 되고, 오류 내용에 따라 DB 모델링 등 설계가 변경되는 경우 수정해야 할 분량은 가늠할 수 없는 수준이 되어 프로젝트 납기 준수에 큰 차질을 빚는다.”라는 분석을 내 놓았다.
애자일 방법론에 대한 이상과 현실이 매우 다르고, 특히 고객의 전형적인 떼쓰기 전략과 수행사를 자금으로 압박하기 환경에서는 고객의 변경 요구를 “법정에서 만나요”라는 말로 대항하기 어렵다. 이런 말 함부로 하면, 고객들에게 매장 당하거나, 경쟁사 영업대표가 신나게 써먹기 때문이다. 그래서 실제 애자일로 성공한 프로젝트가 별로 없다. 게다가 대규모 개발에의 적용은 언감생심(焉敢生心)이었다.
말이 좋아 문서 없이 코드만 가지고 프로그래밍 하는 거지, 남이 짜 놓은 코드를 설명도 없이 유지보수하려면 정말 개고생이다. 따라서, 몇 가지 도구들이 필요한데, 이러한 프레임워크의 필수 요소는 이용용이성(ease of use), 분절화(segmentation), 재사용성(reusability)이다.
이용용이성(ease of use) 관점에서 보면, 투입되는 인력 중 고객과 밀접하게 커뮤니케이션 하는 인력은 PM/PL급이고, 이들이 UI를 만들기엔 최신 트렌드도 모르고, UX개념도 약하고, 할 줄도 모른다. 그러다 보니, 퍼블리셔를 대동하여 회의에 참석하곤 하는데, 퍼블리셔는 주로 프리랜서를 쓰다 보니, 애자일 기반으로 투입하기가 영 어렵다. 그래서, 이런 어렵고 고급진 PM님들, PL님들 모시고 익스트림 프로그래밍하려면, 쉽게 고객과 커뮤니케이션 할 수 있는 툴과 자동생성되는 “준 문서”들이 필요하다.
분절화(segmentation) 관점에서 보면, 기존의 개발은 DB 준비, UI 완성, 그에 따른 프로그램(event기반이던, Stored Procedure 이던)이 모두 완성된 후에야 단위 테스트라도 가능하다. 그러다 보니 전반부에서 정의된 것을 고객이 흔들면(수행사가 실수한 건 그들 사정이니 생략하자), 멘탈에 심한 충격이 온다. 고객은 그것 조금 바꾸면서, 온갖 헐리웃 액션을 남발한다고 하겠지만, 아는 사람은 입술 꽉 깨물어도 나오는 신음을 막을 수 없다. 이를 방지하기 위해 익스트림프로그래밍 하자는 것인데, 이런 식으로는 허상 뿐인 방법론에 지나지 않는다. 동양네트웍스는 이러한 관점에서 분절화를 통해, 각 개발자가 역할별로 단위 테스트를 수행할 수 있고, 이것들이 유기적으로 돌아가도록 TY*eXtreame이라는 프레임워크와 코딩이 필요 없는 테스트/업무 자동화 툴을 보급 중이다.
재사용성(reusability)의 관점에서 보면, 한국사회의 특성을 일부 고려해야 한다. 대부분의 프로젝트는 일정에 쫓겨 프로그램을 찍어내듯이 만들고, 수없이 버그를 만나며, 그 디버깅에 과정에서 지체상금을 물지 않기 위해 오류가 어느 정도 있어도 오픈한 후, 안정화 기간을 통해 보완한다. 일정에 쫓기다 보니, 테스트는 대충하게 되고, 품질은 떨어지는 악순환을 계속하게 되는데, 이를 극복하려면, 통합테스트를 수차례 반복할 수 있도록 자동화 도구가 필요하다. 테스트 자동화 도구는 웹이던 앱이던 구분 없이 가능해야 하며, 도구가 아닌 사람으로 시나리오를 재사용하면 인건비 무덤에 빠지게 된다. 다행히, 이런 자동화 도구가 없는 것은 아니다. 파이온닷컴의 ATAM이라는 도구가 있는데, 그나마 코딩 없이 파워포인트의 슬라이드 생성하듯 장면으로 테스트 시나리오를 구성할 수 있고, 동시에 수십개의 시나리오도 돌릴 수 있다. 웹이던 모바일 앱이던 Device, OS, Browser에 구애를 받지 않는다.
[1] 적어도 하루 1회, 심하면 3~4회의 발표를 하루 내에 하는 경우도 있다. 아예 원탁에 둘러 앉아 서로 바라보면서 끊임없이 의사소통을 하는 팀들도 있다!