3X Explore, Expand, Extract • Kent Beck • YOW! 2018

의역

대단히 감사합니다.

원래는 브리즈번에 아부하고 시드니를 깎아내리는 농담을 잔뜩 준비했었는데, 제 앞에서 이미 그 이야기를 선점해 버리셔서 그 농담으로 시작할 수가 없게 됐네요. 오늘 와주신 여러분 모두 정말 감사합니다. 점심 식사 후 시간대라는 걸 저도 잘 압니다. 대중 연설을 많이 해보셨는지 모르겠지만, 연사들에게 이 시간대는 벌칙이나 다름없거든요. 오늘 제가 무슨 잘못을 해서 이런 벌을 받는지 모르겠지만, 어쨌든 여기 섰습니다.

오늘 제가 여러분께 드릴 말씀은 하나의 '질문'에 관한 것입니다. 제가 처음에는 물어볼 줄 몰랐던 질문이죠. 소프트웨어 아이디어나 비즈니스 개발 초기에 이 질문을 던지는 법을 배우고 나서, 제가 무엇을 해야 하고 어떤 순서로 해야 하는지 바라보는 관점이 완전히 바뀌었습니다.

연사들이 흔히 쓰는 기술 중에 미스터리한 이야기를 던져놓고 맨 마지막에 가서야 그 정체를 밝히는 방식이 있는데, 저는 남들이 그러는 걸 싫어해서 그렇게 하진 않겠습니다. 하지만 이 초기 질문은 배경 설명이 좀 필요합니다. 그래서 제가 이 질문을 발견하게 된 사고 과정을 쭉 설명해 드리겠습니다.

보너스로 두 가지를 더 말씀드릴 수 있겠네요. 첫째, 이 질문을 바탕으로 익스트림 프로그래밍(Extreme Programming)의 문제점이 무엇인지 말씀드리겠습니다. 둘째, 페이스북의 문제점이 무엇인지도 말씀드릴 수 있습니다. 저는 올해 2월까지 7년 동안 페이스북에서 일하면서 이 개념을 이해하게 되었거든요.

2011년 1월 페이스북에 입사했을 때, 저는 난생처음 보는 개발 문화를 접했습니다. 겉보기엔 완전히 혼란스러웠어요. 사람들이 무작위로 일하는 것 같았는데, 희한하게도 잘 돌아갔습니다. 새로운 혁신적인 기능들이 나오고, 사용자 수는 계속 늘고, 전례 없는 엄청난 성장 속에서도 사이트는 다운되지 않고 유지됐습니다. 모바일로의 전환은 그 자체로 따로 강연을 해야 할 만큼 환상적인 비즈니스 스토리지만, 그 모든 게 제가 본 적 없는 규모로 눈 깜짝할 사이에 일어났습니다.

그래서 저는 이 이상하지만 기능적인 업무 문화, 엔지니어링 문화를 보고 생각했습니다. '도대체 무슨 일이 벌어지고 있는지 먼저 이해해야겠다. 그리고 이것을 보존해야겠다.' 왜냐하면 어느 시점이 되면 평균 회귀(mean reversion)가 일어날 테니까요. 당시 페이스북 직원은 2,000명, 엔지니어는 700명이었는데, 더 표준적인 엔지니어링 스타일로 돌아가려는 압력이 매우 강할 것이 뻔했거든요. 그래서 저는 이걸 이해하고, 보존하고, 강화해야 했습니다. 엄청난 성장이 예상됐으니까요. 실제로 제가 떠날 때쯤엔 엔지니어가 5,000명, 전체 직원은 25,000명 정도였으니 그 기간 동안 회사가 엄청나게 성장했죠.

저는 페이스북 내부에서 이 미친 엔지니어링 문화를 보존하고, 강화하고, 설명하려는 임무를 수행하면서 성공도 하고 실패도 맛봤습니다.

페이스북에 가면 가장 먼저 부트캠프를 거칩니다. 페이스북에 채용되면 특정 팀에 배정되는 게 아니라 그냥 엔지니어 풀(pool)로 들어옵니다. 처음 6주 동안 작은 변경사항(diff)을 만들고, 여기저기 자잘한 버그를 고치고, 수십억 명의 사용자에게 코드를 배포합니다. 담력을 시험하는 순간이죠. 첫 배포... 절대 잊지 못할 겁니다.

IRC에 제 첫 변경사항이 반영됐다는 메시지가 떴던 게 기억납니다. "릴리즈 L7이 6400개 서버 중 6300개에 성공적으로 배포되었습니다."라고 뜨더군요. 전 당황해서 옆 사람에게 물었죠. "나머지 100개 서버는 어떻게 된 거죠?" 그러자 "별문제를 일으키지 않는 것 같으니 괜찮아요."라고 하더군요. 그게 제가 겪은 '규모(scale)'에 대한 첫 경험이었습니다. 항상 뭔가 잘못되고 있지만, 전체가 계속 돌아가고 있다면 사실 괜찮다는 거죠.

제가 꽤 명성을 얻었던 그 '빨간색/초록색(테스트 실패/성공)' 개념은, 100개의 서버에서 무작위 코드가 돌아가도 문제없는 상황에서는 그렇게 단순하고 직관적으로 적용되지 않습니다. 이게 빨간색인가요, 초록색인가요? "초록색 비스무리한(Greenish)" 상태인 거죠. 그 정도면 충분합니다.

하지만 그건 또 다른 이야기고, 제가 좀 앞서나갔네요. 어쨌든 입사를 했고, 저는 시니어 엔지니어로서 페이스북 엔지니어링에 제 족적을 남기고 싶었습니다. 주변엔 온통 무작위로 일하는 젊은 애들뿐이었고요.

