▲

소프트웨어 회사처럼 바라보기

 (seangoedecke.com)
22P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • James C. Scott의 “Seeing Like A State(국가처럼 보기)” 의 핵심은 조직이 시스템의 “가독성(legibility)” 을 높여 모든 것을 측정·보고할 수 있도록 바꾸려 한다는 것
  • 그러나 실제로는 추적·예측 불가능한 “비가독적 작업” 이 필수적이며, 가독성만 중시하면 오히려 효율이 떨어지는 현상이 발생함
  • 특히 대기업들은 분기별 계획, OKR, Jira 등의 프로세스를 통해 업무를 가독적으로 만들지만, 이는 역설적으로 효율성을 떨어뜨리며, 소규모 회사가 대기업보다 20배 효율적일 수 있음
  • 조직은 긴급 상황 대응을 위해 "타이거 팀"과 같은 임시 비가독적 영역을 허용하며, 엔지니어 간 백채널을 통한 비공식 협업이 공식 프로세스만큼 중요한 역할을 수행
  • 기술 기업의 성공은 가독적 프로세스와 비가독적 실무 사이의 균형 유지에 달려 있으며, 둘 중 어느 하나만으로는 조직이 제대로 작동하지 않음

서론: “Seeing Like A State”의 핵심 아이디어

  • James C. Scott의 저서 “Seeing Like A State(국가처럼 보기)”의 핵심은 다음 세 가지로 요약됨
    • 현대 조직은 시스템을 “가독성(legibility)” 이 극대화된 형태로 바꿔서, 모든 부분이 측정 및 보고 가능하도록 통제함
    • 하지만 이 조직들은 거대한 “비가독적(illegible)” 작업에 의존함. 즉, 추적하거나 계획될 수 없지만 필수적인 작업이 다수 존재함
    • 가독성의 증진은 효율성을 저해하는 경우가 많으나, 그 밖의 이점(통제, 계획, 투명성 등)이 큰 이득으로 간주됨
  • 가독성이란 예측 가능하고, 산출이 추적 가능하며, 특정 인적 자원에 의존하지 않는 작업임. 예: 일정 관리, OKR, Jira 등
  • 비가독성은 즉흥적이거나 암묵지에 기반한 일, 즉 서면화, 공식화가 불가능한 협업이나 갑작스러운 변경, 인간관계에 의존하는 일 등임

“국가처럼 바라보기(Seeing like a state)” 사례

  • Scott은 19세기 독일의 “질서정연한 숲” 사례를 들어, 조직이 효율을 위해 통제하고 표준화하려는 시도를 설명함
    • 숲의 모든 나무를 한눈에 파악할 수 있도록 관리함으로써, 계획과 거래, 자원 분배 효율이 높아진다는 기대가 있었음
    • 실제로는 숲의 다양성과 하층식물의 역할이 간과되어 생산성이 저하되고, 질병과 기생충에 취약해짐
  • 즉, 효율과 투명성 모두를 노렸지만, 과도한 가독성 추구가 오히려 효율을 저해하는 결과가 발생함

소프트웨어 회사의 가독성과 비가독성

  • 소프트웨어 기업도 마찬가지로, 작은 팀이나 개인이 더 효율적일 수 있음
    • 단일 엔지니어가 혼자 일할 때 팀의 일원으로 일할 때보다 더 효율적일 수 있다는 것은 소프트웨어 엔지니어들 사이에서 거의 상식
    • 엔지니어 주도 작업은 위에서 지시된 작업보다 훨씬 빠르게 진행되는데, 이는 의미 있는 형태로 번역하거나 모든 방향으로 적극적으로 소통할 필요가 없기 때문
  • 소규모 소프트웨어 회사가 대기업보다 소프트웨어 제공에 훨씬 뛰어난 이유는, 대기업이 10배 많은 엔지니어를 투입해도 소규모 회사가 20배 더 효율적이면 문제가 되지 않기 때문
  • 대기업에서는 엔지니어의 작업을 “가독적”으로 만들기 위해 다양한 절차와 도구를 도입함
    • 이는 작업의 계획·측정·보고에는 유리하지만, 실제 소프트웨어 생산성은 떨어뜨릴 수 있음
  • 작은 회사는 즉시 문제에 대응하거나 변화를 빠르게 수용할 수 있음(비가독적인 능력)
  • 대기업이 이런 효율성 대신 복잡한 절차를 유지하는 이유는 대형 엔터프라이즈 계약과 관련 있음. 큰 고객들은 공급사에 예측 가능성과 신뢰성을 요구함
  • 이런 고객과 협업하려면, 장기 계획·기능 약속·진행상황 문서화 등 가독성이 필수임
  • 가독성이 제공하는 가치(달러 기준)가 소프트웨어를 더 효율적으로 생산하는 능력보다 더 크기 때문에 프로세스가 유지됨

