애자일 매니페스토란?
애자일 매니페스토(Agile Manifesto)는
애자일 소프트웨어 개발 선언 이라고 불리며, 소프트웨어 개발에 대한 원칙을 담은 선언문이라고 할 수 있다. 이 선언문은 2001년 17명의 소프트웨어 개발자들에 의해서 만들어 졌으며, 이 중에 소프트웨어 분야에 큰 획을 그은 인물들이 많다. 그 중에 몇몇을 소개해 보자면,
- 켄트 백 (Kent Back)
- 익스트림 프로그래밍(XP, eXtreme Programming)의 창시자로 애자일 방법론의 확산에 가장 큰 영향을 미친 인물 중 한 명이다.
- 테스트 주도 개발 (TDD, Test-Driven Development) 개념을 널리 알렸으며, 현대 소프트웨어 개발의 필수적인 실천법으로 자리 잡았다.
- 로버트 C. 마틴 (Robert C. Martin, “Uncle Bob”)
- ‘클린 코드 (Clean Code)’, ‘클린 아키텍처(Clean Architecture)’등의 저서를 집필 하였다.
- SOLID와 같은 객체 지향 설계 원칙을 정립하여 많은 개발자들에게 영향을 주었다.
왜 이런 선언문이 필요하게 되었을까??
당시에 주로 사용되던 개발방식은
폭포수 모델 이라고 불리었다. 이 방식은 폭포수 라는 말 처럼, 물이 위에서 아래로 떨어지 듯이 각 개발단계를 완벽하게 정의하고 다음 단계로 넘어가며 완성하는 방식으로, 다시 이전 단계로 매우 돌아가기 힘든 구조 였다. [개발 단계] 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포
개발 단계 자체야, 현재 소프트웨어 프로그래밍과 다른 점이 없어서, 그냥 폭포수 모델을 안 사용하면 되는거 아닌가? 하는 생각이 들 수 있다. 하지만 이러한
폭포수 모델을 사용하게 된 경위는 당시 상황에 비하면 최선의 선택이었다고 할 수 있다. 왜냐하면, 소프트웨어라는
신사업 으로 돈을 벌어야 되는데, 고객에게 어떻게 설명할 수 있을까? 고객은 이 새로운 소프트웨어라는 것이 무엇이라 이해하고 돈을 투자할 수 있었을까?? 그러기 위해서 소프트웨어 엔지니어는 이거 어떤 역할과 기능을 할 수 있는 지, 고객의 요구사항을 전부 반영한 결과물이 어느 기간안에 나올 수 있는지 기존 건설업과 제조업의 사업 방식대로 제안할 수 밖에 없었다. 또한 당시에는, 지금과는 비교할 수 없을 정도로 열악한 컴퓨팅 환경도 큰 몫을 차지했다. 폭포수 모델이 메인 스트림이었던 시대에는, 컴퓨터의 메모리, CPU 모든 것들이 비싼 자원이라 코드를 한 번 컴파일하는데도 상당한 시간과 비용이 발생했다. 더군다나, 완성된 제품에 변경을 하게 될 경우에는 재앙에 가까운 비용이 발생했다. 따라서
한 번에 실수없이 만들자 라는 생각이 지배적이었다. 어떻게 보면,
폭포수 모델은 소프트웨어의 본질이 변화와 유연성에 있다는 사실을 깨닫기 전에, 기존 산업의 성공 모델과 기술적 한계속에서 시도할 수 있는 최선의 방법이었다고 할 수 있다. 매니페스토엔 어떤 내용이 있나?
매니페스토의 내용은 아래와 같다.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
매니페스토는 다음과 같은 말로 시작한다.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
여기서
uncovering 이라는 단어로 글을 시작하는 데, 이 매니페스토는 규칙이 아니라 발견이라고 선언하는 것으로 애자일은 이미 완성된 불변의 법칙이 아니라, 계속해서 더 나은 방법을 찾아가는 과정을 표현하는 겸손한 자세임을 보여준다. 이 정신은 애자일의 원칙인
지속적인 개선 과도 일맥상통 한 것으로, 이것이 최종 정답은 아닐 수 있지만, 현재까지 우리가 발견한 최선의 방향입니다 라고 말하는 것과 같다.그리고
by doing it and helping others do it 문구를 보면, 이 당시 선언문을 만들었던 사람들은 그냥 단순 이론가들이 아닌 실제 현장에서 피와 땀으로 얻어낸 결론이라는 신뢰감을 준다. 또한 이것이 단순 지식 자랑이 아닌 다른 사람을 도우면서 얻은 결론이라는, 정말 소프트웨어 개발 공동체를 위해 방향성을 제시하고 있다고 느낄 수 있다. Individuals and interactions over processes and tools
이 문구는
개인과 상호작용이 절차와 도구보다 우선한다 내용으로 당시 폭포수 모델의 제조업 공장과 같은 개발방식을 해결하기 위한 것이었다. 제조업 공장에서의 공정과정과 도구들은 개인보다 우선되는 경향이 크다. 왜냐하면 수천만원을 들여서 도구를 구매하여 공정절차에 포함 시키면, 개인들을 해당 도구를 사용하는 것 자체가 목적이 되어버린다. 또는 그런 제조업의 절차는 누가와서 일하든 똑같은 결과를 만들어 내야하므로, 개인의 일하는 방식보다는 공정 절차가 진행되는 방식이 더 우선되었던 것이다.
그리고
폭포수 모델이 이러한 산업의 기반에서 만들어 졌기 때문에, 소프트웨어가 점차 발전할수록 한계를 느낄 수 밖에 없었다. 이를 개선하기위해 애자일 방식은, 복잡한 문제일 수록 형식적인 문서나 절차를 따르는 것 보다 관련된 사람들끼리 직접 만나 이야기 하는 것이 훨씬 더 빠르고 정확하게 문제를 해결하는 것이 좀 더 우선시되어야 된다는 제안을 한 것이라 볼 수 있다. Working software over comprehensive documentation
폭포수 모델은 소프트웨어를 만들기 전에 모든 것을 정의해야 했다. 이 과정에서 엄청난 문서들이 작성되어야 했었는데, 요구사항 명세서, 상세 설계서, 데이터 베이스 설계서 등등이다. 문서화라는 것이 없어야 된다고 주장하는 것은 아니지만, 문서화라는 것이 많은 문제점을 동시에 안고 있다. 문서는 쉽게 최신정보를 반영하지 못하게 되고, 쉽게 읽는 사람에 따라서 오해를 낳게 된다, 또 개발자들은 이 문서화 작업 때문에 개발보다 문서를 만드는에 들이는 시간이 더 많았던 시절이었다.
따라서
Working software 라는 것은 어떻게 보면 백문이 불여일견이라는 말처럼 직접 눈앞에서 돌아가는 작은 기능 하나가 ‘이렇게 동작할 거야’라는 문서보다 고객에게 전달할 수 있는 확실한 메시지라고 말하는 것이다. 그리고 그에 대한 피드백을 받는 것이 중요하다고 말한다. 어떻게 보면 고객에겐 완벽한 문서더미가 아니라 동작하는 소프트웨어가 가치 있는 것이니까
Customer collaboration over contract negotiation
당시 고객과 개발사의 계약서는 서로간의 창과 방패처럼 여기어져왔다. 고객은 개발사가 나중에 딴 소리 못하게, 가능한 모든 기능을 계약서에 최대한 빽뺵하게 집어넣으려고 했고, 개발사는 고객이 딴지를 걸거나 추가 요구할 때를 대비해서, 우리가 책임져야 할 범위를 계약서상에서 최대한 좁고 명확하게 책임을 한정지으려고 했다.
따라서 한 번 계약서에 도장을 찍고 나면, 그 내용은 마치 바꿀 수 없는 법전처럼 취급 되었고, 변경하려면 다른 변경요청 절차를 진행해야 했는데, 이에 따른 비용이 엄청나서 변경하지 말라는 압박과도 같았다.
하지만 시대와 시장은 유기적으로 변화하기 때문에 프로젝트가 끝나고 계약서 상의 모든 기능이 구현이 되어도, 정작 그 결과물은 고객의 실제 문제를 해결해주지 못해 아무도 만족하지 못하는 비극적인 상황이 자주 발생한 것이다.
따라서 애자일 방식은 고객을 적과 같은 대립관계가 아니라 고객을 협업자, 팀원으로서 지속적인 소통으로
Customer와 collaboration 하여 완성해 나가겠다는 의지인 것이다.Responding to change over following a plan
폭포수 모델 과 같은 전통적인 프로젝트 관리 방식에서의 계획은 완벽해야하고, 반드시 따라야 하며, 계획대로 진행 되는 것이 최고의 미덕이었다. 하지만 현실에서의 계획대로 진행되지 않는 일이 많다. 예를 들어, 고객의 마음이 바뀔 수 있고, 시장은 변하며, 단순 기능 구현이라고 생각했던 것이 엄청난 복잡성을 가진 기능이었으며, 개발할 사람들이 바뀌기도 한다. 이러한 현실 속에서, 애자일의 방식은 계획은 필요하지만 맹신하면 안된다고 말한다. 그리고 계획대로 되지 않으면 틀리고 잘못된 것이라고 생각하는 양상에 대해서 다른 시각을 제시하는 것이다. 마치 지도보다는 계획을 나침반으로서 사용하길 권한다. 어떻게 보면 프로젝트의 성공은 계획을 얼마나 잘 지켰느냐가 아니라, 어떻게 가치를 전달하는 것인지가 핵심이기 때문이다.
나침반이 가리키는 방향으로 나아가되, 예기치 못한 강을 만나면 다리를 놓고, 더 좋은 지름길을 발견하면 과감하게 경로를 수정해야된다는 것이다. 이러한 것이 불확실한 현실속에서 목표를 향해 나아가는
애자일의 핵심사상 이라고 할 수 있다.That is, while there is value in the items on the right, we value the items on the left more.
이 마지막 문장이, 애자일 매니페스토의 균형을 잡아주는 역할을 한다. 왜냐하면 이 문장이 없으면, “기존 방식은 쓸모 없으니 사용하지 말라” 라고 들리기 때문에다. 이 17명의 프로그래머들은 오른쪽의 항목들인 프로세스 / 문서 / 계약 / 계획이 쓸모 없다고 이야기하려는 게 아니다.
이 개발자들이 말하려고 했던 것은
균형과 우선순위이다. 두 가지의 방식을 따라가되, 두 가치의 충돌이 발생했을 때, 어디에 가치를 두고 결정해야되는 지 가이드를 제시하는 것이다.예를 들어, 새로운 아이디어가 떠올랐을 때 기존 방식으로는 문서화하고 공식 변경절차를 밟는데 꽤 오랜 시간이 걸렸다면, 애자일 방식은 당장 개발자와 고객이 만나 대화해서 방향을 결정하고 개발에 착수 할 수 있게 유연성을 두자는 것에 가깝다.
개인적인 결론
마지막문장을 설명하면서 강조하였다 시피, 이 애자일 매나페스토는 기존의 방식을 철폐하려는 것이 아닌 소프트웨어의 개발방식에서 부족했던 부분을 완성하려는 듯한 움직임과 비슷하다고 생각한다. 예수님께서도 구약을 철폐하려는 것이 아니라 완성하기 위해 오셨다고 하는 말씀과 얼추 비슷한 맥락이라 개인적으로 느껴진다.
애자일의 방식으로 인해서, 소프트웨어업은 일로서의 일이 아닌 진정한 가치전달을 위한 방식이 아닐 까 싶다. 어떻게 보면 애자일 방식이라는 것이 이런 방식이다라고 특정 지을수 도 없을 것 같다. 그저 서로와 소통하며 같이 윈윈하기 위한 모든 방법이 애자일 방식이 아닐까 생각한다.
앞으로도 일을 할 때 주어진 일에 대해서 그 일을 완성했다 하더라도 그 속에서 내재된 문제가 느껴지는 데도
에이 뭐 쟤네들이 알아서 하겠지 라고 손을 놓아 버린다면, 그건 애자일 방식이 아닐 것이다. 고객도 개발자들도 서로서로 최선을 결과를 만들기 위해서 최선을 다하고 소통하며 존중하며 나아가는 것이 애자일이 아닐까 생각한다.