Platform Engineering

플랫폼 엔지니어링(Platform Engineering)은 소프트웨어 수명주기를 관리하기 위해 개발자가 스스로 개발, 배포, 운영을 할 수 있도록 셀프 서비스 환경을 구축하는 것을 말한다. 내부 사용자, 일반적으로 소프트웨어 개발자 및 엔지니어에게 공유 플랫폼을 제공하여 서비스 운영 효율을 높이는 것이 목적으로 하며, 최종 사용자에게는 드러나지 않는다. 공유 서비스(Shared Service), 데브옵스 툴(DevOps Tool) 또는 단순히 도구(Tool)라고 부르기도 한다.

플랫폼 엔지니어링이 중요한 이유는 개발자가 스스로 무엇인가를 만들고 시도해 볼 수 있는 효율적인 환경을 제공하되, 걸림돌 또는 병목 지점이 되지 않는 다는 것이다. 넒게 보면 이러한 장점은 서비스 개발 및 배포 간격을 짧게 해주며, 혁신을 가속화 할 수 있도록 만들어 준다. 아마존(Amazon)에서는 이러한 문화를 빌더스(Builders)라고 부른다. 아마존의 직원들은 세상을 바꿀 수 있는 빌더이며, 계속해서 변화를 위한 실험을 스스로 해 볼 수 있다. 이러한 빌더스 문화는 기존 엔터프라이즈와 다르다. 정해진 솔루션의 범위 내에서 허용된 것만 수행하는 것과 달리 아마존의 빌더들은 아마존이 제공하는 플랫폼^[각주:1]환경 위에서 애플리케이션을 빠르게 만들고 실험해 볼 수 있다.

빌더 문화는 단점도 있다. 완벽하게 갖춰진 것이 없어서 스스로 만들어 가야하기 때문에 많은 부분에서 번거로움을 느끼게 된다. 필요한 것이 있으면 항상 챙겨주시던 엄마가 그리울 정도이다. 하지만, 엄마처럼 완벽하게 지원해 줄 수 있는 환경을 기다리는 것은 늦다. 완벽함을 기다리다가는 적절한 때를 놓치게 되며, 남들이 다 완성해 놓은 안정적인 방법을 우리는 혁신이라고 부르지 않는다. 그리고 엄마도 엄마가 처음이라 사실은 완벽할 수 없다. 빌더 문화가 가질 수 밖에 없는 불완전함을 인정한다면, 셀프 서비스는 많은 장점이 있다. 빠르게 실험해 보고 결과를 분석해서 더 나은 방향으로 나아갈 수 있다. 플랫폼 엔지니어링은 이러한 빌더를 위한 놀이터이며 장난감이자 실험실을 꾸며주는 일을 하는 것이다.

삼성에서는 전통적인 서비스 운영 방법을 사용하고 있었다. 개발과 운영 조직을 별도로 운영하여 각자의 전문성을 확보하였고, 다양한 운영 경험을 가진 회사에 운영을 위탁하는 형태를 갖추고 있었다. 전 세계 사용자를 대상으로 스마트폰을 판매하면서 대규모 서비스를 제공해야하는 도전적인 상황에서도 이러한 기존 방식은 대체적으로 잘 동작했다. 하지만, 아쉬운 부분도 존재했다. 많은 사람이 필요하였으며 자동화되지 않은 부분이 존재하였기 때문에 비용이 많이 들었다. 또한 데브옵스에서 이야기하는 개발과 운영 조직 사이의 괴리가 있었고 이 회색지대(Gray Area)를 메우기 위해서 한 쪽의 양보와 희생이 필요했다. 운영을 받는 쪽이 늘 아쉬운 입장이 되었다. 한국에서는 갑을 계약관계에 의한 것이라고 생각하는 편이었다. 파트너라고 불렀지만, 현실은 계약을 수행하는 쪽이 더 책임을 질 수 밖에 없었고, 그래서 더욱 보수적으로 접근했다. 이러한 방식을 크게 깨트리지 않으면서도 조금씩 변화를 주기 위해 노력했다. 몇 년의 시간이 흐르자 차츰 변화가 생겼다. 2012년에는 클라우드 포메이션(AWS CloudFormation) 을 적용했고, 2013년에는 셰프(Chef)^[각주:2]와 AMI(Amazon Machine Image)기반의 불변 서버(Immutable Server) 방식^[각주:3]을 도입하였다. 2016년에는 테라폼(Terraform)과 스핀에커(Spinnaker)를 도입했다. 이 전까지 클라우드 포메이션과 셰프로 구현했던 시스템의 단점을 보완할 수 있었기 때문에 테라폼과 스핀에커로 전환하였고, 이 플랫폼은 사물인터넷(IoT, Internet of Things)과 인공지능(AI, Artificial Intelligence) 서비스의 운영 환경을 효과적으로 개선하였다. 전문 운영 인력 60명이 매월 1회 서비스 배포를 하던 수준에서 소수의 5명이 전 세계 서비스를 매일 배포할 수 있도록 자동화 하였다. 그리고 차츰 개발자에게 배포 버튼을 직접 누를 수 있도록 권한을 열어 주었다. 사물인터넷 클라우드 서비스에 처음 스핀에이커를 적용했을 당시까지만 해도 개발과 운영 조직이 나누어져 있었고 역할이 구분되어 있었기 때문에 운영 팀이 먼저 배포 버튼을 눌러 배포를 해야했었다. 개발자들이 직접 배포를 할 수 있게된 다음 부터 운영 팀은 플랫폼을 개선하는 일에 더 집중하였다.^[각주:4]

