[Programming] XP 방식: Extreme Programming Practices

XP 방식: Extreme Programming Practices

---

포스트 난이도: HOO_Middle

[Notice] 포스트 난이도에 대한 설명

---

 

# XP 방식: Extreme Programming Practices

이번 포스트에서는 XP 모델 기반으로 개발을 진행할 때 지켜야 할 방식에 대해서 살펴보도록 하겠다. 이 포스트를 읽는 Bro들은 기본적으로 애자일 방법과 XP 방식에 대해서 이해를 하고 있다는 가정 하여 이야기를 나누어 보도록 하겠다. 혹시나 애자일 방법론에 대해 이해하지 못한 Bro는 필자의 다른 포스트를 참고하길 바란다.

XP 방식에 대해서 아주 잠깐 Summary식으로 이야기를 나누어보자면, 대표적인 애자일 방법론이면서 정말 개발자는 죽어나가고 경영진은 좋아하는 개발 방식이다. 여기서 중요한 점은 개발자가 죽어나가서 프로젝트 진행이 안되면 문제가 생기기 때문에 XP 개발 방식으로 소프트웨어를 개발할 때 지켜야 하는 것 중에 하나가 체력도 포함된다. 그래서 더 무섭다.

# Incremental Planning

애자일 방법론이기 때문에 Incremental planning을 한다고 이해해도 좋지만 사실상 XP 개발 모델은 사용자 또는 고객이 말한 내용을 Plan으로 바꾸어야 하기 때문에 이 과정이 중요하다. 사용자나 고객이 소프트웨어 개발에 대한 문서는 주겠지만 이것을 바로 개발에 활용할 수 있는 document가 되는 건 아니다. 예를 들어 말로써 기능적인 부분을 설명하거나 종이에 쓰여 있지만 개발자 입장에서 쓰인 게 아니라 일반인 기준에서 작성된 서류일 것이다. 따라서 이러한 내용들을 개발 단계별로 나누어서 적용해야 하기 때문에 Incremental planning이 필요한 것이다. 한마디로 고객 또는 사용자가 stories를 이야기하면 개발자는 그것을 tasks로 변경하는 작업이 바로 이 방식인 셈이다.

 

# Small releases

Small releases란 기본적인 기능만을 우선적으로 개발한다는 것을 의미한다. XP 개발 방식은 incremental 방식을 채택하고 incremental planning이 이루이지기 때문에 먼저 우선시되는 기능부터 개발하고 점진적으로 추가하는 방식을 채택하고 있다. 따라서 처음부터 특정 부분을 구체적으로 구현하기보다는 전반적으로 필요한 기능을 우선적으로 개발하는 방식이 바로 Small releases이다.

 

# Simple design

XP 개발 방식에서는 디자인을 큰 비중으로 고려하지 않는다. 그렇다고 디자인을 아예 하지 않는 것은 아니다. 디자인은 requirments에서 정해진 부분에 대해서만 디자인이 이루어진다. 이 외의 디자인은 하지 않는 것이 바로 XP 개발 방식이다. 그 이유는 다른 규정 또는 방식에서 이해할 수 있지만, XP 개발 방식은 정말 많은 수정과 테스팅 과정을 거친다. 따라서 디자인이 복잡하거나 많을수록 수정과 테스팅이 복잡하고 어려워진다. 심지어 힘들게 한 디자인이 최종 소프트웨어에서 사용이 되지 않을 가능성이 있기 때문에 필요한 디자인만 한다.

 

# Test-first development

XP 개발 원리에서 알고 있겠지만 정말 많은 testing 과정을 거친다. 개발 시간의 많은 시간을 testing에 시간을 드린다고 해도 과언이 아니다. 따라서 XP 개발 방식에서는 효율성을 증대시키기 위해서 Automated unit test framework를 활용한다. 개발자가 testing 때마다 testing을 위한 programming을 할 필요 없이 정해진 automated testing을 통해 효율적인 소프트웨어 테스팅이 가능하다.

 

# Refactoring

