Offcanvas

CIO / How To / HR / 리더십|조직관리

IT 조직을 ‘플랫폼 엔지니어링 팀’으로 재구성하기 ‘Why & How’

2024.06.20 Robert Mitchell  |  CIO
3년 전 BSH 홈 어플라이언스는 IT 조직을 완전히 재정비했다. 3개의 글로벌 플랫폼 엔지니어링 팀과 4개의 지역 플랫폼 및 운영 팀으로 구성된 디지털 플랫폼 서비스 팀을 신설했다. 디지털 플랫폼 서비스 담당 부사장인 버크 메네클리는 그 때의 조직 개편에 대해 자신이 한 일 중 가장 잘한 일이라고 말했다.

유럽 소재 이 가전 기업에서 종전의 인프라 및 운영 팀은 사내의 소프트웨어 개발 조직을 위해 근무했었다. 소프트웨어 개발 조직은 신기능 개발에만 초점을 맞췄고, 인프라 및 운영 팀은 반응적으로 움직였다. 버크는 “새로운 조직에서는 플랫폼 엔지니어링 팀이 애자일 방식으로 조직된 4개의 소프트웨어 개발 팀과 함께 일한다. 이들은 용량 계획, 모니터링, 컨설팅 서비스를 제공하면서 보다 능동적으로 일하고 있다"라고 전했다.

 
BSH 디지털 플랫폼 서비스 담당 부사장 버크 메네클리
BSH에서는 현재 300~400명의 플랫폼 엔지니어링 팀원이 4개의 제품 그룹을 지원하고 있다. 결과적으로 소프트웨어 개발은 더 빨라지고, 운영은 더 효율화됐다. 애플리케이션은 더 안정적으로 실행되고, 중요 인시던트 건수는 월 50건에서 15건으로 70% 감소했다. 

오늘날 엔터프라이즈 IT 분야에서 플랫폼 엔지니어링이 주목받고 있다. 가트너의 부사장 애널리스트 빌리 블로슨에 따르면, 최근 실시한 설문조사에서 응답자의 75%가 조직에서 이미 플랫폼 엔지니어링을 도입했다고 응답했다. 단 공식화되고 구조화된 접근 방식을 채택했다는 응답자는 아직 44%에 그쳤다. "개발자 경험과 생산성 향상을 위한 전략적 행보로 관측된다"라고 그는 말했다.
 
Image Credit : Getty Images Bank

플랫폼 엔지니어링의 목적
플랫폼 엔지니어링 팀은 내부 소프트웨어 개발자가 사용할 수 있는 셀프 서비스 플랫폼을 만들고 실행하는 일을 담당한다. 확장성이 뛰어난 이러한 플랫폼은 일반적으로 개발자 생산성을 최적화하고 규모의 경제를 활용해 비용을 절감하고 안정성을 개선하며 소프트웨어 제공을 가속화하도록 설계된다. 또한 프로세스, 아키텍처, 보안 및 기술 거버넌스 측면에서 일관성을 보장할 수도 있다.

 
USPTO ​​​​ 밥 심스
미국 특허청(USPTO)의 전 엔터프라이즈 인프라 제공 담당 이사인 밥 심스 또한 플랫폼 엔지니어링 팀으로 IT를 재편한 인물이다. 그는 "현재 플랫폼 엔지니어링 팀이 200개 이상의 애플리케이션을 지원하고 있다. 자동화 중심적 혁신을 이뤄냈다. 배포에 몇 주가 걸리던 것이 몇 분으로 단축됐다. 또한 인프라 서비스 수준을 모니터링하고 있으며 문제가 발생하면 제품 팀에 알림을 보낸다. 특정 유형의 중단 사고가 발생하면 통합 가시성 도구가 애플리케이션을 다시 시작하기도 한다"라고 전했다.

젠팩트의 최고 디지털 전략가인 산자이 스리바스타바는 플랫폼 엔지니어링을 통해 배포하는 모든 제품에 대해 공통된 파이프라인과 방법론을 구축할 수 있다고 설명했다. 그는 "역량 기술과 인재 측면에서도 큰 도움이 된다. 영입과 유지 측면에서 특히 그렇다"라고 말했다.

