CloudFront 캐시 무효화 실패, 문제 해결을 위한 심층 분석

CloudFront 캐시 무효화의 중요성과 일반적인 문제점

Amazon CloudFront는 엣지 로케이션에 콘텐츠를 효율적으로 캐싱하여 사용자에게 신속하고 안정적인 서비스 제공을 지원합니다. 그러나 원본 서버의 콘텐츠가 업데이트되었을 때, CloudFront에 남아있는 이전 버전의 캐시가 사용자에게 전달되는 상황이 발생할 수 있습니다. 이를 방지하기 위한 '캐시 무효화(Cache Invalidation)' 기능은 필수적입니다.

캐시 무효화는 원본 콘텐츠 변경 시 CloudFront에게 해당 콘텐츠를 캐시에서 삭제하도록 알리는 과정입니다. 이는 사용자 경험에 직접적인 영향을 미치므로, 특히 중요한 업데이트나 긴급 패치를 적용할 때 최신 콘텐츠를 빠르게 반영하는 데 핵심적인 역할을 합니다. CloudFront 캐시 무효화 실패는 이러한 최신 콘텐츠 전달을 지연시켜 심각한 운영 문제를 초래할 수 있습니다. 문제 해결을 위한 심층 분석에 들어가기 전에, 일반적인 실패 원인을 명확히 이해하는 것이 중요합니다.

CloudFront 캐시 무효화 실패는 다음과 같은 여러 요인으로 인해 발생할 수 있습니다:

경로 불일치: 무효화하려는 경로가 원본 서버의 실제 경로 또는 CloudFront 설정과 일치하지 않을 때 실패합니다. 와일드카드(*)를 사용하더라도 패턴 매칭 오류가 발생할 수 있으니 주의가 필요합니다.
요청 제한 초과: CloudFront는 계정별로 초당 캐시 무효화 요청 횟수에 제한을 두고 있습니다. 대규모 업데이트를 짧은 시간 안에 처리하려 할 경우, 이 제한을 초과하여 요청이 실패할 수 있습니다.
권한 부족: IAM 정책 설정이 잘못되어 캐시 무효화 작업을 수행할 적절한 권한이 없을 때도 실패로 이어집니다.
원본 서버 문제: 캐시 무효화 요청 시 CloudFront는 원본 서버와 통신합니다. 이때 원본 서버의 응답 지연이나 오류는 무효화 과정에 영향을 미칠 수 있습니다.
서비스 일시적 오류: 극히 드문 경우지만, CloudFront 서비스 자체의 일시적인 문제로 인해 캐시 무효화가 실패할 가능성도 존재합니다.

이러한 CloudFront 캐시 무효화 실패의 원인들을 미리 파악하고 대비책을 마련하는 것이 안정적인 서비스 운영의 핵심입니다. 예를 들어, 대규모 무효화 작업 시에는 여러 번에 나누어 요청을 보내거나, 특정 시간대에 집중되지 않도록 스케줄링하는 방안을 고려해볼 수 있습니다.

CloudFront 캐시 무효화 실패: 근본 원인 심층 분석

콘텐츠를 사용자에게 신속하게 전달하는 데 핵심적인 역할을 하는 CloudFront 캐시 무효화 기능. 하지만 예상치 못한 무효화 실패는 사용자 경험을 저하시키고 데이터 불일치를 초래할 수 있습니다. 이러한 문제를 해결하려면 아키텍처 및 설정 전반을 면밀히 살펴보는 것이 중요합니다.

CloudFront 설정 문제점

캐시 동작 설정 오류: 캐시 키 설정이 잘못되면 예상치 못한 파일이 캐시되거나, 동일한 파일이 다른 URL로 인식되어 캐시 무효화가 제대로 작동하지 않을 수 있습니다. 쿼리 문자열, HTTP 헤더, 쿠키 등을 캐시 키에 포함하는 방식에 따라 무효화 대상이 달라지므로 주의가 필요합니다.
무효화 경로 불일치: 캐시 무효화 요청 시 지정한 경로와 실제 캐시된 파일 경로가 정확히 일치해야 합니다. 와일드카드(*) 사용 시에도 경로 패턴을 명확히 하고, 대소문자 구분 문제를 꼼꼼히 확인해야 합니다.
배포 설정 오류: Origin Access Identity (OAI) 또는 Origin Access Control (OAC) 설정이 잘못되면 CloudFront가 오리진에 접근하지 못해 캐시 무효화 요청이 최신 상태를 반영하지 못하는 상황이 발생할 수 있습니다.

