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

직역

번역 켄트백이 3x에 대해 예를 들어 설명해준다. claude opus 4.5 좀 더 의역은 [gemini 3 pro](https://github.com/juniqlim/note/blob/master/programming/kent/kent-3x-yow-2018-gemini-3-pro.md) --- 정말 감사합니다. 브리즈번에 아부하면서 시드니를 깎아내리는 농담을 준비했는데, 그 타이밍을 빼앗겨서 그걸로 시작할 수가 없네요. 오늘 와주셔서 정말 감사합니다. 점심 후 시간대라는 걸 알고 있습니다. 대중 연설을 많이 해보셨는지 모르겠지만, 이건 연사에게는 벌칙 시간대입니다. 그래서 오늘 제가 뭘 잘못했길래 이 시간을 받았는지 모르겠지만, 어쨌든 여기 있습니다. 오늘 여러분께 말씀드릴 것은 하나의 질문입니다. 제가 물어볼 줄도 몰랐던 질문이죠. 소프트웨어 아이디어와 비즈니스 개발 초기에 이 질문을 던지는 법을 배우고 나서, 제가 무엇을 해야 하고 어떤 순서로 해야 하는지를 바라보는 방식이 완전히 바뀌었습니다. 연사들이 쓰는 트릭이 있죠. 이렇게 미스터리를 소개해놓고 맨 마지막까지 기다렸다가 공개하는 거요. 저는 사람들이 그러는 게 싫어서 그렇게 안 할 겁니다. 하지만 이 질문, 이 첫 번째 질문은 약간의 배경 설명이 필요합니다. 그래서 제가 이 질문을 발견하게 된 사고 과정을 함께 따라가 보겠습니다. 그리고 보너스로, 글쎄요, 보너스가 두 개인 것 같네요. 하나는 이 질문을 바탕으로 익스트림 프로그래밍의 문제점을 말씀드릴 수 있다는 것이고, 두 번째 보너스는 이 질문을 바탕으로 페이스북의 문제점을 말씀드릴 수 있다는 겁니다. 왜냐하면 저는 페이스북에서 7년간 일하면서 이것에 대한 이해를 발전시켰거든요. 올해 2월에 퇴사했습니다. 2011년 1월에 페이스북에 들어갔을 때, 문을 열고 들어가서 발견한 것은 제가 본 것 중 가장 이상한 개발 문화였습니다. 겉보기에는 혼란스러웠어요. 사람들이 무작위로 뭔가를 하는 것 같았는데, 그런데도 작동하고 있었습니다. 새로운 기능, 혁신적인 기능들이 나오고 있었고, 사용자 성장은 계속됐고, 사이트는 전례 없는 엄청난 성장 속에서도 계속 운영되고 있었습니다. 모바일로의 전환은 그 자체로 별도의 강연이 필요한 환상적인 비즈니스 스토리인데, 그 모든 것이 제가 본 적 없는 규모에서 눈 깜짝할 사이에 일어났습니다. 그래서 저는 이 이상하지만 겉보기에 작동하는 업무 문화, 엔지니어링 문화를 보면서 생각했습니다. 내가 해야 할 일은 먼저 도대체 무슨 일이 벌어지고 있는지 이해하는 것이다. 이걸 보존해야 한다. 왜냐하면 언젠가는 평균 회귀가 작동할 것이기 때문이다. 그 시점에 페이스북은 직원 2,000명에 엔지니어 700명이었습니다. 더 표준적인 엔지니어링 스타일로 돌아가려는 힘이 매우 강할 것이므로 이걸 이해하고, 보존하고, 강화해야 합니다. 왜냐하면 엄청난 성장이 있을 것이기 때문입니다. 실제로 제가 떠날 때쯤에는 엔지니어가 5,000명이고 총 직원이 약 25,000명이었으니, 그 기간 동안 회사가 엄청나게 성장한 거죠. 저는 페이스북 내에서 이 미친 엔지니어링 문화를 보존하고 강화하고 설명하려는 미션에서 몇 가지 성공도 있었고 몇 가지 실패도 있었습니다. 그래서 거기 도착해서, 페이스북에서 제일 먼저 하는 게 부트캠프를 거치는 겁니다. 페이스북에 채용되면 특정 팀에 배정되는 게 아니라, 엔지니어로서 그냥 엔지니어 풀에 들어갑니다. 그리고 처음 6주 동안 작은 diff를 만들고, 여기저기 작은 버그를 고치고, 수십억 명의 사람들에게 프로덕션에 코드를 푸시합니다. 정말 담력 테스트죠. 첫 번째 푸시, 아휴, 그건 절대 잊지 못할 겁니다. 저는 제 첫 번째 diff가 들어갔을 때 IRC에 메시지가 뜨는 걸 본 기억이 납니다. 메시지가 뜨길, "릴리스 뭐시기 L7이 6,400대 서버 중 6,300대에 성공적으로 푸시됨." 저는 패닉에 빠졌어요. 그래서 옆 사람한테 갔죠. "나머지 100대 서버에는 뭐가 있어요?" "별 문제 안 일으키는 것 같은데요." 그게 제가 스케일에 대해 받은 첫 인상이었습니다. 항상 뭔가가 잘못되고 있고, 전체가 계속 운영되는 한 실제로 괜찮습니다. 제가 어느 정도 명성을 쌓았던 이 레드-그린 것 있잖아요, 100대의 서버에서 무작위 뭔가가 돌아가고 있는데 문제가 아닌 상황에서는 그렇게 단순하고 직접적으로 적용되지 않습니다. 그게 레드인가요 그린인가요? 이건 그린-ish입니다. 충분히 좋습니다. 하지만 그건 또 완전히 다른 이야기고, 제가 좀 앞서나가고 있네요. 그래서 거기 도착했고요. 아시다시피 저는 이름 있는 사람이고, 시니어 엔지니어입니다. 페이스북 엔지니어링에 제 흔적을 남기고 싶었는데, 주변에는 온통 이 애들이 무작위로 뭔가를 하고 돌아다니고 있었습니다. 그래서 생각했죠, 우리 해커톤이 있었고, 해커톤 일부로 수업을 신청해서 강의할 수 있었습니다. 아, 이거 환상적이겠다, 페이스북 엔지니어링에 제 흔적을 남기려면 테스트 주도 개발 수업을 하면 되겠다. 결국 저한테 TDD 수업 듣기 싫은 사람이 어디 있겠어요? 좋은 생각 같았죠. 신청 목록에서 제 수업 바로 전 수업은 '고급 엑셀 기법'이었고, 제 수업 바로 다음 수업은 '아르헨티나 탱고'였습니다. 수업 시간이 됐을 때, 엑셀 수업은 대기자 명단까지 완전 만석이었습니다. 아르헨티나 탱고 수업도, 뭐가 올지 아시죠? 아르헨티나 탱고 수업도 대기자 명단까지 완전 만석이었고, 제 수업에 신청한 사람은 정확히 0명이었습니다. 저요. 어떻게 해야 하지, 아무도 내 말을 안 들으려 하는데 어떻게 페이스북 엔지니어링에 제 흔적을 남기지? 그때 제 경력에서 가장 무서운 결정을 내렸습니다. 제가 성공하는 유일한 방법은 소프트웨어 엔지니어링에 대해 알고 있는 모든 것을 잊고, 왼쪽 사람과 오른쪽 사람이 뭘 하고 있는지 보면서 처음부터 다시 배우는 것뿐이라는 걸 깨달았습니다. 이거 테스트가 필요하죠? 당연히 테스트가 필요하죠. 음, 분명히 테스트가 필요 없대요. [웃음] 누가 알았겠어요. [웃음] 이건 작은 diff 여러 개인가요 아니면 큰 diff 하나인가요? 큰 diff 하나, 정말 정말... 아, 네. 등등등. 그래서 "저는 전문가니까 여러분한테 뭘 해야 하는지 알려드리겠습니다"—라고 했으면 해고당했을 텐데—대신 그냥 그들 방식대로 해보면서 얼마나 빨리 배울 수 있는지, 그리고 정말로 첫 6개월 안에 해고당하지 않을 만큼 충분히 배울 수 있는지 보기로 했습니다. 결국 저는, 숫자를 맞게 말할 수 있을지 모르겠는데, 매니저와 370번의 주간 1:1 미팅을 해고당하지 않고 했습니다. 세어봤어요. 거의 매주 좀 불안했지만, 결과적으로 잘 됐습니다. 그래서 거기서 첫 1년 정도를 코드 작성하면서 보냈습니다. 그리고 배운 것 중 하나, 다시 상기하게 된 것 중 하나는 C++가 싫다는 거였습니다. 특히 주변 사람들에 비해 그냥 코드만 작성하는 건 그렇게 성공적이지 못했습니다. 그래서 새로운 일을 찾아야 했고, 다른 뭔가를 해야 했습니다. 제 친구 피터 드모프가 제안하길, 네가 하는 코칭 얘기를 했잖아, 내부적으로 사람들을 코칭해보는 게 어때? 그래서 'Good to Great'라는 코칭 프로그램을 시작했는데, 엔지니어와 12세션 동안 만나는 겁니다. 한 시간 대화였고, 250년 전쯤인지 뭔지 테크 랩스에 있을 때 워드 커닝햄과 나눴던 대화를 모델로 했습니다. 그런 종류의 대화를 못 보고 있어서, 엔지니어들이 더 빨리 성장할 수 있는지 그런 대화를 해보자고 생각했습니다. 글쎄요, 그 대화가 엔지니어들에게 매우 도움이 됐다는 게 밝혀졌습니다. 좋은 소식이죠. 나쁜 소식은 페이스북은 매우 지표 중심 문화라서, 추천서를 인쇄한 페이지 수는 잘 전달되는 지표가 아니라는 겁니다. 말 그대로 평가 기간 끝에 저는 학생들과 그들의 매니저들로부터 온 종이 더미를 갖고 있었는데, 그 코칭 과정이 얼마나 환상적이었고 얼마나 변혁적인 과정이었는지에 대한 것이었지만, 추천서 인쇄 페이지 수로 진척을 측정하는 사람은 아무도 없었어요. 그래서 저만 그랬죠. 그리고 아마 3년 정도 코칭을 하고 나서야, 충분한 학생과 충분한 이력이 쌓여서 HR이 돌아가서 제 학생들을 동료들과 비교하고 모든 가능한 변수를 통제한 후에 볼 수 있었습니다. 제 학생들은 코칭 후 1년 이내에 승진할 확률이 동료들의 두 배였습니다. 자, 이건 사람들이 관심 갖는 지표입니다. 승진 속도. 그러니까 주어진 해에 승진할 확률이 5%라면, 저한테 코칭을 받으면 이제 10% 확률로 승진하는 거죠. 그건 큰 차이입니다. 측정 가능하고, 사람들에게 큰 차이를 만듭니다. 그 일의 장점 중 하나는 페이스북 코드베이스의 모든 것을 볼 수 있었다는 겁니다. 많은 다른 팀들이 어떻게 일하는지 볼 수 있었고, 발견한 것은 다른 팀들이 매우 다르게 일한다는 것이었습니다. 그래서 맞아요, UI 개발자들은 제가 이해하는 방식으로는 자동화된 테스트를 많이 안 쓰고 일했습니다. 리눅스 커널 팀은 제가 작성하고 예상했을 것보다 훨씬 더 많은 테스트를, 다른 종류의 테스트를 가지고 있었습니다. 그래서 맞아요, 혼란스러웠지만 일관성 없이 혼란스러웠고, 일관성 없는 혼란의 특징은 패턴이 있다는 겁니다. 아직 못 봤을 뿐이죠. 혼란, 혼란은 그냥 혼란입니다. 하지만 사람들이 실제로 진짜 동전을 던지지 않으면서 실제 혼란을 유지하기는 정말 어렵습니다. 어딘가에 패턴이 있을 겁니다. 좋아요, 그래서 페이스북에서 대부분의 시간을 엔지니어 코칭에 썼습니다. 결국 총 약 200명의 엔지니어를 코칭했고, 수천 명이 더 수강한 수업을 작성했고, 코칭 훈련을 받은 시니어 엔지니어와 주니어 엔지니어를 연결하는 코칭 프로그램을 운영해서 수백 명의 엔지니어를 더 코칭했습니다. 그래서 좋은 성과였습니다. 제 경력에서 항상 해온 것 중 하나는 언제나 머릿속에 여러 아이디어가 끓고 있다는 겁니다. 뭐가 튀어나올지 모르니까, 그냥 많은 것들이 로드되어 있기를 원합니다. 그리고 몇 년 전에, EconTalk이라는 팟캐스트를 들었습니다. 여기 EconTalk 청취자 있나요? 재미있어요, 경제학이 재미있어요. 보통 이 두 단어를 함께 쓰지 않죠. 그들이 나심 탈레브와 대화하고 있었고, 그가 지적한 것은 두 가지 보상 스타일 사이에 큰 차이가 있다는 것이었습니다. 불행히도 그는 이것을 볼록(convex)과 오목(concave)이라고 부르는데, 정말 어렵습니다. 이걸 이해하는 데 6년 걸렸어요. 곧 보여드리겠습니다. 그래서 좋은 이름은 아니지만, 본질적인 차이는 이겁니다. 작은 투자를 하고, 대부분의 경우 모든 것을 잃지만, 가끔 큰 보상을 얻는다면, 이것을 볼록(convex)이라고 합니다. 볼록한 세상에서는 많은 베팅을 하고 싶습니다. 대부분이 성과를 내지 않을 것이고, 아무 보상도 없는 상황에 처하고 싶지 않기 때문입니다. 그러면 사업에서 밀려나게 되니까요. 같은 돈으로 더 많은 실험을 할 수 있다면, 큰 개선을 이룬 겁니다. 왜냐하면 이런 큰 보상을 얻을 확률을 바꾼 거니까요. 그리고 이것이 볼록이라고 불리는 이유는—이걸 이해하는 데 6년 걸렸어요, 저는 공간 추론을 정말 못해요—여기 작은 사람을 그리고, 그 사람이 이 방향을 보면 이 곡선이 그들에게 볼록합니다. 이해되시죠? 저는 이거 알아내는 데 6년 걸렸어요. 여러분은 저보다 훨씬 똑똒합니다. 좋아요, 볼록한 세상에서는 특정 종류의 행동이 합리적입니다. 이것과 대비되는 세상은, 매우 큰 투자를 하고, 대부분의 경우 작은 보상을 얻지만, 가끔 많은 돈을 잃는 세상입니다. 이것이 오목(concave)한 세상입니다. 오목한 세상에서는 이 보상을 조금만 올리고 싶습니다. 왜냐하면 그것이 이 곡선의 보상에 큰 차이를 만들기 때문입니다. 그리고 완전한 실패의 확률을 줄이고 싶습니다. 왜냐하면 정말 비싼 것은 그 실패의 순간들이니까요. 그리고 다시, 여기 작은 사람을 그리고 이 방향을 올려다보면 오목한 곡선입니다. 6년 걸렸어요. 세상에. 볼록한 세상에 있는지 오목한 세상에 있는지 구별하는 것은 매우 중요합니다. 잃을 것이 없으면 한 가지 방식으로 행동합니다. 잃을 것이 많으면 먼저 그것을 잃지 않으려 하고, 가능하다면 조금 강화하려 합니다. 두 가지 사이에 매우 다른 마인드셋이 있습니다. 그래서 이 팟캐스트를 듣고, 작은 사람이 어디 서 있는지 알 수가 없어서 여전히 어느 게 어느 건지 혼란스러웠습니다. 하지만 그걸 머릿속 뒤에 넣어뒀습니다. 그래서 그게 돌아다니고 있었습니다. 곧 말씀드릴 이 질문의 두 번째 트리거는 폭포수의 귀환이었습니다. 폭포수의 귀환을 보셨나요? 여기서 최근에 사람들이 "먼저 정확히 무엇을 할지 설계합시다"라고 실제로 주장하는 것을 본 사람? 네. 호주는 욕하는 곳 맞죠? 씨[발] 봤거든요— 더 이상 욕 안 할게요, 약속해요. 아마도. 하지만 정말 다른 어떤 반응이 적절하겠어요? 정말 똑똑한 사람들이 주장하는 걸 봤어요. 그들은 폭포수라고 부르지 않았어요. "시작하기 전에 철저한 시장 조사를 합시다. 시작하기 전에 환경을 이해하고 싶으니까요. 그리고 나서 신중한 비즈니스 모델 개선을 할 거예요. 그리고 나서 제품이 정확히 어떻게 될지 그릴 거예요. 그리고 나서 구현 뭐시기가 있는데, 그건 프로그래머들이 하는 거고. 그리고 나서 유일한 개선은 사용자가 테스트하는 거예요." QA는 없어요, 맞죠. 새로운 세상이니까. 하지만 테스트 없는 폭포수예요. 저도 그런 반응이었어요. "이건 폭포수야. 잘 알려진 이유로 작동 안 해." 30살의 켄트와 50살의 켄트의 차이는, 30살의 켄트는 "저 바보들"이라고 했을 거예요. 50살의 켄트는 "음... 저 바보들, 하지만... 음, 뭐가 일어나고 있는 거지?"라고 했어요. 그리고 이 두 아이디어를 기억했어요, 맞죠? 아이디어는 보통 두 아이디어가 부딪혀서 나오죠. 새로운 아이디어는 없지만 아이디어의 새로운 조합은 있어요. 그래서 볼록과 오목 곡선의 기억이 있었고, 생각했어요, "오." 이 폭포수 스타일 것들은 오목한 상황을 다루려는 시도구나. 그 모든 신중하고 사려 깊은 분석은 잃는 것을 피하려고 있는 거야. 이기는 것을 최대화하려는 게 아니야. 작동은 안 해요. 피드백 때문에. 하지만 그 스타일의 개발을 주장하는 사람들은 바보가 아니에요. 그들은 실제로 제 영역에 없는 문제를 해결하고 있는 거예요. 저는 새로운 아이디어를 탐험하는 걸 좋아해요. 아이디어에 대한 제 작업이 끝났다는 걸 아는 건 누군가가 처음으로 "음, 그거 될 수도 있겠네요"라고 말할 때예요. 그게 그 아이디어에 대한 제 참여의 끝이에요. 내려놓고 다음 것으로 가야 해요. 모두가 "아니, 이건 미친 짓이야, 이건 절대 안 될 거야, 아빠"라고 하는 곳으로요. 그 순간 제가 제 영역에 있는 거예요. 저는 이 볼록한 세상 깊숙이 있어요. 그냥 그 미친, 미친 아이디어들이 너무 좋아요. 여담으로, 이 스타일의 신제품 개발은 볼록도 오목도 아니에요. 큰 투자를 하고 이런 종류의 보상이에요. 그래서 작동을 안 해요. 아주 작은 보상의 아주 작은 확률이 있어요. 폭포수 스타일로 개발하려 하면. 그래서 그게 제가 시드니에서 연습 발표를 한 후에 떠올랐어요. 그래서 여기서 좋은 걸 드릴 수 있는 거예요. 좋아요, 약간의 아부, 약간의 아부만요. 좋아요, 저 두 곡선을 보여드렸고, 볼록한 세상에서 어떻게 개발하는지 대 오목한 세상에서 어떻게 개발하는지에 대해 얘기하기 시작했습니다. 페이스북에서 정말 이상한 영상들을 볼 수 있는데요, 옆머리는 정말 길고 윗머리는 없는 저가 나무집 꼭대기에 있는 거예요. 긴 이야기예요. 하지만 염소가 나와요. 아마 돌아오게 될 거예요. 이것에 대해 얘기하기 시작했는데, 여기 있는 제 친구 티아고가 말했어요, "있잖아, 그 곡선들을 합칠 수 있을 것 같아." 생각했죠, "오, 음..." 그리고 합쳤어요. 그리고 이 질문이 머릿속에 떠올랐습니다. 질문은 이겁니다: 잃을 것이 무엇인가? 제가 어떻게 운영할지 결정할 때 먼저 물어봐야 할 첫 번째 질문입니다. 잃을 것이 무엇인가? 그리고 이건 합당한 질문이에요. 가끔은 잃을 것이 없고 한 가지 방식으로 행동해야 해요. 하지만 잃을 것이 많으면 매우 매우 다른 방식으로 행동해야 해요. 이렇게 진행됩니다. 저는, 새로운 가치의 원천을 찾고 있다고 합시다. 그래서 실험을 해봐요. 안 돼요, 하지만 뭔가 배워요. 다른 실험을 해봐요. 여전히 안 돼요. 다른 것을 해봐요. 안 돼요. 다른 것. 또 다른 것. 또 다른 것. 그리고 방금 했던 다른 모든 실험과 똑같이 생긴 실험을 해봐요. 하지만 어떤 이유에서인지 사람들이 제가 방금 한 것에 완전히 다르게 반응해요. 제 경력에서 이것의 예는 JUnit이에요. 이 이야기는 여러 번 했는데요. 에릭 감마와 저는 비엔나에서 비행기를 타고 워싱턴 DC로 날아가서 애틀랜타의 OOPSLA에 가고 있었어요. 그는 자바를 알았고, 저는 xUnit을 알았어요. 배터리가 다 닳을 때까지 프로그래밍할 거였어요. 잘 됐어요. 착륙했을 때 우리가 만든 것을 마틴 파울러에게 건넸어요. 다음 날 30명이 이 프로그램 사본을 간절히 받으려고 우리를 찾아다녔어요. 이건 정상적인 행동이 아니었어요. 우리 각자는 많고 많은 프로그램을, 알다시피 3시간 분량의 프로그램을 작성했었어요. 이번이 사람들이 이 프로그램을 손에 넣으려고 요구한 처음이었어요. 탐험은 그런 거예요. 이것 해보고, 저것 해보고, 조금 배우고, 조금 해보고, 다른 것 해봐요. 그리고 나서 다른 모든 것과 겉보기에 똑같은 뭔가를 해요. 하지만 이 성장 루프 중 하나를 찾은 거예요. 탐험의 목표는 이 강화 루프를 찾는 겁니다. 더 성장할수록 더 성장하기 쉬워지는. 그래서 고전적인 예는 전화 교환기예요. 전화 교환기에 연결된 사람이 많을수록 다음 사람이 교환기에 연결되는 것이 더 가치 있어져요. 그게 성장 루프예요. 탐험은 그런 새로운 성장 루프를 찾는 것이에요. 그리고 그건 합리적인 과정이 아니에요. 예측할 수 없어요. 다음 루프가 어디 있을지를. 왜냐하면 예측할 수 있다면 누군가가 이미 했을 거고, 돈 많은 누군가가 이미 했을 거고, 당신은 운이 없는 거예요. 그래서 두 개의 미친 아이디어를 합쳐봐야 해요. 알다시피, 메시징 시스템을 만들자, 그리고 모든 메시지를 영원히 저장해서 검색 가능하고 가치 있게 만드는 대신 24시간 후에 모든 메시지를 버릴 거야. 이건 메시징 시스템으로는 가장 멍청한 아이디어야. 스냅챗이죠? 그들은 그 두 아이디어를 합쳤어요. 와, 어떤 이유에서인지 그게 뜨었어요. 그래서 탐험에서는 이것저것 시도해요. 종종 뜨는 아이디어는 터무니없을 거예요. 웃음은 탐험에서 정말 좋은 신호예요. "하하하, 알다시피, 그것만 뽑아내서 다른 것으로 바꿀 수 있다면"이라고 하고 모두가 "아하하하"라고 해요. 그리고 나서 이런 긴장된 순간이 있죠, "음, 그거 얼마나 어려울까?" 그게 탐험의 핵심 질문이에요. 시도하는 게 얼마나 어려울까? 이 미친 아이디어들을 시도해봐야 해요. 왜냐하면 미친 아이디어처럼 보이지만 미친 아이디어가 아닌 것으로 밝혀지면, 독특한 가치를 가지게 되니까요. 다른 아무도 나쁜 아이디어의 경쟁자가 될 만큼 멍청하지 않으니까요. 우! 물론 많은 나쁜 아이디어를 시도해보고 버려야 해요. 하지만 그래서 "이걸 시도하는 게 얼마나 싸겠어?"라는 질문이 들어오는 거예요. TDD. 멍청한 아이디어. 확실히 멍청한 아이디어. 테스트가 통과하기를 원해, 왜 코드를 작성하기 전에 테스트를 작성해, 확실히 실패할 거라는 걸 알 때? 그냥 기다려, 진정해 이 친구야, 이건 멍청해. 코드가 작성될 때까지 기다렸다가 테스트를 작성해. 왜 뛰어들어? 글쎄요, 밝혀진 바로는 코드를 작성하기 전에 테스트를 작성해야 할 좋은 이유가 많아요. 하지만 그건 제가 말 그대로 큰 소리로 웃은 것 중 하나였어요. 이 뒤집기에 대해 생각했어요. 그거 시도하는 게 얼마나 어려워? 30분 걸렸고, "오"라고 했어요. 코드가 정말 여전히 작동하는지에 대한 그 모든 불안, 다음 단계에 뭘 할지, 이 모든 것을 한꺼번에 어떻게 구현할지... 오 그래, 이 모든 걸 구현할 필요가 없구나. 아. 정말 잘 됐어요. 하지만 웃음으로 시작했어요. 그래서 그게 탐험이에요. 탐험은 게임이에요. 규칙이 있어요. 특정한 트레이드오프 세트가 있어요. 많은 장기-단기 트레이드오프가 단기 쪽으로 기울어요. 아시죠, 이거? 이게 트레이드오프의 국제 갱 사인이에요. 말 그대로 팔로알토에 이렇게 하면서 거리를 걸어갈 수 있는 곳이 있어요 [손을 양쪽으로 기울이는 동작]. 그러면 사람들이 [끄덕임] "그래, 우리 쿨해." 좋아요, 그래서 트레이드오프가 모두 단기 쪽으로 균형을 이뤄요. 그래서 더러운 핵들이 탐험에서 칭송받아요. 왜냐하면 지속 가능성은 신경 안 쓰니까요. 어차피 버릴 거니까요. 버리지 않으면 너무 가치 있어서 신경 안 써도 되는 거예요. 그게 탐험이에요. 하지만 이제 뭔가를 했고 그게 폭발해서 전에 했던 어떤 것보다 훨씬 커졌다고 합시다. 게임이 바뀌어요. 트레이드오프가 바뀌어요. 전에 탐험에서 상대는 무관심이었어요. 아무도 당신의 아이디어에 관심 없어요. 오, 이제 사람들이 아이디어에 관심을 가져요. 이제 질문은 확장이에요. 이걸 충분히 빨리 키울 수 있나? 그리고 말했듯이 게임이 바뀌고, 이제 성장에 대한 장벽을 만나기 시작해요. 오, 돈이 떨어지고 있어. 자금을 조달해, 됐어. 이제 사무실 공간이 부족해. 이제 충분히 빨리 채용할 수 없어. 이제 네트워크 대역폭. 이제 다른 뭔가. 이제 뭔가 다른 것, 알다시피, 됐어. 확장의 특징은 각각의 위기가 존재론적이라는 거예요. 그래서 이건 헤라클레스와 일곱 가지 과업 같아요. 헤라클레스와 공주가 함께하고 싶어해요. 아빠 왕이 말해요, "절대 안 돼, 헤라클레스야 일곱 가지를 해야 해, 다 불가능한 것들이야. 하나라도 놓치면 공주 없어." 확장이 그래요. 그 곡선을 아주 멀리 올라갈 수 있어요. 마지막 테스트에 실패하고 미친 듯이 성장하는 것처럼 보였는데도 성공적인 사업을 갖지 못해요. 지속 가능한 사업으로 코너를 돌지 못한 거예요. 그래서 탐험에서는 범위의 경제에 관한 거예요. 어떤 질문을 검증하기 위해 얼마나 적은 일을 할 수 있을까? 이걸 저것으로 바꾸면 사용자가 어떻게 행동할까? 좋아, 시계가 째깍거려. 그 질문에 대한 경험적 답을 얼마나 빨리 얻을 수 있을까? 확장은 위험의 경제에 관한 거예요. 그래서 갑자기 돈이 충분해요. 매월 100% 사용자 성장을 보고 있고, 2주 전에는 전화도 안 받았을 벤처 캐피탈리스트들이 기꺼이 돈을 쏟아부어요. 자본은 갑자기 싸지만 위험은 정말 비싸요. 그래서 확장에서 위험을 줄이기 위해 할 수 있는 모든 것을 해요. 그게 돈을 문제에 던지는 것을 의미한다면 괜찮아요. 왜냐하면 결국 벌게 될 것이 확장에서 취하는 모든 지름길에 대해 확실히 지불할 거니까요. 확장은 그 자체의 엔지니어링 분야예요. 페이스북에는 전체 일이 점심시간에 카페테리아에서 듣는 것으로 이루어진 사람들 그룹이 있었어요. 누군가 다루기 힘든 기술적 문제에 대해 얘기하는 걸 들으면 걸어가서 "오, 이 랙 스위치에 대해 알아야 할 모든 것을 알고 있는데, 당신의 랙 스위치가 왜 불이 나는지 더 말해줘요." 그래서 그들은 갈 거예요, 그들은—가끔 진짜 불이에요—불에서 불로 갈 거예요. 그들의 기술적 마법을 적용해서 성장의 장벽, 기술적 성장의 장벽을 통과해요. 하지만 다른 분야예요. 다른 엔지니어링. 다른 분야. 다른 관리 분야예요. 탐험은 모두 학습과 창의성과 공간의 커버리지에 관한 거예요. 확장은 다음에 당신을 죽일 것을 찾는 것에 관한 거예요. 왜냐하면 뭔가가 당신을 죽일 거니까요. 그리고 그것이 그렇게 하지 않도록 확인하는 것. 그리고 나서 다음에 당신을 죽일 것을 찾는 것. 왜냐하면 연속으로 오니까요. 이 전환을 했다는 것을 눈치채지 못하면 정말 안 좋은 날을 보내게 될 거예요. 왜냐하면 계속 실험하고 이것저것 느슨하게 해볼 거니까요. 한편 시스템은 실패하고, 사용자는 불행하고, 다른 곳으로 가고, 환상적인 기회를 잃은 거예요. 그래서 약간 축구를 시작하는 것 같아요. 공을 차고 있어요. 마침내 게임의 규칙을 알아냈어요. 상대가 뭔지 알아냈어요. 검은색과 흰색 줄무늬를 입은 사람이 휘슬을 불고 이 이상한 타원형 공을 들고 나오고, 크고 털이 많고 땀에 젖은 녀석들이 나와요. 럭비 공이 필드에 있고 럭비 팀이 상대일 때 축구를 계속하면 잘 안 될 거예요. 탐험에서 확장으로의 전환을 하지 않으면 그렇게 돼요. 이전 게임을 이전 전략으로 하면서 성공할 수 없어요. 확장은 매우 집중돼요. 짧은 기간이에요. 그때가 추가 시간이 차이를 만드는 때예요. 그때가 같은 방에 앉아 있는 것이 큰 차이를 만드는 때예요. 전체 프로젝트 시간으로는 많지 않아요. 큰 비율이 아니에요. 하지만 그때가 모두가 같은 페이지에 있고, 같은 문제를 작업하고, 상황을 같은 방식으로 이해해야 하는 때예요. 좋아요, 여섯 가지 다른 방식으로 죽음을 피했다고 합시다. 그리고 이제 시간이 됐어요. 이제 우리는 예측을 시작할 수 있어요. "오, 우리가 추가하는 모든 사용자는 이만큼의 서버가 더 필요할 거야"라고 말할 수 있고, 예측을 시작할 수 있어요. 그리고 이제 다시 게임이 바뀌어요. 가치를 추출하기 시작해요. 계속 성장해요. 하지만 더 질서 있고 예측 가능한 방식으로요. 그래서 계속 성장하고, 여기서 플레이북이 있어요. 알다시피, "좋아, 20번째 나라에 제품을 소개할 거야." 플레이북이 있어요. 실행에 관한 거예요. 문제가 뭔지 알아야 하고, 무자비하게 실행해야 해요. 왜냐하면 뭘 실행해야 하는지 아니까요. 다시 말하지만, 그 제약 조건 세트는 매우 달라요. 여기서 장기가 들어와요. 여기서 리팩토링이 엄청 가치 있어요. 여기서 자동화된 테스팅이 결실을 맺어요. 왜냐하면 장기적 보상이 실현될 장기가 있으니까요. 하지만 다시 말하지만 매우 다른 스타일의 엔지니어링, 다른 스타일의 관리, 그냥 다른 스타일의 재무예요. 여기서 KPI가 들어와요. KPI는 추출에서 정말 말이 돼요. 왜냐하면 많은 데이터가 있고, "당신의 일은 월요일에 출근해서 금요일까지 이 숫자가 4% 올라가야 해요"라고 말하고 맞을 수 있으니까요. 탐험에 있다면 KPI에 맞춰 일하는 건 전혀 말이 안 돼요. 숫자가 뭔지도 몰라요. 올라가거나 내려가야 할 합리적인 양이 뭔지는커녕요. 페이스북에서 추출 팀 안에서 탐험을 하는 팀들과 얘기했어요. 모두 매우 지표 중심이었고, 그들이 말하길, "미쳤어요, 왜냐하면 제 프로젝트는 지표에 전혀 진전이 없거나 약속한 것의 100배만큼 진전이 있거나 둘 중 하나예요. 정말 이분법적이에요." 탐험은 이분법적이에요. 확장은 이 숫자를 개선하지 않으면 우리를 죽일 하나의 숫자가 있어요. 그리고 추출은 균형 잡힌 스코어카드를 가질 수 있고, 지속적인 진전을 이룰 수 있는 곳이에요. 좋아요, 이 곡선을 한 번 거쳐서 성공했다고 합시다. 이제 까다로운 부분이 시작돼요. 까다로운 부분은 같은 조직에서 탐험 프로젝트와 추출 프로젝트를 동시에 운영할 수 있느냐예요. 이게 페이스북이 2011년경 제가 도착했을 때 환상적으로 잘 한 거예요. 매니저로서는 "좋아, 모두 KPI가 있고 다 같은 방식으로 평가될 거야"보다 더 복잡해요. 축구 경기와 럭비 경기에 대해 하나의 통계 세트를 가질 거예요? 말이 안 돼요. 다른 게임이에요. 다른 상대예요. 다른 구조예요. 다른 트레이드오프예요. 축구 팀과 럭비 팀의 플레이를 향상시키는 데 의미가 있는 단일 지표 세트를 만들 수 없어요. 말이 안 돼요. 페이스북이 한 세 번째 것, 그러니까 이게 볼록한 부분인 탐험이고, 추출이 오목한 부분이고, 페이스북이 정말 잘 한 또 다른 것은 떠다니는 이 확장자들 그룹이 있었다는 거예요. 초기 사람들 몇 명과 얘기하고 이 모델을 검토했는데, 그들이 말하길, "네, 저는 확장자였어요. 아무도 이 장비에 이런 걸 시도해본 적 없는 상황에 뛰어드는 게 너무 좋았어요. 벤더도 뭐가 일어나는지 전혀 모르는 방식으로 실패하고 있었고, 저는 그걸 고친 마법사였어요. 그리고 다시 하곤 했어요." 그래서 확장 프로젝트가 모든 것을 이겨요, 맞죠. 탐험에서는 큰 보상의 작은 확률이 있어요. 추출에서는 작은 보상의 큰 확률이 있어요. 확장에서는 큰 보상의 큰 확률이 있어요. 오래 지속되지 않아요. 기회를 놓치면 사업으로서 소프트웨어 개발에서 가장 가치 있는 부분을 놓친 거예요. 그래서 당신이 추출자라고 합시다. 백만 달러를 받고 회사에 천만 달러를 돌려줄 거예요. 모두가 "오, 환상적이다"라고 생각해요. 그러다가 어떤 새 기능이 모든 것을 망가뜨리는 날이 와요. 그리고 매니저가 당신에게 격려하며 말해야 해요, "당신은 저것에 가서 일해야 해요." 페이스북 스타일에서는 그냥 "저것에 가서 일할 거야"라고 말할 거예요. 다른 누군가가 회사를 위해 9백만 달러를 만드는 걸 채워야 해요. 하지만 다른 누군가가 해야 해요. 그 새 기능에 수익이 붙어 있지 않더라도, 큰 돈을 벌지 않더라도, 뭔가가 폭발하고 있다는 사실만으로 거기에 잠재력이 있다는 뜻이에요. 그래서 조직은 작은 자본으로 탐험 프로젝트를, 엄격한 회계 ROI와 많은 지표로 추출 프로젝트를 운영해야 해요. 그리고 뭔가가 빠르게 성장하기 시작하면 그 확장을 도울 수 있는 누구든지 다른 책임이 뭐든 상관없이 뛰어들어야 해요. 그건 관리하기 정말 복잡한 환경이에요. 하지만 지난 15년간 가장 큰 사업 기회 위에 앉아 있다면, 그게 제가 본 유일한 방법이에요. 혁신하고 실행을 동시에 계속할 수 있는. 그게 페이스북 개발이 그렇게 오랫동안 그렇게 큰 규모에서 효과적으로 작동하게 만든 거예요. 다른 프로젝트들이 매우 매우 다르게 취급됐다는 거예요. 이제 당신은 페이스북이 될 수 없어요. 페이스북이 되고 싶지도 않을 거예요, 지금은. 몇 년 전에는 아마 페이스북이 되고 싶었을지 모르지만, 지금은 아무도 페이스북이 되고 싶어하지 않아요. 그래서 여기 이것이 어떻게 잘못됐는지에 대한 설명이 있어요. 이건 제 설명이에요. 저는 혼란스러운 것을 보면 이해하고 싶어해요. 그게 제가 하는 일이에요. 가끔 맞고 가끔 그냥 이해가 되는 것뿐이지만 좋은 설명은 아니에요. 하지만 이게 제가 생각하는 방식이에요. 페이스북에서는 모두가 임팩트로 관리돼요. 당신의 숫자는 뭐야? 다음 6개월 안에 얼마나 올라가야 해? 6개월 시작에 "좋아, 고양이 밈 댓글을 3% 늘릴 거야"라고 말해요. 좋아, 뭔가 시도해요. 그리고 고양이 밈 댓글을 4% 늘려요. 그러면 당신은 정말 좋은 사람이에요. 2%만 늘렸어요, 그렇게 좋지 않아요. 전혀 늘리지 못했어요, 심각한 대화가 있어요. 그게 모델이에요. 수치 목표가 있고 6개월 안에 달성해야 해요. 페이스북 전체가 탐험과 확장에 있을 때 이건 많이 말이 됐어요. 그 스타일의 개발, 관리, 성과 검토는 탐험에서 많이 말이 돼요. 그게 의미하는 건 인센티브가 이걸 더 좋게 만들기 위해 작은 것들을 여러 개 시도하라는 거예요. 그리고 매주 실험할 수 있는 한 뭔가는 될 거예요. 당신이 하는 뭔가는 될 거예요. 그래서 목표를 달성하거나 초과할 좋은 확률이 있어요. 알다시피, 있을 수 있는 가장 좋은 위치는 첫 달 끝에 4%를 얻는 거예요. 그러면 미쳐 날뛰며 정말 야생적인 것을 시도할 수 있어요. 그래서 모두의 관심을 기회에 집중시키는 데 잘 작동해요. 이제 확장으로 가요. 다시 이런 종류의 임팩트 집중이 정말 잘 작동해요. 여러분 모두가 그 병목을 찾기를 원해요. 성장을 죽일 다음 것을 찾기를. 그들이 나가서 적극적으로 "글쎄, 이게 성장하고 있었고 우리 용량을 초과할 예정이었는데 성장률을 낮췄고 해냈고 1억 달러를 절약했어요."라고 말해요. 환상적이죠. 다시 이 우선순위 문제가 있어요. 백만 가지가 진행되고 있어요. 확장하고 있다면 모두가 가장 중요한 할 일을 찾게 하려면 어떻게 해요? 이 6개월 주기와 특정 수치 목표가 해결할 문제를 찾을 인센티브를 줘요. 추출에서는 무슨 일이 일어나요? 이제 그 개선이 점점 더 작아져요. 이제 고양이 밈 댓글을 6개월 안에 4% 늘리는 게 불가능해요. 이제 0.1%만 올라갈 거라고 기대하는 게 합리적일 수도 있어요. 그래서 몇 가지를 시도해봐요. 동시에 프로젝트는 점점 더 길어지죠? 추출에 있어요. 회사가 더 커요. 당신의 고양이 밈 댓글이 다른 누군가의 고양이 밈 좋아요와 충돌할 수 있어요. 엄지 척, 엄지 아래는 없어요. 절대 엄지 아래 없을 거예요. 그만 물어보세요. 알다시피, 당신의 두 지표가 충돌할 수 있어요. 그래서 플러스 0.1%를 얻으려 하고, 플러스 0.1%를 얻으려 하니까 일이 점점 더 오래 걸려요. 6개월 안에 더 적은 실험을 할 수 있어요. 이제 사람들이 시스템을 게임하는 게 보이기 시작해요. 개선을 내보내려고 필사적으로 노력해요. 이제 정확히 악한 게 아니라 뭔가를 하면 어떻게 되요? 그냥 하고 있는 것의 결과를 그렇게 신중하게 생각하지 않아요. 이 실험을 시도했고, 될 것 같고, 코드 리뷰에 좋을 거니까요. 방금 하고 있는 것의 단점을 볼 인센티브가 없어요. 그래서 예를 들어, 페이스북 앱이 이 새 기능 더미를 얻고 정말 복잡해지는 걸 볼 거예요. 그건 기능을 소개하는 모두가 자기 기능이 모두에게 배포되기를 원하기 때문이에요. 다음 6개월 동안 자기 존재를 정당화할 수 있도록요. 장점, 모두 명령 팔레트를 공유하고 점점 더 길어지는 사실, 이건 아무의 책임도 아니에요. 그리고 아무도 "글쎄, 이 기능이 있는데 좀 한계가 있어. 사람들이 어떻게 쓸지 확실하지 않으니까 배포 안 할래요."라고 말할 인센티브가 없어요. 그건 그냥 자살이에요. 페이스북에서의 경력 자살이에요. 왜냐하면 인센티브가 모두 장점을 보는 것에 관한 거니까요. 장점에서 수확 체감이 있더라도요. 그리고 아무의 인센티브도 잠재적 단점을 보는 것에 관한 게 아니에요. 특히 이 기능과 저 기능의 교차점의 잠재적 단점은요. 그건 아무의 레이더에도 없어요. 그래서 그냥 안 봐요. 이 곡선의 어느 지점에서 임팩트, 결과, 측정 가능한 결과에 집중하는 것에서 좋은 의사 결정에 집중하는 것으로 가야 해요. 그래서 기능이 있는데 큰 차이를 안 만들고, 옵션 팔레트를 너무 크게 만들 거면, 배포 안 할 거야. 그게 앱의 모든 사용자에게 옳은 결정이에요. 어느 지점에서 "훌륭한 좋은 결정, 정말 고마워요. 회사, 사용자, 사회 전체를 위해 옳은 일을 했어요."라고 말할 수 있어야 해요. 그리고 저는 페이스북이 그 전환을 절대 안 할 거라고 생각해요. 이 임팩트에 대한 집중이 첫째로 너무 강하고, 정치적으로 영리한 사람들이 권력을 얻는 것에 대한 두려움이 너무 강하기 때문이에요, 맞죠? 그게 임팩트가 있는 이유예요. 말만 잘하고 실행 못하는 사람들을 원하지 않으니까요. 좋아요. 하지만 반대편은 이런 유령 개선을 얻는다는 거예요. 개별적으로, 맞죠, 매 6개월마다 페이스북 전체에 수천 개의 기능이 들어가요. 개별적으로 어떤 주어진 기능이 개인정보 문제를 일으키거나 파시스트를 선출하거나 뭐든 할 확률은 매우 매우 작아요. 하지만 기능이 너무 많고, 예상치 못한 방식으로 상호작용하고, 세계 인구의 그렇게 큰 비율이 사용해요. 제 견해로는 페이스북에 문제가 점점 늘어나는 것은 피할 수 없어요. 그리고 구조적으로 그것을 해결하기 위해 필요한 개혁—임팩트 평가에서 의사 결정의 질 평가로 가는 것—그건 그냥 절대 안 일어날 거예요. 그래서 그게 페이스북이 이 일련의 문제를 겪은 이유에 대한 제 설명이고, 계속될 거라고 예상해요. 하지만 질문은 남아있어요. 잃을 것이 무엇인가? 그 질문과 그 질문에 대한 우리의 반응을 어떻게 관리하느냐가 제가 소프트웨어 개발뿐만 아니라 많은 다른 것들을 바라보는 방식을 근본적으로 바꿨어요. 그래서 트위터가, 예를 들어, 제가 탐험하는 곳이에요. 페이스북에서 7년을 나온 후 제가 관심 있는 얘기할 것들 중에 사람들이 뭘 듣고 싶어하는지 잘 몰랐어요. 트위터가 제가 그걸 탐험하는 곳이에요. 왜냐하면 실험하기가 매우 싸니까요. 생각이 있으면 트위터에 올려요. 명백히 멍청하거나 공격적이지 않은 한요. 제가 공격적일지 항상 아는 건 아니지만, 그건 별개의 문제예요. 그냥 시도해봐요. 그리고 실제로 제가 트윗하는 것에 대한 반응의 크기는 20대 1이에요. 많은 것이 이 정도의 반응을 얻고, 가끔 뭔가 말하면 20배의 반응을 얻어요. 그리고 트윗을 누르는 순간 이게 어느 쪽이 될지 몰라요. 예측할 수 없어요. 그냥 시도해봐야 해요. 동굴에 들어가서 소프트웨어 개발에 관한 책을 신중하게 생각하고 쓴 다음 출시하고 아무도 관심 없다는 걸 발견하는 것과 비교해보세요. 제 아이디어 중 하나에 아무도 관심 없다는 걸 몇 초 만에 발견할 수 있어요. 그 모든 노력을 들일 필요가 없어요. 제 사운드클라우드 페이지도 같은 종류예요. 저는 음악가예요. 사람들이 듣고 싶어하는 음악을 연주하고 싶어요. 사람들이 뭘 듣고 싶어해요? 예측할 수 없어요. 제 최선의 전략은 그냥 핸드폰에 녹음을 누르고 이런 종류의 노래를 하고 올리고, 녹음을 누르고 이런 종류의 노래를 하고 올리고, 보는 거예요. 그리고 실제로 사운드클라우드에 다른 어떤 것보다 5배 더 많이 재생된 곡이 하나 있어요. 절대 숫자는 정말 정말 작아요. 본업을 그만두지 않을 거예요. 본업이 없긴 하지만, 그것도 별개의 문제예요. 하지만 탐험 모드에 있으면 분석하고 싶지 않아요. 어떻게 실험할지 알아내고 싶어요. 뭔가가 성장하고 있으면 성장의 장벽이 뭔지 찾아서 해결하고 다음 것에 대비하고 싶어요. 그리고 추출에 있는 제 경력 부분에서는 어떻게 조금 개선할 수 있을지 생각하고 싶어요. 이 사업을 다른 누군가에게 어떻게 팔 수 있을지. 왜냐하면 저는 추출이 싫거든요. 그건 그냥 제 개인적 선호지만, 제가 그 주기의 어디에 있느냐에 따라 규칙이 바뀌어요. 그리고 XP가 한 근본적인 실수는 이 질문을 인식하지 않고 전체 곡선에 대한 규칙 세트가 되려고 했다는 거예요. 그래서 테스트를 작성해야 하나요? 상황에 따라 달라요. 잃을 것이 있어요? 없어요? 글쎄, 더 빨리 실험하는 데 도움이 되는 테스트만 작성하세요. No Estimates, 모든 것에 대답 못해요. No Estimates는 탐험에서 훌륭한 아이디어예요. 왜냐하면 전에 해본 적 없으니까요. 그래서 추정은 그냥 추측이에요. 아무 가치도 안 더해요. 낭비된 노력이에요. 그러지 마세요. 하지만 추출에 있다면 추정을 안 하면 A 프로젝트를 할지 B 프로젝트를 할지 결정하기 위한 중요한 정보를 놓치는 거예요. 상당히 확신 있는 추정을 할 데이터가 있어요. 그 데이터, 그 경험을 사용해서 이것의 ROI 대 저것의 ROI를 결정해야 해요. 그래서 소프트웨어 개발을 바라보는 방식이 바뀌었고, 경력 개발을 바라보는 방식이 바뀌었고, 청중 개발을 바라보는 방식이 바뀌었고, 이것이 정말 무엇을 의미하는지 여전히 알아가고 있어요. 이게 제가 준비한 내용이에요. 몇 분 일찍 끝나는 것 같네요. 이야기는 훨씬 더 많지만, 여러분이 6시간 더 여기 있진 않을 테니까요. [박수] www.youtube.com/watch?v=WazqgfsO_kY ↗