많은 현대 개발 조직은 데브옵스, SRE(Site Reliability Engineering), 플랫폼 엔지니어링을 도입했다고 주장한다. 그러나 이 세 가지 유행어가 실제로 무엇을 의미하는지를 명확히 파악하는 일은 쉽지 않다. 얼핏 보면 세 가지 모두 상당 부분 겹치는 영역을 다루는 것처럼 보인다.

이 세 가지 용어를 직함에 포함하고 있는 개발자와 엔지니어링 리더 여러 명과 이야기를 나눠, 데브옵스, SRE, 플랫폼 엔지니어링이 어떻게 다르고 어떻게 겹치는지를 들어봤다. 현재 인테그로 테크놀로지스(Integro Technologies)에서 리드 데브옵스 엔지니어로 일하고 있는 데니스 티우멘체프는 과거 이 세 영역 모두에서 일한 경험이 있다. 티우멘체프는 “데브옵스는 왜 해야 하는지를 설명하고, SRE는 신뢰성을 어떻게 확보할지를 제시하며, 플랫폼 엔지니어링은 그것을 어떻게 확장하고 모두가 쉽게 사용할 수 있게 할지를 보여준다”라고 설명한다. 세부 내용을 살펴보자.

데브옵스란 무엇인가?

데브옵스는 원래 개발팀과 운영팀 사이의 ‘혼란의 벽’을 허물기 위한 문화 운동으로 시작됐다. 예전에는 개발자가 개발 환경에서 코드를 작성하고 이를 시스템 관리자(운영팀)에게 넘겨 프로덕션 환경에 배포하는 방식이었다. 그러나 애자일 방법론과 클라우드 기술이 소프트웨어 구축 및 배포 방식을 바꾸면서, 더 빠르고 더 나은 릴리스를 위해 많은 조직이 클라우드 네이티브 방식으로 전환하게 됐다. 그 결과, 개발과 운영 간의 통합이 필요해졌다.

서비스나우의 프로덕트 아키텍트 로한 라사네는 “데브옵스는 소프트웨어 제공과 운영을 공동 책임으로 인식하는 철학을 추구한다”고 말했다. 데브옵스는 자동화, 협업, 지속적 전달에 중점을 두며, CI/CD 파이프라인, 코드형 인프라, 철저한 운영 관리 등이 주요 산출물이다.

라사네는 “직함에 ‘데브옵스 엔지니어’라고 적힌 사람을 볼 수 있지만, 데브옵스는 역할이 아니라 사고방식”이라고 설명했다. 이어 “데브옵스는 개발자와 운영자가 서비스 전체 수명 주기 동안 어떻게 협업할지를 규정하는 사고 방식”이라고 덧붙였다.

SRE란 무엇인가?

SRE는 소프트웨어 엔지니어링 원칙을 운영 문제에 적용하는 분야다. 이 설명만으로도 데브옵스와 상당히 겹친다는 사실을 알 수 있다. 이름에서 알 수 있듯이 SRE는 신뢰성에 중점을 둔다. 코히런트 솔루션(Coherent Solutions)의 데브옵스 프랙티스 부책임자인 알렉산더 시모노프는 “SRE는 프로덕션 중심으로, 신뢰성, 서비스 수준 지표(Service Level Indicator, SLI), 서비스 수준 목표(Service Level Objective, SLO), 사고 대응, 오류 예산(Error Budget) 등을 생각하면 된다”라며, “운영을 엔지니어링 관점에서 보는 방식”이라고 설명했다.

프로그레스 소프트웨어(Progress Software)의 제품 부문 부사장 프라샨트 난준다파는 “SRE는 처음엔 ‘불이 꺼지지 않도록 유지하는’ 수준이었지만, 곧 ‘장애가 발생하더라도 빠르고 우아하게 복구할 수 있는 소프트웨어’를 만드는 것이 목표가 됐다”라고 말했다. 주요 SRE 실천 항목으로는 SLO 설정, 오류 예산을 활용한 신뢰성과 혁신의 균형 유지, 사고 대응 시스템 구현 등이 있다.

플랫폼 엔지니어링이란 무엇인가?

플랫폼 엔지니어링은 재사용 가능한 내부 도구와 프레임워크를 통해 개발자 경험을 개선하는 데 집중한다. 시모노프는 “플랫폼 엔지니어링은 내부 플랫폼을 제품처럼 구축해 매 스프린트마다 팀이 같은 일을 반복하지 않도록 한다. 셀프 서비스, 골든 패스, 재사용 가능한 인프라를 제공하는 것이 핵심”이라고 설명했다.

클라우드비(CloudBees)의 제품 관리 부문 부사장 로렐리 카다판은 “플랫폼 엔지니어는 개발자 경험과 셀프 서비스 기능 제공에 집중하며, 내부 개발자 플랫폼(Internal Developer Platform, IDP) 구축을 맡는 경우가 많다”라고 덧붙였다.

데브옵스, SRE, 플랫폼 엔지니어링의 차이점

세 영역 모두 자동화, 빠른 배포, 신뢰성이라는 공통 목표를 가지고 있지만, 주요 목적과 적용 범위는 다르다. 라사네는 다음과 같이 세 분야의 차이를 정리했다.

“데브옵스는 협업 문화를 중심으로 한다. SRE는 높은 가용성 유지를 강조한다. 플랫폼 엔지니어링은 개발자 지원을 최우선으로 한다.”

