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

구독자님, 메리 크리스마스입니다.
벌써 올해도 얼마 남지 않았다는 사실에 충격을 받는 요즘입니다.

한 해를 돌아보며 '이거 참 재밌었지' 했던 일이나, '이거 참 잘샀다' 싶은 물건 같은 것이 있으실까요? 여러분들의 '이거 참 잘했다' 싶은 순간에 이 뉴스레터를 구독한 것이 꼽힐 수 있기를 바라며...

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

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

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

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

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

그런데 여기서 중요한 점이 있습니다. 그것은 바로, 우리가 제한된 타임프레임을 근거로 ‘제한된 해석’을 내린다는 점입니다. 맨 처음의 코드 이야기를 예시로 들어보겠습니다.

코드에 오류가 발생했던 그때의 우리들은 현재의 업무량, 그리고 오류의 중요도를 따졌습니다. 그 순간에는 이러한 판단이 옳았다고 볼 수 있습니다. 그러나 보다 긴 타임프레임으로 보았을 때는 사뭇 다릅니다. 오류는 여전히 종종 발생하고, 코드를 다루는 개발자의 만족도와 능률은 떨어졌으며, 결론적으로 회사 연혁의 5%에 육박하는 시간을 이 코드의 땜질에 쓰고 말았습니다.

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

타임프레임을 조정하라

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

타임프레임을 조정한다는 것은 ‘가중치’를 무엇에 둘 것인지, 또는 사건의 ‘종결 조건’을 무엇으로 볼 것인지 새롭게 정의하는 것을 말합니다.

아까 전 코드의 예시로 말을 하면, 현재 시점에서 공수가 부족한 것을 이야기하기보다 ‘이걸 새로 짜게 되면 어떤 것들이 짧아질까?’를 생각해보는 것이 더 좋다고 느낍니다. 단기적으로 시간은 더 들어가더라도 멀리 보면 여러 가지를 얻을 수 있을 것입니다. 안정성이 높아진다, 더 많은 개발자들이 코드의 맥락을 알게 된다, 땜질에 드는 시간을 다른 기능 개발에 투자하게 되었다 같은 것들을요.

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