Day 4 - 청구 구조: 여러 계정을 하나로 결제하고, 미리 비용을 가늠한다

그런데 왜 계정을 여러 개로 나누나

입문자가 가장 먼저 갖는 의문은 이것이다. "계정 하나로 다 쓰면 편할 텐데 왜 굳이 쪼개지?"

계정 하나로 시작하는 건 자연스럽다. 문제는 사람이 늘면서 생긴다. 한 계정 안에 개발용 서버와 실제 고객이 쓰는 서버가 나란히 있다면, 누군가 자원을 정리하다 운영 중인 데이터베이스를 함께 지우는 사고가 언제든 가능하다. 권한 설정으로 막을 수도 있지만, 같은 방에 칸막이를 세우는 것과 아예 방을 나누는 것은 안전함의 차원이 다르다.

계정을 나누는 이유는 대체로 세 가지다.

1. 사고의 범위를 가둔다 — 개발 계정에서 무슨 일이 나도 운영 계정에는 닿지 않는다. 실수도, 침해도 마찬가지다.
2. 비용이 저절로 갈린다 — 계정이 곧 경계이므로 태그를 붙이지 않아도 "이 계정이 쓴 돈"이 명확하다.
3. 권한 설계가 단순해진다 — "이 팀은 이 계정 안에서만"이라고 하면 복잡한 규칙을 쓸 필요가 줄어든다.

비유하자면 회사의 법인카드다. 카드 한 장을 부서 전체가 돌려 쓰면 명세서가 뒤엉키지만, 부서마다 따로 발급하면 사용 내역이 자연히 갈린다. 계정을 나누는 것도 같은 발상이다. 문제는 그다음이다. 카드를 열 장 만들면 결제도 열 번, 관리도 열 번이 된다.

[계정을 나누기만 하면]
개발 계정   운영 계정   데이터 계정   보안 계정
   │           │           │            │
 청구서       청구서       청구서       청구서   ← 결제도 관리도 제각각

[Organizations로 묶으면]
        관리(payer) 계정
      ┌────┬────┬────┬────┐
    개발  운영  데이터  보안   ← 정책은 위에서 일괄, 청구서는 한 장으로

오늘 배우는 Organizations와 통합 결제는 정확히 이 그림의 아래쪽을 만드는 장치다. 나누는 것의 이점은 지키면서, 나눔 때문에 생긴 번거로움만 없앤다.

이렇게 여러 계정을 의도적으로 나눠 쓰는 방식을 다계정 전략(multi-account strategy)이라고 부른다. 요즘 규모 있는 조직에서는 계정 하나로 모든 걸 하는 쪽이 오히려 예외에 가깝다. 그래서 "계정을 어떻게 묶어 다스릴 것인가"가 클라우드 운영의 기본 과목이 됐다.

AWS Organizations: 여러 계정을 묶어 다스린다

AWS Organizations는 여러 AWS 계정을 하나의 조직으로 묶어 중앙에서 관리하는 서비스다. 계정들을 조직 단위(OU, Organizational Unit)로 묶고, 서비스 제어 정책(SCP)으로 "이 계정들은 특정 리전·서비스를 못 쓰게" 같은 가드레일을 일괄 적용할 수 있다.

왜 계정을 나눌까. 환경 격리(운영/개발 분리), 팀별 권한·비용 분리, 보안 경계 확보가 쉬워지기 때문이다. Organizations는 그 흩어진 계정들을 하나의 통제 지점으로 모아준다.

비유하자면 회사 조직도다. 조직도가 있으면 "영업본부 산하 전 부서"에 한 번에 공지를 내릴 수 있다. 사람마다 따로 연락하지 않아도 된다. OU(조직 단위)가 그 "본부"에 해당하고, SCP가 그 본부 전체에 내리는 사규에 해당한다.

용어 네 개만 정리하고 간다. 이것들이 Organizations 문항의 뼈대다.