플랫폼 엔지니어링 팀의 핵심 역할은 다양하다. 인프라 엔지니어, 소프트웨어 개발자, 데브옵스 도구 엔지니어부터 데이터베이스 관리자, 품질 보증, API 및 보안 엔지니어, 제품 설계자 등에 이른다. 경우에 따라서는 사이트 안정성 엔지니어, 스크럼 마스터, UI/UX 디자이너, 성능 데이터를 평가하여 병목 현상을 파악하는 분석가도 팀에 포함될 수 있다. 

 
PwC 최고 제품 및 기술 책임자 조 앳킨슨
PwC의 최고 제품 및 기술 책임자인 조 앳킨슨에 따르면 이러한 팀은 수많은 이점을 제공한다. 확장 가능하고 유연한 인프라 및 도구의 구축 및 유지 관리는 물론, 신속한 소프트웨어 개발을 위한 표준화된 프레임워크를 확보할 수 있게 한다. 또 라이브러리 및 도구 개발, 인프라 리소스 통합을 통한 비용 절감, 인프라 수준에서의 보안 및 규정 준수 보장과 같은 효과도 초래한다. "플랫폼 엔지니어링 팀은 IT 및 비즈니스 팀과 긴밀히 협력하여 조직 내 협업을 촉진하기도 한다”라고 그는 말했다.

플랫폼 엔지니어링 팀 구축법
IT 리더들은 매우 효과적인 팀을 구축하려면 고려해야 할 사항이 많다고 말한다.

올바른 기술을 갖춘 인재 영입 : 기본적으로 모든 플랫폼 엔지니어링 팀은 커뮤니케이션 능력이 뛰어나고, 소프트웨어 개발, 하드웨어 및 데이터에 능숙하며, 분석 및 문제 해결 능력이 뛰어나고, 플랫폼 엔지니어링 도구에 익숙한 사람을 채용해야 한다고 PwC의 앳킨슨은 설명했다. 

심스는 "우리 조직의 경우 클라우드 및 데이터베이스 또는 데이터 아키텍트 경험과 같은 핵심 기술이 혼합된 사람을 선호한다. 우리가 이 사람을 데이터 설계자라고 하면, 그 사람의 영역을 제한할 뿐이다. 우리는 한 팀원이 다른 팀원의 업무도 습득할 수 있기를 바란다"라고 말했다.

그러나 기본 역량은 여전히 중요하다. 잰팩트의 스리바스타바는 "올바른 팀을 구성하는 것이 성공의 열쇠이다. 단 각 팀은 각 클라우드 인프라의 세부 사항과 고유한 환경을 확실히 이해해야 한다"라고 말했다.

미래에 대비하기 : 심스는 또한 AI, 머신러닝, 카오스 엔지니어링 등 조직의 미래를 위한 역량을 찾고 있다. 현재 USPTO의 플랫폼 엔지니어링 팀은 성능 문제를 감지해 자동으로 문제를 해결하는 AI 기능을 적극적으로 테스트하고 있다. AI가 자동으로 더 많은 스토리지를 할당하거나 CPU 또는 메모리 리소스를 추가하거나 한 저장소에서 다른 저장소로 데이터를 이동하도록 하려는 것이다.

스리바스타바는 "AI가 플랫폼 엔지니어링을 100% 뒤흔들고 있다. 이를 활용할 수 있는 기술을 갖추는 것이 중요하다. 예를 들어 인프라, 스토리지, 사용자 인증, 규칙 생성을 모두 사전 자동화할 수 있어 생산성을 크게 향상시킬 수 있다"라고 말했다. 

 
USPTO CIO 제이미 홀컴브
실패를 인정하는 강력한 팀 문화 조성 : 조직 문화도 중요하다. USPTO CIO 제이미 홀컴브는  "올바른 행동을 유도하지 않으면 문제가 발생했을 때 서로를 탓하는 사람들이 생기게 된다"라며, 투명성도 중요하다고 말했다. 나쁜 일이 발생하면 즉시 공개하여 다른 사람들이 이를 통해 배우거나 해결책을 제시할 수 있도록 하라는 조언이다. 다른 팀에서 문제를 먼저 경험하고 해결책을 가지고 있을 수 있다. "개방적이고 투명하지 않으면 문제를 신속하게 해결할 수 없다"라고 그는 말했다.

특히 CIO는 플랫폼 엔지니어링 팀원들이 작은 규모의 실패를 통해 배울 수 있도록 해야 하며, 이를 위해서는 큰 프로젝트를 작은 단위로 쪼개야 한다. 홀컴브는 "미성숙한 팀에게 복잡한 작업을 맡긴다면 그것은 리더의 잘못다"라고 말했다.

