🌈 Chapter 3: 애자일

좁은 정의의 애자일은 정확히 말해, '애자일 소프트웨어 개발 방법론'으로 소프트웨어를 개발하는 한 가지 스타일을 일컫는다. 대략 1990년대에 그 모습을 드러내기 시작했고 그 당시에 쓰던 전통적인 소프트웨어 개발 방식이 1990년대의 비즈니스적 상황, 고객의 요구 등과 잘 맞지 않는다고 생각한 사람들이 있었다. 그들은 각자 자기들만의 개발 방식을 만들어서 실천하고 있었다.

그래서 이 방법들의 창안자 스무 명 정도가 2001년에 스노우버드 스키장에서 만나서 선언문을 작성한다. 이를 애자일 선언문이라고 한다. 공식적으로는 유일하게 애자일을 정의한 문서이다.

당시 주도적인 소프트웨어 개발 방식은 계획주도의 방식이었다. 계획주도 방식에서는 초반에 계획을 정교하고 꼼꼼하게 만들려고 엄청난 노력을 한다. 그러면 실행단계에서 간단해지고 예측 가능해진다고 생각을 하기 때문이다. 하지만 애자일은, 불확실성이 높은 일에 대해서는 애초에 이것이 불가능하다고 본다. 불확실성이 크기 때문에 미리 분석하고 설계하는 데 한계가 있다는 것이다. 애자일은 불확실성이 높은 프로젝트에 더 적합하다. 애자일이 불확실성을 다루는 방식은 좀 더 짧은 주기로 더 일찍부터 피드백을 받고, 더 다양한 사람으로부터 더 자주 그리고 더 일찍 피드백을 받는 것으로 정리할 수 있다.

여기까지가 협소한 의미의 애자일이었다면 이번에는 광의의 애자일을 얘기해본다. 애자일을 단순히 소프트웨어 개발 방법론이라는 울타리에 가두어 보지 않고, 일하는 한 가지 스타일, 혹은 더 넘어서서 삶을 사는 방식으로까지 확장해 보는 것이다.

학습과 협력을 증진해서 우리 삶에 애자일을 적용하고, 또 이를 통해 불확실성과 친구가 될 수 있다. 학습이 불확실하다는 것은 우리가 이동할 때 목표점의 위치가 자주 바뀌거나 우리 위치가 자주 바뀌거나 하는 상황으로 비유해 볼 수 있다. 그럴 경우일수록 가다가 멈춰 서서 주위를 둘러보고 목표점과 우리 위치를 확인하는 것 같은 피드백을 통해 방향을 재조정하는 일을 자주 해야 한다. 다시 말해 이동하면서 계속 배워나가야 한다는 뜻이다.

협력의 경우는 두 가지로 나누어 생각해 본다. 안 좋은 일이 생기는 경우, 그리고 좋은 일이 생기는 경우이다. 불확실한 상황일수록 리스크가 높을 것이고, 고로 안 좋은 일이 벌어질 확률이 높을 것이다. 애자일은 서로의 업무를 공유하고 상호 검토하는 협력을 통해 불행한 일을 '또는' 조건에서 '그리고' 조건으로 바꾸게 한다. 반대로 불확실한 상황에서는 예상치 못한 좋은 일이 생길 확률도 있다. 그런 경우 이 좋은 일을 확장해야 하는데 모든 사람이 통찰을 얻어야 업무를 개선할 수 있는 게 아니라 한 사람이라도 통찰을 얻으면 그걸 공유해서 전체가 개선된다.

애자일의 핵심 구동원리가 학습과 협력, 즉 함께(협력) 자라기(학습)이다.

📚 애자일의 씨앗

애자일의 핵심, 애자일의 씨앗이라고 할 수 있는 게 무엇일까? 그 씨앗을 한 문장으로 압축해 다음과 같이 표현할 수 있다.

고객에게 매일 가치를 전하라.

우선 학습적 면에서 보면, '매일' 하는 것은 학습의 빈도를 말한다. 불확실성이 높을수록 빈도가 자주 있어야 한다. 그리고 좋은 학습은 질 높은 피드백에서 오게 된다.

협력이라는 면에서는 '고객에게'라는 부분이 그 중요성을 말하고 있다. 협력을 통해서 결과물이 나온다. 여기에서 고객은 넓은 의미로 이해관계자라고 생각하자. 우리에게 돈을 주고 일을 맡긴 사람뿐만 아니라 우리의 이해관계자는 모두 고객으로 여겨야 한다. 그리고 협력을 할 때 '가치를 전하면' 협력이 쉽다. 왜 그럴까? 우선 신뢰가 쌓이게 된다. 신뢰 자산이라는 말이 있을 만큼 신뢰가 있을 경우 협력의 비용이 낮아지고 원활해진다는 연구가 많다. 그리고 이는 앞의 학습과도 연결되는데 가치를 전달하게 되면 의사소통이 명확하고 구체적이게 된다.

