클라우드 운영 직무를 준비하는 취업 준비생의 프로젝트를 점검하다 보면 AWS에서 VPC와 EC2, IAM을 구성한 경험은 충분한데 온프레미스 서버가 추가되는 순간 전체 구조를 설명하지 못하는 경우가 있습니다. 클라우드 안에서는 퍼블릭 서브넷과 프라이빗 서브넷을 나누고 보안그룹도 설정했지만, 사내 서버가 클라우드 데이터베이스와 통신해야 한다면 어떤 경로를 사용해야 하는지, 내부 DNS와 클라우드 DNS는 어떻게 연결되는지, 두 환경의 사용자 권한은 어디에서 관리해야 하는지를 질문하면 준비했던 내용과 전혀 다른 문제처럼 받아들이는 식입니다. 반대로 Linux 서버와 VMware, 네트워크 장비를 다뤄본 취업 준비생 중에는 온프레미스 환경은 익숙하지만 클라우드로 시스템 일부를 이전했을 때 운영 기준을 어떻게 바꿔야 하는지 설명하지 못하는 경우도 있습니다. 서버와 네트워크는 알고 있지만 VPC와 IAM, 클라우드 모니터링이 추가되면서 어느 시스템이 어디에서 관리되는지와 장애가 발생했을 때 어느 환경부터 확인해야 하는지가 정리되지 않은 것입니다. 하이브리드 클라우드는 단순히 서버 일부는 사내에 두고 나머지는 퍼블릭 클라우드에 두는 구조만을 의미하지 않습니다. 현재 주요 클라우드 사업자도 서로 다른 위치의 인프라를 하나의 운영 범위로 연결하는 서비스를 제공하고 있습니다. AWS Outposts는 AWS 인프라와 서비스, API를 고객 온프레미스 환경까지 확장하고, Microsoft Azure Arc는 온프레미스와 에지, 다른 클라우드에 있는 서버와 Kubernetes 등을 Azure 관리체계에 연결할 수 있도록 지원합니다. Google Cloud 역시 하이브리드 클라우드를 퍼블릭 클라우드와 온프레미스·프라이빗 환경을 함께 사용하는 혼합 컴퓨팅 구조로 설명하고 있습니다. 취업 준비 관점에서 중요한 것은 이러한 제품을 모두 사용할 줄 아는 것이 아닙니다.
온프레미스에서는 기존 서버와 네트워크, 가상화 환경이 어떻게 운영되는지를 이해하고, 연동에서는 두 환경의 통신과 DNS, 데이터 이동, 장애 범위를 설계하며, 보안에서는 계정과 권한, 네트워크 정책과 로그를 서로 다른 환경에서도 일관되게 관리할 수 있어야 합니다. 하이브리드 클라우드 운영 직무는 클라우드만 아는 사람보다 기존 인프라와 클라우드가 어디에서 만나고 무엇이 달라지는지를 설명할 수 있는 준비가 중요합니다.
이번 글에서는 하이브리드 클라우드 운영 직무를 준비할 때 알아야 할 내용을 온프레미스, 연동, 보안 세 가지 기준으로 나누어 정리하겠습니다.
온프레미스는 기존 시스템이 어떤 조건에서 운영되고 있는지를 이해하는 출발점입니다
- 클라우드를 공부하기 전에 기존 서버와 네트워크가 어떻게 동작하는지 이해할 필요가 있습니다
하이브리드 환경에서는 모든 시스템이 처음부터 클라우드에 만들어지는 것이 아닙니다. 기존 데이터센터나 사내 전산실에서 운영하던 서버와 데이터베이스, 네트워크 장비 가운데 일부는 그대로 유지되고 특정 시스템만 클라우드로 확장되는 경우도 있기 때문에 기존 인프라를 읽는 능력이 필요합니다.
온프레미스 준비에서는 다음 내용을 연결해서 볼 수 있습니다.
- Linux와 Windows 서버가 어떤 역할로 운영되는지 구분합니다.
- 물리 서버와 가상머신의 차이를 이해합니다.
- 내부 네트워크와 VLAN, 서브넷 구조를 확인합니다.
- 사내 DNS와 DHCP가 어떤 역할을 하는지 이해합니다.
- 서버와 데이터베이스가 어느 저장장치를 사용하는지 살펴봅니다.
- 장애 발생 시 서버와 네트워크, 애플리케이션을 어떤 순서로 확인할지 정리합니다.
예를 들어 사내 애플리케이션 서버가 데이터베이스에 접속하지 못한다고 하면 클라우드 서비스처럼 콘솔 상태만 확인해서는 충분하지 않을 수 있습니다. 가상머신이 정상인지, 호스트 서버에 문제가 없는지, 내부 네트워크와 DNS는 정상인지, 데이터베이스 프로세스는 실행 중인지까지 여러 계층을 나누어 확인해야 합니다. 이런 경험이 있어야 온프레미스를 단순히 클라우드 이전의 오래된 환경이 아니라 하이브리드 시스템을 구성하는 하나의 운영 영역으로 이해할 수 있습니다.
- 온프레미스와 클라우드는 서버가 있다는 점은 같지만 운영 방식에서 차이가 있습니다
두 환경 모두 컴퓨팅과 네트워크, 스토리지, 계정이라는 공통 요소를 가지고 있습니다. 하지만 자원을 생성하고 장애를 확인하며 용량을 늘리는 방식에서는 차이가 나타납니다.
- 온프레미스 자원 관리: 물리 서버와 스토리지 용량이 먼저 준비되어 있어야 하며 장비 교체와 증설에 실제 인프라 작업이 필요할 수 있습니다.
- 클라우드 자원 관리: 필요한 컴퓨팅과 스토리지 자원을 API나 콘솔, IaC를 통해 비교적 빠르게 생성하고 변경할 수 있습니다.
- 온프레미스 장애 범위: 하드웨어와 가상화 호스트, 네트워크 장비까지 직접 확인해야 할 수 있습니다.
- 클라우드 장애 범위: CSP가 관리하는 물리 영역과 사용자가 관리하는 운영체제·애플리케이션 영역을 구분해야 합니다.
- 공통 운영 영역: 어느 환경이든 모니터링과 백업, 권한 관리, 장애 대응 기준은 필요합니다.
따라서 클라우드 경험이 있다고 해서 기존 인프라 운영 경험이 필요 없어지는 것은 아닙니다. 하이브리드 운영에서는 어느 영역까지 직접 관리해야 하고 어느 영역부터 클라우드 사업자가 관리하는지를 구분하는 능력이 중요합니다.
- 가상화 경험은 온프레미스와 클라우드를 연결해서 이해하는 데 도움이 됩니다
클라우드를 처음 공부하면 EC2나 Azure VM 같은 가상머신을 하나의 서비스로만 받아들이기 쉽습니다. 하지만 온프레미스의 VMware나 Hyper-V 같은 가상화 환경을 이해하면 물리 자원을 여러 가상 서버로 나누어 사용하는 기본 구조를 더 쉽게 연결할 수 있습니다.
온프레미스 가상화 프로젝트에서는 다음 내용을 경험으로 남길 수 있습니다.
- 하나의 물리 호스트에서 여러 가상머신을 운영하는 구조를 이해합니다.
- CPU와 메모리, 디스크 자원이 어떻게 분배되는지 확인합니다.
- 가상 네트워크와 실제 네트워크의 연결 관계를 살펴봅니다.
- 가상머신 장애와 호스트 장애를 구분합니다.
- 스냅숏과 백업의 목적 차이를 이해합니다.
- 자원 부족이 여러 서버에 어떤 영향을 줄 수 있는지 확인합니다.
이런 경험이 있으면 클라우드에서도 인스턴스 하나만 보는 것이 아니라 그 위에서 동작하는 운영체제와 네트워크, 스토리지 관계를 더 구조적으로 이해할 수 있습니다.
- 하이브리드 운영에서는 기존 시스템을 무조건 클라우드로 옮기는 것이 목표가 아닙니다
하이브리드 클라우드를 공부하면서 온프레미스 환경을 클라우드로 모두 이전하는 과정이라고 생각하기 쉽습니다. 하지만 실제로는 지연시간과 데이터 위치, 기존 시스템 의존성, 규제, 비용 등을 고려해 어느 워크로드를 어디에 둘 것인지 결정해야 할 수 있습니다.
- 낮은 지연시간이 필요한 시스템: 현장 장비나 내부 시스템과 빠르게 통신해야 한다면 로컬 환경을 유지할 이유가 있을 수 있습니다.
- 데이터 위치가 중요한 시스템: 특정 데이터가 일정한 장소나 규제 범위 안에 있어야 한다면 온프레미스 또는 로컬 처리 환경이 필요할 수 있습니다.
- 탄력적인 자원이 필요한 시스템: 사용량 변화가 큰 서비스는 퍼블릭 클라우드 확장이 적합할 수 있습니다.
- 기존 시스템 의존성이 큰 환경: 오래된 애플리케이션과 장비가 강하게 연결되어 있다면 단계적인 전환이 필요할 수 있습니다.
- 통합 운영이 필요한 환경: 위치가 달라도 공통 정책과 모니터링 체계를 적용할 방법을 고려해야 합니다.
AWS도 Outposts의 활용 사례로 낮은 지연시간과 로컬 데이터 처리, 데이터 레지던시, 온프레미스 시스템과 의존성이 있는 워크로드 등을 제시하고 있습니다. 따라서 하이브리드 클라우드 직무 준비에서도 단순 마이그레이션 경험보다 왜 특정 시스템을 온프레미스에 남기고 다른 시스템을 클라우드로 확장했는지를 설명하는 판단 과정이 중요합니다.
연동은 두 환경을 연결하는 것보다 통신과 데이터 흐름을 안정적으로 운영하는 영역입니다
- 하이브리드 환경에서는 네트워크 경로를 끝까지 설명할 수 있어야 합니다
온프레미스와 클라우드에 각각 서버를 만드는 것만으로 하이브리드 환경이 완성되는 것은 아닙니다. 실제 서비스가 동작하려면 서로 다른 네트워크에 있는 시스템이 필요한 범위 안에서 통신할 수 있어야 합니다.
연동 프로젝트에서는 다음 내용을 연결할 수 있습니다.
- 온프레미스와 클라우드의 IP 주소 범위를 구분합니다.
- 주소 범위가 서로 충돌하지 않는지 확인합니다.
- VPN이나 전용 연결의 역할을 이해합니다.
- 두 환경 사이의 라우팅 경로를 확인합니다.
- 내부 서비스 이름을 어느 DNS에서 해석하는지 구분합니다.
- 연결이 끊겼을 때 어느 구간부터 확인할지 정리합니다.
예를 들어 사내 애플리케이션이 클라우드의 데이터베이스에 접근해야 한다면 서버 주소만 알고 있다고 통신이 가능한 것은 아닙니다. 온프레미스 라우터에서 클라우드까지 어떤 경로를 사용하는지와 클라우드 측 라우팅, 방화벽 정책, DNS 해석이 모두 맞아야 정상적인 연결이 이루어집니다. AWS Outposts 역시 온프레미스 네트워크와 AWS 리전 사이의 연결이 필요하고, Outposts의 VPC와 로컬 네트워크가 통신할 수 있도록 네트워크 구성을 요구합니다.
- 연결이 되었다는 것과 안정적으로 운영할 수 있다는 것은 다른 문제입니다
실습에서는 VPN 터널이 연결되고 ping이 통과하면 연동이 완료되었다고 생각하기 쉽습니다. 하지만 운영 환경에서는 연결 속도와 장애 시 영향, 경로 이중화와 모니터링까지 함께 봐야 합니다.
- 연결 중심의 실습: 온프레미스와 클라우드 사이에 통신 경로를 만들고 기본 연결을 확인합니다.
- 운영 중심의 연결: 어느 애플리케이션이 해당 경로를 사용하며 필요한 대역폭이 어느 정도인지 파악합니다.
- 장애 중심의 연결: 주 연결 경로가 끊겼을 때 서비스가 어떻게 영향을 받는지 확인합니다.
- 모니터링 중심의 연결: 지연시간과 패킷 손실, 터널 상태 등을 지속적으로 확인합니다.
- 복구 중심의 연결: 장애 이후 연결이 복구되었을 때 애플리케이션과 데이터 상태까지 다시 검증합니다.
이 차이가 있어야 하이브리드 네트워크 프로젝트가 단순 VPN 구축 경험에서 벗어나 실제 서비스를 운영하기 위한 연결 관리 경험으로 발전합니다.
- DNS와 데이터 흐름을 포함하면 하이브리드 연동을 더 현실적으로 이해할 수 있습니다
네트워크 연결만 성공해도 IP 주소로는 두 환경이 통신할 수 있습니다. 하지만 실제 애플리케이션은 IP 주소보다 도메인과 서비스 이름을 사용하고, 데이터 역시 여러 시스템 사이를 지속적으로 이동할 수 있습니다.
연동 실습에서는 다음 내용을 추가로 확인할 수 있습니다.
- 온프레미스와 클라우드에서 사용하는 DNS 영역을 구분합니다.
- 내부 서비스 이름이 어느 DNS 서버에서 해석되는지 확인합니다.
- 같은 이름이 서로 다른 환경에서 충돌하지 않는지 살펴봅니다.
- 데이터가 어느 방향으로 이동하는지 기록합니다.
- 대용량 전송이 네트워크에 미치는 영향을 확인합니다.
- 연결 장애가 데이터 동기화에 어떤 영향을 주는지 살펴봅니다.
예를 들어 사내 데이터베이스의 일부 데이터를 클라우드 분석 환경으로 전달한다면 단순히 두 서버가 통신할 수 있다는 사실만으로는 충분하지 않습니다. 데이터가 어느 주기로 이동하는지, 전송이 실패하면 어느 시점부터 다시 처리해야 하는지, 네트워크가 복구된 이후 중복 데이터가 생기지 않는지도 확인할 필요가 있습니다. 이런 경험이 포함되면 연동을 네트워크 연결과 서비스 이름, 데이터 이동을 함께 관리하는 문제로 이해할 수 있습니다.
- 하이브리드 장애는 온프레미스와 클라우드를 나누어서 확인하는 기준이 필요합니다
두 환경이 연결되어 있으면 장애 원인도 한쪽에만 존재한다고 보기 어렵습니다. 따라서 문제가 발생했을 때 어느 환경과 어느 구간까지 정상인지 범위를 나누어 확인하는 능력이 중요합니다.
- 온프레미스 구간: 서버와 가상화 호스트, 내부 네트워크와 DNS 상태를 확인합니다.
- 연결 구간: VPN이나 전용 회선, 라우팅과 터널 상태를 확인합니다.
- 클라우드 구간: VPC와 라우팅, 보안 정책, 클라우드 서비스 상태를 확인합니다.
- 애플리케이션 구간: 실제 서비스 프로세스와 데이터베이스 연결 상태를 확인합니다.
- 통합 검증 구간: 네트워크 복구 이후 애플리케이션과 데이터 흐름까지 정상화되었는지 확인합니다.
예를 들어 온프레미스 서버가 클라우드 서비스에 접속하지 못할 때 클라우드 방화벽만 계속 변경하면 원인을 찾기 어려울 수 있습니다. 내부 DNS 문제인지, 온프레미스 라우팅인지, 연결 터널인지, 클라우드 측 정책인지 단계적으로 범위를 좁혀야 합니다. 하이브리드 운영 프로젝트에서도 정상 연결 → 장애 발생 → 구간 분리 → 원인 확인 → 복구 → 전체 서비스 재검증의 흐름이 남아 있으면 직무 이해도를 더 구체적으로 보여줄 수 있습니다.
보안은 서로 다른 환경의 계정과 정책을 하나의 운영 기준으로 관리하는 영역입니다
- 하이브리드 보안에서는 계정과 권한이 어디에서 관리되는지 먼저 구분해야 합니다
온프레미스와 클라우드를 함께 사용하면 사용자와 관리자 계정도 여러 환경에 나뉠 수 있습니다. 같은 사람이 사내 서버와 클라우드 자원을 모두 사용하더라도 각 환경에서 전혀 다른 권한 구조를 사용하면 관리가 복잡해질 수 있습니다.
보안 준비에서는 다음 내용을 연결할 수 있습니다.
- 온프레미스 계정과 클라우드 계정의 역할을 구분합니다.
- 사용자와 관리자 권한을 분리합니다.
- 서비스 계정에 필요한 권한 범위를 제한합니다.
- 여러 환경에서 동일한 사용자를 어떻게 인증할지 이해합니다.
- 퇴사나 부서 이동 시 권한이 어디에서 변경되어야 하는지 확인합니다.
- 관리자 활동과 중요한 권한 변경을 로그로 남깁니다.
예를 들어 개발자가 온프레미스 서버에서는 일반 사용자지만 클라우드에서는 관리자 권한을 가지고 있다면 실제 권한 범위를 한눈에 파악하기 어려울 수 있습니다. 하이브리드 보안에서는 각 환경의 권한을 따로 보는 것뿐 아니라 한 사용자가 전체 시스템에서 어느 수준의 접근권한을 가지고 있는지를 확인하는 관점이 중요합니다.
- 네트워크 연결과 보안 연결은 같은 의미가 아닙니다
온프레미스와 클라우드 사이의 통신 경로를 만들었다고 해서 모든 시스템이 서로 자유롭게 통신할 필요는 없습니다. 오히려 연결된 이후 어떤 시스템 사이의 통신을 허용할 것인지가 더 중요해집니다.
- 통신 가능 상태: 두 네트워크 사이에 정상적인 라우팅 경로가 존재합니다.
- 허용 정책 상태: 실제 업무에 필요한 서버와 포트만 통신하도록 제한합니다.
- 관리 접속 상태: 관리자용 접근 경로와 일반 서비스 트래픽을 구분합니다.
- 데이터 보호 상태: 민감한 데이터가 이동할 때 필요한 암호화와 접근 기준을 적용합니다.
- 감사 상태: 중요한 접속과 권한 변경을 추적할 수 있도록 로그를 남깁니다.
이 차이를 이해하면 VPN이나 전용 연결을 만들었다는 사실만으로 보안이 확보되었다고 생각하지 않게 됩니다. 연결된 환경일수록 필요한 통신만 허용하고 누가 어떤 경로로 접근했는지 확인할 수 있어야 한다는 점이 하이브리드 보안의 중요한 기준입니다.
- 로그와 모니터링을 통합해서 보는 경험도 하이브리드 운영에서 중요합니다
온프레미스 서버는 자체 로그와 모니터링 도구를 사용하고 클라우드에서는 CSP의 모니터링 서비스를 사용하면 장애나 보안 이벤트를 한 번에 파악하기 어려울 수 있습니다. 따라서 서로 다른 환경에서 발생한 이벤트를 시간과 계정, 시스템 기준으로 연결해서 보는 경험이 필요합니다.
보안·운영 프로젝트에서는 다음 내용을 확인할 수 있습니다.
- 온프레미스 서버의 인증과 시스템 로그를 수집합니다.
- 클라우드의 계정 활동과 네트워크 로그를 확인합니다.
- 시간 기준을 통일해 이벤트 발생 순서를 비교합니다.
- 동일한 사용자나 시스템에서 발생한 이벤트를 연결합니다.
- 정상적인 운영 활동과 이상 이벤트를 구분합니다.
- 문제 해결 이후 같은 이상 현상이 반복되지 않는지 확인합니다.
예를 들어 클라우드 계정에서 비정상적인 접근이 확인되었다면 해당 계정이 온프레미스 시스템에서도 사용되었는지 함께 확인해야 영향 범위를 더 정확하게 판단할 수 있습니다. Microsoft가 Azure Arc를 온프레미스와 에지, 다중 클라우드 환경을 하나의 관리 영역으로 연결하는 플랫폼으로 제공하는 것도 분산된 자원을 일관된 정책과 관리체계에서 다루려는 접근의 한 사례입니다.
- 하이브리드 보안은 제품 이름보다 일관된 정책을 유지할 수 있는지가 중요합니다
클라우드 보안 서비스를 여러 개 사용한다고 해서 보안 수준이 자동으로 높아지는 것은 아닙니다. 환경마다 다른 도구를 사용하더라도 계정과 네트워크, 데이터, 로그 관리에 동일한 기본 원칙을 적용할 수 있어야 합니다.
- 계정 관리 기준: 일반 사용자와 관리자, 서비스 계정의 권한을 필요한 범위로 제한합니다.
- 네트워크 기준: 시스템 간 필요한 통신만 허용하고 관리 트래픽을 분리합니다.
- 데이터 기준: 민감도와 사용 목적에 따라 저장과 이동, 접근 범위를 구분합니다.
- 로그 기준: 어느 환경에서 발생한 이벤트라도 시간과 사용자, 시스템을 추적할 수 있도록 합니다.
- 변경 관리 기준: 네트워크와 보안 정책을 변경했을 때 영향을 확인하고 기록을 남깁니다.
- 복구 기준: 장애나 보안 문제가 해결된 이후 서비스와 데이터, 권한 상태를 다시 검증합니다.
AWS의 하이브리드 클라우드 권장 프레임워크도 네트워킹과 보안뿐 아니라 복원력, 용량 계획, 인프라 관리까지 함께 다루고 있습니다. 이는 하이브리드 운영이 특정 연결 기술 하나가 아니라 여러 운영 기준을 동시에 맞추는 문제라는 점을 보여줍니다. 따라서 취업 준비에서도 보안 제품을 많이 나열하기보다 온프레미스와 클라우드에 동일한 접근통제와 변경관리, 모니터링 원칙을 어떻게 적용했는지를 프로젝트로 보여주는 편이 더 중요합니다.
- conclusion
하이브리드 클라우드 운영 직무를 준비할 때 가장 먼저 피해야 할 것은 AWS나 Azure 같은 퍼블릭 클라우드 기술만 공부하면 충분하다고 생각하는 것입니다. 하이브리드 환경에서는 기존 데이터센터와 사내 서버가 사라지는 것이 아니라 클라우드와 함께 운영될 수 있기 때문에 Linux와 가상화, 네트워크, DNS, 저장장치 같은 전통적인 인프라 지식도 계속 필요합니다. 온프레미스에서는 기존 시스템이 어떤 구조와 제약 안에서 운영되는지 이해해야 합니다. 클라우드로 옮기지 못하는 시스템이 왜 남아 있는지와 물리·가상 서버, 내부 네트워크가 어떤 방식으로 연결되어 있는지를 설명할 수 있어야 합니다. 연동에서는 단순히 VPN을 연결하는 것을 넘어 두 환경의 IP와 라우팅, DNS, 데이터 이동을 하나의 서비스 흐름으로 이해해야 합니다. 연결이 끊겼을 때 어느 구간부터 확인할 것인지와 복구 이후 애플리케이션과 데이터가 정상인지까지 검증할 수 있어야 실제 운영 경험으로 이어집니다. 보안에서는 서로 다른 환경의 계정과 권한, 네트워크 정책, 로그를 각자 따로 관리하는 데서 끝나지 않아야 합니다. 누가 어느 시스템에 접근할 수 있는지와 필요한 통신만 허용되고 있는지, 중요한 활동을 여러 환경에서 추적할 수 있는지를 하나의 기준으로 확인해야 합니다.
최종적으로 확인할 항목은 다음과 같습니다.
- Linux 서버와 가상화 환경의 기본 구조를 이해하고 있는지 확인합니다.
- 온프레미스 네트워크와 클라우드 VPC의 차이를 설명할 수 있는지 살펴봅니다.
- VPN이나 전용 연결이 어느 구간을 연결하는지 이해하고 있는지 확인합니다.
- DNS와 데이터 흐름을 두 환경에 걸쳐 설명할 수 있는지 점검합니다.
- 온프레미스와 클라우드 계정의 권한 범위를 구분할 수 있는지 살펴봅니다.
- 두 환경의 로그와 장애 정보를 연결해 원인을 좁힌 경험이 있는지 확인합니다.
하이브리드 클라우드 운영 준비 흐름은 다음과 같이 연결할 수 있습니다.
- Linux와 네트워크 기초 → 온프레미스 서버 구성 → 가상화 이해 → 내부 DNS와 계정 관리 → 퍼블릭 클라우드 VPC 구성 → 두 환경 IP 설계 → VPN 또는 전용 연결 이해 → 라우팅과 DNS 연동 → 데이터 이동 확인 → 계정과 권한 통합 관점 → 로그와 모니터링 연결 → 장애 구간 분리 → 복구 후 재검증 → 자동화와 운영 문서화 → 포트폴리오와 면접 연결
결국 하이브리드 클라우드 운영 직무에서 중요한 것은 온프레미스와 클라우드를 각각 공부했다는 사실이 아닙니다. 온프레미스에서는 기존 인프라의 구조와 운영 제약을 이해하고, 연동에서는 서로 다른 환경의 네트워크와 데이터 흐름을 안정적으로 연결하며, 보안에서는 계정과 정책, 로그를 일관된 기준으로 관리할 수 있는가가 핵심입니다. 이 세 영역이 하나의 프로젝트 안에서 연결되어 있다면 클라우드 서비스 사용 경험을 넘어 실제 기업 환경에서 서로 다른 인프라를 함께 운영하는 하이브리드 클라우드 직무의 문제를 이해하고 있다는 점을 포트폴리오와 면접에서 더 구체적으로 보여줄 수 있습니다.
