Kaden Sungbin Cho님의 아티클

최상위 일잘러의 5가지 행동방식

평범한 직원과 파급력 있는 직원의 차이는 무엇일까요?
 
전세계 리더를 교육하고 양성하는 와이즈먼그룹의 대표 리즈 와이즈먼은,
이 질문에 대한 대답을 찾기 위해 10여개국의 170명의 대표들과 350명의 매니저를 조사하였습니다.
 
조사에서 맡은 범위의 업무에서만 개인적으로 기여하는 '평범한 기여자'와 맡은 범위를 넘어 기여하고 팀에도 긍정적인 분위기를 가져오는 '임팩트 플레이어'가 존재한다는 사실을 발견했습니다. 
 
그리고 이 '임팩트 플레이어'를 특별하게 하는 마인드셋과 행동방식을 아래 5가지로 정리했습니다.
 

필요한 일을 한다

임팩트 플레이어는 난처한 문제에 대처할 때 조직의 필요를 메꿉니다. 그들은 할당된 역할이나 직무를 넘어, 해야하는 진정한 일(올바른 일)을 처리합니다. 임팩트 플레이어의 목표는 섬기는 것입니다. 그들의 신조는 리더와 조직에 공감하고, 충족되지 않은 필요를 찾고, 자신이 가장 유용한 곳에 쓰일 수 있도록 상황을 만들어 갑니다. 그들이 행하는 이러한 일들은 조직의 대응 능력이 강화되도록, 기민해지고 목표를 섬기도록 영향을 미칩니다. 

반면 평범한 직장인들은 의무에 기반한 마인드로 일합니다. 자신의 역할과 포지션에 협소한 시각을 취합니다. 

다른 사람들은 자신에게 주어진 일을 할 때 임팩트 플레이어는 반드시 해야하는 우선순위 높은 일을 합니다.

적극적으로 나서고 적절하게 물러선다

반드시 해야하지만 담당이 명확하지 않은 일이 있을 때 임팩트 플레이어는 앞으로 나서서 선도합니다. 그들은 요청받을 때까지 기다리지 않습니다. 공식적인 담당이 아니더라도 먼저 착수하고 다른 사람들을 끌어들입니다. 그들을 명령이 아니라 필요에 따라 선도합니다. 그들은 암묵적인 컨택스트나 상황에서 단서를 얻어 필요를 포착하고, 앞으로 나섭니다. 그러다가 자신의 의무를 다하면 뒤로 물러서서 마찬가지로 수월하게 다른 사람들을 따릅니다. 

반면 평범한 직장인들은 역할이 불분명하면 방관자로 행동합니다. 그들에게 담당은 다른 사람이며, 그 담당이 자신이 필요한 시기와 해야 할 일을 말해(명령해)줄 것이라고 가정합니다. 

다른 사람들은 지시를 기다릴 때 임팩트 플레이어는 적절하게 앞으로 나서서 선도하고, 적절하게 뒤로 물러나 따릅니다.

확실하게 마무리한다

임팩트 플레이어는 완료에 집착하는 경향이 있습니다. 그들은 끈기를 발휘해 전체 일을 마무리합니다. 그들의 이러한 경향의 기반에는 주인의식이 있습니다. 미룰 곳은 없고 내가 이 일의 소유자이며 책임자라는 의식은 시간이 흐르며 동료들의 복잡도를 줄여주며 믿고 맡길 수 있는 사람이라는 평판을 얻게 합니다. 그렇다고 그들이 무턱대고 일을 진행하는 것은 아닙니다. 그들은 다르게 일하고 더 낫게 일하는 방식을 찾습니다. 또한 차질이 생겨도 결과를 내면서 책임성의 문화를 강화하고, 뒤처져도 따라잡을 수 있는 승부사로서의 명성을 만들어 갑니다. 

반면 평범한 직장인들은 회피하려는 마인드셋으로 일합니다. 그들은 책임감 있게 행동하지만 상황이 어려워지면 주인 의식을 갖기보다 문제를 위로 넘깁니다. 최악의 경우에는 한눈을 팔거나 낙담해 완전히 멈춰버립니다. 

다른 사람들은 문제를 넘기지만, 임팩트 플레이어는 마지막까지 마무리하며 그러한 경험을 통해 능력을 강화합니다.

질문하고 조정한다 

임팩트 플레이어는 변하는 환경에 동료들보다 빠르게 적응합니다. 새로운 규칙과 목표를 학습과 성장의 기회로 바라보기 때문입니다. 물론 그들도 인정과 긍적적인 피드백을 좋아합니다. 하지만 동시에 잘못을 바로잡는 피드백과 상반된 시각을 적극적으로 구하며, 이 정보를 활용해 노력의 방향을 재조정하고 초점을 재설정합니다. 그 과정에서 그들은 학습과 혁신의 문화를 강화하고, 조직이 뒤처지지 않도록 지원하며, 조언을 해주며 자신의 플레이 뿐만 아니라 팀 전체의 기준을 높이는 플레이어라는 평판을 얻습니다.

반면 평범한 직장인들은 변화를 짜증스럽거나, 불공정하거나, 업무 환경의 안정성을 위협하는 것으로 바라봅니다. 그들은 변화가 심한 상황에서도 자신이 잘 하는 것을 고수하고, 현재의 전문성을 유효하게 해주는 규칙에 따라 계속 플레이하려는 경향을 보입니다. 

다른 사람들은 변화를 관리하고 최소화하려 하는 반면 임팩트 플레이어는 변화를 학습하고 거기에 적응해 새로운 기회를 모색합니다.

일을 가볍게 만든다

팀이 심해지는 압박과 요구에 짓눌려 있을 때 임팩트 플레이어는 힘든 일을 더 쉽게 만듭니다. 그들은 다른 사람의 일을 대신 해주는 것이 아니라 같이 일하기 쉬운 사람이 됨으로써 부담을 덜어줍니다. 그들은 밝고 차분한 분위기를 조성해 드라마, 정치, 스트레스를 줄이고 일하는 재미를 늘립니다. 또한 모두에게 긍정적이고 생상적인 업무 환경을 창출함으로써 협력과 포용의 문화를 강화하고, 모두가 같이 일하고 싶어하는 고성과, 저관리(별다른 케어를 하지 않아도 알아서 잘하는) 플레이어라는 인정을 받습니다. 

반면 평범한 직장인들은 압박이 가해지고 업무 부하가 절정에 이르면 도움을 주기보다 받으려는 경향이 있습니다. 이것이 기본적인 습관 및 대응 방식이 되어서, 그들은 힘든 시기에 이미 버거워하는 팀에 부담을 더하고 리더와 동료들에게 짐이 되곤 합니다. 

다른 사람들은 짐을 더하는 반면 임팩트 플레이어는 과중한 요구를 가볍게 느끼도록 만듭니다.

개발자여, IT 역사를 공부하라

비전공자로 주니어 시절부터 지금까지 Python, Java, Spring, Hadoop 등등 기술적인 부분들만을 살펴봤었다.

기술 외의 부분이라면 테크매니징, 개발자 커리어, 프로그래밍 철학 등과 관련된 내용들만이 내가 좋은 개발자가 되는 길이라고 인지하고 있었던 것 같다. 

하지만, 최근들어서 내가 가지고 있는 IT에 대한 관점이 풍부하지 못하다는 생각이 들었다. 

주변 상황을 보자면, 비전공자로 늦었다는 생각에 최대한 기술 위주의 것들에 많은 할애를 했었다. 또 재택기간으로 일만 집중하다보니 스몰토크를 통해 내가 있는 필드의 다양한 경험들을 나누고 공유할 시간도 없었던 것 같다.

개발이 너무 기계적이고 피폐하다고 느껴질때 즈음, 내가 몸담고 있는 산업의 역사와 살아 숨쉬는 기업들의 히스토리, 그리고 그 흐름에서의 인물들을 살펴보고 싶다고 느꼈다.

그래서 관련 책들을 찾아보기 시작했다.

