나의 페이스북 계정은 몇개의 개발자 커뮤니티에 가입이 돼 있다. 그 중 하나는 주로 학부생(가끔 중,고등학생 까지)들의 과제 질문이나 인터넷에 떠도는 프로그래밍 관련 밈(meme)들만 넘쳐나는지라 그다지 신경을 쓰지 않고 있었는데, 어느날 무심코 타임라인을 보다가 누군가 해당 커뮤니티에 올린 어떤 책의 부제목이 눈에 확 띄였다.
Back to Basic
음.. 기본으로 돌아간다? 가만히 보니 무려 엉클 밥의 애자일을 다룬 서적이었다. 엉클 밥이라면 약 20여년전 애자일 선언의 주역 아니던가. 심지어 얼마 전 출간된 따끈따끈한 신간. 더 이상 의심할 여지가 없었기에 바로 주문을 때렸(?)다.
폭포수 프로세스
저자는 서두에서, "이 책은 딱딱한 이론을 다룬 학술서가 아닌 저자 본인의 그간 애자일 경험에 대한 '회고록' 이다"라고 밝힌다. 따라서 부제처럼 애자일의 기본부터 A to Z 를 식상하고 고지식하게 나열한 책이 아니다. 또 책의 두께도 생각보다 얇았고 (번역 품질도 굉장히 좋아서) 그만큼 편하게 읽혔다.
그렇다고 내용이 마냥 설렁설렁 흘러가는 것도 아닌, 명확한 근거를 바탕으로 애자일의 구성요소와 실천방법들을 설명한다. 특히나 초반부 애자일의 필요성을 강조하기 위해 일반적인 폭포수 프로세스의 과정들을 이야기하는데, 프로젝트 시작 전 '회의'에 대한 묘사가 그야말로 백미였다. 내용을 다 올릴 수는 없어서, 대충 요약하자면 아래와 같다.
| 5월의 첫날, 부문장이 큰 회의실에 모두를 불러 모았다. "우리는 새로운 프로젝트를 수주했고, 11월1일에 끝날 예정입니다. 이제 일정을 잡아보죠. 프로젝트 분석이 완료되기까지 얼마나 걸릴까요? 만약 두달 이상 걸린다면 프로젝트를 접는게 나을겁니다." 누군가 어이없어 하며 "..두달?" 이라고 중얼거린다. "좋아요! 사실 제 생각에도 그렇습니다. 자, 그러면 설계에는 얼마나 걸릴까요?" 다시한번 충격으로 모두가 말을 잃었다. 11월1일까지 여섯달밖에 남지 않았다. 결론은 자명하다. "두달요..?" 당신이 말한다. "정확해!" 부문장이 활짝 웃는다. "제가 생각한 것과 정말 똑같네요. 그러면 구현에는 나머지 두달을 쓰면 되겠군요. 모두들 회의하느라 수고 많았습니다." |
이 '회의'에 대한 묘사 이후에 전형적인 폭포수 프로세스에 따른 분석, 설계, 구현 그리고 죽음의행진(..) 단계를 순서대로 이야기하는데, 재미는 있었지만 마치 한편의 블랙코미디와 같아 씁쓸할 수 밖에 없었다. 일부러 과장한 이야기라며 저자 스스로 밝힌 것 치고는 너무 많은 부분에서 공감이 되었기에.
뚜렷한 근거없이 프로젝트의 일정을 박는다. 어찌저찌 분석과 설계를 마치지만 그 동안 빠르게 변하는 세상과 함께 고객들과 이해관계자들의 요구사항 또한 쉴새 없이 바뀐다. 프로젝트 전반기에 했던 분석들은 보기좋게 물거품이 되고, 일정은 늘어진다. 쉼없는 야근, 위로부터 오는 압박에 품질과 생산성은 바닥으로 떨어진다. 당초 계획했던 일정의 거의 두배의 가까운 시간을 들여 간신히 너덜너덜하게 돌아가(긴하)는 결과물을 만든다. 그리고는 "아, 다음엔 더 잘해야지" 라는 다짐을 한다.
"우리는 될 리가 없는 일을 계속 하려고 한다. 그것도 아주 많이 하려고 한다"
애자일과 데이터
저자는 이러한 폭포수 프로세스의 문제점을 통해 독자로 하여금 그 다음에 이야기할 애자일에 대한 관심과 기대를 증폭시킨다.
애자일이란 무엇일까? 그리고 책의 부제에서 말하는 그 기본은 무엇일까? 물론, 당연히, 애석하게도 한 단어나 한 문장으로 설명하는 것은 불가능하다. 하지만 개인적으로, 이 책을 읽고 나서 가장 머릿속의 남는 것은 다름아닌 데이터였다.
"애자일은 데이터를 만든다"
애자일에서 말하는 '스토리'는 소프트웨어 기능을 사용자 관점에서 간략하게 설명한 것이다. 이를 반복주기(iteration)를 시작하는 시점에 계획회의(Planning Meeting)을 통해 정의하고 '스토리 포인트'를 산정한다. 이 포인트를 시간 단위나 하루 단위로 오해하는 경우가 많은데 그렇지 않다. 포인트의 의미는 '노력'의 단위이며, 이 말이 난해하다면 차라리 '난이도'라고 이해하는게 쉬울 것 같다. 결과적으로 반복주기(보통은 2주)동안 작업할 스토리들과 스토리 포인트의 총합을 추정하게 된다.
사실 이 세상에 '은탄환'은 없다. 한껏 기대에 부풀어 애자일 프로세스의 '0번째 반복주기'를 시작하지만, 그리 녹록치 않다. 계획회의때 정의한 스토리 이외에 예기치 않았던 작업들이 끼어들고, 그만큼 스토리 포인트는 늘어난다. 반복주기가 거의 끝나갈 무렵에도, 목표로 했던 포인트는 모두 처리되지 못하고 있다. 그렇게 불완전한 '0번째 반복주기'가 끝나버린다.
여기까지 보면 애자일마저 실패한 것으로 생각될 수 있다. 하지만 진가는 그 이후에 점점 발휘된다. 애자일 팀은 이제 데이터를 가지고 있다. 지난번 반복주기때 처음 추정했었던 포인트. 중간에 난입(?)한 스토리에 의한 포인트, 반복주기 동안 실제 처리된 포인트 등등. 이것은 흔히 번 다운 차트(Burn Down Chart)로 표현된다.
이러한 데이터들은 그 다음 계획 회의때 활용된다. 물론 '1번째 반복주기' 도 완벽하진 못할 것이다. 하지만 반복주기를 거듭하며 데이터는 축척되고, 반복주기 안에 처리할 수 있는 스토리 포인트는 더욱 더 합리적으로 추정 된다.
또 하나의 중요한 차트가 있는데, 속도(Velocity) 차트가 그것이다. 이것은 매 반복주기마다 팀이 얼마나 스토리 포인트를 처리했는지에대한 경향을 보여준다.
위 차트를 보면 팀이 반복주기내에 평균적으로 150~160포인트를 처리하고 있다는 것을 금방 알 수 있다. 이 또한 아주 중요한 데이터이며, 팀의 생산성에 대해 강력한 레퍼런스를 제공해준다.
저자는 이렇게 애자일에서 중요하게 여겨지는 차트에 대해 자세히 설명하지만, 아래와 같은 말로 본질을 다시 되짚으며 해당 챕터를 마무리한다.
"진짜로 필요한 것은 차트가 아니다. 진짜 필요한 것은 데이터다."
실천 방법
계획회의를 통해 갖은 스토리를 도출하고, 스토리 포인트를 산정하여 반복주기를 설계한다. 매 반복주기를 거듭하며 쌓이는 데이터를 통해 팀의 생산성을 관리, 개선하며 제품을 완성시켜 나간다.
이것만이 애자일의 전부는 당연히 아니다. '기본으로 돌아가는' 책의 의도에 맞게, 저자는 거듭되는 반복주기 안에서 진행해야할 애자일의 수많은 실천 과제들의 기본을 간단 명료하면서도 심도있게 다룬다. 다만 이것들은 우리 모두가 아는 내용일 것이다. TDD, 코드리뷰, 리팩토링, 짝 프로그래밍, 코드의 공유, 지속적인 통합과 배포, 테스트 자동화, 문서화, 효과적이고 다양한 도구의 사용, 그리고 장인정신. 다들 알고 있거나 적어도 한번쯤은 들어본 것들이 아닌가. 하지만 아는것과 행하는 것은 다르다. 불행하게도 우리는 대부분의 실천과제들을 제대로 하지 못한다. 저자는 그 이유를 아래와 같이 말한다.
"용기와 무모함은 다르다. 최소한의 기능만 배포하려면 용기가 필요하다. 높은코드 품질과 수준 높은 규칙을 지켜나가는 데에도 용기가 필요하다. (.. 중략 ..) 높은 품질과 수준높은 규칙을 지켜야 속도가 빨라질 것이라는 믿음은 용기있는 믿음이다. 권력을 쥔 조금 모자란 사람들이 급한 상황이 생길 때 마다 끊임 없이 어깃장을 높을 것이기 때문이다."
"절대, 절대, 절대, 짝 프로그래밍을 해도 되는지 허락받지 말라. 아니면 테스트를 해도 되는지, 리팩터링을 해도 되는지 등등..."
애자일을 도입하는 것은 쉽지않다. 더더군다나 그것에 공감하는 것이 집단이 아닌 개인 뿐이라면, 더 어려워 진다. 이 때문에 '용기'를 언급한 것으로 보였다.
용기를 가질 수 있는 방법은 무엇일까. 개인적으로 곰곰히 생각해보니, 그것은 바로 믿음이었다. 기독교 역사에서 수많은 순교자들의 죽기를 각오한 용기는 신에 대한 믿음으로부터 나왔다. 중동의 테러리스트들은 이슬람교 낙원에 대한 믿음으로 (무모하고 악랄하지만) 폭탄을 몸에 지니고 다닌다. 믿음만 있으면 그 무엇도 두렵지 않았던 것이다.
TDD와 리팩토링을 수련하면 변경과 확장에 용이한 코드를 만들 수 있다는 믿음. 코드리뷰가 더 나은 코드를 가져다 준다는 믿음. 테스트 자동화가 QA들로 하여금 더 창의적인 활동을 통해 품질을 관리할 수 있게 한다는 믿음. 지속적인 통합을 통해 실패를 빨리 발견하고(Fail Fast) 조치함으로써 코드베이스를 더 안정적으로 운영할 수 있다는 믿음. '소프트웨어 장인정신'을 통해 함께 성장하고, 그 결과물을 통해 이 세계를 더 나은 곳으로 만들 수 있다는 믿음.
이러한 믿음이 있다면 그 대상이 개인이든, 팀이든, 조직이든, 애자일의 가치를 더욱 더 확신에 찬 목소리로 전달할 수 있을 것이다. 그러고 보니 더 좋은 소프트웨어, 더 좋은 개발 프로세스를 위해 우리 모두는 전도사(Evangelist)가 되어야 하는 것은 아닐까?
마치며
전 직장이었던 'C'사는 내가 입사하기 전부터 애자일로 유명한 회사였다. 입사하고 보니 확실히 소문대로 였고, 팀의 구성, 스크럼(Scrum)을 하는 방식, 스프린트마다 철저하게 진행되는 계획회의(Planning)와 회고, 정기배포 이외에 끊임 없이 배포되는 제품들... 아마도 직간접으로 보았을때 국내에서 애자일을 가장 타이트하게 하는 조직일 수도 있겠다.
특히 프랑스 출신의 어느 PO(Product Owner)와 일한 적이 있었는데, 'JIRA'의 애자일 도구들을 정말 탁월하게 사용 했었던 것으로 기억한다. 앞서 언급한 번 다운 차트를 매번 스크럼 시간때 공유하여 팀이 어떻게 흘러가고 있는지 파악하게 했었고, 그것을 통해 스프린트마다 생산성을 철저하게 관리했다. 계획 회의땐 플래닝 포커(Planning Poker)까지 사용했다. 나로썬 굉장히 좋은 경험이었고, 그 때문인지 책을 읽으며 그 PO 생각이 많이 났다.
(글을 쓰고 있는 현 시점 기준으로) 지금 내가 있는 곳은 여느 IT 회사가 그렇듯 'JIRA'를 사용하긴 하지만, 애자일의 'ㅇ' 자도 모른다. 그렇다고 전형적인 폭포수 프로세스도 아닌, 그야말로 중구난방 프로세스를 자랑한다. 우리회사를 악의적으로 디스하는 것은 아니다. 이것은 대한민국의 많은 IT 기업과 조직들의 문제이기 때문이다. (그 잘한다는 'C'사도 완벽하진 않으니)
하지만 앞으로 좋은 기회가 생길 것 같다. 내가 속한 조직은 대기업으로부터 특정 사업의 전문회사로 분사를 한다. 당연히 조직도 전면 개편되고, 많은 신규사업들도 진행할 것이다. 현재 나는 그 회사에서 그러한 신규사업을 진행하기로 결정이 되었고, 팀 세팅부터 참여할 것 같다. 이보다 더 좋은 기회가 있겠는가? 굳건한 믿음을 가지고 애자일의 가치를 전도해 봐야겠다. 앞으로 채용될 사람들이 좋은 동료들이길 바랄 뿐이다.
코로나로 점철된 2020년이 가기전에, 우연히 접한 이 책은 'C'사에서의 추억과 더불어 나에게 믿음을 주는 책이었다. 또한 컴퓨터와 인터넷이 지배하는 세상 속의 '개발자'로서 자긍심을 일깨워 주기도 했다. 다가오는 새해, 더 나은 소프트웨어 '장인'이 되어야겠다는 다짐을 하며 장황했던 독후감을 마친다.