요즘 인프라 쪽에서 주목을 많이 받는 분야 중 하나가 "플랫폼 엔지니어링"이다. 어쩌다 보니 회사 업무로 배포 시스템을 만들면서 플랫폼으로 커지면서 어느 순간 플랫폼 엔지니어링이라는 용어를 만나게 되었다. 내가 하고 있어서 더 그렇게 느낄 수 있지만 의외로 국내에서도 꽤 빠르게 플랫폼 엔지니어링이라는 분야가 많은 회사에서 관심을 받고 있다.

운 좋게 꽤 일찍부터 플랫폼 엔지니어링을 고민하다 보니 관련한 생각을 한번 정리하면 좋겠다고 생각하게 되었다. 플랫폼 엔지니어링이란 게 꽤 넓은 분야이긴 한데 지금 회사에서 사이트 신뢰성 엔지니어로 일하고 있다 보니 인프라적인 관점에 많이 치우쳐져 있긴 하다. 이 글에 내용과 직접적 관련은 없지만 내가 그동안 참여했던 개발자 플랫폼이 어떤 형태로 만들어져 있고 플랫폼 엔지니어링 관련해서 어떤 발표를 했는지는 다음 발표에서 볼 수 있다.

Platform Engineering

대부분의 기술 용어가 완전히 새로운 접근 방법을 정의한다기보다는 이미 업계에서는 많이 하던 관행을 용어로 정리하는 경우가 많다. 플랫폼 엔지니어링이란 접근방법도 새로 나왔다기보다 오랫동안 많은 시도를 했던 Google, Meta, Netflix 등 빅테크 회사들이 DevOps를 더 잘하기 위해서 시행착오를 겪으면서 만든 접근 방법이 업계 밖으로 나오면서 플랫폼 엔지니어링이란 용어로 정리가 되었다고 생각하는 편이다. 그리고 플랫폼 엔지니어링이라는 말은 새로운 용어라고 생각하기 어려울 정도로 쉬운 용어이기 때문에 누가 만들었는지도 명확하지 않고 누구나 플랫폼 엔지니어링이라는 말을 들었을 때 "그게 뭔데?"라고 하기보다는 각자 머릿속에 플랫폼 엔지니어링을 정의할 것이다.

platformengineering.org을 보면 다음과 같이 플랫폼 엔지니어링을 정의하고 있다.

클라우드 네이티브 시대의 소프트웨어 엔지니어링 조직을 위해 셀프서비스를 가능하게 하는 툴 체인과 워크플로를 설계하고 구축하는 분야이다.
플랫폼 엔지니어는 애플리케이션의 전체 생명 주기를 운영하는 데 필요한 내부 개발자 플랫폼(IDP, Internal Developer Platform)을 제공한다.
IDP는 필수적인 컨텍스트와 기반 기술을 유지하면서 개발자의 인지 부하를 줄일 수 있도록 다양한 기술과 도구를 포함해서 개발자 셀프서비스를 가능하게 한다.
플랫폼 엔지니어링을 올바르게 수행한다는 것은 IDP를 사용하는 개발자가 원하는 추상화 수준과 맞는 골든 패스와 포장된 도로를 제공하는 것이다.

여러 용어가 포함되어 있기는 한데 내가 이해하는 접근방법과 해결하려는 문제는 아래와 같다.

DevOps가 등장한 이후 업계에 기본적인 접근으로까지 자리 잡았지만, 복잡해지는 인프라와 기술로 인해서 점점 소프트웨어 엔지니어가 겪는 인지 부하가 너무 높아졌고 그로 인해서 제대로 DevOps를 하기가 어려워졌다. 이러한 문제를 해결하기 위해 복잡성을 어느 정도 추상화하는 IDP를 만들어서 인지부하를 낮추고 인프라 지원 조직이 업무를 처리해 주지 않고도 소프트웨어 엔지니어가 직접 할 수 있도록 셀프서비스를 제공해서 개발 속도와 생산성을 높인다.

