Ch06 성장하는 조직 이끌기

한 줄 정의

팀 하나가 아니라 ‘팀들의 팀’을 이끄는 리더는 3A — 늘 결정하고(Always Be Deciding), 늘 떠나고(Always Be Leaving), 늘 확장한다(Always Be Scaling) — 에 따라, 직접 문제를 풀어내는 사람이 아니라 트레이드오프를 결정해주고, 자기 없이도 굴러가는 조직을 남기고, 커지는 책임 속에서 자기 자신을 보호하는 사람이 되어야 합니다.

쉽게 말하면

Ch05 팀 이끌기에서 개인 기여자(IC)에서 한 팀의 리더로 넘어가는 의미를 다뤘다면, 이 장은 그 다음 계단입니다. 팀 하나를 이끌게 되면 연관된 여러 팀을 함께 이끌게 되는 게 자연스러운 흐름입니다.

역할이 커져도 Ch05 팀 이끌기에서 배운 섬기는 리더십 은 그대로 유효합니다. 다만 섬길 대상이 훨씬 많아졌을 뿐입니다. 풀어야 할 문제의 범위가 넓어지고 더 고차원적이 됩니다. 기술적·엔지니어링적 세부를 접할 일은 점점 줄어들어 ‘깊게’보다는 ‘넓게’ 살펴야 하는 위치가 됩니다.

한 단계 올라설 때마다 묘한 상실감이 따라옵니다. 구체적인 내용을 잊어버리는 자신이 서글퍼지고, 그동안 자랑스러워하던 엔지니어링 전문 지식과 서서히 멀어집니다. 영향력이 훨씬 커졌음을 깨닫기 전까지는 사기가 떨어지기도 합니다. 이 달콤씁쓸한 전환을 어떻게 넘기느냐, 그게 이 장의 주제입니다.

왜 '3A'인가

늘 결정하라(Always Be Deciding), 늘 떠나라(Always Be Leaving), 늘 확장하라(Always Be Scaling). 세 격언의 영어 첫 글자가 모두 ‘A’라서 3A 리더십이라 부릅니다.

왜 중요한가?

핵심 전제는 리더가 올라갈수록 일이 능동형(주도)에서 반응형(대응)으로 바뀐다 는 점입니다. IC 시절에는 할 일 목록을 정하고 코딩·디버깅으로 항목을 하나씩 지워나가는, 잔잔하고 예측 가능한 일상이었습니다. 하지만 리더가 되면 일이 어떻게 진행될지 예측하기 어려워져 마치 소방관처럼 느껴집니다.

높은 자리로 올라갈수록 이 경향이 심해집니다. 긴 코드 블록의 finally 절이 되는 셈입니다. 이메일·채팅·회의 같은 모든 소통 경로로부터 일종의 서비스 거부(Denial-of-Service) 공격 이 들어와 시간과 집중력을 고갈시킵니다. 방치하면 주어진 시간 100%가 반응형 모드로 허비됩니다. 사람들이 던지는 공(일거리, 이슈) 전부를 하나도 떨어뜨리지 않으려 정신없이 받아내는 상태가 됩니다.

3A는 이 압력에 짓눌리지 않고 살아남는 운영 모델입니다. 완벽한 결정을 내리고, 모든 것을 스스로 처리하고, 두 배로 열심히 일하는 것은 정답이 아닙니다. 그렇게 하면 종국에는 일에 압사됩니다. 대신 결정을 빠르게 내리고, 일을 위임해 조직을 자립시키고, 자기 자신이라는 한정 자원을 방어적으로 관리 하는 기술이 필요합니다.

핵심 내용

늘 결정하라 (Always Be Deciding)

여러 팀을 관리한다는 것은 더 높은 수준에서 더 많은 것을 결정해야 한다는 뜻입니다. 특정 엔지니어링 문제를 해결하는 게 아니라 거시적인 전략을 짜는 일이고, 그 결정의 대부분은 여러 전략 사이의 트레이드오프를 정확히 찾아내는 일 입니다.

비행기 일화

