SAFe

Scaled Agile Framework

방법

팀의 주기 위에 큰 주기와 투자 결정 층을 더 얹어 여러 팀을 하나의 계획으로 묶는 확장 체계입니다.

등장 배경

스크럼은 한 팀을 상정하고 만든 규칙입니다. 대여섯에서 아홉 명이 한 목록을 보고 2주짜리 주기를 돌리는 구조라, 그 안에서는 서로 무엇을 하는지 매일 확인할 수 있습니다.

팀이 여덟 개로 늘면 규칙이 닿지 않는 공간이 생깁니다. 결제 팀이 일을 끝내려면 인증 팀이 먼저 무언가를 바꿔 줘야 하는데, 두 팀은 각자 자기 목록만 보고 자기 주기를 돕니다. 결제 팀은 2주를 기다리고, 그 사실은 각 팀 회고에 다른 팀 때문에 막혔다는 한 줄로만 남습니다. 팀 안에서는 해결할 수 없는 문제입니다.

위쪽에서도 다른 문제가 나옵니다. 경영진이 6개월 뒤에 무엇이 나오느냐고 물을 때, 팀 여덟 개의 2주 계획을 모아도 그 답이 만들어지지 않습니다. 규제를 받는 산업이라면 이 질문에 답하지 못하는 것 자체가 문제가 됩니다.

SAFe는 이 두 빈칸을 층을 세워 메웁니다. 팀의 2주 주기 위에 8주에서 12주짜리 큰 주기를 하나 얹고, 그 위에 회사 전체의 투자 결정을 다루는 층을 또 둡니다. 층마다 계획 회의와 책임자와 산출물이 이름까지 규정돼 있어서, 여러 확장 체계 가운데 가장 무겁고 가장 자세합니다.

사용 절차

함께 한 제품을 내는 팀들을 하나의 큰 주기에 묶고, 주기를 시작할 때 전원이 모여 서로의 의존 관계를 맞춥니다.

  1. 팀을 묶습니다. 같은 제품이나 같은 가치 흐름에 속한 팀 다섯에서 열둘을 한 묶음으로 세웁니다. 사람으로는 50명에서 125명입니다. 이 묶음이 같은 날짜에 함께 내보내는 단위가 되고, 그 운영 방식을 릴리스 트레인이라 부릅니다.
  2. 큰 주기의 길이를 정합니다. 보통 8주에서 12주이고 그 안에 2주짜리 스프린트가 넷에서 여섯 개 들어갑니다. 마지막 주기는 새 기능을 담지 않고 통합과 개선에 씁니다.
  3. 큰 주기를 시작할 때 계획 회의를 엽니다. 이틀 동안 전원이 한자리에 모여 팀마다 이번 주기의 목표를 세우고, 다른 팀에 넘겨야 할 것과 받아야 할 것을 벽에 붙여 맞춥니다. 붙이고 나면 어느 팀이 어느 팀을 언제 기다리는지가 한 장에 드러납니다. 그 자리에서 해결되지 않는 것은 위험으로 따로 적어 담당을 정합니다.
  4. 주기를 돕니다. 팀 안쪽은 평소 스크럼대로 돌아갑니다. 2주마다 팀 대표들이 모여 붙여 둔 의존 관계가 실제로 지켜지고 있는지 확인합니다.
  5. 큰 주기를 닫습니다. 묶음 전체가 만든 것을 한자리에서 보여 주고 묶음 단위의 회고를 엽니다. 여기서 나온 것이 다음 큰 주기 계획으로 들어갑니다.
  6. 위층에서 무엇에 사람과 돈을 붙일지 정합니다. 이 층은 분기나 반기 단위로 움직이고, 어느 묶음을 키우고 어느 묶음을 접을지가 여기서 결정됩니다.

적합한 상황과 한계

맞는 자리는 넷입니다. 한 제품에 팀이 다섯 개 이상 붙어 있고 팀끼리 넘겨야 할 것이 많은 경우, 감사 기록을 남겨야 하는 규제 산업, 바깥에 6개월 일정을 약속해야 하는 조직, 그리고 조달이나 하드웨어처럼 앞뒤 일정이 고정된 일이 섞인 경우입니다.

