엔지니어링 레벨링은 누더기가 되었나?
엔지니어링 레벨링 제도가 어려운 이유에 관한 생각
Chanhee·
엔지니어링 레벨링 제도가 어려운 이유에 관한 생각
드롭박스의 엔지니어링 커리어 프레임워크가 세상에 나왔을 때, 많은 조직이 우리 조직에도 저런 것이 필요하다고 했다. 드롭박스는 직군 별로 필수 역량을 정의해 레벨을 나눴고, 개인 기여자(IC)와 매니저를 오갈 수 있는 트랙 구조를 만들었다.
나는 사람들이 크게 두 가지에 매료되었다고 생각한다.
레벨을 보면 무엇을 더 갖춰야 성장하고 보상받을 수 있는지 알 수 있을거야!
매니저가 되어야한다는 압박에서 해방이다! (IC로서 계속 기술을 갈고 닦기)
나 역시 처음에는 그렇게 생각했고 리더십에게 ‘성장을 위한 나침반’을 비유로 들며 발표를 했었다(도입은 안되었다). 하지만 몇 년이 흘러, 레벨 제도를 운영 중인 회사의 지인들이 불편함과 스트레스가 잔뜩 담긴 말을 하는 걸 보고 혼란스러워졌다.
스타트업에서 엔지니어링 레벨링 제도를 하기 어려운 이유가 있는 걸까? 만약 아니라면 우리는 무엇을 놓치고 있는걸까?
LEAN HR의 저자이자 회사 HR 리드인 용훈님은 내게 이런 말을 한 적이 있다. 개발자의 커리어 프레임워크가 성립하려면 사내에 ‘이 사람은 L9야’라고 입을 모아 말할 수 있는 사람이 있어야하는 것 같다고. 마치 Google의 Jeff Dean처럼.
이걸 롤모델이라고 퉁치면 많이 아쉬울 것 같다. 나는 조직이 사람들에게 바라는 모습을 제시하지 못하고 있는 것이 아닐까 생각했다.
역량에 관한 이야기는 많아도 기대하는 모습과 생각에 관한 이야기는 적다고.
무슨 일을 하면 일을 잘하는 사람이고, 무슨 말을 하면 커뮤니케이션을 잘하는 사람인가. 피상적인 느낌은 있지만 손에 잡히는 무언가가 없기에 느낌을 퍼트릴 수 없다.
그래서 기준점이 되어줄 대상을 찾는 것 같다. 하지만 그런 사람은 보통 보이지 않을 것이고, 있더라도 사람을 기준으로 삼는 것이 프레임워크의 정의에 부합하지는 않는 것 같다.
조금 뚱딴지 같은 소리기는 한데, 프레임워크를 아래에서 위로 함께 만들어나갈 수 있지 않을까. 비슷해보이는 사람일지라도 좋은 동료라면 그만의 좋은 점, 그에게서 닮고 싶은 점이 있을 것이다. 그걸 함께 찾고 나에게 적용해보는 것부터 시작하면 어떨까.
코드의 수명보다 회사의 수명이 짧다는 전제가 필요한 것 같다. 피벗으로 제품 혹은 기능이 바뀔 수 있다. 회사가 남은 런웨이를 모두 소진하고 폐업할 수도 있다. 그런 모습을 자주 찾아볼 수 있다.
생존해서 다음의 번영을 누려야 하는 상황이라면 엔지니어들의 레벨링이 그다지 중요하지 않을 것이다. 설령 이를 적용한다고 해도, 두 가지 문제를 만나게 될 것 같다는 생각이 들었다.
먼저, 지금 단계에 꼭 필요하지 않은 사람을 부르게 될 수 있다.
M5가 있으면 좋을 것 같아 채용을 했다고 해보자. 막상 그가 해야하는 일은 IC3의 일이다. 본인이 만족하지 못할 수도 있고, 이 과정에서 조직 역시 현금이나 커뮤니케이션 등 비용의 지출이 있을 것이다.
다른 하나는, 지금 상황에 맞지 않는 옷을 입는 것일 수 있다.
위에서 프레임워크는 모습과 의도를 담는다고 했다. 빌려온 것을 그대로 입기엔 헐렁이거나 꽉 낄 것이다. 뿌리나 뼈대가 부족하니 점진적으로 수정하는 것도 꽤 커다란 일이다.
그러다보니 나는 레벨링을 도입하기 위해서는 몇 가지가 받쳐줘야한다는 생각이 들었다. 조직이 어느 정도 몸집이 붙어있어야하고, 우리가 변하지 않았으면 하는 것들을 말할 수 있을 뿌리나 뼈대가 있어야 한다고.
슬랙: 변화와 재창조를 이끄는 힘을 읽으며 마음을 후벼팠던 것이 있다. 변화를 누가 잘 만들 수 있는지에 관한 내용이었다. 그건 리더십도 아닌, 팀원도 아닌, 중간관리자인 매니저들이라고 책에서는 말한다.
매니저들이 재창조의 역할을 수행하려면 시간과 여유가 필요하다. 하지만 내 모습을 돌아봤을 때, 내가 했던 일과 부탁받은 역할들 간에 거리가 있었다. 더 잘하기 위한 고민보다는 리스크를 줄이기 위한 일, 급한 불을 끄기 위한 소방수의 일을 하고 있는 것 같다.
레벨링이 동작하려면, 트랙의 분리와 관계없이, IC와 매니저 사이의 전환이 가능해야한다. 하지만 개인도 매니저가 되고 나면 뒤로 돌아갈 수 없는 것처럼 느끼며, 조직 역시 매니저를 IC로 되돌리는 선택을 쉽게 내리지는 못하는듯 하다.
IC와 매니저의 업무 비중을 7:3, 8:2 처럼 명확하게 나눌 수 없는 상황에서, 그리고 매니저에 지우는 책임이 상당히 크다는 점을 고려했을 때, 들어맞지 않는 부분이 있어보였다.
커리어 프레임워크, 엔지니어 레벨링이 잘 동작하지 않는 것을 보며 든 생각을 끄적여봤다.
적을까말까 했던 부분들도 있다. 예를 들어, 세분화된 레벨에 따라 접근 가능한 코드에 제한을 건다거나, 보상의 순서 및 자율성을 보고 결정하는게 제한적인 상황 등…
스타트업에서 엔지니어의 레벨링 제도가 정말 필요한 것일까?
그건 아무도 모른다.
하지만 모두가 나침반을 필요로 한다는 것만은 확실하다.