새벽 6시, 모든 승객이 탑승을 마쳤는데 기장이 “누군가 탱크에 연료를 4만 리터나 더 채워놨다”고 방송합니다. 선택지는 둘 — 트럭을 불러 연료를 뽑아내거나(1시간 소요), 승객 스무 명을 내려 무게를 맞추거나. 아무도 내리려 하지 않자 화가 난 1등석 승객이 “비행기에서 내리면 40달러씩 드리죠”라며 현금 다발을 흔듭니다. 20명이 800달러를 받고 내립니다. 그런데 그 직후 비행기 컴퓨터가 고장 나 게이트로 견인됩니다. 그 승객은 다음 비행기를 찾지만 8시 비행기는 만석 — “방금 전에 승객 20분이 갑자기 나타나 남은 좌석을 다 사가셨어요. 제가 본 승객 중 가장 행복해 보이더군요.”

이 일화의 핵심은 트레이드오프는 기술 시스템뿐 아니라 사람의 행동에도 적용된다 는 것입니다. 트레이드오프가 명확할 때도 있지만, 때로는 한참 지나서야 예상치 못한 결과로 피해를 주기도 합니다. 가장 높은 수준에서 리더의 역할은 사람들을 움직여 어렵고 모호한(ambiguous) 문제 — 명확한 해법이 없거나 아예 풀 수 없는 문제 — 를 풀게 이끄는 것입니다. 코드 작성을 벌목에 비유하면, 리더는 ‘나무들 사이로 숲 전체를 보면서’ 목표한 나무까지 가는 길을 안내합니다. 이 과정은 세 단계입니다.

1단계 — 눈가리개 찾기

리더에게는 처음인 문제가 이미 수많은 사람이 몇 년씩 씨름하던 문제인 경우가 많습니다. 한 문제에 너무 오래 빠져 있으면 눈가리개(blinder) 가 시야를 가려 더는 숲을 보지 못합니다. 무언가가 눈앞을 가린다는 사실 자체를 눈치채지 못한 채, 문제(혹은 해법)에 대한 가정을 수없이 쌓아 올립니다. “우린 항상 이렇게 해왔어”라며 비판 능력을 잃고, 현상 유지를 정당화하려 합리화 논리를 만들어내기도 합니다.

바로 이 지점이 깨끗한 눈을 가진 새 리더에게 유리 합니다. 익숙하지 않다는 게 좋은 리더의 조건은 아니지만, 눈가리개를 찾아내고 질문을 던지고 새로운 전략을 모색하는 데는 종종 도움이 됩니다.

2단계 — 핵심 트레이드오프 파악하기

정의상 중요하고 모호한 문제에는 마법 같은 은총알(silver bullet) 이 없습니다. 모든 상황에서 옳은 답이란 존재하지 않으며, ‘특정 상황에서의 최선의 답’이 있을 뿐이고 그마저도 거의 언제나 몇 가지 면에서 절충해야 합니다. 리더의 일은 모든 트레이드오프를 테이블 위에 올려놓고 설명한 다음, 어떻게 균형을 맞출지 결정하도록 돕는 것 입니다.

사례 연구 — 웹 검색의 '지연시간' 트레이드오프

구글의 가장 오래된 제품인 웹 검색에서, 수천 명의 엔지니어가 몇 해 동안 결과 페이지의 ‘품질’을 높였습니다. 한때 링크 10개뿐이던 페이지에 이미지·비디오·위키백과 박스·인터랙티브 UI가 수천 가지 작은 변화로 더해졌습니다. 부작용은 지연시간(latency) 이었습니다. 서버는 정보 생성에 더 많은 CPU를 쓰고, 네트워크 전송량이 늘고, 클라이언트(주로 스마트폰)는 복잡해진 HTML을 렌더링해야 했습니다. 렌더링 시간이 10ms만 늘어도 사용자 참여에 가시적인 영향을 줍니다.

문제는 지연시간이 아주 서서히, 어느 한 팀의 잘못이 아니라 모두가 조금씩 키운 병 이라는 점이었습니다. 결국 누적된 지연시간의 악효과가 ‘품질’ 향상으로 얻은 참여 개선을 넘어서기 시작했습니다. 많은 리더가 골머리를 썼지만, 눈가리개에 가려 “2~3년에 한 번 코드 옐로(code yellow)를 선언하고 모두가 코드를 최적화하는 것”만이 유일한 길이라 여겼습니다. 효과는 한두 달뿐, 지연시간은 금세 원상복구됐습니다.