클라우드비의 카다판은 세 역할을 좀 더 구체적으로 분석했다.

• 데브옵스 엔지니어는 개발과 운영을 연결하는 접착제 역할을 한다. 대표적인 KPI는 배포 빈도, 변경 리드 타임 같은 DORA(DevOps Research and Assessment) 지표이다.
• 플랫폼 엔지니어는 개발자의 인지 부담을 줄인다. 대표적인 KPI는 개발자 만족도나 내부 NPS(Net Promoter Score), 그리고 신규 개발자 온보딩 시간이다.
• SRE는 프로덕션 환경의 신뢰성과 시스템 성능에 집중한다. KPI는 SLI와 SLO, 사고 대응 시간 등이 중심이다.

데브옵스, SRE, 플랫폼 엔지니어링의 접점

각각의 역할은 다르지만, 이들은 함께할 때 가장 효과적이다. 프로그레스 소프트웨어의 난준다파는 “데브옵스는 문화를 이끌고, SRE는 신뢰성을 보장하며, 플랫폼 엔지니어링은 이를 모두가 쓸 수 있도록 확장한다”고 설명했다.

이들이 만들어내는 산출물은 유사하다. 코드형 인프라, 가시성 확보, 자동화 등이 그것이다. 하지만 접근 방식은 다르다. 인테그로의 티우멘체프는 “데브옵스와 SRE는 둘 다 소프트웨어 제공과 운영을 개선하려고 하지만, SRE는 더 체계적이고 지표 중심”이라며, “플랫폼 엔지니어링은 데브옵스와 SRE의 실천을 가능하게 하는 인프라 기반을 구축한다”고 설명했다.

플랫폼 엔지니어링 전문 업체 사이클로이드(Cycloid.io)의 설립자 벤자민 브리알은 세 역할이 “소프트웨어 제공의 효율성, 신뢰성, 속도를 향상시키는 공통된 목표를 공유한다”고 강조했다. 또 “세 역할 모두 개발과 운영의 간극을 메우기 위한 것이지만, 집중하는 영역과 방법론이 다르다”라고 지적했다.

브리알은 이어 “각각의 역할은 다른 영역을 담당하지만, 모두 함께 작동하면서 현대 소프트웨어 개발과 운영의 세 가지 핵심 축인 인프라, 신뢰성, 협업을 제공한다”라며, “이 중 하나만으로도 돌아갈 수는 있지만, 시간이 더 걸리고, 비용이 더 들며, 결국 팀과 프로세스를 재정비해야 할 필요가 생긴다”라고 덧붙였다.

이들 역할은 운영 측면에서도 서로를 뒷받침한다. 서비스나우의 로한 라사네는 “플랫폼 팀이 셀프서비스 포털을 통해 배포하는 재사용 가능한 파이프라인과 쿠버네티스 템플릿(데브옵스 도구)에 SLO 모니터링 기능(SRE 베스트 프랙티스)을 내장하기도 한다”라고 설명했다.

엔지니어링의 성장 가능성

이 세 역할의 분업 구조는 규모가 큰 조직일수록 구현이 쉽다. 클라우드비의 카다판은 “소규모 혹은 초기 단계의 엔지니어링팀에서는 이 세 가지 직함이 뒤섞이거나 겹치는 경우가 많다”라고 말했다. 하지만 팀 규모가 커지고 성숙해지면 역할이 분화되는 경향이 있다고 설명했다.

아이언 소프트웨어(Iron Software)의 CEO 카메론 리밍턴은 “처음에 개발자가 5명일 땐 데브옵스 역할을 맡아 CI/CD 파이프라인을 구축하고 배포를 관리했다. 인원이 15명으로 늘자 SRE를 채용했고, 모니터링과 사고 대응 시스템을 제대로 갖췄다. 그 결과 월간 팀 다운타임이 4시간에서 30분으로 줄었다. 지금은 인원이 40명으로 늘었고, 플랫폼 엔지니어가 내부 API를 구축해 개발자가 몇 시간 걸리던 테스트 환경을 몇 분 만에 만들 수 있게 됐다”라고 자신이 경험한 팀 변화 과정을 소개했다.

이런 개념의 중첩은 성장과 채용 과정에서도 혼란을 야기할 수 있다. 인테그로의 티우멘체프는 “어떤 회사는 데브옵스 인력을 채용한다고 해놓고, 실제로는 데브옵스와 SRE를 모두 요구하는 경우도 있다”라고 지적했다. 리밍턴은 “유행하는 직함을 쫓지 말고, 지금 해결하고자 하는 문제에 맞는 인재를 채용하라”라고 조언했다.

데브옵스, SRE, 플랫폼 엔지니어링이라는 세 기둥

데브옵스, SRE, 플랫폼 엔지니어링은 상호 연결돼 있다. 강조점은 다르지만, 이 세 가지는 대규모 고품질 소프트웨어를 제공하는 강력한 삼각 구도를 이룬다.

서비스나우의 라사네는 “이 세 역할을 제대로 작동하게 하려면 명확한 팀 목표, 측정 가능한 성과 지표, 내부에 제품 사고를 적용하는 것이 핵심”이라며, “도구뿐만 아니라 사람과 명확한 역할 정의에 투자하는 것이 조직이 자신감을 갖고 확장해 나갈 수 있는 방법”이라고 강조했다.
dl-itworldkorea@foundryco.com