viewimage.php?id=3dafdf21f7d335ab67b1d1&no=24b0d769e1d32ca73dec84fa11d0283195504478ca9b7677dc322d30c9349b456bc3b617550c054ce48860111a4884e51aac4dcd516575700708ab125649cc1078201dcdc7a32f

왜 우리가 읽는 [테스트 주도 개발] [클린 코드] [실용주의 프로그래머] 같은 책을 쓴 사람들은 다 애자일 애자일 하는 걸까?


애자일이 좋네 안 좋네 떠드는 사람은 많지만, 정확히 뭔지 아는 사람은 드물다. 너도나도 4차 산업혁명 떠들듯이, 애자일하지 못하게 애자일 흉내만 내면서 망하는 회사도 많으니까.



이 이야기는 클린 코드로 유명한 로버트 C 마틴의 [클린 소프트웨어 Agile Softwar Development] 부록에 나온다.


왼쪽이 폭포수 회사와 오른쪽이 애자일 회사를 비교한 이야기인데. Agile에 대한 책인 만큼, 폭포수 회사를 풍자하는 내용이다.


저자가 컨설턴트인 만큼 실제로 여러 회사들의 사례를 섞어서 만들었다. 하지만 실화는 아니고, 편파적인 면이 있으니까. 알아서 걸러서 읽어보도록 하자.


저작권이 있으니까, 대충 요약해서 옮겨본다. [클린 소프트웨어] 책을 사서 보면 더 자세하고, 유머 코드가 재미있다. 이상적인? 애자일 회사도 여러 갈등과 협상... 끝에 결과물이 나온다는 게 포인트랄까.


(끔찍한) 폭포수 회사

폭포수 회사는 상사의 상사에 의해 일방적으로 프로젝트를 시작한다. 요구사항 문서는 나오지도 않았는데, 설계와 분석에 얼마나 걸리는지 일정을 정하라고 다그친다. 결국 상사는 분석과 설계 마감일을 그냥 정해버린다. 4월 1일, 7월 1일까지 끝내도록!


마감을 맞추려고 발버둥치지만 변덕스럽게 요구사항이 새로 바뀔 때마다, 유즈케이스 문서를 수정하고 다시 만들고 통합하려다 보니 159페이지가 넘어간다. 결국 분석 마감일인 4월 1일이 되었지만... 분석은 끝나지 않는다.


기적이 일어난다. 그냥 분석이 끝났다고 치고, 일단 설계를 해야한다는 것이지.


설계를 시작한다. 설계 문서에서 코드 레벨까지, 버튼 하나까지 다 적어놓고 계약서를 써야한다는데. "그렇게 세부적으로 작업할 거면 왜 그냥 코드를 쓰면 안 되죠?" "그건 설계 작업이 아니지 않나!"


그래서 열심히 다이어그램 그리러 간다. 버튼 하나, 창 하나까지 다이어그램을 그리다보니... 문서가 매우 복잡하고 읽기 어려워진다. 마케팅 부 사람들은 요구사항을 또 새로 바꿔서 가져오는데, 다시 분석하고 설계를 또 뒤엎어야할 판이다.


또 설계 마감일인 7월 1일이 되고 어떻게든 그냥 코딩을 시작한다. 새로 도입한 라이브러리와 특수 문법이 편리하긴 한데... 구조가 너무 달라져서, 다이어그램을 모두 다시 그려야할 판이다. 회사에는 코드 라인 수에 따라 올라가는 빨간색 온도계를 만드는데. 눈에 보이는 라인 수 실적을 내기 위해서 라인 길이를 줄이고, 주석으로 코드를 부풀리라는 지시가 내려온다.


그러다 코드가 계획인 100만 라인보다 긴, 120만이 나오자. 상부는 예산을 초과한 이유를 보고하라며 보고서를 쓰게 된다. 결국 20% 이상 코드 길이를 감축하기 위해 주석을 지우기 시작한다.


11월 1일까지 코드를 완성해야하는데, 요구사항의 50%도 구현하지 못했다. 12월은 커녕 3월까지 완성할 수 있을지도 미지수다.


결국 크런치 야근에 들어가지만, 누구는 그만둬버리지 않나. 이직률이 급상승하고, 주 65시간 근무가 일상이 된다. 결국 3월이 되서야 초기 버전을 내놓지만... 버그 투성이다.


