오래된 SW 엔지니어의 평생 공부

S.O.L.I.D 법칙

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]의 예를 살펴 보자. 

• calculatePay() 매서드는 회계팀에서 기능을 정의하며, CFO 보고를 위해 사용한다.
• reportHours() 매서드는 인사팀에서 기능을 정의하고 사용하며, COO 보고를 위해 사용된다.
• save 매서드는 데이터베이스 관리자(DBA)가 기능을 정의하고, CTO 보고를 위해 사용된다.

즉, 서로 다른 액터가 의존하는 경우는 많이 발생한다. SRP에 따르자면, 이 코드는 분리하라고 하는 것이다. 어떻게 분리할 수 있을까? 최종적으로는 2가지가 가능해 보인다.

이 해결책은 개발자가 세가지클래스를 인스턴스화하고 추적해야 한다는게 단점이다.  이럴 때, 흔히 쓰는 기법으로 파사드(Facade) 패턴이 있다. 아래 그림과 같이, EmployeeFacade에 코드는 거의 없다. 이 클래스는 세 클래스의 객체를생성하고, 요청된 메서드를 가지고 객체로 위임하는 일을 책임진다. 이렇기 때문에,  Facade는 Architectural Composition이라고도 한다.

Employee Data를 CFO에서 담당한다고 하면 Employee Facade Class로 가져올 수 있다면 구조는 조금 더 단순화 될 수 있다. 아래 구조가 최종 구조라고 하면, CFO는 Employee Class를 담당하고, COO는 HourReporter Class를 담당하며, CTO는 EmployeeSaver Class를 각각 담당하여 개발을 진행하면 SRP가 잘 유지되며 개발될 수 있다고 볼 수 있다. 이처럼 조직의 구조도 Software의 구조에 영향을 미친다.

개방-폐쇄 원칙 (Open Close Principle OCP)

개방-폐쇄 원칙(OCP)이라는 용어는 1988년 버트란드 마이어(Bertrand Meyer)가 만들었는데, 소프트웨어 개체(Artifact)는 확장에는 열려 있어야 하고(Open to Extension) 변경에는 닫혀 있어야 한다(Close to Modification)라는 원칙이다. 즉, 객체의 행위는 확장할 수 있어야 하지만, 이 때 개체를 변경해서는 안된다. 어찌 보면 모순 같은 이야기는 매우 중요한 원칙이기도 하다.

책에서는 여러 번 이야기 하지만, 변경이 되지 많아야 할 곳과 변경이 되는 것을 분리하고 변경이 되는 곳이 변경되지 않는 것에 종속되도록(Dependent)하도록 해야 한다는 것이다. 그리고, 이 변경 되는 쪽을 확장하는 쪽으로 쓰고 변경되지 않도록 하는 쪽은 한 곳으로 모아 두어야 한다는 원칙이다.

어떻게 이를 획득할 수 있을까? 책에서의 제무제표 웹 시스템에서는 그러한 예를 많이 보유하고 있다.

일반적인 방향성 제어의 방법에서는 위의 예에서 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의 하위 타입이다.

이 원칙은 일반적으로 OOP에서 상속을 사용하도록 가이드 한다. 위의 예가 바로 그것인데, Billing 애플리케이션의 행위가 License 하위 타입 중 무엇을 사용하는지에 전혀 의존하지 않기 때문이다. 이들 하위 타입은 모두 License 타입을 치환할 수 있다. 이를 Liskov Substitution Principle LSP라고 한다.

정사각형/직사각형 문제는 LSP에서 발생될 수 있는문제를 설명한다.  Square는 Rectangle의 하위 타입으로는 적합하지 않은데, Rectangle의 높이와 너비는 서로 독립적 변경이다. 하지만, Squarue이 높이와 너비는 반드시 함께 변경되기 때문이다. 이런 형태의 LSP 위반을 막기 위한 유일한 방법은 (if문 등을 이용해서) Rectangle이 실제로는 Square인지 검사하는 매커니즘을 User에 추가하는 것이다. 하지만 이렇게 하면 User의 행위가 사용하는 타입에 의존하게 되므로 결국 타입을 서로 치환할 수 없게 된다. 다시 말하자면,  개념적으로는 LSP라 생각하기 쉽지만 이렇게 LSP를 적용하는데는 적당하지 않다.

객체 지향이 혁명처럼 등장한 초창기에는 앞서 본 것 처럼 LSP는 상속을 사용하도록 가이드하는 방법 정도로 간주 되었다. 하지만, LSP는 인터페이스와 구현체에도 적용되는 더 광범위한 소프트웨어 설계 원칙으로 변모하였다.

인터페이스 분리 원칙(Interface Segregation Principle, ISP)

아래 왼쪽 그림 기술된 상황에서,다수의 사용자가 OPS 클래스의 오퍼레이션을 사용한다. User1은 오직 op1을 User2는 op2만을 User3는 op3만을 사용한다고 가정해 보자. 이러한 문제는 아래 그림 오른쪽에서 보는 것처럼 오프레이션을 인터페이스 단위로 분리하여 해결할 수 있다. 

정적타입 언어는 소스코드에 '포함된 included'선언문으로 인해 소스 코드 의존성이 발생한다. 루비나 파이썬과 같은 동적 타입 언어서는 소스코드에 이러한 선언문이 존재하지 않는다. 대신 런타임에 추론이 발생한다. 동적 타입 언어를 사용하면 유연하며 결합도가 낮은 시스템을 만들 수 있는 이유는 바로 이때문이다. 이러한 사실로 인해 ISP를 아키텍처가 아니라, 언어와 관련된 문제라고 결론내릴 여지가 있다. 

일반적으로 필요 이상으로 많은 걸 포함하는 모듈에 의존하는 것은 해로운 일이다. 고수준인 아키텍처 수준에서도 마찬가지 상황이다. 

의존성 역전 원칙 (Dependency Inversion Principle)

의존성 역전 원칙(DIP)에서 말하는 '유연성이 극대화된 시스템'이란 소스 코드 의존성이 추상(Abstraction)에 의존하며 구체(Concretion)에는 의존하지 않는 시스템이다. use, import, include 구문은 오직 인터페이스나 추상 클래스 같은 추상적인 선언만 참조해야 한다는 뜻이다. 구체적인 대상에는 절대로 의존해서는 안 된다.

우리가 의존하지 않도록 피하고자 하는 것은 바로 변동성이 큰(Volatile) 구체적인 요소다. 그리고 이 구체적인 요소는 우리가 열심히 개발하는 중이라 자주 변경될 수 밖에 없는 모듈들이다.

실제로 뛰어난 소프트웨어 설계자와 아키텍트라면 인터페이스의 변동성을 낮추기 위해 애쓴다. 인터페이스를 변경하지 않고도 구현체에 기능을 추가할 수 있는 방법을 찾기 위해 노력한다. 다음과 같은 매우 구체적인 코딩 실천법이 있다. 사실 이것이 DIP를 다시 쓴것과 같다.

• 변동성이 큰 구체 클래스(Concrete Class)를 참조하지 말라. (Refer)
• 변동성이 큰 구체 클래스(Concrete Class)로 부터 파생하지 말라 (Derive)
• 구체함수를 오버라이드하지 말라. 대체로 구체 함수는 소스 코드 의존성을 필요로 한다. 따라서 구체 함수를 오버라이드하면 이러한 의존성을 제거할 수 없게 되며, 실제로는 그 의존성을 상속하게 된다.
• 구체적이며 변동성이 크다면 절대로 그 이름을 언급하지 말라 