오리진 서버 응답 및 구성 문제

캐시 제어 헤더 충돌: 오리진 서버의 `Cache-Control` 또는 `Expires` 헤더 설정이 잘못되었거나 CloudFront 설정과 충돌하면 캐시 무효화 로직에 혼란을 야기할 수 있습니다. 예를 들어, `no-cache`나 `no-store` 헤더가 설정된 경우 CloudFront는 해당 객체를 캐시하지 않거나 무효화 요청을 무시할 수 있습니다.
오리진 서버 응답 지연 또는 오류: 캐시 무효화 시점에 오리진 서버가 응답하지 않거나 오류를 반환하면, CloudFront는 최신 콘텐츠를 가져오지 못하고 이전 버전 캐시를 유지할 수 있습니다.
파일 변경 감지 실패: 오리진 서버에서 파일이 변경되었음에도 ETag 또는 Last-Modified 헤더 값이 동일하면 CloudFront는 변경을 감지하지 못해 캐시 갱신이 누락될 수 있습니다.

TTL (Time To Live) 설정의 중요성

CloudFront의 최소, 기본, 최대 TTL 설정은 캐시 무효화의 효과에 직접적인 영향을 미칩니다. TTL이 너무 길면 캐시 무효화 요청 후에도 이전 버전 콘텐츠가 제공될 수 있으며, 반대로 너무 짧으면 캐시의 이점을 활용하기 어렵고 오리진 서버에 부담을 줄 수 있습니다. 따라서 비즈니스 요구사항과 콘텐츠 변경 빈도를 고려하여 적절한 TTL 값을 설정하는 것이 중요합니다. 캐시 무효화는 TTL 만료와 무관하게 즉시 캐시를 제거하지만, TTL 설정은 예상치 못한 문제가 발생했을 때의 "안전망" 역할을 하므로 신중하게 관리해야 합니다.

이처럼 다양한 기술적 요인을 종합적으로 검토하면 CloudFront 캐시 무효화 실패의 근본 원인을 정확히 파악하고 효과적인 해결책을 마련할 수 있습니다. 예를 들어, 특정 이미지 파일의 캐시 무효화가 반복적으로 실패하는 경우, 해당 파일의 캐시 키 설정과 오리진 서버의 `Cache-Control` 헤더 설정을 함께 점검하는 것이 좋은 접근 방식입니다.

실제 CloudFront 캐시 무효화 실패 사례와 해결 과정

CloudFront 캐시 무효화 실패는 콘텐츠 업데이트 시 사용자 경험에 직접적인 영향을 미칠 수 있는 까다로운 문제입니다. 이 글에서는 실제 발생했던 CloudFront 캐시 무효화 실패 사례를 통해 문제 진단부터 해결 과정까지 단계별로 깊이 있게 분석하고, 효과적인 재발 방지 대책을 공유합니다.

문제 진단 및 해결 과정

특정 이미지 파일이 업데이트되었음에도 불구하고 사용자에게는 이전 버전이 계속 보이는 현상이 나타났습니다. 초기 진단 결과, 캐시 무효화 요청은 정상적으로 접수되었으나 CloudFront 로그를 분석해보니 일부 요청에서 여전히 이전 버전의 파일을 반환하고 있음을 확인했습니다. 오리진 서버에는 최신 버전의 파일이 정상적으로 존재함을 확인한 후, CloudFront 배포 설정에서 캐시 동작, TTL, 캐시 키 정의를 면밀히 검토했습니다. 그 결과, 파일에 포함된 Content-Disposition 헤더 값이 예상치 못하게 캐시 키에 영향을 미쳐 CloudFront 캐시 무효화 실패의 원인이 되었음을 파악했습니다.

이를 해결하기 위해 해당 경로에 대한 캐시 동작 설정을 수정하여 Content-Disposition 헤더가 캐시 키에 포함되지 않도록 변경했습니다. 이후 캐시 무효화 요청을 재시도하고, 다양한 지역의 사용자 환경을 시뮬레이션하여 최신 이미지가 정상적으로 표시되는지 꼼꼼히 검증했습니다. 이 과정을 통해 CloudFront 캐시 무효화 실패 문제를 성공적으로 해결하고, 문제 해결을 위한 심층 분석을 마무리했습니다.

