2001년 2월에, 경량 프로세스(lightweight process)라고 막연히 불리며 떠오르던 경향에 대해 토론하기 위해여 앤디 헌트를 포함해 관심을 가진 사람들 17명이 스노버드에 모였습니다. 논의 끝에 이들은 이런 경량 프로세스의 움직임을 정리해 그 유명한 ‘애자일 선언문’을 발표합니다. 그리고 그 후 10년이 지났습니다.
10년이면 강산도 변한다는데, 애자일이 우리 개발자들에게 칼퇴근의 신화를 현실의 이야기로 만들어 줬나요? 아니면 책을 팔거나 세미나에서 강사로 돈을 벌기 위해서 그냥 새로운 이슈 정도로 만들어 놓은 마케팅이었을까요? 오늘의 글은 애자일 10년을 기념하는 의미에서 지극히 개인적인 경험을 바탕으로 한, 애자일에 대한 초간단 10주년 보고서입니다.
애자일 프랙티스의 서문에서도 밝혔듯이, 제가 애자일을 처음 접한 것은 약 8년 전쯤입니다. 당시 저는 선배 사원과 새로운 프로젝트에 투입되기 직전이었죠.
“선배! 기존 개발방법론보다 결과도 더 낫고 결정적으로 칼퇴근이 가능한 방법론이 있다는데, 이번 프로젝트에 적용해 보는 게 어떨까요?”
사실 선배가 칼퇴근이라는 감언이설(?)에 넘어오지는 않았지만, 그 당시 우리는 칼퇴근 이상의 근본적인 변화를 원했습니다. 프로젝트 일정으로 채워진 달력이 몇 번이나 바뀌었지만, 프로젝트의 내용은 변화가 없었기 때문입니다. 즉, 우리가 참여했던 프로젝트는 주인공과 배경만 바뀌고 스토리는 비슷한 드라마와 같았습니다. 프로젝트 제안서는 항상 고객이 원하는 것 이상을 보여주었지만, MS 프로젝트에 적힌 일정은 현실과 이상의 괴리를 처절히 깨닫게 해주었고, 제안서에 속은 고객은 허기를 달래려고 프로젝트 팀원들을 잡아먹으려 했으며, 목숨이 위태로워진 팀원들은 제안서에 그려진 이상향을 땅 위에 실현시키고자 프로젝트룸에서 청춘을 보내야 했습니다.
그리고 우리 앞에는 또 다른 프로젝트가 놓여 있었습니다.
당시에 XP(Extreme Programming)를 적용하면서, 여러 가지 일을 겪었지만, 짝 프로그래밍을 하면서 부서의 부장님을 설득하는 게 무척 어려웠습니다. 즉, 짝 프로그래밍을 하는 모습을 보신 부장님이 ‘둘이 붙어 앉아서 노는 것’ 아니냐고 말씀하시면서, 개발이 제대로 될지 걱정하셨기 때문이죠. 아무튼 성과가 저희 대신 변명을 해주었기에, 부장님이 더 이상 짝 프로그래밍에 대해서 별 말씀하지 않으셨죠.
근본적인 변화를 꿈꾸면서 시작한 프로젝트는 절반의 성공을 거두었습니다(상당히 모호한 변명이지만… 정치적인 이유가 있었기 때문이죠). 절반의 성공이었지만, 저는 그 프로젝트를 통해 애자일의 묘미를 알게 되었습니다. 시간은 흘러, 애자일 실천방법을 적용한 프로젝트를 몇 번 더 했습니다. 10명이 조금 넘는 팀원들이 참여한 프로젝트에 애자일을 적용한 적도 있었고, 저 혼자서 북치고 장구치면서 애자일 프랙티스를 실천한 경우도 있었습니다.
요즘도 가끔 들어가는 개발자 커뮤니티 사이트에서, 흔히 말하는 SI성 프로젝트를 하는 개발자들이 일이 많거나 고객이 요구사항을 바꾸거나 동료 개발자나 관리자 사이의 관계 때문에, 프로젝트가 힘들다는 이야기를 많이 하시죠. 개발자들의 하소연 가운데 애자일 방법을 적용해서 해결할 수 없는 것도 많습니다. 하지만 애자일을 적용했을 때 해결할 수 있는 것도 있지만 현실이 그다지 개선되지 않는 것을 보면, 애자일 선언 이후 애자일이 우리의 현실을 개선하는 데 별로 기여하지 않았다는 생각이 듭니다. 이런 생각이 들자, 애자일 이거 정말 한때의 유행 아니었나 하는 의심도 듭니다.
나치의 선동가 괴벨스는 이런 말을 했죠. 거짓도 반복해서 들으면 진실이 된다고요. 저도 그런 경우가 있는데요. 실제로 경험해 보지 않았지만, 하도 많이 들어서 진짜로 그것을 경험한 것처럼 느낄 때가 있습니다. 즉 다른 사람의 시선으로 경험해 보지 못한 것을 인식하는 오류죠.
이런 오류는 어느 분야에나 있을 수 있습니다. 즉 새로운 개념이 소개되고 사람들이 열광하지만 실제로 그런 개념을 현실에 적용해서 결과를 내는 경우도 적죠. 기술이나 개념이 성숙하지 않아서 그럴 수도 있지만, 새로운 개념에만 매료되었을 뿐 현실에 그런 것들을 적용하고 자기 것으로 만드는 노력이 없을 때 그렇습니다. 새로움에 대한 열광이 식을 때, 사람들은 새로운 것도 실제로 적용해 보면 별 거 아니라는 생각을 하거나 다른 사람이 경험한 실패 사례에 초점을 맞춰서 예초부터 그런 개념은 현실에 맞지 않는다고 생각하기 시작합니다.
애자일이 탄생한지도 10년이 됐습니다. IT분야의 속도를 생각했을 때, 10년은 무척 긴 세월이죠. 애자일은 창조자들이 생각한 것만큼 더 나은 소프트웨어를 만드는 데 기여하고, 개발자들이 삶을 즐기도로 도와줬을까요? 아니면 한때의 말잔치였을까요? 그것도 아니면 무척 괜찮은 방법인데 사람들의 관심이 사라지고 애자일을 도입해서 실패를 경험하거나 경험하지 못한 분들의 폄하로 그 가치가 평가절하된 것일까요?
이런 물음에 답을 하려면 애자일이 생기게 된 근본 이유가 아직도 유효한지를 살펴봐야 합니다.
애자일을 현장에 적용하는 가장 큰 이유는 무엇일까요? 요구사항이라고 흔히 말하는 게 프로젝트 초반에 명확하지 않기 때문입니다. 즉 고약한 문제 합당한 해결에서 말하는 고약한 문제의 특성을 소프트웨어의 요구사항이 모두 담고 있기 때문입니다.
우리가 개발 현장에서 항상 하는 불만이 있습니다. 바로 고객이 요구사항을 바꿨다는 것이죠. 그런데 본질적으로 다른 의미를 이 문장으로 표현하는 경우가 있습니다.
우선은 최악의 케이스로 고객이 요구사항을 완전히 바꾼 경우입니다. 웹기반의 워드 프로세서를 만들고 있는데, 중간보고 자리에서 경영층이 웹 기반의 ERP를 만들라고 지시하는 경우죠. 이것은 정말로 고객이 요구사항을 손바닥 뒤집듯이 바꾼 경우로, 일정이나 예산 변경 없이 이런 요구사항을 반영하는 건 불가능하죠.
다른 경우는 상당히 현실적인 데요. 고객이 요구사항일 잘 모른 경우입니다. 다시 앞에서 예로 들은 웹 기반의 워드 프로세서를 만드는 걸 살펴보죠. 중간 보고 발표 때 마케팅 쪽에서 데모를 보고 나서, 멋진 마케팅 요소를 찾았는지, 기존에 없던 요구사항인 아래 한글 포맷으로 웹 문서를 변환하는 기능을 추가할 것을 요구합니다.
이런 요구사항 추가나 변경은 흔하죠. 그런데 개발자 입장에서는 왜 이런 요구사항을 개발 처음부터 이야기하지 않았는지 반문하면서, 마케팅 팀의 요구사항을 반영할지 말지를 두고 갑론을박을 버립니다.
앞에서 설명 드린 사례를, 우리는 모두 “고객이 요구사항을 바꿨어요.”란 말로 표현합니다. 하지만 둘은 요구사항의 변경 범위가 엄청나게 다르죠. 고객이 요구사항을 완전히 바꾼 것은, 프로젝트 팀에서 감담할 수 없는 겁니다. 하지만 고객이 요구사항을 잘 몰랐던 것은, 프로젝트 팀 내에서 감당할 수 있죠. 바로 애자일 방법을 사용해서 말입니다.
애자일 선언에 있는 것들에서 공통점을 발견할 수 있습니다. 개발의 과정에서 개발자들이 인간답게 살고 고객들과 좋은 관계를 통해서 비즈니스 기회를 창출하려는 인본적이고 자본주의 지향적인 노력도 있지만요. 제가 생각했을 때 가장 중요한 것은 변화를 포용려는 노력, 여러 가지 변화 중에서 요구사항이 변하는 것을 포용하려는 결과라고 생각합니다.
프로젝트 초반부터 고객이 모든 요구사항을 정하지 못하는 것을 프로젝트 팀에서 포용하기 위해서, 절차와 도구보다는 개인과 그들 사이의 상호작용에, 과도한 문서보다는 돌아가는 소프트웨어에, 계약보다는 고객과의 상호작용에, 계획을 추종하기보다 변화에 대응하는 것에 주안점을 두는 것이죠. 그렇다 보니 이런 현상들을 변화를 포용하여 기민하게 대처하는 것을 담아내려고,애자일(Agile)이라는 사상과 움직임이 탄생한 것이죠.
그런데 이런 사상을 실천하거나 고민하지 않으면, 애자일을 마치 변화무쌍한 고객의 요구사항에 대응할 수 있는 은총알이라고 생각하죠. 하지만 앞에서 말씀드렸듯이, 애자일이 포용할 수 있는 요구사항이 바뀌었다는 것은, 고객이 요구사항을 잘 몰랐던 경우입니다. 즉 고객이 요구사항을 제로 베이스에서 만들었다면, 원점부터 모든 것을 봐야 하죠.
아울러 애자일이라는 말 때문에, 애자일을 마치 아무렇게나 해도 되는 방법이나 설계 단위는 치워버리고 구현에만 급급한 해결책이라고 생각하는 경우도 있습니다. 이것도 넌센스죠. 애자일의 구체적인 실천방법을 본다면, 구현만 하는 게 아니라는 걸 알 수 있습니다.
애자일을 실천하려면 구성원들의 역량이 높아야 합니다. 역량이라는 것이 단순히 기술적인 것만을 뜻하는 게 아닙니다. 프로젝트 내에서 모든 것이 변할 수 있기 때문에 변화에 대해서 항상 열려 있어야 하고, 동료와 결과를 낼 수 있게 신뢰 기반으로 관계를 형성해야 하고, 새로운 것을 배우려는 자세가 되어야 하죠.
모든 소프트웨어 개발에서 설계가 중요하듯이 애자일에서도 설계를 반드시 해야 합니다. 하지만 그 수준이 고객의 요구사항을 구현하는 데 도움이 되는 수준이어야 합니다. 아키텍트가 아키텍처의 완결성을 위해 설계문서에 과도하게 집착하는 것은, 변화하는 요구사항에 대응하는 적절한 방법이 아닙니다. 설계문서의 완결성보다는 팀원들이 아키텍처를 이해하는 수준에서 멈추고 변화하는 요구사항을 관리하도록 역량을 쏟는 게 더 낫습니다.
길게 말씀드렸지만 애자일이 탄생한 근본원인이 요구사항이 모호하다는 것은 아직도 해결되지 않은 문제입니다. 그렇기에 애자일이 아직도 유효한 방법이라고 생각합니다. 다만 애자일의 어원 자체가 변화를 포용하는 기민함을 뜻하는 데서 출발했지만, “애자일 한다면서, 그렇다면 요구사항을 막 바꿔도 되는 거 아니야?” 처럼 애자일이라는 말이 주는 묘한 뉘앙스를 악용하는 사례나, 직접 경험해 보지 못하고 다른 사람의 경험으로 애자일을 판단하기 때문에 그 효용성에 대해서 좋게 판단하지 않는 것 같습니다.
물론 애자일을 성공적으로 적용해서 사용하시는 사례도 실패 사례만큼 많을 겁니다. 제가 경험한 개발현장이나 인터넷을 통해서 접하는 우리네 개발자 이야기를 들어보면, 애자일을 통해서 충분히 개선할 수 있을 것이라는 생각이 들 때가 많습니다. 그래서 애자일 10주년을 기념하면서 조금 긴 글을 써 봅니다. 오늘 글은 애자일 프랙티스를 번역하면서 쓴 서문의 마지막 문장을 인용하면서 마무리하겠습니다. 더 나은 내일을 위해서! 노력해야겠습니다.
우리네 프로젝트 인생이 행복해지기 위해서, ‘내가 바꿀 수 없는 것’도 결국 바꾸어야 합니다. 그러나 우리에게 두 가지 길이 있습니다. 즉, ‘내가 바꿀 수 있는 것’에 열정을 쏟으며 조금 더 나은 오늘을 만드는 것과 ‘내가 바꿀 수 없는 것’을 탓하며 ‘내가 바꿀 수 없는 것’이기에 누군가의 도움만을 바라며 똑같은 오늘을 보내는 것입니다.
어느 쪽을 선택할지는 개인의 문제입니다. 다만 여러분이 조금씩 개선되는 길을 선택하였다면 애자일에서 도움을 많이 받으실 겁니다!