(코드 옐로 는 중대한 문제를 위한 긴급 해커톤을 뜻하는 구글 용어로, 관련 팀이 모두 하던 일을 멈추고 상황이 해제될 때까지 100% 전력투구합니다.)

한 걸음 물러서서 트레이드오프를 처음부터 다시 평가하자, ‘품질’을 추구하는 비용이 하나가 아니라 둘이라는 사실이 드러났습니다.

• 사용자가 부담하는 비용 — 품질을 높일수록 더 많은 데이터를 전송받아 지연시간이 길어집니다.
• 구글이 부담하는 비용 — 품질을 높일수록 데이터 생성 작업이 늘어 더 많은 서버 CPU 시간을 소모합니다(이를 서빙 용량, serving capacity이라 합니다).

품질과 서빙 용량의 트레이드오프를 보던 리더는 많았지만, 여기에 지연시간까지 동등한 비중 으로 넣어 계산한 사람은 없었습니다. “좋게, 빠르게, 저렴하게 중 두 개만 선택하라”는 오래된 농담 그대로의 삼각 트레이드오프입니다.

graph TD
    L["지연시간<br/>(빠르게)"]
    C["용량<br/>(저렴하게)"]
    Q["품질<br/>(좋게)"]
    L <--> C
    C <--> Q
    Q <--> L

세 특성 중 하나(혹은 둘)를 희생해 다른 하나를 개선하기는 쉽습니다. 결과에 데이터를 더 넣어 품질을 높이면 지연시간과 용량이 희생됩니다. 클러스터에 질의를 더 몰면 CPU 사용률이 올라 용량은 늘지만(=하드웨어 비용 증가), 자원 경합으로 평균 지연시간이 길어집니다. 반대로 트래픽을 줄이면 서빙 용량은 줄지만 쿼리 하나하나는 빨라집니다.

숨겨진 트레이드오프까지 모두 이해하자 새 전략이 나왔습니다. 데이터 과학자들이 지연시간이 사용자 참여에 미치는 영향을 정확히 측정 하고, ‘당장의 품질 개선이 주는 참여 증가’와 ‘그로 인한 지연시간 증가가 장기 참여에 주는 손실’을 저울질하는 지표를 만들었습니다. 그 덕분에 “품질은 높지만 지연시간이 늘어나는 작은 변경”의 채택 여부를 구체적 수치로 결정할 수 있게 됐습니다.

3단계 — 결정하고 반복하기

트레이드오프를 이해하면 이번 달의 최선의 결정을 내릴 수 있습니다. 하지만 다음 달이 되면 트레이드오프를 다시 평가하고 균형점을 새로 잡아야 합니다. 이 반복성 이 바로 ‘늘 결정하라’의 본질입니다.

분석 마비를 경계하라

‘트레이드오프의 지속적인 재조정’을 프로세스에 녹이지 않으면, 팀은 완벽한 해법을 찾으려다 분석 마비(analysis paralysis) 에 빠지기 쉽습니다. 예방법은 위험을 낮추고 긴장을 줄여주는 한마디입니다 — “이 결정대로 시도해보고 어떻게 되는지 지켜보죠. 상황을 봐서 다음 달에 취소하고 다른 결정을 내릴 수도 있습니다.” 결정을 되돌릴 수 있는 실험 으로 프레이밍하면 팀이 유연하게 사고하며 자신의 선택에서 배웁니다.

늘 떠나라 (Always Be Leaving)

곧이곧대로 들으면 말도 안 되는 조언입니다. 구글 전 엔지니어링 디렉터 바트 메디라타(Bharat Mediratta)의 말을 인용한 표현인데, 진정한 뜻은 리더는 맡은 조직이 자기 없이도 ‘스스로’ 문제를 풀 수 있게 유도해야 한다 는 것입니다. 그래야 새로운 문제나 조직을 찾아 떠날 수 있습니다. 자생력을 갖춘 팀을 남겨두고 말입니다.

