직무군

스무 명쯤까지는 사람마다 따로 판단해도 굴러갑니다. 연봉은 합류할 때 협상한 숫자대로 가고, 잘하는 사람은 대표가 알고 있으니 챙기면 됩니다. 기준을 적어 둔 문서가 없어도 판단할 사람이 전부를 보고 있기 때문입니다.

인원이 마흔을 넘기고 직무가 예닐곱 갈래로 늘면 그 방식이 멈춥니다. 3년 차 개발자와 3년 차 디자이너가 같은 자리에서 "저는 왜 저 사람보다 낮나요" 를 묻는데, 답할 말이 마땅치 않습니다. 둘이 하는 일이 달라서 같은 잣대로 비교할 수가 없고, 그렇다고 다른 잣대를 쓴다고 말하면 그 잣대가 어디 적혀 있느냐는 질문이 돌아옵니다. 한쪽을 올리면 다른 쪽에서 같은 질문이 다시 나옵니다.

직무군은 이 문제를 비교 범위를 좁혀 푸는 장치입니다. 모든 사람을 한 줄로 세우는 대신, 일의 성격이 비슷한 사람끼리 묶어 그 묶음 안에서만 기준을 적습니다. 개발자는 개발자끼리, 디자이너는 디자이너끼리 무엇을 해내는 사람인지를 적고, 묶음이 다른 사람끼리는 처음부터 견주지 않습니다.

직무군을 나누는 기준은 한 가지입니다. 같은 문장으로 성장을 설명할 수 있는 사람들이면 한 묶음입니다.

직무 레벨은 역량과 책임 범위에 따라 나눈 등급인데, 등급마다 무엇을 해내는 사람인지를 문장으로 적어 둡니다. 그 문장이 직무마다 다르다는 것이 직무군이 필요한 이유입니다. 한 단계 위로 올라간 개발자를 설명하는 말은 "혼자 풀 수 있는 기술 문제의 범위가 넓어졌다" 쪽이고, 같은 단계의 세일즈를 설명하는 말은 "혼자 책임지는 매출 규모가 커졌다" 쪽입니다. 두 문장을 하나로 합치면 양쪽 모두에게 안 맞는 말이 됩니다.

그래서 실제 운영은 세 단계로 돌아갑니다.

1. 회사 안의 직무를 성격이 비슷한 것끼리 묶습니다. 대개 엔지니어링, 디자인, 프로덕트, 세일즈, 마케팅, 경영지원처럼 대여섯에서 열 개 사이로 잡습니다. 지나치게 잘게 나누면 묶음마다 사람이 두셋뿐이라 기준을 적을 근거가 모이지 않습니다.
2. 묶음마다 레벨 표를 따로 씁니다. 다섯에서 일곱 단계를 두고 단계마다 그 직무에서 무엇을 해내는 사람인지를 적습니다. 표는 따로 쓰되 단계 수는 맞춥니다.
3. 같은 단계면 묶음이 달라도 급여 밴드를 같게 맞춥니다. 급여 밴드는 레벨마다 정해 둔 급여 범위입니다. 레벨 4 디자이너와 레벨 4 개발자의 범위가 다르면 사람들은 문서에 적힌 설명 대신 금액을 보고 어느 직무가 더 대접받는지를 읽습니다.

3번이 가장 자주 무너집니다. 시장에서 개발자 몸값이 빠르게 오르면 그 묶음만 범위를 올리고 싶어지는데, 그렇게 한 번 벌어진 차이는 문서로 설명되지 않는 채 남습니다.

직무군은 그 자체로 하는 일이 없고, 다른 제도가 돌아갈 때 범위를 정해 주는 방식으로 쓰입니다. 자주 나오는 자리는 넷입니다.

