2025 DevOps의 본질과 최신 트렌드

 

정명훈 (구글 클라우드)

IT에서의 효율성

IT에서 효율성을 얻을 수 있는 최고의 방법은 무엇일까?

 

반복과 재사용이다.

 

아날로그 현실 세계와 달리 디지털 기반의 IT 세계에서는 동일한 결과물을 만드는 것이 매우 쉽다. 친구나 동료가 말한 목소리를 기억하고 전달하는 아날로그 방식은 내용을 빼먹기도 하지만, 디지털로 남겨지는 스마트폰 녹음은 10년이 지나도 그대로 전달할 수 있다. 한 번 녹음된 디지털 음성은 10개를 복제하던 100개를 복제하던 품질이 그대로 유지된다.

 

 

IT 발전의 역사는 반복과 재사용을 통한 효율화의 역사이다. 어떻게 하면 하드웨어 또는 소프트웨어를 모듈 단위로 만들어 재사용할 수 있게 고민한다. 함수를 통해서, 컴포넌트를 통해서 그리고 API를 통해서 소프트웨어를 재사용한다. 인텔과 AMD에서 만든 CPU를 재사용하고 삼성전자에서 만든 메모리 모듈을 재사용하여 컴퓨터와 스마트폰은 쉽게 만들어낸다. 최근에는 AI를 통해서 지능까지도 재사용하고 있다. 나와 대화하는 ChatGPT나 Gemini는 나의 동료와도 동일한 지능을 재사용하면서 대화한다.

 

 

구글 정명훈님과, 스타트업 화혜 CTO, 피키캐스트 인프라 팀장 출신 이재광님의 Devops 트랜드에 대한 무료 온라인 세미나

4월 9일

신청 하기: https://docs.google.com/forms/d/e/1FAIpQLScNuq7qBqEPVFmQQx9J96rbwfy6XhqeSZDeicdIZeBwWR3waA/viewform?usp=dialog 

[D-DAY] 2025 DevOps 조직과 기술 트렌드 세미나 신청서

신청자분들께 링크 보내드립니다. 

IT에서 비효율적인 부분

그럼에도 불구하고 IT에서는 여전히 비효율적인 부분이 있다. 불행히도 반복과 재사용을 최고의 장점으로 가지는 IT 시스템의 개발과 운영은 지극히 아날로그적인 인간(사람)들이 하고 있기 때문이다. 모듈화된 IT 시스템은 반복과 재사용 과정에 오류가 없지만, 사람의 반복적인 작업은 항상 조금씩 다른 부분이 있다. 물론 그런 특성은 다양한 예외 상황에 직면해도 해결할 수 있는 지능이 발휘되기 때문이다. 하지만 사람도 IT 시스템 개발이나 운영 같은 반복적인 작업을 할 때 디지털적인 재사용이 어느 정도 가능하다면? 당연히 효율이 엄청나게 증가할 수 있을 것이다.

 

DevOps는 이러한 아날로그적인 인간의 협업 과정을 디지털처럼 또는 디지털 기반의 IT 시스템을 통해 표준화하여 자동화(반복 및 재사용)를 하자는 것이다. 거대한 소프트웨어 개발 과정에 이뤄지는 코딩, 디버깅, 빌드, 배포, 테스트, 모니터링 등의 과정을 디지털처럼 자동화할 수 있다면 생산성은 엄청나게 향상될 것이다.

DevOps란?

DevOps의 원칙은 다음과 같다.

 

1. 협업: 개발 및 운영 팀 간의 긴밀한 협력과 소통

2. 자동화: 반복적인 작업을 자동화하여 효율성을 높이고 휴먼 에러를 줄임

3. 지속적 개선: 프로세스와 산출물을 지속적으로 개선하는 문화

4. 고객 중심: 최종 사용자의 요구사항을 빠르게 반영하고 그들에게 가치를 제공하는 것을 목표로 함

 

이를 위해서는 다음과 같은 요소들이 필요하다.

 

1. 지속적 통합(CI): 코드 변경 사항을 통합(빌드 + 코드병합)하여 코드의 문제점을 빠르게 해결

  ⇒ 개발자와 개발자 간 IT 시스템을 통한 협업

 