이 조언의 안티패턴은 리더 스스로가 단일 장애점(single point of failure, SPOF) 이 되는 상황입니다. 구글은 이를 버스 지수(bus factor) — 팀원 몇 명이 버스에 치이면 프로젝트가 망하는지를 나타내는 지수 — 라고 부릅니다.

내가 SPOF인지 확인하는 테스트

일주일 이상 자리를 비웠던 마지막 휴가를 떠올려 보세요. 다른 리더들처럼 수시로 이메일을 확인했나요? ‘왜’ 그랬나요? 신경을 끄면 모든 게 망가질까 걱정됐다면, 여러분은 스스로를 단일 장애점으로 만든 것입니다. 그렇다면 고쳐야 합니다.

미션 — ‘자율주행’ 팀을 만들어라

‘성공적인 리더가 된다’는 것은 어려운 문제를 스스로 해결하는 조직을 만든다 는 의미입니다. 그러려면 강력한 리더들, 건실한 엔지니어링 프로세스, 긍정적이고 자기-영속적(self-perpetuating) 인 문화가 필요합니다. 팀들의 팀을 이끄는 일은 기술 마법사가 되는 것보다 ‘사람들’을 조직하는 일에 가깝습니다. 자생력 있는 조직을 만드는 데는 세 가지가 필요합니다 — 문제 공간 분할, 하위 문제 위임, 필요에 따른 반복.

문제 공간 분할하기

도전적인 문제는 보통 난해한 하위 문제 여러 개로 구성되므로, 각 팀에 하위 문제 하나씩을 배정합니다. 위험은 하위 문제는 시간이 지나면 변하는데 팀은 경직된 경계에 갇혀 그 변화를 못 알아챈다 는 점입니다. 그래서 조직 구조를 느슨하게 관리해야 합니다 — 하위 팀 규모는 유동적이고, 팀원은 다른 팀으로 옮길 수 있고, 상황이 변하면 할당된 문제도 바꿉니다. ‘너무 경직된’과 ‘너무 유연한’ 사이의 외줄타기입니다.

예 — 검색 지연시간 문제의 분할

지연시간 문제는 최소 두 개의 문제 공간으로 쪼갤 수 있었습니다 — 지연의 ‘징후’를 찾는 작업 과 지연의 ‘원인’을 막는 작업 입니다. 최적화 인력을 투입해 속도를 개선해도, 수천 명이 일상 업무로 품질·복잡도를 높이고 있어 금세 원상복구됐습니다. 그래서 지연 요소가 애초에 생기지 않게 하는 일(측정 지표, 분석 도구, 개발자 교육·문서)에도 동시에 인력을 투입했습니다. 원인 대응팀과 징후 대응팀을 함께 가동하자 비로소 지연시간을 장기적·체계적으로 통제할 수 있었습니다. 또한 이 팀들이 특정 해법·도구가 아니라 ‘문제 자체’를 책임지게 해야 함도 깨달았습니다.

하위 문제를 다른 리더에게 위임하기

위임은 모든 관리 책의 단골 주제지만, 배우기가 ‘정말 어렵습니다’. 효율성과 성취라는 본능에 정면으로 배치 되기 때문입니다(“무언가를 제대로 하고 싶다면 스스로 하라”). 하지만 자율주행 조직을 일구는 게 임무라면, 리더를 키우는 가장 효과적인 교육 메커니즘이 바로 위임입니다. 과제를 던져준 뒤 실패하고 다시 시도하도록 놔두는 것 — 실리콘 밸리의 ‘빠르게 실패하고 반복하라’는 엔지니어링 설계뿐 아니라 사람의 학습에도 똑같이 적용됩니다.

장기 미해결 문제가 다시 떠오르고 “내가 직접 처리하면 20분이면 될 텐데” 싶을 때, “이 문제를 처리할 수 있는 사람이 정말 나뿐일까?” 를 스스로에게 물어야 합니다. 직접 처리하는 게 가장 효율적이겠지만, 그러면 다른 리더를 훈련시키는 데 실패하고 자율주행 조직을 만들지 못합니다. 시급하지 않다면 꾹 참고, 시간이 더 걸리더라도 남에게 맡긴 뒤 필요하면 코치하세요. 그리하여 업무 크리티컬 패스(critical path)에서 자기 이름이 사라지게 해야 합니다.

