DevOps·CI/CD·가치흐름

코드는 고쳤는데 고객의 예약은 왜 그대로일까?

앞 절의 공방 예약 서비스가 문을 열었다. 고객은 취소 기한을 알아보기 어렵다고 한다. 개발자는 문구를 고쳤지만 시험 담당자가 다른 일을 끝내야 확인할 수 있고, 배포 담당자는 금요일 밤을 기다린다. 금요일에는 여러 변경이 한꺼번에 올라간다. 다음 날 예약 확인이 실패해도 어느 변경 때문인지 찾기 어렵다.

문구를 고치는 시간은 짧았다. 고객이 개선을 받기까지는 오랜 시간이 걸렸고, 장애까지 생겼다. 이 절에서는 한 사람이 얼마나 빨리 코드를 쓰는가가 아니라, 필요한 변경이 어떻게 안전하게 사용자에게 도달하고 다음 개선으로 돌아오는가를 묻는다. 공방의 취소 안내 개선 한 건을 따라가며 그 사이에 필요한 이론을 읽는다.

이미 배운 세 가지를 연결한다

운영피드백은 실제 사용 결과를 관찰하고 책임자가 다음 행동을 정하는 닫힌 고리였다(검증·확인·운영 피드백). 형상 기준선은 변경을 통제하기로 합의한 산출물의 특정 버전이며, Scrum의 완료 기준을 충족했다는 판단은 공개 배포 시점과 같지 않았다(예측형·반복형·점증형·애자일). 측정값은 대상·기간·분모를 정해야 비교할 수 있었다(측정값·지표·목표·기준선).

DevOps는 부서 사이의 결과 책임을 잇는다

DevOps(Development and Operations)는 개발과 운영이 사용자 가치와 서비스 품질을 함께 책임지고, 변경의 전달·검증·운영피드백을 협업과 자동화로 이어 지속적으로 개선하는 접근이다.

개발팀은 기능 수, 운영팀은 변경 금지만 목표로 삼으면 서로 성공하려 할수록 고객은 기다리게 된다. 공방에서는 제품 담당자가 바꿀 이유를 정하고, 개발·시험·운영·보안 담당자가 안전한 전달 조건과 사용 결과를 함께 본다. 모두가 모든 일을 하거나 승인 권한을 없애라는 뜻은 아니다. 누가 결정을 내리고 누가 확인할지 명확히 하되 부서 인계에서 책임이 끊기지 않게 하는 것이다.

Scrum이 팀의 목표·책무·협업을 조직한다면, 이 절의 DevOps는 그 결과가 운영에 도달하고 피드백으로 돌아오는 흐름을 개선한다. 특정 도구 설치, 팀 이름 변경, 개발자에게 운영 당직만 추가하는 것은 이 흐름이 작동했다는 증거가 아니다.

문화·자동화·흐름·측정·공유가 함께 작동해야 한다

CALMS는 문화(Culture), 자동화(Automation), 린 사고(Lean), 측정(Measurement), 공유(Sharing)를 묶어 DevOps의 주요 관점을 기억하는 표현이다. 새로운 도구 제품이나 보편적인 성숙도 인증 등급이 아니다. 린 사고의 낭비·가치 구분은 앞 절에서 배웠다.

어느 하나만으로 나머지가 생기지는 않는다. 자동화가 빨라도 검토 결과를 공유하지 않으면 같은 실패를 반복하고, 좋은 분위기만 있어도 결과물을 재현·확인할 수 없으면 안전한 전달이 어렵다.

한 변경의 여정과 증거를 함께 본다

다음은 공방 사례를 위해 새로 구성한 흐름이다. 실제 조직에서는 일부 확인을 병렬로 수행하지만, 뒤의 판단이 앞의 증거를 무시해서는 안 된다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

통합·검증·공개는 서로 다른 결정이다. 식별한 같은 산출물을 검증하고 공개를 결정한 뒤, 실제 결과를 다음 변경에 되돌린다. 공개 준비와 자동 공개는 같은 조건이 아니다.

텍스트 표현으로 다시 확인하기

기존 그림의 연결	확인할 증거
고객의 어려움 → 작은 변경 결정 → 함께 쓰는 코드 반영	목표와 변경 범위, 함께 작동하는 코드
코드 반영 → 만들기·빠른 확인 → 식별 가능한 결과물 보관	빌드·시험 결과와 동일 결과물 ID
결과물 → 추가 검증·공개 판단 → 운영 반영·사용 확인	검증·승인·설정·배포 기록
실제 사용 관찰 → 결과 해석·다음 개선 → 고객의 어려움	사용자 결과에서 다음 변경으로 되먹임
각 인계에서 누가 기다리며 무엇을 확인해야 하는가	각 결과물을 어느 변경·검증·승인·배포와 연결하는가

아래에서는 이 일상어에 빌드, 지속적 통합, 지속적 전달 같은 정확한 이름을 붙인다. 도식의 목적은 모든 일이 무조건 직렬이라는 주장이 아니라, 변경과 판단 근거의 연결을 보여 주는 것이다.

같은 코드를 본다는 것부터 시작한다

버전 관리(version control)는 파일의 변경 이력과 특정 시점의 내용을 식별하고 비교·복원할 수 있게 관리하는 방법이다. 공방의 취소 규칙을 누가 언제 왜 바꾸었는지 기록하면 장애가 생겼을 때 후보 변경을 좁힐 수 있다. 변경을 되돌릴 수 있다는 말은 이미 처리된 고객 거래도 자동으로 취소된다는 말이 아니다.

커밋(commit)은 버전 관리에 기록한 하나의 변경 묶음이다. 트랜잭션의 네 성질(ACID)의 데이터베이스 커밋이 거래 처리를 확정하는 것과 달리, 여기서는 파일의 버전 이력에 기록하는 뜻이다. 주 통합선(mainline 또는 trunk)은 여러 사람의 변경을 계속 합쳐 공동으로 확인하는 기준 코드 흐름이다. 각자 떨어져 만든 내용을 마지막 날에만 합치면 문구 수정과 취소 계산 수정이 따로는 맞아도 함께는 어긋날 수 있다.

버전 관리에는 실행 코드뿐 아니라 시험, 빌드·배포 절차, 필요한 설정의 정의도 연결한다. 비밀번호 같은 비밀값 자체를 코드 저장소에 넣으라는 뜻은 아니다. 비밀값은 별도 보호 수단으로 관리하고 필요한 접근 권한과 참조를 통제한다.

코드와 배포할 결과물은 다르다

빌드(build)는 소스 코드와 필요한 의존 항목을 사용하여 검사하거나 실행·배포할 결과물을 만드는 과정이다. 언어에 따라 기계가 실행할 형태로 번역하거나 파일을 묶고 필요한 자원을 준비한다. 항상 하나의 실행 파일을 만드는 것만을 뜻하지 않는다.

아티팩트(artifact)는 제작·검증 과정에서 생성되어 식별하고 보관하는 결과물이다. 이 절에서 배포 아티팩트라고 하면 운영에 놓을 프로그램 묶음을 뜻한다. 시험 보고서도 넓은 뜻의 아티팩트지만 프로그램 묶음과 혼동하지 않는다. 아티팩트 저장소는 이렇게 만든 결과물을 버전별로 보관하고 꺼내 쓰는 곳이다.

공방의 변경 c17에서 만든 프로그램 묶음을 예약-42라고 하자. 시험한 묶음과 운영에 넣은 묶음이 같아야 시험 증거를 연결할 수 있다. 운영 직전에 같은 코드로 다시 만들어도 도중에 가져오는 구성품이 달라지면 내용이 바뀔 수 있다. 따라서 검증한 동일 결과물을 다음 환경으로 넘기고 환경별 설정은 분리한다. 이것이 아무 결과나 번호만 붙이는 것보다 중요한 이유다.

지속적 통합은 ‘자주 합치고 곧바로 확인’한다

지속적 통합(Continuous Integration, CI)은 작은 변경을 주 통합선에 자주 합치고 자동 빌드·시험으로 결합 상태를 빠르게 확인하여 깨진 상태를 우선 복구하는 개발 실천이다.

공방에서 문구 수정과 취소 계산 수정을 오래 따로 두지 않고 함께 작동하는지 확인한다. 자동 시험 서버를 두었어도 변경을 몇 주씩 따로 보관하면 통합의 문제를 뒤로 미룬 것이다. DORA의 CI 설명은 적어도 매일 통합하고 짧은 시간 안에 피드백을 받는 실천을 강조한다. 이 주기는 결함이 없다는 인증이나 모든 종류의 긴 시험을 몇 분 안에 끝내라는 규정은 아니다.

