클라우드 서비스 장애, 사이버보험으로 보상될까 – 멈춘 4시간보다 약관 한 줄이 더 중요합니다

먼저 구분해야 할 보험과 보장의 경계

사이버보험이라는 이름만으로는 충분하지 않습니다

보험 상품명에 ‘사이버’가 들어가더라도 클라우드 장애로 인한 영업중단이 자동으로 보장되는 것은 아닙니다. 개인정보 유출에 따른 배상책임만 보장하는 계약도 있고, 사고대응비와 복구비는 포함하지만 매출 손실은 제외하는 계약도 있습니다.

판단 기준은 광고 문구가 아니라 보험증권과 첨부된 특별약관입니다. 특히 기업휴지, 네트워크 중단, 시스템 실패, 외부 서비스 제공자와 관련된 문구를 따로 찾아야 합니다.

개인정보 배상책임과 제1자 영업손실은 다른 문제입니다

개인정보가 유출되어 고객에게 배상해야 하는 손해는 제3자 배상책임에 가깝습니다. 반면 클라우드 장애로 회사 자체의 매출이 감소하고 복구비가 발생한 손해는 제1자 손해에 해당할 수 있습니다.

두 위험은 한 사고에서 동시에 발생하기도 하지만 필요한 담보와 증거는 다릅니다. 랜섬웨어 사고의 보장 구조가 궁금하다면 사이버보험 랜섬웨어 보상 기준도 함께 확인하면 담보 차이를 이해하는 데 도움이 됩니다.

직접 점검과 전문가 검토 중 무엇이 필요한가

검토 방식	적합한 상황	확인할 사항
회사 내부 점검	사고 전 보장 공백을 미리 확인하는 단계	담보명, 한도, 자기부담금, 면책기간, 외부 사업자 정의
보험사·보험중개사 서면 질의	외부 클라우드 장애 포함 여부가 불명확한 경우	답변 범위, 적용 특약, 지정 사업자 요건, 갱신 시 반영 여부
손해사정사 검토	매출 손실과 장애의 인과관계 또는 산정액을 다투는 경우	업무 범위, 보수 방식, 예상 청구액 대비 비용
변호사 자문	보험사와 공급업체가 책임을 미루거나 합의서가 제시된 경우	추가 청구권 포기, 면책 조항, 구상권 훼손 가능성

보험증권 한 줄이 보상 여부를 가르는 네 가지 질문

첫째, 기업휴지 담보가 실제로 가입되어 있는가

보험증권에서 ‘기업휴지’, ‘영업중단 손해’, ‘네트워크 중단’과 같은 표현을 검색합니다. 기본계약이 아니라 선택특약으로 붙는 경우가 많으므로 보장명만 보지 말고 보험료가 별도로 부과되었는지도 살펴보세요.

• 영업이익 손실이 포함되는지
• 긴급 복구비와 대체 시스템 이용료가 포함되는지
• 손해를 줄이기 위해 지출한 비용이 인정되는지
• 복구 완료 후 매출 정상화 기간까지 보장하는지

둘째, 외부 서비스 사업자의 장애도 포함되는가

자체 서버가 아니라 외부 클라우드에서 사고가 났다면 우발적 기업휴지 또는 종속적 기업휴지 담보가 필요할 수 있습니다. 피보험자 자체 시스템의 중단만 보장하는 계약이라면 클라우드 사업자의 장애는 범위 밖으로 판단될 가능성이 있습니다.

‘외부 정보기술 서비스 제공자’, ‘위탁 서비스 제공자’, ‘지정 서비스 사업자’와 같은 정의를 확인하고, 현재 사용하는 클라우드·호스팅·결제·인증·도메인네임시스템 사업자가 포함되는지 비교해야 합니다.

셋째, 장애 원인이 약관상 보험사고인가

해킹이나 악성코드뿐 아니라 운영 실수, 설정 오류, 소프트웨어 결함을 보장하는 계약이 있습니다. 반대로 악의적 사이버 공격만 담보하고 비악의적 시스템 장애는 제외하는 계약도 있습니다.

사고 초기에는 원인을 단정하지 말고 “특정 시각부터 서비스 접속과 거래 처리가 중단되었으며 원인은 조사 중”이라고 사실 중심으로 통지하는 편이 안전합니다.

넷째, 면책기간과 자기부담금을 넘었는가