매일 아침 던져야 할 질문은 이것입니다 — “우리 팀원 중 아무도 할 수 없는 일 중에서 내가 할 수 있는 일은 무엇인가?” 답은 많습니다(조직 정치로부터 팀 보호, 팀원 격려, Ch02 팀워크 이끌어내기의 겸손·존중·신뢰 문화 조성, 상사와의 관계 관리). 하지만 가장 중요한 답은 ‘나는 나무들을 헤치고 숲을 볼 수 있다’, 즉 고차원적 전략(meta-strategy)을 정의할 수 있다 입니다. 전략은 기술 방향뿐 아니라 조직 차원까지 포괄하며, 모호한 문제를 장기적으로 어떻게 관리할지 규정하는 청사진입니다.

조율하고 반복하기 — 매크로매니징

자생력 있는 조직을 만들었다면 이제 새로운 문제나 전혀 다른 팀으로 떠날 자유가 생깁니다. 이는 훈련시킨 리더들이 한 단계 올라설 길을 터주는 일이자, 자신의 번아웃을 예방하는 길이기도 합니다.

다만 떠난 뒤에도 조직이 건실함을 유지하도록 ‘지도’ 해야 하되, 위기가 아닌 한 지나치게 개입하면 안 됩니다.

기계 마스터의 분필 표시

모든 기계를 꿰고 있는 은퇴한 마스터가 고장 난 기계를 호출받습니다. 그는 점검하고 소리를 들어보더니 한쪽 면에 분필로 작게 ‘X’를 표시하고는 “이 부분 벨트가 느슨하니 수리하라”고 말하고 떠납니다. 벨트를 조이자 기계는 쌩쌩해졌습니다. 그가 천만 원짜리 청구서를 보내자 CEO가 항의했고, 그는 새 청구서를 보냅니다.

• 분필로 표시한 비용: 1,000원
• 표시할 지점을 알려준 비용: 9,999,000원

이 이야기가 말하는 것은 ‘지혜’ 입니다. 단 한 번의 신중한 개입이 거대한 효과를 냅니다. 팀을 ‘커다란 비행선’으로 상상하세요. 마이크로매니징하거나 끊임없이 경로를 수정하는 대신, 한 주의 대부분을 세심히 관찰하고 경청 하는 데 쓰고, 주말쯤 분필을 들고 수정할 정확한 위치를 살짝 표시해줍니다.

관찰 95%, 개입 5%

좋은 관리는 관찰·경청 95% + 절묘하고 시의적절한 개입 5% 입니다. 보고서는 건너뛰고 현장 고객(엔지니어링 인프라 팀이라면 옆자리 동료들이 곧 고객입니다)과 직접 대화하세요. 지시는 사려 깊게, 경로 조정에 꼭 필요한 최소한으로 자제해야 합니다. 자칫 마이크로매니징으로 퇴행하면 다시 단일 장애점이 됩니다. ‘늘 떠나라’는 매크로매니징(macromanaging)의 다른 이름 입니다.

팀 정체성 설정 시 주의점

팀에는 일반적인 ‘문제’ 를 맡겨야 하는데, 흔히 특정 ‘제품’ 을 맡기는 실수를 범합니다. 제품은 문제에 대한 ‘해결책’일 뿐이며 시간이 지나면 더 나은 것으로 바뀝니다. 하지만 잘 선정한 문제는 영원합니다.

팀 정체성을 제품에 못박으면(“우리는 깃 리포지터리를 관리하는 팀”) 위험합니다. 미래에 엔지니어들이 새 버전 관리 시스템으로 옮기고 싶어 하면, 깃 관리팀은 조직 차원의 최선이 아닌데도 변화에 저항하게 됩니다. 제품이 정체성이 되어 눈을 가리는 것입니다. 반대로 문제를 할당하면(“우리는 회사에 버전 관리를 제공하는 팀”) 상황 변화에 맞춰 얼마든지 다른 해결책을 실험할 수 있습니다.

