클라우드를 고르기 전에 워크로드부터 분류해야 하는 이유

‘회사에 맞는 클라우드’를 찾으면 안 되는 이유

회사 단위 선택은 여러 워크로드가 같은 조건이라고 전제합니다. 실제로는 그렇지 않은 경우가 많습니다. 외부 고객이 쓰는 공개 웹서비스는 갑작스러운 트래픽과 사용자 지연이 중요합니다. 야간에만 도는 데이터 집계 작업은 실행 시간대와 내부 데이터 의존성이 더 중요합니다. 사내 관리시스템은 동시 사용자가 적어도 권한과 감사, 기존 업무시스템과의 연결이 앞섭니다. 데이터베이스는 애플리케이션보다 이동과 복구의 부담이 큽니다.

이들을 한 묶음으로 두고 “AWS를 유지할까, 다른 CSP로 옮길까”를 물으면 서로 다른 요구가 하나의 평균값으로 사라집니다. 그 결과는 흔히 두 방향 중 하나로 흐릅니다. 기능이 가장 많은 사업자를 고른 뒤 실제로 쓰지 않는 복잡성까지 떠안거나, 월 기본요금이 낮은 상품을 고른 뒤 데이터 이동과 지원, 운영 인력, 장애 대응에서 예상하지 못한 부담을 만납니다. 어느 쪽이든 문제는 사업자가 아니라 비교 전에 워크로드의 조건을 나누지 않았다는 데 있습니다.^[1]

워크로드는 어떤 단위로 나눠야 할까

워크로드는 목적과 책임, 실패 영향을 따로 판단하는 실행 단위로 잡습니다. 서버 한 대와 일치할 필요는 없습니다. 한 서버에 여러 워크로드가 함께 있기도 합니다. 하나의 워크로드가 여러 서버와 관리형 서비스에 걸쳐 있기도 합니다.

AWS의 Well-Architected 범위 지침은 검토 전에 워크로드의 소유자와 목적, 중단됐을 때의 영향, 경계, 외부 의존성을 먼저 확인하도록 합니다. 이 질문들은 인프라 자산 목록보다 사업 결과와 책임 경계를 먼저 보게 합니다.^[2]

다음 다섯 조건 가운데 하나라도 실질적으로 다르면 별도 워크로드로 나눌 후보가 됩니다. 업무 소유자나 최종 승인자, 따로 시작하고 중단하고 폐기하는지 여부, 다루는 데이터의 민감도와 위치와 보존 조건, 중단 영향과 운영 지원 시간, 사용자 지역과 지연 요구와 수요 패턴과 외부 의존성입니다.

반대로 목적과 소유자, 데이터, 실패 영향, 운영 방식이 모두 같고 항상 함께 바뀌는 구성요소라면 하나의 워크로드로 묶습니다. 처음부터 마이크로서비스 단위로 잘게 나누거나, 현재 서버 목록을 그대로 워크로드 목록으로 옮길 필요는 없습니다.

Workload Classification Matrix

아래 매트릭스는 NIST의 역할·통제 모델과 AWS·Azure·Google Cloud의 아키텍처 검토 항목을 하나의 배치 의사결정 순서로 재구성한 것입니다. 제품 기능을 비교하는 표가 아니라, 비교에 들어가기 전 요구사항을 정리하는 표입니다.^[3][6]

이 표의 값은 추측으로 채우지 않습니다. 각 항목에는 Confirmed 또는 Unknown을 붙입니다. 확인된 값에는 근거와 승인자를 남깁니다.

특히 “규정상 국내에 있어야 한다”, “보안을 위해 전용망이 필수다”, “24시간 지원이 반드시 필요하다” 같은 문장은 누가 어떤 법률과 계약, 내부 정책, 업무 요구를 근거로 확정했는지 확인해야 합니다. 특정 산업에 적용되는 데이터 위치나 규제 결론을 다른 조직에 그대로 옮겨서는 안 됩니다.

Hard Constraint / Preference / Unknown을 섞지 않는다

요구사항 목록이 있어도 모든 항목을 같은 무게로 비교하면 결정이 왜곡됩니다. 세 상태를 갈라야 합니다.

판단 규칙은 간단합니다. 모든 Hard Constraint를 충족하는 환경만 후보가 됩니다. 우선순위는 그 후보 안에서 Preference를 비교해 정합니다. 후보군을 바꿀 수 있는 Unknown이 남아 있으면 판단을 보류합니다.