빌드가 깨지거나 시험이 실제 결함을 발견하면 새 기능을 계속 쌓기 전에 원인을 고친다. 즉시 수정하기 어렵다면 원인 변경을 코드에서 되돌려 공동 작업 기준을 회복할 수 있다. 자동 실행, 빠른 피드백, 잦은 실제 통합, 실패에 대한 행동이 함께 있어야 한다.

짧은 시험과 넓은 시험은 서로 대신하지 않는다

회귀(regression)는 변경 뒤에 원래 되던 기능이 잘못되는 현상이다. 취소 안내를 고치다 기존 예약 확인이 깨지는 것이 예다. 먼저 짧고 신뢰할 수 있는 자동 시험으로 주요 계산과 규칙을 확인한다. 이후 외부 결제 연결, 실제 예약 흐름, 성능과 보안처럼 더 넓은 확인을 이어 붙인다.

배포 파이프라인(deployment pipeline)은 한 변경에서 만든 결과물을 단계별 검증·판단을 거쳐 배포 가능한 상태와 운영 반영으로 연결하는 자동화된 전달 경로다. 한 번의 자동 시험 통과가 모든 후속 검증을 생략하게 하는 것은 아니다. 자동화가 어려운 사용자 경험 확인이나 필요한 승인도 명시적 판단 지점으로 남길 수 있다.

시험이 같은 내용에도 임의로 성공·실패하면 사람들은 실패를 무시하게 된다. 그런 시험은 원인을 분리해 고치고, 그동안 무엇이 검증되지 않았는지 드러내야 한다. 통과율을 높이려고 시험을 삭제하거나 실패를 숨기면 전달 경로의 신뢰가 사라진다. 시험 설계의 상세 원리는 후속 담당 절에서 확장한다.

지속적 전달과 지속적 배포는 마지막 결정이 다르다

지속적 전달(Continuous Delivery)은 필요한 검증을 거친 소프트웨어를 언제든 요청에 따라 안전하게 배포할 수 있는 상태로 유지하는 능력과 실천이다. 실제 운영 반영 시점에는 제품·업무·규제 조건에 따른 사람의 판단이 남을 수 있다. 공방 운영자가 취소 규칙 안내를 먼저 준비한 뒤 다음 날 공개하기로 선택해도 그동안 준비 상태가 유지된다면 모순이 아니다.

지속적 배포(Continuous Deployment)는 정해진 검증 조건을 통과한 변경을 별도의 수동 배포 결정 없이 운영에 자동 반영하는 실천이다. 시험하지 않은 모든 코드를 즉시 고객에게 보내는 것이 아니다. 그만큼 신뢰할 수 있는 검증, 관찰, 중단·복구 조건이 필요하다.

CI/CD는 지속적 통합과 지속적 전달 또는 지속적 배포를 묶어 부르는 표현이며, CD가 어느 뜻인지는 문맥에 명시해야 한다. 이 교재에서는 단독으로 CI/CD라고 쓸 때 지속적 전달을 기준으로 설명하고, 운영 자동 반영까지 뜻하면 지속적 배포라고 쓴다. 전달을 잘하기 위해 모든 제품이 자동 배포를 해야 하는 것은 아니다.

세 표현은 어느 질문에 답하는가?

앞 절의 Scrum은 이 표의 어느 한 행과 같은 개념이 아니다. 스프린트가 끝나기 전에도 사용 가능한 결과를 전달할 수 있고, Sprint Review가 반드시 배포 승인 관문인 것도 아니다. 완료 품질, 운영 반영 판단, 고객의 사용 결과를 구별해야 한다.

운영에 놓는 일과 고객에게 여는 일도 구분한다

배포(deployment)는 특정 프로그램·설정 등을 대상 실행 환경에 반영하는 일이다. 기능 공개(release)는 사용자에게 새 기능을 사용할 수 있게 제공하는 결정과 실행이다. 두 활동을 한 번에 할 수도 있지만 구별할 수 있다. 다만 문서에 따라 release를 배포 묶음의 이름으로도 쓰므로 이 절에서는 기능 공개라는 뜻을 명시한다.

기능 플래그(feature flag)는 설정에 따라 특정 기능의 실행이나 노출을 켜고 끄는 장치다. 공방은 새 취소 안내 기능이 들어 있는 프로그램을 먼저 운영에 놓고, 안내 준비가 끝났을 때 켤 수 있다. 플래그를 껐다고 결함 있는 코드 자체가 제거되거나 이미 바뀐 데이터가 원상 복구되는 것은 아니다.

켜진 상태와 꺼진 상태를 모두 확인하고, 누가 설정을 바꿀 수 있는지 기록한다. 더는 필요 없는 플래그를 정리할 시점을 정하지 않으면 조합이 늘어 검증이 어려워진다. 플래그는 접근권한 검사를 대신하지 않는다. 화면에 감춘 기능도 서버에서 허용 여부를 확인해야 한다.

작은 변경 하나가 실제로 통과하는 순서

공방은 취소 안내 문구 개선과 취소 금액 계산 변경을 하나의 거대한 배포로 묶지 않기로 했다. 먼저 규칙은 그대로 두고 안내만 분명하게 한다. 아래는 그 변경 한 건의 전달 기록 예시다.

빌드가 성공해도 후속 검증이 실패하면 다음 단계로 보내지 않는다. 동일 프로그램 묶음을 사용해도 운영 설정과 외부 연결은 다를 수 있으므로 실제 반영 직후의 확인이 필요하다. 자동화는 사람의 기억에 의존하던 반복 작업을 줄이지만, 잘못된 통과 기준까지 올바르게 바꾸어 주지는 않는다.

처음부터 모두 바꾸지 않는 세 방식

점진 교체(rolling update)는 실행 중인 프로그램 사본들을 일부씩 새 버전으로 교체하는 배포 방식이다. 남은 사본이 요청을 처리하는 동안 바꾸므로 여유 처리능력과 구·신 버전이 함께 작동할 조건이 필요하다.

블루·그린 배포(blue-green deployment)는 구 버전 환경과 신 버전 환경을 나란히 준비하고 사용자 요청이 향하는 곳을 전환하는 방식이다. 두 환경 유지 비용이 들며, 요청을 되돌릴 수 있어도 공유 데이터까지 자동으로 되돌아가지는 않는다.

카나리 배포(canary deployment)는 일부 실제 사용자나 요청에 새 변경을 제한적으로 적용하고 일정 기간 평가하여 확대 여부를 결정하는 방식이다. 작은 집단에서 배운 결과로 더 큰 집단에 대한 진행을 판단한다. 프로그램 교체 방식인 점진 교체와 평가 전략인 카나리는 조합될 수 있다. 블루·그린 환경 사이의 요청도 처음에는 일부만 전환하여 카나리로 평가할 수 있다.

일부에만 배포했어도 제대로 보지 않으면 소용없다

공방이 새 안내를 일부 고객에게만 켰다고 하자. 전체 예약 실패율만 보면 작은 집단에서 생긴 문제가 전체 수치에 묻힐 수 있다. 구·신 버전별로 예약 완료와 오류·응답시간을 나누어 보고, 비교 기간과 고객 특성이 얼마나 비슷한지도 살핀다.

확대 전에는 관찰할 사용자 결과, 허용 범위, 최소 관찰량·시간, 중단 책임자와 복구 방법을 정한다. 야간에 몇 건 성공했다는 이유로 낮 시간의 혼잡이나 드문 취소 경로까지 안전하다고 단정하지 않는다. 관찰량이 부족하면 통과가 아니라 판단 자료 부족이다. 서비스마다 요청량과 위험이 달라 모든 배포에 같은 몇 분 또는 같은 비율을 강제하지 않는다.

구·신 버전이 같은 데이터베이스를 사용하면 새 버전의 잘못된 쓰기가 구 버전 고객에게도 영향을 줄 수 있다. 두 집단이 비슷하다는 상대 비교와 서비스 전체가 지켜야 하는 절대적인 품질 기준을 함께 본다. 일부 배포는 피해 범위를 줄이는 통제이지 무해한 실험을 보증하는 장치가 아니다.

되돌리기와 고쳐 나아가기

