애자일을 대충 알고 있는 당신을 위하여

수업이든, 동아리든, 회사든… 소프트웨어를 개발하는 사람이 모인 조직 내에서 효율적인 업무처리 방식을 논할 때 “ 애자일, 스크럼, 스프린트 “ 이 세 가지 단어는 꼭 끌려 나온다. 덕분에 우리는 개발자로 살아오면서 애자일, 스크럼, 스프린트라는 단어를 한 번쯤은 들어봤다.

그런 식으로 남이 말하는 걸 열심히 주워들은 덕분에, 우리는 애자일 방법론을 몸소 체험해보지 못했더라도 애자일 방법론에서 파생된 단어가 낯설지 않다. 담고 있는 의미를 얼추 설명할 수도 있다. 좀 더 자세한 내용을 찾아보기 위해서 책과 아티클을 따로 읽어본 사람이라면 거기서 이야기하는 각종 사례를 바탕으로 애자일 방법론을 도입한 팀의 업무가 어떤 식으로 굴러가는지도 얼추 짐작할 수 있으리라.

바로 그게 문제다. 우리는 ‘얼추’ 설명할 수 있고, ‘얼추’ 짐작할 수 있다. 얼추란 무엇인가? 사전적 의미는 다음과 같다.

얼추
1. 어지간한 정도로 대충.
2. 어떤 기준에 거의 가깝게.

얼추 = 대충

요약하자면 우리는 지금까지 애자일을 ’대충’ 설명할 수 있었고, 애자일을 도입한 조직이 어떤 식으로 업무를 진행할지 ‘대충’ 짐작할 수 있었다. 우리는 명확히 알고 있는 게 하나도 없다. 남이 이야기하는 애자일 방법론을 듣기만 했지 제대로 된 애자일 방법론을 도입해서 업무를 처리하는 조직을 몸소 경험하지 못했기 때문이다.

방법론은 그 자체가 글자로 쓰여진 이론에 불과하기에 조직에 도입하기 전 체계적인 연구가 필요하다. 또한, 조직이 최고의 효율을 보이며 업무를 수행할 수 있게 도와주는 방법론을 결정하는 과정도 빈말로 쉽다고 할 수 없다. 수많은 고민이 필요하고, 그걸 잘 해낼 수 있는 전문가가 필요하다.

대다수 조직은 가만히 앉아서 방법론만 연구하고 있을 리소스가 없다. 눈으로 확인할 수 있는 성과를 내야 하므로 서비스 개발하기 바쁘다. 그래도 업무처리 방식을 정하긴 해야 되니, 타 조직에서 도입한 방법론을 가져다가 우리 조직에 맞춰서 약간 수정하는 과정을 거친다. 물론 수정 작업을 진행한 사람이 방법론 전문가가 아닌 건 당연지사다.

이 과정 끝에 만들어진 업무 처리 방식이 조직 내에 도입되면, 우리가 제대로 된 방법론을 몸소 느껴봤다고 이야기할 수 있을까?

조금만 덜 대충 해보자.

애자일 방법론을 제대로 사용하면서 업무 프로세스를 끌어나가는 조직을 만나는 건 모래사장에서 바늘 찾는 일만큼 어렵다. 현실이 이러므로 경험해보지 못한 게 당신 잘못은 아니다. 경험해본 사람도 그런 당신을 이해해주리라. 다만, 그러한 그들의 태도가 당신이 계속 대충 아는 상태로 남아도 된다는 의미는 아니다. 경험 못 해봤더라도 어쨌든 지금보다 더 자세히 알긴 알아야 한다.

자세히 알기 위해서 가장 좋은 방법은 직접 경험해보는 거지만 이건 당장 실천할 수 없으니 제쳐두자. 두 번째 방법은 시중에 나와 있는 좋은 책을 사서 읽는 건데 현대인의 독서량이 점점 떨어지고 있는 상황이 바로 지금 우리네가 살아가고 있는 현실에서 펼쳐지고 있기에 감히 시도하라고 말하진 않겠다. 어차피 사서 안 읽을 거 아닌가? 아니면 아예 사지도 않거나. 그럴 거면 그 돈으로 맛있는 거나 사서 먹자.

나는 당신에게 앞으로 소개할 세 번째 방법을 추천한다. 직접 경험도 해보고, 관련 책도 찾아서 좀 읽어본 사람이 잘 정리한 글 을 찾아서 읽어라.