SCP를 조금 더 풀면 이렇다. SCP는 권한을 주는 도구가 아니라 상한을 정하는 도구다. "이 OU 안의 계정들은 지정된 리전 밖에서는 자원을 만들 수 없다" 같은 선을 그어두면, 그 계정 안에서 아무리 넓은 권한을 받은 사람이라도 그 선을 넘지 못한다. 개인의 권한을 아무리 넓혀도 회사 사규를 넘을 수 없는 것과 같다.

[권한이 정해지는 순서]
SCP가 그은 상한선  ← 여기를 절대 못 넘는다
      ∩
개별 계정에서 부여된 권한
      =
실제로 할 수 있는 일

규제 때문에 데이터를 특정 지역 밖으로 내보낼 수 없는 회사를 떠올려 본다. 담당자마다 "그 리전은 쓰지 마세요"라고 안내할 수도 있지만, 사람은 잊는다. 이 회사는 대신 해당 OU에 지정된 리전 외에서는 자원을 만들 수 없게 하는 SCP를 걸었다. 규칙을 기억하는 일이 사람의 몫에서 시스템의 몫으로 넘어간 것이다. 거버넌스의 목표는 "잘 지키라고 부탁하는 것"이 아니라 "어기려 해도 어길 수 없게 만드는 것"이다.

"여러 계정을 중앙에서 관리", "OU로 그룹화", "SCP로 일괄 정책 적용"이 보이면 Organizations다. 권한·정책 거버넌스가 핵심 키워드다.

통합 결제(Consolidated Billing): 청구서를 하나로

통합 결제(Consolidated Billing)는 Organizations의 핵심 혜택으로, 조직 내 모든 계정의 청구서를 관리(payer) 계정 하나로 합치는 기능이다. 장점이 분명하다.

1. 단일 청구서 — 계정이 수십 개라도 결제는 한 번. 회계가 단순해진다.
2. 볼륨 할인 합산 — 모든 계정의 사용량이 합쳐져 S3 같은 계층형 할인 구간에 더 빨리 도달한다.
3. 약정 공유 — RI·Savings Plans의 미사용 약정을 조직 내 다른 계정이 활용해 낭비를 줄인다.

[계정별 따로 결제]      [통합 결제]
계정A 청구서             ┌─ 계정A ─┐
계정B 청구서      →      │  계정B  │ → 관리 계정 1장으로 합산
계정C 청구서             └─ 계정C ─┘   (할인 합산 + 약정 공유)

비유하자면 가족 결합 요금제다. 가족 네 명이 휴대폰을 각자 개통하면 요금제도 넷, 청구서도 넷이다. 결합으로 묶으면 청구서는 한 장이 되고, 무엇보다 합쳐진 사용량 덕분에 각자 쓸 때보다 유리한 구간으로 올라간다. 통합 결제가 하는 일이 정확히 이것이다.

두 번째 이점인 볼륨 할인 합산이 왜 생기는지 그림으로 보면 이렇다. 많이 쓸수록 단가가 낮아지는 계층형 요금에서는, 사용량이 잘게 흩어져 있으면 아무도 아래 구간을 벗어나지 못한다.

[따로 결제]                      [통합 결제]
계정A: 조금 ─ 비싼 구간           A+B+C 합산 ─ 더 저렴한 구간에 도달
계정B: 조금 ─ 비싼 구간     →     (같은 양을 써도 단가가 내려간다)
계정C: 조금 ─ 비싼 구간

세 번째 이점인 약정 공유도 같은 맥락이다. 어제 배운 예약 인스턴스나 Savings Plans는 "이만큼은 꼭 쓰겠다"고 약속하고 할인을 받는 방식이다. 그런데 약속해 둔 만큼을 한 계정이 다 못 쓰면 남는 부분이 그냥 버려진다. 통합 결제로 묶여 있으면 다른 계정이 그 남은 몫을 대신 써서 낭비가 줄어든다.

