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

클라우드를 고르기 전에 워크로드부터 분류해야 한다. “우리 회사에는 어느 클라우드가 맞을까?”라는 질문은 판단 단위가 너무 크다. 한 회사 안에도 고객 요청을 실시간으로 처리하는 애플리케이션, 상태를 가진 데이터베이스, 정해진 시간에 실행되는 일괄 작업, 파일 저장소, 사내 관리시스템이 함께 존재한다. 같은 회사의 시스템이어도 중단됐을 때의 영향과 데이터가 이동할 수 있는 범위, 요구 지연시간, 운영 책임은 서로 다르다. AWS와 Microsoft의 아키텍처 지침도 워크로드를 하나의 서버나 회사 전체가 아니라 사업가치를 제공하는 구성요소의 집합으로 다룬다. (AWS, Microsoft)

따라서 사업자 이름보다 먼저 정해야 할 것은 실패했을 때 어떤 일이 생기는지, 어떤 데이터가 어디로 이동하는지, 사용자가 어디에 있는지, 어떤 시스템과 결합돼 있는지, 누가 운영할 것인지다. 이 조건으로 불가능한 환경을 먼저 제외하고 팀이 감당할 수 있는 운영 모델을 고른 뒤, 마지막에 남은 클라우드 사업자를 비교해야 한다. NIST의 참조 아키텍처가 서비스 모델에 따라 제공자와 이용자의 통제·관리 책임이 달라진다고 설명하는 이유도 여기에 있다. (NIST)

분류가 끝났을 때 나와야 하는 결과는 ‘최고의 클라우드’가 아니다. 각 워크로드별로 반드시 충족해야 할 조건, 협상 가능한 선호, 아직 확인하지 못한 사항이 적힌 Placement Card가 남아야 한다. 결정에 영향을 줄 Unknown이 남아 있다면 가격표와 기능표를 열어도 비교를 시작하기에는 이르다.

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

회사 단위 선택은 여러 워크로드가 같은 조건을 가진다고 전제한다. 실제로는 그렇지 않은 경우가 많다.

외부 고객이 사용하는 공개 웹서비스는 갑작스러운 트래픽과 사용자 지연이 중요할 수 있다. 야간에만 실행되는 데이터 집계 작업은 실행 시간대와 내부 데이터 의존성이 더 중요할 수 있다. 사내 관리시스템은 동시 사용자가 적어도 권한, 감사, 기존 업무시스템과의 연결이 우선일 수 있다. 데이터베이스는 애플리케이션보다 이동과 복구의 부담이 클 수 있다.

이들을 한 묶음으로 두고 “AWS를 유지할까, 다른 CSP로 옮길까”를 물으면 서로 다른 요구가 하나의 평균값으로 사라진다. 그 결과는 흔히 두 방향 중 하나로 흐른다.

기능이 가장 많은 사업자를 고른 뒤 실제로 쓰지 않는 복잡성까지 떠안거나, 월 기본요금이 낮은 상품을 고른 뒤 데이터 이동·지원·운영 인력·장애 대응에서 예상하지 못한 부담을 만나는 것이다. 어느 쪽이든 문제는 사업자가 아니라, 비교 전에 워크로드의 조건을 분리하지 않았다는 데 있다.

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

워크로드는 독립적으로 목적과 책임, 실패 영향을 판단할 수 있는 실행 단위로 잡는 것이 좋다. 반드시 서버 한 대와 일치할 필요는 없다. 한 서버에 여러 워크로드가 함께 있을 수 있고 하나의 워크로드가 여러 서버와 관리형 서비스에 걸쳐 있을 수도 있다.

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

다음 조건 중 하나가 실질적으로 다르면 별도 워크로드로 분리할 후보가 된다.

• 업무 소유자나 최종 승인자가 다르다.
• 별도로 시작·중단·변경하거나 폐기할 수 있다.
• 다루는 데이터의 민감도, 위치, 보존 조건이 다르다.
• 중단 영향이나 운영 지원 시간이 다르다.
• 사용자 지역, 지연 요구, 수요 패턴, 외부 의존성이 다르다.

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

Workload Classification Matrix

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

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

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

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

요구사항 목록이 있어도 모든 항목을 같은 무게로 비교하면 결정이 왜곡된다. 세 상태를 분리해야 한다.

판단 규칙은 간단하다.

계산식

후보 환경 = 모든 Hard Constraint를 충족하는 환경

우선순위 = 후보 환경 안에서 Preference를 비교한 결과

보류 = 후보군을 바꿀 수 있는 Unknown이 남아 있는 상태

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

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

Workload Placement Card

