[독서 리뷰] 클린 애자일을 읽고나서..

'로버트 C.마틴'의 저서 '클린 애자일'을 1독 후 느낀점을 기록한다.

독서 개요

일시

23.12.09(토) - 23.12.23(토)

읽게된 배경

대기업에 재직하면서 애자일에 대한 잘못된 인식이 가져다 주는 악역향을 지켜보게 되었다. 특정 조직의 사람들은 애자일이 단순히 “변화를 수용하여 빠르게 고객에게 다가간다”로만 인식되고 있다는 것을 느꼈다. 이러한 인식의 문제를 느끼고, 잘못된 것이라 알리고 싶었다. 그러나 내겐 힘이 없기에 똑똑해지기로 했다. 어떤 질문이나 비판이 들어와도 설득력있는 근거와 기술력으로 뒷받침해야겠다는 생각이 들었다. 잘못된 것이 잘못된 것임을 알아야 한다. 결론적으로는 애자일이 무엇인지를 설득하기 위해 책을 읽게 되었다.

느낀점

생각의 전환

나는 대학 때 부터 ‘모던 애자일’이라는 개발자 동아리를 설립하고 대표로서 3-4년 째 운영해오고 있다. 이러한 환경 덕분에 애자일에 대한 고찰을 많이 할 수 있었다. 여러 개발자 대회에서도 수상해보고, 창업을 준비해보면서 글로벌 시장에서 일 잘하는 대표로 인정도 받아보고, Coex 박람회에서 ‘스마트 인재’로 강연도 해보았다. 이런 여러 과정에서 스크럼, 칸반, 익스트림 프로그래밍, 스탠드 미팅 등 애자일을 달성하기 위한 여러 방법론들을 지켜보며 경험하고 학습하게 되었다. 전문적인 학습이 있었다고는 자신하기 어렵지만, 아무튼 그랬다.

내가 아는 것과 달랐다.
여러 애자일하다는 조직에서 몇 번 프로젝트를 리딩해보면서 애자일이 무엇이다라는 개념이 잡히게 되었다. 애자일을 가르치는 두 회사에게 가르침도 받았었다. 그러나 놀랍게도 애자일은 내가 아는 것과 달랐고, 우리들이 아는 것과 달랐다.

애자일은 “소프트웨어의 개발 철학”이다.

굉장히 많은 기업에서 애자일을 도입하여 사용한다. 뭔지도 모르면서 ‘빠르고 기민한’ 이라는 이름 덕인지 개나 소나 다 애자일해야한다고 주장한다. 애자일이 사용되는 목적이 “소프트웨어”에 초점이 맞춰져있지 않은 것이 문제다. 우리가 놓쳐선 안되는 게 애자일 선언을 만든 17인은 ‘소프트웨어 개발 전문가’다. 그들은 소프트웨어가 고객이 원하는 방향대로 개발이 될 수 있도록 애자일을 내놓았다.

일하는 방법 보다 중요한 것은 기술 실천 방법이다.

애자일하게 일 한다는 것이 서로 소통을 많이하고, 피드백을 많이 하면 되는 줄 알았다. 가장 중요한 것은 기술 실천 방법이다. 클린 애자일이나, 클린 소프트웨어, 클린 코더 등 애자일 선언을 만든 첫 주동자 ‘로버트 C. 마틴’의 책들을 보면 가장 많이 등장하는 단어이자 기술은 “테스트”이다. 테스트 코드가 없으면 그 조직은 애자일할 수 없다. 애자일하지 않다는 것이 아니고, 애자일 할 수 조차 없다는 것이다. 이유는 책을 통해 확인하길 바란다. 간단히 말하면 아래와 같다.

고객의 요구사항은 지금도 바꼈다.

고객의 요구사항은 지금도 바꼈고, 계속 수도 없이 바뀔 것이다. 이에 대해 대응할 수 있어야한다. 개발자가 고객의 요구사항을 백번 천번 수용하여 프로젝트에 반영해준다고해서 애자일한 것일까. 그렇지 않다. 고객이 A를 요구하였고 개발자가 이를 수용하여 개발하는데 1년이 걸렸다고 해보자. 1년 뒤에는 이미 요구사항이 백번은 바꼈을 것이다. 요점은 고객의 요구사항을 빠르게 반영해 줄 수 있어야 한다는 것이다. 그러한 환경을 개발자는 마련해두어야 한다. 그런 환경을 갖추기 위한 노력들이 지금의 devops라고 볼 수 있다. 빌드/배포/테스트 등의 자동화, 코드의 지속적 통합(깃허브), 코드의 빠른 빌드/컴파일, 서버의 컨테이너화(도커, 쿠버네티스) 등등 말이다.