스타트업 여러 곳을 자회사로 둔 그룹사를 떠올려 본다. 따로 계정을 쓰던 시절에는 회사마다 사용량이 작아 누구도 유리한 요금 구간에 닿지 못했고, 한 회사가 사둔 약정은 남으면 그대로 사라졌다. 계정들을 하나의 조직으로 묶은 뒤로는 아무것도 바꾸지 않았는데 단가가 내려갔다. 통합 결제가 "가장 손쉬운 비용 절감"이라 불리는 이유다.

"여러 계정 청구서를 하나로", "사용량 합산으로 더 큰 볼륨 할인", "약정(RI/SP) 공유"가 보이면 통합 결제다. 비용 절감과 회계 단순화가 효과의 핵심이다.

⚠️ 함정: 청구서를 합친다고 해서 계정 사이의 경계가 사라지는 것은 아니다. 계정 A의 사용자가 계정 B의 자원을 마음대로 볼 수 있게 되는 일은 없다. 통합 결제가 합치는 것은 돈에 관한 것뿐이고, 권한과 격리는 그대로 남는다. 시험 보기에 "통합 결제를 쓰면 계정 간에 리소스를 자유롭게 공유할 수 있다"처럼 적혀 있으면 오답이다.

Organizations와 통합 결제는 무엇이 다른가

이 둘은 늘 같이 나오기 때문에 경계를 흐릿하게 아는 사람이 많다. 관계를 한 문장으로 하면 이렇다. Organizations가 큰 그릇이고, 통합 결제는 그 그릇에 담긴 대표 혜택 하나다.

문항이 "통제"를 말하면 Organizations, "돈"을 말하면 통합 결제라고 갈라두면 거의 틀리지 않는다.

청구 구조의 목표는 관리 단순화와 비용 절감, 둘이다. Organizations가 거버넌스를, 통합 결제가 절감을 맡는다. 여러 계정은 Organizations로 다스리고 통합 결제로 한 장에 합쳐 할인을 키우며, 쓰기 전에는 Pricing Calculator로 견적을 내고 TCO 관점으로 온프레미스와 비교한다.

AWS Pricing Calculator: 쓰기 전에 견적을 낸다

AWS Pricing Calculator는 아직 배포하지 않은 아키텍처의 예상 비용을 미리 계산하는 무료 견적 도구다. "EC2 m5.large를 3대, 한 달, RDS와 함께 쓰면 대략 얼마?"를 입력해 추정 월/연 비용을 뽑는다. 마이그레이션 계획, 예산 수립, 안 vs 밖(클라우드 vs 온프레미스) 비교에 쓴다.

Day2의 Cost Explorer/CUR과 시점이 다르다는 점이 중요하다. Cost Explorer는 이미 쓴 비용을 본다(사후), Pricing Calculator는 쓰기 전 비용을 추정한다(사전).

비유하자면 이사 견적서다. 이사를 결정하기 전에 업체를 불러 "짐이 이만큼이고 층수가 이러면 대략 얼마"를 받아 본다. 실제 청구서는 아니지만, 그 숫자가 있어야 이사를 갈지 말지 결정할 수 있다. Pricing Calculator도 같은 역할을 한다. 아직 아무것도 만들지 않은 상태에서 "대략 이 정도"를 손에 쥐게 해준다.

실무에서 이 견적이 필요한 순간은 셋이다. 예산을 신청할 때("해봐야 압니다"로는 결재가 나지 않는다), 온프레미스와 비교할 때(뒤에 나올 TCO 비교의 클라우드 쪽 칸을 채운다), 그리고 설계 대안을 고를 때(같은 기능을 두 구성으로 만들 수 있다면 만들어 보기 전에 값을 가늠한다).

"배포 전 예상 비용 견적", "마이그레이션 비용 추정"이 보이면 Pricing Calculator다. "이미 발생한 비용 분석"이면 Cost Explorer 쪽이다.

