빠른게 느린 것보다 낫다

Fast is better than slow

성공은 과거(혹은 현재)의 것을 레버리지 삼아서 더 높은 위치로 도약하는 행위의 반복이라고 생각합니다. 그래서 최대한의 많은 경험이 최대한 높은 성공으로 이끕니다. 성공 = 최대한 많은 경험입니다. 최대한 많은 경험을 하기 위해서는 최대한 많은 실행이 필요합니다.

성공 = 경험 = 가설검증 X 속도이고, 속도는 개인의 것이 아닙니다. 일반적으로 속도는 전체에서 가장 느린 것이 기준이 됩니다. 그래서 팀에 속해 있다면 항상 빨라야 합니다.

오늘은 Patrick Dubroy의 Fast is better than slow을 번역했습니다.

왜냐고 묻지 마세요. 빠른게 느린 것 보다 낫습니다. 그냥 그런 겁니다. 당신의 일은 이미 할 수 있는 모든 것을 더 빠르게 하는 겁니다.

빠른 것이 느린 것보다 낫다는 생각을 받아드릴 수 있다면, 이미 절반은 온 셈입니다. 그 생각을 팀 전체가 받아들이게 만들 수 있다면, 너는 많은 경기를 이기게 될 것입니다.

다른 조건이 모두 같다면, 공을 A 지점에서 B 지점으로 한 번에 터치로 보낼 수 있다면 그게 두번의 터치로 보내느 것보다 낫습니다. 왜? 한 번의 터치가 두 번의 터치보다 빠르고, 빠른 것이 느린 것보다 낫기 때문입니다.

— Dan Blank, Soccer IQ

약 10년 전, 저는 함께 일했던 최고의 프로그래머들에게 공통점이 하나 있다는 것을 깨달았습니다. 그들은 빨랐습니다. 빠르다는 것은 그들이 신속하게 움직였다는 뜻입니다. 어떤 문제를 함께 논의하고 나면, 한두 시간 뒤에는 이미 패치를 준비해 두었거나 선보일 프로토타입을 만들어 두곤 했습니다.

시간이 좀 걸렸지만, 결국 저는 깨달았습니다. 그들은 뛰어난 프로그래머라서 빠른 것이 아니라, 빨라서 뛰어난 프로그래머였던 것입니다.

생각해 봅시다. 빠르면 데이터를 더 빨리 얻습니다. 그러면 더 나은 결정을 더 일찍 내릴 수 있습니다. 또한 더 빨리 배운다는 뜻이고, 긴 시간으로 보면 더 많이 배운다는 뜻입니다. 빠르다는 것은 한 문제에 여러 접근법을 시도해 보고 그중 가장 좋은 것을 고를 수 있다는 뜻이기도 합니다.

많은 사람들이 이 말에 반발하는데, 허슬 컬쳐처럼 들리기 때문입니다. 하지만 오래 일하지 않고도 더 빠르게 움직이는 방법은 많습니다. Jamie Brandon은 이에 관해 훌륭한 글 두 편을 썼습니다. Speed matters와 Moving faster입니다. 아직 읽지 않으셨다면 꼭 읽어보시길 권합니다.

저도 몇 가지 제안할 것이 있습니다. 코딩 그 자체보다는, 소프트웨어 엔지니어로 일하면서 마주하는 지저분한 현실에 더 가까운 것들입니다. 그리고 약간 부끄럽지만 고백하자면, 제이미와 달리 저는 이것들을 배우는 데 10년 넘게 걸렸습니다.

미루지 마세요. 이건 정말 중요합니다. 저는 습관적으로 느리게 움직이는 듯한 사람들을 많이 봐 왔습니다. 그들은 오후 4시에 어떤 문제를 알게 되고는 내일 처리하기로 마음먹습니다. 혹은 다음 주, 혹은 다음 분기로 미룹니다.

제 생각에 이것은 흔히 불편함을 회피하려는 것입니다. 시작하는 것은 어렵습니다. 무엇을 정확히 해야 하는지, 어디서부터 시작해야 하는지 모르는 경우가 많습니다. 기다리면 더 쉬워질 거라고 믿으면 마음이 편하지만, 제 경험상 그런 일은 거의 없습니다.

자투리 시간을 되찾으세요. 어떤 프로그래머들은 무언가를 해내려면 길고 방해받지 않는 작업 시간이 필요하다고 스스로를 설득해 왔습니다. Getting things done (in small increments)에서 썼듯이, 저는 이것이 절대적인 제약이라기보다는 선호의 문제에 가깝다고 생각합니다. 대부분의 사람은 노력하면 이 부분을 더 잘하게 될 수 있습니다.

