직원 한 명이 나갔는데, 모든 개발이 멈추었다.

가끔 유능한 직원이 제품의 상당 부분을 혼자 개발하거나, 많은 업무량을 처리할 때가 있습니다. 특히 제가 좋아하는 스타트업에서는 아주 흔한 일입니다. 그런 직원은 정말 고마운 직원인 동시에 정말 무서운 직원이기도 합니다. 핵심 멤버가 이탈하여 1년간 제품 업데이트가 되지 않기도 하며, 아예 처음부터 다시 만들어야 하는 경우도 발생하기도 하기 때문이죠.

왜 이런 상황이 발생하는 것일까요? 다른 업계는 제가 잘 알지 못합니다. 다만 IT 회사는 제가 짧지만, 경험한 바가 있기 때문에 IT업계 이야기를 해보고자 합니다.

프로그래머가 작성한 소스코드는 해석하기가 굉장히 어렵습니다. 코드를 작성할 당시의 사고방식 그대로 소스코드를 작성하기 때문에 사고방식과 표현 방식이 동일하지 않는 한, 동료 개발자가 여러분의 코드를 한 번에 이해하기는 힘듭니다. 심지어 하루 전 자신이 작성한 소스코드도 이해하는 것에 어려움을 겪기도 하는 경우가 매우 흔합니다.

이러한 이유에서 개발자들은 기본 교양 중에 한 가지가 주석 작성입니다. 소스코드를 작성하면, 이 코드가 어떤 역할을 하는지 설명을 적어두는 것이죠. 주석만 잘 작성되어 있다면, 소스코드를 해독할 시간을 아낀 것이니 아주 훌륭한 경우입니다.

하지만 아쉽게도 회사가 만든 프로그램의 소스코드는 수만 라인을 넘어가는 경우가 대다수입니다. 그래서 주석이 작성되어 있다 하더라도 모두 다 읽고 이해하는 것은 아주 버겁습니다. 그리고 코드를 모두 다 이해했을지라도, 특정 기능을 업그레이드하거나 수정하게 되면 프로그램 전체가 오작동을 하는 경우도 많습니다.

이렇게 오류를 만들어낸 프로그래머는 엄청난 심리적 압박감과 스트레스를 느끼게 됩니다. 이를 해결할 방법은 없을까요?

프로그래머들은 이러한 상황을 해결하기 위해 많은 고민을 했고, 그 덕분에 TDD(Test Driven Development)라는 개념을 만들었습니다. 이는 프로그램을 만들 때, 모든 소스코드가 정상 작동하는지 점검하는 점검 프로그램도 함께 만드는 개념입니다. 만들고자 하는 프로그램과, 점검 프로그램을 동시에 같이 만들어야 하니 TDD는 시간이 오래 걸리며 실무에 적용하기 힘들다는 평가를 많이 받았습니다. 하지만 개발자들은 이를 적용해보고 경험하면서 이 개념이 장기적인 관점에서는 아주 유리하다는 결론을 내리게 되었습니다. 점검 프로그램만 잘 만들어두면, 소스코드를 수정했을 때 나타나는 버그를 찾아내고 해결하는 속도가 아주 빨라졌으며 이 덕분에 개발자의 스트레스 또한 줄어들었기 때문입니다.

다시 본론으로 돌아와, 직원 5명 중에 1명이 이탈했을 때 업무 처리 속도가 80%로 줄어드는 것이 아닌 0% 정도로 회사가 마비가 된다면 이는 조직 문화와 시스템에 큰 문제가 있다는 의미입니다. 그렇기 때문에 리더는 개발자들의 TDD 문화와 같이 지속 가능한 개발을 할 수 있는 장치를 공부하고 적용해야만 업무가 원활히 잘 될 수 있습니다.

여러분의 조직은 어떠한가요? 핵심 멤버가 사라지면 회사가 휘청거리게 되나요? TDD와 같이 여러분이 알고 계시는 방법이 있다면 댓글로 남겨주시면 정말 감사드리겠습니다.

좋은 하루 보내시길 바랍니다.