SAFe

Scaled Agile Framework; 대규모 애자일 프레임워크, 세이프
여러 애자일 팀이 하나의 큰 제품이나 시스템을 함께 만들 때 팀 위에 프로그램·포트폴리오 수준의 공통 리듬과 역할을 얹어 정렬과 협업을 맞추는 프레임워크

스크럼이나 칸반은 대체로 10명 안팎의 한 팀을 전제로 한다. 수십, 수백 명이 한 제품을 만드는 대기업이나 정부 시스템에서는 팀 사이 의존성, 공통 아키텍처, 예산 배분, 규제 준수를 조율할 장치가 따로 필요하다. SAFe는 Scaled Agile, Inc.가 만들고 관리하는 프레임워크로, 린(Lean)·애자일·데브옵스 원칙을 팀, 애자일 릴리스 트레인(ART), 포트폴리오 수준으로 확장한다. 창시자는 딘 레핑웰(Dean Leffingwell)이다.

공식 사이트(framework.scaledagile.com)는 SAFe를 린·애자일·데브옵스로 비즈니스 민첩성을 얻기 위한 원칙·실무·역량의 지식 체계라고 설명한다. 이 지식 체계는 리더십과 문화, 팀과 기술 민첩성, 제품 개발 흐름, 대규모 솔루션 통합과 전달, 린 포트폴리오 관리의 다섯 분야(discipline)로 구성된다. 프레임워크는 번호 판 단위가 아니라 매월 갱신되는 방식으로 바뀌었고, 사이트에는 'SAFe 6.0' 구성(Essential, Large Solution, Portfolio, Full)이 함께 제공된다. 2026년에는 기존 체계를 'Core SAFe'로, AI 활용 운영 모델을 'AI-Native SAFe'로 나누어 제시하고 있다. CISSP 출제 기준 8.1은 개발 방법론의 예로 SAFe를 명시한다.

구성 수준

수준	구성	하는 일
팀	애자일 팀(SAFe Scrum, SAFe Kanban)	짧은 반복(이터레이션)으로 스토리를 구현·검증한다.
애자일 릴리스 트레인(ART)	여러 애자일 팀의 팀. 공식 설명으로는 보통 50~125명	공통 비전과 로드맵에 맞춰 하나 이상의 솔루션을 정의·구축·검증·출시하고, 필요하면 운영까지 맡는 교차 기능 조직이다.
대규모 솔루션	여러 ART와 공급업체를 묶는 솔루션 트레인	항공·국방·의료기기처럼 매우 큰 시스템을 조율한다.
포트폴리오	린 포트폴리오 관리(LPM)	전략과 투자 우선순위, 가치 흐름 단위 예산, 대형 이니셔티브(에픽)를 관리한다.

SAFe 6.0 구성은 이 수준을 조합한 것이다. Essential SAFe는 팀과 ART만, Large Solution SAFe는 솔루션 트레인까지, Portfolio SAFe는 포트폴리오까지, Full SAFe는 전부를 포함한다.

계획 주기: PI와 PI 계획

PI(Planning Interval): ART가 가치를 전달하는 일정 길이의 기간이다. 공식 설명으로는 8~12주이고, 보통 4~5개의 개발 이터레이션과 1개의 혁신·계획(IP, Innovation and Planning) 이터레이션으로 이루어진다. 예전 판에서는 같은 약어를 Program Increment의 뜻으로 썼던 것으로 알려져 있어 오래된 자료에는 그 이름이 남아 있다.
PI 계획(PI Planning): PI마다 ART 전체가 모여 다음 PI의 계획을 세우는 행사이다. 보통 이틀 동안 열리며, 팀별 PI 목표를 약속하고 팀 간 의존성을 ART 계획판에 드러낸다. 릴리스 트레인 엔지니어가 진행한다.
이 행사는 비즈니스 맥락과 아키텍처 방향을 모든 팀이 같은 자리에서 듣는 기회이므로, 보안 요구사항과 규제 일정도 여기서 공유해야 팀 백로그에 반영된다.

주요 역할

