왜 애자일일까?

올해로 애자일 매니페스토가 선언된지 10년이 된다. 애자일(Agile)은 한글로 '민첩한'이라는 의미이다. 그동안 SW 개발에서 애자일에 관련된 시도와 노력을 많은 영역에서 접근했지만 현실의 프로젝트는 폭포수 형태의 단계적인 개발 방식을 고수하고 있다. 많은 사람들이 단계별로 감리를 통해 계약을 맺는 관행을 이야기하기도 하며, 진척률이라는 형태로 WBS의 작업 항목들을 처음에 만들어 놓은 대로만 측정하여 통제하려는 문화적인 측면을 이야기하기도 한다.

1990년대부터 시작된 방법론에 대한 발전은 중량(heavyweight)와 경량(lightweight) 방법론의 형태로 1990년대 중반에 갈라지며, 당시 스크럼, XP 등의 방식이 나타나기 시작하면서 애자일 방식의 모태가 되기도 한다. 애자일이라는 용어가 키워드로 나타난 것이 10년 전 17명의 애자일 선구자들이 선언한 애자일 매니페스토이다.

애자일 매니페스토에서는 애자일에 관련된 어떠한 구체적인 실행/수행 방법을 거론하지 않고 있으며 큰 줄기의 원칙들만이 기술되어 있다. 물론 이 매니페스토를 만든 사람들은 현재의 애자일 기법이라고 하는 방식을 이전부터 실천하고 있었던 사람들이다. 애자일 방식의 대표적인 스크럼을 접해본 사람들이나 책을 읽었던 사람들은 현실에서의 괴리를 한번쯤 생각해봤을 것이다. 참으로 단순하다. 심지어 1~2시간 정도의 내용만 익힌다면 스크럼 방식으로 개발하는 것을 익힐 수도 있다.

이제 애자일은 개발 방식 뿐만 아니라, 프로젝트 관리, 품질관리 등의 분야로 확산되고 있다. 또한, 해외에서는 오프쇼어나 아웃소싱 영역까지도 애자일 방식의 프로그램 관리 등까지 확산하고 있는 것 같다. 하지만, 아직까지 애자일이 확실한 소프트웨어 개발 방식 중에 최고라는 생각은 들지 않는다. 왜냐하면 아직까지도 소프트웨어 프로젝트의 성공률이 그리 높지만은 않다는 사실이 소프트웨어 개발에 있어서 은총알은 역시 요원하다는 생각이 든다. 애자일을 즐기는 사람들이 말하는 것들은 기존 RUP나 폭포수 같은 중량 방법론의 반대급부적인 의견이 많다. 즉, 애자일 매니페스토 선언에도 언급된 동작하는 소프트웨어(working software)에 초점을 맞춘 개발 접근 방식의 효과적이고 효율적인 측면을 거론한다. 불필요한 작업들(수많은 문서를 만들어놓고 정작 시간이 지나면서 쓸모없어지는 것들)을 과감하게 생략하고 꼭 필요한 작업만을 수행함으로써 프로세스에 대한 부담을 경감시키려고 한다. 현실적인 작업에 있어서 이러한 방식은 작업자에게 많은 도움이 되는 것이 사실이다. 하지만, 무엇인가 가시적이고 진행 상태를 점검하고자 하는 관리적인 측면에서 보면 소스 코드 하나 변경하는데도 부담스러운 프로세스를 적용하고자 하는 욕심이 생긴다. 또한, 큰 그림의 계획을 세우는데 있어서 짧은 기간의 계획을 수행하는 애자일 방식은 단순히 다른 동네 이야기로만 치부하여 역시 프로젝트 관리는 중량 방법론이 적합하다는 의견을 내세우며 이를 가벼운 이야기로 돌려버린다.

애자일 과연 효과적인가

애자일이 국내에서 활발하게 도입되는 분야가 게임분야라는 이야기를 종종 듣는다. 일년에도 수십번씩 바뀌어야 하는 게임 소프트웨어의 특성상 (혹은 명확한 비즈니스를 정립하기 어렵운 것도 한 요인이 되겠지만) 변화를 수용하는 애자일 방식은 게임 소프트웨어 개발에 그야말로 적합했을 것이다. 애자일 매니페스토에서는 2주에서 2달 간의 짧은 주기를 통해서 동작하는 소프트웨어를 인도하도록 명시되어 있다. 소프트웨어 인도의 빠른 주기는 이러한 비즈니스 특성을 타는 분야에서 적극적으로 수용을 필요로 했을 것이다. 하지만, 게임 산업의 전반적인 흐름을 보면 그 이익에 있어서 빈익빈 부익부 현상이 발생되는 영역이기도 하다. 빠른 비즈니스 변화를 겪는 분야에서는 먼저 선점하는 것이 이익의 대부분을 차지하게 된다. 애자일을 도입하여 빠른 비즈니스에 대처한다고 하지만, 수익을 얻는 과정은 애자일과는 별도의 분야이어서 애자일의 도입이 바로 수익과 연결된다고 보기는 힘들다. 애자일의 도입을 활성화시키기 위해서는 무엇보다도 빠른 비즈니스 대처를 효율적으로 수행하는 애자일의 장점과 이로 인해서 수익을 얻을 수 있는 영역에 대한 연결고리가 필요하다. SW 개발 방식은 폭포수 방식이든 애자일 방식이든 관리자들 눈에는 동작하는 소프트웨어가 나오는 것이 가장 큰 목표이다. 하지만, 동작하는 소프트웨어가 무조건 에러없이 돌아가는 소프트웨어를 의미하지 않는다. 어떤 기능을 가진 동작하는 소프트웨어인지를, 그리고 그것이 비즈니스와 어떤 관계가 있는지를 명확하게 설명할 수 있어야 한다.

