백서

DevSecOps の
성숙도 모델
조직의 DevSecOps 관행을 평가하고
발전시키기 위한 청사진 .

datadog.com
DevSecOps 성숙도 모델 2

목차 요약 3

1
리더가 답해야 할 DevSecOps 관련 핵심 질문 세 가지 に関 する 4

2
DevSecOps 성숙도 모델 6

3
DevSecOps 여정을 위한 나침반 11

4
DevSecOps 의 비즈니스 가치 14

5
시작하기 16

저자 16

Datadog 소개 17

부록 : 세부 성숙도 모델 18

datadog.com
DevSecOps 성숙도 모델 3

요약 고품질의 안전한 디지털 서비스를 빠르고 효율적으로 시장에 공급하기 위해

DevSecOps 관행을 발전시키는 것은 많은 조직의 과제입니다 . 이를 위해 리더는
스스로 다음 세 가지 핵심 질문을 던져야 합니다 .

– 조직의 DevSecOps 성숙도는 현재 어느 수준인가 ?

– 조직이 추구하는 DevSecOps 성숙도는 어떤 수준인가 ?

– 해당 수준에 어떻게 도달할 수 있는가 ?

본 백서는 기술 리더들이 위 세 가지 질문에 답하고 , 조직이 시장에서 경쟁우위를

점하기 위해 사용할 수 있는 DevSecOps 성숙도 모델을 소개합니다 .

마지막 부분에서는 리더가 DevSecOps 이니셔티브의 비즈니스 가치를 입증하는 데

사용할 수 있는 지표에 대해 논의합니다 .

datadog.com
DevSecOps 성숙도 모델 4

1 조직이 시장에서 경쟁하고 혁신하기 위해 빠른 속도와 높은 품질로 DevSecOps 를

수행하는 것은 필수적입니다 . 그러나 DevSecOps 가 전략적으로 필수적임을 많은
리더가 답해야 할 리더들이 인정함에도 불구하고 , 많은 조직이 DevSecOps 를 시작하고 발전시키는 데
DevSecOps 관련 어려움을 겪습니다 . DevSecOps 를 개선하기 위해서 기술 리더는 다음 세 가지 핵심
핵심 질문 세 가지問 질문에 스스로 답해봐야 합니다 .

1. 조직의 DevSecOps 성숙도는 현재 어느 수준인가 ?

2. 조직이 추구하는 DevSecOps 성숙도는 어떤 수준인가 ?

3. 해당 수준에 어떻게 도달할 수 있는가 ?

첫 번째 질문에 답하기 위해서는 현재 DevSecOps 역량 수준을 솔직하게

평가해보아야 합니다 . 두 번째 질문에 답하기 위해서는 조직이 처한
환경에서 ‘바람직한’ 비즈니스 상황이 무엇인지 정의해보아야 합니다 .
마지막 질문은 조직의 현 수준과 원하는 수준 사이의 간극을 줄이기 위한
이니셔티브를 식별하는 것입니다 .

기술 리더가 이 세 가지 핵심 질문에 답하려면 성숙도 모델이

필요합니다 .

소프트웨어 개발 전문가인 Martin Fowler 는 성숙도 모델을 다음과 같이 정의합니다 .

“성숙도 모델은 개인이나 그룹의 효율성을 현 시점에서 평가하고 성과 향상을

위해 강화해야하는 역량을 파악할 수 있도록 돕는 도구입니다 .” 1

성숙도 모델은 특정 영역에 대한 규범적 관점을 제시하고 해당 영역에서의 발전을

위한 가장 효율적이고 효과적인 방법을 아래와 같이 제안합니다 .

전문가

고급
추구하는�목적지

중급
1차적�목적지

초급
현재�위치
1
https://martinfowler.com/bliki/MaturityModel.html

datadog.com
DevSecOps 성숙도 모델 5

방법
당사의 기술 지원팀은 고객과의 긴밀한 협력을 통해 조직의 DevSecOps 관련 혁신을
지원합니다 . 또한 DevOps( 이제는 DevSecOps) 관행 개선과 관련하여 14,000 개
이상의 회사를 지원해오면서 10 년 이상 축적된 경험을 보유하고 있습니다 . 이
과정에서 다양한 수준의 DevSecOps 성숙도를 접할 수 있었고 , 각 회사마다의 발전
경로를 관찰했습니다 . 당사는 이러한 고객 경험을 바탕으로 효율적인 발전 경로를
추려낸 다음 모든 조직의 성공을 위해 DevSecOps 성숙도 모델을 고안했습니다 .

DevOps 와 DevSecOps 의 차이
DevOps 는 개 발 팀 (Dev) 과 운 영 팀 (Ops) 간 의 공 동 작 업 과 공 동 책 임 을
장려함으로써 소프트웨어 작성 및 실행 속도와 품질을 개선할 목적으로 10 여 년 전에
처음 등장했습니다 . 많은 조직이 여전히 DevOps 여정을 진행 중이며 , 그 속도와
성공의 정도는 천차만별입니다 .

DevOps 팀 의 발 전 속 도 가 빨 라 짐 에 따 라 다 음 과 같 은 두 가 지 어 려 움 이
대두되었습니다 . (1) DevOps 팀의 주요 관심사는 보안이 아닌 소프트웨어의 기능
및 성능적 특성이기 때문에 보안 문제는 간과되며 , (2) 보안팀이 ( 갈수록 빠르게
발전하는 ) DevOps 팀과는 동떨어진 채 여전히 별개의 툴 , 문화 및 프로세스를
사용하는 사일로에 남아있기 때문에 보안은 병목 현상을 낳거나 무시됩니다 .

문제는 DevOps 의 라이프사이클을 둔화시키는 이러한 어려움이 지금처럼 보안