분류 결과는 회의록 속 문장보다 한 장의 카드로 남기는 편이 낫다. 다음 양식은 특정 클라우드 사업자 없이도 작성할 수 있다.

text 예시

[Workload Placement Card]

1. Identity
- Workload ID / 이름:
- 만드는 업무 결과:
- 업무 Owner:
- 기술 Owner:
- 현재 Lifecycle:

2. Boundary
- 포함하는 구성요소:
- 포함하지 않는 구성요소:
- 함께 변경되는 대상:
- 주요 외부 Dependency:

3. Behavior
- Interaction: Interactive / Batch / Event-driven / Mixed / Unknown
- State: Stateful / Stateless / Mixed / Unknown
- 수요 패턴:
- 지연·성능 요구:
- 특수 연산 자원 요구:

4. User & Data
- 사용자·호출 주체와 위치:
- 데이터 등급:
- 저장·처리·이동 위치:
- 보존 조건:
- 요구사항을 확정한 담당자와 근거:

5. Failure & Operations
- 중단 시 영향:
- 승인된 허용 중단·데이터 손실 요구:
- 지원 시간:
- 패치 책임:
- 모니터링 책임:
- 장애 대응 책임:
- 외부 지원 또는 Escalation 경로:

6. Economics & Exit
- 주요 비용 Driver:
- 유휴·변동 사용 특성:
- 데이터 이동 경로:
- 이식성 제약:
- 환경 이탈 또는 복구 경로 존재 여부:

7. Decision State
- Hard Constraints:
- Preferences:
- Unknowns:
  - 항목:
  - Owner:
  - 필요한 Evidence:
  - Due Date:
- 후보 환경 범주:
- 후보 Operating Model:
- Vendor 비교 가능 여부: YES / NO
- 아직 비교할 수 없다면 그 이유:

카드가 길어 보일 수 있지만 내용을 채우지 못하는 항목이 바로 현재 의사결정의 위험이다. 모든 필드에 상세 설계가 필요한 것은 아니다. 최소한 확정, 해당 없음, Unknown 중 하나는 남겨야 한다.

Workload → Constraint → Operating Model → Vendor Funnel

클라우드 선택은 다음 순서로 좁혀야 한다.

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

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

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

가상의 한 회사에 서로 다른 카드가 필요한 경우

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

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

다음 항목에 답하지 못한다면 사업자 비교표를 만들기 전에 요구사항부터 보완해야 한다.

• 워크로드의 업무 결과와 업무·기술 Owner가 정해져 있다.
• 포함 범위와 주요 Dependency가 문서화돼 있다.
• Stateful·Stateless·Interactive·Batch 등 동작 특성이 분류돼 있다.
• 중단 영향과 허용 가능한 중단·데이터 손실 요구가 승인돼 있다.
• 데이터 등급, 저장·처리·이동 위치 요구와 그 근거가 확인돼 있다.
• 사용자 위치, 지연 요구, 네트워크 경로가 확인돼 있다.
• Hard Constraint, Preference, Unknown이 분리돼 있다.
• 결과를 바꿀 수 있는 Unknown마다 Owner·Evidence·Due Date가 있다.
• 패치·모니터링·장애 대응·지원 시간의 책임 경계가 정해져 있다.
• 비용을 움직이는 사용 특성과 Exit 제약이 식별돼 있다.
• 후보 사업자를 동일한 Region·지원·책임·사용량 가정으로 비교할 수 있다.

Preflight 판정은 세 가지로 나눌 수 있다.

READY는 최종 선택이 끝났다는 뜻이 아니다. 이제야 실제 Region 제공 여부, 서비스 책임 범위, 지원 조건, 이식성, 동일 사용량에서의 비용을 확인할 수 있다는 뜻이다.

이 글이 멈추는 지점

Placement Card가 완성된 뒤에도 별도의 의사결정이 남는다.

요청량과 자원 요구를 어떻게 측정할지, 네트워크 경로별 비용이 왜 발생하는지, 어떤 백업 수단이 어떤 실패를 막는지, 허용 중단과 데이터 손실을 어떻게 수치화할지, 고객·거래당 비용을 어떻게 계산할지, 이전의 전체 비용을 어떻게 검토할지는 각각 독립적인 분석이 필요하다.

VM·PaaS·Container·Kubernetes 중 무엇을 선택할지, 서비스 건강 상태를 어떤 지표로 정의할지, 배포와 롤백을 어떤 메커니즘으로 구현할지도 이 글에서 결정하지 않는다. 여기서는 그러한 요구가 해당 워크로드의 Placement Constraint로 존재하는지만 기록한다.

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

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

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

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