서비스·배치 모델과 공유책임

서버를 맡기면 데이터와 장애도 모두 맡긴 것일까

한빛도서관의 강좌 신청은 접수 첫날에 몰리고 평소에는 한산하다. 항상 최고 부하에 맞춘 서버를 보유하면 많은 시간에 자원이 남는다. 필요한 때 자원을 늘리고 줄이는 서비스를 검토할 수 있다. 그러나 클라우드를 선택했다는 한 문장만으로 예약 정원, 개인정보, 백업과 장애 대응이 모두 제공자의 책임이 되지는 않는다.

이 장은 어떤 자원을 어떤 서비스로 받고, 누가 어느 층을 바꾸고 확인하는지부터 시작한다. 다음 절은 실행 구조, 마지막 절은 비용·회복성·보안·주권을 연결한다. 이 절의 CL-P1·CL-C1·CL-G1은 자체 교육 사례이며 특정 제품의 가격·계약·도입 결과가 아니다.

앞 가상화는 물리자원과 논리환경을 매핑·중재하는 기술이다. 클라우드는 그 기술을 포함한 자원을 서비스로 요청·제공·회수·계측하는 운영 모델이다. 가상머신이 있다는 사실과 클라우드의 성질을 갖췄다는 판단은 구별한다.

1. 클라우드 컴퓨팅의 정의와 다섯 성질

클라우드 컴퓨팅은 공유된 구성 가능한 컴퓨팅 자원을 네트워크로 필요에 따라 제공하고 회수하며, 사용과 운영을 계측·관리하는 서비스 모델이다. NIST SP800-145의 정의는 다섯 핵심 특성, 세 서비스 모델, 네 배치 모델로 비교 틀을 제시한다.¹

이 특성들은 비공개 자료를 인터넷에 공개하라는 요구가 아니다. 네트워크로 접근하되 권한·연결 정책을 제한할 수 있다. 사용량 계측도 모든 계약이 한 종류의 종량제라는 뜻은 아니다. 실제 서비스에는 고정비·약정·최소 사용량·별도 지원비가 있을 수 있다.

NIST가 자원이 이용자에게 거의 무한해 보일 수 있다고 설명하는 것과 실제 자원이 무한하다는 명제는 다르다. 계정 할당량, 특정 지역의 공급, 주소·저장·연결 수와 응용의 병목이 남는다. 자동확장은 허용 범위와 증설시간을 확인해야 한다.²

2. IaaS·PaaS·SaaS는 소비자가 맡는 층을 비교한다

IaaS는 기본 계산·저장·네트워크 자원을 제공받아 이용자가 운영체제와 응용 등을 구성하는 모델이다. PaaS는 제공되는 실행환경과 도구 위에 자신의 응용을 배치하는 모델이다. SaaS는 제공자가 운영하는 응용의 기능을 이용하는 모델이다.¹

한빛도서관이 가상머신에 직접 예약 프로그램을 설치하면 운영체제·런타임·응용을 관리할 일이 많다. 관리형 실행환경에 예약 코드를 배치하면 일부 기반 관리가 줄어들지만 허용 언어·연결·배포·실행 제약을 따른다. 완성된 강좌 관리 응용을 쓰면 개발량은 줄 수 있으나 정원·취소·자료 반출 기능이 요구에 맞는지 확인해야 한다.

이 표는 비교용 일반 모형이다. 제품의 이름만으로 모든 책임을 확정하지 않는다. 관리형 데이터베이스·스토리지·함수 서비스를 조합한 응용은 여러 모델의 특성을 함께 쓸 수 있다. 동일한 사업자라도 서비스와 옵션에 따라 책임이 달라진다.³

더 높은 수준의 서비스가 언제나 더 싸거나 더 제한적이라고 단정하지 않는다. 직접 운영할 역량·빈도·변경 필요와 제공 기능의 차이를 비교한다. 필요 없는 제어권을 얻으려고 운영 부담을 늘리거나, 중요한 업무 제약을 검토하지 않고 모두 맡기는 선택을 피한다.

3. 배치 모델은 무엇을 제공받는지와 다른 축이다

프라이빗 클라우드는 한 조직의 전용 이용, 커뮤니티 클라우드는 공통 관심을 가진 조직들의 공동체 이용, 퍼블릭 클라우드는 일반 대중에게 열려 있는 서비스 제공 범위를 구분한다. 하이브리드 클라우드는 구별되는 클라우드들을 데이터·응용 이동 등을 가능하게 하는 기술로 연결한 구성이다.¹