1. 채용. 채용 공고에 직무군과 레벨을 함께 적습니다. 공고에 적은 요건이 그 묶음의 레벨 표에서 나온 것이라, 뽑는 기준과 들어온 뒤의 평가 기준이 어긋나지 않습니다.
2. 평가. 성과 평가에서 누구와 견줄지를 정합니다. 같은 묶음, 같은 단계에 있는 사람들이 비교 대상이 되고, 다른 묶음 사람과는 애초에 나란히 놓이지 않습니다.
3. 보상. 급여 범위를 묶음이 아니라 단계로 관리하게 해 줍니다. 시장 조사 자료를 볼 때도 묶음 단위로 봅니다.
4. 이동. 사내 이동을 다룰 때 묶음을 옮기는 것인지 안에서 움직이는 것인지를 가릅니다. 고객 지원에서 프로덕트로 가는 것은 묶음을 건너는 일이라, 대개 단계를 한 칸 내려 시작하거나 같은 단계로 두되 적응 기간을 따로 잡습니다.

작은 회사에서는 이 분류를 문서로 만들지 않고도 머릿속으로 씁니다. "디자이너 연봉은 디자이너끼리 비교해서 정하자" 는 말이 이미 직무군을 쓰고 있는 것입니다. 명시적으로 적기 시작하는 시점은 대개 인원 50명 언저리, 또는 같은 직무를 세 명 이상 뽑기 시작할 때입니다.

"이건 직무군이 달라서 같은 레벨 표로 못 봐요. 디자인 쪽 표를 따로 봐야 해요."

비교 자체가 성립하지 않으니 다른 문서를 보고 판단하자는 말입니다.

"직무군은 마케팅인데 하는 일은 절반이 데이터 분석이에요. 분류를 다시 봐야 할 것 같아요."

한 사람의 실제 업무가 속한 묶음의 설명과 어긋나 있다는 지적입니다.

"직무군별로 밴드를 다르게 가져갈 거면, 왜 다른지부터 적어 둡시다."

금액 차이를 두려면 근거를 문서에 남기자는 요구입니다.

페이지덱이 마흔다섯 명이 되면서 규원이 가장 먼저 만든 것이 이 분류였습니다. 처음 초안에는 묶음이 열두 개 있었습니다. 프론트엔드와 백엔드를 나누고, 콘텐츠 마케팅과 퍼포먼스 마케팅을 나누는 식이었는데, 그렇게 하니 사람이 한 명뿐인 묶음이 다섯 개가 나왔습니다. 한 명짜리 묶음은 레벨 표를 써도 견줄 상대가 없어 결국 대표의 판단으로 되돌아갑니다.

지현이 이를 지적해 묶음을 여섯 개로 줄였습니다. 엔지니어링 하나, 디자인 하나, 프로덕트 하나, 세일즈와 고객 성공 하나, 마케팅 하나, 경영지원 하나였습니다. 대신 묶음 안에서 세부 직무를 적는 칸을 따로 뒀습니다. 태오는 엔지니어링 묶음의 레벨 4이고 세부 직무가 백엔드라고 적히는 식입니다.

직무군을 조직도와 같은 것으로 보는 경우가 많습니다. 실제로 팀 이름과 묶음 이름이 겹치는 일이 잦으니 그렇게 읽기 쉽습니다. 하지만 조직도는 누구에게 보고하는지를 그린 것이고 직무군은 어떤 기준으로 성장과 보상을 볼지를 나눈 것입니다. 한 팀 안에 여러 묶음의 사람이 섞여 있는 경우가 흔합니다. 둘을 같은 것으로 보면 조직 개편을 할 때마다 레벨 표와 급여 범위까지 흔들리고, 평가 기준이 반년마다 바뀌는 회사가 됩니다.

묶음이 다르면 대우도 달라야 한다고 읽는 오해도 있습니다. 하는 일이 다르니 금액도 달라야 한다는 생각이 자연스럽게 따라옵니다. 실제 운영 원칙은 반대입니다. 묶음은 비교 대상을 가르는 선이고, 단계가 같으면 묶음이 달라도 범위를 같게 두는 것이 기본입니다. 이 원칙이 깨지면 사람들은 자기 일을 더 잘하는 쪽이 아니라 더 후한 묶음으로 옮기는 쪽을 먼저 고민하게 됩니다.