애자일 소프트웨어 개발 (Agile Software Development)

 

 

소프트웨어를 개발하는 방법론은 매우 다양합니다. 그리고 산업별/조직별로 다양한 개발 방법론을 취사 선택하고 있을 것입니다. 이는 각 방법론이 갖는 장점으로 인해 그리고 기타 여러 이유로 인해 다른 개발 방법로으로의 전환을 고려하고 있는 조직/회사도 있을 것으로 생각합니다. 이때 선택할 수 있는 개발 방법론 중 하나로 애자일 소프트웨어 개발(Agile Software Development)이 있을 것 입니다.

그렇다면 애자일 소프트웨어 개발이란 무엇일까요?

 

1. 애자일 소프트웨어 개발이란 무엇인가?

애자일 소프트웨어 개발은 유연성의 필요성을 예측하고 완성된 제품의 전달에 실용적인 접근을 적용하는 소프트웨어 개발 방법론의 한 유형입니다. 애자일 소프트웨어 개발은 많은 회사에서 문화적 변화를 요구하는데, 이는 전체 어플리케이션이 아니라 소프트웨어의 개별 부분 즉, 기능이나 피처 단위의 개발 및 배포에 중점을 두게 됩니다.

 

2. 애자일 소프트웨어 개발의 장점

애자일 소프트웨어 개발의 장점으로는 변화하는 환경에서 개발 조직 목표를 달성하면서도 비즈니스 가치를 효율적으로 전달하는데 중점을 두는 능력이 포함됩니다. 애자일이 촉진하는 협력 문화는 팀이 함께 작업하고, 프로세스에서 자신의 특정 역할을 이해하면서 조직 전반의 효율성을 향상 시킵니다. 또한 애자일 소프트웨어 개발을 사용하는 회사는 개발 과정 전반에 걸쳐 테스트가 수행되기 때문에 고품질 제품을 출시하고 있다는 자신감을 가질 수 있습니다. 이는 필요한 경우 변경을 할 수 있는 기회를 제공하고 팀내 발생가능한 잠재적인 문제을 사전에 인식할 수 있도록 도와줍니다. 이러한 애자일 소프트웨어 개발은 전통적인 소프트웨어 개발 방법론인 폭포수 모델(Waterfall Model)을 대체했지만, 최근 DevOps의 인기가 높아짐에 따라 애자일 소프트웨어 개발 방법론의 위상이 퇴색되고 있는 실정입니다.

 

3. 애자일 소프트웨어 개발의 4가지 핵심 가치

2001년 17명의 소프트웨어 개발 전문가가 경량화된 소프트웨어 개발 방법론에 대해 논의하였고, 결국 애자일 선언문(Agile Manifesto)을 작성하게 되었습니다. 이 선언문은 애자일의 4가지 핵심 가치를 개략적으로 설명하고 있습니다. 

3.1 프로세스와 도구보다 개인과 상호작용을 중시합니다. (Individuals and Interactions over Processes and Tools)

애자일 소프트웨어 개발에서는 사람과 상호작용이 프로세스보다 더 중요합니다. 사람들은 개발 프로세스를 이끌고 비즈니스 요구에 응답합니다. 사람들은 개발의 가장 중요한 부분이며, 프로세스와 도구보다 가치있게 여겨져야 합니다. 프로세스나 도구가 개발을 이끌면 팀은 변화에 적응하고 응답할 가능성이 적어지며, 따라서 고객의 요구를 충족시킬 가능성도 낮아집니다.

3.2 포괄적인 문서보다 작동하는 소프트웨어를 중시합니다. (Working Software over Comprehensive Documentation)

애자일 소프트웨어 개발에서는 포괄적인 문서화보다 작동하는 소프트웨어에 중점을 둡니다. 애자일 이전에는 제품 개발 전반에 걸쳐 많은 시간을 문서화에 할애하여 전달했습니다. 문서화된 요구 사항 목록은 길고 개발 과정에 긴 지연을 초래했습니다. 애자일은 문서화를 완전 배제하는 것은 아니지만, 개발자가 작업을 수행하는데 필요한 정보만을 제공하도록 간소화합니다. 즉 애자일 선언문은 문서화보다는 작동하는 소프트웨어에 더 높은 가치를 둡니다.

