<div id="readability-page-1" class="page"><div><h2 id="폭포수와-애자일">폭포수와 애자일</h2>
<p>"모든것을 미리 정해놓고 한번에 개발하자!" 는 폭포수(워터폴) 개발론은 한가지 문제가 있습니다. 너무 큰 걸 만들다보니 <strong>고객</strong>들이 만들어진 시스템의 전체 모습을 그리기가 어려워져 버린 것입니다.<br>
그래서 "폭포수를 개울물만큼 쪼개놓고 계속 반복하면서 피드백을 받을 수 있게 하자"라는 애자일이 등장했습니다. 신세계였어요.</p>
<h2 id="전체-시스템-생각하기">전체 시스템 생각하기</h2>
<p>애자일이 대두되면서, 경험이 많은 개발자들이 미처 예상하지 못한 사태가 발생했습니다. 바로 <strong>"실무 개발자들이 전체 시스템을 머리속에 그리는 일"을 잘 못하게 되어버린</strong> 슬픈 현실에 맞닥드리는 겁니다.</p>
<p>애자일이라는 개념 자체를 만든 사람들은 실력도 뛰어나고, 워터폴로 전체 아키텍쳐를 그리는 데 익숙하며, 이미 서비스 완성 경험이 많기 때문에 애자일이라고 해도 다른 부분을 생각하면서 만들어나갈 수 있습니다.<br>
애자일을 받아들여서 도입하신 분들도 마찬가지에요. 이분들은 보통 C레벨, 아키텍트, AA 등으로 불리며 직접 코딩을 하는 것보다는 전체적인 그림을 그리시는 분들이니 수준이 높을 겁니다.<br>
그래서 경험이 많으시고 수준이 높은 분들이 보기에는 당연한 것들이 경험이 적은 실무 개발자들에게는 전혀 모르는 사실로 다가오는 거죠. </p>
<p>이러한 실무진과 설계자간의 괴리로 인해 개별 이터레이션을 담당하는 개발자들은 전체 모습을 그리지 못하게 됩니다. 당장 나에게 떨어진 미션은 눈 앞의 작은 기능을 완성하는 것이 되어 버리기 때문입니다. 머리로는 이해할 수 있을 지라도 직접 해보지 않은 경험은 와닿는 정도가 다른 법이니까요.</p>
<p>폭포수 개발론은 이런 문제가 잘 일어나지 않습니다. 처음에만 전체 그림을 숙지를 해 두면 프로젝트 종료시까지 코드만 열심히 작성하면 됩니다.  어차피 초반에 꼭 필요한 설계는 다 되어 있기 때문에 소소한 것들은 그 때 그 때 찾아보거나 물어보면 되지요.<br>
하지만 <strong>어설픈 애자일</strong>에서는 그럴 수 없습니다. 실무진들이 다른 <strong>전체 시스템과의 연계를 생각하지 못하</strong>기 때문에 설계는 점점 더 엉망이 되어갑니다. 코드는 파편화되고, 시스템은 중복이 넘쳐나며, 서로 논리적으로 구멍이 생기게 되는 슬픈 현실에 빠져 들죠.</p>
<p>이를 바로 잡아줄 수 있는 설계자 분들이 계시다면 행운이겠지만, 모두가 행운을 가지고 살아가는 것은 아니니까요.</p>
<p>더 큰 문제는 "주니어가 시간이 지나고 언젠가 시니어가 될 때, 그리고 시니어를 지나 설계자 레벨로 올라섰을 때 "전체 시스템 설계를 (해 본 적이 없으니까) 못하게 된다는" 것입니다.<br>
주니어 개발자의 실력이 늘어야 설계자분들이 여유있게 <del>업무중에 유튜브 시청이라도 하면서..</del> 본연의 업무에 집중할 수 있는데 말이죠.</p>
<p>이런 이유 때문에 "요새 애들은 코딩은 잘하는데 설계는 못해"라는 이야기가 빈번하게 들려오는 것 같기도 합니다. <del>아니 해본 적이 없는데 어떻게 잘해..</del></p>
<h2 id="최종-결정자도-바뀌어야-한다">최종 결정자도 바뀌어야 한다.</h2>
<p>덧붙여서 좋은 설계자가 있다고 해도 최종 결정을 하는 사람이 <strong>어설픈 애자일 신봉자</strong>라면 더 큰 문제가 생깁니다.<br>
무엇을 만들 지 결정하는 사람도 애자일이라는 이름 하에 "나중에 생각하지 뭐" 가 당연해 집니다. 청사진 없이 무언가를 만든다는 건, 사실은 자기도 뭐가 필요한 지 모르겠다는 말인 거에요.</p>
<p>개발자로 살아가면서 가장 무서운 말 중 하나는 "나중에 생각하지 뭐. 그 때 끼워넣자" 에요. 외부의 시선으로 바라보기에는 단순하게 레고블럭처럼 조립할 수 있다고 생각하실 수 있지만, 역시 인생은 만만하지 않으니까요.<br>
특히 개발할 때 전체 시스템과의 연계를 생각하지 않고 코드를 작성하면, 모든 코드를 다 들어내고 다시 개발해야 하는 <strong>강제 리팩토링</strong>이 시작될 가능성도 있어요. 우리는 이런 것을 이렇게 부릅니다.<br>
<img src="https://velog.velcdn.com/images/koeunyeon/post/89240cda-1dd5-429a-823c-b7c41a52868b/image.png"><br>
<a href="https://velog.io/@jayce_k">출처 - <code>jayce_k(강진석)</code>님 프로필</a></p>
<h2 id="전체-스프린트-그리고-그-사이의-모듈">전체, 스프린트, 그리고 그 사이의 "모듈"</h2>
<p>만약 현재 속한 조직에서 일하는 방법이 워터폴 방법론이 너무 크고, 애자일의 스프린트가 너무 작다면, 그 중간 단위인 "모듈" 레벨을 두어서 최소한 "모듈" 레벨에서는 서로 연계가 되는 시스템을 설계하고 개발을 시작했으면 좋겠습니다.<br>
즉  <code>스프린트 ⊂ 전체</code>  구조가 비합리적이라면 <code>스프린트 ⊂ 모듈 ⊂ 전체</code> 구조는 어떨까 싶은 거죠.<br>
<code>스프린트</code> 수준에서는 "이터레이션의 주기"를 결정하고, <code>모듈</code> 레벨에서는 "소규모 시스템 완성"을, 그리고 <code>전체</code> 레벨은 사용자 서비스 관점으로 접근하는 것은 어떨까 한번 생각해 보았어요.</p>
<p>당연히 시스템이 크다면 <code>스프린트 ⊂ 모듈 ⊂ 전체</code> 가 아니라 <code>스프린트 ⊂ 모듈 ⊂ 모듈 ⊂ 전체</code> 혹은 <code>스프린트 ⊂ 모듈 ⊂ 모듈 ⊂ 모듈 ⊂ 전체</code> 등의 구조도 가능하겠지요?</p>
<p>"모듈"은 MSA서 말하는 "바운디드 컨텍스트"와 비슷한 개념으로 느껴질 수도 있습니다만 "바운디드 컨텍스트"가 마이크로 서비스를 엮는 중간 복합자 개념이라면, "모듈"은 하나의 소규모 시스템을 지칭한다는 면에서 조금 다르게 봐 주시면 감사하겠습니다.</p></div></div>

