The Nature of Software Development라는 책은 애자일 소프트웨어 개발 선언에 참여하고 익스트림 프로그래밍 방법론 창시에 기여한 론 제프리스가 집필한 책이다. 특이하게도 제목이 번역되지 않은 상태로 출판되었는데 그냥 소프트웨어 개발의 본질이라고 번역하는게 더 좋았을 것 같다.

애자일에 대한 책은 많지만 이 책은 특히나 얇고 핵심적인 내용만 담겨있어서 애자일 방법론이 무엇인지 빠르게 파악하기 위한 입문용으로 좋은 책이라고 생각한다. 하지만 얇은 만큼 구체적인 사용 사례가 부족하기 때문에 애자일 방법론을 팀에 적용하기 위해 공부하는 관리자라면 이 한 권만 읽는 것으론 부족할 수 있다.

책에서 말하는 본질은 무엇인가?

이 책의 이름인 'The Nature of Software Development(소프트웨어 개발의 본질)’은 지금까지 수많은 개발자가 고민해왔고 앞으로도 끊임없이 고민과 의견이 필요한 개발자의 영원한 숙제라고 볼 수 있다. 누군가는 본질이란 정답이 없는 존재하지 않는 것이라고 말하기도 하지만 이 책에서는 본질은 분명히 존재한다고 주장하며 소프트웨어 개발과 관련된 이해관계자 모두에게 큰 도움이 된다고 한다.

그러면 이 책에서 말하는 본질은 무엇일까? 책의 가장 앞부분인 '들어가기 앞서' 챕터를 보면 소프트웨어는 용암입니다라는 말로 시작한다. 이 말은 비유적인 표현으로 저자는 소프트웨어 개발은 매우 험난하고 좋은 길만 있을 수 없다는 것을 말하고 있다. 갑작스레 용암을 만나는 일은 꽤 자주 발생하기 때문에 우리가 원하는 것을 정확히 알고 해야 할 일을 작게 나누어 간결하게 만들어야 한다고 주장한다. 이를 통해 빠르고 유연하게 문제에 대응하며 자주 배포하는 것이 소프트웨어 개발의 본질이라고 한다.

이 책을 읽고 나서 느낀 본질을 요약하면 애자일 방법론을 통한 리스크 관리라고 할 수 있다. 팀의 목적을 확실히 알고 변경에 쉽게 대응하기 위해 문제를 작게 나누며 잘못된 선택을 빨리 바로잡기 위해 자주 배포를 한다. 즉, 되돌아가는 일을 최대한 적게 만드는 것이라 할 수 있다. 물론 이렇게 업무를 진행하는 것은 상당히 어렵다. 만약 쉬웠다면 이 세상에는 소프트웨어 개발을 방해하는 용암으로 가득 차 있다는 표현은 나오지 않았을 것이다.

그럼 책에서 말하는 용암은 무엇을 말하는 걸까?

소프트웨어 개발을 방해하는 요소

보통 어떠한 방법론을 사용하더라도 소프트웨어 개발을 시작하는 초기 구상 단계는 대체로 완벽해 보인다. 이는 유명한 애자일 방법론을 도입하더라도 마찬가지인데 스프린트를 시작하는 월요일엔 완벽했던 계획이 금요일에는 엉망이 된 케이스는 수도 없이 많다.

계획이 엉망이 돼버리는 이유는 대체로 소프트웨어 개발을 힘들게 하는 다양한 요소들이 존재하기 때문이다. 책에선 용암이라 표현한 이러한 요소들은 수도 없이 많아서 길 가던 개발자를 붙잡고 인터뷰하면 겹치지 않는 수많은 사례가 나올 것이라 확신할 수 있다.

그중에서도 몇 가지를 뽑아보면 '기획 변경', '의견 충돌', '우선순위 변경' 세 가지가 가장 공감받기 쉬운 요소라고 볼 수 있다. 이 사례들은 상당히 자주 볼 수 있으면서 갑작스럽게 나타난다는 공통점이 있다.

필자는 평소 일하는 사람을 함수와 비슷하다고 느끼는데 이는 같은 상황, 시간, 조건 하에 인풋이 들어오면 같은 아웃풋이 나온다고 생각하기 때문이다. 그런데 마치 프로그래밍에서 참조무결성이 깨지듯 사람이라는 함수에 사이드 이펙트가 발생한다면 아웃풋을 예측하기 힘들어진다. 이는 너무나도 당연하다.