해커톤의 일환으로 수업을 개설할 수 있었는데, 저는 '아, 이거 좋겠다' 싶었습니다. 페이스북에 제 족적을 남기기 위해 '테스트 주도 개발(TDD)' 수업을 열기로 했죠. 저한테 TDD 수업을 듣고 싶지 않은 사람이 누가 있겠어요? 좋아 보였죠. 제 수업 바로 앞 시간은 '고급 엑셀 기술'이었고, 바로 뒤 시간은 '아르헨티나 탱고'였습니다. 수업 시간이 됐는데 엑셀 수업은 대기자 명단까지 꽉 찼고, 아르헨티나 탱고 수업도... 짐작하시겠지만, 대기자 명단까지 꽉 찼습니다. 그런데 제 수업 신청자는 정확히 0명이었습니다. 저 혼자였죠.

저는 생각했습니다. '이걸 어쩌지? 아무도 내 말을 안 듣는데 어떻게 페이스북 엔지니어링에 족적을 남기지?' 그때 제 경력에서 가장 무서운 결정을 내렸습니다. 제가 성공할 수 있는 유일한 방법은 제가 소프트웨어 엔지니어링에 대해 아는 모든 것을 잊어버리고, 제 왼쪽과 오른쪽에 있는 사람들이 하는 것을 보면서 처음부터 다시 배우는 것이라고 깨달았습니다.

"이거 테스트 필요해?" "당연히 필요하죠." "아니, 보니까 필요 없는 것 같던데." (웃음) 누가 알았겠어요. (웃음) "이게 작은 변경사항들의 연속인가, 아니면 큰 거 한 방인가?" "정말 정말 큰 거 한 방이네? 오, 알겠어." 이런 식이었습니다. 그래서 "내가 전문가니까 내 말대로 해"라고 했다면 해고당했겠지만, 저는 그들 방식대로 해보고 얼마나 빨리 배울 수 있는지 시험해 보기로 했습니다. 첫 6개월 동안 해고당하지 않을 만큼 충분히 배울 수 있을지 말이죠.

결과적으로 저는 해고당하지 않고 매니저와 주간 면담을 370번 정도 했습니다. 세어봤어요. 매주 좀 불안했거든요. 어쨌든 잘 풀렸습니다.

처음 1년 정도는 코드를 짰는데, 제가 배운 것 중 하나는 제가 C++를 정말 싫어한다는 사실이었습니다. 주변 사람들에 비해 코딩만으로는 크게 성공적이지 못했죠. 그래서 새로운 할 일을 찾아야 했습니다. 친구인 피터 데모프가 "네가 말하던 코칭이라는 걸 내부적으로 해보는 건 어때?"라고 제안했습니다.

그래서 저는 'Good to Great'라는 코칭 프로그램을 시작했습니다. 엔지니어와 12회 세션을 갖는 건데, 한 시간 정도 대화하는 방식이었고 예전 테크 랩스(Tech Labs) 시절, 그러니까 한 250년 전쯤에 워드 커닝햄과 나눴던 대화를 모델로 삼았습니다. 그런 대화가 부족해 보여서, 이런 대화를 통해 엔지니어들이 더 빨리 성장할 수 있을지 보고 싶었습니다.

결과는 좋았습니다. 그 대화들은 엔지니어들에게 매우 도움이 되었습니다. 나쁜 소식은 페이스북이 철저히 지표 중심(metrics-driven) 문화라는 점입니다. '추천글이 적힌 종이 장수'는 잘 먹히는 지표가 아니더라고요. 평가 기간 끝에 제 학생들과 매니저들이 쓴, 코칭 과정이 얼마나 환상적이고 변화를 가져왔는지에 대한 칭찬 페이퍼가 수북이 쌓였지만, 아무도 '추천글 페이지 수'로 진척도를 측정해주지 않았습니다. 저 혼자만 그랬죠.

3년 정도 코칭을 하고 학생들과 데이터가 충분히 쌓인 후에야 HR에서 분석을 해줬습니다. 모든 변수를 통제하고 제 학생들을 동료들과 비교했을 때, 제 코칭을 받은 학생들이 코칭 후 1년 이내에 승진할 확률이 2배 더 높았습니다. 그제야 사람들이 '승진 속도(promotion velocity)'라는 지표를 인정해 줬죠. 어떤 해에 승진할 확률이 5%였는데 제 코칭을 받으면 10%가 되는 겁니다. 이건 꽤 큰일이고, 측정 가능하며, 사람들에게 큰 차이를 만들어주는 거였죠.

그 직업의 장점 중 하나는 페이스북 코드베이스의 모든 것을 볼 수 있었다는 겁니다. 수많은 다른 팀들이 어떻게 일하는지 봤는데, 팀마다 일하는 방식이 매우 다르다는 것을 발견했습니다. 사용자 인터페이스 개발자들은 제가 이해하는 방식의 자동화 테스트 없이 일했고, 리눅스 커널 팀은 제가 쓰거나 예상했던 것보다 훨씬 더 많고 다양한 종류의 테스트를 했습니다. 즉, 혼란스럽긴 했지만 '일관성 없게' 혼란스러웠습니다. 일관성 없는 혼란에는 패턴이 있습니다. 아직 그 패턴을 보지 못했을 뿐이죠. 무작위적인 혼란은 그냥 혼란일 뿐이지만, 사람들이 진짜 동전을 던지는 게 아니라면 실제 혼란을 유지하기는 정말 어렵습니다. 어딘가에는 패턴이 있기 마련입니다.