프라이빗은 반드시 조직 건물 안에 있어야 하는 것은 아니다. 반대로 내부 서버가 있다는 이유만으로 셀프서비스·풀링·탄력성·계측을 갖춘 프라이빗 클라우드가 되는 것도 아니다. 퍼블릭은 고객 데이터가 공개라는 뜻이 아니라 서비스의 소비 범위를 설명한다.

이 절에서 멀티클라우드는 여러 클라우드 제공자 또는 별개 클라우드 환경을 함께 이용하는 운영을 가리킨다. 한 제공자의 저장·계산 서비스를 두 개 쓴다는 사실만으로 이 명칭을 붙이지 않는다. NIST의 네 배치 모델에 별도의 다섯째 유형을 추가한 것도 아니며, 실제 사용 환경과 연결 범위를 명시하기 위한 구분이다.

서로 다른 공급자 계정이 두 개라는 사실과 자료·응용이 통합된 하이브리드 구조는 같지 않다. 멀티클라우드가 자동으로 장애 독립성이나 이동성을 보장하지도 않는다. 공통 인증·운영자·배포·데이터가 같은 실패 경로를 갖는지 확인한다.

한빛도서관이 공개 안내와 예약을 외부 서비스에서 운영하고, 연결되지 않은 내부 PC에 오래된 명단을 남겼다고 하자. 두 장소가 존재할 뿐이다. 이를 자동으로 잘 통합된 하이브리드라고 부르면 원장·권한·보존의 미해결을 숨긴다. 내부 자료를 유지할 필요가 있으면 승인된 연결·동기화·대사·종료를 설계해야 한다.

4. 자원 요청과 실제 서비스 실행은 다른 경로다

클라우드의 관리 경로에서는 계정·정책·자원 생성·배포·삭제 같은 요청을 수행한다. 업무 데이터 경로에서는 이용자가 안내를 읽고 예약을 저장한다. 이 구분은 앞에서 본 제어와 데이터 역할을 적용하는 것이며 모든 서비스의 API가 같은 구조라는 뜻은 아니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

관리 경로는 관리자·배포 담당의 권한·정책·할당량 아래 자원을 요청하고 구성·상태를 확인한다. 생성 접수 후 기동·연결·자료 준비가 끝나야 업무를 처리할 수 있다. 이용자의 업무 경로는 서비스 접점→예약 응용→예약 원장·이력이다. 부하·실패·비용·변경의 관찰은 담당자의 재검토로 돌아오며, 관리 API나 클러스터 상태 저장을 예약 원장으로 바꾸어 읽지 않는다.

관리 API에서 생성 요청을 접수했다는 응답을 받아도 새 서버가 앱 요청을 처리할 준비를 마친 것은 아닐 수 있다. 이미지 시작·설정·연결·데이터 준비와 상태 확인이 남는다. 준비되지 않은 자원에 요청을 보내면 자원 수는 늘었는데 오류도 늘 수 있다.

관리 권한이 탈취되면 많은 자원의 설정·비용·데이터에 동시에 영향을 줄 수 있다. 따라서 운영자 접근과 앱의 데이터 접근을 분리하고, 최소한의 역할·승인·변경 기록을 둔다. 서비스 계정에 자원 전체를 삭제할 수 있는 권한을 편의상 주지 않는다.

5. 확장성과 탄력성, 부하분산은 서로 다르다

확장성은 더 많은 수요를 처리하도록 자원과 구조를 늘릴 수 있는 성질이다. 탄력성은 수요 변화에 맞추어 자원을 늘리거나 줄이는 조정을 강조한다. 부하분산은 여러 처리 대상에 요청을 나누는 역할이다. 여러 서버에 요청을 나눈다고 새 자원이 자동 생성되거나 데이터의 충돌이 해결되지는 않는다.

한 자원의 크기를 늘리는 수직확장은 최대 크기·중단·공유 병목을 살핀다. 자원 수를 늘리는 수평확장은 요청 분배와 상태·동시성·공통 의존을 살핀다. 예약 원장이 하나의 잠금 경합으로 막히면 웹 서버만 늘려도 처리량이 기대대로 증가하지 않는다.