삼성에서 데브옵스라는 용어가 자리잡기 전인 2012년부터 꾸준히 준비해 오던 결과물이 여러 사람의 노력으로 어느 정도 모양을 갖추게 되었다. 그리고 우리는 이 것을 데브옵스 플랫폼이라고 불렀다. 데브옵스 플랫폼은 빌더들의 생산성을 높여 주었고, 서비스 개발 운영을 표준화 했다. 가능한 적은 오버헤드로 가치있는 소프트웨어를 만들고 운영할 수 있도록 필요한 기능을 제공하도록 노력했고 다음과 같은 여러 구성요소를 조합하여 플랫폼을 만들었다. 이미 활용 중인 솔루션은 별도로 개발하지 않고 그대로 활용하였다. 대신 단일 사용자 인증(SSO, Single Sign-On)을 사용하여 유기적으로 엮었다. 버전 컨트롤은 GitHub, GitLab, Perforce 등 사용하고 있던 것을 그대로 활용하였으며, 문서 작성과 공유를 위해서 컨플루언스(Confluence)^[각주:5]를 계속 활용했다. 이렇게 함으로써 새로운 플랫폼을 개발하는 데 드는 시간과 사용자가 새로운 시스템에 적응해야 하는 시간을 줄여서 실용적으로 데브옵스 플랫폼을 완성할 수 있도록 했다. 팀 간 소통은 봇을 통한 자동화 지원이 필요해서 슬랙(Slack)을 주로 활용하였으며, 기존 메신저는 일부 영역에서 활용했다. 데브옵스 플랫폼의 핵심 구성 요소를 위해서 인프라스트럭처를 효율적으로 관리하기 위한 테라폼과 테라폼 모듈, 소스 코드 빌드부터 블루/그린(Blue/Green), 카나리(Canary) 배포 워크 플로우(Workflow)를 자동화하는 스핀에커, 시스템 상태를 관측하고 알림을 제공하는 데이터독(DataDog)과 빅터옵스(VictorOps), 그리고 애플리케이션 동작에 대한 로그를 남기고 분석하는 스모로직(SumoLogic)을 신규 적용하였다. 테라폼 모듈과 스핀에커는 오픈소스를 활용하여 개발과 운영을 직접하였고, 데이터독과 빅터옵스, 스모로직은 솔루션을 구매하여 사용하였다. 물론 비용 측면과, 레거시(Legacy) 등 여러 상황을 고려하여 구성 요소을 유연하게 선택할 수 있도록 했다. 만약, 서비스에서 이미 클라우드 포메이션을 사용하고 있다면, 테라폼으로 강제 전환하도록 하지 않았고 대신 스핀에커와 데이터독을 활용할 수 있도록 제안했다. 모니터링을 위해 클라우드 와치(Amazon CloudWatch)를 이미 사용하고 있다면, 빅터옵스를 클라우드 와치에 연동해서 온콜(On-call) 페이저(Pager)로 활용할 수 있도록 지원했다.

두 프로젝트에 성공적으로 데브옵스 플랫폼을 적용한 2018년 이후 플랫폼 엔지니어링 팀은 별도로 분리되어 사물인터넷, 인공지능, 헬스케어(Healthcare), 모바일 광고 등 다양한 서비스를 확대지원했다. 특히 설치 및 관리가 어려운 스핀에커를 SaaS(Software as a Service)로 제공하였으며 각 애플리케이션 담당자들이 스핀에커를 설치하고 관리하는 일에 신경 쓸 필요없이 개발과 운영에 집중 할 수 있도록 했다.^{[각주:6] [각주:7] [각주:8]} 다음 그림은 데브옵스 플랫폼의 구성을 보여준다.