• 거의 모든 IT의 역사, 정지훈: 애플, 마이크로소프트, IBM, 구글, 페이스북 등의 기업들과 각 기업을 만들어낸 인물(스티브 잡스, 빌게이츠, 에릭 슈미트, 래리 페이지, 세르게이 브린, 마크 주커버그 등)들 중심으로 전개된다. 현재의 IT 지형이 어떻게 어떤 흐름으로 이어져 왔는지 느낄 수 있었다. 중간에 동아시아 IT 역사도 다뤄주는데, 한국 내용도 일부 있어서 흥미로웠다.

• 칩 워, 크리스 밀러: 반도체 전쟁이라는 관점에서 반도체의 탄생과 현재의 삼성, 엔비디아, TSMC, ARM로 이어지는 흐름이 너무 재밌었다. 

• A People's History of Silicon Valley, Spencer, Keith A: IT에 대한 비판적인 시각이 주를 이루는데, 밝게만 보았던 이 산업을 이렇게 바라보는 외부의 관점도 있구나라는 생각이 들었다. 적절한 비판은 받아들여 너무 긍정적인 관점으로만 IT를 바라보지 않고 객관적으로 봐야겠구나라는 느낌이 들었다.

• 플랫폼 망상, Jonathan Knee: 역시 IT에 주류를 이루는 관점과 달리 경영학 관점의 경쟁우위 중심으로 기업을 보아야 한다는 관점이 흥미로웠다. 그 관점을 기반으로 FAANG과 기타 IT 기업들을 분석하는데, 지금의 FAANG이 그 왕좌를 어떻게 차지할 수 있었는지라는 부분을 잘 그려주고 있어 재밌었다. 

• 한국의 페이팔 마피아: [1, 2]

여러 자료들을 읽고 나니,

1) 어떻게 현재 시점의 IT 지형이 만들어져왔는지 알 수 있었다. 기계적으로 더 좋게, 더 빠르게 기술적인 관점으로만이 아니라 역사의 흐름에서 임팩트가 있는 한 조각을 만들기 위해서는 무엇이 필요할까라는 풍부한 관점이 생겼다.

2) 미국도 그렇지만, 현재 한국 IT 지형의 주요 인물들은 꽤나 관계가 엮여 있다는 느낌이 들었다. 그렇기에 더더욱 같이 일하는 주변 사람이 정말 중요하다는 생각이 들었다. 

Reference

[1] https://brunch.co.kr/@sungjoonkim/24

[2] https://www.romanceip.xyz/k-paypal-mafia/

어떻게 성장하고, 성장시킬 것인가?

내면에 깊게 자리잡은 '성장 마인드셋'은 메타인지, 인내심과 회복력, 성취, 관계의 긍정적인 영향을 가져옵니다 [1].

물론 '성장 마인드셋'은 성장의 근본에 존재합니다. 하지만 '성장 마인드셋'을 품고 시간이 조금 흐르게 되면 자연스레 다음과 같은 의문이 생겨나기 시작합니다.

"노력과 경험을 통해 내가 성장할 수 있다는 사실은 이해했는데, 어떻게 더 잘 성장하고 성장시킬 수 있을까?"

애덤 그랜트 교수의 책 'Hidden Potential' [2]은 그에 대한 해답을 최신 연구결과에 기반해 말해주고 있습니다.

아래에서는 위의 책에 기반해서 성장을 위한 '성향 기르기', '지속하기', '시스템 만들기' 3가지를 알아보겠습니다.

성장을 위한 성향 기르기

개인이 이룬 성공을 예측하는 연구결과에서 유의미한 지표는 '얼마나 오랜 경험을 가진 유치원 선생님이 가르쳤는가?'라는 점을 발견했습니다 (Chetty). 왜 그런가를 살펴보기 위한 후속 연구에서 '오랜 경험을 가진 유치원 선생님은 인지적 능력이 아닌 Proactive, Prosocial, Disciplined, Determined라는 성향적 특성을 더 성공적으로 가르쳤다'라는 부분이 밝혀졌습니다. 그렇기에 개인의 성취나 성공은 IQ, 수학, 영어와 같은 인지적 능력이 아닌 성향적 특성에 더 큰 영향을 받는다라는 것을 알 수 있습니다. 이는 직장인(성인)을 대상으로 한 직업 훈련(인지적 훈련 vs 성향적 훈련) 연구에서도 동일한 패턴을 보여주었습니다.

위에서 언급한 '성장 마인드셋'이 이러한 성향을 만드는 멘탈모델이라고도 할 수 있겠습니다. 하지만 구체적으로 어떤 성향이 우리의 성장을 돕는 것일까요?

불편함에 익숙해지기

6개국어, 7개국어를 구사하는 polyglot들은 어떻게 언어를 배울까요? 그들은 day1부터 '실제로' 언어를 사용해야하는 상황을 만들어 매일 200번의 실수와 교정을 겪으며 짧은 기간안에 자연스럽게 대화를 나눌 수 있게 됩니다. 

'나에게 맞는 학습방법이 있다'라는 생각은 많은 연구결과 효과가 없음이 증명되었습니다. 

의도적으로 자신을 목적하는 discomfort zone에 위치키심으로써, 우리는 해당 영역에서 comfort해질 수 있습니다.

배움에 스폰지가 되기

지구에서 가장 오래된 동물로 여겨지는 해양 스폰지는 단순히 주변의 모든 것을 흡수(absorb)하는 것에만 그치지 않습니다. 해양 스폰지는 상황에 맞게 흡수한 것들을 적극적으로 필터링하며 상황에 적응합니다. 이러한 absorb, filter, adapt 과정을 통해 해양 스폰지는 2000년까지도 생존합니다. 

성장하려는 개인도 흡수하고, 필터링하고, 적응해야 합니다.

종교개혁의 중심지에 가까운 지역일수록 높은 소득을 보였던 역사에서 알 수 있듯이,

새로운 정보를 흡수하고, 필터링하고, 적응할 때에 차원이 다른 번영을 이룰 수 있습니다.

개인적인 상황에서 이러한 능력은 적극성이라기보다는 prosocial한 능력에 기반합니다. 의견 또는 비판을 객관적으로 수용하는 부분에, 그 시작점이 존재합니다. 

불완전함을 받아들이기

100% 완벽함을 원한다면 100% 완벽할 수 있는 시도만 하면 됩니다. 그렇기에 '완벽주의자'는 필연적으로 '도전'을 두려워할 수 밖에 없게 됩니다. 이는 '고정 마인드셋'을 가진 사람이 실패는 자신의 재능을 나타내는 것이기에 도전을 주저하게 되는 것과 같습니다 [1].

그렇기에 우리는 어느 정도 만족스러운 결과와 완벽한 결과 사이의 어느 지점을 목표해야 합니다. 

그말은 결과의 불완전함을 받아들이는 것을 의미합니다. 결과에 어느 정도 만족할 수 있어야, 다음의 시도에 대한 감정도 긍정적이게 됩니다.

Reference

[1] https://kadensungbincho.tistory.com/18

[2] Hidden Potential, Adam Grant

백엔드 개발자를 위한 모바일 앱의 특징

모바일 앱이 가진 고유한 특징은 뒷단의 백엔드 개발에도 영향을 미칩니다. 이러한 특징들은 웹 기반 서비스에 익숙한 백엔드 개발자들이 쉽게 놓칠 수 있는데요. 

많은 앱들이 웹뷰 형태로 네이티브와 웹을 결합한 형태로 구성되어 있으나, 그렇기에 더욱 네이티브 앱의 특징을 명확하게 인지하지 못하는 경우도 발생합니다.

이번 글에서는 Building Mobile Apps at Scale [1]의 내용을 중심으로, 백엔드 개발과 관련 깊은 네이티브 모바일 앱의 특징들을 알아보겠습니다.

모바일 앱은 바이너리가 스토어(구글플레이 또는 앱스토어)를 통해 업로드 되고, 유저가 모바일 기기에 다운로드 받아 설치되며 배포됩니다. 이러한 모바일 앱의 환경이 모바일 앱 개발과 네이티브 앱이 사용하는 백엔드 API 개발에 영향을 미칩니다.

'설치형'이다

상태관리

모바일 앱 또한 웹 또는 백엔드와 같이 여러 복잡한 문제들이 상태관리에서 발생합니다. 대부분 이벤트 기반으로 변경되는 앱의 상태관리는 웹과 유사하게 Reactive Programming 형태로 발전해왔습니다. 하지만 웹 또는 백엔드와 달리, 앱은 아래와 같은 이슈들을 마주하게 됩니다:

• 작고 제한된 성능의 모바일에서 만약 앱이 과도한 리소스를 사용한다면, OS는 매우 짧은 노티만 주고 앱을 kill하게 됩니다. 이러한 앱 상태 변화에 반응하여 앱은 상태를 저장하고, 재시작 시 상태를 복원할 수 있어야 합니다.

• 권한, 연결 상태, 블루투스 상태 등 다양한 글로벌 앱 상태가 존재하고, 앱의 컴포넌트들은 watch하고 있는 상태에 따라 다르게 반응하여야 합니다. 글로벌 앱 상태를 처리하는 핸들러의 구현 방식에 따라 부하를 주거나, 코드의 복잡도가 올라가거나, tight-coupling이 생기는 등의 trade-off가 발생할 수 있습니다.

• 앱의 기존 상태와 Deeplink와 같은 앱의 특정 화면에 대한 직접적인 접근이 맞물리면서, 상태관리의 leak이나 예상치 못한 상태 등이  발생할 수 있습니다.

바이너리는 모바일 기기에 존재하고 실행된다

애플과 구글은 앱에 송신되는 실행가능한 코드를 허용하는 부분에 대해서 매우 엄격한 기준을 가지고 있습니다 (일부 버그 픽스 같은 경우  CodePush [3]와 같이 허용된 우회적 방법이 가능하나). 또한, 앱을 스토어에 배포하기 위해서는 24 - 48 시간 정도가 소요됩니다. 그리고 그렇게 스토어에 배포되었더라도 사용자는 최신 버젼으로 업데이트하기까지 오랜 시간이 걸리고, 항상 유저가 최신 버전의 앱을 사용한다는 보장도 할 수 없습니다 (강제 업데이트를 하더라도). 

즉, 한 번 배포된 앱을 수정하여 사용자의 기기에서 업데이트되기까지가 오래걸리고, 어렵고, 불가능할 수도 있습니다. 그렇기에 애초에 꼼꼼히 테스트하여 실수 없이 배포하고, Feature Flag Strategy [2]를 통해 특정 기능을 켜거나 끌 수 있도록 하거나, 최대한 강제 업데이트를 완전하게 지원하는 등의 대책이 필요합니다. 이는 작성한 코드 뿐만 아니라, 그러한 코드가 의존하고 있는 3rd party SDK나 라이브러리도 포함됩니다.

하지만 "모든 최신 버젼 배포 시 최대한 완전한 강제 업데이트를 하고 이전 버젼을 지원하지 않는다"가 정책이 아니라면, 하위버젼이 사용하는 백엔드 API도 하위호환을 지원해야 합니다.

그렇기에 백엔드도 최대한 초기에 기존 버젼 하위호환에 대한 지원과 그것을 위한 API 디자인, 모니터링 및 폐기 전략 등이 고려되어야 합니다. 최소한 관련해 어떠한 정보도 얻을 수 없기에, 어떠한 액션도 취할 수 없는 상황은 피할 수 있도록 해야 합니다.

바이너리 사이즈가 영향을 준다

앱 사이즈는 앱 설치 conversion rate에 영향을 줍니다 [4]. 특히, 이머징 마켓(인도, 브라질 등)에서 그러한 특징이 두드러지는데요. 그렇기에 여러 글로벌 앱들은 기능을 축소하고 사이즈를 줄인, lite 버젼을 제공하고 있습니다.

다양한 모바일 기기와 구글과 애플에 영향을 받는 OS 환경에서 실행된다

다양한 환경의 지원과 모니터링

앱이 실행되는 모바일 기기는 종류가 다양합니다. 모바일 기기는 다양한 지역, 장소, 조건에서 사용됩니다 (예, 외곽 이동중). 또한, 그러한 모바일 기기에서 실행되는 OS는 빠르게 진화하고 있습니다. 모바일 기기가 다양한 용도에 쓰이는 만큼 여러 종류의 칩이 들어가고, 여러 기능(블루투스, 카메라, 통화 등등)과 관련된 인터랙션이 존재합니다. 

모든 조건을 다 지원할 수 없기에, 앱은 지원할 수 있는 타겟을 명확히 범주화하고, 그러한 범주에서 오래된 기기나 OS 버젼에서 앱이 정상적으로 작동하는지 테스트해야 합니다. 그리고 피할 수 없이 발생하는 버그나 오류를 모니터링하고 디버그 [5]할 수 있도록 모바일 기기 상에서 발생하는 충분한 정보가 개발자에게 전달 될 수 있도록 해야 합니다. 

Image from [5]

다양한 네트워크 조건에서 사용되는 모바일 앱이기에, offline support도 고려되어야 합니다. 일시적인 네트워크 연결 끊김으로 인한 부부은 retry를 고려하거나, 그러한 상황에서의 상태 처리도 생각해볼 수 있습니다.

Deeplink

앱의 특정 부분에 직접 접근하도록 하는 딥링크는 이해는 쉬우나, 여러가지 조건과 맞물리면 매우 복잡하고 까다로울 수 있습니다 [6]. 그러한 조건들로는 아래와 같은 사항들이 존재합니다:

• 하위호환: 위에서 살펴본 하위호환은 딥링크에서도 해당됩니다. 예로, 마케팅으로 배포되었던 딥링크는 새로운 버젼 출시 이후에도 동작해야 합니다.

• 다양한 진입점: 딥링크를 통해 사파이 브라우저, 다른 앱(Notes, 문자 등), 해당 앱 내, Push notification 등 다양한 진입점에서 접근 가능합니다. 또한, 이는 아래에서 언급될 상태와 함께 고려되어야 합니다.

• 상태: 실행되는 앱의 상태와 딥링크로 인한 진입이 정상적으로 상호작용하는지 고려되어야 합니다. 기존 상태가 초기화되어야 할지, 보존되어야 할지 그로 인해 예상치 못한 상태로 앱이 crash가 발생하지는 않는지 생각해보아야 합니다.

• iOS와 Android의 구현의 차이

iOS와 Android이 제공하는 것들

이 점에서는 크게 2가지, Push & Background notification과 In-App Purchase가 존재합니다.

Push & Background notification

iOS와 Android 모두 각각 APNS와 FCM을 통해 Push notification을 지원합니다. Push notification을 보내는 부분은 백엔드에서 진행되기에, 어떻게 보낼지, 보낸 notification을 클릭 시 어떤 형태로 동작할지 등과 관련해 백엔드와 많은 커뮤니케이션이 필요하게 됩니다. 보통 통합된 도구를 사용해 비교적 간단히 설정할 수 있으나, 아래와 같은 이슈가 발생할 수 있습니다:

• 딥링크와 유사하게 메시지의 액션이 어떤 형태로 동작하여 앱에 접근하게 될지, 하위호환은 어떻게 처리할지 등에 대한 고려가 필요합니다.

• 유저가 notification을 끄고 킬 수 있습니다 (background notification과 같은 예외를 제외하면).

• Push nofitication의 전달이 보장되지 않습니다. 중간 전달자인 애플과 구글이 throttling하는 경우도 있으며, 기기의 연결 이슈가 존재할 수도 있습니다. 그리고 애플과 구글은 관련한 구조나 전달과 관련된 정보를 제공하지 않고 blackbox 형태로 제공하고 있습니다.

• 테스팅이 어렵습니다. 

하지만 위와 같은 이슈에도 Push notification은 여전히 유저 진입 통로, 마케팅, 정보제공 등의 목적에 유용하며 Background notification [7, 8]과 같은 기능은 백엔드의 변경사항을 앱에 전달하기 위한 목적으로도 사용될 수 있습니다.

In-App Purchase

앱 상에서 디지털 상품을 판매하는 경우 IAP를 통하지 않고 우회하여 판매하기는 여러모로(우회를 찾거나 또는 그 여파를 감당하기가) 쉽지 않습니다. 

어쩔 수 없이 IAP를 진행하더라도 고비용의 수수료와 iOS & Android의 각기 다른 정책과 제약(가격 변경, 매출 파악, 회계처리 등의 어려움 등), IAP 유저와 백엔드 회원계와의 매핑 등의 구조적 한계를 감수해야 합니다. 