저는 페이스북에서 보낸 시간의 대부분을 엔지니어 코칭에 썼습니다. 총 200명 정도를 코칭했고, 제가 만든 수업을 수천 명이 들었으며, 시니어 엔지니어가 주니어 엔지니어를 코칭하게 하는 프로그램을 운영해서 수백 명을 더 코칭했습니다. 꽤 괜찮은 성과였죠.

제 경력을 통틀어 저는 항상 머릿속에 여러 아이디어를 담아두곤 합니다. 언제 어떤 게 튀어 나올지 모르니까 잔뜩 넣어두는 거죠. 몇 년 전 'Econ Talk' 팟캐스트를 들었는데, 혹시 청취자 계신가요? 경제학은 정말 재밌죠. 보통 '경제학'과 '재밌다'는 말을 같이 쓰진 않지만요.

거기서 나심 탈레브(Nassim Taleb)와 이야기를 나누는데, 그가 두 가지 보상(payout) 스타일의 큰 차이를 언급했습니다. 불행히도 그는 이걸 '볼록(convex)'과 '오목(concave)'이라고 불렀는데, 이게 참 이해하기 어렵습니다. 제가 알아내는 데 6년 걸렸거든요. 잠시 후에 보여드릴게요. 이름은 별로지만 본질적인 차이는 이렇습니다.

작은 투자를 했는데 대부분은 다 잃지만, 가끔 엄청난 대박이 터지는 경우. 이걸 '볼록(convex)'이라고 합니다. 볼록한 세상에 있다면 베팅을 많이 해야 합니다. 대부분 실패하겠지만, 보상이 전혀 없는 상황은 정말 피해야 하거든요. 그러면 사업을 접어야 하니까요. 같은 돈으로 더 많은 실험을 할 수 있다면 엄청난 개선입니다. 그 거대한 대박을 터뜨릴 확률을 높이는 거니까요. 왜 이게 볼록이냐면, 제가 공간 지각력이 안 좋아서 6년이나 걸렸는데, 여기 작은 사람을 그려놓고 이쪽을 보면 곡선이 그 사람에게 볼록하게 보입니다. 이해되시죠? 저보다 훨씬 똑똑하시네요.

반대로, 아주 큰 투자를 하는데 대부분은 작은 수익을 얻고, 가끔은 엄청난 돈을 잃는 세상이 있습니다. 이게 '오목(concave)' 세상입니다. 오목한 세상에서는 이 수익 곡선을 아주 조금만 위로 올려도 전체 보상에 엄청난 차이를 만듭니다. 그리고 완전한 실패를 줄이고 싶어 합니다. 그 실패 비용이 너무 크니까요. 여기 작은 사람을 그려놓고 위를 보면 오목한 곡선이 보이죠. 6년 걸려서 알아낸 겁니다.

여러분이 오목한 세상에 있는지 볼록한 세상에 있는지를 구별하는 건 매우 중요합니다. 잃을 게 없을 때와 잃을 게 아주 많을 때, 우선 잃지 않으려고 노력하고 가능하다면 조금 더 개선하려는 것 사이에는 사고방식의 큰 차이가 있습니다. 팟캐스트를 들었을 때는 작은 사람이 어디 서 있어야 하는지 몰라서 헷갈렸지만, 어쨌든 그 아이디어를 머릿속에 넣어뒀습니다.

이 질문을 떠올리게 된 두 번째 계기는 '폭포수(Waterfall) 모델의 귀환'이었습니다. 폭포수의 귀환을 보신 적 있나요? 최근에 사람들이 실제로 "정확히 뭘 만들지 먼저 설계하자"고 주장하는 걸 보셨나요? 네, 호주는 욕을 좀 하는 곳 맞죠? "지랄하고 있네" 소리가 절로 나오죠. 똑똑한 사람들이... 아, 욕 안 하기로 했죠. 아마도요. 하지만 정말 다른 반응이 나올 수 있을까요?

저는 정말 똑똑한 사람들이 폭포수라고 부르지는 않지만, "시작하기 전에 철저한 시장 조사를 해야 한다. 풍경을 이해해야 하니까. 그리고 비즈니스 모델을 정교하게 다듬고, 제품이 정확히 어떻게 될지 그려보자"고 주장하는 걸 봤습니다. 구현은 프로그래머들이 알아서 하고요. 유일한 검증은 사용자 테스트뿐이고 QA도 없습니다. 새로운 세상이지만 테스트 없는 폭포수 모델이죠.

저는 그런 반응을 보였습니다. "이건 폭포수잖아. 잘 알려진 이유들 때문에 이건 작동하지 않아." 30살의 켄트와 50살의 켄트의 차이는, 30살의 켄트는 "저런 멍청이들"이라고 했겠지만, 50살의 켄트는 "음, 멍청이들이긴 한데... 음, 무슨 일이지?"라고 생각했다는 겁니다.

그리고 그 두 가지 아이디어가 기억났습니다. 아이디어는 보통 두 가지가 부딪힐 때 나오죠. 새로운 아이디어는 없지만 아이디어의 새로운 조합은 있으니까요. 볼록/오목 곡선이 생각났고, 저는 깨달았습니다. "아, 이 폭포수 같은 방식은 '오목한(Concave)' 상황에 대처하려는 시도구나." 잃지 않으려고 저렇게 신중하고 사려 깊게 분석하는구나. 이기려는 게 아니라 지지 않으려는 거구나. 물론 피드백 때문에 작동하진 않겠지만, 그런 개발 방식을 옹호하는 사람들이 바보는 아니었던 겁니다. 단지 제 전문 분야가 아닌 문제를 해결하고 있었던 거죠.

