아름다운 퇴사

들어가는 구멍은 있는데, 나가는 구멍은 없다. 학생 때 동아리 사람들이 자주 하던 이야기입니다. 상당히 끈끈한 동아리였기 때문에 새로운 사람이 들어오는 것은 환영했지만 동아리를 떠나가는 것은 서운해 하고, 심지어 배신자 취급까지 하곤 했었습니다. 자유롭게 들어올 수 있고 나갈 수 있어야 하는 것이 동아리인데 동아리 조차 떠나는 것에 대한 동료 압박이 매우 크게 작용하는 것을 경험했었습니다. 그 때는 그게 당연하다고 생각 했었는데 졸업 후 생각 해 보니 매우 배타적인 동아리라는 생각이 들었습니다.

동아리가 그 정도인데  회사라고 다를까요? 많은 회사는 퇴사자를 배신자취급 합니다. 저 또한 그러한 취급을 여러 번 당했었습니다. 떠나는 사람 입장에선 애정을 갖고 함께 했던 사람들과 헤어지고 생계를 유지해 주었던 직장을 떠나는 것도 서러운데, 배신자 취급까지 받으면 그 서러움이 배가 될 것 같습니다.

입사하는 것은 쉽지만(상대적으로…) 퇴사하는 것은 어렵습니다. 특히 아름다운 퇴사는 나의 노력 뿐 아니라 주변 환경이 받쳐주지 않으면 불가능에 가깝습니다. 아름다운 퇴사를 하기 위해선 개인도 노력해야 하지만 회사도 함께 노력해야 합니다.

아름다운 퇴사를 위해선 회사가 먼저 노력해야 합니다. 어떤 이유든 퇴사자가 언제든 무리 없이 퇴사할 수 있도록 문을 열어 두어야 합니다. 

그렇게 하기 위해선 첫째, 업무의 결과물이 투명하게 관리 되어야 합니다. 업무의 결과물이 개인 PC에서 관리 되거나 공용 폴더의 안 보이는 곳에 꼭꼭 숨겨져 있다면 그 사람이 만들어 놓은 결과물을 회사의 자산으로 활용할 수 없게 됩니다. 결국 회사 입장에서 퇴사자는 회사에 기여를 하지 않은 것으로 판단하게 됩니다. 

둘째, 퇴사자의 업무는 평소에 인수인계가 되어 있어야 합니다. 평소에 인수인계가 되기 위해선 하나의 업무에 적어도 2명 이상이 관여하고 있어 별도의 인수인계 과정 없이도 퇴사할 수 있도록 해야 한다는 것입니다. 그래야 개인이 보유하고 있는 여러 노하우들이 퇴사와 함께 사리지지 않겠죠. 평소에 인수인계 하는 가장 쉬운 방법은 코드 설계자와 작성자 그리고 Reviewer를 분리하는 것입니다. 경험이 많은 아키텍트가 큰 그림을 그리고 API(Application Programming Interface) 또는 Block Interface를 정의하고, 개발자는 그걸 구현합니다. 그리고 Reviewer는 개발자가 구현한 코드를 작은 단위로 나누어 Review를 합니다. 이 체계가 원활하게 돌기 위해선 git과 같은 코드 관리 시스템을 매일의 업무에 적용하고 있어야 하고, Agile process와 같은 업무 관리 프로세스가 회사의 문화로 자리잡고 있어야합니다.

셋째, 회사의 경영진은 직원이 떠날 때 박수치며 보낼 마음의 준비를 하고 있어야합니다. 대부분의 개발자들에게 회사는 디딤돌에 불과합니다. 짧으면 몇개월, 평균 몇년, 길어도 몇십년 머물다 가는 손님입니다. 회사에 머물면서 인생의 한 부분을 뚝 떼어 주는 소중한 존재입니다. 따라서 회사를 떠날 때 박수치며 내 보내줘야 하지만 경영자 입장에선 그게 말처럼 쉽지 않은 것도 사실입니다.

아름다운 퇴사를 위해선 회사도 노력해야 하지만 직원도 노력해야 합니다. 더 좋은 회사로 이직하기 위해 회사를 떠나는 경우도 있지만 회사 안에서 평가가 낮아져 도망가듯 퇴사를 하는 경우도 많기 때문에 아름다운 퇴사는 정말 정말 어렵습니다.

직원 입장에선 첫째, 회사 내에서 좋은 평가를 받고 있어야합니다. (엄청 어려운 조건이죠…) 회사에서 당당히 자기 몫을 하고 있어야 퇴사도 자신있게 할 수 있습니다. 내가 좀 더 성장하기 위해, 좀 더 큰 물에서 놀기 위해 아쉽지만 회사를 떠난다 라고 당당히 이야기 할 수 있어야 합니다. 이럴 때 회사에서 붙잡진 않더라도 적어도 축복하며 보낼 수 있는 환경이 갖추어지게 됩니다. 아쉽게도 어떤 이유로든 업무 성과가 낮아져 직간접적인 퇴사 압박이 들어오기 시작하면 아름다운 퇴사를 하는 것이 점점 어려워집니다.