가장 중요한 것은 TDD다.
TDD는 테스트를 의무화하여 모든 기능이 테스트된다는 확신이 있다. 근데 이보다 더 중요한 것은 테스트가 있기에 리펙토링을 할 수가 있다는 것이다. 엄청난 레거시를 수정해야한다는 절망감을 느껴보지 못한 자라면 이에 대해 공감하지 못할 것이다. 자세한 건 책을 통해 살펴보자. (관련하여 지속적으로 포스팅할 예정이다.)

TDD는 테스트 뿐만 아니라 문서화, 설계, 유지보수 등 다양한 효과가 있고 그 효과는 엄청나다. 로버트 C. 마틴은 TDD를 무조건 해야한다고 말하며, 테스트 커버리지는 90~100%를 유지해야한다고 말한다. 자세한 건 책을 통해 살펴보자.

기본으로 돌아가자.

클린 애자일의 표지를 보면 “Back to basic”이라는 문구가 보인다. 클린 애자일은 2019년에 쓰인 책이다. 로버트 C. 마틴 저자는 2001년에 애자일 선언을 공개하고 시간이 흐르면서 세상이 애자일을 대하는 태도가 어떤지 지켜봐왔다. 세상은 애자일을 “빠르게 빠르게”에만 초점을 맞췄고, 이는 오히려 소프트웨어를 더 엉망으로 만들게 되었다는 사실을 마주했다.

프로젝트에는 마감일이 있기 마련이다. 마감일에 쫒겨 소프트웨어를 개발하다보면 테스트 코드는 무슨, 함수건 클래스건 변수건 아무 곳에도 흩뿌려 놓게 된다. 결국 소프트웨어의 품질은 엉망이되고 에러는 넘쳐난다. 이미 엉망이 된 소프트웨어는 작은 오류 하나를 수정하는데도 일주일, 한달이 걸리게 된다. 기존에는 하루면 추가했던 작은 기능이, 이제는 한달이 걸리고 두달이 걸리게 된다.

위와 같은 헤프닝이 없게하기 위해서는 프로젝트에 마감일을 없애면 될까? 그럴 순 없다. 언젠간 프로젝트를 고객에게 공개해야 한다. 그럼 프로젝트의 기간을 엄청 길게 잡으면 되는 것일까? 그러다가는 고객의 빠른 요구사항 변화에 발맞출 수 없다. 어떻게 해야할까?

요구사항의 우선 순위 별로 개발하고, 반복 주기(미팅) 별로 릴리즈되어야 한다. 이것 말고도 지켜야 할 여러 원칙이 존재한다. 자세한 건 따로 다루겠다.

개발자의 직업 윤리

개발자는 소프트웨어의 품질을 최고로 끌어올릴 권리가 있다. 그 누구도 개발자에게 똥코드를 만드는 한이 있어도 마감일은 지켜야한다고 강요할 순 없다. 개발자는 소프트웨어를 개발하는 사람이다. 똥코드로 개발했다가는 소프트웨어가 금새 망가질 것이라는 걸 안다. 그 누구도 개발자의 직업 윤리를 스스로 무너뜨리게 해서는 안된다.

고객만을 대변한 애자일. 그래서 문제다.

현대의 기업들은 애자일을 도입할 때 “고객의 입장”만 고려해선 안된다. “빠르게 고객의 요구에 대응한다”에만 초점을 맞추다보면 1년 뒤, 2년 뒤에는 고객의 요구에 대응할 수 조차 없는 조직이 되어있을 것이다. 소프트웨어가 소생 불가능하게 엉망이 되었고, 개발자들은 일정에 치이고, 쓰레기 코드에 치여서 퇴사했을테니 말이다.

마무리

애자일은 소프트웨어를 위한 것이다. 소프트웨어를 개발하는 조직이 “품질 좋은 소프트웨어를 빠르게 고객에게 서비스”하는 것을 추구한다. 클린 애자일은 이러한 원칙과 방법들을 책에 담은 아주 엄청난 책이다. 고작 2만원도 안되는 돈으로 소프트웨어 장인의 지식을 배워갈 수 있다는 것이 얼마나 큰 기쁨인가.

못다한 얘기가 너무나 많다. 하나씩 블로그에 포스팅하여 공유할 것이다. 애자일 뿐만이 아닌 여러 분야의 지식들을 학습하며 기록할 예정이다.

우리들이 진정한 애자일의 의미를 되찾고, 진정한 개발자로서의 권리를 누릴 수 있는 그 날까지. 화이팅!!

오늘도 수고했고 잘했다.
든든하고 멋있다.
나는 성공할 수 있다.
나는 천재다. 아자아자.