[소프트웨어 공학] Agile Software Development

Agile Software Development

Introduction

Rapid Software Development

오늘날 소프트웨어 시스템에서 가장 중요한 요구사항 중 하나는 빠른 개발과 신속한 전달이다. 현대의 비즈니스 환경은 급변하고 있으며, 이러한 환경 속에서는 안정적인 요구사항을 미리 정해두는 것이 사실상 불가능하다. 요구사항은 프로젝트 도중에 계속해서 바뀌기 마련이고, 따라서 소프트웨어 역시 비즈니스 요구사항의 변화를 빠르게 반영할 수 있어야 한다.

물론 어떤 시스템들 -예를 들어 항공 제어 시스템, 의료 장비 시스템 등-은 여전히 계획 기반 개발(plan-driven development)이 필수적이다. 이런 시스템에서는 문서화, 검증, 위험 관리가 철저히 요구된다. 그러나 일반적인 비즈니스 시스템에서는 계획 중심 방식이 현실적인 요구를 충족시키기 어렵다.

이러한 배경 속에서 1990년대 후반, 애자일 개발 방법(Agile Development Methods)이 등장하게 되었다. 애자일 방법론의 목표는 작동하는 소프트웨어 시스템을 가능한 빠르게 전달하는 것이다.

Agile Development의 핵심 개념

애자일 개발에서는 전통적인 개발 방식과 달리 명세, 설계, 구현이 서로 섞여(inter-leaved) 진행된다. 소프트웨어는 하나의 완성품으로 만들어지는 것이 아니라, 여러 버전(increments)으로 나뉘어 점진적으로 개발된다.

각 버전의 명세와 검토에는 고객이나 이해관계자들이 직접 참여하며, 이러한 참여를 통해 소프트웨어가 실제 사용자의 요구를 더 잘 반영하게 된다.

또한, 애자일 개발에서는 새로운 버전의 소프트웨어가 자주 제공되며, 사용자는 그때그때 결과물을 보고 피드백을 제공할 수 있다. 이러한 빠른 피드백 사이클은 요구사항 변화에 유연하게 대응하는 데 매우 효과적이다.

이처럼 빠른 개발 주기를 가능하게 하기 위해서는 자동화 도구의 사용이 필수적이다. 특히 자동화 테스트 도구는 애자일 개발에서 매우 중요한 역할을 한다.

마지막으로, 애자일 개발은 문서화에 많은 비중을 두지 않는다. 오히려 작동하는 코드(working code)가 가장 중요한 결과물이며, 문서는 필요한 범위에서 최소한으로만 작성된다.

Plan-driven vs Agile Development

계획 기반 개발(Plan-driven Development)과 애자일 개발(Agile Development)은 서로 대조적인 방식이다. 계획 기반 접근법은 각 개발 단계를 명확하게 분리하며, 각 단계에서 만들어질 산출물도 사전에 계획된다. 이러한 접근법은 꼭 폭포수 모델에만 국한되지 않는다. 계획 중심의 점진적 개발도 가능하며, 각 활동 내에서 반복(iteration)이 일어나기도 한다.

반면, 애자일 개발은 명세, 설계, 구현, 테스트가 모두 뒤섞여서 수행된다. 개발 중 발생하는 결과물은 처음부터 정해지는 것이 아니라, 개발 과정 중에 협의를 통해 결정된다.

이러한 방식은 개발자와 고객 간의 지속적인 커뮤니케이션과 협력을 바탕으로 한다.

Agile Methods

1980년대와 1990년대의 전통적인 소프트웨어 설계 방식은 문서 중심, 계획 중심의 접근이었다. 하지만 시간이 지나면서 이런 방식이 과도한 오버헤드(overhead)를 발생시킨다는 불만이 제기되었고, 이는 새로운 접근 방식에 대해 필요성을 촉발시켰다.

이러한 배경 속에서 등장한 것이 바로 애자일 방법론(Agile Methods)이다. 애자일은 다음과 같은 핵심 개념을 바탕으로 한다.

