익스트림 방법론 - 특징, 적용, 의견

소프트웨어 개발 방법론 중에 하나인 

익스트림 ( eXtreme Programming ) 일명 XP 방법론에 대해 알아봅니다. 

 

1990년 후반에 Kent Beck 개발했다고 합니다.

이름에서 짐작할 수 있듯이 고객의 요구사항의 변화에 빠르게 대응할 수 있도록 만들어졌습니다. 

[목차]

• 특징
• 적용 방법
• 의견

특징

주요 특징

• 짧은 개발 주기 
  • 되도록 작은 기능 단위를 개발 목표로 짧은 개발 주기( 3주 이내 )를 반복합니다. 
• 테스트 주도 개발 ( TDD , Test-Driven Development ) 
  • 로직을 개발하기 전에 테스트 케이스를 작성하고 그에 맞춰 로직 코드를 작성합니다. 
• 코드 리뷰, 페어 프로그래밍 
  • 개발자 동료들과 함께 코드를 만들고 서로 검토합니다. 
  • 서로의 코드에 지속적인 피드백이 중요합니다. 
• 간단한 디자인 
  • 복잡한 디자인 보다 간단한 다지인부터 동작되게 만든 후에 개선합니다. 
  • 동작을 먼저 생각합니다. 
• 지속적인 통합과 자동화 
  • 코드 변경이 발생할 때마다 자동으로 테스트될 수 있도록 하고, 테스트가 통과되면 통합하여 배포되도록 합니다. 

적용 방법

• 필요성 평가 
  • 고객의 요구사항에 대한 대응을 우선 할지 , 품질 향상을 우선 할지를 결정해야 합니다. 
• 교육과 훈련 
  • 개발자들에게 XP의 기본 개념과 원칙을 이해 시킵니다. 
  • 개발자들에게 TDD, 페어 프그래밍, 지속적인 통합에 대한 이해를 높이고, 교육되어야 합니다.
• 시작 단계 결정 
  • 작은 팀이나 범위에 먼저 적용하여 조직에 적합한지 확인하고 이에 대한 경험을 쌓습니다. 
  • 성공 사례를 중심으로 점차적으로 전개해 나갑니다. 
• 진행과 적응 
  • XP를 시행하면서 발생하는 문제를 파악하고 수정하여 프로세스 개선에 힘써야 합니다.
• 팀 문화 강화 
  • XP는 협업과 피드백 문화를 중심으로 합니다. 팀 간의 소통을 증진시키고 , 개발자 간의 페이 페어 프로그래밍, 코드 리뷰 등의 활동을 통해 지식 공유와 팀의 일관된 방향성을 유지해야 합니다. 
• 평가와 조정 
  • 주기적으로 프로세스의 적용 상태를 확인하고 개선할 부분을 파악하여 조정해야 합니다.  

 

의견

 

XP는 개인적으로 매우 좋아하는 방법론입니다. 아마도 제가 진행한 모든 프로젝트에 적용되어있다고 볼 수도 있습니다. 

물론, 완성도 있게 잘 적용하고 있었다라고 보기엔 많이 부족한 게 사실입니다. 

 

현실적인 어려움에는  

1.  개발 방법론에 대한 기본적인 지식이나, 필요성을 팀원 모두에게 교육하고 이해시키기엔 많은 어려움이 따릅니다. 
2. TDD 부분은 더 힘듭니다. 필요성은 공감하지만, 물리적인 시간의 부족함을 이유로 들어 잘 안 지켜집니다.
3. TDD 가 잘 안되니, CI/CD를 이용한 통합 빌드 방식도 잘 안되거니와, 빌드된 실행 파일도 역시, 잘 동작되지 않습니다. 

같은 것들이 있겠습니다. 

다만, 코드 리뷰는 어느 정도 기본적인 부분으로 정착이 되어 가는 것 같아 다행입니다.

 

정말 의지가 있는 리더라면, 작더라도 제대로 지켜진 예시 프로젝트를 직접이라도 만들어서 그 사례를 공유하여 개발자들에게 직접 보여주는 게 가장 효율적이라고 볼 수 있습니다. 

 

이 프로세스를 도입하면, 불필요한 Git 충돌, 동작하지 않는 빌드 결과물, 그리고 계속해서 발생하는 버그와 같은 문제들로 인해 소요되는 시간을 줄여, 개발자들이 핵심 기능 개발에 집중할 수 있음을 강조해야 합니다.

 

혹은, 강제로 하게 만들던가요 ( 어느 정도 필요하다고 봅니다. ) 

여러분들은 어떻게 생각하시나요 ?  

 

더불어, 꼭 필요한 문서는 만들어야 한다고 생각합니다. 어느 문서든 "불필요한 문서를 만들기 보다는 ..." 이라고 되어있습니다. 

문서를 만들 필요가 없다가 아닙니다.