대기업이 중시하는 가독성의 실질적 가치

  • 대규모 소프트웨어 회사에서 가독성이란
    • 개인 엔지니어까지 현재 진행 중인 모든 프로젝트를 파악할 수 있음
    • 지난 분기에 완수된 프로젝트 목록을 바로 산출할 수 있음
    • 최소 한 분기 단위(혹은 그 이상)로 미리 업무 계획이 가능함
    • 위급 상황 시 부서의 전체 리소스를 동원하여 즉각적인 업무에 투입할 수 있음
  • 작은 소프트웨어 회사는 즉시 유연하게 대응하는 능력 외에는 이런 요건을 거의 충족하지 못함
  • 대기업은 기록, 분류, 장기 계획에는 강점이 있지만, 신속한 대응력(즉각적 조직 자원 투입)은 오히려 약화될 수 있음
  • 이러한 가독성 확보는 주로 엔터프라이즈 고객과의 신뢰, 계약, 장기 협력 등에서 핵심적인 역할을 함

가독성 확보를 위한 가정 및 그 한계

  • 대기업은 가독성 추진 과정에서 다음과 같은 단순한 가정을 함
    • 동일한 직급의 모든 엔지니어가 대략 동일하게 수행한다고 가정
    • 엔지니어를 재배치하거나 재조직해도 생산성 손실이 없다고 가정
    • 팀의 엔지니어 수가 같으면 시간이 지나도 생산성 수준이 유지된다고 가정
    • 프로젝트를 사전에 추정 가능하며 오차 범위가 있다고 가정
  • 하지만 실제로는
    • 같은 직급에서도 실력 차이가 크며, 전문성과 관심사에 따라 프로젝트 생산성에 큰 차이가 생김
    • 팀 규모와 생산성은 약한 상관관계만 존재함
    • 프로젝트 산정은 거의 환상에 가깝고, 실제로는 산정 일정에 맞추기 위해 작업 방식이 바뀌기도 함
  • 그럼에도 불구하고, 이런 가정이 회사 내 의사소통, 외부 대기업과의 협약, 사업 계획엔 쓸모가 있음

임시로 허가된 비가독성 영역

  • 대기업에서 가독성을 만드는 프로세스는 심각한 지연을 초래
    • 제품 아이디어 → 제품 조직의 계획 단계 → 엔지니어링 조직의 기술 검토 → VP와 시니어 매니저의 팀 배정 협상 → 팀 계획 백로그 진입 → 팀 티켓 백로그 → 스프린트 진입 → 실제 작업 착수
  • 즉시 수행해야 하는 업무와는 전혀 호환되지 않는 구조
  • 이러한 문제를 해결하기 위해 "가상 팀", "타격 팀", "타이거 팀" 등의 임시 비가독적 영역을 허용
    • 조직이 신뢰하는 선별된 엔지니어들로 구성
    • 종종 관리자가 전혀 배정되지 않고 매우 시니어한 엔지니어가 프로젝트를 운영
    • 느슨한 임무를 부여받고 목표 달성을 위해 기본적으로 무엇이든 할 수 있도록 허용
  • 이는 완전한 비가독성과 완전한 가독성 사이의 현명한 타협
  • 공식 프로세스를 우회하지만, 상시로 운영되지 않고 임시로만 유지됨
  • 허가된 비가독성도 나머지 조직과 어색하게 공존하며, 다른 엔지니어들은 프로세스 부담 없이 일하는 자유를 보고 질투하거나 위험하다고 생각

