🎯 거대 조직에서 살아남는 법 - 리더십의 진짜 얼굴

 

조직이 크면 클수록, 단순한 전략은 통하지 않는다

작은 스타트업에서는 '우리 편 만들기'만 잘하면 됐어요. 그런데 대기업에 들어가보니 완전히 다른 세상이더라고요. 같은 목표를 향해 가는데도 팀끼리 방향이 달라서 충돌하는 상황이 일상이에요. 처음엔 이해가 안 됐는데, 시간이 지나면서 깨달았어요. 이게 조직이 돌아가는 자연스러운 방식이라는 걸요.

요즘 글로벌 기업들의 조직 구조를 보면 평균 5~7개 부서가 하나의 프로젝트에 관여한다고 해요. 각자 다른 목표와 예산, 평가 기준을 갖고 있죠. 그러니까 마찰이 생기는 게 당연한 거예요. 오히려 이런 충돌 속에서 더 나은 해결책이 나온다는 걸 경험으로 배웠어요.

프로젝트 범위가 과하게 잡혔다고요? 그게 다 전략이에요

신규 부서에서 대규모 검증 작업을 맡았을 때 이야기예요. 정말 비효율적으로 보였어요. 한 팀이 할 수 있는 일을 우리가 다 떠안고, 전문가들이 해야 할 일도 우리 몫이었죠. 게다가 로드맵은 터무니없이 과대하게 짜여 있었고요.

그런데 프로젝트가 끝나고 조직 개편이 시작되면서 전체 그림이 보이더라고요. 애초에 일부러 크게 잡은 거였어요. 나중에 축소하면서 핵심만 남기고, 각 팀이 예산을 확보할 명분을 만들려는 의도였던 거죠. 맥킨지 조사에 따르면 대기업 프로젝트의 약 70%가 초기 계획 대비 범위나 예산이 변경된다고 하더라고요. 이게 실패가 아니라 조직의 복잡성이 반영된 결과라는 걸 이제야 이해하게 됐어요.

결국 중요한 건 이해관계자들이 진짜로 원하는 게 뭔지 파악하는 거예요. 그들이 정치적으로 어떤 레버리지가 필요한지, 어떻게 해야 승리할 수 있는지를 알아야 해요. 처음엔 이런 정치적 게임이 불편했지만, 조직이 충분히 크면 피할 수 없는 현실이더라고요.

리더가 개입하지 않는 것도 하나의 개입이다

리더로서 가장 어려운 게 뭐냐면, 언제 직접 나서고 언제 지켜봐야 하는지 판단하는 거예요. 제 시간을 아껴야 하나요? 팀원에게 배울 기회를 주려는 건가요? 아니면 자율성을 키워주려는 건가요?

심리학에서 말하는 '심리적 어포던스'라는 개념이 있어요. 개입할 조건이 맞는지, 어떤 형태로 개입해야 하는지 판단하는 데 정말 유용한 프레임이에요. 여기서 중요한 건, 아무것도 안 하는 것도 결국엔 하나의 개입이라는 거예요.

기술 부채 문제가 사라진 이유는 해결했기 때문이 아니에요

개발자 경험 개선을 담당할 때 일이에요. 설문조사에서 '기술 부채'가 몇 분기 연속으로 상위 5순위에 올라왔어요. 그런데 절대 이걸 해결할 타이밍이 아니었죠. 리더십은 관심이 없었고, 항상 더 급한 일이 있었거든요.

더 큰 문제는 구조적인 거였어요. 엔지니어들은 로드맵 결정권이 있다고 들었지만, 실제로는 프로덕트 매니저들이 결정했어요. PM 중 상당수는 기술 부채를 진짜 문제로 보지 않았죠. 심지어 어떤 분은 제 면전에서 "그냥 엔지니어들이 불평할 때 쓰는 핑계"라고 말하더라고요.

가트너 조사를 보면 IT 리더의 60% 이상이 기술 부채가 혁신을 저해한다고 답했지만, 실제로 전략적 투자를 하는 조직은 30%에 불과하다고 해요. 이게 현실이에요.

