빠른 것이 느린 것보다 낫다

May 23, 2026

이유를 따지지 마라. 빠른 것이 느린 것보다 낫다. 그냥 원래 그런 것이다. 당신의 일은 이미 할 수 있는 모든 것을 더 빠르게 해내는 것이다.

이 생각, 즉 빠른 것이 본질적으로 느린 것보다 낫다는 생각을 받아들일 수 있다면 당신은 이미 절반은 온 셈이다. 선수들로 이루어진 팀 전체가 그 생각을 받아들이게 할 수 있다면, 당신은 많은 경기를 이기게 될 것이다.

다른 모든 조건이 같다면, 내가 공을 한 번의 터치로 Point A에서 Point B로 보낼 수 있다면 두 번의 터치로 보내는 것보다 그것이 더 낫다. 왜냐고? 한 번의 터치가 두 번의 터치보다 더 빠르고, 빠른 것이 느린 것보다 낫기 때문이다.

— Dan Blank, Soccer IQ

약 10년 전, 나는 내가 함께 일했던 최고의 프로그래머들 모두에게 공통점이 있다는 사실을 깨달았다. 그들은 빨랐다. 내 말은, 그들이 움직이는 속도가 빨랐다는 뜻이다. 어떤 문제를 함께 논의하고 나면 한두 시간 뒤에는 이미 패치를 준비해 두거나 보여줄 프로토타입을 만들어 두곤 했다.

시간이 좀 걸렸지만, 결국 나는 이렇게 깨달았다. 그들은 뛰어난 프로그래머여서 빠른 것이 아니라, 빠르기 때문에 뛰어난 프로그래머였다.

생각해 보라. 빠르면 데이터를 더 빨리 얻는다. 그러면 더 나은 결정을 더 일찍 내릴 수 있다. 또 더 빨리 배우게 되고, 더 긴 시간에 걸쳐 보면 더 많이 배우게 된다. 빠르다는 것은 한 문제에 대해 여러 접근법을 시도해 보고 그중 가장 좋은 것을 고를 수 있다는 뜻이기도 하다.

많은 사람들이 이것이 너무 노력만 강요하는 문화처럼 들린다며 반발한다. 하지만 더 빨리 움직이는 방법 중에는 장시간 일하는 것과 무관한 것들이 많다. Jamie Brandon은 이에 대해 훌륭한 글 두 편을 썼다. Speed matters와 Moving faster이다. 아직 읽지 않았다면 꼭 읽어 보길 바란다.

나도 몇 가지 제안을 하고 싶다. 코딩 그 자체보다는 소프트웨어 엔지니어로 일하는 어질러진 현실에 좀 더 가까운 것들이다. 그리고 Jamie와는 달리, 이런 것들을 배우는 데 10년이 넘게 걸렸다는 점은 조금 부끄럽게 인정해야겠다.

미루지 마라. 이것은 정말 중요하다. 나는 습관적으로 느리게 움직이는 듯한 사람들과 많이 일해 봤다. 그들은 오후 4시에 문제를 알게 되면, 내일 다루기로 한다. 아니면 다음 주, 다음 분기쯤으로 미룬다.

내 생각에 이것은 종종 불편함을 피하려는 마음과 관련이 있다. 시작하는 것은 어렵다. 정확히 무엇을 해야 하는지, 어디서 시작해야 하는지 모르는 경우가 많다. 기다리면 더 쉬워질 것이라고 믿는 것은 위안이 되지만, 내 경험상 실제로 그런 경우는 드물다.

자투리 시간을 되찾아라. 어떤 프로그래머들은 뭔가를 해내려면 길고 방해받지 않는 작업 시간이 반드시 필요하다고 스스로를 설득해 왔다. 내가 Getting things done (in small increments)에서 썼듯이, 나는 이것이 엄격한 제약이라기보다 선호에 더 가깝다고 생각한다. 대부분의 사람들은 노력해 본다면 이 점에서 더 나아질 수 있다.

그 성과는 놀랄 만큼 클 수 있다. 많은 회사에서 하루에 3–4시간 정도의 방해받지 않는 시간 블록 하나만 있어도 운이 좋은 편일 수 있다. 여기에 회의가 한두 시간 더 있다고 해 보자. 그러면 여전히 시간의 25–35%가 파편화로 인해 사라지는 셈이다. 그 시간을 이메일을 읽거나 Hacker News를 훑어보는 대신 생산적으로 쓰면 훨씬 더 많은 일을 해낼 수 있다.