• 설계보다는 코드 중심(Code-Oriented)의 개발에 초점을 맞춘다.
• 반복적인(iterative) 방식으로 개발을 진행한다.
• 작동하는 소프트웨어를 신속하게 전달하고, 그 소프트웨어를 지속적으로 진화시켜 변화하는 요구사항에 대응한다.

애자일 방법의 핵심 목표는 소프트웨어 프로세스에서의 불필요한 오버헤드를 줄이고, 문서화 작업을 최소화함으로써 신속하게 변화에 대응할 수 있도록 하는 것이다. 재작업 없이도 빠르게 새로운 요구사항을 반영할 수 있어야 하며, 이를 위해 전체 프로세스 자체가 단순하고 유연해져야 한다.

The Agile Manifesto(애자일 선언문)

애자일 방법론의 철학은 2001년에 발표된 애자일 선언문(Agile Manifesto)에 잘 담겨있다. 선언문은 소프트웨어를 직접 만들고, 다른 사람들과 함께 만들어온 실천 경험을 통해 도출된 핵심 가치들을 다음과 같이 제시한다.

우리는 소프트웨어 개발을 더 잘하는 방법을 실천하며 발견하고 있다. 이를 통해 다음의 가치를 중요하게 여기게 되었다:

• 프로세스와 도구보다 개인과 상호작용을
• 포괄적인 문서보다 작동하는 소프트웨어를
• 계약 협상보다 고객과의 협업을
• 계획을 따르기보다 변화에 대응하는 것을

즉, 선언문에서는 오른쪽 항목들이 가치가 없다는 것이 아니라, 왼쪽 항목들을 더 중요하게 여긴다는 점을 분명히 하고 있다. 이 선언문은 단순한 원픽을 넘어, 애자일의 핵심 철학을 형성하는 기준으로 작용하며, 많은 애자일 개발 방법들이 이 가치를 기반으로 설계되었다.

The Principles of Agile Methods

애자일 선언문을 보다 구체화한 것이 바로 애자일 방법의 원칙(Principles)이다. 이 원칙들은 실천 가능한 지침으로, 개발자와 조직이 애자일 철학을 일상에 적용할 수 있도록 돕는다.

이러한 원칙은 애자일 개발에서 중요한 의사결정 기준이 되며, 팀워크, 지속적 개선, 고객과의 긴밀한 협력이라는 가치를 강조한다.

Agile Method Applicability(애자일 적용 가능성)

애자일은 모든 개발 프로젝트에 적합한 것은 아니지만, 다음과 같은 경에는 특히 효과적이다.

• 소프트웨어 제품 개발
  • 소프트웨어 회사가 판매용 소프트웨어 제품을 개발할 때 특히 유용하다.
  • 실제로 오늘날 대부분의 소프트웨어 제품과 애플리케이션은 애자일 방식으로 개발되고 있다.
• 조직 내부의 맞춤형 시스템 개발
  • 특정 조직 내에서 고객이 개발 과정에 적극 참여하고, 외부 규정이 많지 않은 환경이라면 애자일이 매우 적합하다.
  • 정부 규제나 엄격한 표준이 없는 경우에 가장 이상적이다. 즉, 애자일은 작고 중간 규모의 프로젝트에서 특히 뛰어난 민첩성과 생산성을 제공하지만, 강력한 고객 참여와 비형식적 제약이 적은 환경이 선행 조건이 된다.

Agile Development Techniques

애자일 개발 방식의 핵심은 단순히 계획을 줄이고 문서를 생략하는 것에 그치지 않는다. 실질적으로 효율적이고 반복 가능한 개발을 가능하게 해주는 다양한 기법들이 존재하며, 그중에서도 가장 널리 알려진 것이 바로 익스트림 프로그래밍(Extreme Programming, XP)이다.

Extreme Programming (XP)

익스트림 프로그래밍은 1990년대 후반 등장한 매우 영향력 있는 애자일 방법으로, 애자일 개발의 여러 핵심 기법들을 통합하고 강화한 실천 중심 접근이다. XP는 기존 반복적 개발(iterative development)을 더욱 극단적으로 확장한 방식을 추구한다.