아래 그림에서 곡선은 아키텍처 경계를 뜻한다. 이 곡선은 구체적인 것들로부터 추상적인 것들을 분리한다. 소스 코드 의존성은 해당 곡선과 교차할 때 모두 한 방향, 즉, 추상적인 쪽으로 향한다. 제어흐름은 소스 코드 의존성과는 정반대 방향으로 곡선을 가로지른다는 점에 주목하자. 다시 말해 소스 코드 의존성은 제어흐름과는 반대 방향으로 역전된다. 이러한 이류로 이 원칙을 의존성 역전(Dependency Inersion)이라고 부른다. 

위 그림의 구체 컴포넌트에는 구체적인 의존성이 하나 있고, 따라서 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일, 송준이 역

[2] Design Pattern 첫 번째: Object Oriented Principles, https://technical-leader.tistory.com/7

배경

제약 이론을 처음 알게 된 것은 데이비드 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에서는 하나의 비즈니스가 다른 비즈니스에 판매한다.

참고 문헌

[1] The art of the OKR, Redux, http://eleganthack.com/the-art-of-the-okr-redux/

[2] The art of the OKR, http://eleganthack.com/the-art-of-the-okr/

[3] Radical Focus, 구글이 목표를 달성하는 방식 OKR

나는 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

[3] OKR을 활용하여 성과를 높이는 애자일 조직문화 만들기, https://learningspoons.com/offline-class/offline-biz/okr

[4] 도미닉 스펜스트 (지은이),김윤재 (옮긴이), "6분 다이어리 - 작지만 확실한 행복," 행성B(행성비)2018-03-14 원제 : Das 6-Minuten-Tagebuch (2016년)

[5] Christina Wodtke, "Personal OKRs, three years later," https://medium.com/@cwodtke/personal-okrs-three-years-later-7616e60574a4

들어가며...

아래 글은 Facebook에 썼다가 기억이 나서 블로그에도 옮겨 적어 본다.

간한절 협업에 대하여...

오늘 일간 애자일의 글 중 가장 쇼킹한 글[1]. 간헐적 협업. 처음 읽을 때는, 혼자 일 할 때 가장 창의적이 된다라는 이야기로 내 뒷통수를 때리는 글이었다.

원본을 봐야겠다 해서 검색하다 찾은 DBR의 글[2]에서는 조금 더 명확하다. 나는 네트워크에서 연결이 중요하다 생각했다. 그렇게 믿고 있었다. 반은 맞고 반은 틀렸다. 글의 실험에서는 '사실 발견'은 연결이 높을 때 결과가 좋다고 한다. 반대로, 솔루션 찾을 때는 과도한 연결이 않좋다고 한다.

다이어트에 운동이 좋다는 믿음으로 식단을 무시하거나, 반대로 식단 만으로 운동이 부족해 에너지를 소모하지 않는 몸을 만들면 요요가 찾아온다.

갑자기 예전에 TF를 하면서 기술 리더들을 하루에 4~5번 씩 불러 미팅하던 TF 리더가 생각났다. 그 때 나는 그것이 과하다 생각했다. 하지만, 정보가 부족했던 초창기에는 그게 맞았던 것일 수도 있겠다 생각이 봐뀌었다. 아쉬었던 것은 그것에 대한 설명이다.

'피드백', 그것이 있었다면, 그 TF 리더도 말해주지 않았을까? 한번 뵙기로 약속은 했는데, 오늘은 날짜라도 확정지어 봐야겠다.

참고 문서

[1] 하루 종일 메신저하고 회의해봐야 소용 없다. 제대로 협업하는법, https://m.blog.naver.com/PostView.nhn?blogId=businessinsight&logNo=221994080342&proxyReferer=http:%2F%2Fblog.naver.com%2Fbusinessinsight%2F221994080342&fbclid=IwAR0XGhuXc-Y7Oyj_eS8X4yS5wxQXidkPLY7uDqdoHP_dYAWpXdPIj2x4wMs

[2] 간헐적인 협업 리듭이 더 효율적인 이유, https://dbr.donga.com/article/view/1201/article_no/9349

내가 사용하고 있는 컴퓨터 언어에는 C/C++, Java, Python이 예전에 사용하던 Perl등도 포함할 수 있겠지만 너무 사용하지 않고 있다. 최근에 관심이 가는 언어는 Go Lang이다. Google의 개발자인 로버트 그리즈머, 롭 파이크, 켄 톰슨 세사람이 개발한 언어이다. [1]에서 설명하는 특징은 다음과 같다.

• 정적 타입, 강 타입 ...
• 컴파일 언어 ...
• 가비지 컬렉션 ...
• 병행성(Concurrency) ...
• 멀티코어 환경 지원 ...
• 모듈화 및 패키지 시스템npm, pip, gem 이나 Maven과 같은 모듈 의존성에 따른 패키지 관리를 언어 차원에서 지원. ...
• 빠른 컴파일 속도

이 언어를 개발한 이유가 C/C++이 사용하기 어려워서 개발하기 시작했다고 한다. 그래서, 서버, 브라우져, 데이터베이스등 큰 응용을 개발하는데 유용하다고 한다. 하지만, 시스템 레벨 프로그래밍에는 적절하지 않다고 한다. 

대략적인 문법이나, 특징은 책에서도 볼 수 있지만 인터넷에 자료가 많고 특히 [2]에서 보게 되었다. 

내가 이 언어를 보게 된 가장 큰 이유는 Android의 Build Systemdp Ninja[3]로 바뀌고 Blueprint(.bp)[4]로 변경되기 시작하고 이다. 이 bp파일들이 Go lang으로 쓰여 지고 있다.

참고 문헌

[1] GO 언어란? - 주요 특징,  https://goodjoon.tistory.com/241

[2] A Tour of Go, https://tour.golang.org/welcome/1

[3] Ninja, a small build system, https://ninja-build.org/

[4] Soong 빌드 시스템, https://source.android.com/setup/build

Game Streaming 서비스 비교

Game Streaming 서비스가 다양해 지고 있다. [1]에는 최근 Game Streaming 서비스를 비교하고 있다. 이러한 서비스는 스마트 폰과 같은 수신기기에서 서버로 부터 게임 화면을 스트리밍 받아서 지원하는 기술이다. 실재로 WebRTC와 보다 더 짧은 Latency 요구 사항이 요구 된다. 이러한 기술은 대부분 서비스 별로 다르기 때문에 상세 내용이 공개 되어 있지 않다. 하지만, Parsec이라는 기술은 이 상세 내용에 대해서 약간의 정보를 제공하고 있으므로 이를 살펴 보고 특징을 이해할 수 있다.

Parsec 개요

Parsec은 Free Game Software이다. 위에서 설명한 것과 같이 Streaming 방식으로 할 수있게 해준다. 지원이 종료되었지만, 삼성의 PlayGalaxy라는 서비스도 이를 활용한 것이다. [2]에는 Android 및 iOS SDK가 제공된다. Source Code는 제공되지 않는다.

Parsec 기술 설명

Parsec에서는 20ms으로는 아주 훌륭한 게임 경험을 할 수 있지만 40ms만 되어도 사용할 수 없다고 한다. 이는 WebRTC가 1초 미만의 수백 ms의 요구 사항이었다고 보면 이 요구 사항은 이 보다 한단계 더 낮은 Latency를 요구하는 서비스라고 생각할 수 있다.

