💡 핵심 인사이트
대규모 애자일(Scaled Agile)은 10명 이하의 소규모 팀 단위에서 기적을 일으킨 '스크럼(Scrum)'의 마법을, 수백~수천 명의 개발자가 협업하는 거대한 엔터프라이즈(대기업) 환경으로 확장(Scaling) 적용하기 위해 고안된 거시적 조직 관리 프레임워크입니다.

Ⅰ. 단일 스크럼의 한계와 대규모 확장의 벽

기본 스크럼(Scrum) 가이드는 개발팀 인원을 9명 이하로 제한합니다. (아마존 피자 두 판의 법칙). 이 소규모 팀 안에서는 매일 15분 스탠드업 회의(데일리 스크럼)만 해도 의사소통이 완벽합니다.

문제의 발생: 국민은행의 차세대 뱅킹 시스템을 1,000명의 개발자가 만든다고 칩시다. 이들을 100개의 스크럼 팀으로 쪼갰습니다.

  • A팀은 '로그인'을, B팀은 '장바구니'를 2주마다 기가 막히게 애자일로 개발해 냅니다.
  • 하지만 배포 날, A팀의 코드와 B팀의 코드를 합치려니 아키텍처가 완전히 달라서 시스템이 터져버립니다.
  • 각 팀은 애자일로 달리는데, 100개 팀 전체의 뱡향을 맞추는 거대한 조타수(의존성 관리자)가 없기 때문에 배가 산으로 갑니다.

이 "여러 스크럼 팀 간의 거대한 충돌과 의존성"을 통제하기 위해 등장한 것이 **대규모 애자일(Scaling Agile)**입니다.

Ⅱ. 대규모 애자일의 핵심 철학 (정렬과 동기화)

모든 대규모 애자일 방법론이 공통적으로 풀고자 하는 숙제는 두 가지입니다.

  1. 정렬 (Alignment)
    • 100개의 스크럼 팀(포드, 보트)이 각자 노를 젓는 게 아니라, 회장님이 가리키는 **거대한 비즈니스 로드맵(북극성)**을 향해 모두가 같은 방향으로 노를 젓게끔 비전을 정렬시킵니다.
    • 이를 위해 전사적 차원의 초대형 '포트폴리오 백로그'를 만들고, 이를 잘게 쪼개서 각 팀에게 뿌려줍니다.
  2. 동기화 (Synchronization) 및 의존성 해결
    • 100개 팀의 스프린트 시작일과 종료일(Cadence)을 무조건 똑같이 맞춥니다. (심장 박동 동기화).
    • "우리 팀 API가 완성되어야 너희 팀 결제가 돌아가잖아?" 이런 치명적인 병목(의존성)을 스프린트 시작 전에 수백 명의 리더들이 모여 거대한 실타래 풀듯 미리 협의(PI Planning)하고 개발에 들어갑니다.

Ⅲ. 대규모 애자일을 대표하는 3대 프레임워크 (다음 장 예고)

기업의 덩치와 문화에 따라 다음의 3가지 프레임워크 중 하나를 골라 씁니다.

  1. SAFe (Scaled Agile Framework): 가장 널리 쓰이며, 대기업 임원진부터 말단 개발자까지 수직적인 통제와 거대한 열차(ART) 메타포를 사용하는 무겁고 완벽한 관료제적 애자일.
  2. LeSS (Large-Scale Scrum): "규칙을 더 만들지 마라!" 스크럼의 기본 본질을 그대로 유지한 채 팀의 개수만 2~8개로 부풀리는 가장 가볍고 미니멀한 확장법.
  3. Nexus (넥서스): 스크럼의 창시자(켄 슈와버)가 직접 만든 3~9개 팀 대상의 확장판으로, 각 팀의 에이스들만 모아 만든 '넥서스 통합팀(NIT)'이 코드 충돌을 중간에서 막아내는 구조.

📢 섹션 요약 비유: 소규모 스크럼이 동네 축구 5인조 팀의 완벽한 **'눈빛 패스 워크'**라면, 대규모 애자일은 5인조 팀 100개가 모여서 하나의 거대한 매스 게임(올림픽 개막식)을 벌일 때 서로 발이 꼬여 넘어지지 않도록 **수백 명의 스텝을 1초의 오차 없이 맞추는 '초대형 군무 지휘 매뉴얼'**입니다.