<div id="readability-page-1" class="page"><div>
  
  
  <p><span>2023년 07월 15일 작성</span></p><h2 id="tldr">TL;DR</h2>

<p>프로세스와 조직구조도 콘웨이의 법칙<sup id="fnref:1" role="doc-noteref"><a href="#fn:1" rel="footnote">1</a></sup>을 고려해야 한다.</p>

<p>쉐이프 업은 조직의 구성에 따라 애자일을 대체할 수도 있다.</p>

<p>쉐이프 업은 개발 과정의 모든 프로세스를 담고 있지 않다. 따라서 비어있는 부분은 알아서 잘 메꿔야 한다.</p>

<h2 id="시작하며">시작하며</h2>

<p>현재 팀은 애자일로 일한다고 주장하지만, 실제로는 가벼운 워터폴 방식으로 일하고 있다. 생각과 행동이 다르기 때문에 프로세스가 뭔가 안맞는 부분도 있는 것 같고, 애자일을 잘 모르는 구성원들은 이 방식이 애자일이라고 생각하고 있는 것도 같다.</p>

<p>최근 프로세스를 개선하기 위해서 여러 책과 문서들을 읽다가 쉐이프 업(Shape Up) 이라는 책을 알게 되었다.</p>

<p>현재 프로토타이핑 팀은 4주간 요구사항을 분석하고, 4~6주간 빌드를 하는 식으로 빌드를 하고 있다.
쉐이프 업은 이 방식과 거의 동일하게 설명하면서도 좀 더 체계적이라 엄청 흥미가 생겼다.</p>

<p>프로토타이핑 팀에서 일하는 방식을 프로덕션 개발에도 적용할 수 있다면 고객의 문화나 조직구조를 바꾸는 데도 영향을 끼칠 수 있지 않을까 하는 기대로 책을 읽게 되었다.</p>

<p>책은 온라인에서 공짜로 읽을 수 있으니, 본 글에서는 책에 대한 내용은 다루지 않는다.</p>

<p>대신, 이미 어떠한 프로세스로 일을 하고 있는 회사나 조직에서 쉐이프 업을 사용할 때 생각해볼만한 내용만 몇가지 적어본다.</p>

<h2 id="쉐이프-업-요약">쉐이프 업 요약</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/ns_i03epYD8" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen=""></iframe>

<p>개인적으로 라이언 싱어의 원래 영상<sup id="fnref:2" role="doc-noteref"><a href="#fn:2" rel="footnote">2</a></sup> 보다 위의 영상이 좀 더 쉽게 설명한거 같다.</p>

<p><img src="https://www.prodify.group/hs-fs/hubfs/Basecamp%20Shape%20Up%20dual%20track%20process.png?width=3032&amp;name=Basecamp%20Shape%20Up%20dual%20track%20process.png"></p>

<p>쉐이프 업은 쉐이핑(Shaping), 베팅(betting) 그리고 빌딩(building) 단계로 이뤄지고, 크게 아래와 같이 설명할 수 있을 것 같다.</p>

<ol>
  <li>주어진 비즈니스 문제에 대해 6주간 분석하고(쉐이핑) 피치(pitch)라는 형태의 문서로 만들어낸다.</li>
  <li>이 피치 문서를 기반으로 얼마만큼의 시간을 할애해서 풀지 (혹은 안풀지) 베팅을 한다.</li>
  <li>베팅된 피치를 팀에서 가져가서 6주간 빌딩하여 결과물을 만든다.</li>
</ol>

<h2 id="생각해볼-점">생각해볼 점</h2>

<p>앞서 말한대로, 쉐이프 업은 현재 사용 중인 프로토타이핑 프로세스와 거의 일치하기 때문에 기존 프로세스에 적용할 수 있거나 개선할 수 있는 인사이트를 얻기를 원했다.</p>

<p>이런 관점에서 생각해볼만한 점들을 정리해 봤다.</p>

<h3 id="배경">배경</h3>

