클린 애자일

2001년 애자일 선언을 만든 17인 중 한 명이자 그 '클린 코드'의 저자인 로버트 C 마틴의 책입니다. 클린 코드(2008), 클린 코더(2011), 클린 소프트웨어(2013), 클린 아키텍쳐(2017), 클린 애자일(2019)이라니 책이 계속 자라고(?) 있습니다. 참고로 본인피셜 다음 책은 클린 장인 정신이라고 하네요. 클린 코드의 원제는 'Clean Code: A Handbook of Agile Software Craftsmanship' 입니다. 수미일관이라고 해야할까요?

 

처음에 신간 소식을 듣고 '에이 뭐 이런 책을 다...' 하는 마음이었지만 팬심으로 일단 읽기 시작했습니다. 비슷한 시기에 팀 동료가 스터디를 제안해서 주 1회씩 토론 시간도 가졌는데, 처음엔 함께 읽는데에 의의가 있겠다 생각했지만 진도가 나갈 수록 토론도 풍성해졌고 여러 가지 생각을 안겨줬습니다. 애자일에 관한 책 속 이야기들 보다는 느낀 점들을 정리해보려고 합니다.

---

애자일의 소개

애자일은 가치 내치는 철학이고, 그를 지키고 따르기 위한 다양한 방법론이 있습니다. 하지만 애자일의 탄생 과정을 살펴보면 방법론이 먼저고 애자일은 그 다음입니다. '경량 프로세스 회담'이라고 이름 붙인 모임에 사람들을 초대했다고 하는데 책에 언급된 명단을 옮기면 이렇습니다.

• 익스트림 프로그래밍: 켄트 벡, 로버트 C 마틴, 제임스 그레닝, 워드 커닝햄, 론 제프리스
• 스크럼: 켄 슈와버, 마이크 비들, 제프 서덜랜드
• 기능 주도 개발(Feature-Driven Development): 존 컨
• 동적 시스템 개발 방법(Dynamic Systems Development Method): 아리 반 벤네쿰
• 크리스털 계열 프로세스(?): 앨리스터 코오번
• 무소속: 앤디 헌트(실용주의 프로그래머), 데이브 토머스(실용주의 프로그래머), 브라이언 매릭(테스트 컨설턴트), 짐 하이스미스(소프트웨어 관리 컨설턴트), 스티브 멜러(모델 주도 철학을 대표) 그리고 마틴 파울러

익스트림 프로그래밍이고 스크럼이고... 애자일이라는 이름이 지어지기 전에 이미 존재하던 방법론들입니다. 회담 분위기가 잘 상상되지 않는데요. 비용, 시간을 누가 댔을리가 없다고 생각해 볼 때, 업계의 경량 프로세스를 대표하는 고급 프로그래머들이 자발적으로 모이면 무슨 대화를 할까요? 회의 방식은? 이틀 동안 하자는 건 누구 아이디어였죠? 모이기 전에 목표가 있었을까요? 페북이 나온 게 몇 년도였죠? 2004년. 사전 커뮤니케이션은 이메일로 했을까요? 회의에 간식은 준비했나요? 저녁 식사 이후에도 회의를 했을까요? 혹시나 해서 물어물어보는건데... 설마 투표 같은 걸 하진 않았겠죠?

 

역사에 이어 애자일이 무엇인가에 대한 설명이 이어지지만, 그 중 좋았던 문장 하나를 인용하겠습니다.

희망을 없애는 것이 애자일의 주요 목표다. 애자일을 실천하면 희망이 프로젝트를 죽이기 전에 희망을 파괴할 수 있다.

 

왜 애자일인가

이번에 스터디를 시작하면서 참여자들에게 애자일란 무엇인지 각자 한 줄로 요약해보고 시작하자는 제안을 해봤습니다. 저는 '불확실성을 일의 일부로 받아들이는 것'이라고 대답했습니다. 지금은 그 뒤에 '그리고 블라블라'를 덧붙여야겠다는 생각이 드는데 아직 문구를 완성하지 못했습니다. 저는 불확실성이 문제의 근원이지만 그건 자연스러운 것이라고 말했으니, 블라블라는 이렇게 개선할 수 있다가 되어야할 것 같습니다.

 