재발 방지 대책

일관된 캐시 키 전략 수립: 불필요한 헤더가 캐시 키에 포함되지 않도록 정기적으로 검토하고 명확한 정책을 수립합니다. 예를 들어, 동적 콘텐츠에만 영향을 미치는 헤더는 캐시 키에서 제외하는 방안을 고려할 수 있습니다.
CI/CD 파이프라인 통합: 배포 시점에 맞춰 자동화된 캐시 무효화 단계를 파이프라인에 통합하여 수동 오류를 최소화합니다.
강화된 모니터링 시스템 구축: 캐시 무효화 실패 또는 지연이 발생할 경우 즉시 감지하고 대응할 수 있는 시스템을 마련합니다.
테스트 환경에서의 철저한 검증: 프로덕션 환경에 적용하기 전에 테스트 환경에서 캐시 무효화 기능이 제대로 작동하는지 충분히 검증합니다.

효과적인 캐시 무효화 전략 수립 및 모범 사례

CloudFront 캐시 무효화 실패는 서비스 안정성과 사용자 경험에 직접적인 영향을 미칠 수 있습니다. 이러한 문제를 최소화하고 효율적인 캐시 관리를 위해서는 사전에 체계적인 전략을 수립하고 검증된 모범 사례를 따르는 것이 필수적입니다. 이 섹션에서는 효과적인 캐시 무효화 전략 수립 방법과 유용한 도구 활용법, 그리고 최적의 설정을 위한 모범 사례를 심층적으로 다룹니다.

1. 캐시 무효화 실패 최소화를 위한 전략

정확한 경로 지정: 무효화하려는 파일 또는 디렉토리의 경로를 정확하게 지정하는 것이 중요합니다. 경로가 잘못되면 의도하지 않은 콘텐츠가 캐시에서 제거되거나, 반대로 필요한 콘텐츠가 제거되지 않을 수 있습니다. 와일드카드(*) 사용 시에도 경로 패턴을 신중하게 검토해야 합니다.
적절한 무효화 주기 설정: 콘텐츠 업데이트 빈도에 따라 캐시 무효화 주기를 설정해야 합니다. 너무 잦은 무효화는 CloudFront에 부하를 주고 비용을 증가시킬 수 있으며, 반대로 주기가 너무 길면 오래된 콘텐츠가 사용자에게 제공될 위험이 있습니다.
버전 관리 활용: 파일 이름에 버전 정보를 포함시키는 전략(예: `style-v1.2.css`)은 캐시 무효화의 복잡성을 줄여줍니다. 파일 내용이 변경될 때마다 새 버전을 사용하면 기존 캐시는 그대로 유지되면서 새로운 버전은 즉시 배포할 수 있습니다.
CloudFront 함수/Lambda@Edge 활용: 동적인 캐시 제어 로직이 필요한 경우, CloudFront 함수나 Lambda@Edge를 사용하여 요청 및 응답을 조작할 수 있습니다. 이를 통해 특정 조건에 따라 캐시 동작을 제어하거나, 무효화 로직을 더욱 정교하게 구현할 수 있습니다.

2. 유용한 도구 및 기능 활용법

AWS CLI: AWS Command Line Interface (CLI)를 사용하면 스크립트를 통해 대량의 캐시 무효화 요청을 자동화할 수 있습니다. `aws cloudfront create-invalidation` 명령어를 활용하여 효율적인 무효화 작업을 수행할 수 있습니다.
CloudFront API: 프로그래밍 방식으로 캐시 무효화를 관리해야 하는 경우, CloudFront API를 직접 호출하는 방법을 고려할 수 있습니다. 이를 통해 CI/CD 파이프라인에 캐시 무효화 기능을 통합할 수 있습니다.
CloudWatch 지표 모니터링: CloudWatch를 통해 캐시 히트율, 오류율 등 CloudFront 관련 지표를 지속적으로 모니터링해야 합니다. 예상치 못한 지표 변화는 캐시 무효화 실패 또는 기타 문제를 시사할 수 있습니다.

3. 최적의 설정을 위한 모범 사례