• 하루에도 여러 번 새로운 버전을 구축할 수 있다.
• 고객에게는 2주마다 새로운 인크리먼트가 제공된다.
• 모든 빌드에서 테스트가 실행되며, 테스트를 통과하지 못하면 해당 빌드는 수용되지 않는다. 이러한 높은 빈도의 통합과 검증은 코드 품질을 유지하면서도 빠른 납품이 가능하게 해준다.

XP의 개발 사이클

XP의 개발 주기는 다음과 같은 순환 구조를 가진다. 사용자 스토리 작성 -> 계획 수립 -> 반복 구현 -> 테스트 및 릴리즈 -> 피드백 수렴 -> 다음 반복 준비

XP의 주요 실천 기법

XP와 애자일 원칙

익스트림 프로그래밍은 애자일 철학을 정확히 구현하는 대표적 사례로 평가받는다.

• 점진적 개발 : 짧고 자주 반복되는 릴리즈를 통해 점진적으로 시스템을 완성하다.
• 고객 참여 : 고객이 개발팀의 일원으로 상주하며 지속적으로 피드백을 제공한다.
• 사람 중심 : 페어 프로그래밍과 집단 코드 소유 등을 통해 사람과 협업을 중심으로 개발한다.
• 변화 수용 : 반복 릴리즈를 통해 지속적으로 요구사항 변화를 반영한다.
• 단순성 유지 : 코드 리팩토링을 통해 설계를 항상 단순하고 명확하게 유지한다.

XP의 주요 기술적 실천 요소들

1. User Stories
   • 고객이 직접 작성하는 요구사항 시나리오이다.
   • 각 스토리는 카드 형태로 기록되며, 개발 팀은 이를 개발 태스크로 분해한다.
   • 고객은 우선순위에 따라 다음 릴리즈에 포함될 스토리를 선택한다.
2. Refactoring
   • XP는 사전에 변화를 예측하고 대비하는 대신, 지속적인 코드 개선을 통해 변화를 쉽게 수용할 수 있도록 한다.
   • 코드 가독성과 구조를 향상시키며, 문서 없이도 이해 가능한 코드 기반을 마련한다.
   • 클래스 계층 구조 재구성, 중복 코드 제거, 명확한 이름 부여 등이 주요 리팩토링 사례이다.
3. Test-first Developmet / Test-driven Developmet(TDD)
   • 코드를 작성하기 전, 먼저 테스트를 작성한다.
   • 테스트는 코드의 요구사항을 명확히 하며, 코드가 정상적으로 동작하는지를 자동으로 확인한다.
   • 일반적으로 JUnit과 같은 테스트 프레임워크를 활용한다.
   • 새로운 기능이 추가될 때마다 기존 테스트도 함께 실행되어, 새로운 코드가 기존 기능을 망가뜨리지 않았는지 확인한다.
4. 고객의 테스트 참여
   • 고객은 수용 테스트(acceptance test)를 정의하고 작성하는 데 참여해야 한다.
   • 하지만 실제 현장에서는 고객이 테스트에 적극 참여하기 어렵거나, 요구사항 정의만으로 충분하다고 느끼는 경우가 많다.
5. 테스트 자동화
   • 테스트는 실행 가능한 코드로 작성되며, 반복적으로 자동 실행된다.
   • 테스트 프레임워크는 입력을 시뮬레이션하고 결과를 자동으로 검증해준다.
   • 모든 기능이 새로 추가될 때마다 전체 테스트를 자동 실행하여 오류를 빠르게 탐지한다.

Pair Programming

페어 프로그래밍은 XP의 가장 상징적인 실천 중 하나이다. 개발자 두 명이 한 컴퓨터 앞에서 함께 코딩을 하며, 실시간으로 코드 리뷰를 수행한다.

• 팀 전체가 서로의 코드에 익숙해지게 되어 지식 공유가 촉진된다.
• 팀원 간의 협업이 향샹되고, 리팩토링 문화가 자연스럽게 자리 잡는다.
• 동적으로 파트너를 바꾸며 작업하므로, 팀 내 모든 개발자가 서로 협력하게 된다.
• 효율성에 대한 오해가 있지만, 실제로는 두 사람이 함께 작업할 때 생산성과 품질이 높아진다는 연구 결과도 존재한다.

Agile Project Management