자체의 중요성이 증가하는 시기에 발생하고 있다는 점입니다 . 조직은 다양한
공격자로부터의 지속적인 위협에 노출되어 있습니다 . 갈수록 많은 비즈니스가 디지털
채널을 통해 수행되고 조직의 공격 표면이 넓어짐에 따라 , 기술 및 비즈니스 위험도
그만큼 증가하고 있습니다 .

datadog.com
DevSecOps 성숙도 모델 6

DEVSECOPS 는 DEVOPS 라이프사이클 전반을 아우르는 다양한 층위의 보안

컨트롤 , 툴 및 관행으로 구성됩니다 .

전 전한

보
스

안
모 협

�스
위

�평

송
델

캔
가
SEC

배
발
코 전한

보 치
안
리

패
개

계
안
딩

릴
획
DEV OPS
코 안
드
보

빌
로

영
서

감 안
드
의

보
운

사
트
스
SA

사 지털
ST

디
인

링
보 석

모 안
터
안
분

보
니
DA

트
ST

펜
스
테

이러한 발전 양상은 보안이 DevOps 라이프사이클에 더 근본적으로 통합되어야

함을 시사합니다 . 따라서 DevSecOps 는 DevOps 운동의 진화 과정에서 논리적인
다음 단계에 해당합니다 . 기업은 보안팀 및 보안 관행을 DevOps 워크플로우에
통합함으로써 제공 속도를 더욱 가속화하고 , 소프트웨어 품질을 높이며 , 프로덕션
환경에서의 서비스의 안정성을 개선할 수 있습니다 . DevOps 운동의 잠재력을
최대치로 실현하려면 보안팀과 DevOps 팀 사이의 사일로를 무너뜨리는 작업이
반드시 필요합니다 . DevSecOps 는 DevOps 에서 벗어난 것이 아니라 DevOps 의
다음 진화 단계입니다 .

2 DevSecOps 성숙도 모델은 6 가지 주요 역량 영역에서 성숙도를 4 단계로 구분합니다 .

전체 성숙도 모델을 제안하기에 앞서 각각의 단계와 역량 영역에 대한 설명을 아래와
DevSecOps 성숙도 같이 요약해 보겠습니다 .
모델
발전 단계

DevSecOps 성숙도는 4 가지 주요 단계로 구분됩니다 . 이 단계들은 수천 개의 다양한

조직에서 관찰된 패턴을 기반으로 정립되었습니다 . 여기서 중요한 점은 , 앞서갈 수
있는 지름길이나 레벨을 ‘건너뛰는’ 방법은 없다는 것입니다 . 성숙도 모델 안에서
DevSecOps 는 하나의 여정을 이룹니다 .

datadog.com
DevSecOps 성숙도 모델 7

– 초 급 : 이 단 계 는 DevSecOps 여 정 의 시 작 을 나 타 냅 니 다 . 공 유 와 협 업 을
강조하는 문화와 사고방식의 변화를 기술 분야 전반에서 이루어내는 것과 하나의
팀으로서 성과를 개선하려는 열망을 공유하는 것이 무엇보다 중요합니다 . 이것이
DevSecOps 의 토대입니다 .

– 중급 : 이 단계에서 조직은 지속적으로 소프트웨어를 출시하지만 , 병목 현상 , 성능

문제 및 팀 간의 마찰이 발생할 수 있습니다 . 보안 컨트롤이 개발 프로세스 초기로
옮겨지고 있지만 , 보안 관련 작업의 대부분은 여전히 프로세스의 마지막 단계에서
수행되므로 릴리즈 주기의 둔화와 코드 품질 저하의 원인이 됩니다 .

– 고급 : 이 단계에서 조직은 매우 효율적이고 생산적이며 , 고품질의 안전한

소프트웨어를 안정적인 플랫폼에 정기적으로 릴리즈합니다 . 소프트웨어 개발
라이프사이클 전반에 걸쳐 보안 체크포인트가 설정되어 있습니다 .

– 전문가 : 최첨단 조직이 이러한 DevSecOps 관행을 사용합니다 . 이러한 조직은

고품질의 코드를 하루에도 여러 번 릴리즈합니다 . SDLC 전체에 보안 컨트롤이
근본적으로 포함되어 있으며 , 보안은 더 이상 사일로에 머무르지 않습니다 . 이
성숙도 단계의 주요 특징은 개발 , 운영 및 보안 전반에 걸쳐 매우 높은 수준의
프로세스 자동화가 이루어졌다는 것입니다 .

역량 요소
DevSecOps 성숙도 모델에서 다루는 6 가지 핵심 역량은 다음과 같습니다 .

– 사람과 문화 : 이 역량은 DevSecOps 의 토대를 이룹니다 . 이 영역에는 조직 구조 ,

커뮤니케이션 스타일 , 가치 , 인센티브 , 행동 , 리더십 , 개인 및 팀의 건전성이
포함됩니다 .

나머지 5 가지 역량은 엔드 투 엔드 DevSecOps 라이프사이클의 주요 단계들에 매핑이

가능합니다 . 이러한 역량 영역들은 프로세스와 기술이 결합된 것입니다 .

– 계획 및 개발 : 이 역량 영역은 작업 우선순위의 지정 방식 , 계획된 작업과 계획되지

않은 작업 간의 비율 , 신규 기능 개발 투자와 기술 부채 상환 간의 비율 , 그리고 개발
프로세스의 가장 초기 단계에서 얼마나 많은 리스크 평가와 코드 검증이 수행되는지
등을 포괄합니다 .

– 빌드 및 테스트 : 이 영역은 테스트 프로세스 및 자동화 , 품질보증 , 코드 스캔 기술 ,

