== 기원 ==
[[애자일]] 방법론에 따르면, 기존의 [[https://ko.wikipedia.org/wiki/%ED%8F%AD%ED%8F%AC%EC%88%98_%EB%AA%A8%EB%8D%B8|폭포수 모델]]의 고질적 단점(고객의 요구사항 변경, 숨은 개발 물량, 테스트 시 발견돼 설계를 변경해야 하는 중대한 결함, 개발일정 지연에 따른 지체상금, 고객의 부동의에 따른 대금 지급 저항 등)을 일거에 해결할 것 같다. 하지만 한국의 개발사 현실은 그리 녹록치 않다.

고객이 요구하면서도 자기가 무슨 요청을 하는지 모르고, 그때는 동의했으나(심지어 문서에 날인 수준으로), 그 의미는 아니었다고 주장하며, 이미 계약해서 수행하고 있는데, 그 정도는 서비스로 해줄 수 있는 것 아니나며 윽박지르고, 결국 납기를 못 맞추면 지체상금을 물리겠다는 겁주기 등 개발 적폐가 만연해 있다. 그러나 대부분의 수행사는 고객의 잘못이 아니라며 울며 겨자 먹기로 감내하고 있다.
== 태동 배경 ==
김종식(現 동양네트웍스 전무)에 따르면, 이렇게 된 배경엔 다음과 같은 설이 가장 유력하다[* [[익스트림 프로그래밍]]].

원래 컴퓨팅서비스는 1990년대 후반까지만 해도 [[IBM]] 등의 공룡사업자가 만드는 [[메인프레임]] 판이었고, 이 메인프레임에 더미터미널 [[콘솔]]을 붙여 서비스를 했다. 그때는 검은 화면에 초록 또는 회색 글씨만 가득찬 화면 구성이라, 키보드 입력 편의성 개선이 제일 중요했다. 그런데 이후 [[PC]]가 보급되면서, 메인프레임이 독점했던 상당량의 컴퓨팅 자원을 굳이 메인프레임이 안 쓰고, 최종 사용자 단의 PC가 나눠져도 되는 환경이 됐으며, 이에 따라, 클라이언트/서버 환경으로 변화[* 라 쓰고, 업계에선 [[http://www.terms.co.kr/downsizing.htm|다운사이징]]이라 불렀다]했다. 이러한 컴퓨팅 환경이 재차 웹시대로 진화하고, 모바일 시대로 흘러가지만, 지금까지도 개발/관리 방법론은 폭포수 모형일 때의 것을 그대로 쓰고 있었다. 기술의 변화에 따라 개발 환경이 변했지만, 25년 동안 방법론의 변화가 없었던 것이다.

현실적으로 고객을 만족시키는 프로그래밍을 하자며, [[익스트림 프로그래밍]](extreame Programming)으로 고객의 요구사항을 주기적, 점진적으로 확인하며 일하고 싶지만, 소규모 프로젝트가 아닌 이상 이를 적용하는 것엔 한계가 있다. 적어도 6개월에서 2~3년씩 걸리는 금융사의 대형 차세대 프로젝트라든지, 정부기관 프로젝트를 하다 보면, 대금 수금의 문제로 다시 폭포수로 돌아가는 게 현실이다. 
== TY*agile[* [[http://www.tynetworks.co.kr/sub/business_rd.php]]]과 TY*eXtreame[* [[http://www.tynetworks.co.kr/sub/business_rd.php]]]을 활용한 제약사항의 극복 ==

이를 보완하고자 나온 게 애자일-익스트림(agile-extreame)이다. 고객을 이해시키기 위해 폭포수 모형 기반의 프로세스를 따르되, 각 프로세스의 상세 절차를 애자일 기법에 맞춰 프로토타입 기반으로 변형한 것이다. 애자일-익스트림(agile-eXtreame)은 개발 후반부에 발생할 문제를 전반부에 도출시켜 리스크를 최소화하고, 일정을 준수할 수 있도록 한 [[https://ko.wikipedia.org/wiki/소프트웨어 프레임워크|프레임워크]]로 다음 3가지 특징이 있다.

이용용이성(ease of use) 관점에서 보면, 투입되는 인력 중 고객과 밀접하게 커뮤니케이션 하는 인력은 프로젝트를 리딩하는 PM/PL급이고, 이들이 [[https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9A%A9%EC%9E%90_%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4]|UI]]와 [[https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9A%A9%EC%9E%90_%EA%B2%BD%ED%97%98|UX]]를 리딩하기엔 역부족이었다. 그래서, 화면을 담당하는 퍼블리셔[* [[https://mulder21c.github.io/2015/06/29/what-does-the-web-developer-do-overview/]]]를 대동했으나, 이들은 주로 협력사 인력이다 보니, 애자일 기반으로 순단 고용(한달은 고용하고 그 다음 달은 쉬고, 그 다음 달은 다시 고용하는 갑질의 끝판)하는 건 말이 안 된다는 현실적 한계가 있었다. 그래서, PM 또는 PL, 업무분석자 등 핵심 프로젝트 리딩인력이 익스트림 프로그래밍해 쉽게 고객에게 납품하려면, 커뮤니케이션 할 수 있는 툴과 자동생성되는 “준 문서”들이 필요하다.

각각의 업무 영역을 분절화(segmentation)하는 관점에서 보면, 기존의 개발은 [[데이터베이스|DB]] 준비, UI 완성, 그에 따른 프로그램[* event 기반이든, [[https://ko.wikipedia.org/wiki/%EC%A0%80%EC%9E%A5_%ED%94%84%EB%A1%9C%EC%8B%9C%EC%A0%80|Stored Procedure]]이든]이 모두 완성된 후에야 단위 테스트라도 가능하다. 그러다 보니 전반부에서 정의된 걸 고객이 바꾸면 멘붕이 온다. 고객은 그것 조금 바꾸면서 온갖 헐리웃 액션을 남발한다고 하겠지만, 아는 사람은 입술 꽉 깨물어도 나오는 신음을 못 막는다. 이를 막기 위해 익스트림프로그래밍하자는 것인데, 이런 식으론 허상뿐인 방법론에 지나지 않는다. [[http://www.tynetworks.com|동양네트웍스]]는 이러한 관점에서 분절화를 통해, 각 개발자가 역할별로 단위 테스트를 수행할 수 있고, 이것들이 유기적으로 돌아가도록 TY*eXtreame[* [[http://www.tynetworks.co.kr/sub/business_rd.php]]]이란 프레임워크와 코딩이 필요 없는 테스트/업무 자동화 툴[* [[http://www.tynetworks.com/sub/business_dt.php]]]을 보급 중이다.

재사용성(reusability)의 관점에서 보면, 한국사회의 특성을 일부 고려해야 한다. 대부분의 프로젝트는 일정에 쫓겨 프로그램을 찍어내듯이 만들고, 수없이 버그를 만나며, 그 디버깅에 과정에서 [[https://ko.wikipedia.org/wiki/%EC%A7%80%EC%B2%B4%EC%83%81%EA%B8%88|지체상금]]을 물지 않기 위해 오류가 어느 정도 있어도 오픈한 후, 안정화 기간을 통해 보완한다. 일정에 쫓기다 보니, 테스트는 대충하게 되고, 품질은 떨어지는 악순환이 계속되는데, 이를 극복하려면 [[http://support.suresofttech.com/ko/support/solutions/articles/5000760844-%ED%86%B5%ED%95%A9%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94-|통합테스트]]를 수차례 반복할 수 있도록 자동화 도구가 필요하다. 테스트 자동화 도구는 웹이던 앱이던 구분 없이 가능해야 하며, 도구가 아닌 사람으로 시나리오를 재사용하면 인건비 무덤에 빠지게 된다. 다행히 이런 자동화 도구가 없는 건 아니다. 파이온닷컴의 ATAM이란 도구가 있는데, 그나마 코딩 없이 파워포인트의 슬라이드 생성하듯 장면으로 테스트 시나리오를 구성할 수 있고, 동시에 수십 개의 시나리오도 돌릴 수 있다. 웹이든 모바일 앱이든 Device, OS, Browser에 구애를 안 받는다.
[[분류:프로그래밍]]