기존 계약이나 할인, 사업자와의 파트너 관계, 팀의 익숙함은 대체로 Preference입니다. 문서로 남은 계약상 제약이나 기술적 의존성이 없는 한 Hard Constraint로 올려서는 안 됩니다. 파트너 관계는 기술적 우월성을 증명하는 Evidence도 아닙니다.

Unknown을 별도 상태로 두는 이유는 의사결정의 빈칸을 숨기지 않기 위해서입니다. 데이터 이동량을 모르는 상태에서 전송 요금이 싼 사업자를 찾는 것은 순서가 맞지 않습니다. 야간 장애 대응 주체가 없는 상태에서 24시간 서비스 구조를 비교하는 것도 마찬가지입니다.

Workload Placement Card

분류 결과는 회의록 속 문장보다 한 장의 카드로 남기는 편이 낫습니다. 다음 양식은 특정 클라우드 사업자가 정해지지 않은 상태에서도 씁니다. 일곱 칸으로 나뉩니다.

카드가 길어 보이지만, 채우지 못하는 항목이 바로 지금 의사결정의 위험입니다. 모든 필드에 상세 설계가 필요하지는 않습니다. 최소한 확정, 해당 없음, Unknown 가운데 하나는 남겨야 합니다.

Identity

워크로드 ID와 이름, 만드는 업무 결과, 업무 Owner와 기술 Owner, 현재 Lifecycle을 적는 칸입니다.

Boundary

포함하는 구성요소와 포함하지 않는 구성요소, 함께 바뀌는 대상, 주요 외부 Dependency를 적는 칸입니다.

Behavior

Interaction과 State, 수요 패턴, 지연·성능 요구, 특수 연산 자원 요구를 적는 칸입니다.

User & Data

사용자와 호출 주체의 위치, 데이터 등급, 저장·처리·이동 위치, 보존 조건, 요구사항을 확정한 담당자와 근거를 적는 칸입니다.

Failure & Operations

중단 시 영향, 승인된 허용 중단과 데이터 손실 요구, 지원 시간, 패치·모니터링·장애 대응 책임, 외부 지원과 Escalation 경로를 적는 칸입니다.

Economics & Exit

주요 비용 Driver, 유휴·변동 사용 특성, 데이터 이동 경로, 이식성 제약, 환경 이탈과 복구 경로의 존재 여부를 적는 칸입니다.

Decision State

Hard Constraints와 Preferences, Unknown별 Owner·Evidence·Due Date, 후보 환경 범주, 후보 Operating Model, Vendor 비교 가능 여부를 적는 칸입니다.

Workload → Constraint → Operating Model → Vendor Funnel

클라우드 선택은 네 단계로 좁힙니다. 워크로드를 정의한 다음 제약을 확정합니다. 운영 모델을 정한 뒤 마지막에 사업자를 비교합니다.

여기서 Operating Model은 특정 배포 기술을 고르는 단계가 아닙니다. 운영체제와 런타임, 데이터, 관측, 장애 대응 가운데 어떤 책임을 내부 팀이 맡고 어떤 책임을 외부에 넘길지 정하는 단계입니다. NIST의 참조 아키텍처도 서비스 모델에 따라 제공자와 이용자의 통제 범위가 달라짐을 보여 줍니다.^[4]

운영 모델이 먼저인 이유는 같은 기능을 제공하는 서비스도 팀이 책임지는 범위가 다르기 때문입니다. 관리 부담을 감당할 인력이 없는 팀에는 낮은 인프라 가격이 충분한 장점이 아닙니다. 반대로 플랫폼 제약을 감수하기 어려운 워크로드는 운영 편의만으로 후보를 정하지 못합니다.

Google Cloud의 Hybrid·Multicloud 전략 지침도 조직 전체에 하나의 환경을 적용하기보다 사업 Use Case와 워크로드별 요구를 확인하고 어떤 워크로드를 어느 환경에서 실행할지 계획하도록 합니다. 그렇다고 여러 클라우드를 쓰는 것 자체가 목적이 되지는 않습니다. 여러 워크로드가 같은 후보로 모이면 하나의 사업자로 정합니다. 조건이 크게 다르면 서로 다른 배치 결과가 나옵니다.^[5]

