HR아키텍처 - 조직구조 ②
(2) 결정권, 업무배치, 흐름 - 조직도는 전략의 구조다
"Structure follows strategy, but strategy is also made to fit structure." "조직구조는 전략을 따르지만, 전략 또한 구조에 맞춰 만들어진다." — Alfred D. Chandler Jr., 경영사학자
제법 규모가 큰 벤처회사에서 HR시스템 계약과 관련해 비용책정의 적정성을 검토해야 하는 절차를 앞두고 있을 때였다.
이미 시스템 호환성과 확장성, 내부 운영 지침과 가이드에 따라 최종 2곳 중에서 선택을 해야 하는 상황이었고, 내부의 다른 시스템들과 견주어 비용 적정성을 의사결정하는 절차를 앞둔 것이었다.
내부 프로세스대로라면, 협의부서에 'IT > 구매 > 재무' 절차로 이해했었는데 갑자기 의외의 인물이 협의 절차에 들어가야 한다는 것이었다.
당시에 '특허'를 담당하는 분이었는데, 창업 초창기부터 그분이 그렇게 협상을 잘해서 가격 네고나 적정성을 검토했었다는 이유로 회사의 대부분의 비용검토에 여전히 관여를 하게 되었다는 것이었다.
당황스러운 상황은 정작 그 본인도 "이게 적정한가?"를 오히려 IT와 HR에 문의를 한다는 것.
왜 이런 억지스러운 상황이 유지되는 걸까?
조직구조는 전략을 실행하고 사람을 배치하는 설계도 그 이상의 의미가 있다.
Jay R. Galbraith는 조직구조가 곧 의사결정 권한(location of decision-making power)의 위치를 정한다고 말한다 — 즉 조직도를 통해 누가 어떤 결정을 내릴지(권한의 위치)를 설계해야 한다.
Henry Mintzberg는 조직구조를 “노동이 어떻게 나뉘고 그 분업을 어떻게 조정하느냐의 총합”이라고 정의하여, 조직이 어떻게 구성되고 작동하는지를 보여주는 운영 지도(Operating Map)라고 이해할 수 있다.
즉, 조직구조를 그리는 일은 어떤 원칙으로 나뉘고, 어떻게 흘러가며, 그 흐름 속에서 성과가 어떻게 만들어지는지를 보여주는 일종의 관리와 운영의 지도를 만드는 것이다.
하지만 종종 위의 사례처럼 새로운 조직구조를 그려도 변화가 없는 경우를 보게 되고,
오히려 커뮤니케이션 비용만 증가하거나, 일의 비공식적인 협의와 의사결정이 증가하기도 한다.
이러한 상황은 조직구조에 무엇을 어떻게 담았는가를 체크해 보면 알 수 있다.
그래서 이번 글에서는 실제로 조직도를 설계하고 나서 '무엇을 담을 것인가'를 다루고자 한다.
목적에 맞게 잘 설계된 조직도라면 다음 세 가지를 명확히 읽고 업무를 수행할 수 있어야 한다.
① 누가 결정하는가? (계층 구조와 소속 라인)
② 어디서 무슨 일을 하는가? (업무 배치의 원칙)
③ 일이 어떻게 흘러가는가? (조직 형태에 따른 흐름)
조직구조를 설계한 후 이 세 가지가 조직도 안에서 명확히 보일 때, 조직은 비로소 '작동하는 구조'를 갖게 된다고 할 수 있다.
조직도를 보면서는 위의 순서대로 눈에 들어오지만,
실제로 조직구조를 설계할 때는 역순으로 접근하게 될 것이다.
이는 전략 다음에 흐름 → 업무 배치 → 계층 순서로 사고하는 것으로,
먼저 우리 전략에 맞는 일의 흐름을 정하고(③ 조직 형태 선택),
그다음 업무를 어떻게 쪼개고 배치할지 결정하며(② 업무 배치),
마지막으로 의사결정 구조와 계층을 확정하는 것(① 계층 설계)이 설계의 흐름이기 때문이다.
맨 위에서 언급했던 Alfred Chandler의 "Structure follows strategy"도 바로 이 순서를 의미하는 것으로, 전략이 일의 흐름을 결정하고 그 흐름으로 구조가 만들어진다.
하지만 이 글에서는 '조직도가 무엇을 담아야 하는가'를 직관적으로 이해하기 쉬운 순서(①→②→③)로 설명할 것이다. 조직도를 보면서 이해하는 방식과 실제로 설계하는 방식은 다르기 때문이다.
그럼, 각각이 무엇을 의미하는지 살펴보자.
① 누가 결정하는가? - 계층 구조와 소속 라인
조직도에서 가장 먼저 보여야 하는 것은 누가 누구 밑에 있고, 누가 결정권자인가에 관한 정보이다. 하지만 실무에서는 이것을 생각보다 명확하게 이해하지 못하는 경우가 종종 발견된다.
"팀장이 결정하나요, 본부장이 결정하나요?" "이 사람은 부장인데 왜 팀장 밑에 있나요?"
이런 질문이 반복되는 이유는 무엇일까?
단순히 이름을 박스에 배치하는 것만으로는 충분하지 않다.
각 조직에서 누가 최종 결정을 내리는지, 보고는 어느 조직을 거쳐 몇 단계에 이르는지를 명확하게 구성원들이 인지할 수 있도록 설계해야 한다.
계층 구조와 소속 라인 : 보고는 어느 조직을 거치고, 몇 단계에 이르는가?
계층은 소위 우리가 'Hierarchy'라 부르는 것을 의미하며, 의사결정의 수직적인 단계를 알 수 있는 정도이다. 보통 조직도를 보면 다음과 같은 조직구조가 보인다.
영업부문 > 영업 1 본부 > 수도권영업팀
개발부문 > 플랫폼본부 > 백엔드개발팀
그리고 조직이름이 들어간 박스와 박스 사이의 이어지는 라인을 따라 책임과 의사결정이 흐른다. 조직도에서 박스는 해당 조직의 의사결정이 모이는 지점이다.
직책 : 각 조직의 의사결정 권한자는 누구인가?
조직도에 그려진 박스와 선으로 이루어진 공식 조직은 '직책(Position)'을 중심으로 그려진 구조이다. 팀장, 파트장, 본부장, CEO와 같은 직책은 조직도에서 해당 조직의 자원에 대한 책임과 권한이 집중되는 의사결정 지점이다.
Galbraith는 "Structure determines the location of decision-making power", 즉 조직구조가 권한의 위치를 결정한다고 강조했다. 따라서 조직구조를 설계할 때 직책을 중심으로 고려해야 하는 것은 다음과 같다.
보고 라인(Reporting Line): 누가 누구에게 보고하며 최종 의사결정을 받는지
의사결정 단계(Layer): 몇 단계 관리층을 두어 결정이 내려가는지
통제범위(Span of Control): 한 직책자가 직접 관리 가능한 적정 인원
결국 조직도를 그린다는 것은 이 직책들을 어떻게 배치하고, 어떤 라인으로 연결할 것인가를 설계하는 일이다.
직급과 혼동하지 않기
여기서 잠깐...
주변에 인사를 꽤 하셨던 분들 중에서도, 혹은 막 창업한 스타트업에서 인사를 하시거나 경영진 분들 중에서도 많이들 혼동하는 부분이 있다. 바로 조직도를 그릴 때 직책과 직급을 헷갈려한다는 것.
직급(Grade)은 개인의 성장 사다리이자 보상 체계를 결정하는 기준이다.
우리가 흔히 대리, 과장, 차장, 부장과 같이 호칭하는 형태로 이루어지는 것이 직급의 전형적인 모습이다. 직급을 보면 그 사람이 조직 내에서 어느 정도의 경력과 전문성을 쌓았는지를 알 수 있으며, 그에 따라 급여와 복리후생 수준이 달라진다.
직책(Position)은 조직도 상에서 그 사람이 어떤 의사결정 권한과 책임을 가지는지를 보여주는 것이다.
이를 실제 현장에서 대입해 보면 보통 아래의 상황과 같다.
동일한 직책이라도 직급이 다를 수 있지만, 조직구조에서 중요한 것은 결국 조직에서 책임을 맡게 되는 직책을 중심을 중심으로 책임과 권한에 대해 의미를 부여한다는 점이다.
부장급 팀장: 부장 직급을 가진 팀장 직책
차장급 팀장: 차장 직급을 가진 팀장 직책
전무급 대표이사: 전무 직급을 가진 대표이사 직책
부사장급 대표이사: 부사장 직급을 가진 대표이사 직책
조직도를 설계한다는 것은 결국 직책을 배치하는 일이다.
어떤 직책을 만들고, 어떤 라인으로 연결하며, 각 직책에 어떤 권한과 책임을 부여할 것인가.
그리고 배치된 각 직책에 구체적으로 어떤 역할을 부여하고, 어디까지 권한을 주며, 무엇을 책임지게 할 것인지는 조직구조 설계 이후 반드시 정의해야 할 영역이다.
※ 다만, 직책에 대한 역할과 권한, 책임의 구체적 설계 방법과 직책-직급 분리 운영 원칙 등은 다음 시리즈인 "HR아키텍처 - 역할과 책임" 편에서 실제 운영 관점에서 상세히 다루기로 한다.
② 어디서 무슨 일을 하는가 - 업무를 쪼개는 원칙
조직설계 시 일의 흐름에 맞게 조직구조 형태를 정했다면(예, 사업부조직, 기능조직), 이제 업무를 어떻게 쪼개고 배치할지 결정해야 한다.
그리고 우리가 조직도를 보면서 의사결정을 누가 하는지부터 확인한 다음 두 번째로 확인하게 되는 부분 역시 '업무를 어떻게 배분했느냐'이다
Mintzberg는 조직설계에서 업무를 어떻게 그룹핑(grouping)하느냐가 구조의 핵심이라고 강조했다. 업무를 묶는 방식에 따라 권한 배분, 조정 방식, 정보 흐름, 협업 형태를 결정하게 되고, 이는 곧 조직의 효율성, 협업 품질, 의사결정 속도가 달라지기 때문이다.
그렇다면 실무에서 업무를 쪼개고 배치할 때 어떤 기준과 원칙을 적용해야 할까?
일을 나누는 데 정답은 없지만 최소한 다음 네 가지 원칙을 고려하도록 권한다.
1. 시너지(효율 극대화) : 관련 업무는 묶는다
같이 하면 효율이 높아지는 일은 한 팀 혹은 하나의 그룹에 배치하는 것이다.
<예시> 제품 기획 + 개발 + 마케팅 → 제품팀고객 응대 + 불만 처리 + 피드백 수집 → CS팀데이터 수집 + 분석 + 리포팅 → 데이터팀
관련 업무를 묶으면 팀 내에서 의사소통이 빨라지고 실행이 즉각적으로 이뤄진다. 외부 요청과 대기 시간이 줄어들고, 결과적으로 협업 비용이 낮아지며 실행 속도가 개선된다.
2. Check & Balance(견제와 균형) : 이익 충돌하는 업무는 분리한다
상충되는 이해관계를 하나의 조직에 담지 않는다.
조직구조를 설계할 때는 권한과 책임을 적절히 분산하고, 서로 다른 부서나 역할이 자연스럽게 견제할 수 있는 구조적 장치를 마련해야 한다. 이는 조직의 투명성을 높이고 더 나은 의사결정을 가능하게 한다.
대표적인 예시를 들어보자.
1) 개발팀 vs QA팀: 개발팀은 속도를 책임지고, QA팀은 품질을 책임진다.
QA가 개발팀장 밑에 있으면 일정 압박으로 품질 테스트를 생략할 가능성이 있다. 따라서 별도 보고 라인에 배치하여 건강한 긴장 관계를 유지한다.
2) 영업팀 vs 재무팀: 영업팀은 매출 극대화를, 재무팀은 비용 관리를 책임진다.
영업팀이 무리한 할인이나 조건을 제시하려 할 때, 재무팀이 재무 건전성 관점에서 견제한다.
3) 구매팀(낮은 가격 추구)과 품질관리팀(높은 스펙 추구)의 분리도 같은 원리다.
이렇게 분리하면 서로 견제하면서 조직 전체의 균형을 맞출 수 있다.
따라서 업무를 어떻게 나누느냐는 갈등을 어떻게 관리하느냐의 문제이기도 하다.
※ 이렇게 분리한 후 실제 운영에서 발생하는 부서 간 회색지대, 책임 공백, 업무 중복을 어떻게 해결할지, 그리고 누가 최종 책임자인지(Decision Rights)를 명확히 하는 방법 등.. 실질적 운영과 관련한 내용은 HR아키텍처 - 역할과 책임 편에서 다룬다.
3. Span of Control(관리 가능 범위) : 감당 가능한 범위로 쪼갠다
한 팀 또는 한 사람이 감당 가능한 범위로 업무를 나눈다.
<예시>한 팀장이 관리하는 인원: 6~8명 (피자 두 판 법칙)한 개발자가 담당하는 모듈: 복잡도와 유지보수 가능성 고려한 PM이 관리하는 프로젝트: 동시 진행 가능한 개수
적정 관리 범위를 넘어서면 관리 품질이 떨어지게 된다. 리더는 팀원 개개인의 일과 성장에 대해 충분히 코칭할 수 없고, 업무 진척도 파악도 어려워진다. 아무리 좋은 사람을 배치해도, 한 사람이 감당할 수 있는 범위를 넘어서면 결국 병목이 생길 수밖에 없다.
4. 유사성(전문성 강화) : 비슷한 일은 한 곳에 모은다
시너지 원칙이 '함께 일해야 하는' 업무를 묶는 것이라면, 유사성 원칙은 '같은 전문성을 가진' 사람들을 모으는 것이다.
즉, 시너지 = 협업 효율 (다른 직군도 함께), 유사성 = 전문성 성장 (같은 직군끼릴 모임)
따라서, 같은 기술, 같은 언어, 같은 방법론을 쓰는 전문가들을 함께 배치한다.
<예시> 프런트엔드, 백엔드, 데이터 엔지니어링 → 개발본부브랜드 마케팅, 퍼포먼스 마케팅, PR → 마케팅본부재무회계, 관리회계, 세무 → 재무본부
이렇게 모으면 조직 내에 전문성이 축적되고, 기술적 노하우가 공유되며, 서로의 성장을 자극할 수 있게 된다. 게다가 같은 전문 언어를 쓰는 사람들이 모여 있으면 깊이 있는 기술 논의가 가능하고, 업계 최신 트렌드도 함께 학습할 수 있다. 예를 들어, 백엔드 개발자는 제품팀에 흩어져 있어도 개발본부 소속으로 묶여 있으면 코딩 스타일, 아키텍처 설계, 신기술 도입 등을 함께 논의하고 발전시킬 수 있다.
실제 조직을 설계할 때는 이 네 가지 원칙이 서로 충돌하기도 한다.
시너지를 위해 묶으면 유사성이 약해지고, 견제를 위해 분리하면 협업 비용이 증가하기도 한다.
그러기에 완벽한 정답은 없으며, 우리 조직의 상황에 따른 우선순위 원칙을 두어 조합하고 균형을 맞추는 과정이 필요하다.
이렇게 네 가지 원칙을 조합하여 업무를 배치하면, 조직도는 단순한 구조도가 아니라 전략 실행의 설계도가 된다.
※ 마찬가지로 각 원칙을 실제로 어떻게 적용하고, 원칙 간 충돌이 발생할 때 어떻게 조정할지, 부서 간 회색지대를 어떻게 해결할지 등의 운영에 관한 것은 HR아키텍처 - 역할과 책임 편에서 구체적으로 다루도록 한다.
③ 일이 어떻게 흘러가는가 - 조직 형태의 선택
조직의 전략에 따라 조직구조를 설계할 때, 실제 설계는 여기서부터 시작한다.
우리 전략이 요구하는 일의 흐름이 무엇인지 정의하고, 그에 맞는 조직 형태를 선택하는 것이 조직구조 설계의 출발점이다.
Chandler가 "Structure follows strategy"라고 했을 때, 그가 의미한 것은 전략이 일의 흐름을 결정하고, 그 흐름에 맞는 조직 형태를 선택해야 한다는 것이었다. 이론뿐만 아니라 실제로 조직구조 설계를 시작하면 이 단계의 선택을 통해 우리 조직의 전략을 어떻게 더 효과적으로 조직에 담을지를 결정하게 된다.
반대로 완성된 조직도를 통해 알게 되는 것으로는 누가 결정하는지 - 어디에 일이 있는지 - 일이 어떻게 흐르는지 순으로 이해하는 것이 더 직관적일 것이다.
그리고 조직형태에 따라 조직을 어떤 원리로 나눴고, 그에 따라 일이 어떻게 흐르는가. 즉, 일이 흘러가는 방식이 결정된다.
조직 형태는 시대와 산업에 따라 진화해 왔다. 전통적으로는 기능 중심과 사업부 중심이 가장 보편적이었고, 1970년대 이후 매트릭스 조직이 등장했다. 최근에는 스타트업과 빅테크를 중심으로 스쿼드형(스포티파이 모델) 조직이 확산되고 있으며, 나이키 같은 기업은 네트워크형 조직으로 핵심 역량에만 집중한다.
여기서는 실무에서 가장 많이 활용되는 다섯 가지 대표적인 조직 형태를 살펴본다. 각 형태는 일이 흐르는 방식이 근본적으로 다르며, 그에 따라 장점과 한계도 명확하다.
조직 형태별 업무 흐름 비교
<5가지 주요 조직형태>
기능형 조직
기능형 조직은 같은 전문 분야끼리 묶어서 조직을 나누는 방식이다.
예를 들어 개발은 개발끼리, 마케팅은 마케팅끼리, 영업은 영업끼리 하나의 그룹으로 모이는 조직형태이다.
따라서 일은 한 조직에서 다음 조직으로 넘어가며 완성하게 된다. 즉, 개발팀이 제품을 만들어 넘기면 QA팀이 테스트를 진행하고, QA가 끝나면 마케팅팀이 홍보 준비를 시작하며, 최종적으로 영업팀이 고객에게 판다.
조직에서 기능형 조직을 선택하게 될 때 가장 큰 이유는 전문성을 극대화하여 활용할 수 있는 장점 때문이다. 개발자는 온종일 개발만 하고, 마케터는 온종일 마케팅만 하며, 같은 분야 사람들끼리 모여 있으니 깊이가 생긴다. 코드 품질을 논하고, 최신 기술을 배우고, 서로의 작업을 리뷰하며 수준을 높인다.
두 번째 이유는 비용 효율이다. 만약 10명의 개발자가 필요하면 딱 10명만 뽑으면 된다. 사업부형처럼 각 팀마다 개발자를 중복 배치할 필요 없고, 같은 기능끼리 모이므로 내부에서 전문성간 시너지가 증가하게 된다.
하지만 기능형 조직은 각 조직 간 목표가 전체의 조합에서 충돌하거나 조화를 이루지 못한 채 개별화될 수 있는. 즉, 사일로의 문제가 우려될 수 있다.
개발팀은 "기술적으로 완벽하게" 만드는 것이 목표이고, 마케팅팀은 "메시지를 매력적으로" 만드는 것이 목표이다 보니, 누구도 "고객이 처음 제품을 보고 구매하고 사용하기까지의 전체 경험"을 책임지지 않게 될 수 있다. 부서 간 벽이 높아질수록 협업은 어려워지고, 각 부서는 자기 영역 안에만 갇힌다.
기능형 조직이 주로 등장하는 시점은 조직 성장의 초기 단계에서 선택된다.
창업기를 지나 본격적으로 일을 구분 짓기 시작하고, 의사결정을 분화해서 각 기능을 정비하며 전문성을 키워가는 시기. 즉, 제품이나 서비스가 단일하거나 적고, 각 기능별 전문성을 구축하는 것이 가장 중요한 과제일 때 적합하다.
대표적인 기능형 조직으로 성장한 회사로는 애플을 들 수 있다. 애플은 현재도 기능형 조직을 유지하며, 각각의 디자인팀, 하드웨어 엔지니어링팀, 소프트웨어 엔지니어링팀이 립적으로 존재하면서, 분야별로 세계 최고 수준을 추구한다. 팀 쿡 CEO 아래 각 기능별 수석 부사장(SVP)들이 전 세계 해당 기능을 총괄한다. 애플 제품의 완성도는 이 전문성에서 나온다.
사업부형 조직
사업부형 조직은 제품이나 시장, 고객군별로 조직을 나누고, 각 사업부가 필요한 모든 기능을 내부에 갖추는 방식이다. 예를 들어 A제품팀에 기획자, 개발자, 마케터, 영업이 모두 있다면, B제품팀도 동일한 구조로 조직을 이루게 된다. 즉, 모든 각 사업부는 소위 작은 회사와 같은 완결형태의 조직구조를 갖게 되며, 사업부에서 벌리는 일은 각 사업부 안에서 시작되고 끝이 나게 된다.
가령, A제품팀은 기획부터 개발, 마케팅, 영업까지 모든 과정을 스스로 완결한다.
다른 팀의 승인을 기다리거나 협조를 구할 필요가 없으므로, 의사결정권자가 명확하고, 성과 책임도 명확하며, 일의 진행속도가 빠르다는 특징이 있다.
조직에서 사업부형 조직을 선택하게 될 때 가장 큰 이유는 자율성과 책임의 일치가 가장 크다고 볼 수 있다. 사업부장은 마치 작은 회사의 CEO처럼 움직이게 되며, 시장이 변화에 독립적으로 즉시 대응할 수 있게 되고, 고객의 요구에도 유연하고 빠르게 해결할 수 있다. 또한 전체 고객 경험을 한 사업부에서 책임지기 때문에 기능형 조직처럼 부서 정보 비대칭으로 인한 비효율이 없고, 어느 기능의 탓인지를 각개로 따질 이유가 없다. 즉, 사업부조직의 가장 큰 장점은 각 시장이나 제품군이 요구하는 속도로 독자적으로 움직일 수 있다는 것이다.
하지만 사업부형 조직은 리소스 중복과 사업부 간 단절이라는 한계를 갖는다.
가령 A사업부도 개발자가 필요하고, B사업부도 개발자가 필요하기 때문에, 전사의 관점에서 보면 같은 역할이 여러 팀에 중복 배치되어 비용이 증가한다. 또한 팀 간 지식과 기술의 단절로 인해, A사업부가 개발한 우수한 기술을 B사업부에서 모르고 다시 개발하거나, 각 팀이 서로 다른 기술 스택을 사용하면서 회사 전체의 시너지는 약해진다.
즉, 사업부조직을 운영하게 되면 전사적 관점에서는 리소스 운영과 관리에서의 비효율적인 면이 상대적으로 증가하게 된다.
사업부형 조직이 주로 등장하는 시점은 조직이 다각화 전략을 추진할 때이다.
제품 라인이 늘어나거나, 여러 시장에 진출하거나, 각기 다른 고객군을 대상으로 사업을 펼칠 때 필요하다. Alfred Chandler가 "구조는 전략을 따른다"라고 했을 때, 그가 주목한 것이 바로 이 지점이다. 다각화 전략을 추진하는 기업은 필연적으로 사업부 구조로 전환하게 된다.
대표적인 사업부형 조직으로는 삼성전자를 들 수 있다.
스마트폰을 만드는 MX사업부, 반도체를 만드는 DS사업부, 가전을 만드는 CE사업부가 각각 독자적인 경영을 한다. 각 사업부는 자체 연구소, 생산시설, 마케팅 조직을 갖추고 있으며, 사업부장이 마치 하나의 회사 CEO처럼 전권을 행사한다. 덕분에 시장 변화에 빠르게 대응하면서 성장할 수 있었다.
매트릭스 조직
매트릭스 조직은 쉽게 말해 한 사람이 두 개의 보고 라인을 갖는 구조라고 볼 수 있다.
즉, 기능 조직과 제품(또는 프로젝트) 조직을 동시에 교차하면서 운영하는 방식이다.
예를 들어 한 개발자는 '개발본부'에 소속되어 개발본부장에게 보고하지만, 동시에 'A제품 프로젝트팀'에도 참여하여 A제품 PM에게도 보고한다. 즉, 두 상사를 모시게 되는 구조인 것이다.
따라서 일의 진행은 기능 축과 제품 축이 교차하면서 흐르게 된다.
개발자는 기능 조직(개발본부)에서 기술 역량을 키우고 표준을 배우면서 동시에, 실제 업무는 제품 프로젝트에서 수행한다. 기능 리더는 기술적 품질과 표준을 책임지고, 프로젝트 리더는 고객 만족과 납기를 책임진다. 두 관점이 균형을 이루면 높은 품질과 빠른 대응을 동시에 달성할 수 있다.
조직에서 매트릭스 조직을 선택하게 될 때 가장 큰 이유는 희소한 리소스를 효율적으로 활용하면서도 여러 프로젝트에 유연하게 대응하기 위해서라고 볼 수 있다.
매트릭스 조직으로 운영하게 되면, 같은 개발자가 여러 프로젝트에 투입되어 전문성을 공유하고, 동시에 각 프로젝트는 필요한 전문가를 적시에 확보할 수 있다. 사업부형처럼 인력을 중복 배치할 필요도 없고, 기능형처럼 부서 간 벽에 갇히지도 않는다.
즉, 매트릭스 조직의 가장 큰 장점은 전문성과 고객 대응을 동시에 가져갈 수 있다는 점이다.
반면, 매트릭스 조직은 이중 보고로 인한 복잡성이 가장 큰 이슈이기도 하다.
기능 리더는 "코드 품질을 높여라"라고 하고, 제품 리더는 "일정을 맞춰라"라고 하는 등, 이 둘은 종종 다른 목표와 일의 우선순위를 요구한다. 구성원 입장에서는 "누구 말을 먼저 들어야 하나?" 하는 상황에 종종 놓이게 된다.
또한, 성과 평가나 책임 소재도 두 리더 간 조율이 필요하여 자칫 운영을 잘못할 경우, 구성원의 입장에서는 마치 하늘에 두 개의 태양이 뜬 것과 같은 상황을 접하게 될 것이다.
그러므로, 매트릭스 조직을 운영하려면, 이런 복잡성을 관리할 수 있는 조직 역량과 문화가 전제되어야 하고, 이를 효과적으로 관리할 수 있는 관리시스템(예 : 성과관리 시스템, 협업시스템 등)이 갖추어져 있어야 한다.
매트릭스 조직이 주로 등장하는 시점은 1) 복수의 프로젝트를 동시에 진행해야 하는데, 각 프로젝트가 전담 팀을 구성할 만큼 크지 않을 때, 2) 전문 인력이 희소해서 여러 프로젝트에 공유해야 할 때, 3) 인사 및 리소스 운영을 효율화해야 할 때로 크게 세 가지의 상황으로 볼 수 있다.
이 조직형태는 1950-60년대 미국 항공우주 산업에서 처음 등장했는데, 당시 NASA 프로젝트들은 매우 복잡했지만 전담 조직을 만들기에는 규모가 애매했고 전문 엔지니어가 부족했기 때문에. 매트릭스는 이 문제를 해결하는 혁신이었다.
대표적인 매트릭스 조직으로는 글로벌 컨설팅 회사들을 들 수 있다.
McKinsey나 BCG에서 컨설턴트는 'Strategy Practice'나 'Operations Practice' 같은 기능 조직에 소속되면서, 동시에 특정 고객사 프로젝트 팀에도 투입된다. Practice 리더는 그의 전문성 성장과 방법론 품질을 책임지고, 프로젝트 리더는 고객 만족과 납기를 책임진다. 이 구조 덕분에 한정된 전문가를 여러 프로젝트에 유연하게 배치하면서도 높은 품질을 유지할 수 있다
스쿼드형 조직 (스포티파이 모델)
스쿼드형 조직은 작은 자율팀(스쿼드) 이 제품 개발의 모든 것을 책임지되, 같은 직군끼리 모이는 커뮤니티(챕터)를 통해 전문성을 키우는 구조다.
예를 들어 스포티파이에서 한 개발자는 '플레이리스트 스쿼드'에 소속된다.
이 스쿼드는 6~10명 규모로, 백엔드 개발자, 프런트엔드 개발자, 디자이너, 데이터 분석가가 모두 포함되어 있다. 동시에 그 개발자는 '백엔드 챕터'에도 속한다. 즉, 제품팀(스쿼드)과 전문가 커뮤니티(챕터) 두 곳에 동시에 소속되는 형태이다.
따라서 일은 스쿼드 내부에서 완결된다. 스쿼드는 "무엇을 만들지, 언제 출시할지"를 스스로 결정하고, 스쿼드 리더 한 명에게만 보고한다.
챕터는 보고 라인이 아니라 같은 직군끼리 모여 코드 리뷰를 하고, 새로운 기술을 학습하고, 개발 표준을 논의하는 커뮤니티로 존재한다. 챕터 리드는 기술 멘토일 뿐, 업무 지시권도 평가권도 갖지 않는다.
조직에서 스쿼드형 조직을 선택하게 될 때 가장 큰 이유는 빠른 의사결정과 높은 민첩성 때문이다. 구조만 보면 매트릭스처럼 제품축(스쿼드)과 기능축(챕터)이 교차하지만, 결정적 차이는 의사결정 권한이다. 매트릭스는 두 리더 모두 의사결정권을 갖지만, 스쿼드형은 오직 스쿼드 리더만 결정한다. 즉, 매트릭스 조직에서 보였던 이중 보고의 복잡성이 제거된다.
따라서 스쿼드형 조직의 가장 큰 장점은 매트릭스의 이중 보고 복잡성 없이 빠른 의사결정을 유지하면서도, 챕터를 통해 전문성 성장이라는 기능형 조직의 장점도 가져갈 수 있다는 점에 있다.
하지만 스쿼드형 조직은 스쿼드 간 조율과 전사 표준 유지에서 균형을 가져가야 한다는 이슈가 늘 존재하게 된다.
이는 각 스쿼드가 자율적이다 보니, 스쿼드마다 다른 기술 스택을 선택할 수 있다는데 핵심이 있다.
가령 A스쿼드는 자체 개발한 결제 시스템을, B스쿼드는 외부 설루션을 선택하거나, 똑같은 로그인 기능을 여러 스쿼드가 각자 개발할 수도 있다. 이렇게 되면 나중에 한 팀에서 개발한 기능을 다른 팀이 이어받거나 통합할 때 복잡성이 증가하게 될 것이다.
똑같은 로그인 기능을 여러 스쿼드가 각자 개발할 수도 있다. 챕터에서 "전사 표준을 만들자"라고 논의하지만, 각 스쿼드는 자율적 운영을 원칙으로 하기 때문에 이를 강제하기 어렵게 된다.
즉, 전사 차원의 일관성과 스쿼드의 자율성 사이에서 균형을 찾는 것이 운영상 핵심 과제인 것이다.
스쿼드형 조직이 주로 등장하는 시점은 빠른 혁신이 생존의 조건인 테크 기업들이 성장기에 접어들 때이다.
자율적 팀 문화를 중시하고, 실험과 실패를 통한 학습을 장려하며, 관료적 승인 절차 없이 빠르게 시장에 출시하는 것이 중요할 때 이 구조가 적합하다.
대표적인 스쿼드형 조직으로는 스포티파이를 들 수 있다. 스포티파이가 이 모델을 만들고 실행하면서 전 세계 테크 기업들이 주목했다. 다만 스포티파이도 시간이 지나면서 이 모델의 한계를 경험하고 일부 수정을 거쳤다. 자율성과 일관성의 균형은 지속적인 조율이 필요한 영역이기 때문이다.
네트워크형 조직
네트워크형 조직은 핵심 역량에만 내부 조직을 집중하고, 나머지는 외부 파트너와 협력하는 방식이다. 조직의 경계가 회사 안에 머물지 않고 밖으로 확장된다.
예를 들어 나이키는 디자인, 브랜딩, 마케팅에만 집중한다. 신발을 직접 만드는 공장은 하나도 없다. 베트남, 중국, 인도네시아 등 전 세계 수백 개 협력 공장이 제조를 담당한다. 즉, 핵심 역량은 내부에, 비핵심 기능은 외부 파트너십으로 운영하는 형태이다.
따라서 일은 내부와 외부가 유기적으로 연결되며 흐른다.
나이키 디자이너가 새 운동화를 설계하면, 베트남 공장에서 시제품을 만들고, 나이키 품질팀이 검수하고, 중국 공장에서 대량 생산하고, 글로벌 물류 파트너가 전 세계로 배송한다. 나이키는 이 모든 과정을 조율하지만, 직접 실행하지는 않는다.
조직에서 네트워크형 조직을 선택하게 될 때 가장 큰 이유는 핵심 역량에 집중하기 위해서일 때이다. 나이키는 "브랜드를 만드는 일"에 모든 에너지를 쏟는 대신에 공장을 짓고, 생산라인을 관리하고, 재고를 쌓는 데 자원을 배분하지 않는다. 이런 경우 브랜드가 핵심 자산이고, 제조는 핵심 역량이 아닐 때 이 선택이 가능하다.
즉, 네트워크형 조직의 가장 큰 장점은 유연한 확장성이다. 시장 수요가 늘면 협력사를 늘리고, 줄면 줄인다. 고정비용이 최소화되고 확장 속도는 극대화된다.
네트워크형 조직에서는 외부 협력과의 관계에서의 통제와 품질 관리가 성공의 key가 된다.
협력 공장은 자사 직원이 아니기 때문에, 품질 문제가 발생하거나 납기가 지연될 때 직접 개입하기 어렵다. 특히 2000년대 초반 나이키는 협력 공장의 아동 노동과 열악한 근로 환경 문제로 국제적 비난을 받았는데, 이때 나이키 본사는 직접 관여한 일은 아니었지만, 파트너사의 문제가 곧 나이키 브랜드의 위기가 되었다. 이후 나이키는 협력사 관리 시스템을 대폭 강화하면서, 정기 감사, 인권 기준 준수, 투명성 보고를 의무화했다. 유연성과 통제 사이에서 균형을 찾는 것이 네트워크형 조직의 지속적인 과제인 것이다.
네트워크형 조직이 주로 등장하는 시점은 조직이 성숙기에 접어들고, 핵심 역량에 집중하면서 비핵심 기능을 외부화할 때다.
가령, 브랜드가 핵심 자산이고, 제조나 물류가 핵심 역량이 아닐 때 이 구조가 적합하다.
글로벌 확장을 빠르게 추진해야 하지만 직접 인프라를 구축하기에는 자본과 시간이 부족할 때도 유효하다.
대표적인 네트워크형 조직으로는 나이키를 들 수 있다. 나이키 외에도 자라(Zara)의 패스트 패션모델, 애플의 제조 파트너십(폭스콘), 수많은 D2C 브랜드들이 이 방식을 활용하고 있다.
조직형태를 선택하는 설계 원칙
조직구조를 어떻게 설계하는 것이 좋을지에 대한 정답은 없다. 다만, 현재 그리고 미래를 예측해서 우리 상황에 맞는 최선의 선택을 하면서도, 모든 장점을 다 가질 수는 없다는 것을 받아들여야 한다.
조직 형태를 선택할 때 가장 먼저 봐야 할 것은 우리가 가고자 하는 방향과 전략의 우선순위이다.
효율이 최우선이라면 기능형 조직이 적합하다. 이를 선택하면서 전문성을 집중시키고 중복을 최소화할 수 있다.
사업 추진 속도와 혁신이 중요하다면 사업부형이나 스쿼드형이 효과적이다. 각 팀이 의사결정부터 실행까지 빠르게 완결할 수 있다.
전문성과 고객 대응을 동시에 취하면서, 운영 효율까지 챙겨야 한다면, 매트릭스 조직을 고려할 수 있다. 다만 이중 보고 라인을 관리할 수 있는 조직 내 관리역량과 시스템이 전제되어야 한다.
현장에서 자주 발견되는 패턴을 보면, 창업 초기에는 대부분 기능형으로 시작한다.
빠르게 성장하면서 제품이나 사업이 다양해지면 사업부형이나 매트릭스 조직, 스쿼드형 조직을 고민하게 된다. 하지만 이건 절대적 공식이 아니며, 중요한 것은 규모가 아니라 전략 우선순위라는 것을 기억해야 한다.
실제 경영현장을 들여다보면 같은 조직 내에서도 경영 상황에 따라 하이브리드 조직형태로 운영되는 경우가 많다. 핵심 사업은 기능형으로 안정적으로 운영하고, 신사업은 사업부형으로 빠르게 실험하는 식이다.
조직의 형태가 적합한가에 대해서 어느 시기에 재검토를 해야 하는가에 대해서도 정해진 답은 없다. 게다가 성장단계와 어떤 산업군에 있느냐에 따라서도 조직을 다시 재편하고 조직형태와 구조를 재설계하는 작업의 주기는 매우 다르다. 가령, 조직 성장단계 초기에는 빠른 템포로 변화하기 때문에 실제 빠르게는 1~3개월 이내로 변경되는 경우도 있고, 같은 성장단계라 할지라도 제품이나 서비스 호흡이 긴 사업 - 예를 들어 중후장대 산업이나 기계산업 - 의 경우 그 기간이 더 길어질 수도 있다.
하지만 이와 관계없이 현재 내부의 리소스 운영과 관리에 대한 효율성, 혹은 효과성에 대한 재검토가 이루어지고 있거나, 외부의 급격한 대응에 현재 조직으로 무리가 있다고 판단된다면 그때는 주기나 성장단계와 관계없이 바로 조직형태를 재검토해야 하는 시기일 수 있다.
이를 체크해 볼 수 있는 간단한 질문을 던져보면 다음과 같다.
전략 맞춤: 빠른 실행이 중요한가, 품질과 안정성이 중요한가?
현실 점검: 우리 규모와 역량으로 실제 운영 가능한가?
변화 대응: 6개월~1년 후 사업 변화에 유연하게 적응할 수 있는가?
운영 역량: 팀장들이 복잡한 구조를 관리할 경험과 스킬이 있는가?
지금까지 [조직구조 1,2] 글을 통해 조직구조가 단순한 박스와 선의 배열이 아니라, 전략이 흐르고 의사결정이 이루어지며 성과가 만들어지는 설계도라는 것을 확인했다.
그리고 조직도에 무엇이 담겨 있는지를 확인할 수 있어야 하고, 반대로 조직구조에 무엇을 담아야 하는지도 살펴봤다. 누가 결정하는가(계층 구조와 소속 라인), 어디서 무슨 일을 하는가(업무 배치 원칙), 일이 어떻게 흘러가는가(조직 형태 선택). 이 세 가지가 명확히 보일 때, 조직도는 비로소 작동하는 구조가 된다.
이제 우리 조직도를 다시 펼쳐보자.
조직도를 보면서 다음을 확인할 수 있는지를 체크해 보도록 한다.
전략 정렬: 우리 전략을 가장 잘 실행할 수 있는 구조인가?
명확성: 의사결정 권한과 책임이 명확한가?
협업: 부서 간 협업이 원활하게 흐를 수 있는가?
유연성: 변화에 빠르게 적응할 수 있는가?
균형: 권한이 적절히 분산되어 있는가?
하지만 조직도를 아무리 정교하게 그려도, 뼈대만으로는 조직이 살아 움직이지 않는다.
실제로 조직이 작동하려면 이 구조 안에서 누가 무엇을 결정하고 책임지는가가 명확해야 한다.
각 직책에 어떤 역할을 부여하고, 어디까지 권한을 주며, 무엇을 책임지게 할 것인가.
부서 간 회색지대는 어떻게 해결하고, 협업이 필요한 지점에서는 누가 최종 결정을 내릴 것인가.
즉, 설계된 구조에 권한과 책임이라는 신경망을 연결해야 조직이 비로소 살아 움직이기 시작한다.
다음 글인 '역할과 책임(R&R)'에서는 바로 이 부분을 다루게 된다.
조직도는 그렸는데 실제로는 작동하지 않는 이유, 부서 간 회색지대가 생기는 이유를 살펴보고, 각 조직 형태에서 발생하는 구체적 문제들을 어떻게 해결할 것인가를 구체적으로 다룬다.
구조를 넘어, 실제로 조직을 움직이게 만드는 실행 원리와 운영의 속을 들여다보도록 하자.
위 글의 참고 및 참조자료
Alfred D. Chandler Jr., Strategy and Structure: Chapters in the History of the American Enterprise (1962)
Jay R. Galbraith, Designing Organizations: An Executive Guide to Strategy, Structure, and Process (2002)
Henry Mintzberg, Structure in Fives: Designing Effective Organizations (1983)
Henrik Kniberg & Anders Ivarsson, "Scaling Agile @ Spotify" (2012), Spotify Engineering Culture Videos (2014)
Davis, Ralph C., Fundamentals of Top Management (1951)
ING Bank Agile Transformation case studies (McKinsey Quarterly, 2017; London Business School, 2016)
Nike Inc., Corporate Responsibility Reports (협력 공장 관리 시스템 강화 관련)