<ul>
  <li>쉐이프 업은 디자이너로 시작한 개발자 겸 프로덕트 매니저가 Basecamp 의 상황에 맞춰 발전시킨 프로세스를 정리한 내용이다.
    <ul>
      <li>개인적으로 다른 애자일 프로세스들 보다 쉐이프 업에서의 디자이너 역량이 훨씬 더 중요해보인다. 쉐이프 업에서 디자이너는 다루는 제품과 UX 에 대한 기본적인 이해를 가지고 있어야 한다. 따라서 경력이 없는 디자이너는 어떤 페이즈에도 단독으로 참여할 수 없다.</li>
      <li>디자이너 센트릭한 프로세스 이므로 기술문서들에 대한 내용이 빠져있다. 실제 장기 프로젝트 운영시 팀간의 소통이나 새로온 사람이 기능을 파악하기 위한 기술문서는 매우 중요하다.</li>
      <li>또한 피치 문서는 드래프트에 가까우며 현실적으로는 빌드 페이즈에 새롭게 수정되거나 발견되는 내용들은 빠질 수 밖에 없는데, 이런 부분은 다루지 않는다.</li>
    </ul>
  </li>
  <li>Appetite 는 프로세스를 위해 의도해서 만든 것이 아니라 현실과의 타협에 대한 결과이다.
    <ul>
      <li>개발자가 유명인 (루비온 레일즈 창시자)이라 쓸 수 있는 시간에 제약이 있었기 때문에 시간을 커밋하는 Appetite 라는 방식을 도입하게 되었다.</li>
      <li>따라서 풀타임으로 개발자들을 보유하는 회사에서는 해당 방식에 대한 저항이 있을 수 있다.</li>
      <li>또 37signals 라는 회사는 리워크, 리모트 라는 책을 쓴 회사이다. 리모트는 업무에 대한 자율성이 매우 중요한 업무 방식이며, 이미 회사의 문화가 그런 부분에 충분히 성숙해있다는 점도 고려해야한다.</li>
    </ul>
  </li>
  <li>소규모 스타트업의 장점을 대규모에서 되살리기 위한 방식이기 때문에, 대규모 서비스를 만드는 엔터프라이즈 급 회사에서는 적용하기 어렵다.
    <ul>
      <li>초기 스타트업은 소규모 팀이 작은 컨텍스트를 공유하면서 일하기 때문에 문서나 티켓을 거의 만들지 않고도 작업이 완료될 수 있다. 규모가 커져도 계속 이렇게 일 할수 없을까?</li>
      <li>회사가 커질수록 다루는 문제가 더 복잡해지고 커지기 때문에 쉽지 않은 경우가 많다. 팀의 구성과 코드 베이스가 모두 autonomous 할 수 있게 지원되지 않으면 불가능하다.</li>
      <li>또한 완벽한 설계는 없기 때문에, 종종 디펜던시 문제가 생길 수 밖에 없다. 대규모 시스템은 그럴 가능성이 더욱 높다. 책에서 말한대로 버그는 천천히 대응할 수 있지만, 다른 팀의 디펜던시는 그렇지 않을 수 있다. 이런 부분을 사전에 파악하지 못하면 빌드 페이즈에 인터럽트가 많이 발생할 수 밖에 없고, 원하는 결과를 빌드할 수 없게 된다.</li>
    </ul>
  </li>
</ul>

<h3 id="회사의-특성">회사의 특성</h3>

