FinOps·회복성·보안·주권

비용을 줄였는데 장애가 길어졌다면 성공일까

한빛도서관은 클라우드 청구액을 줄이려고 평소 사용하지 않는 예비 자원과 오래된 백업을 정리하려 한다. 실제로 불필요한 자원일 수 있지만, 장애 때 예약을 다시 시작하는 데 필요한 자원일 수도 있다. 비용이 낮아졌다는 사실만으로 도서관의 목적을 더 잘 달성했다고 할 수 없다.

앞 서비스 모델과 공유책임, 실행과 실제 상태는 자원·책임과 실제 실행을 구별했다. 인프라 회복성의 장애 범위·허용 시간·데이터 손실을 여기에 연결해 비용과 회복성을 함께 판단한다.

1. FinOps는 재무팀만의 청구서 절감 활동이 아니다

FinOps는 기술·재무·업무 담당자가 사용과 비용의 근거를 공유하고 기술이 만드는 가치와 재정적 책임을 함께 판단하는 운영 실천이다. 이 절에서 확인한 FinOps Foundation의 프레임워크는 사용·비용 이해, 사업가치의 정량화, 사용·비용 최적화, 실천의 관리라는 영역을 제시한다.¹ 기술 지출 전반으로 적용 범위를 정할 수 있지만 이 절은 도서관 서비스에 한정한다.

개발자는 비용이 어디에서 생기는지 알아야 하고 재무 담당자는 이용량·품질·운영 조건을 알아야 한다. 업무 책임자는 어떤 결과를 위해 얼마를 쓸 것인지 정한다. 비용표를 만들어도 누구도 자원·계약·설계를 바꾸지 않으면 관찰 자료만 있고 의사결정은 없는 상태다.

목표는 ‘가장 싼 서버’가 아니라 정상 예약·안내·권리 대응을 정한 시간과 보호조건 안에서 제공하는 것이다. 이용이 줄었는데 지출이 늘었는지, 이용이 늘어 단위 비용이 낮아졌는지, 실패 재시도나 불필요한 로그가 늘었는지 구별한다.

자원에 서비스·환경·담당·목적을 연결하는 태그나 계정 구분을 둘 수 있다. 이는 정보의 연결 수단이지 태그 존재만으로 정확한 청구·책임이 확정되는 것은 아니다. 분류되지 않은 비용과 공통 자원도 포함해 실제 청구액과 합계를 맞춘다.

2. 따라 계산 FO-A1: 공통 비용을 지우지 않고 배분한다

예약 서비스 A와 안내 서비스 B의 직접 비용이 각각 3백만 원이고 공통 관찰·지원 비용이 2백만 원이라고 가정한다. 전체는 8백만 원이다. 공통 비용은 합의한 사용 지표에 따라 A에 60%, B에 40%를 배분한다. 실제 회계 규정이나 보편적으로 올바른 배분율이 아니다.

각 팀이 직접 비용만 보고하면 2백만 원의 책임과 가치가 사라진다. 반대로 두 팀에 각각 공통비 전액을 더하면 총 10백만 원으로 이중계상한다. 배분은 비용을 새로 만드는 것이 아니라 같은 8백만 원을 어떻게 설명할지 정하는 일이다.

showback은 사용 조직에 비용을 보여 주는 방식이고 chargeback은 정한 규칙에 따라 실제 비용 책임을 부과하는 방식이다. 공통 비용을 중앙 예산에 남길 수도 있지만 의도적으로 중앙이 부담한다는 결정과 아무도 모르게 누락한 비용은 다르다. 공식 Allocation 설명도 직접·공유 비용과 여러 배분 방법을 구별한다.²

호출 수로 배분한다면 큰 파일 처리와 작은 조회의 비용이 같은지 확인한다. 단순 지표는 이해하기 쉽지만 실제 비용 유발 요인과 다를 수 있고, 지나치게 세밀한 계측은 비용이 커질 수 있다. 필요한 정밀도·변경 절차·미분류 항목을 함께 관리한다.

3. 따라 계산 FO-U1: 총액과 단위당 비용이 반대로 움직인다

