2023년 11월 21일, AWSKRUG에서 처음으로 플랫폼 엔지니어링 모임이 열렸습니다. 플랫폼 엔지니어링이라는 단어를 보자마자 이거다! 환호하며 바로 신청했고, 기다리던 모임에 참석했습니다. 그리고 모임에서 듣고 나눴던 이야기를 잊지 않도록 집에 들어오자마자 바로 정리해보았습니다.
플랫폼 엔지니어링이란 무엇인가?
플랫폼 엔지니어링이란?
플랫폼 엔지니어링은 클라우드 네이티브 시대에 소프트웨어 엔지니어링 조직의 작업을 촉진하고 가속화하기 위한 플랫폼을 설계하고 제공하는 분야입니다. 이는 모든 부분과 그에 대한 역량, 즉 사람, 프로세스, 정책, 기술을 포괄합니다.
다시 말해, 플랫폼 엔지니어링의 목적은 "소프트웨어 엔지니어링 조직이 일을 더 빠르게 잘 할 수 있도록 하는 것"이고, 그 문제를 "플랫폼"을 통해 해결해나갑니다.
여기까지 읽으면 사실 DevOps와 큰 차이가 없다고 느껴질 수 있습니다. DevOps 역시 애플리케이션을 빠르게 제공할 수 있도록 여러 방법을 이용해서 지원하고자 하거든요.
DevOps란?
애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합
출처 : https://aws.amazon.com/ko/devops/what-is-devops/
사실 플랫폼 엔지니어링은 이 DevOps에서 한 걸음 더 나아간 형태입니다. 개발과 운영 조직의 비효율성을 문화와 도구들을 이용해 해결하려는게 DevOps이고, 플랫폼 엔지니어링은 DevOps의 도구로 '플랫폼'을 채택한 것이라 볼 수 있습니다.
플랫폼 엔지니어링 팀은 DevOps 방법론 위에서 소프트웨어 엔지니어링 팀, 프로덕트 팀을 지원할 수 있는 플랫폼을 만듭니다. 일반적으로 플랫폼이라고 말하면 인프라부터 공통 모듈, API까지 모두 묶어서 이야기하는데요, 플랫폼 엔지니어링 팀이 만드는 플랫폼 역시 큰 틀에서 같은 구조를 가집니다.
왜 지금 플랫폼 엔지니어링을 해야할까요?
플랫폼의 성숙도가 높아질 수록, 프로덕트 팀이 더 빠르게 서비스를 만들어내고 비즈니스에 임팩트를 만들어낼 수 있습니다.
플랫폼 엔지니어링을 통해 얻을 수 있는 이점
플랫폼 엔지니어링은 아래와 같은 여러 이점을 가지고 있습니다.
1. 제품 팀의 인지 부하를 줄여 제품 개발 및 제공을 가속화할 수 있습니다.
2. 플랫폼 기능을 구성하고 관리할 전문가를 전담하여 플랫폼 기능에 의존하는 제품의 안정성과 복원력을 향상시킬 수 있습니다.
3. 기업 내 여러 팀에서 플랫폼 도구와 지식을 재사용하고 공유하여 제품 개발 및 제공을 가속화할 수 있습니다.
4. 제품 및 서비스의 보안, 규제 및 기능 문제의 위험을 줄일 수 있습니다.
이 중 특히 인지 부하와 관련된 부분을 좀 더 자세히 설명하고 싶은데요,
뛰어난 팀은 개발부터 인프라를 비롯해 QA까지 모두 프로페셔널하게 수행할 수 있습니다. 그런데... 대부분 그건 환상에 불과합니다. 개발자가 서비스 하나를 만드는데 보안도 알아야하고, WAF도 알아야하고, VPC도 알아야하고... 알아야 할 내용이 너무 많습니다.
대부분의 사람들에게 이처럼 인지 부하가 커지고, 이로 인해 제품 개발 속도도 느려지고 개별 개발자의 의욕 상실이나 번아웃 등도 걱정해야할 수 있습니다.
그래서 잘 추상화되고, 투명성이 보장된 플랫폼을 만들고 이용할 수 있다면, 제품 팀이 빠르게 제품 자체에 집중하며 가속화할 수 있습니다.
Gartner가 선정한 10대 전략 기술 트렌드 - 2023, 2024 연속으로 선정 (각 5위, 4위)
Gartner가 매년 선정하고 있는 10대 전략 기술 트렌드에 Platform Engineering이 2023년, 2024년까지 2년 연속으로 선정되었습니다. 생성형 AI 관련된 내용이 주를 이루는 가운데, Platform Engineering이 당당하게 순위권에 위치하고 있습니다.
플랫폼 엔지니어링에서 꼭 챙겨야 할 3가지 개념
(1) Self-Service & Internal Developer Platform (IDP)
플랫폼 엔지니어링이라고 하면 가장 많이 언급되는 내용이 바로 Self-Service와 Internal Developer Platform입니다. 가장 쉽게 설명된 자료가 Outsider님의 인프콘 발표 자료여서 해당 내용을 자료로 가져와봤습니다. (여담으로 1월 플랫폼 엔지니어링 모임 때 Outsider님이 발표를 하신다고 하네요! 기대됩니다 ㅎㅎ)
전통적인 방식에서는 Software Engineer가 티켓이나 기타 방법들을 이용해 인프라 팀에 작업을 요청하였습니다. 그러면 인프라 팀은 직접 인프라 작업을 수행합니다. 이 과정에서 자동화 등도 많이 이뤄졌습니다.
반면 내부 개발자 플랫폼은 인프라팀이 수동으로 처리하던 작업을 대체하였습니다. Software Engineer가 인프라 작업에 대해 '요청'하는 것이 아닌 직접 '작업'을 하는 것이죠. 그런데 직접 인프라를 만지는게 아닙니다. 플랫폼을 통해 추상화 레이어를 거쳐서 실제 인프라 관련 작업은 플랫폼이 수행합니다.
플랫폼 엔지니어링 팀은 여기서 내부 개발자 플랫폼을 만드는 역할을 합니다.
(2) Platform as a Product
두 번째는 플랫폼을 단순히 부품 또는 요소로 생각하는 것이 아닌, 하나의 프로덕트로 바라보자는 내용입니다. 사실 아무리 Internal Platform이라고 해도 그것 자체가 일종의 프로덕트라고 볼 수 있습니다. 플랫폼 엔지니어링 팀은 Productivity를 가지고, 내부 고객들의 니즈를 파악하여, 내부 고객들이 필요로 하는 걸 제품으로 만들어야 합니다.
이런 과정 자체가 스타트업 등에서 프로덕트를 만들어나가는 과정이랑 유사한데요, 플랫폼 엔지니어링 팀의 규모가 커지게 되면, 애자일 조직에서의 프로덕트 오너와 같은 Platform Product Manager라는 역할도 고려된다고 하네요.
(3) Thinnest Viable Platform (TVP)
마지막은 바로 TVP입니다. 플랫폼 엔지니어링에 사용되는 플랫폼은, 플랫폼이 제공할 수 있는 가치 중 가장 얇은 가치를 제공해야 합니다. 내부 플랫폼이 엄청나게 뛰어난 UI나 UX를 제공하는게 목표로 설정되지 않듯, 플랫폼이 제공해야하는 기본적인 가치만 제공한다면 (= 충분한 Quality만 제공할 수 있다면), 가장 쉬운 기술을 선택해야한다는 뜻입니다.
이른바 "Don't reinvent the wheel" 과 일맥상통하는 말이며, Lightweight Platform Engineering이라는 표현으로도 설명될 수 있습니다. 흔히 DevOps 방법론을 설명하는 용어 중 CALMS 프레임워크가 있는데, 여기서 Lean이랑도 가깝게 이해할 수 있습니다.
저는 개인적으로 적정기술이라는 용어가 떠올랐습니다. 내부에서 활용되는 플랫폼의 특성상 너무 최신 기술, 복잡한 아키텍쳐를 채택하는 대신, 익숙하면서도 검증된, 그러면서도 문제를 빠르고 적절하게 해결할 수 있는 기술을 선택해야 한다. 그것이 바로 Platform Engineering에서 기술을 선택할 때 주의해야 할 점이라고 이해했습니다.
그 외 여러 이야기들..
발표가 마치고 자유롭게 플랫폼 엔지니어링과 관련된 여러 이야기들을 나눴습니다. 그 중 기억에 남는 몇 가지를 남겨봅니다.
플랫폼이 오히려 기술적인 장벽을 세우는게 아닐까?
플랫폼의 추상화 정도가 높아질 수록, 개별 개발자는 인프라에 대해 전혀 신경쓰지 않고 코드만 바라보면 됩니다. 이런 상황 자체는 조직 전체로 보았을 때 효율성을 높여줌으로 이득을 가져오나, 개별 개발자 입장에서는 성장과 경험 면에서 부정적일 수 있다는 의견이었습니다. 특히 주니어 레벨의 개발자들에게는 인프라와 관련된 이해를 아예 하지 않아도 되니, 그런 부분에서의 성장이 더뎌지는 등 모습을 봤을 때, 오히려 플랫폼이 기술적인 장벽을 세울 수도 있겠다는 의견이었습니다.
개인적으로 굉장히 인상 깊었던 질문이었습니다. 저는 개인적으로 저 부분이 플랫폼 엔지니어링이 가지는 양면성이라고 보고, 시스템을 통해 해결해나가야하는 부분이라 생각했습니다. 예를 들어 매니징 측면에서, 교육이나 연수 등을 통해 그런 결핍 등을 풀어나가는 방식으로요.
플랫폼 엔지니어링을 조직에 도입해야 할 시기는 언제일까?
보통 새로운 개념이나 기술들을 도입한다면 어떤 문제나 Pain Point를 느껴서 도입하는 경우가 많은데, Platform Engineering을 조직에 도입해야겠다고 느낄 시기나 그 기준에 대한 질문이었습니다.
발표자 분은 프로덕트의 개수를 기준으로 삼았습니다. 프로덕트가 5개 이상이라면 플랫폼 엔지니어링 도입을 검토해볼 수 있다는 의견을 제시하였습니다.
플랫폼 엔지니어링의 성과, 어떻게 측정할 것인가?
이게 참 어려운 질문이었습니다. 제품의 수익이 올라가는 걸 플랫폼 엔지니어링의 성과로 볼 수 있는가? 어떤 지표를 KPI로 잡아야 플랫폼 엔지니어링을 통한 성과를 정확히 측정할 수 있을까? 하는게 주요 고민 포인트였습니다.
대부분 공감했던 부분은 Time To Market (TTM) 을 주요 지표로 활용하자는 부분이었습니다. DevOps 뿐 아니라 플랫폼 엔지니어링 자체가 지향하는 바가, 결국 프로덕트 조직 또는 소프트웨어 엔지니어링 조직이 더 빠르게 제품을 만들고 Deliver 할 수 있도록 지원하는 것이기 때문에, 실제 제품 출시까지의 시간이 얼마나 단축되었는지가 KPI로 적절하다는 내용이었습니다.
이와 함께 Platform Engineering의 성과 설정은, Platform Engineering을 도입하기 전에 해야한다는 의견도 있었습니다. 도입 전에 먼저, "Platform Engineering을 왜 도입해야하는가?"를 먼저 생각해보고, 여기서 나온 포인트를 가지고 기준을 정하라는 뜻입니다. 예를 들어, Business의 Ideation 단계부터 Launching까지의 Journey 중 몇 퍼센트의 시간을 줄일 수 있을까? 를 각 과정별로 체크하여 비효율성을 개선할 수도 있겠고, 지난 번 장애에서 Platform Engineering을 도입하여 해결할 수 있었던게 있었을까? 와 같이 현재의 어떤 문제를 해결할 수 있을까? 를 먼저 고민해보자는 내용이었습니다. 이렇게 고민이 먼저 이뤄진다면, 이걸 바탕으로 어떤 지표를 측정해야할지는 자연스럽게 정해지니까요.
후기
첫 모임이어서 그런지 거의 100분 가까이 많은 분들이 찾아오셨습니다. 플랫폼 엔지니어링에 관한 뜨거운 관심을 확인할 수 있었고, 현재 재직 중인 회사나, 또 앞으로 커리어패스 상에서의 도전 과정에서 꼭 한 번 Platform Engineering 분야에서 임팩트를 만들어보고싶다는 생각이 들었습니다!
다음 1월 모임이 정말 기대되는 정말 만족스러운 모임이었습니다 :)