교육 강화 : 메네클리는 우수한 팀 구축은 교육에서 시작된다고 강조했다. "우리는 플랫폼 엔지니어링 팀에게 운영 우수성과 비용 최적화가 무엇을 의미하는지에 대해 교육했다. 그런 다음 애플리케이션 팀도 함께 참여할 수 있도록 교육했다"라고 그는 말했다.

현업과 파트너십 형성 : 플랫폼 엔지니어링 팀이 서비스를 제공하는 제품 그룹을 제대로 지원하려면 협업이 필수적이다. USPTO에는 규모가 크고 복잡하며 릴리스가 많은 가장 중요한 애플리케이션 200여 개가 있다. 심스는 제품 팀의 스크럼 회의와 스탠드업에 참석할 플랫폼 엔지니어링 팀원을 지정한다고 전했다. "이들은 해당 팀과 협력하여 팀의 요구 사항을 파악하고 개발자가 셀프 서비스 기능을 사용할 수 있도록 지원한다"라고 그는 설명했다. 말합니다.

메네클리 또한 SAP, 클라우드, 업무용 애플리케이션을 위한 서비스를 제공하는 BSH의 3개 플랫폼 엔지니어링 팀 중 일부가 제품 그룹에 포함되어 아키텍처, 보안, 기술, 운영 거버넌스 지침을 제공한다고 설명했다.

PwC는 약간 다른 접근 방식을 취하고 있다. "플랫폼 엔지니어링 팀이 IT 부서 내에 속할 수도 있지만, 제품 개발 팀과 직접 통합되어는 게 낫다고 보고 있다. 이렇게 하면 소프트웨어 개발자, 시스템 설계자, 운영 팀과 긴밀하게 협업하여 소프트웨어 개발 수명 주기 및 IT 운영 전반에 걸쳐 성능 고려 사항을 통합할 수 있다"라고 앳킨슨은 말했다.

플랫폼 엔지니어링 vs. 제품 그룹
플랫폼 엔지니어링 팀을 구성할 때 중요한 결정 중 하나는 제품에 대한 엔드투엔드 책임을 질 조직의 결정이다. “애플리케이션 팀이 전체 엔드투엔드 책임을 맡을 것인가, 아니면 일부를 플랫폼 팀에 넘기고 규모의 경제와 애자일 간의 균형을 유지할 것인가? 이것이 바로 3년 전에 우리가 했던 논쟁이다"라고 메네클리는 말했다.

그는 이어 "전자를 택하면 애플리케이션 개발의 민첩성과 유연성은 높아지지만 플랫폼이 늘어날 수 있다. 극단적으로는 플랫폼 엔지니어링 팀이 없고 모든 사람이 자신의 플랫폼에 대한 모든 권한을 갖게 될 수도 있다"라고 덧붙였다.

예산, 규모의 경제, 거버넌스에 초점을 맞추고 있는 BSH의 현재 상황에서SMS 플랫폼 팀이 제품 팀과 긴밀하게 협업하여 엔드투엔드 책임을 공유하는 것이 더 적절하다. "예산은 실질적으로 증가하지 않고 있다. 그렇기 때문에 플랫폼 엔지니어링 팀이 더욱 중요기도 하다"라고 그는 말했다.

스리바스타바에 따르면 또 다른 과제는 각 제품의 구체적인 뉘앙스를 맞춤화하는 능력이다. "우리에게 허브 앤 스포크 구성의 하이브리드 모델이 효과적이었다. 80%는 표준으로, 20%는 커스터마이징을 위해 사용한다"라고 그는 전했다.

USPTO가 플랫폼 엔지니어링으로 전화하기 전에는 전통적인 프로젝트 관리 팀이 있었다. 홀컴브는 "모두가 가능한 한 많은 프로젝트를 수행하려고 노력했다. 매우 워터폴 스타일이었다. 운영과 유지보수를 최적화하려는 이가 없었다”라며, 이제는 특허, 상표, HR 및 재무와 같은 핵심 영역을 지원하는 소프트웨어와 같은 중요한 것들을 위한 서비스를 실행하는 제품 라인이 있다고 전했다.

홀컴브는 이어 "이러한 제품 팀이 최종 결정을 내린다. 인프라 서비스 제공처를 다른 곳으로 옮기고 싶다면 그렇게 할 수 있다. 그러나 제품 그룹이 이렇게 결정하면 인프라 비용 부담이 커진다. 이렇게 우리는 플랫폼 엔지니어링이 경쟁력을 갖출 수 있는 인센티브를 만들었다"라고 그는 말했다.