그 이득은 놀라울 만큼 클 수 있습니다. 많은 회사에서는 하루에 방해받지 않는 3~4시간짜리 시간 한 덩어리만 있어도 운이 좋은 편일 것입니다. 거기에 회의가 한두 시간 더 있다고 치면, 그것만으로도 시간의 25~35%가 파편화로 사라지는 셈입니다. 그 시간을 이메일을 읽거나 해커뉴스를 둘러보는 데 쓰는 대신 생산적으로 쓴다면 훨씬 더 많은 일을 해낼 수 있습니다.

멍청해 보일까 봐 걱정하지 마세요. 당신은 아마 자신의 작업물을 일찍, 그리고 자주 공유해야 한다는 것을 이미 알고 계실 것입니다. 하지만 그것은 불편한 일이라서, “나는 품질 기준이 높아서 그래”라는 식의 이야기를 스스로에게 들려주며 미루기 쉽습니다.

그 불편함을 뚫고 나아가는 법을 익히면 훨씬 더 빨리 결과를 얻을 수 있습니다. 올리버 버크먼은 70% 규칙에 대해 이야기합니다.

당신이 쓴 글에 대략 70% 만족한다면, 발표해야 합니다. 당신이 만든 제품에 70% 만족한다면, 출시하세요.

[…]

70%에서 앞으로 나아가는 것은 100%를 기다리는 것보다 더 많은 배짱과 더 강한 성품을 요구합니다. 왜냐하면 그것은 불확실성과 불안, 그리고 완벽하지 않은 결과물을 세상에 내놓을 때 따라오는 불쾌한 감정 속에서 앞으로 나아가는 일이기 때문입니다.

PR도 마찬가지입니다. 리뷰어가 아무 문제도 찾지 못하기를 바라며 코드를 다듬느라 시간을 낭비하지 마세요. 지금 올리고 피드백을 받아들이세요. 코멘트 하나 없이 PR을 승인받는다고 해서 점수를 더 주는 것은 아닙니다.

더 빠르게 움직이는 또 다른 방법은(그 과정에서 멍청해 보일 수도 있지만) 동료에게 조언을 구하는 것입니다. 저는 모든 것을 혼자 생각해 내야 한다고 여기는 듯한 개발자들을 많이 봐 왔습니다. 하지만 소프트웨어 개발은 팀 스포츠입니다. 혼자서 다 해내려고 자신을 몰아붙이지 마세요.

싸움을 가려서 하세요. 협업에 있어서는 사소한 일로 논쟁하는 데 시간을 낭비하지 마세요. PR 리뷰어가 무언가를 바꾸기를 원한다면, 그것을 두고 다투기보다 그냥 요청대로 하는 편이 거의 항상 더 빠릅니다. 95%의 경우, 그 차이는 너무 사소해서 논의할 가치조차 거의 없습니다. 당신의 시간과 에너지는 정말 중요한 5%를 위해 아껴 두세요.

리뷰를 할 때도 똑같이 적용됩니다. 중요하지 않은 일에 시간을 낭비하지 마세요. 모든 것을 형식적으로 통과시키라는 말은 결코 아닙니다. 저도 더 나은 이름을 제안하거나 다른 방식을 제시하는 코멘트를 자주 남기지만, 최종 결정은 작성자에게 맡깁니다. 제 리뷰의 최소 50%는 ‘코멘트를 단 LGTM(Looks Good To Me)’인 것 같습니다. 제 생각에 이것은 (당신과 동료 모두에게) 코드 리뷰가 시간을 너무 많이 잡아먹지 않게 하면서도 그 이점의 대부분을 누리게 해 줍니다.

요구된 것만 하세요. 첫 인턴십 중 하나에서 팀 리더가 제게 조언을 해 주었습니다. “누군가 무언가를 해 달라고 부탁하면, 요구되는 최소한만 해라. 그걸 꾸준히 할 수 있다면, 모두가 너를 천재라고 생각할 거야.” 그때는 냉소적인 말이라고 생각했지만, 세월이 지나면서 그것이 얼마나 현명한 말이었는지 깨닫게 되었습니다.

‘기대 이상으로’ 하려고 하면, 당신은 거의 항상 추측을 하고 있는 셈입니다. 다른 사람이 무엇을 원하는지, 혹은 시스템이 앞으로 무엇을 요구할지에 대해서 말입니다. 그리고 경험이 부족할수록 그 추측이 틀릴 확률은 더 높아집니다.

더 빠르게 움직이려면, 아무도 요청하지 않은 일을 하는 데 시간을 낭비하지 마세요.

…

왜냐고 묻지 마세요. 빠른 것이 느린 것보다 낫습니다. 그냥 그런 겁니다. 당신의 일은 이미 할 수 있는 모든 것을 더 빠르게 하는 겁니다.