크리스티안 마두스베르그의 '센스 메이킹'은 자신의 책에서 매우 인문학적인 전문가 입장에서 센스 메이킹을 다루고 있다. 책에서는 '인문학적 기초에서 실용적 지혜를 얻는 방식'이라는 정의를 사용한다. 수치나 데이터에서 얻는 알고리즘식 사고와 정반대라고 주장한다. 저자는 센스 메이킹을 통해서 얻은 데이터를 인류학자인 킬리퍼트 기어츠(Clifford Geertz)의 '민족지학(ethonography)'적 현장 조사의 '심층적 기술(thick description)'을 참고하여 '심층적 데이터'라고 불렀다. 40그램의 사과와 1그램의 꿀은 피상적 데이터이지만, 꿀에 절인 사과를 곁들인 로쉬 하샤나Rosh Hashanah(유대인의 명절 중 하나)' 음식은 심층적 데이터라는 것이다.
마두스베르그는 통찰을 얻고 싶을 때에는 맥락을 파고 들어 세계에 완전히 몰입해야 한다고 한다. 이를 통해 피상적 데이터와 심층적 데이터와 관계를 살필 것을 이야기 한다. 이 심층적인 데이터를 알아 내기 위해 마두스베르그는 다음과 같이 지식의 종류를 나누어 설명한다. 이것은 객관적 지식, 주관적 지식, 공유적 지식 그리고 감각적 지식이다. 감각적 지식은 몸에서 기인한다고 했은데 이것은 저차원적으로 이해하고 살아가는 양상을 말해 준다고 한다. 이라크에 파견된 경험 많은 군인들이 근처에 설치된 부비트랩을 모으로 '느끼는' 것이 그것의 예라고 한다.
저자는 센스 메이킹에 귀추법이 필요하다고 이야기 하고 있지만, 디자인 싱킹에 대해서는 비판적인 입장을 가지고 있다. 무엇보다도 사회적 맥락 없이 프로세스 상으로 접근하는 디자인 싱킹은 사실을 오도한고 다양한 관점에서 아이디어를 찾아 내지만 사회적 맥락에 대한 지식없이 공감을 얻을 수 없다고 한다. 또한, 디자인 싱킹이 사람들과 그들이 속한 환경을 관찰하지만 이것을 주마간산식(drive-by) 인류학이라고 비판한다.
마두스베르그의 센스메이킹은 전문가가 되는 것을 방향으로 삼는 것으로 보인다. 여러 사례가 있지만 30년 동안 와인을 만드는 전문가의 이야기가 대표적이다. 유행에 뒤처지면서도 끈기를 가지고 알고리즘이나 화학으로는 알아 낼 수 없는 그의 방식을 이야기 한다.
여기서 주장하는 센스 메이킹이 심층적 데이터를 뽑아 내기 위해서 전문가가 되어야 한다고 주장하는 것으로 보인다. 하지만, 이 내용은 대니얼 카너먼과 게리 클라인이 이야기 한 것과 같이 전문가도 틀릴 수 있다는 부분을 생각해 보자. 이처럼 책에서 이야기 하는 많은 센스 메이킹의 사례도 조금 다른 상황에서는 틀릴 수 있는 것이다.
그렇다면, 우리는 어떻게 센스 메이킹을 해야 하는 것일까? 책의 내용만큼이나 어려운 질문이다.
클린 아키텍처[1]의 5부 아키텍처에서는 원칙이라고 분류하여 설명하지는 않는다. 물론 YAGNI(You Aren't Going to Need It), KISS(Keep It Simple Stupid), DRY(Don't Repeat Yourself)에 대해서 언급하기는 하지만 이 원칙은 아키텍처 설계와 관련되지만 객체 지향 설계에서도 채용되는 개념으로 클린 아키텍처에서 말하는 아키텍처 설계의 핵심 원칙이라고 하기는 어렵다. 여기서는 클린 아키텍처 책의 4부에서는 이야기 하는 주요 개념들을 정리해 본다. 즉, 우선은 15장 부터 22장까지의 내용을 정리하고자 한다. 다른 장들은 전체적인 개념을 바탕으로 상세화 하여 설명한다고 볼 수 있어 여기서는 다루지 않겠다.
언급하는 주요 항목은 프로덕트 생명 주기 (개발, 배포 운영)를 고려하되, 소프트웨어 시스템을 지금까지 논의 한 컴포넌트로 분리하는 것인데, 이를 경계(Boundary)라고 하고 아키텍처 설계는 결국은 어떻게 경계를 나누는가에 대한 것이다. 소프트웨어를 시스템에서 정책(Policy)을 가장 핵심적인 요소로 식별하고 동시에 세부 사항(Detail)은 정책에 무관하게 만들어 이를 결정하는 일은 연기할 수 있게 한다. 더 구체적으로 보면, 정책, 레벨, 그리고 각각의 업무 원칙들을 어떻게 구획을 나누어 컴포넌트로 분리하는지에 대한 결합 분리(Decoupling, 디커플링)에대해 설명한다. 책에서 결국 주장하고자 하는 클린 아키텍처는 핵심 업무 규칙에 가장 엔터프라이즈 업무 규칙을 엔터티로 구분하고 이를 사용하여 구현하는 어플레케이션 업무 규칙을 유스 케이스 계층으로 본다. 이를 외부에서 사용하기 편하게 변환할 인터페이스 어댑터가 그 다음 계층이며 세부 사항인 외부 인터페이스를 프레임워크와 드라이버로 구분한다.
책에서는 좋은 아키텍처는 시스템이 모노리틱 구조(Monolithic Structure)로 태어나서 단일 파일로 배포되더라도, 이후에는 독립적으로 배포 가능한 단위들의 집합으로 성장하고 또 독립적인 서비스나 마이크로서비스 수준까지 성장할 수 있도록 만들어져야 한다고 이야기 한다. 각각의 상세 사항을 살펴 보자.
15장 아키텍처란
이책의 영어 원제는 Clean Architecture: a craftsman's guide to software structure and design 이다. 즉, 소프트웨어 크래트맨쉽을 강조하는 저자의 경험으로 소프트웨어 구조와 설계에 대한 가이드로서 아키텍처를 논하는 것이라 볼수 있다. 그래서, 저자는 아키텍트가 개발을 계속해야 한다고 한다. 이 부분에 대해서는 이견이 있을 수 있다.
저자는 소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태라고 한다. 이 형태는 개발, 배포, 운영, 유지보수되도록 만들어진다고 한다. 이러한 일을 용이하게 만들기 위해서는 가능한 한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다고 이야기 한다.
개발: 팀 구조가 다르다면 아키텍처 관련 결정에서도 차이가 난다. 이를 콘웨이의 법칙으로 연결하여 설명하였다.
배포: 배포 비용이 높을수록 시스템의 유용성은 떨어진다. 따라서 소프트웨어 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는 데 그 목표를 두어야 한다.
운영: 아키텍처가 시스템 운영에 미치는 영향은 개발, 배포, 유지보수에 미치는 영향보다는 덜 극적이다. 운영에서 겪는 대다수의 어려움은 단순히 하드웨어를 더 투입해서 해결할 수 있다. 이는 인터넷 서비스를 기준으로 하는 이야기로 보이며, 실재로 휴대폰과 같은 제품을 목표라면 제품의 비용이 적게 해야 할 수 있다. 하드웨어는 값싸고 인력은 비싸다는 말이 뜻하는 바는 운영을 방해하는 아키텍쳐가 개발, 배포, 유지보수를 방해하는 아키텍쳐보다는 비용이 덜 든다는 것이다. 즉, 인력/하드웨어 보다는 비용 측면에서 고려해야 하지 않을까? 상황에 따라 사람이 비쌀 때도 혹은 프러덕트의 다른 요소의 비용이 높을 수도 있다고 생각한다.
유지보수: 유지보수는 모든 측면에서 봤을 때 소프트웨어 시스템에서 비용이 가장 많이 든다. 새로운 기능은 끝도 없이 행진하듯 발생하고 뒤따라서 발생하는 결함은 피할 수 없으며, 결함을 수정하는 데도 엄청난 인적 자원이 소모된다.
모든 소프트웨어 시스템은 주요한 두 가지 구성요소로 분해할 수 있다. 바로 정책(Polciy)과 세부사항(Detail)이다. 정책 요소는 모든 업무 규칙(Business Rules)과 업무 절차(Procuedures)를 구체화 한다. 정책이란 시스템의 진정한 가치가 살아 있는 곳이다. 세부사항은 사람, 외부 시스템, 플그래머가 정책과 소통할 대 필요한 요소지만, 정책이 가진 행위에는 조금도 영향을 미치지 않는다. 이러한 세부 사항에는 입출력 장치, 데이터 베이스, 웹 시스템, 서버, 프레임워크, 통신 프로토콜 등이 있다.
아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는 데 있다. 세부사항을 결정하는 일은 미루거나 연기할 수 있게 된다. 요점을 파악했을 것이다. 세부사항에 몰두하지 않은 채 고수준의 정책을 만들 수 있다면, 이러한 세부사항에 대한 결정을 오랫동안 미루거나 연기할 수 있다. 이러한 결정을 더 오래 참을 수 있다면, 더 많은 정보를 얻을 수 있고, 이를 기초로 제대로 된 결정을 내릴 수 있다. 선택 사항을 더 오랫동안 열어 둘 수 있다면 더 많은 실험을 해볼 수 있고 더 많은 것을 시도할 수 있다. 그리고 결정을 더 이상 연기할 수 없는 순간이 닥쳤을 대 이러한 실험과 시도 덕분에 더 많은 정보를 획득한 상태일 것이다. 좋은 아키텍트는 결정되지 않은 사항의 수를 최대화 한다.
16장 독립성.
좋은 아키텍처는 결국은 요구 사항을 지원해야 한다. 클린 아키텍처에서도 이 요구 사항을 시스템의 유스케이스를 지원해야 한다고 이야기 한다. 여기에 추가로 아키텍처는 이전에 이야기 한 프러덕트의 라이프 싸이클 중에서 유지 보수를 제외한 운영, 개발, 배포 관점에서도 지원해야 한다고 이야기 한다.
어쩌 보면, 아키텍처는 시스템의 행위에 그다지 큰 영향을 주지 않는다. 다른 말로 행위와 관련하여 아키텍처가 열어 둘 수 있는 선택사항은 거의 없다. 좋은 아키텍처가 행위를 지원하기 위해 할 수 있는 일 중 에서 가장 중요한 사항은 행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아 볼 수 있게 만드는 것이다. 이 부분은 뒤에도 나오지만, "소리치는 아키텍처"로 다르게 표현하기도 한다.
아키텍처를 구조적인 분리로 보면, 계층(Layer)와 유스 케이스(Use Case) 차원에서 분리로 볼 수 있다. 계층 디커플링/결합 분리 (Decoupling Layers) 측면에서 보면, 사용자 인터페이스(User Interface, UI)가 변경되는 이유는 업무 규칙(Business Rule)과는 아무런 관련이 없다. 만약 유스케이스가 두 가지 요소를 모두 포함한다면, 뛰어난 아키텍트는 유스케이스에서 UI부분과 업무 규칙 부분을 서로 분리하고자 할 것이다.
업무 규칙은 그 자체가 애플리케이션과 밀접한 관련이 있거나, 혹은 더 범용적일 수도 있다. 예를 들어 입력 필드 유효성 검사는 애플리케이션 자체와 밀접하게 관련된 업무 규칙이다. 계좌의 이자 계산이나 재고품 집계는 업무 도메인에 더 밀접하게 연관된 업무 규칙이다. 이들 서로 다른 두 유형의 규칙은 각자 다른 속도로 그리고 다른 이유로 변경될 것이다. 이들 규칙은 서로 분리하고, 독립적으로 변경할 수 있도록 만들어야 한다. 즉, 분리/디커플링 해야 한다.
서로 다른 이유로 변경되는 것에 유스케이스 그 자체가 포함된다. 이를 유스 케이스 디커플링 (Decoupling Use Cases)이라고 한다. 주문 입력 시스템에서 주문을 추가하는 유스케이스는 주문을 삭제하는 유스케이스와는 틀림없이 다른 속도로 그리고 다른 이유로 변경된다. 유스케이스는 시스템을 분할하는 매우 자연스러운 방법이라고 설명한다.
결합 분리/디커플링(Decoupling)[1]
이렇게 분리된 컴포넌트를 서로 다른 서버에서 실행해야 하는 상황이라면, 이들 컴포넌트가 단일 프로세서의 동일한 주소 공간에 함께 상주하는 형태로 만들어져서는 안 된다. 분리된 컴포넌트는 반드시 독립된 서비스가 되어야 하고 일종의 네트워크를 통해 서로 통신해야 한다. 많은 아키텍트가 이러한 컴포넌트를 '서비스(Service)' 또는 '마이크로서비스(Microservice)라고 하는데, 그 구분 기준은 모호한 면이 있다. 실제로 서비스에 기반한 아키텍처를 흔히들 서비스 지향 아키텍처(Service-oriented architecture SOA)라고 부른다.
17장 경계: 선 긋기
소프트웨어 아키텍처는 선을 긋는 기술이며, 저자는 이 선을 경계(boundary)라고 부른다. 경계는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다. 아키텍트가 내리는 경계의 결정이 핵심적인 업무 로직을 오염시키지 못하게 만들려는 목적으로 쓰인다. 그러면서, 이케텍트의 목표는 필요한 시스템을 만들고 유지하는 데 드는 인적 자원을 최소화하는 것이라는 사실을 상기하자. 로버트 마틴은 인적 자원이 가장 비싼 자원으로 보고 있다.
어떤 종류의 결정이 이른 결정일까? 바로 시스템의 업무 요구사항, 즉 유스케이스와 아무런 관련이 없는 결정이다. 프레임워크, 데이터베이스, 웹 서버, 유틸리티 라이브러리, 의존성 주입에 대한 결정 등이 여기 포함된다.
어떤게 선을 그을까? 그리고 언제 그을까? 이와 관련된 답으로는 관련이 있는 것과 없는 것 사이에 선을 긋는 것이 기본 규칙이라 할 수 있다. GUI는 업무 규칙과는 관련 없기 때문에, 이 둘 사이에는 반드시 선이 있어야 한다. 데이터베이스는 GUI와는 관련이 없으므로, 이 둘 사이에도 반드시 선이 있어야 한다. 데이터베이스는 업무 규칙과 관련이 없으므로, 이 둘 사이에도 선이 있어야 한다.
업무 규칙(Business Rules)에 플러그인으로 연결하기[1]
두 컴포넌트 사이에 이러한 경계선을 그리고 화살표의 방향이 Business Rules를 향하도록 만들었으므로, Busines Reules에서는 어떤 종류의 데이터 베이스도 사용할 수 있음을 알 수 있다. Database 컴포넌트는 다양한 구현체로 교체될 수 있으며, Business Rules는 조금도 개의치 않는다. GUI는 다른 종류의 인터페이스로 얼마든지 교체할 수 있으며 BusinessRules는 전혀 개의치 않는다는 사실을 알 수 있다. 데이터베이스와 GUI에 대해 내린 두 가지 결정을 하나로 합쳐서 보면 컴포넌트 추가와 관련한 일종의 패턴, 즉, 플러그인 아키텍처가 만들어진다.
18장 경계 해부학(Boundary Anatomy)
위와 같이 분리된 일련의 소프트웨어 컴포넌트와 그 컴포넌트들을 분리하는 경계를 통해서 시스템 아키텍처가 정의 된다. 런타임에 경계를 횡단한다함은 그저 경계 한쪽에 있는 기능에서 반대편 기능을 호출하여 데이터를 전달하는 일에 불과하다. 적절한 위치에서 경계를 횡단하게 하는 비결은 소스 코드 의존성 관리에 있다.
단일체로 변역하는 모노리틱(Monolithic) 구조는 쉽게 이야기 하면, 단일 실행 파일에 지나지 않는다. 이 파일은 정적으로 링크된 C/C++ 프로젝트이거나, 실행 가능한 jar 파일로 묶인 일련의 자바 클래스 파일이거나, 단일 .EXE파일로 묶인 일련의 .NET 바이너리등일 것이다.
배포형 컴포넌트(library, jar, DLL), 스레드, 로컬 프로세스(OS상의 Process), 서비스(물리적으로도 분리된 컴퓨팅 리소스에서 동작) 등으로 컴포넌트들을 분리하는 방법들이 있을 수 있다.
19장 정책과 수준
소프트웨어 시스템이란 정책(Policy)을 기술한 것이다. 실제로 컴퓨터 프로그램의 핵심부는 이게 전부다. 컴포터 프로그램은 각 입력을 출력으로 변환하는 정책을 상세하게 기술한 설명서다. 대다수의 주요 시스템에서 하나의 정책은 이 정책을 서술하는 여러 개의 조그만 정책들로 쪼갤 수 있다. 예를 들어 집계와 관련된 업무 규칙을 처리하는 방식을 서술하는 조그만 정책이 있을 수 있다. 그리고 특정 보고서를 어떤 포맷으로 만들지 서술하는 또 다른 정책이 있을 수 있다. 또한 입력 데이터를 어떻게 검증할지를 서술하는 정책이 있을 수 있다.
수준(Level)을 엄밀하게 정의하자면 '입력과 출력까지의 거리'다. 시스템의 입력과 출력 모두로 부터 멀리 위치할 수록 정책의 수준은 높아진다. 입력과 출력을 다르는 정책이라면 시스템에서 최하위 수준에 위치한다.
정책을 컴포넌트로 묶는 기준은 정책이 변경되는 방식에 달려 있다는 사실을 상기하자. 단일 책임 원칙(SRP)와 공통 폐쇄 원칙(CCP)에 따르면 동일한 이유로 동일한 시점에 변경되는 정책은 함께 묶인다. 고수준 정책, 즉 입력과 출력에 서부터 멀리 떨어진 정책은 저수준 정책에 비해 덜 빈번하게 변경되고, 보다 중요한 이유러 변경되는 경향이 있다.저수준 정책, 즉 입력과 출력에 가까이 위치한 정책은 더 빈번하게 변경되며, 보다 긴급성을 요하며, 덜 중요한 이유로 변경되는 경향이 있다.
이처럼 모든 소스 코드 의존성의 방향이 고수준 정책을 향할 수 있도록 정책을 분리했다면 변경의 영향도를 줄일 수 있다. 시스템의 최저 수준에서 중요하지 않지만 긴급한 변경이 발생하더라도, 보다 높은 위치의중요한 수준에 미치는영향은 거의 없게 된다.
20장 업무 규칙
업무 규칙(Business Rules)은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다. 더 엄밀하게 말하면 컴퓨터 상으로 구현했는지와 상관없이, 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있어야 한다. 심지어 사람이 수동으로 직접 수행하더라도 마찬가지다. 이러한 규칙을 핵심 업무 규칙(Criticial Business Rule)이라고 부를 것이다. 왜나하면 이들 규칙은 사업 자체에 핵심적이며, 규칙을 자동화하는 시스템이 업서라도 업무 규칙은 그대로 존재하기 때문이다. 핵심 업무 규칙은 데이터를 요구하는데, 책에서는 이를 핵심 업무 데이터(Critical Business Data)라고 부르고 있다.
핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 좋은 후보가 된다. 우리는 이러한 유형의 객체를 엔티티(Entity)라고 부른다.
유스케이스 자동화된 시스템이 동작하는 방법을 정의하고 제약함으로써수익을 더거나 비용을 줄이는 업무 규칙도 존재한다. 바로 이것이 유스케이스(Use case)다. 유스케이스는 애플리케이션에 특화된 업무 규칙(Application-specific Business Rules)을 설명한다.
21장: 소리치는 아키텍처
여러분의 애플리케이션 아키텍처는 뭐라고 소리치는가? 상위 수준의 디렉터리 구조, 최상위 패키지에 담긴 소스 파일을 볼 때, 시스템의 본질을 이야기 하는가? 즉, "핼스 케어 시스템이야" 또는 "재고 관리 스스템이야"라고 소리치는가? 아니면 사용하고 있는 디테일인 프레임워크에 대해서 이야기 하고 있는가? 예를 들자면, "레일스(Rails)야", "스프링(Spring)/하이버네이트(Hibernate)야", 아니면 "ASP야"라고 소리치는가?
책에서는 좋은 아키텍처는 유스케이스를 그 중심에 두기 때문에, 프레임워크나 도구 환경에 전혀 구애받지 않고 유스케이스를 지원하는 구조를 아무런 문제 없이 기술 할 수 있다고 이야기 한다. 좋은 소프트웨어 아키텍처는 프레임워크, 데이터베이스, 웹 서버, 그리고 여타 개발 환경 문제나 도구에 대해서는 결정을 미룰 수 있도록 만든다.
프레임워크는 열어 둬야 할 선택사항이다. 좋은 아키텍처는 프로젝트의 훨씬 후반까지 레일스, 스프링, 하이버네이트, 톰갯(Tomcat), MySQL에 대한 결정을 하지 않아도 되도록 해준다. 프레임워크, 데이터베이스, 웹 서버, 여타 개발환경 문제나 도구에 대한 결정을 미룰 수 있어야 한다. 프레임워크는 매우 강력하고 상당히 유용할 수 있다. 하지만, 프레임워크는 도구일 뿐, 삶의 방식은 아니다.
22장: 클린 아키텍처
책에서는 다른 아키텍처 접근 방법에 대해서 설명한다. 이 접근 법들도 목표가 같은데, 바로 관심사의 분리(Seperation of concerns)다. 모두 소프트웨어를 계층으로 분리함으로써 이 관심사의 분리라는 목표를 달성한다고 한다.
이들 아키텍처는 모두 시스템이 다음과 같은 특징을 지니도록 만든다. . 프레임워크 독립성 . 테스트 용이성 . UI 독립성 . 데이터베이스 독립성 . 모든 외부 에이전시에 대한 독립성
아래 다이어그램은 이들 아키텍처 전부를 실행 가능한 하나의 아이디어로 통합하려는 시도라고 이야기 한다. 즉, 핵심 개념도로 볼 수 있으며 지금까지 이야기 한 부분에 대한 큰 그림으로 이해할 수 있다.
클린 아키텍처[1]
의존성 규칙
클린 아키텍어 다이어 그램에서 안으로 들어갈 수록 고수준의 소프트웨어가 된다. 바깥쪽 원은 메커니즘이고 안쪽 원은 정책이다. 여기서 가장 중요한 규칙은 의존성 규칙(Dependency Rule)이다. 즉, 소스코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다. 내부의 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못한다. 함수, 클래스, 변수, 그리고 소프트웨어 엔티티로 명명되는 모든 것이 포함된다. 같은 이유로, 외부의 원에서 선언된 데이터 형식도 (Data Type)도 내부의 원에서 절대로 사용해서는 안 된다.
엔티티
엔티티는 전사적인 핵심 업무 규칙을 캡슐화한다. 엔티티는 메서드를 가지는 객체이거나 일련의 데이터 구조와 함수의 집합이다. 운영 관점에서 특정 애플리케이션에 무언가 변경이 필요하더라도 엔티티 계층에는 절대로 영향을 주어서는 안 된다.
인터페이스 어댑터
인터페이스 어댑터(Interface Adapter) 계층은 일련의 어댑터들로 구성된다. 어댑터는 데이터를 유스케이스와 인터티에게 가장 편리한 형식에서 데이터베이스나 웹 같은 외부 에이전시에게 가장 편리한 형식으로 변환한다. GUI의 MVC 아키텍처를 모두 포괄한다. 프레젠터(Presenter), 뷰(View), 컨트롤러(Controller)는 이 계층에 속한다. 모델은 그저 이 계층에서 사용되는 데이터 구조로 보면 된다.
프레임워크와 드라이버
클린 아키텍처 그림에서 가장 바깥쪽 계층은 일반적으로 데이터베이스나 웹 프레임워크 같은 프레임워크나 도구들로 구성 된다. 이는 안쪽 원과 통신하기 위한 접합 코드로 볼 수 있다.
원은 네 개여야만 하나?
이 다이어 그램은 개념을 설명하기 위한 하나의 예시로, 실재 시스템에서는 더 많은 원이 필요할 수도 있다. 하지만, 어떤 경우에도 의존성 규칙은 적용된다. 소스 코드 의존성은 항상 안쪽으로 향한다. 안쪽으로 이동할 수록 추상화와 정책의 수준은 높아진다. 가장 바깥쪽 원은 저수준의 구체적인 세부사항으로 구성된다.
경계 횡단하기
그림의 우측 하단 다이어그램에 원의 경계를 횡단하는 방법을 보여 주는 예시가 있다. 컨트롤러와 프레젠터가 다음 계층에 속한 유스케이스와 통신하는 모습을 확인할 수 있다. 우선 제어흐름에 주목해 보자. 제어흐름은 컨트롤러에서 시작해서, 유스케이스를 지난후, 프레젠터에서 실행되면서 마무리 된다. 이와 상반되게 의존성은 반대이다.이와 같은 경우, 대체로 의존성 역전 원칙을 사용하여 해결한다.
경계를 가로지르는 데이터는 흔히 간단한 데이터 구조로 이루어져 있다. 기본적인 구조체나 간단한 데이터 전송 객체(Data Transfer Object)등 원하는 대로 고를 수 있다. 또는 함수를 호출할 때 간단한 인자를 사용해서 데이터로 전달할 수도 있다. 그게 아니라면 데이터를 해시맵으로 묶거나 객체로 구성할 수도 있다.
전형적인 시나리오
이 클린 아키텍처의 예로서 전형 적인 웹 서비스 아키텍처를 아래 그림에서 살펴 볼 수 있다. 웹 서버는 사용자로 부터 입력 데이터를 모아서 좌측 상단의 Controller로 전달한다. Controller는 데이터를 평범한 자바객체(POJO)로 묶은 후, InputBoundary 이터페이스를 통해 UseCaseInsteractor로 전달한다. UseCaseInteractor는 이 데이터를 해석해서 Entities가 어떻게 춤출지를 제어하는데 사용한다.
전형적 웹 서비스 구조[1]
결론
클린 아키텍처에서 주장하는 가장 핵심 적인 것을 보통 클린 아키텍처 다이어 그램에서 이야기 하는 4가지 영역의 분리라고 볼 수 있다. 서론에서도 이야기 했듯이 아키텍처의 구조적인 측면에서 경계(Boundary)를 만드는 것이 가장 중요한 일일 수 있다. 다른 말로 관심사의 분리(Separation of Concern)이라고도 했다.
이 분리의 주된 목적은 변경이 필요할 때, 영향을 받지 않는 부분을 분리하자는 것이다. 이렇게 하기 위해 가장 먼저 분리 한 것은 정책(Policy)와 세부 사항(Detail)이다. 그림에서는 프레임워크/드라이버와 나머지가 분리되었다고 볼 수 있다. 정책에서는 업무 규칙 중에서도 유스 케이스에서 더 핵심적인 것을 분리해서 엔터프라이즈 업무 규칙과 유스 케이스 업무 규칙이 분리되고 이 것들이 외부의 세부 사항과 연결하기 위한 영역으로 인터페이스 어댑터를 둔 것으로 볼 수 있다.
이 구조에서 가장 중요한 원칙이 의존성 규칙이라고 했다. 즉, 내부 영역이 외부 영역에 의존하면 안되고 몰라야 한다는 것이다. 혹시 제어 흐름이 반대인 것은 의존성 역전 원칙(DIP)를 적용하는 것도 언급하였다. 이렇게 하면서, 세부 사항들은 늦게 결정하도록 하면서 여러 시험을 통해 더 좋은 선택을 할 수 있게 한다고 이야기 하고 이 것이 좋은 아키텍처, 클린 아키테처라고 주장한다.
애자일과 소프트웨어 크래프트맵쉽을 중시하는 저자의 철학과 연결되는 것이 제품/프러덕트가 모노리틱 구조(Monolithic Structure)로 태어나고, 성장하고, 분화 한다고 이야기로 보인다. 이렇게 분화한 것이 독립적인 서비스(Service Oriented Architecture, SOA)나 마이크로서비스(Microservice Architecture)가 된다고 한다.
참고 문헌
[1] 로버트 C. 마틴 저, "클린 아키텍처 소프트웨어 구조와 설계의 원칙" 인사이트(insight) 2019년 08월 20일, 송준이 역
이 글은 재미있고, 꽤 알려진 애자일의 법칙들을 모아 놓은 글이다. 사실 이야기를 기존에 알고 있던 것은 콘웨이 법칙 뿐이었고 내용을 들은 것은 "프로젝트가 지연될 때 인력을 추가하면 더 늦어 진다"라는 것인데, 이 것이 맨먼스 미신의 저자인 브룩의 법칙이라고 불리는지 몰랐다. 또한, 다른 법칙들도 통찰이 있는 말들이다. 그래서, 곱씹어 보고 생각도 해볼 만한 내용들이다.
글은 [1]에서 가져온 것이다.
애자일 법칙: 콘웨이, 브룩, 해크먼, 굿하트, 라만 그리고 파킨슨 법칙
심리학, 조직 설계 또는 소프트웨어 공학의 관찰, 휴리스틱 및 멘탈 모델의 긴 리스트의 분야에서 분산 애자일 팀과 특히 관련이있는 6 가지 "애자일 법칙"을 선정한다.
콘웨이의 법칙
멜 콘웨이(Mel Conway)는 1968년 그의 논문에서 처음으로 다음과 같이 주장했다.
"(광범위하게 정의된) 시스템을 설계하는 조직은 조직의 커뮤니케이션 구조의 동일한 구조를 가지는 시스템 디자인을 만든다." (출처.)
다시 말해, 두 팀이 응용 프로그램의 일부를 별도로 구축하는 경우 해당 시스템에는 두 가지 구성 요소가 있을 수 있으며 이로 인해 종속성과 추가 통신 오버 헤드가 발생한다.
그것은 항상 도전이었다. 팀이 함께 있으면 커피 또는 워터 쿨러를 통해 비공식적으로 문제를 협상할 수 있다. 분산 된 팀의 경우 기회가 줄어 들고, 추가적인 커뮤니케이션 오버 헤드가 발생하며, 또한 추가적인 원격 회의를 공식적으로 진행해야 한다.
이를 분산된 애자일 팀에 적용하려면 중간 관리자와 조직이 맏닥뜨린 실제 또는 인지된 위기로 돌아가야 한다. 원격 및 종종 비동기식 통신으로 인해 감지된 통제력 상실과 통신 문제에 대해서 가시성을 확보하려는 충동은 더 많은 보고서, 더 많은 지표 및 더 많은 회의와 같이 더 타이트하게 조직을 운영하려는 경향이 있다.
이제 조직이 유연하면서도 탄력적인 조직 구조를 만드는 데 실패하는 이유가 무엇인지 물어볼 수 있다. 크레이그 라만(Craig Larman)은 그 이유를 다음과 같이 공식화하여 만들었다.
"조직은 중간 및 1차 관리자 와"전문가"직위 및 권력 구조를 현 상태에서변경하지 않도록 암묵적으로 최적화되어 있다." (출처.)
이 관찰은 변화에 대한 시스템 사고 방식을 반영한다. 사람들의 행동을 바꾸려면 먼저 시스템을 변경해야 한다. 기본 시스템을 변경하지 않고 조직의 문화를 변경하려는 시도는 실패한다. 따라서 위기에 대응하기 위해 현재 부과된 변화의 필요성은 단순히 운영 또는 전술적 절차가 아닌 시스템 자체를 목표로 해야한다.
파킨슨의 법칙
애자일 팀에서 시간 제한이 그토록 가치있는 관행 인 이유는 간단하다. "작업은 완료 할 수있는 시간을 채우기 위해 확장된다.(Work expands so as to fill the time available for its completion)" (Parkinson의 법칙.)
복잡한 환경에서 가치 있고 지속 가능하며 수익성이있는 제품을 만들려고 할 때 빠른 피드백 루프가 필수적이다. 구축, 측정, 학습. 출시 전에 너무 오래 기다리거나 완벽을 추구하는 것은 선택 사항이 아니다. 대신 스프린트, 사이클, 반복, 검사 및 적응이 사용되는 실천 사항들의 이름이다. 우리는 시장과 동기화 할 수있을 만큼 빠르게 반복하는 것을 목표로하지만 너무 짧은 스프린트로 너무 많은 오버 헤드를 피하는 것을 목표로 한다.
분산된 애자일 팀의 문제는 출시 루틴이 때로 학습 부분보다 더 가치가 높은 경향이 있다는 것이다. 물론 "학습"은 원격 환경에서 더 어렵지만 불가능하지는 않다. 그러나 불확실성을 해결하기 위한 행동에 대한 편견을 완화하기 위해 출시 부분에 초점을 맞추면서, 우리는 고객을 대신하여 문제를 해결하는 자율팀 팀을 구성하는 것과 반대되는 기능 공장이되는 데 더 가까워지고 있다.
애자일 법칙-결론
분산된 애자일 팀으로 일하는 것은 많은 조직에서 기존의 조직, 기술 및 문화적 문제를 증폭한다. 그런 점에서 '애자일 법칙'을 재검토하는 것은 이러한 장애를 해결하는 데 도움이되는 것으로 입증되었다. 아마도 이러한 문제를 유리하게 사용할 수도 있다. 사람들이 말하듯이, "모든 문제는 기회이다.(Every problem is an opportunity.)"
최근에 이러한 애자일 법칙을 경험 한 적이 있는가? 그렇다면 우리와 당신의 의견을 공유부탁한다.
번역을 마치고...
서두에도 적었지만, 알고 있었지만 출처가 불명확했던 것들도 많이 있다. 이러한 원칙들을 살펴 보는 것은 실재로 조직을 애자일하게 운영하는데 도움이 되는 기본 원리를 이해하는데도 도움이 된다고 볼 수 있다.
나는 사람들이 시도하고 종종 실패함에 따라 OKR을 구현하는 핵심에 대해 최근에 많은 좋은 대화를 나누었다. OKR 사용시 문제로 이어지는 패턴이 있다.
분기당 OKR을 너무 많이 설정했다.
하나만 설정하자. 구글은 검색 엔진과 브라우저를 개발하고 소셜 네트워크 서비스를 하며 자율 주행 차를 만들려고하기 때문에 회사에 여러 OKR이 필요하다. 그들이 "모든 제품을 최고로 사회적이 되도록 만들기(Make all products supremely social)"라는 단일 목표를 설정했다고 상상해보자. 자율 주행 자동차 개발 하는 사람들은 키트(나이트 라이더 드라마 참조)를 만는 것일 수 있다. 그러나 대부분의 회사 (그리고 다른 모든 스타트업)은 하나의 대담한 OKR을 통해 조직을 통합하고 노력이 투여 되도록 한다.
일주일 또는 한 달 동안의 OKR을 설정한다.
나는 스타트 업의 목표(Objective)가 “제품/시장 적합성 찾기(find product/market fit)”가 아니라면, 제품/시장 적합성(product/market fit)을 달성하기 전에 OKR을 사용해야한다고 완전히 확신하지는 못한다. 일주일 이상 추적 할 수 없다면 아마도 OKR을 할 준비가되지 않은 것이다. 제품/시장에 적합을 찾고 있다면, 3개월 전체에 걸쳐 진행하라. 결국, 그보다 짧은 시간 내에 할 수있는 진정 대담한 일은 무엇인가? 1 주일 안에 할 수 있다면 그 것은 그저 작업 일 것이다.
메트릭 기반 목표를 설정한다.
이것은 많은 경우 MBA로의 몰락이다. 당신은 숫자를 좋아한다. 당신은 돈을 사랑한다. 모두가 아닌가? OKR은 다분야 팀(multidisciplinary teams)을 통합하며 이는 꿈꾸는 디자이너, 이상주의 엔지니어 및 배려하는 고객 서비스를 의미한다. 목표는 영감을주는 것이어야하며, 사람들이 침대에서 뛰어 내려 새로운 하루와 새로운 도전에 대비할 수 있도록하는 콜 투 액션(call-to-action)하는 문장이어야 한다.
주요 결과가 결과(Results)가 아니라 작업(Task)이다.
OKR에 대한 이 글을 작성하고 처음 다시 읽었을 때 나는 약간의 불안감을 느꼈다. 주요 결과의 예제가 여기 저기에 있었기 때문이다. "온라인 코칭 리소스에서 교육 자료를 검토한다." 이 핵심 결과는작업이며 완료하는 데 한 분기가 소요되지 않는다. "주간 소통 회의 평가를 X %에서 Y %로 높인다."라는 KR은 적절하다. 핵심 결과(Key Result)는 당신이하는 일이 아니라 당신이 한 일 때문에 일어난 일이다. 작업(Task)는 주간 우선 순위 목록에 저장해 두자.
확신 수준(confidence level)을 설정하지 않는다.
핵심 결과(Key Results)의 70 %를 달성 할 것으로 예상한다는 이야기를 많이 듣는다. 그래서, 사람들이 목표 두 개를 쉽게 설정하고 하나를 엄청나게 어렵게 만드는 회사의 사례를 많이 들었다. 요점은 이것이 아니다. OKR은 문 샷(Moon shot)를 하도록 격려하기 위해 있다. 당신이 진정 무엇을 할 수 있는지 보여주기 위한 것이다.
확신 수준을 10 점 만점에 5 점으로 설정하면 목표를 달성 할 확률이 50 %입니다. 그것은 자신의 목표를 스트레칭하는 것이다.
변화하는 확신 수준(confidence level)을 추적하지 않는다.
분기의 마지막 달에 와서 갑자기 OKR에 주의를 기울이는 것을 잊었다는 것을 깨닫는 것보다 더 짜증나는 것은 없다. 새로운 정보를 얻으면 변경 사항을 표시하자. 팀원에게 오랫동안 확신 수준이 5이었음을 상기시자. 도움을 제공하라.
논의가 필요한 것에 대해 토론하라. 우선 순위가 정말로 핵심 결과를 움직일까? 다가오는 프로젝트의 로드맵에 조정이 필요한가? 팀의 건강 상태는 어떻고 그 이유는 무엇인가?
당신은 금요일에 강하게 이야기한다.
우리는 일주일 내내 자신과 서로에게 강인하다. 우리가 한 일에 대해 맥주를 마시고 건배하자. 특히 주요 결과를 모두 달성하지 못할 경우, 큰 목표를 설정하여 달성 할 수 있었던 것이 무엇인지에 대해 자랑스럽게 생각하자.
OKR을 성과 검토(performance review)의 일부로 만든다.
Google에서 Zynga, Swipely에 이르기까지 모든 사람들이 이에 대해 경고한다. 사람들이 높은 목표를 달성하기를 원한다면 터무니없는 목표를 달성하지 못했다고 처벌 할 수 없다. 대신 직원은 주간 상태 메일과 OKR을 사용하여 자신이 수행 한 작업에 대한 자체 검토를 작성할 수 있다. 별을 노릴 때, 문 샷 프로젝트를 달성할 수 있다.
퀵 팁
여러 비즈니스 라인이없는 경우 회사에 대해 하나의 OKR 만 설정하라. 집중에 관한 것이다.
하나의 OKR에 한 분기(3 개월)을 할당하라. 일주일 안에 할 수 있다면 얼마나 대담할까?
목표(Objective)에서 지표가 멀어지게 하자. 목표(Objective)는 영감을주는 것이다.
주간 체크인에서 회사 OKR로 시작하고 그룹의 것을 만들자. 개인 별로 하나 하나 모든 처리하지 말자. 그것은 개인 1:1 미팅에서 하는 것이 더 좋다. 예를 들면, 당신은 매주 어떤 OKR을 가지는가가 1:1 미팅에서의 질문이 될 것이다.
OKR 캐스케이드디도록 하자. 회사 OKR, 그룹/역할, 개인 순으로 설정한다.
OKR은 당신이하는 유일한 일이 아니라 당신이해야하는 한가지 일이다. 사람들이 배를 계속 움직이기를 기대하자.
월요일 OKR 체크인은 대화이다. 확신 레벨, 건강 지표 및 우선 순위의 변화에 대해 논의하자.
직원이 회사 OKR을 제안하도록 장려하자. OKR은 단지 하향식으로 동작만하는 것이 아니라 상향식으로 동작하는 것도 훌륭하다.
이 글은 퍼스널 OKR 보다는 회사 OKR에 대한 것이라는 생각이 된다. 하지만, Key Results와 주간 타스크, 일일 타스크를 구분하는 것은 필요할 수 있겠다.
참고 문헌
[1] 크리스티나 워드케 (지은이),박수성 (옮긴이), "구글이 목표를 달성하는 방식 OKR", 한국경제신문 2018-11-23 원제 : Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results (2016년)
이글[1]은 [2]의 저자인 크리스티나 워드케가 블로그에 작성한 글이다. Personal OKR에 대해서 자신의 생각과 팁들을 정리한 글이다. 이 글 이후에 작성한 것도 있으니 참고하면 좋겠다.
Personal OKRs
나는 OKRS (Objectives and Key Results)에 열광한다. 나는 내가 함께 일하는 모든 스타트업에게 회사의 목표를 향해 나아가는 이 시스템을 전파해 왔으며 그 결과는 항상 인상적이다. 불완전하게 구현된 경우에도 회사가 필요로하는 소통와 생각을 만들어 낸다. 그래서 내 자신이 정체되고 개인적인 삶을 발전시킬 수 없다는 것을 알았을 때 즉시 제대로 돌려 놓지 못하는 것이 충격적입니다. 다행히도 저는 제 문제를 해결하기 위해 제 자신의 도구에 대해서 살펴 보도록 상기시켜 준 훌륭한 코치와 함께 하고 있었다.
그래서 먼저 1분기의 목표를 설정했다. 목표는 시간이 제한 될 때 항상 가장 잘 작동한다. 저는 3 개월이라는 시간 간격을 매우 좋아 한다. 중요한 일을 수행하기에 충분히 길고 긴박감을 느낄 수있을 만큼 짧다. 물론 회사는 분기에 매핑되기 때문에 좋아한다.
목표는 질적으로 높고 구체적이며 대담해야한다
나의 목표는 지속 가능한 행복한 삶을 구축하는 것이었다. 미안하지만, 너무 크고 모호하다! 그것은 인생의 사명에 가깝습니다. 그렇다면 3 개월 동안의 목표는 무엇일까?
목표(Objective) : 건강을 지키고 내가 좋아하는 일을하면서 재정적으로 안정되어야한다. 재정적 안정 : 최저 지출 수준 일 때 지출하는만큼 벌어들인다. 건강 유지 : 나는 끔찍한 위장과 허리 문제를 겪었다. 너무 많은 책상 시간. 스트레스로 인해 위통. 내가 좋아하는 일 : 돌아 보면, 이것은 나를 곤란하게 만들었다. 너무나 쿨하고 멋지다고 생각하는 일이 너무 많다. 지루하지 않기 위해서 내 건강을 해치는 일을 했다.
그래서 지금은 주요 결과(Key Results, KR)이 필요했다. 이 세 가지가 있으면 내 목표에 도달했음을 알수 있다.
KR : 월급을받지 않아도 다른 일을하면서 3 개월 동안 X를 벌기 KR : 확장을 예측하기 위한 관리 가능한 예산 보유 하기 KR : 위산 역류 없음, 요통 없음
X는 친절한 재정 어드바이져와 함께 내 인생을 평가했을 때 나온 결과가 적혀있는 봉투의 뒷면에 적혀있던 수치였다. 그러나 나는 재정 상태를 더 잘 측정하고 이를 Anthropologie(어떤 SNS 서비스 같은데 현재는 검색해도 옷 매장만 나옴)에서 언제 자랑 할 수 있는지 알기 위해 더 정확한 정보를 얻고 싶었다. 나는 내 예산을 한 번도 소진 한 적이 없지만 그것이 제 삶이 지속 가능한지 알 수있는 유일한 방법이라고 생각했습니다.
다음으로 계획이 필요했다. 나는 지난 분기에는 내 삶을 프로토타이핑하는데 사용했다. 이 때 컨설팅과 강의를 해봤는데 둘 다 재미 있었다. 그러나 컨설팅은 내가 감당할 수있는 것보다 더 많은 스트레스를 가져 왔지만 강의는 잘 되었다. 나는 또한 내 웰빙에 중요한 두 가지, 즉 달리기와 쓰기를 발견했다. 정신적 건강으로는 글쓰기 및 신체적 건강으로는 달리기가 큰 영향을 미쳤다. 나는 이제 행복한 밤이 어떤 모습인지에 대한 좋은 가설을 얻기도 했다.
그래서 나는 가르치고, 쓰고, 달리기를 해야했다.
그 시작점에서 나는 나를 목표로 이끌 수있는 많은 아이디어를 생각해 냈다. Dschool에서 찾아보고, General Assembly에서 더 많은 작업을 탐색하고, 함께 책을 쓰자는 제안을 받기도 했다. 최소한 돈이 쓰지 않고 발표를 할 방법을 찾았다. 나는 한덩어리로 구성된 계획(monolithic product plan) (어쨌든 거짓말 인 경향이 있음)을 피하고 대신 자주 평가할 수있는 프로젝트 모음을 만드는데 팬이 되었다. 그래서 저는 제가 시도 할 수있는 활동들을 모아서 순서를 정했다.
주간 보고: 그런 다음 대부분의 사람들이 이야기하지 않는 부분 (또는 가치)를 설정한다.
나는 내 경력을 쌓으면서 주간 보고서를 많이 작성해야했고, 이 보고서는 주로 나는 작성하고 싶지 않았고 상사가 읽고 싶지 않은 보통은 성가시고 지루한 잡무 목록이었다. 그러나 Zynga에서 우리는 이를 멋지게 만드는 방법을 배웠다. 그것은 중요한 변화를 가져온 것들을 추적하고 보고하는 것과 관련이있었다. 그 이후로 시간이 지남에 따라 적절히 조정하면서 컨설팅할 때에도 사용했다.
주간 보고 이메일 형식은 스탠드 업과 유사하다. 지난 주 한일, 다음 주 할일, 어려움이 있는 일을 이야기 하는 것이다. 이메일을 수신하는 사람이 꼭 알아야 할 사항인 "노트" 부분을 추가했다. 또한 각 항목에는 P1 (이번 주에 수행), P2 (가능한 경우 이번 주에 수행) 또는 P3 (고려)의 우선 순위가 있다.
각 섹션에는 3개의 P1 만 있을 수 있다. 두 개의 P2도 가질 수 있다. 아마도 P3도 있을 수 있다. 나는 그들을 상사에게 보내는 것을 아주 즐겼다. 그것은 우리의 우선 순위가 촘촘하게 목표와 맞춰 졌는지 확인했다. 내가 P1을 주었는데 / 상사가 P2라고 생각했다면, 각자가 작업의 긴급성에 대해 다르게 생각하는 이유에 대해 대화를 나눌 수 있었다.
P1은 중요한 것이다. 나는 등급 메기기(stack rank)의 엄청난 팬이다. 나는 모든 것에 순위를 매긴다. 이 방법은 명확성을 제공한다. 이것은 당신을 방종에서 보호한다. 이 것은 당신이 당신의 가치를 검토하게 만든다.
보고서의 지난 주 섹션에는 동의한 우선 순위와 완료 여부가 나열된다. 그렇지 않았다면 왜 안료 되지 않았는가? 무엇이 당신을 엉망으로 만드는 패턴인지 살펴 볼 수 있다.
어려움이 있는 일은 도움이 필요한 것이다. 속도를 늦추는 것들은 스스로 제거 할 수 없다.
자신이 해결하지 못하는 어려운 일을 직접 제거 할 수 있다면 그냥 제거하라. 이 보고서는 변명을위한 것이 아니라 실행을위한 것이다.
내 코치는 상사 대신 주간 보고 이메일 수신에 동의했다. 누군가에게 정직하게이메일을 보내는 것이 좋다.
나는 이미 이 실천에서 배우고 있다. 나는 책 제안이 얼마나 많은 작업이 필요로 하는지를 과소 평가했다는 것을 인정하고 목표를 책 쓰기에서 책의 개요 쓰기로 나의 목표를 바꾸었다. 날씨가 내 운동 일정에 영향을 미칠 것이라는 것을 깨달았고 이 부분에 대해 유연해 져야 했다. 가끔은 내가 바라는 것보다 더 많이 지키지 못한다는 것을 인정해야했고 그것을 이겨낼 방법을 찾아야 했다.
따라서 우리가 목표를 유지할 방법을 찾으려고 노력할 때 OKR을 고려하십시오. 연말의 큰 소원보다는 함께 할 수있는 계획은 어떠한가?
크리스티나 워드케가 Personal OKR을 하면서 참고할 수 있는 팁들이 있다. 분기별로 Objective를 세우고 Key Results들을 정의 한다. 이를 주간으로 진행하면서 마치 일을 하며 상사에게 보고하듯이 코치에게 조언을 받으면 실행하는 실제 방법에 대해 설명한다.
[2]크리스티나 워드케(지은이),박수성 (옮긴이), "구글이 목표를 달성하는 방식 OKR", 한국경제신문 2018-11-23 원제 : Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results (2016년)
Cleann Architecture[1]에서 컴포넌트는 배포 단위를 나타낸다. 즉, "시스템의 구성 요소"로 배포할 수 있는 "가장 작은 단위"로서, 자바의 경우 jar 파일이 루비에서는 gem파일 그리고, 닷넷에서는 DLL이 그것이라고 할 수 있다. 컴포넌트가 마지막에 어떤 형태로 배포되든, 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다. 즉, 팀이 개발하는 독립된 단위가 컴포넌트여야 한다.
이전에 이야기한 SOLID원칙이 벽과 방에 벽돌을 배치하는 방법을 알려 준다면, 여기서 이야기 하는 컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 설명해 주는 것이라 생각하면 된다고 한다.
주로 응집도(Cohesion)과 결합도 혹은 의존도(Coupling)에 대해서 논의 한다. 응집도는 관련된 것들이 모여 있도록 하는 법칙이다. 반대로 의존도는 관련 없는 것들을 분리하는 것이라고 볼 수 있다. 컴포넌트들이 관련 없을 수 없기 때문에 효과적으로 의존하도록 만든는 것이라 볼 수 있다.
재사용/릴리즈 등가 원칙은 너무 당연해 보인다. 소프트웨어 컴포넌트가 릴리스 절차를 통해 추척 관리되지 않거나 릴리스 번호가 부여되지 않는다면 해당 컴포넌트를 재사용하고 싶어도 할 수도 없고, 하지도 않을 것이다.
이 원칙을 소프트웨어 설계와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻한다. 단순히 뒤죽박죽 임의로 선택된 클래스와 모듈로 구성되어서는 안 된다. 컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적이 있어야 한다.
이 조언만으로는 클래스와 모듈을 단일 컴포넌트로 묶는 방법을 제대로 설명하기 힘들기에 이 조언이 약하다고 하는 것이다. 그렇더라도 이 원칙 자체는 중요하다. 이 원칙을 어기면 쉽게 발견할 수 있기 때문이다.
공통 폐쇄 원칙 (Common Closure Principle, CCP)
CCP는 "동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라. 서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라."라는 원칙이다.
이 원칙은 단일 책임 원칙(SRP)을 컴포넌트 관점에서 다시 쓴 것이다. 공동 폐쇄 원칙(CCP)에서도 마찬가지로 단일 컴포넌트(Component)는 변경이 이유가 여러 개 있어서는 안 된다고 말한다.
대다수의 애플리케이션에서 유지보수성(maintainability)은 재사용성보다 훨씬 중요하다. 애플리케이션에서 코드가 반드시 변경되어야 한다면, 이러한 변경이 여러 컴포넌트 도처에 분산되어 발생하기보다는, 차라리 변경 모두가 단일 컴포넌트에서 발생하는 편이 낫다. CCP는 같은 이유로 변경될 가능성이 있는 클래스는 모두 한곳으로 묶을 것을 권한다.
이 원칙은 개방 폐쇄 원칙(OCP)과도 밀접하게 관련되어 있다. 실제로 CCP에서 말하는 '폐쇄closure'는 OCP에서 말하는 '폐쇄closure'와 그 뜻이 같다. OCP에서는 클래스아 변경에는 닿혀 있고 확장에는 열려 있어야 한다고 말한다. 100%완전한 폐쇄란 불가능하므로 전략적으로 폐쇄해야 한다.
공통 재사용 원칙(Common Reuse Principle, CRP)
CRP는 "컴포넌트 사용자들은 필요하지 않은 것에 의존하게 강요하지 말라"라는 원칙이다.
공통 재사용 원칙(CRP)도 클래스와 모듈을 어느 컴포넌트에 위치시킬지 결정할 때 도움되는 원칙이다. CRP에서는 같이 재사용되는 경향이 있는 클래스와 모듈들은 같은 컴포넌트에 포함해야 한다고 말한다.
간단한 사례로 컨테이너 (Container) 클래스와 해당 클래스의 이터레이터(Iterator) 클래스를 들 수 있다. 이들 클래스는 서로 강하게 결합되어 있기 때문에 함께 재사용 된다. 따라서 이들 클래스는 반드시 동일한 컴포넌트에 위치해야 한다. 따라서 CRP는 어떤 클래스를 한데 묶어도 되는지 보다는, 어떤 크래스를 한데 묶어서는 안되는지에 대해서 훨씬 더 많은 것을 이야기 한다. CRP는 강하게 겨합되지 않은 클래스들을 동일한 컴포넌트에 위치시켜서는 안 된다고 말한다.
CRP는 SOLID의 인터페이스 분리 원칙(ISP)의 포괄적인 버전이라 할 수 있다. ISP는 사용하지 않은 메서드가 있는 클래스에 의존하지 말라고 조언한다. CRP는 사용하지 않는 클래스를 가진 컴포넌트에 의존하지 말라고 조언한다.
컴포넌트 응집도에 대한 균형 다이어그램
아마도 응집도에 관한 세원칙이 서로 상충된다. REP와 CCP는 포함(Inclusive)원칙이다. 즉, 두 원칙은 컴포넌트를 더욱 크게 만든다. CRP는 배제(exclusive)원칙이며, 컴포넌트를 더욱 작게 만든다.
컴포넌트응집도(Component Cohesion)[1]
원칙에 반대 위치에 있는 Edge에는 원칙을 따르지 않을 때 감수해야 하는 비용을 나타낸다. 즉, 위에 그림에서 오로지 REP와 CRP에만 중점을 두면, 사소한 변경이 생겼을 때 너무 많은 컴포넌트에 영향을 미친다. 반대로 CCP와 REP에만 과도하게집중하면 불필요한 릴리즈가 너무 빈번해 진다.
뛰어난 아키텍트라면 이 균형 삼각형애서 개발팀이 현재 관심을 기울이는 부분을 충족시키는 위치를 찾아야 하며 또한 시간이 흐르면서 개발팀이 주의를 기울이는 부분 역시 변한다는 사실도 이해하고 있어야 한다. 일반적으로 프로젝트는 삼각형의 오른쪽에서 시작하는 편이며, 이대는 오직 재사용성만 희생하면 된다. 프로젝트가 성숙하고,, 그 프로젝트로 부터 파생된 또 다른 프로젝트가 시작되면 프로젝트는 삼각혀엥서 점차 왼쪽으로 이동해 간다.
컴포넌트 결합
의존성 비순환 원칙(Acyclic Dependencies Principles, ADP)
ADP는 "컴포넌트 의존성 그래프에 순환(cycle)이 있어서는 안 된다"는 원칙이다.
숙취 증후군 the morning after syndrome'이라고 부른다. 퇴근 후, 이튿날 다른 사람의 작업으로 전혀 돌아가지 않는 경험을 말하는 것으로 많은 개발자가 동일한 소스 파일을 수정하는 환경에서 발생한다. 소수의 개발자로 구성된 상대적으로 작은 프로젝트에서는 이 증후군이 그다지 큰 문제가 되지 않는다.
이 문제의 해결책은 개발 환경을 릴리스 가능한 컴포넌트 단위로 분리하는 것이다. 컴포넌트가 새로 릴리스되어 사용할 수 있게 되면 다른 팀에서는 새 릴리스를 당장 적용할지를 결정해야 한다. 적용하지 않기로 했다면 그냥 과거 버전의 릴리스를 계속 사용한다. 이렇게 될 수 있다면, 어떤 팀도 다른 팀에 의해 좌우 되지 않는다. 특정 컴포넌트가 변경되더라도 다른 팀에 즉각 영향을 주지 않는다. 각 팀은 특정 컴포넌트가 새롭게 릴리스되면 자신의 컴포넌트를 해당 컴포넌트에 맞게 수정할 시기를 스스로 결정할 수 있다. 뿐만 아니라 통합은 작고 점진적으로 이뤄진다. 특정 시점에 모든 개발자가 한데 모여서 진행 중인 작업을 모두 통합하는 일은 사라진다.
이 절차가 성공적으로 동작하려면 컴포넌트 사이의 의존성 구조를 반드시 관리해야 한다. 의존성 구조에 순환이 있어서는 안 된다. 구조가 방향 그래프(Directed graph)이라고 하면, 컴포넌트는 정점(Vertex)에 해당하고, 의존성 관계는 방향이 있는 간선 (Directed edge)에 해당한다 볼 수 있다. 이렇게 비순환 방향 그래프(Directed Acyclic Graph, DAG)로 구조를 만들면 문제가 해결 된다. 이렇게 할 수 있는 두 가지 방법은 아래와 같다.
의존성 역전 원칙(DIP)을 적용한다.
Entities와 Authorizer가모두 의존하는 새로운 컴포넌트를 만든다.
안정된 의존성 원칙 (Stable Dependencies Principles, SDP)
SDP는 "안정성의 방향으로(더 안정된 쪽에) 의존하라"라는 원칙이다.
하나의 모듈에 누군가가 의존성을 매달아 버리면 이 모듈은 변경하기 어려워진다. 이 모듈에서는 단 한 줄의 코드도 변경되지 않았지만, 어느 순간 갑자기 해당 모듈을 변경하는 일이 상당히 도전적인 일이 되어 버리는 것이다.
안전성(Stability)이란 무엇인가? '쉽게 움직이지 않는'이라고 정의할 수 있다. 아래 그림5의 X는 안정된 컴포넌트다. 세 컴포넌트가 X에 의존하며, 따라서 X 컴포넌트는 변경하지 말아야 할 이유가 세 가지나 되기 때문이다. 이 경우 X는 세 컴포넌트를 책임진다(Responsible)라고 말한다. 반대로 X는 어디에도 의존하지 않으므로 X가 변경되도록 만들 수 있는 외적인 영향이 전혀 없다. 이 경우 X는 독립적이다(Independent)라고 말한다.
아래 그림의 Y는 상당히 불안정한 컴포넌트다. 어떤 컴포넌트도 Y에 의존하지 않으므로 Y는 책임성이 없다고 말할 수 있다. 또한 Y는 세 개의 컴포넌트에 의존하므로 변경이 발생할 수 있는 외부 요인이 세 가지다. 이 경우는 Y는 의존적이라고 말한다.
안정성(Stability)[1]
이와 같은 정의에서 안정성 지표는 아래와 같이 정의 될 수 있다.
Fan-in 안으로 들어오는 의존성
Fan-out 바깥으로 나가는 의존성
I(불안정성):I = Fan-out / (Fan-in + Fan-out) 이 지표는 [0,1] 범위의 값을 갖는다. 1이면 최고로 불안정한 상태이고, 0이면 최고로 안정된 상태
안정된 추상화 원칙(Stable Abstractions Principle, SAP)
SAP는 "컴포넌트 안정된 정도만큼만 추상화되어야 한다"라는 원칙이다.
안정된 추상화 원칙(Stable Abstractions Principle, SAP)은 안정성(Stability)과 추상화 정도(Abstractness) 사이의 관계가 정의 한다. 이 원칙은 한편으로는 안정된 컴포넌트는 추상 컴포넌트여야 하며, 이를 통해 안정성이 컴포넌트를 확장하는 일을 방해해서는 안 된다고 말한다.
추상화 정도 측정하기 위한 A지표는 컴포넌트의 추상화 정도를 측정한 값으로 다음과 같이 정의 될 수 있다.
Nc: 컴포넌트의 클래스 개수
Na: 컴포넌트의 추상 클래스와 인터페이스의 개수
A: 추상화 정도. A=Na/Nc" A가 0이면 컴포넌트에는 추상 클래스가 하나도 없다는 뜻이다. A가 1이면 컴포넌트는 오로지 추상 클래스만을 포함한다는 뜻이다.
주계열(the main sequence)
이제 안정성(I)과 추상화 정도(A) 사이의 관계를 정의해야 할 때가 왔다. 우선 고통의 구역과 쓸모 없는 구역을 살펴 보고, 주 계열(The main sequence)에 대해서 살펴 보자.
고통의 구역(Zone of Pain), (0,0) 주변 구역에 위치한 컴포넌트를 살펴보자. 이 컴포넌트는 매우 안정적이며 구체적이다. 일부 소프트웨어 엔티티는 고통의 구역에 위치하곤 한다. 데이터베이스 스키마가 한 예다. 데이터베이스 스키마는 변동성이 높기로 악명이 높으며, 극단적으로 구체적이며, 많은 컴포넌트가 여기에 의존한다. 유틸리티 라이브러리로 실제로는 변동성이 거의 없다. 변동성이 없는 컴포넌트는 (0,0)구역에 위치했더라도 해롭지 않다.
쓸모없는 구역(Zone of Uselessness), (1, 1) 주변의 컴포넌트를 생각해 보자. 이 영역도 바람직하지 않은데, 여기위치한 컴포넌트는 최고로 추상적이지만, 누구도 그 컴포넌트에 의존하지 않기 때문이다. 이러한 컴포넌트는 아무도 쓰지 않으므로 쓸모가 없다.
일반적으로 변동성이 큰 컴포넌트 대부분은 두 배제 구역으로부터 가능한 한 멀리 떨어뜨려야 한다. 각 배제 구역으로부터 최대한 멀리 떨어진 점의 궤적은 (1,0)과 (0,1)을 잇는 선분이다. 나는 이 선분을 주계열(Main Sequence)이라고 부른다.
여기서, 주계열과의 거리, 세 번째 지표가도출된다. 컴포넌트가 주계열 바로 위에 또는 가까이 있는 것이 바람직하다면 이 같은 이상적인 상태로 부터 컴포넌트가 얼마나 떨어져 있는지 특정하는 지표를 만들어 볼 수 있다.
D: 거리. = |A+I-1| 유효범위는 [0,1]
주 계열(Main Sequence)와 컴포넌트 산점도[1]
결론
Clearn Architecture에서 설명하는 응집도(Cohesion)와 관련된 REP, CRP, CCP원칙에 대해서 살펴 보았고, 응집도 균현 다이어그램을 살펴 보았다. 그리고, 결합도와 관련된 ADP에서는 어떻게 순환을 끊을 수 있는지 살펴 보았고, SDP와 SAP 원칙에서 분안정성(Instability)와 추상화 정도(Abstractness)의 관계를 통해서 주 계열(Main sequence)를 살펴 보았다.
참고문헌
[1] 로버트 C. 마틴 저, "클린 아키텍처 소프트웨어 구조와 설계의 원칙" 인사이트(insight) 2019년 08월 20일, 송준이 역
Clearn Architecture[1]에서는 좋은 소프트웨어 시스템은 깔끔한 코드(Clean Code)로 부터 시작한다고 이야기 한다. 이러한 코드들이 모여서 요소(Element)가 되는데 이를 건물에 보면 벽돌로 볼 수 있다. 좋은 벽돌로 좋은 아키텍처를 정의하는 원칙이 필요한데 그게 바로 SOLID라고 이야기 한다. 즉, SOLID 원칙은 함수와 데이터구조를 클래스로 배치하는 방법, 그리고 이들 클래스를 서로 결합하는 방법을 설명한다. 사실 SOLID 원칙은 "Design Pattern 첫 번째: Object Oriented Principles"[2]에서 Object Oriented Programming의 설계 원칙 중 하나로 다루었지만 여기서는 조금 더 다른 관점에서 다룬다.
원칙의 목적은 "중간 수준"의 소프트웨어 구조가 아래와 같도록 만드는데 있다.
변경에 유연하다.
이해하기 쉽다.
많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 된다.
S.O.L.I.D는 아래 다섯가지 원칙의 약자를 모은 것이다.
Single Responsibility Principle
Open Close Principle
Liskov Substitution Principle
Interface Seggregation Principle
Dependency Inversion Principle
책에서는 2004년 무렵, 레거시 코드 활용 전략의 저자 마이클 페더스(Michael Feathers)가 기존에 있던 원칙을 재배열하여 각 원칙의 첫 번째 글자들로 SOLID라는 단어를 만들었다고 한다. 각 원칙을 하나씩 살펴 보자.
단일 책임 원칙 (Single Responsibility Principle)
객체 지향 프로그래밍(Object Oriented Programming)에서 하나의 객체는 하나의 책임을 가진다는 원칙이다.
하나의 책임이라는 부분은 사실 모호한다. 어떤 클래스가 가지는 책임이 하나라는 것은 한가지 일만 한다고 하기에는 1차원 적인 것이 있다. 이 책에서는 최종 버전으로 "하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다."라고 이야기 한다. 모듈이 하나의 객체 혹은 소스 파일로 볼 수 있다. 여기서 액터는 개발자/팀이라고 볼 수 있다. 그렇다면, 하나의 소스 파일은 개발자/팀이 책임 져야 한다는 것이다. 분리된 팀이 하나의 소스 파일을 건드린다면 팀을 합치거나 혹은 파일을 분리해야 한다는 이야기로 이해할 수 있다.
책[1]의 예를 살펴 보자.
Employee Class [1]
calculatePay() 매서드는 회계팀에서 기능을 정의하며, CFO 보고를 위해 사용한다.
reportHours() 매서드는 인사팀에서 기능을 정의하고 사용하며, COO 보고를 위해 사용된다.
save 매서드는 데이터베이스 관리자(DBA)가 기능을 정의하고, CTO 보고를 위해 사용된다.
즉, 서로 다른 액터가 의존하는 경우는 많이 발생한다. SRP에 따르자면, 이 코드는 분리하라고 하는 것이다. 어떻게 분리할 수 있을까? 최종적으로는 2가지가 가능해 보인다.
이 해결책은 개발자가 세가지클래스를 인스턴스화하고 추적해야 한다는게 단점이다. 이럴 때, 흔히 쓰는 기법으로 파사드(Facade) 패턴이 있다. 아래 그림과 같이, EmployeeFacade에 코드는 거의 없다. 이 클래스는 세 클래스의 객체를생성하고, 요청된 메서드를 가지고 객체로 위임하는 일을 책임진다. 이렇기 때문에, Facade는 Architectural Composition이라고도 한다.
Facade Pattern[1]
Employee Data를 CFO에서 담당한다고 하면 Employee Facade Class로 가져올 수 있다면 구조는 조금 더 단순화 될 수 있다. 아래 구조가 최종 구조라고 하면, CFO는 Employee Class를 담당하고, COO는 HourReporter Class를 담당하며, CTO는 EmployeeSaver Class를 각각 담당하여 개발을 진행하면 SRP가 잘 유지되며 개발될 수 있다고 볼 수 있다. 이처럼 조직의 구조도 Software의 구조에 영향을 미친다.
Facade Pattern 두 번째[2]
개방-폐쇄 원칙 (Open Close Principle OCP)
개방-폐쇄 원칙(OCP)이라는 용어는 1988년 버트란드 마이어(Bertrand Meyer)가 만들었는데, 소프트웨어 개체(Artifact)는 확장에는 열려 있어야 하고(Open to Extension) 변경에는 닫혀 있어야 한다(Close to Modification)라는 원칙이다. 즉, 객체의 행위는 확장할 수 있어야 하지만, 이 때 개체를 변경해서는 안된다. 어찌 보면 모순 같은 이야기는 매우 중요한 원칙이기도 하다.
책에서는 여러 번 이야기 하지만, 변경이 되지 많아야 할 곳과 변경이 되는 것을 분리하고 변경이 되는 곳이 변경되지 않는 것에 종속되도록(Dependent)하도록 해야 한다는 것이다. 그리고, 이 변경 되는 쪽을 확장하는 쪽으로 쓰고 변경되지 않도록 하는 쪽은 한 곳으로 모아 두어야 한다는 원칙이다.
어떻게 이를 획득할 수 있을까? 책에서의 제무제표 웹 시스템에서는 그러한 예를 많이 보유하고 있다.
재무 제표 웹 시스템[1]
일반적인 방향성 제어의 방법에서는 위의 예에서 FinancialDataGateway 인터페이스는 FinacialReportGenerator와 FinancialDataMapper 사이에 위치하는데, 이는 의존성을 역전시키기 위해서이다. 만일 이러한 DataGateway가 없다면 FinancailReportGenerator Class는 Database Component에 의존하게 된다. 즉, Database가 SQL이었다고 다른 Database로 변경된다면 영향을 받고 변경될 가능성이 생기게 된다. 하지만 Database들이 거꾸로 FinancialDataGateway가 존재함으로서 Database들은 여기에 의존하게 되면서 의존성이 역전되게 된다. FianancialReportPresenter 인터페이스와 2개의 View 인터페이스도같은 목적을 가진다.
정보은닉 차원에서 OCP도 위의 예에서 살펴 볼 수 있다. FainacialReportRequester 인터페이스는 방향성 제어와는 달리, FinancialReportController가 Ineractor 내부에 대해 너무 많이 알지 못하도록 막기 위해서 존재한다. 즉, 의존 관계를 바꾸지는 않지만 의존하는 Class의 의존도를 제한하고 변경이 있을 때에도 인터페이스에 한정하여 의존성을 가지도록 하여 OCP를 유지할 수 있다. 즉, 여러 모듈의 의존도가 있는 모듈인 경우 각 Interafce를 분리하여 정보은닉을 하면서 OCP 의 효과를 획득하는 것이라 할 수 있다.
리스코프 치환 원칙(Liskov Substituion Priniciple)
1988년 바바라 리스코프(Barbara Liskov)는 하위 타입(Subtype)을 아래와 같이 정의했다.
S 타입의 객체 o1, T 타입의 객체 o2일 경우, T타입을 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o2을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다.
LSP 예제
이 원칙은 일반적으로 OOP에서 상속을 사용하도록 가이드 한다. 위의 예가 바로 그것인데, Billing 애플리케이션의 행위가 License 하위 타입 중 무엇을 사용하는지에 전혀 의존하지 않기 때문이다. 이들 하위 타입은 모두 License 타입을 치환할 수 있다. 이를 Liskov Substitution Principle LSP라고 한다.
정사각형/직사각형 문제는 LSP에서 발생될 수 있는문제를 설명한다. Square는 Rectangle의 하위 타입으로는 적합하지 않은데, Rectangle의 높이와 너비는 서로 독립적 변경이다. 하지만, Squarue이 높이와 너비는 반드시 함께 변경되기 때문이다. 이런 형태의 LSP 위반을 막기 위한 유일한 방법은 (if문 등을 이용해서) Rectangle이 실제로는 Square인지 검사하는 매커니즘을 User에 추가하는 것이다. 하지만 이렇게 하면 User의 행위가 사용하는 타입에 의존하게 되므로 결국 타입을 서로 치환할 수 없게 된다. 다시 말하자면, 개념적으로는 LSP라 생각하기 쉽지만 이렇게 LSP를 적용하는데는 적당하지 않다.
Square LSP 위반 사례[1]
객체 지향이 혁명처럼 등장한 초창기에는 앞서 본 것 처럼 LSP는 상속을 사용하도록 가이드하는 방법 정도로 간주 되었다. 하지만, LSP는 인터페이스와 구현체에도 적용되는 더 광범위한 소프트웨어 설계 원칙으로 변모하였다.
인터페이스 분리 원칙(Interface Segregation Principle, ISP)
아래 왼쪽 그림 기술된 상황에서,다수의 사용자가 OPS 클래스의 오퍼레이션을 사용한다. User1은 오직 op1을 User2는 op2만을 User3는 op3만을 사용한다고 가정해 보자. 이러한 문제는 아래 그림 오른쪽에서 보는 것처럼 오프레이션을 인터페이스 단위로 분리하여 해결할 수 있다.
Interface Segregation Principle [1]
정적타입 언어는 소스코드에 '포함된 included'선언문으로 인해 소스 코드 의존성이 발생한다. 루비나 파이썬과 같은 동적 타입 언어서는 소스코드에 이러한 선언문이 존재하지 않는다. 대신 런타임에 추론이 발생한다. 동적 타입 언어를 사용하면 유연하며 결합도가 낮은 시스템을 만들 수 있는 이유는 바로 이때문이다.이러한 사실로 인해 ISP를 아키텍처가 아니라, 언어와 관련된 문제라고 결론내릴 여지가 있다.
일반적으로 필요 이상으로 많은 걸 포함하는 모듈에 의존하는 것은 해로운 일이다. 고수준인 아키텍처 수준에서도 마찬가지 상황이다.
의존성 역전 원칙 (Dependency Inversion Principle)
의존성 역전 원칙(DIP)에서 말하는 '유연성이 극대화된 시스템'이란 소스 코드 의존성이 추상(Abstraction)에 의존하며 구체(Concretion)에는 의존하지 않는 시스템이다. use, import, include 구문은 오직 인터페이스나 추상 클래스 같은 추상적인 선언만 참조해야 한다는 뜻이다. 구체적인 대상에는 절대로 의존해서는 안 된다.
우리가 의존하지 않도록 피하고자 하는 것은 바로 변동성이 큰(Volatile) 구체적인 요소다. 그리고 이 구체적인 요소는 우리가 열심히 개발하는 중이라 자주 변경될 수 밖에 없는 모듈들이다.
실제로 뛰어난 소프트웨어 설계자와 아키텍트라면 인터페이스의 변동성을 낮추기 위해 애쓴다. 인터페이스를 변경하지 않고도 구현체에 기능을 추가할 수 있는 방법을 찾기 위해 노력한다. 다음과 같은 매우 구체적인 코딩 실천법이 있다. 사실 이것이 DIP를 다시 쓴것과 같다.
변동성이 큰 구체 클래스(Concrete Class)를 참조하지 말라. (Refer)
변동성이 큰 구체 클래스(Concrete Class)로 부터 파생하지 말라 (Derive)
구체함수를 오버라이드하지 말라. 대체로 구체 함수는 소스 코드 의존성을 필요로 한다. 따라서 구체 함수를 오버라이드하면 이러한 의존성을 제거할 수 없게 되며, 실제로는 그 의존성을 상속하게 된다.
구체적이며 변동성이 크다면 절대로 그 이름을 언급하지 말라
아래 그림에서 곡선은 아키텍처 경계를 뜻한다. 이 곡선은 구체적인 것들로부터 추상적인 것들을 분리한다. 소스 코드 의존성은 해당 곡선과 교차할 때 모두 한 방향, 즉, 추상적인 쪽으로 향한다. 제어흐름은 소스 코드 의존성과는 정반대 방향으로 곡선을 가로지른다는 점에 주목하자. 다시 말해 소스 코드 의존성은 제어흐름과는 반대 방향으로 역전된다. 이러한 이류로 이 원칙을 의존성 역전(Dependency Inersion)이라고 부른다.
Dependency Inversion Principle[1]
위 그림의 구체 컴포넌트에는 구체적인 의존성이 하나 있고, 따라서 DIP에 위배된다. 이는 일반적인 일이다. DIP 위배를 모두 없앨 수는 없다. 하지만 DIP를 위배하는 클래스들은 적은 수의 구체 컴포넌트 내부로 모을 수 있고, 이를 통해 시스템의 나머지 부분과는 분리할 수 있다.
결론
S.O.L.I.D는 Single Responsibility Principle, Open Close Principle, Liskov Substitution Principle, Interface Seggregation Principle, Dependency Inversion Principle의 앞글자를 딴 것이다. 원칙 하나씩 따져 보았지만, 서로 서로 관련되어 있는 것을 살펴 볼 수가 있다. 이러한 원칙은 컴포넌트 혹은 아키텍처로 확장될 수 있다. 또한, 이러한 원칙은 Design Pattern의 각 패턴의 기본 원칙으로 각 패턴을 상세히 설명하는데도 사용된다.
참고 도서
[1] 로버트 C. 마틴 저, "클린 아키텍처 소프트웨어 구조와 설계의 원칙" 인사이트(insight) 2019년 08월 20일, 송준이 역
제약 이론을 처음 알게 된 것은 데이비드 J. 앤더슨의 칸반 책[1]을 보고 나서였다. 사실 칸반은 도요타 생산 시스템(TPS)의 칸반에서 따온 것이지만 실재로 이론적 배경이 되는 것은 제약 이론이라는 것을 책에서 이야기 한다. 이렇게 발전된 칸반이 TPS의 칸반과 비슷하다는 것을 알게 된 후에 이름을 칸반이라고 붙였다는 일화가 있다. 여기서도 알 수 있 듯이, Lean Thinking과 제약 이론은 일맥 상통하는 부분이 있다고 볼 수 있다.
제약 이론은 1984년에 처음 책으로 소개되고 2014년의 30주년 기념판[2]이 2019년에 다시 번역되어 나온 엘리 골드렛의 오래된 이론이다. 한마디로 이야기 하면, 시스템의 효율성을 저해하는 제약조건(Constraint)을 찾아내서 극복하기 위한 시스템 개선 방법이라고 할 수 있다.
복잡계를 살펴 보고 있는 지금 조직 혹은 인간 사회, 집단이라는 측면에서 개발팀 혹은 회사라는 것을 복잡계로 볼 때 경영 이론들도 복잡성 과학이라는 측면으로 볼 수 있다. 그렇다면, 제약 이론의 경우는 어떨까? 이 생각으로 이를 정리해 본 것이다.
하이킹 이야기
책[2]의 4막에는 주인공인 알랙스 로저가 토요일 아침 7시에 아들 데이브의 보이스카웃 하이킹에 따라갔다고 우연히 분대장역할을 맏게되고 10마일 떨어진 야영장까지 15명의 아이들을 이끌고 가는 일화를 이야기 하고 있다. 처음 목표는 2마일을 한시간에 가는 정도이면 될 것이라고 목표를 잡았고, 8:30에 출발하여 점심을 한시간 반정도 하고 계속해서 간다면 15:00이면 가능하리라고 보았다.
처음에는 가장 빠른 론이라는 아이를 선두에 두고 일정한 속도로 가게 하였다. 그리고, 아이들에게는 거리가 멀어지지 않게 행진하도록 당부하였다. 하지만, 실재로는 일이 그렇게 쉽게 풀리지 않았다. 중간에 있는 느린 아이의 속도에 뒤에 있던 더 빠른 아이들은 제약을 받았다. 즉, 아무리 빨라도 앞에 있는 아이의 속도에 제약을 받는 것이다. 그렇다고 해서, 아이들의 순서를 바꾼다고 해도 별 소용이 없었다.
이렇게 4시간 정도 걸었어도 실재로 점심시간까지는 겨우 2마일 정도 밖에 가지 못한 것이다. 목표에 대비 한참 부족한 상황이었다. 점심을 먹으며 고민한 알렉스는 균형 잡힌 공장에 대한 시뮬레이션으로 성냥과 주사위로 4명의 아이들과 게임을 하고 하이킹을 하는 15명의 아이들과 자신이 '종속적 사건' 집단이라는 깨닳음을 얻는다.
13:30 다시 출발을 시작하였고, 알랙스는 앞의 사람을 따라 잡기 위해서 열심인 아이들을 보고 자신의 공장도 무언가를 따라잡기 위해 달라고 있었지만 왜 페쇄 직전에 위기에 있는지 고민하기 시작했다. 이런 어려움 속에 5마일 지점에 도착한 일행은 14:30이라는 시간이 된 것을 깨닳는다. 목표로 한 시간과는 30분 밖에 남지 않았다.
이제 반전은 여기서 부터였다. 이때 부터, 일행은 손을 잡고 가면서 앞사람과의 간격을 없앴다. 여기서 가장 속도가 느린 허비라는 친구가 어떻게 하면 빨리 갈 수 있는 방법을 아이들과 찾아 내게 된다. 너무나 많은 짐을 가지고 왔던 허비의 짐을 나눠 가지고 전체의 속도를 높일 수 있었다. 결국은 남아 있던 4마일을 2시간만에 주파하고 17:00에는 캠프장에 도착할 수 있었다.
'종속적 사건'과 전체를 보는 방법.
복잡성 과학에서 꼭 비교 하는 것이 환원 주의(Reductionism)와 전일 주의(Holism)이다. 환원 주의는 부분으로 나누어서 전체를 설명한다는 예전 부터 과학에서 사용되던 통념인데, 복잡성 과학에서는 전체가 부분의 합이 아니라는 전체로 보아야 한다는 관점이다.
하이킹 이야기에서도 하이킹을 하는 아이들을 한명 한명으로 보아서 답이 나오지 않다가, 마지막에는 서로 상호 작용이 타이트하게 일어나도록 손을 잡게 하고 전체적으로 최적화 될 수 있도록 허비의 짐을 나눠 가지게 하면서 최적화가 일어나기 시작한 것을 볼 수 있다.
간단한 사례일지는 모르나, 시스템의 부분 부분을 최적화한다고 해서 전체가 최적화 되지 않는 것은 자주 발견되는 사례이다. 그렇게 때문에 시스템을 전체적(Holistic)하게 보아야 한다. 이 부분이 제약 이론의 복잡성 과학과 연결 되는 부분이라고 생각된다.
균형잡힌 공장(Balanced Plant)와 성장
제약 이론에서는 균현 잡힌 공장에 대해서 이야기 한다. 이는 공장이 시장의 요구 사항에 잘 적응하여 제고가 없이 시장의 요구에 맞게 생산해 내는 공장이다. 하지만, 이것을 목표로 하는 공장은 결국 더 망해 간다고 이야기 한다. 왜 그럴까? 이는 복잡계에서 이야기 하는 성장의 관점으로 볼 수 있다
즉, 성장이 지속 되어야 계속 효율화 되는 것이지 유지 한다면 결국은 성장을 멈추고 죽음의 나락으로 떨어 지는 것을 볼 수 있다. 하이킹 중간에 했던 주사위 게임의 결과도 이를 보여주는 일종의 시뮬레이션이라고 할 수 있다. 그렇다면, 어떻게 하는 것을 책에서는 제안하는 것일까?
하이킹의 예에서는 아이들을 손을 잡게 한다. 이는 종속 사건들을 묶는 것이다. 그리고, 제약 요인을 찾고 이을 전체적으로 효율화 하는 방법을 찾게 하는 것이 접근 방법이었다. 전체적인 시스템에서 종속 사건들이 상호 작용을 하게 거기서 시스템이 효율화 되면서 성장하는 것이다.
성장이라는 측면에서 눈에 보이지 않더라도 이를 계속해야 하는 또 다른 이유가 있다. 이는 붉은 여왕의 달리기 비유에서 살펴 볼 수 있다. 붉은 여왕의 달리기는 루이스 캐럴의 거울 나라의 앨리스에서 붉은 여왕이 앨리스에게 했던 말에서 따온 것인데, "같은 자리를 지키고 있으려면 계속 달리 수 밖에 없다"라는 표현이다. 이는 복잡성 과학을 많이 활용하는 생물학에서는 공진화라는 표현을 쓰는데, 상호 작용하는 여러 종이 환경이 아닌 서로 같이 생존하기 위해서 함께 진화하는 것을 의미한다. 즉, 변화가 없어 보이지만 유지하기 위해서 변화하는 것이다.
최적화 하는 방법.
더 골[2] 책에서는 제약 이론을 정리해서 5단계 시스템을 설명하고 있다.
1단계: 제약 요인을 찾아 낸다.
2단계: 제약 요인을 최대한 이용할 수 있는 방법을 선택한다.
3단계: 다른 모든 공정을 위의 결정에 따라 진행한다.
4단계: 제약 요인을 향상 시킨다.
5단계: 만일 4단계에서 제약 요인이 더 이상 성과를 제약하지 않게 되면 다시 1단계로 돌아간다.
. 경고!: 그러나 관성이 제약 요인이 되지 않도록 주의 한다.
즉, 종속된 사건으로 이루어진 시스템을 최적화 하는 방법을 말하는 것이다.
복잡계를 설명하는 주요 저서로 볼 수 있는 스케일[3]에서는 여러 이론들을 물리학 및 생물학의 사례를 들어 설명하는 부분이 많다. 최적화 관련해서는 지속적인 다수의 되먹임 및 미세 조정 메커니즘이 자연선택의 진행 과정에 내재해 있고, 그것들이 엄청난 기간에 걸쳐 이루어 지는 것이라고 설명힌다. 더 구체적인 사례가 포유 동물의 심장 출력 최소화가 그것이라고 한다.
여기에 숨어 있는 것이 엄청난 기간이고 이 기간을 구간으로 나누는 것이 생물으 한 세대라고 볼 수 있다. 제약 이론도 반복적인 절차(Iteration)이 일어난다. 생물에서도 한 세대는 부모 세대로 부터 받은 유전자를 통해서 공통된 것도 있고 돌연 변이 유전자도 받게 될 것이다. 환경 혹은 함께 공존하는 종들과 상호 작용을 거치면서 자연 선택의 과정을 거치고 다음 세대로 넘어가는 것이 마치 5단계 시스템에서 일어나는 일과 유사해 보이지 않은가?
참고 문헌
[1] 데이비드 J. 앤더슨, "칸반: 지속적 개선을 추구하는 소프트웨어 개발," 2014년 11월 30일 출간, 조승빈 옮김, 인사이트
[2] 엘리 골드렛 저, "더 골 The Goal 당신의 목표는 무엇인가?", 동양북스(동양books) 2015년 08월 15일
[3] 제프리 웨스트 저, "스케일 생물, 도시, 기업의 성장과 죽음에 관한 보편 법칙", 김영사, 2018년 07월 30일, 이한음 역
이글은 [1]의 번역이다. 원래 [2]가 있었는데, 증보 된 것으로 보인다. 우선은 최신본을 번역하여 여기 옮겨 놓는다.
OKR의 기술, 속편
오리지널 “OKR의 기술”은 2014년에 작성되었다. 2차 개정판을 위해 Radical Focus[3]를 수정을 위해 다시 돌아 왔다 (출시 때 알림을 받도록 메일링리스트에 등록하세요!) 6 년은 길었고 의외로 많은 것이 변했다. 나는 재작성된 초안을 공유하기로 결정했다 (여전히 편집자에게 보내야 한다) 즐겁게 읽으세요!
OKR은 현재 전 세계의 회사에서 채택되었지만, 2011년 Zynga에서 처음 만났을 때는 그렇지 않았다. 당시 Zynga는 게임을 통해 사람들을 연결함으로써 세상을 변화 시키려고 노력하는 스타트 업이었다. Zynga에서 근무한 시간에 대해서만 이야기 할 수밖에 없지만, 그 곳에 있는 때, 그 회사는 실리콘 밸리에서 가장 빠르게 성장하는 회사 중 하나였다. 다른 회사와 마찬가지로, 기능에 장애가 있었지만 Zynga가 목표를 달성하는 데 얼마나 능숙했으며 조직으로서 지속적으로 똑똑해 졌는지 생생하게 기억한다. Zynga는 OKR을 통해 회사 전체에 실제로 중요한 것에 많은 이질적인 “스트디오*”들을 집중시킬 수 있었으며, 해당 스튜디오가 전략을 실현하는 방법에 대한 자체 선택을 할 수있게 했으며 전례없는 성장을 이끈 독점 정보로 회사를 강화할 수 있었다.
Zynga는 어떻게 OKR을 찾았나? 앤디 그로브(Andy Grove)는 텔에서피터 드러커(Peter Drucker)의 Management를 목표 관리 시스템으로구현하였고, 이로 부터 궁극적으로 Objectives & Key Results가 될 프레임워크가 탄생했다. 전 인텔 임원이자 현재 클라이너 퍼킨스(Kleiner Perkins)의 파트너인 존 도어(John Doerr)는 Google 및 Zynga를 포함하여 투자 한 모든 신생 기업에 OKR을 전파했다. 두 회사 모두 이 시스템을 채택하여 회사를 통일하고 활기를 불어 넣었다. (내가 옮긴 후 OKR을 채택한) 링크드인(Linkedin)과 (2013년에 가르친) 제너럴 어셈블리(General Assembly)와 같이 OKR을 채택한 기업이 많다. OKR은 성장에 효과적인 촉진제였다.
지난 6 년 동안 나는 직업 생활과 개인 생활 모두에서 OKR을 사용해 왔으며 훌륭한 결과를 얻었다. 내가 Zynga를 그만두었을 때 나는 육체적으로나 정신적으로 번아웃이 왔다. 오늘은 베스트셀러 작가이며 스탠포드의 전산과에서 꿈이었던 강의를 하고 있다. OKR은 개인 또는 회사이든 된다.
내가 Zynga를 처음 떠났을 때, 나는 스타트업에 어드바이저 역할을 했다. 나는 신생 기업들이 고통스럽고 치명적인 집중력 부족으로 어려움을 겪고 있음을 발견했다. 제품/마켓에 적합하다는 사실을 발견한 신생 기업조차도 직원들이 검증 된 비전을 향해 모든 작업을 수행하도록 하는 것이 매우 신나는 일이라는 것을 알게 되었다. 모든 스타트업은 자금이 똑딱 거리는 시계처럼 줄어 드는 상황에서 치열할게 살아 남기 위해 노력한다. 그들은 벤처 투자자들의 투자를 놓치기 전에 보여 줄 수 있는 일종의 결과를 얻어야 한다. 내가 이 신생 기업이 중요한 것에 집중하도록 어떻게 도울 수 있었을까? 당신이 알고 있을 것이다.
OKR은 Objectives and Key Results(목표 및 주요 결과)를 의미한다. OKR의 형식은 다소 표준화되었다. 목표는 정성적이며 KR (대개 3 개)은 정량적입니다. 그들은 대담한 목표를 중심으로 그룹이나 개인을 집중시키는 데 사용된다. 목표(Objectives)는 정해진 기간 (보통 한 분기) 동안 목표를 설정한다. 주요 결과(Key Results)는 목표(Objectives)가 그 시간이 끝날 때 달성되었는지 아닌지를 알려준다.
당신의 목표(Objective)는 다음과 같은 단일 문장이다.
정량적 그리고 영감을 주는
목표는 아침에 사람들이 흥분하여 침대에서 벌떡 일어나게 하는 것이어야 한다. 그리고 CEO와 벤처 투자자들은 아침에 주가가 3% 증가에 기뻐하면서 잠에서 벗어날 수 있지만, 대부분의 사람들은 의미와 진보의 측면에서 흥분한다. 팀에서 사용되는 언어를 사용해야 한다. 그들만 사용하는 속어를 사용하고 “pwn it”또는“kill it”이라고 말하고 싶다면 그 단어를 사용하면 된다. 팀원들이 "기쁨"과 "변형"이라고 말하면, 그 것이 그 팀의 언어이다.
시간이 정해진
예를 들어 한 달, 한 분기에 가능합니다. 목표를 향한 명확한 스프린트가 되기를 원할 것이다. 1년이 걸리면 목표는 전략 일 수도 있고 미션일 수도 있다.
팀이 독립적으로 실행 가능
이는 스타트 업에게는 문제가되지 않지만 더 큰 회사는 종종 상호 의존성 때문에 어려움을 겪는다. 당신의 목표는 진정으로 당신의 것이어야하며, “마케팅 담당 부서가 시장에 내놓지 않았다”와 같은 변명의 여지가 없다.
목표는 짧은 기간 동안의 미션 선언서(Mission Statement)와 같다. 훌륭한 목표는 팀에게 영감을 주고 정해진 시간 내에하기는 어렵지만 불가능하지는 않으며, 이를 설정한 사람이나 사람들이 독립적으로 수행 할 수 있다.
좋은 목표의 예는 다음을 참고하자.
South Bay에서 직거래 커피 소매 시장 확보
프러덕트 매니저들을 기쁘게할 멋진 MVP를 시작
습관을 사용하여 Palo Alto의 쿠폰으로 변형 (Transform Palo Alto's coupon using habits).
그리고 몇 가지 아쉬운 목표의 예는 다음과 같다.
매출 30 % 증가
사용자 두 배로 만들기.
200만 달러 수익
왜 이런 목표가 나쁜가? 아마도 그들이 실제로 Key Result(주요 결과)이기 때문일 것이다.
주요 결과(Key Results, KR)
주요 결과(Key Result, KR)는 모든 영감을 주는 언어를 사용하여 이를 정량화한다. 당신은 "우리의 목표가 달성되었는 어떻게 알 수 있을까?"라는 간단한 질문을 통해 그것들을 만든다. 이러한 성취로 인해 "굉장함", "끝내줌" 또는 "획득"의 의미로 정의 할 수 있다. 일반적으로 3개의 주요 결과가 있지만 최대 5개의 항목 혹은 최소 1개의 항목이 될 수 있다. 주요 결과(Key Result)는 다음을 포함하여 측정 할 수있는 모든 것을 기반으로 할 수 있다.
성장(Growth)
참여(Engagement)
수익(Revenue)
성과(Performance)
품질(Quality)
마지막은 사람들을 혼란스럽게 할 수 있다. 품질 이란 측정하기가 어렵다. 그러나 NPS와 같은 도구(NPS = Net Promoter Score, 고객이 친구 나 가족에게 특정 제품을 추천하려는 의지에 근거한 수치이다. 2003 년 12 월 HBR의 “The Only Number You Need to Grow” Harvard Business Review를 참조하십시오.)를 사용하면 가능하다.
KR을 현명하게 선택하면 대표적으로 잠재적으로 반대되는 성장과 성과 또는 수익과 품질과 같은 힘의 균형을 맞출 수 있다.
“최고의 MVP를 시작하라”의 KR은 다음과 같다.
사용자의 40%가 일주일에 2회 이상 재방문
8 이상의 추천 점수
15 % 전환률
그것들이 얼마나 힘든지 주목하라.
KR 어렵지만, 불가능 하지 않아야 하는 것
OKR은 항상 도전적 목표(Stretch Goal)이다. 다음 물음에서 시작해 보자. "1-10까지의 기준에서 이 목표를 달성 할 수 있는 자신감은 어느 정도인가?" 1 의 신뢰 수준은 "이봐요. 이건 절대 안돼"를 의미한다. 10의 신뢰 수준은“그래, 이건 할 수 있어"를 의미 한다. 또한 목표를 너무 낮게 설정하는 것을 의미한다 (종종 샌드백깅이라고도 함. 골프에서 자신의 스코어를 일부러 낮게 하여 이기는 사람을 샌드배거라고 하는데서 왔다고 함). 실패했을 때 처벌하는 회사에서는 직원이 도전하지 않는 법을 빨리 배운다. 좋은 일을 하게하려면, 그 어느 사람 했던 것보다 더 멀리 도달 할 수 있는 것을 안전하게 만드는 방법을 찾아야 한다.
어떤 목표를 달성하는 데 성공 확률이 50/50이라면, 아마도 적절한 도전적 목표(Stretch Goal)의 수준일 것이다. 요가를 해본 적이 있다면 강사는 스트레치 되는 것을 느끼지만, 통증을 느끼지 않는 한 손을 뻗을 것을 권장한다. 통증이 느껴지면 부상을 입을 위험이 있다. 목표 설정도 이와 같다. 목표를 너무 세게 설정하면 팀이 번 아웃할 수 있다. 너무 쉽게 설정하면 회사가 약해지고 죽을 수 있다.
주요 결과(Key Result)를 자세히 살펴보라. 당신이 속에서 “우리는이걸 하려면 모든 것 쏟아 부어야해…”라고 말하는 것을 들을 수 있다면, 아마도 정확히 설정하고 있는 것이다. 당신이 그들을 보고 “우리는 망했어”이라고 생각한다면, 그것들을 너무 어렵게 설정 한 것이다. 당신이 그 것들을 보고 “조금 열심히 하면 그 일을 할 수 있겠어”라고 생각하면 너무 쉬운 것이다.
일부 회사는 헌신과 열망을 이끌어 내는 OKR을 설정한다. "헌신"은 당신이 하겠다고 하는 일이고 "열망"는 당신이 하겠다고 희망하는 일이다. 이는 목표 설정 프로세스에 복잡성을 더한다. 이 책 전체에서 나는 당신의 OKR을 단순화하도록 자극 할 것이다. OKR은 사람들의 마음에 들 수 있을 때 가장 잘 작동한다. 더 많은 OKR 세트를 만들고 더 복잡하게 만들수록 팀은 빠르게한 활동을 다른 활동보다 더 높게 우선 순위를정해야 할 때임을 기억하지 못할 가능성이 높다. 목표를 지나치게 복잡하게하지 말자.
OKR 작동 원리
OKR을 설정하는 것만으로는 충분하지 않는다. 정기적으로 추적해야 한다. OKR의 규칙적 수행(Cadence 케이던스)은 실제로 영감을 주는 목표(Objective)를 설정하는 것과 주요 결과(Key Result)를 결과 중심으로 설정하는 것 이상으로 OKR이 동작하게 한다. 사람들은 OKR과 S.M.A.R.T. 목표 또는 다른 목표 설정 방법의 차이점이 무엇인지 묻는다. 나는 규칙적 수행의 체크인(Check-in)이 차이난다고 말한다. 규칙적 수행은 목표 설정과 목표 달성의 차이를 만드는 것이다.
Zynga에서 수행 한 작업에서 OKR 추적 접근 방식을 수정해야했다. 젊은 신생 기업은 모든 회의에 대한 내성이 매우 낮으며 전술과 측정에 대한 일일 심층 분석이 훨씬 적다. 나는 일주일에 두 번의 주요 회의로 회의를 정리했다. 하나는 의도를 설정하고 하나는 진보를 축하하는 것이다. 이번 주에는 회사가 무엇을 달성하려고했는지에 대한 명확한 리마인드로 주의 시작과 끝이 결정된다.
월요일에 경영진은 회사 OKR 상황에 대해 토론을 한 후, 각 팀의 목표 숫치에 도달하기 위해 위해 팀의 자신감과 노력이 이어졌다. 일부 회사는 다른 비 OKR 지표에 대한 지표 분석을 추가하고 일부는 일 처리하는 파이프라인의 토론을 할 것이다. 이 프로세스의 중요한 부분은 공유된 OKR을 지속적으로 다시 방문하고 목표 수치가 어떻게 이동하고 있는지에 대해 논의 혹은 논쟁하는 것이다. 계속해서 목표를 다시 살펴본다는 것은 회사가 집중력을 유지하고 주의가 산만 해졌을 때 계속 진행하도록 결정을 내릴 수 있다는 것이다. 매 분기 말에 다음 번의 더 나은 목표를 달성하기 위해 해당 분기의 성공과 실패로부터 배우는 것이다.
이는 스타트 업을위한 OKR의 가장 중요한 부분 중 하나인 금요일 자랑 시간(Bragging Session)으로 이어진다. 내가 일한 모든 회사는 매주 금요일 축하 행사를 시작했다. 그러던 어느 날, 나는 그렇게 하지 않은 신생 기업과 일했다. 그들은 어렸고 아직 중요한 유대감을 높여주는 이 의식을 하고 있지 않았다. 여러 해 동안 애자일 개발 프로세스의 의식인 금요일 데모에서 디자이너가 빠져 있어서 불만을 제기한다고 들어서, 모든 사람에게 데모하는 것으로 다시 시작하자는 제안했다. 이것은 변혁이었다. 비즈니스 개발은 새로운 파트너십을 자랑한다. 회계 부서는 세금 감면을 자랑한다. 디자이너들은 보다 편한 체크아웃 플로우를 자랑한다. 각 팀은 갑자기다른 팀이 하는 것을 알게 되고 각각 서로에 대한 존중을 얻게되었다.
OKR은 본질적으로 강하게 밀어 붙이는 힘이 있고, 아무도 전에 한 적이 없는 일을 하려고 할 때 종종 실패하게 된다. 그러나 그런 기회가 없다면 혁신도 없다. 금요일의 성공 축하 행사는 실패한 실험 분야에서 힘들고 치열한 행진으로 인한 피로에 대한 해독제였다. 함께 목표를 설정하고 함께 축하 할 수 있는 기회가 있으면 그룹에 큰 차이가 있다.
OKR이 실패하는 이유는?
그룹에서 처음 OKR을 시도 할 때 발생하는 몇 가지 일반적인 오류가 있다. 새롭고 더 나은 실수를 찾을 수 있기를 바라며 그러한 예를 나열해 본다.
#1 설정하고 잊기
사람들이 목표를 달성하지 못할 때, 분기 초에 OKR을 설정 한 다음 잊어 버렸기 때문인 경우가 종종 있다. 이 3개월 동안, 당신은 팀원의 요청에 당황하고, CEO는 당신이 읽고 통합해야 할 기사를 보내며, 고객 불만을 받는다. 시간을 보낼만한 101가지 흥미로운 것들이 있고, 그것들이 항상 성공으로 이어지지 않는다. OKR을 주간 팀 회의 (있는 경우)와 주간 상태 이메일로 적용하는 것이 좋다. 매주 신뢰 수준을 조정하라. 그들이 오르거나 내리는 이유에 대해 토론하라. 설정하고 잊어 버리면 후회하게 된다.
#2 주차 목표 독려
분기 중반에 OKR을 변경하지 마십시오. 설정이 잘못되었다고 판단되면 주요 결과에서 훨씬 나아지거나 나빠질 것이라는 사실을 알고 있더라도 그것을 받아 들이고 계속 추적하라. 당신은 그 목적을 설정한 이유가 분명히 있다. 그렇게 하고 난 후에 다음 그것을 통해 배운 것을 사용하여 다음에 더 잘 설정하라. 처음부터 OKR을 완벽하게 얻는 팀은 없다. 초점을 희석시키는 것에서 부터 바꾸어, 팀을 목표에 집중시키는 것이 OKR의 전체 요점입니다. 반 정도 즈음에서 변경하면 OKR을 진지하게 받아들이지 않게 된다.
# 3 너무 많은 OKR
회사의 전략적 비전에 절대적으로 중요한 것들에 대해 OKR 설정을 하자. 인간의 기억에는 한계가 있다. 일상적인 활동이 급증함에 따라 시간과 에너지를 어디에 소비할지를 찾으려고 노력할 때, 우선 순위를 정하는 데 도움이되는 쉬운 도구가 필요하다. 하나의 OKR 세트를 사용한다면, 기억해야 할 것은 4 가지가 있으며, 이는 하나의 큰 아이디어로 멋지게 덩어리져 있다.
회사에서 5 개의 OKR 세트를 설정 한 미쉘(Michelle)을 상상해보자. 월요일에, 그녀는 먼저 무엇을해야 할지를 결정하면서 15 가지 주요 목표 (3가지씩 주요 결과(Key Results)를 가진 5가지 목표(Objectives)를 기억하려고 한다. 그리고 나서 잠재적인 프로젝트의 긴 파이프라인을 스캔하고 이러한 작업을 회사가 요구하는 무수한 결과와 연결하려고 한다. 그녀는 고객 서비스 요청으로 인해 중단되었다. 이것은 그녀의 흐름을 방해하고 그녀가 돌아왔올 때, 그녀는 무엇을 하고 있을까? 그녀가 무엇을 해야 하는지 분석하는 일로 돌아 가지 않는다면 아마도 가장 쉬운 일이나 문제되는 일을 처리할 것이다. 당신이 담당하는 리더십 팀이 우선 순위를 정할 수 없었기 때문에 직원들은 현재 여기 저기 산재된 노력을 기울이고 있으며 추진력이나 영향력이 있는 일을 달성 할 수 없다. 이 긴급 상황과 끝없는 과제 목록이 당신에게서는 일어나지 않았다고 해도 놀라지 말자.
.
이제 회사에서 단일 OKR 세트를 설정 한 쉐인(Shane)을 생각하자. 매출 성장의 주요 결과, 유료 요금제와 관련된 대화 및 추천과 함께 "고객은 우리에게 충분히 지불 할 가치가 있다"라는 목표를 생각해 보자. 그는 바쁜 월요일에 다음에 해야 할 일을 결정하려고 한다.
쉐인(Shane)은 "이번 분기에 OKR을 이용하면 무료 사용자를 유료 고객으로 전환 할 수 있다."라고 생각한다. 그는 프로젝트의 파이프라인을 살펴보고 상향 판매 모듈에서 작업하기로 결정한다. 고객 서비스 부서에서 전화를 대응했다고 하자. 이에 대한 대응한 후, 다시 자신에게 물으면 무엇을 할까? 아마도 대답은 쉽게 나올 것이다.
모든 일에 대해 OKR을 설정하지 말자. 중요해서 전략적 노력을 기울여야 하는 것에 대해 설정하자. 하나를 선택할 수 없으면 순차적으로 시도하자. 보다 효과적으로 다른 노력을 기울이기 위해 먼저 할 수있는 일이 있는가? 여러 광고를 보내기 전에 개선할 고객 경험이 있는가? 그래도 도움이 되지 않는다면, 가능한 한 범위를 좁히고 중요도에 따라 순위를 정하라. 그렇게 해야, 미셸은 적어도 "1등 목표"를 기억할 것이다.
# 4 마이크로 매니지먼트를 위한 OKR
우리는 왜 개방형 사무실을 사용하는가? 관리자가 사람들이 일하는 것을 볼 수 있기 때문이다. 왜 진척 상황 점검 회의와 주간 보고 이메일을 보내도록 하는가? 관리자는 이를 통해서 사람들이 일하고 있는지 확인할 수 있다. 관리자가 보고서의 모든 활동을 제어하려고 하면 어떻게 되는가? 관리자는 지치고 직원은 지루하며 아이디어가 덜 생성되고 생산성이 떨어 진다. 이 반복적인 고리를 끊을 준비가 되었다면 OKR이 올바른 선택이다.
대신 OKR을 설정 한 다음 관리를 중지하고 리딩(Leading)을 시작하자. 그런 다음 A급 인재를 고용하여 혼자서 할 수 있던 것보다 회사 목표를 달성하기위한 더 나은 전술을 찾아야 한다. 고려하지 않은 아이디어를 얻을 수 있도록 다양한 팀을 고용하자. 에드워드 웰번(Edward T. Welburn GM)은 General Motors이 파산으로 부터 일어나 다시 활력을 불어 넣었다. 이 때, Cutless Supreme에서 Chevy Volt까지 상징적인 자동차를 만들어 냈지만, 그의 상사가 어깨 위에 앉아 무엇을해야하는지 알려주었다면, 그렇게 하지 못했을 것이다. 그는 혼자 모든 것을 디자인 하려고 고집했다면, GM을 위해 많은 중요한 제품을 만들 수 없었을 것이다. 아무리 훌륭한 보스라도 혼자서 모든 것을 할 수 없다. 특별한 제품을 만들려면 훌륭한 팀이 필요하며 팀에게 고무적인 목표를 부여 할 뿐만 아니라 권한을 부여해야 한다.
# 5 모든 사람이 한 번에 모두 다르게 OKR을 수행
OKR이 신생 기업뿐만 아니라 기존의 회사에도 채택됨에 따라, 이렇게 나는전화를 계속 받고 있다. “우리는 지난 분기에 OKR을 시작했지만 끔찍하게 사라졌고, 이제는 많은 팀장들이 사용을 거부하고 있어요." OKR을 시작하는 가장 좋은 방법은 천천히 하나의 팀으로 함께 시작하는 것이다. 이 부분은 나중에 책에서 다룰 것이다.
OKR 핵심 개념의 검토
목표(Objectvie)는 3 개월간 (또는 연간 OKR을 수행하는 경우 1 년)의 미션이다.
주요 결과(Key Result)는 작업이 아니라 결과여야한다. 신중하게 측정 항목을 선택하라.
OKR은 전략적 가치를 가진 스트레치 골이다.
좋은 목표를 설정하고 달성 방법을 찾기 위해 팀을 신뢰하라.
모든 일에 대해 OKR을 설정하지 말자. 당신이 끝내지 못할 것을 두려워하는 미션 크리티컬 한 일에 대한 OKR 세트를 만들자.
매주 OKR 상태를 추적하자
우리가해야할 남은 모든 것
OKR은 관리 방식의 일부로 존재하지만 전부는 아니다.
일반적으로 돈을 버는 것 말고도 비즈니스를 유지하기 위해 해야 할 일이 있다. 계약, 세금, 회계, 급여 등 이러한 작업을 일정 수준의 품질로 수행해야한다 그렇지 않으면 회사에 문제가 생긴다.
완전히 최적화되었거나 꾸준한 개선 상태에있는 비즈니스로 하는 일이 있다. 이들 중 일부는 주력 제품이다. Microsoft의 Windows, Intuit의 Quickbook 또는 Intel의 메모리 칩. 고객은 회사의 캐시 카우이기 때문에 고객에게 가치가 있을 만큼 좋은 제품을 유지하는 팀을 원한다. 고객의 요구가 발전함에 따라 팀을 발전 시키지만, 이러한 종류의 혼란으로 인해 고객이 얻는만큼 비용이 많이 들기 때문에 혁신을 거의하지 않는다.
많은 서비스 부서는 이와 같습니다. 그들은 혁신보다는 진화한다. 엔지니어링, 고객 서비스, 법률… 대부분의 경우 제대로 작동한다. 너무 자주 그것들을 향상시키기를 원할 수도 있지만, 건전한 회사에서는 훌륭히 그 일을하는 부드러운 리듬이 있다.
이러한 모든 노력을 “운영”이라고 부를 수 있다. 관리자로서 문제가 발생하지 않도록 모니터링해야 한다. 변경 사항을 파악하기 위해 추적하기로 선택한 지표를 OKR 프레임 워크에서 "건강 지표(Health Metrics)"이라고 한다. 다음 장에서 더 자세히 설명하겠다.
마지막으로 기회가 있다. 기회는 전략적으로 중요하지만 항상 시급한 느낌은 아니다. 기회는 비즈니스의 미래가 있는 곳이다. 인튜이트(Intuit)가 더 이른 시장을 포착하기 위해 온라인 버전의 퀵북을 재 설계했을 때와 마찬가지로 기회는 종종 캐시 카우를 재창조 할 기회이다. 때로는 TeeBea에서 보았 듯이 기회는 B2C에서 B2B ** 로의 스타트 업의 피봇이기도 하다. 때로는 Facebook의 뉴스 피드와 같은 새로운 기능이 시작될 때 기회가 생길 수 있으며, 그 성장에서 최대한 많은 가치를 포착 할 수 있도록 더 많은 시간과 사람들이 투자해야한다는 것을 알고 있다. 이런 것들이 OKR을 위한 것들이다. OKR은 회사가 그 기회를 실현하기 위해 시간과 주의를 기울임으로써 중요한 것을 취하고 긴급하게 만든다.
OKR 및 건강 지표(Health Metrics)는 회사 대시 보드에 나란히 표시된다. 둘 다 추적한다. OKR은 더 큰 성장을 추구하는 것들이다. 건강 지표는 성장하는 동안 보호해야 하는 것들이다.
큰 실패에 대한 준비!
솔직하게 말하자 : 우리는 실패하는 것을 싫어한다. 실리콘 밸리의 모든 사람들은 실패에 대한 립 서비스를 제공하지만 실제로 우리는 여전히 그것을 좋아하지 않는다. OKR은 목표 성취로 기분을 좋게 만드는 것이 아니다. OKR은 조직으로서 실제로 할 수있는 것을 배우는 것에 관한 것이다. 예를 들자면, 우리가 설정 한 목표를 달성하지 못했지만 가장 큰 판매 규모를 이뤘다면 실패인가? 예를 들자면, 우리는 신제품을 출시하지 못했지만 생산 방식 중 일부가 구식이 아니며 문제를 해결하고 있다는 것을 알게 되었다면 어떤가? "실패"는 목표를 스트레칭한 것에 대해서 긍정적인 지표가 될 수 있다. OKR은 자신이 생각했던 것보다 더 많은 일을하고 경험을 통해 배울 수 있도록 설계되어 있다. 달을 향해 쏘려면(구글의 Moonshot Project의 비유로 보임) 처음 시도 할 때 성공하지 못할 수 있다. 그러나 때때로 이를 따르는, 벨크로 (Velcro 찍찍이를 만드는 회사), 샤피(Sharpies, 필기구 회사) 및 탱(Tang, 식음료 회사)와 같은 회사를 볼 수 있다.
그리고 몇 가지 좋은 실패 후에, 우리는 아무도 가본 적이없는 곳으로 갈 수도 있다.
* 스튜디오 : 스튜디오는 작고 독립적 인 팀으로 게임 제작 및 개선에 중점을 둔다. 일반적으로 50 명을 넘지 않고 스타트 업처럼 운영되어 교차 프로모션 및 IT와 같은 것에 대해서만 모회사에 전달한다.
** 두 가지 종류의 비즈니스 모델에 대한 약어이다. B2C에서 소비자에게 직접 판매하고 B2B에서는 하나의 비즈니스가 다른 비즈니스에 판매한다.
나는 OKR에 대해서 이야기를 듣고, 책[1][2]을 사보았지만 잘 이해가 되지 않아서 강의[3]도 듣게 되었다. 개인적으로는 일기[4]를 쓰고 있었다. 이 개인 일기를 잘 변형하면, 나의 개인 생활에 OKR을 적용할 수 있다는 생각이 들었다. 그래서, 분기별로 Objective 목록을 잡고, 주별로 주기적으로 관리하는 것으로 사용하고 있다. 즉, 개인 생활의 OKR 적용인 것이다.
그러다가, OKR 전문가들도 이미 나와 비슷한 생각을 하고 있지 않을까 하는 생각을 하게 되었고, 이 글[5]을 발견하게 되었다. 다음은 이글의 번역이다. 참고로, 글의 저자는 국내에 번역된 OKR 서적 중 하나인 [1]의 저자인 크리스티나 워드케이다.
개인 생활에 OKR을 적용하고 이를 분기별, 주별로 평가하고, 다른 사람들과 이를 추적하고 상호 코칭하면서 계속 발전해 가고 있는 것으로 보인다. 나도 이와 유사하게, 분기별, 주별 그리고 일별로 평가하고 있는데, 더 좋은 방향으로 발전 시키기 위한 좋은 내용이 포함되어 있다.
퍼스널 OKR, 그리고 삼년 후
OKR에 대해 문외한인가? 그럼 먼저 "OKR의 기술" 와 "퍼스널 OKR"을 읽도록 한다. 또한 퍼스널 OKR은 개인 생활을위한 것이고, 일인 OKR(Individual OKR)은 개인의 업무 수행을 위한 성과 추적을 위한 것이다. 같은 것이 아니다! 이것은 퍼스널 OKR에 대한 개인적인 에세이이다.
이 글이 3천 단어나 되어서 유감이지만 실제로는 일년에 천 단어로 봐야 한다. 나는 더 짧은 에세이를 쓰려 했지만, 더 줄일 수 있는 시간이 없었다.
내 친구 리비아(Livia)가 물었다. “3 년 전에 퍼스널 OKR이라는 글을 작성했지. 그 이후로 그것에 대해 무엇을 배웠어?” 벌써 3년 전이라고? 우와…
그 이후로 나는 살아가는 것을 사랑하는 삶을 만들었다.
캘리포니아 예술 대학 (California College of Arts)과 스탠포드 평생 교육원 (Stanford Continuing Education)에서 가르치고있다. (2017년 1월에 Creative Founder 수업을 들을 수 있다.)
나는 텔 아비브에서 시작해서 미시간 주의 그랜드래피즈, 부에노스아이레스에 이르기까지 전 세계에서 연설을 했고, 공개적으로나 비공개로 워크샵을 열었다.
나는 Radical Focus(번역서: 구글이 목표를 달성하는 방식 OKR) , Working with Pictures (V.05은 여기를 참고, V1 은 2017년 발행 예정)를 썼으며 현재는 매니지먼트에 관한 책인 Continuous Feedback을 작성 중이다.
OKR이 나의 인생을 바꾸 었다고 말하는 것은 과소 평가일 것이다. 이것은 내 인생을 가능하게 했다. 이는 내 인생을 함께 유지하는 중추이다. 새해 결심을 만들어야 할 시간(주: 이글을 2016년 12월 31일에 썼기 때문으로 보임)이었고 나는 원래 새해라고 새로운 결심을 하는 사람이 아니기 때문에, (그 보단 아마도 1 년 내내 결심을 하는 사람이니까?) 기존의 새해 결심을 하는 것 보다 더 효과적인 것을 원할 경우 참고할 수 있는 내가 배운 것을 공유 할 것이라고 생각해도 좋다.
퍼스널 OKR을 사용해야하는 이유
우리 모두는 인생에서 성취을 원하지만 인생은 우리에게서도 댓가을 원한다. 우리에게 중요하지만 시급하지 않은 것을 어떻게 성취하는가? 인생이 우리에게 비명을 지르면 지금 초점을 맞추려면 어떻게해야 합니까! 지불할 청구서, 세금 납부, 자동차 등록, 쇼핑, 양말 구매, 점심 식사 준비 등... 목표와 주요 결과(Objectives and Key Results, OKR)는 목표 설정 방법이며, 급진적 집중(Radical Focus)은 목표 달성 방법입니다. 여기서는 OKR을 사용하여 내가 이루고자 하는 것을 이루는 방법을 설명한다.
첫 째, 학습을 통해 지난 분기 마감하기
지난 분기의 OKR 세트를 평가하기 위해 분기의 마지막 주를 거기에 사용한다. 돌아보기(Reflection)은 가속화된 학습의 핵심이다. (OKR 평가에서 대한 자세한 내용 참조). 4분기 OKR 세트를 살펴 보겠다. 분기 동안 나는 내가 얼마나 주요한 결과(Key Result)를 냈는지 보여 준다. 7/10은 내가 70 % 달성했다는 것을 의미한다. 그러나 지난 주 보고서가 이 상태인 7/10인 것은 KR을 달성하지 못했음을 의미하고 10/10은 내가 달성했음을 의미한다. 그리고, 얼마나 주요한 결과(Key Results)에 가까운 지 고려하고 등급을 매긴다.
O : 전문 작가로서의 모범적인 생활
KR: 조치 가능한 피드백을 할 (Cathy를 포함한) 초기 독자(Alpha Reader) 리더 목록에 발송할 "Continous Feedback" 초안 평가: A- 초안은 완료. 1 분기까지 Cathy/Apas에게 줄 수 없음. 교정 절차가 필요함.
KR: 아마존에서 "Working with Pictures V2" 5점 만점 별점 리뷰 기준 4점 6/10 평가 : B- 큰 진전. 하지만, 1 분기 중반에 출시 예정
KR : Product-Market Fit 북 (Creative Founder) 인터뷰에서 각각 2천 뷰 혹은 그 이상의 에세이로 완료 10/10 평가: A
OKR에 대한 저의 다른 글에서, 나는 샌드 배거(Sandbagger 골프에서 자기 스코어를 낮춰 속이는사람)와 과잉 성취자(Overachiever)에 대해 언급했다. 나는 분명히 과잉 성취자이다. 나는 나 자신에게 많은 것을 요구하고 결코 그것을 모두 달성하지 못한다. 두 가지 “실패한” 주요한 결과를 보고 왜 평가가 그렇게 높은지 궁금 할 수 있다.
주간 보고서의 나머지 부분을 살펴 보겠습니다
건강 지표 강의 : 채점 및 수업 계획의 상위 수준 유지 - 녹색 신체 건강 : 위장과 허리 문제를 살필 것 - 녹색
지난주 P1 : 평가 - 완료 P1 : 아이 방 정리 (새 서랍이 생겼음. 현재는 사용할 수없는 상태) - 완료 P1 : 벨리즈(중남미 국가) 여행 준비 - 완료 P2 : WWP(Working With Picture) - 진행 중
다음주 P1 : OKR 평가 등급 및 새로운 OKR 설정 P1 : 최종 성적 평가 제출 P1 : WWP(Working With Picture)를 디자이너/카피에디어에게 전달 P1 : 신년맞이 대청소.
이번 분기에는 캘리포니아 예술 대학에서 2 개의 수업을 가르쳤으며, 가족과 휴가를 보내고, 선거 그리고 등 문제를 해결하고 계절성 정동장애(Seasonal Affective Disorder SAD)와 싸웠다. 그것이 내 인생의 소음이다. 음악이라 할정도로 좋은 소음이다. 그래도, OKR 세트에서 여전히 진전을 보였다.
이러한 소음 가운데서 Continuous Feedback 관련하여 5만 단어의 글을 쓰고 중국어 오디오 북 형식의 Radical Focus를 얻었고, Working with Pictures 페이지 수를 두 배로 늘리고 다음 책 관련한 수십 개의 에세이를 썼다.
이번 분기에 저는 한 번에 한가지 프로젝트가 가능한 사람이라는 것을 배웠다. 동지가 올 때 즈음 일할 수 있는 시간이 줄면, 자신을 돌보는 일은 하루 종일 해야 하는 일이고, 성적 평가는 막대한 시간을 필요로 하는 일이다. 참, 내가 몸을 돌보지 않으면, 몸이 산산히 부서진다. 큰 학습이고, 큰 진보이다.
나 자신에게 A를 준다.
다음 분기에는 탐색일까? 획득일까?
나의 분기의 테마로 OKR을 설정했다고 생각하자. 그러나 일반적인 OKR이 항상 효과가있는 것은 아니다. 때로는 4/4분기의 OKR 세트에서 보았 듯이 1/4 분기 가설을 테스트해 보자.
브라이언 크리스티안은 Algorithm Live By에서 탐색/획득 문제를 설명한다. 새로운 가능성을 탐색하는 데 얼마나 많은 시간을 소비하고, 입증된 작업에서 얼마나 많이 획득할 것인가?
예를 들어, 회사 생활을 그만 둔 후 나는 어떻게 살고 싶은지 알아 내기 위해 여러 가지 일을 했다 (“린하게 살기 Living Lean”에 기록되어 있다). 나는 요리 학교, 음식 창업, 조언, 교육에 도전했다… 탐색이었다. 내가 가르치는 것을 얼마나 좋아하는지 알게되었을 때, CCA에서 3 년 동안 건강 보험과 더 나은 임금을 받기위한 계약을 맺었다... 획득이었다. OKR에 대한 나의 문제는 그것들이 탐험을위한 것이 아니라 알려진 영역에서 성능을 향상시키기 위해 고안된 것 같다는 것이었다. 그때 내가 가설 OKR(Hypothesis OKR)이라고 부르는 것을 발명했을 때. 가설 OKR에서 목표는 성공 상태에 대한 가설이며, 주요 결과는 그것이 사실인지 증명하는 지표이다.
이번 분기의 예 : 내 OKR 세트의 첫 번째 초안.
O : 전문 작가로서의 모범적인 생활
KR : 90 % 별점 5의 리뷰로 2 개 언어로 "Radical focus" 판매 KR : 실행 가능한 피드백을 제공할 알파 버전 독자 목록을 위한 Continous Feedbak의 초안 KR : Amazon에서 Working with Pictures를 4개 이상의 별점 받기
나는 파트 타임으로 강의를 하면서 행복하게 글을 쓰면서도, 재정적으로 자립 가능한가하는 가설을 시험해보고 싶었다.
시장에서 여러 권의 책이 필요하고, 사람들이 책을 다 읽으면 다른 책을 구입한다는 것이 일반적으로 통념(가정임을 경고함)이다. 나는 쓰고 싶은 소설과 논픽션의 백로그 리스트를 가지고 있다.
내가 쓰고 싶은 책 목록. 벽을 리스트 보관 용도로 사용
더 많은 책을 시장에 내놓는 것이 저자로서의 성공에 매우 중요했기 때문에, KR을 Radical Focus(번역서: 구글이 목표를 달성하는 방식 OKR)를 통해 획득하는 것에서 Creative Founder 클래스를 기반으로하는 다음 책인 Product / Market Fit로 넘어가도록 변경했다. 하지만 한 번에 두 권의 책을 어떻게 쓸 수 있을까?
에세이를 쓰는 동안 주제에 대해 인터뷰하기 위해 작가 인 Robert Hoekman Jr를 고용했다. 그런 다음 공동 작업할 수 있도록 모아서 초안을 만들것이다.
KR : Product-Market Fit 서적 (Creative Founder)를 위한 인터뷰는 각각 2000 뷰 혹은 그 이상의 에세이로 완성됨.
당신의 목표가 무엇인지 알면 전술이 빨리 명확 해진다. 나는 시장에 더 많은 책을 내길 원한다. 많은 아이디어와 지식이 있지만 확장 할 수 없다. 그러므로 도움을 받자.
완료하지 못할 것에 집중
KR을 변경 한 또 다른 이유는 내가 중국어 번역본와 오디오 북을 만들 것을 알았기 때문이다. 두 가지 모두 이미 진행 중이 었다. 그것을 목표로 삼는 것은 솔직하지 못한 것이었다. OKR은 당신이 걱정하는 것이고 하지 못할 것들에 대한 것이지 당신이 할 것들을 추적하기 위한 것이 아니다. 또는 Product / Market Fit의 경우와 마찬가지로 위임하여 진행 것을 잘 수행해야 한다. 예를 들어, 고용한 필자에게 의존하여 새 책 작업을하고 에세이를 작성하는 것이 쉬울 것이다. 하지만 아이디어를 대필 작가에게 단지 넘겨 작성하는 것이 아니라, 흥미로운 주제가 의미 있는지 확인하고 싶은 것이다. OKR을 만들어 아이디어를 에세이로 만드는 작업을 수행하는 것이다.
당신의 OKR은 당신이 버릴지 모를 꿈을 지키기 위해 존재한다.
퍼스널 OKR은 어떻게 생겼는가?
나는 당신이 예를 원한다는 것을 알고 있다! 1분기 OKR 세트를 디자인하는 방법은 다음과 같다. 내 가설을 입증했다. 나는 가르치는 것을 좋아하고 작가의 반복된 삶을 좋아한다. 그러나 4분기를 되돌아 보면, 자기 관리를 두 번 이상 희생했다. 나는 내 일과 몸의 균형을 맞춰야 한다. 따라서 1분기는 "획득(Exploit)"분기가 될 것이다. 한 분기 동안 나는 “탐색(Explorer)한” 분기에서 배운 것을 가져다가 일반적인 습관으로 만들 것이다. 또한, 나는 너무 많은 수업과 아마도 너무 많은 대화와 워크샵을 진행하는 것에 동의함으로써 나의 스케줄을 훌륭하게 망쳤다. OKR 세트에 남은 시간이 거의 없으므로 신중해야 한다.
초안
Objective: 잘 일하고, 잘 지내자 KR : 초안의 배송 관련 항목 KR : 건강 지표에 관한 것. KR을 다른쪽으로 돌리는것 KR : 행복 / 번 아웃?
나는 객관적으로 시작한다 : 이번 분기에 주목해야 할 가장 중요한 것은 무엇인가? 그런 다음 KR이 측정하고 싶은 모호한 부분을 골라 내 KR이 내 인생을 볼 수있는 균형 잡힌 방법을 제공하고 있는지 확인한다. 지금 나는 행복 / 건강 / 쓰기를 생각하고 있다. 인생의 의무가 노크를 할 때, 무너질 때 내가 떨어 뜨리는 경향이있는 모든 것들. 다음으로 각 KR의 초점을 좁히고 지표를 추가해야 한다.
지표는 중요하다
모든 것이 측정 될 수 있다. 측정하기가 어렵거나 성가시지만 알아낼 가치가 있다. 건강이 걱정 되는가? 당신이 건강하다면 무엇이 바뀔까? 허리 통증, 체중, 허리 둘레, 바지 크기가 줄어 든다.
행복하다면 무엇을 측정 할 수 있는가? 한번은 한 달 동안 매일 행복에 대해 등급을 매겨 보았다. : 행복(happy)-만족(content)-보통(meh)-불만족(discontented)-불행(unhappy). 음식, 수면 및 활동이 나의 기쁨에 영향을 미치는지 알고 싶었다. (스포일러 : 그렇다. 하지만 다른 에세이이다.)
나는 정기적으로 추적하는 것을 잘 하지 못해서, 하루가 끝날 무렵 벽에 붙인 달력에 내 감정을 추정했다. “완벽은 선의 적”이다. 완벽할 필요 없다. 추적이 되는 것이면 충분하다.
나는 일기에서 일어난 일을 기록하기 시작했지만 나중에 달력에 그것을 쓰고, 평가를 적은 포스트있을 붙였다. 그렇게하면 하루를 자세히 정리하고 살펴볼 수 있다. 그리고 때때로 잊기도 한다. 그런 경우에는 항상 자신을 용서하고 다시 시작하자. 이건 요가에서 배웠다.
올바른 측정 항목을 찾고 정기적으로 측정하는 방법을 배우는 것은 좋은 목표를 설정하는 것만 큼 성공의 열쇠다. 측정 항목 추적은 기본적으로 습관 형성이다. B.J. Fogg의 작업을 확인해 보라.
측정할 수 있어야 관리 가능하다 — 피터 드러커
완료하지 못할 것에 집중 II
내 코치 인 Andrea Corney는 저글링하는 공으로 인생의 모든 것을 묘사해 보라 한 적이 있다.
일부는 점토로 만들어졌고 일부는 수정으로 만들어졌으며 일부는 고무로 만들어 졌다고 해보자. 점토 공은 떨어 뜨려도 상관 없다. 그냥 점토나 고무라면 떨어 뜨려도 망가지지 않는다. 그러나 크리스탈은 가치가 높고, 떨어 뜨리면 끝이다. Continuous Feedback과 Product/Market Fit은 고무이다. 편집자인 Cathy와 공동 저술가인 Robert가 그것들에 대해 지켜보고 있기 때문이다. Working with Pictures는 수정이다... 잘 살펴보지 않아 떨어 뜨리면, 다시 튀어 오르지 않을 것이다.
Objective: 잘 일하고, 잘 지내자 KR : 시장에서 Working with Pictures를 별점 4개 혹은 이상 10 개의 리뷰 받기 KR : 옷 한 사이즈 낮추기 KR : 만족도 80 % 이상
건강관련 KR은 어렵다. 이미 건강 지표에서 요통 및 위장 문제를 추적하고 있다. 체중 감량을 고려했지만 근육을 키우면서 체중계에 큰 변화가 없다. 나는 마르기 보다는 더 건강 해지고 싶다. BMI를 쉽게 측정 할 수있는 방법이 없다. BMI는 내가 원하는 것에 가장 적합한 지표이다. 나는 지금 옷의 사이즈를 사용하고 있다. BMI를 정기적으로 측정하는 방법을 알아낼 수 있다면 그것으로 변경할 것이다.
나는 이미 행복 지수를 추적할 방법을 찾았으니, 슬램 덩크라 할 수 있다.
당신의 OKR을 살기
계속 그래왔듯이, 월요일에 코치에게 다음과 같은 이메일을 보낸다.
10월 10일 ~ : 4분기 OKR 및 우선 순위 쓰레드 O : 전문 작가로서의 모범적인 생활
KR: 조치 가능한 피드백 할 (Cathy 포함한) 초기 독자(Alpha Reader) 목록에 보낼 Continous Feedbak 초안. 5/10 KR: Amazon에서 Working with Pictures V2로 별점 4점 리뷰 받기. 5/10 KR: Product-Market Fit (Creative Founder) 인터뷰에서 각각 2000 뷰 또는 이상으로 완료 5/10
건강 지표 강의: 평가 및 수업 계획에서 상위 유지. 녹색 신체 건강: 복부 및 허리 문제 감시 : 노랑
지난주 P1: 이번 주 뛰기 2회 완료 P1: 채점 따라 잡기 (일요일까지 모두 마무리) 완료 P1: WWP 50 페이지 작업 (거의)완료. 50 페이지 윤관 잡기 P2: Creative Founder 블로그 게시물 끝내기 미완
다음주: P1: Creative Founder 블로그 게시물 끝내기 P1: 음식 일기는 매일 작성 P1: 50 페이지 WWP 작성하기 P2: Working With Picture 10 페이지 더 윤곽 잡기
이번 분기에 나는 상태 보고서를 두 친구 인 Livia와 Donna에게 보냈고 그들은 나에게 보냈다. 우리는 퍼스널 OKR과 그것이 우리에게 무엇을 의미하는지 알아내어 서로를 코치하고 싶었다. 내 경우에는 나의 프로세스를 검사받고 싶었다. (체크!) Livia는 Get Thins Done(GTD)를 사용 해서, 약간 다른 형식을 가졌으며 여기에서 공유하기로 동의했다. (그녀의 포스트를참조!)
전반적인 노트
지난주에 너무 많이 좋았다. 계획은 빨리 완료되었으므로 모든 씨를 뿌렸다. 그 후 3 일 동안 비가 내리지 않았지만 놀랍게도 콩과 오이의 새싹이 나 왔으며 토마토와 바질 모종은 이식 후에도 살아 남아 번성했다. 가족 휴가로 29 일까지 도시를 떠나 있을 것이다.
O : 생산적인 부엌 정원을 만들자
KR : 묘목 단계에서 6 개의 다른 식물, 수확 단계에서 4 개의 식물. - 7/10 KR : 개/다른 동물이 정원/식물을 파괴하는 일이 2 회 미만 발생. - 8/10 KR : 내 생일 (11월 21일)에 모두 정원에서 나온 적절한 음식을 하나 먹음. - 6/10
건강 지표 균형 : 후속 조치를 위해 GTD 시스템 내부에 개방형 루프 유지 - 노랑 직업 : 다음 단계와 작업/노출 기회의 탐색 - 노랑 홈 : 가족 먹이기, 내부 운영, 키갈리의 해야 할 일 관리 - 노랑
지난주의 우선 순위 100 % - P1 : 심기 순서 / 믹스를 스케치하고 파종 할 날짜/시간 블록을 일정 잡기. 100 % - P1 : 최대한 빨리 새로운 중요 주택 인프라 관련 할 일을 수행 (또는 이번 주에 가져갈 예정). 100 % - P1 : 일주일 후 케이프 타운에서 Media Party Africa를 위한 프레젠테이션을 작업. 100 % - P2 : Aimable과 퇴비화 접근법에 대해 토론. 한가지 선택 30% - P2 : 모든 열린 루프에 대해 GTD 캡춰와 처리 수행. - 여기에 필요한 시간은 연속된 3시간 할해하지 못했음. 단지 15 분 또는 30 분 밖에 할당 못함. 남아프리카로 돌아와 반나절 반나절을 할애하고 완료 예정.
다음 우선 순위 P1 : 출장 시, 정원 관리 및 토끼 관리 관련 설명을 Emmanuel에게 제공 P1 : 케이프 타운에서의 Media Payer에 대한 준비 마치고 참석 P2 : Mel and Lili와 함께 케이프 타운 휴가 기간 동안 아주 재미있게 보내기 P2 : 케이프 타운에서 내구성있는 상품 (과 할로윈 캔디) 구매하기 P2 : 다음 주말 예정이었던 참석하지 못한 새로운 기술 워크샵을 추가 예정 관련하여 Gardens for Health International에 연락하기
위험 및 방해 요인 모두 좋아 보임; 3 일의 비가 내렸다는 것은 우연한 날씨 패턴으로 보임.
"위험 및 방해 요인"이 좋아 보인다. 다음 분기에는 나의 OKR에도 통합해 보자.
당신을 추적하기 위해 누군가가 필요하다
가장 큰 교훈은 매주 OKR을 체크인하는 습관을들이는 것이 얼마나 어려운지였다. Donna는 새 아기를 낳았을 때 가장 힘들었다. 나는 시간이 일정치 않고 바뀌더라도 계속 썼었다.
일의 일부는 계속 노력하는 것이다. 희망을 잃지 말자. 하루 정도는 게으르게 보내자. 엉망으로만들자 그리곤, 자신을 용서하고 다시 시도하자. 요가나 명상과 같다. 모두 연습인 것이다.
세 명이 하는 것에 대한 좋은 점은 월요일이 OKR을 위한 것이라는 점을 기억하는 사람이 하나는 있다는 것이다. 달력에 기록해 놓아도, 정신이 없으면(11살짜리 아이가 있어서 아침은 때때로 쉬이 사라져 버린다), 잊어 버릴 수 있다.
개선 및 실험
다음 분기에는 OKR을 스프레드 시트에 보관하려고 한다. 일이 완료되지 않았던 이유의 패턴을 더 잘 찾고 싶었다. 3년간 OKR을 모니터링 해 보니, 필요한 것이 무엇인지 상당한 확신이 든다. 또한 매년 OKR과 4O의 접근 방식을 검토하고 있다. 빠른 초안은 다음과 같다.
연간 : (여기에서는 숫자 장난 대신 내가 가장 좋아하는 X를 사용하고 있다) O : 작가-교수가되는 꿈으로 살자 KR : 6 개월마다 X 품질 측정 항목이 포함 된 책 KR : X의 리뷰를 통한 강의 수업 KR : 재정과 웰빙으로 측정된 건강
Q1 : 잘 지내고, 잘 일하자 (건강을 유지하면서 글쓰기를 내 삶에 통합시키자) Q2 : 모든 것을 수정하자! (도서 및 건강 프로그램) Q3 : PMF 출시 (6 개월마다 시장에서 책을 원합니다) Q4 : 마지막으로는 소설! (나는 마침내 소설을 쓰는 꿈을 꾸고 있었다.)
이제 나는 올해의 주제(Theme)와 진전을 통해 가야할 길을 얻었다. 이제 퍼스널 OKR을 시작하는 경우에는 이 작업은 수행하지 안도록 하자! 일단 한 분기에 집중하면 흥미로운 방식으로 실패 할 것으로 예상하라. 개인 OKR을 처음한다는 것은 그것을 통해 자신이 원하는 것을 배우고 자신이 달성하려는 것을 성취하는 것 자체이다.
마지막 무작위 생각
일의 크기 조정은 어렵다. 가족이나 직장과 같은 다른 의무를 고려하여 자신의 삶에 맞는 OKR 세트를 선택해야한다. 목표는 소설만큼 크거나 정원만큼 작을 수 있다. 그 것들은 당신의 OKR이다!
규칙적으로 수행하기(Cadence)를 유지하는 것은 어렵다. 함께 추적할 수 있는 파트너를 하나 혹은 둘을 찾도록 하자. 실패는 쉽다 그리고 권장한다. 하지만, 배우고 있는지 확실히 하자! 진행하는 동안 배우는 것이 있다면, 올바르게 하고 있는 것이다.
그 것들이 당신의 삶에 맞을 때까지 시스템을 해킹해보자! Livia는 추적에 대한 생각과 일치하도록 양식을 변경했다. 더 원하는가? 덜 원하는가? 그건 당신이 원하는데로 하면된다!
필연적으로 목표를 잊어 버렸을 때 자신을 용서하고 부드럽게 자신을 다시 인도하라. 몇 주간 너무 바빠 하지 못 할 수 있다. 때로는 정신적으로 무너질 수도 있다. 다 괜찮다. 나는 퍼스널 OKR이 내 주머니에 있는 행운석이라고 생각한다. 나는 내 꿈을 상기 시키기 위해서 계속해서 그것을 매만진다. 그러나, 나는 희망하는 대신에 계획한다. 그리고 행동한다. 내가 시도한만큼 달성하지는 못한다., 하지만 기대했던 것보다 훨씬 더 많은 것을 항상 성취한다.
나의 결론은?
번역을 하면서 느낀 것 중에 하나는 역시 평가 부분이다. 일주일 혹은 분기별로 KR들에 대한 평가이다. 또한, Objective들을 돌아 보면서 분기 KR들을 다듬는 부분도 약했던 것 같다. 저자와 동료들이 하는 것 처럼 나도 바뀌고 있다.
또한, 고민해봤으면 하는 부분은 바로 같이 하는 동료를 구하는 일이다. 나를 코칭해 주고, 다른 사람에게 피드백하면서 나도 성장할 수 있을 것이다. 이 부분도 찾아 보자. 거기서 또 배울 것이다.
참고 문헌
[1] 크리스티나 워드케 (지은이),박수성 (옮긴이), "구글이 목표를 달성하는 방식 OKR", 한국경제신문 2018-11-23 원제 : Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results (2016년)
[2] 존 도어 (지은이),박세연 (옮긴이),이길상 (감수), "OKR - 전설적인 벤처투자자가 구글에 전해준 성공 방식," 세종서적2019-03-30 원제 : Measure What Matters