잘 정리한 글의 글쓴이는 몸소 애자일한 업무 프로세스를 체험해봐서 그런지 현실과 이상의 차이점을 알고 있다. 글쓴이는 잘 정리한 글을 쓰기 전에 당신이 사지 않은, 혹은 읽지 않은 책을 대신해서 사고, 읽었다. 그렇게 글쓴이는 직접 체험한 경험과 책을 통해 얻은 지식을 자신이 쓴 글 속에 녹였다. 직접 겪은 경험과 직접 얻은 정보를 당신에게 공유하고 전달하기 위함이다.

잘 정리한 글의 글쓴이가 바로 나라고 당당히 소개하고 싶지만, 아직 미숙한 면이 없지 않아서 외침은 삼가겠다. 나보다 먼저 잘 정리한 글을 쓴 사람이 인터넷에 널려있는 게 현실이니까. 그러나, 현실이 그렇다고 내가 잘 정리한 글의 글쓴이가 될 자격과 기회가 없어졌다는 소리는 아니다. 정말로 자격과 기회가 없어졌으면 이 글을 쓰지도 않았다.

잘 정리한 글의 글쓴이 무리에 합류하기 위해서, 당신에게 경험과 지식을 공유하기 위해서 나는 키보드를 두드렸다. 그러니 당신이 이 글을 읽고 난 후, 적어도 스프린트와 KPT 만큼은 조금만 덜 대충 알고 갈 수 있기를 바란다.

추가로, 하필 수많은 애자일 방법론 속 키워드 중에서 스프린트와 KPT 만 이야기하는 이유가 무엇이냐고 묻는다면 나는 이렇게 대답하겠다.

“지금 내가 속한 팀에서 쓰려는 게 저 두 개예요.”

그래도 애자일이 뭔지는 좀 짚고 넘어가자.

우리는 애자일이라는 단어를 지긋지긋하게 들어봤다. 애자일이 도대체 뭘까? 다른 사람은 애자일을 어떻게 설명하고 있을까? 나는 구글에서 검색해봤다.

‘애자일이란?’ with Google

키보드의 엔터키를 누르거나 검색창 우측의 돋보기 모양 버튼을 마우스로 클릭하면, 구글은 웹 브라우저 화면에 애자일이 뭔지 설명하는 수많은 블로그 포스팅 리스트와 위키백과의 사전적 정의를 담은 박스 엘리먼트를 출력한다.
위키백과는 애자일을 다음과 같이 설명한다.

애자일 소프트웨어 개발 혹은 애자일 개발 프로세스는 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진한다.
출처 : 위키백과

음. 소프트웨어 엔지니어링에서 쓰이는 ‘개념적인 뭔가’ 가 애자일이고, 애자일을 사용하면 프로젝트가 살아있는 동안 반복적인 개발을 촉진한다는 건 알겠다. 그 이상은 모르겠다. 네이버에서 똑같이 검색해보자.

‘애자일이란?’ with NAVER

네이버는 애자일의 정의를 말하는 지식백과 리스트와 동영상, 이미지, 타 웹사이트 링크, 네이버 블로그 포스팅, 지식인 등 수많은 내용을 웹 브라우저 화면에 출력한다.
가장 상단에 위치한 지식백과 리스트 중 첫 번째 아이템은 애자일을 다음과 같이 설명한다.

애자일은 2000년대부터 주목받기 시작한 소프트웨어 개발 방식이다. 계획이나 문서화 작업보다는 프로그래밍 과정에 초점을 두고 있다. 고객의 피드백을 적극적으로 반영…
출처 : 네이버 지식백과 <용어로 보는 IT>

모두가 애자일이라고 부르는 ‘개념적인 뭔가’ 는 반복적인 개발을 촉진시키다 못해, 계획이나 문서화 작업보다 프로그래밍 과정에 초점을 두는 특징을 가지고 있는 거 같다. 고객의 피드백을 적극적으로 프로젝트에 반영함은 물론이다.

어떤가. 좀 더 지식이 확장되었음을 느끼는가? 솔직히 말해서 나는 잘 모르겠어서 옆에 있는 책을 바로 펼쳤다. 애자일을 도대체 뭐라고 설명해야할까? 그런 고민과 함께 책의 페이지를 넘겼다. 참고로 내가 읽은 책은 2020년 12월 4일 초판 1쇄가 발행된 로버트 C. 마틴이 쓴 <클린 애자일Clean Agile>이다.

‘애자일이란?’ with Clean Agile

로버트 C. 마틴은 클린 애자일 책에서 애자일을 다음과 같이 설명한다.

