애자일이라는 단어가 특정한 업무 방식을 정의하기 위해 탄생한 단어인 줄 알고 있었다. 하지만 애자일은 원래 존재하던 단어였고, 특정한 업무 방식을 잘 설명하는 단어이기 때문에 차용되었을 뿐이었다. 이 책을 읽어보면서 애자일의 사전적 의미를 찾아봤는데, 이 의미를 이해하고 있다면 애자일 방법론을 더 정확하고 깊이 이해할 수 있을 것이다.
[애자일 방법론은 '서비스를 유연하고 빠르게 변화시키는 업무 방법론']
나름대로 애자일의 정의를 내려봤다. 소프트웨어 장인 :: 1장 21세기의 소프트웨어 개발에서 '기업들은 변화에 유연해야 했고 시장 상황에 맞춰 기민하게 조직을 바꾸기 시작했다.'라고 했었는데, 이러한 변화에 맞춰서 업무 방식도 '유연하고 빠른 서비스의 변화'에 초점이 맞춰진 것 같다. 그래서 실무자들은 서비스를 유연하고 빠르게 변화시킬 수 있는 업무 방식을 익혀야 했다. 이러한 업무 방식을 애자일 형태의 업무 방식이라고 한다. 이 방식을 자세하게 설명한 것이 애자일 방법론이다.
[애자일은 실천하는 것이 중요]
마치 게임 캐릭터가 좋은 무기를 장착해서 공격력이 상승하는 것처럼, 애자일을 적용하는 것만으로도 쉽게 업무 능력이 상승하면 좋을 텐데 아쉽게도 그렇진 않다. '영어를 잘 하려면 많이 말하고 많이 들어야 한다'라는 것은 누구나 다 안다. 하지만 실천이 어렵다. 애자일도 마찬가지다. 애자일에 대해 깊게 이해하는 것도 좋지만 조금씩이라도 애자일을 실천하는 것이 중요하다. 영어를 잘 하기 위해서는 '말하고 듣는 방법을 많이 아는 것'보다 '많이 말하고 많이 듣는 것'이 더 중요할 것이다. (내가 쓴 이 문장에 내가 찔리는 기분이다.)
[애자일은 문제 자체를 해결해주지는 않는다. 다만 애자일은 문제를 드러나게 한다.]
아쉽게도 애자일을 잘 실천하는 것만으론 서비스가 민첩하게 변화하지 않는다. 애자일은 서비스를 민첩하게 변화시키는 것을 결정적으로 도와줄 뿐 직접 변화시키지는 않는다. 변화시키는 것은 우리의 몫이다. 애자일을 잘 실천하면 현재 서비스의 문제점들이 드러나게 되는데 이 드러난 문제점들을 해결하는 것까지 마쳐야 비로소 서비스가 민첩하게 변화할 수 있다.
[테스트 코드의 중요성]
이 특징은 개발자 한정으로 적용될 것 같은데, 애자일을 실천하기 위해서는 테스트 코드가 더욱 중요한 것 같다. 테스트 코드는 어떤 업무 방식에서도 중요하다. 그런데 애자일 방법론에서는 특히 더 중요하다. 이는 애자일의 '빠른 피드백과 빠른 검증'이라는 특징 때문인데, 서비스가 실행되고 있는 코드를 대상으로도 빠른 수정이 필요하기 때문이다. 코드를 빠르게 수정하는 방식은 아무래도 상대적으로 안전성이 낮을 확률이 높을 것이다. 애자일이 안전성이 낮은 방식이라는 의미가 아니다. 코드를 여유롭게 수정하는 방식보다는 상대적으로 안정성이 낮다는 의미이다. 이 낮은 안정성을 보완해 줄 수 있는 것이 테스트 코드이기 때문에 애자일에서는 특히 테스트 코드가 중요한 것 같다.
[애자일을 실천하기 위해서는 구성원들이 뛰어나야 한다]
위에 적어둔 애자일의 특징들을 잘 실천하고 발현시키기 위해서는 고성능(?)의 실무자들이 필요하다. 이 세상에는 애자일을 포함해서 많은 업무 방법론이 존재할 것이다. 그리고 이 업무 방법론들이 효과적으로 작동할 수 있는 환경도 제각기 다를 것이다. 이 책에서도 비슷하게 설명하고 있는데, 애자일을 잘 실천하면 경쟁에서 우위를 점할 수 있겠지만 매우 섬세하고 까다로운 방법론이기 때문에 실천하기가 힘들다. 과실이 크지만 따먹기가 어렵다. 그래서 실무자들의 능력이 탁월하지 않다면 오히려 애자일을 실천하지 않는 것이 더 좋을 수 있다고 생각한다. 실무자들의 능력이 탁월하지 않은 상황에서는 오히려 강력한 탑다운 방식의 업무 방식이 더 효과를 발휘할 수 있는 것 같다. 축구에 비교해 보자면, 선수들의 능력이 평균적으로 뛰어나면 이 능력들이 더 잘 발휘될 수 있도록 자율성을 부여하는 것이 좋겠지만 그렇지 않다면 강력한 조직력으로 선수들의 플레이를 통제하는 것이 승률을 높일 수 있을 것이다. 아무튼 애자일이 만능은 아니라는 말을 하고 싶었다.
[작가에게 하고싶은 질문 두 가지]
45 페이지를 보면, '처음부터 애자일로 시작한 프로젝트임에도 기술적 부채가 쌓인 경우도 있다.'라고 적힌 문장이 있다. 이 부분에서 '애자일은 기술적 부채를 쌓지 않는 방법론인가?'라는 궁금증이 생겼다. 애자일을 잘 실천하는 조직이라도 시간이 부족하거나 순간적으로 인력이 부족하는 등 예상치 못할 다양한 원인으로 인해 기술적인 부채를 만들게 될 수 있지 않을까? 어느 방법론이라도 기술적인 부채를 만들려고 하진 않을 텐데? 혹시 작가는 '애자일은 기술적 부채를 쌓지 않을 확률이 낮다'라는 말을 하고 싶었던 것이 아닌가 싶다.
또한 이 챕터에서는 애자일을 실천하기 위해 기술적인 뛰어남을 계속 강조한다. 그런데 시간은 한정되어 있고 기술적인 부분에만 계속 시간을 투자할 순 없을 텐데 그러면 비즈니스는 조금 후순위로 둘 수도 있음을 전제하고 있는 걸까? 궁금하다!
[생활에서 실천할 수 있는 애자일]
이렇게 애자일에 대해 깊게 고민해 보니 애자일을 실천하기 위해 생활 속에서 애자일을 실천해 보고 싶어졌다. 우선 개발 공부를 애자일스럽게 해봐야겠다. 내가 공부하고 있는 방향과 내용이 맞는지 타인의 시각으로 피드백을 받아보자. 그리고 고칠 건 고치고 유지할 건 유지해 보자. 개발적인 부분 말고도 생활하는 데에 많이 활용해 볼 수 있을 것 같기도 하다.
