애자일이 무엇인가요?
프로그래머가 되고자 하는 분들을 위한 이야기
필자의 지인 중에 잘 알려진 IT출판사에서 근무를 하는 분이 계신다. 출판사에서 일하다보니 출판 기획, 저자 섭외 및 관리(?), 편집이나 교정 작업, 출판 등을 비롯하여 책을 만드는 모든 일을 하고 있는 분이시고, 소프트웨어 개발자는 아니다. (그럴 필요도 없다.) 하지만 개발자들을 아끼고 조금이나마 그들을 이해하고자 프로그래밍을 배우고 있으며, 최근에는 인터넷 방송을 통해 본인의 관점에서 궁금한 소프트웨어 개발 관련 지식을 전달하고 있는 멋진 분이다.
최근에 이 분이 아래의 글을 기고 하였다. 제목은 바로 '도대체 애자일이 뭐에요??' 이다.
https://brunch.co.kr/@pubjinson/6
(현재 삭제된 콘텐츠입니다.)
애자일을 이해하고 알리기 위해 국내 애자일 초고수님들을 모셔놓고 방송을 진행하고 글도 작성하였으나, 필자 생각에는 애자일을 뚜렷하게 이해하기에는 쉽지 않았던 모양이다.
애자일이라는 주제는 다소 이해하기 어려운 것일 수 있으나, 보는 시각에 따라 쉽게 이해 할 수도 있다. 필자는 국내에서 소프트웨어 개발자들이 되고자 하는 분들을 위한 글을 쓰고 있고, 근래에 국내 많은 회사들이 애자일을 활용하고 있기에, 같은 맥락에서 이번 글을 쓰고자 한다. 참고로 필자는 2009년경에 처음 애자일을 접했고, 현재도 작은 규모의 애자일 프로젝트를 수행하고 있다. 직접 애자일 컨설팅을 할 정도로 전문가는 아니나, 꾸준히 관심을 가지고 있고 실제 프로젝트에서도 사용 중이니, 애자일에 대해서 가볍게 이해하는 수준으로 글을 풀어 쓸 수 있을 듯 하다.
그럼, 시작해 보자.
애자일, 애자일 하는데 애자일은 도대체 무엇을 하는 걸까? 새로운 기술인건가? 아니면 무슨 프로그래밍 언어인건가? 왜 요즘에 소프트웨어를 개발하는 곳에서 끊이지 않고 화자가 되는 이 녀석의 정체는 무엇일까?
애자일은 흔히들 '방법론'이라고 얘기 한다. '방법론'이라는 말은 처음 접할 때 쉽게 가슴에 와 닿는 용어는 아닌 듯 싶다. 그렇다면 '프로세스'는 어떤 가? 그저 그렇다. 그냥 쉽게 '일하는 방식' 정도로 생각 해 보자. 애자일은 기존에 소프트웨어 개발을 할 때 사용하던 '구닥다리 일하는 방식'을 오랜 기간에 걸쳐 소프트웨어 제품을 만들어 오던 거장들이 소프트웨어의 소프트 한 면을 살려서 정의 한 일종의 '유연하게 일하는 방식' 이라고 볼 수 있겠다. 애자일이라 용어 자체가 '기만한', '재빠른', '민첩한' 이라는 뜻을 가지고 있는 것을 보았을 때, 이름 하나는 기가 막히다.
그럼 예전에 일하던 구닥다리 방식이 무엇인지, '책을 만드는 과정'을 통해 먼저 살펴 보자.
어떤 저자가 프로그래밍 기술 서적을 쓰기로 마음 먹었다고 가정해보자. 출판사에 저자의 기획안을 제출하고 나면, 출판사는 여러 가지 기준을 통해 저자의 책을 출판하기로 결정한다. 출판하기로 결정이 되면, 저자와 출판사는 계약서에 싸인을 하고 저자는 집필을 시작한다. 서로 약속한 탈고일까지 6개월 정도 걸린다고 하였을 때, 저자는 집필을 하고 출판사는 띄엄 띄엄 프로그레스를 점검하면서 간혹 저자에게 오는 질문과 원고에 대한 조언과 피드백을 준다. 집필을 시작하는 당시에 저자와 출판사가 약속했던 책의 최종 모습에 대한 초안이 있지만, 작성을 하다 보면 처음 계획과는 틀어질 가능성이 있다. 심지어는 제 때 끝내지 못 하는 경우도 허다 하다. 포기 하거나 저자가 잠수 타는 경우도 있다. 초기에 출판사는 저자에게 입문자가 볼 수 있는 쉬운 책을 요구 하였으나 6개월이 지난 후 탈고가 된 전체 글을 읽어 보니 이 책은 입문자가 읽기에는 너무 어렵다. 처음부터 저자와의 커뮤니케이션이 잘 못 된 것이다. 그렇다고 저자에게 문제가 있었던 것일까? 그렇지 않다. 저자 입장에서는 지금 수준이 정말 쉬운 수준이라고 생각 했던 것이 화근이었다. 6개월이 지나서야 출판사와 저자는 다시 고민하게 된다. 이 책을 그대로 출판할 것인가? 아님 다시 쓸 것인가? 그대로 출판하게 되면 난이도로 인해 예상했던 판매 부수보다 훨씬 못 미칠 듯 하다. 다시 쓰게 된다면 지금까지 6개월간의 노력은 물거품이 될 수도 있다.
위에서 생긴 문제의 근본적인 원인은 무엇을까? 몇 가지 생각 해 보자.
1) 저자와 출판사 간의 의견 차이
2) 6개월 후 탈고한 전체 글을 읽기 전 까지는 미완성이고, 내용을 확인 할 수 없었다.
3) 6개월이 지난 후에 문제점이 발견되어 고치려고 하니, 비용이 너무 많이 든다.
4) 그렇다고 그냥 출판하자니 내가 원하던 모습이 아니다.
5) 급하게 고친다고 하더라도 책의 품질은 떨어질 것이다.
6) 만약, 집필 초기에 문제점을 발견 했더라면, 쉽게 수정 할 수 있었을 것이다.
실은 여기서 책을 만드는 과정은 소프트웨어를 만드는 과정과 너무나도 비슷하다. 출판사는 고객이고 저자는 소프트웨어 개발자다. (실제 계약서에는 저자가 갑이고 출판사가 을이긴 하다..ㅡㅡㅋ) 그리고 이렇게 제안 -> 기획 -> 계약 -> 집필 -> 탈고 -> 교정 -> 출판 하는 형태로 순서대로 일이 진행되고 다시 되돌아 갈 수 없는 구조로 일하는 방식을 소프트웨어 세계에서는 폭포수 개발 방식 (Waterfall model)이라고 부른다. 폭포수 개발 방식에서는 일반적으로 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포 형태로 단계적으로 프로젝트가 수행이 된다.
그럼 폭포수 개발 방식을 따르면 모든 소프트웨어 개발 프로젝트가 잘 못 흘러가는가? 꼭, 그렇지만은 않다. 현재 해결하고자 하는 문제점이 무엇인지 명확하고, 솔루션 역시 구체적이라면 해볼만하다. 예를 들어서 100권짜리 백과사전에 있는 모든 내용을 전산화하는 프로젝트가 있다고 가정해보자.1권씩 차례대로 1장 1장 옮기면 된다. 화면이 그리 복잡하지도 않을 것이다. 개발하는 속도 측정도 무척 간단하다. 1페이지 전환하는 시간을 계산하여 전체 페이지수만 곱하면 된다. End image가 너무나도 뚜렷하다. 이런 경우에는 폭포수 개발 방식도 사용이 가능하다.
하지만, 대부분의 소프트웨어 개발은 그렇지가 않다. 위에서 언급하였던 집필하는 과정과 너무나도 비슷하며, 위에서 나열한 문제점들로 인해 실패하는 프로젝트가 너무나도 많다. (반 이상 될 것이다.) 이렇게 실패한 프로젝트에서 흔히들 볼 수 있는 원인은 바로.. '고객의 요구사항 변경' 이다.
대부분의 소프트웨어 개발 프로젝트는 고객의 Needs에 의해 시작된다. 그런데 재미있는 사실은 고객이 본인들이 원하는 것을 잘 표현하지 못한다는 것이다.심지어는 잘 모르는 경우도 많다. 필자는 처음 이것을 깨달았을 때 솔직히 말하자면 어이가 없었다. 왜 본인들이 하고자 한 일인데, 어떻게 잘 모를 수가 있지? 하지만, 곧 이유를 알 수 있었다.
모르는 것이 아니라 소프트웨어가 만들어지는 과정이나 어려움을 잘 모르기 때문에 생기는 문제가 대부분이였다.
가령, 어느 정도 개발이 된 화면을 본 고객이 쓱~ 쳐다보면서 한 마디 거들었다.
"이거.. 레이아웃을 이렇게 좀 바꿔보면 어떨까요?"
개발자는 속으로 이렇게 생각 할 것이다.
'참나.. 처음 부터 그렇게 만들라고 할 것이지..'
개발자가 일주일간 열심히 작업해서 원하는 대로 소스를 수정하여 고객에게 보여주었다. 고객 왈,
"아.. 예전게 더 좋은 거 같아요, 예전 걸로 가시죠?"
개발자의 속마음은 더 이상 쓰지 않더라도 예상하리라 본다.
이런 상황은 실은 비일비재하다. 특히 국내에서는 소프트웨어가 공짜라는 인식이 강한지라 저런 식의 요구사항을 아무렇지도 않게 툭툭 뱉게 마련이다. 해외는 대부분 저럴때 마다 고객이 비용을 지불해야 하고 일정이 지연되기 때문에 섣불리 그렇기 하지도 못하고, 하더라도 철저하게 분석 한 다음에 진행하기 마련이다. 그런데도 불구하고 해외에서도 이런 변덕스러운 고객의 요구사항 변경으로 인하여 실패하는 프로젝트가 빈번하게 발생하게 되었고, 이를 어떻게든 해결하고자 소프트웨어 세계의 거장들이 모여서 선언문을 작성하게 된다. 이것이 바로 2001년에 선언된 '애자일 소프트웨어 개발 선언'이다. (애자일 선언문 본문 링크 : http://agilemanifesto.org/iso/ko/manifesto.html)
자바 테스트 프레임워크인 JUnit으로 유명한 켄트백 아저씨의 저서 '익스트림 프로그래밍' 36페이지를 보면 아래와 같은 내용을 찾을 수 있다.
소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비즈니스도 변한다. 기술도 변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기 때문에, 문제가 되는 것은 변화가 아니다. 그보다는 변화를 극복하지 못하는 우리의 무능력이 문제다.
변화는 반드시 일어나기 때문에 문제가 되는 것은 변화가 아니며, 이를 극복하지 못하고 대응하지 못 하는 우리의 무능력이 문제라고 얘기하고 있다. 그럼 이 변화에 어떻게 하면 민첩하게 (애자일 스럽게) 대응 할 수 있을 까?
이번엔 필자가 책을 한번 애자일 스럽게 써 보겠다고 가정해 보자. 필자는 여러 가지 주제를 두고 어떤 책을 쓸지 고민하고 있다. 헌데, 어떤 책이 출판사나 독자에게 도움이 될지 확신이 서질 않는 다. 그저 '책을 쓰고 싶을 뿐'이다. 그렇다고 긴 시간을 낭비하고 싶지는 않다.
필자는 최근에 브런치라는 글쓰기 플랫폼에 관심이 많았다. 작가로 선정 되어야 만 글을 쓸 수 있는 자격이 주어지고, 인기가 좋으면 책으로 출간도 해준다고 한다. 해서, 필자는 고민 끝에 '소프트웨어 개발자로 취업하기 위해서 필요한 지식' 을 주제로 글을 쓰기로 결정하였다. 잠이 오지 않던 밤, 3시간에 걸쳐서 첫 글을 썼고 필자는 '발행' 버튼을 눌러서 인터넷상에 공개 하였다. 그리고는 잠이 들었다.
아침에 일어나서 스마트폰을 쳐다보니 브런치 앱에서 수 많은 알람이 뜨고 있는 것을 발견 하였다. 발행한지 세 시간만에 천 명 이상이 이 글을 읽었다. 여섯 시간이 지나니 3배로 뛰더니 이 글은 순식간에 만 회 이상 조회에 천 회 이상 공유가 되었다.
필자는 세 시간이라는 짧은 시간에 작성한 단 하나의 온전한 글을 통해 본인이 선택한 주제가 가능성이 있음을 확인 하였다.
이번엔 두 번째 글을 작성 하였다. 첫 번째 글의 후속편으로 조금 더 자세한 정보를 담아서 작성하였다. 어제까지만 하더라도 내가 쓸 글에 관심이 있을까 생각했지만, 가능성을 확인했기에 필자는 기분이 좋아졌다. 두 번째 글은 조금 더 공을 들여서 작성하였고, 발행 하였다. 두 번째 글 역시, 빠른 속도로 공유가 되었고 관심을 끌었다.
헌데, 이번 글에는 한 가지 문제가 있었다. 내용 중 일부가 잘못되었다는 소식을 독자로부터 전달 받았다. 필자는 그로 인해 기존에 잘 못 알고 있던 지식을 바로 잡게 되었고, 아주 쉽게 그 글을 수정하고 다시 '발행' 버튼을 눌렀다. 학습을 했고, 바로 수정했다. 만약, 조기에 발견하지 못 했다면, 추후의 글에도 해당 내용으로 인한 잘 못 된 정보들이 기재될 것이고 필자의 글은 점점 신뢰를 잃을 것이다. 참 다행이다.
이렇게 글을 하나 둘 씩 써 나가다 보니 어느새 많은 분량의 글을 작성하게 되었고, 이를 눈여겨보던 필자의 지인은 이 내용들을 엮어서 책으로 출판하자는 제안을 하게 된다. 필자는 이미 글을 쓴 상태였고, 출판사에서도 내용을 이미 알고 있기 때문에, 책의 내용에 대한 이해의 차이가 거의 없다. 게다가 많은 사람들이 좋아해주고 댓글로 피드백을 준 것을 반영함으로써 어느정도 검증이 되었다. 이 정도면 서로가 원하고 만족하는 책을 성공적으로 출판할 수 있을 것 이다.
이번 경우에 성공적인 출판을 할 수 있었던 이유는 무엇일까?
1) 어떤 책을 쓸지 명확하지 않은 상황에서 짧은 시간에 한 개의 글을 발행하여 독자의 반응을 살펴 보았다.
2) 방향성에 확신을 가진 뒤에는 작업에 더 신중해졌고, 결과물에 대한 자신감이 생겼다.
3) 글에 문제가 있는 경우, 바로 수정하여 재발행 하였다.
4) 이런 즉각적인 대응 덕분에 추후에 발생할 문제를 미연에 방지 하였고, 독자의 신뢰를 잃지 않았다.
5) 1개 단위로 글을 발행하면서 독자의 피드백을 반영하니 독자가 원하는 글이 써지고, 품질이 높아진다.
6) 출판사와 저자사이에 커뮤니케이션 오류는 최소화 될 것이고, 의견의 차이가로 인한 실수는 방지가 된다.
이런식으로 짧은 주기로 고객이 사용 할 수 있는 소프트웨어를 만들어가면서 커뮤니케이션의 비용을 최소화하고 이슈 사항들을 바로 바로 제거하면서 개발하는 방식이 바로 애자일 소프트웨어 개발 방식이다. 예전의 폭포수 개발 방식으로 6개월만에 책을 만들어내던 방식 대신에, 애자일 방식을 활용하여 1주일에 글 하나씩 작성하여 매번 책에 들어갈 내용을 확인 할 수 있었다. 작업의 단위는 훨씬 작아 졌고, 처음에 생각했던 방향성에서 크게 틀어질 가능성을 최소화 하였다. 수정할 필요가 있으면 바로 바로 수정하기 때문에, 비용도 크게 들지 않고 쉽게 수정 할 수가 있다. 이것이 바로 일반적으로 소프트웨어를 개발해 나가는 방식이라는 것이다.
하지만 이러한 애자일 소프트웨어 개발 방식을 마치 퍼즐 맞추기처럼 조각 조각 내서 개발하는 걸로 오해하는 사람들이 있다. 아래 그림을 살펴 보자.
잘못 이해한 사례 (Jaff Patton 님의 User Story Mapping 중)이 그림에서 화가가 5일 동안 '모나리자를 그리세요'라는 요청으로 그림을 그리는 과정을 볼 수 있다. 만약, 이런 식으로 그림을 그리기 시작 한다면, 처음에 필자가 얘기했던 폭포수 모델의 단점과 같이 그림이 완성되기 전 까지 문제점을 발견하기 어렵다. 즉, 5일차가 될 때 까지 이 그림은 미 완성이며, 5일차가 되어야만 전체 그림을 볼 수 있어 근본적으로 잘 못 된 부분에 대해서 조기에 수정할 수 없을 것이다.
그럼 아래 그림을 살펴 보자.
잘 이해한 사례 (Jaff Patton 님의 User Story Mapping 중)화가에게 내려진 요청은 실은 '야외에 있는 여성 초상화를 그려주세요' 라는 것이다. 소프트웨어 개발에 있어 요구사항이라 함은 모나리자와 같이 구체적이 않고, 이렇게 모호한 경우가 많다는 것이다.
그리고 첫 번째 날에 그린 그림을 보자. 부분을 그린 것이 아니라, 전체에 대한 스케치를 그렸다. 이것이 소프트웨어로 따지면 애자일 선언문에서 말하는 '동작하는 소프트웨어'다. 완벽하진 않지만 짧은 시간안에 고객의 요구사항을 증명 할 수 있는 그림을 선보인 것이다. 고객은 이 그림을 보고 여성의 손의 위치와 배경의 산의 비중을 줄여 달라는 피드백을 주었다. 해서 2일차에는 해당 요구사항이 반영이 된 스케치를 확인 함으로써, 최대한 빠른 시일내에 고객과 개발자의 방향성을 바르게 잡아 주었다. 그 뒤에도 점점 진하게 색을 칠해 가면서 작품을 완성한다. 옷이나 머리색 등도 언제든지 변경 될 수 있을 것이다.
지금까지 설명한 것이 바로 애자일의 기초적인 개념이다. 그리고 이런 개념들을 잘 실천 할 수 있도록 만들어 놓은 도구들이 바로 스크럼 (Scrum), 칸반 (Kanban), XP(eXtream Programming), Lean SW Development 등을 들 수 있겠다. 그 중에 가장 흔히 사용하는 도구가 바로 스크럼이다. 혹시 어떤 회사가 스크럼 마스터를 채용한다고 하는 것을 들은 경우도 있을 것이다. 이런 경우, 애자일 방법론 적용을 잘 하기 위한 퍼실리테이터 역할을 하는 롤이 바로 스크럼 마스터이고, 회사에 애자일이 이미 자리 잡았다는 것을 알 수 있다. 스크럼이나 기타 실천 도구들 (이 또한 방법론이다.)에 대해서는 훗날 소개 해 보도록 하겠다. (댓글 요청 환영)
열심히 작성해 보았는데, 처음 의도대로 쉽게 이해 할 수 있는 글이 되었는 지는 의문이다. 이 역시 필자는 초반에 소개한 필자의 지인을 통해 피드백을 받을 것이고, 필자의 글을 읽은 독자 여러분의 댓글을 참조하여 다듬어 나갈 예정이다. 애자일스럽게 말이다.
마지막으로 애자일에 대한 필자의 생각을 끝으로 마무리 하겠다. 애자일은 일하는 방식이며 더 나아가 '문화'가 되어야 한다. 이 기본 사상에는 소프트웨어를 만드는 주체가 바로, '사람'이기 때문이다. 애자일을 잘 못 적용하면 오히려 독이 된다. '문화'가 되어야 할 것을, 개발자를 다그치게 만드는 '채찍질' 로 쓰여진다면, 안 쓴만 못하다. 애자일에 대한 책은 시중에 널렸다. 하지만, 책에 씌여진 대로 적용 하려고만 하면 대부분 실패하기 마련이다. 조직에 맞게 반드시 커스터마이징 되어야 한다. 함께 일하는 개발자들과 즐겁게 일하는 문화를 만들기 위한 도구로 생각해야 한다. 그리고 이러한 '문화'속에서 높은 품질의 제대로 만들어진 소프트웨어 제품이 나올 수 있다.
대한민국의 소프트웨어 개발 문화는 해외에 비해서 많이 뒤쳐지는 것이 사실이다. 개발자들에 대한 대우도 낮다. 소프트웨어에 대한 중요성도 다른 나라에 비해 현저히 떨어진다. 그렇다고 해서 해외로만 나가는 것이 답이라고 하는 것은 아닌 듯 싶다. 우리가 한번 바꿔 볼 수 있지 않을까. 분명, 국내 사정도 점점 좋아지고 있는 것을 필자는 느낄 수 있다. 필자도 필자의 위치에서 노력하고 있다.
같이 노력 해 보자. :)
애자일 관련 글 더 읽기
애자일이 무엇인가요?: https://brunch.co.kr/@insuk/5
애자일을 어떻게 실천하나요? - 스크럼편 (1/2): https://brunch.co.kr/@insuk/13
애자일을 어떻게 실천하나요? - 스크럼편 (2/2): https://brunch.co.kr/@insuk/14
애자일과 린, 그리고 워터폴: https://brunch.co.kr/@insuk/17
애자일 실천 사례 - XP 편: https://brunch.co.kr/@insuk/15