애자일은 프로젝트를 더 작은 반복 주기로 나누는 프로세스다. 각 반복 주기의 결과물을 측정하여 지속적으로 일정을 평가하는 데 사용한다. 기능은 비즈니스 가치 순서대로 구현하므로 가장 중요한 것이 먼저 구현된다. 품질은 가능한 한 높게 유지한다. 일정은 주로 범위를 조절하여 관리한다.
이것이 애자일이다.

오, 이제 뭔가 좀 알겠다. 애자일은 ‘프로젝트를 더 작은 반복 주기로 나누는 소프트웨어 개발 방식’ 인 거 같다. Google과 NAVER에서 찾은 문장까지 합쳐서 정리해보자. 애자일이 ‘더 작은 반복 주기로 개발을 촉진하고, 계획이나 문서화 작업보다 프로그래밍 과점에 초점을 두는’ 특징을 가지고 있다는 걸 확인할 수 있다.

당신은 이제 대충 애자일이 뭔지 감이 잡혔다… 라고 생각할 것이다.

자. 여기서 다시 한 번 대충 이라는 단어가 나왔다. 잠깐 스크롤을 위로 올려보자. 내가 대충 넘어가지 말자고 앞에서 이야기한 문장을 다시 확인할 수 있다. 난 적어도 당신이 덜 대충 알고 갈 수 있게 글을 쓰기로 마음을 먹었다. 그래서 다음 키워드인 스프린트로 넘어가기 전에 애자일을 조금만 더 파고 들어갈 생각이다.

왜 애자일이 등장했을까?

왜 프로젝트를 더 작은 반복 주기로 나누는 프로세스가 필요했을까?

여기에 대한 히스토리를 알게 되면 당신은 애자일을 덜 대충 이해하고 넘어갈 수 있다. <클린 애자일> 속 내용을 좀 더 알아보자.

애자일 덜 대충 이해하기

팀 단위로 협업해본 사람은 안다. 프로젝트 매니저, 즉 관리자가 팀에 대한 데이터를 파악하고 있어야 업무 프로세스가 원활하게 굴러간다. 여기서 데이터는 팀원의 시시콜콜한 정보 따위를 말하는 게 아니다. 관리자가 파악할 데이터는 바로 팀의 업무 속도, 팀의 목표 달성치를 의미한다.

관리자는 어떤 수단을 통해 그 중요한 데이터를 파악하고 있을까? 제 두 눈으로 직접 팀이 일하는 모습을 관찰하면 데이터를 주르륵 뽑을 수 있을까? 아니다. 그런 방법 만으론 팀이 어떤 속도로 움직이고 있는지, 팀이 목표를 달성하기까지 얼마나 남았는지 파악할 수 없다. 관리자는 직접 업무에 발을 담구지 않는 사람이라는 걸 명심하자.

소프트웨어 개발팀은 ‘마감 기한은 바뀌지 않지만, 요구 사항은 끊임없이 바뀌는 프로젝트를 성공적인 결과로 이끌어야 하는’ 세상 속에서 살고 있는데, 프로젝트 매니저가 팀에 대한 데이터를 파악하고 있지 않으면 그 세상은 과연 어떤 식으로 돌아갈까? 어떤 결말을 맞이하게 될까?

1. 우선 회의를 하겠지

두둥.

프로젝트 시작을 알리는 회의가 열렸다.
조직장은 말했다.

“새로운 프로젝트를 수주했습니다. n월 m일에 끝날 예정입니다. 아직 정확한 요구 사항은 모릅니다. 아마 1, 2주 정도 안에 전달될 겁니다. 자, 요구 사항 분석하는 데 얼마나 걸릴까요?”

당신을 포함한 소프트웨어 개발팀에 속한 이들은 쉽게 말을 꺼내지 못하고 눈치만 보고 있다. 당연하다. 쉽게 대답할 수 있는 질문이 아니니까.
침묵이 이어지고 있는 와중에 어느 한 명이 용기를 ‘조금’ 내서 중얼거렸다.

“하지만 아직 요구 사항이 뭔지도 제대로 모르는데요.”

조직장이 소리쳤다.

“요구 사항이 있다 치고 해보자는 거죠! 일이 어떻게 돌아가는지 다 알잖아요. 모두 전문가 아닙니까? 제가 지금 정확한 날짜를 말하라는 게 아닙니다. 러프하게라도 일정을 잡아야 하니까 물어보는 겁니다. 참, 만약 분석 과정에 두 달이 넘게 소요된다고 하면 이 프로젝트는 그냥 접는 게 나아요. 알아 두세요.”

누군가의 입에서 되묻는 것처럼 “두 달?”하고 작게 웅얼대는 소리가 흘러나오자, 조직장은 그걸 냉큼 의견으로 받아들이며 외쳤다.