그리고 빌드 및 서명 검증을 다룹니다 .

– 릴리즈 및 배포 : 이 역량은 배포 전략 및 릴리즈 빈도 , 배포 프로세스 자동화 , 그리고

배포 관련 문제의 검증 및 수정에 중점을 둡니다 .

datadog.com
DevSecOps 성숙도 모델 8

– 운영 : 이 영역은 코드로서의 인프라 , 용량 계획 , 확장성 및 안정성 , 카오스 테스트

및 레드팀 활동 , 패치 및 재해 복구를 다룹니다 .

– 관 찰 및 대 응 : 이 역 량 은 서 비 스 수 준 목 표 (Service Level Objectives, SLO),

취약점 및 구성 오류 스캔 , 보안 모니터링 , 사용자 경험 모니터링 , 침해 사고 관리 및
사후 분석에 중점을 둡니다 .

모델ル
아래 매트릭스에서 6 가지 역량 영역 각각은 몇 가지 개별 역량을 포함하며 , 그 중
최소 2 개는 보안 관련 역량에 해당합니다 . 각 역량은 4 단계의 성숙도 수준 , 즉 초급 ,
중급 , 고급 및 전문가로 구분됩니다 .

( 참고 : 이 문서의 부록에는 아래 매트릭스의 각 셀에 대한 세부적 추가 정보가

수록되어 있습니다 .)

datadog.com
DevSecOps 성숙도 모델 9

역량 초급 중급 고급 전문가

사람과 문화 – 기능팀들의 사일로화 – 사일로 해체 – 팀 간의 지속적인 – 제품 및 서비스에

– 팀 간 높은 수준의 – 실험 및 투명성을 협업 맞게 조정된 교차
마찰 수용 – 탓하지 않는 문화 기능팀

– 초창기 온보딩 – 온보딩 프로세스 진행 – 포괄적인 온보딩 – 높은 신뢰 , 실험 ,

프로세스 프로세스 학습의 문화
– 번아웃이 공개적으로
– 빈번한 번아웃 논의됨 – 번아웃이 빠르게 – 드문 번아웃
해결됨

계획 및 개발 – 리스크와 보안이 – 제한적 리스크 평가 – 위협 모델링 및 – 광범위한 위협

고려되지 않음 – 보통 수준의 기술 리스크 평가 모델링 / 리스크 평가
– 높은 수준의 기술 부채 – 낮은 수준의 기술 – 최소한의 기술 부채
부채 – 보통 수준의 버그 부채 – 신규 기능에 집중
– 과도한 버그 수정 작업 – 약간의 버그 수정 – 전면 자동화된 코드
– 수정 작업 – 일부 코드의 검증 작업 검증
– 코드가 – 모든 코드의 검증

– 검증되지 않음

빌드 및 테스트 – 수동 테스트 – 부분적 테스트 자동화 – 높은 수준의 테스트 – 완벽한 테스트 자동화
– 코드 스캔 없음 – 일부 코드의 스캔 자동화 – 포괄적 동적 코드
– 빌드 / 서명 검증 없음 – 부분적 빌드 / 서명 – 동적 코드 스캔 스캔

– 제한적 핵심 기능 검증 – 본격적 빌드 / 서명 – 포괄적 빌드 / 서명

테스트 – 부분적 핵심 기능 검증 검증
테스트 – 본격적 핵심 기능 – 포괄적 핵심 기능
테스트 테스트

릴리즈 및 배포 – 수동 배포 – 부분적 배포 자동화 – 높은 수준의 배포 – 완전한 배포 자동화

– 간헐적인 대규모 – 월 단위의 중간 규모 자동화 – 매일 수차례의 릴리즈
릴리즈 릴리즈 – 주 단위의 소규모 – 배포 실패 처리의
– 배포 보안 태세 기준 – 기본적 배포 보안 릴리즈 자동화
없음 태세 기준 – 세부적 배포 보안 – 신속한 포워드 수정
– 실패한 배포의 수정이 – 허용 가능한 수준의 태세 기준 방식을 선호
어려움 배포 실패 수정 시간 – 짧은 배포 실패 수정
시간

datadog.com
DevSecOps 성숙도 모델 10

역량 초급 중급 고급 전문가

운영 – 수동 프로비저닝 / – 부분적 구성 / – 광범위한 구성 / – 모든 인프라 구성

구성 프로비저닝 자동화 프로비저닝 자동화 및 지침이 코드로서
– 긴 용량 계획 주기 – OpEx 기반의 용량 – 계절 / 성장에 따른 인스턴스화됨

– 수동 확장 계획 용량 계획 – 세분화된 사용량
– 부분적 자동 확장 – 본격적 자동 확장 동향 / 예측을
– 단일 가용성 영역 기반으로 한 용량
– 카오스 테스트 또는 – 다중 가용 영역 / 지역 – 멀티 클라우드 계획
레드팀 활동 없음 – 기본적 카오스 테스트 공급자 / 고가용성
– 포괄적 자동 확장
– 열악한 패치 위생 또는 레드팀 활동 – 본격적 카오스 테스트
및 레드팀 활동 – 멀티 클라우드
– 재해 복구 전략 없음 – 기본적 패치 위생 공급자 / 최고 수준의
– 기본적 DR 전략 – 신속한 패치 가용성
– 포괄적 DR 전략 – 지속적 카오스 테스트
및 레드팀 활동
– SLA 패치
– DR 계획의 주기적
테스트

관찰 및 대응 – SLO 없음 – 기본적 SLO – SLO 및 오류 예산 – SLO 및 오류 예산이