캐시 동작 설정 최적화: TTL(Time To Live) 설정을 콘텐츠의 변경 빈도에 맞게 최적화합니다. 자주 변경되지 않는 콘텐츠는 긴 TTL을, 자주 변경되는 콘텐츠는 짧은 TTL을 설정하여 불필요한 캐시 무효화를 줄입니다.
정기적인 감사 및 테스트: 설정된 캐시 무효화 전략이 의도한 대로 작동하는지 정기적으로 감사하고 테스트해야 합니다. 실제 환경에 적용하기 전에 개발 또는 스테이징 환경에서 충분히 검증하는 것이 중요합니다. 예를 들어, 특정 경로의 캐시 무효화가 예상대로 이루어지는지 주기적으로 확인하는 자동화된 테스트를 구축해볼 수 있습니다.
오류 로깅 및 알림 설정: 캐시 무효화 실패 시 즉각적으로 인지할 수 있도록 오류 로깅 시스템을 구축하고 관련 알림을 설정해야 합니다. 이를 통해 문제 발생 시 신속하게 대응하고 해결할 수 있습니다.

이러한 전략과 모범 사례를 적용함으로써 CloudFront 캐시 무효화 실패 가능성을 현저히 줄이고, 안정적이며 효율적인 콘텐츠 전송을 보장할 수 있습니다.

지속적인 모니터링과 신속한 알람: 캐시 무효화 상태 관리의 핵심

콘텐츠 업데이트의 생명줄인 CloudFront 캐시 무효화 작업은 때때로 예상치 못한 난관에 부딪히곤 합니다. 이러한 돌발 상황을 조기에 감지하고 민첩하게 대처하기 위한 체계적인 모니터링 및 알람 시스템 구축은 선택이 아닌 필수입니다. 본 섹션에서는 캐시 무효화 상태를 실시간으로 면밀히 추적하고, 문제가 발생했을 때 즉각적인 경보를 받을 수 있는 실질적인 방안들을 심도 있게 살펴보겠습니다.

1. CloudFront 캐시 무효화 작업 현황 추적

AWS CloudWatch를 활용하면 CloudFront 캐시 무효화 작업의 진행 상황을 빈틈없이 감시할 수 있습니다. 주목해야 할 주요 지표들은 다음과 같습니다:

Invalidation Requests Succeeded: 성공적으로 완료된 캐시 무효화 요청 건수를 나타냅니다. 이 수치가 기대치에 미치지 못하거나 0에 가깝다면, 주의 깊게 살펴볼 필요가 있습니다.
Invalidation Requests Failed: 실패한 캐시 무효화 요청 건수를 집계합니다. 이 지표의 상승은 즉각적인 조사와 개입이 필요함을 명확히 알리는 신호입니다.
Invalidation Requests In Progress: 현재 처리 중인 캐시 무효화 요청 건수를 보여줍니다. 이 숫자가 비정상적으로 높게 유지된다면, 작업 지연이나 처리 큐 병목 현상을 의심해 볼 수 있습니다.

이러한 핵심 지표들을 CloudWatch 대시보드에 시각화하여 캐시 무효화 작업의 전반적인 상태를 한눈에 파악할 수 있도록 구성하는 것이 운영 효율성을 크게 높일 것입니다.

2. CloudWatch 알람을 통한 선제적 대응

단순히 현황을 지켜보는 것을 넘어, 특정 임계값을 넘어서거나 이상 패턴이 감지될 때 자동으로 알림을 받을 수 있도록 CloudWatch 알람을 정교하게 설정해야 합니다.

실패 임계값 알람: 'Invalidation Requests Failed' 지표가 일정 시간 동안 0을 초과하는 경우 즉시 알람을 발생시켜 문제 인지 시간을 최소화합니다.
진행 중 요청 과다 알람: 'Invalidation Requests In Progress' 지표가 설정된 임계값(예: 100건)을 초과하여 일정 시간 이상 지속될 경우 알람을 설정합니다. 이는 캐시 무효화 작업의 잠재적 병목 현상을 조기에 포착하는 데 효과적입니다.
성공률 저하 알람: 일정 기간 동안 'Invalidation Requests Succeeded' 지표가 예상 범위를 크게 벗어나는 경우 알람을 설정하여 잠재적 문제를 선제적으로 발견합니다.

이렇게 설정된 알람은 Amazon SNS(Simple Notification Service)와 연동하여 이메일, SMS, 또는 Slack과 같은 선호하는 채널로 즉시 전송되도록 구성해야 합니다. 이를 통해 담당 팀은 문제 발생 사실을 신속하게 인지하고, CloudFront 콘솔이나 API를 통해 세부 사항을 파악하여 즉시 문제 해결에 착수할 수 있습니다.

