Blog

스크럼이다 린 소프트웨어 개발이다 말이 많은데, Agile Software Development with Scrum 역시 이런 관심을 등 엎고 나온 책이다. 책의 목차를 보면 큰 줄기가 눈에 들어오는데, 스크럼을 처음 배우려는 사람에게 무난하다. 무엇을 준비하고 무엇을 실천해야 하는지, 그 이론적 또는 경험적 배경은 무엇인지, 실제로 적용한 사례는 어떤 게 있는지 하나씩 알려준다.

1. 스크럼을 시작하며

2. 스크럼 준비

3. 스크럼의 실천법

4. 스크럼 적용하기

5. 왜 스크럼인가?

6. 왜 스크럼은 통할까?

7. 스크럼 적용 고급편

8. 스크럼과 조직

9. 스크럼의 가치

책이나 프로젝트를 통해 다양한 개발방법론을 접한 사람에겐 다소 가벼운 이야기가 될테고, 그렇지 않은 사람에겐 좋은 길잡이가 될 것이다. 사실, 번역서 중에 스크럼을 쉽게 설명한 책이 거의 없으니 나름 의의가 큰 크다. 하지만 내겐 너무나 익숙한 이야기였고, 딱히 새로운 지식을 얻진 못했다. 다만, 오랜만에 내가 하는 일을 돌아보고 새삼 느끼는 점이 많았다. 그러니 개발방법론을 잘 모르는 독자에겐 미안하지만, 책의 소개보다는 내가 느낀 점을 위주로 독후감을 쓸 생각이다.

1장

인디비쥬얼 사의 스크럼에서 가장 인상 깊었던 점은 스크럼을 시작하면서부터 한 주에 여덟 시간이나 하던 고위 임원들의 회의를 없애버렸다는 사실이다.

스크럼만의 이야기는 아니다. 흔히 익스트림 프로그래밍 같은 애자일 방법론을 생각할 때 귀찮은 문서화나 회의를 없애고 개발자를 위한 환경을 구축한다고 생각한다. 그러나 내가 생각하기엔 피드백이야 말로 소프트웨어 개발의 승패를 쥔다. 애자일 방법론이란 결국 피드백을 빨리 주고 받는 환경을 만드는 것이다. 그래서 애자일을 하면 회의가 없어지는 게 아니고 되려 많아진다(문서화는 줄어든다고 봐야 한다). 일일 스크럼 회의가 좋은 예이다. 15분 가량 매일 같이 회의를 한다. 회의 주기를 줄여서 의사소통의 공백을 줄인다. 사람들은 회의하길 꺼려한다. 한번 할 때마다 별 이야기도 아닌데 30분, 1시간, 또는 몇 시간을 붙잡히기 때문이다. 그러나 이는 회의 자체의 문제라 보기 힘들다. 회의가 길어지는 이유야 많지만, 무엇보다도 한꺼번에 많은 이야기를 하기 때문에 그런 탓이 크다. 할 이야기가 많다 보니 한번에 한 주제에 집중하지 못하고 이 이야기했다 저 이야기했다 한다. 그러니 되려 자주 함으로써 회의의 필요성을 줄이겠다는 역발상이 힘을 발휘한다.

스크럼에선 제품 백로그와 일일 스크럼 회의을 특히 중요시한다. 용어가 어려워서 그렇지 사실 둘다 경량화된 방법론에선 하나 같이 강조하는 부분이다. 일일 스크럼은 앞서 다뤘고, 제품 백로그는 우선순위를 정해 일하자는 이야기일 뿐이다. 이게 참 기본이면서 하나 같이 제대로 못하는 부분이다. 능력있는 관리자 밑에서 일을 배웠거나 스스로 일하는 법을 익힌 일부 사람만 이렇게 일한다. 그러나 문제는 개인의 능력이 좋고 나쁘냐란 게 아니고, 이러한 프로세스를 신입사원조차 당연하게 받아들이는 환경과 체계를 구축하는 것이다. 스크럼과 같은 애자일 방법론에선 이런 체계를 잦은 피드백과 검토를 통해 내재화할 수 있다고 주장한다. 이렇게 자연스럽게 도입된다면 좋은 일이다.

우선순위와 일일 회의는 어렵지 않은 개념이라 실천하기 쉽지만, 알다시피 이론적으로 쉽다는 이야기고 막상 조직에 도입하려면 문제가 많다. 자신이 막강한 권한을 가진 관리자면 모를까 팀 구성원 중 한명일 뿐일 때, 익숙치 않은 무언가를 해보자고 설득하고 끈기있게 실천해나가기란 쉽지 않다. 도입 과정에서 문제가 생기면 다음번엔 더 보수적으로 반응하기 때문에 미래를 위해서라도 신중해야 한다. 단순히 내일부턴 일일 회의를 합시다!라고 의욕찬 발언을 한다고 될 문제가 아니다. 결국, 더 나은 방법이 있다는 사실을 공부해서 아는 게 시작이고, 이를 현명하게 실천해나가는 게 그 다음이다. 그러고 나서 비로소 어떻게 하면 더 잘 할까?를 고민해야 한다.