영구적이고 비허가된 비가독성 영역

  • 팀 A의 엔지니어가 팀 B에 작업을 요청하는 공식적 방법은 "계획" 백로그에 이슈를 생성하고 12단계 프로세스를 거쳐 스프린트에 들어갈 때까지 기다리는 것인데, 이는 수주에서 수개월이 소요
  • 공식적 해결책은 팀 A가 계획 프로세스에서 팀 B의 작업을 예상해야 한다는 것인데, 코드를 작성하기 몇 달 전에 모든 변경 사항을 예상할 수 없다는 점에서 터무니없음
  • 실제 해결 방법은 비가독적 백채널
    • 팀 A의 엔지니어가 팀 B의 엔지니어에게 "이 한 줄 변경을 해줄 수 있나요?"라고 요청
    • 팀 B의 엔지니어가 즉시 수행하고 티켓 생성 여부는 선택적
    • 엔지니어 간 대인 관계에 의존하므로 비가독적
  • 백채널은 회사의 모든 수준에서 지속적으로 존재
    • 엔지니어 간 크로스팀 백채널, 팀 내부 백채널, 관리자 간, 제품 관리자 간
    • 공식 공간에서 질문이 제기될 때 이미 답변자와 사적으로 리허설되고 검토된 경우가 많음
  • 백채널은 잘못될 수 있으며, 때로는 순진한 엔지니어를 희생시켜 자신에게 이익을 주는 데 사용됨

소시오패스, 무지한 자, 패자

  • Venkatesh Rao의 "Gervais 원칙"은 조직을 세 그룹으로 나눔
    • 최상위의 "소시오패스" 는 자신의 이익을 위해 조직 규칙을 냉소적으로 사용
    • 중간 관리직의 "무지한 자(clueless)" 는 조직의 공식 규칙을 믿으며 그 위에서 더 깊은 게임이 진행되는지 인식하지 못함
    • 그 아래의 "패자(losers)" 는 게임이 진행되고 있음을 인식하지만 참여하고 싶어하지 않음
  • 이 범주들을 가독성 측면에서 읽을 수 있음
    • 소시오패스와 패자는 모두 조직의 비가독적 세계에 관여
    • "무지한 자"는 오직 가독적 프로세스에만 관여하며, 승진을 원할 때 공식 직무 사다리를 찾아보고 다음 레벨의 각 가치를 어떻게 구현할지 계획
  • 이들을 "무지한 자"라고 부르는 것은 지나치게 냉소적
    • 가독적 프로세스는 여전히 매우 중요하며 조직이 하는 일의 큰 부분
    • 공식 프로세스를 개선하는 것은 여전히 매우 높은 레버리지 작업
  • 이러한 범주로 사람들을 생각하면 소프트웨어 회사의 빈번한 갈등 영역이 이 그룹들 간의 마찰에서 비롯된다는 점을 이해하는 데 도움

