Branch Prediction으로 생산성을 높이자

나는 성실하지만 매우 게으른 사람이다.

성실하다라는 말과 게으르다라는 말이 서로 상충되기에 혼란이 올 수 있을 것이다.

조금 더 구체화한다면 나는 해야하는 일에 대해서는 대부분 반드시 해내는 편이지만 정작 그 일을 실제 처리하는 데는 매우 게으른 방식으로 처리한다.

최근에 있었던 실제 사례를 A를 하는 프로그램을 난생 처음 접해보는 Python으로 작성하는 과제가 주어졌다고 하자.

다음 표는 내 사유 과정이다.

1. 나는 무엇을 할 줄 아는가? 나는 C, C++, Java를 배웠고 자잘한 프로젝트들을 진행해보았다. Android, Java, JSP 를 이용한 학생 수준에서 6man/month의 프로젝트도 몇 개 해봤다. 따라서, 프로젝트에 대한 막연한 두려움은 적으며 다른 언어를 받아들이는 것도 특별히 거부감이 없는 상태다. 2. 당장 Python 을 사용하기 위해 뭘 어떻게 해야하는가?  하지만, Python 은 일자무식 상태이다. 당장 Python을 사용해야 하므로 쉽게 설명된 얇고 탄탄한 책을 찾아보자. => Jump to Python 구매 Python IDE로는 보통 무엇을 쓰지? IntelliJ로 유명한 JetBrain에서 비슷하게 생긴 PyCharm을 release했다고 한다. (이름의 유래가 궁금하지만 잘 검색이 안된다.) 백문이 불여일타라고 들었다. Python interactive shell를 통해 아주 기본적인 기재를 익힌다.  구매한 점프투파이썬 책을 보고 중요한 예제 중심으로 vim 을 통해서 돌려보다가 PyCharm을 본격적으로 사용하였다. 3. 코드를 어떻게해야 '잘' 작성하지? 구글 코드 컨벤션을 찾아볼까 했는데 PIP 룰이라는게 있다고 한다. 인쇄해서 적용해본다. 말이 좀 쓸데없이 어렵게 되어있기도 하고 글로 읽어서는 모르겠다. github에 공개된 다른 잘 관리되는 파이썬 코드를 검색한다. 내가 했던 방식과는 좀 다르지만 몇 번 써보니 익숙해졌다. 4. 자 이제 프로그램을 작성해보자. 큰 그림 설계 => 검증(선배, 교수님 등) => 내부 상세 시나리오(클라이언트 관점, 서버 관점 등) 작성 => 검증 => 시나리오 모듈 단위 분화 및 일일 태스크 설정  => 이제야 시작

이러한 과정은 상대적으로 보장된 결과를 산출할 수 있다.

각 프로세스를 가능한 철저히 인과관계로 분화시키고 만약 내가 하고자 하는 행동들의 논거가 부족하다면

검색의 통해 타인의 흔적을 찾거나, 오프라인에서 만날 수 있는 조력자들과 회의하며 검증과정을 거친다. 

얼마나 논리적으로 맞는 소리인가!

나는 이렇게 생각하고 행동하는 것이 철저히 옳은 일이며 최적의 솔루션이라고 생각해왔다.

바로 얼마전까지만 해도 그랬다.

하지만, 함정이 있었다. 그것은 시간이 정해져있다는 것이다.

Sequential Programming Paradigm이 Pipelining & Parallel Paradigm으로 가게 된 가장 큰 이유는 단위 시간 당 생산량이 한계가 분명하기 때문이다.

옳은 일이라도 생산성에서 뒤쳐진다면 최적의 솔루션이라고 할 수 있겠는가?

사람은 컴퓨터처럼 빠르게 context switching을 할 수도 없거니와 분산 컴퓨팅도 불가능하잖아요!!라고 나의 과거가 변명해본다.

하지만, 내 일 처리 과정에 뭔가 병목이 있다는 것은 분명하다. 어디에서 병목이 발생하는가? 

사유하는 것 자체가 군더더기인가? 사유 과정은 반드시 필요하다. 사유 과정이 없다면 정말 무식하게 접근하게 될 수 있고, 무식한 접근은 최악의 비효율을 낳는다.

적절한 솔루션을 찾기 위해서 베이직한 단계부터 정의한 것은 잘한 것 같은데..

이 부분을 꽤 오랫동안 생각하고 있었는데 최근에야 알게되었다.

바로  '최적해'를 찾기 위해 계속하여 검증하는 일 자체가 오버헤드 였던 것이다. 

나의 게으름이 빛을 발한 부분이 바로 이 부분이다. 정말 효율적으로 일하는 딱 한 포인트만을 집중 공략해서 확 끝내고 싶다는 한탕주의가 내면에 자리잡고 있었던 것이다.

자 그럼 도대체 어떻게 하면 시간도 절약하고 조금 더 생산성을 높일 수 있는가?

정답은 Branch Prediction 이다. 

최적의 Branch를 찾는데 너무나 많은 시간이 걸리는 문제를, Prediction(예측)으로 해결한다.

'최적'을 찾기 위해 조언을 통해 검증을 해왔으나 사실 그것은 조금 더 식견이 높을지 모르는 사람이 예측을 대신 해주는 과정이었던 것이다.

지금까지 그런 검증을 통한 결과를 보았을 때 반드시 검증을 했어야만 했다는 경우는 많지않았다.

다만, 몇 케이스가 나를 '극악의 비효율'로부터 구해주었기 때문에 나 자신의 판단에 상당한 의심과 적개심을 가지게 되었던 것 같다.

하지만 이런식으로 판단을 타인에게 유보시키는 것은 내 성장에 별 도움이 되지 않는다.

내가 제일 좋아하는 미국 코미디언인 코난 오브라이언이 말하길, 백 번의 성공보다 한 번의 처절한 실패가 진짜 당신을 만나게 해줄 것이라 했다.

고민하는 시간, 할지말지 망설이는 시간을 최대한 줄여야겠다. 애초 모든 의사 결정에 100% 최적이라는 것은 존재하지 않는다.

100%는 아니어도 90%정도의 솔루션은 스스로 구할 수 있다. 문제는 그것을 즉시 행하느냐 남은 10%를 해결하기 위해 아둥바둥 매달리느냐이다.

make the common case fast

일부는 실패해도 좋다. 실패로부터 배우면 되니까 오히려 이득이다. 100% 정확도가 중요하지 않다. 오히려 위험하다.

어느정도 의사결정할 근거가 있다면 즉시 추진하는 습관을 기르자.

그것이 전체적으로 생산성을 올릴 수 있는 가장 쉽고 빠른 길이다.