소프트웨어 프로젝트 관리자(Software Project Manager)의 핵심 책임은 소프트웨어가 제시간에, 예산 내에서 개발될 수 있도록 프로젝트를 관리하는 것이다. 이를 위해 전통적으로 사용되어온 방식은 계획 기반(plan-driven)프로젝트 관리이다.

이 방식에서는 전체 프로젝트를 사전에 세운 계획에 따라 관리한다. 무엇을, 언제, 누가 개발할지 등의 모든 작업 항목과 책임이 문서로 작성되어 있으며, 계획이 변경되는 경우 전체 일정이 영향을 받는다.

하지만 애자일 개발 방식에서는 이러한 접근이 적합하지 않다. 애자일은 점진적(incremental)이고 유연한 개발 방식을 따르기 때문에, 이에 맞춘 새로운 관리 방식이 필요하다. 이로 인해 등장한 것이 바로 애자일 프로젝트 관리(Agile Project Mangement)이다.

Scrum : 대표적인 애자일 관리 프레임워크

스크럼(scrum)은 구체적인 개발 기법보다는 반복적인 개발을 어떻게 관리할 것인가에 초점을 맞춘 애자일 방법론이다. scrum은 세 개의 주요 단계로 구성된다.

1. 초기 계획 단계 : 전체 프로젝트의 목표와 소프트웨어 아키텍쳐의 큰 틀을 설정한다.
2. 스프린트 반복 단계 : 일정한 기간(보통 2~4주) 동안 반복적으로 인크리먼트를 개발한다.
3. 프로젝트 마무리 단계 : 프로젝트를 종료하며, 사용자 설명서, 시스템 도움말 등 문서를 완성하고 프로젝트로부터 얻은 교훈을 정리한다.

• Scrum 용어 정리

Scrum Sprint Cycle

스프린트는 고정된 기간(보통 2~4주) 동안 진행된다. 그 시작점은 제품 백로그이며, 이 백로그를 바탕으로 고객과 팀이 함께 이번 스프린트에 구현할 기능을 선정한다.

합의된 항목이 정해지면, 팀은 자율적으로 역할을 나누어 구현을 시작한다. 이때 고객과의 직접 소통은 차단되고, 모든 커뮤니케이션은 스크럼 마스터를 통해 이루어진다. 스크럼 마스터는 팀을 외부 간섭으로부터 보호하며 집중할 수 있는 환경을 마련한다.

스프린트가 종료되면 팀은 작업 결과물을 공유하고 검토하며, 다음 스프린트에 들어갈 준비를 한다.

Scrum의 팀워크

스크럼 마스터는 단순한 관리자나 지시자가 아니다. 그는 다음과 같은 역할을 수행한다.

• 매일 아침 회의를 주관하고
• 작업 백로그를 추적하며
• 진행 상황을 기록하고
• 외부와의 커뮤니케이션을 담당한다.

스커럼 회의는 모든 팀원이 참여하며, 각자 이전 작업 진행상황, 오늘 할 일, 발생한 문제를 공유 한다. 이 과정은 모든 팀원이 현재 프로젝트의 상태를 정확히 파악하게 하며, 문제가 발생했을 때 즉시 짧은 주기 안에서 계획을 조정할 수 있게 해준다.

Scrum의 장점

• 제품이 작고 이해하기 쉬운 단위로 나뉘어 관리된다.
• 요구사항이 안정되지 않더라도 개발은 지속될 수 있다.
• 팀원 전체가 정보를 공유하며, 팀 커뮤니케이션이 활발해진다.
• 고객은 정해진 시간에 인크리먼트를 제공받고, 이를 테스트해 피드백을 줄 수 있다.
• 고객과 개발자 사이에 신뢰가 생기며, 팀 전체에 긍정적인 문화를 형성한다. 결과적으로, 모든 팀원이 프로젝트의 성공을 자신의 일처럼 기대하게 된다.

Distributed Scrum - 분산 환경에서의 애자일 적용

Scrum은 본래 팀원들이 동일한 공간에서 함께 일하는 것을 전제로 설계되었다. 매일 아침 함께 모여 짧은 미팅을 하고, 얼굴을 맞대며 즉시 피드백을 주고받는 등의 특성이 핵심이기 때문이다.

