스쿼드 만들었다고 목적조직이 아니다

지난 몇 년간 한국에서도 많은 기업들이 '목적조직', '스쿼드', '애자일' 전환을 시도했습니다. 쿠팡, 토스, 카카오 등 성공 사례가 회자되면서 "우리도 해야 한다"는 분위기가 퍼졌죠. 그런데 막상 도입한 조직들의 이야기를 들어보면, "뭔가 바뀐 것 같은데 본질은 그대로"라는 반응이 많습니다.

McKinsey가 2025년 8월에 발표한 이 리포트는 정확히 이 문제를 다룹니다. 왜 조직 전환이 실패하는지, 어디서 막히는지, 6가지 함정을 구체적 사례와 함께 분석했습니다.

15초 요약

"스쿼드 도입했어요", "트라이브로 바꿨어요", "애자일 전환 3년차예요" — 그런데 왜 달라진 게 없을까요?

McKinsey가 수십 개 기업을 분석한 결과, 조직 전환의 76%가 실패하거나 기대에 못 미칩니다.

실패하는 조직의 공통점

구조만 바꿈 — 스쿼드 이름만 붙이고 일하는 방식은 그대로
프로세스는 그대로 — 예산은 프로젝트 단위, 승진은 기능조직 기준
리더십 커밋먼트 없음 — CEO는 빠지고 "애자일 담당자"만 열심히

핵심 메시지

"말의 앞다리를 바퀴로 바꾼다고 경주용 차가 되지 않는다." 부분 전환, 형식적 전환은 혼란만 가중시킵니다.

알아두면 좋은 용어

**기능조직 **(Functional Organization) 같은 직무끼리 모인 조직. 개발팀, 디자인팀, 마케팅팀처럼 기능별로 나뉨. 전문성 축적에 유리하지만, 제품 단위 의사결정이 느림.

**목적조직 **(Cross-functional Team) 하나의 목표를 위해 다양한 직군이 모인 조직. PM, 개발자, 디자이너가 한 팀으로 움직임. 빠른 의사결정이 가능하지만, 기능별 전문성 관리가 과제.

스쿼드/트라이브/챕터 Spotify가 대중화한 조직 모델. 스쿼드(8~10명의 목적조직)가 기본 단위, 여러 스쿼드가 모여 트라이브, 같은 직군끼리는 챕터로 연결.

Y's Insight

먼저 짚고 갈 게 있습니다.

목적조직과 기능조직은 조직의 환경일 뿐, 뭐가 더 좋고 나쁘고가 없습니다.

각자의 조직 상황과 목표에 따라 일하는 방식을 가져가면 됩니다. 목적조직의 빠른 의사결정, 기능조직의 전문성 축적 — 양쪽의 장점을 필요에 따라 차용하면 되는 거지, "우리는 목적조직이야" "우리는 기능조직이야"를 따지는 것 자체가 사치일 수 있습니다.

그럼에도 불구하고, 최근 기능조직에서 목적조직으로 전환을 시도하는 회사가 늘고 있습니다.

왜 지금일까요?

AI 시대의 조직 전환 필요성

개발 속도가 빨라졌습니다. AI 코딩 도구로 프로토타입이 며칠 만에 나옵니다. 기획서 쓰고, 검토받고, 개발 일정 잡고... 하는 사이에 경쟁사는 출시합니다.
작은 팀으로 큰 성과가 가능해졌습니다. AI가 개인의 생산성을 높여주면서, 10명이 하던 일을 3명이 할 수 있게 됐습니다. 대규모 기능조직의 효율성 이점이 줄어들고 있습니다.
전문성의 경계가 흐려지고 있습니다. PM이 간단한 코드를 짜고, 개발자가 데이터 분석을 하고, 디자이너가 프롬프트를 씁니다. 기능별로 칸막이 치는 게 오히려 비효율이 됩니다.
시장 피드백 루프가 빨라져야 합니다. 고객 반응을 보고 바로 수정하는 팀이 이깁니다. 기획→개발→QA→배포 순차 진행으로는 따라갈 수 없습니다.

그래서 빠른 의사결정, 작은 팀, 크로스펑셔널 협업이 가능한 목적조직으로 전환하려는 시도가 늘고 있습니다.

문제는, 전환을 '결정'하는 건 쉬운데 '실행'하는 건 어렵다는 겁니다.

McKinsey 리포트에 따르면 조직 전환의 76%가 실패하거나 기대에 못 미칩니다. 스쿼드라는 이름만 붙이고 일하는 방식은 그대로인 경우가 대부분입니다.