롤백(rollback)은 실패한 변경의 영향을 줄이기 위해 이전의 알려진 정상 프로그램·설정 상태로 되돌리는 복구 방식이다. 롤포워드(roll forward)는 문제를 고친 새 변경을 적용하여 정상 상태로 나아가는 복구 방식이다. 여기서 롤백은 데이터베이스 트랜잭션 한 건의 취소와 범위가 다르다.

공방의 새 화면에만 문제가 있고 구 버전이 현재 데이터와 맞는다면 이전 프로그램으로 되돌리는 편이 빠를 수 있다. 반대로 구 버전이 새 데이터 형식을 읽지 못하면 무조건 되돌리는 것이 또 다른 장애를 만든다. 그때에는 문제 기능을 제한하거나 호환 가능한 수정본으로 진행하는 방안을 검토한다. 긴급 수정도 확인을 전부 생략하는 면허가 아니다.

선택은 이름의 선호가 아니라 현재 영향, 복구에 걸릴 시간, 구 버전의 현재 상태 호환성, 이미 발생한 거래와 데이터 손실 위험으로 한다. 확대를 멈추는 일, 사용자 영향을 줄이는 일, 근본 원인을 고치는 일은 순서와 완료 조건이 다를 수 있다.

스키마는 필드의 이름·자료형·제약·의미를 정한 데이터 계약이었다(데이터 형식·스키마·호환성). 값을 쓰는 생산자와 읽는 소비자가 서로 다른 버전이어도 필요한 데이터를 해석할 수 있는지 확인하는 것이 호환성 판단이다. 프로그램을 되돌릴 때도 현재 데이터와 그 프로그램의 계약이 맞는지 먼저 본다.

데이터 변경에는 되돌릴 수 없는 경계가 있다

예약의 취소기한을 새 필드로 옮기면서 구 필드를 즉시 삭제하면 아직 구 버전인 프로그램과 복구용 프로그램이 읽지 못한다. 과거 값을 합치거나 삭제해 정보가 사라졌다면 코드 파일을 되돌려도 그 정보는 돌아오지 않는다.

확장·이행·정리(expand–migrate–contract)는 새 구조를 함께 사용할 수 있게 확장한 뒤 사용처·데이터를 옮기고, 이전 구조가 불필요해졌음을 확인한 후 제거하는 변경 패턴이다. 공방에서는 새 필드를 준비하고, 구·신 프로그램이 필요한 값을 읽는지 확인한 뒤 데이터와 사용처를 옮긴다. 마지막에 구 사용처가 없고 되돌릴 경계가 정리됐다는 증거를 확인하여 구 필드를 없앤다. 구 구조를 영구 보존하라는 뜻은 아니다.

이 사례의 전환에서는 데이터 복사 중의 새 예약·수정도 놓치지 않도록 쓰기 일관성, 중단 후 재개, 누락·중복과 값의 대조를 별도로 설계해야 한다. 백업은 필요하지만 과거 시점으로 복원하면 그 뒤의 정상 예약을 잃을 수 있으므로 보존·재반영할 거래와 허용 손실을 판단한다. 코드 복구, 스키마 전환, 데이터 복원, 외부 결제의 취소·보정은 서로 다른 작업이다. 이행 방식의 상세 구현은 데이터·응용 구현 담당 절로 연결한다.

전달 방식은 줄여 주는 위험과 남기는 위험으로 비교한다

자동화를 시작하기 전에 연결이 너무 강해 항상 모든 서비스를 동시에 바꾸어야 하는지도 본다. 그 구조를 그대로 빠르게 반복하면 배포 횟수와 함께 장애도 늘 수 있다. 공방의 취소 안내처럼 경계를 좁힐 수 있는 변경부터 안전한 전체 흐름을 만든 뒤, 실제 제약을 근거로 확대한다.

가치흐름에는 코딩 전후의 기다림도 들어간다

가치흐름(value stream)은 고객에게 필요한 결과를 제공하기까지 업무가 지나가는 활동·정보·인계의 연결이다. 필요를 발견하고 우선순위를 정하는 일부터 실제 사용 결과를 확인하는 일까지 범위를 정해 볼 수 있다. 코드가 저장된 뒤 운영에 반영되기까지는 그중 전달 구간이다.

가치흐름 매핑(Value Stream Mapping, VSM)은 선택한 업무 흐름의 단계·인계·대기와 되돌아가는 일을 실제 관찰 근거로 나타내어 개선 지점을 찾는 방법이다. 공방에서는 ‘취소 안내가 어렵다’는 요청이 들어온 시점부터 고객이 바뀐 안내를 읽은 시점까지 한 건을 따라간다.

지도를 만드는 목적은 예쁜 업무도가 아니라 개선할 지점을 판단하는 것이다. 누구에게 언제 넘어갔는지 모르면 책임 공방이 생기고, 코딩 시간만 재면 사흘의 승인 대기를 놓친다. 새 기능의 정상 전달 경로뿐 아니라 문제가 생겨 긴급 수정이 도달하는 복구 경로도 살핀다.

측정값은 정한 방법으로 관찰한 값이고, 지표는 그 값을 목적에 맞게 계산·해석한 척도였다(측정값·지표·목표·기준선). 같은 이름의 시간이나 비율도 대상·기간·단위·분모가 다르면 바로 비교할 수 없다. 이제 공방의 변경 한 건에 시작과 끝을 정해 실제 처리와 기다림을 구별한다.

처리시간과 경과시간을 더하지 않도록 경계를 정한다

리드타임(lead time)은 미리 정한 시작 사건부터 종료 사건까지 흐른 시간이다. 실제 처리시간(process time)은 그 범위에서 해당 일을 직접 수행한 시간이다. 대기시간(wait time)은 필요한 다음 처리가 시작되지 못한 채 기다린 시간이다.

이 절의 업무 리드타임은 요청 접수부터 고객에게 제공할 때까지로 정한다. 다른 조직이 착수부터 완료까지를 재거나 달력시간 대신 근무시간을 재면 같은 수치처럼 비교할 수 없다. 이미 경과시간에 대기가 포함돼 있다면 다시 더하지 않는다. 여러 활동이 겹치면 각 담당자의 작업시간 합계와 한 건의 경과시간도 다르다.

아래 사례는 복잡한 겹침 없이 한 건이 순서대로 지나가며 같은 근무시간 단위로 기록되었다고 가정한다. 이 조건을 먼저 정해야 ‘전체에서 무엇을 줄일 것인가’를 계산할 수 있다.

화살표의 방향과 조건을 따라 연결을 읽습니다.

1시간은 36 px로 같게 배치했다. 첫 처리 구간은 요구 확인·문구 작성, 둘째는 코드 반영·빌드·시험, 셋째는 공개 준비·운영 확인이다. 긴 16시간 대기가 강조된다. 달력시간이나 DORA의 커밋 기준 리드타임과 바로 비교하지 않는다.

읽는 계산: 빌드를 빠르게 해도 긴 대기는 남는다

공방의 안내 개선 한 건에 다음 시간이 걸렸다고 가정한다. 숫자는 설명을 위한 자체 사례이며 DORA 조사 결과가 아니다.

순차 진행이고 빠진 시간이 없으므로 업무 리드타임은 6 + 24 = 30시간이다. 직접 처리한 시간의 비율은 6 ÷ 30 = 20%다. 여기서 직접 처리시간 전부가 고객 관점의 가치 있는 시간이라고 자동 판정하지는 않는다.

빌드에서 30분을 줄여도 전체는 29.5시간이다. 16시간의 공개 대기가 정말 필요한지, 누구의 어떤 증거를 기다리는지 확인하면 더 큰 개선 가능성을 찾을 수 있다. 필요한 규칙 승인은 없애지 않고, 자료 준비를 앞당기거나 승인 책임자와 조건을 명확히 하여 불필요한 대기를 줄일 수 있다. 이것은 빌드 최적화가 무의미하다는 뜻이 아니라 현재 전체 흐름의 주요 제약과 개선 목적을 먼저 본다는 뜻이다.

한 단계만 바꾸어 계산해 보자. 같은 순차 업무에서 실제 처리 6시간은 그대로이고 공개 대기를 16시간에서 4시간으로 줄였다면, 전체 대기는 8 + 4 + 0 = 12시간, 새 업무 리드타임은 6 + 12 = 18시간이다. 직접 처리 비율은 6 ÷ 18 × 100 ≈ 33.3%가 되지만 처리 자체를 더 빨리 한 것은 아니다. 기다리는 시간이 줄어 같은 6시간이 전체에서 차지하는 비율이 커진 것이다. 30 − 4 = 26시간이라고 답하면 새 대기값 4시간을 감소량으로 착각했다. 먼저 감소량 16 − 4 = 12시간을 구하거나 각 구간을 다시 합산하고, 처리시간과 경과시간을 더하지 않도록 경계를 정한다의 시간 경계를 복습한다. 독립 적용에서는 어떤 구간을 얼마로 바꾸었는지와 근무시간·달력시간 중 무엇인지 먼저 적어 두어야 한다.