– 취약점 / 구성 오류 – 부분적 취약점 / 구성 확보됨 관련 결정을 주도함
스캔 없음 오류 스캔 – 본격적 취약점 / 구성 – 광범위한 취약점 /
– 보안 메트릭 미정의 – 일부 보안 메트릭이 오류 스캔 구성 오류 스캔

– 사일로화된 정의 및 표시됨 – 대부분의 서비스에서 – 100% 의 서비스에서

텔레메트리 – 일부 관찰가능성 공통 보안 메트릭이 정의 보안 메트릭이 정의
데이터 세트 및 표시됨 및 표시됨
– 사용자 여정 미정의
– 사용자 경험에 대한 – 관찰가능성 공통 – 표준화된 메타데이터
– 과도한 MTTD 및 데이터 플랫폼 모델
MTTR 기본적 이해
– 약간 높은 MTTD 및 – 세부적 사용자 여정 – 완전한 사용자 여정
– 사후 분석 없음 가시성 가시성
MTTR
– 기본적 사후 분석 – 약간 낮은 MTTD 및 – 매우 낮은 MTTD 및
MTTR MTTR
– 세부적 사후 분석 – 명확하고 건설적인
사후 분석

datadog.com
DevSecOps 성숙도 모델 11

3 기술 리더에게 던지는 세 가지 핵심 질문 ( 우리 조직은 어디에 있는가 ? 우리가

추구하는 목적지는 어디인가 ? 거기에 도달하는 방법은 무엇인가 ?) 으로 돌아가서 ,
DevSecOps 여정에 성숙도 모델을 이러한 질문에 한 번 적용해 보겠습니다 .
미치는 영향
조직의 DevSecOps 성숙도는 현재 어느 수준인가 ?
DevSecOps 성숙도 평가評価
기술 리더는 DevSecOps 성숙도 곡선에서 조직의 현 위치를 정확하게 파악해야
합니다 . 당사는 이를 위해 DevSecOps 성숙도 모델에 기반한 온라인 자체 평가 도구를
개발했습니다 . 평가 문항은 총 36 개이며 , 약 10 분 이 소요됩니다 .

이 평가 도구는 정확한 진단용이 아니며 , 조직의 DevSecOps 성숙도와 개선이 필요한

영역을 대략적으로 알아볼 수 있도록 고안된 것입니다 . 평가 결과는 종합적 성숙도
점수로 표시됩니다 .

조직마다 역량 영역에 따라 성숙도 수준이 다양할 수 있기 때문에 , 아래와 같이

레이더 / 스파이더 차트에 성숙도 수준을 나타내보면 유용합니다

1 단계 : 조직의 현재 성숙도를 평가

역량별�성숙도
문화

관찰�및�대응 계획�및�개발

종합적�성숙도

전문가 운영 빌드�및�테스트
고급

중급

초급
릴리스�및�배포

리더는 평가 결과를 바탕으로 개선 및 투자의 여지가 있는 부분을 한눈에 파악할 수

있습니다 .

datadog.com
DevSecOps 성숙도 모델 12

조직이 추구하는 DevSecOps 성숙도는 어떤 수준인가 ? 매트릭스에서

오른쪽으로 이동하기
리더가 조직의 DevSecOps 관행이 어떤 위치에 있는지 파악했다면 , 다음 단계는
관련 산업 및 비즈니스 목표를 감안하여 ‘바람직한’ 상황이 어떤 모습인지 판단하는
것입니다 . 성숙도 모델의 가장 오른쪽에 있는 단계는 오늘날 기업 환경에서 동급
최고의 DevSecOps 관행이 어떤 모습인지 보여줍니다 .

DevSecOps 성숙도는 업계에 따라 다르다는 점에 유의해야 합니다 . 어떤 업계에서는

‘중급’ 등급으로도 경쟁력이 확보된 경우더라도 , 다른 업계에서는 뒤쳐질 수 있습니다 .

아래에 도움이 되는 예시가 있습니다 . 어떤 가상의 조직의 성숙도를 모든 역량에 걸쳐

나타낸 다음 , 향후 12~18 개월 내에 도달할 합리적인 목표를 표시했습니다 .

2 단계 : 조직이 추구하는 성숙도 단계를 정의る

초급 중급 고급 전문가

문화

계획 및 개발

빌드 및 테스트

릴리즈 및 배포

운영

관찰 및 대응

종합적 성숙도

조직의 현재 위치 조직의 목적지

발 전 은 점 진 적 으 로 일 어 납 니 다 . 12 개 월 이 라 는 시 간 동 안 종 합 적 성 숙 도 를 한
단계라도 끌어올렸다면 이는 대단한 일입니다 . 수행해야 할 작업량에 따라 , 리더는
중간 목표들로 채워진 장기적 계획을 세워야 할 수도 있습니다 .

최신의 DevSecOps 방식이 지속적으로 진화 및 발전하고 있다는 사실을 명심하는

것도 중요합니다 . 어떤 해에는 ‘고급’ 등급이었던 것이 다음 해에는 ‘중급’ 등급이 될 수
있습니다 . 따라서 두 성숙도 모델 모두에서 최신 상태를 유지하는 한편 가장 최근의
모델을 사용하여 조직을 지속적으로 재평가하는 것이 중요합니다 .

datadog.com
DevSecOps 성숙도 모델 13

해당 수준에 도달할 수 있는 방법은 ? 한 번에 한 칸씩 .

DevSecOps 는 사람 , 프로세스 및 기술에 걸쳐 수많은 관행들을 아우르는 하나의

세트이므로 , 각각의 역량은 다른 역량을 강화해줍니다 . 따라서 한 가지 영역에서
성숙도가 낮은 조직은 가장 저조한 해당 영역이 개선될 때까지는 종합적 발전을
빠르게 진행할 수 없게 됩니다 . 보다 발전된 성숙도 단계를 위한 강력한 기반을
구축하려면 먼저 성숙도가 낮은 영역에 우선순위를 두는 것이 좋습니다 .