그렇지만 사실 위에서 말한 요소들은 우리를 괴롭히기 위해 나타난 것이 아니다. 결과는 알 수 없지만, 팀의 목표를 이루거나 성과를 더 내기 위해 나오는 것들이라 볼 수 있다. 우리는 그 사실을 알고있기 때문에 투덜대면서도 훌륭하게 일을 마치려고 노력한다.

앞서 말한 것 처럼 결국 이런 방해 요소에 대한 리스크를 줄이기 위해 애자일 방법론이 탄생했고 많은 팀이 도입하고 있다. 이 이론적인 내용만 본다면 더할 나위 없이 훌륭한데 많은 팀이 애자일 도입에 실패하는 이유가 무엇일까?

팀 성장의 본질

저자는 팀이 잘 일할 수 있게 해주는 것이 애자일이라 말하지만 반대로 애자일을 잘하기 위해서는 팀의 역량이 무엇보다도 중요하다는 사실을 알고 있다. 그렇기 때문에 책 전반적으로 팀 성장에 대한 내용이 많이 나온다.

애자일 방법론에 대한 가장 많은 착각은 애자일을 도입했을 때 일이 더 편해지고 여유로워진다고 생각하는 점이다. 애자일은 확실한 목표를 가지고 짧은 주기로 배포하는 방법론이다. 이를 위해서는 해야 할 일을 작은 단위로 정리할 필요가 있고 정확한 일정 관리를 위해 자기 자신과 다른 팀원의 퍼포먼스를 정확하게 측정할 수 있어야 한다. 결국 이는 심적으로 굉장한 부담이 되며 자칫 잘못하여 배포 주기가 깨지게 되면 큰 죄책감이 들기도 한다.

따라서 애자일 방법론을 잘하기 위해서는 뛰어난 개인이 아닌 훌륭하게 성장하는 팀이 되어야 한다. 팀이 성장하기 위해 가장 중요한 것은 팀 구성원 모두가 팀의 역량을 최대한 정확하게 아는 것일 것이다. 이것을 제대로 알지 못하거나 제각기 다르게 파악하는 경우 성장은 이루어질 수 없고 애자일 방법론은 내부의 불만에 의해 무너질 수밖에 없다.

그래서 결국 팀원 각각의 역량을 정확하게 알고 업무에 대한 평가가 올바르게 이루어지며 팀 역량에 따른 달성 가능한 목표를 배포 주기마다 만드는 것이 소프트웨어 개발과 팀 성장의 본질에 가장 가까운 상태라 볼 수 있다.

우리는 애자일을 어떻게 도입해야 할까

이러한 사실을 많은 사람이 알고 있고 그다지 어렵지 않은 개념임에도 불구하고 애자일 방법론이 실패하는 것은 다양한 이해관계와 상황이 존재하기 때문이다. 저자도 이것을 인정하고 쉽지 않은 일이라고 표현하면서 해결을 위한 어제의 날씨, 파이브 카드, 테스트 코드, 야영지 규칙 등의 다양한 방법을 제시한다.

이 책에서 소개된 방법 외에도 개발의 문제가 아닌 팀이나 상황 문제 해결에 대한 방법은 무수히 많을 것이다. 소프트웨어 개발은 아직 역사가 길지는 않지만 많은 문제와 해결에 대한 패턴이 나왔고 우리 팀이 가진 문제에 적합한 해결 방법이 있을 확률은 매우 높다.

따라서 중요한 것은 문제가 있다면 개선을 위한 방법을 찾고 팀이 완전히 자리 잡을 때까지 다양한 실험을 해야 한다는 점이다. 처음부터 완벽하게 잘하는 팀은 존재하지 않는다.

마지막으로 한 가지 명심해야 할 것은 방법론과 방법은 다르다는 것이다. 방법론(方法論)은 목적을 이루기 위한 여러 방법을 비교하고 대조하는 이론을 뜻한다. 반면, 방법(方法)은 목적을 이루기 위한 방식을 말한다. 그렇기 때문에 필자는 100개의 팀이 있다면 100개의 애자일이 있다고 생각한다. 팀에 맞는 방법을 끊임없이 찾으며 발전하고 목표와 평가를 하는 것이 애자일에 대한 올바른 자세라고 생각한다.