?? ????? ???? ??? ??? ?? ?? ????(DevOps), ??? ??? ?????(SRE), ??? ?????? ??? ??? ??? ??? ???? ?? ?? ? ????? ??. ? ??? ??? ??? ?? ?? ??? ??? ????? ???? ?? ????. Credit: Macrovector / Shutterstock 개발팀 내에서 데브옵스(DevOps), 사이트 신뢰성 엔지니어링(SRE), 플랫폼 엔지니어링을 도입했다고 말하는 기업은 많지만, 실제로 각 개념이 의미하는 바를 명확히 구분하기는 쉽지 않다. 언뜻 보면 유사한 목표와 방법을 공유하는 듯 보이지만, 세 분야는 서로 다른 목적과 실행 방식을 지닌다. 이에 따라 여러 개발자와 엔지니어링 리더들을 만나 세 역할의 차이점과 공통점에 대한 견해를 들어봤다. 이들 중 일부는 실제로 해당 용어가 직함에 포함된 인물들이다. 현재 인테그로 테크놀로지스(Integro Technologies)에서 수석 데브옵스 엔지니어로 일하고 있는 데니스 튜멘체프는 세 역할의 관계에 대해 “데브옵스는 ‘왜’에 대한 질문이고, SRE는 신뢰성을 어떻게 보장할 것인가, 플랫폼 엔지니어링은 그것을 확장해 모두가 쉽게 사용할 수 있도록 만드는 방법이다”라고 표현했다. 이제 각 역할의 세부 내용을 살펴보자. 데브옵스란 무엇인가? 데브옵스(DevOps)는 개발자와 운영팀 사이의 ‘혼란의 벽(wall of confusion)’을 허무는 데서 시작된 문화적 운동이다. 과거에는 개발자가 개발 환경에서 코드를 작성한 뒤, 이를 시스템 관리자(운영팀)에게 넘겨 운영 환경에 배포하고 통합하는 식으로 역할이 분리돼 있었다. 그러나 애자일 방법론과 클라우드 기술의 등장은 소프트웨어의 구축과 배포 방식을 근본적으로 바꿔 놓았고, 이에 따라 많은 조직이 빠르고 더 나은 릴리스를 목표로 클라우드 네이티브 방식에 맞춰 조직 구조를 재편했다. 이는 곧 개발과 운영 간의 더 긴밀한 통합을 요구하게 됐다. 서비스나우(ServiceNow)의 제품 아키텍트 로한 라사네(Rohan Rasane)는 “데브옵스는 소프트웨어 제공과 운영이 공동의 책임이라는 개념을 중심에 둔다”라며 “자동화, 협업, 지속적 제공이 핵심이며, CI/CD 파이프라인, 코드형 인프라, 강력한 운영 위생 관행 등이 데브옵스의 주요 산출물”이라고 설명했다. 라사네는 이어서 “비록 ‘데브옵스 엔지니어’라는 직함을 가진 사람들을 종종 볼 수 있지만, 데브옵스는 역할이 아니라 철학이다. 서비스의 전체 생애 주기에서 개발자와 운영팀의 협업 방식을 규정하는 사고방식”이라고 강조했다. SRE란 무엇인가? SRE(Site Reliability Engineering)는 운영상의 문제를 소프트웨어 엔지니어링의 원칙과 기법을 통해 해결하는 접근 방식이다. 이 정의만 봐도 SRE가 데브옵스와 많은 영역을 공유한다는 점을 알 수 있다. 이름에서 알 수 있듯이, SRE는 ‘신뢰성’에 초점을 맞춘다. 코히어런트 솔루션즈(Coherent Solutions)의 데브옵스 부문 부대표 알렉산더 시모노프(Alexander Simonov)는 “SRE는 운영 환경 중심의 방식이다. 신뢰성과 서비스 수준 지표(SLI), 서비스 수준 목표(SLO), 인시던트 대응, 에러 예산 등이 주요 개념이며, 운영을 엔지니어링의 관점에서 바라본 접근”이라고 설명했다. SRE는 원래 구글에서 개발됐으며, 이후에는 단순히 시스템을 유지하는 수준을 넘어섰다. 프로그레스 소프트웨어(Progress Software)의 제품 부사장 프라샨스 난준다파(Prashanth Nanjundappa)는 “더 이상 불이 꺼지지 않게 유지하는 것에 머물지 않았다”라며 “SRE는 장애가 발생하더라도 빠르고 우아하게 복구할 수 있는 소프트웨어를 구축하는 데 목표를 두게 됐다”고 전했다. SRE의 주요 실천 항목으로는 SLO를 정의하고, 신뢰성과 혁신 간 균형을 위한 에러 예산을 설정하며, 인시던트 대응 시스템을 구축하는 것이 있다. 플랫폼 엔지니어링이란 무엇인가? 플랫폼 엔지니어링은 재사용 가능한 내부 도구와 프레임워크를 통해 개발자의 경험을 개선하는 데 초점을 맞춘다. 코히어런트 솔루션즈(Coherent Solutions)의 알렉산더 시모노프(Alexander Simonov)는 “플랫폼 엔지니어링은 내부 플랫폼을 제품처럼 구축해 팀이 매번 바퀴를 새로 만들지 않도록 한다. 셀프서비스, 골든 패스, 재사용 가능한 인프라가 그 핵심”이라고 설명했다. 클라우드비즈(CloudBees)의 제품관리 부사장 로렐리 카다판은 “플랫폼 엔지니어는 개발 경험과 셀프서비스 기능 제공에 집중하며, 보통 내부 개발 플랫폼(IDP)을 구축하는 역할을 맡는다”고 말했다. 데브옵스, SRE, 플랫폼 엔지니어링의 차이점 이 세 분야는 자동화, 빠른 제공, 신뢰성 확보 등 공통의 목표를 지니지만, 그 중심 과제와 범위는 서로 다르다. 서비스나우의 로한 라사네는 이를 “데브옵스는 협업 문화를 중심으로, SRE는 고가용성 유지에 중점을, 플랫폼 엔지니어링은 개발자 역량 강화에 집중한다”라고 정리했다. 카다판은 각 역할의 지표(KPI) 차이를 좀 더 구체적으로 설명했다. 데브옵스 엔지니어는 개발과 운영 사이를 잇는 연결 고리 역할을 하며, 배포 빈도나 변경 리드 타임 등 DORA 지표가 대표적인 KPI다. 플랫폼 엔지니어는 개발자의 인지 부담을 줄이는 데 집중하며, 개발자 만족도, 내부 순추천지수(NPS), 온보딩 시간 등이 KPI로 활용된다. SRE는 운영 환경의 신뢰성과 시스템 성능에 집중하며, 주요 KPI는 SLI, SLO, 인시던트 대응 시간 등이다. 공통점과 상호작용 차이점이 존재하지만, 이 세 역할은 함께할 때 가장 큰 시너지를 발휘한다. 프로그레스 소프트웨어(Progress Software)의 프라샨스 난준다파는 “데브옵스는 문화를 주도하고, SRE는 신뢰성을 확보하며, 플랫폼 엔지니어링은 이를 모든 팀에 확장 가능한 형태로 만든다”라고 말했다. 이들 역할이 만드는 결과물은 유사하다. 코드형 인프라, 가시성 확보, 자동화 등이 대표적이다. 하지만 그 관점은 다르다. 튜멘체프는 “데브옵스와 SRE는 모두 소프트웨어 제공과 운영 개선을 목표로 하지만, SRE는 보다 구조화되고 지표 중심이다. 플랫폼 엔지니어링은 데브옵스와 SRE의 실천을 가능하게 하는 인프라 기반을 구축한다”고 설명했다. 플랫폼 엔지니어링 전문기업 사이클로이드(Cycloid.io)의 설립자 벤자민 브리알은 “세 역할은 모두 소프트웨어 제공의 효율성, 신뢰성, 속도를 높이기 위한 공통의 목표를 지닌다. 개발자와 운영 사이의 간극을 메우는 데 있어 각각의 역할이 다르며, 접근 방식도 서로 다르다”고 강조했다. 브리알은 이어 “각기 다른 초점을 갖고 있지만, 인프라 구축, 신뢰성 확보, 협업이라는 현대 소프트웨어 개발의 세 핵심 요소를 함께 제공한다. 이 중 하나라도 빠지면 결국 더 많은 시간과 비용이 들고, 조직과 프로세스를 재편해야 하는 상황에 이르게 된다”고 덧붙였다. 서비스나우의 라사네는 “플랫폼 팀은 셀프서비스 포털을 통해 재사용 가능한 파이프라인이나 쿠버네티스 템플릿(데브옵스 도구)을 제공하고, 여기에 SLO 모니터링(SRE의 모범 사례)을 내장해 세 역할이 하나로 통합된 형태를 구현할 수 있다”고 설명했다. 엔지니어링의 성장 여지 데브옵스, SRE, 플랫폼 엔지니어링 간의 역할 구분은 조직 규모가 클수록 명확하게 실현될 수 있다. 클라우드비즈(CloudBees)의 로렐리 카다판은 “소규모이거나 초기 단계의 엔지니어링 팀에서는 이 세 직함이 혼재되거나 겹칠 수 있다”라며 “하지만 팀 규모가 커지고 성숙해질수록 역할이 분화되는 경향이 있다”라고 설명했다. 아이언소프트웨어(Iron Software)의 CEO 카메론 리밍턴(Cameron Rimington)은 자사의 팀이 어떻게 성장하면서 각 역할을 분리해 갔는지 구체적으로 밝혔다. “처음에는 개발자가 5명뿐이라 내가 데브옵스 역할을 겸임했다. CI/CD 파이프라인을 설정하고 배포를 관리했다. 팀이 15명으로 늘자 SRE를 채용했고, 그는 모니터링과 인시던트 대응 시스템을 구축해 팀의 월평균 다운타임을 4시간에서 30분으로 줄였다. 현재 팀이 40명이 되자 플랫폼 엔지니어를 채용해, 개발자가 몇 분 안에 테스트 환경을 만들 수 있는 내부 API를 구축했다”고 말했다. 이처럼 역할 간 개념적 중첩은 성장과 채용 과정에서 혼란을 야기할 수 있다. 튜멘체프 “기업이 데브옵스 인력을 채용한다고 해놓고 실제로는 데브옵스와 SRE 역할을 모두 요구하는 경우가 있다”고 지적했다. 리밍턴은 “유행하는 직함을 쫓지 말고, 지금 당장 해결해야 할 문제에 적합한 인재를 채용하라”라고 조언했다. 데브옵스, SRE, 플랫폼 엔지니어링의 삼각 구도 데브옵스, SRE, 플랫폼 엔지니어링은 각각 강조점은 다르지만, 서로 밀접하게 연결돼 있다. 이 세 가지가 함께 작동할 때 대규모 소프트웨어를 고품질로 제공할 수 있는 강력한 기반이 된다. 라사네는 “이 세 역할이 효과적으로 작동하기 위해서는 명확한 팀의 역할 정의, 측정 가능한 목표 설정, 그리고 내부에 제품 사고방식을 적용하는 것이 중요하다”라며 “도구뿐만 아니라 사람과 명확한 체계에 투자해야 조직이 자신 있게 확장할 수 있다”라고 설명했다.dl-ciokorea@foundryco.com ???? ???? ??? ??? IT ??? ???? ??? ????! ??? ??? ??? ?????. ????