Refactoring은 말 그대로 Refactor를 해야 한다는 것이다. XP 개발 과정은 지속적인 Refactor가 이루어진다. Refactor 과정이 필요한 이유는 코드의 심플함과 간단한 유지 관리성을 위해서 하는 거지만 실질적으로 보면 차질없는 XP 개발 과정을 위해서 하는 것이다. Refactoring이 사소해 보일 순 있지만 사실상 정해진 기한 내에 XP 개발 과정을 진행하기 위해서는 XP 개발 방식들이 모두 다 잘 적용되고 수행되어야만 한다. Refactoring은 마치 기본적으로 다른 방식들이 잘 수행되기 위해서 필요한 부분인 셈이다. 예를 들어 우리가 공부하기 전에 주변 정리를 깔끔하게 하는 것이 집중을 더 잘하게 만드는 것처럼 Refactoring도 이와 비슷하다고 생각하면 이해하기 쉬울 것이다.

 

# Pair programming

XP 개발 방식의 주요한 특징 중에 하나가 바로 Pair programming이다. Pair는 쌍을 의미하는데 예를 들면 양말 한 켤레 했을때 두 짝을 의미하는 거와 같다. 따라서 Pair programming은 두 개발자가 서로의 개발 내용이나 업무를 확인하고 검토한다. 이를 기반으로 항상 최고의 결과물을 산출할 수 있다. 두 개발자가 각기 다른 업무를 하는 것이 아니라 같은 업무임에도 서로의 작업을 확인하고 검토하여 최고의 방식을 채택하여 소프트웨어에 적용한다고 생각하면 된다.

 

# Collecitve ownership

Coolective ownership은 한마디로 모든 개발자가 모든 개발 과정에 대해 잘 알고 있어야 한다는 것이다. 예를 들어서 인공지능 프로그램을 개발한다고 했을 때 머신러닝 부분과 빅데이터 플랫폼 전문 개발자가 팀에 따로 있는 것이 아니라 모든 개발자가 인공지능 프로그래밍 가능하면서도 빅데이터 플랫폼 구축에 대한 부분을 잘 알고 있어야 한다. 따라서 개발자 간의 업무가 변경되더라도 문제없이 업무 수행이 될 수 있을 정도로 소프트웨어 개발에 전반적인 내용을 모든 개발자가 master 하고 있어야 한다는 것이 바로 Collective ownership 방식이다.

 

# Continuous integration

XP 개발이 힘들다고 하는 이유는 바로 이것 때문이기도 하다. Continuous integration이라는 의미에서 이미 예상이 되겠지만 모든 과정이 통합되어 하나의 소프트웨어로 구현되어야 한다는 것이다. 새로운 작업을 통해 변경되거나 추가된 tasks가 있다면 여기서 끝나는 것이 아니라 해당 부분을 전체 시스템으로 통합하여 구현해야 된다는 것이다. 왜냐하면 이를 기반으로 testing 과정을 거쳐야 하기 때문이다.

 

# Sustainable pace

XP 개발 과정에서 개발자의 체력도 지켜야할 방식 중에 하나이다. 여기서 말하는 체력이란 프로젝트가 끝날 때까지 개발자가 문제없이 프로젝트에 참여할 수 있는 걸 의미한다. XP 개발 방식이 개발자를 힘들게 하는 이유도 있겠지만 XP 개발 방식은 참여 개발자 한 명이 빠지면 프로젝트 진행이 어렵다. 따라서 참여한 개발자들이 모두 제 역할을 꾸준히 해 주어야지만 최종적인 소프트웨어 개발이 이루어지기 때문에 체력 관리가 중요하다. Extreme이라는 의미와 무색하게 XP 개발 방식은 과도한 업무를 지양한다. 개발자들이 할 수 있는 범위 내에서 지속적으로 업무를 수행할 수 있는 걸 지향한다.

 

# On-site customer

On-site customer란 소프트웨어 사용자 또는 고객이 처음부터 끝까지 개발 과정에 참여해야 한다는 걸 의미한다. 한마디로 개발 과정에서 모두 참여하기 위해서는 팀의 일원으로써 같이 개발과 테스팅 등 모든 과정에 참여해야 한다. 사용자 또는 고객은 최종적으로 소프트웨어를 사용하는 입장이기 때문에 end-user라고도 불린다. End-user의 역할을 말로만 원하는 내용을 전달하는 것이 아니라 현재 소프트웨어가 requirments의 적합하게 개발이 되는지를 인지하고 있어야 된다.

---

# In conclusion, 3줄 요약

1. XP 개발 방식은 Extreme Programming 방식을 의미한다.

2. XP 개발 과정에서 지켜야할 방식들이 존재한다.

3. XP 개발 방식은 애자일 방법론의 한 방식이다.

---