저는 새로운 아이디어를 탐험하는 걸 좋아합니다. 누군가 "음, 그거 될 수도 있겠는데"라고 말하는 순간 저는 그 아이디어에 대한 흥미를 잃습니다. 그건 버리고 다음 아이디어로 넘어가야죠. 사람들이 "아니, 이건 미친 짓이야. 절대 안 될 거야"라고 할 때가 제가 가장 좋아하는 순간입니다. 저는 그 미친 아이디어들이 넘치는 볼록한 세상(convex world) 깊숙이 있는 걸 좋아합니다. 참고로 이런 스타일의 신제품 개발은 볼록도 오목도 아닙니다. 큰 투자를 하는데 보상은 적은, 아주 작은 확률의 작은 보상만 있는 경우죠. 그래서 폭포수 스타일로 개발하려고 하면 잘 안 되는 겁니다.

시드니에서 연습 삼아 강연을 하고 나서야 이 생각이 정리돼서 지금 여러분께 제대로 된 버전을 들려드리는 겁니다. 약간의 아부 맞습니다.

제가 그 두 곡선을 보여주고 볼록한 세상과 오목한 세상에서 어떻게 개발해야 하는지 이야기하기 시작했을 때, 제 친구 티아고가 "그 곡선들을 합쳐보면 어때요?"라고 했습니다. 저는 "오, 음..." 하고 합쳐봤습니다. 그랬더니 이 질문이 제 머릿속에 떠올랐습니다.

질문은 바로 "당신은 잃을 것이 무엇인가? (What do you have to lose?)"입니다.

제가 어떻게 행동할지 결정할 때 가장 먼저 물어봐야 할 질문입니다. 잃을 게 없는 경우도 있고, 잃을 게 아주 많은 경우도 있는데 그때마다 행동은 아주, 아주 달라야 합니다.

자, 이렇게 진행됩니다. 제가 새로운 가치의 원천을 찾고 있다고 칩시다. 실험해 봅니다. 안 됩니다. 하지만 뭔가 배웠죠. 또 다른 실험을 합니다. 여전히 안 됩니다. 다른 거, 또 다른 거, 또 다른 거... 그러다가 이전에 했던 모든 실험과 겉보기엔 똑같은 실험을 했는데, 어떤 이유에서인지 사람들이 완전히 다르게 반응합니다.

제 경력에서는 JUnit이 그랬습니다. 이 이야기는 많이 했는데요. 에릭 감마와 제가 비엔나에서 비행기를 타고 워싱턴 DC로 가서 애틀랜타에서 열리는 OOPSLA에 가는 길이었습니다. 그는 자바를 알았고 저는 XUnit을 알았죠. 우리는 배터리가 다 될 때까지 프로그래밍하기로 했습니다. 잘 됐어요. 착륙해서 우리가 만든 걸 마틴 파울러에게 건네줬습니다. 다음날 30명이 그 프로그램을 얻으려고 필사적으로 우리를 쫓아다녔습니다. 이건 정상적인 행동이 아니었죠. 우리 둘 다 수많은 프로그램을 짰지만, 사람들이 그 프로그램을 달라고 요구한 건 처음이었습니다.

탐험(Exploration)이란 게 그렇습니다. 이것저것 시도해 보고, 조금 배우고, 조금 해보고, 다른 걸 시도하다가 겉보기엔 다른 것들과 똑같아 보이지만 '성장 루프(growth loop)'를 발견하게 되는 겁니다. 탐험의 목표는 성장할수록 더 성장하기 쉬워지는 이런 강화 루프를 찾는 것입니다. 전화 교환기가 고전적인 예죠. 교환기에 연결된 사람이 많을수록 다음 사람이 연결될 때의 가치가 더 커지는 것, 그게 성장 루프입니다.

탐험은 그런 새로운 성장 루프를 찾는 과정입니다. 그리고 이건 합리적인 과정이 아닙니다. 다음 루프가 어디에 있을지 예측할 수 없습니다. 예측할 수 있었다면 돈 많은 누군가가 이미 했을 테고 여러분에겐 기회가 없었겠죠. 그래서 미친 아이디어 두 개를 합쳐봐야 합니다.

"메시지 시스템을 만들 건데, 모든 메시지를 영구 저장하고 검색 가능하고 가치 있게 만드는 대신, 24시간 뒤에 다 지워버리자." 메신저 시스템치고는 역사상 가장 멍청한 아이디어 같지만, 스냅챗(Snapchat)이죠. 그 두 아이디어를 합쳤더니 어떤 이유에서인지 대박이 났습니다.

탐험 단계에서는 여러 가지를 시도해야 합니다. 종종 대박 나는 아이디어는 터무니없어 보입니다. 탐험에서 '웃음'은 정말 좋은 신호입니다. "이걸 뜯어내고 저걸로 바꾸면 어떨까?" 했을 때 다들 "하하하" 하다가, "근데... 그거 시도하는 데 얼마나 어려울까?"라는 긴장된 순간이 오는 거죠. 그게 탐험의 핵심 질문입니다. 시도해 보는 게 얼마나 어려울까?

나쁜 아이디어는 많이 시도해 보고 버려야 합니다. 하지만 "이걸 시도하는 게 얼마나 저렴한가?"라는 질문이 중요합니다. TDD(테스트 주도 개발)도 멍청한 아이디어였죠. 명백히 멍청한 아이디어입니다. 테스트가 통과되길 원하는데, 실패할 게 확실한 테스트를 코드보다 먼저 짠다니요? 진정하세요, 멍청한 짓이니까요. 코드가 다 작성될 때까지 기다렸다가 테스트를 짜면 되잖아요. 왜 먼저 합니까?