📚 애자일 도입 성공 요인 분석

🎈 애자일 도입 설문

일전에 애자일 도움 실태 설문을 진행했고, 약 70여 개의 회사에서 응답을 해줬따. 응답자의 직급은 다양했고 43% 분들이 과장, 차장 직급이었다.

애자일을 도입해서 프로젝트 성공에 도움에 되었냐는 질문에 대한 응답은 53%가 그렇다고 답했고, 25%는 매우 그렇다고 답했다. 전체에서 78%는 애자일이 프로젝트 성공에 긍정적인 영향을 미쳤다고 본 셈이다.

프로젝트 성공과는 별개로 현재 실천하는 애자일 실천법의 성숙도를 묻은 질문이 있었다. 전혀 안된다, 보통, 잘 하고 있다의 세 그룹이었다.

성숙도와 성공도의 상관성이 중간 정도였고 따라서 대체적으로 애자일 성숙도가 높은 조직은 애자일이 프로젝트 성공에 도움이 많이 된다고 느끼는 것으로 나왔다. 흥미로운 점은 성숙도를 낮게 평가한 조직이 성공도도 무조건 낮은 것은 아니라는 사실이다. 하지만 성숙도가 높은데 성공도가 낮은 조직은 없었다.

🎈 애자일 도입에 대한 무서운 사실

고객 참여를 잘하는 프로젝트는 성공도가 0.77만큼 높아질 수 있었다. 애자일이 프로젝트 성공에 도움에 되었냐는 질문에 매우 그렇다고 답한 그룹에서 약 60%가 고객 참여를 도움이 된 실천법으로 꼽은 반면 애자일이 프로젝트 성공에 도움이 되었는가에 그저 그렇다, 아니다, 매우 아니다로 답한 그룹에서 고객 참여를 선택한 조직은 없었다.

고객 참여 다음의 세 가지는 성공 기여도가 비슷했다. 리팩터링, 코딩 후 자동화 단위 테스트 붙이기, 코드 공유 순이다. 어쨌건 이 4가지가 잘 되어야 프로젝트 성공에 애자일이 도움이 될 수 있다.

그런데 많은 조직들이 고객 참여와 코드 공유를 뒤로 미룬다. 우리 상황에서는 할 수 없다. 어렵다라고 생각한다. 두 가지 모두 사람이 중심이 되기 때문이다. 고객 참여는 고객을 설득해야 하고, 코드 공유는 개발자를 설득해야 한다. 하지만 이런 것들을 제대로 하지 않으면 프로젝트를 성공하기가 더 힘들어진다.

두려워도 중요하다면 시도해봐야 한다. 두려운 걸 용기를 갖고 직면해야 한다는 것이다.

🎈 성숙도가 낮다면 고객 참여는 필수

성숙도가 낮아도 고객 참여를 잘하면 프로젝트 성공도가 한 칸 올라간다. "우리가 애자일을 도입한 지 얼마 안 되었다. 잘 못 한다. 그런데 어떻게든 프로젝트가 더 성공적이 되었으면 좋겠다"라는 입장이라면 답은 고객 참여뿐이다.

성숙도가 높은 조직을 보면 짧은 반복 개발 주기가 1등이다. 고객 참여보다 더 기여도가 높다. 그 말은 성숙도가 높은 조직에서는 고객 참여보다 짧은 반복 개발 주기가 성공에 더 도움이 될 수 있다는 뜻이다.

애자일에 대해 어느 정도 이해는 하고, 실험도 좀 해봤다 싶은 조직에서 성공 기여도를 높이려면 짧은 반복 개발 주기, 고객 참여, 코드 공유에 관심을 기울여야 한다. 성공도 회귀분석을 정리하자면 고객 참여와 짧은 개발 주기가 프로젝트 성공의 가장 핵심이라고 말할 수 있다. 애자일 소프트웨어 개발 프로젝트에 적용할 때 고객 참여와 짧은 개발 주기를 하면 함께 자라기가 되는 것이고, 이것이 불확실성하에서 우리가 더 현명해지도록 도와주는 것이다.