2. 지속적 배포(CD): 소프트웨어를 자주 배포하여 사용자에게 가치를 빠르게 전달

  ⇒ 개발자와 운영자, 고객 간 IT 시스템을 통한 협업

 

3. 자동화된 테스트: 코드의 품질을 보장하면서 배포 과정을 빠르게 함

  ⇒ 개발자와 운영자 간 IT 시스템을 통한 협업

 

4. 모니터링: 배포된 소프트웨어의 성능과 사용자 경험을 지속적으로 관찰

  ⇒ 사용자와 운영자, 개발자 간 IT 시스템을 통한 협업

 

5. 문화적 변화: 팀 간 또는 팀 내부에서 팩트(데이터)에 기반한 협력을 통해 신뢰를 확보하고 책임 소재를 명확히 함

  ⇒ IT 시스템을 통한 모든 당사자들 간의 협업 및 대화

 

다음은 이상적인 DevOps 프로세스가 돌아가는 모습이다. 각 팀 간의 협업(대화 + 산출물 전달 + 피드백)은 IT 시스템의 일부인 CI, CD, 테스트, 모니터링 도구들을 이용하여 데이터(팩트) 기반으로 이루어 진다. 따라서 최대한 아날로그적인 사람들 간 협업의 특성을 배제하고 디지털적인 효율성(반복과 재사용)을 극대화 한다.

 

다음은 DevOps의 요소들이 갖추어지지 않았을 경우의 협업 모습이다. 자동화된 IT 시스템을 활용하지 않을 경우 막대한 인간의 노력이 필요하다. 시스템이 단순하면 사람의 노력만으로 운영이 가능하지만, 시스템이 커지고 복잡해지면 단순 반복적인 업무들로 인해 집중력이 저하되고 휴먼 에러의 가능성이 높아진다. 

DevOps가 어려운 이유

이렇듯이 DevOps를 도입하여 개발, 운영 과정이 마치 디지털 세계처럼 IT 시스템 기반으로 동작한다면 효율성이 매우 높다. 하지만, 현실에서는 이러한 DevOps가 잘 동작하지 않는 경우도 종종 목격한다. 왜 그럴까?

 

 

DevOps의 기반이 되는 도구들은 IT 시스템(디지털)이지만, 그것을 운영하는 것은 사람들이기 때문이다. DevOps가 실패하는 이유는 대개 다음과 같다.

 

1. 조직 문화와 구조의 문제

• 개발팀과 운영팀의 분리: 개발과 운영 조직이 완전히 분리된 조직에서는 협업이 어려움
• 기존 조직 구조의 저항: 각 팀 리더들의 기득권과 조직 재편에 대한 저항
• 엔지니어의 낮은 지위: 한국적인 특성으로 개발자와 운영자의 조직 내 직급이 높지 않아 문화적 정착을 방해 

2. 인식과 이해 부족

• DevOps를 도구로 오해: 위에서도 언급했듯이 DevOps는 아날로그적인 사람의 특성을 IT 시스템을 기반으로 문화적으로 변경하는 시도. 따라서 도구만 갖춰졌다고 해서 모든 것이 해결되지 않음
• 협업 문화의 부재: DevOps는 IT 도구 기반으로 자동화 되지만 팀 간에 긴밀한 소통이 필요. 특히 대상 시스템이 크고 복잡하다면 DevOps 프로세스 자체에 대해서도 끊임 없는 개선이 필요함

3. 기술적 어려움

• 레거시 시스템: 기존 코드와 시스템이 DevOps에 적당하지 않을 수 있음 (예: 오래된 시스템, 높은 외부 의존도, 복잡한 의존성)
• 자동화의 어려움: 테스트나 CI/CD 자동화에 필요한 기술적 역량의 부족

4. 인력과 교육

• 멀티태스킹 개발자 부족: DevOps는 전체 라이프사이클을 이해하는 개발자를 필요로 하지만, 이러한 인재 양성에는 시간이 많이 소요
• 교육과 훈련 부족: 팀 전체에 대한 체계적인 교육의 부족

5. 비용과 투자의 부족

• 초기 투자 비용: DevOps 도구와 인프라 구축에 필요한 초기 비용 부담
• 장기적 이점에 대한 의심: 조직의 리더들이 DevOps의 장기적 이점에 대한 확신 부족 