그래서 저는 매 분기 기술 부채 이슈를 확인하고, 대신 다른 해결 가능한 이니셔티브를 찾았어요. PM들에게 개발자 도구 접근 권한을 주고 사용법을 알려줬죠. 엔지니어링 리더들이 로드맵에 영향력이 있다는 C-레벨의 가정과, 실제로는 없다는 현실 사이의 괴리를 명확히 했고요.

그랬더니 '기술 부채' 문제가 마법처럼 사라졌어요. 애초에 기술 부채가 문제가 아니었거든요. 커뮤니케이션이 문제였던 거죠. 물론 제가 '커뮤니케이션 문제'라고 말했다면 아무도 대화하지 않았을 거예요.

블랙 스완을 예측했지만 무시당했던 날

대규모 아키텍처 결정을 내릴 때 이야기예요. 잘못된 선택이 수십 년간 부정적 영향을 미칠 수 있는 프로젝트였어요. 회사는 모든 부작용을 예측하길 원했죠. 솔직히 말하면, 최대한 자기 방어를 하고 싶었던 거예요.

다른 사람들이 전통적인 리스크를 다룰 거라 생각했어요. 그래서 저는 블랙 스완 이벤트를 찾기로 했죠. 여러 오픈소스 프로젝트의 기업 포획 가능성과 공급망 지속성을 분석했어요. 국가 주체가 개입할 수 있는지, 그게 위협 모델에 어떤 영향을 미칠지도 파악하려고 했고요.

모든 의존성을 추적해서 기반 프로젝트들이 무기한 유지될 수 있는지 확인했어요. 안 되면 벤더들이 대응 메커니즘을 갖췄는지 확인해야 했죠.

2025년 정치 경제 상황이 어떻게 전개됐는지 보면 정말 제가 정확히 예측했더라고요. 맞을 때는 기분이 묘해요.

모든 우려사항과 대응 전략을 문서화해서 내부에 공유했는데, 정중하게 무시당했어요. 프로젝트의 정치적 의제와 맞지 않았거든요.

흥미로운 건 그 이후였어요. 약 10개월 후, 제가 나열한 모든 우려사항이 하나씩 현실이 되기 시작했어요. 블랙 스완 이벤트들이 실제로 일어나기 시작한 거죠.

다행히 문서를 써뒀기 때문에 사람들이 참고하며 전략을 세울 수 있었어요. 돌이켜보면 무시당한 게 오히려 좋았어요. 당시에 진지하게 받아들여졌다면 정치적으로 존재하지도 않는 문제를 해결하느라 프로젝트가 실패했을 거예요.

중요한 건 '일찍 맞는 것'보다 '모두가 정신 모델을 업데이트할 수 있는 상황'을 만드는 거더라고요.

판단보다 호기심이 먼저인 이유

솔직히 저는 아직도 이게 서툴러요. 스스로를 호기심 많은 사람이라 생각하지만, 때로는 정말 판단적이거든요. 직관이 좋은 편이라 대부분 틀리진 않지만, 때로는 참기 힘들어요.

그래서 스스로에게 물어요. '무엇이 이 사람의 선택을 가장 합리적으로 만드는 환경 조건일까?' 이 조건들을 파고들면 진짜 호기심 있는 질문을 할 수 있어요. 나쁜 의도로 유도 질문을 하고 싶진 않거든요.

여기서 중요한 점은 진짜 호기심이 없으면 호기심으로 리드하는 게 통하지 않는다는 거예요.

주당 2시간 미팅이 왜 문제냐고요?

개발자 경험 개선 작업 중에 흥미로운 일이 있었어요. '집중 시간'이라는 지표가 상위 10순위에 있다가 점점 올라와서 최우선 순위가 됐어요. 개발자들은 명확히 신호를 보냈는데, 엔지니어링 리더들은 전혀 모르거나 공감하지 못했어요.

