개발자가 한달 쉬어도 끄떡없어야 좋은 회사

전규현

내가 만약 한달동안 휴가를 간다면 회사에서는 무슨일이 벌어질까? 각자 한번 상상을 해보자.

내가 있던 없던 상관없이 회사는 잘 돌아갈까? 아니면 내가 관련된 일들이 진행되지 않아 회사가 마비될까? 내가 없으면 회사가 잘 안돌아가도 문제지만 내가 있으나 없으나 회사가 아무일 없이 잘 돌아가도 불안하다. 혹시 내가 없어도 되는 사람이 아닌가 걱정이 되기도 한다.

“유지 보수가 어렵게 코딩하는 방법” 이란 책도있다.원제는“How to write unmaintainable code : Ensure a job for life ;-) This essay is a joke!”이다. 이 책은 조크지만 내가 없으면 유지보수가 몇배, 몇십배 어려워지는온갖 다양한 방법을 소개하고 있다. 사실 본인도 유지보수가 어려워지는 방법들이다.

몇년에 한번씩 강제로 한달동안 휴가를 가야하는 회사가 있다. 휴가 기간 한달동안 원격지에서 일을 할 수 있다는 것이 아니다. 진짜 휴가를 가야 한다. 이런 강제 휴가 제도를 만든 이유는 어느 직원이던 그 직원이 없어도 회사가 잘 돌아가야 하기 때문이다. 업무의 특수성 때문에 한달동안 자리를 비울 수 없는 직원이 있다면 회사 조직을 바꾸던지 프로세스를 변경해 다른 사람으로 대체나 보완이 가능하도록 한다. 누가 한달간휴가를 떠나도 아무 문제없이 해놔야 한다.

이런 회사에서는 직원들이 언제든지 짤릴 수 있다는 불안감을 가져야 할까?

가상의 이야기가 있다. 원자력발전소에서 일하는 홍길동씨는 절대로 3일이상 휴가를 갈 수 없다. 홍길동은오랜 노하우로 적절하게 원자로의 온도를 조절하는 특수한 능력을 가지고 있고 홍길동외에는 그런 기술이없다고 하자. 홍길동은 수동으로 온도제어장치 조절이 가능한데 자동 처리 시스템을 갖추려면 엄청난 비용과 많은 추가 인력이 필요하다고 한다.

회사 입장에서는 큰 비용을 투자하는 것 보다 홍길동씨만 잘 지키면 적은 비용으로 발전소 운영이 가능하고홍길동씨는 자신이 없으면 발전소가 돌아가지 않는 상황에 자부심을 가지고 있다. 하지만 홍길동씨는 격무에 시달려서 회사를 그만두거나 불의의 교통사고를 당할 수도 있다. 옆나라의 발전소에서 더 높은 연봉으로데려갈 수도 있다.

나는 강연이나 세미나를 할 때 자주 묻는다. “지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람?”. 그러면거의 대부분 손을 드는 사람이 없다. 실제로 퇴사를 해도 문제가 없는 사람이 없을 수도 있고 다른 사람들 눈치를 봐서 그랬을 수도 있다.

반대로“그럼 당장 퇴사하면 회사가 안돌아가는 사람”손을 들라고 하면 몇사람들이 당당하게 손을 번쩍 든다. 몇 사람은 떠밀려서 손을 든다. 그러면서 주변에서는 웅성웅성 말들이 많아진다. 약간의 빈정적인 말도들려온다. 대부분의 회사에서 벌어지는 공통적인 현상이다.

우리 주변의 소프트웨어 회사들 중에는 개발자 한두명만 퇴사를 해도 큰 영향을 받는 회사가 많다. 회사의경영진은 문서화도 잘 되어 있고 공유도 잘 되어 있어 문제없다고 하는 경우도 있지만 속을 들여다보면 유지보수에 별쓸모도 없는 문서에 공유는 형식적으로 되어 있어 실제로는 큰 문제지만 “쉬쉬”하는 경우가 많다. 개발자들도 자신이 없을 때 회사가 잘 안돌아가는 상황을 그렇게 나쁘게만 보지 않기 때문에 별 이슈로생각하지 않는다.