<ul>
  <li>먼저 Basecamp 는 bootstrapped 회사다. 즉 일반적인 회사들과 다르게 VC 투자를 받지 않았다.
    <ul>
      <li>따라서 피쳐를 개발하는 프로세스를 매우 자유롭게 정할 수 있다. VC 투자를 받은 회사(대부분의 한국 회사)는 2주 쿨다운 등의 여유(?) 를 부릴 수가 없다.</li>
      <li>꽉꽉 짜여서 움직이는 스크럼 방식이 훨씬 회사 입장에서 효과적으로 보일수 밖에 없다.</li>
    </ul>
  </li>
  <li>Basecamp 는 20년된 회사다. 애초에 본인들의 문제를 해결하기 위해 만든 협업툴이므로 스스로가 고객이기도 하다. 따라서 일반적인 스타트업과 다르게 고객전문가를 보유하고 있다.
    <ul>
      <li>애자일 프로세스가 전제하는 것도 고객전문가를 보유하고 있다는 점이다. 만약 고객전문가를 회사가 보유하고 있지 않다면(대부분의 스타트업) 린 스타트업을 사용하는 것이 훨신 유효한 전략일 것이다.</li>
      <li>여튼 이런 전제 때문에 요구사항 분석에 대해 잘못된 제품을 만드는 부분은 커버하지 않는다.</li>
      <li>쉐이프 업은 애자일을 대체할 수 있는 프로세스이며, 린 스타트업과 함께 써볼 수 있는 보완재라고 볼 수 있다.</li>
    </ul>
  </li>
  <li>Basecamp 는 개발자와 디자이너 비율이 거의 1:1에 가까운데, 이는 Autonomous Team 을 만들기 위해서 필수적인 내용이다.
    <ul>
      <li>실제로 프로젝트 진행할 때도 개발자 2, 디자이너 1 정도의 비율로 팀이 구성되어서 빌드한다고 한다.</li>
    </ul>
  </li>
  <li>Basecamp 는 시니어와 주니어의 비율이 비슷하거나, 시니어의 비율이 높다. 이는 Autonomous 해야하는 쉐이핑과 빌드 페이즈에 큰 영향을 끼친다.</li>
</ul>

<h3 id="기타">기타</h3>

<ul>
  <li>꼭 쉐이핑을 한 사람이 빌드를 할 필요는 없다.
    <ul>
      <li>책에서도 시니어 개발자와 디자이너들이 모여서 쉐이핑을 충분히 하고 팀에게 할당한다고 되어 있다.</li>
    </ul>
  </li>
  <li>시니어의 매니지먼트 부담을 줄여준다고 주장한다.
    <ul>
      <li>태스크 단위로 개발하는 것이 아니라 컨텍스트를 완전히 공유한 상태로 작은 팀이 작은 문제를 해결하는 솔루션을 개발하기 때문에, 마이크로매니지먼트를 하지 않아도 된다고 한다.</li>
      <li>하지만 실제로는 팀의 결과물을 책임지는 것이 시니어이므로 부담이 없을 수 없다.</li>
      <li>특히 팀 구성원이 주니어가 껴 있으면 주니어의 문제를 같이 봐주면서 개발하게 되면 속도가 같이 느려질 수 밖에 없는데, 베팅 시점에 기간이 이미 결정되었기 때문에 시니어가 팀원의 능력을 어느정도 파악하고 있지 않으면 무조건 일정이 지연된다.</li>
    </ul>
  </li>
</ul>

<h2 id="마치며">마치며</h2>

<p>잡 플래닛의 많은 스타트업 리뷰에서 체계가 없다는 이야기를 많이 본다.</p>

<p>근데 그 회사들은 사실 슬랙, 지라, 컨플루언스 등을 쓰고 업무의 프로세스가 있고 일이 되고 있는 것처럼 보이는 회사들이다.</p>

<p>하지만 구성원들은 일하면서 체계가 없다는 평가를 한다. 왜일까?</p>

<p>여러가지 이유가 있겠지만, 개인적으로는 아래 문제가 제일 크지 않을까 한다.</p>

<ul>
  <li>일을 할때 기존 프로세스를 무시하고 맘대로 하는 사람이 있지만(특히 높은 사람들) 아무런 불이익이나 제재가 가해지지 않는다.</li>
</ul>

<p>프로세스는 각 구성원들이 각자가 다루는 다양한 변수들을 예측 가능한 상수로 만들기 위해, 커뮤니케이션을 용이하게 해주는 회사내의 합의이다.</p>

