도대체 애자일이란 무엇인가? 기술자만 이해할 수 있는 특수한 개념인가? 현실과 동떨어진 이상론인가? 그저 좋은 것은 다 애자일인가? 모두 아니다. 애자일은 변화에 기민하게 대응하기 위한 경영 기법이다. 스티브 블랭크는 린스타트업은 고객 개발과 애자일 개발을 결합한 것이라 했다.
애자일 기본 원리는 다음과 같다. (스티브 잡스 말 처럼 탁월한 경영 원리는 단순하고 당연하지만, 실천은 쉽지 않다.)
- 요구 사항은 언제나 변할 수 있다. (변하지 않는 것이 비정상.)
- 그러니 일을 최대한 작게 쪼개서 우선 순위가 높은 것 부터 처리하고,
- 문서가 아닌 동작하는 소프트웨어를 수시로 확인하여 요구 사항 변화나 예기치 못한 변수를 조기에 감지하자.
그렇다면 애자일은 왜 필요할까? 질문을 바꿔보자. 경영은 왜 필요한가? 소프트웨어 개발 프로젝트는 태생적으로 복잡도가 높고 변수가 많기 때문이다. 명확한 핵심 가치와 우선 순위 정의가 없다면 난제를 해결하기 어렵다. 우선 순위는 명확하면 명확할 수록 좋다. 우선 순위가 명확해서 해로울 것은 아무것도 없다.
물론 주먹구구 방식이 반드시 실패하는 것은 아니다. 제법 큰 규모의 성공을 거둘 수도 있다. 하지만 불확실성이 커지면 주먹구구 방식은 위험에 무방비로 노출된다. 주먹구구 성공 경험을 창의, 직관, 경륜 따위로 착각한다면 위험은 더욱 커진다. 문제를 해결하려면 공상과 합리화를 멈추고 현실을 직시해야 한다.
우리는 쓸데없이 과도하고 복잡한 생각을 하면서, 이것을 직관적이며 자연스럽다 여기며 자원을 낭비하는 실수를 반복한다. 사람의 두뇌는 축적, 저장, 비축, 수집, 분류 따위를 하도록 설계되어 있기 때문에, 우리는 선천적으로 더 많은 것을 선호한다. 애자일은 문제 해결에 방해가 되는 본능을 억제한다.
소프트웨어 프로젝트의 요구 사항은 끊임없이 바뀔 수 밖에 없으며, 이는 자연스러운 현상이다. 사용자는 직접 써 보기 전 까지는 자신이 무엇을 원하는지 정확히 알지 못하니까. 하지만 기존의 유연하지 못한 관리 방식이나 주먹구구 식으로는 요구 사항 변화에 지혜롭게 대처하기 어렵다. 그래서 애자일이 필요하다.
애자일을 어설프게 적용하여 실패한 프로젝트를 경험하고 애자일을 의심하는 경우도 있다. 실패 원인을 명확히 파악하지 못하고 애꿏은 애자일 탓만 하는 것이다. 조선 민주주의 인민 공화국의 민주주의가 효과를 발휘하지 못하는 것 처럼, 애자일 개발 역시 어설프게 실행하면 효과를 보기 어렵다.
애자일은 개발 방법론이기 이전에 일이 되게 하기 위한 경영 기법이며, 개발자와 비개발자가 원활히 소통하기 위한 방식이다. 애자일이 만병통치약은 아니다. 합리적 경영 역량, 기본적인 근면성실, 새로운 방식을 배우려는 의지와 호기심 따위가 없다면, 애자일의 장점이 제대로 발휘될리 없다.
폭포수 모델이 잘 맞는 프로젝트 따위는 없다. 사람을 바꾸기 어려울 뿐. 개발 현장에 애자일 적용이 어려운 오만가지 이유가 있겠으나 한 마디로 말하면 용기 부족. 발주자는 당초 계획한 기능을 하나라도 버릴 용기가 없다. (예정에 없던 기능을 무시로 끼워 넣을 만큼 염치도 없다.) 개발자는 주기적으로 동작하는 데모를 구현해서 시연할 용기가 없다.
애자일을 적용하고 싶지만 애자일이라는 용어가 모호하고 어렵게 느껴진다면, 그래서 동료나 고객과의 소통이 힘들어졌다면, 당분간 애자일이라는 말을 입 밖에 내지 말고, 대신 '일을 작게 쪼개자, 우선 순위를 명확히 하자, 일부 기능이라도 갖춘 제품을 최대한 빨리 릴리즈하여 직접 써 보자'고 말해보자.
댓글 없음:
댓글 쓰기