Ch1 플랫폼 엔지니어링이
점점 더 중요해지는 이유

5/7/2025

 Timothy @ Daangn Frontend Core

Software Engineer, Frontend @Daangn Frontend Core Team

ex) Senior Lead Software Engineer @NHN Dooray (2021 ~ 2023)

ex) Lead Software Engineer @ProtoPie (2016 ~ 2021)

ex) Microsoft MVP

Timothy Lee

이 웅재

1.1 '플랫폼'과 기타 주요 용어의 정의

플랫폼

• 셀프 서비스 API, 도구, 서비스, 지식 및 지원으로 구성된 하나의 토대

• 매력적인 조직 내부 제품의 형태로 구성

• 자율적 애플리케이션 팀들은 이 플랫폼을 활용해서 팀간 조정 비용을 줄이면서도 더 빠른 속도로 제품의 기능들을 전달할 수 있다.

• 플랫폼이 아닌 것이 무엇인가

  • ​주어진 어떤 대상을 플랫폼이라고 부를 수 있으려면 '플랫폼 엔지니어링' 이라는 요소가 필요하다.

  • '위키 페이지' 는 엔지니어링이 필요 없으므로 플랫폼이 아니다.

  • '클라우드 자체' 는 방대한 서비스의 집합체

플랫폼 엔지니어링

• 플랫폼을 개발하고 운영하는 하나의 분야

• 비즈니스에 레버리지를 전달하기 위해 전체 시스템의 복잡성을 관리하는 것을 목표로 함

• 폭넓은 애플리케이션 개발자층을 위한 소프트웨어 기반 추상화로서의 플랫폼을 개발하고

• 이를 비즈니스의 토대로 운영하는 큐레이션 제품 접근 방식을 통해 목표 달성

레버리지

• (플랫폼 엔지니어링의 맥락에서) 소수의 플랫폼 팀 엔지니어들의 작업이 조직 전체의 업무를 줄여주는 것을 의미

• 플랫폼이 레버리지를 달성하는 두 가지 방식

  • ​애플리케이션 엔지니어들이 비즈니스 가치를 창출하는 과정에서 생산성을 높이는 것

  • 애플리케이션 엔지니어링 팀 간의 중복 작업을 제거하여 엔지니어링 조직의 효율성을 높이는 것

제품

• 플랫폼을 하나의 제품으로 보는 것이 매우 중요

• 플랫폼을 매력적인 제품으로 개발한다는 것

  • 플랫폼의 기능을 결정할 때 고객 중심적 접근 방식을 취한다는 뜻

  • 사용자가 주된 초점

• ​​​다양한 기능 요구사항 중 제품에 반영할 것들을 잘 큐레이션하는 것은 물론이고 반영하지 않을 것들을 신중하고 세련되게 큐레이션하기 위해 노력한다.

1.2 과도한 일반화의 늪

• 가장 심각한 문제는 인프라와 개발자 도구 관련 영역에서 발생하며, 그런 문제들은 조직이 플랫폼 엔지니어링을 요구하게 되는 가장 큰 원인이다.

• 이는 그런 시스템들이 공용 클라우드 및 오픈소스 소프트웨어와 가장 밀접하게 통합되어 있기 때문이다. 이 두 가지 트렌드는 지난 25년간 업계에 많은 변화를 가져왔는데 모든 것이 고르게 개선되지는 않았다.

• 결과적으로 애플리케이션을 구축하기는 쉬워졌지만 유지보수는 더 어려워졌으며, 시스템이 성장할수록 조직의 발전 속도는 마치 늪 속을 걷는 것처럼 느려졌다.

• 결국 우리는 소프트웨어의 작성과 유지보수에 관한 경제적 현실의 문제로 돌아올수밖에 없다.

• (추정에 따르면) 소프트웨어의 생애 주기 비용 중 최소 60 ~ 75%가 초기 개발 이후에 발생하며, 그 중 약 4분의 1은 전적으로 마이그레이션 같은 '적응적' 유지보수에 사용된다.

• 클라우드와 OSS는 유지보수 비용을 줄이기는 커녕 이 문제를 더욱 악화시켰다.

• 이들 때문에 기본요소 계층이 계속 늘어나기 때문이다.

  • ​여기서 기본요소는 광범위한 기능을 제공하지만 서로 통합되어 있지 않은 범용 구성요소를 말한다.

• 이들이 제대로 동작하려면 접착제가 필요하다.

  • 통합 코드, 일회성 자동화, 구성, 관리 도구 등등

  • 이 접착제는 모든 것을 하나로 묶어주지만, 동시에 미래의 변경을 매우 어렵게 만드는 '끈적임'의 원인이 된다.

• 이 접착제가 점차 확산되면서 '과도한 일반화의 늪'이 만들어진다.

• 애플리케이션 팀들은 빠르게 구축할 수 있는 기술을 선택하고 최신 기능 선호한다.

  • 맞춤형 접착제를 만들어낸다.

• 이런 과정이 반복되면서 더욱 복잡한 모습이 된다.

• 더 큰 문제는 시간이 지나면서 이 끈적이는 혼란을 변경하기가 대단히 어려워진다는 점이다.