자동확장에는 관찰 주기, 측정값, 시작시간, 최소·최대 수, 축소 때 진행 중인 작업의 처리 등 조건이 필요하다. 바쁜 시간에 생성할 자원도 확보할 수 있는지 확인한다. AWS의 신뢰성 지침은 자동확장에도 할당량·제약과 장애 시 대체 자원의 여유가 필요함을 설명한다.²

이용자가 직접 수요를 만드는 서비스에서는 무제한 확장이 비용 폭증을 만들 수 있다. 자원 상한·속도 제한·대기·기능 축소와 사용자 안내를 함께 정한다. 비용 상한에 도달했다고 이미 확정한 예약을 조용히 삭제하거나 요청을 성공으로 속여서는 안 된다.

6. 따라 계산 CL-P1: 자원 수와 준비시간

CL-P1의 작업자 하나는 지정된 처리 조건에서 초당 40개의 독립 읽기 요청을 처리한다고 가정한다. 자료·공통 의존에 병목이 없고 부하가 고르게 분산되는 단순 모형이다. 현재 작업자 2개의 용량은 80건/초다. 이 처리율을 같은 원장을 경쟁하여 변경하는 예약 쓰기의 보장값으로 옮기지 않는다. 대기시간을 포함한 사용자의 지연 목표는 별도로 확인한다.

수요가 140건/초이면 최소 작업자 수는 140/40=3.5를 올림한 4개다. 3개는 120건/초로 부족하다. 최대 할당량이 3개라면 확장 설정을 켜도 부족 20건/초가 남는다. 자동화 설정과 실제 수용 가능성을 구별한다.

현재 2개에서 필요한 4개가 준비될 때까지 30초 걸리고, 그동안 수요 140·처리 80이 일정하며 요청이 대기열에 무손실로 남는다고 하자. 대기는 (140−80)×30=1,800건 쌓인다. 4개가 준비된 뒤 총 160건/초에서 새 수요 140을 빼면 대기를 줄이는 속도는 20건/초다. 해소에는 1,800/20=90초가 더 걸린다.

따라서 증설 시작 후 총 120초가 지나야 이 모형의 누적 대기가 없어진다. 추가 90초는 전체 대기열의 해소시간이지 각 요청의 대기시간이나 평균 응답시간이 아니다. 개별 지연을 알려면 요청 도착시각·처리순서·실행시간을 함께 보아야 한다. 서버 준비 30초를 전체 정상화 시간으로 보고하지도 않는다.

같은 수요라도 대기열이 1,000건으로 제한되면

CL-P1-L은 위의 무손실 가정을 바꾼 별도 예다. 대기열은 처음에 비어 있고 최대 1,000건이며, 가득 차면 새 초과 요청을 즉시 거절한다. 요청 만료·재시도·중도 포기·추가 장애는 없고 유입·처리율은 연속적인 일정 비율로 근사한다.

초당 60건씩 쌓이므로 약 1,000/60=16.67초에 한도가 찬다. 증설 전 30초 동안 들어온 4,200건은 처리 2,400건, 대기 1,000건, 거절 800건으로 나뉜다. 합계는 다시 4,200건이다. 실제 로그의 이산 요청·처리 중인 상태는 별도 계수 규칙으로 대사해야 한다.

증설 뒤에는 남은 대기 1,000건을 순감소 20건/초로 처리하므로 50초가 더 필요하다. 전체 대기 해소는 80초로 앞의 120초보다 짧지만, 800건을 거절한 결과이므로 성능 개선이라고만 보고할 수 없다. 거절·만료·재시도가 있으면 그 상태와 비용을 지표에 남긴다. 이 예의 한도를 실제 서비스의 권장값으로 사용하지 않는다.

정상 용량과 한 작업자 장애를 견디는 용량

작업자 4개 중 하나가 고장 나면 남은 3개는 120건/초여서 140건/초를 감당하지 못한다. 이미 준비된 동일 작업자 중 하나의 장애만 고려하면 (전체 수−1)×40≥140이어야 하므로 최소 5개가 필요하다. 정상에 필요한 수 N에 하나를 더하는 N+1의 산술적 예다.

5개라는 수는 감지·전환 지연, 장애 노드가 보유한 진행 작업, 데이터 원장·인증·네트워크의 공통 장애까지 해결하지 않는다. 실제 장애영역·잔존 처리율·재처리·할당량을 확인해야 한다. 평소 유휴처럼 보이는 자원이 실패 흡수에 필요한지 비용 검토와 함께 판단한다.

7. 따라 계산 CL-C1: 사용한 시간과 보유한 시간을 나눈다

