“프로세스가 개발을 방해해서는 안 된다.”
제가 경험한 최고의 팀 중 하나에서, 당시 리더께서 하신 말입니다. “프로세스는 방해가 된다”와는 전혀 다릅니다. 제 식대로 해석하자면, 조직의 의사결정과 개발이 ‘생각할 수 있는 가장 효율적인 방식으로 이루어지도록 안내하는 프로세스를 추구한다’는 뜻이었죠. 그 팀은 반복을 없애고, 실수를 막고, 속도는 높이는 건 당연하고, 다양한 모범사례를 발굴/적용하며 항상 업계 최고 수준의 선진 프로세스를 갖추기 위해 노력했습니다. 끊임없이 고민하면서, 생각이 전진한만큼을 모두와 공유하고, 그 생각대로 움직이는 데 딱 필요한 만큼씩 프로세스를 변형/개선했습니다.
물론 현실이 매 순간 이상과 일치할 수는 없습니다. 어떤 시점에서는, 혹은 어떤 부분에서는 비합리적으로 일하기도 하는 건 어쩔 수 없죠. 사람마다 이상이 다를 수도 있고, 우선순위도 고려하고, 때로는 현실과 타협해야 하는 일도 있었습니다.
그럼에도 리더가 이런 원칙을 가지고 조직을 이끌었기에 대체로 매우 정교하고 효율적인 프로세스를 유지하고 발전시킬 수 있었습니다. 당시 회사는 ‘소프트웨어 엔지니어링’ 부서를 별도로 운영했음에도 우리 팀에는 관여하지 않을 정도로 인정을 받았지요.
개발자에게 이런 훌륭한 리더와 훌륭한 프로세스는 소속 조직에서 제공할 수 있는 최고의 복지 중 하나입니다. 중요하지 않은 일 때문에 스트레스 받지 않고 본연의 일에 집중할 수 있어서, 빠르게 경험하고 성장하는 토대가 되어 주니까요.
‘플랫폼 엔지니어링’은 방금의 옛 이야기가 현대화된 개념입니다. 지금부터 이 생소한 개념을 ‘저의 방식대로’ 소개해 올리겠습니다. ‘개발자를 위한 최고의 복지’, 플랫폼 엔지니어링을 알아가는 여행을 함께 떠나 보아요.
아차! 저는 『구글 엔지니어는 이렇게 일한다』를 번역한 개앞맵시, 이복연입니다.
시대가 변함에 따라 최고의 개발자 복지도 바뀌어 왔습니다.
더 옛날, 스타 개발자들이 혼자서도 뚝딱뚝딱 제품을 완성해 내던 시절에는 농반진반으로 “성능 좋은 컴퓨터와 널찍한 모니터가 최고의 복지다”라고 이야기하곤 했습니다. 느린 컴퓨터와 비좁은 작업 공간이 개발자를 방해하지 않게끔, 즉 ‘개발자가 개발에 몰두할 수 있는 환경’을 만들어주라는 뜻이었죠. 앞의 이야기와 일맥상통합니다.
시간이 흘러 소프트웨어 규모가 커지면서, 긴 호흡으로 여러 사람이 함께 개발하는 시대가 되니 일하는 절차와 소통 방식을 규정하는 ‘프로세스’가 중요해졌습니다. 프로세스가 실제 일하는 방식에 매끄럽게 결합되지 못하면 개발자들이 본연의 일에 몰두할 수 없게 됩니다.
오늘날 소프트웨어는 더 이상 홀로 존재할 수 없습니다. 앱과 서비스는 수많은 외부 시스템과 연결되고, 개발 팀은 글로벌하게 확대되며, 협업 부서는 끊임없이 늘어나고 있습니다. 마치 블록버스터 영화의 엔딩 크레딧처럼, 개발에는 수많은 이름과 시스템이 얽혀 있습니다.
이제 우리는 코드 편집, 빌드, 테스트, 배포 같은 전통적인 도구를 넘어, 리뷰, 지식 관리, 협업까지 아우르는 복잡한 ‘플랫폼 안에서 개발하는 시대’에 살고 있습니다. 바로 이 지점에서 ‘플랫폼 엔지니어링’이 필요해집니다. 이 복잡함 속에서도 개발자가 본질적인 일에 집중하려면 누군가는 플랫폼을 정교하게 설계하고, 운영하고, 끊임없이 개선해야 합니다. 결국 플랫폼 엔지니어링은 개발을 방해하지 않는 프로세스의 실체이자, 개발자 몰입을 가능하게 하는 보이지 않는 복지입니다.
‘플랫폼 엔지니어링’이라는 용어는 최근 몇 년 사이에 급부상했지만 그 근간은 오래전부터 존재해 왔습니다. 사실 많은 조직이 오랜동안 ‘개발자를 돕는 내부 도구’를 만들어 왔습니다. CI/CD 파이프라인을 구성하고, 공통 템플릿을 만들고, 배포 자동화를 구축하는 식으로요. 문제는 이 모든 작업이 뿔뿔이 흩어져 있고 ‘누구를 위한 것인가’라는 명확한 사용자 관점이 빠져 있었다는 점입니다.
그러던 중, 데브옵스가 등장하면서 개발자에게 더 많은 권한과 책임이 부여되었고, 동시에 너무 많은 것을 알아야만 하는 시대가 되었습니다. 배포도, 인프라도, 보안도 알아야 했고, 그에 따라 생산성이 떨어지고 실수는 잦아졌습니다. 결국 개발자들이 묻기 시작했습니다.
이 질문들에 답하기 위해 등장한 것이 플랫폼 엔지니어링입니다. 정의하자면, 플랫폼 엔지니어링은 다음과 같은 활동입니다.
“개발자가 반복적이고 비효율적인 작업에서 벗어나, 본질적인 개발에만 집중할 수 있도록 조직 차원의 내부 플랫폼을 설계하고 운영하는 일.”
이때의 ‘플랫폼’은 조직 내부의 개발자 플랫폼(Internal Developer Platform, IDP)을 의미합니다. 쉽게 말해, 개발자들이 인프라나 도구를 직접 다루지 않고도 필요한 작업을 자율적으로 처리할 수 있는 셀프서비스 환경입니다.
플랫폼 엔지니어링의 핵심 구성 요소는 다음과 같습니다.
좋은 플랫폼 엔지니어링은 마치 ‘보이지 않는 손’처럼 작동합니다. 개발자는 뭔가 특별한 도움을 받는다는 느낌 없이 자연스럽게 최적의 환경에서 일하게 됩니다. 마치 공기처럼 당연하게 존재하지만, 없으면 곧바로 불편을 느끼게 되는 그런 시스템이죠.
그리고 이 모든 것은 결국 ‘개발을 방해하지 않는 프로세스’를 만들기 위한 실천입니다.
구분 | 데브옵스 | 플랫폼 엔지니어링 |
핵심 개념 | 개발과 운영의 협업 문화를 통해 소프트웨어 전달을 자동화하고 개선 | 개발자가 효율적으로 일할 수 있도록 내부 개발 플랫폼(IDP)을 설계하고 제공 |
주요 대상 | 개발자 자신이 수행 주체이며 데브옵스 문화와 도구를 직접 책임짐 | 개발자가 고객이며, 플랫폼 팀이 효율적인 도구와 워크플로를 제공 |
관점 | “내가 더 잘 배워서, 더 잘 자동화하자” | “개발자가 도구와 인프라 고민 없이 개발에 집중하도록 하자” |
구현 방식 | CI/CD, IaC, 모니터링 등을 개발자가 주도적으로 설정 | CI/CD 파이프라인, 템플릿, 셀프서비스 포털 등을 플랫폼 팀이 설계 및 유지보수 |
개발자의 역할 | 도구 설정, 배포 자동화, 모니터링 등도 직접 담당 | 제공된 플랫폼 위에서 비즈니스 로직 개발에 집중 |
팀 구조 | Dev + Ops 협업 팀이거나, Ops 역할을 개발자가 겸하는 경우 많음 | 별도의 플랫폼 팀이 존재 (일종의 내부 서비스 조직) |
기대 효과 | 개발자 주도적인 자동화 문화 정착 | 생산성 향상, 온보딩 시간 단축, 신뢰성 있는 배포 환경 제공 |
개발자에게 X란? | 자유도는 높지만, 설정/운영에 드는 부담이 큼 | 개발에만 집중할 수 있는 환경을 제공받음 더 빠르고 안전한 배포 가능 |
그렇다면 우리 주변의 어떤 회사들이 플랫폼 엔지니어링을 잘 실천하고 있는지, 그 사례를 함께 보겠습니다.
플랫폼 엔지니어링은 ‘개발자 중심의 프로세스 설계’라는 철학을 어떻게 실천하느냐에 따라 성패가 갈립니다. 자동화를 몇 개 구축하는 걸로는 부족합니다. 핵심은 플랫폼을 직원들에게 서비스하는 제품처럼 대하는 태도, 그리고 개발자를 진짜 고객으로 바라보는 시선입니다.
이 철학을 일찌감치 실천해 온 대표적인 기업들을 살펴보면 공통된 특징이 보입니다.
스포티파이는 수많은 개발자 팀이 동시에 다양한 서비스를 운영하는 복잡한 구조를 갖고 있습니다. 이런 환경에서 생길 수 있는 가장 큰 문제는 ‘어디서부터 어떻게 시작해야 할지 몰라서 헤매는 시간’입니다.
그래서 스포티파이는 ‘골든 패스(Golden Path, 황금 경로)’라는 개념을 도입했습니다. 골든 패스는 일종의 ‘모범 사례를 담은 셀프서비스 가이드라인’입니다. 팀이나 개발자가 서비스를 새로 만들거나 배포할 때, 이 ‘황금 경로’를 따르면 빠르고 안전하게 작업을 끝낼 수 있도록 설계돼 있습니다.
여기서 중요한 점! 골든 패스는 강제가 아니라 ‘선택 가능한 기본값’입니다. 스포티파이는 “잘 일할 수 있는 기본 경로를 제공하되, 자율성을 침해하지 않는다”는 원칙을 지켰습니다. 그래서 플랫폼이 ‘방해물’이 아닌 ‘안내자’ 역할을 하게 되었죠.
넷플릭스는 ‘개발자가 직접 인프라를 관리하지 않아도 되는 시스템’을 만드는 데 집중해 왔습니다. 대표적으로 ‘포장 도로(Paved Road)’라는 이름의 플랫폼을 운영합니다. 마치 포장된 도로 위를 달리듯, 개발자는 신경 쓸 것이 거의 없이 바로 기능 개발과 배포에 몰입할 수 있습니다. 예를 들어, 새로운 서비스나 기능을 만들면 다음 작업들이 자동으로 처리됩니다.
이 시스템이 가능했던 이유는 넷플릭스가 플랫폼 팀을 내부 개발자의 생산성을 높이기 위한 제품 팀처럼 운영했기 때문입니다. 즉, 플랫폼을 만든 팀이 개발자를 고객으로 보고, 고객 경험을 끊임없이 개선한 것이죠.
구글은 개발자 경험을 진지하게 바라보는 대표적인 회사입니다. 심지어 ‘개발자(엔지니어링) 생산성 팀’이라는 전담 조직이 존재합니다. 이 팀은 엔지니어링 생산성을 수치로 분석하고, 병목을 파악해 지속적으로 개선합니다.
유명한 사례로는 빌드 시스템인 Blaze와 오케스트레이션 시스템인 Borg가 있습니다. 내부 개발자가 빠르게 빌드하고 어디서든 안정적으로 서비스가 실행되도록 하기 위한 플랫폼이죠. 두 시스템은 나중에 오픈소스로 재탄생해 바젤(Bazel)과 쿠버네티스가 되었습니다.
이처럼 구글은 플랫폼 엔지니어링을 단지 효율화 도구로 보지 않고, 조직의 기술 경쟁력을 만드는 근본 인프라로 인식하고 있습니다.
이상의 회사들은 규모도 크고 자본도 많기에 가능한 일 아니냐고요? 어느 정도는 그럴 수 있습니다. 하지만 주목할 건 ‘도구’가 아니라 ‘태도’입니다.
조직 규모와 무관하게 오늘부터도 곧바로 적용할 수 있는 원칙들입니다. 그리고 이제 우리는 압니다. 플랫폼 엔지니어링은 ‘어떤 기술을 쓰느냐’보다 ‘개발자를 어떻게 대하느냐’의 문제라는 것을요.
이 글을 시작하며 “프로세스가 개발을 방해해서는 안 된다”는 말을 소개했습니다. 이제는 이 문장을 다음처럼 바꿔도 무리가 없을 것 같습니다.
“플랫폼이 개발을 방해해서는 안 된다.”
플랫폼 엔지니어링은 본래 개발을 더 빠르고, 더 정확하고, 더 쉽게 만들기 위해 존재합니다. 그런데 현실에서는 오히려 개발자의 발목을 잡는 일도 꽤 자주 벌어집니다.
이런 시스템 하에서는 개발자들이 점점 ‘플랫폼을 우회하거나 회피하려는 경향’을 갖게 됩니다. 플랫폼 엔지니어링의 실패를 의미하죠. 플랫폼이 제공하고자 했던 가치, 즉 몰입, 속도, 일관성을 하나도 전달하지 못했기 때문입니다.
좋은 플랫폼은 ‘곧게 뻗은 도로’처럼, 분명 존재하지만 의식되지 않습니다.
이 모든 요소는 기술보다 ‘경험 설계’에 가깝습니다. 좋은 플랫폼은 결국 사용자인 개발자의 입장에서 끊임없이 고민한 결과입니다. 그리고 이건 단순한 기술 과제가 아니라, 철저한 서비스 마인드가 있어야 가능한 일입니다.
강제적인 프로세스는 쉽게 무너지고 회피됩니다. 하지만 좋은 가이드는 사람을 움직이게 합니다. 그 길이 더 빠르고 편하다는 걸 사용자가 느낄 수 있기 때문이죠. 앞에서 본 스포티파이의 골든 패스, 넷플릭스의 포장 도로가 좋은 예입니다. “이 길을 따르라”고 명령하지 않고, 대신 “이 길을 따라가면 더 빠르게, 더 잘할 수 있다”는 걸 몸소 느끼게 합니다.
결국 좋은 플랫폼은 개발자에게 자율성, 안심, 속도를 동시에 제공합니다. 이것이 진정한 의미에서 ‘개발을 방해하지 않는 플랫폼’입니다.
좋은 플랫폼의 효과는 개발자 개인의 몰입에서부터 시작하여 조직 전체의 역량 강화로 이어집니다. 단기적으로는 개발 효율을, 장기적으로는 조직의 기술 체력을 끌어올리는 기반 인프라인 셈이죠.
빠른 컴퓨터와 광활한 모니터만으로 개발자들이 만족하던 시절은 지났습니다. 오늘날의 개발자들은 일에 몰입할 수 있는 구조, 본질에 집중할 수 있는 환경, 일 잘하는 사람으로 성장하도록 돕는 시스템을 원합니다. 그래서 글을 맺으며 이렇게 말하고 싶습니다.
“플랫폼 엔지니어링은 개발자를 위한 최고의 복지이자, 그 복지를 실현하는 리더십이다.”
개발자가 매일 마주하는 도구와 인프라, 그 설계 철학이 곧 조직의 일하는 방식을 정의합니다. 더 나은 플랫폼은 더 나은 팀을 만들 수 있습니다. 여러분이 조직의 리더라면 지금 당장 플랫폼 엔지니어링도 고민해 주세요. 여러분이 개발자라면 더 나은 개발 환경을 당당히 요구해 주세요. 그 선택이 우리 모두를 더 나은 미래로 빠르게 이끌 것입니다.
마침 좋은 책이 나왔습니다. 정직한 이름, 『플랫폼 엔지니어링』. 이 책은 지금까지의 제 소개와 달리, 실무 관점에서 플랫폼 엔지니어링을 깊이 이해하고 실천할 수 있게 안내합니다. 아직은 낯설고 정보가 부족해서 용기가 나지 않는다면, 혹은 단순히 흥미가 생겨 더 알아보고 싶다면, 이 책이 좋은 안내자가 되어줄 것입니다.
관련 콘텐츠
최신 콘텐츠
