내가 만약 한달 동안 휴가를 간다면 회사에서는 무슨 일이 벌어질까? 각자 한번 상상을 해보자.
내가 있던 없던 상관없이 회사는 잘 돌아갈까? 아니면 내가 관련된 일들이 진행되지 않아서 회사가 마비가 될까? 내가 없으면 회사가 잘 안 돌아가도 문제지만 내가 있으나 없으나 회사가 아무 일 없이 잘 돌아가도 불안하다. 혹시 내가 없어도 되는 사람이 아닌가 걱정이 되기도 한다.
“유지보수가 어렵게 코딩하는 방법” 이란 책도 있다. 원제는 “How to write unmaintainable code : Ensure a job for life ;-) This essay is a joke!”이다. 이 책은 조크이지만 내가 없으면 유지보수가 몇배, 몇십배 어려워지는 온갖 다양한 방법을 소개하고 있다. 사실 본인도 유지보수가 어려워지는 방법들이다.
몇 년에 한번씩 강제로 한달 동안 휴가를 가야 하는 회사가 있다. 휴가기간 한달 동안 원격지에서 일을 할 수 있다는 것이 아니다. 진짜 휴가를 가야 한다. 이런 강제 휴가제도를 만든 이유는 어느 직원이던지 그 직원이 없어도 회사가 잘 돌아가야 하기 때문이다. 업무의 특수성 때문에 한달 동안 자리를 비울 수 없는 직원이 있다면 회사의 조직을 바꾸던지 프로세스를 바꿔서 다른 사람으로 대체가 가능하거나 보완이 가능하도록 한다. 누구든지 한달간 휴가를 떠나도 아무런 문제가 없이 해놔야 한다.
이런 회사에서는 직원들이 언제든지 짤릴 수 있다는 불안감을 가져야 할까?
가상의 이야기가 있다. 원자력 발전소에서 일하는 홍길동은 절대로 3일 이상 휴가를 갈 수 없다. 홍길동은 오랜 노하우로 적절하게 원자로의 온도를 조절하는 특수한 능력을 가지고 있고 홍길동 외에는 그런 기술이 없다고 하자. 홍길동은 수동으로 온도 제어장치 조절이 가능한데 자동 처리 시스템을 갖추려면 엄청난 비용과 많은 추가 인력이 필요하다고 한다. 회사 입장에서는 큰 비용을 투자 하는 것보다 홍길동만 잘 유지하면 적은 비용으로 발전소 운영이 가능하고 홍길동은 자신이 없으면 발전소가 돌아가지 않는 상황에 자부심을 가지고 있다. 하지만 홍길동은 격무에 시달려서 회사를 그만두거나 불의의 교통사고를 당할 수도 있다. 옆 나라의 발전소에서 더 높은 연봉으로 데려갈 수도 있다.
나는 강연이나 세미나를 할 때 자주 묻는다. “지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람”. 그러면 거의 대부분 손을 드는 사람이 없다. 실제로 퇴사를 해도 문제가 없는 사람이 없을 수도 있고 다른 사람들 눈치를 보기도 한다.
반대로 “그럼 당장 퇴사하면 회사가 안 돌아가는 사람” 손을 들라고 하면 몇 사람들이 당당하게 손을 번쩍 든다. 몇 사람은 떠밀려서 손을 든다. 그러면서 주변에서는 웅성웅성 말들이 많아진다. 약간의 빈소적인 말도 들려온다. 대부분의 회사에서 공통적인 현상이다.
우리 주변의 소프트웨어 회사들 중에는 개발자 한두명만 퇴사를 해도 큰 영향을 받는 회사가 많다. 회사의 경영진은 문서화도 잘되어 있고 공유도 잘 되어 있어서 문제 없다고 하는 경우도 있지만 속을 들여다 보면 유지보수에 별 쓸모도 없는 문서에 공유는 형식적으로 되어 있어서 실제로는 큰 문제지만 “쉬쉬” 하는 경우가 많다. 개발자들도 자신이 없을 때 회사가 잘 안 돌아가는 상황을 그렇게 나쁘게만 보지 않기 때문에 별 이슈로 생각하지 않는다.
이러한 현상 때문에 아버지가 돌아가셨는데 상중에도 회사를 나와서 일을 했다는 경우를 들기도 하고 신혼여행도 제대로 못가는 경우도 발생한다.
그럼 이런 현상이 회사에는 불리하지만 개발자에게는 유리한 현상일까? 단기적으로는 그렇게 생각할 수 있지만 장기적으로는 얘기가 완전히 달라진다.
나는 “당장 퇴사하면 회사가 안 돌아가는 사람”은 하루 빨리 정리를 해야 하고, “지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람”은 회사에 꼭 필요한 사람이라고 얘기한다. “당장 퇴사하면 회사가 안 돌아가는 사람”이 많다면 회사가 갑자기 망해도 이상하지 않은 상황이다. 이렇게 망한 회사들은 이런 이유 때문에 망한 것이라는 것을 알아채기는 쉽지 않다.
“지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람” 중에는 정말로 하는 일이 없어서 있으나 마나 한 사람이 있을 수도 있지만 그건 주제에서 벗어난 얘기고 대부분 그 동안 해왔던 일들이 문서화가 잘 되어 있고, 공유가 잘되어 있으며 다른 사람이 이어 받아서 처리하는데 문제가 없는 경우다. 이런 사람은 회사의 미래의 프로젝트를 위해서 꼭 필요한 사람이다.
반대의 경우는 그 동안 저질러 놓은 일이 많고 자신이 아니면 유지가 안 된다. 뭘 하나 해결하려고 해도 원 개발자에게 물어봐야 하고, 다른 사람들은 시스템에 대해서 이해하기도 어렵고 원 개발자가 한두 시간이면 뚝딱 해결할 수 있는 것을 유지보수 개발자에게 시키면 며칠이 걸려도 해결이 어렵고, 해결을 했다고 해도 또 다른 문제를 만들어 냈을까봐 두렵다. 회사입장에서는 큰 리스크가 아닐 수 없없다. 하지만 회사에서는 이런 개발자를 핵심 개발자라고 착각하고 질질 끌려 다닌다.
물론 개발자가 일부러 이런 경우는 흔치 않다. 회사의 문화, 프로세스가 엉망이니 그냥 열심히 하던 대로 개발을 하다 보면 이런 현상은 십중팔구 일어난다. 특히나 개발 능력이 뛰어난 개발자들에게서 이런 현상이 더 잘 일어난다. 혼자서 많은 양의 코딩을 해내지만 같이 공유하고 리뷰를 해줄 개발자가 없고, 혼자서 제품 하나를 뚝딱 만들어도 유지보수에서 발을 빼기 어렵게 된다. 일부러 유지보수가 어렵게 코딩하는 사람은 없겠지만 작성해놓은 코드를 보면 “유지보수가 어렵게 코딩하는 방법” 이란 책을 공부한 사람처럼 코딩하는 경우도 있다.
이렇게 자신의 과거 업무에 발목이 잡혀있는 개발자들은 앞으로 나아가면서 성장하기 어렵다. 회사의 미래 프로젝트, 좀더 어렵고 재미있는 일을 못하게 된다. 새로운 기술이나 지식을 익힐 기회는 점점 줄어들고 매일 하던 반복적인 유지보수에 매달리거나 과거에 해놓은 일의 기억을 헤집는 일을 주로 하게 된다. 자신의 과거의 업무에서 자유로워지는 일은 자신의 가치를 좀더 높이는 일이다.
물론 우리나라 회사에서는 이런 것이 통하지 않는다고 주장하는 사람도 있을 것이다. 개발자를 부품으로만 생각하는 회사는 개발자가 없어도 문제없게 만들어 놓은 개발자는 언제든지 자를 수 있다. 실제 이런 회사도 많이 있고 이런 회사에서 일하는 개발자라면 “유지보수가 어렵게 코딩하는 방법”을 잘 공부하기를 바란다.
개발자가 자신이 없어도 회사가 문제 없이 돌아가게 하려면 공유를 잘 해야 한다. 문화적으로 성숙되고 프로세스를 잘 갖춘 회사라면 모든 개발업무가 진행되면서 자연스럽게 공유가 되는 시스템을 갖추고 있다. 중간 중간 리뷰 과정을 다 거치고 문서화가 되며 지식과 경험이 자연스럽게 여러 사람과 공유가 된다. 이런 프로세스를 뒷받침할 기반시스템도 적절히 갖추고 있다. 공유를 위한 공유가 아니기 때문에 훨씬 자연스럽고 부담도 없다.
자신은 어떤가 생각을 해보자. 한달간 휴가를 갈 수 있을까? 회사의 모든 직원이 각자 한달간 휴가를 갈 수 있을까? 그렇지 않다면 무엇을 바꿔야 할지 생각해보자.