구현 이후에 테스트와 운영 시에도 위와 같은 복잡한 구조로 인해 어렵습니다. 특히 금액과 관련된 예민한 사항이기에, CS와 관련한 준비가 필수적입니다.

Reference

[1] Building Mobile Apps at Scale, Gergely Orosz

[2] https://www.uber.com/en-KR/blog/piranha/

[3] https://learn.microsoft.com/en-us/appcenter/distribution/codepush/

[4] https://medium.com/googleplaydev/shrinking-apks-growing-installs-5d3fcba23ce2

[5] https://www.datadoghq.com/monitoring/mobile-application-monitoring/

[6] https://albertodebortoli.com/2019/04/16/deep-linking-at-scale-on-ios/

[7] https://firebase.google.com/docs/cloud-messaging/concept-options#data_messages

[8] https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app

'어떻게할지' 보다 '누구와할지'가 중요한 이유

우리는 너무도 '어떻게'에 집중하며 살아왔습니다. 

'어떻게 더 좋은 팀을 만들지'

'어떻게 더 많은 성과를 이룰 수 있을지'

'현재 마주한 문제를 어떻게 해결할 수 있을지'

...

하지만 책 '누구와 함께 일할 것인가'의 저자 벤저민 하디 [1]는 우리가 '누구와'에 초점을 맞추어야 한다고 합니다.

마이클 조던은 팀 그로버 코치와 잭슨 감독이라는 조력자가 있었습니다. 그렇기에 그의 팀 시카고 불스는 여섯 번의 우승이라는 전례없는 기록을 세울 수 있었습니다.

스티브 잡스, 제프 베조스, 래리 페이지 등의 실리콘 밸리 거물들의 시작에는 빌 캠벨이라는 뛰어난 코치가 있었습니다.

이렇듯 뛰어난 업적을 빛내는 개인 주변에는 수많은 파트너와 조력자가 존재했습니다. 크고 멋진 결과는 사람을 통해서만 만들어집니다. 

그렇기에 우리는 사람, 즉 누구와에 집중해야 합니다. 

우리가 목표(무엇을?), 이유(왜?) 사람(누구와?)에 집중하면 더 많은 조력자를 얻을 수 있습니다.

바로 목표와 이유의 영감에 이끌린 이 사람들이 '어떻게'를 그들이 가진 전문성으로 채워줄 수 있습니다. 이때 당신은 세부적인 '어떻게'는 전문가에게 맡기고, 명확한 목표와 이유 그리고 이상적인 결과를 통해 그들과 커뮤니케이션해야 합니다.

그렇기에 더욱 큰 목표를, 관계에 기반한 더욱 큰 효능감을 통해 이룰 수 있습니다. 

당신의 지금 하려는 일이 성공적인 이직이라면, '누가 나를 성공적인 이직을 하도록 도울 수 있을까?'에 집중할 수 있습니다.

그렇기에 커리어 코치를 고용하거나, 선망하는 기업의 현직자의 면접 멘토링이라는 투자에 이르게 됩니다. 아니면, 자신의 명확한 목표(원하는 조건)와 이유를 널리 알려 여러 잠재조력자에게 노출할 수도 있습니다.

이말은 항상 누군가와 함께하라는 말이 아닙니다. 대신, '누구와'에 집중하고 그만큼 자신과 맞는 사람을 찾는데 투자하라는 의미입니다. 

다시 한 번 반복하면,

대부분의 사람들은 성공적인 결과를 생각할 때 너무나도 '어떻게 이 결과를 달성할까?'에 집중합니다.

우리는 '누구와 함께 일해야 하는가'에 초점을 맞추어야 합니다. 압도적인 성과는 사람을 통해 창출되고, 당신의 목표와 비젼은 사람과의 관계를 통해 더욱 단단해지고 확장되기 때문입니다.

Reference

[1] 누구와 함께 일할 것인가, 벤저민 하디

플랫폼이면 다 된다는 환상: FAANG의 실질적 경쟁우위와 살아남은 기업들

검색엔진에 기반해 검색을 하려는 사람과 디지털 퍼블리셔 그리고 광고주를 '연결'한 구글.

앱스토어를 통해 앱 개발자와 사용자를 '연결'한 애플.

사람과 사람을 '연결'한 SNS 페이스북.

판매자와 구매자를 '연결'한 마켓플레이스 아마존.

폭발적으로 성장해온 디지털 플랫폼들과 역사속으로 사라진 아날로그 기업들을 보면서,

'디지털 플랫폼이 되어 연결하면 뭐든지 가능하다'라는 맹신이 널리 퍼졌습니다.

플랫폼의 특징은 그것이 촉진하는 연결을 통해 핵심적인 가치가 나온다는 점입니다. 

하지만 이러한 플랫폼은 디지털 시대 이전에도 존재했습니다. 

그렇기에 IT 기업을 평가할 때에는 "On the most basic level, Peloton sells happiness" [2]과 같은 Yogababble [3]이 아니라 과거부터 검증된 동일한 프레임워크로 분석할 수 있습니다. 경영학 또는 투자자들이 기업을 판단하는 조건인 '경쟁우위'가 바로 그것입니다. 

위와 같은 맹신에 가장 걸맞는 기업은 바로 FAANG(Facebook, Apple, Amazon, Netflix, Google)일 것입니다. 하지만 FAANG을 자세히 살펴보면, 5곳 모두의 경쟁우위가 단순히 플랫폼에 있지 않다는 사실을 알 수 있습니다. 또한, FAANG의 빈틈을 파고들어가 자리를 차지하고 살아남은 기업들도 존재합니다. 

'플랫폼 망상'의 저자 조너선은 이러한 플랫폼에 대한 맹신은 현실가 괴리가 있으며, FAANG의 예시를 들며 실체를 보여주고 있습니다. 

그렇다면, 우리가 흔히 뭉뚱그려 말하는 '디지털 플랫폼'에는 어떤 가정이 있고, 실제는 어떠한 것일까요?

플랫폼 환상 이면의 가정들

사람들이 생각하는 '플랫폼'에 대한 환상을 자세히 나누어 보면, 다음과 같은 4가지가 존재합니다:

• 플랫폼은 혁신적이고 새로운 비즈니스 모델이다

• 디지털 플랫폼은 아날로그 플랫폼 보다 우수하다

• 모든 플랫폼은 강력한 네트워크 효과를 발휘한다

• 네트워크 효과는 곧 승자 독식 시장으로 이어진다

하지만, 조금만 생각해보아도 많은 허점을 발견할 수 있습니다.

• 상인과 고객을 연결하여 거래할 수 있도록 하는 신용카드 제공사는 1950년대부터 존재했습니다. 비디오 게임, 운영체제, 신용카드 등 예시는 인터넷 이전에도 다수 존재합니다.

• 온라인 쇼핑몰이 언제나 전통적인 쇼핑몰보다 우수한 것은 아닙니다. 온라인 상에서 판매자와 구매자의 관계는 아날로그 보다 매우 약하기에, 온라인 판매자는 끈임없이 경쟁사와 가격 경쟁을 벌이게 됩니다. 인터넷 탄생이후 등장한 수십 개의 전자상거래 회사중 1/4이 파산하거나 폐지되었고, 인수된 나머지의 2/3는 공모 가격보다 낮은 가격으로 인수되었습니다. 남은 상장 기업 1/3 중 60퍼센트 이상은 신규 상장 이후 전체 시장보다 실적이 낮습니다.

• 텔레비전 방송국, 영화관도 제작자와 시청자를 연결하는 플랫폼입니다. 넷플릭스 역시도 그렇습니다. 하지만 이러한 플랫폼의 경우 네트워크 효과가 발생한다기 보다는 규모의 경제에 이익을 누리는 측면이 큽니다. 줌(Zoom)은 링크 한 번으로 설치 직후 온라인 미팅 진입이라는 fritionless UX를 제공하지만, 그렇기에 lock-in 효과 없이 다른 제품으로 쉽게 대체될 수 있습니다.