FO-U1은 같은 기능·품질·비용 포함범위의 두 달이다. 첫 달에는 1.2백만 원으로 예약 6,000건을 정상 완료했고, 다음 달에는 1.5백만 원으로 10,000건을 정상 완료했다고 가정한다. 실패 요청의 재처리 비용도 해당 월 비용에 포함한다.

첫 달 건당 비용은 1,200,000/6,000=200원, 다음 달은 1,500,000/10,000=150원이다. 총비용은 25% 늘었지만 정상 완료 한 건의 평균 비용은 25% 줄었다. 지출 증가만으로 실패라고 하거나 건당 감소만으로 예산 문제가 없다고 결론 내리지 않는다.

단위경제성은 지출을 처리량·이용자·가치 단위와 연결해 해석한다. 자원 한 시간의 단가와 업무 한 건의 비용은 다른 지표다. FinOps Foundation도 자원 효율 단위와 업무 결과 단위를 구별한다.³ 계산자원만 싸졌는데 오류·사서 정정 시간이 늘면 전체 개선이 아닐 수 있다.

150원은 해당 월의 평균 비용이다. 다음 예약 한 건을 추가할 때의 비용 증가인 한계비용과 같다고 단정하지 않는다. 고정비와 사용량 구간에 따라 추가 비용이 달라질 수 있다. 다른 품질·지원 범위의 서비스를 이 값으로 바로 순위화하지 않는다.

접수만 된 요청이나 같은 예약의 반복 조회를 완료 건수에 넣으면 분모를 키워 단가를 낮출 수 있다. 처음 정한 업무 단위·고유 식별·품질·기간을 유지하고 바뀌면 이유를 남긴다. 비용·호출량·확정된 예약·이용자가 받은 결과는 같은 수가 아니다.

4. 사용량 최적화와 가격 최적화는 다르다

사용량 최적화는 불필요한 자원을 없애거나 적정 크기·수명·배치로 바꾸는 일이다. 가격 최적화는 필요한 사용량을 어떤 계약·약정·할인 방식으로 구매할지 판단하는 일이다. 같은 소비를 싸게 산 것과 필요 없는 소비를 줄인 것은 다른 개선이다.⁴

CPU가 낮다고 자원을 즉시 삭제하지 않는다. 저장·네트워크 병목 때문에 CPU만 낮거나 장애·피크의 예비분일 수 있다. 역할·사용·복구 시나리오를 확인한 뒤 바꾸며, 실행을 중지해도 디스크·주소·로그 비용이 남는지 본다.

중단 가능한 저가 자원은 재실행할 분석에 유리할 수 있으나 상태·마감·재처리 비용을 따져야 한다. 할인율만 보고 예약 원장을 같은 자원으로 옮기지 않는다. 약정 할인도 불필요한 계산 자체를 없애 주지는 않는다.

FO-K1: 전체 기간 묶음이라는 가정의 비용 경계

자체 계약 모형에서 여러 자원에 합산해 사용할 1,000자원·시간 묶음을 60,000원에 미리 사고, 남는 시간은 환불·이월되지 않는다고 하자. 같은 범위를 필요할 때 사면 시간당 100원이다. 시간대별 사용 제한이 없는 가상 묶음이며 실제 Savings Plans나 예약 인스턴스의 청구 규칙을 복제한 것이 아니다.

500시간만 쓰면 필요구매 50,000원보다 약정 60,000원이 비싸다. 사용한 시간 기준 약정 실효단가는 120원이다. 800시간이면 필요구매 80,000원 대비 60,000원이며 실효단가는 75원이다. 표시 단가 60원을 실제 사용 단가로 무조건 쓰지 않는다.

동등 비용은 60,000/100=600시간이다. 이 묶음의 허용 범위 안에서 600시간보다 많이 써야 약정이 더 싸다. 이는 두 구매안의 비용 경계이지 전체 사업의 흑자 전환점이 아니다. 범위·만료·미사용 위험과 자원 변경 계획을 함께 본다.

