고객사 요구가 모호할 때, 운영 관점에서 요구사항을 어떻게 명확히 하겠습니까
SLA, SLO, SLI를 CDN 운영에 어떻게 적용하겠습니까
운영은 고객이 아무 일도 못 느끼게 만드는 직무입니다.
운영에서 가장 위험한 건설 정변경입니다.
운영에서도박은 무능입니다.
기능은 무엇을 바꾸는지, 운영은 어떤 수준을 보장해야 하는지입니다.
운영은 결국 체계 싸움입니다.
저는 CDN 운영을 장애 대응이 아니라 서비스 신뢰를 설계하는 직무로 보는 지원자입니다.

고객사 요구가 모호할 때, 운영 관점에서 요구사항을 어떻게 명확히 하겠습니까
압박) CDN은 결국 벤더장비와 솔루션이 대부분인데, 본인 역량이 어디서 차이를 만들 수 있습니까
압박) 설정 변경을 본인이 했고 장애가 났습니다.
압박) 고객이 "지금 당장 캐시를 전부 날려라"라고 요구합니다.
압박) 원인은 아직 불명확한데 고객이 책임과 보상을 요구합니다.
운영은 고객이 아무 일도 못 느끼게 만드는 직무입니다.
CDN 운영자는 캐시 정책, 라우팅, 보안, 장애대응을 통해 가용성과 성능, 비용을 동시에 관리해야 합니다.
장애가 나도 영향 범위를 좁히고 되돌릴 수 있어야 하며, 비용(원본 트래픽, egress, 캐시적 중률)까지 관리돼야 합니다.
2단계 복구 : 최근 변경이력부터 확인하고, 핵심 지표(5xx/4xx 비율, TTFB, 캐시 HIT, 오리진 응답)를 기반으로 병목지점을 찾습니다.
에러율(5xx, 4xx)과 응답 시간(TTFB, 처리시간)을 본 뒤 2) 캐시 HIT/MISS와 오리진 요청량 변화를 확인합니다.
리전 별 편차가 있으면 네트워크/피어링/특정 PoP 이슈 가능성을 우선 봅니다.4) 그 다음 요청로 그에서 공통 패턴(특정 경로, 특정 UA, 특정 헤더, 특정 쿼리)을 찾고, 원본로그와 대조해 오리진 문제인지, CDN 룰 문제인지 확정합니다.
HIT가 떨어지면 원본 비용과 지연이 동시에 올라갑니다.
Cache-Control, Expires 등 헤더가 보수적으로 설정되어 TTL이 과도하게 짧은 경우 2) 쿼리스트링이나 쿠키가 캐시키를 과도하게 분기시키는 경우 3) 퍼지(무효화)가 너무 잦아 캐시가 "따뜻해질 시간"이 없는 경우 4) 변동 콘텐츠를 정적처럼 운영해 불필요한 MISS가 나는 경우입니다.
TTL 임시 상향과 stale-while-revalidate, stale-if-er ror 등으로 오리진 보호2) 오리진 장애 시 대체응답(커스텀에러, 정적 폴백) 적용 3) 핫 콘텐츠를 사전 프리웜하거나, 오리진 요청을 줄이는 룰 적용 4) 요청 폭주가 봇/공격이면 WAF, 레이트리밋, 챌린지로 차단입니다.
운영에서 가장 위험한 건설 정변경입니다.
변경 목적과 영향 범위 문서화 2) 롤백 플랜 사전 준비 3) 단계적 배포(카나리, 특정 리전/도메인부터)4) 배포 전후 관측항목 고정(에러율, 응답 시간, HIT, 오리진 요청)5 배포 후 일정 시간 동안 집중 모니터링입니다.
운영에서도박은 무능입니다.
지표로는 세그먼트 응답 시간, 206/200 비율, 재시도 횟수, 특정 비트레이트에서의 실패율을 봅니다.
기능은 무엇을 바꾸는지, 운영은 어떤 수준을 보장해야 하는지입니다.
SLA는 대외 약속, SLO는 내부 목표, SLI는 측정지표입니다.
벤더가 제공하는 건 기능이고, 차이는 운영 품질에서납니다.
저는 벤더기능을 외우는 사람이 아니라, 기능을 안정적으로 쓰는 체계를 만드는 사람입니다.
운영자는 고객 요구를 따르는 사 람이 아니라, 고객 요구를 안전한 실행으로 바꾸는 사람입니다.
현재 확인된 영향 범위 2) 고객 피해를 줄이기 위해 이미 적용한 임시조치 3) 원인 분석 계획과 다음 업데이트 시간 4) 원인이 확정된 뒤 재발방지와 보상 논의의 절차입니다.
책임을 회피하지 않되, 추정으로 책임을 떠안지도 않겠습니다. 고객은 완벽한 변명보다 통제된 대응을 원합니다.
반복 장애는 시스템 결함이고, 운영이 그 결함을 계속 떠안는 구조가 문제입니다.
운영에서 야간 장애가 '일상'이면 그건 정상 운영이 아닙니다.

[hwp/pdf]2026 GS네오텍 CDN 운영(신입) 면접족보, 면접질문기출