고은연

폭포수와 애자일
"모든것을 미리 정해놓고 한번에 개발하자!" 는 폭포수(워터폴) 개발론은 한가지 문제가 있습니다. 너무 큰 걸 만들다보니 고객들이 만들어진 시스템의 전체 모습을 그리기가 어려워져 버린 것입니다.
그래서 "폭포수를 개울물만큼 쪼개놓고 계속 반복하면서 피드백을 받을 수 있게 하자"라는 애자일이 등장했습니다. 신세계였어요.
전체 시스템 생각하기
애자일이 대두되면서, 경험이 많은 개발자들이 미처 예상하지 못한 사태가 발생했습니다. 바로 "실무 개발자들이 전체 시스템을 머리속에 그리는 일"을 잘 못하게 되어버린 슬픈 현실에 맞닥드리는 겁니다.
애자일이라는 개념 자체를 만든 사람들은 실력도 뛰어나고, 워터폴로 전체 아키텍쳐를 그리는 데 익숙하며, 이미 서비스 완성 경험이 많기 때문에 애자일이라고 해도 다른 부분을 생각하면서 만들어나갈 수 있습니다.
애자일을 받아들여서 도입하신 분들도 마찬가지에요. 이분들은 보통 C레벨, 아키텍트, AA 등으로 불리며 직접 코딩을 하는 것보다는 전체적인 그림을 그리시는 분들이니 수준이 높을 겁니다.
그래서 경험이 많으시고 수준이 높은 분들이 보기에는 당연한 것들이 경험이 적은 실무 개발자들에게는 전혀 모르는 사실로 다가오는 거죠. 
이러한 실무진과 설계자간의 괴리로 인해 개별 이터레이션을 담당하는 개발자들은 전체 모습을 그리지 못하게 됩니다. 당장 나에게 떨어진 미션은 눈 앞의 작은 기능을 완성하는 것이 되어 버리기 때문입니다. 머리로는 이해할 수 있을 지라도 직접 해보지 않은 경험은 와닿는 정도가 다른 법이니까요.
폭포수 개발론은 이런 문제가 잘 일어나지 않습니다. 처음에만 전체 그림을 숙지를 해 두면 프로젝트 종료시까지 코드만 열심히 작성하면 됩니다.  어차피 초반에 꼭 필요한 설계는 다 되어 있기 때문에 소소한 것들은 그 때 그 때 찾아보거나 물어보면 되지요.
하지만 어설픈 애자일에서는 그럴 수 없습니다. 실무진들이 다른 전체 시스템과의 연계를 생각하지 못하기 때문에 설계는 점점 더 엉망이 되어갑니다. 코드는 파편화되고, 시스템은 중복이 넘쳐나며, 서로 논리적으로 구멍이 생기게 되는 슬픈 현실에 빠져 들죠.
이를 바로 잡아줄 수 있는 설계자 분들이 계시다면 행운이겠지만, 모두가 행운을 가지고 살아가는 것은 아니니까요.
더 큰 문제는 "주니어가 시간이 지나고 언젠가 시니어가 될 때, 그리고 시니어를 지나 설계자 레벨로 올라섰을 때 "전체 시스템 설계를 (해 본 적이 없으니까) 못하게 된다는" 것입니다.
주니어 개발자의 실력이 늘어야 설계자분들이 여유있게 업무중에 유튜브 시청이라도 하면서.. 본연의 업무에 집중할 수 있는데 말이죠.
이런 이유 때문에 "요새 애들은 코딩은 잘하는데 설계는 못해"라는 이야기가 빈번하게 들려오는 것 같기도 합니다. 아니 해본 적이 없는데 어떻게 잘해..
최종 결정자도 바뀌어야 한다.
덧붙여서 좋은 설계자가 있다고 해도 최종 결정을 하는 사람이 어설픈 애자일 신봉자라면 더 큰 문제가 생깁니다.
무엇을 만들 지 결정하는 사람도 애자일이라는 이름 하에 "나중에 생각하지 뭐" 가 당연해 집니다. 청사진 없이 무언가를 만든다는 건, 사실은 자기도 뭐가 필요한 지 모르겠다는 말인 거에요.
개발자로 살아가면서 가장 무서운 말 중 하나는 "나중에 생각하지 뭐. 그 때 끼워넣자" 에요. 외부의 시선으로 바라보기에는 단순하게 레고블럭처럼 조립할 수 있다고 생각하실 수 있지만, 역시 인생은 만만하지 않으니까요. 
특히 개발할 때 전체 시스템과의 연계를 생각하지 않고 코드를 작성하면, 모든 코드를 다 들어내고 다시 개발해야 하는 강제 리팩토링이 시작될 가능성도 있어요. 우리는 이런 것을 이렇게 부릅니다.
출처 - jayce_k(강진석)님 프로필
전체, 스프린트, 그리고 그 사이의 "모듈"
만약 현재 속한 조직에서 일하는 방법이 워터폴 방법론이 너무 크고, 애자일의 스프린트가 너무 작다면, 그 중간 단위인 "모듈" 레벨을 두어서 최소한 "모듈" 레벨에서는 서로 연계가 되는 시스템을 설계하고 개발을 시작했으면 좋겠습니다.
즉  스프린트 ⊂ 전체  구조가 비합리적이라면 스프린트 ⊂ 모듈 ⊂ 전체 구조는 어떨까 싶은 거죠.
스프린트 수준에서는 "이터레이션의 주기"를 결정하고, 모듈 레벨에서는 "소규모 시스템 완성"을, 그리고 전체 레벨은 사용자 서비스 관점으로 접근하는 것은 어떨까 한번 생각해 보았어요.
당연히 시스템이 크다면 스프린트 ⊂ 모듈 ⊂ 전체 가 아니라 스프린트 ⊂ 모듈 ⊂ 모듈 ⊂ 전체 혹은 스프린트 ⊂ 모듈 ⊂ 모듈 ⊂ 모듈 ⊂ 전체 등의 구조도 가능하겠지요?
"모듈"은 MSA서 말하는 "바운디드 컨텍스트"와 비슷한 개념으로 느껴질 수도 있습니다만 "바운디드 컨텍스트"가 마이크로 서비스를 엮는 중간 복합자 개념이라면, "모듈"은 하나의 소규모 시스템을 지칭한다는 면에서 조금 다르게 봐 주시면 감사하겠습니다.

어설픈 애자일

댓글