기업휴지 담보에는 일정 시간 동안 발생한 손해를 보상하지 않는 면책기간이 붙을 수 있습니다. 장애가 2시간 지속되었더라도 면책기간이 그보다 길다면 영업손실 보험금이 발생하지 않을 수 있습니다.

다만 포렌식, 긴급 복구, 법률 자문과 같은 다른 비용 담보는 별도의 자기부담금이나 조건이 적용될 수 있습니다. 영업중단 손해가 작다고 사고 전체를 포기하기 전에 비용 항목별 보장 여부를 나누어 보세요.

같은 4시간 장애라도 원인에 따라 결론이 달라집니다

사이버 공격으로 멈춘 경우

서비스 거부 공격, 계정 탈취, 악성코드 또는 랜섬웨어로 시스템이 멈췄다면 전형적인 사이버 사고에 가까워집니다. 그러나 공격 대상이 클라우드 사업자인지, 회사 계정과 설정인지에 따라 적용되는 담보가 달라질 수 있습니다.

클라우드 사업자 측 사고라면 외부 서비스 제공자 장애 담보가 핵심이고, 회사 계정이 탈취되었다면 자체 네트워크 사고 담보와 보안관리 의무가 함께 검토될 수 있습니다.

업데이트 오류나 설정 실수로 멈춘 경우

악의적인 공격이 없었다면 ‘시스템 실패’, ‘비악의적 네트워크 중단’, ‘운영 오류’가 보장되는지 확인해야 합니다. 약관이 사이버 공격만을 보험사고로 정의한다면 단순 기술 장애는 제외될 수 있습니다.

클라우드 사업자의 첫 공지는 잠정적인 설명일 수 있습니다. 공급업체 공지만으로 원인을 확정하지 말고, 내부 배포 기록과 설정 변경 이력까지 함께 보존하세요.

정전이나 장비 고장으로 멈춘 경우

데이터센터 정전, 냉각설비 고장, 통신망 단절은 사이버보험과 재물보험의 경계에 놓일 수 있습니다. 물리적 손상이 발생했는지, 회사가 소유한 자산인지, 외부 사업자의 시설인지에 따라 적용 계약이 달라집니다.

일반 재물보험의 기업휴지 담보는 물리적 손상을 전제로 하는 경우가 있으므로, 데이터 접근 불능만 발생한 사고가 자동으로 포함된다고 보기는 어렵습니다.

원인별로 확인할 약관 문구

장애 원인	우선 확인할 담보	놓치기 쉬운 쟁점
해킹·서비스 거부 공격	사이버 사고, 네트워크 중단, 외부 서비스 제공자	공격 대상이 회사인지 공급업체인지
업데이트·설정 오류	시스템 실패, 비악의적 장애, 운영 오류	악의적 행위가 없는 사고의 포함 여부
정전·장비 고장	재물보험, 기계보험, 우발적 기업휴지	물리적 손상 요건과 외부 시설 범위
계획된 유지보수	보험사고 정의와 제외 조항	사전 공지 여부와 불가피한 긴급 작업인지
간헐적 성능 저하	서비스 중단 정의와 면책기간	완전 중단이 아닌 지연도 인정되는지

조금 더 깊이 알고 싶다면

사이버보험은 상품마다 ‘컴퓨터 시스템’, ‘네트워크’, ‘보안 사고’, ‘시스템 실패’를 다르게 정의합니다. 같은 업데이트 오류라도 회사가 직접 관리하는 응용프로그램의 오류와 외부 클라우드 기반 서비스의 오류는 다른 조항으로 처리될 수 있습니다.

따라서 사고 원인만 찾는 것으로는 부족합니다. 사고가 발생한 시스템의 소유자, 운영자, 계약 상대방과 서비스 제공 단계를 함께 표시해야 약관상 어느 담보를 검토할지 정할 수 있습니다.

외부 클라우드 장애를 다루는 우발적 기업휴지

자체 시스템이 멀쩡해도 영업은 멈출 수 있습니다

쇼핑몰 서버는 정상이어도 결제대행 서비스가 중단되면 주문이 완료되지 않습니다. 예약 시스템이 작동해도 문자 인증이나 지도 서비스가 멈추면 고객은 거래를 포기할 수 있습니다.

