<div id="readability-page-1" class="page"><section data-astro-cid-4eu74nwj=""> <p><a href="https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=99183703" rel="noopener noreferrer" target="_blank">📖 The Nature of Software Development</a></p>
<p>제목만 봐선 다분히 개발 이야기가 주를 이룰 것 같지만 사실 이 책은 애자일에 관한 책이다.
200쪽가량의 짧은 분량으로 예전부터 읽어야지 했었는데 오히려 분량이 짧아선지 언제든 읽을 수 있다는 근거 없는 자신감으로 미뤄 왔던 책이었다.
그렇게 뒷순위로 밀려나 있던 책이었는데 매번 개발과 직접 관련된 도서만 읽다가 보니 환기할 겸, 또 모임에서 주제로 이 책을 다루기로 해서 최근에서야 읽게 되었다.</p>
<h2 id="정리">정리</h2>
<h3 id="본질적-방법">본질적 방법</h3>
<blockquote>
<p>이 책에서 하고 싶은 말은 간결합니다. “소프트웨어 개발에는 본질적인 방법이 존재한다. 그 방법은 모두에게 도움을 준다.” 라는 것입니다.</p>
</blockquote>
<p>다소 모호하고 추상적인 ‘소프트웨어 개발의 본질적 방법’에 대해 화두를 던지면서 책은 시작된다.
그럼 본질적 방법이 구체적으로 무엇인가 하는 게 이 책의 주제라고 생각하기 쉽지만, 저자는 바로 다음 명확하게 아니라고 밝힌다.</p>
<blockquote>
<p>이제 저와 함께 살펴봅시다.
명확한 가치를 자주 배포하는 데 초점을 맞춰 소프트웨어 개발을 더 간결하게 만드는 방법을요.
이 책에서는 본질적인 방법이 정확히 어떤 것이라고 말하지는 않습니다.
다만 우리가 노력한다면 어떻게 조직을 변화시킬 수 있는지 이야기할 뿐이죠.</p>
</blockquote>
<h3 id="가치">가치</h3>
<p>애자일을 학습하다보면 반복적으로 나오는 키워드가 있다. 바로 <strong>가치</strong>다. 저자가 정의 내리는 가치란 우리가 추구하고 원하는 것이다.
소프트웨어에서는 피처를 통해 가치를 얻을 수 있으며, 소프트웨어로 시간이나 돈을 절약할 수 있기에 가치는 흔히 돈과 연결된다.
그리고 소프트웨어는 배포하고 사용할 때 비로소 가치를 전달할 수 있다.</p>
<p>모두가 한 번쯤은 겪어 봤을 전통적인 방법으로는 가치 전달이 쉽지 않다.
계속 추가되는 요구사항, 촉박한 일정으로 급하게 개발하여 망가지는 코드, 매번 바뀌는 프로젝트 방향성 등으로 항상 제날짜에 모두가 원하는 피처를 완성한 채 배포한다는 것은 꿈에 가깝다.</p>
<p>그렇다면 굳이 피처 전체가 아니라 가치를 일찍 제공할 수 있는 피처를 먼저 배포한다면? 이 방법대로라면 프로젝트는 성공할 것이다.</p>
<blockquote>
<p>작고 가치 있는 피처를 자주 배포할 때 최고의 가치를 얻을 수 있습니다.</p>
<p>피처 단위로 소프트웨어를 배포한다면 최고의 결과를 얻을 수 있다는 것을 꼭 기억하세요.</p>
</blockquote>
<h4 id="피처-단위-개발의-이점">피처 단위 개발의 이점</h4>
<p>작은 피처 단위로 프로젝트를 진행한다면 계획대로 가는지, 얼마나 끝났고 얼마나 빨리 진행 중인지 살펴보기 좋다.
주어진 기간에 얼마나 많은 것을 할 수 있을지 더 쉽게 예측할 수도 있다.
그리고 비즈니스 담당자나 경영진의 요구 사항이 변경돼도 적절하게 대응할 수 있다.</p>
<h4 id="조직-구성">조직 구성</h4>
<p>작은 피처 단위로 반복하여 가치를 전달하기 위해선 작은 개발팀을 여럿 구성해야 한다.
물론 각 개발팀이 피처 일부가 아닌 전체를 개발할 수 있는 기술을 가졌는지도 반드시 확인해야 한다.</p>
<p>하지만 알다시피 이렇게 조직하긴 어렵다. 전문가를 적절하게 투입한다고 하더라도 어렵다.
그럼 이제는 훈련이 필요할 때이다.
개발팀에 포함된 학습공동체를 만들어 팀의 선임 기술자가 다른 사람을 전문가로 이끌게끔 한다.</p>
<h4 id="계획">계획</h4>
<blockquote>
<p>아이젠하워 장군(General Eisenhower)은 이렇게 말했습니다.
“계획은 쓸모없을 때가 많습니다. 하지만 동시에 없어서는 안 될 부분입니다.”</p>
</blockquote>
<p>늘 계획대로 되진 않더라도 큰 틀에서의 계획은 필요하다.
구체적으로 세부 목록까지 기술해 놓은 너무 세세한 계획은 시간만 낭비하고 혼란만 가중하니 피해야 한다.
또 계획을 세우되, 언제든지 변화를 줄 수 있는 환경을 만들도록 하자.</p>
<p>핵심이 되는 계획 방법은 먼저 개발해야 할 핵심 피처를 추리고 가치가 낮은 피처는 최대한 뒤로 미루어야 하는 것이다.
그리고 커다란 피처를 태스크 단위로 쪼개지 말고 항상 작은 사용자 스토리를 기준으로 개발하자.</p>
<p>업무량은 각팀이 스스로 정해야 한다. 예측하기 힘들다면 가장 최근 주기의 작업량을 기준으로 업무량을 계획하면 된다.
추정은 위험하고 무리한 목표는 자멸을 초래한다. 또한 과욕은 금물이다.</p>
<blockquote>
<p>모든 피처를 동일한 크기로 잘게 쪼개는 데 능숙해지면 프로젝트를 쉽게 관리할 수 있습니다.
개발에 걸리는 시간을 바로 알 수 있기 때문입니다.
완성돼야 할 일과 미룰 수 있는 일을 구분하여 가장 가치 있는 피처를 먼저 개발함으로써 일정 지연 없이 프로젝트를 성공적으로 끝낼 수 있습니다.</p>
</blockquote>
<blockquote>
<p>일반적으로 프로젝트 추정은 어긋나기 마련입니다.
추정은 가치가 아닌 비용과 관련된 내용이 대부분이죠.
비용 추정은 중요도를 낮추거나 배제하고 가치에 중점을 두어 성공으로 나아가야만 합니다.</p>
</blockquote>
<h4 id="개발">개발</h4>
<p>피처를 잘게 쪼개고 가장 높은 가치를 가진 피처를 먼저 개발해야 한다.
이는 반복되어 나오는 내용으로 그만큼 중요하다는 것을 의미한다.
각 주기가 끝나는 시점에서는 소프트웨어의 결함이 없어야 하며 이것만으로는 충분하지 않고 제품이 성장할 때마다 소프트웨어의 설계도 개선해야 한다.</p>
<blockquote>
<p>피처를 유연하게 추가하기 위해서는 프로젝트가 시작할 때부터 끝날 때까지 시스템의 기반을 견고하게 유지해야 합니다.</p>
</blockquote>
<p>기반은 중요하다.
하지만 기반을 먼저 구성하게 되면 너무 적은 피처로 제품을 배포하게 된다.
그러니 간결하지만 작동하는 버전을 먼저 개발하고 몇 번의 개발 주기로 피처를 개선하자.</p>
<p>프로젝트가 나아갈수록 설계도 계속 변화한다.
그 과정에 여러 실수가 생길 수 있는데 이를 방지하기 위해 테스트해야 한다.
오직 테스트만이 결함을 최소화한다.</p>
<p>설계도 한순간의 결정으로 나빠질 수 있다. 올바르게 유지하려면 지속적으로 설계를 개선해야 한다.</p>
<blockquote>
<p>피처 단위로 개발하려면 테스트와 리팩토링을 함께 진행해야 합니다.
이 개발 방법의 본질이 테스트와 리팩토링에 있기 때문이죠. 오늘날까지 이보다 나은 방법은 없습니다.</p>
<p>이 방법은 최고의 품질과 차질 없는 일정, 그리고 정확한 예측을 도와주는 데 가장 잘 알려진 방법이기도 합니다.
테스트와 리팩토링은 피처 단위 개발에서 핵심 도구니까요. 절대 이 둘 없이 피처 단위 개발을 진행해서는 안 됩니다.</p>
</blockquote>
<h3 id="조언">조언</h3>
<blockquote>
<p>우리에게 필요한 정보는 사용자가 선호하는 가치입니다. 이 정보로 무엇을 만들지 결정합니다.</p>
<p>가치를 선택하는 일은 우리가 중요하다고 생각하는 것을 선택하는 일입니다.
가치는 우리가 원하는 것이니까요.</p>
</blockquote>
<p>끊임없이 가치에 대해 논한다.
그 가치가 어떤 것인지 스스로나 이해관계자에게 묻고 무엇이 중요한지 왜 중요한지 팀과 함께 고민하며 만들어 나아간다.</p>
<blockquote>
<p>이것만은 기억하세요.
항상 가치에 집중할 것, 가치를 기준으로 계획하고 관리할 것, 사용자가 어떤 반응을 보이는지 살펴볼 것.
이렇게 간결하고도 명확한 기준을 기반으로 길을 나아가야 한다는 점 말입니다.</p>
</blockquote>
<h4 id="성장하는-개발팀">성장하는 개발팀</h4>
<blockquote>
<p>다니엘 핑크가 쓴 [드라이브]에서, 그는 목적, 자율성, 숙련이 직원의 만족과 제품의 생산성을 이끄는 핵심이라고 설명합니다.</p>
</blockquote>
<p>목적은 비즈니스로부터 나오며, 자율성은 팀에게 책임감을 부여하고, 반복적인 개발 주기로 품질을 높이고 기준을 엄격하게 만들면 숙달되어 완벽해질 수 있다.</p>
<h4 id="압박">압박</h4>
<blockquote>
<p>압박한다면 개발팀은 잘못 돼가는 것을 알면서도 포기합니다.
테스트를 충분히 하지 않죠. 나쁜 코드를 방치합니다.
이 현상은 가치를 떨어뜨리고 가치를 얻는 데 필요한 일정을 지연시킵니다.
그 결과 제품의 가치도 떨어지고 배포도 늦게 되죠.</p>
</blockquote>
<p>압박은 최악의 수다. 압박받는다면 보수적이나 방어적으로 일할 수 있다.</p>
<blockquote>
<p>여러분이 정말로 빠르게 개발해야 한다면 일정을 지연시키는 원인을 분석하세요.
일반적으로 개개인이 가진 생산성보다는 이쪽이 더 영향력이 큽니다.</p>
</blockquote>
<p>팀 생산성에 주목하되, 개개인의 생산성을 높이려면 재촉하지 말고 개개인의 능력을 향상하게 시켜야 한다.</p>
<h4 id="리팩토링">리팩토링</h4>
<blockquote>
<p>주의: 프로젝트는 일정한 속도를 유지해야 합니다.
일정한 속드는 설계를 항상 깔끔하게 유지해야 나옵니다.
설계를 깔끔하게 하려면 반드시 리팩토링해야 합니다.</p>
</blockquote>
<p>코드 품질을 고려치 않는다면 비슷한 난이도의 피처를 개발하는 데 걸리는 시간이 완전히 차이가 나게 된다.
이러한 나쁜 개발은 외부에서 눈치채기 어렵다.
리팩토링은 꾸준히 코드를 개선하기 위한 중요한 방법이며 기존 프로젝트에 적용하려면 그곳을 발견했을 때보다 떠날 때 더 나은 곳이어야 한다는 야영지 규칙을 따르도록 하자.
즉, 피처를 추가할 때마다 주변 코드 위주로 깔끔하게 정리하는 걸로 시작한다. 완벽할 필요는 없다.</p>
<h2 id="후기">후기</h2>
<p>가치를 무엇으로 정할 것이며 어떻게 발전시키고 나아갈 것인지가 이 책의 핵심이라 할 수 있다.
하지만 직접적으로 구체적인 것들을 알려주기보단 함께 성장할 수 있는 고민을 던져준다.
그러다 보니 애자일을 시작하기엔 도움이 되나 깊이 있는 수준의 내용으론 구성되어 있지 않아서 많은 걸 기대했다면 실망스러울 수도 있다.</p>
<p>기억에 남는 부분으로는 테스트와 리팩토링이었다.
애자일이라고 해도 테스트나 리팩토링을 제대로 하지 않는 곳들이 많은데 책에서는 반드시 해야 하는 필수적인 핵심 도구라 강조한다.
100퍼센트 공감한다. 설사 애자일이 아니더라도 이 두 방법은 반드시 필요하다.
제아무리 코드 리뷰를 하더라도 올바른 동작을 보장하는 건 결국 테스트이며, 코드의 품질을 개선하여 개발 속도를 결정하게 하는 건 결국 리팩토링이다.</p>
<p>현실에서 애자일은 어떻게 진행되고 있는가?
책에서 이야기하는 것처럼 높은 가치를 우선순위로 평가하며, 압박받지 않고, 정해진 주기로, 제대로 된 방법을 써가며 발전을 도모하고 있을까?
구성원 모두가 이해하고 공감대가 형성되어 있지 않다면 형식적이거나 제자리에 머물러 있을 가능성이 크다.</p>
<p>그런 면에서 이 책은 조직의 모두가 읽는다면 당장의 변화는 아니더라도 큰 틀에서의 방향성은 공유할 수 있을 것이다.
그럼 애자일하게 제대로 시작해보자.</p> </section></div>

lannex

Shin, SJ

[책] The Nature of Software Development - 간결하게, 가치 있게, 하나씩 완성하기

The Nature of Software Development

댓글