며칠 전 대표님과 같이 커피마실 기회가 있었는데, 애자일이 어쩌고 전환 어쩌고 하셨던 기억이 있다. 그 때는 '으음... 오오.. 아하!' 하면서 고개를 끄덕였으나 사실 뭔 말씀인지 몰랐다. 스킬향상에 도움이 되는 개념은 아니지만, 계속 저 단어가 머리에 빙빙 돌아 한 번 정리해 보고자 한다.
애자일으 탄생 배경
위키백과에 따르면 '지나치게 계획적인 개발방식 vs 지나치게 무계획적인 개발방식' 이 충돌하여 서로 타협점을 찾고자 나온 방법론이라고 한다.
한마디로 FM 소대장과 매번 어물쩍 넘어가려는 짬부사관의 자강두천 싸움 같은 느낌이랄까.
이 애자일 다른 방법론으로는 워터폴 모델과 나선모델이 있는데 이것도 추후에 정리해보도록 하겠다.
기존의 프로그래밍은 철저히 단계를 밟아가며 계획된대로 진행되었다. 근데 아무래도 이 프로그램이란 것이, 자동차처럼 시장에 내놓으면 뽑기운이 좋길 바라는... 그런 개념이 아니지 않은가. 또한 소-중한 우리 클라이언트님들께서 마음이 쬐끔이라도 바뀌면 몇날 며칠 힘들게 만들어 놓은 프로그램을 다시 갈아엎어야 하는 상황이 오는데, 그 때 마다 회의하고, 절차 정하고, 문서작성하고 할 수가 없다는 것이다.
그래서 '아 이거 이대론 안되겠다...' 싶어서 등장한 개념이라고 이해하면 편할 듯 하다.
애자일에 대한 개괄적 이해
주구장창 설명하면 이해하기 어려우니 몇가지 키워드로 개념을 잡자
애자일에 대한 첫번째 키워드는 빠른대처다. 앞서 말했듯 소듕하신 고객님들께서 부처님 손바닥 뒤집듯 이랬다 저랬다 하신다던지, 아니면 초기 계획과 다르게 여러 문제들이 생겼을 때 빠르고 유연하게 대처할 수 있다.
두번째 키워드는 소통 이다. 문서로 뭐 만들고, 보고하고, 주고받고 하는 과정을 줄이고 최대한 소통하는것이다. 이 때 소통은 고객들이랑만 하는 것이 아니다. 개발자들끼리도 끊임없이 소통한다. 피드백을 해준다던지, 리팩토링, 효율적인 개발 방식 논의등을 통해 빠른 대처 및 효율성을 향상시키고자 한다.
세번째 키워드는 반복이다. 프로토타입을 만들고 이를 테스트하고 보완하고 하는 방식을 채택한다. 이렇게 하면 왕창 만들어놓고 하나하나 찾는 방식보다, 그때 그때 필요한 것들을 보충할 수 있고, 또 초기 기획에는 발견하지 못했던 문제점들을 조기에 찾아내 대처할 수 있다.
대충 어떤 느낌인지 감이 왔다면 좀 더 세부적인 개념으로 들어가 보자
세부개념은 다음화에 계속...