[3]에서는 Parsec이 동작하는 방식을 설명하고 있다. 

1. Capture raw desktop frames
2. Encode the raw frames
3. Send the encoded frames over the network
4. Decode the frames
5. Render the frames on the screen

1번에서는 Windows 8.1부터 빠른 캡춰를 가능하게 한다고 한다. 2의 경우는 nVidia와 같은 빠른 인코더를 사용해서 성능을 높이고 있다고 한다. 

Codec의 경우는 H.264의 60fps 설정이 저지연으로 동작한다고 한다. 또한 Codec의 인터페이스 사용을 직접하여 지연도 줄인다고 한다.

이렇게 처리된 데이터는 화면에 Rendering되게 되는데, 데이터를 GPU상에서 모두 처리하게 되면 지연이 준다고한다. Memory Copy와 Color coversion등이 효율화 항목 중 하나이다.

네트워크 성능도 중요한데, 아래 그림과 같이 Local에서 하는 것과 Cloud에서 하는것의 성능 차이가 상당히 있다. 5G Network의 Mobile Edge Computing(MEC)를 사용하는 것도 장점이 있을 것이다. 이러한 이유로 xCloud등이 모바일 사업자와 협력하는 것이 이유가 있다고 볼 수 있다.

아래 그림에서와 같이 nVidia와 AMD의 코덱 성능에는 차이가 상당히 있다. 그렇기 때문에 nVidia를 사용하는 것이 Game Streaming에 성능에 차이가 있을 수 있다. 그리고, Encoder쪽의 성능 차이가 중요한 부분일 수 있다고 생각된다.

성능 최적화

nVidia의 코덱을 사용하더라도 설정을 잘 못하면 성능의 차이가 나올 수 있다. [6]에서는 nVidia Codec의 목표에 따른 코덱 최적화 방법을 설명한다. 아래 표가 

상기 테이블의 내용 중 아래 옵션들은 관련된 주요 파라미터 설정에 대한 설명을 포함한다.

-bf set maximum number of B frames between Non B frames (default 0)

-rc-lookahead Number of frames to look ahead for frametype and ratecontrol

-b bitrate video bitrate (pelease use –b:v)

-bufsize set ratecontrol buffer size (in bits)

-g set the group of picture (GOP) size. 999999 is about 44h with 60fps

-maxrate Set maximum bitrate tolerance (in bits/s)

-tune zerolatency

특히, B frame의 사용 여부, bitrate할당 방법의 차이 그리고 GOP 크기등을 통해서 주요한 설정 방법에 대해서도 가늠해 볼 수 있다.

정리하며...

Game Streaming은 이야기 한데로, 표준이 아니면서도 극단적인 스트리밍 요구 사항이 포함되어 있어 매우 흥미롭지만 내용이 많은 내용이 공개 되어 있지 않은 문야이다. 점차 Client의 계산 능력으로는 충분하지 못하고 Cloud에서 힘을 빌려야 하는 응용이 늘어 날 수록 이 기술은 적용 범위가 확대 될 것이므로 기본적인 이해가 필요하다고 생각된다.

참고 자료

[1] Game Streaming 서비스 비교, https://www.clien.net/service/board/lecture/14562043

[2] Parsec SDK; https://github.com/parsec-cloud/parsec-sdk

[3] Parsec Description: https://blog.parsecgaming.com/description-of-parsec-technology-b2738dcc3842

[4] Parsec Introduction to Video Codec, https://blog.parsecgaming.com/an-introduction-to-video-compression-c5061a5d075e

[5] New Nvidia GPUs Outperform New AMD Cards On H.264 Compression Latency, https://blog.parsecgaming.com/new-nvidia-gpus-outperform-new-amd-cards-on-h-264-compression-latency-d32784464b94

[6] Turing H.264 Video Encoding Speed and Quality, https://devblogs.nvidia.com/turing-h264-video-encoding-speed-and-quality/

이 글은 오래전 Wowza에서 발간한 가이드 문서[1]를 살펴 보고 실시간 인터액티브 스트리밍의 구조 관련 내용을 정리하려고 한 것이다. 우선은 일반적인 실시간 연동이라고 하면, Live 방송을 해야 하고, 사용자에게 Interaction을 받아서 이를 처리하여야 한다. 그러므로, 일반적인 Pipeline을 설명하고, 관련된 비디오 스트리밍 프로토콜에 대해서 설명하려 한다.  사용자 인터액션에 대한 처리를 원할히 하기 위해서는 저지연, 즉 Low Latency까지 이야기 되어야 한다.

일반적인 Live Streaming 서비스 구조

우리가 YouTube 혹은 Facebook을 이용하여 라이브 방송하는 구조를 생각할 수 있다. 복잡한 장비를 사용하여 TV 방송 수준 품질의 방송을 하던, 아주 간단하게 휴대폰을 활용하던, 실재 Streaming을 위한 구조는 대동 소이하다.

Live Video Streaming의 경우는, 아래 그림과 같이 First Mile에서는 카메라에서 동영상을 비디오를 촬영하면 이를 전송 가능한 형태로 인코딩한다. 아직까지 일반적으로는 H.264를 많이 사용한다. 이를 처리하기 위한 서버로 전송하는데 아래 그림에서는 Processing 혹은 Ingestion이라고 한다. 이를 위해 전송하는 프로토콜은 RTMP, RTSP/RTP 혹은 SRT를 사용한다고 한다. 

위에서 이야기 한데로 YouTube 혹은 Facebook이 Live 기능을 제공하기 시작하면서 개인 방성 기술에 대해서 여러 접근 법이 있었다. 그리고, 주로 많이 사용되는 것은 한번 상용화가 되기 시작하니 우후 죽순 처럼 RTMP[1] 기술이 주류처럼 나왔지만, 정말 오래된 기술 중 하나인 RTSP/RTP도 사용되고 있다.

처리된 콘텐츠들은 서비스 특징에 따라 전송 방법들을 달리한다. 위의 그림은 YouTube와 같이 많은 사용자들이 볼 수 있는 형태인 DASH 혹은 HLS로 변환하여 Content Delivery Network (CDN)을 통해 배포 하는 사례를 보여 준다.

지연 요구 사항에 따른 Streaming Protocols

아래 그림은 다양한 지연 요구 사항에 따른 Last Mile 처리 Protocol의 사례를 보여 준다. 

처음 이야기 한 것과 같이 HLS, DASH는 일반적으로 많이 사용되고 있다. 많은 비디오 스트리밍 구성들이 캡춰에서 재생까지 30초 이상의 지연(Latency)을 가진다. 쉽게 말하면, YouTube에서 라이브로 보고 있는 내용들인 대부분 30초 전에 일어난 일이라는 것이다.

저지연이면서도 많은 사람들에게 전송하기 위한 Protocol Tuning을 하기 위해서 최적화 작업을 하는 업체들이 많다. 위에 그림에서 볼 수 있듯이 그렇다 하더라도 5초 이상의 지연을 가지게 된다.

이러한 노력에 추가하여, 프로토콜 표준상 최적화를 위해서 Low Latency HLS와 CMAF를 채용한 DASH가 제안되기도 했다. 기본 개념은 HLS/DASH에서 수신하는 작은 조각 (Fragment 혹은 Chunk)라고 불리는 것들을 작게 만들어 수 초대의 지연으로 만들어 일반 방송과 유사한 수준까지 만드는 것이다.