둘째, 자신의 기술을 무기화 하지 않아야 합니다. 일부 개발자들은 자신의 전문성을 활용해 회사에 족쇄를 채우려는 시도를 합니다. 어떤 경우는 의도적이기도 하고, 어떤 경우엔 무의적으로 하기도 합니다. 가장 쉬운 방법은 문서를 쓰지 않는 것입니다. 회사에서 문서를 먼저 쓰고 그 다음에 개발을 하도록 강제 하더라도 개발 과정에서 업데이트 되는 부분을 문서에 반영하지 않음으로써 문서 따로 코드 따로 놀도록 합니다. 문서도 쓸모 없어지고, 코드도 쓸모 없어지고, 코드를 보고 문서를 재구성 하느니 차라리 코드를 다시 씨는 것이 낫겠다 싶을 정도로 문서를 안 씁니다. 그 개발자가 회사를 떠나면 개발했던 상당 수의 결과물들이 무용지물이 되는 것은 아주 많은 회사들이 경험하는 것이고, 많은 회사들이 떠나는 개발자들에게 욕을 하는 이유입니다. 내가 만든 결과물들이 제품화 되어 시장에 출시되고, 그 결과물을 다른 사람들이 쓰도록 만들려면 문서와 코드 간의 Sync가 맞아야 합니다. 문서와 코드가 한 짝이 되어야 옆에 있는 다른 동료가 계속해서 제품을 유지보수하고 개발을 이어갈 수 있습니다. 내가 만든 결과물이 의미있게 활용 되려면 적어도 Documentation을 잘 해야 합니다. 문서 외에도 개발자가 자신의 기술을 무기화 하는 방법은 수 없이 많습니다. 의도적으로 어려운 약어 쓰기, 공식 용어가 아닌 은어를 사용하기, 읽기 힘든 코드 만들기 등등 시스템으로 걸러내기 어려운 소위 회사를 망하게 하는 방법은 전문성이 높아지면 높아질수록 기술력이 높아지면 높아질수록 노하우가 쌓입니다. 기술을 무기화 하지 않는 것은 알고는 있지만 하지 말아야 할 것을 하지 않는 것입니다.

셋째, 책임감 있는 행동을 해야 합니다. 내가 지금 빠지면 프로젝트가 어떻게 될까에 대한 최소한의 고민은 해야 합니다. 많은 경우 1개월 정도 여유를 두고 퇴사를 해야 하는 것이 한국 사회의 공통적인 인식입니다. 저는 그 정도까지 할 필요는 없다고 생각합니다. 문서와 코드 간의 Sync가 잘 맞고, 설계-개발-Reviewer가 분리 되어있고, 높은 기술력을 활용해 하지 말아야 할 것을 하지 않으면 한주 정도로도 충분히 인수인계가 가능합니다. 어떤 경우 그 동안 숨겨 놓은 과가 많아서 프로젝트 마무리를 할 자신이 없어서 프로젝트 직전에 퇴사를 하는 경우도 있습니다. 회사 입장에선 폭탄이고, 개발자 자신에게도 결코 좋지 않은 선택이라 생각합니다.

아름다운 퇴사는 참 어렵습니다. 회사도 준비가 되어있어야 하고, 직원도 마음의 준비를 하고 있어야 합니다. 그럼에도 제 주위의 여러명이 아름다운 퇴사를 하는 것을 목격했습니다. 저와 함께 일했던 양팀장은 S/W팀의 에이스였습니다. 양팀장에게 그 직장은 첫 번째 직장이었고 개발자로 시작해 실력을 인정받아 팀장까지 올라갔습니다. 팀장으로서 리더십도 훌륭해 여러명의 팀원들을 거느리며 제품 개발에 성과를 발휘했습니다. 어느날 양팀장은 저에게 퇴사를 하겠다고 밝혔습니다. 퇴사 이유를 묻자 외국계 기업으로 이직을 준비하고 있다는 답변을 들었습니다. 회사 입장에선 아쉽지만 양팀장이 가는 길을 제가 막을 권한은 전혀 없었습니다. 양팀장이 퇴사를 하고 얼마 뒤 외국계 회사에서 reference letter가 왔습니다. 저는 그 레터에 이렇게 적었습니다.

He was one of the best men in my company.

양팀장 외에도 퇴사 이후 지속적으로 연락하며 지내는 좋은 친구들이 있습니다. 아름다운 퇴사를 한 수 많은 개발자들이 여전히 제 친구로 남아 서로 연락하며 지냅니다. 무엇이 아름다운 퇴사일까요? 좋은 친구를 많이 남길 수 있으면 그 것이 아름다운 퇴사라고 생각합니다. 아름다운 퇴사를 해야지만 친구가 늘어납니다.