한 설문조사에 따르면 영국의 테필로가 실시한 이 설문조사에서는 새집이 내 집처럼 느껴지기까지 평균 4개월이 걸리는 것으로 나타났습니다. 아무래도 저는 평균과는 다른가 봅니다.
저는 영국인도 아니니 어쩌면 그걸 핑계로 삼을 수 있을지도 모르겠네요. 있잖아요, 저는 지금 집에서 7년째 살고 있는데도 어떤 전등 스위치가 선풍기를 켜고 어떤 스위치가 거실 콘센트의 전원을 끄는지 아직도 헷갈립니다. 짐작하시겠지만, 잘못 누르면 그때 영화를 보거나 비디오 게임을 즐기던 사람은 상당히 당황하게 됩니다.
이런 점에서 똑같은 집은 하나도 없으며, 이는 의도된 설계입니다. 스위치나 로커 스위치 같은 장치는 동일하고 누구나 작동법을 알고 있지만, 집 안에서의 배치나 위치는 표준화되어 있지 않습니다.
하지만 홈 자동화 시스템 하나를 정해 어디를 가든 함께 가져간다면, 이따금 겪는 이런 문제는 아마 생기지 않을 것이다. 선풍기와 조명을 익숙하고 표준화된 인터페이스로 조작할 수 있기 때문이다.
이것이 클라우드 환경의 현실입니다. 모든 클라우드 환경은 공통적인 운영 작업을 수행하기 위해 API, 콘솔, 프로세스 등 동일한 메커니즘을 사용합니다. 이는 클라우드의 장점 중 하나입니다. 또한 새로운 기술 전문가를 온보딩할 때 필요한 시간을 크게 단축할 수 있습니다. 인프라 관리 계층은 모든 회사에서 동일합니다. 동일한 API. 동일한 콘솔. 동일한 프로세스.
맞춤형 데이터 센터에서는 프라이빗 클라우드든 기존 방식이든 반드시 그렇지는 않습니다. 운영하려면 특정 지식과 전문성이 필요한 여러 프레임워크(예: OpenShift, OpenStack 등)가 사용되기 때문입니다.
이는 궁극적으로 새로운 기술 전문가가 이미 ‘클라우드’에 대한 실무 지식을 갖추고 있으므로 온보딩에 걸리는 시간을 단축합니다. 클라우드 운영 팀을 확장해야 한다면 Cloud X에 익숙한 사람을 찾으면 됩니다. 이는 새로운 개념이 아닙니다. JavaScript 지식이 필요한 앱을 개발할 개발자가 필요하다면 일반적으로 Python 전문가를 찾지는 않습니다.
이것이 멀티 클라우드가 어려운 이유 중 하나입니다. 필요한 도메인 지식의 범위가 넓어지고, 온보딩 과정에서 인프라 운영 방법을 교육해야 할 필요성이 다시 생기기 때문입니다. 집마다 구조가 다르듯이 클라우드도 서로 똑같지 않습니다. 기본적인 인프라 개념은 비슷할 수 있지만 용어, 객체 모델, API, 콘솔은 서로 다릅니다.
당연하게도, 각 클라우드 환경에 특화된 도메인별 도구와 프로세스는 기업 내에 클라우드 ‘사일로’를 만들어 냈습니다. 당사의 연례 조사에서 전체 응답자의 절반은 현재 멀티 클라우드를 관리하기 위해 클라우드 환경별로 전담 팀을 운영하고 있다고 답했습니다. 또한 나머지 절반은 이 방식을 선호한다고 밝혔습니다.
이는 제게 놀라운 일이 아닙니다. 클라우드를 하나의 제품으로 생각해 보면—실제로도 제품이므로—다른 모든 제품과 마찬가지로 동일한 운영 부채가 발생한다는 사실을 금세 알 수 있습니다. 모델, API, 워크플로는 클라우드마다 고유합니다. 모든 클라우드를 어중간하게 관리하기보다는 하나에 집중해 전문성을 키우는 것이 합리적입니다.
멀티 클라우드를 실제로 운영하게 되면서 인프라 자동화 도구의 도입이 확산되었습니다. 자동화는 프로비저닝, 구성 및 운영을 더 쉽게 해줄 뿐만 아니라, 인프라 자동화 도구 자체가 특정 클라우드에 종속되지 않는다는 장점도 있습니다. 즉, 이러한 도구가 멀티 클라우드 관리를 복잡하게 만드는 차이점을 추상화하므로, 한 클라우드에서 사용한 것과 동일한 Terraform 템플릿이나 Ansible 스크립트를 다른 클라우드에서도 사용할 수 있습니다.
이는 모든 사람이 확신을 갖고 더 빠르게 움직일 수 있도록 일관된 방법론과 도구 세트로 수렴하는 사례입니다. 이러한 흐름은 엔터프라이즈 IT 전반에서 뚜렷하게 나타납니다. 애플리케이션 보안 및 전송 계층이든, 애플리케이션 인프라(웹 및 애플리케이션 서버) 계층이든, 데이터 스토리지 계층이든, 표준화는 일관성을 확보하기 위한 수단입니다. 다소 반복적으로 들릴 수 있지만, 멀티 클라우드의 과제를 논할 때 일관성은 일관되게 등장하는 주제입니다.
이처럼 멀티 클라우드 환경에서 자동화는 있으면 좋은 기능이나 경쟁 우위를 위한 수단이 아니라 필수 요소가 되었습니다.
작성자 소개
Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.
Lori Mac Vittie의 다른 블로그 게시물관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.