American Express의 부사장 겸 글로벌 인프라 책임자인 Matthew Liste는 성공적인 기술 플랫폼은 구성 요소의 수가 아니라 복잡성을 숨기고 개발자에게 안정적이며 명확한 경험을 제공하는 능력으로 평가해야 한다고 본다. Liste는 Goldman Sachs, JPMorgan Chase, American Express에서 중요 시스템을 위한 플랫폼과 인프라를 구축하며 보낸 20년 이상의 경험을 바탕으로 QCon San Francisco에서 발표했다.
Liste가 설명한 플랫폼은 많은 수의 내부 개발자를 지원한다. American Express에서는 약 2만 명, JPMorgan Chase에서는 약 6만 명의 사용자를 지원한다. 클라우드 서비스 제공업체와 규모는 다르지만, 다른 사람들이 의존하는 계층을 구축하는 모든 팀에 동일한 기본 원칙이 적용된다고 그는 본다.
좋은 플랫폼은 무슨 일이 일어나는지는 숨기지 않고 복잡성을 숨긴다
Liste는 플랫폼을 그 위에서 애플리케이션을 구축하기 위한 기반을 이루는 통합 기술 집합으로 정의하면서 시작한다. 그는 이를 상하수도 서비스에 비유한다. 사용자는 서비스가 작동하는 한 그 뒤에 있는 인프라를 생각하지 않지만, 서비스가 중단되면 즉시 알아차린다.
따라서 플랫폼 경험은 직관적이어야 하며, 모니터링, 신원, 네임스페이스를 위한 통합 기반과 같이 공유 가능하고 상호 교환 가능한 구성 요소를 사용해야 한다. 이러한 조합 가능성은 플랫폼을 추가적인 노력 없이는 함께 작동하지 않는 별개의 서비스 모음이 아니라 Lego 블록에 가깝게 만든다.
안정성, 보안, 확장성은 선택 사항이 아니다
Liste는 자신이 ‘세 가지 기둥’이라고 부르는 안정성, 보안, 확장성을 제시한다. 필요한 가용성 수준은 시스템의 가치에 따라 달라진다. 그의 발표에 따르면 American Express의 신용카드 승인 시스템은 최대 6개의 9 수준으로 작동하는 반면, 다른 시스템은 더 많은 중단 시간을 감내할 수 있다.
그는 또한 초기의 성공이 확장성 문제를 가릴 수 있다고 강조한다. 처음에는 잘 작동하던 플랫폼도 사용량이 증가하면 병목을 겪을 수 있고, 이는 안정성에 직접적인 영향을 미친다. 따라서 서비스 소비자와 함께 서비스 수준 목표(SLO)를 정하고, 출시 당일뿐 아니라 시간이 지나도 이를 준수해야 한다.
지속적인 업데이트와 차별화되지 않는 작업의 최소화
Liste는 플랫폼을 최신 상태로 유지하는 일을 가장 어렵고 미루기 쉬운 작업 중 하나로 본다. 미뤄진 업그레이드가 쌓이면 최신 버전으로의 전환 비용이 커지고 고객에게 영향을 줄 수 있다. 그는 내부 기준으로 0114를 제안한다. 이는 자동화를 통해 정기 유지보수에 필요한 인력을 0명으로 만들고, 전체 플릿의 모든 구성 요소를 업그레이드할 수 있으며, 하루 이내에 업그레이드를 완료하고, 14일 이하의 주기로 업데이트를 수행하는 것을 의미한다.
그는 또한 충분한 품질로 이미 제공되는 것을 다시 구축하지 말라고 권한다. 새로운 PostgreSQL 엔진을 작성하는 대신, 규제 요건을 충족하는 데 필요한 부분인 객체 저장소로 매일 백업을 수행하는 제어 계층을 구축하는 사례를 든다. 핵심은 공학적으로 가장 흥미로운 작업이 아니라 조직에 필요한 가치에 집중하는 것이다.
명확한 결정과 소비자와의 계약적 관계
플랫폼 소유자는 고객의 의견을 들어야 하지만 모든 요청을 실행해서는 안 된다. 자원은 제한되어 있고, 기존 기능을 폐기하지 않은 채 유지하면 기술 부채가 쌓여 더 중요한 기능을 개발할 수 없게 된다. 따라서 플랫폼은 명확한 ‘입장’을 가져야 한다. 무엇을 지원할지, 무엇을 중단할지, 무엇이 대다수 사용자의 요구를 충족하는지 정해야 한다.
여기에는 API, 서비스 수준 계약, 운영을 통해 책임 범위를 공식적으로 설정하는 일이 포함된다. 팀이 무엇을 제공하는지 아는 것만으로는 충분하지 않다. 소비자 역시 자신에게 어떤 책임이 있는지, 플랫폼이 넘지 않는 경계가 무엇인지 알아야 한다. Liste는 플랫폼을 형태가 고정된 구성 요소에 비유한다. 제한된 팀이 모든 고객을 위한 맞춤형 제품을 만들 수는 없기 때문이다.
실제 경험: 일찍 시도하고, 세부 사항을 숨기지 않는 추상화를 사용하라
Liste는 구축 결정을 내린 뒤 빠르고 반복적으로 실패하되, 전환 과정에서는 고객을 보호하라고 조언한다. 그는 Linux 컨테이너와 여러 오케스트레이션 도구를 초기에 실험한 뒤 Kubernetes로 전환한 사례를 든다. 조기에 실험했기 때문에 팀은 하나의 솔루션이 성숙하기를 기다리지 않고 학습할 수 있었다.
반대로 추상화 계층이 그 아래에서 일어나는 일을 가려서는 안 된다. Terraform과 같은 사용자 인터페이스, API, Infrastructure as Code를 제공할 수 있지만, 장애를 이해하고 필요할 때 동작을 조정할 수 있도록 충분한 가시성과 세부 정보를 제공해야 한다. Liste는 오픈 소스와 개방형 표준을 기반으로 구축해야 한다고 강조하며 마무리한다. 그래야 플랫폼 팀이 모든 계층을 처음부터 다시 만드는 대신 통합과 부가 가치에 집중할 수 있다.
이 원칙들이 중요한 이유
Liste의 주장에 담긴 핵심 가치는 플랫폼 구축을 도구 모음을 출시하는 프로젝트가 아니라 장기적인 운영상의 약속으로 전환한다는 데 있다. 플랫폼은 도입된 뒤 많은 팀에 영향을 미치므로, 새로운 기능을 빠르게 추가하는 것보다 업데이트 가능성, 책임의 명확성, 폐기 관리가 더 중요해진다. 이러한 원칙은 실무 경험에 기반한 지침일 뿐 성공을 보장하는 통일된 표준은 아니다. 가용성 수준, 자동화 범위, 추상화 선택은 여전히 시스템의 특성과 사용자 요구에 따라 달라진다.
뉴스 출처
InfoQ - Architecture Articles
원문 보기 ↗