전환을 결정했다면, 그 책임감의 무게를 느껴야 합니다. 리더십이 먼저 모범을 보이고, 그 다음 매니저, 그 다음 실무자 순으로 변화가 내려가야 합니다. 위에서 안 바뀌는데 아래만 바꾸라고 하면, 혼란만 가중됩니다.

이번 글에서는

McKinsey가 정리한 조직 전환 실패의 6가지 함정을 살펴보고,
한국에서는 어떤 모습으로 나타나는지,
각 레벨에서 무엇을 했을 때 조직 전환 성공률을 높일 수 있는지

6가지 함정별로 정리했습니다.

함정 1: 목표가 전환과 연결되지 않음

맥킨지가 말하는 것

"더 많은 권한 위임", "고객 중심 문화", "애자일하게 일하기" — 이런 추상적 목표는 멋지지만, 정량화되지 않으면 의미가 없습니다.

유럽 통신사 CFO 왈, "크로스펑셔널 팀, 분기별 계획 프로세스까지 다 도입했는데, 성과에 변화가 없어요."

문제는 트라이브에 구체적인 예산 제약이나 성과 목표가 없었다는 것. 각 팀이 알아서 목표를 정하다 보니, 전사 전략과 연결되지 않았습니다.

한국에서 제가 본 것

컨설팅하면서 "왜 스쿼드로 전환하셨어요?"라고 물으면, 대답이 크게 세 가지입니다.

"토스/쿠팡이 그렇게 한다길래요" → 벤치마킹은 좋은데, 우리 조직의 문제가 뭔지부터 정의해야 합니다.
"속도가 느려서요" → 속도가 뭔가요? 기획→개발 핸드오프? 배포 주기? QA 병목? 원인이 다르면 해법도 다릅니다.
"대표님이 하라고 하셔서요" → 솔직한 대답인데, 이러면 담당자만 고생하고 성과는 안 나옵니다.

목표 없는 전환은 표류합니다. "애자일하게"가 아니라 "출시 주기를 월 1회에서 주 1회로", "고객 중심"이 아니라 "NPS 40에서 55로" 같은 정량 목표가 먼저입니다.

레벨별 필요 액션

리더십 (본부장, C레벨)

전환 목표를 전사 전략과 연결해서 정량화하세요
"3개월 후 이 숫자가 이렇게 바뀌어야 한다"를 선언
목표 달성 여부를 분기별로 리뷰하고, 전환 효과를 측정

매니저 (스쿼드 리드, 팀 리드)

추상적 목표를 정량 지표로 번역하는 게 당신 역할
"고객 중심"을 받으면 → "DAU 10% 증가" 또는 "CS 인입 20% 감소"로 구체화
위에서 정량 목표를 안 주면, 먼저 제안하고 합의받으세요

**실무자 **(PM, 개발자, 디자이너)

스쿼드 목표가 뭔지 명확히 물어보세요. "우리 스쿼드의 성공 지표가 뭔가요?"
목표가 불명확하면 매니저에게 escalate. "이거 정해지지 않으면 우선순위를 못 정해요"
본인이 속한 스쿼드의 KPI를 직접 제안해보는 것도 방법

함정 2: 새 조직이 기존 구조의 번역판

맥킨지가 말하는 것

유럽 은행 사례 "표면적으로는 End-to-End 책임 조직이었지만, 실제로는 전략팀 → PM팀 → 아키텍처팀 → 개발팀으로 기존 구조 그대로였다."

스쿼드라는 이름만 붙이고, 일하는 방식은 기능조직 그대로인 경우입니다.

한국에서 제가 본 것

가장 흔한 패턴

기획팀이 "프로덕트 오너"로 이름 바꿈
개발팀이 "스쿼드 개발파트"로 이름 바꿈
그런데 기획서는 여전히 기획팀에서 개발팀으로 "전달"됨
스프린트 회의는 하는데, 조그마한 의사결정이라도 "위에 확인하고요"

1000명 넘게 PM 면접 보면서 조직 구조 관련 질문을 많이 했습니다.

"전 회사에서 스쿼드로 일하셨다고 했는데, 의사결정은 어떻게 했나요?"

패턴 A: "스쿼드 리드랑 논의해서 바로 결정했어요" → 진짜 목적조직에서 일한 분
패턴 B: "스쿼드에서 논의하고, 본부장님께 공유드리고, 승인받으면 진행했어요" → 이름만 스쿼드인 기능조직에서 일한 분

B 패턴이 체감상 8:2로 많습니다. 이분들이 잘못한 게 아니에요. 조직이 "스쿼드"라고 부르면서 실제로는 기능조직으로 운영한 겁니다.