그렇다면, 이보다 낮은 방법은 없는 것인가? Wowza에서는 WebRTC를 제안하고 있다. 하지만, 이는 Peer-To-Peer 방식으로 콘텐트 소비자의 가까운 곳에 Computing Resource를 할당 하는 등 HLS/DASH 기반의 다른 방식에 비해서 비용이 높을 수 있다.

정리

위의 그림 하나로 모두 정리 된다고 볼 수 있지만, 사용자 인터렉션의 요구 사항이 높아지는 가운데, Low Latency HLS 혹은 CMAF를 이용한 DASH까지 가고 있지만, 실재로 서비스의 구성을 잘 고려하지 않으면 원하는 품질을 확보하기 어렵다. 이를 위해서는 실재 컨텐츠의 해상도 품질과 지연 요구 사항을 잘 고려하여 서비스를 고민해야 한다.

참고 문서

[1] Wowza media systems, "Real-Tme Interactive Apps: A Best Practices Guide With The Wowza Streaming Cloud Service", (링크 깨짐) https://www.wowza.com/uploads/images/Real-Time-Interactive-Apps-WSC-2019.pdf

다른 링크

[2] Streaming Protocols: Everything You Need to Know, www.wowza.com/blog/streaming-protocols

[3] 2019 Video Streaming Latency Report, https://www.wowza.com/blog/2019-video-streaming-latency-report

개요

이 책[1]은 오래 전에 읽었던 것이다. 아래 내용들은 읽으면서 기억하고 싶은 내용들을 메모한 것이다 아메리컨 풋볼 코치로서 리더십에 관련된 내용을 정리한 것인데, 팀을 운영하는 사람으로서는 참고할 만한 내용이 많다. 

책 내용 요약

I. 리더가 될 준비를 하라

Ch1. 열정을 품고 시작하라.

내꿈은 고등학고 풋볼팀 감독이 되는 것이었다. 

Ch2. 돈보다 참된 스승을 쫓아라

. 블랑그린 주립대학 로이튼 페리, 노스웨서던 대학 애리 파사지언, 오하이오 주립대 우디 페이스

. 나의 스승들은 누구인가?

Ch3. 적당한 때를 기다려라.

. 지식을 최고의 코치가 되는데 사용했다.

 좋은 기회가 오기를 기다려라, 그리고 나머지는 모두 거절하라. 그러면, 상황은 완전히 달라질 것이다.

II. 주도권을 확보하라

Ch4. 첫날 부터 기준을 확립하라

리더가 되기 위한 준비! -> 이것이 역사를 바꾼다.

Ch5. 몸 담고 있는 곳의 역사를 존중하라

. 사람들에게 모든 것이 달라질 것이라는 찬물을 끼언어야 한다. 하지만, 단체나 조직에게 똑같은 행동을 하면 안된다.

Ch6. 정직하라

. 회사 스캔들 "저는 몰랐습니다."

  나중에 알게되도, 그것에 맞게 해야 한다.

. 정직하라

Ch7. 기대치를 명확히 제시하라

. 용건이 없는 회의는 소집하지 마라

1. 다른 사람을 존경하라

2. 정직하라

3. 자신의 성적에 책임을 져라

4. 외부인을 들이지 말라

5. 살아도 팀, 죽어도 팀, 팀만이 전부다

Ch8. 리더가 되려면 목표를 세워야 한다.

. 위에서 아래가 아니라, 목표를 달성할 책임이 있는 사람에게서 목표가 나와야 한다.

. 리더는 팀원들이 목표에 도달할 수 있도록 도와 주고, 목표가 무엇인지, 그 꿈을 이루기 위해서 무엇을 어떻게 해야할지 "매일" 일깨워야 한다.

. 일년에 한번 리더가 정한 목표를 보여주는 것은 의미가 없다.

. 팀의 목표는 팀원들이 정하며, 그것이 뼈에 사무쳐야 한다.

  팀원들에게 중차대한 책임감을 안겨줘야 한다.

  직원들에게 리더가 될 기회를 주는 것. 그것이 리더가 할일이다.

III 내 팀을 만들어라

Ch9. 나를 위해 일하겠다는 사람을 채용하라

. 미시건대에서 데리고 있던 36명의 코치들은 11명이 다른 곳의 감독이 되었다. 새로운 사람을 뽑으려고 하면,나는 그들에게 전화해서 마땅한 사람이 없는지 물어 본다.

. 현재하고 있는 일을 그만 두고 싶어 안달이 난 사람을 채용하는 일은 하면 안된다.

. 다른 곳에서 선수를 스카우트 하는 일보다는 코치를 면밀히 분석하는데 더 많은 시간을 투자해라

 가족들을 만나는 것도 중요하다. 배우자는 내조할 강건함이 있어야 한다.

Ch10. 참모진을 최대한 활용하라

. 참모진 만큼은 내 의사대로 끌고 갈 생각이 없다. 스태프 미팅에 참석하면, 너 나할 것없이 고함을 지르고 주먹을 내리치는 광경. 코치 한명을 일부러 골탕 먹일 때도 있다. 가장 좋은 것을 추려내기 위함이다.

. 우리는 우리가 무엇을 할 것인가, 그리고 그것을 어떻게 할 것인가에 대한 의견 일치 없이는 맹세코 단 한번도 필드에 나간 적이 없다는 사실

. 잠시 짬을 내서 주변에 벌어지는 일들을 되는데로 골라 이야기 나누면 인간적인 관계를 맺을 수 있다.

. 일단 책임자가 되면, 나는 채찍, 부관들은 당근이다. 일단 감독이 되면, 코치처럼 행동하면 안된다. 더 이상 보조가 아니다.

. 리더는 보좌진을 불리한 입장에 두게 하면 안된다.

Ch 11. 품성으로 사람을 뽑아라

. 재능이 중요하지만, 품성을 보고 선수를 뽑아야 두다리 뻣고 편히 잘 수 있다.

. 가장방문으로 잃는 선수보다 우리를 잃는 유망주가 2배 더 많다.

Ch 12 아랫사람을 리더로 키워라

. 그러히 않으면 혼자 모두 떠 맡아야 한다.

. 경찰관이자, 인생의 안내자가 되게 해야 한다.

. 선수들을 차별대우 했다는 점은 굳이 부인하지 않겠다.

Ch 13 스타 시스템을 폐지하라

. 사람을 다루는 법

  스타플레이어는 분수를 지키게. 중간 실력은 동기 부여, 실력이 처지는 친구는 성공에 기여하도록

. 당분간 나를 떠날 생각이 없는 선수라면, 최대한 능력을 발휘하게 한다.

Ch 14 중간 계층의 사기를 복돋워라

Ch 15 누구에게나 기회를 줘라

. 누군가 받아들이기 어려운 결정을 내려야 한다면, 그런 결정을 내릴 수 밖에 없는 이유를 설명해 주어야 한다. 당사자가 달가와 하지않겠지만, 이해해줄 것이고, 설명을 들은데에 대해서 고마운 마음을 품을 것이다. 방법은 간단하다. 진실을 이야기 해주는 것이다.

. 팀이 가진 능력을 최대한 이끌어 내려면, 별 능력이 없어 보이는 사람이라도 무엇인가 보여줄 수 있는 기회를 주어야 한다.

