[데이터조직] 시니어 개발자 리더는 버그마저도 문제 해결을 위해 사용할 수 있어야 한다.

사회 생활 초년시절이었다. BI 시스템을 대규모로 신규 버전으로 마이그레이션 해야 하는 상황이었던 것으로 기억난다. 당시에 이미 연봉을 1억 가까이 받고 계셨던 시니어 개발자 분이었다. 나이가 이미 나와 상당히 차이가 났던 탓에, 징징대는 말도 종종하였는데 잘 받아주셨기에 많이 대화하면서 일을 했던 기억이 난다.

당시에는 지금보다 개발자에 대한 대우가 그리 좋지 않았기에, 욕만 거의 없을뿐, 당황스러울 수 밖에 없는 일정으로 업무를 말미에 가서 요청주시는 경우가 있었는데, 그 때마다 시니어 개발자분은 거의 모든 문제를 해결하셨고, 그걸 보면서 많이 놀라곤 했는데, 그 때 가장 신기했던 부분은 바로 해당 솔루션의 특정 버전의 버그를 이용해서 리포트를 만든 것이었다.

이후에 마이그레이션을 하는 상황이 되었을 때 아무일 없다는 듯이 그런 리포트만 모아서, 관련 사용자 대상으로 공유를 하고 우회할 수 있는 방향성을 가이드하셔서 역시 아무 일 없다는 듯이 버그를 사용하지 않는 운영환경으로 매끄럽게 전환하셨다. 정확히 기억나지는 않지만, 버그를 활용한 것만 기억이 확실히 난다.

이후 시간이 지나, 내가 그 연차 근처에 조금 보다 가까워지게 되니, 그 시니어 개발자 분이 보여준 모습이 이제는 이해가 된다. 사업 및 서비스의 요구사항을 수렴하다 보면 종종 그 시급성이나 중요성으로 인해서 어처구니 없는 요청이 정말 너무나도 말도 안되는 시점에 프로덕트 조직에게 요구되는 경우를 심심치 않게 본다.

이 때, 시니어이면서 리더로서 나는  장애가 날 각오를 하고 프로덕트를 날림으로 만드는 의사결정을 종종 해야 하는 경우가 발생한다. 우리는 이런 케이스를 소위 기술부채라는 용어로 부르기도 한다. 리더로서 이렇게 문제를 해결한 이후에는 다시 이 프로덕트가 장애가 나지 않도록 필요한 과제들을 발의해나가며 다양한 방식으로 메꿔나감으로써 프로덕트의 생명주기를 예측 및 관리 가능한 수준에서 관리하게 된다.

누군가 나에게 말했던 것같다. 리소스가 무제한이면 공학이 필요없다고... 리소스가 제한적이기 때문에 최소한의 리소스를 활용해서 붕괴시점이 예측가능한 다리를 만들어야 하고 그래서 공학이 필요하다고 말이다. 리더는 그 시점을 알고 활용할 수 있는 역량이 필요하다.

프로덕트의 규모가 커지게 되면 리더 외에 많은 시니어가 존재할 수 있기 때문에 이런 고민은 보다 정교해질 필요가 있다. 하여 시니어로부터 프로덕트의 다양한 아이디어를 수렴하고 커뮤니케이션을 위 아래로 잘 흐르게 해야 한다.

아래 내용은 "실리콘밸리에선 어떻게 일하나요?"라는 책에서 발췌한 내용으로 리더가 모든 문제의 Detail을 싸매고 해결하고 또 관리할 수 없기 때문에 아래와 같이 적절히 시니어를 활용함으로써 시너지를 유도함으로써 대형 프로덕트의 유지 관리가 가능해진다.

자본잠식이라는 재무 관련 용어가 있다. 자본잠식이 발생하더라도 결손금으로 처리하고 사업 성장성을 감안해서 3~5년 정도는 수익 창출이 되지 않아도 사업 초반이기에 관계 기관도 어느 정도 용인해준다. 하지만 이러한 상태가 지속되면 금융기관의 대출 제한, 법인 신용평가등급 하락 등의 불이익이 생길 수 있다. 따라서 단기로는 해결하지 못하더라도 장기로는 반드시 해결해야 하는 것이 자본잠식이다.

기술부채도 동일하다.단기적으로는 이런 것들이 문제가 되지는 않는다. 오히려 더 나은 퍼포먼스를 줄 수도 있다. 하지만 장기적으로 확장성이나 안정적인 관리를 위해서는 반드시 해결하지 않는다면, 프로덕트에 대한 고객을 포함한 주요 이해관계자들의 신뢰도는 하락할 것이기에 반드시 관리를 해야 한다. 팀내 구성원과의 적절한 커뮤니케이션 역시 꾸준히 동반되어야 한다.

이런 독성을 감안하더라도, 버그나 기술부채를 기업의 영속성을 담보하기 위한 비즈니스 목표 아래 지속해서 활용하고 관리하는 것이 리더이면서 시니어 개발자로서 의무일 것이다. 이전에 언급하였던 바와 같이 많은 책들이 완벽한 제품보다 중요한 제품을 만드는 것이 더 높은 우선순위를 가짐을 공통적으로 말하였기 때문이다.