성숙도 모델의 셀은 리더가 다음 단계로 나아가기 위해 택할 수 있는 점진적 진행

지점을 보여줍니다 .

3 단계 : 이니셔티브와 투자의 우선순위를 지정하고 각 역량 영역과 개별 역량에 대한

소유자를 지명함으로써 어떻게 목표에 도달할 것인지 결정

초급 중급 고급 전문가

문화 2 분기 소유자 3 분기

계획 및 개발 1 분기 소유자 2 분기

빌드 및 테스트 2 분기 소유자

릴리즈 및 배포 2 분기 소유자 3 분기

운영 1 분기 소유자 2 분기

관찰 및 대응 1 분기 소유자 2 분기

종합적 성숙도 3 분기

조직의 현재 위치 목적지 도달 방법 조직의 목적지

각각의 역량 범주와 구체적인 개별 역량 영역은 그 자체로서도 커다란 주제입니다 . 리더가

먼저 특정 역량 영역을 소유한 직속 직원을 임명한 후 해당 담당자가 구체적 역량 ( 예 :
테스트 자동화 ) 을 소유한 팀원들을 모집하는 것을 권장합니다 .

datadog.com
DevSecOps 성숙도 모델 14

4 DevSecOps 는 팀을 더욱 생산적이고 협력적이고 대응 능력이 뛰어나게 만듦으로써

고품질의 안전한 소프트웨어를 더욱 빠르게 안정적인 프로덕션 환경에 딜리버리할
DevSecOps 의 수 있도록 합니다 . 이는 실질적인 비즈니스 가치로 전환될 수 있습니다 . 하나씩
비즈니스 가치 살펴보겠습니다

네 가지 주요 가치 동인
성숙도 모델에 기반한 DevSecOps 관행을 채택한 조직은 다음 네 가지 주요 동인을
통해 비즈니스 가치를 실현합니다 .

1. 더 빠 르 고 민 첩 한 딜 리 버 리 와 출 시 기 간 단 축 : DevSecOps 는 조 직 이
애플리케이션을 시장에 더 빨리 출시하고 수익을 좌우하는 애플리케이션의 릴리즈
주기를 단축함으로써 수익을 보호하고 증대할 수 있도록 해줍니다 . DevOps
워크플로우에 보안을 통합함으로써 잠재적인 병목 현상을 제거하고 , 조직의
효율성과 민첩성을 가속합니다 .

2. 보안 태세 개선 및 리스크 감소 : DevSecOps 는 보안 이해관계자와 보안 관행을

소프트웨어 개발 라이프사이클의 모든 단계와 프로덕션 서비스 운영 과정에
통합합니다 . 개발 (Dev), 보안 (Sec), 운영 (Ops) 팀 간의 협업 , 신뢰성 및 투명성이
향상되면 소프트웨어 관련 리스크가 줄어듭니다 .

3. 운영 및 개발 비용 절감 : DevSecOps 관행의 빠른 피드백 루프는 소프트웨어 개발

라이프사이클을 간소화해주며 , 프로덕션 환경으로 넘어가기 이전 단계에서부터
문제의 대부분을 해소해줍니다 . 발생하는 사고는 매우 빠르게 해결됩니다 .

4. 향상된 고객 경험 및 만족도 : DevSecOps 는 품질이 더 높고 안전한 소프트웨어의

생산함으로써 조직이 고객에게 제공할 수 있는 가치를 증가시킵니다 . 또한 서비스
개선과 업그레이드가 더욱 자주 이루어질 수록 고객은 제품을 높게 평가합니다 .
무엇보다도 , 조직이 최종 사용자의 관점에서 시스템을 관찰하고 엔드 투 엔드 고객
여정에 대한 가시성을 확보할 수 있게 되므로 고객 만족도 역시 향상됩니다 .

datadog.com
DevSecOps 성숙도 모델 15

메트릭 비용 고객 수익

더 빠르고 민첩한 릴리즈 주기 결함을 식별 , 재현 고객 / 시장 점유율 신규

딜리버리와 출시 기간 및 문서화하는 데 고객으로부터의
출시 기간 고객 만족도
단축 필요한 품질관리 수익
개발 및 품질보증 시간 고객의 지갑점유율
지갑점유율 증가로
환경에서 식별된
개발자 대기 시간 인한 수익
문제
출시 기간 단축으로
인한 수익
신제품으로부터의
수익
가격 개편으로 인한
수익

보안 태세 개선 및 MTTD/MTTR 엔지니어의 사고 고객 만족도 가동중단으로 인한

리스크 감소 해결 소요 시간 수익 손실
사고에 관여한 FTE 고객의 지갑점유율
기술 지원 센터 비용 이탈 고객 감소로
고객 불만 전화 고객 이탈
인한 수익
성능 저하 또는 보안
사고 / 가동중단
사고에 따른 재정적 높은 지갑점유율로
손실 인한 수익

운영 및 개발 비용 절감 릴리즈 주기 엔지니어의 사고
해결 소요 시간
개발 및 품질보증
환경에서 식별된 결함을 식별 , 재현
문제 및 문서화하는 데
필요한 품질관리
사고 / 가동중단
시간
개발자 대기 시간
인프라 오버
프로비저닝

향상된 고객 경험 및 고객 만족도 기술 지원 센터 비용 고객 만족도 이탈 고객 감소로

만족도 인한 수익
고객의 지갑점유율
높은 지갑점유율로
고객 이탈
인한 수익

datadog.com
DevSecOps 성숙도 모델 16

DevSecOps 비즈니스 가치 메트릭クス

