16.2 애자일 선언문(Agile Manifesto)과 12가지 실천 원칙

1. 애자일 선언문의 배경과 의의

애자일 소프트웨어 개발 선언(Manifesto for Agile Software Development)은 2001년 2월 미국 유타주 스노우버드(Snowbird)에서 17명의 소프트웨어 개발 방법론 실천가가 모여 작성하고 서명한 선언문이다. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, 그리고 Dave Thomas가 서명자이다.

이 선언은 1990년대 후반 소프트웨어 산업에서 지배적이었던 폭포수 모형(Waterfall Model) 중심의 중량급(Heavyweight) 개발 방법론에 대한 대안으로 제시되었다. 폭포수 모형의 엄격한 순차적 단계, 방대한 사전 문서화, 그리고 변경에 대한 경직적 대응이 소프트웨어 프로젝트의 높은 실패율의 원인으로 지목되었으며, 애자일 선언은 이에 대한 근본적 패러다임 전환을 제안하였다.

2. 네 가지 핵심 가치

애자일 선언문은 네 가지 핵심 가치를 다음과 같이 선언한다.

“우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.

프로세스와 도구보다 개인과 상호작용을, 포괄적인 문서보다 작동하는 소프트웨어를, 계약 협상보다 고객과의 협력을, 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.

이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.“

3. 가지 실천 원칙

3.1 고객 가치 전달에 관한 원칙

원칙 1: “우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달함으로써 고객을 만족시키는 것이다.” 이 원칙은 대규모 일괄 전달(Big-bang Delivery)이 아닌 소규모 점진적 전달(Incremental Delivery)을 통한 조기 가치 실현을 강조한다.

원칙 2: “비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스는 변화를 고객의 경쟁력을 위해 활용한다.” 이 원칙은 변경을 통제하고 억제하려는 전통적 접근과 대조적으로, 변경을 가치 창출의 기회로 수용하는 태도를 강조한다.

원칙 3: “작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 달의 간격으로 하되, 더 짧은 기간을 선호하라.” 이 원칙은 짧은 반복 주기(Iteration)를 통한 빠른 피드백 루프의 확립을 강조한다.

3.2 협업과 소통에 관한 원칙

원칙 4: “비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.” 원칙 5: “동기가 부여된 사람들 중심으로 프로젝트를 구성하라. 그리고 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.” 원칙 6: “개발 팀으로, 또 개발 팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.”

3.3 기술적 탁월성에 관한 원칙

원칙 7: “작동하는 소프트웨어가 진척의 주된 척도이다.” 원칙 8: “애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.” 원칙 9: “기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.” 원칙 10: “단순성, 즉 하지 않아도 될 일의 양을 최대화하는 기술은 필수적이다.”

3.4 자기 조직화와 성찰에 관한 원칙

원칙 11: “최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 나온다.” 원칙 12: “팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 자신의 행동을 조율하고 조정한다.”

4. 딥테크 기업에서의 해석과 적용

딥테크 기업에서 애자일 선언의 원칙을 적용할 때 다음과 같은 맥락적 해석이 필요하다.

“작동하는 소프트웨어“의 확장적 해석이다. 딥테크 제품에서 “작동하는 산출물“은 소프트웨어뿐만 아니라 하드웨어 시제품, 시뮬레이션 결과, 시험 보고서, 그리고 시스템 수준의 시연을 포함하여야 한다.

“포괄적 문서보다 작동하는 소프트웨어“의 규제적 해석이다. 기능 안전 표준(ISO 26262, DO-178C 등)이 요구하는 문서화 수준은 규제적 의무이므로, 이를 “불필요한 문서“로 간주하여서는 안 된다. 규제가 요구하는 문서는 작성하되, 규제가 요구하지 않는 문서의 불필요한 생산을 최소화하는 것이 이 원칙의 올바른 적용이다.

“면대면 대화“의 현실적 적용이다. 분산 팀 환경에서 물리적 면대면이 곤란한 경우, 화상 회의와 같은 풍부한 매체(Rich Media)를 통한 동기적 소통이 대안이 된다.