이처럼 핵심 공급업체의 사고 때문에 회사의 영업이 중단되는 손해를 다루는 구조가 우발적 기업휴지입니다. 클라우드뿐 아니라 콘텐츠 전송망, 결제, 인증, 통신, 도메인네임시스템 등 서비스 사슬 전체가 검토 대상입니다.

모든 클라우드 사업자가 자동으로 포함되는 것은 아닙니다

일부 계약은 특정 외부 사업자를 보험증권에 기재하거나 사전에 신고하도록 요구할 수 있습니다. 직접 계약한 사업자만 인정하거나 일정 규모 이상의 유료 서비스만 포함하는 조건도 확인해야 합니다.

• 보험증권에 외부 사업자 이름이 기재되어 있는지
• 클라우드 리셀러와 실제 인프라 운영자 중 누가 담보 대상인지
• 해외 리전과 특정 국가의 서비스가 제외되는지
• 무료·시험판·베타 서비스도 포함되는지
• 2차 또는 3차 하청 사업자의 장애까지 확장되는지

서비스 사슬을 한 장으로 그려보세요

보험 청구와 재계약 준비를 위해서는 기술 구성도보다 간단한 ‘매출 의존 지도’가 유용합니다. 고객의 주문이 매출로 기록될 때까지 거치는 외부 서비스를 순서대로 적어보세요.

1. 고객이 접속하는 도메인과 도메인네임시스템
2. 콘텐츠 전송망과 웹 방화벽
3. 응용프로그램과 데이터베이스
4. 로그인·본인인증 서비스
5. 결제대행과 금융기관 연결
6. 주문·예약·고객관리 시스템
7. 문자·메일·고객 안내 채널

복구 전략을 함께 점검하려면 기업용 클라우드 백업 가격과 선택 기준을 참고해 보험과 기술적 복구 수단을 분리해서 비교할 수 있습니다.

보상액은 멈춘 시간의 매출 전부가 아닙니다

매출 감소액과 영업손실은 다릅니다

장애 시간 동안 평소보다 주문이 3천만 원 줄었다고 해서 3천만 원이 그대로 보험금이 되는 것은 아닙니다. 지출하지 않게 된 결제 수수료, 배송비, 원재료비와 같은 변동비를 제외하고 실제로 감소한 영업이익을 계산하는 방식이 적용될 수 있습니다.

장애 중 보류된 주문이 복구 후 다시 결제되었다면 영구적인 손실과 단순 지연 매출을 구분해야 합니다. 반대로 고객이 경쟁사로 이동해 돌아오지 않았다면 그 손해가 약관상 얼마나 인정되는지 별도 검토가 필요합니다.

추가비용은 항목별로 기록해야 합니다

• 긴급 서버 이전과 임시 인프라 이용료
• 외부 복구업체와 정보보호 전문가 비용
• 초과근무, 긴급 배포와 장애 대응 인력 비용
• 고객 안내, 문자 발송과 임시 상담센터 운영비
• 대체 서비스 또는 소프트웨어의 단기 사용료
• 사고 원인 조사와 로그 분석 비용

지출 목적, 승인자, 공급업체, 작업 시간과 장애와의 연관성을 함께 기록하세요. 단순히 영수증만 모아두면 평소 운영비인지 사고 대응비인지 구분하기 어렵습니다.

면책기간과 정상화 기간을 나누어야 합니다

기술적으로 시스템이 복구된 시각과 매출이 정상 수준으로 돌아온 시각은 다를 수 있습니다. 장애 직후 고객이 불안해 거래를 미루거나 검색 노출과 광고 효율이 떨어지면 영업 영향이 더 오래 이어질 수 있습니다.

보험계약이 복구 후 일정 기간의 손실까지 인정하는지, 간헐적으로 반복된 장애 시간을 합산하는지, 하나의 사고로 집계하는지를 확인해야 합니다.

손해액 자료는 이렇게 나누면 깔끔합니다

자료 구분	준비할 내용	주의할 점
기준 매출	동일 요일·시간대, 전주·전월·전년 매출	계절성, 행사, 가격 변경을 반영
실제 매출	장애 중 주문, 취소, 지연 결제, 복구 후 회복 매출	중복 집계와 단순 지연 매출 제외
절감 비용	결제 수수료, 배송비, 원재료비 등	고정비와 변동비를 구분
추가비용	복구업체, 대체 인프라, 초과근무, 고객 안내	사고와의 관련성과 승인 내역 기록
성장·계절 조정	신제품 출시, 광고 캠페인, 성수기 자료	단순 과거 평균이 부적절한 이유를 설명