FO-K2: 같은 총량이라도 시간대가 다르면 비용이 달라진다

실제 서비스의 약정은 시간별로 적용될 수 있다. AWS Savings Plans는 시간별 약정에 해당 시간의 적격 사용을 적용하고, 그 시간에 쓰지 못한 약정을 이후 시간으로 넘기지 않는다고 설명한다.⁵ 따라서 월간 합계 사용량만으로 할인 적용을 계산하면 틀릴 수 있다.

이를 연습할 별도 가상 계약은 두 시간 동안 매시간 60원을 내고 그 시간의 1자원·시간까지 충당한다고 정한다. 남는 몫은 다음 시간으로 넘기지 않으며 초과량은 자원·시간당 100원이다. 할인 없는 필요구매도 100원이다. 실제 제품의 단가·통화·약정 기간을 나타내지 않는다.

두 경우 필요구매는 모두 200원이다. 고른 사용에서는 80원이 절약되지만 몰린 사용에서는 20원이 더 든다. 첫 시간의 빈 몫이 둘째 시간의 초과를 상쇄하지 않는다는 조건 때문이다. 전체 기간의 사용 비율이 같아도 약정 활용과 절감은 다를 수 있다. 실제 구매에서는 시간별 수요·적격 서비스·공유·약정 적용순서와 범위를 확인한다.

5. 서비스의 목표와 계약, 실제 측정의 경계를 맞춘다

SLI는 서비스 품질을 관측하는 지표, SLO는 그 지표의 목표다. SLA는 약속과 책임을 정한 계약으로 실제 보상·제외 조건을 따로 확인한다. Google SRE의 설명도 사용자 결과·측정 구현·목표·계약을 구별한다.⁶

자체 CR-S1은 30일 내내 운영하는 예약 API의 시간 기준 가용성 목표를 99.9%로 정한다. 전체 43,200분에서 불가용 예산은 43.2분이다. 관측된 장애 60분이고 나머지가 정한 정상 조건을 만족한다고 확인됐다면 가용률은 (43,200−60)/43,200×100≈99.8611%로 미달이다.

오류예산은 허용 오류·불가용량에 따라 무엇을 우선 개선하고 언제 위험한 변경을 줄일지 판단하는 도구다. 예산 안이라고 이용자 피해가 없거나 법정 통지까지 면제되는 것은 아니다. 마감시간 중단의 영향과 클라우드 사고의 통지를 별도로 확인한다.

시간 기준 99.9%와 요청 기준 99.9%는 분모가 다르다. 요청이 적은 구간의 긴 중단, 백엔드에 도달하지 못한 요청, 오류인데 성공 코드가 반환된 요청을 어떻게 관측할지 정한다. 로그가 없다는 사실만으로 정상 또는 장애 어느 쪽도 자동 확정하지 않는다.

CR-S2: 관측 공백을 빼면 목표가 좋아 보일 수 있다

CR-S2는 동일 비중의 1분 구간 1,000개를 각각 성공·실패로 평가하는 별도 표본 지표다. 970구간은 성공, 10구간은 실패, 20구간은 관측 공백으로 상태를 모른다고 하자. 관측된 집단의 성공률은 970/980≈98.98%지만 전체 1,000구간의 비율은 아직 하나로 확정할 수 없다.

미확인 20구간이 모두 실패라면 97%, 모두 성공이라면 99%다. 이것은 해당 조건의 가능한 범위이며 통계적 신뢰구간이 아니다. 목표가 98%라면 관측 집단의 98.98%만으로 전체 통과를 선언할 수 없다. 보수적으로 공백을 실패 처리하는 운영 규칙을 택할 수 있지만, 그 정책상 값과 실제 장애가 확인됐다는 사실은 구분한다.

관측 복구·외부 측정·접점 기록으로 공백을 좁히고 측정 장치의 신뢰성도 함께 본다. 같은 원리로 비용·사용량이 빠진 구간을 0원·0건으로 자동 채워 단위경제성을 좋게 만들지 않는다.

6. 복제 수보다 함께 실패할 수 있는 범위를 본다