플랫폼 엔지니어링을 포함해서 기술 업계에 나오는 용어는 개념을 정리하고 커뮤니케이션을 편하게 하는 장점도 있지만 마케팅적인 의도도 있다. 새로운 접근 방법이 나오면 순수하게(?) 문제 해결을 위해서 접근하는 사람도 있지만 컨설팅이나 스타트업 등 해당 분야로 돈을 벌기 위해서 접근하는 사람들도 있게 마련이다.(이게 꼭 나쁘다는 것은 아니다.)

용어가 어떻게 만들어졌든지 간에 마케팅적으로 효과를 내기 위해서는 정의를 약간 두루뭉술하게 해서 커버리지는 높이는 접근을 한다고 생각하는 편이다. 정의를 너무 명확하고 좁게 하면 고객의 범위도 줄어들기 때문에 이것도 저것도 다 플랫폼 엔지니어링이라고 해서 전체 파이를 크게 만드는 게 사용자도 많이 끌어들일 수 있기 때문에 복잡한 이해관계가 얽혀있는 편이다.

플랫폼 엔지니어링이라는 접근 방법이 꽤 좋다고 생각하고 계속 공부하고 있지만 마케팅적인 목적에서는 비슷한 현상이 있다고 생각하고 있다. 개인적으로 이런 거에 약간 거부감이 있어서 전에는 의도적으로 이 용어를 잘 사용하지 않다가 이젠 국내에서도 많이 사용되는 용어가 되어서 지금은 나도 같이 사용하고 있다.

어쨌든 운 좋게 그동안 플랫폼 엔지니어링 분야에 일찍 관심을 가지게 되었고 그동안 고민하면서 만들어왔기 때문에 플랫폼 엔지니어링에서 IDP가 어떠해야 하는지 정리해 봤다.

Opinionated Platform 이어야 한다

보통 "a 'right' way of doing things"라는 개념을 가지고 다양한 방법의 자유도를 주기보다는 올바른 방법을 강하게 유도할 때 Opinonated라는 말을 많이 사용한다. 나는 IDP는 Opinionated 해야 한다고 생각한다.

이건 범용적인 것이 아니라 현재 회사의 상황에 딱 들어맞는 맞춤형 플랫폼이다. 서비스의 성격, 엔지니어들이 겪는 문제, 가장 불편한 부분, 회사가 가진 기술 스택에 딱 맞춰서 해결하려는 것이기 때문에 다양한 사례를 고려하기보다는 올바른 방법을 찾아서 일관성을 유지하고 개선해야 한다. 그래서 나는 보통 80~90%의 요구사항만 커버하려고 생각하고 새로운 요구사항이 생길 때 구현 여부를 조직 내에 이 기능의 적용 범위가 어느 정도인지를 생각하고 있다. 나머지 10~20%는 의도적으로 플랫폼에서 다루지 않으려고 하고 수동으로 처리하거나 다른 방법으로 해결하려고 하고 있다.(아예 안 해줄 수는 없다.)

그냥 오픈소스 프로젝트를 가져다가 설치하는 것이 아니라 IDP를 만든다는 것은 그런 의미라고 생각하고 그래야 전사 엔지니어가 얻는 혜택도 커진다.

또한, 오픈소스 프로젝트도 다양하게 있지만 그 성격상 Opinionated를 표방하는 프로젝트일지라도 상당히 범용성을 가질 수밖에 없다. 기본적으로 사용자가 많고 그에 따른 엣지 케이스도 많기 때문에 모든 걸 다 해결해 주진 않는다더라도 상당한 범용성을 가지게 된다. 회사에서 겪는 문제는 그보다 특정하기가 쉽다고 생각하기 때문에 어떤 부분에서는 적은 인력으로 짧은 시간 내에 IDP를 구현해서 오픈소스보다 더 문제를 잘 해결해 낼 수 있다고 생각하고 그렇기 위해서는 Opinionated Platform이어야 한다.

다른 말로 하면 작은 기능 하나에도 이 기능을 통해서 사용자가 어떻게 행동했으면 좋겠는지 확실한 의도가 담겨 있어야 한다. 그래야 해당 기능이 의도대로 동작하고 있는지 빠르게 피드백도 받을 수 있고 의도한 베스트 프렉티스가 정말 베스트 프렉티스인지도 검증할 수 있다. 회사의 상황이나 서비스의 상황도 계속 달라지기 마련이므로 전에는 베스트 프렉티스였는데 이젠 아닐 수도 있다. IDP는 "뭘 좋아할지 몰라서 다 준비해 봤어요"여서는 안된다고 본다.