DevOps Platform

데브옵스 플랫폼이 제공된 이후 부터 새롭게 시작하는 프로젝트는 간단하게 DevOps/SRE에서 요구하는 서비스 수준 관측(Service Level), 변경 관리(Change Management), 온콜 및 런북(Runbook), 사후 분석(Postmortem)과 같은 운영 표준을 제공받게 되어, 서비스 런칭 시간과 운영 인력 비용을 줄일 수 있게 되었다. 개발자들은 플랫폼을 자판기처럼 활용하여 원하는 아키텍처를 다양한 클라우드 기반으로 구축할 수 있게 되었고, 자신의 책임에 따라 직접 서비스를 배포하고 롤백(Rollback) 할 수 있게 되었다. 따라서 데브옵스 플랫폼은 개발자 생산성을 높였고, 회사 입장에서는 운영 비용을 절감했다. 그리고 자동화를 통해 서비스 안정성을 높임으로써 고객 만족도 올렸다.

여기까지는 플랫폼의 장점으로 이야기를 것과 크게 다를 것 없었다. 그런데 여기에 추가하고 싶은 데브옵스 플랫폼의 숨겨진 장점이 있다. 개발자들이 직접 운영을 하기 시작하면서, 책임감이 더 높아졌고, 고객에게 서비스를 판매하기 위해서 소프트웨어를 개발하고 관리하기 시작했다는 것이다. 자신이 맡은 기능을 끝까지 책임지고 운영하지 못한다면, 밤새 울리는 온콜 알람을 견디지 못할 것이다. 그러나 남 탓을 할 수도 없다. 더 이상 '내 자리에선 잘 되던데요.'라는 변명이 소용없게 되었기 때문이다.

사실 데브옵스 플랫폼은 데브옵스를 하기 위한 도구일 뿐이며 데브옵스는 고객에게 판매용으로 제공할 소프트웨어 상품을 잘 만들자는 목표를 달성하기 위한 방법이라고 생각하기 때문에, 서비스품질에 대한 개발자들의 태도가 달라 진 것이 가장 뜻깊은 변화라고 생각했다. 음식장사는 쉽지 않고, 요리와 응대를 제대로 하지 못하면 낮은 별점을 받을 것이다. 이럴 때 손님 탓만 하는 가게 주인을 손님들은 어떻게 바라볼 지 당연하다. 마찬가지로, 소프트웨어 개발도 운영도 제대로 하지 못한다면 서비스 수준 지표(Service Level Indicator)는 낮은 점수를 받을 것이고, 별점이 낮은 식당처럼 서비스는 외면 받을 것이다. 그래서 서비스 품질관리에 대한 인식변화는 데브옵스 플랫폼을 통해 얻은 여러 결과 중 가장 의미가 크다고 생각한다.

---

 

1. 가장 대표적으로 아마존 웹서비스(Amazon Web Services) 클라우드 컴퓨팅이 있다. 필요한 만큼 컴퓨팅 자원을 API로 요청해서 사용하다가 사용이 끝나면 간단하게 반납할 수 있다. 도서관에서 책을 빌리듯이 새로운 서비스를 간단하게 실험해 볼 수 있는 환경을 제공받을 수 있으며, 성공 여부에 따라 간단하게 반납을 하면되다. 실패에 대한 부담이 줄어들며, 새로운 시도를 하기 위한 마찰력이 작다. 빠른 시도와 경험 축적은 무엇보다 강력한 힘이 된다 [본문으로]
2. https://youngookkim.tistory.com/7 [본문으로]
3. https://youngookkim.tistory.com/8 [본문으로]
4. 꽤 오랜 시간 인내하며 기다렸던 순간이 마침내 이루어 진 것이다 [본문으로]
5. jira confluence [본문으로]
6. AWS 기반 Microservice 운영을 위한 데브옵스 사례와 Spinnaker 소개 - 김영욱(삼성전자)(https://youtu.be/cfc4or8VH-k?si=4yFgXRjA0qoFG7Wn) [본문으로]
7. Terraform을 기반한 AWS 기반 대규모 마이크로서비스 인프라 운영 노하우 - 이용욱(삼성전자)(https://youtu.be/9PTdO7DM6XQ?si=ej4Um5WeqIPsdmXS) [본문으로]
8. Amazon EKS 기반 삼성 헬스 서비스 구축 사례 - 이상호 선임(삼성전자 Health서비스팀)(https://youtu.be/AebQVeykk8o?si=hH-E03XZkv0-DoG2) [본문으로]