S/W 개발 방법론의 반항아「익스트림 프로그래밍」

ZDNet : 마이크로스프트웨어 에서 읽은 내용임.

S/W 개발 방법론의 반항아「익스트림 프로그래밍」 전통적인 소프트웨어 개발 방법론과는 달리 문서를 강조하지 않고 변경을 장려하며, 개발 초기부터 테스트를 병행할 것을 강력히 권고하는 새로운 방법론이 있습니다. 바로 '익스트림 프로그래밍(eXtreme Programming ; XP)'이라는 방법론으로, 우리나라에서는 대략 3년 전부터 관심을 끌기 시작했습니다. 김기주 (마이크로소프트웨어) 2004/02/16 컴퓨터가 발명되고 소프트웨어가 개발되기 시작한 이래로, 시간이 흐르면 흐를수록 소프트웨어는 점점 더 그 규모가 커지고 복잡해지기만 합니다. 초창기에는 컴퓨터 시스템 개발비용의 대부분이 하드웨어 개발비였으나, 요즘은 하드웨어 개발비용보다 소프트웨어 개발비용의 비율이 더 높다고 합니다. 소프트웨어 개발의 비중이 높아지면서 소프트웨어 개발 방법에 대해서 많은 사람들이 고민했고, 그 결과로 여러 가지 소프트웨어 개발 방법론이 제안됐습니다. 소프트웨어 개발의 각 단계를 나타내는 라이프사이클(lifecycle) 모델로 대표적인 폭포수 모델(waterfall model, <그림 1>)도 제안됐고, 요즘은 이를 개선한 나선형 모델(spiral model, <그림 2>)이 많은 지지를 받고 있기도 합니다. 폭포수 모델은 소프트웨어 개발의 각 단계를 구분했고, 각 단계에서 해야 하는 일을 명확히 했습니다. 하지만 개발 과정을 단순하게 나타내는 단점이 있고, 이전 단계에서 한 일에 대한 오류가 나중 단계에서 밝혀질 경우 이를 바로잡기 위한 작업을 나타내지 못하는 문제가 있습니다. <그림 1> 폭포수 모델 <그림 2> 나선형 모델 이에 비해 나선형 모델은 전체 시스템이 갖춰야 할 특성을 단계별로 나누어, 각 단계별로 폭포수 모델에서 제시한 것과 비슷한 단계들을 밟아 조금씩 시스템의 완성도를 높여가는 방식의 소프트웨어 개발 과정을 그리고 있습니다. 나선을 따라 한 바퀴 돌 때마다 이전 단계에서 미흡했던 부분을 보완할 수 있고, 개발 일정을 모두 마쳤을 때에만 구현된 소프트웨어를 볼 수 있었던 폭포수 모델과는 달리, 각 바퀴를 돌 때마다 부분적으로 완성된 시스템을 볼 수 있다는 장점이 있습니다. 익스트림 프로그래밍 우리나라에서는 대략 3년 전부터 관심을 끌기 시작한 것으로 보이는데요, 이 방법론이 만들어진 것은 1990년대 중반이라고 합니다. 위원회에서 만들어진 알골(ALGOL)보다 개발자에 의해 만들어진 C 언어가 더 널리 쓰이게 된 것을 생각하면, 연구소 등에서 만들어진 기존의 다른 방법론보다 아마도 회사에서 경험적으로 만들어진 익스트림 프로그래밍(XP)이 개발자들에게 좀 더 가깝게 다가올 것 같기도 합니다. 지금부터 XP에 대해서 알아보겠습니다. 1996년 켄트 백(Kent Back)과 워드 커닝험(Ward Cunningham)은 함께 다임러 크라이슬러 프로젝트를 진행하면서 새로운 소프트웨어 개발 방법을 정리하게 되는데, 그것이 XP 방법론입니다. XP는 고객이 원하는 소프트웨어를 고객이 원하는 시기에 제공하는 것을 목표로 하며, 프로젝트 막바지에도 나올 수 있는 요구사항 변경에 더욱 잘 대처할 수 있도록 합니다. 소프트웨어 프로젝트를 개선하기 위해 켄트 백은 네 가지 요소가 중요하다고 했는데, 이것은 의사소통(communication), 단순성(simplicity), 피드백(feedback), 그리고 용기(courage)입니다. XP 개발자들은 고객 및 동료 개발자들과 의사소통을 잘 해야 하고, 개발하는 소프트웨어에 대해 개발 첫 날부터 유닛 테스트를 통해 피드백을 받습니다. 개발 중인 시스템을 최대한 빨리 고객한테 보여줌으로써 고객들이 원하는 변경 사항을 빨리 도출할 수 있으며, XP 개발자들은 이러한 기초 위에서 요구사항이 계속 바뀌더라도 용감하게 나아갈 수 있습니다. <그림 3> 전통적인 변경 비용 곡선 <그림 4> 켄트 백의 변경 비용 곡선 지금까지 XP의 탄생과 중요시하는 요소(value)에 대해 알아보았습니다. 이제부터 XP의 대표적인 작업들을 따라가며 XP가 구체적으로 어떻게 이뤄지는지 알아보겠습니다. <그림 5> 익스트림 프로그램 프로젝트 유저 스토리 XP를 이용해서 프로젝트를 시작한다면 먼저 유저 스토리(user story)를 모아야 합니다. 유저 스토리는 일종의 요구사항(requirement)입니다. 폭포수 모델이나 나선형 모델에서 ‘Requirements Process’나 ‘Software Requirements’ 단계를 거치는 것과 비슷합니다. 유저 스토리는 UML(Unified Modeling Language)의 유스 케이스(<그림 6>)와 같은 목적으로 만들어지지만 형식이 없고(informal) 고객에 의해 작성된다는 것이 다릅니다. <그림 6> 유스 케이스 다이어그램 유저 스토리는 시스템이 고객을 위해 해야 하는 일들을 담고 있고, 유저 인터페이스 외의 요구사항도 포함할 수 있으며, 개발자의 말이 아니라 고객의 말로 쓰여야 합니다. 유저 스토리를 가지고 개발 일정(release plan)을 잡게 되고, 뒤에 설명할 승인 테스트(acceptance test)를 만드는 토대가 됩니다. 유저 스토리가 전통적인 소프트웨어 개발 방법론의 요구사항 명세(requirement specification)와 크게 다른 것은 유저 스토리에는 요구사항 명세처럼 세세한 것까지 적지 않는다는 것입니다. 유저 스토리에는 그것을 구현할 때 얼마나 걸릴 것인가를 예측할 수 있을 정도로만, 그것의 구현에 있어 주요한 어려움(risk)이 어떤 것이 있을지를 살펴 볼 수 있을 정도로만 적으면 됩니다. 구현하기 위해 필요한 세부사항은 해당 유저 스토리를 구현할 때 고객을 만나 다시 들으면 된다는 것이죠. ‘시간과 돈이 충분한 프로젝트는 없다’는 말이 있습니다. 주어진 고객의 요구사항을 모두 구현한다는 것이 거의 불가능하다면, 구현하지도 않을 요구사항을 자세히 명세하느라 시간을 낭비하느니 간략하게 적어서 전체 일의 크기만 가늠하고, 실제 구현할 것만 그때그때 자세히 알아보는 것도 좋은 생각인 것 같습니다. 스파이크 솔루션 유저 스토리가 만들어지면 그 가운데 어려워 보이는(risky) 문제에 대해 스파이크 솔루션(spike solution)을 만듭니다. 스파이크 솔루션은 기술적 또는 설계상의 어려운 문제를 해결하기 위한 것입니다. 스파이크 솔루션은 숨어 있을 수 있는 문제를 찾아내기 위한 아주 간단한 프로그램입니다. 처리해야 하는 문제 외의 다른 조건들은 모두 무시하고 프로그램을 만듭니다. 대부분의 스파이크 솔루션은 계속 두고 쓸 정도로 좋지는 않으므로 조만간 짜야 합니다. 스파이크 솔루션을 만드는 목적은 기술적인 문제를 줄이고 유저 스토리를 가지고 추정한 개발 일정에 대한 신뢰도를 높이는 것입니다. 주기 계획 각 주기가 시작될 때마다 주기 계획 회의(iteration planning meeting)를 합니다. 각 주기는 1～3주 정도입니다. 각 주기에 처리할 유저 스토리는 고객이 고릅니다. 고객에게 가장 가치있는 부분을 가장 먼저 만들기 위함입니다. 처리할 유저 스토리는 이를 구현하기 위한 프로그램 과제(programming task)로 나눠집니다. 유저 스토리를 고객의 말로 적는 데 비해 과제는 개발자의 말로 적습니다. 각 과제를 개발자에 할당하고 소요기간을 예측하게 되는데, 같은 일이라도 소요기간은 사람마다 다를 수 있기 때문에 예측은 반드시 담당 개발자가 합니다. 각각의 과제는 하루에서 사흘까지 걸리게 됩니다. 하루가 안 걸리는 과제는 몇 개를 묶어서 하나로 만들고, 사흘보다 더 걸리는 과제는 더 잘게 나눕니다. 각 주기에 할 일이 너무 적거나 너무 많으면 처리할 유저 스토리를 더하거나 뺍니다. 유저 스토리를 가지고 예측했던 소요시간은 과제를 가지고 예측한 것으로 보완합니다. 계획에 포함되어 있지 않는 기능을 추가하려고 하면 안됩니다. 계획되지 않은 기능을 추가하려다보면 계획된 개발 기간을 초과하게 됩니다. 추가하고 싶은 기능이 있으면 그에 대한 유저 스토리를 추가하고 다음 주기를 기약합니다. <그림 7> Iteration 주기 개발 각 주기의 길이를 비슷하게 유지하는 것이 좋습니다. 각 주기의 길이가 일정하면 프로젝트 진행에 대한 측정과 계획이 쉽고 믿음직스럽게 됩니다. 프로그램 과제를 미리 스케쥴하면 안됩니다. 각각의 주기에 해야 할 일은 해당 주기가 시작될 때 주기 계획 회의를 통해 결정합니다. 고객의 요구사항은 계속 바뀌기 때문에 미리미리 계획해두지 않는 것이 좋습니다. 주기 데드라인을 엄수해야 합니다. 주기 중 진척상황을 확인해서 데드라인을 넘길 것 같으면 주기 계획 회의를 다시 소집해서 일부 과제를 빼야 합니다. 다른 과제를 구현 안 된 채로 남기더라도 고객이 고른 가장 중요한 과제에 집중합니다. 승인 테스트 주기가 시작되면 주기 계획 회의에서 골라진 유저 스토리를 가지고 승인 테스트를 만듭니다. 여기서도 고객이 참여해 구현될 코드를 검사할 시나리오를 만들게 됩니다. 승인 테스트는 블랙박스 테스트입니다. 고객은 승인 테스트가 올바르게 만들어졌는지를, 그리고 실패한 테스트의 중요도를 확인합니다. 승인 테스트는 또한 나중에 리그레션 테스트(regression test)로도 쓰입니다. 승인 테스트를 통과해야 유저 스토리에 대한 처리가 완료됩니다. 승인 테스트를 자동화해서 자주 테스트하는 것이 좋습니다. 승인 테스트를 통과한다는 것은 고객의 요구사항을 만족한다는 뜻입니다. 유닛 테스트 개발을 하다보면 종종 한 두 사람이 맡고 있는 부분이 늦어져서 전체 프로젝트를 지연시키는 수가 있습니다. 이 경우 다른 사람들이 도와줄 수 있다면 좋을 것입니다. XP에서는 집단 코드 소유(collective code ownership, <그림 8>)라고 하는데, 필요하면 누가 어떤 코드든지 고친다는 뜻입니다. 이렇게 하기 위해서는 유닛 테스트(unit test)가 필요합니다. 유닛 테스트는 XP의 초석(cornerstone) 가운데 하나입니다. 유닛 테스트는 자주 실행할 수 있도록 자동화돼야 하고(JUnit과 같은 유닛 테스트 프레임워크를 이용하기도 합니다), 모든 모듈을 테스트할 수 있도록 만들어져야 합니다. 그리고, 될 수 있으면 코드를 작성하기 전에 유닛 테스트를 작성하는 것이 좋습니다. 유닛 테스트는 코드와 함께 코드 저장소(code repository)에 저장됩니다. 프로젝트를 진행하게 되면 언제나 시간이 모자라기 때문에 유닛 테스트를 만드는 시간이 아깝게 느껴지기 쉽습니다. 하지만 자동화된 유닛 테스트는 문제점을 찾아내는 데 있어서 훨씬 더 많은 시간을 절약해 주는 것으로 알려져 있습니다. <그림 8> 집단 코드 소유 찻길 한복판으로 걸어가면 사고가 난다 얼마 전까지만 해도 XP는 문서작업을 강조하지 않고, 컴퓨터 한 대를 놓고 두 사람이 짝 프로그래밍(pair programming)을 하며, 리팩토링(refactoring)이란 방법으로 끊임없이 코드를 고치는 개발 방법론으로 알고 있었습니다. 물론 이런 것들도 XP의 요소이기는 하지만 이것보다는 앞에서 얘기한 전반적인 절차가 XP를 더 잘 설명하는 것 같습니다. XP는 애자일 방법론(agile methodology) 가운데 하나입니다. 애자일 방법론은 고객에게 고객이 원하는 소프트웨어를 빨리 전달하는 것을 목표로 합니다. 1～3주 내에 구현할 수 있는 수많은 요구사항(유저 스토리) 가운데 고객이 가장 중요하게 생각하는 것을 먼저 구현합니다. 시간이 모자라면 유저 스토리 가운데도 고객이 가장 중요시하는 과제를 먼저 구현합니다. 프로젝트가 예측한 시일 안에 끝날 수 있도록 1～3주마다 진행상황을 점검하고 다음 1～3주 동안 할 일을 계획합니다(주기 계획 회의). 유닛 테스트를 통해 구현된 코드가 유저 스토리를 만족한다는 것을 확실히 합니다. 유닛 테스트를 이용함으로써 틈틈이 리팩토링을 통해 코드의 질도 높일 수 있습니다. 짝 프로그래밍은 개발자 사이에 의사소통을 원활히 하는 한 방법이고, 코드와 동떨어지게 되거나 그렇지 않아도 읽어 볼 사람이 없는 문서라면 만들지 않습니다. 심지어 요구사항 분석이나 구현 일정도 당장 구현할 내용이 아니라면 자세히 만들지 않습니다. 요구사항은 종종 바뀌고 미리 만든 계획은 쓸모없어지기 때문입니다. 하지만 XP를 도입하고자 할 경우 주의해야 할 것들이 있습니다. 사람이란 원래 편하고 쉬운 것을 택하고 불편하고 어려운 것은 버리고자 하는 경향이 있기 때문에, 문서를 만들지 않는다든지, 미리미리 계획하지 않는다든지, 세세하게 설계하지 않는다든지 하는 것은 받아들이기 쉽지만, 코드를 작성하기 전에 유닛 테스트를 만든다든지 틈틈이 리팩토링을 한다든지, 고객과 자주 만나 주기 계획 회의를 한다든지 구현이나 승인 테스트를 위한 세부 스펙을 정한다든지 하는 것은 등한시하기 쉽습니다. 예전에 어떤 무술 영화에 이런 말이 나옵니다. “길 이쪽 편으로 다니면 안전하고, 길 저쪽 편으로 다녀도 안전하다. 하지만 찻길 한복판으로 걸어가면 사고가 난다.” 기존의 방법론을 제대로 사용해도 효율은 떨어질지 모르지만 안전하게 프로젝트를 수행할 수 있고, 새로운 방법론을 제대로 익혀 사용해도 프로젝트를 안전하게 수행할 수 있습니다. 하지만 새로운 방법론을 어설프게 따라하다가는 프로젝트를 위험에 빠뜨리게 됩니다. 시간이 모자랄 때 구현하지 않게 될 지도 모를 부분을 미리 자세히 설계해 둘 필요가 없다는 말이지 스펙이 닥치는 대로 일단 코딩부터 하고 보면 된다는 것은 아닙니다. 읽지 않을 문서를 만드느라 시간과 노력을 낭비하지 않는 대신 소스 코드에 충실한 코멘트를 달아야 합니다. 함께 일하는 사람이 꼭 읽어야 할 문서가 있다면 반드시 만들고 언제나 소스 코드와 일치하는 정보를 지니도록 갱신해야 할 것입니다. 참고자료를 보면 XP를 도입하고자 하는 사람들이 주의해야 할 사항들이 잘 정리되어 있습니다. 새로운 방법론을 대할 때에는 확실히 공부하고 정말 중요한 것이 무엇인지 잘 생각해서 받아들여야 합니다. 개발 일정에 쫓겨 프로젝트에 대한 통제력을 잃고 있다면, XP와 같은 새로운 방법론도 공부해 보고 현재의 개발 관행에 대해서도 다시 한번 돌아보기 바랍니다. @