Interview with Kent Beck • YOW! 2018

진행자: 호주에 오신 것을 환영합니다.

Kent Beck: 감사합니다. 여기 오게 되어 기쁩니다. 악수가 좀 어색해서 죄송합니다. 어깨 상태가 좀 엉망이라서요.

진행자: 어젯밤에 기타를 너무 오래 쳐서 그런 건 아니겠죠?

Kent Beck: 기타도 어느 정도 영향이 있었던 것 같네요. 맞아요.

진행자: 소닉 파이(Sonic Pi) 밴드와 함께 공연하시는 모습 정말 보기 좋았습니다.

Kent Beck: 정말 재밌었습니다. 오랫동안 DJ와 함께 연주해보고 싶었는데, 공연 내내 DJ가 코딩을 하고 있었잖아요. 재밌었던 건, 춤추고 있는 사람들의 무리가 있는 반면에, 한쪽 구석에는 꼼짝도 하지 않고 서서 샘(Sam)이 어떻게 코딩하고 있는지 파악하려는 '진짜 괴짜(Geeky Geeks)' 무리가 있었다는 점이에요. "도대체 저 코드가 내가 듣는 소리와 무슨 관련이 있는 거지?"라고 생각하면서요. 하지만 이 모든 혼란 속에서 가장 중요한 건 결국 코드죠. 지켜보는 게 정말 즐거웠습니다.

진행자: 페이스북에서 수년 동안 일하신 후, 다시 밖으로 나와 강연하시는 모습을 보니 좋습니다. 괜찮으시다면 '3X'와 '탐색(Explore), 확장(Expand), 추출(Extract)'에 대해 어떤 이야기를 하고 계신지, 그리고 대기업을 떠나신 지금 어떤 방향으로 나아가려 하시는지 공유해 주시겠습니까? 아마도 많은 사람들에게 XP(익스트림 프로그래밍)의 본질과 소프트웨어 구축의 의미를 다시 일깨워주면서, 이를 대규모 환경에 적용하려는 미션을 가지고 계신 것 같아서요.

Kent Beck: 네, 제가 거의 8년 전 페이스북에 입사했을 때 맞닥뜨린 근본적인 수수께끼는 이것이었습니다. '어떻게 수억 명의 사람들에게 전례 없는 규모의 좋은 경험을 제공하고, 사용자를 빠르게 늘리면서, 동시에 혁신까지 할 수 있는가?' 저는 이 세 가지를 모두 해내는 조직을 본 적이 없었습니다.

제가 처음 갔을 때는 그저 완전한 혼돈(chaos)처럼 보였습니다. 그래서 소프트웨어 공학에 대한 제 이해를 완전히 재설정해야 했습니다. 그들은 제 책에 나오는 방식대로 하지 않았지만, 매우 성공적이었으니까요. 저자 입장에서 사람들이 내 조언을 따르지 않는데도 성공하는 것만큼 짜증 나는 일은 없거든요. 사람들이 제 조언을 따르지 않는 건 상관없는데, 그렇다면 실패해줬으면 하거든요. (웃음)

그래서 주의 깊게 관찰하고, 소프트웨어 개발에 직접 참여하고, 젊은 엔지니어들을 멘토링하면서 페이스북에는 세 가지 뚜렷한 스타일의 프로젝트가 있다는 것을 알게 되었습니다.

첫째, 잃을 것이 거의 없는 상황에서 실험이 가능하도록 설정된 '탐색(Exploration)' 프로젝트들이 있었습니다. 이 스타일은 그에 맞는 엔지니어링 규율이 필요합니다. 어차피 오래 쓸 게 아니니까 요령을 피워도(cut corners) 됩니다. 의도적으로 소규모로 진행하고, 확장성(scaling)은 걱정하지 않습니다. 프로젝트 기간도 매우 짧고요.

