10. Slow is fast. Fast is Slow
내 주 업무 중 하나는 다른 사람들이 만든 코드를 리뷰하는 작업이다.
1. 나는 늦어도 아침 9시에 컴퓨터 앞에 앉는다. 다들 출근을 일찍 한다. 나는 전날에 인스타그램 릴스를 보고 자기 때문에 늦게 자고 늦게 일어난다. 컴퓨터에 앉으면 나를 기다리는 리뷰가 쌓여있다. 여기서 "리뷰"는 다른 팀원이 만든 코드를 검토하는 과정이다. 누군가 퀀트 알고리즘에 수정을 하고 싶으면, 바로 할 수는 없고, 리뷰를 거쳐야 한다. 나는 리뷰를 꼼꼼히 하는 편이다. 그래야 책임을 면할 수 있다. 그래서 그런지, 다들 나한테 리뷰를 요청한다. 그래서 나는 내 코드보다 다른 사람들이 짜는 코드를 보는 시간이 더 많다.
2. 대부분 나는 내가 직접 고치지 않는다. 대신에 코드를 만든 원작자에게, 더 나은 코드를 답변에 달고 (Github에서는 Comment라고 한다), 그 원작자가 받아들이거나 재반박을 한다. 여기서 논쟁이 발생하기도 한다. 다행히, 대부분 똥고집이 있는 편은 아니라서, 자신이 틀렸다고 생각하면 그걸 쉽게 받아들인다 (나도 그러려고 노력한다).
3. 근데, 가끔 어떤 코드는 처음부터 손을 봐야 하는 경우가 있다. 누군가 리뷰를 요청할 때, 적어도 자신의 컴퓨터에서 한 번쯤은 테스트를 거치고 요청을 해야 한다. 그런데, 그런 테스트를 과연 했는지 의심이 드는 코드들이 있다. 이 때는 내가 코드를 "제시"하기보다는 직접 바꾼다. 그리고 상대방한테 말한다.
"너의 코드가 내 컴퓨터에서 안 돌아간다. 그래서 처음부터 다시 바꿨다 : ) 그래도 너의 의도는 반영했다. 혹시 문제가 생기면 알려달라". 이렇게 말하면, 그와 나 사이에 미묘한 긴장감이 흐른다.
4. 다행히, 위와 같은 상황은 많지 않다 (한 달에 한 번?). 이렇게 리뷰를 많이 하다 보면, 내가 만든 코드를 누군가가 리뷰를 할 때 그 사람이 어떤 기분일지 느낄지 상상할 수 있다. 그래서 나는, 빨리 코드를 만들기보다는, 천천히, 이 코드를 리뷰하는 사람을 생각해서 만든다. 테스팅도 여러 번 거치고, 그래서 코드를 만드는 속도가 느리다.
5. 속도는 느리지만, 결과적으로는 빠른 방법이다. 팀장이 처음 나에게 가르쳤던 교훈은 "Slow is fast. Fast is Slow"이다. 문법적으로 맞는 영어 문장인지는 모르겠지만, 하여튼, 빠르게 일을 처리하려다 보면 실수가 많아져 오히려 느려지고, 천천히 정공법으로 문제를 처리하면, 오히려 처리 속도가 빠르다는 이야기다. 나도, 한때는 "빨리"를 입에 달고 살았다. 걸을 때도 파워 워킹이 아니면 걷는 기분이 안 들었다. 그런데 이 회사에 들어오면서부터는, 생각이 급하게 앞서 나갈 때, "Slow is fast. Fast is Slow"를 심호흡과 함께 입으로 내뱉는다.