• 책 '플랫폼 비즈니스의 모든 것'에서 저자는 (플랫폼 기업 중) "2015년까지 독립 상장 기업으로 남은 회사는 17퍼센트(252개 중 43) 뿐이었다. (중략) 플랫폼 분야에서 경쟁 업체가 진정한 승자 독식 또는 승자 다식의 경지에 이르는 바람에 실패한 기업은 비교적 적었다"라고 말합니다.

위와 같이 플랫폼에 대한 환상을 걷어내었다면, 실질적으로 IT 기업을 평가할 수 있는 잣대는 없는 것일까요?

경쟁우위

뛰어난 디지털 사업은 아날로그 사업과 마찬가지로 지속가능한 경쟁우위에 기반합니다. 경쟁우위(또는 해자 혹은 진입장벽)는 '효과적인 경쟁 공격을 방해하는 구조적 속성'에 해당되는데요. 효율적인 운영방식, 뛰어난 경영진은 경쟁업체가 모방하거나 고용할 수 있지만, 경쟁우위는 경쟁업체가 상대적 구조적 핸디캡을 예상하고 진입을 단념하게 만듭니다.

그렇기에 선두에 있는 FAANG은 단순히 플랫폼이라는 시각보다는 각각이 가지고 있는 경쟁우위에 기반해 분석해볼 필요가 있습니다.

FAANG의 실질적 경쟁우위와 살아남은 기업들

Facebook

페이스북 이전 또는 이후에도 수많은 소셜네트워크 서비스가 존재했습니다. 이전 SNS의 실패를 학습하여 적절한 타이밍에 성공적으로 안착할 수 있었습니다. 이후 페이스북 역시도 기존에 존재하던 '마이스페이스'와 같은 SNS이 무너지는 것을 보며 성장했기에, 창업자인 마크 저커버그는 초기부터 고객 유지력을 위한 전환, 습관, 확장성, 검색 등에 집중해왔습니다. 그렇기에 다른 분야의 사업을 확장한 기타 FAANG 기업들과 달리 페이스북은 SNS의 고객유지력을 위한 기업인수, 기능 개발이 주요 전략의 방향성이었습니다.

현재의 페이스북은 전형적인 네트워크 효과에 기반해 있다고 말할 수 있습니다. 대규모의 사용자, 연결된 수많은 3rd party 서비스들, 규모에서 나오는 높은 R&D 비용이 경쟁자들이 진입하여 의미있는 경쟁구도를 만들어 내는 것을 어렵게 하고 있습니다.

하지만 그렇기에 네트워크 효과에 기반한 취약점이 존재합니다. 네트워크가 충분히 커지면 참여자가 늘어도 가치가 별로 증가하지 않습니다. 또한, 커질수록 네트워크의 질을 떨어뜨리는 위험인자(사기꾼, 선동꾼 등)의 위협이 존재합니다. 다른 하나는 디지털 영역의 고객유지력의 한계라는 부분입니다. 페이스북 이전 또는 이후의 망해나간 SNS가 그렇듯이, 페이스북도 그러한 위협에서 완전하게 안전하지는 못합니다.

Amazon

아마존은 언뜻 판매자와 구매자를 연결하는 플랫폼의 전형으로 보입니다. 하지만 시초에는 아마존도 도소매의 디지털 버젼이었습니다. 실제로 판매자와 구매자를 연결하는 마켓플레이스를 시작한 것은 아마존이 설립한 뒤 10년이 지나서였습니다. 그러한 마켓플레이스에서 판매자는 여러 마켓플레이스를 통해 구매자에게 접근할 수 있으며, 아마존이 약한 카테고리(식품 등)도 존재했습니다. 그렇기에 아마존은 아마존 프라임이라는 멤버십을 통해 치열한 소매 업계에서의 고객 lock-in을 목적하였습니다.

아마존 프라임 이후 15년 동안 킨들, 킨들파이어, 홀 푸드 인수 등 10개 이상의 비지니스에 진입하였으나 의미있는 수익으로 연결된 것은 없었습니다. 하지만 의미있는 한 가지 AWS는 현재 아마존의 캐시카우가 되었으며, 현금 흐름표에서도 대부분의 R&D 비용이 이곳으로 들어가고 있습니다. 또한, 최근의 광고 사업도 유의미한 성과를 보이고 있습니다. 

아마존의 사업구조에서 네트워크 효과와 연관되어 있을 부분은 마켓플레이스에 해당됩니다. 하지만 아마존의 치열한 서브 마켓플레이스 인수가 보여주듯이, 모든 카테고리에서 아마존이 강력한 지배력을 보여주고 있지는 못합니다. 그렇기에 식료품(월마트), 자동차(지역 자동차 대리점), 주택거래(질로) 등 온오프라인의 빈곳들이 존재합니다. 지역적으로도 중국, 인도, 한국 등 빈곳이 존재합니다.

Apple

애플의 성공을 설명하는, 흔히 보이는 내러티브는 브랜드입니다. 하지만 브랜드는 경쟁우위에 기반이 될 때에만 의미가 있습니다. 그러한 연결은 제품이 속한 산업구조에 영향을 받습니다.

또한, 다른 FAANG과 다르게 애플은 시초가 매우 하드웨어 기반의 회사였습니다. 2001년 까지의 30여년 동안 애플의 영업 마진율은 10퍼센트를 넘긴적이 거의 없으며, 아이팟 이후부터 의미있는 성장을 시작했습니다. 아이팟은 마진이 현저히 낮았지만, 아이팟을 기반으로 컴퓨터, 아이폰(2007), 아이패드(2010)의 매출이 엄청난 성장을 이뤘습니다. 

운영체제는 원래 매우 네트워크 효과에 기반한 사업입니다. 개발자, 사용자의 참여는 더 많은 개발자와 사용자의 참여를 촉진합니다. 아이팟, 아이패드, 아이폰, 맥북으로 이어진 강력한 시장 점유율위에 애플은 '플랫폼'으로 보이는 아이튠즈, 앱 스토어 등을 올렸습니다.

애플은 아이클라우드, 애플 뮤직, 애플 TV 등의 서비스를 출시하며, 또 실적 보고에서 아이폰 판매량을 제거하고 서비스 매출을 표기하며 서비스 회사를 지향하고 있습니다. 안드로이드 보다 평균 3배 비싼 고급화를 지향하며 스티브 잡스(기술자)가 아닌 팀쿡(조달 및 공급망 관리)의 경영 아래 끊임없이 혁신해야 하는 애플은, 운영체제에 기반한 네트워크 효과를 서비스 시장과 연결하여 하드웨어에서 서비스 기반을 강화하는 방향을 보이고 있습니다.

Netflix

"미디어 업계의 감춰진 더러운 비밀 하나는 콘텐츠 제작자가 아닌 콘텐츠 수집가가 가치 창출의 압도적인 원천이라는 것이다. 1997년에 넷플릭스가 설립되기 훨씬 전부터, 오래된 영화와 만화, 텔레비전 프로그램을 모아서 방영하는 것 외에는 별다른 일을 하지 않던 케이블 채널들이 독창적인 콘텐츠를 제작하는 영화 스튜디오보다 몇 배나 높은 수익률을 자랑했다" [1].

넷플릭스를 생각하면 언뜻 시청자와 콘텐츠 제공자 사이의 플랫폼 사업이라고 생각하기 쉽습니다. 하지만 넷플릭스 초기에는 기존의 콘텐츠 통합 업체의 온라인 버젼이었습니다. 콘텐츠, 마케팅, 기술 비용은 넷플릭스의 고객이 늘어나며 규모의 경제를 통해 고정비용이 다수의 가입자를 통해 분산되었습니다. 하지만 다른 콘텐츠 통합 업체와의 경쟁에서는 주로 누가 훌륭한 콘텐츠를 많이 확보했냐가 우위를 누릴 수 있는 포인트입니다. 경쟁이 치열해지면, 선택의 여지가 없이 직접 콘텐츠 제작에 뛰어들 수 밖에 없습니다. 그것이 넷플릭스가 전략을 바꾸어 직접 콘텐츠를 제작하는 '창조적 위험'을 감수하기로한 이유입니다.

