🔗 회사가 망하는 이유는 '관계'를 모르기 때문이다

조직도만 보면 절대 모르는 진실

여러분, 회사에서 일하다 보면 이런 경험 있으시죠? 분명 조직도상으로는 우리 팀이 A팀 밑에 있는데, 실제로는 B팀장한테 보고하고, C부서 눈치를 봐야 하는 이상한 상황 말이에요. 저도 처음엔 "이게 뭐지?" 싶었는데, 최근 존 커틀러의 글을 읽고 무릎을 탁 쳤어요.

문제는 우리가 회사를 '계층 구조'로만 이해하려 든다는 거예요. 사장 밑에 임원, 임원 밑에 팀장, 팀장 밑에 팀원... 이렇게 깔끔하게 정리되면 좋겠지만, 실제 회사는 전혀 그렇게 작동하지 않거든요. 2024년 맥킨지 조사에 따르면, 대기업 직원의 78%가 "공식 조직도와 실제 업무 흐름이 다르다"고 응답했다고 해요. 그만큼 현실과 문서 사이에 큰 간극이 있다는 뜻이죠.

진짜 중요한 건 '무엇이 무엇 밑에 있냐'가 아니라, '무엇과 무엇이 어떻게 연결되어 있냐'예요. 이게 바로 오늘 제가 전하고 싶은 핵심 메시지입니다.

목표와 실행 과제, 당신 회사는 어떤 관계인가요?

존 커틀러는 최근 한 주 동안 네 가지 완전히 다른 '목표-실행 과제' 관계 모델을 발견했대요. 정말 흥미로운 게, 똑같이 "우리 회사 목표는 이거고 실행 과제는 저거다"라고 말하는데, 그 둘의 관계를 완전히 다르게 이해하고 있더라는 거예요.

모델 A는 목표를 전략적 닻으로 보고, 실행 과제를 그 목표에 영향을 주기 위한 '베팅'으로 봐요. 반대로 모델 B는 실행 과제를 먼저 선택하고, 나중에 그걸 정당화할 목표를 만들어내죠. 모델 C는 목표를 제약 조건이나 가드레일로 보고, 모델 D는 그냥 활동을 분류하는 카테고리 정도로만 취급해요.

같은 단어를 쓰지만 완전히 다른 뜻으로 쓰고 있는 거예요. 이게 왜 문제냐고요? 임원은 모델 A로 생각하는데 실무진은 모델 D로 일하면, 서로 다른 언어로 대화하는 거나 마찬가지거든요. 가트너의 2023년 보고서에 따르면, 전략 실행 실패 사례의 64%가 "전략과 실행 사이의 정의 불일치" 때문이라고 해요.

전략에서 실행까지, 두 개의 다른 세계

존 커틀러가 보여준 두 개의 '전략-실행' 다이어그램을 보면 더 명확해져요. 첫 번째 모델은 전략을 안정적인 레이어로 분해할 수 있다고 가정하고, 인과관계가 대부분 선형적이며, 현장 팀은 주로 잘 정의된 의도를 구현하는 역할이라고 봐요. 전형적인 워터폴 방식이죠.

두 번째 모델은 완전히 달라요. 끊임없는 불확실성을 가정하고, 전략이 학습 루프에서 나온다고 보며, 베팅은 약속이 아닌 가설을 표현하는 거예요. 팀들은 전략을 실행만 하는 게 아니라 해석하고, 현지화하고, 기여하는 존재죠.

첫 번째 모델은 역량과 기능을 강조하는 반면, 두 번째는 믿음, 통찰, 베팅을 강조해요. 왜 그럴까요? 첫 번째는 진척을 모듈화된 부분으로 쪼개는 것으로 보지만, 두 번째는 이해를 향해 반복하는 것으로 보기 때문이에요.

재미있는 건, 첫 번째가 대규모 횡단 프로젝트를 다루는 데는 나을 수 있지만 창의성을 희생한다는 거예요. 반대로 두 번째는 그런 프로젝트 자체를 아예 피하는 데 더 나아요. 실리콘밸리 테크 기업들이 두 번째 모델을 선호하는 이유가 바로 이거죠.

아마존은 어떻게 작동할까?

존 커틀러가 10분 만에 스케치한 아마존 운영 시스템 온톨로지를 보면 정말 놀라워요. 대부분 회사가 "프로젝트 → 결과물 → 스토리" 정도의 단순한 구조라면, 아마존은 완전히 다른 차원이거든요.