그러나 현실적으로는 팀원들이 다른 도시, 다른 나라, 혹은 다른 시간대에 위치한 경우도 많다. 이러한 환경을 분산 개발(Distributed Development)이라고 하며, 이때 적용되는 스크럼을 Distributed Scrum이라고 부른다.

• 분산 Scrum의 필요성 : 기업이 글로벌화됨에 따라 개발팀이 물리적으로 흩어져 있는 경우가 많아졌다. 예를 들어, 본사는 미국에 있고, 개발팀 일부는 인도, QA팀은 한국에 있는 식이다. 이러한 분산 환경에서도 애자일의 민첩성과 스크럼의 조직력을 활용하기 위해서는 몇 가지 보완과 적응이 필요하다.

• Distributed Scrum의 주요 도전 과제
  • 커뮤니케이션의 지연 : 다른 시간대에 있는 팀 간에는 회의 일정을 맞추는 것 자체가 어렵다. 동기화 되지 않으면 정보 공유가 지연되고, 개발 효율이 낮아질 수 있다.
  • 스크럼의 핵심인 매일 회의의 어려움 : 서로 일하는 시간이 겹치지 않으면 매일 짧은 스크럼 회의를 갖기 어렵다. 이 경우 회의를 녹화하거나, 텍스트 기반 스커럼(예: 슬랙, 컨플루언스 등)을 활용할 수도 있다.
  • 팀 간 문화적 차이 : 문화나 언어의 차이는 오해를 낳을 수 있다. 이러한 차이를 줄이기 위한 공감 훈련이나 글로벌 팀워크 교육도 도움이 된다.
• 장점
  • 전 세계의 전문 인력을 팀으로 구성할 수 있다.
  • 다양한 문화와 관점을 통해 더 창의적인 해결책을 기대할 수 있다.
  • 24시간 개발 가능성 - 시간대를 나누어 팀이 순차적으로 개발을 어아가면, 제품 개발 속도가 빨라질 수 있다.

Scaling agile methods

애자일 방법론은 소규모 팀이 협업 공간을 공유하면서 개발하는 환경에서 탁월한 성과를 보여주었다. 하지만 대규모 시스템이나 조직 전체에 애자일을 적용하는 데에는 다양한 도전 과제가 따른다.

Agile Scaling은 크게 두 가지 관점으로 나뉜다.

• Scaling up : 하나의 대형 시스템을 여러 팀이 협력하여 개발할 때 애자일을 적용하는 것. 예: 정부 시스템, 은행 시스템 등 대형 프로젝트
• Scaling Out : 오랜 전통을 가진 대기업 전체에 애자일 문화를 확산시키는 것. 기존의 문서 중심, 규칙 기반 문화를 벗어나 조직 전체가 애자일 원칙을 채택하는 것을 의미한다.

Practical Problems with Scaling Agile

실제로는 애자일을 확장하는 과정에서 여러 가지 현실적인 문제들이 드러난다. 가장 큰 문제는 애자일의 비공식성이 대기업에서 사용하는 계약 기반 시스템과 맞지 않는다는 점이다.

기업들은 보통 상세한 요구 명세를 바탕으로 계약을 체결하고, 그에 따라 소프트웨어를 개발한다. 하지만 애자일은 명세와 개발이 동시에(interleaved) 진행되기 때문에, 이러한 계약 구조와는 충돌을 일으킨다. 애자일을 적용하기 위해서는 기능 기반이 아니라 개발 시간에 기반한 계약 구조가 필요하다. 그러나 많은 조직에서는 이를 법적 리스크로 간주하여 쉽게 수용하지 못한다.

또한 대부분의 대기업에서는 신규 개발보다 기존 시스템의 유지보수에 더 많은 자원을 투입한다. 그런데 애자일은 새로운 시스템 개발에는 잘 맞지만, 문서화가 부족하고 팀의 지속성 유지가 어려워 유지보수에는 약점을 드러낸다.

