The Nature of Software Development

📖 The Nature of Software Development

제목만 봐선 다분히 개발 이야기가 주를 이룰 것 같지만 사실 이 책은 애자일에 관한 책이다. 200쪽가량의 짧은 분량으로 예전부터 읽어야지 했었는데 오히려 분량이 짧아선지 언제든 읽을 수 있다는 근거 없는 자신감으로 미뤄 왔던 책이었다. 그렇게 뒷순위로 밀려나 있던 책이었는데 매번 개발과 직접 관련된 도서만 읽다가 보니 환기할 겸, 또 모임에서 주제로 이 책을 다루기로 해서 최근에서야 읽게 되었다.

정리

본질적 방법

이 책에서 하고 싶은 말은 간결합니다. “소프트웨어 개발에는 본질적인 방법이 존재한다. 그 방법은 모두에게 도움을 준다.” 라는 것입니다.

다소 모호하고 추상적인 ‘소프트웨어 개발의 본질적 방법’에 대해 화두를 던지면서 책은 시작된다. 그럼 본질적 방법이 구체적으로 무엇인가 하는 게 이 책의 주제라고 생각하기 쉽지만, 저자는 바로 다음 명확하게 아니라고 밝힌다.

이제 저와 함께 살펴봅시다. 명확한 가치를 자주 배포하는 데 초점을 맞춰 소프트웨어 개발을 더 간결하게 만드는 방법을요. 이 책에서는 본질적인 방법이 정확히 어떤 것이라고 말하지는 않습니다. 다만 우리가 노력한다면 어떻게 조직을 변화시킬 수 있는지 이야기할 뿐이죠.

가치

애자일을 학습하다보면 반복적으로 나오는 키워드가 있다. 바로 가치다. 저자가 정의 내리는 가치란 우리가 추구하고 원하는 것이다. 소프트웨어에서는 피처를 통해 가치를 얻을 수 있으며, 소프트웨어로 시간이나 돈을 절약할 수 있기에 가치는 흔히 돈과 연결된다. 그리고 소프트웨어는 배포하고 사용할 때 비로소 가치를 전달할 수 있다.

모두가 한 번쯤은 겪어 봤을 전통적인 방법으로는 가치 전달이 쉽지 않다. 계속 추가되는 요구사항, 촉박한 일정으로 급하게 개발하여 망가지는 코드, 매번 바뀌는 프로젝트 방향성 등으로 항상 제날짜에 모두가 원하는 피처를 완성한 채 배포한다는 것은 꿈에 가깝다.

그렇다면 굳이 피처 전체가 아니라 가치를 일찍 제공할 수 있는 피처를 먼저 배포한다면? 이 방법대로라면 프로젝트는 성공할 것이다.

작고 가치 있는 피처를 자주 배포할 때 최고의 가치를 얻을 수 있습니다.

피처 단위로 소프트웨어를 배포한다면 최고의 결과를 얻을 수 있다는 것을 꼭 기억하세요.

피처 단위 개발의 이점

작은 피처 단위로 프로젝트를 진행한다면 계획대로 가는지, 얼마나 끝났고 얼마나 빨리 진행 중인지 살펴보기 좋다. 주어진 기간에 얼마나 많은 것을 할 수 있을지 더 쉽게 예측할 수도 있다. 그리고 비즈니스 담당자나 경영진의 요구 사항이 변경돼도 적절하게 대응할 수 있다.

조직 구성

작은 피처 단위로 반복하여 가치를 전달하기 위해선 작은 개발팀을 여럿 구성해야 한다. 물론 각 개발팀이 피처 일부가 아닌 전체를 개발할 수 있는 기술을 가졌는지도 반드시 확인해야 한다.

하지만 알다시피 이렇게 조직하긴 어렵다. 전문가를 적절하게 투입한다고 하더라도 어렵다. 그럼 이제는 훈련이 필요할 때이다. 개발팀에 포함된 학습공동체를 만들어 팀의 선임 기술자가 다른 사람을 전문가로 이끌게끔 한다.

계획

아이젠하워 장군(General Eisenhower)은 이렇게 말했습니다. “계획은 쓸모없을 때가 많습니다. 하지만 동시에 없어서는 안 될 부분입니다.”