“좋아요! 제 생각도 그래요. 두 달이면 충분할 거 같습니다. 자, 그러면 설계에는 시간이 얼마나 걸릴까요?”

조직장의 선언이 다시 한번 모두의 뒤통수를 쿵 치고 지나갔다. 충격에 말을 잃었음은 물론이다. 오늘 날짜로부터 n월 m일까지 6개월밖에 남지 않았다는 사실이 조직장을 제외한 팀원의 머릿속을 스치고 지나갔다. 그리고, 조직장이 듣고 싶은 답이 정해져 있음을 깨달았다.
당신은 말했다.

“두 달요?”
“좋아! 정확해. 제가 생각한 거랑 똑같네요. 그러면 분석에 두 달, 설계에 두 달을 쓰고 남은 두 달 동안 구현하는 데에 집중해봅시다. 모두 회의하느라 고생 많았어요.”

와, 정말 시간 낭비 그 자체다. 쓸모없는 회의의 대명사라고 위 사례를 소개할 수 있으리라.

소설처럼 사례를 설명한 만큼, 저게 정말 현실에선 일어나지 않는 일이었으면 좋겠다.

안타깝지만 저건 현실이다. 나는 저런 개노답 회의를 종종 겪어봤다. 당신도 마찬가지일 것이다.

2. 어찌 됐든 분석을 하긴 해야 하는데…

자. 요구사항이 1, 2주 걸려서 팀에 떨어지긴 했다. 이제 분석 단계에 들어갈 시간이다.

어… 분석 단계에서 정확히 무슨 일을 하면 좋을까? 요구 사항을 정교하게 다듬는 일? 데이터 모델 및 객체 모델 미리 만드는 일? 목업 컴포넌트 만드는 일? 프로젝트 규모를 추산하는 일? 실현 가능성 검증? 인력 계획? 프로젝트를 마칠 수 있는지에 대한 여부 파악?

이처럼 분석이 도대체 뭔지 정확히 알지도 못하는 상태로 당신은 두 달이라는 시간을 보내야 한다.

뭐, 행복할 거다. 분석을 빌미로 웹 서핑도 좀 하고, 주식 장도 좀 보고, 고객 인터뷰도 하고, 분석한 데이터-뭘 분석한 건지 모르겠지만-를 가지고 차트도 그려볼 테니까.

그렇게 두 달이 지나면 분석은 놀랍게도 알아서 끝난다.

뭐지? 왜 분석이 끝났을까? 사실 위에 나열한 것만 보면 딱히 분석이라고 부를만한 일을 한 것도 없다. 그냥 월급 루팡의 일상에 불과하다. 근데 분석이 끝났다고 다들 손뼉을 치고 조직장은 팀원을 칭찬하고 회식 자리를 만들고 작은 난리를 피운다.

이건 다 분석 단계에 할당된 두 달이라는 시간이 모두 지났기 때문이다. 그냥 단순히 해당 단계를 처리하라고 주어진 시간이 다 지났기 때문에 다음 단계로 넘어가는 거다.

3. 설계할 시간이다. 어, 잠깐만. 분석한 게 없는데?

뭐, 그래도 설계 단계는 얼추 돌아간다. 분석보다는 조금 더 명확하게 해야 할 일이 보이기 때문이다.

소프트웨어 설계란 프로젝트를 모듈별로 나누고, 각 모듈 간의 인터페이스를 구성하는 것을 말한다. 각각의 모듈과 인터페이스를 구성하기 위해 팀을 나누고, 나누어진 팀과 팀은 어떻게 연결할지 고민하는 단계라고 보면 된다. 현실적으로 달성 가능한 구현 계획을 만들기 위한 일정 조정도 보통 이 단계에서 이루어진다.

물론 설계 단계가 순순히 흘러가란 법은 없다. 예상하지 못한 일은 이곳저곳에서 발생한다. 새로운 기능이 추가되고, 기존 기능은 빠지거나 변경된다. 답이 나오질 않아서 요구 사항을 다시 분석해보고 싶지만 앞 단계로 돌아가기엔 시간이 없다. 그러니 적당히 땜빵해서 설계의 구멍을 메꾼다.

와! 그렇게 두 달이 지나니까 알아서 설계가 끝난다! 다시 또 두 달이 지났으니까!

단계를 처리하라고 주어진 두 달의 시간이 전부 어디론가 사라지고 남은 건 구멍 숭숭 뚫려서 답 없는 소프트웨어 설계도뿐인데 설계가 끝났단다.