조직의 DevSecOps 성숙도가 높아질수록 이러한 각 동인에서 파생되는 비즈니스
가치도 증가하게 됩니다 . 위의 표는 각 동인과 관련한 생산성 메트릭 , 고객 메트릭 ,
비용 및 수익 측면에서의 비즈니스 가치를 보다 자세히 다룹니다 .

기 술 리 더 는 위 의 메 트 릭 을 사 용 하 여 조 직 의 DevSecOps 여 정 을 측 정 할 수
있으며 , 해당 메트릭을 반드시 측정해야 합니다 . 이러한 메트릭은 조직 전체의 진행
현황을 파악하고 성숙도 곡선을 따라 나아가는 데 필요한 투자를 정당화기 위해 꼭
필요합니다 .

5 DevSecOps 성숙도 모델은 DevSecOps 를 발전시키고자 하는 수천 개의 고객사와

협력하는 동안 발견한 패턴에 기반하고 있습니다 . 이는 실제 고객사들에게 검증
시작하기 받았으며 현재 조직이 어느 단계에 있고 , 어느 방향으로 가야하며 어떻게 목표에
도달할 수 있는지의 세 가지 핵심 질문에 답하기 위한 도구로서 활용되고 있습니다 .

조 직 의 DevSecOps 여 정 에 첫 발 을 내 딛 을 수 있 도 록 약 10 분 이 소 요 되 는
DevSecOps 자체 평가 도구 를 사용해 테스트해 볼 것을 권해드립니다 .

저자 기술 커뮤니티 및 오픈소스 부문 이사 , 제레미 가르시아 (Jeremy Garcia)

기술 에반젤리스트 , 앤드류 크룩 (Andrew Krug)

기술 서비스 부문 부사장 , 파힘 가파르 (Fahim Ghaffar)

수석 솔루션 엔지니어 , 보얀 시야로프 (Boyan Syarov)

기술 지원 부문 이사 , 크리스티 파시온 (Christy Pasion)

선임 테크니컬 어카운트 매니저 , 지콴 먀오 (Ziquan Miao)

datadog.com
DevSecOps 성숙도 모델 17

Datadog 소개 Datadog 은 클라우드 애플리케이션을 위한 모니터링 및 보안 플랫폼입니다 . 당사의

SaaS 플랫폼은 인프라 모니터링 , 애플리케이션 성능 모니터링 및 로그 관리 업무를
통합하고 자동화하여 고객의 전체 기술 스택을 아우르는 통합적인 실시간 가시성을
제공합니다 .. 광범위한 산업군의 수많은크고 작은 조직들이 Datadog 을 이용하여
디지털 트랜스포메이션 및 클라우드 마이그레이션을 진행하고 , 개발 , 운영 , 보안 및
비즈니스 팀 간의 협업을 강화하며 , 애플리케이션 출시 속도를 가속화하고 , 문제 해결
시간을 단축하는 한편 애플리케이션 및 인프라를 보호하고 , 사용자 행동을 이해하며 ,
주요 비즈니스 지표를 추적하고 있습니다 .

더 많은 정보는 datadoghq.com 을 방문하십시오 .

datadog.com
DevSecOps 성숙도 모델 18

부록 :
세부 성숙도 모델

datadog.com
DevSecOps 성숙도 모델 19

1. 문화

역량 초급 중급 고급 전문가

커뮤니케이션 개별 팀이 사일로 되어 Dev 및 Ops 팀간의 보안 이해관계자는 운영 , 개발 및 보안

있음 . 커뮤니케이션은 Dev 및 Ops 팀과 분야 전반에 걸친
이루어지나 보안은 정기적으로 정보를 정기적인 커뮤니케이션
사일로에 머물며 , 공유하지만 , Dev 및 및 정보 공유 . 팀원들이
팀원들이 보안 관련 Ops 팀 간의 공유 보안 관련 우려 사항을
우려 사항을 보고할 빈도에는 못 미침 . 보고할 대상이 누구인지
대상이 없음 . 알고 있음 .

온보딩 표준화된 온보딩 온보딩 프로세스가 온보딩 완료 시 포괄적인 온보딩

프로세스가 없음 . 존재하지만 , 완료 엔지니어의 생산성이 프로세스를 통해
시에도 엔지니어의 보장됨 . 엔지니어의 생산성을
생산성이 보장되지 보장하고 램프업 시간을
않으며 램프업 시간이 단축시킴 .
오래 걸림 .

책임성 두려움 , 신뢰 부족 , 실험에 대한 두려움 , 탓하지 않는 문화와 투명하고 , 탓하지 않고 ,

비난 , ‘남탓 ' 문화 . 약간의 투명성 , 뒤에서 빈번한 실험 . 서로 신뢰하고 , 배우는
‘남탓 ' 문화 . 문화와 실험 .

팀 건전성 팀원이 번아웃에 대해 팀원이 번아웃에 대해 팀원이 번아웃에 대해 번아웃이 드물지만

논의할 수 없고 완화 공개적으로 논의하지만 논의할 수 있고 완화 공개적으로 논의되고
조치를 취할 권한이 완화 조치를 취할 조치를 취할 권한이 신속하게 해결됨 .
없음 . 권한이 없음 . 있음 .

datadog.com
DevSecOps 성숙도 모델 20

2. 계획 및 개발

역량 초급 중급 고급 전문가

리스크 평가 개발 주기 초반부에 보안 및 리스크 관련 설계 단계에서의 리스크 평가 또는 위협

보안 및 리스크가 고려 사항이 개발 리스크 평가 또는 위협 모델링이 설계 단계의
고려되지 않음 . 주기의 중후반 단계에서 모델링이 초반부터 일부로서 모든 신규
도입됨 . 수행되는 경우는 서비스에 적용됨 .
전체가 아닌 일부
서비스에 국한됨 .