서버가 여러 개여도 전원·네트워크·관리 계정·원장·잘못된 배포를 공유하면 함께 실패할 수 있다. 가용영역과 리전은 장애 범위를 나누는 수단이지만 서비스·계정·설정·자료의 모든 의존성이 자동으로 독립되지는 않는다.⁷

CR-A1은 한 시점에 두 필수 구성 A·B가 각각 확률 0.999로 정상이고 서로 독립이라는 인위적 모형이다. 둘 다 필요하면 전체는 0.999×0.999=0.998001, 99.8001%다. 각 구성의 수치만큼 전체도 정상이라고 쓰지 않는다.

반대로 완전히 독립된 동일 서비스 두 개 중 하나만 정상이어도 되고, 충분한 용량·즉시 전환·다른 실패가 없다면 모두 실패할 확률은 0.001×0.001이다. 전체 정상확률은 99.9999%다. 이 값은 강한 가정의 결과이지 실제 서비스나 계약의 보장값이 아니다.

CR-A2: 두 복제본 앞의 공통 인증이 멈추면

공통 인증 C가 정상일 확률을 0.99라고 하자. C가 정상일 때에만 뒤의 두 실행계통이 각각 0.999 확률로 정상이며 서로 조건부 독립이라고 정한다. C가 실패하면 서비스를 사용할 수 없다. 다른 실패·전환 지연은 없다는 가정이다.

전체 정상확률은 0.99×(1−0.001²)=0.98999901, 약 98.999901%다. 실행계통만 계산한 99.9999%가 전체에 그대로 적용되지 않는다. 전체가 필수 공통 구성 C의 99%보다 좋을 수 없는 이 모형의 관계도 확인한다.

독립 가정이 근거 없이 주어졌다면 숫자부터 곱하지 않는다. 도식에 공통 인증·DNS·키·원장·배포와 장애 후 잔존 용량을 표시하고 실제 시나리오로 확인한다. 이 예는 의존성의 영향을 읽는 산술이지 실제 장애 확률을 추정한 결과가 아니다.

7. 복제·백업·재해복구의 목적을 나눈다

앞 인프라 절은 RTO를 서비스 복구시간 목표, RPO를 되살릴 자료 시점에 대한 허용 손실의 시간상 경계로 설명했다. 둘을 더해 전체 중단시간으로 만들지 않는다. 여기서는 자료·권한·실제 업무를 함께 복구하는 기준에 적용한다.

복제는 다른 곳에 상태를 유지하지만 잘못된 삭제·변조도 전파할 수 있다. 시점별 백업과 복구 검증은 별도다. AWS의 재해복구 설명도 전략 선택을 중단·손실 허용, 비용·복잡성과 연결한다.⁷

이 구분에서 pilot light는 추가 행동 전에는 완전한 요청 경로가 준비되지 않고 warm standby는 축소된 수준에서 동작한다. 어느 이름도 특정 RTO·RPO를 보장하지 않는다.⁷ 자료 크기·복제 지연·권한·외부 서비스와 준비된 처리량을 확인해야 한다.

복구 절차가 장애 난 관리 기능이나 원래 지역의 키에 의존하면 대체 환경이 있어도 막힐 수 있다. 복구에 필요한 자원 생성·인증·해독·연결을 장애 시나리오에 넣는다. 이미 충분히 배치한 자원과 복구 중 확보할 예정인 자원을 같은 준비 상태로 세지 않는다.

따라 판단 CR-R1: 데이터 목표는 맞지만 시간 목표는 틀린다

자체 목표가 RPO 15분·RTO 30분이고 10:00에 중단됐다고 하자. 복원 가능한 마지막 일관된 자료가 09:50이라고 확인된 가정이다. 서버는 10:20에 켜졌지만 예약·권한·알림을 대사하고 정한 업무를 할 수 있게 된 때는 10:35다.

자료점 간격 10분은 RPO 안이지만 업무 재개 35분은 RTO를 5분 초과한다. 서버 기동 20분만 쓰면 목표를 지킨 것처럼 보인다. 10분의 간격을 예약 10건 유실로 해석하지 않으며 실제 손실·중복·외부 발송을 대사해야 한다.