분산된 팀 간 협업 역시 큰 문제다. 애자일은 같은 공간에서 일하는 팀을 전제로 만들어졌지만, 현실에서는 여러 국가에 퍼진 개발자들이 협업하는 경우가 많다. 이럴 경우, 비공식적 커뮤니케이션을 기반으로 한 애자일 방식은 어려움을 겪는다.

애자일은 가능한 문서를 줄이고 코드를 중심으로 움직이지만, 시스템이 장기간 유지되어야 하는 경우에는 이 역시 문제가 된다.

• 제품에 대한 명확한 문서가 부족하고
• 고객이 개발에 계속 참여하지 않거나
• 초기 개발 팀이 유지되지 않을 경우 해당 시스템의 향후 유지보수는 매우 어려워질 수 있다. 특히 수명이 긴 시스템이라면, 처음 만든 사람이 떠났을 때도 누군가 이해하고 관리할 수 있도록 정확한 의도와 설계 내용이 문서화되어 있어야 한다.

Agile과 Plan-driven의 조화

위와 같은 문제로 현실적인 많은 프로젝트에서는 애자일과 전통적인 접근 방식이 혼합된다.

• 매우 상세한 설계와 명세가 필요한 경우에는 계획 중심 방식(plan-driven)이 적합하고,
• 빠르게 고객 피드백을 받아가며 점진적으로 납품하는 방식이 가능하다면 애자일이 적합하다.

시스템의 크기, 생명 주기, 요구되는 규제 수준 등을 모두 고려하여 상황에 맞는 균형점을 찾는 것이 중요하다.

조직에서 Agile 원칙을 적용할 때의 어려움

애자일의 핵심 원칙들이 실제 조직 환경에서는 이상적으로만 작동하지 않는다

• 고객이 시간과 자원을 충분히 투입할 수 있다면 고객 참여(Customer Involvement)는 어려운 원칙이 된다.
• 수많은 이해관계자들이 존재하는 시스템에서는 변화 수용(Embrace Change)이 간단하지 않다. 모두가 우선순위를 다르게 보기 때문이다.
• 단기 반복과 점진적 납품(Incremental delivery)은 기업의 장기적 마케팅 계획 등과도 충돌할 수 있다.
• 단순성 유지(Maintain Simplicity) : 빠른 납품 압박 속에서 쉽게 무너진다.
• 팀 구성원들이 모두 활발히 협력할 수 있는 성향을 가진 것도 아니기 때문에 사람 중심(People not process)의 원칙이 항상 상공하는 것은 아니다.

System issues 시스템 개발에서의 고려 사항

• 시스템 규모가 클수록, 애자일 방식만으로는 조율이 어렵다.
• 분석이 중요한 시스템은 사전에 충분한 설계가 필요하며,
• 수명이 긴 시스템은 명확한 문서가 필수이고,
• 법적 규제나 인증이 필요한 시스템은 형식적인 문서와 절차가 반드시 요구된다.

People and teams

• 애자일은 높은 실력을 가진 개발자를 전제로 한다.
• 문서가 부족한 상태에서도 시스템을 유지할 수 있으려면, 훌룡한 개발자들과 시각적 툴이 필요하다.
• 분산된 팀이라면 문서화 없이는 협업이 어렵기 때문에, 애자일 방식이 제한될 수 있다.

Organizational issues - 조직 차원의 애자일 도입

조직 차원에서는 또 다른 어려움이 있다.

• 애자일 경험이 없는 관리자는 새로운 방식을 리스크로 간주하며 거부감을 가질 수 있고,
• 전통적인 조직은 정해진 품질 절차를 따르는데, 이는 애자일의 유연함과 상충된다.
• 팀 내 능력의 차이도 문제이며,
• 오랫동안 전통적 방법에 익숙한 조직 문화에서는 애자일 방식이 문화적 저항에 부딪히기도 한다.

대형 시스템에서의 애자일 전략

대형 시스템은 보통 여러 개의 하위 시스템으로 나뉘고, 이들은 서로 통신하며 동작한다. 팀도 여러 지역에 분산되어 있고, 시스템 자체가 기존 시스템들과 연동되어야 하는 brownfield 시스템인 경우가 많다.

