📚 지식 노트

클라우드란

미국 국립표준기술연구소(NIST)의 SP 800-145는 클라우드 컴퓨팅을 "설정 가능한 컴퓨팅 자원의 공유 풀에 네트워크로 어디서나 편하게 필요할 때 접근하고, 최소한의 관리나 사업자와의 상호작용만으로 빠르게 할당·반납하는 모델"로 정의한다. 핵심은 다섯 특성이다.

• 주문형 셀프서비스: 사람에게 요청하지 않고 콘솔·API로 서버를 직접 만든다.
• 폭넓은 네트워크 접근: 표준 네트워크 프로토콜로 어느 기기에서든 쓴다.
• 자원 풀링: 많은 고객이 같은 물리 자원을 나눠 쓴다(멀티테넌시). 고객은 대개 정확한 물리 위치를 모르고 리전 정도만 고른다.
• 빠른 탄력성: 필요할 때 늘리고 줄인다. 고객 입장에서는 자원이 무한해 보인다.
• 사용량 측정: 쓴 만큼 재고, 그 측정값으로 요금을 매긴다.

경제적으로 보면 클라우드는 서버를 사는 자본 지출(CapEx)을 쓴 만큼 내는 운영 지출(OpEx)로 바꾼다. 몇 달 걸리던 구매가 몇 분이 되고 실패한 실험은 끄면 그만이라, 수요를 모르는 초기 서비스나 들쑥날쑥한 부하에 특히 유리하다. 반대로 부하가 일정하고 크면 자체 설비가 더 쌀 수 있다(비용 절에서 다시 본다).

IaaS·PaaS·SaaS·FaaS

서비스 모델은 "스택의 어디까지를 사업자가 맡느냐"로 구분된다. 아래로 갈수록 하드웨어, 위로 갈수록 내 일에 가깝다.

• IaaS(Infrastructure as a Service): 가상 머신·디스크·네트워크를 빌린다. 운영체제 패치부터 위는 전부 내 일이다. 자유도가 가장 크고 할 일도 가장 많다.
• PaaS(Platform as a Service): 코드나 컨테이너만 올리면 실행 환경·확장·패치를 사업자가 맡는다. 관리형 데이터베이스도 이 부류다.
• FaaS(Function as a Service, 서버리스 함수): 요청·이벤트 하나에 함수 하나가 돌고, 요청 수와 실행 시간(밀리초 단위)만큼 낸다. 요청이 없으면 0으로 줄어드는 대신, 오래 놀던 함수가 처음 깨어날 때 늦는 콜드 스타트와 실행 시간 상한이 있다.
• SaaS(Software as a Service): 완성된 소프트웨어를 쓴다(메일, 협업 도구). 고객은 데이터와 계정·권한만 관리한다.

"서버리스"는 FaaS보다 넓게, 서버 수를 고객이 정하지 않고 쓴 만큼 내는 서비스 전반(서버리스 컨테이너, 객체 스토리지, 서버리스 DB)을 가리키기도 한다.

리전과 가용 영역

리전(region)은 서울·도쿄·프랑크푸르트처럼 지리적으로 떨어진 데이터센터 묶음이고, 리전 안의 가용 영역(availability zone, AZ)은 전력·냉방·네트워크를 따로 갖춘 하나 이상의 데이터센터다. 영역끼리는 홍수·정전이 함께 닥치지 않을 만큼 떨어져 있으면서도 동기 복제가 가능할 만큼 가깝게(수 ms 안) 이어져 있다. 이름은 사업자마다 조금 달라 Azure는 availability zone, Google은 zone이라 부르지만 구조는 같다.

영역 하나의 가용성을 99.5%로 잡으면 한 달에 약 219분 멈추지만, 두 영역 중 하나만 살아 있으면 되는 구성은 1 − 0.005² = 99.9975%로 약 1.1분이 된다. 이 계산은 두 영역의 고장이 독립이라는 가정에 기대며, 실제로는 리전 공통 제어 기능의 장애, 잘못된 배포의 동시 전파, 장애 조치(failover) 자체의 실패가 상관된 고장을 만든다. 그래서 핵심 서비스는 리전 단위 장애까지 대비해 다른 리전에 복제본이나 복구 절차를 둔다. 리전을 고를 때는 사용자와의 거리(지연), 그 리전에 있는 서비스 종류, 가격(리전마다 다르다), 데이터를 둘 수 있는 나라를 함께 본다.

리전은 한도의 단위이기도 하다. AWS 계정은 서비스마다 기본 할당량(quota, 예전 이름은 limit)을 갖고, 따로 적지 않은 한 할당량은 리전마다 따로 센다. 늘려 달라고 요청할 수 있는 것도 있지만 모두 되지는 않고, 새로 만든 계정은 기본값보다 낮게 시작할 수도 있다. 다른 리전으로 장애 조치하는 계획이라면 그 리전의 할당량도 미리 늘려 둬야 막상 넘어갔을 때 서버를 못 띄우는 일이 없다.

공동 책임 모델