비즈니스 실천 방법 / 팀 실천 방법 / 기술 실천 방법

애자일이 추구하는 가치에 동의한다면 해볼만한 여러 방법들을 카테고리에 따라 설명합니다. 이 방법을 지금 우리 일에 적용할 수 있는 지, 무엇이 어려운 지, 책 속 상황과 우리의 상황이 어디에서 유사하고 어느 부분이 다른 지 토론이 있었습니다. TDD 이야기가 특히 매혹적이었죠.

 

애자일해지기

애자일 방법론이 이야기하는 규칙과 실천 방법만 따른다고 애자일해질 수는 없다는 내용입니다. 이런 저런 실패 사례들이 많이 나오는데다, 그동안 생각해보지 못했던 여러 가지 부분들을 설명하고 있어서 특히 좋았습니다.

어떤 방법론을 택하든 상관없이, 결국에는 프로세스를 당신의 필요에 맞게 고치고 다듬게 될 것이다.

가장 중요한 조언은 전체 생애 주기에 걸쳐 애자일 방법론을 도입하라는 것이다. 특히 기술 실천 방법은 꼭 지켜야 한다. 너무나 많은 팀이 애자일에서 바깥쪽의 비즈니스 부분만 도입한다.

그리고 이 챕터의 핵심 내용은 아니었지만, 개인적으로 '애자일은 소프트웨어에 대한 것이고 작은 소프트웨어팀에 대한 것이다.' 라고 단호하게 말한 부분이 눈에 띄었습니다. 그렇기 때문에 다른 분야 또는 큰 팀에 애자일을 적용하려면 어떻게 해야하는지에 대해선 답변하기 어렵다는 거죠. '큰 팀의 문제는 이미 해결된 문제다.' 화끈하네요.

 

장인 정신

다음 책을 위한 밑거름일까요. 앞 장에서 '애자일은 소프트웨어에 관한 것이다.'라고 했는데, '장인 정신'은 무언가를 만드는 모든 사람들에게 동일하게 요구되는 것 아닌가? '소프트웨어' 장인만을 위한 특별한 점은 어떤 부분일까? 하면서 읽었습니다. 또한 '소프트웨어 장인 정신'이라는 새로운 운동을 소개하는데 우연히 '소프트웨어 장인'을 작년에 읽었었네요. 다시 한 번 읽어보면 더 새로울 것 같습니다.

 

---

다 읽고 나서

이 책을 통해 엉클밥은 애자일해지기 위해 필요한 실천 방법들을 다시 정리했습니다. 이름만 붙이지 않았지 결국 나름의 방법론을 하나 정의한 셈 아닌가 하는 생각이 드는데, 필요에 맞춰 고쳐 써야한다는 당부도 잊지 않았습니다. 몇 몇 애자일 방법론 진영에서 이루어지고 있는 인증이라던가 자격증 같은 것에 대한 냉소도 별로 숨기지 않는 걸 보면, '이 방법들만 따르면 애자일을 적용할 수 있어'라는 방향성에 제동을 걸고 싶었던 게 아닌가 싶습니다. 애자일 방법론으로부터 탄생한 애자일이 이제 애자일 방법론들에게 던지는 경고의 느낌입니다.

 

책을 읽고 나서 이제 더 이상 우리 팀이 어떤 방법론을 따르고 있는지 의식하지 말아야겠다고 생각했습니다. 이 책은 방법론이라는 프랜차이즈를 에둘러서 부정하고, 대신 현재까지 유효하다고 보여진 방법들을 소개하면서 앞으로 더 추가하거나 발전시키라는 요구를 전한 것이라고 봅니다. 비즈니스 실천 방법, 팀 실천 방법, 기술 실천 방법의 카테고리에 맞춰 현재 팀이 사용하고 있는 방법들을 다시 확인하고, 왜 그것들을 도입하게 되었는지, 어떤 맥락을 거쳐서 지금의 모습으로 변형된 것인지 정리해보려고 합니다. 만약 어떤 방법을 변형해서 사용한다면 그 맥락 또한 명시적으로 전파되어야겠다는 생각이 들었습니다.

 

클린 애자일