앞에서 DevOps에 필요한 요소로 문화적 변화를 언급했다. 팩트 즉 데이터에 기반한 협업을 통해 상호 신뢰를 구축하고 책임 소재를 명확히 한다고 했다. 필자가 SRE로 근무했던 외국계 스타트업에서 재미있는 경험이 있었다. 

 

어느날 고객사에 대형 장애가 나서 그날 슬랙방(전 세계 여러 브랜치에 흩어져 있어 기본 대화는 모두 슬랙)의 분위기가 험악했다. 한국적인 문화에 익숙한 나로서는 당연히 큰 싸움이 일어나겠구나 생각하며 열심히 채팅 메시지를 해석하며 따라가고 있었다. 과연 누구의 잘못이고 얼마나 질책을 받을까??? 그런데, 10분 만에 정리하고 각자 자신의 자리로 돌아간 것이었다. 대화의 마지막은 우리의 IaC 코드를 이렇게 이렇게 변경하자였다.

 

대화 내용을 자세히 읽어 보니, 이번 일의 원인은 IaC 코드 상에 특정 부분에 문제가 있었다. 해당 코드는 당연히 GitOps의 특성상 해당 코드를 커밋한 사람과 리뷰한 사람(+1)이 있었지만, 코드 변경 당시에는 이 상황을 예측할 수 없었다는 것이다. 그러니 해당 코드를 수정해서 커밋하는 것으로 그날의 사건은 마무리 되었다.

 

머리가 복잡했다. 당시가 거의 10년 전이니 한국이었다면 난리가 나도 대형 난리가 날 상황인데, 이들은 Git에 들어 있는 IaC 코드를 가지고 논쟁(치열하긴 했음)을 하다가 그것을 수정하는 것으로 정리가 되었다. 무슨 차이가 있는 것일까? DevOps와 GitOps 기반으로 모든 시스템이 자동화된 이 스타트업에서는 소스와 커밋 이력이라는 데이터 기반으로 거의 모든 것이 분석되다 보니 책임 소재가 분명했다. 누구의 잘못이 더 크냐는 논쟁도 필요 없고, 무엇이 잘못이니 그것을 고치는 것으로 아주 간단하면서도 명쾌한 해결책이 나왔다. DevOps 시스템에 대한 신뢰를 바탕으로 사람과 조직에 대한 신뢰가 문화가 되어 있었다.

DevOps의 효과

DevOps는 자동화된 IT 시스템을 통해 크고 복잡한 시스템을 개발, 운영하는 사람들 간의 협업을 돕는 프로세스이다. IT 시스템의 반복과 재사용이라는 특성을 활용해 비즈니스적 효율성을 높이는 것이 목적이다. 말하자면 모바일 통신 인프라로 인해 사람 사이의 대화가 훨씬 편해진 것처럼, IT 시스템의 개발과 운영도 DevOps라는 인프라를 두어 효율적으로 하자는 것이다.

 

DevOps의 비즈니스적인 효과는 다음과 같다.

 

1. 비즈니스 효율성 향상

• 시장 출시 시간 단축: DevOps를 통해 기업은 새로운 제품과 기능을 수십 배 더 빠르게 배포 가능
• 운영 효율성 증대: 자동화된 워크플로우를 통해 반복적인 작업을 줄이고 리소스 활용을 최적화
• 비용 절감: 효율적인 프로세스와 자원 관리로 장기적인 비용 절감 효과

2. 제품 품질 및 고객 만족도 개선

• 제품 품질 향상: 지속적인 테스트와 모니터링으로 결함을 조기에 발견하고 해결
• 고객 경험 개선: 빠른 업데이트와 피드백 반영으로 고객 만족도가 향상
• 안정성 강화: 장애 복구 시간을 24배 단축하고 변경 실패율을 3배 감소

3. 조직 문화 및 협업 강화

• 팀 간 협업 증진: 개발과 운영 팀 간의 소통과 협력이 강화
• 직원 만족도 향상: 자율성과 성장 기회 제공으로 직원 유지율이 높아짐
• 혁신 촉진: 실험과 빠른 피드백 루프를 통해 혁신적인 아이디어를 신속하게 검증

4. 비즈니스 민첩성 및 경쟁력 강화