일을 많이 시작하는 것과 많이 끝내는 것은 다르다

진행 중 작업(Work in Process, WIP)은 정한 흐름 안에서 착수했지만 아직 완료하지 않은 작업의 양이다. 검토 대기·차단도 정한 시작·완료 경계 안이면 포함하며, 보드에서 위치만 옮겼다는 이유로 제외하지 않는다. WIP 제한은 동시에 진행할 작업량에 상한을 두어 새 착수보다 기존 작업의 완료와 막힘 해소를 돕는 운영 규칙이다.

공방 팀이 다섯 변경을 시작했는데 검토 담당자가 한 번에 하나만 확인할 수 있다면 검토 앞에 일이 쌓인다. 개발자가 계속 새 일을 시작할수록 완료를 기다리는 항목과 문맥 전환이 늘 수 있다. 제한에 닿았을 때 할 일은 수치를 숨기거나 상한부터 높이는 것이 아니라 검토 자료를 정리하고 막힘을 풀어 기존 일을 끝내는 것이다.

제한값은 한 조직의 절대 정답이 아니다. 처리능력·작업 크기·긴급 운영 업무를 함께 보고 조정한다. 인원 모두가 잠시도 쉬지 않는 상태보다 고객 결과가 안정적으로 완료되는 흐름을 우선한다. 여러 진행 중 작업을 카드 하나로 합쳐 수치만 낮추거나 장애 대응을 장부에서 빼면 실제 양을 잃는다.

빠른 팀 하나가 전체를 빠르게 만들지는 않는다

공방이 코드 작성 속도만 두 배로 높였지만 검토·운영 준비 능력은 같다고 하자. 전달된 고객 기능이 늘지 않으면 대기열만 커진 것이다. 반대로 무조건 모든 단계를 직렬로 둘 필요도 없다. 서로 독립된 보안·기능 확인은 준비된 동일 결과물에 병렬로 수행하되 필요한 결과를 모두 모아 다음 결정을 내릴 수 있다.

작게 나눈 변경을 공개 전에 다시 한꺼번에 묶으면 고객 피드백이 늦어진다. ‘승인 대기’를 없애 보이려고 접수 시각을 늦추거나, 장애 수정을 별도 표에서 제외하면 보고는 좋아져도 흐름은 그대로다. 팀은 고객 결과를 기준으로 가장 큰 제약 하나를 고치고, 같은 측정 경계로 전후 변화와 부작용을 확인해야 한다.

공유 책임은 잘못한 개인을 찾아내지 않는다는 뜻이 아니다. 누가 어떤 판단을 했는지 기록하면서도, 같은 오류가 다시 발생하게 하는 절차·환경·정보 부족을 함께 고친다. 실패 보고를 벌점으로만 사용하면 다음 실패는 더 늦게 발견된다.

DORA 지표는 사람의 실력이 아니라 전달 체계를 본다

DORA(DevOps Research and Assessment)는 소프트웨어 전달·운영 역량과 성과의 관계를 연구하는 프로그램이다. 이 절의 소프트웨어 전달 성과 지표는 2026-09-05에 확인한 공식 가이드의 다섯 지표를 기준으로 한다. 세 지표는 변경의 처리량, 두 지표는 변경의 불안정성이라는 묶음으로 설명된다.

‘처리량 묶음’이라고 해서 세 지표가 모두 건수라는 뜻은 아니다. 이동에 걸리는 시간과 실패한 전달의 회복도 함께 본다는 연구상 분류다. 숫자가 좋아질수록 좋은 방향도 다르다. 빈도는 필요한 결과를 더 자주 전달할 수 있는지 보고, 시간·실패·재작업은 줄어드는지 본다. 무의미한 배포를 늘릴 목표는 아니다.

우선 하나의 애플리케이션이나 서비스에서 대상·기간·사건 기록을 정한다. 공방 예약 서비스와 전혀 다른 제품의 평균을 섞어 개인 순위를 만들면 구조·규제·사용자 조건을 잃는다. 측정의 기본 정의표는 측정값·지표·목표·기준선의 원칙을 그대로 사용한다.

처리량 묶음: 전달 시간·빈도·실패한 배포의 회복

변경 리드타임(change lead time)은 코드가 버전 관리에 커밋된 때부터 운영에서 성공적으로 실행될 때까지 걸린 시간이다. 앞의 ‘요청 접수부터 고객 제공까지’ 업무 리드타임과 시작점이 다르다. 한 배포에 여러 커밋이 들어가면 각 커밋의 연결과 집계 방식을 정해야 한다.

배포 빈도(deployment frequency)는 정한 기간에 운영 반영을 얼마나 자주 하는지를 나타내는 지표다. 기간당 배포 건수 또는 배포 사이 간격으로 표현할 수 있다. 테스트 환경 반영이나 같은 배포의 내부 재시도를 별개 운영 배포로 셀지는 임의로 바꾸지 않고 사건 단위를 먼저 정한다.

실패 배포 복구시간(failed deployment recovery time)은 즉시 개입이 필요한 실패한 배포로부터 서비스가 회복될 때까지의 시간이다. 예컨대 배포 때문에 예약 확인이 실패하기 시작한 시점과 정상 예약 처리의 회복 시점을 연결한다. 배포와 무관한 시설 장애를 섞거나 코드 수정이 끝난 시각만으로 종료하지 않는다. 집계할 때 평균인지 중앙값인지, 미복구 건을 어떻게 표시하는지 함께 밝힌다.

불안정성 묶음: 실패를 만든 배포와 복구를 위한 배포

변경 실패율(change fail rate)은 운영 배포 중 배포 뒤 즉시 개입을 필요로 한 실패 배포의 비율이다. 분자는 문제를 일으킨 배포, 분모는 같은 대상·기간·사건 정의로 센 전체 배포다. 배포 전 시험에서 걸러진 결함 수를 이 분자에 더하지 않는다.

배포 재작업률(deployment rework rate)은 운영 문제 때문에 계획에 없던 수정으로 수행된 배포가 전체 배포에서 차지하는 비율이다. 분자는 앞 배포의 실패 자체가 아니라 그 문제를 고치기 위해 이루어진 배포다. 하나의 실패에 여러 번 수정할 수도 있고, 한 수정이 여러 문제를 해결할 수도 있어 변경 실패율과 항상 같은 값이 되지는 않는다.

공식 일반 가이드는 운영 사고로 생긴 비계획 배포를 설명하고, 공개 연구 설문은 최근 6개월에 사용자에게 드러난 결함을 고치려고 수행한 비계획 배포를 묻는다. 자체 측정에서는 채택한 범위·기간을 명시해야 하며, 모든 계획 변경·모든 유지보수를 자동으로 이 분자에 넣지 않는다. 다음 예시는 이 설문의 사용자 결함 수정 범위로 한정한다.

읽는 계산: 실패율 15%와 재작업률 20%는 모순이 아니다

공방이 최근 6개월의 동일 예약 서비스에서 중복 제거한 운영 배포 20건을 확인했다. 그중 3건이 사용자에게 드러난 장애를 일으켜 즉시 개입이 필요했고, 이를 해결하기 위한 비계획 수정 배포가 총 4건 있었다. 이 4건도 전체 20건에 포함되며, 이 사례에서는 수정 배포 자체가 새 장애를 만들지는 않았다고 가정한다.

변경 실패율은 3 ÷ 20 × 100 = 15%, 배포 재작업률은 4 ÷ 20 × 100 = 20%다. 같은 20건을 분모로 삼지만 서로 다른 사건을 분자로 센다. 3건을 4건으로 나누거나 전체 20건에서 수정 배포를 빼면 다른 지표가 된다. 배포 빈도는 이 정의에서 6개월 동안 20건이며, 고객이 얻은 새 기능이 20개라는 뜻은 아니다.

세 실패 배포의 복구시간이 각각 10분·20분·90분이었다면 평균은 120 ÷ 3 = 40분, 중앙값은 가운데 값인 20분이다. 어느 쪽도 90분 사례를 지우지 않는다. 복구가 끝나지 않은 건이 있다면 별도로 드러내며 성공한 건만 골라 계산하지 않는다. 배포가 0건이면 비율은 측정 불가이지 자동으로 실패율 0%가 아니다.

