위의 애자일 매니페스토에도 있지만, 협업(개인과 상호작용), 작동하는 소프트웨어, 고객과 협력, 변화에 대응하는 것에 초점을 맞추었습니다. 실제로 소프트웨어 개발만 봐도, 10년 전과 지금의 기술 스택도 다를 뿐 더러, 만약 현재 우리가 사용하는 기술 스택을 담당하던 분이 갑자기 업데이트를 중단해버리면 우리는 다른 기술 스택을 적용해야 할 수 있습니다. 그렇기에 우리는 불확실한 영역인 개발에서 애자일이 전통적인 폭포수 방식보다 더 적합할 것입니다. 그리고 더 나아가 생각해보면 과거의 많은 개발자 분들은 애자일 방법론을 지지하고, 적용하고 있기 때문에 많은 회사에서 애자일을 발전시켜서 적용하는 중일 겁니다.
전통적인 폭포수 방법론
앞에서 계속 전통적인 폭포수 방법론에 대해 언급하는데, 잠깐 폭포수 방법론에 대해 이야기하고 넘어가겠습니다.
폭포수 모델은 전통적인 소프트웨어 개발 방법론이다. 1970년 Winston W. Royce가 처음 소개했다. 일련의 단계로 구성된 소프트웨어 개발을 선형적이고, 순서대로 접근한다. 각각의 순서를 끝내야한다. 간단하고 이상주의적이다. 옛날에 매우 유명했지만, 오늘 날에는 자주 쓰이진 않는다.
하지만, 이 모델은 중요한데 그 이유는 대부분의 소프트웨어 개발 주기 모델이 여기서 파생되었기 때문이다.
출처: https://www.geeksforgeeks.org/waterfall-model/   (번역: 필자)
여기서 보면 알 수 있듯이, 폭포수 방법론은 기술적으로 불확실한 정도가 낮거나, 안정성이 필요한 대규모 시스템에서 보통 많이 사용한다고 합니다.
애자일의 역사
 그렇다면 애자일은 어떻게 생긴걸까요? 한번 https://agilemanifesto.org/history.html 이 문서를 Claude로 번역하며 알아봅시다.
