개발자

왜 플랫폼 엔지니어링에 집중해야 할까?

Isaac Sacolick | InfoWorld 2023.05.04
오래지 않은 과거만 해도 엔지니어는 수동으로 시스템을 구성했다. 당시에는 애플리케이션을 배포할 때 관리자가 따라야 할 절차 문서 초안을 개발자들이 작성했다. CI/CD를 사용한 배포, 코드형 인프라 구성, 컨테이너화된 시스템 관리를 포함한 데브옵스 툴과 방식이 나오면서 IT 팀은 시스템 안정성과 보안, 성능을 개선할 수 있게 됐다.
 
그 결과 더 많은 데브옵스 팀이 애플리케이션 변경을 배포하고 클라우드 인프라를 더 빠르게 확장할 수 있게 됐다. 데브옵스 팀은 기존의 분기별 릴리즈 주기에서 지속적인 배포 방식으로 전환했고 클라우드 엔지니어는 컴퓨팅 수요를 기반으로 클라우드 인프라를 확장하기 위한 자동화를 개발했다.
 
 
ⓒ Getty images Bank

애자일 개발 팀은 데브옵스 관행을 사용해서 핵심 워크플로우와 수익 창출 환경을 위한 애플리케이션을 구축하고 강화했다. 마이크로서비스를 개발하고 멀티클라우드 아키텍처로 배포하면서 더 높은 유연성을 얻었지만 가동 중단, 성능 문제 또는 기타 주요 사고에 대응할 때의 복잡성도 더 높아졌다. 많은 기업이 서비스와 애플리케이션의 안정성 및 성능을 개선하기 위해 사이트 안정성 엔지니어링(SRE)을 채택하고 AI옵스 플랫폼을 구축했다.
    

광범위한 데브옵스 도입으로 어려움을 겪는 IT

데브옵스와 SRE 역량을 성숙화하기 위해서는 기술 개발과 관행, 문화적 변화에 많은 투자가 필요하다. CIO와 IT 리더 과점에서는 두 가지 기본적인 문제가 발생한다.
 
첫째, 많은 기업이 기술 부채와 기술 간극으로 어려움을 겪는다. 따라서 데브옵스와 SRE 관행은 발전했지만 광범위한 도입은 더욱 어려워졌다. 이러한 기업은 클라우드 네이티브 및 현대화된 애플리케이션을 대상으로 CI/CD와 IaC를 성공적으로 구축할 수 있다 해도 이와 같은 역량을 표준화된 관행으로 활용하는 데는 애를 먹는다.
 
기술적으로 더 발전한 기업이 겪는 문제는 다르다. 이러한 기업은 대체로 자기 기업화 방식을 채택하고, 팀이 애플리케이션 아키텍처 요구사항 및 구현 가치에 부합하는 데브옵스 툴을 구성할 수 있도록 권한을 부여한다. 표준화된 플랫폼이 있을 수 있지만 각 팀이 서로 다른 방식으로 툴을 사용한다. 따라서 이들은 맞춤형 CI/CD 파이프라인과 IaC 자동화, 클라우드 아키텍처, 모니터링 구성을 배포한다.
 
이 같은 기업과 리더에게 관건은 ‘데브옵스 모범 사례를 목표 변경이 가능한 패턴으로 구현하려면 어떻게 해야 하는가’이다. 더 구체적으로 말하자면 관건은 애자일 팀이 애플리케이션을 개발하는 데 더 많은 시간을 투자하고 클라우드 구성 및 자동화에 소비하는 시간을 줄이는 것이다.
 

플랫폼 엔지니어링이 데브옵스를 발전시킨다

플랫폼 엔지니어링은 규모가 큰 기업이 표준을 개발하고 재사용 가능한 구성을 지원하고 시스템 엔지니어링을 내부 제품 역량으로 제공하도록 돕기 위한 데브옵스 관행의 발전형이다.
 
