어떤 사람들은 플랫폼 엔지니어링이 하이프 사이클의 환멸 단계에 들어섰다고 말한다. 높은 인지 부하, 비즈니스와의 불일치, 내부 개발자 플랫폼(IDP) 도입의 어려움으로 인해 한때 가장 뜨거운 기술 트렌드 중 하나가 제자리에 멈춰 섰다.

플랫폼 엔지니어링 이니셔티브가 실패하는 이유는 리더십 부재부터 개발자의 불참, 부실한 IDP 구현에 이르기까지 다양하다. 이 글에서는 플랫폼 엔지니어링에서 피해야 할 것들, 팀이 빠지기 쉬운 함정과 그 경험에서 얻은 교훈을 살펴본다.

프론트엔드를 먼저 구축하기

플랫폼 엔지니어링에서 큰 오해 중 하나는 플랫폼이 곧 시각적 인터페이스라는 인식, 즉 플랫폼과 개발자 포털을 하나의 객체로 보는 인식이다.

실제로는 그렇게 단순하지 않다. 인기 플랫폼 엔지니어링 커뮤니티인 플랫폼 엔지니어링(Platform Engineering)의 기여자 루카 갈란테는 “플랫폼 구현은 프론트엔드가 아니라 견고한 백엔드부터 시작해야 한다. UI를 더하기 전에 API와 오케스트레이션으로 견고한 백엔드를 구축하는 데 집중하라”고 말했다.

백스테이지(Backstage) 같은 프론트엔드 사용자 인터페이스는 플랫폼 엔지니어링에서 중요한 요소지만 전부는 아니다. GUI 포털 밖에서 CLI나 API를 통해 상호작용하는 방식을 선호하는 개발자도 있다.

업바운드(Upbound)의 개발자 애드버킷인 빅토르 파르치크는 “포털에 로직을 넣지 않는 것이 중요하다. 로직을 넣으면 플랫폼 액세스 방법을 한 가지로 스스로 제한하게 된다”면서 “이 경우 한가지 소비 방식으로 고정되면서 유연함을 원하는 사용자들의 불만을 살 수 있다”고 말했다.

제품 마인드셋의 부재

플랫폼 엔지니어링 분야에서 제품 마인드셋을 가지라는 조언은 이제 너무 뻔한 말처럼 들리지만 그게 사실이다. 플랫폼을 제품으로 대하지 않는 것은 저조한 사용률로 이어지는 확실한 길이다.

테트레이트(Tetrate)의 관리자 에리카 휴버그는 2024년 북미 쿠버콘(Kubecon)에서 “최고의 제품조차 스스로 알아서 팔리지는 않는다”고 말했다. 휴버그에 따르면 마케팅 측면에서 명확한 접근 없이 엔지니어들이 도입을 이끌어 주기를 막연히 기대하는 것은 실패로 가는 공식이다. 사용자 기반을 구축하기 위해서는 내부 지지, 스토리텔링, 초기 도입자의 성공 사례 공유 등 생각보다 많은 것이 필요하다.

제품 마인드셋은 시간이 지남에 따라 플랫폼 개선을 이끄는 데도 도움이 된다. 플랫폼 엔지니어링의 갈란테는 “최소 기능 플랫폼에서 시작해 피드백을 기반으로 반복하고 적응하면서 플랫폼의 영향을 측정할 필요성도 고려해야 한다”고 말했다.

공유 소유권의 부재

새로운 기술에 대한 하향식 지침은 특히 그 기술이 기존 워크플로의 변화를 수반하는 경우 개발자들의 저항에 부딪치기 쉽다. 기여와 반복의 여지가 없는 플랫폼은 개발자의 필요에서 멀어지고 편법적인 우회로 이어진다.

스포티파이의 제품 관리 책임자인 톰 바르칸-벤클러는 “팀에 얼마간의 소유권을 부여하라. 도입을 강제하면 안 된다”고 말했다. 스포티파이는 실제로 이를 실천하기 위해 개발자들에게 스포티파이의 IDP인 백스테이지를 위한 플러그인을 만들 수 있는 역량과 자율성을 부여한다.

한 예로 스포티파이가 지속적 개발 프로세스 내에서 새 코드를 검증하기 위해 만든 플러그인인 사운드체크(Soundcheck)가 있다. 바르칸-벤클러는 “엔지니어들은 자신이 플랫폼을 구축하고 맞춤 설정할 수 있을 때 프로세스의 일부가 되고 그 플랫폼을 사용할 가능성이 더 높아진다”고 말했다.

이 공유 소유권 모델은 성공적인 것으로 입증되고 있다. 스포티파이의 엔지니어링 부문 선임 책임자인 피아 닐슨에 따르면 현재 모든 스포티파이 직원이 백스테이지 내부 버전을 사용하고 있다.