미래 지향적이어야 한다

IDP로 어떤 문제를 해결하려고 하든지 간에 그 해결 방향은 지금의 문제를 푼다기보다 미래지향적이어야 한다. IDP로 얻을 수 있는 장점 중 하나는 일관성이다. 예를 들어 어떤 설정이 파편화되어 있다면 지금 수많은 곳에서 그 파편화 문제를 겪고 있겠지만 지금 새로 만든다면 어떤 모양이 가장 좋은지를 고민하고 앞으로 생기는 설정은 항상 베스트 프렉티스를 따르고 파편화가 생기지 않아야 한다. 지금 레거시를 고려 안 할 수는 없지만 너무 고려하면 IDP를 사용하고 나서도 문제 해결이 제대로 안될수 있다.

현재 겪고 있는 레거시 문제가 꽤 크게 느껴지기 때문에 이를 얼마나 무시해야 할지 두렵기도 하고 많은 고민이 들지만 IDP를 만들면 IDP를 앞으로 사용할 시간이 더 크다는 생각으로 해결 방법을 고민하는 게 경험상으로 훨씬 좋은 결과가 있었다.

단점을 가릴 수 있는 혜택을 제공한다

기능을 구현할 때 실제로 좋은 방향으로 잘 가고 있다고 하더라도 플랫폼으로 일관화한다는 것은 일부 엣지 케이스를 버린다는 의미가 된다. 그렇기 때문에 도입 과정에서 엣지 케이스를 못 다루면서 불만의 목소리가 나올 수 있다. 이런 부분을 상쇄하려면 단점보다 제공할 수 있는 혜택이 훨씬 커서 단점을 가릴 수 있어야 한다.

추상화하면 기능이 어느 정도 획일화되기 때문에 불편함이 생길 수밖에 없고 어떤 정책은 의도적으로 불편함을 줄 수밖에 없는 부분도 있다. 가능한 혜택을 함께 제공하려고 노력하지만, 그럴 수 없는 기능에는 다른 편의 기능과 릴리스 시점을 맞추어서 단점이 잘 안 보이도록 해야 한다. 기본적으로 이 플랫폼이 계속 우리를 불편하게 한다는 인식이 안 생기도록 해야 한다. 사용자에게 정보를 업데이트하는 등의 동작을 유도하기 위해서 불편함을 줄 수도 있고 편리함을 줄 수도 있다. 나는 IDP가 긍정적인 인식을 줘야 한다고 생각하기에 가능하면 편리함을 줄 수 있는 넛지(Nudge)를 먼저 고려하고 그게 안 될 때만 불편함으로도 행동을 유도하게 하고 있다.

프로세스를 새로 정의해야 한다

기본적으로 IDP는 기존에 하던 일을 그대로 자동화해서 UI를 붙여놓은 것이 아니라 처음부터 새로 고민해야 한다.

개발자에게 물어보세요라는 책을 보면 일본의 한 대학에서 청구서 처리를 자동화하는데 기존에는 왼쪽에 청구서를, 오른쪽에 명세서를 놓고 비교하면서 처리하고 있었는데 이를 솔루션으로 만들면서 요구사항이 화면 왼쪽에는 청구서가 나오고 오른쪽에는 명세서가 나와서 운영자가 클릭해서 처리할 수 있게 해달라는 사례가 나온다.(책 124 페이지)

당연히 소프트웨어에서는 이렇게 할 필요가 없고 그냥 자동 비교해서 맞지 않는 숫자만 보여주는 등의 방법이 가능하다. 이렇게 읽어보면 우스워 보이는 사례일 수 있지만 현실에서 이런 상황은 꽤 자주 마주하게 된다. IDP는 기존에 하던 일이 그대로 자동화만 좀 하는 것이 아니라 프로세스 자체를 다시 검토하고 사용자가 보지 않아도 되는 절차가 있는지를 계속 고민해서 없애서 프로세스를 간단하게 만들어야 하고 그러면 사용성도 올라가게 할 수 있다.