CL-C1은 하루 24시간 동안 평소 20시간에는 작업자 2개, 바쁜 4시간에는 8개를 사용하는 가상 수요다. 작업자 하나의 시간당 가격을 1,000원으로 정하고 성능은 같다고 가정한다. 저장·전송·운영·약정·할인·증설지연은 이 계산에서 제외한다.

항상 8개를 켜면 8×24=192작업자·시간, 192,000원이다. 수요에 정확히 맞춰 늘리고 줄이면 2×20+8×4=72작업자·시간, 72,000원이다. 차이는 120,000원, 이 계산 항목의 62.5%다. 전체 사업비가 62.5% 줄었다는 결론은 아니다.

새 자원 준비와 종료에 합계 6작업자·시간이 더 필요하다면 78작업자·시간, 78,000원이다. 그 비용까지 포함한 동일 항목 감소율은 (192−78)/192=59.375%로 달라진다. 준비 비용을 추가한 뒤에도 앞의 62.5%를 그대로 보고하지 않는다.

안정적인 시작·축소에 필요한 시간을 숨기지 않는다. 제공자가 분·초·최소시간 중 무엇으로 계측하는지, 줄인 자원 외의 디스크·주소·로그에도 계속 비용이 발생하는지도 확인한다. 이미 보유한 사내 장비에 가상 단가를 곱해 실제 현금 절감이라고 할 수도 없다. 같은 기간의 유지·인력·이전·종료와 실제 회피 가능한 비용을 비교한다. 투자·총비용 판단은 투자성과 분석과 적용조건·경제성·위험·대체기술 비교의 틀을 적용한다.

8. 공유책임은 반반 책임이 아니라 층과 행위의 구분이다

공유책임 모델은 제공자와 이용자가 어떤 계층·설정·데이터·운영 통제를 맡는지 나누는 방식이다. 비율 50대50이나 어느 한쪽의 일괄 면책을 뜻하지 않는다. AWS는 선택한 서비스에 따라 이용자가 맡는 설정·운영이 달라진다고 설명하고, Microsoft도 데이터·계정·접근과 이용자가 통제하는 구성을 별도로 명시한다.⁴³

도서관의 관리형 데이터베이스를 예로 들자. 제공자가 기반 운영체제를 관리하더라도 예약 계정의 읽기·쓰기 권한과 개인정보 항목, 파기 기준, 잘못된 애플리케이션 쿼리는 이용자의 설계와 운영에 남을 수 있다. 자동 백업 옵션이 있어도 켜져 있는지·보존기간·복구 권한·복구 가능한 상태를 확인해야 한다.

인증서가 있다고 이 표의 모든 업무가 이미 완료된 것은 아니다. 인증의 대상 서비스·지역·기간과 제외 범위를 확인한다. 사고의 법적 의무는 선택한 기술 모델뿐 아니라 실제 주체·처리·계약·법령으로 판단하며, 클라우드 법규의 인증·선정·실제 도입 구별과 연결한다.

종료의 기술적 필요와 제공자가 법·계약에 따라 반환할 범위도 나눈다. 이용자 데이터가 반환돼도 실행환경·권한·필요한 키 사용 경로가 없으면 업무를 재개하지 못한다. 제공자 관리키나 독자 프로그램을 반드시 그대로 반출할 수 있다고 가정하지 않고, 재구성·재암호화·전환 지원의 실제 조건을 확인한다. 법규 절의 종료안은 이 책임과 자료의 경계를 설명한다.

9. 완성 선택안 CL-G1

CL-G1의 목표는 강좌 조회·예약을 운영하면서 접수기 수요를 감당하고 업무 원장을 지키는 것이다. 자체 예약 규칙이 필요하다는 가정 아래, 검토한 관리형 실행환경과 데이터 서비스를 우선 후보로 둔다. 완성된 SaaS의 정원·취소·반출 기능이 충분하면 더 단순한 대안이 될 수 있으므로 기능을 실제로 대조한다.

이 사례에서 운영체제 수준의 특별 제어가 필수라는 근거는 없다. 그럼에도 IaaS를 기본으로 선택해 패치·백업·시작·장애의 부담을 늘리는 안은 기각한다. 반대로 PaaS가 허용하는 실행시간·연결·상태 저장이 요구에 맞지 않으면 그 제약을 인정하고 대안을 다시 고른다.