한계는 넷입니다.

  1. 무겁습니다. 계획 회의 이틀에 100명이 들어가면 200인일이 계획에만 들어갑니다. 그만큼을 들일 이유가 있는 조직에서만 값을 합니다.
  2. 배우는 데 시간이 듭니다. 층마다 역할과 산출물의 이름이 따로 있어서 용어를 익히는 것부터 일입니다.
  3. 층이 늘면 결정이 위로 올라갑니다. 팀이 정할 수 있는 범위가 좁아지고, 심하면 애자일이라는 이름을 쓰면서 실제로는 위에서 내려온 계획을 순서대로 실행하는 상태가 됩니다. 이 체계를 두고 가장 자주 나오는 비판이 이 자리입니다.
  4. 굳어진 계획이 바뀌기 어렵습니다. 8주에서 12주치를 벽에 붙여 두었으니 5주째에 방향을 바꾸려면 여덟 팀의 약속을 다시 맞춰야 합니다.

규모가 그만큼이 아니라면 더 가벼운 쪽이 있습니다. 팀이 셋넷이면 대표끼리 모이는 스크럼 오브 스크럼으로 시작하고, 합치는 과정이 문제라면 넥서스를, 규정집을 얇게 두고 싶으면 LeSS를 봅니다.

실무 용례

"팀이 여덟 개라 조율 회의만으로는 안 돼요. 큰 주기를 한 겹 두는 걸 검토합시다."

팀 사이 의존이 회의 하나로 감당되지 않는다는 판단입니다.

"계획 회의에 이틀 200인일이 들어갑니다. 그만큼 값을 하는지 먼저 보죠."

도입 비용을 숫자로 올려놓고 판단하려는 말입니다.

"이건 이름만 애자일이고 위에서 내려온 계획을 순서대로 하는 거예요."

층이 늘어 결정이 위로 올라간 상태를 지적하는 말입니다.

페이지덱에서는 이 체계를 쓰지 않습니다. 구성원이 45명이고 제품 팀이 둘뿐이어서, 두 팀 사이의 의존은 주간 회의 한 번으로 정리됩니다. 규원이 지난해에 한 번 검토했다가 접었습니다.

접은 이유도 기록에 남겼습니다. 벽에 붙일 의존 관계가 대여섯 개에 그쳤고, 그 정도는 지현과 태오가 30분 통화로 맞추는 양이었습니다. 대신 팀이 넷을 넘어가면 다시 보기로 조건을 적어 두었습니다.

흔한 오해

애자일의 상위 버전이라고 보는 경우가 가장 많습니다. 이름에 확장이 들어 있고 층이 더 많으니 발전한 형태처럼 읽힙니다. 하지만 이 체계가 다루는 것은 성숙도가 아니라 규모입니다. 팀 하나가 스크럼을 잘 돌리고 있다면 다음 단계는 이것이 아닙니다. 팀 둘이 이 체계를 도입하면 회의와 문서만 늘고 바뀌는 것이 없습니다. 고를 기준은 우리가 얼마나 잘하는지가 아니라 팀이 몇 개이고 팀 사이에 넘겨야 할 것이 몇 개인지입니다.

도입하면 애자일해진다고 보는 것도 흔합니다. 문서와 교육 과정이 잘 갖춰져 있어서 따라 하기만 하면 될 것처럼 보입니다. 다만 옮겨 오기 쉬운 것은 회의 이름과 문서 양식이고, 옮기기 어려운 것은 결정 권한입니다. 팀이 무엇을 만들지 스스로 정하지 못하는 상태에서 계획 회의만 도입하면, 이틀을 들여 위에서 내려온 목록을 벽에 붙이는 행사가 됩니다. 도입 전에 확인할 것은 규정집을 지킬 수 있는지가 아니라 팀에 무엇을 맡길 것인지입니다.

자주 헷갈리는 용어

용어무엇을 더하는가SAFe와의 차이
LeSS거의 더하지 않고 빼는 쪽입니다제품 책임자와 목록과 주기를 하나로 두고 팀만 여럿 둡니다. 새 층과 새 역할을 만들지 않아 규정집이 얇고, 그만큼 위에 설명할 산출물도 적습니다
스포티파이 모델회의가 아니라 조직도를 다시 그립니다스쿼드와 챕터로 사람을 묶어 자율에 기댑니다. 정해진 주기와 계획 회의가 없어서, 층을 세워 일정을 맞추는 SAFe와 답하는 방식이 반대입니다

같이 보면 좋은 페이지

  • 스케일링 프레임워크

    여섯 체계가 무엇을 얼마나 손대는지로 줄 세워지는 모습을 봅니다

  • LeSS

    같은 문제에 가장 다르게 답한 쪽이어서 둘을 나란히 읽으면 선택 기준이 잡힙니다

마지막 업데이트 2026-09-16