• 시장 변화 대응력 향상: 빠른 배포와 피드백 반영으로 시장 트렌드에 신속하게 대응
• 확장성 개선: 자동화된 인프라 관리로 비즈니스 성장에 따른 확장이 용이
• 기술 부채 감소: 지속적인 업데이트와 유지보수로 기술 부채를 줄일 수 있음 

DevOps의 도입은 단순한 기술적 변화가 아닌 전체적인 비즈니스 운영 방식의 혁신을 가져온다. 이를 통해 기업은 더 빠르고 효율적으로 가치를 제공하며, 시장에서의 경쟁력을 강화할 수 있다.

2025년 현재, DevOps

2009년 Patrick Debois에 의해 처음 소개된 DevOps는 발전된 IT 환경에 맞춰 다음과 같이 변화하고 있다.

기술 스택 변화

과거 Jenkins 중심에서 GitOps, Cloud Native 기술(Kubernetes, Serverless) 중심으로 변화하였다.

 

GitOps는 Git 저장소를 단일한 Source of Truth로 사용하여 시스템을 구성하는 방식이다. GitOps는 다음과 같은 특징들을 가지고 있다.

 

• 선언적 기술 (Declarative): 시스템의 desired state를 선언적으로 기술한다. Kubernetes YAML, IaC 구성 파일과 같은 선언적 설정 파일은 시스템이 어떻게 동작해야 하는지 정의하며, 시스템의 현재 상태가 아닌 목표 상태를 명확하게 나타낸다.
• 버전 관리 및 불변성 (Versioned and Immutable): 선언적 기술은 Git과 같은 버전 관리 시스템에 저장된다. 모든 변경 사항은 Git을 통해 추적되고 관리되며, 이력을 통해 변경 사항을 확인하고 필요시 롤백할 수 있다. 또한, 시스템 구성은 Git 저장소에 정의된 내용을 기반으로 하므로, 수동 변경으로 인한 예측 불가능성을 최소화 한다.
• 자동 적용 (Automated Pull): Git 저장소의 변경 사항은 자동으로 시스템에 적용된다. 다양한 CI/CD 도구들은 Git 저장소를 지속적으로 모니터링하고 변경 사항을 감지하면 자동으로 가져와 빌드, 통합 및 배포한다.
• 지속적인 조정 (Continuous Reconciliation): GitOps 에이전트는 Git 저장소에 정의된 목표 상태와 현재 시스템의 실제 상태를 지속적으로 비교하고 조정한다. 시스템 구성이 수동으로 변경되거나, 오류로 인해 목표 상태와 실제 상태가 일치하지 않는 경우, GitOps 에이전트(예: IaC 도구)는 자동으로 시스템의 구성을 Git 저장소를 기준으로 변경한다.

 

이로 인해 다음과 같은 장점들이 있다.

 

• 자동화 및 간소화: 배포 프로세스를 자동화하여 수동 작업을 최소화하고 오류를 줄임
• 증가된 투명성: Git 기록을 통해 시스템의 변경 사항을 추적하고 검사하여 변경 내역을 명확하게 파악 가능
• 개발 및 운영 팀 간 협업 강화: 개발팀과 운영팀이 모두 동일한 코드베이스를 사용하여 협업을 강화하고, 오류를 최소화
• 롤백 및 복구 용이: 이전 버전의 코드로 롤백하여 시스템을 쉽게 복구 가능
• 더 빠른 배포 속도: 자동화된 배포 프로세스를 통해 더 빠르게 애플리케이션과 인프라를 배포하고 업데이트 가능
• 향상된 안정성: 코드 기반 관리를 통해 시스템의 일관성을 유지하고 오류 발생 가능성을 줄여 안정성을 높임
• 버전 관리: Git의 강력한 버전 관리 기능을 활용하여 시스템의 이전 또는 특정 상태로 쉽게 복원 가능
• 코드 기반의 검토: 코드 리뷰를 통해 배포 전에 변경 사항을 검토하고 오류를 사전에 예방

Kubernetes는 최신 애플리케이션의 사실상 표준이 되었으며 DevOps 워크플로우의 핵심이 되었다.

• 확장성: 수요에 따라 애플리케이션을 쉽게 확장 가능
• 자동화: 자동 확장, 자가 복구, 자동 롤아웃 및 롤백 기능을 제공
• 플랫폼 독립성: 다양한 클라우드 제공업체와 온프레미스 환경을 지원
• 마이크로서비스 친화적: 복잡한 분산 시스템을 효과적으로 관리할 수 있음