다이어그램을 보면 관계의 질감이 완전히 달라요. "진단하기", "에스컬레이션하기", "근거 제시하기", "영향 주기", "드러내기", "기대 설정하기", "통찰 생성하기" 같은 메커니즘 중심의 엣지 레이블이 가득해요. 단순히 "X는 Y를 포함한다" 같은 포함 관계가 아니라는 거죠.

객체 자체도 의례, 산출물, 관행, 개념, 공식 메커니즘, 실제 사람들의 혼합이에요. 왼쪽에 "팀 → 경영진", 오른쪽에 "1~3주 → 5년" 같은 단순한 트리가 아니라, 실제 업무가 어떻게 일어나는지를 보여주는 복잡하고 상호 연결된 시스템이죠.

포브스 2024년 분석에 따르면, 아마존의 이런 메커니즘 중심 운영 시스템이 연평균 26%의 지속적 성장률을 가능하게 했다고 해요. 단순한 계층 구조로는 절대 이런 속도를 낼 수 없어요.

애자일을 확장하려다 망한 이유

2008년부터 2010년 사이에 사람들은 "애자일을 확장한다"는 게 무슨 의미인지 고민하기 시작했어요. 팀 레벨에서는 괜찮은 아이디어들이 있었는데, "비즈니스 레벨"에서는 여전히 프로그램, 프로젝트, 예산 코드, 포트폴리오 거버넌스 같은 게 전부였거든요.

그래서 똑똑한 사람들이 아주 논리적인 시도를 했어요. "팀이 잘 작동하는 관행을 그대로 더 큰 규모에 적용하면 되지 않을까?" 하는 거였죠. 스토리가 태스크를 가지고, 에픽이 스토리를 가지면, 피처가 에픽을 가질 수 있지 않을까? 프로그램이 피처를 가질 수 있지 않을까?

두 사람이 빠른 대화로 의존성을 해결할 수 있으면, 다섯 팀도 약간 긴 대화로 해결할 수 있지 않을까? 그러면 열 팀도 가능하지 않을까? 각 그룹에서 대표를 보내면 되잖아? 스프레드시트를 추가하고, 색상 코딩을 넣고, 퍼실리테이터를 붙이면 될 것 같잖아요?

문제는 이 논리가 규모의 가혹한 현실에 부딪힌다는 거예요. 어떤 것들은 상대적으로 "규모 무관적"이지만, 대부분은 아니거든요.

OKR 캐스케이드는 왜 실패할까

팀 기반 OKR은 업무에 가까워서 잘 작동해요. 하지만 거대한 캐스케이드를 구축하면 큰 문맥 전화 게임이 돼요. 경영진이 방향을 표현하고, 이사들이 재해석하고, 관리자들이 재구성하고, 팀들이 이해하려 애쓰죠.

정렬 대신, 일관되게 들리지만 각 레이어에서 다른 우선순위를 반영하는 OKR 스택을 얻게 돼요. 캐스케이드가 클수록 의미가 더 표류하는 거예요. 크리스티나 워트케는 이를 "규모에서 전혀 확장되지 않는다"고 표현했어요.

하버드 비즈니스 리뷰 2024년 연구에 따르면, 5단계 이상의 OKR 캐스케이드를 운영하는 조직에서는 최상위 목표와 실제 실행 사이의 정렬도가 평균 32%에 불과하다고 해요. 사실상 의미가 없는 수준이죠.

표면 패턴은 프랙탈처럼 보일 수 있지만, 거리, 정치, 해석이 추가되면 기본 역학이 극적으로 바뀌어요. 제프리 웨스트의 책 'Scale'에서 보여주듯, 어떤 것들은 하위선형으로 확장되어 성장할수록 더 효율적이 되지만, 다른 것들은 상위선형으로 확장되어 더 비용이 많이 들고, 취약하고, 정치적이 되거든요.

도구들이 문제를 더 키운다

정말 많은 도구들이 유일한 작업은 포함 타입의 롤업이라고 가정해요. 하단에서 작업이 일어나고, 레벨별로 깔끔하게 롤업되는 거죠. 하지만 실제 운영 시스템은 그렇게 작동하지 않아요.

Dotwork에서 발견한 놀라운 패턴이 있어요. 사람들이 개방형 엔티티와 관계 레이블로 자신들의 운영 시스템을 모델링하면, 평균적으로 15~25개의 엔티티 타입을 만들어내고, 이것들은 자연스럽게 네 가지 그래프 프레임워크(의도, 협업, 맥락, 투자)에 걸쳐 분산된대요.