개발자들에게 실질적인 작업만을 수행할 수 있게 한다는 논리로 애자일 도입을 강요하거나 추천할 수는 없다. 애자일이 기업에 도입되기 위해서는 기업의 수익 증대 측면에서도 그 효과를 증명해야 한다. 물론, IT 기술 도입이 수익 증대에 효과적이다라는 비즈니스 모델의 접근 방식이 도움이 되긴 하지만, 이 IT 기술이 애자일을 통해 지속적으로 변화가 가능한 소프트웨어를 의미하는지, 빅뱅 형식의 단계적인 개발 방식으로 오픈 후에도 자잘한 버그와 데이터 무결성을 맞추기 위한 노력을 추가로 필요로 하는 소프트웨어인지를 명확히 해야 한다. 개발자들만을 위한 애자일은 경영자나 관리자에게 그리 중요한 것은 아닐 수도 있다.

애자일이 개발 접근 방법의 대안이 될 수 있는가

애자일 프로세스라고 속하는 개발 접근 방법은 스토리 방식의 요구사항 관리, 추정에 의한 일정 계획/관리, 테스트 기반의 개발, 지속적인 통합/인도, 커뮤니케이션을 통한 코드 리뷰/회고 등이 있다. 모두 그 효과나 효율성 면에서 좋은 접근 방식이며 정말 개발자들에게 꼭 필요한 방법들이다. 하지만, 그 밖의 것들은 어떻게 해야 하는가? 예를 들어, 개인당 진척 관리, 프로젝트 전체 계획과 예산/공수 소요 예측, 전체 개발 범위의 예측 및 계획, 인력관리, 비즈니스 요구사항에 대한 정리, 위험 관리 등등. 수많은 애자일 프로세스에 속하지 못한 것들은 사소하다고 볼 수 없는 것들이다.

소프트웨어 개발을 바라보는 시선들을 모두 애자일식 접근 방법으로 강요할 수는 없다. 하지만, 애자일 방식이 아닌 개발 접근 방법들이 과연 효과적이거나 효율적이라고 할 수 있을까? 어느 측면에서 경량 프로세스와 중량 프로세스는 상호 보완적인 성격들이 분명 존재하며, 아직까지 이 두가지 방식은 혼재하여 소프트웨어 개발을 진행할 것으로 보인다. 애자일이 아닌 방식으로 프로젝트를 진행한다고 하더라도 애자일 방식이 아니라서 거부할 수 있는 태도는 좋지 못하다. 또한, 애자일이라서 아예 시도조차 해보지 않고 맞지 않는다고 이전의 방식으로 되돌아가려는 태도 역시 바람직하지 못하다.

결국 애자일이 개발 접근 방법의 한가지 대안의 형태보다는 효율적이고 효과적인 부분은 적극 도입하려는 노력이 필요하며, 이는 개발자에게 뿐만 아니라, 프로젝트 관리나 고객 측면에서도 더 도움이 되는 방향으로 적용해야 한다. 중량 개발 방법론을 사용하는 프로젝트에서는 소프트웨어 개발을 하나의 거대한 덩어리 형태로 생각하고 A부터 Z까지를 하나의 접근방식만을 도입하려 하는 경향이 있다는 것이다. 특히, 대형 시스템의 경우, 이러한 접근 방식은 각 업무의 특성을 무시하고 몸에 맞지 않는 옷을 어거지로 입히려는 접근 방식을 도입하는 형태로 좀 더 다양한 형태의 접근 방식을 고려하여 채택할 필요가 있다. 통제와 관리, 운영적인 측면에서 변형이나 변이를 용납치 않는 개발 접근 방식은 또 다른 문제를 가지고 올 수 있는 단초를 제공하기도 한다. 애자일 역시 이러한 오류에 빠질 수도 있지만, 반복과 점증의 형식을 채택할 수 밖에 없는 애자일 방식에서는 이러한 위험성을 상당히 줄일 수도 있다.

운영 시스템에서는 고정된 SR 처리 방식을 고수하여 시스템의 변형을 최소화시키고 최대한 안정화하려는 경향이 강한데, 애자일이 이 영역까지도 고려될 필요가 있다. 소프트웨어 생명 주기에서 거의 절반 이상을 차지하는 유지보수 단계에서 고정되거나 유연성이 없는 개발 접근 방식은 기존 시스템에 새로운 문제들을 주입하는 형태로 진화시킬 수도 있다. 결국 개발 접근 방식은 애자일이 주창하는 방향성에 초점을 맞추려는 노력이 필요하다.