2001년 2월 11일부터 13일까지, 유타주 와사치 산맥에 위치한 스노우버드 스키 리조트에서 17명이 모여 대화하고, 스키를 타고, 휴식을 취하며 공통점을 찾기 위해 노력했습니다—그리고 물론, 함께 식사도 했습니다. 이 모임에서 애자일 '소프트웨어 개발' 선언문이 탄생했습니다. 익스트림 프로그래밍, 스크럼, DSDM, 적응형 소프트웨어 개발, 크리스털, 기능 중심 개발, 실용주의 프로그래밍 등을 대표하는 사람들과 문서 중심적이고 무거운 소프트웨어 개발 프로세스에 대한 대안의 필요성에 공감하는 이들이 모였습니다.
더 큰 규모의 조직적 무정부주의자들의 모임을 찾기는 어려울 것이므로, 이 회의에서 나온 것은 상징적인 것이었습니다—모든 참가자들이 서명한 애자일 소프트웨어 개발 선언문이었습니다. '애자일(agile)'이라는 용어에 대한 유일한 우려는 마틴 파울러(영국인인데, 그를 모르는 사람들을 위해 말하자면)로부터 나왔는데, 그는 대부분의 미국인들이 '애자일'이라는 단어를 발음하는 방법을 모른다고 지적했습니다.
앨리스테어 콕번의 초기 우려는 많은 참가자들의 초기 생각을 반영했습니다. "개인적으로 이 특정 애자일 지지자들 그룹이 실질적인 어떤 것에도 동의할 것이라고 기대하지 않았습니다." 하지만 그의 회의 후 감정도 공유되었습니다. "저 개인적으로는 최종 문구에 매우 기뻤습니다. 다른 사람들도 최종 문구에 똑같이 기뻐 보인 것에 놀랐습니다. 그래서 우리는 실질적인 무언가에 동의했습니다."
우리 자신을 "애자일 연합(The Agile Alliance)"이라고 명명하면서, 소프트웨어 개발에 대한 독립적인 사상가들이자 때로는 서로 경쟁자이기도 한 이 그룹은 이 웹사이트의 제목 페이지에 표시된 애자일 소프트웨어 개발 선언문에 동의했습니다.
그러나 선언문이 몇 가지 구체적인 아이디어를 제공하는 동안, 연합의 많은(물론 모든 것은 아니지만) 회원들을 이끄는 더 깊은 주제가 있습니다. 이틀간의 회의가 끝날 무렵, 밥 마틴은 자신이 "감성적인" 발언을 하려 한다고 농담했습니다. 그러나 유머가 섞인 말이었지만, 밥의 감정에 동의하지 않는 사람은 거의 없었습니다—우리 모두는 서로에 대한 신뢰와 존중에 기반한 가치관, 그리고 사람, 협업, 우리가 일하고 싶은 조직 커뮤니티를 구축하는 조직 모델을 촉진하는 가치관을 가진 사람들 그룹과 함께 일할 수 있는 특권을 느꼈다는 것입니다. 핵심적으로, 저는 애자일 방법론자들이 실제로 "감성적인" 것에 관한 것이라고 믿습니다—"사람이 우리의 가장 중요한 자산"이라고 말하는 것을 넘어, 실제로 사람이 가장 중요한 것처럼 "행동"하고 "자산"이라는 단어를 없애는 환경에서 운영하여 고객에게 좋은 제품을 제공하는 것에 관한 것입니다. 따라서 최종 분석에서, 애자일 방법론에 대한 관심의 급격한 상승—그리고 때로는 엄청난 비판—은 가치와 문화의 감성적인 부분에 관한 것입니다.
예를 들어, 궁극적으로 익스트림 프로그래밍이 사용과 관심에서 폭발적으로 성장한 것은 페어 프로그래밍이나 리팩토링 때문이 아니라, 전체적으로 봤을 때 이러한 실천 방법들이 딜버트식 기업의 짐으로부터 해방된 개발자 커뮤니티를 정의하기 때문이라고 생각합니다.
이렇게 애자일은 기존의 방식을 탈피하고 자신만의 개발 방법론을 가진 사람들이 만나 회의를 통해 만들어졌습니다.
더 나아가서
 그리고 이 회의에서 애자일 매니페스토 이외의 12가지 원칙들이 있습니다. 각각 어떻게 보면 우리가 프로젝트를 진행하는데 있어서 한번 참고하면 좋을 것 같아 공유해보자면 다음과 같습니다.
애자일 선언 이면의 원칙
우리는 다음 원칙을 따른다:
우리의 최우선 순위는, 가치 있는 소프트웨어를
일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
비록 개발의 후반부일지라도 요구사항 변경을 환영하라.
애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이
되게 한다.
작동하는 소프트웨어를 자주 전달하라. 두어 주에서
두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에
걸쳐 날마다 함께 일해야 한다.
동기가 부여된 개인들 중심으로 프로젝트를 구성하라.
그들이 필요로 하는 환경과 지원을 주고 그들이 일을
끝내리라고 신뢰하라.
개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장
효율적이고 효과적인 방법은 면대면 대화이다.
작동하는 소프트웨어가 진척의 주된 척도이다.
애자일 프로세스들은 지속 가능한 개발을 장려한다.
스폰서, 개발자, 사용자는 일정한 속도를 계속 유지
할 수 있어야 한다.
기술적 탁월성과 좋은 설계에 대한
지속적 관심이 기민함을 높인다.
단순성이 -- 안 하는 일의 양을
최대화하는 기술이 -- 필수적이다.
최고의 아키텍처, 요구사항, 설계는
자기 조직적인 팀에서 창발한다.
팀은 정기적으로 어떻게 더 효과적이 될지
숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
그래서 애자일에 관한 당시의 구체적인 방법들을 살펴 볼 수 있습니다.
마무리
 이렇게 애자일에 관하여 알아봤습니다. 우리는 프로젝트를 진행하면서 많은 사람들과 대화를 통해 무언가를 만들어내기도 합니다. 그런 부분에서 보자면 애자일은 성공적인 프로젝트를 만들어내는 것에 대한 좋은 방법 중 하나라 생각됩니다. 곧 있을 솔루션 챌린지에서도 한번 활용해보는 것은 어떨까요? 현재는 이미 많은 분들이 애자일을 변형하여 만들어놓은 프로젝트들이 있어서 한번 고민해 봐도 좋을 것 같습니다.