스타트업 개발 생산성 높이기: (1) Shape Up
2022 / 11 / 13
벌써 디어코퍼레이션에 합류한지 6개월이 지나가고 있습니다. 2022년 5월에 입사한 이후에 조직의 제품 개발 생산성을 높이기 위해 고군분투하고 있습니다. 반년이라는 길지 않은 시간이었지만 개발 프로세스를 정비하고 효율을 높이기 위해 도입했던 절차와 아이디어들을 공유합니다.
(이 글은 회사 블로그에도 기고했습니다: https://blog.deering.co/shape-up/)
“… 생각할 시간이 부족해요.”
디어 물류팀의 첫 번째 필드테스트(개발한 제품을 물류 주선사의 직원분들에게 제공해서 사용자 반응을 관찰)와 지금까지의 개발 방식을 회고하면서 개발자들이 모두 동의했던 문장입니다. 개발 방식에 어떤 변화가 필요할지 고민하고 있던 중에 은성님(물류팀 개발자)이 Shape Up이라는 개발 방법론을 들고왔습니다.
Shape Up은 개발 방법론이면서 책 이름이기도 합니다. 책은 웹에 무료로 공개되어 있고 pdf로 받아볼 수도 있습니다. 저는 Introduction을 읽으면서부터 강렬한 인상을 받았습니다: https://basecamp.com/shapeup/0.3-chapter-01
첫 번째 강렬한 인상은 Ruby on Rails가 Basecamp라는 프로덕트를 만들면서 탄생한 부산물이라는 것입니다. Ruby on Rails의 핵심 철학인 ‘Convention over Configuration’은 Spring Boot가 탄생하는데 큰 기여를 했습니다.
- Convention Over Configuration: Rails has opinions about the best way to do many things in a web application, and defaults to this set of conventions, rather than require that you specify minutiae through endless configuration files.
Basecamp는 회사 이름인 동시에 프로덕트 이름입니다. 2003년에 Basecamp(회사)는 웹사이트 디자인을 하는 컨설팅 회사였습니다(At the time we were a consultancy designing websites for clients). 일을 하면서 고객, 디자이너, 프로젝트 매니저간의 의사소통에서 발생하는 정보가 파편화되는 문제를 겪었고, Basecamp는 이 문제를 해결하기 위해 정보를 한 곳에 모을 수 있는 제품을 만들었습니다. 많은 회사들이 동일한 문제를 겪고 있었고 오늘날에는 수백만 명의 사람들이 다양한 업종에서 Basecamp를 사용하고 있습니다.
Basecamp의 첫 번째 버전은 Basecamp 설립자인 Jason Fried, 공동 설립자이자 프로그래머인 David Heinemeier Hansson, 그리고 디자이너이면서 Shape Up 방법론 책을 Ryan Singer가 만들었습니다. David는 당시 Basecamp에 주당 10시간 밖에 할애할 수 밖에 없는 상황이었기 때문에 Basecamp는 코딩할 수 있는 10시간을 최대한 생산적으로 사용해야만 했습니다.
10시간의 제약조건을 극복하기 위해 Basecamp는 해야 할 일의 범위를 잘게 쪼개야만 했습니다. David는 극한의 생산성을 달성해야만 했고, 이를 위해 Ruby on Rails 프레임워크를 만들었습니다. Ruby on Rails의 두 가지 핵심 철학 ‘DRY(Don’t Repeat Yourself)', ‘Convention over Configuration’ 모두 프로그래머가 작성해야 하는 코드의 양을 최소화하는 방향에 초점이 맞추어져 있습니다.
엔터프라이즈 웹애플리케이션 세상에 Ruby on Rails가 끼친 영향력을 이미 알고 있었기 때문에 Shape Up에서 어떤 이야기를 할지 기대가 되었습니다.
TailwindCSS 개발팀은 2020년에 Shape Up을 도입했습니다. 디어코퍼레이션에서는 TailwindCSS를 적극적으로 사용하고 있고 이 라이브러리가 제공하는 가치를 높게 평가하고 있기 때문에, TailwindCSS 팀에서도 Shape Up을 사용하고 있다는 것도 기대가 되었습니다.
Semantic css(css class 이름에 맥락이 담긴 의미를 부여해서 사람이 알아보기 쉽게 작성하는 방식)는 사람에게는 좋지만 기계에게는 힘든 방식입니다. 기계에게 사람이 생각하는 방식을 알게 하는 것은 너무너무 어려운 일이기 때문입니다. 디자이너가 만든 디자인 결과물에서 실제 프로덕트에 사용할 수 있는 코드를 생성하려는 시도는 GUI가 등장한 직후부터 끊임없이 시도되어 왔습니다. 하지만 높은 퀄리티를 가진 코드를 생성하는 것에는 번번히 실패했는데, 기계가 생성한 코드를 사람이 알아보기가 너무 어려웠기 때문입니다.
이 문제에 대해서 저는 ‘어떻게 하면 기계가 더 높은 퀄리티를 가진 코드를 생성할 수 있을까? 결국 머신러닝밖에 답이 없나?’라고만 생각하고 있었는데, https://velog.io/@teo/adorable-css 이 글을 보고 생각이 달라졌습니다. 이 글은 'Semantic css 방식을 포기하면 사람이 읽기 어려운 코드가 될 것이다'라는 전제를 깨부숩니다. css class 이름에서 맥락을 없애면서도 사람이 읽기 쉬울 수 있다면 기계가 자동생성한 코드를 실제 프로덕트에 사용할 수 있게 됩니다. 위 글의 작성자인 Teo님은 TailwindCSS에서 그 희망을 발견했고 AdorableCSS라는 라이브러리를 직접 만들어서 오래된 꿈(디자이너의 결과물에서 고품질의 코드를 뽑아낸다)을 실현했습니다.
AdorableCSS의 핵심 기능인 functional css는 클래스 이름을 함수처럼 작성해서 css를 생성합니다. Teo님이 AdorableCSS를 개발하던 시절에는 TailwindCSS에 이 기능이 없었지만, TailwindCSS가 버전 3으로 올라가면서 ‘Arbitrary Values’라는 이름으로 동일한 기능을 제공합니다.
이런 이유 때문에 디어코퍼레이션에서는 TailwindCSS를 도입했습니다. 저희 회사는 React Native를 사용하고 있는데, React Native에도 Tailwind CSS 구현체(twrnc, https://github.com/jaredh159/tailwind-react-native-classnames )가 있어서 웹과 앱 모두 TailwindCSS를 사용하고 있습니다. 웹과 앱을 통일된 방식으로 스타일링을 할 수 있어서 매우 만족스럽습니다.
Adam Wathan은 Tailwind CSS를 만들었습니다. 그의 2020년 회고(https://adamwathan.me/journal/2020/12/29/2020-year-in-review/ )의 ‘Becoming a Leader' 부분에 Tailwind CSS 팀도 Shape Up을 도입했다는 사실과 그 이유가 적혀있습니다.
Adam은 1~2주 정도의 시간이 걸리는 작은 단위의 프로젝트가 많이 쌓여있는 상황에서 프로젝트 계획을 작성하는데 고통을 느끼고 있었습니다. 그는 큰 크기의 프로젝트를 계획할 시간이 없다고 느꼈기 때문에 계획을 빨리 끝낼 수 있는 작은 크기의 프로젝트만 선택해서 처리했습니다. 때문에 높은 효과(=고객 가치)를 만들어낼 수 있는 큰 크기의 프로젝트는 방치되고 있었습니다.
Ryan Singer(Shape Up의 저자)는 Adam과 Shape Up에 대한 대화를 나눴습니다(https://www.youtube.com/watch?v=qkJJ9v4eryM ). Ryan은 한 번에 6주 단위의 계획을 세우는 것(Shape Up은 6주 단위로 Cycle을 수행하기를 권장합니다)이 어떤 가치를 갖는지 알려주었습니다. 한 번에 6주 단위를 계획한다는 건 1년에 프로젝트 계획을 7~8번밖에 할 수 없다는 뜻이고, 따라서 프로젝트 계획에 충분한 시간을 쓸 수 있게 됩니다. Adam에게 ‘다음번에 하자’는 말은 1~2주 뒤를 의미했지만 Shape Up을 도입하면서 ‘다음번’의 의미는 6~8주 뒤로 바뀌었습니다. 어떤 프로젝트를 6~8주 뒤에 수행할 수 있다고 할 때 마음이 불편하다면 그 프로젝트는 이번 Cycle에 어떻게든 포함해야만 합니다.
이렇게 관점을 바꾸고 나자 큰 효과를 내는 프로젝트에 정당한 우선순위를 부여할 수 있게 되었고, Adam은 프로젝트를 계획하는 주기가 길어졌기 때문에 엔지니어링 업무에 더 집중할 수 있게 되었습니다.
Ryan은 디자이너였지만 David에게 프로그래밍을 배우면서 프로그래머가 복잡도를 관리하기 위해 사용하는 소프트웨어 개발 원칙들을 제품을 디자인하고 관리(manage)할 때도 적용할 수 있을 것 같다고 느꼈습니다.
As the business grew, I started widening my skills. Working with David and Ruby on Rails made the world of programming accessible to me. I learned the techniques programmers use to tame complexity: things like factoring, levels of abstraction, and separation of concerns. With one foot in the design world and one foot in the programming world, I wondered if we could apply these software development principles to the way we designed and managed the product.
그는 2009년부터 소프트웨어 개발 원칙들을 개발 방법론에도 적용하는 시도를 했습니다. 디자이너와 프로덕트 매니저의 역할을 겸하면서 가령 빵판(breadboard)로 프로토타입을 만드는 방식을 소프트웨어를 디자인할 때도 적용하거나 개발할 범위(scope)를 정하는 방식을 제품 자체에도 적용했습니다. 이 방식은 효과적이었고 꾸준히 발전해서 Shape Up 방법론이 되었습니다.
- Six-week cycles
- Shaping the work
- Making teams responsible
- Targeting risk
Basecamp는 6주의 시간이 의미있는 변화를 만들어내기에 충분한 시간이면서도 Cycle이 종료되는 날짜를 피부로 느낄 수 있을 만큼 짧기 때문에 시간을 현명하게 사용할 수 있었다고 합니다. Daily meeting도 없고, 2주마다 방향성(roadmap)을 을 재고하지도 않습니다. Shape Up 방법론에서는 ‘이 제품이 6주 뒤에 배포되었을 때 우리가 행복할지, 우리가 겪어낸 시간이 의미 있었는지’에 집중합니다.
Shape Up에서는 문제를 두 번 풉니다. 추상적인 레벨에서 한 번 풀고, 구체적인 레벨에서 한 번 더 풉니다. 문제를 두 번 푸는 핵심적인 이유는 상세 기획을 하거나 코드를 작성하기 전에 중요한 문제를 해결함으로써 변경에 발생하는 비용을 최소화할 수 있기 때문입니다. 구현체가 있을 때보다 없을 때 변경 비용이 훨씬 작기 때문에 높은 추상화 수준에서 문제를 찾고 해결하면 빠르게 움직일 수 있습니다.
Basecamp에서는 숙련자 그룹과 구현팀이 나누어져 있습니다. 프로젝트는 구현팀이 무엇을 해야 할지 알 수 있도록 충분히 구체적이면서도 그들이 직접 세부사항을 결정할 수 있을 정도로 추상적이야 합니다. 이렇게 추상화 수준을 정하고 프로젝트를 정의하는 과정을 Shape the work 라고 표현합니다.
Shape the work 과정에서 숙련자 그룹은 개발 기간을 예측하기보다는 프로젝트의 내용이 얼마나 구미에 당기는지(appetite)에 집중합니다. 만약 프로젝트 크기가 너무 커서 6주 안에 구현하기 힘들어 보인다면 범위를 쪼개(hammering the scope)서 2개의 cycle로 분리합니다. 만약 프로젝트 크기가 너무 작다면 여러 개의 shape(Shape the work 의 결과물)을 한 번의 cycle로 묶을 수도 있습니다. 프로젝트가 작은 경우 Basecamp는 2주 단위로 계획한 프로젝트 3개를 cycle에 포함하기를 권장하지만, 의무적으로 2주를 지켜야 하는 것은 아닙니다.
디자이너와 프로그래머로 구성된 구현팀은 주어진 shape를 어떻게 구현할지에 대한 모든 책임을 가지게 됩니다. 매니저가 티켓을 나누고 프로그래머가 티켓을 처리하는 방식과는 본질적으로 다릅니다. 구현팀은 주도성을 가지며 일 할 수 있고(autonomous) 숙련자(senior)들은 팀을 매니징할 때 적은 시간만 사용해도 되기 때문에 이후에 구현팀에게 주어질 shape를 더 잘 만들 수 있게 됩니다.
저는 Shape Up을 사용한다고 해서 추상적인 문서(shape)만 있고 상세 기획 문서 없이 일할 수 있다고 생각하진 않습니다. 많은 회사에서 기획자가 자세한 상세 기획 문서까지 작성하고 개발자는 문서의 내용을 구현하는 방식으로 일하지만, Shape Up의 구현팀은 적당히 구체적으로 작성되어 있는 shape를 바탕으로 상세 기획 문서를 직접 작성해서 일해야 한다고 생각합니다.
디어코퍼레이션에는 기획 직군이 없습니다. 개발자와 디자이너로만 이루어져 있기 때문에 숙련자 그룹과 구현팀이 나누어져서 일하는 Shape Up은 물류팀은 물론 회사 전체 개발팀에도 적용할 수 있을 정도로 저희 회사와 잘 맞는다고 느꼈습니다.
Shape Up은 단 하나의 risk에 집중합니다: 제때 제품을 배포할 수 있는가?
애자일은 우리가 얼마나 망했는지 빨리 파악하고 현실적인 소프트웨어 개발 기간을 예측하는 것을 목표로 하는 반면, Shape Up은 정해진 기한(6주) 안에 현실적으로 해낼 수 있는 일 만큼만 해서 배포 날짜를 지키는 것을 목표로 합니다.
따라서 숙련자 그룹은 구현팀에게 shape를 전달하기 전에 risk를 최대한 줄여야 합니다. shape에는 rabbit hole과 tangled interdependencies가 없어야 합니다.
Rabbit hole은 ‘뭘 모르는지 모르는 문제Unknown unknown’라고 할 수 있습니다(디어코퍼레이션 부대표 손명균의 표현). 해결책을 찾기 위해 소비해야 하는 시간이 예측이 안 되는 문제이고, 구현팀이 이 문제에 시간을 소비하기 전에 숙련자 그룹에서 먼저 이 문제를 발견하고 합리적인 해결책을 제시해야 합니다.
Tangled interdependency가 없다는 의미는 업무간 의존성을 명확히 파악해서 독립적으로 작업할 수 있는 범위(scope)로 업무를 잘라내야 한다는 뜻입니다.
We break the overall scope (singular) of the project into separate scopes (plural) that can be finished independently of each other.
- https://basecamp.com/shapeup/3.3-chapter-12#organize-by-structure-not-by-person
이상의 합리적인 4가지 핵심 철학을 마음속에 새겨놓아야 Shape Up 방식으로 제품을 개발할 수 있습니다.
디어코퍼레이션 부대표 손명균님은 Shape Up 방법론을 만든 사람들이 어떤 문화와 철학을 가지고 있는지를 탐구한다면 Shape Up이라는 문화의 형식 이면에 있는 핵심적인 내용을 파악하기 쉬울 것이라고 했습니다.
다음 글에 Basecamp가 어떤 회사인지 자세히 적혀있습니다: https://medium.com/the-mission/how-basecamp-built-a-100-billion-business-by-doing-less-on-purpose-5f978ce6478c . 한 마디로 요약하면 적게 일하면서도 높은 성과를 낼 수 있는 기업 문화를 추구한다고 할 수 있습니다. bullet point로 정리해보면
- 1999년 설립, 2014년에 1천억원($100 billion) 가치 평가를 받았다.
- 느리게 성장하지 않을거면 아무것도 하지 마라(Grow slowly or not at all).
- 반만 만들어라. 가장 큰 가치를 전달하는 일들만 골라서 해라(Build half a product).
- 미팅 하지마라(Say no to meetings).
- 가서 잠 좀 자라(Go to sleep).
- 경쟁자들보다 덜 해라(Underdo your competitors).
- 엑싯할 생각일랑 하지 말고 장기적 관점으로 헌신해라(Don’t plan your exit. Commit to the “long slow run”).
- 급하게 하지 마라. 시기時機와 상관없이 가치 있는 일을 해라(Don’t be hot. Optimize for timelessness).
- 성공해서 은퇴할 생각 말고 세상에 어떤 유산을 남길지 고민해라(Forget success. Think about your legacy).
- 세상을 바꾸려고 하지 말고 쓸모 있는 것을 만들어라(Don’t change the world. Be of use).
- 투자 받지 말고 최대한 빨리 자립해라(Bootstrap, bootstrap, bootstrap).
- 투자금으로 연명하기보다 돈 벌 생각 해라(Stop being a startup and grow up).
- 혁신하지 마라. 유용한 것을 만드는게 새로운 것을 만드는 것보다 훨씬 어렵다(Don’t innovate. It’s more important to build something good than something novel; it’s also much harder.)
- 눈 앞의 작은 일에 집중해라(Think small. And then smaller).
- 좋은 디자이너는 핵심만 남긴다(Good designers kill the inessential).
- 제약이 창조를 가능케한다(Constraints enable creativity).
- 좋은 질문은 무의식적인 편향과 쓸모없는 가정을 드러낸다(Ask better questions).
- 미팅은 최악의 생산성 학살자다(Kill Meetings).
- 매몰비용을 무시해라(Don’t throw good time after bad work).
의미있고 유용한 내용이 가득 들어있는 글이었습니다. 장기적 관점을 강조하고 현금을 중요하게 생각하는 디어코퍼레이션의 문화와도 비슷한 부분을 많이 찾을 수 있었습니다.
저희는 최소 6주간 해야 할 일을 정할 수 있는 상황이 Shape Up을 적용하기 위한 필요조건이라고 판단했습니다. Shape Up은 충분한 시간을 가지고 제품 개발 계획을 세우게 도와줍니다. 때문에 역설적으로 6주간 무엇을 해야 할지 명확하게 정할 수 없는 상태라면 Shape Up 방식으로 제품을 개발하기 곤란합니다. 매주 비즈니스 상황이 달라지고 빠르게 대응해야 한다면 Shape Up보다는 스프린트 방식이 더 적절할 수 있습니다.
물류팀은 B2B 프로덕트를 만들고 있고, B2B 특성상 고객의 요구사항이 명확한 경우가 많습니다. 고객이 무엇을 원하는지 제대로 파악하고 일거리가 충분히 쌓여있다면 Shape Up을 적용해서 좋은 성과를 볼 수 있을 것입니다. 하지만 B2B 프로덕트라도 고객의 요구사항 자체가 명확하지 않은 부분이라면 빠르게 프로토타입을 만들어 고객의 반응을 탐구하고 방향을 정해야 합니다. 이 과정에서 Shape Up을 적용해 개발하기는 쉽지 않다고 느꼈지만, 1~2주의 짧은 기간이라도 Shape Up은 의미가 있었습니다.
Shape Up 책의 부록에서는 6주가 너무 길게 느껴지는 상황에서도 Shape Up을 적용할 수 있다고 합니다: https://basecamp.com/shapeup/4.1-appendix-02#small-enough-to-wing-it . 팀이 작은 경우 한 사람이 프로그래밍도 하면서 고객의 요구사항에도 대응하면서 인프라 문제까지 해결하고 있을 수 있습니다. 이런 경우엔 Shape Up이 요구하는 구조의 많은 부분을 덜어낼 수 있습니다. 6주보다 더 짧은 단위로 계획을 세울 수 있고, Cool Down period라 불리는 마무리 기간이 필요없을 수도 있습니다. 하지만 여전히 appetitie을 정할 수 있고, 다음에 무엇을 할지 shape할 수 있고, 제품을 개발할 수 있습니다. Cycle을 명확하게 지키지 않더라도 여전히 Shape Up의 철학은 유효하고 유용합니다.
Cycle을 2주나 1주 단위로 돌게 된다면 스프린트와 유사한 형태가 되긴 합니다. 이를 스프린트 대신 Shape Up이라고 부르는게 이득이 있을까요? 저희는 이득이 있다고 생각했습니다. Shape Up은 충분히 고민하고 생각할 시간을 확보하도록 요구합니다. ‘충분히 생각하고 계획하라'는 메시지는 cycle 기간이 짧더라도 여전히 의미가 있습니다. Pitch를 작성하고 Betting하는 과정은 cycle 기간과 상관없이 가치가 있습니다.
Shape에 어디까지 포함해야 할까요? Shape Up은 문제의 추상화 수준을 나누어 문제를 2번 해결합니다. 어디까지가 숙련자 그룹에서 풀어야 할 문제고 어디부터 구현팀이 풀어야 할 문제일까요? 이 선을 잘 정하는게 Shape Up을 성공적으로 도입하기 위한 핵심이 될 수 있습니다.
Ryan Singer의 Shape Up 책엔 적절한 추상화 수준을 유지하기 위한 여러 가지 기법과 힌트가 나와있습니다. 하지만 직접 cycle을 수행하면서 여러 번의 회고를 통해 각자의 팀에 맞는 선을 찾아야 합니다. 비즈니스 도메인 혹은 팀원의 구성에 따라 문제의 추상화 수준은 달라져야 합니다.
어떤 기능을 제공하기 위한 최소한의 복잡도가 존재합니다. 아무리 빨리 만든다고 한들 제품을 제작하는데 필요한 최소 시간이 존재합니다. 양자역학을 아무리 쉽게 설명하려고 해도 어려울 수밖에 없는 것처럼요. 애자일은 제품을 빨리 만들기 위한 방법론이 아닙니다. 마찬가지로 Shape Up은 제품을 빨리 만들기 위한 방법론이 아닙니다.
애자일이 빠르게 나아가는 것이라고 생각하는 사람도 있다. 그렇지 않다. 빠르게 나아가는 것이었던 적은 없다. 애자일은 우리가 얼마나 망했는지를 최대한 빨리 아는 것이다. 최대한 빨리 알아야 상황을 관리할 수 있기 때문이다. 맞다. 이 관리가 관리자가 하는 일이다.
관리자는 데이터를 모으고 그 데이터에 기반하여 최선의 결정을 내림으로써 소프트웨어 프로젝트를 관리한다. 애자일은 데이터를 만든다. 애자일은 데이터를 많이 만든다. 관리자는 이 데이터를 사용하여 프로젝트를 가능한 최선의 결과로 이끈다.
Excerpt From
31쪽, 1장 애자일 소개, 클린 애자일
로버트 C. 마틴
Shape Up은 고객에게 최대한의 가치를 빠르게 전달하게 도와주는 개발 방법론입니다. 중요한 일을 먼저 함으로써 많은 가치를 빠르게 제공할 수는 있지만, 제품 자체를 빠르게 만들 수는 없습니다. 여러 가지 기법을 통해 제품 개발 과정에 숨어있는 비효율을 제거함으로써 빨라질 수는 있지만, 어떤 방법론을 사용하더라도 기능 개발에 필요한 최소 시간마저 줄일 수는 없습니다. 억지로 이 시간마저 줄이려고 한다면 근시일 내에 몇 곱절의 시간을 소모해 대가를 치루게 되고 제품 개발 속도는 느려집니다.
내가 품질을 떨어뜨리는 것은 소용이 없다고 이야기할 거라는 걸 독자들은 알고 있었으리라 믿는다. 쓰레기를 만든다고 더 빨리 갈 수는 없다. 더 느려질 뿐이다. 이것이 프로그래밍을 20년 아니면 30년 정도 한 뒤에 배우게 되는 중요한 교훈이다. 빨리 대강 할 수 있는 방법 같은 것은 없다. 대강 하면 느려진다.
빠르게 가는 유일한 방법은 제대로 가는 것이다.
자, 그러니 우리는 품질 스위치를 돌려서 11로 올릴 것이다. 일정을 앞당기고 싶다면 유일한 선택지는 품질을 올리는 것이다.
Excerpt From
35쪽, 1장 애자일 소개, 클린 애자일
로버트 C. 마틴
Shape Up을 도입하시려면 아래의 순서를 통해 수월하게 학습하실 수 있습니다.
- 한글 요약본 읽기 (저자의 철학이 어느정도 반영되어 있음): https://www.relate.kr/blog/shape-up-relate/
- 원서 읽기, 요약본을 읽었으면 'Glossary → Appendix → 처음부터' 순서로 읽으면 이해하기 쉽다.
- https://basecamp.com/shapeup/4.5-appendix-06
- Shape Up에서 사용하는 개념이 정리되어 있는 단어장입니다. 특정 단어가 Shape Up이라는 철학에서 어떤 의미를 갖는지 먼저 파악하면 원서의 내용을 이해하기 쉽습니다.
- https://basecamp.com/shapeup/4.0-appendix-01
- 현실에서 Shape Up을 적용하기 위한 여러 가지 팁들이 적혀있습니다.
- https://basecamp.com/shapeup/webbook
- 한글 요약본도 읽고 단어의 뜻도 파악하고 실제 업무에 Shape Up을 적용하기 위한 팁도 읽었다면 이제 저자의 생각을 제대로 이해하기 위해 원서를 직접 읽어볼 차례입니다. 요약본만 읽고 끝내지 말고 직접 저자의 생각을 느껴보시기를 강력하게 추천드립니다.
- https://basecamp.com/shapeup/4.5-appendix-06