소프트웨어 개발을 하다 보면 특정 방법론을 선택하는 경우가 보통이다. 최근 접한 익스트림 프로그래밍(extreme programming, 이하 XP)은 애자일 방법론의 한 갈래로, 빠르게 변하는 요구사항에 대응하면서 높은 품질의 소프트웨어를 개발하기 위한 접근 방법이다. 특정한 하나의 방법론이 소프트웨어 개발의 만능 열쇠가 될 수 없겠지만, 최근 XP 책을 읽으면서 '그래서 뭐가 XP이고, 무엇을 기준으로 하고 있다고 할 수 있는 거지?' 라는 생각이 맴돌기 시작했다. 부분은 이해 했지만 전체를 이해하지 못한 느낌이다. (물론 책을 다 읽기 전이다.)
의사소통과 협업.
XP 의 핵심 중 하나는 원활한 의사소통과 협업이다. 프로젝트가 진행 되는 동안 동료와 끊임없는 대화가 이루어져야 한다. 단순히 정보를 공유하는 목적을 넘어 상호 존중하고, 문제를 같이 해결함을 뜻한다. 만약 데일리 미팅을 통해 전체적인 진행 상황과 장애를 공유하고, 각 팀원의 프로젝트 목표와 현황을 상호 이해하고 있다면 XP 의 중요한 요소를 실천하고 있다고 판단할 수 있다.
단순성.
너무나 당연하게도 복잡한 설계는 유지보수와 유연한 확장을 어렵게 만든다. XP 에서는 필요한 기능만 구현하고, 나중에 필요할 때 추가하는 방식으로 단순성을 유지 한다. 이를 통해 코드의 가독성을 높이고, 변화에 유연하게 대처할 수 있다. 불필요한 기능을 (군더더기) 고려하지 않고, 당장 필요한 최소한의 것에만 집중할 수 있다면, 이것 역시 XP를 실천하고 있다고 판단할 수 있다.
빠른 피드백을 통한 개선.
XP 에서는 짧은 개발 주기를 통해 빠르게 피드백을 받아 제품의 품질을 지속적으로 개선하라고 한다. 이것은 반복적인 릴리즈(배포)와 테스트를 통해 가능하다. 내가 속한 팀이 짧은 주기로 소프트웨어를 배포 하고, 사용자(고객)로부터 피드백을 받아 즉시 개선 사항을 배포하고 있다면, XP 를 실천하고 있다고 판단할 수 있다.
변화에 대응하는 용기.
소프트웨어 개발을 하다보면, 다른 모든 일들도 그렇겠지만, 변화를 피할 수 없다. XP 는 변화를 두려워하지 말고, 필요한 경우 기존 코드를 과감하게 수정하는 용기를 강조 한다. 팀이 기술 부채를 인지하고 있고, 꾸준한 리팩토링을 통해 개선해 나가고 있다면 XP 를 실천하고 있다고 판단할 수 있다.
TDD(테스트 주도 개발)와 지속적인 통합.
XP 에서 코드 품질을 위해 TDD 를 권장 한다. (그래서 그런 것인지 잘 모르겠지만, XP 와 TDD 가 닮은 구석이 있는것 같다.) 모든 코드는 테스트를 먼저 작성한 후 개발 해야 한다. 그리고 지속적인 통합을 통해 코드 변경 사항을 자주 통합하고, 빌드와 테스트 자동화 시스템이 구축 되어 있다면, XP 를 실천하고 있다고 판단할 수 있다.
고객과 지속적인 협력.
XP 는 고객이 개발 과정에 적극적으로 참여 할 것을 권장 한다. 그래야 요구사항이 보다 명확해지고, 피드백 받는 것이 보다 쉬워지기 때문이다. 이 부분에 대해 회사 내부 시스템 소프트웨어 개발이 아닌 경우, 실제 고객을 포함하여 회의를 주체하는 것이 이상적이라는 생각을 하고 있지만, 만약 그게 가능한 환경이고 실천적 활동으로 팀이 하고 있다면 XP 를 하고 있다고 판단할 수 있다.
아직 책을 읽는 중이지만, '그래서 XP 를 한다는 것이 무엇인데?' 라는 질문이 이따금 떠올라 나름 정리를 해봤다.
기술적인 관점에서 소프트웨어를 개발하는 것도 중요 하지만, 읽고 생각하면 할 수록 결국 사람이 중요한 것 같다.