과도한 하향식 통제가 막 생겨난 플랫폼 엔지니어링 이니셔티브의 성장에 방해가 될 수 있다는 데는 대부분이 동의한다. 아카마이(Akamai)의 클라우드 컴퓨팅 부문 CTO인 제이 젠킨스는 “강력한 거버넌스는 중요하지만 거버넌스는 사람들을 제약하는 것이 아니라 역량을 부여해야 한다”고 말했다.

사용자 설문조사의 부재

사용자 기반을 완전히 이해하지 못하면 결과도 들쭉날쭉할 수밖에 없다.

다이나트레이스(Dynatrace)의 데브옵스 활동가이자 ‘설계자를 위한 플랫폼 엔지니어링’의 공동 저자인 안드레아스 그라브너는 “대상 사용자와 이들을 도울 방법을 모른 채 무언가를 만든다면, 그것은 엔지니어링 효율성 측면에서 아무런 효과도 없는 결과물이 된다”면서 플랫폼 설계자가 최종 사용자와 이들의 고충을 깊이 이해해야 한다고 말했다.

쉽지 않은 일이다. 조직마다 특성이 다르고, 사용자 하위 집단마다 요구사항이 제각각이기 때문이다. 그라브너는 예를 들어 자바 개발자가 요구하는 사용자 경험과 품질 관리 테스터나 사이트 안정성 엔지니어가 기대하는 경험은 매우 다르다고 말했다. 이는 특정 사용자 하위 집단에 대한 피드백 수집의 중요성을 잘 보여준다.

개발자 포털 제공업체 포트(Port)의 CEO 조하르 아이니는 “자신의 의견이 경청, 반영되고 있다는 느낌은 매우 중요하다. 사용자들은 누군가가 자신들의 문제에 대해 물어보고 포털을 구축했다는 사실을 알게 되면 더 거부감 없이 수용한다”고 말했다.

플랫폼 엔지니어는 사전에 사용자 리서치와 개발자 설문을 실시함으로써 모든 이해관계자의 요구사항을 파악하고, 기존 워크플로우와 잘 융합되면서 생산성에 이득이 되는 플랫폼을 구축할 수 있다.

엉뚱한 지표 추적

다이나트레이스의 그라브너는 “만드는 모든 것은 측정 가능해야 한다”고 말했다. 단, 올바른 지표를 근거로 의사결정을 내려야 한다. 그라브너는 도라(DORA) 지표는 플랫폼 엔지니어링 관점에서 후행 지표라고 지적했다.

마찬가지로, 플랫폼을 사용하는 개발자의 온보딩 비율이 높게 나온다 해도 표면적인 수준의 성공 지표일 뿐 비즈니스에 대한 ROI을 정확히 반영한다고 단정할 수는 없다.

내부 개발자 플랫폼을 구축하기 위한 툴을 제공하는 휴머니텍(Humanitec) 창업자이자 CEO인 카스파 폰 그륀베르크는 “성공적인 플랫폼은 출시 시간을 단축하고 비용을 절감하고 혁신을 늘려야 한다”면서 “출발점은 제대로 된 ROI 계산이고, 플랫폼 구축은 그 다음 일”이라고 말했다.

다른 회사의 플랫폼과 접근 방식을 그대로 모방

스포티파이, 익스피디아(Expedia), 아메리칸 에어라인(American Airlines)과 같은 대기업의 플랫폼 엔지니어링 사례 연구는 문서상으로 보면 인상적이다. 그러나 이러한 기업의 전략이 다른 조직에 그대로 적용된다는 보장은 없다. 특히 중소 규모 환경에서는 더욱 그렇다.

소프트웨어 제공 플랫폼 개발사인 하네스(Harness)의 제품 관리자이며 과거 스포티파이의 백스테이지 팀에서 일했던 히만슈 미슈라는 “개발자가 100명이든 몇 천 명이든 투입되는 노력은 동일하다. 투자 회수를 고려해야 하며, 대기업이 하는 것을 그대로 모방하면 안 된다”고 말했다.

IDP 참조 아키텍처를 보면 플랫폼 구축을 위해 필요한 요소를 개략적으로 파악할 수 있다. 그러나 그 보편적 유용성에 대해 회의적인 시각도 존재한다. 오라일리(O’Reilly)에서 출판한 ‘플랫폼 엔지니어링’의 저자이자 고문, CTO인 카밀 푸르니에는 다음과 같이 말했다.

“가장 어려운 문제인 애플리케이션 팀으로부터 인프라를 추상화하는 문제를 IDP 참조 아키텍처가 해결해 주지는 않는다. 각 팀이 전체 애플리케이션 스택을 어떻게 확장하고 지원할지 이해해야 하는 과제는 여전히 남는다. 여기서 프로비저닝, 심지어 관찰가능성 설정도 전체 수명 주기 비용에서 보면 아주 작은 부분에 불과하다.”

시작부터 오버엔지니어링