<p>그리고 이 프로세스에서의 합의는 교차로의 신호등과 같이 어느정도의 유연함을 가진 규칙이기 때문에 단순히 합의를 종종 어기는 것 만으로는 체계가 없다는 느낌을 받지는 않는다고 생각한다.</p>

<p>예를 들어 교통체증이 심하지 않을땐 노란불일 때 꼬리를 살짝 물어도 전체 트래픽에 영향을 주지 않지만, 어떤 경우에는 꼬리물기한 몇대의 차량 때문에 전체 교차로가 차로 가득찰 수도 있다.</p>

<p>항상 트래픽을 보고 막힌 트래픽을 제어하기 위해 적절히 관리해줘야하는 신호등, 경찰 같은 사람들이 제역할을 못하거나 오히려 트래픽을 방해하는 경우에, 신호등도 있음에도 불구하고 신호체계가 없다는 평가를 듣게 된다.</p>

<hr>



</div></div>

Haandol

TL;DR
프로세스와 조직구조도 콘웨이의 법칙1을 고려해야 한다.
쉐이프 업은 조직의 구성에 따라 애자일을 대체할 수도 있다.
쉐이프 업은 개발 과정의 모든 프로세스를 담고 있지 않다. 따라서 비어있는 부분은 알아서 잘 메꿔야 한다.
시작하며
현재 팀은 애자일로 일한다고 주장하지만, 실제로는 가벼운 워터폴 방식으로 일하고 있다. 생각과 행동이 다르기 때문에 프로세스가 뭔가 안맞는 부분도 있는 것 같고, 애자일을 잘 모르는 구성원들은 이 방식이 애자일이라고 생각하고 있는 것도 같다.
최근 프로세스를 개선하기 위해서 여러 책과 문서들을 읽다가 쉐이프 업(Shape Up) 이라는 책을 알게 되었다.
현재 프로토타이핑 팀은 4주간 요구사항을 분석하고, 4~6주간 빌드를 하는 식으로 빌드를 하고 있다.
쉐이프 업은 이 방식과 거의 동일하게 설명하면서도 좀 더 체계적이라 엄청 흥미가 생겼다.
프로토타이핑 팀에서 일하는 방식을 프로덕션 개발에도 적용할 수 있다면 고객의 문화나 조직구조를 바꾸는 데도 영향을 끼칠 수 있지 않을까 하는 기대로 책을 읽게 되었다.
책은 온라인에서 공짜로 읽을 수 있으니, 본 글에서는 책에 대한 내용은 다루지 않는다.
대신, 이미 어떠한 프로세스로 일을 하고 있는 회사나 조직에서 쉐이프 업을 사용할 때 생각해볼만한 내용만 몇가지 적어본다.
쉐이프 업 요약
개인적으로 라이언 싱어의 원래 영상2 보다 위의 영상이 좀 더 쉽게 설명한거 같다.
쉐이프 업은 쉐이핑(Shaping), 베팅(betting) 그리고 빌딩(building) 단계로 이뤄지고, 크게 아래와 같이 설명할 수 있을 것 같다.
주어진 비즈니스 문제에 대해 6주간 분석하고(쉐이핑) 피치(pitch)라는 형태의 문서로 만들어낸다.
이 피치 문서를 기반으로 얼마만큼의 시간을 할애해서 풀지 (혹은 안풀지) 베팅을 한다.
베팅된 피치를 팀에서 가져가서 6주간 빌딩하여 결과물을 만든다.
생각해볼 점
앞서 말한대로, 쉐이프 업은 현재 사용 중인 프로토타이핑 프로세스와 거의 일치하기 때문에 기존 프로세스에 적용할 수 있거나 개선할 수 있는 인사이트를 얻기를 원했다.
이런 관점에서 생각해볼만한 점들을 정리해 봤다.
배경
쉐이프 업은 디자이너로 시작한 개발자 겸 프로덕트 매니저가 Basecamp 의 상황에 맞춰 발전시킨 프로세스를 정리한 내용이다.
    