고객 참여란 고객 혹은 고객을 대표하는 사람의 참여다. 진정 중요한 것은 프로젝트의 성패를 좌우하는 사람과 최대한 가까운 사람을 참여시키려고 우리가 계속 노력하는 것이다.

애자일 도입의 핵심적 성공 요인이 무엇이었는가. 성공하는 조직들에는 항상 뛰어난 애자일 코치가 있었다. 뛰어난 애자일 코치를 통해 실천법을 더 잘 도입할 수 있게 되는 것이다.

애자일 코치는 어느 누가, 어느 조직이 정해줄 수 있는 것이 아니다. 조직적, 정치적 위치와는 관계가 없다. 오로지 자신의 선택이다. 애자일 코치는 그런 것이다. 내가 애자일 코치가 되어야지 결심하는 것이 가장 중요하다. 뛰어난 애자일 코치가 정해져 있다고 믿지 않는다. 성장할 수 있다고 믿는다. 누구나 뛰어난 애자일 코치가 될 수 있다고 믿는다.

성과 높은 사람으로서의 전문 S/W 엔지니어에 대한 연구로부터 밝혀진 것은 사회적 능력의 중요성이다. 지적 능력이 뛰어난 프로그래머들의 성과를 구분하는 것은 사회적 능력임이 밝혀졌다. 다른 사람과 협력이 중요하다. 실제로 뛰어난 S/W 엔지니어들은 높은 대인 능력을 갖고 있는 것이 관찰되었다. 탁월한 엔지니어들은 프로젝트 전반에 대한 큰 그림을 가지려고 하고, 경영진에게 더 적극적인 태도로 다가가고, 다른 엔지니어들을 도와준다.

결과적으로 보면 뛰어난 애자일 코치는 함께 자라기를 하는 사람이다.

1. 애자일을 도입해서 성공하는 조직들이 국내에 있다.
2. 애자일 실천법을 잘 실행하면 성공률도 높아질 수 있다.
3. 실천법 중에서 비교적 성공과 직결되는 것들이 존재한다. 그것은 고객 참여, 리팩터링, 코딩 후 자동화 단위 테스트 붙이기, 코드 공유 등이다.
4. 애자일 성숙도가 낮은 조직일수록 고객 참여를 하지 않으면 프로젝트 성공이 어렵다.
5. 무섭고 두렵지만 중요한 일이라면 계속 미루지 말라.
6. 뛰어난 애자일 코치가 있는 것이 애자일 도입 성공에 핵심적이다.
7. 뛰어난 애자일 코치는 함께 자란다.

📚 당신의 조직에 새 방법론이 먹히지 않는 이유

소프트웨어 개발은 예측하기 어렵고 복잡한 도메인이다. 새 프로젝트를 진행할 때에 우리가 어떤 방법론을 쓰느냐는 문제보다도 누가 참여하는가가 훨씬 더 압도적으로 중요한 문제가 아닐까?

애자일 방법론을 도입을 원하는 팀장이라면 "나는 어떤 팀장인가" 를 먼저 자문해봐야 하지 않을까 싶다. 내가 어떤 팀장인지가 전혀 바뀌지 않으면서 새 방법론만 도입한다고 무슨 효과가 있을까? 반대로, 별 볼 일 없어 보이는 방법론일지라도 그걸 처방하는 팀장에 따라 전혀 다른 효과가 있을 것이다.

📚 애자일을 애자일스럽게 도입하기

애자일을 진행하는 가운데 가장 빈법히 빚어지는 폐단은 무엇인가?

애자일을 반애자일적으로 진행하는 것이다. 예컨대 애자일은 불확실한 상황에 대한 접근법인데, 애자일을 도입할 때 확실성 위에서 진행하려고 한다면 문제가 된다.

애자일 방법론을 도입할 때 뭘 해야 할지 명확하게 알려달라고 한다. 근데 그 모습은 전혀 애자일적이지 않다. 찾아가는 모습이 애자일이다. 어차피 방법론 도입이라는 것이 매우 불확실한 것이기 때문에 정답이 있을 수 없다.

이것은 거의 모든 종류의 방법론 도입에 적용된다. 왜냐하면 방법론 도입은 태생적으로 불확실성이 높기 때문이다. 그럴 때 현명한 전략은 정해진 수순을 따르는 것이 아니라 곁에 있는 사람들과 함께 주변을 탐색하고 조금 나아가고 확인하고를 반복하면서 우리의 현 맥락에 맞는 좋은 전략들을 스스로 만들어 나가는 것이 아닐까 한다. 그리고 이 과정에서 함께 자라기가 귀중한 나침반이 되어 줄 것이다.