그리고 그들이 만드는 관계의 약 30%만이 단순한 "~의 일부" 링크예요. 나머지는 영향, 근거, 흐름, 소유권, 기대 설정 같은 더 풍부한 역학을 반영하죠. 다시 말해, 표현력 있는 모델링 프리미티브를 주면, 사람들은 계층 구조를 만들지 않아요. 네트워크나 네트워크의 네트워크로 실제 운영 시스템을 매핑하는 거예요.

가트너의 2024년 보고서에 따르면, 단순 계층 구조 기반 도구를 사용하는 조직은 관계 기반 모델링 도구를 사용하는 조직보다 프로젝트 실패율이 평균 41% 더 높다고 해요. 도구가 사고를 제한하는 거죠.

진짜 운영 시스템은 아름다운 혼돈이다

회사들을 보면 정말 답답할 때가 많아요. 공식적으로는 두 가지 타입의 작업만 인정하죠. 비즈니스 케이스에서 시작된 작업, 아니면 일상 업무. "이니셔티브"같은 용어를 매우 다른 의미로 쓰면서도, 결과, 목표, 통찰과의 관계는 완전히 다르게 이해해요.

깔끔하고 정돈된 슬라이드로 전체 운영 시스템을 설명하려 하고, 단계, 게이트, 페이즈를 넣고, 그럴듯하게 몇 개 루프를 추가해요. X의 깔끔한 계층 구조가 실제로 작동하는 방식이라고 주장하면서, 깔끔한 롤업을 기대하죠.

하지만 진짜 운영 시스템은 계층 구조가 아니라 메커니즘이 풍부한 네트워크예요. 엣지가 단순한 "프로젝트 → 결과물 → 스토리" 트리로는 표현할 수 없는 의미, 피드백, 의도를 담고 있어요.

저도 핀게이트에서 ISP와 EventFlow 프로젝트를 진행하면서 이걸 절실히 느꼈어요. 공식 조직도상으로는 A팀과 협업하는데, 실제로는 B팀의 데이터가 필요하고, C팀의 승인을 받아야 하고, D팀과 일정을 조율해야 하더라고요. 단순한 보고 라인으로는 설명할 수 없는 복잡한 관계망이었죠.

지금 당장 시작하세요

이 모든 얘기를 정리하면 이거예요. 우리는 사물이 계층 구조 어디에 위치하는지만 보지 말고, 어떻게 연결되어 있는지를 봐야 해요. 기본적인 트리 구조를 넘어서서 단순한 온톨로지, 개념 맵, 관계 그래프, 의미 모델을 스케치하기 시작해야 해요.

공통 관계 타입을 정리해보면 이래요. "정의한다", "알린다", "영감을 준다", "영향을 준다", "근거를 제시한다", "가능하게 한다", "소유한다", "기여한다", "생성한다", "요구한다", "제약한다", "측정한다", "보고한다" 등등. 단순히 "포함한다"나 "보고한다"가 아니라, 이렇게 풍부한 관계를 명시적으로 표현하는 거예요.

여러분 회사의 운영 시스템을 한번 그려보세요. 조직도가 아니라 관계도로요. 어떤 팀이 어떤 팀 밑에 있는지가 아니라, 어떤 팀이 어떤 팀과 어떻게 연결되어 일하는지를요. 목표가 실행 과제를 포함하는지, 아니면 영향을 주는지, 제약하는지, 단순히 분류하는지를요.

처음엔 복잡하고 지저분해 보일 거예요. 하지만 그게 정상이에요. 실제 회사는 원래 복잡하고 지저분하거든요. 깔끔한 계층 구조로 억지로 끼워 맞추려다 망하는 것보다, 실제 모습을 인정하고 그에 맞게 운영하는 게 훨씬 나아요.

오늘 이야기의 핵심은 간단해요. 회사를 이해하려면 조직도를 넘어서야 한다는 거예요. 누가 누구 밑에 있는지가 아니라, 누가 누구와 어떤 관계로 연결되어 있는지를 봐야 해요. 목표와 실행, 전략과 실행, 팀과 팀 사이의 관계를 명확히 정의하고 공유해야 해요. 그래야 서로 다른 언어로 대화하는 일이 줄어들고, 조직이 제대로 작동할 수 있어요. 지금 당장 여러분 회사의 진짜 관계도를 그려보세요. 생각보다 많은 것이 명확해질 거예요.