늘 확장하라 (Always Be Scaling)

여기서 ‘확장’은 팀 규모를 키우는 공격적 전략이 아니라, 방어적이고 개인적인 관점 입니다. 리더의 가장 값진 자원은 자신의 제한된 시간·집중력·에너지 입니다. 이 내면을 보호하는 법을 익히지 못한 채 책임과 영향력만 공격적으로 키우면, 확장은 오히려 파멸로 가는 지름길이 됩니다.

성공 사이클 — 보상은 더 많은 일이다

한 팀이 난제를 해결하는 사이클은 다음과 같습니다.

단계	무엇이 일어나는가	리더의 역할
분석	문제를 받고 씨름을 시작	눈가리개를 식별하고 모든 트레이드오프를 찾아 관리 방안 합의
분투	준비가 덜 됐어도 착수, 실패하면 다시 시도·반복	고양이 떼를 모으듯 의견 개진을 유도하고 경청, 전략 고안. 처음엔 ‘진심이 아닐지라도’ 듣는 척이라도
견인	팀이 문제를 정복하기 시작, 사기 상승	때때로 트레이드오프만 조율, 조직은 스스로 헤쳐나감
보상	상사가 성공을 축하	그런데 보상은 칭찬이 아니라 ‘전혀 새로운 문제’

성공의 보상은 더 많은 일과 더 많은 책임 입니다. 보통 인력 충원은 없으므로, 맡은 문제가 둘이 됩니다. 원래 문제도 관리해야 하니 절반의 인력·시간을 할애하고, 새 문제는 나머지 절반으로 대응합니다. 그래서 이 단계를 압축 단계(compression stage) — 하던 일을 절반 크기로 압축 — 라고 부릅니다.

graph LR
    A["분투"] --> B["'척'하기"]
    B --> C["견인"]
    C --> D["압축"]
    D --> E["더 격렬한 분투"]
    E -.->|반복| B

실제 성공 사이클은 평면적 원이 아니라 나선형 에 가깝습니다. 몇 달, 몇 해에 걸쳐 새 문제를 정복하고 압축하고 또 다른 문제를 배정받으며 조직이 점점 커집니다. 충원 속도가 확장 속도를 따라가지 못하는 게 보통입니다. 거북하지만 피할 수 없는 과정이며, 문제를 압축하려면 팀 효율을 극대화하는 동시에 자신의 시간·집중력도 함께 확장 해야 합니다.

중요한 일 vs 급한 일

아이젠하워 (1954)

저에겐 두 가지 종류의 문제가 있습니다. 급한 문제와 중요한 문제. 급한 문제들은 중요하지 않고, 중요한 문제들은 절대 급하지 않습니다.

(흔히 스티븐 커비의 말로 알려져 있지만 아이젠하워에게서 인용한 것입니다.) 조급함은 리더의 효율을 갉아먹는 가장 큰 적 입니다. 완전한 반응형 모드로 전환하면(거의 자동으로 그렇게 됩니다) 멀리 보면 중요하지 않은 ‘급한’ 일만 처리하며 시간을 흘려보냅니다. 고차원 전략 수립은 매우 중요하지만 시급한 경우는 드물고, 급한 메일을 처리하는 게 항상 더 쉽습니다. 급한 일이 아니라 ‘나만이 할 수 있는’ 중요한 일 에 몰두하기 위한 기술은 다음과 같습니다.

위임하자

급한 일 상당수는 다른 리더에게 위임할 수 있습니다. 사소한 일을 떠넘기는 데 죄책감이 들거나 비효율적이라 느껴지더라도, 이는 리더를 훈련시키는 좋은 수단이자 나만이 할 수 있는 일에 집중할 시간을 버는 길입니다.

따로 정기적으로 시간을 내자

정기적으로 2시간 이상, 방해받지 않고 중요하지만 급하지 않은 일 을 처리하는 시간을 마련합니다. 팀 전략 수립, 부하 리더 경력 관리, 옆 팀과의 협업 계획 같은 일입니다.