레벨별 필요 액션

리더십

스쿼드 리드에게 진짜 의사결정 권한을 주세요
"공유 후 승인" 프로세스를 "사후 보고"로 바꾸는 것만으로도 큰 차이
권한을 줬다가 번복하면 안 준 것보다 못함. 일관성이 핵심

매니저

스쿼드 내에서 결정할 수 있는 범위를 명확히 정의하세요
"이건 스쿼드에서 결정", "이건 위에 escalate" 기준을 문서화
위에서 자꾸 번복하면, 그 패턴을 기록해서 리더십에 공유

실무자

"이 결정, 스쿼드 안에서 할 수 있나요?"를 매번 체크
의사결정이 계속 밖으로 나간다면, 그건 스쿼드가 아님을 인지
면접 준비할 때: "내가 직접 결정한 것"과 "위에서 결정된 것"을 구분해서 정리

함정 3: 기술 변화 없이 조직만 변경

맥킨지가 말하는 것

라틴아메리카 은행 사례 "엔지니어들을 비즈니스 담당자 옆에 앉게 해서 크로스펑셔널 팀을 만들었다. 초반에는 성공적이었지만, 코드 테스트와 릴리스 프로세스가 중앙 집중식이라 배포에 지연이 생겼다."

조직은 바꿨는데 기술 인프라는 그대로면, 조직 전환의 이점을 누릴 수 없습니다.

한국에서 제가 본 것

스타트업에서 흔한 케이스

스쿼드별로 빠르게 개발하는데, 배포는 2주에 한 번 "릴리스 데이"에 몰아서 함.
스쿼드 A가 기능 완성해도 스쿼드 B 때문에 대기
릴리스 데이에 버그 터지면 전체 롤백
"스쿼드가 빨라도 소용없네"

대기업에서 흔한 케이스

목적조직으로 바꿨는데, 모든 데이터는 여전히 DW팀에서 관리.
스쿼드에서 데이터 분석하려면 DW팀에 요청
2주 대기
"데이터 기반 의사결정" 불가능

레벨별 필요 액션

리더십

조직 전환과 기술 전환을 같이 로드맵에 넣으세요
"먼저 레거시 정리하고 조직 바꾸자"는 함정. 둘 다 같이 가야 합니다
플랫폼팀에 투자하세요. 스쿼드 자율성은 플랫폼이 뒷받침해야 가능

매니저

스쿼드의 기술적 자율성을 체크하세요. 독립 배포 가능한가? 데이터 접근 가능한가?
병목 포인트를 정량화해서 리더십에 보고. "이 때문에 평균 X일 지연"
플랫폼팀/인프라팀과의 협업 구조를 만드세요

실무자

기술적 병목이 어딘지 기록하세요. "이거 때문에 2주 기다림" 같은 리스트
스쿼드 회고에서 기술 인프라 이슈를 계속 제기
가능하다면 작은 범위에서 독립 배포 실험 제안

함정 4: 예산/인사 프로세스가 정렬되지 않음

맥킨지가 말하는 것

한 대형 통신사는 QBR(분기별 비즈니스 리뷰)을 도입했지만, 애자일 코치들이 운영하고 시니어 비즈니스 리더들은 참여하지 않았습니다. 결과적으로 위에서 내려오는 우선순위 가이드가 없고, 예산과 의사결정이 연결되지 않았습니다.

라틴아메리카 은행에서는 스쿼드를 만들었지만, 예산은 여전히 프로젝트 단위로 스티어링 커미티에서 승인받는 구조였습니다.

한국에서 제가 본 것

"스쿼드인데 예산 권한이 없어요"

멘토링하면서 상당히 많이 듣는 고민 중 하나입니다.

스쿼드 리드한테 "자율성"을 줬다고 하면서, 정작:

예산 승인은 본부장 결재
인력 충원은 HR과 기능조직장이 결정
외부 툴 도입도 결재 라인 타야 함

이러면 스쿼드 리드는 권한 없는 책임자가 됩니다. 책임은 지는데 권한은 없는, 가장 피곤한 자리예요.

"OKR 쓰는데 평가는 KPI로 해요"

스쿼드 단위로 OKR 세팅하는데, 개인 평가는 기능조직 KPI 기준.

스쿼드 목표 달성해도 본인 평가에 반영 안 됨
"스쿼드 일보다 내 KPI 챙겨야지"

스쿼드는 형식만 남음

레벨별 필요 액션

리더십