그러다 무언가가 터지면(성공하면) 모든 것이 바뀝니다. 모두가 한 방에 모이고, 확장에 따른 기술적 장애물을 극복하기 위해 회사 전역에서 기술 전문가들이 차출됩니다. "자, 사진 기능이 대박 났는데 저장 공간이 부족해. 다들 이 문제에 집중해." 이렇게 집중적인 '확장(Scaling)' 시기가 오는데, 이는 탐색 단계와는 다른 엔지니어링 규율, 관리 규율, 재무적 규율이 필요합니다. 더 좋고 나쁨의 문제가 아니라, 그냥 다른 겁니다. 트레이드오프(trade-offs)가 바뀐 거죠.

그러다 어느 시점이 되면 성장이 지속되긴 하지만 예측 가능해집니다. '예측 가능한 성장(Predictable Growth, 추출 단계)'은 그 자체로 또 다른 엔지니어링, 재무, 관리 규율이며, 종종 다른 인력, 다른 기술, 그리고 바라보는 시간적 프레임도 달라집니다.

제 관점에서 놀라웠던 점은 페이스북이 같은 조직 내에서, 때로는 같은 사람들이 프로젝트 사이를 이동하면서 이 서로 다른 스타일들을 운영하고 있었다는 것입니다. 누군가 무언가를 시작해서 키우고, 그 미친듯한 성장 단계를 거친 다음, 빠져나와서 또 다른 무언가를 시작하는 식이었죠.

"잃을 것이 얼마나 있는가?"라는 이 질문을 익스트림 프로그래밍(XP)을 개발하는 동안에는 놓치고 있었습니다. 저는 그저 "소프트웨어 개발을 위한 규칙 세트가 여기 있다"라고만 생각했죠. 규칙이라기보다는 가야 할 방향이라고 해야겠지만요. 하지만 탐색 단계일 때는 추출 단계일 때와 트레이드오프가 완전히 다릅니다.

이 깨달음은 저에게 큰 경종을 울렸습니다. 테스트를 작성해야 하는가? 추정을 해야 하는가? 마감일이 있어야 하는가? 이 모든 것에 대해 겸손해지게 되었죠. 정답은 "상황에 따라 다르다(It all depends)"입니다. 이것이 제가 얻은 큰 교훈이었습니다.

해고된 지 10개월 동안 저는 이 '3X'에 대해 이야기하기 시작했습니다. 왜냐하면 이것이 제가 소프트웨어 개발, 비즈니스 개발, 그리고 인생 전반을 바라보는 방식을 근본적으로 바꾸었기 때문입니다. 반응은 엄청나게 긍정적이었습니다. "이걸 적용했더니 문제들이 명확해졌고 다음에 뭘 해야 할지 알게 되었다"는 사람들이 있었죠.

하지만 더 강력한 반응은 이런 것이었습니다. "3X 이야기 정말 도움이 되네요. 그런데 지난 10년 동안 애자일 전환(Agile transformation)을 시도해 왔는데, XP는 너무 힘든 작업처럼 들려서 스탠드업 미팅(stand-ups)만 하고 그 위에 다른 것들을 얹어서 해왔거든요. 근데 전혀 작동하질 않아요. 그 익스트림 프로그래밍이라는 거에 대해서 다시 좀 이야기해 주실 수 있나요?"

저는 새로운 것을 좋아하는데, 사람들이 저의 '히트곡 모음'을 듣고 싶어 한다는 게 좀 김 빠지기도 했습니다. 저는 지금 프로젝트 관리를 위한 '범위 제어(scope control)'에 대해 열변을 토하고 있는데, 이건 제가 15년 동안 하지 않았던 이야기거든요. 하지만 사람들이 그런 메시지에 관심이 있고, '제대로 된' 소프트웨어 공학이라는 힘든 작업에 대한 수요가 있다면 해야죠.