3.3 계약 협상보다 고객 협력을 중시합니다. (Customer Collaboration over Contract Negotiation)

애자일 소프트웨어 개발에서는 계약 협상보다 고객과의 협력을 중시합니다. 애자일은 고객과 프로젝트 관리자 간의 협상을 통해 전달 세부 사항을 조율하기보다, 고객과 프로젝트 관리자 간의 협력을 강조합니다. 고객과의 협력은 개발 과정 전체에 걸쳐 고객이 포함되므로 팀이 고객의 요구를 충족시키기 더 쉬워집니다. 예를 들어, 애자일에서는 제품 시연을 위해 다양한 시점에 고객이 참여할 수 있습니다. 따라서 고객은 매일 팀과 상호 작용하고 모든 회의에 참석하여 제품이 그들의 요구를 충족하는지 확인할 수 있습니다.

3.4 계획을 따르는 것보다 변화에 대응하는 것을 중시합니다. (Responding to Change over following a Plan)

애자일 소프트웨어 개발에서는 계획을 따르는 것보다 변화에 대응하는 것에 중점을 둡니다. 전통적인 소프트웨어 개발은 변화를 원하지 않는 비용으로 간주하여 피했습니다. 애자일은 이 아이디어를 없앱니다. 애자일 주기의 짧은 반복은 쉽게 변경할 수 있어 팀이 프로세스를 적절히 조정하도록 도와줍니다. 전반적으로, 애자일 소프트웨어 개발은 변화가 항상 프로젝트를 개선하고 추가 가치를 제공하는 방법이라고 믿습니다.

 

4. 애자일 소프트웨어 개발의 12가지 원칙

또한 애자일 선언문에서는 애자일 개발 프로세스를 위한 12가지 핵심원칙을 설명하고 있습니다. 

• 가치 있는 작업의 조기 및 지속적인 배포를 통해 고객을 만족시킵니다.
• 큰 작업을 빠르게 완료할 수 있는 더 작은 작업으로 나눕니다.
• 최고의 작업은 자율적으로 조직된 팀에서 나온다는 것을 인식합니다.
• 동기 부여된 개인에게 필요한 환경과 지원을 제공하고 그들이 일을 완수할 것이라는 신뢰를 주어야 합니다.
• 이해관계자들이 지속적으로 참여하고 실천할 수 있는 프로세스를 만듭니다.
• 완료된 작업에 대해서도 일정한 속도를 유지해야합니다.
• 프로젝트 후반에도 요구 사항 변경을 적극적으로 반영할 수 있어야 합니다.
• 프로젝트 전반에 걸쳐 매일 프로젝트 팀과 고객이 모여 진행사항을 확인할 수 있어야 합니다.
• 팀이 더 효과적으로 되기 위한 방법을 정기적으로 반성하고 이에 따라 행동을 조정하도록 합니다.
• 완료된 작업량으로 진행 상황을 측정합니다.
• 지속적으로 결과물에 대해 고객으로부터의 만족을 이끌어 낼 수 있어야 합니다.
• 경쟁 우위를 위해 변화를 활용합니다.

 

5. 애자일 소프트웨어 개발 주기

5.1 Concept Phase (개념 단계)

첫 번째 단계인 개념 단계(Concept Phase)에서는 각 잠재 프로젝트에서 비즈니스 기회를 식별하고 프로젝트 완료에 필요한 시간과 작업량을 추정합니다. 이 정보는 프로젝트를 우선순위로 지정하고 기술적, 경제적 타당성에 따라 어떤 프로젝트를 추구할 가치가 있는지 판단하는 데 사용됩니다.

5.2 Inception Phase (시작 단계)

두 번째 단계인 시작 단계(Inception Phase)에서는 팀 구성원을 식별하고, 전체 일정을 확인하며 초기 요구 사항을 고객과 논의합니다. 또한 각 스프린트에 대해 작업이 완료될 예상 시점을 명확히 정의하는 다양한 팀의 책임을 개략적으로 설명하는 타임라인을 작성해야 합니다. 스프린트는 특정 작업이 완료되어 검토 준비가 되는 일정 기간입니다.

5.3 Iteration/Construction Phase (반복/구축 단계)