⚠️ 함정: 견적은 추정이지 보장이 아니다. 내가 입력한 가정(서버 몇 대, 몇 시간, 데이터 얼마)이 틀리면 결과도 틀린다. 그래서 실무에서는 견적을 낸 뒤에도 Budgets로 한도를 걸고 Cost Explorer로 실제와 대조한다. 사전 견적(Pricing Calculator) → 한도 경고(Budgets) → 사후 확인(Cost Explorer)이 하나의 고리로 이어진다고 기억해 둔다.

TCO(총소유비용): 온프레미스 vs 클라우드를 제대로 비교한다

TCO(Total Cost of Ownership, 총소유비용)는 어떤 자산을 소유·운영하는 데 드는 모든 비용을 합산한 개념이다. 온프레미스와 클라우드를 비교할 때 단순히 "서버 가격"만 보면 틀린 결론이 난다. 진짜 비교는 눈에 잘 안 보이는 비용까지 포함해야 한다.

• 온프레미스 TCO: 서버·스토리지 구매비뿐 아니라 데이터센터 공간·전력·냉방, 하드웨어 유지보수, 운영 인력, 노후 장비 교체 등 숨은 비용이 크다.
• 클라우드 TCO: 자본 지출(CapEx)을 운영 지출(OpEx)로 바꾸고, 위 숨은 비용 상당수를 AWS가 떠안아 총비용을 낮추는 경우가 많다.

비유하자면 자동차 값과 유지비의 관계다. 차를 살 때 사람들이 비교하는 건 차량 가격이지만, 실제로 지갑에서 나가는 돈은 그것만이 아니다. 보험료, 기름값, 주차비, 정기 점검비, 그리고 몇 년 뒤 팔 때 떨어진 값까지가 진짜 비용이다. 차값만 보고 "이게 더 싸다"고 결론 내리면 대개 틀린다. 서버도 마찬가지다.

온프레미스에서 청구서에 찍히지 않는 비용을 늘어놓으면 이렇게 된다.

마지막 줄이 특히 중요하다. 시간도 비용이다. 장비가 도착할 때까지 몇 주를 기다렸다면, 그동안 출시하지 못한 서비스가 벌지 못한 돈도 실제 손실이다.

물론 TCO 비교가 항상 클라우드의 손을 들어주는 건 아니다. 부하가 몇 년간 일정하고 이미 데이터센터와 인력을 갖춘 조직이라면 직접 보유가 유리할 수도 있다. 그래서 시험에서 "클라우드는 언제나 더 싸다" 같은 절대 표현은 오답 신호다. TCO가 말하는 건 "클라우드가 싸다"가 아니라 "제대로 비교하려면 숨은 비용까지 세라"다.

"온프레미스 대비 클라우드의 총비용 비교", "전력·냉방·인력 등 숨은 비용까지 포함"이 보이면 TCO 관점이다. Week1의 CapEx→OpEx 전환과 직결되는 개념이며, Pricing Calculator로 TCO 비교를 위한 클라우드 측 견적을 낼 수 있다.

Pricing Calculator와 TCO는 무엇이 다른가

이름이 둘 다 "비용을 미리 따져보는 것"이라 헷갈리기 쉽다. 하지만 층위가 다르다.

한 문장으로 하면 이렇다. TCO는 질문이고, Pricing Calculator는 그 질문의 절반을 계산해 주는 도구다.

Week 5의 도구는 한 줄로 이어진다. 쓰기 전에는 Pricing Calculator로 가늠하고, 쓰는 동안에는 Budgets가 지키고, 쓴 뒤에는 Cost Explorer와 CUR로 확인하며, 그 전부를 Organizations와 태그가 계정·팀 단위로 가른다. 어느 도구든 "언제 쓰는 물건인가"만 잡으면 보기에서 흔들리지 않는다.

시험에 이렇게 나온다

헷갈리기 쉬운 짝은 Pricing Calculator와 Cost Explorer를 바꿔 놓는 것이다. 문항에서 시제를 찾는다 — "앞으로 쓸 것"이면 Pricing Calculator, "이미 쓴 것"이면 Cost Explorer다.