뭔가 불안한 마음이 싹트는 와중에 다들 손뼉을 치고 조직장은 팀원을 칭찬하고 회식 자리를 만들고 작은 난리를 피운다 2.

뭐, 분석하고 설계는 어쩔 수 없이 이런 식으로 넘어가야 하는 건 맞다. 분명한 완성 기준이 없어서 진짜로 분석이나 설계가 끝났는지 알 방법이 없다.

그러나 구현은 다르다.

4. 구현만이 남아있다. 지옥이 다가온다.

구현은 완성 기준이 명확하다. 완성된 것처럼 꾸밀 방법은 없다. 당연히 해야 할 일은 모호하지 않다.

당신은 코딩한다. 코딩하고, 코딩을 한다.

그 와중에 요구사항은 계속 바뀐다. 새로운 기능이 계속 추가되고, 기존 기능은 계속 빠지거나 변경된다.

으악! 요구사항을 다시 분석하고 설계하고 싶지만 이제 진짜 마감 기한까지 얼마 남지 않았다. 계속 코드를 땜질한다. 땜질, 땜질, 땜방. 걱정할 시간 따위 없다. 야근만이 있을 뿐.

그러다가 마감 기한이 거의 코앞으로 다가왔을 때쯤, 누군가가 말한다.

“저, 이거 마감이 언제죠? 언제까지 완성해야 하죠?”

소프트웨어 개발팀은 주어진 시간이 얼마 남지 않은 상황에서 마감 기한까지 구현 단계를 절대 끝낼 수 없다는 걸 알아차리게 됐다. 동시에, 이해관계자는 프로젝트에 문제가 생겼다는 걸 마감 기한이 얼마 남지 않은 시점에 와서야 처음으로 전해 듣게 될 것이다.

와. 당신은 이해관계자의 불만을 상상할 수 있는가?

“분석 단계에서 우리에게 알려줄 수는 없었습니까? 프로젝트 규모를 산정하고 일정을 맞출 수 있는지 가늠하는 건 분석 단계에서 해야 할 일 아닙니까? 설계 단계에서는요? 요구사항을 모듈별로 나눈 후, 그 모듈을 팀별로 할당하고, 인력 수요를 계산하는 일이 설계 단계에서 해야 할 일 아닙니까? 왜 이제 와서 문제가 생겼다고 말하는 거죠?”

5. 지옥의 끝이 보이지만…

고객은 이미 화가 났고 이해 관계자도 화가 났다. 압박은 심해지고 야근 시간은 급증한다. 그만두는 사람이 하나둘 늘어난다. 지옥이다.

그래도 뭐, 한 3~4개월 시간을 보내고 나니 고객의 초기 요구 사항 중 절반 정도는 그럭저럭 해내는 소프트웨어를 만드는 데 성공했다. 와, 끝났다… 기뻐하긴커녕 상심한 모두는 다짐한다. 다음엔 이렇게 안 한다. 제대로 할 거다. 더 분석하고, 더 설계해야지!

과연…

자, 아주 끔찍한 사례를 하나 살펴봤다. 업무 프로세스에 폭포수 모델을 사용했을 때 발생하는 일이고, 프로젝트 매니저가 팀에 대한 데이터를 제대로 파악하지 않았을 때 펼쳐지는 지옥도다.

뭐, <클린 애자일> 이라는 책 속에 나도는 이야기니 과장도 어느정도 포함되어 있으리라. 실제로 <클린 애자일> 에서 로버트 C. 마틴은 이런 말을 한다.

“이 이야기는 과장일 수 있지만, 한 편으로 사실이기도 하다.”

나는 이 말에 공감한다. 과장같지만, 사실이다. 나도 경험해본 적이 있다. 이 글을 읽는 당신도 아마 경험해본 적이 있을 것이다. 경험자인 우리는 다시금 생각한다.

우리 소프트웨어 개발자는 위와 같이 프로젝트가 진행되는 걸 원하지 않는다.

그래서 애자일이 나왔다.

애자일의 정의를 다시 한 번 살펴보자.

애자일은 프로젝트를 더 작은 반복 주기로 나누는 프로세스다. 각 반복 주기의 결과물을 측정하여 지속적으로 일정을 평가하는 데 사용한다. 기능은 비즈니스 가치 순서대로 구현하므로 가장 중요한 것이 먼저 구현된다. 품질은 가능한 한 높게 유지한다. 일정은 주로 범위를 조절하여 관리한다.
이것이 애자일이다.

위 정의처럼 애자일은 전체 프로젝트를 마감 기한에 맞춰서 일정한 크기로 더 작게 나눈다. 이걸 반복 주기 또는 스프린트라고 부른다.

