"비행기는 오지 않았다. 활주로를 흉내 냈을 뿐이니까."

1. 어느 날, 우리는 Squad라는 단어를 의심하기 시작했다

사실 이 의심은 갑자기 시작된 것이 아닙니다. 5년 전, 그 당시 한 리테일 대기업 DT(Digital Transformation)본부에 몸담고 있을 때 이미 한 번 겪었던 장면이 다시 눈앞에 펼쳐지려 하고 있었기 때문입니다.

2021년, 그곳에서는 야심차게 Chapter와 Squad 조직을 도입하고 영어 호칭까지 함께 쓰기로 했습니다. 슬라이드 위의 그림은 더없이 깔끔했고, 컨설팅 보고서는 아름다웠습니다. 그러나 매트릭스 조직의 이중 보고/이중관리 구조를 처음 본 순간 저는 솔직히 의심이 들었습니다 — "이게 정말 우리한테 맞는 옷일까?" 그리고 시간이 흐르면서 그 의심은 현실이 되었습니다. Chapter Lead와 Squad Lead 사이에서 결론이 나지 않는 사안들, 누구의 우선순위를 따라야 할지 모르는 실무자들, 결국 위로 올라가 처리되는 의사결정들. 라벨은 바뀌었지만 일하는 방식은 더 복잡해졌고, 그 무게는 결국 사람에게 얹혔습니다.

그리고 시간이 흘러 지금 조직의 CTO로 일하는 자리에서 비슷한 조직 개편 안건이 다시 책상 위에 올라왔을 때 — 솔직히 말하면 두려웠습니다. 같은 영화를 두 번 볼 수는 없었으니까요.

게다가 우리 회사가 풀어야 했던 문제는 단순히 "Squad를 도입하느냐 마느냐"가 아니었습니다. 세 가지가 동시에 해결되어야 했습니다.

  1. 저연차 개발자들로 구성된 학습/실무 모임과 그 리더 명칭이 필요했고
  2. 고연차가 리드하며 안정적으로 운영되어야 할 정규 서비스 조직과 명확히 구분되어야 했으며
  3. 그러면서도 빠른 PoC(Proof of Concept)와 신규 사업 제품 개발을 담당하는 조직을 별도로 두어야 했습니다.

이 세 가지를 하나의 매트릭스 안에 욱여넣는 순간, 5년 전의 그 풍경이 그대로 재현될 것이 분명했습니다. 그래서 질문을 거꾸로 던졌습니다 — "실패하기로 소문난 Spotify 모델을 우리는 정말 채용해야 하는가?" 성공 사례와 실패 사례를 뒤지기 시작했고, 그러던 중 충격적인 사실 하나를 발견했습니다. Spotify 자신도 이 모델을 쓰지 않았다는 것이었습니다.

과거의 실패 경험은 새로운 길을 찾아야 한다는 가장 강한 동인이 되었습니다.

2.(카고 컬트: 화물 숭배) — 활주로만 흉내 낸 사람들

Cargo Cult: Spotify 조직 구성 방법론의 실패, 의심.

이 이야기를 이해하려면 잠시 1942년의 남태평양으로 가야 합니다.

태평양 전쟁이 터지면서 미군은 일본군과 맞서기 위해 멜라네시아의 외딴 섬들 (바누아투, 솔로몬 제도 등) 에 기지를 짓고 활주로를 깔았습니다. 하늘에서 화물기가 끊임없이 내려왔습니다. 그 안에는 통조림, 의약품, 라디오, 냉장고, 사탕, 트럭이 들어 있었습니다. 섬의 원주민들은 그때까지 한 번도 본 적 없는 물자들이었죠. 그 풍요는 압도적이었고, 미군은 그 물자를 원주민들과도 나눴습니다 [Fact link].

그러다 전쟁이 끝났습니다. 미군은 떠났고, 화물기도 끊겼습니다. 풍요가 사라진 자리에 남은 것은 텅 빈 활주로와 버려진 군용품뿐이었습니다.

