SRE와 DevOps의 차이: 겹치는 곳과 갈리는 곳
채용 공고에는 DevOps 엔지니어와 SRE가 따로 올라오는데, 업무 설명은 절반쯤 겹칩니다. 같은 것의 다른 이름일까요, 다른 직무일까요? 답을 먼저 적으면, DevOps는 개발과 운영의 벽을 없애자는 문화·방법론이고, SRE는 그 문제를 소프트웨어 엔지니어링으로 푸는 구체적인 구현입니다. 구글의 표현을 빌리면 “SRE는 DevOps라는 인터페이스의 한 구현체(class SRE implements DevOps)“입니다. 이 글은 이 한 줄을 실무 감각으로 풀어냅니다. SRE 입문 4부작의 첫 편이고, 이어서 SLI·SLO·SLA, Error Budget, 인시던트 핸들링을 다룹니다.
DevOps: 벽을 없애자는 방향 선언 #
DevOps는 특정 직무이기 전에 방향입니다. 개발팀은 빨리 바꾸고 싶어 하고 운영팀은 안 바뀌어야 안정적이라, 결과물을 벽 너머로 넘기던(“우리는 만들었으니 너희가 돌려라”) 구조를 없애자는 것입니다. 실천 항목은 배포 자동화(CI/CD), 인프라의 코드화(IaC), 관측과 피드백 루프, 작은 단위의 잦은 릴리스처럼 도구보다 흐름에 관한 것들입니다.
방향 선언이다 보니 조직마다 해석이 다르고, 그래서 “DevOps 엔지니어"라는 직함의 실체도 조직마다 다릅니다. 어떤 곳에서는 CI/CD와 IaC를 만드는 빌드·플랫폼 엔지니어이고, 어떤 곳에서는 이름만 바뀐 시스템 관리자입니다.
SRE: 신뢰성을 숫자로 다루는 엔지니어링 #
SRE(Site Reliability Engineering)는 구글이 만든 직무이자 방법론으로, 출발점이 뚜렷합니다. 운영 문제를 운영자가 아니라 소프트웨어 엔지니어가 풀게 하면 어떻게 되는가입니다. 그 결과물이 SRE의 고유 도구들입니다.
- 신뢰성의 정량화: “안정적으로"라는 형용사를 SLI(지표)와 SLO(목표)라는 숫자로 바꿉니다. 가용성 99.9%처럼 목표가 숫자면, 지금 목표를 지키고 있는지가 논쟁이 아니라 조회가 됩니다.
- Error Budget: 100%는 목표가 아니라는 선언입니다. SLO가 99.9%면 0.1%만큼의 실패는 쓸 수 있는 예산이고, 예산이 남아 있으면 빠르게 배포하고, 소진되면 신뢰성 작업이 우선권을 가집니다. 개발 속도와 안정성의 갈등을 협상이 아니라 규칙으로 바꾸는 장치입니다.
- 토일(toil) 상한: 반복적·수동적 운영 작업을 토일이라 부르고, 업무 시간의 일정 비율(구글 기준 50%)을 넘지 않게 관리합니다. 넘치면 자동화가 최우선 업무가 됩니다. “운영을 자동화하는 데 쓰는 시간"이 직무 정의에 들어 있는 셈입니다.
- 비난 없는 포스트모템: 장애를 사람의 잘못이 아니라 시스템의 결함으로 다루고, 재발 방지를 구조로 만듭니다.
정리하면 DevOps가 “개발처럼 운영하자"는 방향이라면, SRE는 그 방향을 숫자(SLO), 예산(Error Budget), 상한(토일), 절차(포스트모템)라는 운영 가능한 규칙으로 굳힌 것입니다.
실무에서 갈리는 모양 #
교집합은 큽니다. 둘 다 자동화, IaC, CI/CD, 관측을 씁니다. 갈리는 것은 책임의 초점입니다.
| 관점 | DevOps 엔지니어(통칭) | SRE |
|---|---|---|
| 초점 | 개발 → 배포의 흐름을 빠르고 매끄럽게 | 서비스가 목표한 신뢰성을 지키게 |
| 대표 산출물 | CI/CD 파이프라인, IaC, 개발자 셀프서비스 | SLO 정의, 대시보드·알림 체계, 포스트모템, 용량 계획 |
| 성공 지표 | 배포 빈도, 리드 타임, 개발자 경험 | SLO 준수율, Error Budget 소진 속도, 토일 비율, MTTR |
| 장애 시 | 파이프라인·인프라 복구 지원 | 인시던트 지휘, 원인 분석, 재발 방지 설계 |
작은 조직에서는 한 사람이 두 역할을 다 합니다. 규모가 커지면 배포·개발자 경험 쪽은 플랫폼 엔지니어링이라는 이름으로, 신뢰성·온콜 쪽은 SRE라는 이름으로 분화하는 것이 최근의 일반적인 흐름입니다. 채용 공고를 읽을 때도 직함보다 성공 지표가 배포 속도 쪽인지 신뢰성 쪽인지를 보면 실체가 보입니다.
어느 쪽이 필요한가: 조직 관점의 판단 #
도입 순서를 묻는 조직에게 실용적인 답은 이렇습니다.
- 배포가 고통스럽다면(수동 배포, 환경 불일치, 릴리스가 큰 행사가 되는 상태) 먼저 필요한 것은 DevOps 실천, 즉 파이프라인과 IaC입니다.
- 배포는 되는데 장애가 반복되고, 안정성과 속도가 매번 회의실에서 싸운다면 SRE의 도구가 필요한 시점입니다. 이때 첫 단추는 채용이 아니라 SLO를 정의하는 것입니다. 다음 편에서 다루는 SLI·SLO·SLA가 그 출발점입니다.
- 순서를 뒤집으면(측정 없는 SRE 직함, 파이프라인 없는 Error Budget) 이름만 남습니다. SRE의 도구는 전부 측정 위에 서 있기 때문입니다.
정리 #
- DevOps는 개발과 운영의 벽을 없애자는 문화·방법론이고, SRE는 그것을 소프트웨어 엔지니어링과 숫자로 구현한 방법입니다.
- SRE의 고유 장치는 SLI/SLO, Error Budget, 토일 상한, 비난 없는 포스트모템입니다. 공통 도구(CI/CD, IaC)는 양쪽이 같이 씁니다.
- 실무에서는 성공 지표가 갈림길입니다. 배포 속도·개발자 경험이면 DevOps/플랫폼, SLO 준수·MTTR이면 SRE입니다.
- 배포가 아픈 조직은 DevOps 실천부터, 안정성 갈등이 반복되는 조직은 SLO 정의부터 시작합니다.
- SRE 도입의 첫 단추는 채용이 아니라 측정입니다. 다음 편(SLI·SLO·SLA)이 그 구체적인 방법입니다.