현실의 교훈
플랫폼 엔지니어링을 시도한 IT 리더들은 대부분 이 조직화 기법이 아직 성숙 단계에 있으며, 현실에서 체득한 몇 가지 교훈이 있다고 말했다. 

커뮤니케이션이 핵심이다. "소통과 협업이 부족하면 생산성이 저해되고 팀 간에 불협화음이 발생할 수 있다"라고 앳킨슨은 말했다.

올바른 스킬 세트를 갖추기 위해 필요한 조치를 취하라. "플랫폼 엔지니어링의 과제와 요구 사항을 처리하려면 현명한 채용과 기존 팀원의 기술 향상 모두 필요합니다"라고 앳킨슨은 덧붙였다.

가장 필요한 곳에 엔지니어를 배치하라. 많은 제품을 보유한 대규모 조직에서는 모든 개발 팀에 플랫폼 엔지니어를 배치할 수 없기에 비즈니스에 중요한 팀에 집중해야 한다고 홀컴브는 조언했다.

확장하라. 플랫폼 엔지니어링 원칙은 기술적 복잡성이 있는 조직의 다른 부서에도 적용할 수 있다. 가트너의 블로슨은 "비즈니스 사용자가 근본적인 복잡성을 이해하지 않고도 기술 기능을 제공할 수 있도록 사용하기 쉬운 셀프 서비스 방식으로 제공되는 로우코드 애플리케이션 플랫폼을 한 예로 들 수 있다"라고 설명했다. 

BSH는 이미 비즈니스 사용자에게 서비스를 제공하는 RPA 플랫폼을 지원하기 위해 플랫폼 팀을 구성했다. "우리는 플랫폼을 관리하고 기술 거버넌스를 수행하지만 모든 애플리케이션 개발과 운영은 비즈니스 부서에서 담당한다"라고 메네클리는 말했다.

자동화 및 도구에 대해 투자하라 "투자하지 않으면 수작업과 시간 소모적인 프로세스로 인해 효율성에 영향을 미칠 수 있다"라고 앳킨슨은 전했다.

보안과 컴플라이언스를 꼭 고려하라. 플랫폼이 취약성과 법적 위험에 노출되지 않도록 이러한 기능에 우선순위를 두어야 한다고 앳킨슨은 덧붙였다.

AI 활용을 염두에 두고 팀을 배치하라. 심스는 USPTO가 예측 분석 및 자동화를 포함한 새로운 AI 기반 기능을 실험하는 데 필요한 기술을 도입했다. 그의 팀은 또한 성능 제약을 인식하고 이를 해결할 수 있는 AI 기능을 테스트하고 있다. 하지만 메네클리는 ML이 입증되었지만, 팀이 생성형 AI와 같은 최신 기술에 대해 충분히 생각하지 않고 뛰어들지 않도록 주의해야 한다고 경고했다. "비용이 많이 들기 때문에 AI뿐만 아니라 새로운 기능을 가져올 다른 새로운 소프트웨어에도 유효한 좋은 비즈니스 사례가 필요다"라고 그는 말했다.

변화지 않는 상수가 있다면 변화 뿐이다. 메네클리는 앞으로 소비자 여정, 기업용 앱, 제조, 제품 디지털화를 지원하는 BSH의 제품 팀이 IT 부서에서 비즈니스 부서로 이동하게 될 것으로 예상한다. "비즈니스 개발자와 분석가가 더 많이 투입될수록 아키텍처와 보안에 대한 생각은 줄어들 것이다. IT의 가치 제안은 확장 가능하고 안정적인 플랫폼 서비스 제공과 제품 팀에 대한 IT 전문 지식으로 옮겨갈 것이다" 라고 그는 말했다.

이러한 팀에는 여전히 IT 팀원이 있을 것이며, 이들은 비즈니스 기술자를 위한 가이드 역할을 해야 하지만 나머지는 비즈니스 부서의 일부가 될 가능성이 높다. 메네클리는 "현재 IT에 대한 비용과 납기 압박으로 인해 오랫동안 사용되어 온 공장식 접근 방식은 지속 불가능하다. 새로운 세대의 직원들은 솔루션을 개발하고, 로우코드 및 노코드와 같이 사용하기 쉬운 도구와 생성형 AI를 추가하는 데 사용할 수 있는 기술도 갖추고 있다. 모든 기업은 어떤 식으로든 모든 직원을 디지털 생산에 활용해야 한다"라고 말했다. ciokr@igd.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
Sponsored
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.