Serverless 아키텍처는 애플리케이션 개발 및 운영 과정을 간소화하고 있다.

• 인프라 관리 부담 감소: 클라우드 제공업체가 인프라를 관리
• 자동 확장: 수요에 따라 자동으로 확장
• 비용 효율성: 실행 시간에 따라 비용을 지불하는 모델을 제공
• 빠른 배포: 프로비저닝 과정이 없어 배포 속도가 빨라짐

이러한 변화로 인해 DevOps 팀은 기존의 인프라 관리보다는 애플리케이션 개발과 혁신에 더 집중할 수 있게 되었다. 또한 이러한 기술들은 CI/CD 파이프라인과 원활하게 통합되어 소프트웨어 개발 수명 주기(SDLC, Software Development Life Cycle) 전체를 자동화하고 최적화할 수 있게 되었다.

 

 

조직 구조 변화

DevOps 팀의 역할이 다양화 (DevOps, SRE, Platform Engineering, Cloud Engineering 등) 되었다.

 

DevOps 엔지니어는 개발과 운영 사이의 간격을 줄이고 CI/CD 파이프라인 구축, 자동화, 인프라 관리, 모니터링 등의 업무를 수행한다. 여기에 각각의 전문성을 띤 SRE, 플랫폼 엔지니어 등의 역할로 다양화 하고 있다. 이들 모두 개발, 운영 팀 사이에서 협업을 위한 역할을 하며 지속적인 개선의 문화를 중시하는 면에서는 공통적인 부분이 있다.

 

SRE(Site Reliability Engineering)는 시스템의 안정성과 신뢰성을 보장하는 데 중점을 두며 주요 역할은 다음과 같다.

 

• 서비스 가용성과 성능 모니터링 및 최적화
• 자동화 도구 개발 및 유지보수
• 용량 계획 및 확장성 관리
• 인시던트 관리 및 문제 해결
• SLI(Service Level Indicators)와 SLO(Service Level Objectives) 정의 및 관리 

플랫폼 엔지니어(Platform Engineer)는 개발자 경험을 향상시키고 생산성을 높이는 데 초점을 맞추며 주요 역할은 다음과 같다.

 

• 내부 개발자 플랫폼(IDP) 설계 및 구축
• CI/CD 파이프라인 최적화
• 개발자를 위한 셀프 서비스 도구 제공
• 인프라 자동화 및 관리
• 개발 팀과의 긴밀한 협력을 통한 요구사항 수집 및 구현 

SRE와 플랫폼 엔지니어를 분리함으로써, SRE는 시스템의 안정성과 신뢰성에 집중하고, 플랫폼 엔지니어는 개발자 생산성 향상에 집중할 수 있다. 즉, SRE는 시스템 운영 업무를 중심으로 플랫폼 엔지니어는 개발 중심의 업무를 담당하며 각자의 역할을 한다.

 

(출처: devopsschool.com) 

 

참고로 플랫폼 엔지니어가 구축하는 내부 개발자 플랫폼(IDP, Internal Developer Platform)은 다음과 같은 특징을 가진 개발자들을 위한 셀프 서비스 도구이다. 이를 통해 개발자들이 인프라에 대한 깊은 이해 없이도 필요한 리소스에 쉽게 접근하여 소프트웨어 개발 본연의 임무에 더 충실할 수 있게 한다.

 

• 개발 프로세스 통합 및 간소화: 개발 팀의 일상적인 작업을 쉽고 효율적으로 관리
• 셀프 서비스 기능: 개발자가 인프라와 배포 작업을 직접 관리
• 표준화: 모든 팀에 표준화된 도구 및 서비스 세트를 제공
• 생산성 향상: 개발 환경 설정, 빌드 파이프라인 구성, 애플리케이션 배포를 자동화하여 개발자가 코드 작성에 집중할 수 있게 함
• 협업 강화: 개발 팀과 조직의 다른 부서(예: 운영 및 보안 팀) 간의 협업을 위한 공유 플랫폼 제공
• 온보딩 개선: 새로운 개발자가 적절한 도구를 사용하여 생산성을 높이는 데 걸리는 시간을 단축 (예: 소프트웨어 카탈로그)
• 확장성: 조직의 성장에 맞춰 확장 가능한 플랫폼을 제공
• 거버넌스: 보안 및 규정 준수 요구 사항을 준수하는 모범 사례를 유연하게 적용할 수 있는 프레임워크를 설정

