OKR, 평가, 보상, 그리고 조직문화에 대한 실제 시행착오 기록 (2편)
안녕하세요. 카펜스트리트 Management Team Lead Nari 입니다. 1편에서 우리는 코어밸류를 세팅했다. 우리 조직이 함께할 사람의 질적 기준, 어떤 가치관으로 일하는 사람인가를 정의했습니다.
그런데 코어밸류가 세팅되자 다음 질문이 생겼다. 같은 가치관을 가진 사람들 사이에서, 누가 어느 수준의 책임을 지는가. 코어밸류는 Who를 정의했지만, 그 사람의 역할 크기는 아직 정의되지 않았다. 1편에서 이 질문을 남겼습니다. 보상은 정말 Outcome을 보고 있는가.
그 답을 만들기 위해 가장 먼저 부딪힌 현실이 있었습니다. Outcome을 판단하려면, 누구 기준으로 판단할 것인지가 먼저 정해져야 한다는 것입니다. 그 기준이 없다면 같은 결과물을 두고 팀장마다 해석이 달라지고, 같은 역할을 두고 시니어와 주니어의 경계가 명확해지지 않기 때문입니다.
보상의 기준이 불명확하면, 아무리 평가를 잘 설계해도 결국 연봉 협상은 협상력 싸움이 됩니다. 경력이 많은 사람이 더 세게 요구하거나, 퇴사 카드를 꺼내거나, 분위기가 좋았던 해에 올라가고 조용했던 사람은 제자리걸음을 합니다.
HR 입장에서 이 상황이 가장 불편한 이유는 단순히 불공평해서가 아닙니다. 설명이 안 된다는 것입니다. 왜 이 연봉인지, 왜 이 사람은 저 사람보다 높은지, 왜 이번에는 올랐고 지난번에는 안 올랐는지. 기준이 없으면 HR은 항상 방어하는 위치에 서게 됩니다. 그래서 다음 질문은 명확했습니다. 역할과 기여의 차이를 어떻게 시각화할 것인가?
역량 차이를 시각화한다는 것의 의미
역량 차이를 시각화한다는 말은 거창하게 들리지만, 실제로는 이 두 가지 질문에 답하는 작업입니다.
•
이 사람이 잘하고 있다는 걸 어떻게 아는가
•
이 사람이 저 사람보다 책임이 크다는 걸 어떻게 설명하는가
감각으로는 알 수 있습니다. 오래 함께 일한 팀장이라면 직관적으로 압니다. 하지만 그 감각을 다른 팀장과 공유할 수 없고, 구성원에게 설명할 수 없고, 보상의 근거로 제시할 수 없다면, 그 감각은 조직의 자산이 되지 못합니다. 잡레벨은 그 감각을 언어로 만드는 작업으로 직관을 기준으로 바꾸는 일입니다.
왜 직함이 아니라 Level 번호인가
처음에는 직함으로 레벨을 표현하는 방식도 고민했습니다. 주니어, 시니어, 리드, 헤드. 많은 회사들이 쓰는 방식이고, 구성원들에게도 익숙합니다.
하지만 직함에는 근본적인 문제가 있습니다. 직함은 이미 의미를 갖고 있습니다. 시니어라는 단어를 들으면 사람마다 떠올리는 기준이 다릅니다. 경력 3년이면 시니어인지, 5년인지, 아니면 역할의 크기인지. 직함으로 레벨을 정하면, 레벨 논의가 직함 논의로 흘러갑니다.
Level 번호는 그 자체로 아무 의미가 없습니다. 의미는 기대행동 정의에서 나옵니다. 레벨 번호는 비어 있는 그릇입니다. 그 그릇에 우리 조직이 정의한 스코프와 책임을 담기 때문에, 외부 경험과 비교되지 않고 우리 기준에서만 이야기할 수 있습니다.
또 한 가지 이유가 있습니다. 유추가 되지 않아야 한다는 것입니다. Level 번호는 어떤 포지션인지 추측이 어렵습니다. 같은 Level이라도 Product와 Business와 Management의 기대행동은 다릅니다. 번호는 그 사람이 무엇을 하는지를 드러내지 않습니다. 기대행동을 드러냅니다.
JobFamily를 3개 트랙으로 분리한 이유
잡레벨을 하나의 기준으로 통일하는 방식도 있습니다. 하지만 카펜의 구성원을 보면, 개발자와 마케터와 HR이 같은 기준으로 평가받을 수가 없습니다. 역할이 만들어내는 Outcome의 성격 자체가 다릅니다. 그래서 JobFamily를 세 가지로 분리했습니다.
트랙 | 포함 역할 | 평가 핵심 |
Product | 개발, 디자인, UX | 제품 품질, 기술 완성도 |
Business | 마케팅, 세일즈, 운영 | 성과 지표, 매출 기여 |
Management | HR, 재무, 법무 | 프로세스, 조직 운영 |
분리하면서 가장 신경 쓴 것은, 레벨의 논리 구조는 같게 유지하는 것이었습니다.최하위 레벨은 어느 트랙이든 기준실행자입니다. 합의된 기준을 정확히 이해하고 실행하며, 리스크를 숨기지 않고 공유하는 단계입니다.
Product → 코드 구현 품질과 PR 문서화로 나타나고
Business → 지표 공유와 데이터 이상 보고로 나타나고
Management→ 프로세스 준수와 운영 이슈 공유로 나타납니다
Scss
복사
그런데 이 기대행동이 같은 논리를, 다른 언어로 표현하는 것입니다. 이 구조 덕분에 트랙 간 레벨 비교가 가능해집니다. Product와 Business의 같은 레벨은 같은 수준의 책임과 자율성을 요구받습니다. 도메인이 다를 뿐입니다.
연봉밴드는 트랙별로 차등을 뒀습니다. 시장 데이터와 채용 난이도, 직접적인 매출 기여 여부를 종합한 결과입니다. 이 차등 자체도 기준으로 설명할 수 있어야 납득이 됩니다.
레벨 스코프를 어떻게 정의했는가
레벨을 처음부터 다 채운 것은 아닙니다. 현재 조직에 존재하는 역할들을 먼저 보고, 그 역할들이 어느 정도의 책임과 자율성을 갖고 있는지를 기준으로 구간을 나눴습니다.
각 레벨의 스코프는 3가지 축으로 정의했습니다.
축 | 낮음 → 높음 |
책임의 범위 | 개인 작업 단위 → 프로젝트 → 팀 → 조직 단위 |
자율성 | 지시 받아 실행 → 스스로 판단·완결 → 기준 수립 |
영향 범위 | 본인에게만 영향 → 팀 → 여러 팀 → 조직 전체 |
이 축들을 교차하면 레벨의 경계가 생깁니다.
•
하위 레벨 — 합의된 기준 안에서 정확하게 실행
•
중간 레벨 — 단위 업무를 끝까지 책임지고, 결과물을 팀이 재사용할 수 있는 형태로 생성
•
상위 레벨 — 프로젝트 전체를 독립적으로 리드하고, 여러 팀을 조율하고, 팀의 기준 자체를 수립
주의한 것이 하나 있습니다.
•
상위 레벨의 기대행동은 하위 레벨을 포함하지 않는다.
•
더 많이 한다가 아니라, 다른 방식으로 기여한다입니다.
잡레벨 실제 예시 — Level 1 기준실행자
기준을 높게 유지한 이유 — 몰림을 감수한 선택
잡레벨 기준표를 공유했을 때 팀장들의 반응 중 하나는 이것이었습니다.
→ 기준이 너무 높은 것 같다. 이 기준이면 대부분이 낮은 레벨에 몰릴 것 같다.
맞습니다. 그게 의도였습니다. 기준을 낮추면 편합니다. 많은 사람이 높은 레벨에 위치하고, 당장의 불만은 줄어듭니다. 하지만 그렇게 되면 레벨은 의미를 잃습니다. 모두가 비슷한 레벨에 위치해 있으면, 레벨 간 차이가 보상으로 연결될 수 없습니다. 레벨 시스템이 보상 기준으로 작동하려면, 레벨 간 차이가 실제로 보여야 합니다.
기준을 낮추면 모두 높은 레벨 → 차이 없음 → 보상 연결 불가
기준을 높게 유지하면 정직한 분포 → 레벨 간 차이 명확 → 보상 근거 생김
Scss
복사
대부분이 하위 레벨에 위치하는 것은 문제가 아닙니다. 우리 조직의 역량 분포를 정직하게 보여주는 것입니다.
레벨은 현재 상태를 측정하는 도구입니다. 낮은 레벨에 있다는 것은 부족하다는 뜻이 아닙니다.
이 레벨에서 기대하는 역할을 충실히 수행하고 있다는 뜻입니다. 기준이 높을수록 레벨 이동이 주는 의미도 커집니다.
팀장들과 기대행동을 정렬한 과정
기대행동 문서를 만드는 것과, 팀장들이 그 문서를 같은 방식으로 읽는 것은 다른 일입니다.
잡레벨 기대행동을 팀장들과 공유했을 때, 같은 문장을 두고 해석이 달랐습니다. 자율적으로 완결한다는 표현을 어떤 팀장은 혼자서 한다고 읽었고, 어떤 팀장은 묻지 않고 처리한다고 읽었습니다. 둘 다 틀리지 않았지만, 같지도 않았습니다.
그래서 두 단계로 진행했습니다.
1단계 — 원온원 스터디
팀장들이 자기 팀원들에게 1:1 피드백을 어떻게 하고 있는지를 먼저 맞추는 자리였습니다.
피드백 방식이 정렬되지 않으면 레벨 판단도 정렬되지 않기 때문입니다.
2단계 — 레벨 세팅 세션
팀장들에게 사전에 각 팀원의 레벨 가설을 세워오도록 요청했습니다.
그 가설을 함께 보면서, 왜 이 레벨로 봤는지, 어떤 행동을 근거로 했는지를 이야기했습니다.
Scss
복사
이 과정에서 가장 많이 나온 질문이 있었습니다.
이 사람은 Outcome은 좋은데 기대행동이 애매하다. 어떻게 봐야 하나요?
이 질문이 나오는 것 자체가 중요한 신호였습니다. Outcome과 Behavior를 분리해서 보기 시작했다는 뜻이기 때문입니다.
캘리브레이션 — 기준을 실제 사람에게 적용하기
레벨 기준표와 기대행동이 만들어졌다고 해서 바로 레벨을 확정할 수는 없습니다. 팀장 여러 명이 같은 기준표를 읽어도, 실제로 사람에게 적용하는 방식은 다릅니다. 누군가는 더 후하게, 누군가는 더 엄격하게. 이 편차를 줄이는 과정이 캘리브레이션입니다.
카펜의 캘리브레이션은 7단계로 구성했습니다.
1단계. 잡레벨 가설 세팅
각 팀장이 자기 팀원의 레벨을 먼저 설정합니다.
최근 1년간 역할 수행을 기준으로, 스코프·책임·자율성 세 가지 축에서 판단합니다.
2단계. 레벨 불일치 정렬
팀장 간 이견이 있을 경우, 이번 성과가 아닌 1년치 행동 기준으로 맞춥니다.
단기 성과와 장기 역할 수행이 충돌할 때 분리해서 질문합니다.
3단계. Outcome · Behavior 점수 입력
레벨이 확정된 상태에서, Outcome과 Behavior 각각 점수로 입력합니다.
JobFamily별로 가중치가 다릅니다. Business는 Outcome 비중이 높고,
Management는 Behavior 비중이 높습니다. (Behavior 점수는 코어밸류 기반으로 평가합니다)
4단계. Outcome 경중 정렬
점수가 아니라 성과의 해석을 맞추는 단계입니다.
달성률이 높아도 질이 낮다고 보는 조건은 무엇인지,
미달이어도 의미 있는 성과로 인정하는 조건은 무엇인지를 팀장들이 함께 합의합니다.
5단계. 앵커표로 Outcome 해석 정렬
등급 기준으로, 같은 레벨 안에서 이번 성과가 어디에 위치하는지를 맞춥니다.
점수 차이가 클 경우 앵커표의 질문을 사용해 해석을 좁힙니다.
6단계. Behavior 점수 정렬
결과와 무관하게 반복적으로 관찰된 행동과 협업 방식을 근거로 점수를 맞춥니다.
7단계. 분포 확인과 최종 점검
등급 분포가 특정 구간에 쏠려 있지 않은지, 평가자 간 편차가 기준 이상인 케이스는 없는지를 확인합니다.
Scss
복사
이 7단계는 점수를 맞추기 위한 절차가 아닙니다. 해석을 맞추기 위한 대화의 구조입니다.
같은 사람을 두고 팀장들이 왜 다르게 봤는지를 이야기하는 과정에서, 기준이 실제로 살아납니다.
참고그림
이 작업이 남긴 것
잡레벨 설계를 끝내고 나서, 이 작업이 꼭 필요하다고 생각했습니다. 코어밸류가 우리 조직에 함께할 사람의 질적 기준을 정의했다면, 잡레벨은 그 사람의 역할 크기와 기여 수준을 시각화하는 작업이었습니다. 같은 가치관을 가진 사람들 사이에서 누가 어느 수준의 책임을 지는가를 명확히 하지 않으면, 평가도 보상도 결국 근거를 잃기 때문입니다.
팀장들과 잡레벨 기준과 기대행동을 함께 문서화하고, 한 사람씩 얼라인해 나가는 과정이 생각보다 훨씬 좋았습니다. 기준이 생기니 대화가 달라졌고, 소통이 훨씬 수월해졌습니다. 조직이 조금 더 단단해지는 느낌이었습니다.
그리고 캘리브레이션을 실제로 돌려보면서, 같은 사람을 두고 팀장마다 해석이 이렇게 다를 수 있다는 걸 처음으로 숫자로 확인했습니다. 감각의 차이가 아니었습니다. 기준이 없었던 것입니다.
잡레벨은 사람을 줄 세우는 도구가 아닙니다. 팀장의 감각을 조직의 언어로 바꾸는 작업입니다. 그 언어가 생기고 나서야 비로소 대화가 가능해집니다. 이 사람이 왜 이 레벨인지, 다음 레벨로 가려면 무엇이 달라져야 하는지를 구성원에게 설명할 수 있게 됩니다. 그런데 여기서 한 가지 질문이 남습니다. 레벨이 정해졌다고 해서 보상이 납득되는 것은 아닙니다.
이 레벨이 연봉밴드와 어떻게 연결되는지, 그 연결이 어떻게 구성원에게 설명되는지, 그리고 CFR을 통해 그 대화가 어떻게 분기마다 살아있게 유지되는지가 아직 남아 있습니다. 그게 3편의 주제입니다. 그럼 3편으로 돌아오겠습니다.
늘 그렇듯 조금이나마 같은 업무를 하고 있는 분들께 인사이트가 되길 바랍니다.
긴글 읽어주셔서 감사합니다.