원주민들이 내린 결론은 이것이었습니다 — "우리가 본 그 의식들을 다시 행하면, 화물기는 다시 돌아올 것이다." 그래서 그들은 야자수로 관제탑을 흉내 내고, 대나무로 헤드폰을 만들어 쓰고, 야간에는 활주로를 따라 횃불을 피웠습니다. 사람들은 줄을 맞춰 행진했고, 가슴팍에는 "USA"를 그렸습니다. 어떤 섬에서는 지금도 매년 2월 15일에 그 의식이 이어지고 있습니다 [Fact link].

그러나 비행기는 끝내 오지 않았습니다. 그들은 외형을 완벽하게 모방했지만, 비행기를 오게 한 진짜 원리 (공기역학, 연료, 항법, 그리고 그 뒤의 거대한 산업 시스템) 은 모방할 수 없었던 것입니다.

소프트웨어 업계는 이 인류학적 사례에서 이름을 빌려와 다음과 같이 씁니다 — "외형(이름/구조)만 따라하고 본질(문화/작동 원리)은 가져오지 못해 효과가 나지 않는 모방." 그리고 이게 바로 Spotify 모델이 전 세계에서 겪고 있는 일이었습니다.

3. Spotify 자신도 Spotify 모델을 쓰지 않는다

가장 충격적인 증언은 Spotify 전직 엔지니어 Jeremiah Lee로부터 나왔습니다. 그가 2020년에 공개한 분석에 따르면, 회사가 18개월 동안 3배로 성장하는 사이 Squad 모델은 '열망'에 그쳤고 실제로는 작동하지 않았다고 합니다 [Fact link].

핵심 실패 원인은 이중 보고(Chapter Lead + Squad Lead) 매트릭스 구조였습니다. 두 상사 사이의 충돌이 빈번했고, 결론을 내리지 못한 사안들은 결국 엔지니어링 디렉터까지 에스컬레이션되어 의사결정 비용이 폭증했습니다. 5년 전 제가 DT본부에서 본 풍경과 정확히 똑같았습니다.

심지어 Spotify 모델의 원저자인 Henrik Kniberg 본인조차 "이건 모델이 아니라 우리 한 시점의 스냅샷이었다"라고 인정했습니다 [Fact link]. 즉, 우리가 따라 베끼고 있던 그 모델은 만든 사람조차 모델이라고 인정하지 않는 어떤 것이었던 셈입니다.

