R&R에 대한 흔한 오해. 그리고 책임의 경계와 의사결정 라인의 설계
급성장한 회사.
그리고 조직문화와 인사에 대한 체계를 잡으려는 대표이사의 의지가 강했던 곳.
그래서 시작한 조직문화구축 프로젝트를 위해 컨설팅사와 함께 조직문화진단을 긴 시간을 들여 시작했다. 경영진을 인터뷰하고, 구성원들과 몇 차례 설문지 응답과 일부는 인터뷰를 진행했다.
진행이 완료되어 조직문화진단 컨설팅 결과를 받았을 때, 한 항목이 유독 눈에 들어왔다.
조직 내 구성원들 다수의 의견 - "일을 어디서 누가 해야 하는지 모호합니다."
업무가 혼재되어 있거나 중복과 누락으로 서로 협력하기 힘들어한다는 것. 구성원들의 목소리였다. 조직문화진단 결과 반영해야 할 일은 많았지만, 그중 역할과 책임(R&R)을 우선적으로 정리해야겠다고 생각했다.
사실, 이전의 경험상 부서 간 R&R체계는 일의 주도권과 협업, 리소스(사람)가 포함되어 있기 때문에 조직 간 의견차이와 마찰이 어느 정도는 예상이 되었던 것이긴 하다.
예상했던 마찰이란 서로 주도권 경쟁 혹은 소위 성과가 돋보이거나 조직내 영향력이 큰 업무 빼앗기지 않기. 일종의 '알력'과 같은 것들... 이었다.
하지만 이때 마주한 반응은 기존에 생각하던 것과 전혀 다른 맥락의 저항이었다.
"R&R을 정리한다고요? 그럼 너 일, 내 일 나누자는 거예요?"
"왜 이렇게 대기업처럼 일하려고 하세요?"
"우리는 '쓰레기는 먼저 본 사람이 줍는다'는 문화로 여기까지 왔는데요?"
"뭉쳐서 일하는 조직을 갈라놓으려는 것으로 보여요"
저항의 핵심은 부서 간 갈등이 아니었다. 창업 초기부터 성경처럼 전해 내려온 한 문장, "쓰레기는 먼저 본 사람이 줍는다" 정신을 해석하는데서 오는 오해였다.
이 문장은 창업 초기, 모두가 소매를 걷어붙이고 필요한 일이라면 뭐든 했던 시절의 상징이었다. 실제로 그 덕분에 회사는 빠르게 성장할 수 있었다.
기존 경영진과 멤버들은 이 문화를 자랑스러워했고, 심지어 경영진 중에는 "내가 조직문화를 더 잘 안다"며 직접 주도하려는 분도 있었다. R&R 정리를 마치 이런 너나 할 거 없이 서로 일하려는 문화를 부정하는 것처럼 받아들인 것이다.
그러나 그런 경계 없는 것이 해석이 확장되면서 조직 안에서는 마치 업무의 경계보다는 더 잘하는 누군가가 하면 되지라는 생각이 만연해 있었다.
이걸 반영하듯이 한 번은 채용브랜딩을 정리하려 할 때였다.
브랜드커뮤니케이션팀에서 "브랜딩이니까 우리가 하겠다"라고 먼저 나섰다. 적극적인 관심과 능력이 동기가 된 것이었지만, 교통정리 없이 일이 한쪽으로 쏠렸다. 주관팀인 채용팀의 역할은 애매해졌고, 지속성도 무너졌다.
조직문화 커뮤니케이션도 그랬다. 마케팅팀에서 '커뮤니케이션은 더 잘한다'며 주도하겠다고 먼저 나섰다. 누가 최종 책임자인지 불분명한 채로 일이 진행됐다.
이미 규모가 커지고, 관리체계가 필요해진 조직에서 이러한 움직임은 오히려 서로 협력해 가며 일을 완성해 가는데 독이 되어가고 있었다.
첫째, 목소리 큰 사람, 기존 멤버 중심으로 일의 주도권이 몰렸다.
"내가 오래 있어서 더 잘 알아"라고 주장하는 사람이 일을 가져갔고, 새로 들어온 사람들은 어디까지가 자신의 일인지 알 수 없었다.
둘째, 향수와 관성이 변화를 가로막았다.
"예전에는 다 같이 했는데"라는 말이 R&R 정리를 거부하는 논리가 되었다.
셋째, 규모가 커지면서 한눈에 챙기기 어려워졌다.
누가 무엇을 하고 있는지, 중복은 없는지, 공백은 없는지 파악하기 어려워졌다.
이런 현상들이 가져오는 문제는 바로 조직이 성장하면서 가져가야 할 업무의 지속성과 연속성도 사라지면서 발전하기 어렵게 된다는 점이다.
더 큰 문제는 경영진의 저항이었다.
"제가 000님보다 여기서 더 오래 있었어요. 우리 조직문화를 잘 모르시는 거 같아요"
"우린 규모가 커졌어도 스타트업 체계를 유지하고 싶어요"
그들의 말이 완전히 틀린 것은 아니었다. 하지만 그들이 놓친 것이 있었다. 조직의 규모와 복잡성이 달라지면, 과거에 효과적이었던 방식이 더 이상 작동하지 않는다는 사실이다.
프로젝트를 마치면서 R&R이 왜 필요한지를 설득하려 했지만 쉽게 수용되지 않는 분위기였다.
이후 조직에 OKR을 도입하고 조직별 목표를 정렬해 가면서 더욱 자연스럽게 R&R을 받아들이기까지 상당한 시간을 보내게 되었다.
이 경험과 이후 여러 조직에서 마주한 유사한 상황들, 그리고 조직 설계 이론을 바탕으로 이 글에서는 역할과 책임을 설계하는 원리와 맥락을 다룬다.
앞선 '조직구조' 글에서 조직의 '뼈대'를 세웠다면, '역할과 책임'에서는 그 뼈대를 따라 권한과 책임이 실제로 흐르도록 하는 '신경망'을 설계한다고 보면 된다.
조직구조를 그렸다고 해서 조직이 조직도대로 저절로 움직이지 않는다.
'누가 무엇을 결정하고 책임지는가(수직적 정렬)'와
'부서와 부서가 어떻게 협력하는가(수평적 경계)'에 대한 구체적 관계 설정이 약속으로 이루어져야 그것들을 토대로 조직도에 실제로 일이 흐르게 된다.
이 약속이 바로 조직 운영을 실질적으로 움직이는 핵심 기제인 '역할과 책임(Roles and Responsibilities, R&R)'이다.
조직구조가 "조직도"라는 큰 틀이었다면, R&R은 "구체적으로 누가 무엇을 어떻게 할 것인가?"라는 실행 설계이다. R&R이 불분명하면 의사결정이 지연되고 책임 소재가 애매해지며, 결국 전략은 실행되지 않고 성과는 흐르지 않게 된다.
따라서 이 글에서는 다음의 내용을 다룰 것이다.
1) 언제 R&R을 다시 들여다봐야 하는가?
설계한 조직구조가 제대로 작동하기 위해 R&R 정비가 필요한 결정적 순간을 판한다.
2) 수평적 경계 설계: 부서와 팀 사이의 배관을 어떻게 연결할 것인가?
조직구조 설계 이후 조직 간 발생하는 '회색지대'와 업무흐름의 병목 문제를 구체적으로 해결하는 방법을 알아본다.
3) 수직적 정렬: 의사결정 라인을 어떻게 실제로 작동시킬 것인가?
조직도에서 의사결정의 책임을 지게 되는 직책 개념을 바탕으로, 실제 현장에서 혼동하는 직급과의 개념적 차이를 이해한다. 그리고 이를 어떻게 설계하고 운영할지 구체적인 방법을 볼 것이다.
4) 설계된 R&R의 운영과 다음 단계 연결
완성된 R&R이 어떻게 운영되며, 이후 성과관리(3장), 평가(4장), 보상(5장)의 토대가 되는지 그 연결고리를 살핀다.
5) 마지막에는 산업, 성장 단계, 전략에 따른 R&R 설계 방향을 참고 예시로 보게 된다.
같은 조직구조라도 조직의 상황에 따라 R&R을 어떻게 다르게 설계해야 하는지 실무 기준을 이해하고, 실제 경험사례를 통해 산업 변화와 성장단계에 따라 변화가 왜 필요했는지를 간접적으로 경험하게 할 것이다.
조직은 살아 움직이는 유기체다. 특히 팀과 팀 사이의 역할과 책임은 수시로 조정이 필요하다. 새 프로젝트가 시작될 때, 협업 방식이 바뀔 때, 업무 중복이 발견될 때, 책임 공백이 생길 때마다 점검하고 조정해야 한다.
하지만 그중에서도 특히 더 긴급하게 전면적 재정비를 해야 하는 시점들이 있다.
조직의 전략·구조·프로세스·사람·보상 중 하나라도 크게 달라지면, 역할과 책임의 전면적 재조정이 필요하다.
급성장으로 인한 혼란기 - 비공식 방식으로의 한계
더 이상 과거의 비공식적인 방식이 통하지 않을 때다. 비공식적 소통이 한계에 부딪히며 의사결정이 지연되고, 여러 팀이 같은 일을 중복 처리한다. Alfred Chandler가 말한 "구조는 전략을 따른다(Structure follows Strategy)"처럼, 전략이 성장과 확장을 지향한다면 반드시 이에 맞춘 R&R 재정렬이 뒤따라야 한다.
전략 변화에 따른 부조화 - 기존 R&R과 새 전략의 부조화
제조에서 서비스로, 기술 중심에서 고객경험 중심으로 전환될 때 기존 R&R이 새로운 전략 방향과 맞지 않아 실행력이 저하된다. 이때는 각 팀의 역할과 협업 지점을 다시 정의해야 한다.
정체·관료화의 위기 - Legacy가 된 R&R이 새로운 변화와 혁신을 방해
과거에 잘 작동하던 구조와 책임 체계가 오히려 성장의 발목을 잡는다. 의사결정은 느려지고 부서들은 "그건 내 일이 아니다"라며 선을 긋는다. 이때는 회색지대를 다시 정리해야 한다.
조직 개편 후의 과도기 - 새로운 구조에 맞는 R&R 미정립
기능 조직에서 제품 조직으로, 또는 애자일 조직으로 전환한 후, 새로운 구조에 맞는 R&R이 정립되지 않아 혼선이 빚어진다. 부서 간 경계와 협업 방식을 다시 설계해야 한다.
새로 합류한 구성원의 잦은 이탈 - R&R 모호함이 가져온 갈등과 충돌
역할과 책임의 경계가 공식화되지 않아 비공식 규칙이 지배하고 있는 상황.
새로 합류한 인재는 "누가 어느 영역을 담당하는지", "어디까지 내가 결정할 수 있는지" 등 기존 멤버들끼리 암묵적으로 나눠 놓은 규칙을 모른 채 일하다 충돌한다. 명확한 역할과 임팩트를 원하는 우수 인재일수록 이런 비공식적 질서 속에서 더 빨리 좌절하고 떠난다.
역할과 책임을 설계하는 것은 크게 두 개의 축으로 볼 수 있다.
첫 번째는 수평적 경계 설계에 의한 부서와 부서, 팀과 팀 사이의 관계이다.
"이 일은 누구 책임인가", "협업할 때 누가 최종 결정하는가", "정보는 어떻게 흐르는가"를 명확히 한다. 조직구조가 실제로 작동하려면, 그 안에서 부서 간 역할과 협업 방식이 구체적으로 정의되어야 한다.
두 번째는 수직적 정렬 즉, 위에서 아래로 흐르는 의사결정 단계의 라인이다.
"이 직책은 무엇을 결정할 수 있는가", "승인은 몇 단계를 거치는가", "한 리더가 몇 명을 관리하는가"를 정한다. 조직구조 설계 시 하이어라키에 해당되는 부분으로 각 조직의 책임권한으로써 직책에 대한 개념을, 실제 현장에서 어떻게 운영할지 구체화하는 작업이다.
그리고 이렇게 두 축이 정리가 되어야 조직 안의 역할과 책임이 명확하게 반영이 된다고 볼 수 있다.
조직이 커질수록 한 사람, 한 부서가 담당하는 일의 범위는 좁아지는 대신, 부서 간의 유기적인 연계가 성과에 훨씬 더 결정적인 영향을 미친다. 이때 책임의 경계가 모호하면 다음과 같은 두 가지 문제가 동시에 발생하며, 업무흐름의 병목을 만든다.
첫 번째는 책임의 공백, 이른바 회색지대가 발생한다.
애초에 누구의 일인지 명확히 정해지지 않아 방치되는 상황이다. 예를 들어, 신규입사자 온보딩은 채용팀 일인가, 교육팀 일인가? 채용 브랜딩은 채용팀 일인가, 마케팅팀 일인가? 사내 커뮤니케이션 도구 선정은 IT팀 일인가, HR팀 일인가? 이렇게 경계가 모호한 업무들이 공백으로 남게 된다.
두 번째는 업무의 중복이다.
여러 부서가 사실상 같은 일을 각자 수행하여 자원의 비효율을 초래하는 상황이다. A팀과 B팀이 각자 다른 외부 업체를 통해 비슷한 내용의 시장 조사를 진행하여 예산과 시간을 낭비하는 식이다.
물론 때로는 의도적으로 책임을 중첩시켜 부서 간 협력을 강화할 수도 있다. 그럼에도 이때에도 반드시 누가 최종 책임자인지는 분명히 해야 한다.
결국 수평적 경계 설계의 핵심은 누가 최종 책임을 갖는지(Decision Rights)를 명확히 하는 것이다.
(참고: Paul Rogers and Marcia Blenko, "Who Has the D? How Clear Decision Roles Enhance Organizational Performance", Harvard Business Review, 2006)
그렇다면 조직 간 경계를 명확히 하면서도 협업이 원활하게 흐르게 하려면 어떻게 해야 할까?
Jay Galbraith는 부서 경계를 넘어 정보와 책임이 흐르게 만드는 구체적 장치들을 제시했는데, 이는 단순히 "협력하라"는 구호가 아니라, 조직구조 사이사이에서 협업을 유도하는 보조적 장치로써의 설계로 볼 수 있다.
대표적인 수평적 협업 메커니즘은 다음과 같다.
Cross-functional teams(크로스 기능 팀) 활용
부서 벽을 넘는 상시 협업 조직으로, 여러 부서 전문가가 공동의 목표로 함께 일하는 조직구조이다.
흔히 말하는 '프로젝트팀'이나 'TF'와 비슷하지만, 결정적 차이는 상시운영이 된다는 점이다.
임시 프로젝트팀/TF: 특정 문제 해결 후 해체되는 임시 조직
크로스 기능 팀: 제품이나 고객군을 중심으로 상시 운영되는 협업 조직
핵심은 상시적으로 이런 조직을 운영면서 여러 부서 전문가가 공동의 목표로 함께 일하되, 단순한 정보 공유를 넘어 공동 의사결정까지 수행한다는 점이다. 각자 소속 부서(개발본부, 마케팅본부)는 다르지만, 이 팀에서는 하나의 제품 성공을 향해 움직인다.
예를 들어 '결제 서비스 스쿼드'라면, 기획자는 마케팅본부 소속이고 개발자는 개발본부 소속이지만, 일상 업무에서는 '결제 서비스의 성공'이라는 공동 목표로 함께 일한다.
크로스기능팀의 운영 예시로는 다음과 같은 조직형태가 있다.
스쿼드(Squad): 스포티파이가 유명하게 만든 용어. 보통 6-10명의 다기능 팀으로, 특정 제품 기능이나 고객 경험을 책임진다. 기획자, 개발자, 디자이너가 한 팀으로 묶여 움직인다.
파트(Part): 네이버 등 국내 서비스 기업에서 사용하는 조직 단위. 여러 직군이 모여 하나의 서비스나 기능을 담당한다.
셀(Cell): 넷플릭스식 표현. 작고 자율적인 팀 단위.
제품팀(Product Team): 가장 일반적인 표현. 하나의 제품이나 서비스를 처음부터 끝까지 책임지는 팀.
Stage-gate processes(단계별 검증 프로세스)
각 단계마다 관련 부서가 공동 검토하는 체계적 진행 방식이다.
신제품 개발 시 컨셉 검토 → 설계 검토 → 시제품 검토 → 출시 검토 단계를 거치며, 각 단계(Gate)마다 관련 부서들이 함께 검증한다. 이런 과정을 반영하게 되면, 부서별로 정보가 체계적으로 흐르게 되는 것뿐만 아니라, 해당 분야별로 의사결정에 공동으로 참여하게 하는 전형적인 수평적 협업 메커니즘이 된다는 것이다. 각 단계에서 "우리 부서만 OK면 된다"가 아니라 "관련된 모든 부서가 함께 OK 해야 다음으로 넘어간다"는 원칙이 작동하면서 업무의 완결성과 신뢰가 확보된다.
이에 해당하는 대표적인 조직 간 일하는 방식으로는 다음의 형태들이 있다.
애자일의 스프린트 리뷰: 2-4주 주기로 개발한 결과물을 이해관계자들이 함께 검토
디자인 스프린트의 체크포인트: 구글이 유명하게 만든 5일 프로세스에서 매일 검증 단계
분기별 체크인(Quarterly Business Review): OKR을 운영하는 회사들이 분기마다 진행하는 공동 검토
IR 단계별 검증: 스타트업이 Pre-seed → Seed → Series A로 넘어갈 때 투자자들과 거치는 검증 단계와 비슷한 논리
Shared metrics(공동 성과 지표)
가장 강력하고 직접적인 협업 촉진제라고 할 수 있다.
각 부서의 각자 KPI가 협업하는 업무와 관계가 없다면, 혹은 협업하는 업무와 Conflict가 있게 된다면, 수평적 협업은 절대 일어나지 않을 것이다.
가령, '신제품 출시 성공률'이나 '고객 만족도' 같은 공동의 목표를 협업하는 부서 간 목표에 나누어 설정하고 이를 성과관리하고 평가에 연계하게 되면 관계 부서들이 협력할 강력한 동기와 유인이 생기게 된다.
예를 들어, 기획팀은 스펙 완성도만, 개발팀은 기능 구현율만, QA팀은 버그 발견 건수만 추구하면 누구도 '제품의 시장 성공'에 책임지지 않는다. 하지만 세 팀 모두 '출시 후 3개월 내 고객 만족도 4.5점 이상'이라는 공동 지표를 갖게 되면, 자연스럽게 협업하게 된다.
대표적으로 공동성과지표를 담는 방식으로는 다음의 방법들이 있다.
북극성 지표(North Star Metric) : 전체 조직이 함께 추구하는 단 하나의 핵심 지표. 넷플릭스의 '주간 시청 시간', 에어비앤비의 '예약 숙박일 수', 토스의 '금융 슈퍼앱 MAU'처럼 모든 팀이 이 지표 향상에 기여하도록 설계된다.
공동 OKR 수립 : 여러 팀이 하나의 Objective(목표)를 공유하고, 각자 다른 Key Result(핵심 결과)로 기여하는 방식. 예를 들어 "Q2에 신규 고객 10만 명 확보"라는 목표를 마케팅팀·제품팀·CS팀이 공유하되, 각 팀은 다른 방식으로 기여한다.
공동 KPI 설정 : 개인 KPI가 아닌, 팀 전체의 성과로 평가하는 방식. 당근마켓의 '우리 동네 거래 성사율'처럼 앱팀·커뮤니티팀·CS팀이 함께 책임지는 지표를 설정한다.
Integrator roles(통합자 역할)
특정 부서에 소속되지 않고, 여러 부서 간의 조율과 협력을 전담하는 역할이다.
프로젝트 매니저(PM), 프로덕트 매니저(PO), 브랜드 매니저 등이 대표적이다. 이들은 공식적인 부하 직원은 없지만, 프로젝트나 제품의 성공을 위해 관련된 모든 부서와 소통하고 자원을 조율하며 갈등을 중재하는 '미니 CEO'와 같은 역할을 한다.
이들은 정보의 허브이자, 부서 간 이해관계를 조정하는 조율자로서, 제품이 실제로 완성되고 출시되도록 만든다. 최근 빅테크를 중심으로 서비스기획, 제품기획자로서 PM에 대한 수요가 늘고 있는데, 새로운 고정된 팀을 조직화하지 않고 조직 내에서 필요한 리소스를 유연하게 확보하고 조직화하면서, 전체 각 고정된 팀 간 조율을 이끌어내는 역할을 하고 있다.
통합자 역할을 실제로 운영하는 대표적인 형태로는 다음이 있다.
PO(Product Owner): 애자일 조직에서 제품의 방향과 우선순위를 결정하는 역할. 개발팀·디자인팀·마케팅팀을 조율하며 제품 백로그를 관리한다.
PM(Product Manager): 제품의 전략부터 실행까지 책임지며, 개발·디자인·마케팅·영업을 아우르는 조율자. 특히 테크 기업에서는 '제품의 CEO'로 불린다.
챕터 리드(Chapter Lead): 스포티파이 모델에서 같은 직군(예: 백엔드 개발자)을 관리하며 여러 스쿼드를 지원하는 역할. 전문성 관리와 성장 지원을 담당한다.
트라이브 리드(Tribe Lead): 여러 스쿼드를 아우르는 상위 조율자로, 제품군이나 사업 영역 단위의 전략과 자원 배분을 책임진다.
(참고: Jay R. Galbraith, 『조직설계방법론』, Star Model)
수평적 경계를 명확하게 정리하고 완결하였어도, 실제로 일이 진행되기 위해서는 조직에서 소위 '보고라인' 혹은 '하이어라키'에 따른 의사결정 주체를 알 수 있는 수직적 정렬이 체계화되어야 한다.
조직도의 수직 라인을 따라 의사결정이 흐른다. 팀장은 무엇을 결정하고, 본부장은 무엇을 결정하며, CEO는 무엇을 결정하는가. 이 의사결정 단계를 몇 개로 구성하고, 각 단계에 어떤 권한과 책임을 부여할 것인가가 수직적 정렬의 핵심이다.
※ 직책과 직급, 다시 한번 구분하기
본격적으로 들어가기 전에, 앞서 조직구조 글에서 다룬 '직책과 직급의 차이'를 명확히 이해하자.
직급(사원, 대리, 과장, 차장, 부장)은 개인의 역량과 경력을 인정하는 등급이다. 역량 사다리이자 보상 기준이지, 의사결정 라인과는 무관하다.
예를 들어, 한 팀에 사원부터 부장까지 모두 있는데 그중 차장 한 명이 팀장이라면? 부장도, 과장도, 대리도 모두 그 차장급 팀장에게 보고하고 결재를 받는다. 의사결정자는 오직 차장급 팀장 한 명이다. 직급이 높은 부장이라고 해서 의사결정권이 있는 것이 아니다.
이 글에서 다루는 수직적 정렬의 핵심은 '직책', 즉 의사결정 단계다. 직급은 나중에 보상 체계를 다룰 때 자세히 살펴볼 것이다.
따라서 직책을 설계할 때는 일이 실질적으로 흐를 수 있도록 다음을 종합적으로 고려해야 한다.
√ 보고 라인(Reporting Line):
누가 누구에게 보고하며 최종 의사결정을 받는지에 대한 보고와 의사결정까지의 라인이 명확해야 한다. 예를 들어, 수도권영업팀장은 영업 1 본부장에게 보고하고, 영업 1 본부장은 영업부문장에게 보고한다는 식의 보고와 의사결정 라인을 두는 것이다.
√ 의사결정 단계(Layer):
몇 단계 관리층을 두어 결정이 내려가는지. 스타트업은 2-3단계, 대기업은 5-6단계가 일반적이다.
√ 관리 범위(Span of Control):
한 직책자가 직접 관리 가능한 적정 인원. 조직구조 글에서 다룬 피자 두 판 법칙처럼 일반적으로 8-9명 수준이 적정하다.
√ 권한 범위:
해당 조직 안에서 일어나는 예산 승인권, KPI 목표 설정권, 성과 평가권 등 실제 권한의 범위이다.
의사결정 단계를 설계할 때 핵심 질문은 "몇 개 단계로 구성할 것인가?"이다.
보통 조직에서 하이어라키(Hierarchy)라고 하며, 조직구조상 세로 라인, 즉 수직라인에 해당한다.
스타트업은 보통 2-3단계로 얇게 간다. CEO → 팀장 → 팀원. 빠른 의사결정과 실행이 생명이기 때문이다. 반면 규모가 커진 대기업의 경우 5-6단계 이상으로 깊다. 가령, CEO → 사업부장 → 본부장 → 실장 → 팀장 → 팀원과 같이 이루어지는데, 이는 그만큼 복잡해진 사업 구조에 따른 리스크 관리가 필요하기 때문이다.
의사결정 단계를 나눌 때 가장 중요한 것은 각 단계가 실질적으로 다른 수준의 의사결정을 담당해야 한다는 점이다. 단계가 많다고 좋은 것이 아니라, 각 단계가 명확히 구분되는 의사결정 범위를 가져야 한다. 일반적으로 하위 단계일수록 일상적이고 단기적인 결정을, 상위 단계일수록 전략적이고 장기적인 결정을 담당한다.
예를 들어, 팀장은 팀의 일상 업무와 단기 목표를 결정한다. 누가 어떤 업무를 맡을지, 이번 주 우선순위는 무엇인지, 고객 문의는 어떻게 처리할지. 본부장은 본부의 전략과 자원 배분을 결정한다. 어느 제품에 더 투자할지, 팀 간 인력을 어떻게 재배치할지, 분기 목표를 어떻게 설정할지. CEO는 전사 전략과 방향을 결정한다. 신사업 진출 여부, M&A, 조직 개편, 핵심 가치 정의 등 조직 전체가 나가야 할 방향과 대외를 대표하는 역할을 맡는다.
만약 해당 단계가 실질적 의사결정을 하지 않는다면, 그 단계는 형식적으로만 존재할 뿐인 소위 '옥상옥'구조에 해당하게 된다.
※ 옥상옥 구조란?
'지붕 위에 또 지붕을 얹는다'는 의미로, 옥상옥(屋上屋)은 실질적인 가치 창출 없이 "관리를 위한 관리" 단계가 쌓여가는 현상을 말한다.
의사결정 단계가 많다고 무조건 옥상옥은 아니다. 각 단계가 서로 다른 수준의 의사결정을 담당한다면 필요한 구조라고 본다. 여기서 문제는 중간에 끼어있는 단계가 아무런 실질적 결정도 하지 않고, 그냥 위로 올리고 아래로 내리는 소위 '전달자 역할'만 하는 경우를 말한다.
예를 들어, 실장이 팀장의 보고를 받아 본부장에게 그대로 전달만 하고, 정작 본인은 어떤 의사결정도 내리지 않는다면? 그 실장 직책은 옥상옥일 수 있다.
현실에서는 이런 구조가 설계 과정에서 만들어지기도 하고, 조직을 운영하면서 종종 자연스럽게 파생되기도 한다. 간혹 뛰어난 성과를 낸 핵심 임원을 예우하기 위해, 혹은 마땅한 보직이 없는 선임을 위해 없던 자리를 만드는 경우도 있을 것이다. "그분을 어디 보내지?"라는 고민에서 시작된 선의의 결정이, 결국 조직 전체를 옥상옥 구조로 만든다.
의사결정 단계를 설계할 때 또 하나 중요한 것은, 모든 사람이 관리자 단계에 올라가야만 성장하는 것이 아니다는 점이다.
많은 조직에서 "승진 = 관리자 되기"라는 등식이 당연시된다. 하지만 조직 전체의 이익을 위하는 관점에서 이 부분을 다시 질문해봐야 한다.
우수한 인재가 성장의지가 있다는 것이 곧 조직내 관리직책자로 성장하는 것 뿐일까?
그리고 그런 관리자의 증가가 조직 전체의 의사결정 질을 높이고, 전문 영역의 수준을 끌어올리는 데 최선인가?
해당 영역의 전문성을 지닌 핵심 인재들이 모두 관리자가 되면, 조직은 고도의 전문성을 잃게 된다. 예를 들어, 뛰어난 개발자가 팀장이 되면 이제 코드를 직접 관리하지 않고, 조직운영과 인력관리에 시간을 써야 한다. 최고 수준의 디자이너가 본부장이 되면 직접 디자인을 하기보다는 내부의 디자이너 양성과 조직관리에 역량을 발휘해야 할 것이다.
이처럼 관리자가 되면 전문성보다는 조직 운영과 관리 역할에 기여하게 되는데, 회사 입장에서 해당 영역의 탑티어 전문 인력을 그렇게만 성장시키고 활용하는 것이 과연 조직에 최선의 기여인가?
더불어, 전문성 있는 우수 인재들 입장에서도 이는 불필요한 딜레마를 강요한다. 더 높은 보상과 인정을 받으려면 자신이 잘하고 좋아하는 일을 포기하고 관리자가 되어야 하는 상황. 조직도 전문성을 잃고, 개인도 본인의 강점을 발휘하지 못하는 구조가 만들어진다.
듀얼 래더: 두 가지 동등한 성장 경로
이 문제를 해결하기 위해 조직에서 종종 활용되는 것이 듀얼 래더(Dual Ladder) 시스템이다. 하나의 사다리가 아니라, 두 개의 동등한 성장 경로를 만드는 것이다.
관리자 트랙(Management Track) 팀장에서 실장, 본부장으로 이어지는 관리 책임 확대 경로다. 사람과 조직운영과 관리에 대한 의사결정을 담당한다. 팀을 이끌고, 자원을 배분하며, 구성원을 성장시키는 데 집중한다.
전문가 트랙(Individual Contributor Track) 시니어 개발자에서 테크 리드, 아키텍트로 이어지는 전문성 심화 경로다. 기술과 전문 영역에 대한 의사결정을 담당한다. 조직도의 관리 단계를 따라 올라가지 않지만, 기술적·전문적 의사결정에서 더 큰 영향력을 발휘한다.
전문가 트랙 안에서도 다양한 스타일이 존재한다. 순수하게 기술 전문성에만 집중하는 경우도 있고, 프로젝트 리더(PM)나 제품 책임자(PO)처럼 전문성과 리더십을 동시에 발휘하는 경우도 있다. 중요한 것은 이들 모두 사람을 관리하지 않으면서도 조직에 큰 영향력을 발휘한다는 점이다.
듀얼 래더 시스템이 실제로 작동하려면, "다른 길이지만 동등한 가치"라는 원칙을 조직 전체가 체화해야 한다.
구글의 Staff Engineer는 Engineering Manager와 동일한 레벨로 인정받으며, 급여나 스톡옵션에서도 차별을 받지 않는다. 더 나아가 기술적 의사결정에서는 오히려 더 큰 발언권을 갖기도 한다. 국내에서도 네이버의 테크니컬 아키텍트나 카카오의 테크 리드들이 이런 역할을 하고 있다.
전문가 트랙에서도 명확한 성장 단계와 그에 따른 보상, 그리고 무엇보다 조직 내에서의 인정과 존중이 따라야 한다. 그렇지 않으면 결국 "팀장이 되어야만 인정받는다"는 인식이 퍼지고, 전문가 트랙은 유명무실해진다.
(참고: "Management shouldn't be a thing you have to do just to get ahead" - Atlee Clark, VP of Talent Operations at Shopify, WorkLife, 2024)
수평적 경계와 수직적 정렬. 이 두 축이 명확히 정리되었다면 조직 안에서 필요한 R&R 설계는 완성이 된 것이다.
하지만 설계한 것을 문서에만 담아두면 아무 일도 일어나지 않는다. 조직도가 그려져 있어도 사람들이 그대로 움직이지 않는 것처럼, R&R도 실제로 작동하게 만드는 과정이 필요하다. 이를 위해서는 설계된 R&R을 명문화하여 구성원들과 공유하고, 실행 과정에서 지속적으로 개선해나가야 한다.
더 중요한 것은, 여기서 설계한 R&R이 이후 다룰 모든 HR 시스템의 토대가 되어야 하고, 실제 의사결정과 협업에 필요한 R&R이 시스템상에서도 반영이 되어야 한다.
그리고 HR시스템의 토대가 된다는 것은, 역할과 책임이 성과관리 기준과 평가, 보상, 그리고 향후 인재관리와도 연관이 된다는 것을 의미한다.
결국 R&R은 조직 전체 HR 아키텍처의 기초 설계이자, 성과관리-평가-보상-인재관리로 이어지는 모든 시스템의 출발점이 된다.
조직의 뼈대(조직구조)와 신경망(역할과 책임)을 설계함으로써 조직 안에서 누가, 무엇을, 어떻게 해야 하는지에 대한 조직의 기본 틀이 완성되었다.
조직구조에서 우리는 조직을 어떤 형태로 나누고, 어떤 원칙으로 업무를 배치하며, 일이 어떻게 흘러가게 할 것인지를 결정했고, 역할과 책임에서는 그 구조 안에서 부서 간 책임의 경계를 명확히 하고, 의사결정 라인을 체계화했다.
하지만 이는 조직이 목표를 향해 실행하기 위한 견고한 기반과 틀을 마련한 것뿐이다.
조직구조가 아무리 잘 설계되어 있고, 역할과 책임이 명확해도, 사람들이 "무엇을 향해 달려가야 하는지" 모르면 각자 자신의 조직 안에서 다른 방향으로 열심히 달리게 될 뿐이다. 개인의 노력이 조직의 성과로 모이려면, 조직을 한데 모으는 공동의 목표가 필요하다. 그리고 "무엇을 중요한 성과로 볼 것인가"에 대한 조직의 명확한 성과 철학이 세워져야 한다.
이어지는 성과관리에서는 바로 이 목표 설정과 성과 철학을 구체적인 시스템으로 설계하고, 이를 통해 어떻게 성과를 만들어 가는지를 보게 될 것이다.
성과관리는 조직의 전략을 실제 구성원의 행동으로 연결하는 HR 아키텍처의 핵심이라 할 수 있다.
우리 조직의 R&R은 실제로 얼마나 잘 설계되고 작동하고 있을까?
다음 세 가지 핵심 질문으로 점검해 보자
□ 권한과 책임이 명확한가?
중요한 의사결정의 최종 책임자는 누구이며, 부서 간 업무의 회색지대는 없는가?
□ 협업이 원활하게 작동하는가?
둘 이상의 부서가 얽힌 문제에서 책임 전가보다 협력을 통한 해결이
더 자주 일어나는가?
□ 구조가 전략을 뒷받침하는가?
현재 역할과 책임 분배가 조직의 성장 방향과 일치하며,
핵심 인재의 성장을 촉진하는가?
이 세 가지 질문에 자신 있게 "예"라고 답하기 어렵다면,
바로 그 지점이 우리가 가장 먼저 들여다봐야 할 개선 영역이다.
조직구조와 협업 설계
Alfred D. Chandler, Jr., "Strategy and Structure: Chapters in the History of the Industrial Enterprise", MIT Press, 1962
Jay R. Galbraith, "Designing Organizations: An Executive Guide to Strategy, Structure, and Process", Jossey-Bass, 2002
의사결정권과 역할 분배
Paul Rogers and Marcia Blenko, "Who Has the D? How Clear Decision Roles Enhance Organizational Performance", Harvard Business Review, January 2006
듀얼 래더와 전문가 트랙
Will Larson, "Staff Engineer: Leadership beyond the management track", 2021
Atlee Clark, "Management shouldn't be a thing you have to do just to get ahead", WorkLife, Shopify, 2024
애자일 조직 운영
Henrik Kniberg and Anders Ivarsson, "Scaling Agile @ Spotify", 2012