다른 한 변경이 금요일 10시에 커밋되어 월요일 10시에 운영에서 성공적으로 실행됐다면 달력시간 기준 변경 리드타임은 72시간이다. 앞의 30시간 사례는 근무시간으로 잰 업무 흐름이므로 두 숫자를 바로 비교하지 않는다. 이처럼 적은 수의 가상 사건만으로 산업 등급이나 개인 실력을 판정하지 않는다.

이번에는 같은 20건 중 실패한 배포는 여전히 3건인데, 문제를 고치는 데 비계획 수정 배포가 5건 필요했다고 조건을 바꾸어 보자. 두 비율 중 바뀌는 것은 재작업률이며 5 ÷ 20 × 100 = 25%다. 실패율은 원래 실패를 만든 배포 3건을 세므로 15%로 남는다. 수정이 5건이니 실패도 5건이라고 쓰면 원인 배포와 복구 배포를 같은 사건으로 센 것이다. 불안정성 묶음: 실패를 만든 배포와 복구를 위한 배포의 분자 정의로 돌아가 각각의 배포 ID가 어느 사건에 속하는지 구분한다. 이 연습에서도 수정 배포 5건은 전체 20건에 이미 포함되고 그 자체가 새 장애를 만들지 않는다는 가정이 필요하다. 가정을 바꾸면 사건부터 다시 세어야 한다.

옛 네 지표를 보았을 때 무엇을 바꾸어 읽는가?

DORA의 2026년 공식 이력 해설은 2023년에 복구 지표의 이름·범위를 조정했고 2024년에 배포 재작업률을 추가했다고 설명한다. 옛 용어가 나온 기출을 무조건 무효로 버릴 필요는 없다. 원문이 어느 시기의 분류를 물었는지 밝히고 현행 정의와 차이를 덧붙인다. 과거 문항을 실제로 검증하지 않은 이 절의 예제를 실제 기출이라고 부르지는 않는다.

숫자를 목표로 만들면 숫자만 좋아질 수 있다

공방이 배포 빈도만 개인 평가에 연결하면 내용 없는 배포를 쪼개 횟수를 늘릴 수 있다. 실패율만 벌점으로 삼으면 장애를 ‘일반 수정’으로 바꾸어 적거나 배포 자체를 피할 수 있다. 리드타임을 줄이려고 커밋 전 대기를 길게 두면 전달 구간만 짧아 보인다.

그래서 다섯 전달 지표와 함께 업무 전체의 대기·진행 중 작업, 실제 예약 완료와 서비스 오류, 고객 문의와 팀의 과부하를 본다. 사건 기록의 정의를 고정하고 누락·예외·미복구 건을 공개한다. 서로 다른 제품을 서열화하기보다 같은 제품의 개선 가설을 검증한다.

작은 변경, 믿을 수 있는 시험, 안전한 복구를 갖추면 더 빠른 전달과 안정성을 함께 개선할 가능성이 있다. 그러나 배포 횟수를 강제로 높였다는 사실만으로 안정성이 좋아진다는 인과관계가 증명되지는 않는다. 지표 → 제약에 대한 가설 → 실제 개선 → 같은 경계의 재측정과 사용자 결과 확인으로 연결해야 한다.

자동화된 길도 공격받을 수 있다

소프트웨어 공급망(software supply chain)은 소프트웨어를 만들고 전달하는 데 연결된 코드·외부 구성품·제작 도구·배포 경로와 그 관계다. 공방이 직접 쓴 코드가 맞아도 외부 구성품이나 빌드 도구, 배포 계정이 바뀌면 운영 결과물은 달라질 수 있다.

DevSecOps는 보안 요구·검증·위험 대응을 개발과 운영의 협업·자동화 흐름에 통합하는 접근이다. 보안 검사를 맨 마지막에 한 번 추가하는 이름이 아니다. 바꿀 기능을 정할 때부터 허용 권한과 보호할 정보를 정하고, 코드·구성품을 확인하며, 만든 결과물이 운영에 놓이는 경로와 운영 후 취약점 대응까지 잇는다.

공방의 공개 코드 제안을 검증하는 작업에 운영 배포 권한을 그대로 주면, 신뢰가 확인되지 않은 변경이 비밀값을 읽거나 운영을 바꿀 수 있다. 검증 환경과 운영 권한을 분리하고 필요한 권한·기간·대상을 최소화한다. 절차와 시험 기록도 변조될 수 있으므로 접근을 통제하고 보관한다.

무엇으로 만들었는가와 어떻게 만들었는가는 다르다

소프트웨어 구성명세서(Software Bill of Materials, SBOM)는 소프트웨어를 구성하는 항목과 그 관계를 식별해 나타내는 명세다. 이름·버전 등 필요한 구성 정보를 연결하면 새 취약점이 발견됐을 때 영향받는 결과물을 찾는 데 도움을 준다. 명세가 있다는 사실만으로 구성품이 안전하거나 라이선스 문제가 없다는 판정이 끝나지 않는다.

프로비넌스(provenance)는 결과물이 어디에서 어떤 입력·과정을 거쳐 만들어졌는지 추적·검증하는 데 쓰는 출처와 생성 이력 정보다. 여기서 빌드 프로비넌스는 프로그램 묶음과 소스 버전·빌드 주체·과정의 연결에 초점을 둔다. SBOM과 일부 정보가 겹쳐도 하나가 다른 하나를 항상 대신하지는 않는다.

공방은 ‘외부 달력 구성품 2판을 포함한다’는 구성 명세와 ‘허용된 빌드 환경이 커밋 c17로 결과물 예약-42를 만들었다’는 생성 이력을 함께 보관할 수 있다. 구성품을 바꾸면 관련 명세와 확인 결과도 갱신한다. 목록과 생성 기록의 내용·시점·완전성이 맞는지 확인하지 않으면 오래된 종이는 최신 프로그램을 설명하지 못한다.

SSDF는 보안 활동과 확인 근거를 함께 다룬다

SSDF(Secure Software Development Framework)는 소프트웨어 생명주기에 통합할 고수준 보안 개발 실천을 정리한 NIST의 지침 체계다. NIST는 미국 국립표준기술연구소다. 이 절의 사실 기준일인 2026-09-05에 공식 목록은 1.1을 최종판, 1.2를 초안으로 표시한다. 더 높은 번호의 초안을 이미 확정된 의무처럼 적용하지 않는다.

이 절에서 사용하는 1.1의 범위는 제작 도구와 환경 보호, 보안 확인 기준·증거, 배포 무결성 확인, 결과물·구성 정보 보존과 이후 취약점 대응이다. 공방에서는 ‘누가 빌드를 바꿀 수 있는가’, ‘무엇을 확인하고 어느 결과물에 대한 기록을 남기는가’, ‘새 취약점이 나오면 어떤 배포가 영향을 받는가’라는 질문으로 적용한다.

확인 실패를 임시로 허용해야 한다면 책임자·이유·대체 통제·만료와 후속 조치를 분명히 한다. 예외를 기록했다는 이유만으로 위험이 사라지지는 않는다. SSDF가 이 교재의 모든 독자에게 동일한 국내 법적 의무를 직접 부과한다는 뜻도 아니다. 계약·관할·업무별 적용 판단은 별도다.

암호학적 해시는 내용을 고정 길이의 요약값으로 바꾸어 변경을 비교하는 재료였고, 그 자체로 작성자를 확인하지는 못했다(키·해시·암호화·전자서명). 전자서명은 개인키로 만든 서명값을 대응 공개키로 검증하여 내용의 무결성과 키 소유에 대한 증거를 제공한다. 공개키가 신뢰할 주체의 것인지, 그 주체가 이 일을 할 권한이 있는지는 따로 확인해야 한다.

해시·서명·프로비넌스도 확인하는 쪽이 있어야 한다

결과물 옆에 해시값 파일만 같이 두었는데 둘 다 바뀔 수 있다면, 값이 서로 맞는다는 확인만으로 믿을 수 없다. 서명이 유효해도 허용하지 않은 주체나 다른 빌드 과정에서 만든 결과물이면 채택하지 않아야 한다.