청구 구조 신호 키워드

다음 글에서는 Week 5 전체 — 요금 모델, 비용 도구, 지원 플랜, 청구 구조 — 를 한 번에 복습한다.

📖 용어

• AWS Organizations : 여러 AWS 계정을 하나의 조직으로 묶어 중앙에서 관리하는 서비스. 회사 조직도에 해당한다.
• 관리 계정(payer 계정) : 조직을 만들고 전체 청구를 떠안는 대표 계정.
• 멤버 계정 : 조직에 속한 나머지 계정들.
• OU(조직 단위) : 멤버 계정들을 묶는 폴더. 정책을 이 단위로 일괄 적용한다.
• SCP(서비스 제어 정책) : OU나 계정이 넘을 수 없는 상한선을 긋는 가드레일. 권한을 주는 게 아니라 막는 도구다.
• 통합 결제(Consolidated Billing) : 조직 내 모든 계정의 청구서를 관리 계정 하나로 합치는 기능. 가족 결합 요금제에 해당한다.
• 볼륨 할인 합산 : 계정별 사용량이 합쳐져 더 저렴한 요금 구간에 빨리 도달하는 효과.
• 약정 공유 : 한 계정이 다 쓰지 못한 RI·Savings Plans 약정을 조직 내 다른 계정이 대신 활용하는 것.
• 다계정 전략 : 환경·팀·보안 경계를 기준으로 계정을 의도적으로 나눠 쓰는 운영 방식.
• AWS Pricing Calculator : 아직 배포하지 않은 구성의 예상 비용을 미리 계산하는 무료 견적 도구. 이사 견적서에 해당한다.
• TCO(총소유비용) : 구매비뿐 아니라 전력·냉방·인력·교체 등 숨은 비용까지 합산해 비교하는 관점.
• CapEx / OpEx : 미리 크게 나가는 자본 지출 / 쓴 만큼 나가는 운영 지출. 클라우드는 앞을 뒤로 바꾼다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

수십 개의 AWS 계정을 운영하는 기업이 결제를 한 장으로 합치고, 사용량을 합산해 볼륨 할인을 키우려 한다. 가장 적합한 기능은?

• AAWS Budgets
• BAWS Organizations의 통합 결제
• CAWS Pricing Calculator
• D비용 할당 태그

문제 2

여러 계정을 조직 단위(OU)로 묶고 서비스 제어 정책(SCP)으로 일괄 가드레일을 적용해 중앙에서 거버넌스를 하려 한다. 가장 적합한 서비스는?

• AAWS Organizations
• BAWS Trusted Advisor
• CAmazon CloudWatch
• DAWS Cost Explorer

문제 3

아직 배포하지 않은 새 아키텍처를 클라우드로 옮길 때 드는 예상 월 비용을 미리 산정해 예산을 짜려 한다. 가장 적합한 도구는?

• AAWS Cost Explorer
• BAWS Cost and Usage Report
• CAWS Pricing Calculator
• DAWS Budgets

문제 4

온프레미스 데이터센터를 유지하는 비용에는 서버 구매비 외에 전력·냉방·운영 인력 같은 숨은 비용이 포함된다. 이렇게 모든 비용을 합산해 클라우드와 비교하는 개념은?

• A볼륨 할인
• B총소유비용(TCO)
• C예약 인스턴스
• DSavings Plans

문제 5

통합 결제의 비용 측면 이점으로 가장 거리가 먼 것은?

• A모든 계정의 청구서를 하나로 합쳐 회계가 단순해진다
• B계정별 사용량이 합산되어 볼륨 할인 구간에 더 빨리 도달한다
• CRI·Savings Plans 약정을 조직 내 다른 계정이 공유할 수 있다
• D각 계정에 서로 다른 SCP를 강제로 적용해 비용을 자동 절감한다