사람들은 원인보다는 해결책을 들고 찾아오는 경향이 있다. "OO를 설치해 주세요."라거나 "OO 기능 사용할 수 있나요?" 같은 어떤 문제를 해결하기 위해 나름대로 고민하고 찾아본 해결책을 들고 찾아오게 된다. 이럴 때 이 요구사항을 그냥 받거나 거절하는 게 아니라 만나서 왜 그런 기능이 필요한지, 어떤 문제가 있는지를 찾아낼 수 있어야 한다. 앞에서 요구사항의 8~90%만 커버한다고 했는데 결국 이런 식으로 실제 문제상황을 모으고 그런 문제를 근본적으로 잘 해결할 방법을 고민해야 제대로 해결할 수 있다.

사용자의 요구사항만 수집하는 게 아니라 그걸 바탕으로 상당한 직관을 사용해야 한다. "People don’t know what they want"라는 스티브 잡스의 유명한 말처럼 사람들에게 불편한 점이나 해결해야 할 문제를 불으면 꽤 자질구레한 얘기가 나오기 마련이고 이런 게 문제를 재정의해서 해결하려면 기능을 어떻게 제공할지 직관적으로 선택해야 한다. 스타트업도 그렇듯이 어떤 제품이나 서비스도 사용자의 모든 요구사항을 해결해 주는 곳은 없고 실제로 그렇게 한다고 해도 제품은 특징이 전혀 없어서 매력적이지 않은 서비스가 된다.

추상화 수준에 대한 끝없는 고민

IDP를 만들면 인프라 관련한 디테일을 추상화해서 감추게 된다. 그러면 자연히 얼마나 추상화할지 즉, 무엇을 감추고 무엇을 감추지 않을지에 대한 고민으로 이어지게 된다. 간단한 예시로 Kubernetes를 쓴다면 Pod이라는 용어를 그대로 사용할지, 이건 Kubernetes에 있는 개념이니까 Kubernetes를 모를 수도 있다는 전제로 다른 친숙한 용어로 바꾸어서 제공할지 같은 고민이 남게 된다. 더 크게는 Kubernetes로 운영하는 것조차 몰라도 될 정도로 추상화할지 같은 고민이 된다.

회사의 엔지니어 수나 엔지니어들의 역량 수준 등 회사마다 다르기 때문에 정답은 없다. 그럼에도 내가 지금 가진 결론은 어느 정도 추상화를 하지만 IDP를 계속 사용하면서 인프라에 대한 이해도가 높아질 수 있도록 교육할 수 있는 플랫폼이 되어야 한다는 것이다. 외부 SaaS는 아니기 때문에 너무 과도한 추상화는 만들기 어렵기도 하고 기본적으로 트러블 슈팅등 너무 다 감추는 것은 좋지도 않을뿐더러 시간이 지나면서 전체 엔지니어의 역량이 높아질 수 있어야 더 좋다.

그래서 오늘 입사한 사람도 쓸 수 있어야 하지만 어느 정도 인프라를 노출해서 내부를 이해할 수 있도록 돕고자 한다. 처음에는 더 많은 추상화를 하려고 했지만 결국 내부 플랫폼이니 때문에 문제상황을 같이 살펴보고 설명하면서 인프라 디테일을 설명하게 되고 사내 엔지니어도 이를 이해하는 게 더 좋다는 결론으로 이어졌다. 그럼에도 기능마다 어디까지 노출할지는 항상 어려운 문제다.

스타트업처럼 움직여야 한다

IDP를 만드는 조직은 사내 엔지니어가 고객이 된다. 스타트업처럼 움직여야 한다는 것은 고객의 요구사항을 잘 해결해 주어야 하고 실제 해결했는지 계속 봐야 한다는 것이고 제품 품질이 외부에 있는 SaaS 수준과 비교해도 떨어지지 않아야 한다.

IDP를 만드는 조직이 내부 조직이고 그 특성상 관련한 인프라에 대한 정책을 정하거나 관리할 수 있는 위치에 있을 가능성이 높다. 그렇기 때문에 사내에 반발이 있을지라도 인프라 조직에서 새 솔루션을 만들거나 이를 쓰라고 하면서 강제할 수 있기도 하다. 이러면 잘못하면 제공자의 함정에 빠져서 해결 방법을 제공하는 데 만족하고 실제로 사용자들이 만족하고 있는지는 제대로 파악하고 있지 못할 가능성이 크다. 실제 스타트업이라면 해당 솔루션이 만족하지 않으면 바로 떠나버리겠지만 사내에서는 그럴 수 없기 때문에 사용자의 요구사항을 파악할 수 있는 장치를 마련해 두고 사용자가 만족하지 못하는 부분을 빠르게 대응해서 해결해 주어야 한다.