일부 플랫폼 팀은 첫날부터 모든 문제를 해결하려 한다. 하네스의 미슈라는 기본적이고 구체적인 개발자 접점과 CI/CD를 간소화하는 것부터 시작한 다음 점진적으로 복잡성을 늘려 나갈 것을 권하며 “항상 플랫폼 엔지니어링 시간이 아닌 개발자 시간에 맞춰 최적화하라”고 말했다.

점진적인 개발이 성공적인 플랫폼 엔지니어링 도입의 핵심이라는 데는 다른 전문가들도 동의한다. 푸르니에는 “오늘 당면한 문제를 해결하고, 확고하게 성공할 때까지는 너무 먼 미래에 신경을 쓰지 말아야 한다”면서 우선 집중된 소유권의 부재로 인해 어려움을 겪는 공유 소프트웨어 영역에 초점을 맞출 것을 권했다.

아카마이의 젠킨스는 “복잡성은 적”이라면서 “플랫폼 엔지니어링이 줄이는 일보다 그로 인해 만들어지는 일이 더 많다면 잘못된 것”이라고 지적했다. 플랫폼은 불필요한 툴 계층, 경직된 프로세스, 개발자의 속도를 저하시키는 무거운 템플릿을 추가해서는 안 된다. 젠킨스는 최고의 플랫폼은 거의 보이지 않는 플랫폼이라고 말했다.

운영 팀 리브랜딩

플랫폼 엔지니어링을 위해서는 단순한 리브랜딩 이상의 에너지가 필요하다. 내부 개발자 플랫폼 크래틱스(Kratix)를 만든 신타소(Syntasso)의 공동 창업자이자 최고운영책임자인 폴라 케네디는 “운영 팀이나 인프라 팀이 플랫폼 엔지니어링 팀으로 이름만 바뀔 뿐 조직에 실질적인 변화나 이익은 거의 없는 경우를 많이 봤다”고 말했다.

잘못된 방향 설정이나 명확한 요구사항의 부재로 인한 프로젝트 실패 사례는 셀 수 없이 많으며, 플랫폼 엔지니어링도 예외가 아니다.

푸르니에는 플랫폼 엔지니어링에는 간과해서는 안 되는 중대한 문화적 전환이 필요하고, 따라서 조직은 이를 전통적인 비용 센터로 취급하지 말고 소프트웨어 엔지니어링 문제를 해결하는 새로운 접근 방법으로 봐야 한다고 말했다.

플랫폼 엔지니어링에 끝은 없다

오늘날 많은 클라우드 네이티브 조직이 플랫폼 엔지니어링을 위한 여정을 진행 중이며, 대부분의 개발자는 백스테이지와 같은 내부 개발자 플랫폼에 익숙하다. 스포티파이의 바르칸-벤클러는 “기초적인 질문을 듣는 일이 점점 줄어들고 있다. 플랫폼 엔지니어를 위한 회사와 툴이 많다는 것은 좋은 신호”라고 말했다.

좋은 내부 플랫폼은 개발자가 현재 있는 곳에 접점을 둔다. 셀프 서비스 형식이며, 고된 작업을 자동화하고 일관성을 위한 표준 소프트웨어 카탈로그와 템플릿을 제공하고 확장성과 유연성을 갖춘 최적의 길을 제시한다. 플랫폼 엔지니어링 이니셔티브 자체는 경영진의 지지를 받는 것이 이상적이지만 공동 소유권도 포용한다.

전체 그림은 훌륭해 보이지만, 얼핏 상충되는 이 모든 목표를 달성하기란 거의 불가능하게 느껴질 수 있다. 실제로 많은 사람들이 그렇게 생각한다.

많은 조직에서 프로덕션 환경의 플랫폼 엔지니어링은 들쭉날쭉한 결과를 내고 있다. 2024년 도라 보고서에 따르면 전담 플랫폼 엔지니어링 팀을 둘 때 소프트웨어 개발 팀의 생산성 증가는 6%에 불과했다. 더 기운 빠지는 점은 처리량이 오히려 8% 감소했고 변경 안정성이 14% 낮아졌다는 사실이다.

이들 조직이 깨달은 바와 같이 플랫폼 엔지니어링에는 수많은 가변적 요소가 있고, 초기 단계에서의 실수가 후속 단계에 많은 영향을 미친다. 이 상황에서 성공을 달성하기는 쉽지 않다.

대체로 플랫폼 엔지니어링의 성공은 기본적인 제품 원칙으로 귀결된다. 많은 전문가들이 조언하는 바와 같이 제품 관점에서 내부 개발자 플랫폼에 접근해서, 개발자의 변화하는 요구사항을 충족하도록 지속적으로 제품을 개선해야 한다.

포트의 아이니는 “제품 관리자 마인드셋을 갖추는 것이 핵심”이라고 말했다. 하네스의 미슈라도 공감하며 “회사 내부의 제품 관리자가 돼야 한다”고 말했다.
dl-itworldkorea@foundryco.com