SLSA(Supply-chain Levels for Software Artifacts)는 소프트웨어 공급망의 보안 보장 수준을 단계적으로 설명하고 높이기 위한 명세다. 2026-09-05에 확인한 버전 1.2는 소스와 빌드의 서로 다른 트랙을 둔다. 이 절은 빌드 결과와 근거의 관계만 다루며 전체 명세의 적합성 판정을 하지 않는다.

빌드 트랙에서 L1은 생성 이력의 존재, L2는 호스팅된 빌드 플랫폼이 만든 생성 이력과 소비자의 진위 확인(대표 수단은 서명), L3는 강화된 빌드 환경의 보호를 강조한다. 여기의 L은 수준(level)을 뜻한다. SLSA의 호스팅된 빌드 플랫폼은 개인 작업 PC가 아니라 공유 또는 전용 기반시설에서 빌드 단계를 실행하는 환경이다. 개인 PC에서 자동 빌드를 돌렸다는 사실만으로 이 조건을 채우지는 못한다. L3에서는 동시에 또는 나중에 실행되는 다른 빌드에 원치 않는 영향을 주지 못하도록 격리하는 등의 보호까지 필요하다.

이것은 대표 차이의 요약이지 모든 세부 요구사항을 대체하는 인증 체크리스트가 아니다. 배포하는 쪽은 허용된 소스·빌드 주체·과정·결과물에 대한 기대와 실제 근거를 비교한다. 빌드 수준이 높아도 다른 구성품의 수준이 자동으로 같아지거나 업무 기능에 결함이 없다는 뜻은 아니다.

보안과 전달 증거를 같은 변경에 묶는다

이 연결이 있으면 시험 문서를 다시 수작업으로 베껴 쓰기보다 제작 과정에서 근거를 남기고 필요한 사람이 확인할 수 있다. 반대로 자동화가 생성한 기록이라도 잘못된 결과물 ID에 붙었거나 권한 없이 수정할 수 있다면 증거의 신뢰가 깨진다. 보관 기간·접근 권한·변조 보호와 책임자를 정해야 한다.

보안을 이유로 모든 작은 변경에 같은 장시간 회의를 추가하는 것과, 속도를 이유로 모든 확인을 없애는 것은 둘 다 목적을 놓친다. 위험에 맞는 통제를 앞에서 설계하고 가능한 확인은 자동화하되 예외·실패 판단은 실제 책임으로 남긴다.

방법론을 운영까지 활용하는 하나의 절차

앞 절에서 개발 방식의 선택과 통제를 배웠다면, 이 절은 그 방식의 산출물이 안전한 운영과 피드백까지 이어지게 적용한다. 다음은 공방의 개선 결정을 하나의 실행 방식으로 구체화한 절차다.

1. 가치와 흐름 경계를 정한다. 고객의 취소 안내 이해를 목표로 하고, 요청부터 사용까지의 인계·처리·대기와 복구 경로를 확인한다.
2. 작은 변경과 책임을 정한다. 규칙을 유지한 안내 개선부터 나누고, 결정 권한·검증 조건·WIP 제한으로 착수보다 완료를 관리한다.
3. 전달 경로를 만든다. 잦은 통합·자동 빌드·단계별 검증을 연결하고, 식별된 동일 결과물과 환경 설정·승인 근거로 배포 준비 상태를 유지한다.
4. 반영 위험을 통제한다. 제품 조건에 따라 지속적 전달과 지속적 배포를 구별하고, 제한적 적용·관찰·중단·복구를 설계한다. 데이터 변경은 구·신 사용처와 거래 손실 경계를 따로 확인한다.
5. 공급망과 증거를 지킨다. 코드·도구·환경 권한을 보호하고 구성 명세·생성 이력·시험·승인·배포를 같은 결과물에 연결한다.
6. 성과를 해석하고 조정한다. 같은 대상·분모·기간의 다섯 전달 지표와 업무 대기·사용자 결과·부작용을 함께 보고 가장 큰 제약을 개선한다.

이 절차는 특정 도구 제품의 설치 순서가 아니다. 조직의 조건에 맞는 방법론 활용을 실제 책임·산출물·판단과 운영 결과로 구체화한 사례다. 자동 시험 통과나 지표 개선만으로 고객의 목적과 서비스 품질까지 확인됐다고 단정하지 않는다.

독립 연습 — 빠른 빌드와 올바른 전달을 별도로 판단한다

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

공방의 순차 업무는 처리 6 시간과 대기 24 시간으로 이루어진다. 개선안은 공개 대기 16 시간을 8 시간으로 줄이고 나머지는 유지한다. 검증한 예약-42는 배포 준비가 되어 있지만 운영자가 다음 날 공개하기로 결정했다. 같은 6 개월의 운영 배포 20 건 안에 실패 배포 3 건과 그 문제를 고친 비계획 수정 배포 4 건이 이미 포함되어 있다.

• 새 업무 리드타임과 직접 처리 비율을 구하고 시간의 시작·끝 및 순차 가정을 적어라.
• 공개를 기다리는 상태가 지속적 전달과 모순되는지 설명하라.
• 실패율과 재작업률을 계산하고 4 건을 분모에 다시 더하지 않는 이유를 적어라.

풀이와 오답 교정 보기

시간은 요청 접수부터 고객 제공까지 같은 근무시간 단위로 재며, 한 건의 작업이 순차로 진행되고 누락된 단계가 없다고 가정한다. 대기는 8 시간 감소하여 16 시간이고 전체 리드타임은 6+16=22 시간이다. 직접 처리 비율은 6/22×100≈27.27%이며 처리 자체가 빨라진 것은 아니다. 배포할 준비 상태에서 사람의 공개 판단이 남는 것은 지속적 전달과 양립한다. 실패율은 3/20=15%, 재작업률은 4/20=20%다. 수정 4 건은 이미 전체 20 건 안의 사건이므로 분모를 24 건으로 만들지 않는다. 기능 공개와 프로그램 배포도 구별해야 한다.

분모를 바꿨다면 사건을 세는 두 비율, 공개 대기를 준비 미완료로 썼다면 전달과 배포의 결정, 처리시간이 줄었다고 썼다면 시간 경계를 다시 읽는다.

10점 문제: 비슷한 이름의 경계를 정확히 쓴다

지속적 통합, 지속적 전달, 지속적 배포를 구분하고 안전한 소프트웨어 전달을 위한 공통 조건과 유의사항을 설명하시오.

이 문제는 자체 작성한 학습 예제다. 세 정의를 나열한 뒤 끝내지 말고 자동화의 대상과 마지막 배포 결정이 어디까지인가를 구별한다. 공통 조건은 작은 변경·동일 결과물·단계별 검증이며, 주의점은 공개·데이터 복구·운영 확인의 경계다. 실제 시험 시행이나 채점 결과를 가정하지 않는다.

10점 풀이와 답안 구성 보기

10점 답안 목차

1. CI·지속적 전달·지속적 배포의 정의와 자동 반영 결정 차이
2. 작은 변경 → 빌드·시험 → 동일 결과물 → 후속 검증·배포 준비의 원리
3. 기능 공개·실패 복구·데이터 변경을 구분하고 운영 결과로 확인

10점 답안 도식

조건과 연결	지속성의 뜻
작은 변경 → 주 통합선 → 빌드·빠른 시험	지속적 통합: 공동 기준과 실패 대응
동일 결과물·후속 검증 → 언제든 배포 가능한 상태	지속적 전달: 준비 상태를 유지
필요한 수동 결정 또는 조건 통과 후 자동 반영	후자의 운영 자동 반영을 지속적 배포로 명시
운영 확인 → 이상 시 확대 중단 → 데이터 경계에 따른 복구 → 다음 개선	자동 반영도 검증·중단·복구 조건이 필요

지속적 통합의 출력만으로 운영 준비를 단정하지 않는다. 수동 결정의 유무와 검증의 유무는 서로 다른 축이다.

10점 모범답안

지속적 통합은 작은 변경을 주 통합선에 자주 합치고 자동 빌드·시험의 빠른 피드백으로 깨진 상태를 우선 복구하는 개발 실천이다. 지속적 전달은 필요한 검증을 거친 결과를 언제든 요청에 따라 안전하게 내보낼 준비 상태로 유지하며, 실제 배포 결정에 사람이 남을 수 있다. 지속적 배포는 정해진 검증을 통과하면 별도 수동 결정 없이 운영에 자동 반영한다. 따라서 CI 서버의 존재, 배포 준비, 운영 자동 반영은 같은 상태가 아니다.