침해·손상이 의심되면 가장 최근의 백업 시각만으로 복구점을 고르지 않는다. CR-R1은 09:50 자료의 사용 가능성을 이미 확인한 예다. 그 전제가 깨지면 원래 판정을 그대로 유지하지 말고 안전하게 쓸 수 있는 자료점·후속 보정·시간 목표를 다시 판단한다. 빠른 재개를 위해 검증을 생략한 결과를 목표 달성으로 쓰지 않는다.

8. 주권 요구는 서버 주소 한 칸보다 넓다

데이터 레지던시는 저장·처리 위치의 조건이고, 디지털 주권의 요구는 누가 어떤 권한·의존성·규범 아래 자료·기술·운영을 통제하는지까지 묻는다. Microsoft의 공개 설명도 데이터 통제·운영 통제·기술적 독립을 구별한다.⁸ 해당 기업 제품의 보증이나 모든 국가의 법적 정의를 대신하지 않는다.

도서관은 실제 적용법과 기관 정책에서 필요한 범위를 먼저 정한다. 특정 국가에 원본이 있어도 백업·로그·지원 자료·관리자 접근은 다른 경로를 쓸 수 있다. ‘국내 데이터센터’라는 표시만으로 국외 접근·이전 문제가 끝났다고 하지 않는다. 개인정보 처리 흐름과 클라우드 법규를 함께 대조한다.

키 관리권, 키 사용, 키 반출은 다르다

‘고객 관리 키’는 고객이 정책·수명 등을 관리하는 범위를 뜻할 수 있지만, 비밀 키 자료를 원하는 곳으로 내려받을 수 있다는 뜻은 아니다. AWS KMS의 고객 관리 키와 HSM의 키 자료, 별도로 생성되는 데이터 키도 다른 대상을 가리킨다. 원문은 키 식별값이 실제 키 자료와 무관하며, HSM의 해당 기반 키는 평문으로 반출하지 않도록 설계됐다고 설명한다.⁹

따라서 키의 이름이나 식별자만 복사해 다른 서비스에 같은 이름을 만들면 기존 암호문을 읽을 수 있다는 가정은 틀리다. 복구·이관 시 원래 서비스에서 허용된 키 사용이 가능한지, 목적지에서 읽을 수 있게 재암호화하거나 제공되는 이관 기능을 사용할 수 있는지 확인한다. 모든 종류의 키가 반출 가능하거나 반대로 전부 반출 불가능하다고 일반화하지 않는다.

암호화는 비인가 열람 위험을 낮추지만 잘못된 업무권한·키 상실·서비스 중단을 해결하지 않는다. 고객이 정책을 관리해도 실제 복호화를 호출할 역할·키 서비스·리전·감사 경로가 필요하다. 키 삭제·회수는 필요한 자료의 복구와 보존을 확인한 뒤 수행하고, 그 행위를 모든 평문·로그·사본의 삭제 완료로 대신하지 않는다.

공급자 연결이 끊겨도 계속 운영할 필요가 있는지 요구를 명시한다. 모든 업무가 완전한 독립 운영을 필요로 하지는 않으며 비용·기능·위험을 비교한다. 클라우드 서비스 종료안처럼 법정 반환 정보, 계약한 전환 지원, 실제 재개 자원을 나누어 통제 가능성을 확인한다.

9. 완성 운영안 FO-G1

FO-G1은 예약·안내·권리 대응을 유지하면서 비용과 위험을 설명하는 운영안이다. 업무 책임자는 정상 완료 기준·SLO·RPO·RTO, 기술 담당은 사용·확장·장애, 재무 담당은 청구·배분·약정, 보안·개인정보 담당은 접근·자료 경로·보존·이전을 맡는다. 실제 구매·법률 승인을 수행한 사례가 아니다.

