DevOps를 가속화하는 플랫폼 엔지니어링 | 인프콘2023

서비스 개발자가 기능과 비즈니스 일정에 더해 버전 관리, CI/CD, 모니터링, 프로비저닝과 컨테이너까지 모두 익혀야 하면 인지 부하가 감당하기 어려워진다. 클라우드 네이티브 도구의 복잡성은 번아웃 위험을 높이고, 명목상 운영팀을 없애도 각 팀의 소수 전문가가 운영을 전담하는 섀도 운영을 만든다. DevOps의 가치가 틀려서가 아니라 이를 수행할 수단과 학습 비용이 분산된 현실을 해결하기 위해 플랫폼 엔지니어링이 필요해진다.

Netflix의 full-cycle developer는 자신이 만든 것을 운영하되 모든 팀이 배포·로깅·모니터링 도구를 반복해서 만들지 않도록 공통 플랫폼 팀의 지원을 받는다. Google SRE는 수작업 운영 문제에 소프트웨어 엔지니어링을 적용해 반복 업무를 자동화하고 내부 서비스와 도구로 확장했다. 빅테크가 DevOps를 실현하며 축적한 이런 해법이 업계 밖으로 일반화된 개념이 플랫폼 엔지니어링이며, 새로운 목표보다 기존 목표를 가능하게 하는 수단에 가깝다.

내부 개발자 플랫폼은 인프라 팀에 티켓을 보내 결과를 기다리는 대신 개발자가 서비스 형태의 인터페이스에서 필요한 자원을 직접 얻도록 한다. 뒤에서는 Terraform이나 코드가 조직 정책에 맞게 인프라를 구성하고, 앞에서는 개발자가 알아야 할 롤백 같은 제어만 노출해 나머지 복잡성을 감춘다. 추상화의 경계는 조직과 제품마다 다르지만 운영 피드백에 필요한 정보까지 숨기지 않아야 IDP가 DevOps를 가속하는 목적을 지킬 수 있다.

사람이 요청을 심사하는 게이트키퍼 대신 정책을 코드화한 가드레일을 제공하면 개발자는 시간과 담당자에 구애받지 않고 안전하게 셀프서비스할 수 있다. 모든 개발자에게 Terraform과 클라우드 세부 지식을 요구하지 말고 낮은 진입점으로 기본 품질을 끌어올리면서 숙련자에게는 높은 확장 가능성을 남겨야 한다. 사내 개발자를 강제로 쓰게 할 사용자가 아니라 고객으로 보고 제공자의 함정을 경계하며, 개발자 경험과 실제 생산성 향상을 계속 측정하는 제품 팀처럼 플랫폼을 운영해야 한다.