스타트업처럼 움직여야 한다고 모두 똑같은 건 아니고 사내이기 때문에 취할 수 있는 장점이 있다. 외부 스타트업이라면 고객을 유치하기 위한 많은 마케팅을 해야 하지만 IDP는 굳이 그럴 필요는 없고 사용자가 플랫폼을 떠날 때 찾아가서 어떤 부분이 불편한지, 어떤 문제가 해결되었으면 하는지 물어볼 수 있다. 그리고 불특정 다수를 만족시키는 게 아니라 정해진 수의 사내 엔지니어의 문제를 해결해 주는 것이기 때문에 문제 파악이나 해결 방법을 찾는 것도 더 유리하다는 장점도 있다.

사내 조직이라는 장점을 최대한 활용하면서 외부 SaaS와 비슷한 품질로 만들어야 한다.

DevEx

보통 사용자 경험(UX)이라고 얘기하지만 여기서는 고객이 개발자이기 때문에 더 강조하는 의미로 DevEx라고 보통 얘기한다. 결국 플랫폼의 고객이 만족해야 하는 것이기 때문에 DevEx는 무엇보다 중요하다. 위에서 외부 SaaS와 비슷한 품질이라고 얘기한 것을 개발자 경험도 우리가 아는 AWS, Vercel, Cloudflare 등을 기준으로 해야 하고 익숙하거나 좋아하는 SaaS와 비교하는 것도 좋은 방법이다.

개발자 경험을 좋게 하는데 기능의 설계도 당연히 중요하지만, UI도 중요하다. 이쁜 UI가 좋은 개발자 경험과도 이어진다고 생각하는 편이라 디자이너는 아니지만 가능하면 이쁘게 만들려고 노력한다. 인프라 조직에 디자이너를 두기 어려울 수 있지만 그래도 요즘은 디자인 키트가 공개된 게 많아서 꽤 좋은 퀄리티로 만들 수 있다. 버튼의 여백이 너무 좁다거나 아이콘의 정렬이 안 맞는다거나 하나하나 다 신경 써서 만드는 게 좋은 플랫폼을 만들 수 있다고 생각하는 편이다.

앞에서 말한 대로 오늘 입사한 사람도 바로 사용할 수 있을 정도로 UI가 편해야 한다. 어떤 서비스를 사용할 때 문서를 읽어본 다음에 사용하는 사람은 거의 없다. 대부분은 화면의 버튼을 클릭해 보면서 사용하다가 해결 안 될 때 문서를 찾아보면서 사용할 것이다. 개인적으로 사내에서는 문서에 너무 의존한다고 생각하는 편이고 대표적인 제공자의 함정에 빠진 경우라고 생각한다. 어떤 부분에 대해 문의했을 때 "문서에 적혀있어요."라는 답변은 문의한 쪽에 허탈감만 준다.

IDP를 만들어서 UI를 만든다면 이러한 문제를 상당 부분 해결할 수 있다. 결국은 문서를 제공해야 하겠지만 문서를 보지 않고도 대부분의 기능을 사용할 수 있어야 하고 용어나 기능에 대한 설명도 문서에 의존하기보다는 UI에서 설명을 제공하거나 툴팁을 제공해서 플랫폼을 이용하면서 바로 이해할 수 있어야 한다.

다양한 플랫폼을 만들어 본 것은 아니지만 그동안 시도해 보았을 때는 한사람이 처음부터 끝까지 만드는 게 훨씬 좋았다. 여기서 처음부터 끝까지라는 것은 백엔드나 파이프라인 기능을 만드는 사람이 UI까지 다 만들어서 처음부터 사용자가 어떻게 사용했으면 좋겠는지 고민하고 만들어야 좋은 DevEx를 제공할 수 있다. 조직의 특성일 수 있지만 PM이나 디자이너가 따로 있지 않기 때문에 프론트엔드와 백엔드의 역할을 나누어서 작업했을 때 작업도 더 비효율적이고 결과도 좋지 않다고 느껴졌다.