공방의 취소 안내 개선을 작은 변경으로 나누고 커밋·빌드 입력과 결과물 ID를 연결한다. 빠른 시험과 외부 연결·예약 흐름 등의 후속 검증을 구별하며, 검증한 동일 프로그램 묶음을 환경별 설정과 함께 운영에 반영한다. 운영 직전 재빌드로 결과물이 달라지거나 자동 시험 하나를 모든 검증의 대체물로 삼지 않는다.

기능 플래그 등으로 프로그램 배포와 사용자 공개를 구분할 수 있으나 플래그 해제나 코드 롤백이 이미 바뀐 데이터를 되돌리지는 않는다. 운영 반영 후 실제 예약 결과를 확인하고 문제가 생기면 확대를 멈춘다. 현재 데이터와 구 버전의 호환성·복구시간·거래 손실을 검토하여 롤백 또는 검증된 수정본의 롤포워드를 선택하고, 결과를 다음 개선에 반영한다.

25점 문제: 이름에서 실행·판단으로 확장한다

예약 서비스에서 변경의 대기가 길고 일괄 배포 후 장애가 반복된다. DevOps 관점의 가치흐름 개선, CI/CD 구성, 배포·데이터·공급망 위험 통제 및 현행 DORA 지표를 활용한 개선 검증 방안을 설명하시오.

이 문제 역시 자체 작성 예제다. 상황의 두 문제인 긴 대기와 반복 장애를 각각 개선 절차에 연결해야 한다. 배포 도구 목록만 쓰면 업무 제약·복구·지표가 빠지고, 지표 이름만 쓰면 무엇을 실제로 바꿀지가 빠진다. 앞에서 배운 공방 사례의 원리와 계산을 그대로 답안 표현으로 연결한다.

25점 풀이와 답안 구성 보기

25점 답안 목차

1. 고객 가치와 공유 책임을 정하고 전체 가치흐름·WIP를 확인
2. CI·단계별 검증·동일 결과물의 전달 경로와 공개 판단을 구성
3. 제한적 적용·중단·롤백/롤포워드와 데이터 이행 위험을 통제
4. 공급망·권한을 보호하고 구성 명세·생성 이력·검증·배포를 연결
5. 현행 다섯 DORA 지표의 경계·분모를 고정하고 실제 사건을 해석
6. 전체 대기와 사용자 결과·부작용을 함께 보고 개선을 재검증

25점 도식 대조표

전달·복구·증거 관계	판단
가치 목표·공유 책임 → 요청·처리·대기·WIP 확인	한 사람의 코딩 속도보다 전체 흐름
작은 변경·CI → 동일 결과물·후속 검증 → 제한적 배포·운영 확인	검증 증거와 사용자 영향을 연결
사용자 결과·DORA 지표 → 개선 재검증 → 요청	같은 사건·분모·기간으로 다음 개선
운영 이상 → 확대 중단 → 복구 방식 선택	코드·설정과 데이터·거래 경계를 각각 판단
요구 ↔ 커밋 ↔ 빌드·구성/생성 정보 ↔ 시험·승인 ↔ 배포·운영 사건	공통 증거로 대기·실패·영향 결과물을 추적

이 표는 본문의 전달·운영피드백 그림에 답안의 판단을 대조하는 정리다. 실제 그림의 전달 경로와 되먹임을 먼저 따라 읽고, 맨 아래의 증거 연결로 각 단계의 대기·실패와 영향 결과물을 추적한다.

25점 모범답안

1. 가치 목표·공유 책임·전체 흐름과 작은 변경

DevOps는 개발·운영이 사용자 가치와 서비스 품질을 함께 책임지고 전달·검증·피드백을 협업과 자동화로 개선하는 접근이다. 공방의 목표를 취소 안내 이해 개선으로 정하고 요청부터 사용자 제공까지 활동·인계·처리·대기를 확인한다. 규칙을 유지한 안내 변경부터 작게 나누며, WIP 제한에 닿으면 새 착수보다 검토 대기 등 막힘을 해소한다. 담당자의 코드 작성 속도만 높여 완료되지 않은 작업을 쌓지 않는다.

2. CI/CD 유형 선택·동일 결과물·단계별 검증과 근거

CI로 작은 변경을 주 통합선에 자주 합치고 자동 빌드·빠른 시험 실패를 우선 해결한다. 커밋·빌드 입력·결과물 ID·시험 증거를 연결하고, 외부 결제와 예약 흐름·보안 등 후속 검증을 수행한다. 검증한 동일 결과물을 분리된 환경 설정과 함께 전달한다. 공방이 안내 공개 시점을 선택한다면 지속적 전달로 준비 상태를 유지하며, 조건 통과 후 운영 자동 반영까지 채택하면 지속적 배포로 명시한다. 자동화는 필요한 승인·통제를 삭제하지 않는다.

3. 제한적 적용의 관찰·중단·복구와 데이터의 별도 경계

일부 사용자에 적용하는 카나리에서는 구·신 버전별 예약 결과·오류·응답시간을 같은 조건에서 비교하고 관찰량·시간, 허용 범위, 중단 책임과 복구 방법을 정한다. 공유 데이터로 양쪽이 함께 영향을 받을 수 있으므로 전체 서비스의 절대 품질 기준도 본다. 이상 시 확대를 멈추고 영향·복구시간·구 버전의 현재 데이터 호환성을 기준으로 롤백 또는 롤포워드를 선택한다. 스키마는 확장·이행·정리로 구·신 사용처를 관리하며, 누락·중복·신규 거래를 확인한 후 구 구조를 제거한다. 백업 복원으로 이후 정상 예약을 잃는 위험과 외부 결제 보정은 코드 되돌리기와 별도로 판단한다.

4. 공급망 보호·명세와 생성 이력·검증에서 배포까지 추적

보안 요구를 처음부터 포함하고 코드·빌드 도구·환경·배포 권한을 보호한다. 신뢰가 확인되지 않은 변경의 시험에 운영 권한을 제공하지 않으며 기록의 접근·변조도 통제한다. SBOM은 구성품과 관계, 프로비넌스는 결과물의 생성 이력을 설명하므로 함께 확인한다. 해시 일치나 서명 존재만으로 안전을 단정하지 않고 허용된 소스·빌드 주체·과정·결과물이라는 기대와 실제 근거를 비교한다. 요구·커밋·빌드·시험·보안 예외·승인·배포·운영 사건을 같은 변경과 결과물에 연결하여 새 취약점의 영향과 조치를 추적한다.

5. 현행 다섯 지표의 사건·분모와 실패율/재작업률 계산

현행 DORA 전달 지표는 변경 리드타임·배포 빈도·실패 배포 복구시간의 처리량 묶음과 변경 실패율·배포 재작업률의 불안정성 묶음이다. 리드타임은 커밋부터 성공적인 운영 실행까지이며 전체 업무 리드타임과 구별한다. 동일 서비스의 6개월 배포 20건 중 실패 배포 3건, 그 문제를 고친 비계획 배포 4건이 전체에 포함되었다면 실패율은 15%, 재작업률은 20%다. 두 비율은 같은 전체 배포를 분모로 삼되 실패 사건과 수정 배포를 각각 센다. 복구시간의 집계 방식과 미복구 건, 누락·제외 규칙도 밝히고 배포 0건을 자동으로 실패율 0%로 만들지 않는다.

6. 전달 성과·사용자 가치·대기의 균형과 개선 검증

지표를 개인 순위나 배포 횟수 목표로 사용하지 않는다. 처리 6시간·대기 24시간의 순차 업무라면 리드타임은 30시간으로, 빌드 시간을 30분 줄이는 데만 집중하기보다 큰 대기의 원인과 필요한 승인 증거를 먼저 확인한다. 다섯 전달 지표, WIP와 업무 대기, 실제 예약 완료·문의·오류·과부하를 함께 살피고 중요한 제약을 개선한 후 같은 경계로 재측정한다. 시험 삭제·장애 재분류·커밋 전 대기 은폐로 숫자만 개선하지 않는다. 방법론의 선택이 책임·산출물·통제·운영피드백까지 연결될 때 활용의 실체가 생긴다.

출처·기준일과 읽는 범위

이 절은 2026-09-05에 확인한 공식·저자 1차 자료를 바탕으로 독립적으로 작성했다. 사례·계산·도식은 공방을 위한 자체 구성이며 외부 원본 도식이나 장문의 번역을 싣지 않았다.

