가까이서 보면 비극, 멀리서 보면 희극

퇴사를 앞두고 작업 내역을 돌아보다, 오랫동안 저를 괴롭혔던 거대하고 오래된 코드가 생각났다. 여기서 오류가 나면 옛날 기록도 찾아야하고 또 하나씩 뜯어봐야해서 진절머리가 났던 기억이 난다. 이 코드를 고치자고 말하는 사람은 많았다. 그러나 그때마다 번번히 ‘지금 개발할 것이 많아서 어려워요’ 라던가 ‘땜질로 해결되지 않을까요?’라는 이야기에 결국 손을 대지 못했다.

불현듯 지난 8년간 이 코드에 땜질을 했던 작업을 모아 시간을 계산해보았다. 그러자 ‘반년’이 조금 넘는다는 결과가 나왔다. ‘이럴 바에는 같은 시간에 새로 짜는 것이 훨씬 나았을텐데’ 하며 씁쓸함만이 남았다.

#타임프레임에 기반한 해석과 반응

어떤 사건이 발생했을 때, 우리는 즉각적으로 감정을 표현하거나 현재까지 알고 있는 정보를 조합해 이성적인 판단을 내리려고 한다. 현재까지의 기간, 즉 현재라는 **‘타임프레임(Timeframe)’**으로 사건을 해석하고 반응하는 것이다.

그렇다면 타임프레임은 무엇일까? 시간에 따른 변화를 나타내는 그래프가 있다고 해보자. 이때 그래프의 기간을 언제부터 언제까지로 잘라서 볼지에 따라 그래프의 모양이 달라질 것이다. 여기서 언제부터 언제까지의 ‘기간’을 ‘타임프레임’이라고 부른다.

그런데 여기서 중요한 점이 있다. 그것은 바로, 우리가 제한된 타임프레임을 근거로 ‘제한된 해석’을 내린다는 점이다. 맨 처음의 코드 이야기를 예시로 들어보면, 코드에 오류가 발생했던 그때의 우리들은 현재의 업무량, 그리고 오류의 중요도를 따졌다. 그 순간에는 이러한 판단이 옳았다고 볼 수 있다. 그러나 보다 긴 타임프레임으로 보았을 때는 사뭇 다를 것이다. 오류는 여전히 종종 발생하고, 코드를 다루는 개발자의 만족도와 능률은 떨어졌으며, 결론적으로 회사 연혁의 5%에 육박하는 시간을 이 코드의 땜질에 쓰고 말았기 때문이다.

그때 일어났던 ‘팩트’를 토대로 내린 판단은 장기적인 효과를 가늠하기 어렵다는 걸 우리는 기억해야한다. (같은 관점에서 A/B 테스트가 정말 도움이 되는지도 생각해볼 수 있다)

#타임프레임을 조정하라

그러나 한편으로는 이것이 모두 결과론에 불과한 것 아닌가, 혹은 그러면 결정을 어떻게 해야하느냐는 의문이 들지도 모르겠다. 나는 우리가 제한된 타임프레임으로 사건을 바라본다는 사실을 인정하면서도, 동시에 그러한 제약에 순응하는 것이 아닌, 타임프레임을 조정하려는 시도를 해야한다고 생각한다.

타임프레임을 조정한다는 것은 **‘가중치’**를 무엇에 둘 것인지, 또는 사건의 **‘종결 조건’**을 무엇으로 볼 것인지 새롭게 정의하는 것을 말한다. 아까 전 코드의 예시로 말을 하면, 현재 시점에서 공수가 부족한 것을 이야기하기보다 ‘이걸 새로 짜게 되면 어떤 것들이 짧아질까?’를 생각해보는 것이 더 좋다고 믿는다. 단기적으로 시간은 더 들어가더라도 멀리 보면 여러 가지를 얻을 수 있을 것이다. 안정성이 높아진다, 더 많은 개발자들이 코드의 맥락을 알게 된다, 땜질에 드는 시간을 다른 기능 개발에 투자하게 되었다 등…

타임프레임의 조정을 통해 나는 우리가 시간의 제약에서 벗어나 보다 중요한 것을 인식할 수 있다고 믿는다. 심지어 놓치면 안되는 것을 붙잡을 수도 있을 것이다.

#가까이의 비극도 멀리 보면 희극으로

삶은 가까이서 보면 비극이지만 멀리서 보면 희극이라는 찰리 채플린의 명언이 있다. 우리 앞에 일어난 어렵고 힘든 일도, 현재라는 제한된 타임프레임에서 벗어남으로서 사건의 해석을 바꿔낼 수 있지 않을까.

그렇기에 기억하자. 가까이의 비극도 멀리서 보면 희극이 될 수 있다는 걸.