자동화 레벨

2025년 DevOps의 트렌드 변화 중 자동화 수준 향상은 Infrastructure as Code(IaC)와 Policy as Code를 중심으로 인프라 관리와 보안 자동화를 크게 발전시키고 있다.

 

IaC(Infrastructure as Code)의 발전 - 인프라를 코드로 정의하고 관리하는 방식으로 주로 Git 저장소와 연동되어 GitOps 형태로 운영

• 자동화 도구 투자 확대: 2025년까지 70% 조직이 인프라 자동화 도입 예상
• 버전 관리 강화: IaC를 통해 인프라 변경 사항을 Git 등의 버전 관리 시스템에서 추적하고 관리
• 일관성 및 재현성 향상: IaC는 동일한 환경을 반복적으로 프로비저닝할 수 있게 하여 개발, 테스트, 운영 환경의 일관성을 보장
• 확장성 개선: 클라우드 네이티브 환경에서 IaC를 통해 인프라를 빠르게 확장하고 관리

Policy as Code는 보안 정책과 규정 준수 요구사항을 코드로 정의하고 자동화하는 방식이다.

• 자동화된 정책 모니터링: 복잡한 IT 환경에서 정책 기반 거버넌스의 중요성 증가
• 컴플라이언스 자동화: 보안과 규정 준수를 자동으로 확인하고 관리
• 보안 강화: 개발 초기 단계부터 보안 정책을 코드로 통합하여 전체 개발 라이프사이클에 걸쳐 보안을 강화
• DevSecOps 강화: 보안이 개발 및 운영 프로세스에 더욱 깊이 통합되어 DevSecOps 문화가 강화

이러한 자동화를 통해 수동 작업을 줄이고 인적 오류를 최소화하여 운영 효율성을 크게 높일 수 있다. 코드로 정의된 인프라와 정책을 Git 저장소를 통해 기존 또는 새로운 환경에 빠르게 배포하고 확장할 수 있다. 가장 중요한 점은 Git 저장소를 Single Source of Truth로 사용하여 모든 환경에 일관된 구성과 보안 정책을 적용할 수 있다는 것이다. 이러한 변화는 DevOps 팀이 더 안전하고 효율적으로 인프라를 관리하고 애플리케이션을 배포할 수 있게 해주며, 조직의 디지털 전환을 가속화하는 데 크게 기여할 것이다.

확장된 개념

2025년 DevOps 트렌드에서 주목할 만한 점은 DevOps의 개념이 GitOps, FinOps, SecOps 등으로 확장되고 있다는 것이다. 이러한 확장은 DevOps의 핵심 원칙을 특정 영역에 적용하여 더욱 전문화된 접근 방식을 제공한다. GitOps는 위에서 이미 살펴보았고 FinOps, SecOps에 대해서 알아보자.

 

FinOps(Financial Operations)는 클라우드 비용 관리를 위한 운영 프레임워크이다. FinOps가 등장한 이유는 복잡해진 IT 환경 특히 클라우드의 비용 효율화가 중요한 환경에서 이에 대한 가시성을 높여 클라우드 투자 가치를 극대화 하기 위함이다.

 

• 클라우드 비용 증가: 클라우드 컴퓨팅이 점점 더 많은 조직의 가장 큰 운영 비용(OpEx)이 되면서, 효율적인 비용 관리의 필요성이 대두
• 비용 가시성 부족: 복잡한 클라우드 환경에서 비용을 정확히 파악하고 관리하기 어려움
• 재무적 책임과 투명성 강화: 조직 내 여러 팀이 클라우드 비용에 대한 책임을 공유하고, 투명한 비용 관리 필요
• 비즈니스 가치 극대화: 클라우드 투자에서 최대의 가치를 얻기 위해 지속적인 협업, 실시간 데이터 가시성, 비용 최적화 전략 필요
• 하이브리드 및 멀티클라우드 환경 관리: 복잡해진 클라우드 환경에서 효율적인 비용 관리와 최적화가 필요

 