이런 상황에서는 완전한 애자일 적용은 어려우며, 통합과 구성이 주된 업무가 된다. 그렇다고 애자일 원칙을 포기해서는 안된다. 자주 릴리즈하고, 팀 간 커뮤니케이션을 체계화하며, 아키텍쳐 설계와 일부 문서화도 병행하는 하이브리도 전략이 필요하다.

• IBM’s agility at scale model

Multi-Team Scrum

여러 팀이 동시에 협력하는 경우에는 Multi-team Scrum을 적용한다.

• 각 팀은 자체적인 Product Owner와 Scrum Master를 가진다.
• 모든 팀은 자신만의 제품 아키텍트(Product Architect)를 가지고, 이들이 모여 전체 시스템 아키텍처를 설계한다.
• 모든 팀은 릴리즈 날짜를 조정(alignment)하여, 전체 시스템이 완성된 형태로 제공되도록 한다.
• 각 팀의 대표들이 모여 Scrum of Scrums라는 메타 회의를 통해 각자의 진척 상황을 공유하고 조율한다.

Agile Methods Across Organizations

애자일 방법론은 빠르고 유연한 개발을 가능하게 하지만, 실제로 모든 조직이 이를 쉽게 받아들이는 것은 아니다. 특히 기존의 방식에 익숙한 조직일 수록 새로운 개발 방식에 대한 심리적 저항감을 보이기도 한다.

가장 먼저 고려해야 할 점은 프로젝트 관리자의 경험이다. 애자일 방법에 익숙하지 않은 프로젝트 관리자들은, 그 접근법이 기존의 통제 방식보다 느슨해 보일 수 있기 때문에 이를 위험하다고 판단하고 기존 방식에 집착하려는 경향이 있다.

게다가, 대기업에서는 거의 예외 없이 정해진 품질 관리 절차와 표준을 따르도록 되어 있다. 이러한 절차는 대부분 매우 관료적이고 문서 중심이며, 이러한 성격이 바로 문서화와 형식주의를 최소화하려는 애자일 방식과 충돌하게 된다.

또한, 애자일은 상대적으로 높은 역량을 가진 구성원을 기반으로 설계되었다. 그러나 현실 속 대형 조직에서는 팀원의 실력 수준이 제각각이기 때문에, 애자일의 자율성과 빠른 의사결정이 모든 구성원에게 자연스럽게 적용되기 어렵다.

마지막으로, 애자일은 비교적 최근에 등장한 철학이기 때문에, 오랫동안 전통적인 시스템 공학 프로세스를 사용해온 조직들에서는 문화적 저항이 생기기 쉽다. 이런 조직에서는 계획 중심, 문서 중심의 개발 문화가 뿌리 깊게 자리 잡고 있기 때문이다.

Key Points

이 챕터에서는 애자일 소프트웨어 개발의 철학, 기법, 적용 방식과 도전과제들을 전반적으로 다루었다.

우선, 애자일 방법론은 점진적 개발 방식(Incremental Development)을 기반으로 하며, 빠른 소프트웨어 개발과 잦은 릴리즈를 강조한다. 문서화보다는 실제 작동하는 고품질 코드, 그리고 고객과 개발자의 긴밀한 협력으르 중시한다.

애자일 개발에서 주로 사용되는 실천은 다음과 같다.

• 사용자 스토리(user stories)를 통한 시스템 명세
• 빈번한 릴리즈(frequent releases)
• 지속적인 코드 개선
• 테스트 우선 개발(test-first development)
• 개발 팀 안에서 이루어지는 고객의 적극적인 참여

그 중에서도 스크럼(Scrum)은 애자일 프로젝트 관리를 위한 대표적인 프레임워크로, 정해진 시간 내에 하나의 인크리먼트를 완성하는 스프린트(sprint) 주기를 중심으로 진행된다.

하지만 실무에서는 순수 애자일보다는 계획 기반 접근법과 애자일 방식이 섞여 있는 형태가 훨씬 더 흔하다. 특히 대규모 시스템 개발에서는 완전한 애자일 방식의 적용이 쉽지 않다. 설계와 문서화는 여전히 중요한 요소이며, 조직의 관행과 충돌하는 지점도 많기 때문이다.