최종 생각

  • 조직 내 비가독성 세계를 인식·활용하는 것이 중요함
  • 나는 기술 회사에서 비가독성을 인식하고 사용하는 것에 대해 많이 글을 썼음
  • 비가독적 프로세스에 대한 조언은 "위험한 조언" 에 해당
    • 공개적으로 공식 프로세스 대신 백채널을 통해 작업을 완료한다고 발표하면 조직에 의해 처벌을 받게 됨
    • 관리 체인이 그렇게 하기를 원했더라도 처벌
  • 공식 프로세스를 결코 우회해서는 안 된다는 부정적 피드백을 많이 받지만, 저자는 이러한 견해가 순진하다고 생각
  • 모든 조직은 가독적 측면과 비가독적 측면을 모두 가짐
    • 가독적 측면은 특정 규모 이상에서 중요하며, 장기 계획, 다른 대규모 조직과의 조정 등을 가능하게 함
    • 비가독적 측면도 똑같이 중요하며, 고효율 작업을 가능하게 하고, 현재 상황에 맞지 않는 프로세스를 위한 안전밸브를 제공하며, 가십과 부드러운 합의에 대한 자연스러운 인간의 욕구를 충족
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 대부분의 내용은 공감하지만 리더십이 자동적으로 'legibility'가 모든 비용을 지불할 만큼 가치 있다고 가정하는 점은 이의를 제기하고 싶음. 만약 CEO가 모든 세부 업무(예: 유닛테스트 병렬화 등)에 다 신경 써야 한다면 뇌가 손가락 하나 옮길 때마다 의식하는 것과 같아서 아무것도 못 하게 됨. 현실적으로 CEO, 즉 한 회사의 수장은 전체의 약 7% 정도만 통제 가능함. 나머지는 각 직원들이 채우며, 본인은 두뇌 역할일 뿐 전체 신체가 아님. 하지만 리더들은 자기가 제일 중요하다고 착각하기 쉽고, 시간이 부족하거나 전문성이 없는 분야(예: 뛰어난 MIT 출신 엔지니어와 부트캠프 출신 평균 엔지니어의 차이 등)는 대충 넘어감. 구글이 성공했다고 이야기할 때도 수십 명의 뛰어난 실무진보다 창업자 두 명이나 CEO에게만 공을 돌리는 경향 있음

    • "뇌가 숨 쉴 때마다 의식한다"는 예시는 다소 허수아비 논법이라고 생각함. 유능한 CEO라면 개발팀 내 유닛테스트 관리까지 직접 신경 쓸 필요 없다는 사실을 알 것임. 실제로 기업이 지향하는 legibility 수준은 훨씬 합리적인 범위임

  • 여기 내용 일부는 맞지만, 지나치게 극단적인 것 같지는 않음. 약 5000명 규모(작진 않지만 Amazon급은 아님) 회사에 다님. 대부분의 규칙은 꽤 괜찮은 이유가 있음. 예를 들어 코드 리뷰어 2명이 필요한 것도 실수 방지용임. 리뷰 거절이 많진 않지만 리뷰 없이 배포하면 장애가 더 자주 생길 것임. 이런 규칙은 억지로라도 체크하게 만들어줌. 물론 언젠가는 규칙을 깨야 할 상황(팀원 대다수가 장애로 급히 빠진 경우 등)이 올 수 있음. 그럴 땐 규칙의 취지에 맞춰 예외를 허용해야 타당함. 하지만 이해 못할 순수 관료적 규칙만 가득한 곳(누군가가 자기만의 프로세스 고집해서 '너 방식이 틀렸어'만 외치는 타입)은 떠나게 됨. 진짜 진행과 성과보다 프로세스나 개인의 자존심을 더 중시하는 환경에선 이직이 답임

  • TDD 이후 "테스트할 수 없으면 구현도 안 됐다"라는 유혹이 강해졌음. 이를 설명하는데 'legibility'라는 단어가 참 적절함. Tritium에는 수백 개의 유닛 테스트를 두었지만, 실제로 블로그를 만들면서야 유닛 테스트가 잡아내지 못한 질적 버그(테스트로는 확인하기 힘든)가 드러났음 https://tritium.legal/blog/eat 참고. 인디 게임 개발이 시장 논리에 잘 버티는 것도 이 때문인 듯. 게임 개발자는 자기 제품을 직접 사용하며(Food-dogging) 질적 개선을 이룸. 대기업 소프트웨어처럼 과도한 legibility 표면적이 필요 없음. 핵심은 질적·양적 지표 둘 다 필요하다는 점임

    • 테스트, 특히 유닛 테스트는 '가로등 효과'에 취약함. 사소하거나 덜 중요한 부분일수록 테스트가 쉽고, 그래서 쉬운 것만 테스트하게 됨. 조직이 line coverage 같은 측정 가능한 쉬운 지표에만 집착하면 진짜 의미 있는(어려운) 검증은 빠질 위험이 있음. 경험 많은 엔지니어의 리뷰 같은 정성적 평가도 중요함

    • 게임 개발은 다른 소프트웨어 분야보다 피드백 루프가 훨씬 짧음. 예를 들어 메모리 누수가 발생하면 매초 수백 번씩 바로 문제가 드러남. 느린 코드는 시각적 끊김으로 바로 체감되어서 캐시 일관성, GC 사용 여부 등 퍼포먼스 관점까지 신경 쓰게끔 만듦

    • TDD를 좋아하지만, 결국 수동 테스트도 꼭 필요함. 직접 테스트하지 않으면 예상 밖의 문제가 자주 생김. 특히 사용자 친화성 등은 실제 사용해봐야 잘 드러남

  • Sean의 글을 즐겨 보는데, 이번 글도 제품 영역 전반에 공감함. 예를 들어 1년 전쯤, 여러 제품 담당자와 엔지니어들이 타팀에도 도움이 될 만한 것을 만들려 했음. 공식적인 채널(legible channel)로 승인받기엔 당시 구조상 현실성이 떨어져서, 신뢰와 존중을 바탕으로 비공식(illeigible channel) 형태로 진행함. 풀뿌리(Grassroots)식으로 추진됐고, 오히려 빠르게 사내에서 입소문을 타고 traction을 얻게 됨. 결국 지금은 경영진이 이 사례를 자기들의 성공 스토리처럼 써먹고 있지만, 거꾸로 모든 공적 절차(legible channel)와 사후 근거 마련에 돌입하니 절차가 꽤 고통스러움. 하지만 실패 위험이 대폭 줄어들었으니 한결 수월한 편임. 최근 몇 년간 가장 보람 있고 재미있게 일했던 프로젝트임

  • 더 오랫동안 회사 생활, 사무 정치(office politics)에 노출될수록 지오폴리틱스(geopolitics)나 외교와 닮았단 생각이 듦. 더 나아가면 사회적 관계, 연애 관계와도 평행선을 볼 수 있음. 아마 추상적 모델 만들기를 좋아하는 수학자적 성향 때문임

    • 내가 가장 좋아하는 주제가 바로 정치임. 책, 잡지, 각종 자료를 즐겨보고, 솔직히 사내 정치도 크게 불편하지 않음. 핵심은 결국 인간이 인간답게 행동한다는 점임. 모든 개인(조직도 마찬가지)이 바라는 것(욕구)와 두려운 것(공포)을 가지며, 이를 균형 있게 맞추는 과정이 일종의 재미임. 꼭 공학 문제 푸는 것과 같지만, 요구사항이 '사람'이라는 점만 다름. 이런 문제를 푸는 과정 자체가 흥미로움

    • 최근에야 이런 걸 깨달았음. 처음엔 외교를 수백 명의 외교관이 만들어내는 복잡계의 결과로 봤는데, 사실상 몇몇 권력자가 얽힌 인간 관계일 뿐임. 어린이집에서 일어나는 일과도 비슷하게 접근할 수 있음

    • 이게 본능적으로 자연스러운 현상임. 사회적 관계(연애 등)보다는 대기업과 정부 간에 더 확실히 닮은 점이 많음. 기업들은 보통 훨씬 더 독재적(autocratic) 또는 봉건적(feudal)에 가까움. 차이점도 많지만, 규모가 커질수록 점점 정부와 비슷해지는 경향이 있음. 고도화된 관료제라는 부분도 그 중 하나임

    • 게임 이론 위키

    • 현대 정치인들 중 상당수가 일반 사무직에서 출발한 경우가 많아진 걸 보면 이런 현상이 이상할 것도 없음

  • 나는 IT 보안 쪽에서 일하는데, 여긴 이런 상황이 더 극명함. '우리 팀이 직접적인 지표에 도움이 안 되는 요청'을 받아야 할 때 공식적이지 않은 방법(back channel)이 아닌 대체 방안이 있을지 궁금함. 아시는 분 있으신지 궁금함

    • 팀 엔지니어를 상대 팀 원하는 업무나 로드맵 항목에 교환 투입하는 식으로, 서로 원하는 걸 맞교환할 수 있음

  • 좋은 글이지만 항상 다루지 않는 한 가지를 이야기하고 싶음. 본문은 소프트웨어 엔지니어(SWE)를 나무의 잎, 즉 조립 라인의 작업자 정도로만 그려서 아쉬움. 하지만 "Legible assumptions" 부분에도 나오듯, 실제로 엔지니어는 조직 구조에 '코드'로 연결을 확장하는 '관리자적 역할'도 함. 문제는 적용 대상만 다를 뿐, 서로 비슷한 고민을 겪게 됨

    • Senior Engineer처럼 IC 레벨을 올리려면 실제 관리자의 역할까지도 기대됨. 단순히 코드만 잘 짜서는 부족함. 프로젝트 관리, 아키텍트, 팀 리더, 설득가 역할까지 요구되고, 문서로 근거도 남겨야 함

  • 본문 중 "왜 작은 회사는 없어도 큰 소프트웨어 회사에는 이런 역량이 꼭 필요할까? 내 전문 분야는 아니지만 아마 대기업용 프로젝트 때문일 것" 부분에 동의하시는 분? 의견 요청함

    • 대기업 딜 때문이라기보단, 내부 '정보 흐름(communication at scale)' 때문이라고 생각함. m명의 직원을 가진 조직을 m*m 커뮤니케이션 행렬로 비유할 수 있음. 소수 인원일 땐 모든 칸이 거의 1(긴밀한 소통)이지만, 규모가 커질수록 0(단절), 0.5(비공식적 소통)가 대부분으로 바뀜. 하지만 정보는 결국 회사 자체임. 그래서 매니저와 공식 프로세스로 정보 '흐름'을 책임지는 구조가 필수적임. 기획, 프로모션, 검토 등이 다 이런 legibility를 확보하기 위함임

    • 작은 회사에서 대기업 프로젝트를 도맡지만, 내부까지 엄격한 legibility 요구하지 않아도 딜 성사 가능함. 고객 앞에선 프로젝트 관리의 legibility가 필요하지만, 내부 개발방식까지 세세하게 간섭하는 것은 아님. 결론적으로 큰 회사가 legibility에 집착하는 건, 그들이 이미 대기업이거나 대기업을 지향하기 때문임

    • 의료 영상 영역에서 오래 있었는데, 대다수 사업주는 자기가 IT 서비스/솔루션 업계에 있는 걸 제대로 이해 못 함. IT 서비스 역량이 실제 성공 요인이었음. 진단 자체보다 비(非)방사선 전문 인력들이 플랫폼의 사용성과 효율성을 높이려 노력한 부분이 훨씬 컸음

    • 아무리 큰 조직이어도 여러 번의 내부·외부 감사(audit)를 항상 대비해야 함. 감사인은 프로세스 문서를 되도록 많이 보려는 경향이 있음. 예를 들어 이 사례처럼, 최악의 경우 감사인이 고객을 '해고'하기도 함

    • 그 부분(대기업 딜 때문임)은 역시 다소 특이하게 느껴짐. 스타트업 출신이자 현재 중견기업 중간관리자로서, 조직 규모가 커질수록 직무 수행법을 알려주는 최소한의 구조는 늘 필요하다고 봄. 아무리 프로세스를 싫어해도 Dunbar’s Number 넘어가면 공감과 비공식 소통만으론 한계. 극단적인 예외가 Steam 정도인데, 거기도 특정 유형의 인재만 선별되고 내부 정치가 매우 심함

  • legibility 라는 단어 선택부터 흥미로움. 공식적·비공식적인 프로세스의 이분법처럼 느껴짐. 회사가 작을 때는 비공식적 방식이 잘 통하지만, 어느 임계점을 넘어서면 공식 규칙과 프로세스를 도입할 수밖에 없음. 장기적으론 규칙이 경직성과 변화를 못 따라가는 현상이 생김. 점점 목적보다 과정 자체에 집착하게 됨. 이렇게 루틴에서 벗어나 새로움을 유지하는 게 쉽지 않음. 회사에서 돈이 혈액 같다고 말하곤 하지만, 실제로 돈이 동기부여의 근본인 경우는 적음. 돈은 필요조건이긴 해도, 존재 이유 그 자체는 아니라고 봄

  • 항상 균형 이슈임. 25년 동안 엔지니어링 매니저였고, 강력한 프로세스 중심 회사에서 일했음. 답답했지만, 세계 수준의 하드웨어를 꾸준히 만들어낸 데에는 장점도 있었음(소프트웨어는 아님). 문서화 등은 꼭 필요하지만, 지나치게 엄격하면 프로젝트가 굳어질 위험이 있음. 커뮤니케이션 오버헤드가 가장 심각한 문제임. 그래서 소수의 유능한 팀이 함께 오래 일하면 엄청난 생산성을 내는 것이고, '트라이벌 노하우(tribal knowledge)'도 실제로 매우 중요한 촉진제임. Concrete Galoshes란 글을 쓴 것도 이런 구조적·경직성 요소를 다루고자 함. 최고 교훈은 "모든 프로젝트에 같은 옷을 입히면 안 된다"임. 프로젝트별로 다양한 구조·오버헤드가 필요함

    • 커뮤니케이션 오버헤드가 진짜 문제임. 팀원을 늘리면 팀 내 커뮤니케이션 요구가 기하급수적으로 늘고, 조직 전체 팀 수가 많아져도 마찬가지임. 극도로 효율적인 팀이 되는 비결은 신뢰와 이해임. 시간이 지나면서 각자의 강점·약점을 서로 파악하고, 팀원 간 신뢰를 쌓음. 이렇게 축적된 '트라이벌 노하우'는 문서화, 멘토링, 발표 등으로 잘 전수되는 게 이상적임
답변달기