하지만, 애자일 개발 접근 방식이 앞으로의 소프트웨어 개발 방식의 대안이 되기에는 아직까지 해결해야 하는 문제들이 많이 있다. 특히나, 한번에 모든 것을 해결하고자 하는 국내 특성에 애자일 방식은 무엇인가 부족하게 느껴지는 방식으로 인식될 수 있다. 과연 현업과 개발자의 협업이 얼마나 효과적으로 진행될지, 그리고 과연 동작하는 소프트웨어만으로 프로젝트의 모든 것을 이야기할 수 있는지는 현장에서 의심이 되는 부분들이다.

소프트웨어 개발 프로젝트는 현실 세계에서 그동안 국내에서 진행된 관습이 분명 존재하며 애자일은 여기에 맞추려는 노력을 해야 애자일 개발 방식이 앞으로 더 의미있는 발전을 할 수 있다. 아무리 기존 개발 방식의 단점을 이야기한들 이미 여기에 익숙해져있고, 다른 대안을 찾아보려고 노력하지 않는 사람들에게는 소귀에 경읽기에 지나치지 않는다. 좀 더 눈높이를 맞추려는 노력이 필요하다.

애자일, 그 다음은

애자일은 아직 현실적으로 국내에서도 그리 활발히 도입하고 있지는 않은 것 같다. 특히, 공공이나 금융과 같은 대형 프로젝트들에서 애자일 접근 방식에 대한 도입은 상당한 모험이기도 하며, 경직화된 조직 전체의 문화를 바꾸어야 가능한 것처럼 보인다. 또한, 유지보수 단계 역시 애자일 개발 방식의 접근 방식은 전혀 다른 나라 이야기로 취급되기 일수이다. 애자일은 국내에서 정착화하기 전에 다른 개발 접근 방식이 나온다면 그리고 그 개발 접근 방식이 국내 입맛에 맞는다면 그저 예전에 있었던 개발 방식 정도로 소프트웨어 개발사에 남을 것이다.

애자일의 도입이 국내 소프트웨어 개발 프로젝트에 시급히 필요한 부분은 소프트웨어 개발로 먹고 사는 문제 뿐만 아니라, 너무나도 힘든 환경의 탓이 크다. Best Practice들을 도입했던 프로젝트들은 왜 Worst Case들로만 남게 되었는지를 생각해보면 애자일이 추구하려는 원칙과 목적에서 그 답을 한번 찾아보는 것도 도움이 될 것이다.

애자일이 린(lean)과 칸반(Kanban)과 같이 새로운 방향을 추구하는 모습을 보이고 있다. 이들의 궁합이 잘 맞게 연결고리를 찾아가는 모습을 보면, 애자일의 본고장에서는 정착화 단계를 지나 새로운 접근 방향으로 모색을 하는 것이 부럽기만 하다. 어찌보면 국내에서는 프로세스를 통해서 작업을 진행하기 위한 문화가 그리 쉽게 정착하기란 쉽지 않은 이유도 있을 듯 하다. 비단 소프트웨어 개발 영역 뿐만 아니라, 다른 영역에서도 프로세스를 도입하기 위해서 그리고 그러한 프로세스를 통해 업무를 수행하려는 습관이나 관행이 정착하기에는 상당한 시간이 걸리기도 하다.

1990년대에 폭발적으로 늘어난 소프트웨어 개발 프로젝트에 프로세스를 도입하려던 노력은 이제 걸음마 단계에 지나치지 않는다. 즉, 어떠한 개발 프로세스이든 아직까지도 효과적이거나 효율적이다라고 검증된 프로세스는 아직까지도 없다고 말해도 과언이 아니다. 타사나 타 프로젝트의 Best Practice들을 찾기보다는 그러한 결과를 얻기 위해서 노력한 과정을 참고해야 한다. 애자일 역시 이러한 과정을 겪는 노력을 통해서 정착화와 발전을 할 수 있을 것이다.

이제 본격적인 소프트웨어 개발에 대한 접근 방식에 대한 중요성을 논하기에는 아직 성숙되지 못한 문화에서 애자일이 빠른 정착을 보여주기 위해서는 국내의 특수한 환경을 수용할 수 있는 타협을 시도해야 한다. 린이나 칸반은 일본의 고유한 문화적인 특수성을 수용한 애자일의 또 다른 모습일 수 있으며, 역으로 이러한 것을 애자일의 본 고장에서 수용하여 더 나은 개발 접근 방식으로 만들어나가려는 모습을 한번 고찰해볼 필요가 있다.

국내에서 Agile Korea 2011 컨퍼런스가 최초로 개최된다고 한다. 아직은 시작이지만, 분명 국내에 애자일의 관심도를 높이는데 영향이 있을 것이다. 애자일이 좀 더 현실적인 영역으로 접근하려는 시도를 한다면 많은 관심을 통해 실용적인 소프트웨어를 만드는데 도움이 될 것이다. 그러한 방식을 만들고자 하는 시도와 노력 역시 또 다른 애자일 접근법으로 해결할 수 있지 않을까.