클라우드 보안은 사업자와 고객이 나눠 진다. AWS의 표현으로 사업자는 클라우드 자체의 보안(security of the cloud), 고객은 클라우드 안의 보안(security in the cloud)을 맡는다(AWS 공동 책임 모델). 경계는 앞 절의 서비스 모델에 따라 움직인다. IaaS의 게스트 OS 패치는 고객 몫이지만 관리형 DB의 엔진 패치는 사업자 몫이다.

Google은 여기서 한 걸음 나아가 사업자가 안전한 기본값과 검증된 설계도를 제공해 고객의 실수를 줄여야 한다는 공동 운명(shared fate)을 말한다. 권한을 최소로 나누고 사람마다 신원을 확인하는 설계는 보안 › 제로 트러스트에 있다.

• 루트 사용자는 금고에: 계정을 만들 때 쓴 루트 사용자는 모든 권한을 가진다. AWS는 루트에 강한 비밀번호와 다중 인증(MFA)을 걸고, 루트의 접근 키는 만들지 말라고 권한다(루트 사용자 모범 사례). 일상 작업은 권한을 좁힌 사용자나 역할로 한다.
• 공개 버킷은 대개 바꾼 설정이다: 새 S3 버킷·객체는 기본으로 공개 접근을 허용하지 않는다. 사고는 누군가 버킷 정책이나 객체 권한을 고쳐 열면서 생긴다. 계정 단위로 퍼블릭 액세스 차단을 켜 두면 이런 정책보다 차단 설정이 앞선다.

서비스 지도: AWS·Azure·GCP

세 클라우드는 이름은 달라도 분류는 거의 같다. 흔한 웹 서비스 하나를 그리면 필요한 분류가 다 나온다.

대응표는 출발점일 뿐 같은 칸의 서비스라도 한도·과금·일관성 보장이 다르다. 공식 대응표는 Google Cloud의 비교표와 Azure의 AWS 비교 문서에 있다.

네트워크 기초: VPC·서브넷·보안 그룹

VPC(virtual private cloud)는 클라우드 안에 만드는 나만의 사설 네트워크다. 만들 때 10.0.0.0/16 같은 사설 IP 대역을 정하고, 그 대역을 가용 영역마다 서브넷으로 쪼갠다. 서브넷이 "공개"인지 "사설"인지는 이름이 아니라 라우팅 표가 정한다. 기본 경로(0.0.0.0/0)가 인터넷 게이트웨이로 가면 공개, 그렇지 않으면 사설이다. 사설 서브넷의 서버가 패치를 받으려면 밖으로 나가는 길만 열어 주는 NAT 게이트웨이를 거친다.

• 주소 계산: /16은 주소 65,536개, /24 서브넷은 256개다. /16을 /24로 나누면 256개가 나오고, AWS는 서브넷마다 앞의 네 개와 마지막 한 개를 예약해 251개를 쓸 수 있다(VPC 문서). 컨테이너마다 IP를 주는 환경은 주소를 빨리 먹으므로 처음부터 넉넉히 잡는다. 나중에 다른 VPC·사내망과 이을 생각이면 대역이 겹치지 않게 미리 나눠 둔다.
• 보안 그룹: 인스턴스(네트워크 인터페이스)에 붙는 상태 기반(stateful) 방화벽이다. 허용 규칙만 있고, 들어온 요청의 응답은 자동으로 나간다. 출발지를 IP 대신 "로드 밸런서의 보안 그룹"처럼 다른 보안 그룹으로 지정할 수 있어 서버가 늘고 줄어도 규칙을 고치지 않아도 된다.
• 네트워크 ACL: 서브넷 경계에 붙는 상태 없는(stateless) 규칙으로, 거부 규칙도 쓸 수 있다. 응답 방향도 따로 열어야 한다.
• 사설 연결: 객체 스토리지·관리형 DB 같은 사업자 서비스를 인터넷을 거치지 않고 부르려면 VPC 엔드포인트(사설 링크)를 쓴다. NAT 처리 요금도 줄어든다.

비용 구조

요금은 대체로 계산(인스턴스 시간·vCPU·메모리), 스토리지(GB·월과 요청 수), 데이터 전송으로 나뉜다. 계산 자원은 사는 방식에 따라 값이 크게 달라진다.

• 온디맨드: 약정 없이 초·시간 단위로 낸다. 가장 비싸지만 언제든 끈다.
• 약정 할인(Reserved Instances, Savings Plans, 약정 사용 할인): 1년·3년 동안 일정 사용량을 약속하고 깎는다. AWS는 최대 72%라고 밝힌다(Savings Plans).
• 스팟(선점형): 남는 용량을 싸게 쓰되 사업자가 필요하면 회수한다. AWS는 최대 90% 할인과 회수 2분 전 알림을 밝힌다(스팟, 중단 알림). 중간에 끊겨도 되는 배치 작업·CI·상태 없는 작업자에 맞는다.
• 데이터 전송: 들어오는 데이터는 대개 무료지만 인터넷으로 나가는(egress) 데이터는 GB당 요금이 붙고, 같은 리전의 영역 사이 전송에도 요금이 붙는 경우가 많다. 그래서 전송비는 설계를 바꾸는 비용이다.
• 잊힌 자원과 경보: 시험하고 끄지 않은 서버, 서버를 지운 뒤 남은 디스크·스냅숏처럼 아무도 안 쓰는데 시간·용량만큼 요금이 나가는 자원이 흔한 새는 곳이다. 자원에 팀·환경 같은 태그를 달고 비용 할당 태그로 활성화하면 청구서를 태그별로 나눠 볼 수 있다. 월 예산을 정하고 실제 지출과 예상 지출이 넘을 때 알림을 받는 예산 경보는 계정을 만든 날 걸어 둔다.