하지만 콘텐츠 제작에는 네트워크 효과는 물론, 규모의 경제 등을 통한 뚜렷한 경쟁우위를 만들기가 쉽지 않습니다. 시청자의 시청율, 데이터 등을 통해 '히트작'을 만들려고 했던 넷플릭스의 방향은 유의미한 성과를 보이지 못했습니다. 그리고 블록버스터 영화, 시리즈물 같은 콘텐츠 제작은 고정비용이 많지는 않고 대부분 변동비용이기 때문입니다. 

이는 애플 TV, 디즈니, HBO, 수많은 로컬 OTT와 넷플릭스가 수많은 곳에서 경쟁을 벌이게된 이유로 보입니다. 넷플릭스 이탈률 추정치가 연간 20 ~ 35 퍼센트인 점으 고려할 때, 그 부분은 더욱 치열하게 느껴집니다.

Google

디지털 광고 시장은 기존 아날로그 광고 시장은 빨아드리며 꾸준히 성장해왔습니다. 구글(알파벳)은 전세계 검색 90% 점유율에 기반해 매출의 85%가 광고에서 발생하고 있습니다.

구글은 누구도 따라올 수 없는 규모로 고정비용을 효율적으로 분산하며 많은 R&D 비용을 투자하고 있습니다. 이는 더 좋은 검색을 가능하게 하고, 더 많은 사용자를 촉진하고, 더 많은 학습과, 더 많은 광고주를 끌어들이는 규모, 공급, 수요의 효과적인 강화효과를 만들고 있습니다. 네트워크 효과는 광고 시장의 일부에서 더 많은 광고와 더 많은 광고 퍼블리셔 사이에서 일부 발생하나, 구글의 경쟁우위는 보기 드물고 강력한 규모, 공급, 수요의 강화효과에서 기인합니다. 

이러한 전세계 데이터에 대한 독점에 가까운 점유율은 구글에 대한 규제와 의심을 촉발했기에, 구글은 주로 "사악해지지 말자"와 같은 모호한 컨셉을 보이곤 했습니다. 하지만 이러한 핵심사업에서의 구조적 우위는 매우 강력해서 다른 산업에서의 실험과 탐색을 가능하고, 신사업의 경쟁력을 만들기도 해주고 있습니다.

Reference

[1] 플랫폼 망상, 조너선 A. 니

[2] Adrift: AMERICA IN 100 CHARTS, Scott Gallaway

[3] 상품을 팔거나 브랜드를 있어보이기 위해 붙인 spiritual-sounding 글귀, https://jeffswystun.medium.com/yogababble-the-spiritual-disguising-of-brands-dc2a873714f5

Conway's Law : '자세'를 잡지못한 조직이 '프로덕트'라는 힘을 쓸 수 없는 이유

컴퓨터 과학자 Melvin Edward Conway는 다음과 같이 말했습니다.

시스템 디자인은 조직의 커뮤니케이션 구조와 유사한 형태의 시스템을 만들게 된다 [1]

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure

이 말을 곰곰히 생각해보면, 특정 구조의 시스템 디자인을 원한다면 그러한 커뮤니케이션 구조를 만드는 조직 디자인(Organization Design)을 먼저 해야한다는 점을 알 수 있습니다. 

구체적 예시로 생각해보면, 이 말은 '마이크로서비스 아키텍쳐로 개발을 하려면, 마이크로서비스 아키텍쳐 형태의 조직 구조를 먼저 갖춰야 한다'와 같은 것들일 것입니다. 

다른 방향으로는, 원하는 시스템(또는 프로덕트) 디자인이 실제 조직의 커뮤니케이션 구조와 어긋난다면 목표하는 시스템 디자인을 이룰 수 없거나 추가적인 비용을 소모하게 된다고 느껴지기도 합니다.

그럴듯해 보이는 이 말은 명확한 근거자료가 있는 것일까요? 어느 정도 신빙성이 있는 말이라면, 실제 글로벌 기업이나 devops에는 어떻게 연결지어 이해될 수 있을까요?

조직의 커뮤니케이션 구조는 프로덕트 구조에 영향을 미치는가?

Conway의 아티클(1968) [1]은 조직 구조와 시스템 구조의 연관성에 대한 좋은 인사이트를 남겼지만, 이론적인 추론이었습니다. 하지만 비교적 최근 [2, 3]의 HBS(Harvard Business School)과 Microsoft의 연구결과는 양쪽 모두, '조직의 구조와 조직이 생산해내는 소프트웨어와의 연관성'을 시사하고 있습니다. 

특히, HBS의 연구는 조직 구조와 생산해내는 프로덕트의 구조의 미러링 현상, 즉 Conway's Law에 직접적인 결과를 뒷받침합니다. Loosely-coupled한 조직과 Tightly-couple한 조직에서 유사한 형태의 소프트웨어 제품(워드 프로세서, 재무회계 프로그램 등)이 어떻게 구현했는지 조사하였는데요. 그 결과, Loosely-coupled한 조직은 모듈로 구성된 프로덕트를(matrix 기법을 통해 수치화), tightly-coupled한 조직은 일부 코드의 수정이 전체에 미치는 영향이 큰 '뭉친' 코드로 구성된 경향이 강했습니다. 

그렇기에, 후자는 각 시기별 한정된 코어 개발자에 의존하고 그러한 코어 개발자가 떠나면 제품의 진화가 더뎌졌습니다. 반대로, 전자는 다수의 개발자가 참여하여 고르게 분포된 기여도를 보여주었습니다. 

Skewed Gnumeric (left) and Evenly distributed Apahce (right) - Image from [2]

Microsoft 연구도 Mythical Man-Month의 조직구조가 소프트웨어 품질에 영향을 미친다는 부분을 인용하며 시작하고 있습니다. Window Vista라는 샘플을 통해 조직구조가 초기의 소프트웨어 품질(테스팅, 디자인 재작업, 경제적 비용 등) 관점의 성공여부를 판가름하는데 유의미했다라는 정도의 결과를 보여주고 있습니다.

이렇게 조직의 커뮤니케이션 구조가 프로덕트에 영향을 미친다면, 최근의 마이크로서비스 아키텍쳐, Devops, FAANG 기업들의 뒷단에는 어떠한 조직 커뮤니케이션 구조가 존재할까요?

Modern Org Design for Software

어떤 조직구조여야 좋을까라는 생각을 하다보면, 어떤 프로덕트여야하나라는 생각을 먼저하게 됩니다. 특히 프로덕트의 구조, 아키텍쳐를 고민하게 되는데요. 이 부분에 있어서, 책 Team Topologies [6]는 무엇을 고려해야할지 잘 정리해주고 있습니다.

1. Conway's Law를 이해할 것, 즉 조직 (커뮤니케이션) 구조가 프로덕트 구조에 미치는 영향을 이해할 것

2. 그렇기에 목표하는 시스템 아키텍쳐를 이루기 위해서, 조직과 팀 구조를 그에 맞게 정비할 것 (Reverse Conway Maneuver)

3. 정비 시, 아래와 같은 사실에 유의할 것

- 개인이 아닌, 팀에 보상을 줄 것

- 피자 한 판의 팀(5 ~ 15명, 가능한 작은 팀을 권장)을 최소단위로, 팀은 장기적으로 유지할 것

- 팀에 명확하고, 인지적으로 부하가 높지않은 범위의 도메인을 할당하고 너무 넓어지지 않도록 제한할 것

- 도메인 간의 커뮤니케이션 패턴을 정리하여, 불필요하게 많은 커뮤니케이션이 발생하지 않도록 할 것

- 팀 간에는, 가능하면 명확한 API로 교류하도록 할 것

- '공유지의 비극'을 최대한 피해서, 각 도메인에 명확한 팀을 할당할 것

이런 작은 유닛 구조는 새로운 정보에 부분부분 빨리 대응할 수 있게 한다는 점 [7], 그로 인해 유연한 시스템과 유연한 프로덕트를 가능하게 합니다. 

또한, 구체적으로는 그러한 팀에는 어떠한 종류가 있고, 팀 간의 인터랙션은 어떠한 종류가 있는지 아래와 같이 전달해주고 있습니다. 

팀의 종류

