Move Fast
앞서 소개한 하이퍼커넥트의 일곱 가지 핵심가치 proactive에 이어 move fast를 소개합니다. 하이퍼커넥트를 가장 강하게 대표하는 가치임과 동시에 move fast가 가장 오해를 많이 사는 가치이기도 하다고 생각합니다. 이에 제가 이해하고 있는 move fast에 대해 설명 드립니다. 적어도 저희 조직에서는 다음과 같은 방식으로 move fast를 해석하고 업무에 임하고 있습니다.
하이퍼커넥트의 7가지 일하는 방식 중 하이퍼커넥트를 가장 강하게 대표하는 것이 move fast라 생각합니다. 과거 제가 처음 디렉터가 되었을 때에도 여러 디렉터들께 여쭈어 보았을 때에 모든 디렉터들이 입을 모아 이야기했던 하이퍼커넥트의 가장 중요한 가치는 move fast였습니다. 저는 move fast가 우리의 가장 중요한 가치 중 하나라고 생각합니다.
하지만 하이퍼커넥트를 가장 강하게 대표하는 가치임과 동시에 move fast가 가장 오해를 많이 사는 가치이기도 하다고 생각합니다. 문자 그대로 해석하면 빠르게 일하라는 것이며 너무나도 당연한 이야기이기 때문입니다. 특히 하이퍼커넥트의 다른 가치인 aim high와 서로 모순적이지 않느냐는 질문도 종종 받았습니다. 이에 제가 이해하고 있는 move fast에 대해 설명 드립니다. 적어도 저희 조직에서는 다음과 같은 방식으로 move fast를 해석하고 업무에 임하고 있습니다.
제가 생각하는 move fast는 "짧은 레이턴시latency를 높은 쓰루풋throughput보다 선호한다" 입니다. 레이턴시는 지연속도/지연시간을 의미하죠. 어떤 액션을 하고 결과를 다시 받아보기까지 걸리는 시간이라고 해석하면 됩니다. 쓰루풋은 처리량을 의미하는데, 단위 시간 당 얼마나 많은 결과를 만들어 냈느냐를 의미합니다. 짧은 지연과 많은 결과는 둘 다 중요한 가치입니다. 가능하면 두 마리 토끼를 다 잡는 것이 좋겠죠. 그러나 둘 중 하나를 선택해야 하는 상황이 만약 생긴다면, 더 짧은 레이턴시를 먼저 선택하라고 이야기하는 것이 move fast입니다. 물론 밸런스가 중요합니다. 극단적인 레이턴시의 선택으로 쓰루풋이 터무니 없이 낮아진다면 이는 올바른 선택이 아닐 것입니다. 다만 쓰루풋을 높일 방법을 고민하기에 앞서 먼저 레이턴시를 줄일 방법을 먼저 고려하자는 것이 move fast라 생각하면 좋을 것 같습니다.
우리가 이렇게 레이턴시를 줄이고자 하는데에는 이유가 있습니다.
기본적으로 우리 하는 모든 행위는 회사가 사용자에게 더 많은 가치를 전달하고 이로인해 돈을 더 많이 벌기 위함입니다. 이 과정 전체는 생각보다 느리고 그렇기 때문에 불확실성이 높은 상황에서 미래를 예측하며 여러 행동을 해야 합니다. 문제는 특히 이러한 불확실한 상황에서 미래 예측을 하는 것은 대단히 어렵다는 것입니다. 그렇기 때문에 불확실성을 다루기 위한 다양한 수단을 활용합니다. 그 중 한 가지가 행동으로부터 결과까지의 레이턴시를 줄이는 것입니다. 이러한 원칙 하에 많은 조직이 기능 조직보다 목적 조직을 선택하게 되는 것입니다. 기능 조직이 레버리지의 측면에서 목적 조직보다 많은 면에서 우월하지만 레이턴시의 측면에서 불리하며, 그 한가지 불리함이 너무나도 중요한 역할을 하기 때문에 목적 조직을 선택하는 것이죠. 그렇기 때문에 언제나 쓰루풋을 높이는 것보다 레이턴시를 줄이는 것을 먼저 고민하시길 권합니다. 불확실성을 줄이기까지의 레이턴시, 가치를 창출하고 이를 전달하기까지의 레이턴시, 학습의 레이턴시, 피드백을 받는 레이턴시, 이러한 모든 종류의 유의미한 레이턴시를 줄이는 것을 고민해야 합니다.
몇 가지 예시를 들어볼까요? XKCD의 아주 유명한 컴파일러 코믹이 있습니다. 당연하게도 이런 상황에서 칼싸움하며 시간을 보내는 것은 이상적이지 않습니다. 보통 다들 먼저 생각하시는 것이 그 시간에 다른 중요한 업무를 하면서 시간을 보내는 것입니다. 그것도 물론 의미있지만 저는 더 좋은 방법은 컴파일 시간을 줄일 수 있는 더 나은 도구를 사용하거나 컴파일링을 아예 안 해도 되는 도구를 사용할 수는 없는지 고민해보고 선택하는 것이라 생각합니다.
특히 ML 모델의 관점에서 생각해보면 모델 학습에 긴 시간이 걸리니 그 사이에 다른 것을 하자는 것도 좋은 접근이지만 더 move fast할 수 있는 접근은 학습을 통해서 우리가 확인하고자 하는 것을 더 빠르게 볼 수 있는 방법을 선택하는 것입니다. 더 적은 데이터로 최대한 feasibility를 본다든지, 공격적인 분산 학습을 통해 모델 학습 완료까지의 시간을 줄이는 선택 등을 언제든 권장합니다.
타 부서와 협업을 할 때에 자주 있는 일로, 어떤 요청 처리에 일주일이 걸린다는 답변을 들을 수 있습니다. 물론 다들 바쁘고 해야 할 일이 많기 때문에 그럴 수 있습니다. 이 때에 그 시간 동안 다른 업무를 수행하겠다고 생각하는 것도 좋지만, 더 빠르게 할 수 있는 방법은 없을지, 도와드릴 수 있는 것은 없는지, 정말 방법이 없는지 여쭤보는 것이 보다 능동적인 접근이며 이로인해 업무가 더 빨라지는 경우가 깜짝 놀랄 정도로 자주 있는 접근 방법입니다.
코드의 리팩토링에 대해서도 비슷한 시각을 적용할 수 있습니다. 우리가 리팩토링을 하는 이유는 기술 부채를 갚기 위함입니다. 기술 부채를 갚는다는 것은 미래에 있을 변화에 사용될 비용을 줄이기 위해 지금 비용을 들여서 기술 부채를 갚아버리는 것을 의미합니다. 이런 접근의 어려움은 우리가 미래 예측을 잘 못한다는데에 있습니다. 지금 갚아버린 비용이 미래에 ROI가 나오는 선택이 아닐 수도 있다는 것이지요. 그렇기 때문에 저는 한 번에 큰 규모로 리팩토링을 수행하는 것보다 기능을 구현하면서 필요한 작은 수정을 그때그때 하는 것을 훨씬 선호합니다. 캐싱의 원리를 생각해보면 최근에 바뀐 코드와 자주 바뀐 코드가 다음 번에도 다시 바뀔 가능성이 높으리라 생각할 수 있습니다. 그러므로 이번에 수정하는 부분의 작은 부채를 그리 크지 않은 비용을 들여서 갚아버리는 것은 현명한 부채 청산이라고 볼 수 있는 것이죠. 이 또한 투자의 가치를 보기까지의 레이턴시를 줄이는 선택이라 할 수 있겠습니다.
어떤 종류의 업무는 아주 복잡해서 대단히 다양한 각도로 고려하고 깊은 생각이 필요한 경우가 있습니다. 이런 경우에도 한 번에 생각을 다 끝내서 완벽하게 정리된 내용을 공유하려고 하기 보다는 데드라인을 정해놓고 그 기간 안에 할 수 있는 정리를 최대한 한 뒤에 한 번 공유하고 이후 팔로우업 아이템을 추적하는 것이 좋은 방법이라고 생각합니다. 애초에 얼라인이 잘 안되어 있는 상황이었다면 잘못된 문제에 대한 고민을 하고 있었을 수도 있고, 얼라인이 잘 되어 있는 상황이었다 하더라도 완벽하게 생각을 마치는 사이에 환경이 변해서 문제가 변해버렸을 수도 있습니다. 피드백의 레이턴시를 줄이면 이러한 문제를 빠르게 대응할 수 있습니다.
큰 프로젝트를 수행할 때에 끝 그림을 생각해보는 것은 반드시 필요합니다. 이런 경우에도 여러 접근이 있을 수 있겠죠. 가령 일 두 번 하지 않을 수 있도록 한 번에 완성도가 높은 것을 만들겠다는 방식으로 진행할 수도 있고, 두 번 작업 하더라도 빠르게 이터레이션을 돌면서 불확실성을 줄이는 접근을 택할 수도 있습니다. 제가 생각하는 move fast란, 두 가지 선택지 중 후자를 선택하는 것을 의미합니다. 물론 항상 그렇게 하는 것이 옳지는 않을 수 있습니다. 개발자들은 APIs are forever라는 이야기를 합니다. 즉, 어떤 결정은 무르기가 어렵기 때문에 깊게 고민해서 결정해야 한다는 것이죠. 보통 불특정 다수에게 제공하는 플랫폼 선택이 이러한 특징을 갖는 경우들이 있습니다. 이런 것은 깊게 고민하기는 해야 합니다. 그러나 저는 이러한 문제들 조차도 사람들이 생각하는 것보다 이터레이션을 통한 접근이 더 우월한 경우가 많다고 생각합니다. 구글의 Jeff Dean도 구글 내부 크롤러를 세 번은 넘게 만들었던 걸로 알고 있습니다. 한 번 만들고 완성하자마자 문제가 생겨서 다시 만들고 또 다시 만드는 경험을 몇 번 한 뒤에야 이 문제를 제대로 풀어냈다는거죠. 단순히 생각만 깊게 해서 인프라를 만든다는 아이디어는 신화에 가깝다고 생각합니다.
Move fast 정신은 빠르게 움직여서 빠르게 불확실성을 줄이고 빠르게 피드백을 받고 빠르게 성장하는 것을 의미합니다. 서두에 이야기했다시피 move fast는 하이퍼커넥트의 가장 핵심적인 가치라 생각합니다. 저희 AI 팀에게 이 원칙은 단순한 슬로건이 아니라, 급변하는 기술 환경 속에서 꾸준히 사용자의 문제를 해결하고 임팩트를 만들어내는 핵심적인 운영 체제입니다. 이와 관련된 글귀 몇 개를 공유드립니다.
What are some of the advantages of organizing much of a company in a mission-oriented form? There is only one. It is that the individual units can stay in touch with the needs of their business or product areas and initiate changes rapidly when those needs change. That is it. All other considerations favor the functional-type of organization. But the business of any business is to respond to the demands and needs of its environment, and the need to be responsive is so important that it always leads to much of any organization being grouped in mission-oriented units.
Andy Grove
When someone says "Let's have a follow up conversation", what is the implicit unspoken understanding of when that should happen? What will be considered early, appropriate and late in a way that violates cultural norms? In companies I've been at, that has ranged from a few hours to the next day to the next week to …perhaps never. This little test usually tells me a lot about how fast your organization/company works.
Sriram Krishnan
All systems are created incrementally, one character typed at a time. The choice is length and scope of feedback loops.
Big changes are an illusion. All changes are small. There are only longer and shorter feedback cycles.
When you try to make fewer mistakes by making fewer mistakes you slow feedback, learn less, and make more mistakes. When you speed feedback you learn more and make fewer mistakes.
Kent Beck