소프트웨어 프로젝트에 대해 책을 십여권 넘게 읽었지만 여태 일일 회의조차 도입 못했던 게 사실이다. 이제사 이런 제도를 정착시키려 하는 중이고 성공 여부는 한참 지나봐야 알겠다.

팀 소유권

익스트림 프로그래밍엔 코드 공동소유권(Collective Code Ownership)이란 개념이 있다. 간단히 말해 이건 내가 짠 코드니까 넌 건드리지마!란 태도를 배척하자는 이야기다. 부분 최적화가 아닌 전체 최적화를 강조하는 사례인데, 결국 프로젝트와 팀의 성공을 위해 어떠한 제한도 두지 않고 열린 마음으로 협력하겠단 선언이다. 스크럼 역시 이러한 태도가 필수적이다.

팀의 모든 사람은 스프린트 목표 달성에 필요한 것이라면 무엇이든지 가리지 않고 하고

일전에 영문 블로그에 밝힌 적이 있지만, 경력이 1년, 2년, 해를 거듭해갈수록 소프트웨어 개발 현장의 좋은 점과 나쁜 점을 많이 알게 된다. 개인의 관점에서 보면 소스 코드를 자신의 소유물로 여기는 사람이 생각보다 많다는 사실이 나쁜 점 중 하나다. 무척 놀라운 일이지만 정말 그렇다. 이런 현상의 배경엔 사람을 쉽게 대체가능한 기계 부품 정도로 여기는 경영진들의 횡포가 있지만, 환경이 바뀌거나 개선된 다음에도(그러니까 이직한 이후에도) 자신의 방어 기제를 버리지 못하는 게 문제다. 다행히 나는 이런 사람과 함께 일하지 않지만, 만약 그런 사람이 포함된 팀이라면 어떻게 일해야 할까 무척 고민된다.

경험해보니 팀 단위 인센티브를 도입하더라도 내가 아닌 팀 중심적 사고를 이끌어내기가 쉽지 않다. 솔직히 팀 단위 인센티브란 것도 대체로 보면 그 안에서 공을 평가하기 때문에 문제다. 보통 일한 만큼 받는 게 당연하다고 생각하기 쉽지만, 그리고 나도 그렇게 생각했지만, 전체 최적화를 방해하는 요소가 되기 마련이라 비판하는 사람이 생각보다 많다. 팀 내에선 인센티브 폭을 작아야 난 내 할 일만 잘하면 돼라는 태도가 없어진다.

어쨌건 간에 저 단순한 한마디, 팀의 모든 사람은 스프린트 목표 달성에 필요한 것이라면 무엇이든지 가리지 않고 한다가 말처럼 쉽진 않다.

거창한 방법론

나는 방법론이 하라는 대로 다 했어. 분명 개발자가 방법론이 지시한 내용을 제대로 하지 않았을 거야.

이런 말하는 컨설턴트나 프로젝트 관리자가 많고 고충을 이해하지만, 이런 생각도 해봐야 하지 않을까? 방법론 자체가 글러먹은 건 아닐까? 애당초 모든 사람이 방법론의 세부사항을 하나하나 숙지하고 따라하리란 가정 자체가 웃기다고 생각한다. 그럴 능력이 되는 사람들이 왜 자신들만의 방법론을 안 만들고 여러분이 제안하는 방법론을 따를지 한번쯤 생각해봐야 한다. 무턱대고 이게 옳은 방법이니까 무조건 따라야 해라고 했다가 결과가 신통찮으면 저자가 말한 것처럼 상황은 악화되기 때문이다.

죄책감에 이어 무관심이 생기기 시작한다. 최선을 다했음에도 불구하고 계속해서 기대를 만족시키지 못한 작업자들은 결국 최선을 다하지 않게 된다.

마치는 글

비슷한 내용이라도 내 업무, 그러니까 소프트웨어 개발과 관련된 책이라면 가리지 않고 여러 번 읽는다. 뭐야, 다 아는 이야기잖아!, 별 것 없네!라고 말할 정도가 되려면 그만한 경험과 지식을 체득해야 한다. 단순히 안다는 정도론 부족하다. 스크럼에서 딱히 새로운 지식을 얻진 못했지만, 지식과 경험을 서로 대조해보고 배우고 느낀 점이 많다. 그러나 한번에 너무 많은 이야기를 하자니 긴장감이 떨어져서 다음번에 불확실성과 화해하는 프로젝트 추정과 계획을 소개할 때 나머지도 풀어볼 생각이다.

• Author Details

Author Details

최 재훈

Kubernetes, DevSecOps, AWS, 클라우드 보안, 클라우드 비용관리, SaaS 의 활용과 내재화 등 소프트웨어 개발 전반에 도움이 필요하다면 도움을 요청하세요. 지인이라면 가볍게 도와드리겠습니다. 전문적인 도움이 필요하다면 저의 현업에 방해가 되지 않는 선에서 협의가능합니다.

https://twitter.com/andromedarabbit

plaintext@andromedarabbit.net