멍청해 보일까 봐 걱정하지 마라. 아마 당신은 이미 일을 초기에, 그리고 자주 공유해야 한다는 것을 알고 있을 것이다. 하지만 그것은 불편하기 때문에, “나는 품질 기준이 높아” 같은 이야기를 스스로에게 하며 미루기 쉽다.

그 불편함을 뚫고 나가는 법을 배우면 결과를 훨씬 더 빨리 얻을 수 있다. Oliver Burkeman은 70% 규칙에 대해 이야기한다.

당신이 써낸 글에 대해 대략 70% 정도 만족한다면, 그것은 출판해야 한다. 당신이 만든 제품에 70% 정도 만족한다면, 출시해야 한다.

[…]

70%에서 앞으로 나아가려면 100%를 고집하는 것보다 더 큰 배짱과 더 강한 인품이 필요하다. 왜냐하면 그것은 불확실성, 불안, 그리고 완벽하지 않은 결과물을 세상에 내놓을 때 따라오는 불쾌한 감정 속에서도 계속 전진하는 것을 뜻하기 때문이다.

PR도 마찬가지다. 리뷰어가 아무 문제도 찾지 못하길 바라며 코드를 다듬는 데 시간을 낭비하지 마라. 지금 올리고 피드백을 받아들여라. 코멘트 없이 PR 승인을 받는다고 해서 점수가 있는 것은 아니다.

더 빨리 움직이는 또 다른 방법은, 그리고 그 과정에서 어쩌면 멍청해 보일 수도 있는 방법은 동료들에게 조언을 구하는 것이다. 나는 모든 것을 스스로 생각해 내야 한다고 여기는 듯한 개발자들을 많이 봤다. 하지만 소프트웨어 개발은 팀 스포츠다. 혼자 다 하려고 스스로를 몰아붙이지 마라.

싸울 대상을 가려라. 협업에서는 사소한 것에 집착하며 시간을 낭비하지 마라. PR 리뷰어가 무언가를 바꾸라고 한다면, 거의 언제나 그것에 대해 논쟁하는 것보다 요청받은 대로 하는 편이 더 빠르다. 95%의 경우 차이는 너무 사소해서 논의할 가치조차 거의 없다. 정말 중요한 5%를 위해 시간과 에너지를 아껴라.

리뷰할 때도 마찬가지다. 중요하지 않은 일에 시간을 낭비하지 마라. 그렇다고 아무거나 대충 승인하라는 말은 절대 아니다. 나는 더 나은 이름이나 다른 방식에 대한 제안을 코멘트로 남기는 경우가 자주 있지만, 최종 결정은 작성자에게 맡긴다. 내 리뷰의 적어도 50%는 “코멘트는 있지만 LGTM”이다. 내 생각에 이것은 코드 리뷰의 장점 대부분을 얻으면서도 그것이 너무 많은 시간을 빨아들이지 않게 해 준다. 적어도 당신이나 팀 동료들의 시간을 말이다.

요구된 것만 하라. 내가 처음 했던 인턴십 중 하나에서, 팀 리드는 내게 이런 조언을 했다. “누군가가 네게 무언가를 해 달라고 하면, 필요한 최소한만 해라. 그걸 꾸준히 할 수 있으면 모두가 널 천재라고 생각할 거야.” 그때 나는 그것이 냉소적으로 들린다고 생각했다. 하지만 세월이 지나면서, 그것이 얼마나 현명한 말인지 깨닫게 되었다.

“그 이상”을 하려고 하면, 거의 언제나 추측하게 된다. 다른 사람이 무엇을 원하는지, 혹은 시스템이 미래에 무엇을 요구할지에 대해 추측하는 것이다. 그리고 경험이 부족할수록 그 추측이 틀릴 가능성은 더 커진다.

더 빨리 움직이려면, 아무도 요청하지 않은 일을 하느라 시간을 낭비하지 마라.

이유를 따지지 마라. 빠른 것이 느린 것보다 낫다. 그냥 원래 그런 것이다. 당신의 일은 이미 할 수 있는 모든 것을 더 빠르게 해내는 것이다.