예산 단위를 프로젝트에서 프로덕트/스쿼드로 바꾸세요
평가 체계를 스쿼드 성과 중심으로 재설계
분기별로 리소스 재배치하는 메커니즘을 만드세요. 고정 예산 내에서 우선순위에 따라 이동

매니저

스쿼드 예산을 받아내세요. 작은 범위라도 "이 예산은 스쿼드 리드가 결정"
팀원 평가에 스쿼드 성과를 반영하는 기준을 만드세요
분기별 리소스 재배치 권한을 요청하세요 (5~10%라도)

실무자

스쿼드 성과가 본인 평가에 어떻게 반영되는지 명확히 확인하세요
연결이 안 되면 매니저/HR에 문제 제기
스쿼드 성과 기여를 본인이 직접 기록해두세요 (평가 시즌 대비)

함정 5: 문화와 리더십이 그대로

맥킨지가 말하는 것

글로벌 항공사 전환 책임자 왈, "우리는 '임파워먼트', '심리적 안전' 같은 멋진 말을 연설에서 씁니다. 하지만 실제로 누가 승진하는지, 어떻게 승진하는지 보면, 메시지가 완전히 달라요."

포스터에 적힌 가치와 실제 인사 결정이 다르면, 직원들은 포스터가 아니라 인사 결정을 따릅니다.

한국에서 제가 본 것

수평적 문화인데 회의에서 막내는 발언 안 함
호칭은 "OO님"인데 결국 연차순으로 발언
슬랙에서는 이모지 달고 놀지만, 진짜 결정은 임원 회의에서
실패해도 된다고 하면서, 실패한 프로젝트 담당자는 다음 인사에서 불이익
새 조직 리더에 기존 사일로 리더를 앉힘

스쿼드 체계로 바꾸면서, 스쿼드 리드를 기존 기능조직에서 "고과 잘 받은 사람"으로 뽑음. 그 사람의 일하는 방식은 기능조직 스타일 그대로. 결국 스쿼드인데 기능조직처럼 운영됩니다.

레벨별 액션

리더십

승진/보상 기준을 새로운 일하는 방식에 맞게 재설계
새 조직의 리더를 뽑을 때, "기존 방식의 고성과자"가 아니라 "새로운 방식에 맞는 사람" 기준으로
리더십 본인들이 먼저 변화해야 합니다. 말로만 하면 아무도 안 믿음

매니저

팀 내에서 새로운 일하는 방식을 보상하세요 (칭찬, 기회 부여)
승진/평가 기준에 "협업", "실험", "학습"을 명시적으로 포함
본인부터 새로운 방식으로 일하는 모습을 보여주세요

실무자

실제로 누가 승진하는지, 왜 승진하는지 관찰하세요. 그게 진짜 문화입니다
본인의 일하는 방식이 평가에 어떻게 반영되는지 매니저와 대화
문화가 안 맞으면, 맞는 조직으로 이동하는 것도 선택지

함정 6: 탑다운 리더십 부재

맥킨지가 말하는 것

한 대형 통신사에서 "애자일 및 운영 모델 전환 총괄"을 맡은 사람이, 비즈니스 리더들이 전환 내용을 처음 듣는 것처럼 반응하는 게 이상하다고 했습니다. 전환이 3년째 진행 중인데도요.

CEO 커밋먼트 없이 "애자일 담당자"에게 위임하면, 전환은 사이드 프로젝트가 됩니다.

한국에서 제가 본 것

"김 부장, 네가 맡아봐"

CEO나 C레벨이 직접 드라이브하지 않고, 중간 관리자에게 "전환 담당"을 맡깁니다. 그 결과,

담당자는 열심히 하지만 권한이 없음
다른 임원들은 "그건 김 부장 담당이잖아"로 방관
현업 부서는 "또 새로운 거 시키네" 피로감
2년 후 담당자 지쳐서 퇴사, 전환은 흐지부지

"위에서 다시 보겠다"

스쿼드에 자율성을 줬다고 하면서, 실제로는

스쿼드에서 결정 → 팀장 보고 → 본부장 보고 → "검토 후 말씀드릴게요"
2주 후 "방향을 좀 바꿔보면 어떨까요?"

스쿼드 구성원들: "어차피 뒤집어질 건데 뭐하러 열심히 해"

자율성을 줬다가 뺏으면, 안 준 것보다 못합니다.

레벨별 필요 액션

리더십

전환을 "담당자"에게 위임하지 마세요. 본인이 직접 드라이브
주 4시간은 써야 합니다. 그럴 가치가 없다면 전환을 안 하는 게 나음
다른 임원들도 참여시키세요. CEO 혼자 해도 안 되고, 탑팀 전체가 움직여야 함

매니저

