클라우드 서버 초과판매 증거 확보 및 티켓 작성 가이드

3단계로 초과판매 증거 확보, 이렇게 티켓을 써야 효과적입니다

업데이트됨 2026-09-05 · CloudWorth

초과판매증거 확보티켓성능 테스트CloudWorthSteal TimeVPS 오버셀링VPS 점검

시스템 로그+타임스탬프+제3자 공증으로 증거를 고정하고, 티켓에서 SLA 위반을 직접 지적하세요.

오버셀링 측정 방법

서비스 제공자에게 벤치마크 소프트웨어로 성급하게 결론을 내리지 마세요. 상대방이 “테스트 방법이 표준적이지 않다”는 한마디만 하면, 아무리 멋진 스크린샷도 소용없습니다. 오버셀링의 본질은 물리적 리소스가 초과 할당되는 것이며, 그 징후는 눈에 잘 띄지 않는 두 곳에 숨어 있습니다: CPU의 Steal Time과 디스크의 캐시 절벽입니다.

먼저 저부하 시간대에 기준선을 한 번 실행하세요. top -d 5로 10분간 steal 값을 기록하십시오. 정상적인 클라우드 서버는 1% 미만이어야 하며, 장기간 5%를 초과하면 이웃 VM이 여러분의 vCPU를 침범하고 있다는 뜻입니다. 디스크 IO도 fio로 최대값만 보지 말고 10GB 연속 쓰기 시의 처리량 곡선을 확인하세요. 오버셀링 호스트의 캐시가 고갈되면 IOPS가 절벽처럼 급락합니다. 이는 “테스트 방법”으로 바꿀 수 없는 사실입니다.

같은 테스트를 세 가지 시간대(예: 비첨두·저녁 피크·새벽)에 각각 한 번씩 실행하고 원본 출력을 보관하세요. Steal Time조차 이해하기 어렵다면, 저희가 정리한 핵심 요점으로 절차를 따라 해 보거나 /app에서 자동 진단 예시를 확인할 수 있습니다. 기억하세요. 측정 대상은 “느리냐 빠르냐”가 아니라 “리소스가 이웃에게 도난당했는지”입니다.

증거를 어떻게 확보할 것인가

증거를 확보하는 목표는 '성능이 나쁘다'를 입증하는 것이 아니라 '리소스 약속이 SLA와 맞지 않는다'는 것을 입증하는 것이다. 따라서 각 증거에는 타임스탬프, 명령어 또는 도구 이름, 원본 출력, 실행 환경이라는 네 가지 요소가 반드시 포함되어야 한다.

date -u +%FT%TZ를 테스트 명령과 함께 실행하여 로그에 UTC 시간이 자동으로 남게 하고, script -a session.log를 사용해 전체 터미널 세션을 기록하면 사후 조작 의심을 피할 수 있다. 스크린샷은 제목 표시줄과 시스템 시간을 남겨야 하며, 휴대폰으로 화면을 녹화하고 녹화 시작 때 현재 시간을 소리 내어 읽는 것이 가장 확실한 제3자 시간 기준이 된다. 디스크 Cache가 급락하는 순간은 iostat -dx 5로 연속 측정한 CSV와 함께 보관하는 것이 단일 스크린샷보다 설득력이 훨씬 높다.

'교차 검증'도 잊지 말아야 한다. 두 차례 테스트는 최소 6시간 이상 간격을 두고, 가급적 '갱신 주기'나 '옆 테넌트의 업무 피크'를 걸치도록 한다. 한 번만 측정하면 상대가 부인할 여지가 있지만, 다른 날짜와 다른 부하에서 같은 결과가 반복되면 증거 체인은 닫힌다.

더 나아가 동일한 증거로 가성비 곡선을 그려보는 것도 방법이다. 같은 가격대에서 CPU 할당 지분이 퍼블릭 클라우드 기준보다 30% 낮은가? 이 수치는 과매각을 직접 증명하지는 못하지만, '기술적 논쟁'을 'FinOps 프리미엄 손실'로 끌어올려 티켓을 '당신이 거짓말한다'에서 '내가 손해다'로 바꿔준다.

티켓 작성 방법

티켓의 철칙은 사실만 쓰고, 단정하지 않기입니다. “여러분이 오버셀했다”고 말하지 말고 “CPU steal 평균 12%, 디스크 캐시 급락 4회 관측됨”이라고 하세요. “성능 불합격”이라고 말하지 말고 “귀사 SLA의 CPU 성능 약속 기준으로 현재 성능이 기준선을 벗어났습니다”라고 하세요.

권장 구조:

1. 환경 설명: 인스턴스 구성, 운영체제, 시간 범위
2. 테스트 방법: 재현 명령 첨부 (일반 명령을 사용하고, 宝塔이나 타사 벤치마크 도구는 사용하지 않음)
3. 원시 데이터: 세 세트의 steal 로그, 디스크 CSV, 타임스탬프가 있는 스크린샷을 압축해 첨부
4. 영향 설명: 업무에 미친 구체적 영향 기재 (예: API 응답 시간이 80ms에서 2s로 증가)
5. 요청: 공식 측에 호스트 부하 상태 재검토와 리소스 할당 설명을 요청

템플릿은 이렇게 시작할 수 있습니다:

“저희 인스턴스는 2025-06-01 02:00, 08:00, 20:00에 동일한 테스트를 세 번 실행했고, 샘플은 첨부를 참조하십시오. 세 번 모두 CPU steal이 8%를 초과했으며, 디스크 캐시가 바닥난 뒤 IOPS가 명목의 20% 미만으로 떨어졌습니다. 귀사 SLA가 기준 CPU 및 IO 성능을 약속하고 있으므로, 기술팀에서 물리 호스트의 현재 할당 비율과 이웃 부하를 점검해 주시기 바랍니다.”

주의: 본문에 “불만”, “오버셀”, “사기” 등의 단어를 넣지 마십시오. 그런 표현은 티켓이 에스컬레이션된 후에 사용하십시오. 티켓의 가치는 상대방이 “도구가 정확하지 않다”고 반박하지 못하게 하는 것이므로, 모든 데이터가 완전한 로그 라인과 대응되어야 합니다. 상대방이 “당사 테스트 도구를 사용하세요”라고 답하면, “이미 귀사 문서의 방법으로 재테스트했으며 자세한 내용은 첨부 제3그룹 데이터를 참조하십시오”라고 답할 수 있습니다. 이렇게 하면 공을 상대에게 깨끗하게 되돌려준 셈입니다.

서비스 제공자가 인정하지 않을 경우

상대가 “테스트 방법에 문제가 있다” 또는 “호스트 로드는 정상이다”라고 말할 때, 서둘러 논쟁하지 마세요. 먼저 같은 시간대의 호스트 모니터링 로그를 요구하세요. 그들은 대개 내놓지 못하거나 축소된 버전만 줄 수 있습니다. 이 시점에서 당신은 이미 두 가지 확실한 증거를 갖고 있습니다: CPU steal이 8%를 넘는 라인별 로그와, 디스크 캐시가 바닥난 뒤 IOPS가 명세된 수치의 20%까지 떨어진 곡선입니다. 이 두 데이터를 시간 축을 맞춘 비교표로 만들고, 디스크 캐시의 급락이 steal 피크와 정확히 겹친다면, 이는 호스트 CPU와 저장소 자원이 동시에 이웃에게 잠식된 것이지 일회성 테스트 변동이 아니라 리소스 풀 과다 판매의 전형적인 형태임을 지적하세요.

만약 상대가 여전히 “도구가 정확하지 않다”고 버티면, 이렇게 답하면 됩니다: “귀사가 공식적으로 권장하는 테스트 스크립트와 파라미터를 제공해 주십시오. 문서대로 재테스트하고 제3자 공증인이 과정을 기록하겠습니다.” 이 단계의 가치는 입증 책임을 서비스 제공자에게 되돌리는 것입니다. 동시에 다른 날짜에 두 번의 독립 테스트를 추가로 수행하세요(예: 새벽과 저녁 피크 시간대). 교차 검증을 위해서입니다. 세 번의 샘플이 모두 같은 결론을 가리킨다면, 상대는 “우연한 현상”으로 얼버무릴 수 없습니다. 각 테스트의 원본 로그, 시스템 시간, NTP 동기화 기록, 스크린샷의 타임스탬프를 반드시 보관하세요. 이것들은 이후 상위 채널에 이의를 제기할 때 사용할 자료입니다.

민원 에스컬레이션 및 환불

만약 담당 고객 서비스 부서가 에스컬레이션을 거부한다면 채널 상향 조정을 시작하세요. 첫째, 서비스 제공업체 공식 웹사이트에 공지된 abuse/불만 신고 이메일로 이메일을 보내고, 제목에 “SLA 위반 증거 첨부 번호”를 명시하세요. 둘째, 클라우드 서비스 제공업체가 위치한 관할 지역의 통신 관리국 또는 12321 인터넷 불량 및 스팸 신고 접수 센터에 자료를 제출하세요. 제출할 때 테스트 결론을 반복하지 말고 사실 목록만 나열하세요: 어떤 날짜에 어떤 인스턴스에서, 어떤 테스트를 실행했는지, 결과 값이 얼마인지, 해당하는 SLA 조항은 무엇인지.

환불 요청은 두 단계로 나누어 진행하세요. 먼저 서비스 제공업체의 환불 규칙에 따라 “미사용 기간 환불”을 신청하고, 리소스 미달로 인한 비즈니스 손실을 명시하며 추가 배상을 요구하세요. 이때 FinOps 관점에서 계산해 볼 수 있습니다: 명목상 8코어 16G에 프리미엄을 지불했지만, 실제 사용 가능한 컴퓨팅 성능은 3코어에 불과해 이미 가성비가 크게 떨어졌습니다. 만약 상대방이 일부 비용만 환불하려 한다면, “리소스 할당 설명”을 발급해 줄 것을 요구하고, 해당 인스턴스가 고밀도 저가 VPS와 호스트를 공유하는지 여부를 명시하도록 하세요. 대부분의 서비스 제공업체는 이 설명을 바탕으로 초과 판매 신고를 받을까 두려워해 절충안을 제시할 것입니다.

마지막으로 주의할 점: 모든 커뮤니케이션은 티켓 또는 이메일로 진행하고 스크린샷을 보관하세요. 환불을 신청하는 경우, 먼저 디스크 데이터를 내보낸 후 인스턴스를 삭제하세요. 환불 후 인스턴스는 비워지며, 이후 중재 또는 소송에 대비해 포렌식 로그를 최소 180일 동안 보관해야 합니다. 환불에 성공하더라도 이 포렌식 방법을 다음 서비스 제공업체에도 적용해 결제 전에 검증하고, 다시 문제를 겪지 않기를 권장합니다.