개인적으로 다른 애자일 프로세스들 보다 쉐이프 업에서의 디자이너 역량이 훨씬 더 중요해보인다. 쉐이프 업에서 디자이너는 다루는 제품과 UX 에 대한 기본적인 이해를 가지고 있어야 한다. 따라서 경력이 없는 디자이너는 어떤 페이즈에도 단독으로 참여할 수 없다.
디자이너 센트릭한 프로세스 이므로 기술문서들에 대한 내용이 빠져있다. 실제 장기 프로젝트 운영시 팀간의 소통이나 새로온 사람이 기능을 파악하기 위한 기술문서는 매우 중요하다.
또한 피치 문서는 드래프트에 가까우며 현실적으로는 빌드 페이즈에 새롭게 수정되거나 발견되는 내용들은 빠질 수 밖에 없는데, 이런 부분은 다루지 않는다.
Appetite 는 프로세스를 위해 의도해서 만든 것이 아니라 현실과의 타협에 대한 결과이다.
    
개발자가 유명인 (루비온 레일즈 창시자)이라 쓸 수 있는 시간에 제약이 있었기 때문에 시간을 커밋하는 Appetite 라는 방식을 도입하게 되었다.
따라서 풀타임으로 개발자들을 보유하는 회사에서는 해당 방식에 대한 저항이 있을 수 있다.
또 37signals 라는 회사는 리워크, 리모트 라는 책을 쓴 회사이다. 리모트는 업무에 대한 자율성이 매우 중요한 업무 방식이며, 이미 회사의 문화가 그런 부분에 충분히 성숙해있다는 점도 고려해야한다.
소규모 스타트업의 장점을 대규모에서 되살리기 위한 방식이기 때문에, 대규모 서비스를 만드는 엔터프라이즈 급 회사에서는 적용하기 어렵다.
    
초기 스타트업은 소규모 팀이 작은 컨텍스트를 공유하면서 일하기 때문에 문서나 티켓을 거의 만들지 않고도 작업이 완료될 수 있다. 규모가 커져도 계속 이렇게 일 할수 없을까?
회사가 커질수록 다루는 문제가 더 복잡해지고 커지기 때문에 쉽지 않은 경우가 많다. 팀의 구성과 코드 베이스가 모두 autonomous 할 수 있게 지원되지 않으면 불가능하다.
또한 완벽한 설계는 없기 때문에, 종종 디펜던시 문제가 생길 수 밖에 없다. 대규모 시스템은 그럴 가능성이 더욱 높다. 책에서 말한대로 버그는 천천히 대응할 수 있지만, 다른 팀의 디펜던시는 그렇지 않을 수 있다. 이런 부분을 사전에 파악하지 못하면 빌드 페이즈에 인터럽트가 많이 발생할 수 밖에 없고, 원하는 결과를 빌드할 수 없게 된다.
회사의 특성
먼저 Basecamp 는 bootstrapped 회사다. 즉 일반적인 회사들과 다르게 VC 투자를 받지 않았다.
    
따라서 피쳐를 개발하는 프로세스를 매우 자유롭게 정할 수 있다. VC 투자를 받은 회사(대부분의 한국 회사)는 2주 쿨다운 등의 여유(?) 를 부릴 수가 없다.
꽉꽉 짜여서 움직이는 스크럼 방식이 훨씬 회사 입장에서 효과적으로 보일수 밖에 없다.
Basecamp 는 20년된 회사다. 애초에 본인들의 문제를 해결하기 위해 만든 협업툴이므로 스스로가 고객이기도 하다. 따라서 일반적인 스타트업과 다르게 고객전문가를 보유하고 있다.
    