첫 번째 반복 주기를 반복 주기 0이라고 하는데, 이때 스토리를 만든다. 스토리는 프로젝트에 들어갈 기능 목록, 즉 개발자가 개발해야 하는 기능이라고 생각하면 된다. 반복 주기 0 동안 개발 환경을 준비하고, 스토리의 크기를 추산하고 최초의 계획을 ‘단순하게’ 세운다. 개발자와 기획자, 디자이너는 만들어진 스토리를 바탕으로 프로젝트의 밑그림을 그린다. 프로젝트가 끝날 때까지 이러한 분석과 설계 과정이 끊임없이 반복된다.

어라? 이상하다고 생각한 사람 분명히 있으리라. 왜냐하면 분석과 설계를 반복하는 건 위에 나온 폭포수 모델과 다른 구석이 없어 보이기 때문이다. 분석과 설계를 거치는 크기를 작게 만들었을 뿐, 애자일은 폭포수 모델과 다를 바가 없어 보인다.

하지만 그렇지 않다. 애자일은 반복 주기 전체에 걸쳐서 요구 사항 분석, 아키텍처 수립, 설계, 구현 작업이 끊임없이 일어난다. 설계 단계에서 분석 단계로 다시 회귀할 수 없는, 구현 단계에서 설계 단계로 다시 회귀할 수 없는 폭포수 모델과는 확연히 다르다.

이렇게 분석, 설계, 구현 작업이 특정 주기 동안 끊임없이 일어나면, 자연스럽게 특정 주기 하나 동안 개발팀이 스토리를 얼마나 완료할 수 있는지에 대한 수치를 측정할 수 있다. 관리자는 소프트웨어 개발팀에 대한 데이터를 얻을 수 있고, 데이터를 기반으로 계획을 조정하거나 프로젝트의 종료 일자를 명확히 계산할 수 있다.

물론 오차가 커서 초기에 예상했던 프로젝트 종료 일자보다 훨씬 더 먼 미래의 날짜가 계산될지도 모른다. 그럼 이제 관리자는 개발팀의 희망을 부술 일만 남았다. 관리자가 “개발 어떻게 되어가요?” 라고 물었을 때, “나쁘지 않아요. 괜찮아요.” 라고 대답하는 개발팀이 품은 희망을 부숴야 한다.

애자일은 빠르게 나아가는 게 아니다. 우리가 얼마나 망했는지를 최대한 빨리 아는 것이다. 그래야 망한 상황 속에서도 최선의 결과를 얻을 수 있다.

상황이 망해버리고 나면 이후는 어떻게 흘러갈까? 뻔하지 않겠는가. 일정을 변경해보거나, 인력을 추가하거나, 품질을 포기하거나, 개발 범위를 변경하거나, 비즈니스 가치에 따라 개발 순서를 변경하거나…

프로젝트가 망해도, 얼마나 망했는지 최대한 빨리 알아차린 다음 망한 상황 속에서 최선의 결과를 얻기 위해 발등에 불난 듯 뛰어서 해결책을 마련하는 업무 프로세스.

이게 바로 애자일이다.

애자일 소프트웨어 개발 선언

반복 주기 또는 “스프린트”

애자일을 덜 대충 알 정도로만 설명했는데 글이 어마어마하게 길어졌다. 하지만 걱정하지 않아도 된다. 애자일 설명이 고비였고, 스프린트나 KPT 에 대한 설명은 아주 쉽고 짧게 끝날 예정이다. 예고편이 본편보다 길어진 꼴이 되었지만 애자일이란 게 원래 이런 녀석이다. 어쩌겠는가?

자, 위에서 언뜻 키워드가 나오긴 했지만 한 번 제대로 사전에서 찾아보자. 스프린트를 과연 뭐라고 정의하고 있을까? 네이버 국어사전은 다음과 같이 스프린트를 정의하고 있다.

스프린트(sprint)
1. 체육 육상, 수영, 스피드 스케이트 따위의 단거리 레이스. 또는 단거리를 전력으로 수영하거나 달리는 일.
2. 체육 자전거 경기에서, 트랙을 두 바퀴 또는 세 바퀴 돌아 도착한 순서를 겨루는 경기. 거리는 대략 1,000미터이고, 마지막 200미터에서 전속력을 낸다.

쉽게 말하면 단거리다. 짧은 거리, 짧은 시간 동안 결판을 내는 스포츠의 주기가 바로 스프린트다. 애자일을 스포츠에 비유해보면 더 이해하기 쉬울 것이다.