FO-A1처럼 직접·공통 비용을 대사하고 정상 예약당 비용과 자원 단가를 나누어 FO-U1의 총액 증가·단위 개선을 설명한다. FO-K1의 기간 묶음과 FO-K2의 시간별 약정을 구별하여 수요·만료·적격 범위를 검토한다. 필요한 예비 자원·백업을 지우거나 쓰지 않은 시간 몫을 임의로 이월해 절감을 꾸미지 않는다.

서비스 측정에는 성공·실패·미관측과 실제 수신·처리 경계를 둔다. CR-S2의 97~99% 범위처럼 미확인이 목표 판정을 바꿀 수 있으면 근거를 보완한다. 관측된 집단의 좋은 비율을 전체 결과로 표시하지 않으며, 장애와 법정 통지·주민 업무 영향을 별도로 추적한다.

공통 인증·데이터·키·배포의 실패범위를 그리고 잔존 용량을 확인한다. RPO 15분·RTO 30분을 충족할 전략 후보는 명칭이 아니라 대체 환경에서의 자료·권한·접속·거래·외부 결과 대사로 판단한다. CR-R1의 35분이 반복되면 단계별 원인과 준비·대안을 검토하고, 완료 기준을 기동으로 바꿔 통과시키지 않는다.

주권·종료는 위치뿐 아니라 접근·키 사용·관할·반환·재구성의 조건을 맞춘다. 보안·보존 요구를 위반하며 복구 위치만 바꾸는 안은 채택하지 않는다. 격리된 새 환경에서 반환할 원장·관계·판본을 읽고 필요한 업무를 수행할 수 있는지 검증한다. 실제 개통 전에는 옛 원장의 독립 쓰기 권한 회수를 확인한 뒤 새 쓰기를 연다. 옛 키·사본·계약 등 잔여는 보존·복구 조건을 충족한 뒤 정리한다. 미확인 기능은 확대하지 않고 담당·추가 확인·잔여를 남긴다.

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

FO-U1의 비용 변화와 CR-R1의 복구 결과를 해석하고 클라우드 비용 최소화의 한계를 설명하시오.

목차: 비용·가치의 단위 → 두 복구 목표 → 필요한 보호·준비와 선택.

같은 비용·품질 포함범위에서 월 총액과 정상 완료당 비용을 계산한다. 복구에서는 사용 가능한 자료점과 업무 재개 시각을 각각 목표와 비교한다.

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

클라우드 예약 서비스의 FinOps·회복성·보안·주권을 연결한 FO-G1을 설계하시오.

구성 과정: 동일 업무의 비용·성과·장애·자료 경로를 연결하고, 미확인과 변경·확대 보류의 조건까지 쓴다.

비용 배분과 청구 합계를 맞추고 시간별 약정의 빈 몫을 뒤 시간으로 넘기지 않는다. 관측 공백·공통 인증·키 의존이 승인과 복구에 주는 영향을 별도로 설명한다.

12. 자기교정

조건 변경과 해설

다음 달 같은 1.5백만 원으로 7,500건을 정상 완료하면? 건당 200원으로 첫 달과 같다. 총액과 정상 업무량이 각각 25% 늘었다. 오류·지원·비용 범위가 같은지 확인한 뒤 해석한다.

FO-K1의 800시간과 FO-K2의 두 시간 합계 2를 같은 방식으로 합산해도 될까? FO-K1은 기간 내 자유 합산이 가능한 가상 묶음이므로 60,000/800=75원이다. FO-K2는 시간별 몫을 넘기지 않아 사용이 몰리면 220원이 된다. 어느 계약을 적용하는지 확인하지 않고 전체 합계식만 복사하지 않는다.

CR-R1의 자료점이 09:40이고 업무 재개가 10:25라면? 사용 가능한 자료라는 전제에서 RPO는 간격 20분으로 5분 초과, RTO는 25분으로 충족한다. 키 서비스가 없어 실제로 자료를 읽지 못하면 이 ‘사용 가능’ 전제부터 성립하지 않으므로 재개와 복구점을 확정할 수 없다.

독립 확인: 일부 관측 공백을 복원한 뒤에도 목표가 미확정일까