애자일 프로세스가 전제하는 것도 고객전문가를 보유하고 있다는 점이다. 만약 고객전문가를 회사가 보유하고 있지 않다면(대부분의 스타트업) 린 스타트업을 사용하는 것이 훨신 유효한 전략일 것이다.
여튼 이런 전제 때문에 요구사항 분석에 대해 잘못된 제품을 만드는 부분은 커버하지 않는다.
쉐이프 업은 애자일을 대체할 수 있는 프로세스이며, 린 스타트업과 함께 써볼 수 있는 보완재라고 볼 수 있다.
Basecamp 는 개발자와 디자이너 비율이 거의 1:1에 가까운데, 이는 Autonomous Team 을 만들기 위해서 필수적인 내용이다.
    
실제로 프로젝트 진행할 때도 개발자 2, 디자이너 1 정도의 비율로 팀이 구성되어서 빌드한다고 한다.
Basecamp 는 시니어와 주니어의 비율이 비슷하거나, 시니어의 비율이 높다. 이는 Autonomous 해야하는 쉐이핑과 빌드 페이즈에 큰 영향을 끼친다.
기타
꼭 쉐이핑을 한 사람이 빌드를 할 필요는 없다.
    
책에서도 시니어 개발자와 디자이너들이 모여서 쉐이핑을 충분히 하고 팀에게 할당한다고 되어 있다.
시니어의 매니지먼트 부담을 줄여준다고 주장한다.
    
태스크 단위로 개발하는 것이 아니라 컨텍스트를 완전히 공유한 상태로 작은 팀이 작은 문제를 해결하는 솔루션을 개발하기 때문에, 마이크로매니지먼트를 하지 않아도 된다고 한다.
하지만 실제로는 팀의 결과물을 책임지는 것이 시니어이므로 부담이 없을 수 없다.
특히 팀 구성원이 주니어가 껴 있으면 주니어의 문제를 같이 봐주면서 개발하게 되면 속도가 같이 느려질 수 밖에 없는데, 베팅 시점에 기간이 이미 결정되었기 때문에 시니어가 팀원의 능력을 어느정도 파악하고 있지 않으면 무조건 일정이 지연된다.
마치며
잡 플래닛의 많은 스타트업 리뷰에서 체계가 없다는 이야기를 많이 본다.
근데 그 회사들은 사실 슬랙, 지라, 컨플루언스 등을 쓰고 업무의 프로세스가 있고 일이 되고 있는 것처럼 보이는 회사들이다.
하지만 구성원들은 일하면서 체계가 없다는 평가를 한다. 왜일까?
여러가지 이유가 있겠지만, 개인적으로는 아래 문제가 제일 크지 않을까 한다.
일을 할때 기존 프로세스를 무시하고 맘대로 하는 사람이 있지만(특히 높은 사람들) 아무런 불이익이나 제재가 가해지지 않는다.
프로세스는 각 구성원들이 각자가 다루는 다양한 변수들을 예측 가능한 상수로 만들기 위해, 커뮤니케이션을 용이하게 해주는 회사내의 합의이다.
그리고 이 프로세스에서의 합의는 교차로의 신호등과 같이 어느정도의 유연함을 가진 규칙이기 때문에 단순히 합의를 종종 어기는 것 만으로는 체계가 없다는 느낌을 받지는 않는다고 생각한다.
예를 들어 교통체증이 심하지 않을땐 노란불일 때 꼬리를 살짝 물어도 전체 트래픽에 영향을 주지 않지만, 어떤 경우에는 꼬리물기한 몇대의 차량 때문에 전체 교차로가 차로 가득찰 수도 있다.
항상 트래픽을 보고 막힌 트래픽을 제어하기 위해 적절히 관리해줘야하는 신호등, 경찰 같은 사람들이 제역할을 못하거나 오히려 트래픽을 방해하는 경우에, 신호등도 있음에도 불구하고 신호체계가 없다는 평가를 듣게 된다.
Conway’s Law ↩
Shape up in nutshell ↩

Shape Up 프로세스에 대한 생각

댓글