들어가기 앞서
애디 오스마니의 『무엇이 1등 팀을 만드는가』(원제 Leading Effective Engineering Teams)는 구글 크롬의 엔지니어링 리더가 25년의 경험과 구글의 두 대형 연구를 정리한 책이다. 7장짜리인데 1~4장과 5~7장의 성격이 꽤 다르다. 앞쪽은 '효과적인 팀이란 무엇인가'를 세우는 개념 편이고, 뒤쪽은 안티패턴 카탈로그와 매니저·리더의 실전 편이다. 한 번에 다 정리하면 너무 길어지기도 하고, 사실 앞쪽 네 장이 책의 사고방식을 거의 다 담고 있다. 그래서 1~4장을 장별로, 대신 핵심은 빠뜨리지 않고 정리한다.
관통하는 한 줄은 이렇다. 효과성은 올바른 일을 올바르게 하는 사고방식이고, 리더가 그걸 정의하고 맡기고 키울 때 팀이 1등이 된다.
1장. 무엇이 효과적인 팀을 만드는가
집단과 팀은 다르다
책은 집단(group)과 팀(team)을 갈라놓고 시작한다. 집단은 각자 일을 조율하는 개인들의 모음이고, 팀은 공동의 책임과 목표로 묶인 집단이다. 같은 자리에 앉아 있다고 팀이 되는 게 아니다. 리더는 그 개인들을 공동 목표에 연결하는 축으로서 비전·방향·조언·환경을 제공한다.
아리스토텔레스 프로젝트: 구성이 아니라 상호작용
1장의 중심은 구글의 아리스토텔레스 프로젝트다. 180개 팀을 인터뷰·설문하고 35개 통계 모델로 분석했다. 출발 가설은 "팀이 어떻게 구성되는가보다 팀원이 어떻게 상호작용하는가가 더 중요하다"였고, 데이터가 이를 뒷받침했다. 반직관적인 건 무엇이 영향을 주지 않았는가다. 팀의 규모, 한 공간 근무 여부, 외향성, 직급, 근속 연수 같은 구성 변수는 효과성과 별 상관이 없었다.
대신 다섯 가지 원동력이 중요도 순으로 나왔다. 중요도 1위가 맨 아래 토대가 되고, 그 위로 차례차례 쌓이는 구조다.
효과적인 팀의 5가지 원동력 (아래가 위를 떠받친다)
[5위] 영향력 : 내 일이 가치 있고 변화를 만든다
[4위] 의미 : 이 일이 내게 개인적으로 중요하다
[3위] 체계와 명확성 : 역할·계획·목표가 분명하다
[2위] 신뢰성 : 서로 제때, 높은 기준으로 해낼 거라 믿는다
──────────────────────────────────
[1위] 심리적 안전감 : 걱정 없이 솔직할 수 있다 (토대)
Plain Text
복사
이건 단순 나열이 아니라 계층이다. 맨 아래 심리적 안전감이 토대가 되고, 그 위에 신뢰성, 체계와 명확성, 의미, 영향력이 차례로 쌓인다. 바닥이 없으면 위층은 세워지지 않는다.
아리스토텔레스가 가장 유명하지만 책은 다른 연구도 같이 본다. 작은 팀이 낫고(소통 채널이 기하급수적으로 늘기 때문에 많은 연구가 10명 이하를 권한다), 다양성은 이로우며(미시간대 루 홍과 스콧 페이지 연구에서 다양성을 섞어 뽑은 집단이 최고 실력자만 모은 집단을 이겼다. 단, 포용이 전제될 때다), 투명한 소통은 필수이고, 리더십은 중요하며(옥시젠), 기민함이 적응력을 높인다(맥킨지의 애자일 연구).
동기부여가 성과를 이끈다
성과는 동기부여가 이끈다. 다니엘 핑크의 『DRIVE』를 빌려 책은 내적 보상 세 가지를 든다. 자율성(자기 주도로 일하려는 욕구), 전문성(기술을 계속 갈고닦으려는 장인정신), 목적의식(의미 있는 일을 하려는 욕구). 금전 보상은 단순 작업에서만 잘 듣고, 창의가 필요한 개발 업무에선 내적 보상이 더 강력하다. 5년차 엔지니어 데이비드는 연봉이 아니라 '톱니바퀴가 된 기분' 때문에 열정을 잃었고, 매니저 사라가 권한 사회적 영향력 있는 프로젝트로 다시 불타올랐다. 동기는 쥐여주는 게 아니라 연결해주는 것에 가깝다.
효과적인 팀 만들기 4단계
1장의 나머지는 '그래서 어떻게 만드느냐'에 답한다. 인재를 모으고, 팀 정신을 일깨우고, 리더십을 발휘하고, 그 효과성을 이어가는 네 단계인데, 순서가 곧 한 팀이 자라나는 과정이기도 하다.
① 적합한 인재 모으기. 첫 단추는 사람을 모으는 일이지만, 책은 의외로 '크기'부터 경계한다. 최적 인원은 3~5명이고, 규모가 능사가 아니라는 걸 '코드 크루세이더스'가 보여준다. 멋진 첫 버전을 낸 스타트업이 성공 후 30명으로 불어나 같은 제품의 네 버전을 동시에 떠안자, 결속력 있던 팀이 고립된 집단으로 쪼개졌다. 팀은 자기 성공의 피해자가 될 수 있다.
누구를 뽑느냐에서 책이 기술 역량만큼 보는 건 '엔지니어적 사고방식'이다. 닐 디그래스 타이슨의 면접 일화가 이걸 압축한다. 첨탑 높이를 묻자 한 지원자는 외운 숫자를 빠르게 답했고, 다른 지원자는 "모른다"고 인정한 뒤 그림자 길이로 높이를 유추했다. 정답을 아는 사람보다 생각하는 법을 아는 사람이 강하다는 것이다. 다양성도 마찬가지인데, 모으는 것만으로는 부족하다. 네 대륙 출신이 섞인 어느 구글 팀은 초기 회의가 대화가 아니라 '독백'이었지만, 라운드 로빈 회의나 멘토링 같은 장치로 포용을 설계하고 나서야 그 다양성이 비로소 힘이 됐다.
② 팀 정신 일깨우기. 사람을 모았으면 '한 배를 탔다'는 감각을 심어야 한다. 핵심은 역할을 할당하는 게 아니라 이해시키는 것이다. 알렉스의 팀은 기능은 완벽한데 사용자가 불만이었는데, 원인은 무능이 아니라 잘못 그어진 책임선이었다. 개발자에게 자기 문서와 유닛 테스트를, 테스터에게 투명한 테스트 계획을, 라이터에게 매뉴얼을 제대로 맡기자 비난이 협력으로 바뀌었다. 여기에 '왜 하는가'라는 공동의 목적과 서로에 대한 신뢰가 더해진다. 같은 실력이라도 열린 '오픈도어 팀'은 혁신과 신뢰를 얻고, 무관심한 '사일로 팀'은 "내 알 바 아니야" 속에 흩어졌다. 실력이 아니라 신뢰의 유무가 갈랐다.
③ 효과적으로 리더십 발휘하기. 리더의 일은 팀을 꾸리고 자원을 대고 위험을 미리 치우는 것이지만, 책이 따로 짚는 건 '전략적 가시성'이다. 뛰어난 브라우저 팀이 더 화려한 프로젝트들의 그늘에 가려 인정받지 못하자, 리더는 회사의 핵심 목표와 팀의 강점이 겹치는 일을 골라 뛰어들고 그 과정을 문서로 공유했다. 결국 전사 회의에서 인정받았다. 단 조건이 붙는다. 자기 공을 내세우지 말고 팀을 비추는 치어리더가 되라는 것이다. 가시성은 자기 홍보가 아니라 팀의 일을 이야기로 만들어 보여주는 것에 가깝다.
④ 성장 지향 문화로 효과성 이어가기. 마지막은 만들어둔 효과성을 지키는 일이다. 효과성은 한 번 만들면 끝이 아니라 부패하기 쉽다. 정체는 지루함과 인재 유출을 부른다. 그래서 학습과 멘토링으로 성장을 공급하고, 애자일과 CI/CD로 기민함을 유지하고, 프로세스와 도구를 꾸준히 손봐야 시간이 지나도 효과성이 남는다.
2장. 효율성 · 효과성 · 생산성, 그리고 수박 효과
세 단어를 갈라놓기
2장은 비슷해 보이는 세 단어를 구분하는 데 거의 전부를 쓴다. 효율성은 일을 올바르게 하는 것(낭비 최소화, 결과물 측정), 효과성은 올바른 일을 하는 것(고객·조직 가치, 성과 측정), 생산성은 투입 대비 산출이라는 효율성의 하위 개념이다. 셋은 다르지만 상호 배타적이지 않다. 측정의 결도 다르다. 생산성은 코드 줄 수·기능 점수·스토리 포인트·배포 빈도 같은 날 수치, 효율성은 거기에 시간·자원·결함 밀도·품질을 더한 정제된 수치, 효과성은 고객 만족도·비즈니스 가치·사용자 채택률·ROI·출시 속도처럼 성과 그 자체다.
세 단어가 어떻게 갈리는지는 음식 배달 앱 MVP 사례가 깔끔하다. 같은 MVP를 만든 두 팀 중, 같은 기간 더 많이 만든 A팀이 더 생산적이고, 더 적은 자원으로 더 적은 이슈를 남긴 B팀이 더 효율적이며, 첫 달 같은 다운로드에도 재주문이 세 배 많았던 A팀이 더 효과적이다(A에는 비건 필터가 있어 사용자가 더 자주 썼다). '생산성 1등', '효율성 1등', '효과성 1등'은 서로 다른 팀에 손을 들어줄 수 있다.
결과물과 성과는 다르다
가장 중요한 구분은 결과물(output)과 성과(outcome)다. 결과물은 우리가 만든 것이고, 성과는 그래서 달라진 것이다.
결과물(무엇을 만들었나) → 성과(그래서 무엇이 달라졌나)
──────────────────────────────────────────────────
새 앱 출시 → 사용자 증가
코드 리팩터링 → 성능 개선
새 기능 추가 → 더 나은 사용자 경험
디자인 문서 발행 → 개발 프로세스 간소화
새 API 배포 → 다른 기업과의 협업
Plain Text
복사
문제는 왼쪽이 오른쪽으로 저절로 이어지지는 않는다는 데 있다. '클라우도이드' 팀이 그 함정에 빠졌다. 마이크로서비스와 쿠버네티스로 멋지게 옮기고 마감 준수를 피자로 자축했지만, 사용자 입장에서는 아무것도 안 달라졌다. 리더는 자기들이 '영향력 없는 기술의 왕국'을 짓고 있었음을 깨닫는다. How에 빠져 Why를 놓친 것이다.
결과물만 좇으면 네 가지 함정에 빠진다. 개인 결과물을 떼어 정확히 재기 어렵고, "많이 찍어내라"는 압박이 가치 없는 과잉 생산을 부르고, 비현실적 마감이 날림을 낳고, 끝없는 경쟁이 번아웃으로 간다. 기능에만 집중해 비대해진 윈도우 비스타, 법에 출시일이 박혀 완성도와 무관하게 강행했다 무너진 HealthCare.gov가 예다.
이 착시에 책은 이름을 붙였다. 수박 효과. 지표는 초록불인데 실제 성과는 빨간불이다. 겉은 멀쩡한데 속은 이미 익어버렸다. 코드 줄 수, 수정한 버그 수, 출시한 기능 수가 서류상 좋아 보여도 실제 가치와 무관하면 그건 거짓 양성 지표다.
가장 아픈 사례는 저자 팀의 테크 리드 브라이언이다. PR도 디자인 문서도 보안 계획도 흠잡을 데 없었던 결과물의 장인이었지만, 시장 조사로 방향이 바뀔 때마다 좌절했고 자기가 만들 수 있는 결과물에만 집중하고 싶어 했다. 비즈니스 성과는 제품 팀이 대신 고민해주길 바랐고, 결국 팀을 떠났다. 반대로 지멘스 헬스 서비스는 '원하는 성과부터 파악'하는 쪽으로 접근을 바꿔 정말 중요한 결과물을 짚었고, 작업 주기를 42% 단축했다. 성과에 집중하니 올바른 결과물이 보였다.
효과적인 효율성과 절충
책이 권하는 이상은 '효과적인 효율성', 올바른 일을 올바르게 하는 것이다. 크롬의 스타 개발자 제인은 기술적 측면에만 빠져 비즈니스 목표를 놓치곤 했는데, 저자가 PM과 협업하게 하자 더 넓은 시야를 갖게 됐다. 책은 개발자가 효과적인 효율성에 닿는 행동을 넷으로 정리한다. 코딩 전에 큰 그림부터 질문하기, 표준 지키기, 비공식적으로도 협력하기, 적절한 도구 쓰기. 여기 붙은 '20분 규칙'이 실용적이다. 막히면 처음 20분은 스스로 분석하고, 그다음 발견한 것을 공유하며 질문하라.
효율과 효과는 늘 맞물리지 않아서 절충이 필요하다. 새 기술의 학습 비용, 포괄적이지만 느린 테스트와 빠르지만 일부만 보는 테스트 사이의 선택 같은 것들이다. 일정·예산·유지보수성·사용자 요구가 그 선택을 좌우한다. 초창기 에어비앤비가 화려한 검색 필터를 미루고 사진 프로필과 예약이라는 핵심만 남긴 것처럼, 무엇을 포기할지가 곧 전략이다.
새 시각으로 측정하기
코드 줄 수 같은 전통 지표는 반복 작업용이라 지식 노동을 못 잡는다. 깃허브는 사내 도그푸딩으로 슬랙·지라·PR·문서 데이터를 모아, 피드백을 받는 시간이나 집중 작업 시간 같은 질문으로 전체론적 생산성 지표를 만들었다. 목표 프레임워크는 수준별로 쓴다. 개인은 SMART, 팀은 GQM(목표·질문·지표), 조직은 OKR이다. "최선을 다하자"는 목표는 함정이다. 외부 기준이 없는 '최선'은 사람마다 제각각 해석된다. 구체적이고 어려운 목표가 더 높은 성과를 내고, 시어즈 홀딩스에서 OKR을 일관되게 쓴 팀은 상위 성과 팀이 될 확률이 11.5%포인트 높았다.
결국 균형은 세 가지에 달렸다. 올바른 것을 파악하는 전략, 성공을 어떻게 잴지 정하는 지표, 끝까지 실행하는 결단과 행동. 넷플릭스는 비디오 로딩 시간·화질·비트레이트·중단 빈도 같은 사용자 체감 지표를 데이터로 모니터링하며 효율과 효과를 동시에 잡는다.
3장. 효과적인 엔지니어링을 위한 3E 모델
리더가 효과성을 키우는 세 단계, 3E다. 아래 단계가 위 단계의 토대가 된다.
3E 모델 : 리더가 효과성을 키우는 3단계 (위로 갈수록 넓어진다)
▲ 3단계 확장(Expand) 검증된 방식을 다른 팀·조직으로 이식
│ 2단계 권한 부여(Empower) 자원·자율·신뢰로 스스로 결정하게
│ 1단계 활성화(Enable) '효과성'이 뭔지부터 정의하고 시동
Plain Text
복사
활성화(Enable): 효과성을 정의하라
첫 단계는 '효과성이 뭔지부터 정의하는 것'이다. 핵심은 그 정의가 조직마다 다르다는 데 있다. 스타트업의 효과성은 MVP를 빨리 내놓는 것, 에이전시는 예산 안에서 정시 고품질 납품, 사회적 기업은 도움받은 사람 수다. 그러니 하나의 정의를 위에서 못 박으면 해롭다. 같은 회사 안에서도 충돌한다. 영국 텔레그래프에서 광고 팀은 광고로 수익을 늘리려 했지만 그건 성능과 UX를 해쳐 엔지니어링 팀 목표를 방해했고, 결국 절충안을 찾아야 했다. 가트너의 2020년 조사가 정의의 방향을 거든다. 팀이 자기 표준을 직접 만들게 하면 23% 더 효과적이고, 다재다능한 팀이 전문가만 모인 팀보다 18% 더 효과적이며, 장애물을 미리 치우는 서번트 리더십은 효과성을 16%(이해관계자 협력 시 11% 추가) 끌어올렸다. 정의했으면 소통·교육·측정·피드백·보상으로 시동을 건다.
권한과 자율성 부여(Empower): 기회는 살찌우고 문제는 굶겨라
이 단계의 원칙을 책은 한 문장으로 압축한다. "기회는 살찌우고 문제는 굶겨라." 성장 기회엔 자원을 몰아주고, 장애물의 영향력은 빠른 처리로 굶긴다. 어느 팀이 성능 문제를 일으킨 DB 쿼리에 인덱스를 추가해 해결했는데, 같은 최적화를 비슷한 문제가 생길 다른 페이지에도 적용하면 그건 기회를 살찌우는 것이 된다.
그런데 이 단계에서 가장 흔한 병목은 의외로 리더 자신이다. 저자도 팀이 커지자 메일함이 '결정을 기다리는 요청'으로 막히고서야 자신이 병목임을 깨닫고, 유일한 의사결정권자에서 멘토·조언자로 역할을 바꿨다. 피터 드러커의 자기경영 습관도 같은 맥락이다. 시간이 어디로 흐르는지 파악하고, 오직 나만 할 수 있는 일에 집중하고, 강점에 힘을 쏟고, 몇 가지 핵심 분야에만 집중하라는 것이다. 리즈 와이즈먼의 구분으로, 리더는 팀 역량을 키우는 멀티플라이어도, 자기도 모르게 짓누르는 디미니셔도 될 수 있다.
팀을 진단하는 틀도 둘 나온다. 렌시오니 모델은 신뢰의 결핍 → 충돌의 두려움 → 헌신의 결핍 → 책임의 회피 → 결과에 대한 무관심으로 이어지는 5층 기능 장애 피라미드다(신뢰가 토대). 터크만 모델은 형성 → 격동 → 규범 → 성과 → 해산의 발달 5단계인데, 선형이 아니라 신규 합류 시 후퇴할 수 있다. 깃랩의 테일러 머피는 데이터 팀의 급성장에 dbt 도입·스노우플레이크 이전·문서화 투자·회의 축소·경영진 지지로 대응했다.
여기에 레버리지가 효과성을 숫자로 만든다. 앤드루 그로브의 표현으로 레버리지가 높다는 건 더 적은 노력으로 더 많은 성과를 낸다는 뜻이다. 자주 간과되는 게 조직적 레버리지인데, 개인 효과성을 10% 올리는 것보다 30명 조직의 효율을 10% 올리는 게 엔지니어 3명을 더 뽑은 것과 같다. 그래서 멘토링·자동화·재사용처럼 팀 전체를 끌어올리는 활동이 우선이다. 구글이 프로토콜 버퍼·맵리듀스·빅테이블 같은 공유 추상화와 코드 랩에 초창기부터 투자한 것도 같은 이유다.
확장(Expand): 늘 결정하라, 늘 떠나라, 늘 확장하라
확장은 검증된 방식을 다른 팀으로 퍼뜨리는 단계다. 크롬 부서의 베테랑 캐시는 역할이 커지자 코드 리뷰부터 전략 회의까지 다 챙기려다 병목이 됐는데, 신뢰로 위임하고 보고를 간소화하고 2차 리더십 계층을 길러내며 풀렸다. 역할을 넓힌다는 건 더 많은 일을 관리하는 게 아니라 팀이 더 자율적으로 일하게 만드는 것이다. 역할이 커질수록 관심은 기술에서 사람으로 옮겨가고, 기술 전문성은 부차적이 되며, 자잘한 운영에서 내 자리는 사라진다.
만트라는 벤 콜린스-서스만의 "늘 결정하라, 늘 떠나라, 늘 확장하라"다.
•
늘 결정하라. 정보가 부족해도 제때 고차원 결정을 내려라. Build vs Buy 같은 결정에서는 '눈가리개'(편견·정보 한계)를 먼저 찾고, 핵심 절충안을 드러내고, 분석 마비에 빠지지 말고 의도적으로 결정한 뒤 결과를 보며 조정한다.
•
늘 떠나라. 팀을 방치하라는 게 아니라, 내가 없어도 굴러가는 자율주행 팀을 만들라는 뜻이다. 여기 버스 지수가 연결된다. 핵심 인력이 빠져도 안 무너질수록(버스 지수가 높을수록) 회복탄력적이다. 리더 한 명 없으면 멈추는 팀에서 그 리더는 단일 장애점일 뿐이다. 자율주행 팀은 문제 공간을 쪼개고, 하위 문제를 다른 리더에게 위임하고, 알아차리지 못할 정도로만 조율하며 만들어진다.
•
늘 확장하라. 더 키우라는 게 아니라 시간·집중력·에너지를 보호하라는 뜻이다. '중요하지만 급하지 않은 일'에 매일 시간을 떼어두고, 곤도 마리에의 정리법으로 할 일을 20/60/20으로 나눠 나만 할 수 있는 상위 20%에 집중한다. 에너지도 관리 대상이다.
아마존이 모범으로 나온다. 베조스의 빠른 고품질 결정("늘 결정하라"), "세상의 모든 것을 팝니다"라는 확장 열망("늘 확장하라"), 피자 두 판으로 먹일 만큼 작은 팀("늘 떠나라").
4장. 효과적인 관리 행동: 구글의 연구
4장은 1~3장의 주장에 구글의 실제 연구를 붙이는 장이다. 옥시젠 프로젝트는 좋은 매니저를, 아리스토텔레스 프로젝트는 좋은 팀을 다룬다.
옥시젠 프로젝트: '매니저는 중요하지 않다'를 반증하려다
출발이 짓궂다. 2007년에 생긴 인력 분석 팀은 원래 '매니저는 중요하지 않다'를 증명하려고 데이터를 팠다. 초창기 구글은 중간 관리자를 다 없앤 수평 조직을 실험하기도 했다. 그런데 데이터가 정반대였다. 좋은 매니저가 있는 팀이 더 행복하고 생산적이었다. 반증하려던 가설이 뒤집히면서 2008년 옥시젠 프로젝트가 시작된다. 직원 설문, 이중 익명 인터뷰, 최고/최악 매니저 선정을 거쳐 처음 8가지 행동을, 이후 10가지로 개편했다.
1.
좋은 코치로 행동하기
2.
마이크로매니징 대신 팀에 권한 부여하기
3.
포용적 환경을 만들고 성공·웰빙에 관심 갖기
4.
생산적이고 결과 지향적으로 행동하기
5.
경청·공유에 능한 의사소통가 되기
6.
경력 개발을 지원하고 성과를 관리하기
7.
팀을 위한 명확한 비전과 전략 갖기
8.
조언할 핵심 기술 능력 갖추기
9.
뛰어난 의사결정자 되기
10.
회사 전반에 걸쳐 협업하기
목록보다 순서가 더 많은 걸 말한다. 1번이 '좋은 코치'이고, '핵심 기술 능력'은 한참 뒤인 8번이다. 매니저를 매니저로 만드는 건 기술력이 아니라, 사람을 키우고 방향을 주고 막힌 걸 치워주는 능력이라는 뜻이다. 엔지니어 출신 리더가 가장 받아들이기 힘든 결론이기도 하다. 좋은 권한 부여가 방임이 아니라 타이밍이라는 점도 분명히 한다. 한 구글러는 "목표를 향해 일할 자유를 주되, 언제 개입해야 하는지도 정확히 아는" 매니저를 최고로 꼽았다.
이 장에는 바로 쓸 도구도 여럿 나온다. 1:1 미팅은 프로젝트만이 아니라 경력·동기·웰빙까지 다루는 자리이고, 매니저가 자기 효과성("제가 해드려야 하는데 아직 못 한 일이 있나요?")까지 점검하는 양식을 제시한다. 경력 대화에는 GROW 모델을 쓴다. Goal(목표) → Reality(현실) → Option(선택) → Will(의지)의 네 질문이다. 업무와 무관한 쉬운 웰빙 목표 하나를 정하게 하는 '간단한 것 하나(One Simple Thing)'도 있다. 비전을 다룰 때는 추상적인 '왜'에서 출발해 구체적인 '무엇'으로 내려오는 피라미드를 쓴다.
가치에서 목표로 (위는 추상적인 '왜', 아래로 갈수록 구체적인 '무엇')
목적 : 왜 우리는 존재하나
▽
핵심 가치 : 우리가 굳게 믿는 신념
▽
사명 : 무엇을 이루려 하나
▽
전략 : 그것을 어떻게 이룰까
▽
목표 : 전략을 쪼갠 단기·달성 가능한 목표
Plain Text
복사
추상적인 '왜'가 구체적인 단기 목표까지 한 줄로 꿰이는 셈이다. 구글은 이 연구를 매니저 개발 프로그램과 최고 매니저 상(Great Manager Award)의 기준으로 제도화했다.
아리스토텔레스 프로젝트: 매니저가 5원동력을 어떻게 심는가
5원동력은 1장에 나왔지만, 4장은 '매니저가 이 다섯을 어떻게 팀에 자리잡게 하느냐'에 초점을 둔다.
심리적 안전감. 가장 중요한 요인이고, 책이 분명히 선을 긋는다. 에이미 에드먼슨이 정의한 이 개념은 집단 응집력과 다르다. 응집력만 높은 팀은 분위기 깨질까 봐 반대를 삼키지만, 심리적 안전감은 나쁘게 보일 두려움 없이 발언하고 위험을 감수하는 것이다. 발언을 주저하는 이유도 성격이 아니라 상황에 있다(상황적 관점). 구글의 역할극 워크숍에서 참가자들은 사람들이 보통 자기를 보호하려 위험한 행동을 피한다는 걸, 그리고 그 회피가 효과적 팀워크엔 독이라는 걸 체험했다. 핵심은 심리적 안전감이 성과 기준을 낮추는 게 아니라는 것이다. 높은 기준을 유지하면서도 솔직할 수 있는 상태이고, 기준을 낮추는 게 아니라 솔직함의 비용을 낮추는 것에 가깝다. 매니저는 갈등에 협력자로 접근하고, 비난을 호기심으로 전환하고, 자기 소통 방식에 대한 피드백을 구하고, 정기적으로 측정해서 이를 높인다.
신뢰성. 거창한 게 아니라 회의 시간을 지키는 것 같은 단순한 데서 드러난다. 한 명이 늦으면 팀 전체 불만을 부르고, 지각이 용인되면 시간 약속에 무관심해진다. 신뢰할 수 있는 사람의 특성은 진정성 있는 의도, 책임감, 합리적 사고방식, 꾸준한 기여다. 매니저는 팀 내부뿐 아니라 외부 이해관계자에게도 팀의 신뢰성을 보여야 한다.
체계와 명확성. "누가 팀원인지보다 팀원들이 어떻게 상호작용하고 업무를 체계화하느냐가 훨씬 중요하다"는 게 아리스토텔레스의 핵심 결론이다. 원격·하이브리드가 보편화되며 더 중요해졌다. 담당과 기대가 명확하면 엔지니어는 매번 방향을 논의하지 않고 자주적으로 나아간다. 도구는 둘이다. OKR은 팀 목표를 최소 하나의 조직 목표와 잇고, RACI 차트는 결과물별로 실무 담당자(R)·의사결정권자(A)·조언자(C)·통보 대상자(I)를 못 박아 혼란과 중복을 없앤다.
의미. 일에서 목적의식과 성취감을 느끼는 것이다. 의미는 사람마다 다르다. 코딩 자체의 열정일 수도, 가족 부양이나 사회 변화 같은 개인 목표의 수단일 수도 있다. 의미를 느끼면 팀원은 '완료할 일'이 아니라 '잘 해낼 일'로 임한다. 매니저의 임무는 동기부여 일장연설이 아니라, 각자가 공감할 수 있는 이야기를 찾도록 돕는 것이다.
영향력. 자기 일이 진짜 변화를 만든다는 걸 깨달을 때 사람은 더 몰입한다. 인정받으면 가치 있다고 느끼지만, 아무도 알아주지 않으면 일을 대충 처리하게 된다. 아무리 작은 업무도 조직 목표에 한 걸음 다가가는 일임을 보여주는 게 리더의 몫이다.
작은 규범이 만든 측정 가능한 변화
이게 구호가 아니라는 증거가 있다. 구글의 한 실험에서, 모든 회의를 주말 잡담 같은 가벼운 대화로 시작하는 작은 규범 하나를 도입한 팀은 심리적 안전감 평가가 6%, 체계와 명확성 평가가 10% 올랐다. 구글은 이런 진단을 gTeams exercise라는 10분 설문과 대면 토론 도구로 제도화했다. 회의 첫 5분을 바꾼 것만으로 측정 가능한 변화가 났다.
마무리
1장~4장을 관통하는 건 결국 하나다. 효과성은 능력이 아니라 사고방식이고(1장), 그 사고방식은 결과물이 아니라 성과를 본다(2장). 리더는 그 효과성을 정의·위임·확장하고(3장), 이 모든 게 구호가 아니라 데이터로 뒷받침된다(4장). 5~7장의 안티패턴과 실전 매뉴얼은 다음 글에서 이어가겠다.