호기심이 생겨서 모든 개발자의 캘린더를 조사했어요. 통계를 뽑아보니 개발자들이 주당 평균 2시간 정도 미팅을 한다는 거예요. 첫 반응은 웃음이었어요. 두 번째는 '좀 참지 그래'였죠.

주당 35시간 이상 미팅을 하는 리더 입장에서 보면 정말 우스운 일이에요. 그런데 일주일에 겨우 2시간 미팅으로 불평한다고요? 솔직히 공감하기 어려웠어요.

마이크로소프트 연구에 따르면 개발자들은 15분 이상 방해받으면 원래 작업에 완전히 집중하는 데 평균 23분이 걸린다고 해요. 2시간이 적어 보이지만, 몰입의 맥락에서는 큰 영향을 줄 수 있는 시간이죠.

데이터를 믿을 수 없어서 개발자들과 직접 인터뷰를 시작했어요. 그리고 여러 가지를 발견했죠.

리더십이 '미팅 없는 목요일'을 약속했는데 몇 분기째 지켜지지 않았어요. 채용 헤드카운트는 4배 늘렸는데 인터뷰하는 엔지니어는 늘리지 않아서 미팅 피로가 심했죠. 캘린더에 없는 즉석 미팅들이 많았고, 감사 시즌에는 지루한 컴플라이언스 미팅이 쏟아졌어요.

호기심을 가지고 접근하니 해결책이 자연스럽게 나왔어요. 미팅 에티켓 문서를 만들고, 개발자들이 미팅을 거절할 수 있게 권한을 주고, 미팅 없는 목요일을 실제로 지키고, 인터뷰 로테이션을 늘렸죠.

이런 개입 후에 개발자들의 평균 미팅 시간은 주당 6시간으로 '증가'했어요. 그런데 집중 시간 지표는 한 분기 만에 최하위 우선순위가 됐죠. 몇 분기 일찍 해결할 수도 있었지만, 진지하게 받아들일 수 없었던 거예요. 호기심으로 접근할 방법을 찾고 나니 해결책이 자연스럽게 나왔어요.

트레이드오프처럼 보이지만 사실은 양립 가능한 문제들

표면적으로는 단순한 트레이드오프처럼 보이는데, 실제로는 양립 가능한 상황인 경우가 많아요. 아키텍처 작업을 하다 보면 이런 경우를 자주 만나요.

한 프로젝트는 두 가지 목표가 있었어요. 기존 컴포넌트를 단종하고, 프로젝트 범위를 확장해서 더 많은 요구를 해결하는 거였죠. 표면적으론 우선순위 문제예요. 새 기능을 먼저 개발할까요, 아니면 기존 컴포넌트를 교체해서 빠르게 가치를 증명할까요?

정치적으로 보면 기존 컴포넌트 교체가 회사 방식에 맞았어요. 가치를 먼저 보여주고 나중에 개선하는 게 자연스러운 진행이거든요. 하지만 새 기능이 어떻게 구현될지 확실하지 않았어요. 꽤 진행하고 나서야 중요한 새 기능이 생각대로 구현 불가능하다는 걸 깨달을 수도 있었죠.

이런 트레이드오프를 만나면 먼저 트레이드오프 공간 자체를 이해하려고 해요. 이 선택들은 '새 로드맵 vs 기존 로드맵'의 이분법이 아니에요. 복잡하게 얽힌 기준들로 비즈니스를 위한 진화하는 역량을 개발하는 거죠.

깊이 파고들어 기준들을 분해하고 여러 역량을 매핑하니 진짜 선택이 명확해졌어요. 다음에 어떤 기능을 개발할지가 아니라, 향후 3년에서 5년을 대비하기 위해 회사로서 어떤 기반 역량과 기술을 개발해야 하는지였죠.

답은 당연히 '로드맵 어디에도 없는 많은 것들'이었어요.

아무도 이 답을 듣고 싶어 하지 않아요. 하지만 이런 답을 마주했을 때, 리더들이 믿게 만들고 상황을 재평가하게 만드는 게 정말 중요해요. 이 장벽을 넘으면 양립 가능한 상황으로 바뀌고 함께 문제를 해결할 수 있게 돼요.