세마포어 CI/CD(Semaphore CI/CD)의 공동 창업자인 마르코 아나스타소브는 “플랫폼 엔지니어링은 데브옵스에서 한 걸음 진전한 것”이라며 “플랫폼 엔지니어링은 개발자가 빠른 애플리케이션 개발에 사용할 수 있는 '기준 경로'를 만들어 개발자가 데브옵스 관행을 더 쉽게 따를 수 있게 해준다”고 말했다.
 
대규모 기업의 경우 플랫폼 엔지니어링에는 애플리케이션을 구축하는 개발자와 제품으로서의 데브옵스를 만드는 플랫폼 엔지니어의 임무의 분리가 필요할 수 있다. 아나스타소브는 “플랫폼 엔지니어는 개발자가 애플리케이션을 작성하는 데 필요한 툴과 라이브러리, 인프라를 셀프 서비스로 조달할 수 있는 수단을 만드는 데 초점을 둔다”고 말했다.
 

개발자 경험과 생산성의 개선

플랫폼 엔지니어링은 개념은 간단하지만 제품을 개발한다는 사고방식이 필요하기 때문에 실행하는 것은 쉽지 않다. 플랫폼 엔지니어는 애자일 개발 팀이 소비하고 싶은 제품을 개발해야 하며 개발자는 DIY 데브옵스 접근 방법에 대한 욕심을 버려야 한다.
 
출발점 중 하나는 IT가 표준을 통해 큰 혜택을 얻고 개발자에게 애플리케이션별 아키텍처 요구사항이 있을 가능성이 상대적으로 적은 인프라 및 클라우드 프로비저닝이다.
 
퍼코나(Percona)의 제품 관리 담당 부사장인 도니 버크홀츠는 “플랫폼 엔지니어링은 팀이 자동화 및 셀프 서비스를 사용해서 적절한 종류의 개발자 경험을 제공하는 방법을 다루므로 개발자는 티켓 요청에 따라 인프라가 준비될 때까지 기다리는 일 없이 코드를 쓰고 애플리케이션을 구현하는 일에 집중할 수 있다”고 말했다.
 
이부분에 고객의 고충이 있다. 코딩하기를 원하는 개발자 또는 데이터 과학자라면 컴퓨팅 리소스를 위한 티켓을 끊는 것을 무엇보다 싫어할 것이다. 그러나 IT와 보안 리더는 개발자가 인프라 구성을 맞춤 구성하는 일을 피하고 싶어한다. 많은 비용이 들고 보안 취약점도 발생할 수 있기 때문이다.
 
버크홀츠는 “기업은 내부 개발자 경험에 관심을 기울이므로 플랫폼 엔지니어링 도입은 확대될 것이다. 개발자에게 방해가 된다면 그게 무엇이든 직원들의 생산성을 저하시켜 결국 비용이 된다”고 말했다.
 

재사용할 수 있고 구성 가능한 셀프 서비스 구성요소 만들기

플랫폼 엔지니어링에 대해 생각하는 한 가지 방법으로, 개발자에게 다음 문장을 채우도록 요청하는 방법이 있다. “우리 팀은 <기술 자동화> 및 <인프라 구성>을 개발, 유지 또는 개선하는 데 시간을 소비하고 있기 때문에 <기술적 관심사>에 대처하는 데 충분한 시간을 투자할 수 없다.”
 
기술적 관심사에는 테스트 가능성, 성능, 확장성, 보안을 개선하면서 기술 부채 줄이기와 같은 비기능적 요구사항이 들어가는 경우가 많다. 모두 애플리케이션의 최종 사용자 경험을 개선하는 부분이며, 많은 데브옵스 팀이 이러한 영역에 더 많은 시간을 투자하고자 할 것이다.
 