전체 프로젝트를 마라톤 코스라고 생각하자. 마라톤 코스를 단거리 수준으로 잘게 쪼갠다. 그리고, 쪼갠 만큼 우선 달려본다. 목표 지점에 도착했을 때 처음 생각했던 것보다 선수가 더 지쳤으면 다시 한번 코스를 쪼갠다. 생각보다 선수가 더 잘 달리면 코스를 조금 더 늘린다. 몸 상태와 코스 상태를 분석하고, 목표 지점까지 무사히 달릴 계획을 설계하고, 달린다.

애자일과 비슷하지 않은가? 그래서 스프린트라는 키워드가 애자일에 등장하게 된 것이다.

다만 여기서 하나 다시 한번 짚고 넘어가야 할 게 있다. 스프린트라는 단어만 보면 특정 기간 동안 전력으로 질주해야 할 것처럼 받아들이는데, 애자일은 빠르게 나아가는 게 아니다. 우리가 얼마나 망했는지를 최대한 빨리 알기 위해서 전체 프로젝트를 쪼개고 쪼개는 거다.

쪼갠 작업에 대해 요구사항 분석부터 아키텍쳐 수립, 설계, 구현 작업을 끊임없이 반복하는 하나의 과정 자체를 반복 주기 또는 스프린트라고 부르지만 절대 전력 질주가 아니다. 평균 1~2주의 기간 동안 개발팀이 충분히 해낼 수 있을 정도의 업무를 진행하는 게 목적임을 명심하자.

KPT

애자일은 필승전략이 아니다. 애자일은 그저 방법론일 뿐이고, 방법론을 제안하고 수용하는 사람이 어떤 태도와 능력을 갖추고 있느냐에 따라서 프로젝트는 망할 수도 있고 성공할 수도 있다.

그러므로 프로젝트를 마친 뒤엔 왜 망했는지 반성하고, 다음에 망하지 않으려면 어떻게 해야 하는지 분석할 시간이 필요하다. 왜 성공했는지 되돌아보고, 다음에도 성공하려면 무엇을 이번처럼 해야 하는지 분석할 시간도 필요하다.

우리는 이걸 회고라고 부르고, KPT는 수많은 애자일 회고 방법론 중 하나이다.

What we should keep. Where we are having ongoing problems. What we want to try in the next time period.
-Alistair Cockburn (KPT 회고 방법론 초기 제안자)

KPT는 Keep / Problem / Try 의 약자다. KPT 방법론은 회고를 진행하되 내용은 Keep / Problem / Try 세 가지 관점을 기준으로 생각해야 한다. 정해진 시간 순서대로 작성하고 모두와 함께 공유하면서 서로 의견을 나누고 최종적으로 해결책을 찾을 수 있도록 유도하는 간단한 회고 방법론이다.

Keep

• 현재 만족하고 있는 부분
• 계속 이어갔으면 하는 부분

Problem

• 불편하게 느끼는 부분
• 개선이 필요하다고 생각되는 부분

Try

• Problem의 해결책
• 다음 회고 때 판별할 수 있고, 바로 실천 가능한 부분

여기서 중요한 건 Keep 도, Problem 도 아니다. Try 가 가장 중요하다.

Problem 키워드가 나왔다는 건 개선이 필요하다는 의미인데, 대충 좋게 넘어가자고 말만 하고 끝내면 아무것도 해결되지 않는다. 다음 회고를 진행할 때까지 Problem을 확실히 개선할 수 있을 해결책을 Try 로 제안하여 팀 내에 존재하는 불편한 요소를 해소하고자 팀원 모두가 노력해야 한다.

물론, 그러기 위해서는 Problem 을 남몰라라 묻어두지 말고 팀원 모두에게 명확히 공유되어야 하는 게 선행 조건이지만 말이다.

난 이전 회사에서 KPT 회고를 경험했다. 내가 입사하기 전부터 팀원들은 주기적으로 회고를 진행했다고 들었다. 그래서인지 KPT 회고를 하기 위해 회의실로 갔을 때 책상 가운데에 놓인 Keep, Problem, Try 를 격자로 나눈 칸에 적은 하얀색 하드보드지 위에 이미 포스트잇이 덕지덕지 붙어있었다.

본격적인 회고에 들어가기 전, Keep을 잘 이어가고 있는지, Problem은 Try로 개선했는지, Try는 모두가 잘 실천했는지 훑어봤다. 이후 하드보드지 위의 포스트잇을 모두 떼어낸 다음 각자 다양한 색깔의 포스트잇과 유성 매직을 나눠 가졌다.