이러한 현상 때문에 아버지가 돌아가셨는데 상중에도 회사를 나와서 일을 했다는 경우를 듣기도하고 신혼여행도 제대로 못가는 경우도 발생한다.

그럼 이런 현상이 회사에는 불리하지만 개발자에게는 유리한 현상일까? 단기적으로는 그럴수 있으나 장기적으로는 얘기가 완전히 달라진다.

나는“당장 퇴사하면 회사가 안돌아가는사람”은 하루빨리 정리를 해야하고, “지금 당장 퇴사를 해도 회사에큰 문제가 없는사람”은 회사에 꼭 필요한 사람이라고 얘기한다. “당장 퇴사하면 회사가 안돌아가는 사람”이많다면 회사가 갑자기 망해도 이상하지 않은 상황이다. 이렇게 망한 회사들은 이런 이유 때문에 망한 것이라는 것을 알아채기 쉽지않다.

“지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람”중에는 정말로 하는 일이 없어서 있으나 마나 한 사람이 있을 수도 있지만 그건 주제에서 벗어난 얘기고 대부분 그동안 해왔던 일들이 문서화가 잘되어 있고, 공유가 잘 되어 있으며 다른 사람이 이어 받아서 처리하는데 문제가 없는 경우다. 이런 사람은 회사의 미래 프로젝트를 위해 꼭 필요한 사람이다.

반대의 경우는 그동안 저질러 놓은 일이 많고 자신이 아니면 유지가 안된다. 뭘 하나 해결하려고 해도 원개발자에게 물어봐야 하고, 다른 사람들은 시스템에 대해서 이해하기도 어렵고 원개발자가 한두시간이면 뚝딱 해결할 수 있는 것을 유지보수 개발자에게 시키면 며칠이 걸려도 해결이 어렵고, 해결을 했다고 해도 또다른 문제를 만들어냈을까봐 두렵다. 회사입장에서는 큰 리스크가 아닐 수 없다. 하지만 회사에서는 이런 개발자를 핵심 개발자라고 착각하고 질질 끌려다닌다.

물론 개발자가 일부러 이런 경우는 흔치 않다. 회사의 문화, 프로세스가 엉망이니 그냥 열심히 하던대로 개발하다 보면 이런 현상이 십중팔구 벌어진다. 특히나 개발능력이 뛰어난 개발자들에게서 이런 현상이 더 잘일어난다. 혼자서 많은 양의 코딩을 해내지만 같이 공유하고 리뷰를 해줄 개발자가 없고, 혼자서 제품 하나를 뚝딱 만들어도 유지보수에서 발을 빼기 어렵게 된다. 일부러 유지보수가 어렵게 코딩하는 사람은 없겠지만 작성해놓은 코드를 보면 “유지보수가 어렵게 코딩하는 방법” 이란 책을 공부한 사람처럼 코딩하는 경우도 있다.

이렇게 자신의 과거 업무에 발목이 잡혀 있는 개발자들은 성장하기 어렵다. 회사의 미래 프로젝트, 좀더 어렵고 재미있는 일을 못하게 된다. 새로운 기술이나 지식을 익힐 기회는 점점 줄어들고 매일하던 반복적인 유지보수에 매달리거나 과거에 해놓은 일의 기억을 헤집는 일을 주로 하게 된다. 자신의 과거 업무에서 자유로워지는 일은 자신의 가치를 좀더 높이는 일이다.

물론 우리나라 회사에서는 이런 것이 통하지 않는다고 주장하는 사람도 있을 것이다. 개발자를 부품으로만생각하는 회사는 개발자가 없어도 문제없게 만들어 놓은 개발자는 언제든지 자를 수 있다. 실제이런 회사도많이 있고 이런 회사에서 일하는 개발자라면 “유지 보수가 어렵게 코딩하는 방법”을 잘 공부하기 바란다.