알고 보니 코드를 짜기 전에 테스트를 짜야 할 좋은 이유가 많았습니다. 하지만 저도 처음엔 말 그대로 크게 웃었습니다. 그러다 "반대로 해보는 게 얼마나 어려울까?" 생각했죠. 30분 걸렸습니다. 그리고 깨달았습니다. "아, 코드가 정말 작동하는지 불안해할 필요가 없구나. 다음 단계는 뭐지? 이걸 한꺼번에 다 구현할 필요가 없네." 결과는 좋았지만 시작은 웃음이었습니다.

그게 탐험입니다. 탐험은 게임입니다. 규칙이 있고 트레이드오프가 있습니다. 장기적인 것과 단기적인 것 사이의 트레이드오프는 철저히 단기적인 쪽에 쏠려 있습니다. 지저분한 편법(filthy hacks)도 탐험에서는 환영받습니다. 지속 가능성은 신경 안 씁니다. 어차피 버릴 거니까요. 만약 안 버리게 된다면 그건 너무 가치 있는 거니까 어쨌든 신경 안 쓰게 되고요.

이게 탐험(Exploration)입니다. 하지만 우리가 뭔가를 해냈고 그게 터져서 이전에 했던 그 어떤 것보다 커졌다고 칩시다. 게임이 바뀝니다. 트레이드오프가 바뀝니다. 이전의 탐험 단계에서 상대방(적)은 '무관심'이었습니다. 아무도 당신 아이디어에 신경 안 썼죠. 이제는 사람들이 신경 씁니다. 이제 문제는 '스케일링(확장)'입니다. 우리가 충분히 빨리 성장할 수 있을까?

제가 말했듯이 게임이 바뀌고 성장의 장벽을 만나기 시작합니다. 돈이 떨어지고, 투자를 좀 받았더니 사무실 공간이 부족하고, 채용 속도가 못 따라가고, 네트워크 대역폭이 부족해지고, 다른 무언가가, 또 다른 무언가가 문제가 됩니다. 확장(Expansion)의 특징은 각각의 위기가 '실존적(existential)'이라는 겁니다. 헤라클레스의 12과업 같아요. 헤라클레스가 공주와 맺어지려는데 왕이 안 된다며 불가능한 7가지 일을 시키는 거죠. 하나라도 실패하면 공주는 없는 겁니다.

확장이 그렇습니다. 곡선 위로 쭉 올라갔더라도 마지막 테스트를 통과 못 하면, 미친 듯이 성장하는 것처럼 보였어도 지속 가능한 비즈니스를 만들지 못하고 끝납니다.

탐험은 '범위의 경제(economies of scope)'에 관한 것입니다. "이걸 저걸로 바꾸면 사용자가 어떻게 반응할까?"라는 질문을 검증하기 위해 얼마나 적은 일을 할 수 있는가? 시계는 가고 있고 얼마나 빨리 경험적인 답을 얻을 수 있는가?

확장은 '위험의 경제(economies of risk)'에 관한 것입니다. 갑자기 자본이 넘쳐납니다. 매월 100%씩 사용자 성장이 일어나면 2주 전만 해도 전화도 안 받던 벤처 캐피털리스트들이 돈을 싸 들고 옵니다. 자본은 갑자기 저렴해지지만 리스크는 정말 비싸집니다. 확장에서 리스크를 줄일 수 있는 일이라면 뭐든지 합니다. 돈을 쏟아부어서 해결된다면 그렇게 합니다. 결국 만들어낼 결과물이 확장 단계에서 택한 모든 지름길 비용을 갚고도 남을 테니까요.

확장은 그 자체로 하나의 엔지니어링 규율입니다. 페이스북에는 구내식당에서 점심을 먹다가 누군가 해결 불가능해 보이는 기술적 문제를 이야기하면 "오, 내가 그 랙 스위치가 왜 불타는지 알아. 더 말해봐"라고 하며 다가오는 사람들이 있었습니다. 그들은 말 그대로 불을 끄러 다니며(가끔은 진짜 불이기도 하고요) 기술적인 마법을 부려 기술적 성장 장벽을 돌파했습니다.

하지만 다른 규율, 다른 엔지니어링, 다른 관리 규율입니다. 탐험이 학습과 창의성, 공간의 커버리지에 관한 것이라면, 확장은 다음번에 우리를 죽일 요소를 찾아서 그것이 우리를 죽이지 못하게 하고, 그다음 죽일 요소를 찾는 것입니다. 꼬리에 꼬리를 물고 이어지죠.

이 탐험에서 확장으로 넘어가는 전환(Explore to Expand transition)을 눈치채지 못하면 정말 안 좋은 날이 될 겁니다. 계속 느슨하게 실험만 하고 있는데 시스템은 무너지고 유저는 불행해져서 딴 데로 가버리면, 환상적인 기회를 놓치는 겁니다.

마치 축구를 하다가 공을 차고 룰을 익히고 상대방을 파악했는데, 심판이 호루라기를 불더니 이상한 타원형 공을 들고 나오고 크고 털 많고 땀 냄새 나는 거구들이 들이닥치는 것과 같습니다. 럭비공이 필드에 있고 럭비 팀이 상대인데 계속 축구를 하고 있으면 잘 풀릴 리가 없죠. 이전 게임의 전략으로 성공할 수 없습니다.

확장은 매우 집중된 짧은 기간입니다. 초과 근무가 효과를 발휘하는 시기이고, 같은 방에 앉아 있는 게 큰 차이를 만드는 시기입니다. 전체 프로젝트 시간에서 큰 비중을 차지하진 않지만, 모두가 같은 페이지에 있고 같은 문제를 다루고 상황을 똑같이 이해해야 하는 시기입니다.