나에게 맞는 추적 시스템을 마련하자

소프트웨어 도구, 종이·펜의 불렛 저널(Bullet Journal), 구현과 무관한 방법(받은 편지함 0건을 유지하는 GTD, Getting Things Done) 등 다양합니다. 핵심은 여러 방법을 시도해 자신에게 맞는 것을 찾되, 모니터에 붙이는 ‘포스트잇’보다는 효과적인 방법 을 쓰라는 것입니다.

공 떨어뜨리기

엔지니어 시절의 본능과 정면으로 모순되는 방법입니다. 세부사항에 집중하고, 목록을 확인하고, 버그를 없애고, 받은 편지함을 0으로 만드는 데서 만족을 얻던 습관 말입니다. 하지만 리더의 시간과 집중력은 쉼 없이 공격받아 아무리 노력해도 결국 떨어뜨리는 공이 생깁니다. 자꾸 놓치다 보면 주눅이 들고 죄책감에 빠지기 쉽습니다.

그렇다면 어차피 떨어뜨릴 거, ‘실수로’보다 ‘의도적으로’ 떨어뜨리는 게 낫습니다. 그래야 최소한의 통제력은 유지됩니다. 곤도 마리에의 정리법(『인생이 빛나는 정리의 마법』)을 받은 편지함과 할 일 목록에 응용합니다.

선반	비중	무엇을 담는가
아래 칸	20%	급하지도 중요하지도 않은, 지우거나 무시할 공
중간 칸	60%	조금 급하거나 중요할 수도 있는 애매한 공
위 칸	20%	아주 중요한 게 확실한, 나만이 할 수 있는 공

곤도의 통찰은 ‘진짜’ 정리는 아래 20%를 버리는 게 아니라 위 20%에 무엇을 둘지 골라내는 것 이라는 점입니다. 상위 80%(위+중간)에 집중하면 될 것 같지만 아닙니다. 그러면 여전히 급하지만 중요하지 않은 일에 시간을 허비합니다. 오직 상위 20%에만 집중하고 나머지 80%를 버릴 권한을 자신에게 부여 해야 합니다.

처음엔 말이 안 된다 싶지만 의도적으로 공을 떨어뜨리다 보면 두 가지를 발견합니다 — 첫째, 중간 60%는 위임하지 않아도 때때로 중간 리더들이 알아서 가져갑니다. 둘째, 잘못 분류했더라도 ‘진짜’ 중요한 일이면 어떤 식으로든 다시 튀어올라 상위 20%로 돌아옵니다. “상위 20%에 못 든 일들은 알아서 처리되거나 다시 올라올 것”이라 믿기만 하면 됩니다.

에너지 관리하기

시간·집중력 못지않게 개인의 에너지 도 이 방정식의 한 축입니다. 모든 확장은 소모적이기 때문입니다. 두 가지 좋은 소식이 있습니다 — 첫째, 나이가 들수록 (육체보다) 정신적 지구력 이 좋아집니다. 마라톤 훈련처럼 뇌와 몸은 세월이 흐르며 체력을 축적합니다. 둘째, 리더는 에너지를 점점 더 지능적으로 활용하는 법을 배웁니다. 남은 에너지를 인지하고 시의적절하게 ‘충전’ 하는 것입니다.

방법	핵심
진짜 휴가 떠나기	주말은 휴가가 아님. 회사 일을 잊는 시간이 최소 3일(실감하려면 일주일). 쉬는 중 메일·채팅을 확인하면 단절의 이점이 모두 날아감
일과 쉽게 단절하기	업무용 랩톱은 회사에 두고, 폰의 업무 앱은 지우거나 안드로이드 ‘직장 프로필(work profile)‘로 버튼 하나에 전체 비활성화
진짜 주말 보내기	직장과 단절된 상태에서만 재충전됨. 금요일 저녁 미련 없이 퇴근, 주말엔 좋아하는 일만, 월요일 아침에 일 모드로 전환
매일매일 휴식하기	뇌는 90분 주기(BRAC)로 운용됨. 90분마다 일어나 10분 산책. 작은 재충전이지만 스트레스를 크게 낮춤
정신 건강의 날 권한 부여	이유 없이 저기압인 날, 리더의 어두운 기운은 팀 전체로 전염되고 끔찍한 결정으로 이어짐. 능동적으로 피해를 주느니 연차를 쓰고 귀가하는 게 차라리 나음

