최근 Agile 과 관련된 책을 많이 보고 있습니다. 집에 있을때는 XP Explained 를 읽고 있고, 차 안에 있을때는 Clean Code 를 읽고 있고, 학교에서는 Agile 과 관련이 있는 UML 책을 읽고 있습니다. 수업 시간에도 교수님께서 Agile 이랑 Use cases 에 대해 수업 하시고, 수업 중간 중간의 학생들 발표 숙제 하는거 들으면 내용의 반 이상은 또 Agile 관련입니다...

이렇게 Agile 에 완전히 둘러 쌓여서 살고 있다 보니, 거의 세뇌가 되어가는 수준으로 Agile 이 바로 내 갈길이라는 생각이 점점 더 강해지고 있습니다. 특히 게임 개발 처럼 기획자의 요구 사항이 자주 변하고 기술적으로 Re-factoring 을 많이 해야하는 프로젝트에는 더 할나위 없이 딱 맞는 개발 방법론이라는 일종의 확신을 가지게 되었습니다.

그래서 오늘은 Agile 에 대해 그간 제가 습득한 정보들을 좀 요약해보려고 합니다.

UML Distilled 라는 책의 설명에 따르면 1997년 경까지 여러 이론가들(Meteorologist)이 서로 서로 자기내 방식이 더 좋다고 싸우던 전투가 UML 의 승리로 끝이났다고 합니다. 그리고 제가 이곳 저곳에서 주워 들은 정보들을 종합해보면, 그 후로 급속히 UML 을 사용한 설계 방법론들이 쏟아져 나오게 되었습니다. OOA (Object-Oriented Analysis) 와 OOD (Object-Oriented Design)을 줄여서 OOAD 혹은 OOA/D 라고 부르는데, 이게 실제로 회사에서 적용해 보니까 잘 안되더라는 것이 드러났던것 같습니다.

예전에 정훈이랑 재정이랑 강남에서 술마시면서 하던 이야기 중에 어느 유명한 누구 누구가 코딩 한줄 안하고 설계 부터 끝낸뒤에 코딩을 해서 프로젝트를 저비용으로 끝냈더라 라는 이야기를 무슨 영웅담 듣듣이 들었던 기억이 납니다. 그런데 사실 현실에서 UML 만을 사용해서 설계 한것들이 막상 코딩으로 구현하려고 하면 문제가 발생하더라는 것이 일반적인 의견인것 같습니다. UML 버전 2 의 표준화 작업에 동참했던 UML 의 대가 Martin Fowler 는 자신의 책 UML Distilled 3rd, 2003 에서 자기 자신도 UML 만 가지고 설계 안한다고 적고 있습니다. 그러면서 UML 을 "스케치" 용으로 만 사용할것을 권하고 있습니다.

이런 관점에서 보면 1999년에 Jacobson 이 Unified Process (이하 UP) 라는 개발 방법론을 제시한 것도 일종의 같은 맥락에서 필연적이었던게 아닌가 싶습니다. 왜냐하면 1997년 UML 의 성공후 OOA/D 의 주요 개발 도구로 UML 이 사용되었는데 "설계"를 먼저 완벽하게 끝내고 "구현"으로 넘어가던 기존의 폭포수 (waterfall) 모델로 프로젝트를 진행하려고 봤더니, "설계가 엉망이어서 코딩이 안된다"는 비난을 받았을 겁니다. 왜냐하면 UML 만으로 설계를 하고 나면 항상 구현할때 불일치가 발생하기 때문입니다.

여기에 UP 개발 방법론은 iteration 이라는 새로운 용어를 사용하면서 "분석/설계/구현/테스팅" 의 싸이클을 짧게 여러번 갖으면 결과물을 성장(incremental) 시켜가면서 프로젝트를 진행할것을 제안하는 방법론입니다. 사실 "결과물을 성장" 시킨다고 대부분 설명하지만 제가 볼때는 "설계"를 성장 시키는데에 중요한 비중이 있는 것 같습니다. 이런 방법을 통해 설계가 구려서 코딩이 안된다는 현실적인 문제점을 개선하려고 한것 같습니다. 물론 이것은 어디까지나 하나의 관점일 뿐이고, 사실 더 큰 그림에서 보면 요구사항의 변화에 빠르게 대응할 수 있게 된다는 점이 더 큰 특징이라고 볼수 있겠습니다.

아무튼 1997년에 UML 1.0 이 발표되고, 1999년에 UP 가 제안되고, 2000년에 Rational UP 라는 좀더 발전된 형태의 UP 가 제안되었습니다. 이런 변화의 흐름에 힘을 더욱 받아서 2001년에는 Agile 동맹이라는 것이 형성되었습니다.

Agile 이라는 것은 Umbrella Term (우산 용어??) 이라고 하는데요, 여러가지 자잘하게 새로 생겨나는 개발 방법론들을 싸잡아서 통칭하는 용어라고 할수 있습니다.

그리고 나서 설계나 개발 방법론에 대한  논문이나 책을 을 검색해보면 2001년 경을 정점으로 해서 2004년까지 출판되는 것들의 량이 점점 줄어들다가 2002년 Robert C. Martin 의 "Agile Software Development" 이 출간된 이후 혹은 좀 더 넓게 잡아서 2004년 UML 2.0 이 발표된 이후로는 관련해서 출간된 책이 전혀 없다 시피 합니다.

물론 2004년 이후로 Agile 이라는 용어가 점점 더 유행하면서 주류 개발 방법론으로 자리를 굳혀가게 되었고, 거기에 맞춰서 관련된 책들의 출판 량이 상당히 증가한것을 도서관에서 확인할수 있었습니다. 하지만 제가 지적하는 것은 UML 이나 설계, 패턴, 분석, 개발 방법론과 관련된 대가들의 활동이 거의 정지하다 시피 했다는 점입니다.

