퇴사를 바라보는 또다른 관점
그 사람은 왜 퇴사를 선택했을까? 퇴사로 바라보는 팀빌딩 실험과정
1.
회사 팀빌딩의 과정에서 퇴사하는 인원이 발생하기도 한다. 그러나 퇴사 자체를 문제라고 생각할 필요는 없다. 오히려 그들이 왜 퇴사를 선택하게 되었는지를 확인하는 기회가 되어주기 때문이다. 실제로 내가 진행한 실험 들 중 하나는, 일반적으로 봤을때 미친짓이나 다름없는 일이었다. 퇴사자에게 '어떤 이유에서 퇴사를 결심하게 되었는지. 회사에 들어와서 업무하던 과정에서 힘겨웠던 내용을 자유롭게 적어달라고 했던 것이다. 강한 어조로 이야기하거나, 심지어 욕을 쓰더라도 괜찮다고 했다. 그 결과 꽤나 흥미로운 결과가 나왔다. 기존의 관리체계에서 어떤 헛점이 있었는지. 이전 작업자들 사이에 어떤 일들이 있었는지를 알게된 것이다.
대부분의 공통점을 정리해보면, 가장 큰 문제점은 개발 리더의 부재. 그리고 체계화된 문서화가 없다는 지점이었다. 내부에서 무엇을 어떻게 개발하는가에 대한 체계가 없으니, 주먹구구식의 개발을 진행하게되었고, 그 부분이 다시 새로운 개발자에게 남겨진다. 기획서가 제대로 완성되지 않은 상태에서 작업을 하거나, 소수 인원만 특정 기능을 알고있는 경우도 많았다. 전반적으로 PM 역할을 할 사람이 없어서 생긴 문제라는걸 알 수 있었다. 그렇다면 PM 역할만 있으면 처리가 되는걸까? 사실 꼭 그렇지는 않았다. PM과 개발 리더의 부재는 서로 엄연히 다른 지점이기 때문이다.
디자인과 기획의 분야에서라면, 내가 직접 강의를 해도 좋으니 뭐든 해결할 수 있다고 생각했다. 하지만 개발의 영역에서는 내가 할 수 있는 일이 없었다. 개발 리더라고 부를 수 있는 사람이 없는 상태였으니까. 그들이 보고 배울 '롤모델'이 없었던 것이다. 그런 상황에서는 자신이 코딩을 하더라도 이게 맞는 방향인지, 좋은 구조인 건지 알 수가 없다. 깜깜한 방 안에서 혼자 걷는 것과 비슷한 상황이니까. 신입 개발자라면 힘들 수 밖에 없었다. 게다가 개발자들끼리의 개발 스택을 고려하지 않고, 새로운 기술을 막무가내로 교육시킨 것도 문제였다. 대체 왜 이 사람에게 이 기술을 가르친건가 싶을 정도로, 퇴사자가 남긴 글에는 이해가 가지 않는 내용들이 많았다. 그리고 나중에서야 개발 스택에 대한 이해도가 부족한 사람이, 개발 리더였었다는걸 알게됐다.
2.
대체 큰그림 없이 어떻게 개발을 했던걸까? 개발 리더였던 사람에 대해 여러가지 궁금증이 생겼다. 기획서에는 로직이 빠져있었고, 서버와 DB의 관계도조차 정리되어있지 않았다. 누가 무슨 작업을 하는건지. 어떤 것을 왜 해야하는지. 너무나 당연한 질문을 하는것 조차 '바쁘다는 이유'로 잘려나갔다. 이런 식으로 '도움을 주기는 커녕, 윽박지르는 상사'가 남아있으니, 신입 개발자가 나가는건 당연한 결과였다. 대체 그럼 이 사람들은 '무슨 이유로' 이런 짓을 반복했던 걸까? 상식적으로는 이해할 수 없었기에, 그들이 특이한 상황에 놓였었거나. 혹은 '물경력 + 연차 사기꾼'이 아니었는가를 생각하게 만들었다.
연차는 쌓였는데, 할 수 있는 일은 없고, 만만한 회사에 들어가 '자신이 아는 선에서' 업무를 처리하는 사람들. 이런 사람들을 나는 물경력 + 연차 사기꾼이라고 부른다. 이들은 처음부터 나쁜 사람들이었던건 아니다. 단지 제대로된 교육을 받지 못했거나, 방법을 터득하지 못했을 뿐이다. 하지만 그 과정에서 '이정도만 일해도 돈을 벌 수 있다'는 사실을 알아버린다. 그리고 어느 회사에 들어가더라도, 자신이 해왔던 수준의 업무를 반복한다. 더 나아지려는 기회를 찾기보다, 이미 아는 것들을 반복해서 돈을 버는 방식을 택하는 것이다. 그리고 이런 사람들이 '오랫동안 회사에 남아있게 되면' 문제가 더욱 심각해진다.
회사 업무와 자신의 삶의 밸런스를 찾는건 좋은 일이라고 생각한다. 각자 삶의 목표는 다른거고, 그중 하나가 자신의 삶 자체에 집중하는 것일 수도 있으니까 말이다. 하지만 삶의 행복감을 추구하는만큼 '배우는 과정'이 늦어진다는걸 얼마나 인식하고있는지는 생각해볼 필요가 있다고 생각한다. 나이가 든다는것. 연차가 쌓인다는건 그만큼 '책임져야할 것들이 늘어난다'는걸 의미한다. 남들이 하는 수준에서, 인터넷을 검색해서 나오는 수준에서 업무를 처리하는 사람이 어떻게 팀을 이끌어나갈 수 있을까? 회사에서 처리한 업무나, 문제해결과정을 되돌아보거나. 그 방식이 '좋은 방식이었는지' 생각해보지 않는다면, '시간이 지난다고' 과연 그 사람이 더 나은 방식을 찾을 수 있을까? 나는 이 지점에 대해 '단언코 그럴리 없다'고 생각한다.
3.
팀원을 리드해야하는 시간은 언젠가는 오게된다. 문제는 그떄 스스로가 그런 역할을 할 수 있을만한 준비가 되어있느냐는 거다. 내가 아는 것들을 상대에게 알려줘야할 때. 그리고 그보다 더 나은 방법을 찾아야할 때. 자신이 알고있는 방법, 그 이상의 내용을 어떻게 남에게 가르칠 수 있을까? 말 그대로 아는게 없으니 가르칠 수도 없는 시기가 온다. 이 부분이야말로 '연차가 쌓이는 만큼' 준비해야하는 것들이 많아지는 이유다. 회사에서는 누군가를 이끌고 가르치며 내 일까지 해야하는 시기가 온다. 그리고 그 때는 선택을 해야한다. 내 업무 시간을 쪼개어가며 다른 사람을 가르쳐야할지. 아니면 무능력한 팀장이 되면서 내 할일만 처리할 것인지. 그리고 결국 이런 '무능력한 팀장'은 오랫동안 회사에 머물 수가 없다. 팀원들이 터져나가는 시기가 오기 때문이다.
결국 '신입 직원'이 퇴사를 하게되는 상황은, 무능력한 리더가 존재한다는 증거다. 그리고 무능력한 리더가 '남아있을 수 있도록' 내버려둔 회사 시스템의 문제를 보여주기도 한다. 가능하면 빠른 시기에 문제점을 찾아내고, 초기에 해결을 해야겠지만, 나중에 회사에 들어온 사람 입장에서는 할 수있는 일이 별로 없다. 그저 새로 뽑을 사람들은 물경력이 아닌 사람을 뽑기 위해 '충분한 준비를 해야할 뿐'. 이런 상황이 반복된다면, 그 상황을 막지 못한 나자신도 무능한 사람이라는 이야기가 된다.
결국, 내가 누군가의 퇴사를 바라보는 관점은 이렇다. 퇴사를 하게된 이유를 명확하게 파악하고, 똑같은 문제가 반복되지 않도록 준비해야한다는 것이다. 대부분의 퇴사자는 충분한 교육과 상담이 존재했더라면, 일어나지 않았을 일들이 많다. 그런 지점에서는 안타깝지만, 동시에 '이런 일들이 발생하게 만든' 회사의 시스템을 어떻게 바꿔야하는지. 무엇을 주의해야할지를 고민하게 만드는 지점이다. 결국이 사람이 무얼 원하는지. 어떤 것들을 추구하는지를 파악해야하기 때문이다.
-
항상 생각하는거지만, 개발자들에게 메리트가 될만한 것들은 흔치 않다. 지식적인 지점에서, 경험적인 지점에서 '이 회사에 와야할 이유'를 만들어내려면, 어떻게 해야할까? 이 회사에 머물러야 할 '이유가 되어주는 사람'을 찾으려면 대체, 무엇을 준비해야하는 걸까?