에너지 관리는 시간 관리만큼 중요합니다. 둘 다 잘 통제할 수 있게 되면, 책임을 확장하고 자생력 있는 팀을 일구는 성공 사이클을 헤쳐나갈 준비가 된 것입니다.

비교 / 트레이드오프

3A 한눈에 보기

격언	한 줄 요지	대표 안티패턴	핵심 도구
늘 결정하라	모호한 문제에 정답은 없으니 트레이드오프를 찾아 결정하고 반복	분석 마비(완벽한 해법 추구)	눈가리개 찾기 → 트레이드오프 파악 → 결정·반복
늘 떠나라	나 없이도 굴러가는 자율주행 조직을 남긴다	단일 장애점(SPOF)이 되는 것	문제 공간 분할, 위임, 매크로매니징(95% 관찰 + 5% 개입)
늘 확장하라	커지는 책임 속에서 나 자신을 방어적으로 확장한다	모든 공을 받아내려다 압사	중요 vs 급함 분리, 의도적으로 공 떨어뜨리기, 에너지 관리

마이크로매니징 vs 매크로매니징

관점	마이크로매니징	매크로매니징(늘 떠나라)
개입 빈도	끊임없이 경로 수정	관찰 95% + 시의적절한 개입 5%
결과	리더가 다시 SPOF로 퇴행	자율주행 조직이 스스로 항해
비유	운전대를 계속 붙잡음	비행선에 분필로 정확한 한 점을 표시

세 격언은 결국 하나의 메시지로 수렴합니다 — 리더의 가치는 직접 풀어낸 문제 수가 아니라, 자기 없이도 굴러가는 시스템(조직)을 얼마나 남겼는가 로 측정됩니다. Ch05 팀 이끌기의 ‘how가 아니라 what을 고민하라’를 조직 규모로 확장한 것입니다.

내 생각

• ‘늘 떠나라’는 곧 SPOF 제거이자 버스 지수 높이기입니다. 시스템 설계에서 단일 장애점을 없애려 이중화·문서화하듯, 리더 자신도 이중화 대상입니다. “휴가 중 메일을 확인했는가”는 곧 “내가 핵심 경로의 단일 인스턴스인가”를 묻는 헬스체크입니다.

• ‘문제를 맡기고 제품을 맡기지 말라’는 인터페이스 vs 구현의 조직 버전입니다. 제품(구현)에 정체성을 묶으면 더 나은 해결책으로의 마이그레이션을 팀 스스로가 저항합니다. 팀의 미션을 추상화 계층 한 단계 위(문제=계약)에 두면 구현 교체가 자연스러워집니다.

• ‘공 떨어뜨리기’는 의도적 부하 차단(load shedding)입니다. 과부하 시스템이 모든 요청을 받다 전체가 죽느니 우선순위 낮은 요청을 의도적으로 드롭하듯, 리더도 상위 20%만 처리하고 나머지를 버려야 무너지지 않습니다. “다시 튀어오르는 공”은 곧 정말 중요한 요청은 재시도로 다시 들어온다는 관찰입니다.

• 성공 사이클의 압축 단계는 곧 무한정 늘어나는 큐 깊이입니다. 처리량(충원)이 유입(새 문제)을 못 따라가면 리틀의 법칙대로 대기열이 폭증합니다. 위임으로 처리량을 늘리거나 공 떨어뜨리기로 유입을 줄이지 않으면 리더가 병목이 됩니다.

관련 개념

• Ch05 팀 이끌기 — 섬기는 리더십, ‘how가 아니라 what’, 위임의 토대. 이 장은 그 원리를 ‘팀들의 팀’ 규모로 확장
• Ch02 팀워크 이끌어내기 — 겸손·존중·신뢰(HRT), 자율주행 조직 문화의 바탕
• Ch03 지식 공유 — SPOF 분산·문서화는 ‘늘 떠나라’의 실천 도구