이것을 기술 자동화 및 인프라 구성과 대조해 보자. 여기서는 기본적인 기능을 구축하는 것이 소프트웨어 개발의 전제 조건이 될 수 있는 동시에 지속적인 투자가 개발 팀의 생산성을 개선한다. 불행히도 개발 팀이 이러한 영역에 투자하는 시간이 많을수록 기능을 제공하고 비기능적인 기술적 관심사를 개선하는 데 사용할 수 있는 시간은 줄어든다.
 
팀이 이 세 가지 영역에 많은 시간을 투자하고 여러 팀 간에 공통된 요구사항이 있는 시나리오에서는 플랫폼 엔지니어링이 이익을 산출할 수 있는 솔루션으로 부상한다.
 
소스랩스(Saucelabs)의 기술 전략 담당 부사장 마커스 머렐은 “데브옵스 프레임워크가 확장성, 가용성, 운영 가능성을 재창조했듯이 플랫폼 엔지니어링은 개발 팀의 조립 라인에서 사용할 수 있는 교체 가능한 툴의 컨베이어 벨트와 같다. 이를 통해 테스트 같은 전통적인 병목 지점을 피하고 여러 프로젝트에 걸쳐 실행 효율성을 높이고 필요한 툴을 배포해 다양한 요구사항을 실시간으로 충족하고 출시 시간을 단축할 수 있다”고 설명했다.
 

플랫폼 엔지니어링의 혜택

품질을 개선하고 더 빠르게 기능을 제공하는 것은 플랫폼 엔지니어링의 공통적인 목표다. 플랫폼 엔지니어링은 이 목표에 어떻게 접근할까?
 
코랄로직스(Coralogix)의 개발자 지지자인 크리스 쿠니는 “플랫폼 엔지니어링은 엔지니어의 문제를 한 곳에서 해결하는 공유된 내부 서비스를 만드는 방식이다. 플랫폼 엔지니어링은 대규모로 발생하는 몇몇 핵심 문제를 해결하는 데 탁월하다”고 말했다.
 
즉, 많은 개발 팀이 있는 대규모 IT 부서는 플랫폼 엔지니어링의 효과를 얻기에 유리하다. 쿠니는 플랫폼 엔지니어링이 해결하는 문제의 예를 다음과 같이 들었다.
 
  • 팀 간의 일관성을 개선하고 단일 솔루션 사고방식을 줄임
  • 다시 만들고 맞춤 구성하는 대신 공유 구성요소를 발견하고 재사용
  • 플랫폼 내에 규정 준수 구축
 

도입 경로

위의 모든 이야기는 긍정적으로 들리지만, 비판적인 사람들은 대규모 IT 부서가 내부 기술 솔루션과 플랫폼을 제품화하려는 시도는 전에도 있었다는 점을 지적한다. 기업 리더와 팀은 플랫폼 엔지니어링으로 뛰어들기 전에 다음과 같은 질문을 고려해야 한다.
 
  • 플랫폼 엔지니어링이 효율성 또는 규정 준수의 개선을 통해 여러 팀에 걸쳐 가치를 제공할 수 있는 영역은 어디인가?
  • 새로운 병목 지점을 유발하지 않으면서 플랫폼 엔지니어링 개발 작업을 체계화하려면 어떻게 해야 하는가?
  • 더 많은 개발 팀이 플랫폼 엔지니어링이 제공하는 기능을 활용하도록 동기를 부여할 만한 당근과 채찍은 무엇인가?
  • 플랫폼 엔지니어링을 통해 초점을 옮겨 개발 팀이 기능을 제공하고 비기능적 역량을 개선하는 데 더 많은 시간을 투자하도록 할 수 있을까?
 
플랫폼 엔지니어링은 유망하지만 IT 기업은 간단한 목표부터 작게 시작해야 한다. 명확한 혜택이 있고 기술 장벽이 거의 없고 공통된 요구사항이 있는 영역을 파악해 거기에서부터 시작해야 한다.
editor@itworld.co.kr 

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

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

Copyright © 2024 International Data Group. All rights reserved.