앱은 한정된 권한으로 예약 API를 쓰고 서버는 계정·정원·중복 요청을 확인한다. CL-P1의 읽기 수요 140건/초에는 정상 4개, 이미 준비된 동일 작업자의 단일 장애를 견디는 산술상 수는 5개다. 이 계산을 예약 쓰기 처리율의 근거로 쓰지 않고 원장 경합·부하·실패를 따로 검토한다.

확장 계획은 준비 30초와 누적 대기 해소 90초를 나누고, 대기 상한·개별 요청의 지연·만료·거절을 포함한다. CL-P1-L의 800건 거절처럼 목표에 들어가지 못한 요청을 보고에서 제외하지 않는다. 비용은 CL-C1의 처리자원뿐 아니라 준비·종료·저장·복구 여유와 실제 계약을 같은 경계로 맞춘다.

업무 책임자는 정원·사용자 권리·목표를, 개발 담당은 코드·동시성·입출력을, 운영 담당은 권한·확장·복구·비용을 맡는다. 제공자의 관리 범위·연락·변경·사건 협력은 계약과 공식 서비스 문서로 확인한다. 자원 요청 접수·준비·업무 완료를 나누어 기록하고 실제 복구 후 예약을 대사한다.

접수 전에는 부하 상승·증설 지연·할당량 부족·작업자 장애·저장 장애·권한 거절·실제 자료 반출을 검토한다. 산출물은 모델 선택표·공유책임표·용량/비용 가정표·실행/복구 절차·종료 시 반출 범위다. 클라우드라는 이름을 책임 생략과 무제한 용량의 근거로 쓰지 않는다.

10. 자체 10점 문제와 완성 답안

클라우드의 서비스·배치 모델과 공유책임을 구별하고 CL-P1의 확장 한계를 설명하시오.

구성: 무엇을 받는가 → 이용·배치의 축 → 남는 책임 → 수치와 적용 한계.

CL-P1에서 준비 전 부족 60건/초와 준비 후 여유 20건/초를 구해 30초·90초의 다른 시간을 설명한다. 무손실 모형과 한도 1000건의 거절 800건을 구별한다.

10점 자체 연습의 구성과 완성 답안

목차: 서비스·배치 모델 → 확장·탄력성 → CL-P1 용량·준비시간 → 공유책임 경계

확장 흐름	따로 확인할 제약·근거
수요 확인	독립 읽기 수요와 원장 쓰기 병목을 분리
자원 요청	할당량·실제 공급·권한
준비·기동	이미지·설정·연결·자료·시작 시간
서비스 가능	실제 준비 수·처리율·대기·거절·업무 결과

관리·업무 경로와 CL-P1의 준비·대기·한도 계산을 함께 읽는다.

완성 답안

클라우드는 공유 자원을 필요에 따라 네트워크로 제공·회수·계측하는 모델이다. IaaS·PaaS·SaaS는 기본 자원·응용 실행환경·완성 응용 중 무엇을 제공받고 어느 층을 관리하는지를 비교한다. 프라이빗·커뮤니티·퍼블릭·하이브리드는 이용 범위와 배치·연결의 축이며 퍼블릭을 데이터 공개로 해석하지 않는다.

공유책임은 층·설정·행위별 책임의 구분이다. 관리형 서비스에서도 계정·데이터·업무규칙·설정·복구 확인·사건 대응의 역할을 정한다. 실제 책임은 선택한 서비스와 계약·규범의 범위를 대조하며 인증이나 위치만으로 일괄 면제하지 않는다.

CL-P1은 독립 읽기 작업자 40건/초와 수요 140건/초에서 정상 4개가 필요하다. 초기 2개에서 준비 30초 동안 쌓인 1,800건은 증설 뒤 순처리여유 20건/초로 추가 90초에 해소된다. 이는 전체 대기열의 해소시간으로 개별 응답시간과 다르다. 한 작업자 장애 뒤에도 같은 처리율을 유지하려면 산술상 5개가 필요하며 공통 병목·전환·요청 손실은 별도 검토한다.

11. 자체 25점 문제와 완성 설계 답안

도서관 예약 서비스의 클라우드 선택안 CL-G1을 설계하시오. 모델·탄력성·비용·공유책임과 종료를 포함하시오.

목차: 업무 요구와 대안 → 실행·데이터 경계 → 용량·비용 → 책임·검증·반출.