서비스 크레딧과 보험금을 함께 받을 수 있을까

서비스 크레딧은 실제 영업손실과 구조가 다릅니다

클라우드 서비스 수준 계약에서 제공하는 크레딧은 일정 수준의 가용성을 충족하지 못했을 때 서비스 이용료 일부를 돌려주는 방식이 일반적입니다. 월 이용료가 수백만 원이더라도 장애로 인한 매출 손실이 수천만 원이라면 두 금액 사이에는 큰 간극이 생길 수 있습니다.

크레딧 신청 가능 여부와 사이버보험 보장 여부는 별개의 계약에서 판단됩니다. 서비스 크레딧을 받지 못했다고 보험 청구가 곧바로 불가능해지는 것도 아니고, 크레딧을 받았다고 보험금이 자동으로 지급되는 것도 아닙니다.

이중 보상과 구상권을 함께 확인하세요

같은 손해가 클라우드 사업자의 환불·합의금과 보험금으로 중복 보전되는 경우 보험금 산정에서 조정될 수 있습니다. 크레딧, 환불, 손해배상금 또는 합의금을 받았다면 보험사에 알리고 어떤 손해 항목에 충당되는지 기록하세요.

보험금 지급 후 보험사가 클라우드 사업자에게 책임을 묻는 구상 절차가 진행될 수도 있습니다. 보험사의 권리를 해칠 수 있는 책임 포기나 광범위한 면책 합의에 서명하기 전에는 계약 검토가 필요합니다.

서비스 크레딧 신청은 기한부터 확인합니다

서비스 수준 계약은 크레딧 신청 기한, 제출 자료와 신청 방식을 정해둘 수 있습니다. 보험 검토가 끝날 때까지 기다리다가 신청 기한을 놓치지 않도록 두 절차를 병행하세요.

• 장애가 발생한 서비스와 리전
• 장애 시작·종료 시각과 적용 시간대
• 계정번호, 계약번호와 이용 서비스
• 상태 페이지 공지와 자체 모니터링 자료
• 크레딧 수령이 추가 청구권에 미치는 영향

보험금보다 먼저 지켜야 할 청구 증거

공급업체 공지와 내부 로그를 함께 보존합니다

클라우드 상태 페이지의 장애 공지는 중요한 자료지만 그것만으로 회사의 손해까지 입증되지는 않습니다. 내부 감시 시스템, 접속 오류율, 거래 실패 기록, 고객 문의와 주문 감소 자료를 같은 시간축으로 맞춰야 합니다.

• 장애 시작과 종료 시각을 시간대까지 표시
• 상태 페이지 화면과 공지 원문 보존
• 접속 실패, 응답 지연, 오류 코드 기록
• 배포·설정 변경과 관리자 작업 이력
• 주문·결제·예약 실패 자료
• 고객 문의, 취소와 환불 기록

매출 자료는 정상 기간과 비교할 수 있어야 합니다

장애 당일 매출만 제출하기보다 동일 요일과 시간대의 정상 매출, 광고비, 방문자 수, 전환율을 함께 제시하세요. 성장 중인 회사라면 최근 증가 추세와 프로모션 계획도 별도로 설명해야 합니다.

주문이 단순히 늦게 들어온 것인지 완전히 사라진 것인지 구분하기 위해 고객·주문 단위의 상태 변화를 추적하는 것이 좋습니다.

복구비는 승인 과정까지 남겨야 합니다

보험계약에 따라 특정 사고대응 업체를 이용하거나 사전 승인을 받아야 할 수 있습니다. 긴급 상황에서 구두 승인을 받았다면 통화 시각, 담당자 이름과 승인 범위를 즉시 이메일이나 사고 기록에 남기세요.

업체 견적을 받을 때는 작업 범위, 시간당 비용, 긴급 할증, 결과물과 추가 비용 조건을 확인해야 합니다. 복구 비용과 보안 개선 비용을 한 견적서에 섞으면 사고 대응비의 범위를 나누기 어려워질 수 있습니다.

청구 준비 폴더를 여섯 칸으로 나누세요