우리가 6가지 죽을 고비를 넘겼다고 칩시다. 이제 때가 됐습니다. 이제 예측을 시작할 수 있습니다. "사용자가 한 명 늘 때마다 서버가 이만큼 더 필요해"라며 전망(projections)을 할 수 있습니다. 다시 게임이 바뀝니다. 우리는 가치를 추출(Extract)하기 시작하고 성장은 계속됩니다. 하지만 더 질서 정연하고 예측 가능한 방식이죠.

계속 성장합니다. 여기엔 플레이북(Playbook)이 있습니다. "20번째 국가에 제품을 출시한다." 플레이북이 있죠. 실행에 관한 것입니다. 문제가 뭔지 알고 무자비하게 실행해야 합니다. 무엇을 실행해야 할지 아니까요. 하지만 제약 조건은 또 다릅니다. 여기서는 장기적인 관점이 중요해집니다. 리팩터링이 엄청난 가치를 지니고, 자동화 테스트가 보상을 줍니다. 장기적인 보상이 실현될 시간이 있으니까요.

하지만 역시 매우 다른 스타일의 엔지니어링, 관리, 재무 방식입니다. KPI(핵심 성과 지표)는 추출(Extract) 단계에서 아주 합리적입니다. 데이터가 많으니까요. "월요일에 출근해서 금요일까지 이 숫자를 4% 올려놔." 이게 가능합니다. 탐험 단계에서 KPI를 쓰는 건 말이 안 됩니다. 숫자가 뭔지도 모르는데 얼마나 올리고 내릴지 어떻게 압니까.

페이스북에서 추출 팀 내에서 탐험을 하는 팀들과 이야기해 봤는데, 다들 "미치겠어요. 지표상 진척이 0이거나 약속한 것보다 100배 더 나오거나 둘 중 하나예요."라고 하더군요. 정말 이진법(binary)적입니다. 탐험은 이진법적입니다. 확장은 우리를 죽일 숫자 하나가 있고 그걸 개선하지 않으면 끝입니다. 추출은 균형 잡힌 스코어카드를 가지고 지속적인 진척을 만들 수 있는 곳입니다.

이 곡선을 한 번 겪고 성공했다고 칩시다. 이제 까다로운 부분이 시작됩니다. 탐험 프로젝트와 추출 프로젝트를 같은 조직에서 동시에 운영할 수 있을까요? 2011년경 제가 갔을 때 페이스북이 기가 막히게 잘했던 게 이겁니다.

관리자로서 이건 단순히 "모두에게 KPI를 주고 똑같이 평가하겠다"는 것보다 훨씬 복잡합니다. 축구 경기와 럭비 경기에 같은 통계를 적용하시겠습니까? 말이 안 되죠. 다른 게임, 다른 상대, 다른 구조, 다른 트레이드오프니까요. 축구팀과 럭비팀의 플레이를 개선하기 위해 하나의 지표 세트를 만들 순 없습니다.

페이스북이 잘했던 세 번째는, 탐험은 볼록한 부분이고 추출은 오목한 부분인데, 이 '확장가(expanders)' 그룹을 유동적으로 운영했다는 점입니다. 초기 멤버들과 이 모델에 대해 이야기해 보면 "맞아, 내가 확장가였어. 아무도 시도해 본 적 없는 장비에 뛰어들어서, 벤더도 모르는 이유로 실패하는 걸 고치는 게 정말 좋았어. 내가 고친 마법사였고, 또 다른 걸 하러 갔지."라고 합니다.

확장 프로젝트는 다른 모든 것보다 우선합니다. 탐험에서는 작은 확률의 큰 보상이, 추출에서는 큰 확률의 작은 보상이 있지만, 확장에서는 큰 확률의 큰 보상이 있습니다. 그 기간이 길지는 않지만, 그 기회를 놓치면 비즈니스적으로 소프트웨어 개발의 가장 가치 있는 부분을 놓치는 겁니다.

여러분이 추출자(extractor)라고 칩시다. 백만 달러를 받고 회사에 1,000만 달러를 벌어다 줍니다. 모두가 환상적이라고 생각하죠. 그런데 어느 날 새로운 기능 때문에 모든 게 망가지고 있습니다. 매니저는 여러분에게 "가서 저것 좀 해결해"라고 해야 합니다. 페이스북 스타일에서는 그냥 "내가 가서 저거 해결할게"라고 말하죠.

누군가는 제 대신 회사를 위해 900만 달러를 버는 일을 메워야 하겠지만, 그 새로운 기능이 당장 매출을 내지 않고 대박을 터뜨리지 않았더라도, 무언가 터지고 있다는 사실 자체가 잠재력이 있다는 뜻이기에 누군가는 그걸 해야 합니다.

그래서 조직은 적은 자본으로 탐험(Explore) 프로젝트를 돌리고, 엄격한 회계 ROI와 수많은 지표로 추출(Extract) 프로젝트를 돌려야 합니다. 그리고 무언가 급격히 성장하기 시작하면, 도울 수 있는 사람은 누구든 자신의 다른 책임과 상관없이 거기에 뛰어들어야 합니다.

이건 관리하기에 정말 복잡한 풍경이지만, 지난 15년 동안 가장 큰 비즈니스 기회 위에 앉아 있다면, 혁신을 지속하면서 동시에 실행할 수 있는 유일한 방법입니다. 제가 본 바로는 그렇습니다. 페이스북 개발이 그토록 오랫동안 그토록 큰 규모로 효과적으로 작동했던 이유는 서로 다른 프로젝트가 매우, 매우 다르게 취급되었기 때문입니다.