• Stream-aligned 팀: 비지니스 도메인 또는 특정 조직 기능에 align되어 지속적인 업무(feature delivery)를 진행하는 팀. 다른 종류의 팀들은 이 팀의 부하를 덜어주는 것이 주요 목적이게 됨. 프로덕트 delivery의 풀 스펙트럼에 관여하기에 피드백이나 시스템 문제에 near-realtime으로 반응해야 함. 

• Complicated-subsystem 팀: 특정 지식에 깊게 관여한 컴포넌트를 개발하고 운영하는 역할을 담당함. 

• Enabling 팀: 특정 기술 도메인의 전문가로 구성되어, 여러 Stream-alinged팀이 특정 기술 전문성이 필요한 문제를 빠르게 해결하는 것을 지원함. 

• Platform 팀: Stream-aligned 팀이 자율적으로 업무(on-demand)를 진행할 수 있도록 지원함. 

위와 같은 프레임워크를 통해, 현재의 우리팀은 어떠한 역할들을 하고 있는지, 그렇다면 어떤 종류에 해당되고 그 목적은 무엇인지 분석해볼 수 있습니다. 

Final thoughts

헬스를 하다보면, 아무리 힘을 주어도 제대로 힘이 들어가지 않을 때가 있습니다. 대부분 부정확한 자세에서 기인하는 그 문제는, 애꿎은 곳에 힘을 주어 리소스를 낭비하고 목표한 부분을 타겟팅하지 못하는 기대와는 다른 디자인을 낳게 됩니다. 

프로덕트도 내부는 조직 커뮤니케이션 구조에 많은 영향을 받습니다. 필요없는 것 같은 커뮤니케이션이 너무 많이 발생하고 있거나, 조직구조와는 다른 형태의 커뮤니케이션이 필요한데 발생하지 못하는 경우에는 Conway's Law의 관점에서 양쪽을 점검해볼 필요가 있겠습니다.

원본:

Reference

[1] https://www.melconway.com/Home/pdf/committees.pdf

[2] https://www.hbs.edu/ris/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf?lipi=urn:li:page:d_flagship3_pulse_read;Jt69%2BCqYSgSZqq23lkSrbA%3D%3D

[3] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf

[4] https://radekmaziarka.pl/2021/03/14/conways-law-how-organizations-structure-influences-its-results/

[5] https://teamtopologies.com/key-concepts

[6] Team Topologies

[7] A second effect on performance of creating small, empowered units is to increase the likely speed of adaptation to new information - John Roberts, The Modern Firm

콜드 스타트 이슈 - 어떻게 네트워크 프로덕트를 성장시킬 것인가?

콜드 스타트 이슈(Cold Start Problem)는 말그대로 웜업(Warm-up)이 되지 않은 - 갓 출시된 프로덕트를 인지시키고, 각인시키고, 성장시키는 문제를 말합니다. 그러한 프로덕트 중에서도 특히, 네트워크 효과에 기반한 프로덕트에 해당되는데요.

용어를 만든 앤드류 첸은 운전 서비스 제공자와 이용자의 문제를 해결하는 Uber에서 초기 경험을 쌓았습니다. 그리고 이러한 문제가 Uber 뿐만 아니라 플랫폼의 성격을 지닌 다양한 IT 프로덕트, 그리고 다른 산업에서도 발생한다는 사실을 깨달았습니다. 

그는 이후 모습은 조금씩 다르지만 Uber, Airbnb, Facebook, Dropbox, Slack 등 다양한 프로덕트의 성장과정에서의 문제와 그것으로 인한 성공 및 실패를 네트워크의 라이프사이클 관점으로 정리하였습니다.

이 글에서는 콜드 스타트 이슈와 그것을 극복했던 방법들을 알아보겠습니다.

...

네트워크 효과, 그리고 콜드 스타트 이슈란?

네트워크 효과 [2]는 상품의 가치가 그것을 사용하는 수에 의존하는 것을 말합니다. 

Uber로 예를 들면, 강남구에서 분당을 가는 택시를 잡으려고 Uber를 켰는데 기사님들이 100분이 계셔서 1분만에 콜을 잡는 상황을 생각해볼 수 있습니다. 반대로 강남에서 분당으로 가려는 기사님들이 한 분도 안계셔서 5분, 10분, 30분을 기다려도 잡히지 않는 상황이 있을 수 있습니다. 전자와 후자에서의 Uber라는 서비스의 가치는 플랫폼에 존재하는 유저(기사님들) 수에 따라 엄청난 차이를 보입니다. 

다양한 IT 프로덕트들은 이러한 네트워크 효과에 기반한 상품입니다. 그러한 상품들은 위와 같이 노드 간의 연결(connection)을 늘려가며 성장하게 됩니다. 

앤드류 첸은 위의 프레임워크 중 가장 중요한 극초기 구간인 '콜드 스타트' 이름을 따서 '콜드 스타트 이론'이라고 정의했습니다. 이중에서 집중할 부분은 바로 네트워크의 가장 왼쪽인 극초기 부분인데요. 

대부분의 네트워크(또는 기반한 프로덕트)는 이 구간에서 실패합니다. 그러한 실패의 모습은 Uber에서 택시를 잡으려고 앱을 켰는데 드라이버가 아무도 없거나, 내가 여행갈 지역에서 숙소를 구하려고 Airbnb에 들어갔는데 겨우 1, 2개 리뷰가 달린 3 ~ 4개의 숙소가 있는 상황 등과 같습니다. 또는, 이메일을 사용하려고 앱을 켜면 내게 의미있는 이메일만 보이는 것이 아니라 스팸과 광고 메일로 뒤덮여서 그대로 앱을 삭제해버리는 상황과 같은 경우도 상상해볼 수 있습니다. 

실패의 모습이 위와 같다면, 성공은 어떻게 가능하고 또 어떠한 모습일까요? 

앤드류 첸은 다음과 같은 3가지를 강조합니다:

- Atomic Network 

- Anti-network effect를 예방하기

- Hard side 문제를 해결하기

Atomic Network

네트워크 상품의 가장 작은 기초는 외부 연결 없이도 동작하는 최소단위의 연결에서 시작됩니다. 강남에서 분당까지 운전을 제공하려는 제공자와 강남에서 분당까지 운전을 이용하려는 이용자 한명씩만 있다면 의미있는 상품의 연결(트랜잭션)을 만듭니다. 

그렇기에 네트워크 상품은 atomic network를 가능하게 하는 작은 기능에 집중해야 합니다. 상품의 atomic network에 대해 가설을 세우고 실험하며 그 특징을 이해해야 합니다. 그것에 따라 전략과 방향성이 달라지기 때문입니다.

채팅은 2명만 있으면 의미있는 연결을 이룹니다. Slack은 협업도구이기에 최소로 3명은 필요로 합니다. 반대로 HR 서비스의 경우 최소 10명, 20명이 모인 '회사'를 필요로 합니다. Atomic network의 크기는 물론, 그 밀집도(회사)도 다르기에 HR 서비스의 경우 viral 성장 전략은 어려울 수 있습니다. 하지만 경쟁자가 모방하여 성장하기는 어려울 수 있습니다.

작은 기능 상품으로 몇개의 의미있는 Atomic network를 이뤘다면, 그 다음은 무엇이 필요할까요?

Anti-network effect를 예방하기

Anti-network 효과는 새로운 네트워크를 제로로 만드는 힘을 의미합니다. 아래 이미지 (a)와 (b)에서의 연결의 갯수를 동일합니다. 하지만 (b)는 (a)보다 더 높은 밀집도로 이러한 anti-network 효과에서 보다 더 sticky합니다. 구체적인 사례로는 카카오톡을 사용하지 않으려고 지워도, 민원도 카카오톡으로 처리해야 하고, 친구에게 청첩장을 받을 때도, 회사에 연락을 할때도 사용하기에 다시 가입하고 설치하게되는 상황을 생각해볼 수 있습니다.

그렇기에 네트워크 상품은 진입 직후에 가장 약한 연결을 가지고 있습니다. 50% 이상의 사용자들이 앱을 다운받은지 일주일 이후에는 더이상 추가적인 트래픽을 발생시키지 않는다는 통계도 이와 비슷합니다. 많은 상품들은 이러한 진입 시점에서 가능한 많은, 그리고 밀집된 연결을 만들기 위해 노력합니다. 아래는 프로덕트별로 널리 알려진 관련 목표지표입니다:

• 페이스북: 7일 안에 10명의 친구 만들기

• Slack: 2000개의 메시지 (2000개의 메시지를 발생시킨 유저군의 93%가 여전히 Slack을 사용한다는 통계에 기반)

• Airbnb: 지역별로 100개 이상의 리뷰를 가진 300개의 숙소

또한 관련되어서 익숙한 UI 흐름들도 이 목표지표를 위한 것임을 알 수 있습니다:

• 페이스북 가입 시, 연락처 기반으로 친구 등록 

• Clubhouse 가입 시, 페이스북 친구리스트 또는 연락처 기반 친구 등록

Hard side 문제를 해결하기

Atomic network를 단단하게 만들고, Anti-network를 예방해도 유의미한 연결에 큰 영향을 미치는 또 다른 한 가지가 남아있습니다. 

네트워크를 자세히 살펴보면, 시간이 흐르면서 네트워크는 많은 연결을 지탱하는 쪽과 아닌 쪽으로 구분되게 됩니다. 많은 연결을 지탱하는 쪽은 Uber에서는 운전제공자, Instagram이라면 많은 뷰를 발생시키는 인플루언서, Youtube라면 컨텐츠 크리에이터 등이 해당됩니다. 이 대상이 바로 network의 hard side입니다. 그리고 네트워크 프로덕트에서 이러한 hard side를 만족시키며 충분히 확보하는 것이 atomic network를 유지하고, 전체 네트워크 그리고 프로덕트를 성장시키는 원동력입니다.

아래와 같은 사실들은 얼마나 소수의 hard side가 전체 네트워크에 기여하는지 알 수 있습니다:

• Wikipedia: 오직 유저의 0.02%만이 네트워크의 나머지를 위해 컨텐츠를 생성함

• 1/10/100 rule: Youtube라면 1% 유저가 컨텐츠를 생성하고, 10% 유저가 댓글을 쓰는 등을 통해 적극적으로 참여하고, 네트워크의 나머지는 컨텐츠를 소비함

• Tinder: 여성 유저는 오직 5% 확률로 ok(swipe)를 하나, 남성 유저는 50% 확률로 ok를 함

또한 그러한 hard side만을 분석해보았을 때도, 아래와 같이 매우 편중되어있다는 사실을 알 수 있습니다:

• Uber: 운전자의 20%가 60%의 콜을 처리함

• Wikipedia: 수백만명의 사용자 중, 매달 액티브 contributor는 100,000명이고, 그중 매달 100+ 수정을 하는 유저는 4,000명임

그렇기에 네트워크 프로덕트는 이러한 hard side를 정의하고, 충분한 hard side의 확보와 유지를 최우선으로 해야합니다. 

(원본: https://kadensungbincho.tistory.com/189)

Reference

[1] The Cold Start Problem, Andrew Chen

[2] https://en.wikipedia.org/wiki/Network_effect

고부가가치 개발

최근 팀내에서 논의가 있었다. 내부 툴 Front 단 개발을 어떤 형태로 진행할까에 대한 논의였다. 

보통 '이러한' 개발은 특정 이름 a라고 불리는 팀에 요청하여 처리하였기에, 이번에도 그런 형태로 처리하자고 마무리가 되었다. 내부에서 보면 '뚜렷하게' 차이가 나지 않는 팀 a는 명확히 구분하자면 외부사로, 특정 계약을 통해 프로젝트별로 비용을 지불하는 것으로 보였다. 

그 순간 내 머릿속에 떠오른 질문은 '어떤 기준으로 특정 작업(A)은 외주를 맡기고, 특정 작업(B)은 직접 고용한 인원으로 개발을 진행할까?'였다. 이어서, '그렇다면 내 밥값은 A 대신 B라는 특정 작업을 하고 있다는 사실로 정당한걸까?'였다. 

순간 스쳐지나간 생각을 글로 '끌고올' 정도로, 의미가 있다고 느꼈던 이유는

1. 이 부분에 대한 정리된 관점이, 앞으로 커리어를 잘 베팅하는 촉에 대한 도움이 될 것 같기에

2. 언젠가 '보이지 않는' 곳에서 이러한 판단을 내릴 수도 있기에 

라는 2가지 점 때문인 것 같다. 

어쨋든, 이 고민에 좀 더 머물러도 재밌겠다는 생각이 들었다.

이후 정리되지 않은 상태로 문제의 여운을 곰곰히 떠올려본 결과, 두 번째 의문은 쉽게 풀리는 것 같다. 

최근에 읽은 책, 사회학자 Jake Rosenfeld가 쓴 'You're paid what you're worth' [1]라는 책의 내용을 통해서다.

관련 부분은 짧게 요약하자면, "현대 기업은 점점 더 주주친화주의가 강해지면서 비용절감에 대한 요구에 지속적으로 부응하는 정책을 취했다. 기업들은 비핵심 또는 핵심 중에서도 비핵심적인 부분을 아웃소싱하는 형태로 발전해왔다. 또한, 그러한 시장을 만족시키는 아웃소싱 제공 업체도 점점 발전했다. 그렇기에 같은 회사에서 유사한 일을 하지만 소속에 따라서 급격한 임금 및 복지의 격차가 발생하고 있다." 

(논외로 책에서는 정확하게 성과를 측정하고 임금과 연결시키는 점의 어려움, 좋은 잡이 나빠지거나 나쁜 잡이 좋아졌던 히스토리 등 여러 흥미로운 내용을 다뤄준다 - 추천)

감정적으로는 안타깝다는 생각이 들지만, 개인적으로는 어쩔 수 없지 정도로 넘어갈 수 있는 정도의 정리인 것 같다.

첫 번째 고민을 생각해보니, 의외로 연관성이 있다고 느껴지는 부분은 꽤나 기술적인 개념에서 떠올랐다. 바로 DDD((Business) Domain-Driven (Software) Design) [2].

DDD에 관해 읽었던, (역시 좋은 책인) Vladik Khononov의 'What Is Domain-Driven Design?'라는 책에서는 비지니스 도메인 분석을 진행하며 서브도메인인 코어, 제너럴, 서포팅에 대하 구분지어 정의하고 있다. 

• 코어: 경쟁기업과 '다르게' 행하는 부분, 반드시 기술적일 필요 없음, 경쟁자가 복사 및 모방이 어려워야 하기에 본질적으로 복잡, 인하우스로 구현, (기술적인 부분이라면) 높은 수준의 엔지니어를 요구

• 제너럴: 대다수 기업들이 유사한 형태로 운영하고 있는 활동, 구현된 제품을 구입하는 것이 보통 더욱 비용효율적

• 서포팅: 기업 비지니스를 지원하는 부분, 어떤 경쟁우위도 제공하지 않음, 인하우스로 구현하는 것에 대한 필요성이 드뭄, 아웃소싱도 고려해볼 수 있음

당시에 책을 읽고 열심히 정리[2]할 때에는 느끼지 못한 부분이 실감되었다. 명확하게 보이진 않지만, 어느 곳에서 진행되고 있는 방향성이 DDD에서 말하는 부분과 일치한다는 느낌이 들었다. 

안그래도 좋았던 DDD에 대한 인상이, 커리어 고민에 대한 도움까지 된다니 더욱 좋아지는 듯 했다.

돌아보니 이러한 생각의 흐름에서 찾고 있는 것은 막연한 단어로만 들었던 '고부가가치'를 '개발'에서 찾고 있는 것 같았다.

최근 하는 일에 의미를 찾으며 프로덕트에 대한 관심이 높아졌는데, 역시 이 부분도 프로덕트라는 컨택스트에서야 가치가 평가되는 것 같다. 

현재 컨택스트에서의 고부가가치는 무엇일지, 현재 가지고 있는 능력이 어느 컨택스트에서 고부가가치가 될지라는 또 다른 질문을 만드는 생각들이었다.

Reference

[1] You're paid what you're worth, Jave Rosenfeld

[2]

[3] What Is Domain-Driven Design?, Vladik Khononov

주니어 개발자에게 추천하는 책 TOP 11

+300개의 책 중에서 꼽은 top11을 뽑아보았습니다!