이 단계에서는 제품을 반복적으로 개발합니다. 각 반복(스프린트)마다 제품의 특정 부분을 구축하고, 이를 테스트 및 검토하여 지속적으로 개선해 나갑니다. 요구 사항은 개발 도중 변경될 수 있으며, 팀은 이러한 변경에 신속하게 대응합니다.

5.4 Release Phase (출시 단계)

반복 단계를 통해 개발된 기능이 충분히 모이면, 이를 최종 사용자에게 출시합니다. 이 단계에서는 제품의 안정성과 품질을 보장하기 위해 철저한 테스트와 검토가 이루어집니다.

5.5 Production Phase (운영 단계)

출시된 제품을 실제 환경에서 운영하는 단계입니다. 이 단계에서는 제품의 성능을 모니터링하고, 버그 수정 및 유지보수를 수행합니다. 또한 사용자의 피드백을 수집하여 향후 개선 사항에 반영합니다.

5.6 Retirement Phase (폐기 단계)

제품의 수명이 다하여 더 이상 사용되지 않을 때, 이를 폐기하는 단계입니다. 이 단계에서는 제품의 데이터를 백업하고, 시스템에서 안전하게 제거하는 작업이 이루어집니다. 제품의 폐기 이유와 향후 계획에 대한 문서화도 이루어집니다.

 

6. Types of Agile Methodologies (애자일 방법론의 유형)

애자일 방법론의 목표는 변화에 적응하면서 작동하는 소프트웨어를 최대한 효율적으로 전달하는 것입니다. 하지만 각 방법은 소프트웨어 개발 단계 정의 방식에 따라 다릅니다. 가장 널리 사용되는 애자일 방법에는 다음이 포함됩니다:

6.1 Scrum

스크럼은 프로젝트 관리자가 모든 유형의 반복적이고 점진적인 프로젝트를 제어할 수 있도록 도와주는 경량 애자일 프레임워크입니다. 스크럼에서 제품 소유자는 팀과 협력하여 시스템 기능을 식별하고 우선순위를 지정할 수 있는 제품 백로그를 작성합니다. 제품 백로그는 성공적인 작동 소프트웨어 시스템을 제공하는 데 필요한 모든 것을 포함하는 목록입니다. 우선순위가 설정된 후, 교차 기능 팀은 각 스프린트(종종 30일 이내) 동안 작동하는 소프트웨어 증분을 제공하기로 동의합니다. 각 스프린트 후, 제품 백로그는 재평가되고 분석되며 우선순위가 다시 지정되어 다음 스프린트를 위한 새로운 기능을 선택합니다. 스크럼은 간단하고 생산성이 높으며 다른 애자일 방법이 장려하는 다양한 실천을 통합할 수 있어 인기를 얻고 있습니다.

6.2 Lean Software Development

린 소프트웨어 개발은 효과적인 가치 흐름 매핑을 사용하여 팀이 고객에게 가치를 제공하도록 보장하는 반복적인 방법입니다. 이 방법은 유연하고 진화하며, 엄격한 지침이나 규칙이 없습니다. 린 방법은 다음과 같은 주요 원칙을 사용합니다:

• 학습 증대
• 팀에게 권한 부여
• 진실성 촉진
• 낭비 제거
• 전체 이해
• 가능한 늦게 의사 결정
• 가능한 빨리 제품 제공

린 방법은 고객과 프로그래머 간의 빠르고 신뢰할 수 있는 피드백을 통해 빠르고 효율적인 개발 워크플로우를 제공하는 데 중점을 둡니다. 이를 달성하기 위해 개별 사용자와 소규모 팀에게 의사 결정 권한을 부여하며, 위계적인 통제 흐름에 의존하지 않습니다. 린 방법은 사용자에게 시스템에 진정으로 가치 있는 기능만 선택하고, 이러한 선택된 기능을 우선순위에 두고 작은 배치로 제공하도록 요청합니다. 또한, 린 소프트웨어 개발은 코드와 동시에 자동화된 단위 테스트를 작성하도록 권장하며, 팀의 모든 구성원이 최대한 생산성을 발휘하도록 집중합니다.

6.3 Extreme Programming (XP)