정해진 시간 동안 Keep과 Problem에 해당하는 회고 내용을 적었다. 정해진 시간이 끝나면 돌아가면서 포스트잇에 적은 내용을 간단하게 설명한 뒤 하드보드지에 붙였다.

그렇게 모든 사람이 한 번씩 이야기하고 나면 진행자는 Problem을 해결할 수 있는 Try 를 고민하는 시간을 준 다음, 포스트잇에 내용을 쓸 수 있도록 유도했다.

오래전 일이라서 흐릿하지만 하나 생생하게 기억나는 Problem 과 Try 가 있다. 그 당시, 우리가 모두 오전 10시에 맞춰서 출근하지 않고 미적미적 지각하기 시작했는데 하나둘 그러다 보니 각자가 회사에 도착하는 시간이 뒤로 계속 늦춰졌다. 자연스럽게 각자의 업무 시간이 어긋나 협업 시 커뮤니케이션에 불편함을 불러일으켜서 Problem으로 해당 내용이 적힌 포스트잇이 붙였다.

우리는 그 문제를 해결하기 위해 출근하자마자 사무실에 있는 화이트보드에 출석명부(..)를 적은 뒤 10시 정각에 캡처해서 슬랙으로 지각자를 공개처형(..) 하기로 Try 를 정했다. 우스꽝스러운 Try라고 생각할 수도 있겠으나, 놀랍게도 성과가 있었다. 지각률이 확연히 줄었다.

어째서냐고? 모든 팀원이 해당 불편 사항을 Problem으로 인지했으며 이대로 가다간 조직 문화에 안 좋은 영향을 끼칠 수 있으니 개선할 필요성이 있다고 분명히 생각했기 때문이다. 더불어 문제점을 개선하기 위한 해결책으로 나온 Try를 진중하게 받아들여 정말 실천으로 옮기고자 모두 노력했기 때문이다.

이처럼 KPT 회고는 단순해 보여도 회고에 참여하는 팀원의 마음가짐이 가장 중요하다. 정말로 문제를 개선하는 게 필요하다고 생각했으며, 개선하기 위한 해결책을 몸소 실천하는 행동력을 보일 정도로 진지하게 회고에 임해야 한다. 직접 경험해본 바가 그렇다.

덜 대충 맺음말을 적어본다.

솔직하게 말하자면 나는 운이 좋다. 첫 회사에서 만난 사람들에게 개발 지식부터 조직 문화, 각종 방법론까지 무수히 많은 것을 배웠다. 그곳에서 본격적으로 총대를 메고 진행해본 적은 없지만 열심히 주워들은 게 많아서 지금까지 알차게 써먹고 있다. 애자일이나 스프린트, KPT 도 첫 회사에서 제대로 배웠고 몸소 경험했다. 물론 학부생 때 소프트웨어 공학 수업에서 배우기야 했지만 그건 정말 탁상공론에 불과한 재미없는 이론이 아니던가.

지금 와서야 이렇게 주저리주저리 글을 쓸 수 있을 정도로 좀 더 공부하게 됐지만, 나도 막 주워듣기 시작했을 땐 딱 당신처럼 대충 알고 있었다. 그래도 되는 줄 알았다. 나는 애자일 마스터가 아니고, 개발자고, 프로젝트 매니저는 어차피 따로 있을 테고 나는 관리 받기만 하면 될 테니까. 참으로 나이브하게 생각했었다.

그러다가대충 알고 있는 걸 대충 알고 있지도 않은 사람에게 알려주려고 하면서 나의 부족함을 깨달았고, 정신 차릴 수 있었다. 그때 다시 내 경험을 되짚어봤다. 생각보다 진짜배기 애자일을 경험해봤더라. 그걸 남에게 알려주지 못하는 게 아까워서 좀 더 전문적인 용어를 확실히 이해하기 위해 유명한 사람(여기선 로버트 C. 마틴)이 쓴 책을 읽었다. 둘을 비교하면서 머릿속에 대충 박혀있던 걸 덜 대충이 될 수 있도록 정리하고, 키보드를 두드리면서 글로 쓰기 시작했다.

생각보다 회사는 애자일을 따르며 일하지 않는다. 허울뿐인 스프린트, 회고 를 진행하는 조직이 파다하다. 제대로 된 애자일을 한 번이라도 겪어본 내가 운이 좋았던 거고, 나처럼 운이 좋지 않은 사람이 대다수임을 안다. 그래서 운이라도 좋았던 내가 경험한 애자일과 내가 이해한 애자일을 좀 더 쉽게 풀어서 이야기하고 싶었다. 알려주고 싶었다.

애자일을 대충 알고 있는 당신을 위해서.