실무 팁: 실제 운영 환경에서는 캐시 무효화 실패율이 1%를 초과하거나, 진행 중인 요청 수가 50건 이상 10분 이상 지속될 경우 알람을 발동하도록 설정하는 것을 고려해 볼 수 있습니다. 이는 일반적인 상황과 비정상적인 상황을 구분하는 데 도움이 될 수 있습니다.

3. 로그 분석 기반의 심층 진단

CloudFront 액세스 로그 및 오류 로그를 CloudWatch Logs 또는 S3에 저장하고 면밀히 분석하는 것은 캐시 무효화 실패의 근본 원인을 규명하는 데 결정적인 역할을 합니다. 로그를 통해 특정 요청이 왜 실패했는지, 어떤 오류 메시지가 반환되었는지 등을 상세하게 추적할 수 있습니다. 이러한 귀중한 로그 데이터를 활용하여 CloudWatch Logs Insights로 복잡한 쿼리를 실행하고, 반복되는 오류 패턴을 식별하여 효과적인 문제 해결 전략을 수립할 수 있습니다.

이처럼 빈틈없는 모니터링, 자동화된 알람 시스템, 그리고 심층적인 로그 분석을 유기적으로 결합함으로써 CloudFront 캐시 무효화 프로세스의 안정성을 극대화할 수 있습니다. 이는 잠재적 문제를 사전에 예방하고, 발생 시 신속하게 대응할 수 있는 견고한 운영 기반을 마련하며, 궁극적으로 사용자 경험 향상과 서비스 가용성 유지라는 목표 달성에 크게 기여할 것입니다.

CloudFront 캐시 무효화의 중요성과 일반적인 문제점

CloudFront 캐시 무효화 실패는 다음과 같은 여러 요인으로 인해 발생할 수 있습니다:

경로 불일치: 무효화하려는 경로가 원본 서버의 실제 경로 또는 CloudFront 설정과 일치하지 않을 때 실패합니다. 와일드카드(*)를 사용하더라도 패턴 매칭 오류가 발생할 수 있으니 주의가 필요합니다.
요청 제한 초과: CloudFront는 계정별로 초당 캐시 무효화 요청 횟수에 제한을 두고 있습니다. 대규모 업데이트를 짧은 시간 안에 처리하려 할 경우, 이 제한을 초과하여 요청이 실패할 수 있습니다.
권한 부족: IAM 정책 설정이 잘못되어 캐시 무효화 작업을 수행할 적절한 권한이 없을 때도 실패로 이어집니다.
원본 서버 문제: 캐시 무효화 요청 시 CloudFront는 원본 서버와 통신합니다. 이때 원본 서버의 응답 지연이나 오류는 무효화 과정에 영향을 미칠 수 있습니다.
서비스 일시적 오류: 극히 드문 경우지만, CloudFront 서비스 자체의 일시적인 문제로 인해 캐시 무효화가 실패할 가능성도 존재합니다.

경험에서 배운 점

CloudFront 캐시 무효화 실패는 예상치 못한 상황에서 서비스 중단을 야기할 수 있습니다. 이는 단순한 설정 오류를 넘어 배포 파이프라인, 인프라 종속성, 팀 간 커뮤니케이션 문제까지 복합적으로 작용하는 경우가 많습니다. 실제 경험상, 이러한 문제의 근본 원인은 다음과 같은 몇 가지 패턴으로 귀결되었습니다.

첫째, 무효화 요청의 비동기적 특성을 간과하는 것입니다. CloudFront는 캐시 무효화 요청을 즉시 처리하지 않고 점진적으로 전파합니다. 특히 대규모 분산 환경에서는 모든 엣지 로케이션에 변경 사항이 반영되기까지 상당한 시간이 소요될 수 있습니다. 이 시간 동안 이전 버전의 콘텐츠가 사용자에게 제공될 위험이 있으며, 이는 긴급 패치나 보안 업데이트 시 심각한 문제를 야기할 수 있습니다.