RealKM의 정리는 더 직설적입니다 ("대부분의 도입 시도는 Cargo Cult) 기존 팀 라벨만 Squad/Chapter로 바꾸는 것" [Fact link].

4. 그래서 우리는 다른 길을 가기로 했다

Spotify 모델의 라벨을 그대로 쓰는 순간, 우리도 같은 함정에 빠진다는 것이 분명해졌습니다. 그렇다면 무엇으로 대체할 것인가?

우리가 참고한 것은 라이프사이클 기반 분리 사상을 검증해 온 4개의 글로벌 모델이었습니다.

모델 핵심 개념 우리가 차용한 요소
(워들리 PST: Pioneer/Settler/Town Planner — 개척자/정착자/도시계획자) 라이프사이클 3단계 라이프사이클 기반 분리 사상 [Fact link]
McKinsey Three Horizons H1 운영 / H2 성장 / H3 변혁 성숙/운영 vs 성장/탐색 2분 압축
(바이모달 아이티: 양식적 IT, 안정/민첩 두 모드로 분리) Mode 1 안정 / Mode 2 민첩 2단계 단순 분리 구조 차용 [Fact link]
Alphabet Core / Other Bets Google 본업 + X 베팅 본업과 탐색의 명확한 분리

핵심은 매트릭스를 버리고 단일 보고 구조를 채택한다는 것이었습니다. 한 사람은 한 단위에만 소속됩니다. 두 상사 사이에서 줄타기하는 일은 없습니다.

5. 이름이 단어 자체로 행위를 강제해야 한다

이름을 정하면서 우리는 한 가지 원칙을 세웠습니다 — 단어 자체가 그 단위가 무엇을 해야 하는지를 강제해야 한다는 것. Squad나 Chapter처럼 의미가 비어 있어 무엇이든 담을 수 있는 단어는 결국 Cargo Cult로 귀결되니까요.

그래서 도착한 답이 Spire와 Frontier입니다.

Spire & Frontier: Frontier는 도메인을 성장시키거나 새 시장을 탐색하는 조직, Spire는 정규 서비스를 안정적으로 운영/확장하는 굵직한 조직

Spire (스파이어)

"첨탑, 솟아오른 구조물" —(Merriam-Webster: 첨탑/상승하는 구조)

우리 회사에서 Spire는 정규 서비스를 안정적으로 운영/확장하는 굵직한 조직을 의미합니다. 일정 규모(인력 5명 이상 + ARR 임계치)와 미션 정착도를 충족한 단위에만 부여됩니다. 단어 자체가 "솟아 있다"는 정태적 안정감을 강제합니다. 앞서 말씀드린 우리 회사의 두 번째 요구 ("고연차가 리드하며 안정적으로 운영되어야 할 정규 서비스 조직") 이 자리하는 곳입니다.

Frontier (프론티어)

"미개척지, 학문/기술의 최전선" —(Cambridge Dictionary: 미개척 영역, 학문/기술의 최전선)

Frontier는 도메인을 성장시키거나 새 시장을 탐색하는 조직입니다. Spire 승격을 목표로 도메인을 키워나가는 단위죠. 이 단어를 쓰는 순간 "여기는 아직 정착되지 않은 곳"이라는 긴장감이 함께 따라옵니다. 우리의 세 번째 요구 ("빠른 PoC와 신규 사업 제품 개발") 이 살아 숨 쉬는 곳입니다.

영문 어휘 역시 자연스럽습니다. 미국 IT 업계에서 "Frontier team"은 통용 표현이고, Stripe의 컨퍼런스명에서도 보이는 대로 신영역 탐색을 가리키는 어휘로 정착해 있습니다.

그리고 첫 번째 요구 (저연차 개발자 학습 모임) 은 별도의 길드(Guild) 형태로 Spire/Frontier와 직교(orthogonal)하게 두기로 했습니다. 보고 라인이 아니라 학습/교류 라인이기 때문에 매트릭스의 함정에 빠지지 않습니다. 이 부분은 별도의 글에서 다루겠습니다.

6. Spotify가 실패한 자리, 우리가 막아낸 자리

설계가 끝난 뒤 다시 처음으로 돌아가, Spotify의 실패 원인 하나하나에 우리 모델이 어떻게 대응하는지를 점검했습니다.

측면 Spotify 모델의 실패 패턴 Thingspire Spire/Frontier 모델
보고 구조 이중 보고 (Chapter + Squad) 단일 보고 (Spire OR Frontier 1 단위)
분리 기준 수직(미션) × 수평(직능) 매트릭스 단일 축 = 라이프사이클(성숙/성장)
명칭 의미 Squad/Chapter (의미 미해석) Spire/Frontier (단어 자체가 행위 강제)
자기조직화 강요 → 실제로는 작동 안 함 명시적 우선순위 매주 갱신으로 거부
승격 경로 없음 Frontier → Spire 승격 기준 명문화
문화 라벨 도입에 의존 "문화 우선" 행동 룰로 명시

표 안의 두 줄에 대해 추가 설명이 필요합니다.

"자기조직화"란 무엇이며 왜 강요되면 실패하는가

(셀프 오거나이제이션: 자기조직화)는 Spotify 모델의 핵심 가정 중 하나로, "팀이 외부의 지시 없이 스스로 우선순위/역할/작업 방식을 결정한다"는 사상입니다. Squad는 자율적인 미니 스타트업처럼 움직여야 한다는 것이죠.

이론은 매력적이지만 현실에서는 자주 무너집니다. 이유는 단순합니다 — 자기조직화는 (가) 명확한 미션, (나) 풍부한 컨텍스트, (다) 충분히 성숙한 팀원이라는 세 가지 전제 조건이 모두 충족되었을 때만 작동하는데, 대부분의 조직은 이 셋 중 하나도 갖추지 못한 채 "이제부터 너희가 알아서 해"라고 던져버리기 때문입니다. 그 결과는 의사결정의 마비, 우선순위의 표류, 그리고 결국 위로 올라가는 에스컬레이션입니다. Jeremiah Lee의 분석에서도 핵심 실패 지점으로 지적된 부분입니다 [Fact link].

우리는 자기조직화를 강요하지 않습니다. 대신 매주 명시적 우선순위 갱신(Weekly Priority Refresh)을 룰로 박아두었습니다. Spire/Frontier Lead는 매주 월요일 "이번 주 우리 단위가 무엇을 가장 먼저 해야 하는가"를 명문화해서 공유합니다. 자율성은 그 우선순위 안에서 작동하는 것이지, 우선순위 자체를 매번 재발명하는 것이 아닙니다.

"문화 우선"의 그 문화란 구체적으로 무엇인가

표에 적은 "문화 우선"이 추상적으로 들릴 수 있어 구체적으로 풀어두겠습니다. 우리가 말하는 문화는 다음 세 가지로 구성됩니다.

  • 심리적 안전(Psychological Safety) — 실수했다고 말하는 것이 안전한 분위기. 예를 들어, 매주 회고에서 *"이번 주 내가 망친 것"*을 가장 먼저 발표하는 사람은 항상 Lead입니다. 리더가 먼저 약점을 드러내면, 팀원들도 마음 놓고 자신의 실수를 공유할 수 있게 됩니다. 이렇게 누적된 발화 기록이 곧 "이 조직에서는 실수해도 안전하다"는 신호가 됩니다.
  • 결정의 투명성(Decision Transparency) (모든 의사결정에는 *"왜 그렇게 결정했는가"*가 1~3문장으로 명문화됩니다. 예를 들어 *"기능 A를 다음 분기로 미룬다) 이유: 인프라 부채 청산이 더 시급하다고 판단, 근거는 4월 P95 latency 측정치"*처럼 적습니다. 따라가지 못한 사람도 6개월 뒤에 그 결정의 이유를 알 수 있고, 권력이 아니라 근거가 결정을 만든다는 신호가 됩니다.
  • 승격이 아닌 기여로 존중하기 (직급보다 *"이 사람이 어떤 문제를 풀어냈는가"*를 먼저 이야기합니다. 예를 들어 분기 리뷰에서 *"올해 입사한 신입이 결제 모듈의 race condition을 잡아냈다"*가 *"5년차 시니어가 정기 운영을 이끌었다"*보다 먼저 언급될 수 있습니다. 저연차의 좋은 의견이 고연차의 권위에 묻히지 않도록) 그것이 심리적 안전의 또 다른 얼굴입니다.

이 세 가지가 없으면 Spire와 Frontier는 그저 새로운 라벨일 뿐입니다.

7. 그러나 단어만으로는 충분하지 않다 ("Culture eats strategy for breakfast"

여기서 솔직하게 인정해야 할 것이 있습니다. 이름을 잘 짓는 것만으로 Cargo Cult를 피할 수는 없습니다. 그것이 바로 Spotify 모델 도입에 실패한 모든 회사들이 보여준 교훈입니다.

이 지점에서 자주 인용되는 말이 있습니다) "Culture eats strategy for breakfast." (문화는 전략을 아침식사로 먹어치운다.)

흔히 경영학자 Peter Drucker의 말로 알려져 있지만, 사실 출처는 모호합니다. Quote Investigator의 추적에 따르면, 이 표현은 2000년 3월 Giga Information Group의 한 헤드라인에 처음 등장했고, 2006년 Ford 미국 사장이었던 Mark Fields가 자신의 회의실 벽에 걸어두면서 널리 퍼졌습니다. Drucker가 직접 이 말을 했다는 기록은 어디에도 없습니다 [Fact link].

출처가 어찌 됐든 이 말의 메시지는 분명합니다 — "아무리 잘 짠 전략이라도, 그것을 받아낼 문화가 없으면 그저 죽고 만다." Mark Fields의 표현을 빌리면, *"세계 최고의 계획을 세워도 문화가 그것을 허락하지 않으면 시들어 죽는다"*는 것입니다 [Fact link].

그러면 그 "문화"는 어떻게 심리적 안전을 만들어 내는가? 이 질문에 대한 우리 답은 6장 후반부에 풀어둔 세 가지 (심리적 안전/결정의 투명성/기여 중심 존중) 가 각자 따로가 아니라 서로를 강화하는 시스템으로 작동한다는 것입니다. Lead가 먼저 실수를 공개하면(심리적 안전), 그 다음 결정에서 *"내가 틀렸기 때문에 이렇게 바꾼다"*를 명문화할 수 있고(결정의 투명성), 그러면 직급이 낮아도 권위에 눌리지 않고 의견을 낼 수 있게 됩니다(기여 중심). 한 가지가 빠지면 나머지 둘도 무너집니다.

조직 모델도 마찬가지입니다. Spire/Frontier라는 멋진 구조도, 그것을 받아낼 이 세 가지 문화가 없다면 결국 5년 전의 Chapter/Squad와 같은 운명을 맞이할 것입니다. 전략을 아침식사로 먹어치우는 그 문화가 우리 편이 되도록 만드는 것 (이것이 진짜 과제입니다.

그래서 우리는 명칭 변경과 함께 8개의 행동 룰을 동반시켰습니다. 그중 가장 중요한 두 가지만 옮기자면)

  • R1. 이름만 바꾸지 않기 (Spire/Frontier Lead는 분기마다 "지난 분기 우리가 어떻게 작동을 바꿨는지"를 시연해야 합니다.
  • R8. 문화 우선) 위에 풀어놓은 세 가지 문화 요소가 매 회고에서 점검됩니다.

이 룰들이 작동하지 않으면, Spire와 Frontier도 결국 Squad/Chapter처럼 빈 라벨이 됩니다. 우리는 그것을 알고 시작했습니다.

8. 마치며 — 비행기는 활주로가 아니라 비행 원리에서 온다

남태평양 원주민들이 활주로 모양을 정확히 그렸어도 비행기는 오지 않았습니다. 비행기를 오게 하는 것은 활주로의 모양이 아니라 공기역학과 연료와 항법이었으니까요.

조직 설계도 마찬가지입니다. Squad라는 이름이 마법을 부리지는 않습니다. 우리가 Spire와 Frontier로 이름을 바꿨다고 해서 자동으로 더 잘 일하게 되지도 않을 겁니다.

다만 우리는 이 이름들을 통해 매번 스스로에게 질문을 강제할 수는 있습니다 — 이 Spire는 정말로 "솟아 있는가"? 이 Frontier는 정말로 "미개척지를 향하고 있는가"? 단어가 우리에게 매일 묻고, 우리가 매일 답해야 하는 구조. 그게 우리가 원하던 것입니다.

5년 전 제가 한 번 본 그 영화를 두 번 보지 않기 위해, 우리는 이 길을 택했습니다. 비행기는 그 질문에 정직하게 답하는 조직에게만 옵니다.

NeuTeam / 2026년 4월