DevOps, SRE, 플랫폼 엔지니어링, NoOps와 클라우드 거버넌스

개발과 운영을 잇는 방식의 변화

flowchart TB
  subgraph sdlc["전통적 SDLC: 단계마다 다른 팀, 넘겨주기(hand-off)"]
    direction LR
    s1["코드"] --> s2["빌드"] --> s3["테스트"] --> s4["릴리스"] --> s5["모니터링"]
  end
  subgraph devops["DevOps: 한 팀이 자동화로 순환"]
    direction LR
    d1["코드"] --> d2["빌드"] --> d3["테스트"] --> d4["릴리스"] --> d5["모니터링"]
    d5 -->|"반복"| d1
  end
  subgraph noops["NoOps"]
    direction LR
    o1["코드"] --> o2["빌드·배포·확장·모니터링은 클라우드 관리형 서비스"]
  end
  sdlc --> devops

전통적인 방식은 단계마다 담당 조직이 따로 있어 일이 벽을 넘을 때마다 기다리고 책임이 흩어진다. 아래 네 가지는 이 벽을 줄이는 서로 다른 접근이다. 서로 대체재가 아니라 층위가 다른 개념이라 함께 쓰인다.

네 가지 비교

DevOps

DevOps는 개발과 운영이 소프트웨어 수명 주기 전체를 함께 책임지는 문화다. 도구 이름이 아니라 원칙이다. 반복 작업을 자동화(CI/CD)하고, 작게 자주 배포하고, 운영에서 얻은 피드백을 개발로 빨리 돌린다. 기본 개념과 배경은 CI/CD와 DevOps 분야 머리말에 있다.

SRE

SRE(Site Reliability Engineering)는 운영을 소프트웨어 공학 문제로 다루는 실천이다. "구현된 DevOps"라고도 부른다.

에러 버짓은 "빨리 배포하고 싶은 개발"과 "바꾸기 싫은 운영"의 갈등을 같은 숫자로 조정한다.

플랫폼 엔지니어링

팀마다 쿠버네티스·CI·관측 설정을 따로 익히면 인지 부담이 커진다. 플랫폼 엔지니어링은 이 공통 기반을 내부 개발자 플랫폼(IDP, Internal Developer Platform)으로 만들어 제품처럼 제공한다. 개발자는 검증된 기본 경로(골든 패스)를 따라 템플릿으로 서비스를 만들고, 셀프서비스로 배포·환경 생성을 한다. IDP의 구성, 포털과 플랫폼의 차이, 골든 패스의 성질은 플랫폼 엔지니어링에 있다.

NoOps

NoOps는 서버리스로 운영 작업 대부분을 클라우드 제공자에게 넘겨 개발자가 기능에만 집중하는 지향이다. 함수 실행(FaaS)과 관리형 백엔드(BaaS: 인증, DB, 스토리지)로 시스템을 짜면 서버 관리·확장·패치가 사라진다. 작은 팀과 작은 서비스에서 수명 주기를 DevOps보다 더 줄인다.

다만 운영이 0이 되지는 않는다. 모니터링, 비용 관리, 권한 설정, 장애 대응은 여전히 남고, 제공자 종속(lock-in)과 콜드 스타트 같은 제약이 따른다. 서버리스의 쓰임은 서버리스 아키텍처에 있다.

클라우드를 들인 조직: 운영 모델과 거버넌스

클라우드의 장점은 하루에도 여러 번 바꾸고 배포할 수 있다는 데 있다. 몇 달에 한 번 모아 반영하던 조직 구조로는 이 장점을 못 쓰고, 오히려 누구나 버튼 하나로 서버를 만들게 되면서 비용과 보안 사고가 는다. 그래서 클라우드 도입은 기술보다 조직과 규칙의 문제가 된다.

전담 조직은 독립 팀이든 IT 부서 안의 전담 인력이든 의사 결정권자의 확실한 지원이 있어야 한다. 설계 단계부터 클라우드 아키텍트와 운영 인력을 한 팀에 두고(DevOps), 서버·스토리지·네트워크 부서를 합쳐 관리하며, 비용 관리 방안을 처음부터 마련한다. 구심점은 클라우드 아키텍트다. 사업자를 고르고, 표준 아키텍처와 배포 절차를 만들고, 비용·접근 관리·규정 준수 절차를 세운다.

CCoE의 표준을 셀프서비스 도구로 만들어 내놓으면 위의 플랫폼 엔지니어링이 된다. 전 조직을 한 번에 바꾸기는 어려우므로 단순하고 효과가 분명한 서비스부터 옮겨 성공 경험을 만들고, 목표 조직·직무 정의 → 현재 구조·역량·문화 진단 → 구조·역할 재설계 → 단계별 이행 순으로 넓힌다.

거버넌스는 감시가 아니라 가드레일이다. 목표는 「허락받고 쓰기」가 아니라 「정해진 울타리 안에서는 마음대로 쓰기」이고, 울타리를 넘는 행동(공개 버킷, 허용 안 된 리전, 너무 큰 인스턴스)만 자동으로 막거나 알린다. 감시가 목적이 되면 다들 우회한다. 거버넌스가 맡는 일은 이렇다.

새 방식에는 늘 저항이 따른다. 지금의 업무·직책·영향력이 줄어든다고 느낄 때 커지므로 배울 기회를 넉넉히 주고 단계적으로 바꾼다. 바뀌어야 하는 사고방식은 다섯 가지다.

테스트는 개발자의 몫이 됐다

배포 주기가 짧아지면서 개발자 대 전담 테스터 비율이 크게 바뀌었다.

전담 테스터가 줄었다고 테스트가 줄어든 것은 아니다. 테스트 작성이 개발 과정 안으로 들어오고(시프트 레프트), 품질 전문가는 도구와 교육을 만드는 쪽으로 옮겨 갔다. 테스트를 언제 어디서 돌리는지는 테스트를 돌리는 시점에 있다.

회사 규모에 따라 달라지는 배포·품질 도구

정답 하나는 없다. 회사가 무엇에 집중하는지에 따라 도구와 절차가 바뀐다.

작은 조직이 큰 조직의 절차를 그대로 들이면 속도만 잃는다. 단계에 맞는 만큼만 들인다는 점은 스타트업 인프라 선택 원칙과 같다.

정리

• DevOps는 문화, SRE는 그 문화를 숫자로 운영하는 방법, 플랫폼 엔지니어링은 그것을 내부 제품으로 만드는 조직 방식이다.
• SRE의 에러 버짓은 배포 속도와 안정성의 갈등을 하나의 숫자로 조정한다.
• NoOps는 운영을 없애는 게 아니라 클라우드에 넘기는 것이다. 관측·비용·권한은 남는다.
• 클라우드를 들인 조직은 규모에 맞는 운영 모델(중앙·분산·공유 서비스·CCoE)을 고르고, 거버넌스를 감시가 아니라 가드레일(비용 가시성, 최소 권한, 자동화된 프로비저닝과 탐지)로 운영한다.
• 배포가 빨라질수록 테스트는 개발자의 일이 되고, 품질 조직은 도구를 만든다.
• 도구와 절차는 회사의 단계에 맞춰 늘린다.

관련 노트: 플랫폼 엔지니어링, CI/CD, 배포 전략, 관측 가능성: 로그, 트레이스, 메트릭, 고가용성과 재해 복구 설계, 테스트를 돌리는 시점: 로컬, PR, CI, 장애 대응과 포스트모템, 클라우드 비용 최적화, 클라우드 SLA·계약과 규제