1. 보험: 보험증권, 특별약관, 사고접수 기록
2. 계약: 클라우드 이용약관, 서비스 수준 계약, 엔터프라이즈 계약
3. 기술: 로그, 설정, 배포 이력, 상태 페이지 자료
4. 영업: 주문, 예약, 결제 실패, 고객 이탈 자료
5. 재무: 기준 매출, 절감 비용, 추가비용, 세금계산서
6. 소통: 고객 안내, 공급업체 답변, 내부 의사결정 기록

사고 발생 후 24시간 안에 해야 할 일

원인이 확정되지 않아도 임시 통지는 가능합니다

보험 통지를 원인 확정 뒤로 미루면 약관상 통지 기한과 비용 승인 절차를 놓칠 수 있습니다. 사고 초기에는 확인된 사실과 현재 영향을 구분해 통지하면 됩니다.

예상 손해액을 아직 모른다면 “매출 영향과 복구비를 산정 중이며 추가 자료를 제출하겠다”고 표시하세요. 추정치를 단정적으로 적기보다 계산 근거가 준비되는 대로 보완하는 방식이 낫습니다.

고객 안내는 장애와 침해사고를 구분합니다

서비스가 중단되었다고 개인정보 유출이 발생한 것은 아닙니다. 조사 전부터 해킹이나 유출을 단정하면 불필요한 혼란과 계약상 문제가 생길 수 있습니다.

장애 사실, 영향 범위, 현재 복구 상태, 고객이 취해야 할 행동을 분리해 안내하고 원인과 정보 유출 여부는 조사 중이라고 명확히 표시하세요.

클라우드 사업자와 최종 합의를 서두르지 않습니다

서비스 크레딧 신청과 최종 손해배상 합의는 다릅니다. 합의서에 추가 청구 포기, 비밀유지, 책임 면제와 같은 문구가 있다면 보험사의 구상권과 회사의 추가 청구 가능성에 영향을 줄 수 있습니다.

금액이 크거나 계약 문구가 넓다면 서명 전에 법률 검토를 고려하세요. 작은 크레딧을 빨리 받으려다 더 큰 손해의 청구권을 좁히는 상황은 피해야 합니다.

실제 적용 사례

온라인 예약 서비스를 운영하는 한 기업이 오전 10시부터 결제와 로그인 장애를 겪었다고 가정해 보겠습니다. 클라우드 상태 페이지에는 일부 인증 서비스 지연만 표시되었지만, 내부 자료에서는 로그인 실패율과 결제 이탈률이 동시에 상승했습니다.

담당자는 복구가 우선이라는 이유로 임시 서버 이전을 진행했고, 비용 승인과 작업 범위를 나중에 정리하려 했습니다. 그런데 보험사 확인 과정에서 지정 대응업체 요건과 외부 서비스 사업자 담보가 쟁점이 되었습니다.

회사는 상태 페이지, 내부 로그, 주문 자료, 복구업체 작업 시간을 한 시간표로 묶어 제출했습니다. 덕분에 단순한 서비스 지연이 실제 거래 중단으로 이어졌다는 흐름을 설명할 수 있었습니다.

여기서 교훈은 장애 규모를 크게 표현하는 것이 아닙니다. 어떤 외부 서비스가 어떤 기능을 멈췄고, 그 결과 어떤 거래와 비용이 발생했는지를 시간순으로 연결하는 것이 청구의 뼈대입니다.

침해 가능성이 함께 발견되었다면 한국인터넷진흥원 118 사이버사고 신고 절차를 확인하고, 로그와 증거자료를 삭제하지 않은 상태에서 대응 순서를 정하세요.

예방 예산과 외부 지원이 필요한 기업은 2026년 중소기업 정보보호 지원사업을 함께 살펴보면 보험 외의 복구·예방 수단을 비교하는 데 도움이 됩니다.

자주 묻는 질문

AWS나 네이버클라우드 자체 장애도 국내 사이버보험으로 보상받을 수 있나요?

가능성은 있지만 보험증권에 외부 서비스 제공자 또는 우발적 기업휴지 담보가 있어야 합니다. 해당 사업자가 지정 사업자로 기재되어야 하는지, 해외 리전도 포함되는지, 비악의적 시스템 장애가 보험사고인지까지 확인해야 합니다.

해킹이 아닌 단순 서버 오류도 보험사고가 될 수 있나요?