• DORA의 CI, 지속적 전달, 배포 자동화는 실천·결과물·설정·검증 관계의 근거다.
• 가치흐름 매핑, 진행 중 작업 제한, 작은 변경은 흐름·대기·피드백의 근거다. 일부 옛 페이지의 네 지표 분류는 현행 분류로 사용하지 않았다.
• 지표는 현재 가이드(갱신 2026-01-05), 공식 이력(2026-01-02), 공개 연구 문항(갱신 2025-02-04)의 정의·기간 차이를 구별했다. DORA 자료의 표기 권리는 Google LLC의 CC BY 4.0이며 제3자 예외는 별도다.
• Google의 The Site Reliability Workbook(2018), DevOps와의 관계와 카나리 평가, Microsoft의 서비스 갱신·안전 배포를 대조했다. Google 책은 CC BY-NC-ND 4.0 표기가 있으므로 여기의 사실 참고를 원문 번역·변형 배포 허락으로 표시하지 않는다.
• 확장·이행·정리는 Danilo Sato의 Parallel Change(2014-05-13)와 앞서 배운 호출 계약의 호환성 원리를 저장 형식에 적용한 자체 사례다.
• NIST SP 800-218 / SSDF 1.1의 PO.3·PO.4·PO.5, PS.2·PS.3, PW.4.1, RV.1을 사용했다. 공식 목록의 1.2 초안 상태와 1.1 최종 상태를 구별했다.
• SLSA 1.2의 빌드 트랙·프로비넌스·FAQ와 빌드 요구사항의 Hosted·Isolated 구분을 사용했다. Linux Foundation의 Community Specification License 표기와 구체 사용 범위는 출처 장부에 기록하며, 이 본문은 명세 인증이나 저작권 검토 완료를 주장하지 않는다.

웹 갱신일·HTTP 응답 시각·최초 발행일은 서로 다른 정보다. 시험 직전 재확인 대상은 지표 정의, 보안 명세의 버전·상태와 해당 조직의 적용 조건이다. 출처 바이트 보존·권리 검토·교재 검수 상태는 별도 검수 장부에서 관리한다.

다시 읽을 때 이어 잡을 문장

작은 변경을 자주 합치고 빠르게 확인하는 것이 CI다. 언제든 안전하게 내보낼 준비 상태가 지속적 전달이며, 조건 통과 뒤 운영 자동 반영까지 하면 지속적 배포다. 같은 결과물의 시험·승인·배포를 연결하고, 사용 중 결과까지 확인해야 흐름이 닫힌다.

빠른 코딩보다 고객에게 도달하는 전체 경로를 본다. 대기·WIP를 숨기지 않고 필요한 통제를 제때 배치한다. 일부 배포와 롤백도 데이터·거래의 경계를 없애지 못한다.

현행 다섯 전달 지표는 사건·분모·기간을 먼저 정해 해석한다. 공급망의 구성·생성·검증 근거와 사용자 결과를 함께 보며, 숫자가 좋아졌다는 이유만으로 고객 가치와 품질이 확인됐다고 단정하지 않는다.

직접 연습: 시간의 겹침, 검증한 판본, 작은 집단의 실패를 확인한다.

아래는 자체 계산 사례다. 비교할 경계와 진행 기준을 문제에서 먼저 정했으며, 관찰 비율만으로 장래의 안전성이나 통계적 유의성을 판정하지 않는다.

1. VF-P. 같은 변경이 0시간에 두 독립 검증을 시작한다. 기능 검증은 0~4시간, 보안 검증은 0~2시간에 수행한다. 두 담당자가 각 작업에 해당 시간 내내 직접 참여하며, 두 검증이 모두 끝나야 공개 판단을 요청한다. 4~7시간은 판단 대기, 7~8시간은 운영 반영·확인이다. 같은 근무시간 축에서 전체 리드타임, 담당자 작업시간 합계, 적어도 하나의 처리가 진행된 경과시간, 아무 처리도 없는 대기시간을 각각 구하라. 작업시간 합계+대기시간이 이 경우 리드타임인가?
2. AF-1. 동일 커밋 c17을 사용했지만 시험 아티팩트 A는 달력 구성품 2판을, 운영 직전 재빌드 B는 3판을 포함했다. 서로 다른 프로그램 바이트이며 해시도 다르다. A의 시험은 통과했고 B는 시험하지 않았다. A의 통과 기록을 B에 그대로 붙일 수 있는가? A를 승인된 운영 설정과 함께 전달하는 안과 B를 새 판본으로 식별해 필요한 확인을 다시 하는 안에서 각각 남겨야 할 연결 증거를 쓰라. 해시가 같다는 사실만으로 빌드 주체의 권한까지 확인됐다고 할 수 있는지도 판단하라.
3. CA-1. 같은 관찰 기간의 예약 시도에서 구 버전은 900건 중 9건, 새 버전 카나리는 100건 중 10건이 실패했다. 각 시도는 한 번만 세고 누락은 없다. 사전에 정한 확대 조건은 각 집단 100건 이상 관찰하고 구·신 버전 각각의 관찰 실패율이 2% 이하이며 전체 서비스 실패율도 2% 이하인지 함께 본다. 두 집단과 전체 실패율을 계산하고 확대 여부를 판단하라. 전체 1개 숫자만 보았을 때 놓치는 문제와 이 관찰만으로 단정할 수 없는 결론도 쓰라.

병렬 경과시간·아티팩트 증거·카나리 집단별 계산 풀이

1. VF-P — 겹치는 담당자 시간은 한 변경의 경과시간에 두 번 넣지 않는다. 리드타임은 8−0=8시간이다. 담당자 작업시간 합계는 기능 4+보안 2+운영 확인 1=7인·시간이다. 적어도 하나의 처리가 진행된 시간은 0~4시간과 7~8시간의 합인 5시간이며, 그 사이 아무 처리도 없는 판단 대기는 3시간이다. 경과시간은 5+3=8시간이다. 작업시간 합계에 대기를 더한 7+3=10은 0~2시간의 동시 작업을 두 번 센 값으로, 리드타임이 아니다. 또 7/8을 앞의 순차 사례와 같은 직접 처리 비율로 비교하면 인·시간과 경과시간을 섞는다. 이 조건에서 처리 중인 경과시간의 비율을 별도로 정의하면 5/8=62.5%지만, 그것도 고객 가치가 62.5% 늘었다는 뜻은 아니다.

2. AF-1 — 코드 이름이 같아도 시험 대상이 같다는 증거는 없다. 구성품과 실제 바이트가 바뀌었으므로 A의 통과 기록은 B 자체의 시험 결과가 아니다. A를 전달한다면 A의 식별값·시험 결과·승인된 운영 설정·배포 대상과 운영 확인을 연결한다. B를 선택한다면 바뀐 입력과 B의 식별값을 기록하고, 그 변경의 영향에 맞는 확인·승인 증거를 B에 연결한다. A에서 확인한 변하지 않은 사실을 근거로 재사용할 수 있는지와 B 전체가 확인됐다는 주장은 따로 판단한다. 동일 패키지와 환경별 설정을 구별하는 배포 원리

해시는 내용 비교의 재료이므로 일치만으로 허용된 빌드 주체나 과정을 인증하지 못한다. 서명·생성 이력도 신뢰할 주체와 기대한 소스·과정·결과물에 맞는지 확인해야 한다. 운영에서 실제로 사용한 설정과 외부 연결의 확인 역시 프로그램 바이트 일치만으로 끝나지 않는다.

3. CA-1 — 작은 집단의 큰 실패가 전체 평균에 가려진다. 구 버전은 9/900=1%, 새 버전은 10/100=10%, 전체는 (9+10)/(900+100)=1.9%다. 관찰량 조건은 충족하고 전체 비율도 2% 이하이지만 새 버전의 10%가 집단별 조건을 넘으므로 확대하지 않는다. 문제의 원인과 사용자 영향을 확인하고 정해 둔 중단·복구 절차에 따른다. 1.9%만 보고 확대하면 100건의 새 버전 집단에서 10건이 실패했다는 사실을 놓친다. 카나리와 비교 집단을 구별하는 평가

여기서 실패율은 예약 시도의 실패 비율이다. 배포 사건을 분모로 삼는 DORA 변경 실패율로 바꾸어 부르지 않는다. 고객·시간대·공유 데이터의 차이와 이후의 관찰도 살펴야 하므로, 이 비율만으로 새 코드가 모든 실패의 원인이라거나 다음 기간도 같은 비율일 것이라고 확정하지 않는다. 문제의 2%와 100건은 자체 진행 규칙이며 모든 서비스에 적용되는 보편 기준이 아니다.