리더십의 커밋먼트 레벨을 솔직하게 파악하세요
커밋먼트가 약하면, 작은 범위에서 성공 사례 만들어서 위를 설득
"전환 담당자"가 되면, 권한 범위를 먼저 명확히 하세요. 권한 없이 책임만 지면 번아웃

실무자

리더십 커밋먼트가 없으면 전환은 어렵다는 걸 인지하세요
본인이 바꿀 수 있는 범위에서 새로운 방식 실험 (작은 성공 사례 만들기)
조직 전체 전환이 안 되면, 팀 레벨에서라도 변화 시도

근데 말이죠

목적조직이 답은 아닙니다.

도입부에서 말씀드린 것처럼, 목적조직과 기능조직은 좋고 나쁨의 문제가 아닙니다.

실제로 기능조직이 더 잘 맞는 상황도 많습니다:

기능별 전문성이 핵심 경쟁력인 경우 (예: 연구소, 법무팀)
제품보다 프로젝트 단위 업무가 많은 경우
조직 규모가 커서 전문성 관리와 표준화가 더 중요한 경우

패턴을 보면, 조직 규모가 커질수록 기능조직의 비중이 높아집니다. 전문성 관리, 채용, 평가, 커리어 패스를 기능 단위로 운영하는 게 효율적이거든요. 반대로 작은 규모의 스타트업은 대부분 목적조직에 가깝습니다. 10명이 다 같이 모여서 하나의 제품을 만드니까, 굳이 기능별로 나눌 이유가 없죠.

그리고 실제로 많은 조직들이 둘 중 하나를 고르는 게 아니라, 각자의 방식대로 조합하면서 계속 개선하고 있습니다. 기능조직 안에 프로젝트 TF를 만들기도 하고, 목적조직이면서 챕터로 전문성을 관리하기도 합니다.

그러나 본질은 동일합니다.

스쿼드든 기능조직이든, 결국 핵심은:

고객 문제에 집중하는가
빠르게 실험하고 학습하는가
의사결정이 명확하고 빠른가

이게 되면 어떤 구조에서도 성과가 나고, 이게 안 되면 어떤 구조도 소용없습니다.

가장 주의해야 할 건, 조직 구조를 핑계로 삼는 겁니다.

목적조직 핑계

"우리는 스쿼드니까 위에 승인 안 받아요. 왜 받아야 해요?"

스쿼드 리드가 예산 수억 원짜리 의사결정을 독단으로 하고, 나중에 문제 터지면 "자율성 줬잖아요"라고 합니다. 목적조직이라고 해서 모든 의사결정을 스쿼드 안에서 해야 하는 건 아닙니다. 영향 범위와 리스크에 따라 escalation 기준이 있어야 합니다. 자율성과 무책임은 다릅니다.

"빠르게 가야 하니까 문서화는 안 해요."

스쿼드가 해체되거나 사람이 바뀌면 히스토리가 전부 날아갑니다. 왜 이 결정을 했는지, 어떤 시도가 실패했는지 아무도 모릅니다. 다음 스쿼드가 똑같은 실수를 반복합니다. 빠르게 가는 것과 기록을 안 남기는 건 다른 문제입니다.

기능조직 핑계

"우리는 기능조직이라 어쩔 수 없어요. 개발팀이 일정 안 주면 저희도 못 해요."

PM이 개발팀 일정만 기다리면서 3개월을 보냅니다. 그 사이에 직접 할 수 있는 건 많습니다. 고객 인터뷰, 데이터 분석, 경쟁사 리서치, 프로토타입. 기능조직이라서 협업이 안 되는 게 아니라, 협업을 안 하는 핑계로 기능조직을 쓰는 겁니다.

"개발팀이니까 기획은 기획팀이 해야죠. 저희는 받은 대로 만들어요."

요구사항대로 만들었는데 고객이 안 씁니다. "기획이 잘못됐네요"로 끝납니다. 그런데 만드는 과정에서 "이거 고객이 진짜 쓸까요?" 한 번이라도 물어봤다면? 기능조직이라도 고객 문제에 대한 오너십은 가질 수 있습니다.

결국 조직 구조가 아니라 일하는 방식의 문제입니다.

"우리도 스쿼드 해야 해"가 아니라 "우리가 풀어야 할 문제가 뭐고, 그걸 위해 어떻게 일해야 하지?"를 먼저 물어보세요. 목적조직의 장점이 필요하면 차용하고, 기능조직의 장점이 필요하면 차용하면 됩니다. 중요한 건 구조의 이름이 아니라, 그 안에서 실제로 어떻게 일하느냐입니다.