CR-S2의 공백 20구간 중 12구간을 복구하여 성공 7·실패 5로 확인했고 8구간은 여전히 미확인이다. 원래 성공 970·실패 10과 목표 98%는 같다. 새 관측 집단 비율과 전체 가능한 범위를 계산하여 통과 여부를 판단한다. 전체 공백을 정책상 실패로 처리하는 값과 실제 장애가 확인된 값도 구별한다.

풀이를 닫고 120원·220원의 같은 총량/다른 시간대, 공통 인증 99%가 복제본 99.9999%를 제한하는 이유, 키 관리권·사용권·자료 반출을 각각 설명한다.

2026-10-05 Savings Plans 적용 공식 문서와 AWS KMS 개념 문서를 다시 열람했다. 실제 구매 단가·계약·모든 키 유형이나 국내 법률 적용을 확인한 것으로 확대하지 않는다.

근거·판본·적용 범위

본문의 가격·시각·확률·지표·계획·문제·답안은 자체 교육 자료다. 실제 청구 분석·구매·법률 적용·장애/복구 시험·독립 감수는 수행하지 않았다.

회독의 핵심

지출과 같은 품질의 결과를 연결하되 시간대·분모·관측 공백을 숨기지 않는다. 공통 의존과 사용 가능한 자료점, 실제 키·권한·복구 경로를 확인한다. 낮은 비용이 아니라 필요한 가치·보호·회복 조건을 만족하는 선택을 근거와 결과로 관리한다.

보강 연습 1: 컴퓨트 비용 감소가 업무 단가 감소를 뜻하는가

두 기간은 길이와 서비스 품질 기준이 같고 아래 비용을 모두 포함한다. 첫 기간의 컴퓨트·공유·오류 수정 비용은 각각 900,000원·300,000원·200,000원, 정상 완료한 서로 다른 업무는 7,000건이다. 다음 기간은 720,000원·300,000원·480,000원, 정상 완료 업무는 6,000건이다. 다음 기간의 실행 시도는 재시도를 포함해 12,000회다. 수치는 실제 요금제가 아닌 교재 계산용이다.

총비용과 정상 완료 업무당 평균 비용을 비교하라. “컴퓨트 비용이 20% 줄었고 720,000/12,000=60원이므로 최적화에 성공했다”는 보고를 평가하라.

periods = [(900_000, 300_000, 200_000, 7_000),
           (720_000, 300_000, 480_000, 6_000)]
for compute, shared, correction, completed in periods:
    total = compute + shared + correction
    assert completed > 0
    print(f"총비용={total}, 업무당비용={total / completed:.0f}")

보강 연습 2: 높은 관측 성공률로 누락 구간까지 통과시킬 수 있는가

동일 가중치의 1분 구간 1,000개 중 성공 980개·실패 5개·상태 미확인 15개다. 전체 구간의 성공 비율 목표는 99% 이상이며, 관측 누락을 실제 실패로 정의한다는 별도 정책은 없다. 관측된 구간만의 성공률과 전체 기간의 가능한 성공률 범위를 구하라.

나중에 미확인 구간 중 성공 8개·실패 3개가 확인되어 미확인 4개가 남았다. 지금 목표 달성을 확정할 수 있는가? 남은 구간 중 몇 개가 성공해야 하는가?

보강 연습 3: 최신 백업 파일이 있어도 복구 가능한 시점은 더 과거일 수 있다

10:00 장애에 대해 RPO 목표 15분·RTO 목표 30분이다. 09:50 백업은 손상 여부와 복호화가 확인되지 않았고, 09:35 백업만 일관성과 복호화·복원이 확인되었다. 추가 저널로 더 최신 상태를 재구성할 수 있다는 증거는 없다. 09:35 백업을 사용해 10:25에 합의된 업무 흐름이 정상화되었다. 두 목표의 충족 여부를 각각 판단하라.

별도 이전 계획은 암호문을 새 환경으로 복사하고 같은 문자열의 KMS 별칭을 만들었으므로 기존 키를 즉시 폐기해도 된다고 한다. 실제 키·권한·복원 경로 검증은 아직 없다. 계획에서 필요한 검증을 설명하라.