이와 더불어 '3X'라는 질문이 '제대로 된' 것이 무엇인지를 근본적으로 정의하고 맥락을 설정해 줍니다. 동시에 저는 브랜드 유행이 지나간 후 '음지'로 들어가 지난 15년 동안 조용히, 그리고 종종 매우 성공적으로 XP를 실천해 온 익스트림 프로그래머 커뮤니티와 다시 연결되었습니다.

즉, 애자일 개발이 약속했던 가치를 얻기 위해 기꺼이 힘든 작업을 하려는 '강한 수요'가 있고, "그래, 그 작업을 하고 싶다면 이렇게 하면 돼"라고 설명해 줄 수 있는 수백, 수천 명의 매우 숙련된 실무자들이 존재합니다.

지금은 이 모든 게 파편화되어 있습니다. 내년, 아니 올해 제 큰 프로젝트는 개선을 위한 힘든 작업을 원하는 사람들과 그것을 실제로 할 줄 아는 사람들을 어떻게 하면 가장 잘 연결할 수 있을지 모색하는 것입니다. 지난번보다는 좀 덜 개인적인 방식으로, 일종의 '프로듀서'로서 그 그룹들을 연결해 보고 싶습니다. 무슨 일이 일어날지 보고 싶어요.

왜냐하면 소프트웨어 개발의 근본적인 약속은 여전히 이행되지 않았기 때문입니다. 우리는 인류 역사상 유례없는 확장성을 가진 기술을 가지고 있는데, 우리가 할 수 있는 만큼 효과적으로 사용하지 못하고 있습니다. 그 점이 여전히 저를 화나게 합니다(pisses me off). 그래서 그런 일이 일어나는 걸 보고 싶습니다.

진행자: 정말 기대됩니다. 주제를 조금 바꿔서, 아주 많은 수의 프로그래머들과 작업할 때 어떤 기법이 효과적일지 실험하고 계신다고 들었습니다. 그 부분에 대해 좀 말씀해 주시겠습니까?

Kent Beck: 네, 페이스북 재직 말기에 저는 페이스북 엔지니어가 700명에서 5,000명으로 늘어나는 것을 보았습니다. 5,000명에서 10,000명으로 가는 방법에 대해 고민하는 사람은 많았습니다. 그래서 그건 별로 흥미로운 질문이 아니었죠.

"10만 명의 엔지니어가 동시에 하나의 시스템에서 협업하려면 무엇이 필요할까?" 이것이 흥미로운 질문이었습니다.

현재의 코드 리뷰 및 풀 리퀘스트(pull request) 스타일의 개발에서 보편적으로 인정받는 근본적인 진리 중 하나는 '풀 리퀘스트(변경 사항)는 작을수록 좋다'는 것입니다. 그래서 생각했죠. "좋아, 나한테 특별한 기술은 별로 없으니, 그냥 '작은 변경(small diffs)'이라는 원칙을 극한까지 밀어붙여 보자. 무슨 일이 생기나."

프로젝트 이름은 '림보(Limbo)'입니다. 림보 노래 가사에 "얼마나 낮게 갈 수 있나(How low can you go)?"라는 말이 있잖아요. 그래서 "얼마나 작게 변경할 수 있나?"가 핵심입니다.

만약 변경 사항(diff)을 아주 작게 만들고 아주 안전하게 만들어서, '커밋 전 코드 리뷰(pre-commit code review)'가 필요 없을 정도라면 어떨까요? 그렇다면 훨씬 더 많은 사람이 훨씬 적은 병합 충돌(merge conflicts)을 겪으며 같은 시스템에서 작업할 수 있을 겁니다.

구체적인 실험을 시작했는데, 주석 하나를 수정했다고 그걸 수천 대의 서버와 수백만 대의 스마트폰에 즉시 배포하는 건 현실적으로 불가능하긴 합니다. 만약 그게 실용적이었다면 누군가 이미 하고 있었을 테고, 그럼 더 이상 흥미롭지 않았겠죠. 그게 아이디어입니다. 이게 어디로 갈지, 어떻게 밀고 나갈지는 모르겠지만요.