익스트림 프로그래밍(XP) 방법은 속도와 지속적인 전달에 중점을 둔 규율 있는 접근 방식입니다. 이는 고객 참여 증가, 빠른 피드백 루프, 지속적인 계획 및 테스트, 긴밀한 팀워크를 촉진합니다. 소프트웨어는 1~3주마다 자주 전달됩니다. 목표는 소프트웨어 품질을 향상시키고 변화하는 고객 요구에 대한 대응력을 높이는 것입니다.

XP 방법은 커뮤니케이션, 피드백, 단순성 및 용기의 가치를 기반으로 합니다. 고객은 개발 팀과 긴밀히 협력하여 요청된 사용자 스토리를 정의하고 우선순위를 지정합니다. 그러나 팀은 각 반복에서 테스트된 작동 소프트웨어의 형태로 가장 높은 우선순위의 사용자 스토리를 제공해야 합니다. XP 방법은 사용자를 지원하고 고품질의 엔터프라이즈 소프트웨어를 출시하도록 돕는 가벼운 프레임워크를 제공합니다.

6.4 Crystal

크리스탈은 가장 가볍고 적응력이 뛰어난 방법론입니다. 이는 애자일 프로젝트를 수행하는 동안 발생하는 사람과 상호작용, 개발 중인 시스템의 비즈니스 중요성과 우선순위에 중점을 둡니다. 크리스탈 방법은 각 프로젝트가 약간의 맞춤형 정책, 실천 및 프로세스를 요구하는 고유한 특성을 가지고 있다는 인식에 기반합니다. 결과적으로, 이는 크리스탈 오렌지, 크리스탈 클리어 및 크리스탈 옐로우와 같은 다양한 애자일 프로세스 모델로 구성됩니다. 각 모델은 프로젝트 우선순위, 팀 규모 및 시스템 중요성과 같은 다양한 요인에 따라 고유한 특성을 가지고 있습니다.

크리스탈은 작동하는 소프트웨어의 빈번한 제공, 높은 고객 참여, 적응성, 관료주의와 산만함의 제거를 강조합니다. 그 핵심 원칙에는 커뮤니케이션, 팀워크 및 단순성이 포함됩니다.

6.5 Kanban

칸반은 시각적 워크플로우 관리 방법을 사용하여 팀이 소프트웨어 개발 수명 주기(SDLC)에서 스트레스를 더 가하지 않고 제품 생성 작업을 적극적으로 관리할 수 있도록 합니다. 이는 린 소프트웨어 개발을 실천하는 팀 사이에서 인기를 얻었습니다.

칸반은 세 가지 기본 원칙을 사용합니다: 워크플로우 시각화, 진행 중인 작업의 제한, 작업 흐름의 개선. 스크럼과 마찬가지로 칸반 방법은 팀이 서로 더 효율적으로 작업하도록 돕기 위해 설계되었습니다. 이는 지속적인 협업을 장려하고, 적극적이고 지속적인 학습 및 개선을 촉진하는 최상의 워크플로우를 정의하려고 시도합니다.

6.6 Dynamic Systems Development Method (DSDM)

동적 시스템 개발 방법(DSDM)은 빠른 소프트웨어 제공을 위한 공통 산업 프레임워크의 필요에 대응하기 위해 개발되었습니다. DSDM은 여덟 가지 핵심 원칙에 기반하며, 이 원칙 중 하나라도 준수하지 않으면 프로젝트 성공에 위험이 따릅니다. 여덟 가지 원칙은 다음과 같습니다:

• Collaboration (협업)
• On-time delivery (적시 납품)
• Demonstrated control (명확한 통제)
• Continuous, clear communication (지속적이고 명확한 의사소통)
• A constant focus on the business need (비즈니스 필요에 대한 지속적인 집중)
• Iterative development (반복적 개발)
• Creation in increments from firm foundations (견고한 기초로부터 점진적 창조)
• Refusal to compromise quality (품질 타협 거부)

DSDM에서는 재작업이 프로세스에 내장되어 있으며 모든 변경 사항은 되돌릴 수 있어야 합니다. 시스템 요구 사항은 MoSCoW 규칙을 사용하여 우선순위가 지정되며, 이는 다음과 같이 우선순위를 나눕니다:

• M – must have (반드시 필요함)
• S – should have (있으면 좋음)
• C – could have, but not critical (있으면 좋지만, 필수는 아님)
• W – won’t have now, but could have later (지금은 필요 없지만 나중에 있을 수 있음)

DSDM에서는 모든 요구 사항을 필수로 간주하지 않는 것이 중요합니다. 각 반복에는 덜 중요한 항목이 포함되어야 하며, 이는 더 높은 우선순위의 요구 사항에 영향을 미치지 않도록 제거할 수 있습니다.

6.7 Feature-Driven Development (FDD)

피처 주도 개발(FDD)은 피처별 개발, 코드 소유권, 도메인 객체 모델링과 같은 소프트웨어 공학의 모범 사례를 결합하여 일관된 모델 기반의 짧은 반복 프로세스를 만듭니다. FDD는 전체 모델 형태를 정의하는 것으로 시작하여 피처 리스트를 생성합니다. 그 후, 피처별 계획 수립, 피처별 설계, 피처별 구축에 초점을 맞춘 2주간의 반복으로 진행됩니다. 피처을 구축하는 데 2주 이상이 걸리면 더 작은 기능으로 나누어야 합니다. FDD의 주요 장점은 초기 설계를 적절히 수행하는 JEDI(Just Enough Design Initially) 개념을 사용하여 대규모 팀에도 확장 가능하다는 것입니다.

 

7. Advantages and Disadvantages of Agile

애자일과 폭포수 접근법 간의 비교는 오랜 기간 동안 많이 이루어졌습니다.

7.1 Advantages of Agile (애자일의 장점)

폭포수 시대의 소프트웨어 개발에서는 코더들이 혼자 작업하고, 소프트웨어를 테스터에게 전달하기 전까지 거의 입력이 없었습니다. 버그, 복잡성 및 기능 변경은 잘 처리되지 않거나, 프로세스 후반부에 다루어져 프로젝트가 심각하게 지연되거나 폐기되기도 했습니다.

애자일 모델의 아이디어는 비즈니스 측면을 포함하여 모두가 개발 프로세스에 참여하고 정보를 공유한다는 점에서 회사 문화와 더 나은 소프트웨어를 더 빨리 시장에 내놓을 수 있는 능력에 있어 중대한 변화를 나타냈습니다.

협업과 커뮤니케이션이 기술만큼 중요해졌고, 애자일 선언문이 해석에 열려 있기 때문에 애자일은 모든 크기와 유형의 조직에 맞게 조정되고 수정되었습니다. 애자일 문화의 변화는 최신 소프트웨어 개발 진화인 DevOps로 나아가는 길을 열어주었습니다.

7.2 Disadvantages of Agile (애자일의 단점)

많은 사람들이 애자일의 가장 큰 단점은 많은 조직에서 수정(또는 희석)되었다는 점이라고 말할 것입니다. 이 현상은 너무 널리 퍼져 있어, “우리는 스크럼을 하지만…“이라는 의미의 “스크럼버트(ScrumButs)“라는 용어까지 생겼습니다.

애자일은 개발자와 비즈니스 측면 간의 커뮤니케이션 라인을 열었지만, 테스트와 운영을 그 혼합에 성공적으로 포함시키지 못했습니다. 이는 DevOps 아이디어가 인기를 얻는 데 일조했을 가능성이 있습니다.

또 다른 잠재적인 문제는 애자일이 기술에 대한 강조가 부족하다는 점입니다. 이는 소프트웨어 개발에서 문화의 역할을 이해하지 못하는 고위 관리자에게 개념을 판매하는 데 어려움을 줄 수 있습니다. 또한, 스프린트를 제때 완료해야 한다는 필요성은 소프트웨어 개발자에게 스트레스가 많은 작업 환경을 조성할 수 있습니다. 개발자들은 기한을 맞추기 위해 추가 시간을 작업하고 늦게까지 일해야 할 수 있습니다.

---

2024.07.13 - [System & Software Engineering] - 소프트웨어 공학의 중요성: 의사소통과 협업을 중심으로

소프트웨어 공학의 중요성: 의사소통과 협업을 중심으로

2024.06.19 - [System & Software Engineering] - 소프트웨어 개발자 생산성에 관하여

소프트웨어 개발자 생산성에 관하여