• 이러한 상황을 피하는 핵심은 접착제의 양을 제한하는 것이다.

• 플랫폼 엔지니어링은 OSS와 벤더의 선택을 조직의 필요에 맞게 제한된 집합으로 추상화하고 강력한 의견을 제공함으로써 관심사의 분리를 가능하게 한다.

요약

• 추상화와 캡슐화의 개념을 구현하고 사용자를 바탕 복잡성으로부터 보호하는 인터페이스를 구축함으로써 필요한 접착제의 양을 제한한다.

1.3 과도한 일반화의 늪에 빠지게 된 과정

• 지난 25년간 소프트웨어 산업은 엄청난 변화를 겪었다.

• 그 시작은 인터넷이 대중화된 것이다.

• 과도한 일반화의 늪은 ​더 많은 것을 더 빠르게, 실패 없이 배포하라는 압박 때문에 존재한다.

선택의 폭발적 증가

• 인터넷은 새로운 소프트웨어에 대한 수요 증가

• 소프트웨어는 하드웨어에서 실행되어야 함

• 데이터센터에 더 많은 하드웨어 도입

• 인프라 엔지니어링의 성장

• 인프라 팀과 상호작용하는 애플리케이션 개발자들은 자신들이 처리해야 하는 하드웨어 문제들의 폭과 깊이에 계속 좌절

• 좌절한 애플리케이션 개발자들이 공용 클라우드를 반김

• PaaS 서비스에서 IaaS 로

• 쿠버네티스의 부상과 클라우드 네이티브

• 쿠버네티스는 많은 것을 표준화했지만 복잡성 측면에서 들이 되지 않았다.

  • 각각의 애플리케이션을 제대로 지원하기 위해서는 세부적인 설정이 대단히 많이 필요

  • 물 새는 추상화

운영 요구사항의 증가

• 인프라 기본요소와 이를 활용하는 애플리케이션이 폭발적으로 증가하면서,

• 이들을 누가 어떻게 운영할 것인가 하는 문제가 대두

• 처음엔 시스템 관리자

• 24시간 운영 지원의 중요성이 커지면서 운영 엔지니어링 팀이 성장했다.

• 데브옵스라 부르는 방식의 탄생과 광범위한 도입

  • 개발과 운영 활동을 통합하는 모델

  • 문화적 변화

  • 분리형과 통합형

• 구글의 사이트 신뢰성 엔지니어링 SRE

결과) 늪에 빠지다

• 정리하자면,

  • ​애플리케이션 팀이 늘어났고,

  • OSS와 클라우드 기본요소들도 늘어났고,

  • 이들을 선택하는 문제도 더욱더 복잡해졌다.

  • 왜 이런 상황에?) 빠른 전달을 원했기 때문이다.

• ​문제 해결에 적합한 최신 시스템을 확용해야 했다.

• 사이버 공격과 취약점 발견이 급증했고, 이로 인해 인프라와 OSS도 이러한 위험에 대응하기 위해 더 빠르게 변화하고 있다.

• 이러한 이유들로 애플리케이션 팀에게 접착제를 수정하고 다시 테스트하거나 소프트웨어를 마이그레이션해야하는 작업을 요구한다.

• 변화에 대한 압박은 개별 팀의 의사결정이 가져온 작기적 결과물이 접착제와 뒤섞인, 마치 늪과도 같은 엉망진창의 상황을 만들었다.

1.4 플랫폼 엔지니어링은 어떻게 늪을 정화하는가

• 상황

  • OSS와 클라우드 시스템에서 발생하는 새로운 복잡성을 따라잡을 수 없다.

  • 애플리케이션은 복잡해지고 개발자의 생산성은 떨어진다.

• ​해결책

  • ​플랫폼을 구축해서 이러한 복잡성을 관리한다.

• ​문제

  • ​플랫폼 구축에는 상당한 투자가 필요하다.

  • 구축과 지원 비용뿐만 아니라, 애플리케이션 팀의 OSS와 클라우드 기본요소 선택을 제한하는 데 따른 간접비용도 포함된다.

  • 플랫폼 엔지니어링 팀의 설립은 조직 개편, 역할 변경, 회사의 주력 분야 도입에 따른 추가부담을 수반한다.

• ​설명할 내용

  • ​이러한 투자를 정당화하고 장기적 가치를 전달하는지 설명

간접비용을 최소화하면서 기본요소 제한하기

• 선택의 폭발적 증가가 전적으로 나쁜 것은 아니었다.

  • 그린필드 애플리케이션을 과거보다 훨씬 빠르게 출시할 수 있게 됐고,

  • 좋아하는 시스템을 사용할 때 더 큰 자율성과 주인의식을 느낀다.

• 기업이 다양한 선택으로 인한 지원 부담과 장기 비용 절감에 초점을 맞추기 시작하면 이러한 이점은 종종 잊힌다.

• ​​리더들의 본능적인 첫 반응은 권위에 호소하여 표준을 규정하는 것

  • ​전문가들도 최적의 선택을 하기에는 비즈니스 요구사항을 충분히 이해하기 어렵고

  • 결국 애플리케이션 팀이 고통을 겪게 된다.

  • 권위에 의한 표준화만으로는 부족하다.