한 달 비용을 어림해 보자. 가정(실제 견적 아님): 상시 가상 머신 4대 × 시간당 0.1달러 × 730시간, 스토리지 500GB × GB당 0.08달러, 인터넷 전송 2,100GB 중 무료 100GB를 뺀 나머지 × GB당 0.09달러. 약정 할인은 40%, 스팟은 70%로 가정한다.

온디맨드는 계산 292달러 + 스토리지 40달러 + 전송 180달러 = 512달러다. 계산을 스팟으로 바꾸면 308달러까지 내려가지만 전송비 180달러는 그대로라 전체의 59%가 된다. 실무에서는 늘 켜 둘 바닥 부하만 약정으로 사고, 오르내리는 부분은 온디맨드와 자동 확장으로, 끊겨도 되는 일은 스팟으로 나눈다. 비용을 엔지니어링·재무가 함께 보고 결정하는 운영 방식을 FinOps라 한다. 꺼 두지 않은 개발 환경, 붙어 있지 않은 디스크·IP, 오래된 스냅숏이 흔한 낭비다.

Well-Architected 기둥

세 사업자 모두 "잘 설계된 워크로드"를 점검하는 프레임워크를 낸다. AWS는 여섯 기둥(문서), Azure는 지속 가능성을 뺀 다섯 기둥(문서)으로 정리하고, Google도 같은 축으로 Well-Architected Framework를 낸다.

• 기둥끼리는 서로 당긴다. 영역을 셋으로 늘리면 안정성은 오르지만 비용이 오르고, 보안 검사를 늘리면 배포가 느려진다. 프레임워크의 쓸모는 이 맞바꿈을 의식적으로 고르게 하는 데 있다.
• 검토 질문은 "모든 변경이 코드로 관리되는가", "복구 목표 시간을 정하고 실제로 시험했는가" 같은 꼴이다. 답이 "아니오"인 항목이 곧 개선 목록이 된다.

멀티 클라우드와 하이브리드

멀티 클라우드는 클라우드 사업자를 둘 이상 쓰는 것, 하이브리드는 사내 설비(온프레미스)와 클라우드를 이어 쓰는 것이다. 둘 다 "한 곳에 묶이지 않는다"는 장점이 있지만 그 값이 싸지 않다.

• 이식성의 값: 어디서나 돌게 하려면 각 클라우드의 고유 관리형 서비스 대신 공통분모(가상 머신, 쿠버네티스, 오픈소스 DB)로 설계해야 한다. 관리형 서비스가 덜어 주던 운영 부담을 다시 진다.
• 데이터 중력: 데이터가 많이 쌓인 쪽으로 계산이 끌려간다. 클라우드 사이로 데이터를 옮기면 전송비와 지연이 든다. 그래서 흔한 멀티 클라우드는 "서비스 A는 이쪽, 분석은 저쪽"처럼 일을 나누는 형태이고, 한 서비스를 두 클라우드에 똑같이 펼친 능동-능동 구성은 드물다.
• 떠나는 비용: 떠날 때의 전송비가 이전을 막는다는 비판이 커지자 사업자들이 이전 목적의 전송비를 면제하기 시작했다(예: AWS 2024년 발표).
• 하이브리드가 맞는 경우: 공장·병원처럼 현장 지연이 중요한 시스템, 규제로 옮기기 어려운 데이터, 이미 감가상각이 끝난 설비가 있을 때다. 전용선·VPN으로 망을 잇고, 신원(ID)과 관측 도구를 한 체계로 묶는 것이 첫 과제다.

데이터 주권

데이터를 어느 나라에 두느냐는 요구는 세 겹으로 나뉜다. 데이터 상주(residency)는 저장 위치, 데이터 주권(sovereignty)은 그 데이터에 어느 나라 법이 미치느냐, 운영 주권은 누가 시스템을 운영하고 접근할 수 있느냐의 문제다.

예를 들어 미국의 CLOUD Act는 미국 사업자가 보관·통제하는 데이터라면 해외에 저장돼 있어도 법적 절차에 따른 제출 요구 대상이 될 수 있게 했다. 서울 리전을 골라도 사업자의 본국 법이 닿을 수 있다는 뜻이라, 공공·금융처럼 요구가 엄격한 곳은 현지 법인이 운영하고 사업자 직원의 접근을 막는 "주권 클라우드" 상품이나 고객이 직접 관리하는 암호 키(키를 사업자 밖에 두는 방식)를 함께 검토한다. 개인정보를 국외로 옮길 때의 요건은 나라마다 법이 따로 정하므로, 설계 전에 어떤 법이 적용되는지부터 확인한다.

핵심 자료