늘 계획대로 되진 않더라도 큰 틀에서의 계획은 필요하다. 구체적으로 세부 목록까지 기술해 놓은 너무 세세한 계획은 시간만 낭비하고 혼란만 가중하니 피해야 한다. 또 계획을 세우되, 언제든지 변화를 줄 수 있는 환경을 만들도록 하자.

핵심이 되는 계획 방법은 먼저 개발해야 할 핵심 피처를 추리고 가치가 낮은 피처는 최대한 뒤로 미루어야 하는 것이다. 그리고 커다란 피처를 태스크 단위로 쪼개지 말고 항상 작은 사용자 스토리를 기준으로 개발하자.

업무량은 각팀이 스스로 정해야 한다. 예측하기 힘들다면 가장 최근 주기의 작업량을 기준으로 업무량을 계획하면 된다. 추정은 위험하고 무리한 목표는 자멸을 초래한다. 또한 과욕은 금물이다.

모든 피처를 동일한 크기로 잘게 쪼개는 데 능숙해지면 프로젝트를 쉽게 관리할 수 있습니다. 개발에 걸리는 시간을 바로 알 수 있기 때문입니다. 완성돼야 할 일과 미룰 수 있는 일을 구분하여 가장 가치 있는 피처를 먼저 개발함으로써 일정 지연 없이 프로젝트를 성공적으로 끝낼 수 있습니다.

일반적으로 프로젝트 추정은 어긋나기 마련입니다. 추정은 가치가 아닌 비용과 관련된 내용이 대부분이죠. 비용 추정은 중요도를 낮추거나 배제하고 가치에 중점을 두어 성공으로 나아가야만 합니다.

개발

피처를 잘게 쪼개고 가장 높은 가치를 가진 피처를 먼저 개발해야 한다. 이는 반복되어 나오는 내용으로 그만큼 중요하다는 것을 의미한다. 각 주기가 끝나는 시점에서는 소프트웨어의 결함이 없어야 하며 이것만으로는 충분하지 않고 제품이 성장할 때마다 소프트웨어의 설계도 개선해야 한다.

피처를 유연하게 추가하기 위해서는 프로젝트가 시작할 때부터 끝날 때까지 시스템의 기반을 견고하게 유지해야 합니다.

기반은 중요하다. 하지만 기반을 먼저 구성하게 되면 너무 적은 피처로 제품을 배포하게 된다. 그러니 간결하지만 작동하는 버전을 먼저 개발하고 몇 번의 개발 주기로 피처를 개선하자.

프로젝트가 나아갈수록 설계도 계속 변화한다. 그 과정에 여러 실수가 생길 수 있는데 이를 방지하기 위해 테스트해야 한다. 오직 테스트만이 결함을 최소화한다.

설계도 한순간의 결정으로 나빠질 수 있다. 올바르게 유지하려면 지속적으로 설계를 개선해야 한다.

피처 단위로 개발하려면 테스트와 리팩토링을 함께 진행해야 합니다. 이 개발 방법의 본질이 테스트와 리팩토링에 있기 때문이죠. 오늘날까지 이보다 나은 방법은 없습니다.

이 방법은 최고의 품질과 차질 없는 일정, 그리고 정확한 예측을 도와주는 데 가장 잘 알려진 방법이기도 합니다. 테스트와 리팩토링은 피처 단위 개발에서 핵심 도구니까요. 절대 이 둘 없이 피처 단위 개발을 진행해서는 안 됩니다.

조언

우리에게 필요한 정보는 사용자가 선호하는 가치입니다. 이 정보로 무엇을 만들지 결정합니다.

가치를 선택하는 일은 우리가 중요하다고 생각하는 것을 선택하는 일입니다. 가치는 우리가 원하는 것이니까요.

끊임없이 가치에 대해 논한다. 그 가치가 어떤 것인지 스스로나 이해관계자에게 묻고 무엇이 중요한지 왜 중요한지 팀과 함께 고민하며 만들어 나아간다.

