DevOps는 소프트웨어 산업에서 가장 중요한 패러다임 전환 중 하나입니다. 개발과 운영의 경계를 허물고, 빠른 피드백 루프를 만들고, 자동화를 통해 신뢰성을 높였습니다.
그러나 DevOps를 도입한 많은 조직에서 여전히 같은 문제가 반복됩니다. DevOps가 부족한 것이 아닙니다. DevOps가 처음부터 해결하려 하지 않았던 문제들이 있습니다.
DevOps가 해결하지 않는 것
DevOps는 기술적 실행에 집중합니다. 빠른 배포, 자동화, 모니터링, 피드백. 이것들은 모두 중요하고 DevOps가 잘 다루는 영역입니다.
그러나 DevOps는 이 질문에 답하지 않습니다.
누가 배포를 승인하는가. 파이프라인이 자동으로 배포하더라도, 그 배포를 누가 책임지는지는 기술의 문제가 아닙니다.
어떤 변경이 어떤 위험을 가져오는가. 변경의 위험도를 평가하고, 그에 맞는 절차를 적용하는 것은 프로세스의 문제입니다.
규제와 컴플라이언스를 어떻게 충족하는가. 공공 시스템, 금융, 의료 분야에서는 변경에 대한 증거와 승인 기록이 필요합니다. DevOps 파이프라인은 이 기록을 자동으로 생성하지 않습니다.
릴리즈 거버넌스의 필요성
릴리즈 거버넌스는 "무엇을 언제 어떻게 배포할 것인가"를 조직 수준에서 결정하는 구조입니다.
DevOps가 배포를 빠르게 만든다면, 릴리즈 거버넌스는 그 빠른 배포를 안전하게 만듭니다.
핵심 구성 요소는 이렇습니다.
변경 위험도 분류. 모든 변경이 같은 위험을 가지지 않습니다. UI 텍스트 수정과 데이터베이스 스키마 변경은 다른 수준의 검토가 필요합니다. 변경 유형에 따른 위험도 분류와 그에 맞는 승인 프로세스가 있어야 합니다.
변경 관리 위원회(CAB) 또는 동등한 구조. 고위험 변경은 여러 이해관계자가 검토해야 합니다. 이 구조는 의사결정을 느리게 만드는 것이 아니라, 중요한 결정에 적절한 사람들이 참여하게 합니다.
변경 캘린더. 어떤 변경이 언제 예정되어 있는지 전체 팀이 볼 수 있어야 합니다. 서로 영향을 줄 수 있는 변경이 겹치지 않도록 조율합니다.
변경 관리가 DevOps를 방해하지 않으려면
변경 관리 프로세스가 DevOps의 속도를 죽인다는 비판이 있습니다. 맞는 말이기도 합니다. 잘못 설계된 변경 관리는 관료적 병목이 됩니다.
핵심은 위험도에 따른 차등 프로세스입니다.
저위험 변경—테스트가 통과하고, 작은 범위이고, 빠른 롤백이 가능한—은 파이프라인이 자동으로 처리합니다. 별도 승인이 필요 없습니다.
중위험 변경은 팀 내 피어 리뷰와 간단한 승인으로 처리합니다.
고위험 변경만 더 엄격한 검토와 승인을 거칩니다.
이 구조에서 DevOps는 저위험 변경의 속도를 최대화합니다. 고위험 변경에는 적절한 통제가 적용됩니다.
DORA 지표 너머
DevOps 성숙도를 측정하는 DORA 지표(배포 빈도, 리드 타임, 변경 실패율, 복구 시간)는 기술적 실행 역량을 측정합니다.
그러나 이 지표들만으로는 부족합니다. 추가로 측정해야 할 것들이 있습니다.
- 승인 없이 이루어진 변경의 비율
- 변경과 장애의 추적 가능성
- 컴플라이언스 요구사항 충족 여부
- 지식 분산도(특정 담당자 의존도)
DevOps는 좋은 시작입니다. 그러나 운영 안정성은 기술적 실행 이상을 요구합니다. 릴리즈 거버넌스, 변경 관리, 명확한 책임 구조가 DevOps 위에 얹혀야 합니다. 이것이 파인만소프트가 운영 아키텍처를 이야기하는 이유입니다.