이제 여러분은 페이스북이 될 수 없고, 지금은 페이스북이 되고 싶지도 않으실 겁니다. 몇 년 전엔 되고 싶었을지 몰라도 지금은 아무도 페이스북이 되고 싶어 하지 않죠.

이제 이 상황이 어떻게 나빠졌는지 설명해 드리겠습니다. 이건 제 설명입니다. 저는 혼란스러운 걸 보면 이해하고 싶어 합니다. 그게 제가 하는 일이죠. 가끔은 맞고, 가끔은 그냥 그럴싸하게 이해만 하는 겁니다. 좋은 설명은 아니지만 저는 이렇게 생각합니다.

페이스북에서는 모두가 '임팩트'로 관리됩니다. "너의 숫자는 뭐야? 향후 6개월 동안 얼마나 올려야 해?" 6개월이 시작될 때 "고양이 밈 댓글 수를 3% 올리겠습니다."라고 합니다. 몇 가지 시도해서 4% 올리면 정말 훌륭한 사람입니다. 2%만 올리면 별로고, 하나도 못 올리면 심각한 대화를 하게 되죠.

이게 모델입니다. 수치적인 목표가 있고 6개월 안에 달성해야 합니다. 페이스북 전체가 탐험과 확장 단계에 있을 때는 이런 스타일의 관리와 성과 평가가 아주 잘 통했습니다. 탐험 단계에서는 작은 것들을 많이 시도해 보라는 인센티브가 되니까요. 매주 실험을 할 수만 있다면 무언가는 성공할 겁니다. 그래서 목표를 달성하거나 초과 달성할 확률이 높죠. 가장 좋은 건 첫 달 만에 4%를 달성하고, 남은 기간엔 정말 미친 짓들을 시도해 보는 겁니다. 기회에 집중하게 만드는 데 아주 효과적입니다.

확장 단계로 가봅시다. 여기서도 임팩트에 집중하는 것이 잘 통합니다. 저는 여러분 모두가 병목 현상을 찾아서 성장을 가로막는 다음 요인을 찾아내길 원합니다. 그들은 선제적으로 나가서 "이게 성장하고 있어서 우리 용량을 초과할 뻔했는데, 제가 성장률을 낮추고 해결해서 1억 달러를 아꼈습니다."라고 말합니다. 환상적이죠. 수백만 가지 일이 일어나는데 어떻게 모두가 가장 중요한 일을 찾게 할까요? 확장 단계라면 이 6개월 주기와 구체적인 수치 목표가 문제를 찾아 해결하라는 인센티브를 줍니다.

추출(Extraction) 단계에서는 무슨 일이 벌어질까요? 이제 개선의 폭은 점점 작아집니다. 6개월 안에 고양이 밈 댓글을 4% 올리는 건 불가능합니다. 이제는 0.1% 올리는 게 합리적인 기대치가 됩니다. 몇 가지를 시도해 봅니다. 동시에 프로젝트 기간은 점점 길어집니다. 추출 단계이고 회사가 커졌으니까요.

내 고양이 밈 댓글 목표가 다른 사람의 고양이 밈 '좋아요' 목표와 충돌할 수도 있습니다. 엄지척만 있고 엄지 아래는 없죠. 절대 안 생길 거니까 묻지 마세요. 어쨌든 두 지표가 충돌할 수 있습니다. 0.1%를 얻으려고 애쓰는데 시간은 점점 더 걸리고 6개월 동안 할 수 있는 실험 횟수는 줄어듭니다.

이제 사람들이 시스템을 게임화(악용)하는 게 보이기 시작합니다. 그들은 개선 사항을 내놓으려고 필사적입니다. 만약 정확히 '악한' 건 아니더라도, 자신이 하는 일의 결과를 깊게 생각하지 않고 행동하면 어떻게 될까요? 실험해 보니 성공할 것 같고 코드 리뷰도 통과할 것 같습니다. 자신이 하는 일의 부정적인 면(downside)을 볼 인센티브가 전혀 없습니다.

예를 들어 페이스북 앱에 새로운 기능들이 잔뜩 쌓여서 정말 복잡해지는 걸 보게 됩니다. 기능을 도입하는 모든 사람이 자신의 기능을 모든 사용자에게 배포하고 싶어 하기 때문입니다. 그래야 또 다른 6개월 동안 자신의 존재를 정당화할 수 있으니까요. 인센티브는 모두 그 기능의 장점(upside)에만 맞춰져 있습니다. 명령 팔레트가 점점 길어지는 건 누구의 책임도 아닙니다.

아무도 "내 기능은 좀 미미하고 사람들이 어떻게 쓸지 잘 모르겠으니 배포하지 않겠습니다."라고 말할 인센티브가 없습니다. 페이스북에서는 그게 커리어 자살행위입니다. 인센티브가 오로지 장점을 보는 것에만 맞춰져 있고, 장점의 수익 체감(diminishing returns)은 고려되지 않으며, 아무도 잠재적인 단점, 특히 이 기능과 저 기능이 교차했을 때의 단점을 볼 인센티브가 없습니다.

이 곡선의 어느 시점에서는 '측정 가능한 결과(임팩트)'에 집중하는 것에서 '좋은 의사결정'에 집중하는 것으로 넘어가야 합니다.

"기능이 큰 차이를 못 만들고 옵션만 너무 많게 만드니 배포하지 않겠습니다."라고 했을 때, "정말 좋은 결정입니다. 회사와 사용자, 사회 전체를 위해 옳은 일을 했습니다."라고 말할 수 있어야 합니다.