기술 부채 관리 기술 부채가 통제되지 기술 부채가 다소 기술 부채 관리가 기술 부채 감축이

않은 채 증가함 . 규칙적으로 줄어들지만 강조됨 . 애플리케이션 및 인프라
감축이 우선순위는 전반에 걸쳐 지속적으로
아님 . 진행되고 있으며 낮은
수준을 유지함 .

우선순위 지정 엔지니어가 계획에 없던 엔지니어의 업무가 엔지니어가 대부분의 엔지니어가 대부분의

작업 , 버그 수정 작업 계획에 없던 작업과 시간을 새로운 기능에 시간을 새로운 고객
및 사고 복구 작업에 버그 수정 작업으로 투입하지만 계획에 없던 대면 기능을 개발하는
대부분의 시간을 보냄 . 인해 자주 중단되며 작업량이 여전히 많음 . 데 투입함 .
계획된 릴리즈가
지연됨 .

코드 검증 개발 이후의 코드 개발 이후의 코드 취약한 코드의 커밋을 취약한 코드의 커밋을

검증이 없음 . 검증이 부분적으로 수동 방지할 목적으로 일부 방지할 목적으로
진행됨 . 코드를 대상으로 정적 개발 단계부터 정적
코드 분석 ( 예 : 정적 코드 분석 ( 예 : 정적
애플리케이션 보안 애플리케이션 보안
테스트 또는 SAST) 이 테스트 또는 SAST) 이
수행됨 . 수행됨 .

datadog.com
DevSecOps 성숙도 모델 21

3. 빌드 및 테스트

역량 초급 중급 고급 전문가

테스트 자동화 전담 팀이 수동으로 일부 테스트는 테스트가 대부분 테스트가 완전히

테스트를 수행함 . 자동으로 , 상당수의 자동화되어 있음 . 자동화되어 있으며 개발
테스트는 수동으로 라이프사이클의 모든
진행됨 . 단계마다 다양한 테스트
방식이 적용됨 .

코드 스캔 취약한 코드의 패키징을 취약한 코드의 패키징을 취약한 코드의 패키징을 취약한 코드의 패키징을
방지하기 위해 커밋된 방지하기 위해 일부 방지하기 위해 일부 방지하기 위해 모든
코드를 스캔하지 않음 . 코드를 스캔함 . 커밋된 코드를 대상으로 커밋된 코드를 대상으로
동적 코드 스캔 ( 예 : 동적 코드 스캔 ( 예 :
동적 애플리케이션 보안 동적 애플리케이션 보안
테스트 또는 DAST) 을 테스트 또는 DAST) 을
수행함 . 수행함 .

빌드 검증 서명되지 않았거나 서명되지 않았거나 서명되지 않았거나 서명되지 않았거나

취약한 패키지를 취약한 패키지를 취약한 패키지를 취약한 패키지를
차단하기 위한 빌드 및 차단하기 위한 빌드 및 차단하기 위해 대다수 차단하기 위해 빌드 및
서명 검증이 진행되지 서명 검증이 부분적으로 빌드 및 서명의 검증이 서명의 검증이 자동으로
않음 . 진행됨 . 자동으로 진행됨 . 진행됨 .

품질보증 핵심 비즈니스 기능의 핵심 비즈니스 기능의 다수 애플리케이션의 전체 애플리케이션의

테스트가 진행되지 테스트가 간헐적 또는 핵심 비즈니스 기능이 핵심 비즈니스 기능이
않음 . 수동으로 진행됨 . 자주 , 자동으로 지속적으로 , 자동으로
테스트됨 . 테스트됨 .

datadog.com
DevSecOps 성숙도 모델 22

4. 릴리즈 및 배포

역량 초급 중급 고급 전문가

배포 자동화 한 환경에서 다른 배포 프로세스의 부분적 대다수 배포 프로세스의 프로덕션까지의 과정이

환경으로의 코드 이동이 자동화 . 자동화 . 완전히 자동화된 배포
수동으로 진행됨 . 툴의 사용 .

배포 전략 대규모의 간헐적 새 코드가 애자일 방법론과 애자일 방법론과

릴리즈로 이어지는 반정기적 ( 예 : 최신 배포 전략 ( 예 : 최신 배포 전략 ( 예 :
폭포수 방법론 . 월간 ) 으로 카나리아 , 블루 / 그린 , 카나리아 , 블루 / 그린 ,
릴리즈됨 섀도우 ) 을 통한 정기적 섀도우 ) 을 통한 매일
릴리즈 ( 예 : 매주 ). 수차례의 릴리즈 .

배포 검증 보안 태세를 근거로 새 보안 태세를 근거로 새 보안 태세를 근거로 새 보안 태세를 근거로 새

배포의 실패 여부를 배포의 실패 여부를 배포의 실패 여부를 배포의 실패 여부를
판단하는 기준이 없음 . 판단하는 약간의 판단하는 일련의 판단하는 일련의
기준들이 있지만 , 배포 기준들이 있지만 , 완전 기준들이 있으며 , 완전
검증의 일관성이 없음 . 자동화가 구현되어 있지 자동화가 구현되어
않음 . 있음 .

배포 수정 실패한 배포의 수정 실패한 배포를 신속하게 실패한 배포를 신속하게 배포 관련 문제에서

작업이 장시간에 걸쳐 롤백할 수 있는 역량을 롤백할 수 있지만 , 포워드 수정 방식이 주로
수동으로 진행됨 . 갖춤 . 가끔은 포워드 수정 선호되며 , 이를 신속히
방식을 선택함 . 수행할 수 있음 .