진행자: 우리가 스몰토크(Smalltalk)로 작업했던 경험이나, 에너미(Envy) 개발 환경에서의 경험을 떠올려보면, 기본적으로 사람들은 이미지(image)에 대해 매우 미세한 단위의 변경 사항을 공유했습니다. 사실상 우리는 '병합(merge)'이라는 걸 하지 않았죠. 왜냐하면 우리는 항상 병합된 상태였으니까요. 비록 많은 변경이 있어도 조각들이 서로 충분히 떨어져 있어서 실제로 충돌이 발생하는 횟수는 정말 적었습니다.

Kent Beck: 맞습니다. 그게 바로 질문입니다. 변경 크기를 충분히 줄이고, 개발 환경이 내가 무엇을 하는지 알고 있어서 단순히 무작위 텍스트를 편집하는 게 아니라 "아, 주석을 지우는 중이구나. 그건 안전해. 다 배포해 버려."라고 할 수 있다면 어떨까요? 안 될 이유가 없죠.

진행자: 이번 주 시드니 CTO 컨퍼런스에서 전 트위터 출신 인사가 흥미로운 이야기를 했습니다. 그들은 병합 충돌 때문에 작업이 막히는(blocked) 문제가 있었습니다. 특히 분산 환경이라서 구글에 있는 누군가의 승인을 기다리고, 트위터에 있는 누군가의 승인을 기다리고 해야 했죠.

그래서 그들이 도입한 방식은 기본적으로 '사후 리뷰(review is after)'입니다. 변경 사항을 먼저 반영하고, 리뷰는 나중에 하는 거죠. 그렇게 하면 리뷰를 모아서 다음 날 아침이나 주 후반에 한꺼번에 처리할 수 있습니다. 지금까지의 경험으로는 작업이 막히지 않아서 훨씬 더 많은 일을 처리하고 있고, "이 코드 좀 리뷰해 줘, 승인해 줘" 하면서 방해받는 일도 줄었다고 합니다. 속도(velocity)가 빨라졌고, 나쁜 코드가 들어가는 문제도 없었다고 하더군요.

Kent Beck: 코드 리뷰 스타일은 많은 가치를 창출하지만, 동시에 막대한 비용도 발생시킵니다. 멀티태스킹을 해야 하거나, 변경 사항(diff)을 쌓아둬야 하거나, 개발 스타일을 인위적으로 바꿔야 하는 등의 비용 말이죠. 이 비용은 어디에도 계상되지 않습니다. "우리 회사는 엔지니어링 예산의 40%를, 혹은 80%나 10%를 코드 리뷰에 쓰고 있다"라고 파악할 방법이 없습니다. 알 수가 없죠.

그래서 '사후(post-hoc) 변경 리뷰'와 함께 훨씬 작은 단위의 스타일을 시도해보는 것은 분명 실험적인 일이지만, 해볼 만한 가치가 있습니다. 잠재적인 이득이 크고 확장성이 있기 때문입니다. 조직이 커질수록 코드 리뷰 비용은 증가합니다. 시간적 비용뿐만 아니라 "야, 왜 내 변경 사항 리뷰 안 해줘?" "나도 내 할 일이 있거든?" 같은 사회적 마찰 비용도 커지죠. 사람이 많아질수록 상황은 점점 더 나빠집니다. 즉, 팀 규모가 커질수록 이 방식의 이점은 점점 더 커진다는 뜻이고, 바로 그 지점을 지향해야 합니다.

진행자: 아쉽게도 시간이 다 되었네요. 켄트, 호주까지 와주셔서 정말 감사합니다.

Kent Beck: 감사합니다. 즐거웠습니다.

진행자: 청중들도 켄트 님의 이야기를 듣고 대화할 수 있어서 즐거워했습니다. 3X와 림보(Limbo)에 대한 앞으로의 작업도 기대하겠습니다.

Kent Beck: 정말 감사합니다.

진행자: 네, 안녕히 가세요.