SaaS의 업무 적합성과 관리형 환경의 제약을 먼저 비교한다. 목표가 같은 정상·단일 장애 용량을 계산하고 데이터·복구·사건·종료의 실제 담당과 근거를 쓴다.

25점 자체 연습의 설계 과정과 완성 답안

목차: 목적·서비스/배치 선택 → 탄력성·비용 → 공유책임 → 종료·재검토

업무 요구에 맞춰 서비스 모델과 배치 모델을 별도로 선택하고, 자원·탄력성의 준비·한도를 비용·공유책임과 대조한다. 관리·업무 경로, 용량·준비시간, 비용 포함범위, 운영·복구·종료 책임을 연결한다. 필요한 보호·복구·반출을 미확인한 상태에서 낮은 비용만으로 채택하지 않는다.

완성 설계 답안

CL-G1은 예약 원장과 권한을 지키며 접수기의 변동 수요를 처리한다. 완성 SaaS의 정원·취소·자료 반출 기능을 먼저 비교하고, 자체 규칙이 필요한 범위에는 관리형 실행환경과 데이터 서비스를 검토한다. 특별한 운영체제 제어 근거 없이 IaaS를 선택하지 않으며 PaaS의 실행·연결 제약도 대조한다. 서비스 모델과 배치 모델을 별도로 기록하고 퍼블릭 서비스에서도 자료 접근을 제한한다.

관리 경로에서는 자원 생성·권한·할당량·배포를, 업무 경로에서는 예약 요청·동시성·정원·결과를 관리한다. 생성 요청 접수와 작업자 준비·업무 성공을 구별한다. 수평확장이 원장 병목을 없애지 않으므로 읽기와 쓰기의 실제 처리율을 별도로 확인한다.

CL-P1의 독립 읽기 수요 140건/초에는 정상 4작업자가 필요하고 준비 중 대기 1,800건, 이후 해소 90초가 계산된다. 단일 작업자 장애의 잔존 용량에는 5개가 산술상 필요하다. CL-P1-L처럼 대기 한도가 1,000건이면 준비 전 800건이 거절되므로 더 빠른 대기 소진을 전체 성공으로 보고하지 않는다. 실제 지연·기한·재시도·공통 의존을 검토하며 최소·최대·축소·관찰 조건을 정한다.

CL-C1의 상시 192작업자·시간과 변동 72작업자·시간은 가상 단가에서 192,000원과 72,000원이다. 준비·종료 6작업자·시간까지 포함하면 78,000원, 동일 항목 감소율은 59.375%다. 범위 밖 저장·전송·인력·약정과 회피 가능한 비용을 대조하기 전 총사업비 절감으로 확대하지 않는다.

업무·개발·운영과 제공자의 책임을 계정·코드·자료·백업·패치·사건·종료별로 지정한다. 인증 범위와 실제 도입·지원·통보를 나누어 확인한다. 종료 시 반환될 자료·판본·관계와 새 환경의 실행·권한·키 사용 경로를 대조해 격리된 환경에서 정상·거부·복구를 검증한다. 같은 원장을 확정하는 새 쓰기의 개통 전에는 옛 경로의 독립 쓰기 권한 회수를 확인한다. 기존 키·사본·계약 등 잔여는 보존·복구 조건을 충족한 뒤 정리한다. 미확인 보호·복구·반출을 낮은 비용으로 상쇄하지 않는다.

12. 자기교정

조건 변경과 해설

CL-P1 수요가 100건/초라면? 정상 용량에는 3개가 필요하다. 초기 2개에서 준비 30초 동안 600건이 쌓이고 이후 여유 20건/초로 30초가 더 필요하다. 무손실 가정에서 총 60초이며 단일 작업자 장애까지 고려한 산술상 수는 4개다.

CL-C1의 바쁜 시간이 8시간으로 늘면? 평소 16시간×2와 바쁜 8시간×8을 합해 96작업자·시간이다. 준비·종료 추가비를 제외한 이 조건에서 비용은 96,000원, 상시 8개 대비 50%다. 다른 비용 항목을 포함할 때에는 같은 범위로 다시 계산한다.

SaaS에서 전체 예약 기록을 꺼낼 수 없다면? 이용 중 기능이 편리해도 종료·감사·정정 요구를 검토한다. 반환 대상·형식·관계와 별도로 재구성할 실행·권한·필요한 키 경로·비용을 확인한다. 계약상 권리와 실제 샘플의 사용 가능성을 확인하기 전 전면 도입을 승인하지 않는다.