약관에 시스템 실패, 운영 오류 또는 비악의적 네트워크 중단이 포함되어 있다면 검토할 수 있습니다. 공격만 보장하는 계약에서는 제외될 수 있으므로 ‘사이버 사고’라는 넓은 상품명보다 보험사고 정의와 제외 조항을 읽어야 합니다.

클라우드 장애가 두 시간뿐이어도 보험금을 청구할 수 있나요?

영업중단 담보의 면책기간보다 짧다면 매출 손실은 보상되지 않을 수 있습니다. 다만 긴급 복구비나 사고조사비처럼 별도의 비용 담보는 다른 조건이 적용될 수 있으므로 사고 전체를 하나로 묶어 포기하지 말고 항목별로 확인하세요.

복구됐지만 고객이 이탈한 손해도 인정되나요?

보험계약이 매출 정상화까지의 기간을 어디까지 인정하는지에 따라 달라집니다. 장애 후 매출 감소가 사고와 연결된다는 점을 보여주려면 재방문율, 취소율, 광고 전환율과 정상 기간 자료가 필요합니다. 장기적인 평판 손해는 별도로 제외될 수 있습니다.

서비스 크레딧과 보험금을 함께 받을 수 있나요?

서로 다른 계약에 따른 보전이므로 두 절차를 모두 진행할 수는 있습니다. 다만 같은 손해를 중복 보전하는 부분은 보험금 산정에서 조정될 수 있으므로 크레딧과 환불액을 보험사에 알리고 어떤 항목에 적용되었는지 기록해야 합니다.

클라우드 사업자가 장애 원인을 공개하지 않으면 어떻게 청구하나요?

원인 발표를 기다리기보다 확인된 장애 시간, 내부 오류, 거래 실패와 손해 자료를 중심으로 임시 통지하세요. 이후 공급업체 보고서와 조사 결과가 나오면 보완할 수 있습니다. 원인 미확정 자체가 사고 통지를 미루는 이유가 되지는 않습니다.

리셀러를 통해 클라우드를 계약했다면 누구에게 요구해야 하나요?

서비스 크레딧과 계약상 손해배상은 리셀러 계약의 상대방과 책임 조항을 먼저 확인해야 합니다. 보험 측에서는 실제 인프라 운영자와 계약 상대방 중 어느 범위가 외부 서비스 제공자로 정의되는지 서면으로 질의하는 것이 좋습니다.

여러 클라우드 서비스가 동시에 멈추면 한 번의 사고로 계산하나요?

공통된 하나의 원인에서 발생했는지, 서로 독립된 사고인지에 따라 사고 건수와 자기부담금 적용이 달라질 수 있습니다. 동일한 공급업체의 연쇄 장애인지, 별도 시스템 오류가 겹친 것인지 시간표와 원인 자료를 통해 구분해야 합니다.

지금 15분 안에 보험증권에서 찾을 다섯 문장

보험증권 검색창에 다섯 용어를 입력하세요

1. 기업휴지 또는 영업중단: 매출 손실과 추가비용이 포함되는지 표시합니다.
2. 네트워크 중단 또는 시스템 실패: 해킹이 아닌 장애도 담보되는지 확인합니다.
3. 외부 서비스 제공자: 클라우드·결제·인증 사업자가 포함되는지 봅니다.
4. 면책기간: 보상이 시작되는 장애 지속 시간을 기록합니다.
5. 자기부담금과 보상한도: 예상 손해액과 비교할 숫자를 적습니다.

불명확한 부분은 세 문장으로 서면 질의합니다

• “당사가 이용하는 외부 클라우드 서비스의 비악의적 시스템 장애로 발생한 영업중단도 담보됩니까?”
• “담보 대상 외부 정보기술 서비스 사업자의 범위와 사전 신고 또는 지정 요건을 알려주십시오.”
• “면책기간의 계산 방식과 간헐적으로 반복된 장애의 합산 기준을 확인해 주십시오.”

오늘 할 일은 새 보험을 급히 구매하는 것이 아닙니다. 현재 계약에서 실제로 보장하는 범위를 한 장에 적고, 핵심 클라우드 사업자와 면책기간이 비어 있다면 그 빈칸부터 서면으로 확인하세요. 약관의 빈칸을 사고가 난 뒤 발견하면 가장 비싼 문장이 됩니다.

최종 검토: 2026-09