Ch 16 각자의 역할을 주고 가치를 인정하라

. 우리가 모든 선수들에게 준것은 시간과 관심.

Ch 17 불가피한 해고를 하려면 재빨리 단행하라.

. 단 한시간도 1분도 허투루 다루면 안된다.

 어떤 직업도 수련 과정이 필요하다. 그렇기 때문에 리더의 궁극적인 책임은 아랫 사람을 훈련시키는 것이다.

. 훈련을 계획 할 때, 최종 결과물을 생각해야 한다.

Ch 18 철저한 준비 태세를 갖추어라

.Staff, 선수, 연습, 모니터링, 연습 경기

  -> 25초라는 시간. 경기당 100번, 1년에 총 12경기

  -> 미리 조직화 하고 연습시키고 완전히 체득케 하는 일이다.

  -> 훈련은 최대한 실전에 가깝게 설계해야 한다. 일어나지 않을 것 같은 상황도 준비하고 훈련한다.

IV 문제는 신속하게 해결하라

Ch 19 남의 말을 경청하라

. 남의 말을 경청하지 않는 사람은 리더가 될 수 없다.

.내게 말하는 사람에게 귀를 기울이지 않는 것은 그 사람에게 나는 당신이 필요 없다라는 메시지를 전달하는 것이다.

Ch 20 아랫사람을 철저히 파악하라

.두려움을 버리고 선수들의 라커룸, 직원들의 현장속으로 걸어들어가야 한다.

.아랫사람을 파악

  - 어디 출신인지, 어떤 목표를 지향하는지?

  - 그들의 장점, 약점은 무엇인지? 

  - 하다 못해 그들이 입는 옷의 단추가 어떻게 생겼는지?

Ch 21 밤새 고민하지도 앙심을 품지도 말라

. 인사 문제를 오래 끌지 마라. 잘못되었다며 나중에 사과하면 된다.

V 중대한 고비를 정면으로 맞서라.

Ch 22 철저히 무너뜨리고 다시 일으켜 세워라

. 풀이 죽어 있을 때 아무 소리 하지 않는다

 기분이 고조 되어 있을 때, 찬물을 끼얹는다.

 약팀도 부풀렸다. 약체일수록 더 부플렸다.

Ch 23 혁신보다 제대로 된 실천을 강조하라

. 모든 것은 실천으로 귀결된다. 훌륭한 아이디어 보다도...

. 기본기가 잡혀 있지 않으면 구급기술도 할 수 없다.

  -> 지열대에 물건이 가지런히 놓여 있는지?

  -> 잘 팔리는 물건은 떨어지지 않게.

  -> 인사를 잘한다.

Ch 24 연설 대본은 찢어 버려라

. 연설을 잘하고 싶다면, 열정을 품고 있는 주제를 말해야 한다.

. 대본은 찢어 버려라. 마음에서 우러난 이야기를 하는 편이 백배 낫다.

Ch 25 현실에 기반을 두고 작전을 변경하라

. 같은 일을 고집하면 매번 같은 결과를 얻을 뿐이다. 다른 결과를 원한다면 다른 일을 해야 한다. 함게 일하는 보좌진의 말을 경청하고 기존의 작전을 변경하는 것은 절대 나약함의 상징이 아니다. 실패하는 작전을 고수하는 것이야 말로 나약함의 상징이다.

Ch 26 위기를 기회로 바꿔라

. "Sudden Change" 공이 상대에게 넘어 갔을 때, 좌절하지 않고 상대의 피를 말릴 수 있는 기회로 여겼다.

Ch 27 포화 속에서도 중심을 잃지 마라

.선수들의 눈과 귀가 열려 있을 대 최대한 활용해야 한다.

 실재 고객과 마주할 때 한참 중압감에 시달릴 때 몇미리는(??) 직원이 사회 생활을 하는 내내 중요한 지침이 되어 줄 것이다.

. 손수 모범을 보이는 일 또한 중요하다.

Ch 28 기본을 다시 세워라

. 감독을 오래 하다 보면, 한번쯤 실망스러운 해를 겪어야 하는 때도 온다.

. 문제의 핵심을 파고 들어 고쳐야 한다.

. 과거에 정립했던 기본 원칙에 맞춰 조직의 잘못된 면을 고쳐가면 간단하다.

Ch 29 세간의 비평은 무시하라

. 중요한 것은 조직원들의 생각이다.

돌아 보며...

이 책에는 인생 경험이 녹아있다. 아마도 인간적이며, 카리스마 넘치는 리더가 있다. 다분히 개인 특징이 있을 수도 있다고 생각한다. 내가 나로서 받아 들일 수 있는 부분에 대해서 좀 더 고민해 봄직하다.

참고문헌