결국 옆짚 Rupert 회사가 만들었다는 신작 프로그램 라이선스를 사서 처리하기로 한다. "마케팅 부서 사람들은 만족하고 당신은 해고된다"


(이상적인) 애자일 회사

바로 그 Rupert회사다.


마케팅 담당자 제이가 이런저런 아이디어를 제시하면, 프로그래머 팀장 로버트는 여러 해결책을 제시한다. 계속 논의하면서 사용자 스토리User Story 카드를 쓴다.


어느 정도 방향이 정해지면 팀원들과 다시 제이를 만난다. 사용자 스토리를 구체적으로 테스트할 수 있게 작은 단위로 쪼갠다. 대강 얼마나 시간이 걸릴지 다 같이 카드마다 점수를 매긴다. (프로젝트 추정) 어려운 일은 5점, 쉬운 일은 1점 같은 식.


제이는 요구사항 카드 중에 50점 어치 분량을 고르고, "지난 프로젝트를 보면 50점 분량의 작업은 3주 만에 끝냈더군요." 개발자 로버트씨는 새로운 프로젝트라 3주는 좀 무리라고 생각하지만 팀원들과 이미 이야기도 했고, 해볼만하다고 생각해서 받아들인다.


"단, 이야기 예측과 속도는 이 시점에서 아직 시험적일 뿐인 것이라는 사실을 기억해주세요." "작업 계획을 세우고 구현해보면 더 정확히 알 수 있을 것 같습니다."


팀원들에게 돌아가서 작업을 분배한다. 각자 지난 경험을 토대로 자기 스케쥴에 맞게 자원해서 작업을 가져간다.


하지만 작업이 남는다. 이건 누가하지? 로버트씨는 야근을 하면 버그가 많아지고 생산성이 떨어진다는 걸 안다. 결국 당장 필요하지 않은 로그인 기능을 일단 제거하기로 한다. 이런 식으로 당장 꼭 필요하지 않은 작업을 제거해나간다.


로버트씨는 마케팅 담당자 제이를 만나 딜을 하고, 사용자가 프로토타입을 받는 "인수 테스트"가 가능하도록 하겠다고 약속한다.


이제 코딩을 시작한다. 프로그래머 조는 신입 엘모를 데려다놓고 말한다. "나의 어린 제자여. 이제 자네는 테스트를 우선적으로 하는 설계 방법을 배우게 될 것이다."


각자 테스트를 만들고 작업을 해나간다. 짝 프로그래밍을 하면서 전체 코드의 개발 방향을 서로 공유한다. 지속적으로 코드를 통합하면서, 빠르게 에러를 잡는다. 코드를 리팩토링하면서 유지보수가 쉽도록 구조를 개선해나간다.


하지만 속도는 생각보다 느리다. 제이에게 1주차 데모를 보여주자 만족하는 듯하면서도 "이건 계획보다 느린 것 같은데요?"

로버트씨는 다시 한 번 협상을 한다. 정말 중요한 것만 남기고 몇 개를 또 포기하는 게 좋겠다는 거지.


...


하지만 예상외로 작업은 순조롭게 진행이 된다. 첫 3주가 끝나고 데모는 성공을 거둔다.


그 후로 다시 6주. 9주. 12주... 3주 싸이클을 반복하면서 팀의 리듬이 만들어진다. 팀은 작업에 얼마나 시간이 걸릴지 예측하기 쉬워진다. 요구사항은 계속 변덕스럽게 변하지만 당황하진 않는다. 리팩토링을 잘 해놨기 때문에 코드를 수정하고 새로운 기능을 추가하기도 편하다. 인수 테스트를 대비한 스크립트도 자동화해서 테스트가 간편하게 만든다. 팀은 높은 생산성을 가지고 술술 프로그램을 만들어나간다.


3월에 임원들을 대상으로, 6월에는 전시회에 데모를 출품한다, 몇몇 기능이 빠진 걸 알아차리지만 고객들은 전반적으로 만족한다. 팀장 로버트와 마케팅 담당자 제이는 만족스럽게 전시회장을 나오며, 이번 프로젝트는 성공적이었다고 생각한다.


몇 달 후 옆집 회사에서 연락이 온다. 그쪽 회사도 비슷한 프로그램을 만들었는데 프로젝트가 쫄딱 망했다며... 우리 회사 프로그램 라이선스를 사고 싶다는 것이지.


이야기 끝