몹 프로그래밍으로 팀 생산성을 3배 올린 방법

팀과 함께 새로운 작업 방식을 시도한 경험이에요. 엔지니어들이 며칠씩 조용히 막혀서 혼자 문제를 해결하고 있었어요. 너무 느렸죠. 제도적 지식도 개인에게 갇혀서 팀 전체로 퍼지지 않았어요. 팀 구성도 신입과 베테랑으로 양극화돼서 모두가 편하게 질문할 수 있는 환경이 필요했어요.

게다가 수백 개의 지루한 작업들이 있었어요. 20분에서 3주까지 걸리는 작업들이요. 정말 끔찍했어요.

처음엔 전통적인 방식으로 접근했어요. 티켓으로 나누고, 개별적으로 작성하고, 할당하고, 일일 업데이트를 요청했죠. 매우 표준적이고 매우 비효과적이었어요. 정보는 여전히 사일로에 갇혀 있었고, 사람들은 보이지 않게 지연됐고, 진척이 없었어요.

그래서 몹 프로그래밍과 페어 프로그래밍을 조합한 방식으로 바꿨어요.

전체 팀을 모아서 이틀 동안 모든 티켓을 함께 트리아지했어요. 실제 코드베이스에 들어가서 티켓이 쉬운지, 중간인지, 어려운지 큰 소리로 평가했죠. 모두가 내부 생각을 공유하니까 전문가들이 아는 이상한 팁과 트릭이 쏟아져 나왔어요. 어떤 게 어려울지에 대한 제도적 지식도 문서화됐죠.

스택오버플로우 조사에 따르면 개발자의 86%가 페어 프로그래밍이 코드 품질 향상에 도움이 된다고 답했고, 팀 학습 효과도 크게 증가한다고 해요.

그 후엔 쉬운 문제부터 할당하기가 훨씬 쉬워졌어요. 처음 몇 개 티켓은 몹으로 함께 했어요. 처음부터 끝까지 팀으로 진행하면서 라이브 트위치 스트리밍처럼 협업했죠. 모두가 흐름과 리듬을 알게 되자 페어 프로그래밍으로 나눴어요. 처음엔 줌으로 카메라 켜고 했지만, 적응 기간 후에는 카메라 선택권을 주고 업무 필요에 따라 유기적으로 하도록 했어요.

결과는 마법 같았고 처리량이 로켓처럼 올라갔어요. 나중에 다른 프로젝트에서도 사람들이 자연스럽게 몹-페어 방식을 쓰기 시작할 때 이 방식이 효과가 있다는 걸 알았어요. 문제와 학습을 공유하는 방식도 바뀌었죠. 팀의 협업 능력이 정말 촘촘한 메시가 됐어요. 이게 나중에 큰 도움이 됐고, 제가 리드한 팀 중 최고의 성과를 내는 팀 중 하나가 됐죠.

대기업 리더십은 완벽한 답이 아니라 올바른 질문에서 시작됩니다

큰 조직에서 리더십은 단순히 올바른 결정을 내리는 게 아니에요. 복잡성을 받아들이고, 마찰을 활용하고, 진짜 호기심을 유지하고, 적절한 타이밍을 기다리는 거예요.

리더십은 완벽한 답을 아는 게 아니라 올바른 질문을 던지고 환경을 읽는 능력이더라고요. 그리고 무엇보다 자신이 틀릴 수 있다는 걸 인정하면서도, 팀이 배우고 성장할 수 있는 공간을 만드는 거예요.

요즘 조직 문화 연구를 보면 심리적 안전감이 높은 팀이 그렇지 않은 팀보다 평균 27% 이상 높은 성과를 낸다고 하더라고요. 결국 리더십의 핵심은 사람들이 실패를 두려워하지 않고 시도할 수 있는 환경을 만드는 거예요. 완벽한 계획보다 중요한 건 배우고 적응하는 능력이거든요.