저는 페이스북이 결코 그 전환을 하지 못할 거라고 생각합니다. 임팩트에 대한 집중이 너무 강하고, 정치적으로 영리한 사람들이 권력을 잡는 것에 대한 두려움이 너무 크기 때문입니다. 임팩트 중심 평가는 말만 번지르르하고 실행은 못 하는 사람들을 막기 위한 거니까요.

하지만 그 이면에는 '유령 개선(Phantom improvements)'들이 있습니다. 6개월마다 수천 개의 기능이 페이스북에 들어갑니다. 개별적으로 보면 어떤 기능이 프라이버시 문제를 일으키거나 파시스트를 당선시킬 확률은 매우 매우 낮습니다. 하지만 기능이 너무 많고 예상치 못한 방식으로 상호작용하며 전 세계 인구의 상당수가 사용합니다. 제 관점에서는 페이스북에 점점 더 많은 문제가 생기는 건 필연적입니다.

구조적으로 이를 해결하기 위해 필요한 개혁, 즉 임팩트 평가에서 의사결정의 질 평가로 넘어가는 것은 절대 일어나지 않을 겁니다. 그게 페이스북이 겪고 있는 일련의 문제들에 대한 제 설명이고, 앞으로도 계속될 거라고 봅니다.

하지만 질문은 여전히 남습니다. "나는 잃을 것이 무엇인가?"

이 질문과 그에 대한 우리의 대응 방식은 제가 소프트웨어 개발뿐만 아니라 다른 많은 것들을 바라보는 방식을 근본적으로 바꿨습니다. 예를 들어 트위터는 저에게 탐험(Explore)의 장입니다. 7년 동안 페이스북에 있다가 나왔더니 제가 관심 있는 주제 중 사람들이 뭘 듣고 싶어 하는지 모르겠더군요.

트위터에서 그걸 탐험합니다. 실험 비용이 매우 저렴하니까요. 생각이 나면 트위터에 올립니다. 명백히 멍청하거나 공격적인 게 아니라면요. 물론 항상 공격적인지 아닌지 아는 건 아니지만 그건 별개의 문제고요. 그냥 시도해 봅니다. 실제로 제가 트윗 한 것에 대한 반응의 크기는 20대 1 정도 차이가 납니다. 많은 것들이 요만큼 반응을 얻다가 가끔 어떤 말을 하면 20배의 반응이 옵니다. 트윗 버튼을 누르는 순간에는 이게 어떤 반응을 얻을지 모릅니다. 예측할 수 없으니 그냥 시도해 봐야죠.

이걸 "동굴에 들어가서 소프트웨어 개발에 관한 책을 신중하게 쓰고 출시했더니 아무도 관심이 없더라"는 상황과 비교해 보세요. 저는 제 아이디어 중 하나에 아무도 관심이 없다는 걸 몇 초 만에 알아낼 수 있습니다. 그 모든 노력을 들이지 않고도요.

제 사운드클라우드 페이지도 마찬가지입니다. 저는 음악가로서 사람들이 듣고 싶어 하는 음악을 연주하고 싶습니다. 사람들이 뭘 듣고 싶어 할까요? 예측할 수 없습니다. 제 최고의 전략은 그냥 폰에서 녹음 버튼을 누르고 이런 노래를 해서 올려보고, 저런 노래를 해서 올려보고 지켜보는 겁니다. 실제로 사운드클라우드에 다른 곡보다 5배 더 많이 재생된 곡이 하나 있습니다. 절대적인 숫자는 정말 작아서 본업을 그만두진 않겠지만요. 본업이 있는 건 아니지만 그건 또 다른 문제고요.

만약 제가 탐험(Explore) 모드라면 분석하고 싶지 않습니다. 어떻게 실험할지를 알아내고 싶습니다. 무언가 성장하고 있다면 성장의 장벽이 뭔지 찾아서 해결하고 다음을 대비하고 싶습니다. 제 경력 중 추출(Extract) 단계에 있는 부분에 대해서는, 어떻게 조금 더 개선할지, 혹은 이 비즈니스를 누구한테 팔아버릴지 생각하고 싶습니다. 저는 추출 단계를 싫어하거든요.

이건 제 개인적인 선호지만, 이 사이클의 어디에 있느냐에 따라 규칙은 바뀝니다. XP(익스트림 프로그래밍)가 저지른 근본적인 실수는 이 질문을 인식하지 못한 채 곡선 전체에 대해 하나의 규칙 세트가 되려고 했다는 점입니다.

테스트를 작성해야 할까요? 상황에 따라 다릅니다(It depends). 잃을 게 없나요? 실험을 더 빨리하게 해주는 테스트만 작성하세요. 'No Estimates(무추정)'의 모든 것에 답할 순 없지만, 탐험 단계에서 'No Estimates'는 훌륭한 아이디어입니다. 안 해봤으니까 추정은 추측일 뿐이고 가치가 없는 낭비니까요. 하지만 추출 단계에 있는데 추정을 안 한다면, 프로젝트 A를 할지 B를 할지 결정하는 데 중요한 정보를 놓치는 겁니다. 꽤 신뢰할 만한 추정을 할 데이터가 있으니까요. 그 데이터와 경험을 사용해서 이것의 ROI와 저것의 ROI를 비교 결정해야 합니다.

이 질문은 제가 소프트웨어 개발을 보는 방식, 커리어 개발을 보는 방식, 청중 개발을 보는 방식을 바꿨습니다. 그리고 그게 진짜 무엇을 의미하는지 저는 여전히 알아가는 중입니다.

준비한 내용은 여기까지입니다. 몇 분 일찍 끝난 것 같네요. 이야기는 훨씬 더 많지만 여러분을 6시간이나 더 붙잡아 둘 순 없으니까요.

(박수)