이것만은 기억하세요. 항상 가치에 집중할 것, 가치를 기준으로 계획하고 관리할 것, 사용자가 어떤 반응을 보이는지 살펴볼 것. 이렇게 간결하고도 명확한 기준을 기반으로 길을 나아가야 한다는 점 말입니다.

성장하는 개발팀

다니엘 핑크가 쓴 [드라이브]에서, 그는 목적, 자율성, 숙련이 직원의 만족과 제품의 생산성을 이끄는 핵심이라고 설명합니다.

목적은 비즈니스로부터 나오며, 자율성은 팀에게 책임감을 부여하고, 반복적인 개발 주기로 품질을 높이고 기준을 엄격하게 만들면 숙달되어 완벽해질 수 있다.

압박

압박한다면 개발팀은 잘못 돼가는 것을 알면서도 포기합니다. 테스트를 충분히 하지 않죠. 나쁜 코드를 방치합니다. 이 현상은 가치를 떨어뜨리고 가치를 얻는 데 필요한 일정을 지연시킵니다. 그 결과 제품의 가치도 떨어지고 배포도 늦게 되죠.

압박은 최악의 수다. 압박받는다면 보수적이나 방어적으로 일할 수 있다.

여러분이 정말로 빠르게 개발해야 한다면 일정을 지연시키는 원인을 분석하세요. 일반적으로 개개인이 가진 생산성보다는 이쪽이 더 영향력이 큽니다.

팀 생산성에 주목하되, 개개인의 생산성을 높이려면 재촉하지 말고 개개인의 능력을 향상하게 시켜야 한다.

리팩토링

주의: 프로젝트는 일정한 속도를 유지해야 합니다. 일정한 속드는 설계를 항상 깔끔하게 유지해야 나옵니다. 설계를 깔끔하게 하려면 반드시 리팩토링해야 합니다.

코드 품질을 고려치 않는다면 비슷한 난이도의 피처를 개발하는 데 걸리는 시간이 완전히 차이가 나게 된다. 이러한 나쁜 개발은 외부에서 눈치채기 어렵다. 리팩토링은 꾸준히 코드를 개선하기 위한 중요한 방법이며 기존 프로젝트에 적용하려면 그곳을 발견했을 때보다 떠날 때 더 나은 곳이어야 한다는 야영지 규칙을 따르도록 하자. 즉, 피처를 추가할 때마다 주변 코드 위주로 깔끔하게 정리하는 걸로 시작한다. 완벽할 필요는 없다.

후기

가치를 무엇으로 정할 것이며 어떻게 발전시키고 나아갈 것인지가 이 책의 핵심이라 할 수 있다. 하지만 직접적으로 구체적인 것들을 알려주기보단 함께 성장할 수 있는 고민을 던져준다. 그러다 보니 애자일을 시작하기엔 도움이 되나 깊이 있는 수준의 내용으론 구성되어 있지 않아서 많은 걸 기대했다면 실망스러울 수도 있다.

기억에 남는 부분으로는 테스트와 리팩토링이었다. 애자일이라고 해도 테스트나 리팩토링을 제대로 하지 않는 곳들이 많은데 책에서는 반드시 해야 하는 필수적인 핵심 도구라 강조한다. 100퍼센트 공감한다. 설사 애자일이 아니더라도 이 두 방법은 반드시 필요하다. 제아무리 코드 리뷰를 하더라도 올바른 동작을 보장하는 건 결국 테스트이며, 코드의 품질을 개선하여 개발 속도를 결정하게 하는 건 결국 리팩토링이다.

현실에서 애자일은 어떻게 진행되고 있는가? 책에서 이야기하는 것처럼 높은 가치를 우선순위로 평가하며, 압박받지 않고, 정해진 주기로, 제대로 된 방법을 써가며 발전을 도모하고 있을까? 구성원 모두가 이해하고 공감대가 형성되어 있지 않다면 형식적이거나 제자리에 머물러 있을 가능성이 크다.

그런 면에서 이 책은 조직의 모두가 읽는다면 당장의 변화는 아니더라도 큰 틀에서의 방향성은 공유할 수 있을 것이다. 그럼 애자일하게 제대로 시작해보자.