datadog.com
DevSecOps 성숙도 모델 23

5. 운영

역량 초급 중급 고급 전문가

플랫폼 관리 무질서한 방식의 인프라 구성이 인프라 구성이 완전하게 인프라 관리가 구성
구성 관리 및 배포용 부분적으로 코드 코드 저장소에 커밋되며 관리 / 오케스트레이션
템플릿의 부재 . 저장소에 커밋되며 일부 대부분의 프로세스가 툴을 통해 진행되고
프로세스는 수동으로 자동으로 진행됨 . 코드 저장소에 커밋됨 .
진행됨 .

용량 계획 CapEx 예산을 용량 계획 시 OpEx 용량 계획 시 OpEx 용량 계획 시 OpEx

활용하는 긴 용량 예산이 활용되지만 , 예산이 활용되며 , 예산이 활용되며 ,
계획 주기 ( 연간 또는 계절성과 성장에 대한 계절성과 성장을 계절성과 성장에
분기별 ). 인사이트는 제한적임 . 고려하여 진행됨 . 기반하여 진행됨 .

확장 수동 확장 . 자동 및 수동 확장 환경의 부분적 자동 특정 조건 ( 예 : 올바른

프로세스가 혼재 . 확장 . 요청의 유입 ) 의 충족 시
오토스케일링 실행 ..

신뢰성 프로덕션 환경이 단일 프로덕션 환경이 다수의 프로덕션 환경이 고가용성 프로덕션
클라우드 공급자 리전 가용 영역 및 / 또는 다수의 가용 영역 / 환경이 다수의
또는 가용 영역에서 리전에 걸쳐 구동됨 . 리전 , 멀티클라우드에 가용 영역 / 리전 ,
구동됨 . 걸쳐 구동됨 . 멀티클라우드에 걸쳐
구동됨 .

복원력 테스트 환경이 한계점까지 사전 프로덕션 일부 프로덕션 환경에서 프로덕션 환경에 대한

환경에서만 성능 빈번한 카오스 테스트 . 지속적인 카오스
테스트되지 않으며
테스트가 진행됨 . 빈번한 레드팀 테스트 . 테스트 . 지속적인
레드팀 테스트 / 공격자
간헐적인 레드팀 레드팀 테스트 .
시뮬레이션이 진행되지
테스트 .
않음 .

패치 패치가 체계적이지 않은 패치가 정기적으로 취약점 감지 시 취약한 것으로 판명된

방식으로 간헐적으로 수행되지만 시스템이 지속적인 패치가 시스템의 패치와
수행됨 . 장시간 취약한 상태를 수행되지만 SLA 는 관련하여 SLA 가
유지함 . 체결되지 않음 . 체결됨 .

재해 복구 재해 복구 재해 복구 전략이 반정기적으로 정기적으로 테스트되는

전략이 없음 . 마련되어 있지만 , 테스트되는 재해 복구 재해 복구 전략이
정기적으로 테스트되지 전략이 마련되어 있음 . 마련되어 있음 .
않으며 상당한 가동
중지 시간을 포함함 .

datadog.com
DevSecOps 성숙도 모델 24

6. 관찰 및 대응

역량 초급 중급 고급 전문가

서비스 수준 SLO 없음 . 사용자 경험과 일치하지 SLO 및 오류 예산이 SLO 및 오류 예산이

목표 (“ SLO” ) 않는 기초적인 SLO 가 서비스 안정성의 주요 엔지니어링 관련 결정의
자리잡은 상태 . 지표로 활용됨 . 주요 동인임 .

취약점 / 구성 오류 스캔 스캔 미실시 . 일부 인프라 및 대다수 인프라 및 앱의 모든 인프라 및 앱의

애플리케이션 스캔이 스캔이 진행됨 . 지속적인 스캔 .
진행됨 .

보안 모니터링 보안 메트릭 ( 예 : 보안 메트릭이 100% 의 서비스에서 100% 의 서비스에서

로그인 실패 ) 이 정의 부분적으로 정의 및 보안 메트릭이 정의되고 보안 메트릭이 정의되고
또는 표시되지 않음 . 표시됨 . 부분적으로 표시됨 . 완전히 표시됨 .

사용자 경험 엔드 투 엔드 고객 일부 고객 여정에 대한 대부분의 고객 여정에 모든 고객 여정에 대한

여정에 대한 가시성이 부분적인 가시성 . 대한 높은 가시성 . 완전한 가시성 .
없음 .

데이터 모델 및 액세스 데이터 간의 연관성이 일부 데이터 세트는 메타데이터 모델을 태그나 라벨 시스템으로
없으며 , 개별 팀 소유의 공통이지만 연관 , 검색 갖추고 대부분의 팀에서 모든 팀에서 활용이
분리된 시스템으로 및 필터링이 어려움 . 활용이 가능한 공통 가능한 성숙한
수집되고 공유되지 빈번한 컨텍스트 전환 . 데이터 플랫폼 . 메타데이터 모델 .
않음 .

사고 관리 사고 탐지 및 수정 사고 탐지 및 수정 사고 탐지 및 수정 사고 탐지 및 수정
시간이 지나치게 길고 시간이 개선 중이지만 시간이 짧으며 시간이 매우 짧으며
정확하게 알려지지 정확하게 측정되지 대략적으로 측정됨 . 철저히 측정됨 .
않음 . 않음 .

사후 분석 사후 분석을 위한 건설적이거나 명확하지 시기적절하게 명확한 조치 항목과

공식적인 템플릿이나 않은 방식의 비일관적 이루어지는 건설적인 함께 시기적절하게
프로세스가 없음 . 사후 분석 . 사후 분석 이루어지는 건설적인
사후 분석

datadog.com