1. 기원
애자일 방법론에 따르면, 기존의 폭포수 모델의 고질적 단점(고객의 요구사항 변경, 숨은 개발 물량, 테스트 시 발견돼 설계를 변경해야 하는 중대한 결함, 개발일정 지연에 따른 지체상금, 고객의 부동의에 따른 대금 지급 저항 등)을 일거에 해결할 것 같다. 하지만 한국의 개발사 현실은 그리 녹록치 않다.고객이 요구하면서도 자기가 무슨 요청을 하는지 모르고, 그때는 동의했으나(심지어 문서에 날인 수준으로), 그 의미는 아니었다고 주장하며, 이미 계약해서 수행하고 있는데, 그 정도는 서비스로 해줄 수 있는 것 아니나며 윽박지르고, 결국 납기를 못 맞추면 지체상금을 물리겠다는 겁주기 등 개발 적폐가 만연해 있다. 그러나 대부분의 수행사는 고객의 잘못이 아니라며 울며 겨자 먹기로 감내하고 있다.
2. 태동 배경
김종식(現 동양네트웍스 전무)에 따르면, 이렇게 된 배경엔 다음과 같은 설이 가장 유력하다[1].원래 컴퓨팅서비스는 1990년대 후반까지만 해도 IBM 등의 공룡사업자가 만드는 메인프레임 판이었고, 이 메인프레임에 더미터미널 콘솔을 붙여 서비스를 했다. 그때는 검은 화면에 초록 또는 회색 글씨만 가득찬 화면 구성이라, 키보드 입력 편의성 개선이 제일 중요했다. 그런데 이후 PC가 보급되면서, 메인프레임이 독점했던 상당량의 컴퓨팅 자원을 굳이 메인프레임이 안 쓰고, 최종 사용자 단의 PC가 나눠져도 되는 환경이 됐으며, 이에 따라, 클라이언트/서버 환경으로 변화[2]했다. 이러한 컴퓨팅 환경이 재차 웹시대로 진화하고, 모바일 시대로 흘러가지만, 지금까지도 개발/관리 방법론은 폭포수 모형일 때의 것을 그대로 쓰고 있었다. 기술의 변화에 따라 개발 환경이 변했지만, 25년 동안 방법론의 변화가 없었던 것이다.
현실적으로 고객을 만족시키는 프로그래밍을 하자며, 익스트림 프로그래밍(extreame Programming)으로 고객의 요구사항을 주기적, 점진적으로 확인하며 일하고 싶지만, 소규모 프로젝트가 아닌 이상 이를 적용하는 것엔 한계가 있다. 적어도 6개월에서 2~3년씩 걸리는 금융사의 대형 차세대 프로젝트라든지, 정부기관 프로젝트를 하다 보면, 대금 수금의 문제로 다시 폭포수로 돌아가는 게 현실이다.
3. TY*agile[3]과 TY*eXtreame[4]을 활용한 제약사항의 극복
이를 보완하고자 나온 게 애자일-익스트림(agile-extreame)이다. 고객을 이해시키기 위해 폭포수 모형 기반의 프로세스를 따르되, 각 프로세스의 상세 절차를 애자일 기법에 맞춰 프로토타입 기반으로 변형한 것이다. 애자일-익스트림(agile-eXtreame)은 개발 후반부에 발생할 문제를 전반부에 도출시켜 리스크를 최소화하고, 일정을 준수할 수 있도록 한 프레임워크로 다음 3가지 특징이 있다.
이용용이성(ease of use) 관점에서 보면, 투입되는 인력 중 고객과 밀접하게 커뮤니케이션 하는 인력은 프로젝트를 리딩하는 PM/PL급이고, 이들이 UI와 UX를 리딩하기엔 역부족이었다. 그래서, 화면을 담당하는 퍼블리셔[5]를 대동했으나, 이들은 주로 협력사 인력이다 보니, 애자일 기반으로 순단 고용(한달은 고용하고 그 다음 달은 쉬고, 그 다음 달은 다시 고용하는 갑질의 끝판)하는 건 말이 안 된다는 현실적 한계가 있었다. 그래서, PM 또는 PL, 업무분석자 등 핵심 프로젝트 리딩인력이 익스트림 프로그래밍해 쉽게 고객에게 납품하려면, 커뮤니케이션 할 수 있는 툴과 자동생성되는 “준 문서”들이 필요하다.
각각의 업무 영역을 분절화(segmentation)하는 관점에서 보면, 기존의 개발은 DB 준비, UI 완성, 그에 따른 프로그램[6]이 모두 완성된 후에야 단위 테스트라도 가능하다. 그러다 보니 전반부에서 정의된 걸 고객이 바꾸면 멘붕이 온다. 고객은 그것 조금 바꾸면서 온갖 헐리웃 액션을 남발한다고 하겠지만, 아는 사람은 입술 꽉 깨물어도 나오는 신음을 못 막는다. 이를 막기 위해 익스트림프로그래밍하자는 것인데, 이런 식으론 허상뿐인 방법론에 지나지 않는다. 동양네트웍스는 이러한 관점에서 분절화를 통해, 각 개발자가 역할별로 단위 테스트를 수행할 수 있고, 이것들이 유기적으로 돌아가도록 TY*eXtreame[7]이란 프레임워크와 코딩이 필요 없는 테스트/업무 자동화 툴[8]을 보급 중이다.
재사용성(reusability)의 관점에서 보면, 한국사회의 특성을 일부 고려해야 한다. 대부분의 프로젝트는 일정에 쫓겨 프로그램을 찍어내듯이 만들고, 수없이 버그를 만나며, 그 디버깅에 과정에서 지체상금을 물지 않기 위해 오류가 어느 정도 있어도 오픈한 후, 안정화 기간을 통해 보완한다. 일정에 쫓기다 보니, 테스트는 대충하게 되고, 품질은 떨어지는 악순환이 계속되는데, 이를 극복하려면 통합테스트를 수차례 반복할 수 있도록 자동화 도구가 필요하다. 테스트 자동화 도구는 웹이던 앱이던 구분 없이 가능해야 하며, 도구가 아닌 사람으로 시나리오를 재사용하면 인건비 무덤에 빠지게 된다. 다행히 이런 자동화 도구가 없는 건 아니다. 파이온닷컴의 ATAM이란 도구가 있는데, 그나마 코딩 없이 파워포인트의 슬라이드 생성하듯 장면으로 테스트 시나리오를 구성할 수 있고, 동시에 수십 개의 시나리오도 돌릴 수 있다. 웹이든 모바일 앱이든 Device, OS, Browser에 구애를 안 받는다.
[1]
익스트림 프로그래밍
[2]
라 쓰고, 업계에선
다운사이징이라 불렀다
[3]
http://www.tynetworks.co.kr/sub/business_rd.php
[4]
http://www.tynetworks.co.kr/sub/business_rd.php
[5]
https://mulder21c.github.io/2015/06/29/what-does-the-web-developer-do-overview/
[6]
event 기반이든,
Stored Procedure이든
[7]
http://www.tynetworks.co.kr/sub/business_rd.php
[8]
http://www.tynetworks.com/sub/business_dt.php