FinOps의 주요 특징은 다음과 같다.

 

• 투명성 및 책임성: 클라우드 비용에 대한 가시성을 확보하여 모든 팀이 비용 사용 내역을 명확히 이해하고 예산 관리에 적극적으로 참여
• 데이터 기반 의사결정: 실시간 클라우드 비용 데이터에 접근하고 분석하여 정보에 기반한 결정을 내림
• 협업 강화: IT, 재무, 비즈니스 팀이 협력하여 속도, 비용, 성능 간의 균형을 맞춘 의사 결정
• 지속적인 최적화: 변화하는 비즈니스 요구사항에 클라우드 사용을 지속적으로 최적화 

FinOps를 통해 조직은 클라우드 지출을 더 잘 관리하여 수익성을 개선하고 비용, 속도, 품질 간의 절충점에 대해 더 나은 정보에 입각한 결정을 내릴 수 있다. 이는 단순히 비용을 절감하는 것을 넘어, 클라우드 투자의 가치를 극대화하고 비즈니스 목표와 클라우드 사용을 효과적으로 연계하는 데 도움을 준다.

 

SecOps(Security Operations)가 등장한 이유는 공격자들의 전술, 기술, 절차(TTP, Threat Techniques and Procedures)가 더욱 정교해지면서 조직이 대응해야 할 보안 위협의 수, 유형, 복잡성이 크게 증가했기 때문이다. 2021년 공급망(Supply Chain) 즉, 협력 업체, 소프트웨어 제공업체 등 제 3자 연결을 통한 해킹이 1%에서 17%까지 증가했다. 전통적인 보안 도구로는 새로운 공격에 대한 대응이 어렵다는 것을 의미한다.

 

또한 전통적인 IT 환경에서 분산/클라우드 환경으로 전환되면서 네트워크 경계가 모호해졌고, 이에 따라 새로운 보안 전략이 필요해졌으나, DevOps는 개발과 운영의 통합에 초점을 맞추어졌기 때문에 SecOps가 이러한 격차를 해소하기 위해 등장한 것이다.

 

SecOps의 특징은 다음과 같다.

 

실시간 협업 도구 활용: ServiceNow와 같은 ITSM 플랫폼을 보안 도구와 통합하여 원활한 사고 에스컬레이션 가능

자동화된 인시던트 대응: 로그 집계, 위협 정보 강화 등 일상적인 작업을 자동화하여 효율성 향상

행동 기반 이상 탐지: 사용자, 엔드포인트, 애플리케이션의 행동 기준선을 설정하여 미묘한 편차 식별

위협 정보 기반 방어 전략: 위협 정보(Threat Intel) 기반 탐지 및 인시던트 대응 플레이북에 통합

 

SecOps는 보안을 개발 및 운영 프로세스에 통합함으로써 조직의 전반적인 보안 태세를 강화하고, 빠르게 변화하는 위협 환경에서 민첩성을 유지할 수 있도록 한다. 보안을 IT 수명 주기 전반에 걸쳐 공유 책임으로 통합하는 문화, 자동화 및 플랫폼 설계에 대한 접근 방식이다. 이를 통해 보안과 운영 팀 간의 사일로를 줄이고, 개발 초기 단계부터 보안을 통합 하여 취약점을 최소화하고 안정적인 업데이트 배포를 할 수 있도록 한다. 보안 사고 발생 시에는 미리 정의된 대응(플레이북)으로 복구를 빠르게 한다.

 

다음은 전형적인 SecOps 환경의 예시이다. SIEM에서 각 시스템의 정보(로그, 이벤트 등)를 수집하여 위협정보를 이용하여 보안 위협을 탐지하고, 탐지된 결과는 SOAR를 이용하여 인시던트 형태로 관리하고 플레이북을 통한 대응을 하게 된다.

 

이 외에도 AI와 머신 러닝 기술을 통해 DevOps를 수행하는 AIOps나, 데이터 분석과 같은 데이터 중심 업무에 대한 DataOps, AI 중심 업무에 대한 MLOps 등도 새로운 트렌드라 할 수 있다.

이글은 2025년 Devops 트렌드에 대해서 구글 클라우드 정명훈님이 작성하신 글입니다. 이 정명훈님의 개인 의견임을 알려드립니다.