독립 확인: 정상 처리량과 같으면 쌓인 대기도 없어질까

CL-P1의 수요만 160건/초로 바꾼다. 초기 작업자 2개, 각 40건/초, 추가 준비 30초와 무손실 대기 가정은 같다. 정상 수요에 필요한 최소 수를 구하고 그 수만 준비했을 때 대기가 없어지는지 답한다. 5개를 준비한 대안의 대기 해소시간과 단일 작업자 장애 뒤 조건을 계산한다.

변경 조건의 완전한 풀이와 오답 교정

정상 최소는 160/40=4개다. 준비 30초 동안 (160−80)×30=2400건이 쌓인다. 4개 준비 뒤 처리 160과 신규 160이 같아 순감소 0이므로 기존 2400건은 이 일정 유입 모형에서 없어지지 않는다. 2400/160=15초라는 답은 신규 요청을 분모에서 빠뜨렸다. 5개면 처리 200−신규 160=40건/초가 남아 2400/40=60초 추가, 증설 시작부터 90초에 누적 대기가 사라진다. 5개 중 하나가 실패하면 남은 4개는 신규 160을 맞추지만 새 대기를 해소할 여유는 없다. 정상 최소와 기존 대기 해소·장애 후 여유는 서로 다른 요구다. 개별 응답시간과 공통 장애는 여전히 별도다.

풀이를 닫고 생성 요청 접수·자원 준비·업무 완료, 62.5%·59.375%의 비용 범위, 퍼블릭의 소비 범위와 데이터 접근을 설명한다.

2026-10-05 Microsoft 공유책임 문서의 서비스 모델별 통제 범위를 직접 열람했다. 제품별 실제 계약·가격·복구 결과의 전수 검증이나 기존 NIST2011 PDF의 신규 전수 대조로 확대하지 않는다.

근거와 적용 범위

모든 숫자·책임표·선택안·문제·답안은 자체 교육용이다. 실제 클라우드 생성·가격 조사·투자 자문·성능/복구 시험·독립 승인은 수행하지 않았다.

회독의 핵심

제공받는 층, 이용 범위, 자원 배치와 실제 책임을 따로 읽는다. 탄력성이 있어도 준비·대기·손실·용량·비용의 한계가 남는다. 정상과 장애의 요구를 구별하고 실제 업무 원장과 보호·복구·종료까지 선택안에 포함한다.

추가 자원 판단: 수요가 바뀌거나 비용 단위가 달라지면

세 문제는 CL-P1·CL-C1과 구분하는 작은 자체 모형이다. 처리율은 독립 읽기에만 적용하고 실제 예약 원장·클라우드 서비스·장애 전환을 실행한 결과로 쓰지 않는다. 자원이 준비된 시각과 대기·요금의 관찰 경계를 먼저 고정한다.

문제 1 — 준비가 끝난 뒤 수요가 먼저 줄면

처음 대기 0, 준비된 작업자 2개·각 40건/초다. t=0부터 60초까지 수요 140건/초, 그 뒤 60건/초이며 작업자 4개는 t=30초에 모두 준비된다. 대기 상한·거절·만료·재시도·장애는 없고, 유입과 처리율을 연속 일정 비율로 근사한다. 30초·60초의 대기와 대기가 없어지는 시각을 구하라. 원래의 ‘증설 후 90초’를 그대로 써도 되는가?

수요가 바뀌는 지점마다 순증감을 다시 계산하는 풀이

첫 30초 대기는 (140−80)×30=1,800건이다. 30~60초에는 처리 160−유입 140=20건/초로 줄어 60초의 대기는 1,800−20×30=1,200건이다. 60초 뒤에는 160−60=100건/초로 줄어 추가 12초, t=72초에 대기가 0이 된다. 이후 60건/초의 유입은 160건/초의 용량보다 작다.

처음 72초의 유입은 140×60+60×12=9,120건이며 처리도 80×30+160×42=9,120건이다. 대기가 있는 동안의 이 합계가 일치한다. 원래의 90초는 유입 140이 계속된 다른 조건이므로 복사하지 않는다. 72초는 전체 누적 대기 해소시각이며 각 요청의 응답시간이나 실제 복구 목표 충족의 증거는 아니다.

문제 2 — 기존 대기를 60초 안에 해소하면서 한 개가 실패해도