같은 회사 안에서도 카드가 갈립니다. 공개 상품 카탈로그는 외부 사용자가 읽기 중심으로 쓰고 요청량이 급격히 변하며 상태 의존성이 낮으므로, 사용자 지역과 지연, 콘텐츠 갱신 방식, 장애 시 허용되는 기능 축소를 먼저 확인합니다. 정산 일괄 작업은 정해진 시간에 실행되고 상태와 내부 데이터 의존성이 높으며 실패하면 다음 업무가 밀리므로, 데이터 위치와 이동, 실행 완료 시점, 재실행 책임, 야간 지원 가능 여부를 먼저 확인합니다.

두 워크로드가 같은 회사에 있다고 해서 같은 환경이 자동으로 정답이 되지는 않습니다. 반대로 특성이 다르다고 해서 반드시 다른 사업자를 써야 하는 것도 아닙니다. 카드가 보여 주는 것은 Vendor 수가 아니라 배치 판단을 나눠야 할 이유입니다.

Vendor 비교를 시작해도 되는지 확인하는 Preflight

다음 열한 항목에 답하지 못한다면 사업자 비교표를 만들기 전에 요구사항부터 보완합니다. 앞의 네 항목은 워크로드 자체를 묻습니다. 업무 결과와 업무·기술 Owner가 정해져 있는지 확인합니다. 포함 범위와 주요 Dependency가 문서로 남아 있는지 확인합니다. Stateful·Stateless·Interactive·Batch 같은 동작 특성이 나뉘어 있는지 확인합니다. 중단 영향과 허용 가능한 중단·데이터 손실 요구가 승인됐는지입니다.

다음 네 항목은 제약을 묻습니다. 데이터 등급과 저장·처리·이동 위치 요구와 그 근거가 확인됐는지 확인합니다. 사용자 위치와 지연 요구와 네트워크 경로가 확인됐는지 확인합니다. Hard Constraint와 Preference와 Unknown이 나뉘어 있는지 확인합니다. 결과를 바꿀 수 있는 Unknown마다 Owner와 Evidence와 Due Date가 있는지입니다.

마지막 세 항목은 운영과 비용을 묻습니다. 패치·모니터링·장애 대응·지원 시간의 책임 경계가 정해져 있는지, 비용을 움직이는 사용 특성과 Exit 제약이 식별됐는지, 후보 사업자를 같은 Region·지원·책임·사용량 가정으로 비교하는지입니다.

READY는 최종 선택이 끝났다는 뜻이 아닙니다. 이제야 실제 Region 제공 여부와 서비스 책임 범위, 지원 조건, 이식성, 같은 사용량으로 계산한 비용을 확인한다는 뜻입니다.

이 글이 멈추는 지점

Placement Card가 완성된 뒤에도 별도의 의사결정이 남습니다. 요청량과 자원 요구를 어떻게 측정할지, 네트워크 경로마다 요금이 왜 붙는지는 독립된 분석이 필요합니다. 어떤 백업 수단이 어떤 실패를 막는지, 허용 중단과 데이터 손실을 어떻게 수치로 옮길지도 별도로 분석합니다. 고객·거래당 비용을 어떻게 계산할지, 이전의 전체 비용을 어떻게 검토할지는 각각 독립된 분석이 필요합니다.

VM·PaaS·Container·Kubernetes 가운데 무엇을 고를지, 서비스 건강 상태를 어떤 지표로 정의할지, 배포와 롤백을 어떤 방식으로 구현할지도 이 글에서 정하지 않습니다. 여기서는 그런 요구가 해당 워크로드의 Placement Constraint로 존재하는지만 적습니다.

좋은 클라우드 결정은 로고가 아니라 배치 지도를 남긴다

클라우드 선택 회의가 끝났을 때 “A사를 쓰기로 했다”는 한 줄만 남는다면, 다음 워크로드에서도 같은 논쟁을 처음부터 되풀이합니다.

대신 어떤 워크로드가 어떤 조건 때문에 어느 후보 환경으로 좁혀졌는지, 무엇이 필수였고 무엇이 선호였는지, 어떤 Unknown을 누가 확인했는지가 남아야 합니다. 그러면 사업자가 바뀌거나 새 Region과 서비스가 늘어나도 판단 구조를 다시 씁니다.

클라우드를 잘 고르는 방법은 사업자 목록을 길게 만드는 것이 아닙니다. 워크로드를 나누고 실패 비용과 운영 제약을 먼저 확정한 뒤, 그 조건을 통과한 후보만 비교하는 것입니다.