이렇게 이렇다할 차새대 기술의 등장이 정지 한 가운데 Agile 관련 실험 논문들의 량이 하나씩 출간되기 시작하면서 지금은 거의 학계에서도 Agile 이라는 용어가 별다른 정의 없이도 받아들여질 정도가 된것 같습니다.

최근의 동향은 어떻게 하면 Agile 이라고 하는 정의자체 부터 모호한 방법론을 나의 프로젝트에 도입할 수 있을까 하는 것입니다. Agile 이라는 것이 사실 자세히 들여다보면 이것 저것 여러 종류의 기술들을 최대한으로 도입하는 방식입니다. 설계하는 과정이 따로 존재하지는 않지만 Re-factory 를 하면서 설계를 항상 개선 시키고 있기 때문에 설계의 중요도가 오히려 더 높습니다. 프로젝트 진행에 대한 자동화도 중요하게 다루어지고 있고 설계 패턴이나 사소한 코딩 스타일 까지도 모두 망라해서 깊은 이해를 요구 하기 때문에, Agile 을 도입한다는 것 자체가 프로그래밍이나 설계 다방면에서 완벽해 질것을 요구하는 것과 같은 개념입니다.

이런 특징 때문에 Agile 을 도입하려고 했다가 프로젝트가 망했다고 하더라도 Agile 을 탓하지 않고 프로그래머들이 Agile 을 도입하지 못해서 망한것이라는 비판으로 결론지어 지게 됩니다.

또 한가지 최근 동향들 중의 하나는 요구사항 추적 (Requirement Traceability) 입니다. 짧은 iteration 이 여러번 반복되면서 요구 사항이 수시로 변경되게 되는데, 이로 해서 프로그램의 잦은 변화가 불가피 하게 됩니다. 그런데 이렇게 요구 사항이 변경되고 나면 관련된 테스트 코드나 실제 코드들도 그 변화를 정확히 반영해야하는데, 실제로 해보면, 요구사항은 변경되었어도 테스트 코드는 그대로 남아있기 때문에 실제 프로그램의 행동이 변하질 않는 문제가 발생하는 것입니다. 이런 문제를 해결하기 위해서 요구 사항을 작성할때 관련된 테스트 코드들과 링크를 만들고 요구 사항이 변경되면 변경된 요구 사항과 관련된 테스트 코드들을 파기 하는 형식의 추가 관리를 하는 것입니다. 이 작업을 아직까지 자동화 시켜줄 방법이 없기 때문에, 수작업으로 해야하는데, iteration 도입으로 발생한 새로운 형태의 부작용이라고 할수 있겠습니다.


제가 지금까지 이해한 바로는 Agile 의 특징은 4가지로 간단히 요약할수 있을것 같습니다.

1. 빠른 반복 주기 (iteration)
2. Re-factor
   
3. 짝 프로그래밍 (Pair-Programming)
4. 테스트 우선 개발 (TDD)
   

Agile 의 정의가 모호하기 때문에 자신의 프로젝트에 맞게 적용해야한다고 강조하지만, 제가 보기에 이 4가지 중의 한개라도 빠지면 사실 Agile로 보기 어려운것 같습니다. 빠른 주기는 당연히 가장 큰 특징이라 빠질수 없지요.

Agile 의 가장 큰 특징들 중의 하나는, 프로그램이 성장한다는 점입니다. 이 특징은 물론 빠른 반복 주기 때문에 생겨난 것입니다. 그런데 이렇게 성장하려면 Re-factor 가 필수적입니다. 그리고 이렇게 Re-factor 를 할수 있으려면 프로그래머가 설계와 설계 패턴에 어느 정도 이상 익숙한 전문가(Expert)여야 하는데, 아무리 훌륭한 팀이라도 전문가의 수는 한정되어있습니다. 때문에 짝 프로그래밍을 통해서 전문가들에게 좀 더 생각할 시간을 많이 할애해 주고, 신참에게 키보드 타이핑 작업(Driver)을 하도록 분업화 시키는 것입니다. 그리고 짝이 항상 바뀔수 있다는 규칙 때문에 소수의 전문가가 소스 코드 이곳 저곳을 두루 둘러보면서 코드 청소(Clean Code)를 할수 있게 됩니다.

이점은 기존의 "책임 중심 작업 분담"과 구분되는 것인데, 예를 들어, "내가 Ui 를 책임 지고 만들겠다", "네트워크는 내가 책임 프로그래머다", "암호화는 저 친구가 책임지고 있지" 이런식이 기존 작업 분담 방식입니다. 그리고 다른 사람이 책임지고 있는 영역에는 서로 관심을 끊고 살게 되면서 시간이 갈수록 분절의 벽이 높아지고 대화도 없어지게 되는 것이지요. 이런 문제점을 짝 프로그래밍이 해결하면서 전체적인 코드가 항상 전문가들에 의해 깨끗이 청소된 상태로 유지되게 하는 것입니다.

여기에 테스트 우선 개발 방식이 도입되어서 Re-factor 할때의 위험 부담을 낮추어 줍니다.

이런 이유 때문에 제가 생각하기에는 위의 4 가지는 서로 강하게 연관되어있는 것이고, 이들중 한가지라도 빠지면 Agile 의 장점을 발휘하고 있는 프로젝트라고 보기 어렵다고 생각합니다.

아무튼 최근 Agile 공부하는데 시간을 많이 할애하고 있습니다. 그리고 지금까지 이해한 것을 간단히 적어봤습니다. 또 공부하다가 새로 배우게 되는 것들이 생기면 또 몰아서 정리해보겠습니다.