[1] 보 스켐베클러, 존 U. "베이컨, 전설의 리더, 보", 서돌, 2008년 (원제 : Bo's lasting lessons)

소개

이 글[1]은 2015년도 글이기는 해도, 최근에 발견했다. 애자일 과정과 기존의 Software Architecture 접근법에 대한 고찰이 포함되어 있어 참고할만한 글이다.

Towards an Agile Software Architecture

소프트웨어 아키텍처는 시스템의 골격(Skeleton)이다. 다른 기능적 요구 사항(Functionall Requirements)과 비기능적 요구 사항(Non-functional requirements)으로 시스템이 작동하는 방식을 정의한다. 한편으로 전통적인 워터폴 방식은 프로젝트 개발의 모든 단계에 강한 제약을 가하기 때문에 엄격하다. 반면에 애자일 접근법은 개발 단계 후반에도 변경 사항을 환영한다. 우리는 견고한 개발에서보다 유연한 개발로 전환하고 있지만, 소프트웨어 아키텍처는 골격(Skeleton)이라는 태생상 기본 특성으로 인해 변화에 민감하다. 따라서 애자일 접근법을 따라갈 때 핵심 요소는 지속 가능한 소프트웨어 아키텍처의 개념을 수용하는 것이다. 이는 프로젝트의 복잡성 증가와 함께 시스템 확장이 점진적이고, 쉽고, 유지 보수 가능한 방식으로 이루어질 수 있도록한다.

이 글에서는 기존의 워터폴 소프트웨어 아키텍처와 애자일 아키텍처 모두에서 작업 할 때의 경험을 다룬다. 나는 세 가지 영역에 중점을 둔 이들의 유사점과 차이점을 묘사한다.

• 소프트웨어 아키텍트 역할의 세부 사항
• 소프트웨어 아키텍처의 타임스팬(Timespan)
• 소프트웨어 아키텍처의 결과물

소프트웨어 아키텍처란 무엇인가?

소프트웨어 아키텍처에 대한 정의는 수백 가지가 있다 (실제로 새로운 본인의 정의를 직접 추가 할 수도 있음). 그 이유는 모든 사람이 자신의 상황에 따라 정의하기 때문이다. 나는 특히 IEEE의 정의를 좋아하는데, 기본 개념을 설명하고 머리에서 쉽게 그려 볼 수 있기 때문이다. 또한 소프트웨어 아키텍처의 생성 방식이 아니라 소프트웨어 아키텍처의 본질을 묘사하기 때문에 워터폴 및 애자일 프로세스에 모두 적용된다. 이 글의 나머지 부분에서 나는 이 정의를 언급 할 것이다.

구성 요소(Components) 서로와 그리고 환경(Environment)과의 관계(Relationship), 설계 및 진화(Evolution)를 안내하는 원칙으로 구현되는 시스템(System)의 기본 구조(Fundamental Organization)

워터폴 소프트웨어 아키텍처

기존의 워터폴 개발은 시작 날짜와 종료 날짜가 명확한 일련의 단계로 구성되며, 각 단계에는 특정 활동 세트가 포함된다. 모든 단계는 서로 연결되어 있으며 각각의 단계는 이전 단계에서 생성된 결과물에 크게 의존한다. 그림 1은 폭포 개발과 관련된 일반적인 단계를 보여준다.

소프트웨어 아키텍처에 대한 작업은 일반적으로 소프트웨어 요구 사항이 정의 된 후에 시작된다. 이 시점에서 시스템은 수행해야 할 작업에 대해 잘 정의되어 있다고 가정한다. 다음 단계는 소프트웨어 아키텍처를 정의하는 담당자와 이 단계의 실제 결과를 조사하는 것이다.

전통적인 소프트웨어 아키텍트

소프트웨어 아키텍처는 실제로 소프트웨어 아키텍트가 수행한다. 기술 지식과 경험이 풍부한 사람이다. 일반적으로 회사의 특정 수준에 도달한 후 승진 한 개발자이다. 이 사람은 소프트웨어 요구 사항을 분석하고 이러한 요구 사항을 기반으로 미래 시스템에 대한 특정 기술 결정을 담당한다. 많은 회사에는 일반적으로 프로젝트 당 하나의 소프트웨어 아키텍트가 있지만 일부 대기업에는 소프트웨어 설계자 팀이 함께 작업 할 수 있다. 이는 일반적으로 프로젝트 도메인이 복잡하거나 프로젝트의 기간이 더 큰 경우 (예 : 2-3 년 이상)이다. 모든 회사에 지정된 소프트웨어 아키텍트 역할이있는 것은 아니다. 많은 회사에서 이러한 책임을 경험 많은 개발자(Senior Developer)에게 위임한다. 이 글의 나머지 부분에서는 명시적으로 언급하지 않는 한 소프트웨어 아키텍트는 다른 누군가가 하지 않고 소프트웨어 아키텍트가 수행하는 특정 활동을 언급한다.

전통적인 소프트웨어 아키텍트는 다음과 같은 네 가지 주요 기능을 담당한다.

• 큰 그림에 초점을 맞춘다. - 소프트웨어 아키텍트는 시스템이 향후 몇 달 (때로는 몇 년)처럼 어떻게 보일지 고려해야한다. 또한 관련된 다른 모든 시스템 (예 : 타사 시스템 및 데이터 저장소)과 시스템 간의 통신이 어떻게 진행 될지 고려해야 한다.
• 규정 준수 지향 - 소프트웨어 아키텍트는 가능한 규정 준수 문제를 고려해야 한다. 이것은 입법 규범, 라이센스, 표준 또는 기타를 포함하여 미래의 시스템이 이러한 중요한 기준을 충족하도록 해야한다.
• 청사진을 생성한다. - 중요한 산출물은 다양한 관점에서 아키텍처를 설명하는 문서 및 다이어그램 모음이다. 개발 팀은 이러한 결과물을 사용하여 시스템 구축을 시작한다.
• 실무 경험이 많지 않음 - 소프트웨어 아키텍트의 목표는 개발 팀을위한 최종 문서를 작성하는 것이다. 소프트웨어 아키텍트는 일반적으로 개발자로서의 경험이 있지만 개발 프로세스에는 거의 관여하지 않으며 개발자가 설계 시스템을 구축하도록 유도한다. 어느 시점에서 그는 개발자는 남겨 두고, 다른 프로젝트로 이동할 수 있다. 

실제 사례의 고통 

나는 세계에서 가장 큰 맥주 회사 중 하나를 위한 소프트웨어 프로젝트를 진행하고 있다. 이 프로젝트를 완료하는 데 2-3 년이 걸렸으며 일반적인 워터폴 방식으로 수행 되었기 때문에 소프트웨어 아키텍트, 개발자, 테스터 등 여러 단계를 담당하는 사람들이있었다. 나는 소규모 팀의 개발자였으며 ​​소프트웨어 아키텍트로부터 시스템 개발 수행 방법에 대한 지시와 가이드라인을 받았다. 처음에는 소프트웨어 아키텍트가 우리를 지원하기 위해 팀에 있었지만 나중에 그 프로젝트의 작업량이 줄어들면서 다른 프로젝트로 옮겼다. 제안 된 소프트웨어 아키텍처는 정의된 경계에 맞지 않는 새로운 종속성이 등장함에 따라 어느 시점에서 따르기가 어려워졌다. 수석 개발자가 아키텍처 비전을 인수하려고 했지만이 프로젝트는 소위 스파게티 코드로 성장했다.이 프로젝트는 다른 곳에서 문제를 일으킬 수 있으므로 모든 사람이 변경을 두려워 했다. 불행히도 프로젝트를 정상 괘도에 올릴 수 있는 과감한 변화를하기에는 너무 늦었었다. 우리는 프로젝트를 출시했지만 나중에 결국 종료되었다.

애자일 접근법

기존의 워터폴 구조는 시작 날짜와 종료 날짜가 명확한 일회성 활동이지만, 애자일 소프트웨어 아키텍처는 진행중인 프로세스이므로 결코 끝나지 않을 수 있다. 이를 통해 필요한 경우 아키텍처 변경 사항을 정기적으로 적용 할 수 있다. 프로젝트의 변화를 환영하는 메커니즘 중 하나는 반복적이고 점진적인 개발을 적용하는 것이다. 스크럼에서는 이러한 반복을 스프린트라고하며 하나의 스프린트는 일반적으로 그림 2에 표시된대로 2-4 주 사이에 지속된다. 이러한 작은 간격을 사용하면 발생하는 모든 변경 사항에 대해 바로 바로 논의 할 것이다. 또한, 팀 협업에 중점을 두고 있으며 오해와 의사 소통이 원활치 않은 것을 방지하며 팀원 간의 문제를 즉시 해결한다.

애자일 접근법을 통해 프로젝트의 변화를 환영할 수 있지만 얼마나 빠르게 대응해야하는지 알려주지는 않는다. 소프트웨어 아키텍처는 시스템의 백본이므로 변경에 따라 움직인다. 예를 들어, 프로젝트 중간에 사용하는 플랫폼이나 언어를 변경할 수 있다고 생각하는가? 드물기는하지만 이러한 변경에는 많은 추가적인 이터레이션을 필요로 한다. 심지어 프로젝트의 시작 부분으로 돌아갈 수도 있다. 소프트웨어 아키텍처와 관련하여 일부 유형의 변경은 고통스럽고 구현하는 데 시간이 걸린다.

애자일 소프트웨어 아키텍트

스크럼은 세 가지 유형의 역할을 정의한다.

• 제품 소유자(Product Owner) - 특정 비즈니스 도메인에 대한 정보를 제공한다.
• 스크럼 마스터 - 팀의 의사 소통 및 협업 촉진 한다.
• 개발팀 - 사용자 스토리을 구현하고 작동하는 소프트웨어를 제작한다.

전통적인 소프트웨어 아키텍트 역할을 애자일 개발에 맞는 역할로 변환하기 위해 가능한 변형을 살펴 봐야한다. 스크럼 팀을 구성하는 한 가지 방법은 개발자 팀과 별도의 소프트웨어 아키텍트 팀이 긴밀하게 협력하는 것이다. 그림 3은 이 시나리오를 여러 스크럼 팀에 적용한 것을 보여준다.

이것이 팀을 구성하는 올바른 방법이지만 두 가지 문제가 있다.

• 소프트웨어 아키텍트 팀은 수요자(Demander)가 될 수 있지만 개발자 팀은 일반적으로 워터폴 접근 방식의 경우 생산자(Producer)입니다. 소프트웨어 아키텍트는 비전을 정의하고 개발자는 비전을 구현해야한다. 이는 개발자를 관여시키지 않고 정중하게 다루지 않으면 개발자 간의 동기를 감소시킬 수 있다.
• 위의 결과로 일부 개발자는 다른 개발자가해야 할 일을 선택할 수 있도록 소프트웨어 설계자 팀의 일원이되기를 원할 수 있다. Trustpilot은 핵심 팀과 개발 팀을 보유한 사례를 제시했지만, 이는 작업장과 공동 작업에 대한 도덕을 감소 시켰기 때문에 핵심 팀의 각 구성원을 하나의 개발 팀으로 옮겼다. 이는 긍정적인 결과를 낳았다.

또 다른 방법은 소프트웨어 아키텍트를 그림 4와 같이 개발 팀에 직접 배치하는 것이다.

이 경우 애자일 소프트웨어 아키텍트는 약간 다른 책임을 갖는다.

• 큰 그림과 현재의 균형 – 민첩한 소프트웨어 아키텍트는 전체 시스템의 큰 그림에 맞춰 개발하는 동안 발생하는 상황을 고려해야 한다.
• 실무 경험 – 애자일 소프트웨어 아키텍트는 개발자이며 시스템 구현 작업을 한다. 이것은 선택된 구조적 결정(architectural decision)에 대한 직접적인 피드백을 제공한다.
• 결정 사항을 설명할 수 있도록 프로토 타입을 제작 - 중요한 기술적 결정을 내려야 할 경우, 빠른 프로토타입을 통해이 결정이 가능한지 여부와 기존 시스템에 어떤 영향을 미치는지 알 수 있다. 또한 전체 개발 팀과의 커뮤니케이션은 개인 개별 활동이 아닌 공동 노력해야 하는 것으로 필수적이다.
• 지속 가능성에 초점 – 구조적 결정(architectural decision)이 지속 가능한 소프트웨어 아키텍처를 이끌어내는 것이 매우 중요하다. 이는 장기적으로 프로젝트를 지원할 것이다. 이것의 필수 부분은 개인적인 책임과 공감이다. 애자일 소프트웨어 아키텍트는 개발 팀의 일원이므로 위에서 설명한 의사 결정을 통해 직접적인 피드백을 받는다. 이는 워터폴에서 접근하는 방식과 달리 개인의 책임 수준을 높이며, 결정은 개발 팀에 전달되어 구현된다.

다른 개발 팀 (및 프로젝트)간에 구조를 공유하려는 경우 별도의 소프트웨어 설계자 팀과 함께 구조를 선택할 수 있다. 또한 많은 관점을 고려해야하는 복잡한 도메인에서 작업하는 경우, 이 구조를 적용 할 수도 있다. 그러나 이 경우 소프트웨어 아키텍트가 개발자와 긴밀하게 협력하고 지원하도록 해야한다. 애자일 방법론은 협업에 중점을 두므로 소프트웨어 아키텍트를 개발자와 분리하면 협업이 어려워진다. 결과적으로 개발 프로세스는 워터폴 모델에 가까워진다. 나는 개인적으로 팀 구성원 간의 의사 소통이 향상되기 때문에 각 개발 팀에 한 명의 소프트웨어 설계자가 존재하는 두 번째 변형을 선호한다. 선임 아키텍트(High level architects)는 여전히 서로 협력 할 수 있다 (꼭 그렇게 해야 한다).

애자일 소프트웨어 아키텍처의 타임스팬

애자일 소프트웨어 아키텍처의 중요한 측면은 언제 시작하는가 이다. 우리가 잘 정의 된 단계를 가지고있는 워터폴 모델과는 달리, 애자일 세계에서는 사람들이 시작 단계라 정의 하는 특정 항목이 없다. 일반적인 접근 방식 중 하나는 스프린트 #0을 진행하는 것이다. 개발 환경을 구성하고 프로그래밍 언어, 플랫폼, 데이터베이스 등과 같은 몇 가지 기본 결정을 내리는 특수 스프린트이다.

그러나 이러한 접근 방식의 일반적인 함정은 사람들이 항상 “거의 준비되었다”고하면서 이 기간을 연장하는 경향이 있다는 것이다. "일주일 더 있으면 정규 스프린트를 시작할 수 있다"라는 말이 종종 들린다. 많은 경우에, "사전 도움말 기능을 미리 구현하는 것이 정말 멋지므로"라며서 유저 스토리없이 시스템에 이미 작업하고있는 것을 알 수 있다. 이러한 상황에서는 스프린트 #0의 종료 날짜에 미리 동의해야 한다. 이는 스프린트 지속 시간 또는 그와 유사한 기간이 될 수 있다.

정규 스프린트가 시작될 때 아키텍처가 준비되지 않은 경우 어떻게 될지 궁금 할 것이다. 글쎄, 그래도 괜찮다. 실제로 준비되지 않았을 수 있다. 그리고 그것 또한 괜찮다. 소프트웨어 아키텍처는 지속적으로 진행되는 프로세스이다. 이것은 시스템의 골격이므로 항상 되돌아와 수정해야한다. 당신의 아키텍처가 필요한 것을 충분히 지원하지 않는다면 시스템을 개발할 여유가 없다. 사이먼 브라운(Simon Brown)의 말을 인용해 보자 :

기민한 팀(Agile Team)이 반드시 기민한 소프트웨어 아키텍처(Agile Software Architecture)를 만들지는 않는다.
그러나 좋은 아키텍처는 기민성(Agility)을 가능하게한다.

관리 원칙

우리가 사는 세상은 복잡하며 모든 비즈니스 영역도 마찬가지이다. 소프트웨어 아키텍처를 구축 할 때는 처음부터 작업을 너무 복잡하게하면 결과적으로 오류가 발생하기 쉽다. 의사 결정시 두 가지 원칙이 사실상의 표준이되었다.

• 바보야, 단순하게 해 (Keep It Simple, Stupid. KISS)
• 넌 그것을 필요로하지 않을 거야 (Your Aren't Gonna Need It. YAGNI)

이 두 가지 원칙이 지키려고 하는 것이 바로 그 순간에 특정 기능이나 결정이 필요한지 생각하게 하는 것이다. 나중에 결정을 연기 할 수 있다면 아키텍처를 단순하게 유지하여 더 오랜 시간 동안 쉽게 관리 할 수 ​​있다. 소프트웨어 아키텍처가 복잡 해지는 일반적인 방법 중 하나는 추상화를 도입하는 것이다. 이 형식은 데이터를 한 형식으로 복사하여 다른 형식으로 변환하는 새로운 고급 레이어 일 수도 있고, 코드 100 % 테스트 가능하게 하기 위해 많은 클래스, 인터페이스, 팩토리 등을 생성하는 것일 수도 있다. .

그러나, 이 두 가지 원칙을 적용 할 때 한 가지 함정은 우리가 마지막 순간까지 모든 것을 지연시키는 경향이 있다는 것이다. 그때에는 필요한 변경을 구현하기가 이미 너무 어려워 졌을 수 있다. 대신 우리의 임무는 훨씬 더 어렵다. 왜냐하면:

우리는 마지막 순간이 아닌 가장 적정한 시간(Most Responsible Time)에 결정을 내려야 하기 때문이다 

구조적 결정을 내리려고 할 때, 결정의 확실성이 높은 경우, 일반적으로하는 일이 시간이 많이 걸리지 않는 작은 준비를하는 것이다. 나는 또한 동료들과 상의하고 함께 토론한다.

실제 상황의 고통

온라인 페리 티켓 판매에 관한 프로젝트를 진행하고 있었다. 다른 4 개의 타사 시스템과 통신해야했기 때문에 복잡한 시스템이었다. 처음에는 주로 사용자 스토리를 기반으로 기능을 구현하는 데 중점을 두었다. 우리는 정교한 캐싱 메커니즘이 필요하다는 것을 알고 있었지만 그 순간에 필요하지 않았기 때문에 이를 지연시켰다. 당시 사용자 스토리에 집중해야 했다. 그러나 나중에 다른 타사 시스템과의 광범위한 통신으로 인해 시스템 속도가 느려졌다. 우리는 다른 선택의 여지 없이 사용자 스토리에 대한 작업을 중단하고 캐싱 메커니즘에 초점을 맞추어야 했다. 그 때에는 이미 구현하기가 어려웠다.

문서를 작성하는 방법

워터폴 접근 방식은 단계 간에 정보를 전송하는 데 문서가 사용되므로 각 단계에 관련된 사람들이 광범위하게 문서를 작성해야한다. 이 작업은 시간이 많이 걸리는 프로세스 일뿐만 아니라 잘못 설명된 기능으로 인해 오해로 이어질 수 있다. 또한 개발 속도가 빨라지면, 문서가 더 이상 이를 반영하지 않기 때문에 문서를 최신 상태로 유지하기가 어렵다. 코드 작성하기 위해 반복(Iteration)을 하는 애자일 접근법을 사용하면, 문서 작성도 유사하게 수행할 수 있다. 우리는 시스템의 중요한 측면만을 설명하고 시작한 다음 필요할 때 지속적으로 더 많은 정보를 추가한다.

문서화 내용(What to Document)

동일한 형식을 여러 형식으로 여러 번 문서화하지 말자. 예를 들어 코드에서 다이어그램을 생성하는 데 도움이되는 도구가 있다. 이 도구는 사용되지 않는 경향이 있으므로 별도의 다이어그램을 만드는 대신 매우 편리 할 수 ​​있다. 또한 시스템의 특정 측면을 설명하기 위해 시각적 산출물을 작성한 경우 단어로 동일한 내용을 설명하는 광범위한 텍스트 문서를 작성할 필요가 없다 (세부 사항을 추가하지 않으면 시각적으로 표현할 수 없음). 여기서 중요한 점은 당신과 당신의  팀은 사용 된 도면 표기법에 대한 일반적인 이해가 필요하다는 것이다.

문서화하는 방법

소프트웨어 아키텍처를 문서화 할 때 UML이 최선의 방법이라고 생각할 수 있다. UML은 표준이며 모든 사람이 알고 있으며 대학에서 이를 가르치므로 조직의 모든 사람을 통합할 수있는 도구 중 하나다. 내 경험에 따르면 실제로 UML을 사용하는 사람은 거의 없다. 그 이유 중 하나는 다른 관점에서 시스템을 설명하는 많은 방법이 있기 때문에 정기적으로 사용하지 않으면 좌절 할 수 있습니다.

애자일 세계에서 소프트웨어 아키텍처를 문서화하기위한 특정 도구는 없다. 화이트 보드 그림, Post-It 메모, 텍스트 문서, 위키 등을 사용할 수 있다 (아래 그림 참조). 실제로 2-3 개의 다른 산출물 형식만 사용하는 것이 더 안전하다. 그렇지 않으면 해당 형식을 저장하고 정보를 검색하기가 어려워 질 수 있습니다. 예를 들어, 그림을 그린 후에 화이트 보드 사진을 찍어야 디지털 버전의 다이어그램을 만들 수 있다. 그러나 나중에 편집해야하는 경우 디지털 방식으로 편집 할 것인지 화이트 보드에 다시 그릴 것인지 새 사진을 찍을 것인지 선택해야한다.

결론

소프트웨어 아키텍처는 미래 시스템의 골격(Skeleton)을 정의한다. 이것은 선과 점이있는 다이어그램이 아니라 코드 자체를 포함하여 시스템 개발을 관리하는 완전한 결정 세트(Decision Set)이다. 모든 결정은 타협이므로 신중하게 고려해야 한다. 애자일 사고 방식은 요구 사항이 다소 안정적 일 것으로 예상되는 기존 워터폴 모델과 달리 프로젝트 후반에도 변화에 개방적이어야 한다. 그러나 시스템 골격의 변경이 항상 구현하기 쉽지는 않으며 개발 프로세스를 이전으로 되돌릴 수도 있다. 따라서, 마지막 순간까지 결정을 지연시키지 말고 그 시점에 필요하지 않은 것을 구현할 위험이 적더라도 가장 적정한 결정(Most Responsible Decision)을 내리는 것이 중요하다. 또한 애자일 소프트웨어 아키텍처는 모든 사람이 구축 할 수있는 지속 가능한 플랫폼을 만들기 위해 큰 그림과 "지금"을 복합적으로 혼합해야 한다.

번역의 결론

이 글을 읽으면서 가장 기억에 남은 문구는 가장 적정한 결정(Most Responsible Decision)이라 번역한 표현이다. 외국에 있을 때, 음주 관련 공익 광고 중에 "Drink Responsibly"라는 광고 카피가 기억에 남는다. 이는 자기가 감당할 정도로만 마셔서, 자신의 생활과 관계를 잘 유지할 수 있도록 하자는 뜻이라고 한다. 나는 이와 일맥 상통한다고 생각했다. 즉, 구조적 결정을 하는 시간과 범위를 가능한 미루는 것이 아니고 알맞고 발라야 한다는 것이다.

또한, 토론에 대한 언급도 좋았다. 나는 애자일 접근법이 소통으로 이루어 지는 부분이 매우 훌륭하다고 생각한다. 특히, 애자일 12원칙 중 "최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다."라는 구절을 매우 좋아 한다. 창발은 팀의 원할한 소통에서 나올 수 있다. 그러므로, 소통이 없는 팀에서는 좋은 아키텍쳐가 나오기 어렵다.

아쉬운 부분은 절차에 대한 이야기가 있지만, 어떻게 구조적 결정을 해야 하는지에 대한 기술적인 방법(Technical Method)에 대해서는 설명이 없다는 것이다. 이러한 부분은 아직 Design Pattern, Architectural Style, Aspect Driven Design(ADD) 혹은 AD를 활용해야 하는 것인지도 모르겠다. 이 부분은 숙제로 남겨두고 고민해도 좋겠다.

참고 문헌

[1] Boyan Mihaylov, "Towards an Agile Software Architecture," https://www.infoq.com/articles/towards-agile-software-architecture/?p13nId=6817&p13nType=followTopic#