• ​권위에 호소하는 표준 규정 대신, 플랫폼 엔지니어링은 광범위한 요구사항을 충족할 수 있는 소수의 기본요소를 큐레이션하는 고객 중심의 제품 접근 방식을 취한다.

  • ​이러한 방식을 잘 적용한다면, 하향식 명령으로 인한 최악의 결과를 피하면서도 사용되는 OSS와 클라우드 기본요소의 수를 줄이는 것이 가능하다.

애플리케이션별 접착제 줄이기

• 한 걸음 더 나아가 남은 요소들과의 '접착제'를 줄이는 것을 목표로 한다.

• 기본요소들을 더 광범위한 요구를 충족할 수 있는 체계적인 플랫폼 역량들로 추상화함으로써 애플리케이션 수준의 접착제를 대부분 제거할 수 있다.

• 테라폼 관리를 통한 설명

마이그레이션 비용의 중앙화

• 마이그레이션 관리가 플랫폼의 가치에서 중요한 부분을 차지한다.

• 애플리케이션과 기본요소들의 수명은 길다. 그 수명들은 각각 독립적이다. 긴 수명 동안 이들은 수많은 변화를 겪는다. 그러한 변화들이 모여 높은 유지보수 비용이 발생한다.

• 다음과 같은 방식으로 이러한 비용을 절감한다.

  • ​사용 중인 OSS 및 클라우드 시스템의 다양성 감소

  • API를 통한 OSS 및 벤더 시스템의 캡슐화

    • ​플랫폼 API가 OSS와 벤더 시스템의 모든 측면을 완벽하게 캡슐화하지는 못하더라도, '충분히 좋은' API라면 구현의 상당 부분을 추상화할 수 있다. 플랫폼의 보호 덕분에 애플리케이션을 바꿀 필요가 없다.

  • ​플랫폼 사용에 대한 관측성 확보

    • ​플랫폼을 사용하는 애플리케이션의 의존성 상태에 대한 가시성 혹은 관측성은 의존성 업그레이드가 필요할 때 그 부담을 줄여준다.

  • ​​소프트웨어 개발자가 있는 팀에 OSS 및 클라우드 시스템 소유권 부여

애플리케이션 개발자의 자체 운영 권한

• 온콜 근무는 싫어한다. 하지만 자체 애플리케이션으로 인한 문제만 대응한다면 받아들인다.

• 대다수의 기업에서는 인프라, OSS, 그리고 이들을 연결하는 접착제로 인한 운영 문제가 애플리케이션 코드 자체의 문제를 압도하고 있다.

  • 더 높은 수준의 회복 탄력성을 추구하는 애플리케이션이 여러 가용 영역, 클라우드 지역, 또는 데이터센터에 걸쳐 배포될 때 볼 수 있다.

• 플랫폼 엔지니어링은 애플리케이션 팀을 대신해 장애 조치를 처리할 수 있는 탄력적인 추상화를 구축함으로써 이 문제를 해결하고 심야 긴급 호출을 줄인다.

• 바탕 시스템의 운영 복잡성을 플랫폼 추상화 뒤로 숨기면, 그러한 복잡성을 플랫폼 팀이 소유하고 관리하는 것이 가능해진다.

  • 이를 위해서는 지원하는 옵션을 제한해야 한다. 그래야 추상화 경계선을 핵심 서비스 집합으로 상향 이동할 수 있으며, 각 서비스는 광범위한 애플리케이션 용례를 처리할 수 있다.

1.5 플랫폼 구축에 필요한 권한 부여

• 기본 요소들과 그 복잡성을 관리할 플랫폼을 구축할 수 있는 팀이 필요하다.​​​

• 현재 인기 있는 플랫폼 인접 접근 방식은 네 가지이다.

  • ​이들은 모두 조직에 가치 있는 기술을 제공하지만,

  • 플랫폼 구축에 필요한 초점과 기술의 조합을 갖추지는 못했다.

• 플랫폼 엔지니어링은 이러한 엔지니어 그룹들이 각자의 사일로에서 벗어나 균형 잡힌 플랫폼을 만드는 더 광범위한 임무를 가진 팀에서 일할 것을 요구한다.

• 다음과 같은 균형이 추가되어야 한다.

  • 인프라 팀 ) 인프라 역량과 개발자 중심의 단순성 사이의 균형

  • 개발 도구 팀 ) 개발 경험과 프로덕션 지원 경험 사이의 균형

  • 데브옵스 팀 ) 애플리케이션별 최정의 접착제와 더 많은 애플리케이션을 지원하는 범용 소프트웨어 사이의 균형

  • SRE 팀 ) 신뢰성과 기능 민첩성, 비용 효율성, 보안, 성능 등 다른 시스템 특성 사이의 균형

• ​조직의 기대를 의도적으로 재설정함으로써, 플랫폼 엔지니어링은 마침내 늪을 정리할 기술을 구축하는 데 집중하는 팀을 만들 수 있게 한다.