<p>그동안 애자일에 대해 쓰고 싶은 글이 하나 있었다. <strong>애자일의 함정</strong> 같은 중2병 돋는 제목을 붙이고, 애자일의 진짜 단점들과 반론들을 써보려고 했다. 근데 요즘 여기저기 다양한 회사와 사람들을 만나면서 아직 한국은 애자일의 단점 같은 거 논할 때가 아니라는 생각이 들었다. 심지어 애자일 사례 발표라고 하는 것도 내용을 보면 애자일과 무관하거나, 심지어 애자일에 반하는 내용이 많았다. xper 메일링에도 애자일에 대한 오해로 가득하고, 애자일을 제대로 이해하고 있다고 할 만한 사람은 극소수다. 게다가 그런 오해들은 점점 확산되고 있다. </p>
<p>그래서 한 번쯤 애자일이 뭔지에 대해 짚어볼 필요가 있다는 생각이 들었다. 니가 뭔데 애자일이 뭔지 니 맘대로 정의하냐고? 물론, 내 맘대로 정의할 생각은 없다. 오히려 그 반대로 아무도 제발 애자일을 맘대로 정의하지 말았으면 좋겠다. 내가 말하고 싶은 것은 애자일이라는 단어를 용어로 정착시킨 사람들의 정의를 그대로 사용하자는 것이다.</p>
<h2 style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; color: #333333;">애자일 선언</h2>
<p>2001년 2월에 XP, 스크럼 등을 대표하는 선지자들이 모여서 공통점을 모아 애자일 선언이라는 걸 발표했다. 이것이 애자일이 용어로써 자리잡게 된 시초다. <a href="http://agilemanifesto.org/">http://agilemanifesto.org/</a>를 통해서 전문을 볼 수 있고, 선언에 참여한 저자들, 선언의 배경 등에 대한 설명도 있다. 다행히 <a href="http://agilemanifesto.org/iso/ko/">한국어 번역</a>도 있다. 번역하기 어려운 내용임에도 꽤 잘된 번역이라고 생각하지만, 약간의 거리감이 있는 것 같아서 여기서는 영문을 차용해서 이야기하려고 한다. 애자일 선언은 네 문장의 가치 선언과, 이를 부연하는 12개의 원칙으로 구성되어 있다.</p>
<blockquote>
<p><span style="font-size: medium;">Individuals and interactions </span><span style="font-size: small;">over processes and tools<br></span><span style="font-size: medium;">Working software </span><span style="font-size: small;">over comprehensive documentation<br></span><span style="font-size: medium;">Customer collaboration </span><span style="font-size: small;">over contract negotiation<br></span><span style="font-size: medium;">Responding to change </span><span style="font-size: small;">over following a plan</span></p>
</blockquote>
<p>over 오른쪽에 서술된 것도 중요하게 생각하지만 굵은 글씨로 왼쪽에 서술된 것에 더 가치를 두자는 것이 애자일 선언이다. 그럼 일단 이것부터 하나하나 뜯어보자.</p>
<h3 style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; color: #333333;">Individuals and interactions over processes and tools</h3>
<p>개인과 상호작용을 프로세스와 도구보다 중시한다는 것이다. 추상적인 말 같지만 의외로 실제 사례로 이야기하기 쉽다. 우선 individuals, 개인이 뜻하는 바는 무엇일까? 흔히 한국사람들이 하는 이야기로 <em>사람이 중요하다</em>라는 표현이 있는데 그런 의미일까? 그럼 아마 people이라고 썼을 것이다. 굳이 individual이라는 단어를 쓰고, 프로세스나 도구에 대비시킨 것은 개인의 판단과 의사결정을 말하고 싶은 것이다. 관료주의 조직은 흔히 판단을 프로세스에 맡기려는 경향을 보인다. 실무자에게 결정권이 없고 의사결정은 위로위로 프로세스에 태운다. 사실 그렇게 프로세스에 태워도 누군가는 사람이 결정을 할 수 밖에 없는데도 뭔가 프로세스에 따라 결정을 내리면 더 안전하다고 생각한다. 그래서 개인의 판단보다 프로세스를 통한 결정이 중시된다. 애자일은 이것을 극복하고 개인에게 더 많은 것을 위임하기를 권하는 것이다.</p>
<p>구체적인 예를 들어보자.</p>
<blockquote>
<p>테스트 커버리지가 60%를 넘겨야 한다는 규칙을 가진 조직이 있다고 가정해보자. 그런데 어느날 개발자 A는 개발을 하다가 유닛 테스트를 만들 필요가 전혀 없는 기능을 개발하게 되었다. 그런데 마침 소스 코드의 커버리지는 60%를 아주 약간 상회하는 수준이었고, 개발자 A가 해당 기능을 테스트 없이 추가하게 되면 바로 테스트 커버리지는 59%가 된다. 이런 상황에서 개발자 A가 <strong>자신의 개인 판단으로 테스트를 만들지 않기로 결정할 수 있다</strong>면 <em>프로세스를 지키기 위해 무조건 테스트를 추가</em>하는 것보다 더 애자일한 것이다. 여기서 규칙을 어겼다고 비난하지 않고 오히려 더 나아가 60%라는 규칙에 의심을 품을 기회로 삼고 거기에 대한 토론까지 진행한다면 아주 훌륭한 애자일 팀이다.</p>
</blockquote>
<p>예를 하나 더 보자.</p>
<blockquote>
<p>서버에 장애가 나서 서비스가 중단되었다. 개발자 B는 마침 이 문제가 코드 한 줄만 수정하면 되는 간단한 일임을 발견했다. 너무 명백한 문제라서 모든 팀원이 그 해법에 동의한다. 그래서 <strong>로컬에서 간단히 코드 수정해서 확인해본 후 바로 실 서버에 적용한다</strong>면 이 팀은 꽤 애자일한 팀이다. 그런데 <em>곧이 곧대로 코드를 테스트 서버에도 올려서 QA에게 확인을 받고 15분이 걸리는 전체 회귀 테스트를 다 돌린 다음 실 서버에 배포한다</em>면 이 팀은 그리 애자일한 팀이 아니다.</p>
</blockquote>
<p>그러니까, 현장에서 문제를 가장 잘 이해하고 있는 개인의 판단이 정해진 프로세스를 넘어서거나 우회할 수 있다면 좀더 애자일한 것이다. 반대로 상황과 무관하게 늘 프로세스를 곧이 곧대로 지켜야 한다면 애자일하지 않은 것이다.</p>
<p>이것은 생각보다 중대한 함의를 담고 있다. 개인이 프로세스보다 중요한데, 프로세스는 누가 만드는 것인가? 프로세스는 팀이 만든다. 팀장이 정하든, 민주적으로 정하든 어쨋든 프로세스는 팀의 규칙이다. 그런데, 그런 팀의 규칙보다 개인을 우선한다는 것이다. 충격적인 이야기 아닌가? 이를테면 아주 민주적인 팀의 경우 팀의 프로세스도 민주적으로 정했을 수 있다. 그런데, 그런 민주적인 절차를 거친 프로세스조차도 개인보다 우선하지 않는다는 것이다.</p>
<p>방법론이나 일 잘하는 방법 등을 이야기할 때 팀이 빠지는 경우는 드물다. 팀웍이 강조되고 개인보다 팀을 우선하는 모습이 존중 받는다. 하지만 <a href="http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap">ExtremeProgrammingRoadmap</a>에도 팀웍을 강조하는 표현은 전혀 찾아볼 수 없다. <a href="http://agilemanifesto.org/">애자일 선언</a>에도 마찬가지다. 켄트 벡의 <a href="http://www.amazon.com/Extreme-Programming-Explained-Embrace-Edition/dp/0321278658">Extreme Programming Explained</a>에도 찾아보기 힘들다. 사실은 애자일 리더들은 팀보다 개인을 중시했던 것 아닐까? 애자일 선언을 보면서 이 정도 의심은 해봐야 한다.</p>
<p> </p>
<p>그럼, interaction, 상호작용이 의미하는 것은 뭘까? 이것은 비교적 쉽다. 그리고 아주 흔하게 보이는 사례가 있다.</p>
<blockquote>
<p>마케팅팀과 영업팀으로부터 늘 요구사항에 시달리는 개발팀이 있다. 그들은 불쑥 찾아와서 개발자의 집중을 방해하고는 요구사항을 마구 늘어놓고 돌아간다. 메일로도 요구사항들이 쏟아진다. 개발자는 일하기가 힘들어서 대책을 강구한다. 누군가 이슈 트래커라는 걸 쓰면 된다고 알려준다. 짜잔, JIRA를 도입했다. 이제부터 개발팀에 요청하실 일은 무조건 JIRA에 올려주세요. JIRA에 안 올리면 일은 하지 않을 것이고, JIRA에 올린 티켓이 적절한 우선순위를 배당 받으면 그 때 작업을 시작할 겁니다. 이제 개발팀에 직접 찾아오는 사람을 돌려보낼 겁니다.</p>
<p>개발자들은 이제 방해 받지 않게 되었고, 그저 우선순위대로 정렬된 티켓을 하나씩 가져와서 하기만 하면 되었다. 마케팅팀도 영업팀도 이제 자신들의 요구사항을 개발자가 까먹어서 안해주는 일은 사라졌다. 이제 모두가 행복해졌다.</p>
</blockquote>
<p>이런 패턴은 정말 지겹도록 봐왔는데, 놀라운 것은 이것을 애자일한 방법으로 생각한다는 것이다. 하지만 이것은 명백히 interaction, 상호작용보다 프로세스와 도구를 중시하는 태도로, 애자일에서 지양해야 할 방법이다. 이런 팀은 실제로 애자일 팀에 비해 매우 느린 속도로 일하지만 정작 팀 내부에서는 티켓의 처리 개수 따위로 생산성 측정을 하게 되기 때문에 자신들이 느리다는 인식조차 없다.</p>
<p>이건 문제의 원인을 잘못 파악했기 때문이다. 개발팀이 괴로운 건 다른 팀에서 찾아오기 때문이 아니라, 집중을 방해받기 때문이다. 그러니까 집중을 방해하지 않는 문화를 만들어 가야 할 일이지, 찾아오지 않게 할 것이 아니다. interaction이 process보다 중요하다는 것은 이슈 트래커를 통하는 것보다 interaction을 통해서 즉각적인 의사결정을 내리는 것이 생산적이라는 것이다. 물론 이 interaction이 꼭 face to face를 말하는 것은 아니다. 중요한 것은 이슈 트래커 같은 시스템을 통해서 중요한 의사 결정이 내려지게 하기보다, 담당자간의 상호작용을 통해서 기민하게 대응하라는 것이다. 예를 들어 마케팅 이벤트를 하기로 했는데 중간에 이벤트 내용이 크게 변경되었다고 할 때, 스프린트 중에는 티켓을 크게 변경하면 스토리 포인트가 안 맞아서 다른 일이 밀리니까 다음 스프린트로 넘기자는 판단을 한다면 process를 더 중시하는 것이다. 이럴 때 담당자끼리 즉석에서 합의 보고 해결책을 찾아간다면 interaction을 더 중시하는 것이다.</p>
<p>individuals와 interaction을 분리해서 이야기하긴 했으나, 사실은 이 내용은 두 가지가 아니라 하나로 요약될 수 있다. 팀이 어떤 프로세스를 정했고, 어떤 툴을 쓰기로 했든, 현장에서 일하는 개인의 판단이 더 중요하다는 것이다.</p>
<p>첫번째부터 매우 논쟁적일 수 있는 내용이 되어버렸는데, 어쨋든 무조건 팀이 중요하다는 식의 발상에 조금은 의심해볼 때가 되지 않았을까. </p>
<p> </p>
<h3>Working software over comprehensive documentation</h3>
<p>풍부한 문서보다 작동하는 소프트웨어가 중요하다는 것이다. 국내에서 아주 흔하게 보는 개발 방식 중 하나가 UI 문서를 먼저 만들고 이를 바탕으로 GUI 문서를 만든 후 개발에 들어가는 것이다. 개발자는 UI 문서를 보면서 기능을 이해하고 GUI 문서에 맞춰서 화면을 만든다. GUI 문서를 따로 만들지 않고 UI 문서만 만드는 경우도 있지만 대동소이. UX가 뭔지도 모르면서 UI/UX라는 이름을 붙이는 것도 같은 범주다.</p>
<p>이 방식으로 개발하게 되면 개발이 잘 되었느냐 아니냐를 UI 문서대로 만들었느냐 아니냐로 평가하게 된다. 개발하는 기능 하나하나가
WikiNamu
영록이 홈페이지
Youngrok Pak