핵심 인사이트 (3줄 요약)
- 본질: LeSS (Large-Scale Scrum)는 2~8개의 복수 애자일 팀이 단일 제품 (Product)을 개발할 때, SAFe처럼 관료제적 계층을 덧붙이지 않고 원래 스크럼 (Scrum)의 본질을 그대로 뻥튀기(Scaling)하여 적용하는 가장 미니멀한 대규모 애자일 프레임워크다.
- 가치: "규칙과 역할을 더 추가하지 마라(Do Less)"는 철학에 따라, 오직 1명의 진짜 제품 책임자 (PO), 1개의 제품 백로그, 1개의 공통 스프린트라는 '완벽한 단일화(1-1-1 구조)'를 강제하여 조직의 복잡성을 타파한다.
- 판단 포인트: 여러 팀이 스프린트 계획 회의(Sprint Planning)를 할 때 대표자만 모여 거시적 일감을 배분하는 1부와, 팀별로 흩어져 작업 단위(Task)를 쪼개고 타 팀과 즉석 의존성을 푸는 2부로 영리하게 분업시켜 시장통의 혼란을 막았다.
Ⅰ. 개요 및 필요성
LeSS (Large-Scale Scrum)는 "조직이 커질수록 룰은 더 단순해져야(LeSS) 애자일의 민첩성이 살아난다"는 크레이그 라만 (Craig Larman)의 철학에서 출발한 대규모 스크럼 프레임워크다.
대기업들은 규모가 커지면 자꾸 중간 관리자(PMO)를 두고 포트폴리오 관리 같은 무거운 결재 라인을 만든다(SAFe 방식). 하지만 이러한 관료주의는 결국 빠른 적응이라는 애자일의 본질을 죽인다. 만약 8개의 스크럼 팀이 각자의 PO (제품 책임자)를 두고, 각자의 백로그(일감 리스트)를 들고 각기 다른 날짜에 스프린트를 시작한다면, 거대한 하나의 제품(예: 은행 앱)의 통일성은 산산조각이 나버린다. LeSS는 기존 10페이지짜리 스크럼 가이드 룰을 최대한 유지하면서 오직 '참여하는 팀의 개수'만 늘릴 수 있도록 최소한의 안전장치만 부여하여 이 혼돈을 막아낸다.
- 📢 섹션 요약 비유: 8명이 노를 젓는 조정 경기에서, 배가 커졌다고 사공을 이중 삼중으로 늘려 감시하게 하는 게 아니라, 뱃머리에 오직 1명의 진짜 선장을 앉히고 모두가 똑같은 구령에 맞춰 한 몸처럼 노를 젓게 만드는 최소한의 단순화 전략이다.
Ⅱ. 아키텍처 및 핵심 원리
LeSS의 뼈대는 철저하고 완벽한 단일화 구조인 '1-1-1 아키텍처'에 있다. 수백 명의 개발자가 팀으로 찢어져 일하더라도 제품은 무조건 하나여야 한다.
- 단 하나의 제품 책임자 (One Product Owner, PO)
- 8개 팀에 8명의 가짜 PO(Proxy PO)를 두는 것을 엄격히 금지한다.
- 전체 팀을 통틀어 오직 1명의 진짜 PO만이 전체 제품의 비전과 투자 수익률(ROI), 일감의 최상위 우선순위를 결정한다.
- 단 하나의 제품 백로그 (One Product Backlog)
- 팀별로 To-Do 리스트를 따로 관리하지 않는다. 8개 팀 전체가 쳐다보는 거대한 마스터 '제품 백로그'는 오직 1개뿐이다.
- 스프린트가 시작할 때, 모든 팀이 이 하나의 게시판 앞에 모여 자기가 이번 2주 동안 소화할 일감을 각자의 스프린트 백로그 (Sprint Backlog)로 가져간다.
- 단 하나의 공통 스프린트 (One Sprint)
- 팀마다 시작 날짜를 중구난방으로 운영하지 않는다. 1초의 오차도 없이 8개 팀이 동시에 스프린트 출발 총성을 듣는다.
- 끝나면 다 같이 멈추고 하나의 거대한 '통합된 제품 증가분 (Increment)'을 함께 시연하고 검토(리뷰)한다.
┌──────────────────────────────────────────────────────────────┐
│ LeSS 의 완벽한 1-1-1 단일화 아키텍처 구조 │
├──────────────────────────────────────────────────────────────┤
│ [ 1 Product Owner (PO) ] │
│ │ (전체 우선순위 결정) │
│ ▼ │
│ [ 1 Product Backlog (마스터) ] │
│ │ (일감을 팀별로 배분) │
│ ┌───────────────┼───────────────┐ │
│ ▼ ▼ ▼ │
│ [Team 1 Backlog] [Team 2 Backlog] [Team 8 Backlog] │
│ │ │ │ │
│ └───────────────┼───────────────┘ │
│ ▼ │
│ [ 1 Common Sprint ] │
│ (모든 팀이 동시에 시작하고 종료) │
│ │ │
│ ▼ │
│ [ 1 Integrated Increment ] │
│ (통합된 단 하나의 거대한 제품 완성) │
└──────────────────────────────────────────────────────────────┘
이 다이어그램은 각 팀이 물리적으로 찢어져 코드를 짜더라도, 지시를 내리는 뇌(PO)와 통합되어 나오는 결과물(Increment)은 철저하게 한 몸처럼 맞물려 돌아가는 LeSS의 이상적인 뼈대를 보여준다.
- 📢 섹션 요약 비유: LeSS는 8개의 팔을 가진 거대한 문어 1마리다. 머리와 심장이 따로 있는 10마리 물고기를 그물로 묶어 끌고 가는 SAFe와 달리, 뇌(1명의 PO)와 위장(1개의 백로그)은 오직 1개로 유지한 채, 8개의 다리가 일사불란하게 움직여 하나의 사냥감을 잡는 단일 유기체 시스템이다.
Ⅲ. 비교 및 연결
대규모 애자일 도입을 고민할 때 실무에서 가장 크게 부딪히는 두 진영이 바로 LeSS와 SAFe다.
| 비교 기준 | LeSS (Large-Scale Scrum) | SAFe (Scaled Agile Framework) |
|---|---|---|
| 철학과 방향성 | 룰을 최소화하여 민첩성 극대화 (미니멀리즘) | 기존 엔터프라이즈 구조 포용을 위한 계층 추가 |
| 적용 규모의 한계 | 2~8개 팀 (약 50~100명 내외) 최적 | 수백~수천 명의 거대 조직도 가능 |
| PO (제품 책임자) | 수개 팀을 1명의 진짜 PO가 통제 | 팀별 PO와 그 위를 덮는 PM, Epic Owner 등 계층화 |
| 스프린트 계획 구조 | 단일 백로그를 기반으로 대표자 분업 기반 회의 | PI (Program Increment) Planning이라는 거대 기차 탑승 |
조직이 유연한 스크럼 문화를 이미 뼛속까지 이해하고 있다면 LeSS가 압도적인 속도를 내지만, 기존 대기업의 계층과 예산 승인 절차를 무시하기 어렵다면 관리의 안정감을 주는 SAFe를 선택할 수밖에 없다. LeSS는 개발자 중심적이고 본질 지향적인 반면 도입의 허들이 높다.
- 📢 섹션 요약 비유: LeSS는 기존의 동네 축구단(스크럼)이 프로 리그에 나가기 위해 군더더기 장비 없이 원래 팀워크만 죽어라 훈련시키는 방식이고, SAFe는 축구단 위에 단장, 전력분석관, 감독관 등 새로운 관리 부서를 세워 대기업 구단으로 탈바꿈시키는 방식이다.
Ⅳ. 실무 적용 및 기술사 판단
수십 명이 한 방에서 백로그를 나누면 시장통이 된다. LeSS는 이 스프린트 계획 회의(Sprint Planning)를 2단계 분업으로 영리하게 쪼개어 병목을 뚫는다.
- 스프린트 플래닝 1부 (거시적 분배): 8개 팀의 '대표자(대사)' 1~2명씩만 PO와 만난다. PO가 "이번 주엔 이 20개 기능을 쳐냅시다" 하면, 각 팀 대표들이 "우린 1번, 2번", "우린 3번" 하며 큼직한 일감을 굵직하게 팀으로 가져온다. 수백 명이 동시에 논쟁하는 오버헤드를 원천 차단한다.
- 스프린트 플래닝 2부 (미시적 쪼개기): 대표가 자기 팀원(개발자 7명)들에게 돌아와 텐트를 친다. 방금 받아온 일감을 어떻게 코딩 태스크(Task)로 분배할지 디테일하게 작전을 짠다. 이때 옆 텐트에서 연관된 코드를 짜는 타 팀과 즉석에서 대화하며 크로스 팀 의존성을 현장에서 바로 풀어버린다.
기술사 판단 (도입 주의사항 및 안티패턴)
- 가짜 PO (Proxy PO) 안티패턴: PO 1명이 8개 팀을 상대하려니 벅차서, 비공식적인 팀장이나 분석가를 가짜 PO로 세운다. 이 순간 1-1-1 구조는 무너지고 각자 다른 방향으로 배가 산으로 간다.
- 독립된 컴포넌트 팀 구성 안티패턴: 팀 1은 DB만, 팀 2는 프론트엔드만 짜는 식의 기능 중심 조직은 LeSS에서 악몽이다. 한 기능(스토리)을 완성하기 위해 두 팀이 끝나기를 무한정 기다려야 하므로, 반드시 모든 팀을 End-to-End 개발이 가능한 피처 팀 (Feature Team)으로 구성해야 한다.
- 📢 섹션 요약 비유: 1부는 부족의 추장들만 모여 "우리는 사슴을 잡고, 너희는 멧돼지를 잡자"고 큰 사냥감을 결정하는 회의고, 2부는 각 부족의 사냥꾼들이 모여 "내가 창을 들게, 넌 그물을 던져"라며 실제 사냥 전술을 짜고 다른 부족과 협력하는 현장 작전 회의다.
Ⅴ. 기대효과 및 결론
LeSS는 대규모 애자일 환경에서 흔히 겪는 조직의 팽창과 관료화, 의사결정의 지연(Bottleneck) 문제를 "복잡성을 더하지 않는다"는 단 하나의 대원칙으로 정면 돌파한다.
오직 1명의 PO와 1개의 백로그를 향한 정렬은 거대 프로젝트가 방향을 잃지 않게 만드는 최고의 나침반이다. 비록 기존 관리 계층을 축소해야 하기에 경영진의 반발이 심하고 팀 간 자발적 조율이 고도화되어야 한다는 한계 전제조건이 있지만, 이 험난한 도입 문턱을 넘고 나면 조직 전체가 하나의 거대한 스타트업처럼 움직이는 기적을 맛볼 수 있다. "More with LeSS" — 더 큰 성과는 더 적은 규칙에서 나옴을 기억해야 한다.
- 📢 섹션 요약 비유: 여행 가방을 쌀 때 "혹시 모르니"하며 온갖 물건(새로운 룰, 관리자)을 쑤셔 넣으면 결국 가방이 무거워 지친다. LeSS는 꼭 필요한 티셔츠와 여권(1명의 PO, 1개의 백로그)만 챙겨 몸을 가볍게 만들고 민첩하게 뛰쳐나가는 실전 배낭여행의 지혜다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| SAFe (Scaled Agile Framework) | LeSS와 쌍벽을 이루는 경쟁 체제, 철저하게 상위 계층과 포트폴리오를 관리하려 드는 무거운 엔터프라이즈 애자일 |
| 가짜 PO (Proxy Product Owner) | LeSS가 가장 혐오하는 직책. PO의 권한을 대리하려는 순간 방향성이 쪼개지는 치명적 안티패턴 |
| 피처 팀 (Feature Team) | UI부터 DB까지 기능의 처음과 끝을 혼자 다 짤 수 있는 독립적 팀. LeSS가 원활히 작동하기 위한 필수 전제조건 |
| 스프린트 백로그 (Sprint Backlog) | 공통 마스터 백로그에서 떼어와 2주 동안 우리 팀이 박살 내기로 약속한 현장 태스크 리스트 |
📈 관련 키워드 및 발전 흐름도
단일 애자일 (Scrum 1개 팀, 10명 내외)
│
▼
대형 프로젝트 확장 요구 (50명 이상) 및 팀 간 의존성 문제 발생
│
▼
대규모 확장 체제 분기: 관료적 통제 강화 (SAFe) vs 룰 단순화 극대화 (LeSS)
│
▼
1-1-1 구조 확립 (1 PO, 1 Backlog, 1 Sprint)
│
▼
스프린트 계획 1부/2부 분업 체계 (Sprint Planning 1 & 2) 및 동기화 구현
이 흐름도는 스크럼 팀이 규모를 키워야 할 때 통제를 늘릴 것인가 룰을 깎아낼 것인가의 기로에서 미니멀리즘으로 뻗어나간 LeSS의 방향성을 보여준다.
👶 어린이를 위한 3줄 비유 설명
- 친구들 50명이 다 같이 하나의 커다란 레고 성을 만들려면, 조장이 여러 명이면 싸움만 나고 성이 이상해져요 (복잡성 폭발).
- LeSS는 50명 중에 딱 1명만 설계도(백로그)를 들고 대장(PO) 역할을 하게 만들어서 헷갈림을 없애는 완벽한 규칙이에요.
- 그리고 대장이 큰 덩어리를 나눠주면, 작은 팀들끼리는 알아서 오순도순 상의하며 끼워 맞추기 때문에 멋진 성이 순식간에 완성된답니다!