역할	설명
릴리스 트레인 엔지니어(RTE, Release Train Engineer)	ART의 서번트 리더이자 코치이다. ART 행사와 절차를 진행하고, 장애물 제거와 위험 관리, 이해관계자 소통을 돕는다. 팀 수준의 스크럼 마스터를 ART 수준으로 키운 역할로 볼 수 있다.
제품 관리(Product Management)	ART 수준 백로그(기능, feature)의 우선순위를 정하고 비전과 로드맵을 책임진다.
시스템 아키텍트(System Architect)	ART의 기술 방향과 아키텍처 런웨이를 책임진다. 보안 아키텍처 결정과 가장 밀접한 역할이다.
비즈니스 오너(Business Owners)	비즈니스 성과와 투자 수익에 책임을 지는 관리자들로, PI 목표의 가치를 평가한다.
시스템 팀, 공유 서비스	통합 환경과 파이프라인을 지원하거나(시스템 팀), 보안·데이터베이스·UX처럼 여러 팀이 나눠 쓰는 전문가(공유 서비스)이다.

보안 통합 방법

SAFe에서 보안은 별도 단계가 아니라 백로그 항목과 품질 기준으로 들어간다.

방법	SAFe 개념	보안 적용 예
비기능 요구사항(NFR)	시스템 품질 속성으로, 여러 백로그에 걸친 제약이 되고 이터레이션·PI·릴리스의 완료 정의(DoD)에서 반복 확인된다. 공식 설명은 보안을 대표적 NFR로 든다.	"모든 외부 API는 인증과 속도 제한을 갖춘다", "개인정보는 저장 시 암호화한다"를 NFR로 두고 모든 기능에 적용
인에이블러(Enabler)	아키텍처 런웨이를 넓히거나 개발 가치 흐름을 개선하는 백로그 항목. 탐색, 아키텍처, 인프라, 컴플라이언스의 네 범주가 있다.	중앙 인증 서비스 구축(아키텍처), 파이프라인에 SAST 추가(인프라), 감사 증적 자동화(컴플라이언스)
완료 정의(DoD)	각 수준에서 '끝났다'고 말하기 위한 기준	보안 검사 통과, 위협 모델 갱신, 취약점 기준 충족을 DoD에 포함
지속적 전달 파이프라인	SAFe의 데브옵스 실무	데브섹옵스 방식의 자동 보안 검사
공유 서비스	여러 팀이 나눠 쓰는 전문 인력	보안 아키텍트·보안 엔지니어가 PI 계획에 참여하고 필요한 팀에 배치

핵심은 보안 작업을 '보이는 백로그 항목'으로 만들어 우선순위 경쟁에 정식으로 참여시키는 것이다. 인에이블러로 올리지 않은 보안 작업은 기능 개발에 밀려 계속 미뤄진다.

비판과 한계

무거움: 역할, 행사, 산출물이 많아 애자일 선언의 '프로세스와 도구보다 개인과 상호작용' 정신과 멀어진다는 비판이 실무계에서 꾸준히 나온다.
위로부터의 계획: PI 단위 약속이 길어지면 사실상 짧은 폭포수 계획처럼 운영되어 변화 대응력이 떨어질 수 있다.
형식적 도입: 이름과 역할만 바꾸고 기존 관리 방식을 유지하면 비용만 늘고 민첩성은 생기지 않는다.
상업 프레임워크: 교육·인증 생태계가 한 회사 중심이다. 대안으로 LeSS, Nexus, 스포티파이 모델 같은 다른 확장 방식도 거론된다.

보안 관점에서는 SAFe 자체가 보안을 보장하지 않는다는 점이 중요하다. NFR·인에이블러·DoD에 보안을 넣는 조직의 결정이 있어야 한다.

시험 포인트

SAFe는 여러 애자일 팀을 대규모로 조율하는 프레임워크이다. 단일 팀 방법론(스크럼)과 구분한다.
ART는 '팀들의 팀'이고 PI 계획은 ART 전체가 함께 하는 정렬 행사이다. 보안 요구는 PI 계획에서 공유해야 반영된다.
보안은 비기능 요구사항과 인에이블러(특히 컴플라이언스·아키텍처 인에이블러)로 백로그에 넣는다. "보안은 마지막 하드닝 스프린트에서 처리한다"는 흔한 오답이다.
어떤 개발 방법론이든 CISSP의 관점은 같다. 보안은 수명 주기 처음부터 통합하고, 경영진의 지원과 정책이 먼저이다.

같이 보기

참고 문헌

About SAFe – Scaled Agile, Inc.
Agile Release Train – Scaled Agile, Inc.
PI Planning – Scaled Agile, Inc.
Nonfunctional Requirements – Scaled Agile, Inc.
Enablers – Scaled Agile, Inc.