마이그레이션

플랫폼을 만들 때 마이그레이션은 아주 중요하므로 처음부터 함께 고려해야 한다.. 어느 시점에 만들든 간에 기존 레거시가 있기 마련이고 플랫폼으로 일관된 정책이나 사용 방법을 강제하더라도 기존에 있던 레거시나 예외 상황으로 생기는 파편화는 계속 있게 마련이다. 앞에서 레거시보다는 앞으로 필요한 베스트 프렉티스에 더 집중해야 한다고 했지만, 이는 설계의 기본 접근일 뿐 실제로 마이그레이션을 무시할 수 없다. 실제로는 무시할 수 있는 정도가 아니라 마이그레이션이 플랫폼을 만드는 것보다 더 어려운 경우가 많다.

플랫폼을 만들었는데 마이그레이션이 되지 않는다면 결국 혜택받는 사람들의 제한이 있을 수밖에 없고 플랫폼을 만드는 조직도 추진력을 잃을 수밖에 없다. 플랫폼이 상당 부분을 추상화했으므로 사용자에게 영향을 주지 않고 마이그레이션을 할 수 있으면 제일 좋고 그렇지 않다면 별도로 지원해서라도 마이그레이션을 지속적으로 해야 한다. 경험상 마이그레이션은 결국 시간을 상당히 들여서 수동으로 해야 하는 노가다 작업이기 때문에 IDP를 만드는 조직에도 상당한 부담을 줄 수밖에 없지만 그럼에도 마이그레이션을 업무의 중심에 두어서 지원해야 한다.

기능을 설계할 때부터 마이그레이션을 편하게 할 수 있도록 고려해야 하고 그에 따라 기술 선택이나 설계가 달라질 수도 있다. 이상적으로는 플랫폼이 만들어지고 파편화된 게 다 마이그레이션 되어서 플랫폼 개발에만 집중하는 것이겠지만 현실에서는 새로운 요구사항과 예외 케이스도 계속 등장하고 플랫폼도 점점 변화하기 때문에 마이그레이션을 그냥 항상 있다고 생각하는 게 오히려 낫다.

또한 마이그레이션에는 최신화도 포함된다. 프로젝트의 담당 부서 정보라거나 프로젝트 설명, 사용하지 않는 리소스의 정리 등 회사도 계속 변화하기 때문에 시간이 지나면서 많은 것들이 낡아버리게 된다. IDP의 기능적으로 이렇게 낡은 정보가 많아지지 않도록 기능적으로 고려하는 게 좋고 그렇지 않다면 전부 마이그레이션의 부담으로 쌓이게 된다. 결국 기능을 설계할 때부터 마이그레이션을 포함해서 최신상태가 계속 유지될 수 있도록 고민을 해야 한다.

결론

개인적으로 플랫폼 엔지니어링 접근법이 꽤 괜찮다고 생각하고 있고 그동안 복잡한 인프라의 문제를 꽤 잘 해결할 수 있다고 생각한다. Mercari의 Platform Engineering도 보면서 동의를 많이 했기에, 이 발표 자료를 참고해 봐도 좋다.

마지막으로 강조하고 싶은 건 플랫폼 엔지니어링 접근은 레버리지가 꽤 높은 작업이라는 점이다. 요구사항에 따라 다르겠지만 요즘처럼 오픈소스 프로젝트나 공개된 자료가 많은 상황에서 플랫폼을 만드는 노력은 많이 들지 않지만 사내 엔지니어가 50명이든, 100명이든 그 혜택은 아주 크다고 생각한다. 어떤 도구를 만들어서 사내 엔지니어의 10분을 아껴줄 수 있다면 전사적으로 생각하면 회사에서 충분히 시도해 볼만한 작업이다. 플랫폼이라고 해서 시작할 때부터 아주 거창하게 시작할 필요는 없고 조직 내에서 가장 불편하다고 생각되는 문제를 하나씩 해결해 가면서 키워나갈 수 있다.

Outsider's Dev Story

내가 생각하는 플랫폼 엔지니어링