고참은 유지보수를 하고 신참들이 신제품을 개발하는 모습을 어렵지 않게 볼 수 있다.

고참들이 경험도 많고 신제품을 만드는데 더 적임이지만 그럴 수 없는 이유가 있다.

기존 제품의 유지보수에서 도저히 빠져나갈 수 없는 것이 그 한 이유이다. 간단한 업그레이드가 아니고 완전히 새로운 제품을 만들려고 하는 이유도 기존 제품이 유지보수가 너무 복잡하고 기능을 추가하거나 수정하기에 아키텍처가 더이상 감당이 안되기 때문인 경우가 많기 때문이다.

현 제품의 유지보수는 당장 회사의 생존이 달린 문제이기 때문에 신제품이 개발되기 전까지는 고참들이 버텨줘야 한다. 문제는 자칫하면 신제품이 기존 제품보다 훨씬 못하는 경우가 종종 벌어지는 것이다.

이렇게 고참들이 유지보수에서 빠져 나오지 못하는 이유는 무엇인가?

첫째, 유지보수 문서의 부실이다.

고참들은 수시로 기존 제품의 유지보수에서 빠져나오기 위해 온갖 인수인계 노력을 한다. 하지만 쉽지 않고 성공적인 인수인계가 잘 이루어지지 않는다. 인수인계를 위해서 작심을 하고 유지보수에 관련된 모든 내용을 문서화하고 교육도 한다. 하지만 후배들은 그 문서를 보고 유지보수를 잘 해내지 못한다.

개발할 때 개발을 위해서 작성한 문서가 아니고 차후에 유지보수를 위해서 만드는 문서는 제대로 작성하기가 어렵다. 수많은 내용이 빠져도 알아챌 수가 없고 정성껏 작성하기도 어렵다. 문서는 개발 중에 그 때가 아니면 다시 작성하는 것은 거의 불가능하다. 그런데 이미 그 때를 놓쳤기 때문에 유지보수를 위한 제대로 된 문서를 다시 만들어 내기란 몇배 어려운 일이 되어 버렸다.

둘째, History의 부재이다.

또, 그동안 유지보수 History가 잘 기록되어 있으면 다행이지만 그렇지 않은 경우 유지보수 인수인계가 어려워진다. Mantis, Jira, Redmine 등의 이슈관리시스템에 유지보수를 포함한 모든 개발 History가 기록되어야 한다. 이슈관리시스템을 쓴다고 해도 100% 사용하지 않으면 안된다. 소스코드를 한줄이라도 고친 내용은 모두 이슈관리시스템에 기록이 남아 있어야 한다.

셋째, 복잡한 Architecture이다.

첫번째 버전에서 시장의 요구에 따라서 기능이 덕지덕지 붙다보면 어쩔 수 없이 컴포넌트의 구분도 없고 인터페이스가 보통 복잡해지는 것이 아니다. 오랫동안 유지보수를 해온 개발자가 아니면 이를 제대로 파악하기가 어렵다. 그러다보니 고참이 계속 유지보수를 하는 것이다.

이 또한 처음 개발 당시부터 미래의 비즈니스 전략을 고려하여 컴포넌트를 잘 나누어서 깨끗하게 개발을 해야 한다. 그렇지 않으면 아무리 유지보수를 위한 문서를 잘 작성하여도 어려운 상황이 된다.

이런 상황이 계속되다보면 기존에 열심히 일하던 고참들도 즐겁게 일하지 못하고 보람도 떨어지면서 이탈이 많이 일어난다.

가끔은 이렇게 소수의 핵심인력에 회사가 전적으로 의지하는 시스템을 본인들이 원하기도 한다. 하지만 이런 현상은 나중에 본인들의 발목도 잡고 회사의 큰 리스크가 된다.

해결책은 원인의 반대이다.

개발 당시 스펙/설계 문서를 제대로 작성하고 컴포넌트를 잘 나눠서 개발을 하고 소스코드관리시스템과 이슈관리시스템을 사용해서 모든 기록을 남기고 투명하게 개발하면 되는 것이다. 그렇게 되면 유지보수 단계가 아니라 구현단계에서도 다른 사람들이 얼마든지 도와줄 수 있고 분석이나 설계만 하고 빠져나와 다른 프로젝트를 수행할 수도 있다.

내가 지금 퇴사를 하면 회사에 무슨 일이 벌어지는지 한번 생각해보자. 당장 지금 진행 중인 프로젝트나 유지보수가 문제 없이 진행이 되면 회사에 가장 필요한 인재이다. 그렇지 않고 당장 큰 문제가 되면 당장은 꼭 필요하지만 동시에 회사의 리스크이므로 고민스럽지 않을 수 없다.