한빛미디어

전에 일하던 스타트업에서 애자일-스크럼을 도입한 적이 있다. 3–4명의 소규모일때는 각자의 방식대로 일하다가 팀원이 10명 가까이 늘어나면서 하나의 제품을 통일성 있게 개발하고 관리하기 위함이었다.

애자일-스크럼의 장점은 진입장벽이 낮다는 점이다. 애자일 선언문을 한 번 읽어보고, 스크럼의 방법 및 원칙 몇가지를 숙지하면 당장이라도 시작할 수 있다. 이와 관련된 책만 해도 수십권이 넘어가지만, 대충 둘러봐도 다들 비슷한 내용인 듯 싶다. 당시 우리팀도 약간의 문서를 읽고 몇 번의 회의를 통해 배포 주기, 일정 관리 도구 등의 세부 사항을 확정한 뒤 바로 실행에 돌입했다.

애자일-스크럼의 단점은 탈출장벽(?) 또한 낮다는 점이다. 워낙에 간결한 방법론이다보니 현실 세계에서 벌어지는 수 많은 난관을 어떻게 헤쳐 나가야 하는지 알려주지 않는다. 점점 발언권이 센 누군가의 의견이 강하게 반영되면서 어느샌가 ‘이건 애자일이 아니야…’라는 생각이 모두의 마음 속에 자리잡게 된다.

현실의 난관에는 많은 것들이 있지만 대체로 아래와 같이 공통적인 범주 안에 있을 것이다.

왜 이렇게 개발이 느려요?

이 기능은 한 번의 스프린트(개발 주기) 안에는 못끝내요.

(스프린트 도중) 비즈니스에 갑자기 필요해졌으니 이 기능 먼저 당장 만들어야해요.

지금 코드 상태가 너무 엉망이에요. 이번 스프린트에는 리팩토링에 집중할게요.

당시에는 이런 문제들에 대해서 어떻게 대처해야 하는지 잘 몰랐고, 그렇게 애자일에서 멀어지면서 ‘원래 애자일이 쉬운게 아니야.’ 란 생각만 굳게 되었다.

그 때 이 책과 함께였으면 어땠을까라는 생각이 든다. 새롭게 애자일한 개발방식을 적용하려고 하는 모든 사람들이 다 같이 이 책을 읽고 어려운 일이 있을 때마다 같은 방향으로 해결책을 모색했다면 더 나은 개발문화가 정착되지 않았을까 하는 생각이 들었다.

이 책은 크게 1부와 2부로 나뉘어져서 1부는 애자일의 기본 원칙을 설명하고 2부에서는 좀 더 각론으로 들어가 위에서처럼 마주칠 수 있는 어려움들을 어떻게 해결할 수 있을지 부연해준다.

1부는 여차 애자일 서적, 자료들과 크게 다를 바 없는 내용이다. 다만 책의 저자가 애자일 선언문 작성자 중 한명이며 애자일 철학을 구체화시킨 Extreme Programming의 창시자라는 점을 상기한다면 더욱 신뢰감있게 다가오는 것이 사실이다.

하지만 이 책의 백미는 2부에 있다. 경영진, 제품 책임자, 개발자 모두에게 생길 수 있는 의문들에 대해 대답해준다. 적어도 모든 팀원들이 이 책을 읽었다면, 최소한 같은 방향을 바라보며 해결책을 구상할 수 있을 것이다. 그리고 위의 문제들에 대해서 이렇게 대처하지 않았을까.

왜 이렇게 개발이 느려요?

=> 처음엔 느려보여도 나중에 테스트, 버그 수정할 시간을 지금 쓴거에요. 일단 당장 배포 가능한 제품이잖아요.

이 기능은 한 번의 스프린트(개발 주기) 안에는 못끝내요.

=> 그럼 한 번에 끝낼 수 있는 분량으로 쪼개보고 그 중 가장 중요한 것 부터 만들자.

(스프린트 도중) 비즈니스에 갑자기 필요해졌으니 이 기능 먼저 당장 만들어야 해요.

=> 지금 만드는게 현재 가장 중요한 기능이에요. 그것보다 중요한게 확실한지 다시 한번 판단해 볼 필요가 있어요.

지금 코드 상태가 너무 엉망이에요. 이번 스프린트에는 리팩토링에 집중할게요.

=> 가장 중요한 기능의 아주 작은 부분이라도 동작하도록 추가하고 해당 부분에서만 리팩토링하면서 개선해야해요.

이 책에 애자일을 성공으로 이끄는 모든 것이 들어있지는 않다. 그래도 최소한 성공적인 애자일을 위해서는 테스트 주도 개발 능력이 필수적이고 제품 개발을 위해 필요한 핵심 기술이 모두 한 팀에 있어야 하며, 무엇보다 제품 개발의 가치를 모든 팀원들이 공유하고 있어야 한다는 점은 확실하게 알게 되었다.