이미 대기 1,200건이 있고 수요 140건/초가 계속된다. 동일 작업자 각 40건/초, 정수 n개가 지금 모두 준비돼 있다고 하자. 무손실로 60초 이내에 대기를 없애는 정상 최소 수와, 시작 순간 한 작업자가 실패해 복구되지 않아도 같은 목표를 맞추는 최소 수를 구하라. 실패 감지·분배 전환은 즉시이고 진행 중 손실·공통 병목은 없다고 한정한다.

새 유입을 빼고 남는 용량으로 대기를 해소하는 풀이

정상에서는 (40n−140)×60≥1,200, 즉 40n≥160이므로 최소 4개다. 처리 160·여유 20으로 정확히 60초에 기존 대기를 해소한다. 단순히 1,200/160=7.5초라고 쓰면 계속 들어오는 140건/초를 빠뜨린다.

한 개 실패 뒤에는 40(n−1)≥160이어야 하므로 최소 5개다. 5개가 정상이면 순여유 60으로 20초, 한 개 실패 뒤에는 순여유 20으로 60초다. 4개에서 하나가 실패하면 처리 120이 유입 140보다 작아 대기는 60초 뒤 1,200+20×60=2,400건으로 늘어난다. 이 결과는 명시한 단일 작업자·즉시 전환의 산술이며 실제 실패영역·진행 작업·원장 쓰기·복구 승인을 검증한 것이 아니다.²

문제 3 — 사용시간과 최소 청구시간을 구별하면

새 하루 모형은 기본 작업자 2개를 24시간 유지하고, 09시·12시·15시에 각각 작업자 6개를 추가로 10분씩 켰다가 끈다. 각 추가 시작은 독립 청구되고 시간대는 겹치지 않는다. 가상 가격은 작업자·시간당 1,000원이다. 계약 A는 분 단위 실제 사용만 청구하고, 계약 B는 추가 작업자 하나의 매 시작마다 최소 1시간을 청구한다. 준비·종료·저장·전송·세금·할인 등은 제외한다. 두 계약의 청구량·비용과 항상 8개를 켜는 비교안 대비 동일 항목 감소율을 구하라.

작업자 수·시작 횟수·청구 단위를 함께 맞추는 풀이

기본 사용은 2×24=48작업자·시간이다. 추가 작업자의 시작 수는 6×3=18회다. A의 추가 사용은 18×(10/60)=3작업자·시간으로 합계 51작업자·시간·비용 51,000원이다. B의 추가 청구는 18×1=18작업자·시간으로 합계 66작업자·시간·비용 66,000원이다. 18회 시작을 동시에 작업자 18개가 필요했다는 뜻으로 해석하지 않는다.

상시 8×24=192작업자·시간·192,000원과 비교하면 A의 감소율은 (192−51)/192=73.4375%, B는 (192−66)/192=65.625%다. 실행시간이 같아도 계약 단위가 다르면 비용이 달라진다. 여기의 최소 1시간은 자체 계약 조건이며 특정 제공자의 현재 가격·청구 규칙이 아니다. 제외한 항목을 합치기 전에는 총사업비나 실제 현금 절감률로 확대하지 않는다.

Footnotes

1. NIST SP800-145, The NIST Definition of Cloud Computing (September2011), §2·본문2~3쪽. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf . 초고 작성 시 2026-09-20에 확인한 본문·화면의 분류 근거를 유지한다. 이번 내용 보완에서 해당 PDF를 새로 전수 확인한 것으로 표시하지 않는다. 국내 의무나 특정 구현을 강제하는 규격이 아니다. ↩ ↩² ↩³

2. AWS Well-Architected Reliability Pillar, Design principles 및 REL01-BP06. https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-principles.html ; https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_suff_buffer_limits.html . 보완에서 BP06의 할당량·장애 대체 여유를 재확인했다. 단가·처리율·확장시간과 N+1·유한 대기열의 수치는 자체 가정이다. ↩ ↩² ↩³

3. Microsoft Learn, Shared responsibility in the cloud. https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility . 2026-09-20 보완에서 서비스 모델과 고객 데이터·ID·설정 책임의 HTML을 재대조했다. 실제 계약은 서비스별로 확인하며 원문 그림을 복제하지 않았다. ↩ ↩²

4. AWS, Shared Responsibility Model. https://aws.amazon.com/compliance/shared-responsibility-model/ . 초고의 서비스별 책임 근거를 유지한다. 제공자 한 곳의 설명을 모든 상품의 동일 계약조건으로 쓰지 않는다. ↩