둘째, 무효화 대상 경로를 부정확하게 지정하는 경우입니다. 와일드카드(`*`)를 사용한 무효화는 편리하지만, 의도치 않은 경로까지 무효화하여 예상치 못한 캐시 미스를 증가시킬 수 있습니다. 반대로, 너무 세밀하게 지정된 경로는 누락된 파일이나 변경된 리소스가 캐시에서 제거되지 못하는 결과를 초래합니다.

이러한 문제를 예방하고 신속하게 해결하기 위한 몇 가지 실무적인 교훈을 공유합니다. 첫째, 배포 시점과 캐시 무효화 시점의 명확한 동기화가 필수적입니다. CI/CD 파이프라인에 캐시 무효화 단계를 포함시키되, 무효화 요청이 완료된 후에 다음 단계를 진행하도록 구성해야 합니다. 특히, 긴급 배포 시에는 무효화 완료를 기다리는 대신, 점진적 롤아웃(Canary Deployment) 전략을 병행하여 문제 발생 시 즉각적인 롤백이 가능하도록 대비해야 합니다.

둘째, 무효화 전략을 세분화하고 충분히 테스트해야 합니다. 모든 것을 와일드카드로 무효화하기보다는, 변경된 파일의 경로를 명확히 식별하고 해당 경로만 무효화하는 것을 우선시해야 합니다. 가능하다면, 실제 배포 전 스테이징 환경에서 캐시 무효화 시뮬레이션을 수행하여 예상치 못한 영향을 미리 파악하는 것이 중요합니다.

궁극적으로, CloudFront 캐시 무효화 실패는 기술적인 문제뿐만 아니라 프로세스 및 커뮤니케이션의 개선을 요구합니다. 배포팀, 운영팀, 개발팀 간의 명확한 책임 분담과 협업 체계를 구축하는 것이 중요합니다. 캐시 무효화 실패 발생 시, 즉각적인 비상 대응 절차를 마련하고, 로그 분석을 통해 근본 원인을 파악하며, 재발 방지를 위한 자동화된 검증 및 모니터링 시스템을 강화해야 합니다. 예를 들어, 특정 경로의 캐시 히트율 변화를 지속적으로 모니터링하고, 비정상적인 변화 감지 시 알림을 발송하는 시스템을 구축하는 것이 효과적입니다. 또한, 팀원들에게 CloudFront 캐싱 동작 방식 및 무효화의 비동기적 특성에 대한 교육을 정기적으로 실시하여 잠재적인 실수 가능성을 줄이는 것이 장기적인 관점에서 중요합니다.

함께 보면 좋은 엔터프라이즈 사례

CSS로 레이어 팝업 화면 가운데 정렬하는 방법 (top·left·transform 완전 정리)

레이어 팝업 센터 정렬, 이 코드만 알면 끝 (CSS 예제 포함) 이벤트 배너나 공지사항을 띄울 때 레이어 팝업(center 정렬) 을 깔끔하게 잡는 게 생각보다 어렵습니다. 화면 크기가 변해도 가운데에 고정되고, 모바일에서도 자연스럽게 보이게 하려면 position , top , left , transform 을 정확하게 이해해야 합니다. 이 글에서는 아래 내용을 예제로 정리합니다. 레이어 팝업(center 정렬)의 기본 개념 자주 사용하는 position: absolute / fixed 정렬 방식 질문에서 주신 스타일 top: 3.25%; left: 50%; transform: translateX(-50%) 의 의미 실무에서 바로 쓰는 반응형 레이어 팝업 HTML/CSS 예제 1. 레이어 팝업(center 정렬)이란? 레이어 팝업(레이어 팝업창) 은 새 창을 띄우는 것이 아니라, 현재 페이지 위에 div 레이어를 띄워서 공지사항, 광고, 이벤트 등을 보여주는 방식을 말합니다. 검색엔진(SEO) 입장에서도 같은 페이지 안에 HTML이 존재 하기 때문에 팝업 안의 텍스트도 정상적으로 인덱싱될 수 있습니다. 즉, “레이어 팝업 센터 정렬”, “레이어 팝업 만드는 방법”과 같이 관련 키워드를 적절히 넣어주면 검색 노출에 도움이 됩니다. 2. 질문에서 주신 레이어 팝업 스타일 분석 질문에서 주신 스타일은 다음과 같습니다. <div class="layer-popup" style="width:1210px; z-index:9001; position:absolute; top:3.25%; left:50%; transform:translateX(-50%);"> 레이어 팝업 내용 <...

이 블로그 검색