[iid] 레벨링 도입하기 프로젝트 (단기속성 편)
직무분석부터 FM대로 하기 힘들지요. 속성으로 해봅시다
[Edited by iid the HRer]
※ 내가 쓰는 글들은 아주 개인적인 경험에 근거한 지극히 개인적 소견이니 편하게 봐주면 좋겠다.
일전에 썼던 레벨링 관련 글의 후속시리즈로 정통 직무분석/레벨링 글을 쓰기에 앞서 각 회사에서 속성으로 도입할 수 있는 방법에 대해 가볍게 경험을 공유할까 한다.
https://brunch.co.kr/@shineastkim/23
먼저 위 글의 요지는 다음과 같았다.
▶ 직무분석/레벨링은 단순히 프레임으로 이해하기에는 다른 관점의 철학/사상적 배경을 이해해야 한다.사람이 중요하지 않다기보단 구조와 시스템을 더 중요시하는 관점 하에서 모든 업무는 과학적으로 분석/분류될 수 있다.
▶ 각각의 직무에 대해서는 여러 기준들(이건 추후에 얘기해볼까 한다. Hay/Mercer로 대표되는 직무분석방법론)로 스코어링을 하여 해당 직무의 난이도/업무 영역/대체 가능성 등을 고려하여 직무 자체의 Point를 평가할 수 있다.
▶ 해당 Point 분포에 대해 어느정도 그룹화/클러스터를 형성한 게 레벨이고 그리고 그 레벨에 따른 market pay data를 연계하면 Payband가 된다.
▶ Market data는 사실 완전 이직이 자유로운 노동환경에서 실제 수요와 공급관점에서의 시장 가격 상황을 반영한 형태로 어느 시점 특정 기술이 갑자기 시장에서 부각되었는데 해당 포지션 공급이 제한적이라면 그 사람의 몸값은 갑자기 수직상승할 수 있다.
위의 직무분석/레벨링을 아주 이상적으로 진행하기 위해서는 사실 조직 구조에 사람을 꽂기 전에 먼저 설계를 해놓고 그 뒤에 각각의 포지션에 적합한 사람을 배치하거나 채용하는 것이 맞다. 하지만 그런 조직은 어디에도 없다. 대부분의 한국 스타트업에서는 이미 갖추어진 조직에 뒤늦게 레벨링 개념을 도입하기 때문이다.
실제 레벨링을 진행하기에 앞서 아래의 고려사항들은 꼭 검토해보아야 한다.
1. 우리 조직은 왜 레벨링을 도입하나요?
항상 모든 제도나 변화의 시작은 why? 에서부터 시작한다. 그래야 방향을 잡고 우선순위를 잡을 수 있다. 수많은 도입했을 때의 장점과 이유/목적들이 있겠지만 해당 조직에서 가장 우선으로 도입하려고 하는 니즈에 따라 제도 설계 방향성 및 로드맵은 매우 달라질 수 있다.
레벨링 또한 다르지 않다. 다양한 이유들이 있을 수 있다.
내부 구성원들의 경력과 전문성들이 다양하다 보니 각자의 레벨에 맞는 업무 배분 및 목표치를 제시하여야 가장 조직의 성과가 극대화될 것 같아요 (가장 일반적 정답 ver)
다른 회사들도 다들 하는 것 같아 우리도 하고 싶어요
비싼 시니어/리드급을 데려왔는데 뭔가 기존 인력들에 비해 그만큼 더 업무 역할과 책임을 부여하고 싶어요
다 같이 열심히만 하는 형태에서 좀 더 업무를 명확하게 분배하며 효율적으로 진행하게 하는 좀 더 체계적인 시스템을 갖추고 싶어요
시니어들이 직급은 아니더라도 자기들이 주니어와 다른 어떤 구분점을 만들어달라고 요구해요
초기멤버가 8년간 계속 똑같은 일만 하는데 이 사람에 대해서 어떻게 대해야 할지 모르겠어요. 연봉을 계속 무한정 올려주기도 힘든 것 같아요
위의 이유들은 예시일 뿐이다. 뭔가 멋지지 않아도 상관없다. 어떤 이유든 상관없다.
우리 조직에서 왜 도입해야 하는지 적어도 이유는 알아야 한다. 그래야 진짜 실효적으로 업무를 위한 건지 아니면 우선적으로 껍데기 형태로라도 도입해야 할지 결정을 할 수 있다. 그리고 이후 이것이 다른 고려사항들과도 연계되어 이로 인한 파급효과 및 risk가 발생할 때 그에 대한 대비도 가능하다.
2 우리 조직에는 얼마나 인력들이 다양하게 분포되어 있나요?
적어도 우리 조직 내 시니어와 주니어, 만약 좀 더 세분화한다면 그 중간 미들급까지 해서 어느 정도 구성은 되어있는지 봐야 한다. 왜냐하면 미들/시니어 층이 너무 약하거나 적다면 주니어 층에서는 다른 시니어 레벨에 대해 수용성이 떨어지고 구분점으로서의 명확함이 부족해진다. 최악의 경우 주니어 사이에서 서로 조금 더 주니어냐 아니냐에 따라 세분화된 레벨 구분이 이루어질 수도 있다.
어느 정도 비율이 안정적이냐고 딱 답하기는 힘들지만 기본적으로 시니어 / 미들 / 주니어 3단계 정도로 본다면 정말 아주아주 보수적으로 적어도 10% / 20~30 % / 60~70% 정도 비율은 구성되는 것이 그래도 레벨 자체도 주니어에 너무 편중되지 않고, 우리 회사에는 존재하지 않는데 굳이 만들어놔서 아무도 될 수 없을 것 같은 유령 같은 레벨 구간을 만드는 우를 범하지 않는다.
과거 이드가 몸담았던 회사들에서는 대부분의 대표님들이 레벨링을 도입하고 싶어 했다. 당연히 이유와 목적은 사전에 확인했지만 그 뒤에는 꼭 현재 인력 구성을 파악했다. 너무 시니어층이 부족하다 싶으면 레벨링 도입을 미루고 일단 채용을 강화해 시니어 구간을 두텁게 해서 (당연히 레벨링만을 위함은 아니고 업무와 조직목적이 더 메인이었다) 그 구조가 어느 정도 안정화된 뒤에 레벨링을 진행하였다. 주니어들이 대부분인데 무리하게 레벨을 부여하게 되면 점점 옥상옥 구조의 레벨들이 신설되며 시니어 위의 시니어 들만 양산된다.
여담으로 실리콘밸리의 레벨제도를 보면서 그것이 너무 국룰이라고 생각하는 분들이 꽤 많다. 우리에게 제일 많이 알려진 곳이라면 구글/아마존 (+쿠팡) 이 있을 것 같다. 이전 글에서 말했듯이 레벨 구분점이나 직무명은 그냥 그 회사에서 임의로 만든 것이며 원래 market data를 제공하는 글로벌 HR 컨설팅에서는 그렇게 명확하게 기준점을 만들어두진 않는다.
단지 빅테크이기에 시장의 보편성을 확보했기에 해당 기준으로 이야기하기 편할 뿐 레벨과 market data는 언제든 변할 수 있다. 아주아주 소설이지만 A.I. 가 너무 발전해서 개발자들을 다 대체한다면 해당 직무의 레벨 구분이나 보상 현황은 그냥 폭파될 수도 있다.
우리나라에도 실리콘밸리 빅테크에서 근무하다 오시는 개발자분들이 빅테크에서의 직무영이 익숙하다 보니 그 레퍼런스대로 진행하고 싶어 하는데....
(아주아주 개인적으론) 우리나라는 그 정도 레벨 구분이 큰 의미가 없을뿐더러 (SI업체랑의 비교가 정당하냐고 누군가 물을 수도 있지만 그 규모와 영향력은 무시할 수 없다는 전제하에서 삼성 SDS에서 조차도 직급은 그렇게 많지 않다) 우리나라에선 principal 이런 거 쓰면 농담 50% 첨가해서 교장/학장 이런 걸로 오해받는다. 정작 시니어가 얼마있지도 않은데 빅테크 따라한다고 시니어 위에 시니어를 어느 정도까지 만들까를 고민하게 되면 최초 구분점이 되어야하는 시니어가 너무 주니어가 돼버린다.
3. 구성원들은 결과를 받아들일 수 있나요?
스타트업의 특징은 (체계나 시스템이 아직 형성되지 않았거나 느슨하기에) 맘만 먹는다면 넓고 다양한 업무범위와 권한을 가질 수 있다. 이 말을 다르게 한다면 내가 굉장히 어렵고 다양한 업무를 많이 하는 사람으로 당연히 생각할 수 있다. 여기에서부터 레벨링 도입 시의 가장 큰 이슈가 발생한다.
바로 본인의 레벨에 대해 얼마나 수용성 높게 받아들일 수 있는가
의외로 많은 주니어분들은 본인이 주니어가 아니라 생각한다. 왜냐하면 업무가 분화되거나 체계화되기 전에는 이 업무의 고도화된 버전이 뭔지도 복잡도/난이도가 높아진 버전도 경험해보지 않았기에 일단 내가 하는 업무 자체가 그 기준이 되는 것이다. 일을 얼마나 잘하고 얼마나 완성도 있고 얼마나 하이레벨로 하냐라는 개념이 자리 잡는 것은 생각보다 나중일이다. 어쨌든 일을 해내고 수행해 내는 것이 먼저 발생한다. 그러면 내가 일단 특정영역의 총괄처럼 모든 일을 다 수행한다. 그러면 나는 당연히 회사에서 중요한 역할을 수행하며 업무 난이도도 높고 그렇기에 나는 시니어일 거라 생각한다.
(이 고민포인트는 사실 정통 ver 레벨링과정에서도 사실 어려운 난제긴 하다. 업무의 깊이와 범위, 당연히 둘 다 고려되어야겠지만 성숙화되지 않은 회사에서 현재 업무에 대해 어떤 기준을 어느 정도로 가중치를 부여할 것인가는 정답이 없다. 심지어 변동가능성도 높다)
그리하여 레벨을 부여하기 위해선 아주 원론적으로는 사람을 배제한 채 직무와 업무로만 봐야겠지만 현실적으로는 사람 중심으로 볼 수 밖에 없게 된다. 그러면 해당 직무/업무의 일 잘하는 시니어가 어떻게 일하는지를 알아야 이 사람이 시니어인지 아닌지를 평가할 수 있다.
자! 이제 실제로 속성으로 레벨링을 진행해 보자.
1. 구성원들의 직무(Job Title)를 정리한다.
직무명은 업계 내에서 어느 정도 표준화되기도 했고 (혹시나 자기 회사만의 너무 특이한 직무명이 있는 것이 아니라면) 쿠팡/토스/야놀자 등 큰 회사들의 채용 공고를 참고해도 좋다.
가능하면 직무는 업무의 독립성은 반영하되 어느 정도 표준화되는 선에서 목적성을 잃지 말아야 한다. "동료와 업무가 조금이라도 다르기 때문에 그 직무명 싫어. 나만의 직무명 하고 싶어" 이런 직원의 개별화된 욕망을 다 이뤄주고 싶은 것이 목적이라면 레벨링보다는 다른 프로젝트가 맞다고 생각한다.
2. 직무를 관리하는 직군(Job Group)을 결정한다
직군 구분은 생각보다 다양하게 존재한다. 가능하면 너무 다양하게 하기보단 적은 숫자를 권장하긴 하지만 이는 현재 회사 내에서 운영되고 있는 각 그룹의 고용형태 / 보상 / 업무 형태 / 일하는 방식 등을 종합적으로 고려해서 나누는 것이 맞다고 생각한다.
직군의 구분은 단순 직무의 그룹으로 볼 수도 있지만 이 직군으로 인해 HR제도의 차별적 적용이 발생할 수도 있고 사고의 접근 또한 달라질 수 있기 때문이다. 그렇기에 직군의 구분은 생각보다는 신중하되 관리의 효율성을 고려해 적정 수준이 좋다.
ex)
Tech / Non-Tech
Corporate / Biz / MKT / Product / Tech
Sales / Strategy / HR&Finance / Tech / Design / Biz / MKT
3. 이제 직군/직무를 매칭한 직원들을 나열한다
가장 쉬운 것은 연봉 수준과 경력을 같이 고려해서 순서를 세우는 형태이다. 하지만 이는 아주 기초적인 접근법이고 아무리 레벨을 부여한다 해도 사전에 각 팀장급들에게 구성원들의 실력이나 시니어 수준을 확인해보아야 한다. 일렬로 줄세우기까진 힘들더라도 몇개의 그룹정도라도 세울 수 있다면 좋다.
원칙적으로는 연봉수준/경력이 아닌 그 직무에 대한 그 사람의 전문성 수준으로만 평가를 하는 것이 정답이긴하다. 하지만 그정도는 해당 직무의 리드급의 의견을 참고할 수 있지만 이번 버젼은 단기속성 버젼이기에 쉽게 일단 도입버젼으로 안내한다. 연봉을 보는 이유는 어느정도 시장에서의 평가를 인정했다와 고연봉자를 너무 낮은 레벨로 배치시 바로 Outlier가 되어 연봉캡 적용이 될 수 있기 때문이다.
경력은 사실 전통적인 연공서열식 사고라 볼 수도 있지만 시간은 거짓말을 하지 않기에 (천재 개발자는 예외로 하자) 구분점 정도로는 참고할 수 있다. 근데 막 세부적으로 그 숫자 자체에 너무 꽂혀서 10년차 / 9년차가 있다면 10년차가 무조건 더 잘할거야는 위험하다. 전문성 관점에서 9년차가 더 잘할 수 있다. 경력은 년차 숫자 자체에 너무 얽매이기보다는 예를 들어 5년차 정도는 되어야 그래도 실무에서 주니어는 아닐 것 같다와 같은 구분점정도로 이해하는 것이 오류를 최소화할 수 있다.
절대관점의 기준이 힘들면 두 명을 서로 비교하면서 A가 B보단 시니어다 정도만 되어도 좋다. 여기서 말하는 시니어란 현재는 같은 업무를 하고 있더라도 전문성이 높고 더 난이도 높은 업무를 줄 수 있는 사람이자 주니어를 선배로서 가르치거나 혹은 리딩할 수 있다는 의미이다. 단순히 일을 잘한다 못한다의 개념보단 좀 더 많은 의미와 가치를 부여해야 한다.
※ 레벨링은 한번 했다고 바뀌지 않는 불변의 것이 아니다. 최초 부여한 레벨은 수정되어야 할 가능성이 높다. 그렇기 때문에 레벨에 대해서 너무 관대하게도 또 너무 보수적이지 않게 조직 내에서 업무관점에서 그 분포가 어떤지를 고민해 볼 수 있어야 한다.
4. 구분점을 몇 개로 할지 어떤 기준으로 할지 결정한다. (레벨 개수)
앞에서 말했듯이 이미 조직/인원의 규모가 큰 빅테크는 당연히 레벨이 굉장히 세분화되어 있다. 레벨의 구분점이란 업무/역할의 구분점으로 볼 수도 있다. 그 정도로 세밀하게 단위를 구분할 수 있냐 그리고 그게 의미가 있냐라고 스스로에게 질문하면서 그 단계수를 잡아야 한다.
정말 단순하게 Entry / Junior / Middle / Senior / Lead 이렇게만 잡아도 사실 충분하다. 작은 조직의 경우는 아직 업무의 난이도/복잡도가 높지 않기에 그만큼 구분이 필요하지 않을 수 있을뿐더러 middle급에 대한 내부 구분점이 없을 수도 있다. 주니어 중에 시니어는 아닌데 좀 애매한 급들이 있다 문제는 그 급들이 주니어로 부르기에는 정말 적합하지 않는가. 주니어/시니어와는 다른 레벨의 업무/역할을 줄만한 정도의 구분점이 나타났는가 이런 고민들이 최종 심화되었을 때 하나의 레벨이 생성될 수 있다. 단순히 주니어 안에서의 순서상에서 최상위권이라는 이유로 그네들을 위한 별도의 레벨을 만들어주는 것은 레벨링이라는 제도 자체가 또다른 비효율성과 관료화를 만드는 계기가 될 수 있다.
정말 극단적으로 CTO 밑에서 시니어 / 주니어 정도로만 나누어져도 되는데 시니어 급 안에서 굳이 자기 위안/만족을 위해 억지 명칭을 붙이는 형태도 있을 수 있다. 과거 군대에서 계급 안에서도 초봉 / 꺾인 단계 / 말봉 이런 표현을 쓰면서 굳이 세분화한 경우를 생각하며 그것의 악영향 또한 고민해 볼 필요는 있다.
또 하나 중요한 건 구분점이다. 이를 위해서는 그 아래 레벨과는 구분점이 될 수 있는 앵커 멤버가 필요하다. 이 사람은 누가 봐도 시니어라고 인정될 수 있는 급이 필요하다. 그러면 그 사람을 중심으로 레벨의 분기점이 형성될 수 있다. 정통 직무분석에 의한 사람을 맵핑하는 형태가 아닌 사람베이스로 중간에 레벨링을 진행할 때는 각 레벨별 앵커멤버가 사실 무엇보다 중요하다.
5. 세부 정책을 결정해야 한다.
아래 사항들은 레벨링을 하게 되면 부가적으로 고민해야하는 옵셔널한 선택사항들이다.
옵셔널하다라는 말은 정답은 없다와 같다. 어떤 걸 선택하더라도 각각의 장단점이 있기에 본인의 회사/구성원에 맞는 방식을 선택하면 된다.
레벨을 오픈할 것인가. 오픈한다면 당사자에게만? 아니면 전체?
레벨을 공식기준으로 할 것인가. 레벨은 관리용으로만 하고 레벨을 어느 정도 통합한 Senior 정도 구분이 들어간 직무명으로 할 것인가?
레벨을 전체 8단계로 한다했을 때 Lv 3~5를 Senior OOO Manager로 내부 직무명으로 사용도 가능하다. 마치 대기업에서 직급은 통합했지만 내부 pay grade를 구분한 것과 동일하게.
페이밴드를 연동할 것인가? 연동한다면 min/max를 오픈할 것인가?
레벨별 JD를 다 만들 것인가?
이건 양날의 검이다. 성장 중인 스타트업에서는 사실 레벨이나 직무범위가 끊임없이 달라지고 심지어 조직체계도 계속 바뀐다. 그러면 그때마다 JD를 다 수정해야 하는데 관리 cost가 더 클 수도 있기에 이 부분은 양날의 검이다.
채용공고를 레벨별로 별도 오픈할 것인가? 면접 때 레벨까지 평가할 것인가?
6. 레벨링을 이제 돌려보면서 계속 수리/보완작업하자
일단 레벨 세팅까지 속성으로 하는 버전을 설명한 내용이기에 실제 운영하면서 고도화하는 내용이나 평가 / 보상과 연동하는 내용은 다른 아티클에서 또 다를 예정이다.
레벨링은 한번 했다고 영원불멸한 것이 아니고 실제 외국에서도 조직개편할 때마다 전사 전략이 변경될 때마다 조직이나 직무의 가치가 달라질 수 있기 때문에 주기적으로 직무가치도 새롭게 책정하며 레벨링도 바뀔 수 있다. 심지어 직무 구조도 바뀔 수 있다. 그렇기에 레벨링을 한번 세팅한 것은 앞으로 지속적으로 개선하는 과정에서 정말 한 스텝을 시작한 것뿐이라 생각하면 좋을 것 같다.
