Nginx CORS 에러, 원인부터 해결까지: 실전 점검 가이드

AI 생성 이미지: Nginx에서 CORS 에러 발생 시, 설정 점검 및 해결 사례

CORS, 왜 문제될까? Nginx에서 발생하는 주요 원인 분석

웹 애플리케이션 개발 시 'CORS' 에러는 흔히 마주치는 난관입니다. CORS(Cross-Origin Resource Sharing)는 브라우저의 기본 보안 정책인 '동일 출처 정책(Same-Origin Policy)'을 유연하게 적용하여, 서로 다른 출처(프로토콜, 도메인, 포트가 다른 경우) 간의 리소스 접근을 허용하는 기술입니다.

Nginx는 웹 서버, 리버스 프록시 등 다방면으로 서비스 성능을 최적화하지만, Nginx에서 CORS 에러가 발생할 경우에는 설정 점검이 필수적입니다. 이러한 에러는 주로 클라이언트(브라우저)가 서버로부터 예상과 다른 응답을 받을 때 발생합니다. Nginx에서 CORS 에러가 발생하는 주요 원인은 다음과 같습니다.

부적절한 CORS 헤더 설정: 서버 응답에 Access-Control-Allow-Origin, Access-Control-Allow-Methods와 같은 필수 CORS 헤더가 누락되었거나 잘못 구성된 경우입니다. Nginx 설정 파일에 이를 명시적으로 추가해야 합니다.
Nginx 리버스 프록시 설정의 누락: Nginx가 백엔드 서버로 요청을 전달하는 과정에서 CORS 헤더가 변조되거나 누락될 수 있습니다. 백엔드에서 CORS를 처리하도록 구성했다면, Nginx가 해당 헤더를 그대로 전달하도록 설정하는 것이 중요합니다.
Preflight 요청에 대한 미흡한 처리: PUT, DELETE와 같이 복잡한 HTTP 메소드를 사용하거나 사용자 정의 헤더를 추가하는 경우, 브라우저는 먼저 OPTIONS 메소드를 이용한 Preflight 요청을 보냅니다. Nginx가 이 요청에 대해 CORS 헤더를 포함한 올바른 응답을 제공하지 않으면 에러가 발생할 수 있습니다.

이처럼 다양한 원인으로 인해 Nginx에서 CORS 에러가 발생하면 사용자 경험 저하와 서비스 안정성에 문제가 생길 수 있습니다. 따라서 Nginx 설정과 백엔드 연동 부분을 꼼꼼하게 점검하는 것이 중요합니다. 예를 들어, Nginx 설정 파일에서 다음과 같이 특정 경로에 대한 CORS 헤더를 명시적으로 추가하는 것이 한 가지 해결책이 될 수 있습니다.

 location /api/ {     add_header 'Access-Control-Allow-Origin' '*';     add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';     add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';     add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';      if ($request_method = 'OPTIONS') {         return 204;     }     # ... backend proxy settings ... }

Nginx CORS 설정, 무엇을 봐야 할까?

Nginx에서 CORS(Cross-Origin Resource Sharing) 에러가 발생했을 때, 문제의 원인을 파악하고 해결하기 위해 가장 먼저 점검해야 할 부분은 Nginx 설정 파일 내 CORS 관련 지시어입니다. 이 지시어들은 HTTP 응답 헤더에 특정 값을 추가하여, 브라우저가 다른 출처(origin)에서의 리소스 접근을 허용할지 여부를 결정하는 역할을 합니다.

Nginx CORS 관련 주요 지시어 점검

Nginx 설정에서 CORS 관련 핵심 지시어는 주로 add_header를 통해 관리됩니다. 이 지시어는 클라이언트에게 응답할 때 특정 HTTP 헤더를 추가하도록 설정하며, CORS 정책을 정의하는 데 필수적입니다. 주요 설정 항목은 다음과 같습니다:

Access-Control-Allow-Origin: 허용할 출처(origin)를 지정합니다. 모든 출처를 허용하려면 *를, 특정 출처만 허용하려면 해당 URL을 명시합니다. (예: add_header 'Access-Control-Allow-Origin' '*';)
Access-Control-Allow-Methods: 허용할 HTTP 메서드(GET, POST, OPTIONS 등)를 지정합니다. (예: add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';)
Access-Control-Allow-Headers: 클라이언트가 요청 시 보낼 수 있는 HTTP 헤더를 지정합니다. (예: add_header 'Access-Control-Allow-Headers' 'Content-Type,Authorization';)
Access-Control-Allow-Credentials: 쿠키나 인증 헤더와 같은 자격 증명을 포함한 요청을 허용할지 여부를 설정합니다. true로 설정하면 가능합니다.
Access-Control-Max-Age: 사전 요청(preflight request) 응답의 캐시 시간을 초 단위로 지정합니다.

이러한 add_header 지시어들은 http, server 또는 특정 location 블록 내에 위치할 수 있습니다. CORS 정책을 특정 API 엔드포인트에만 적용하려면 해당 location 블록에만 설정하는 것이 효율적입니다. 또한, 복잡한 CORS 요청의 경우 브라우저는 OPTIONS 메서드를 사용하는 사전 요청을 보내므로, 이에 대한 적절한 응답 처리가 중요합니다. 예를 들어, /api/ 경로에 대한 CORS 설정을 다음과 같이 구성할 수 있습니다.

 location /api/ {     if ($request_method = 'OPTIONS') {         add_header 'Access-Control-Allow-Origin' 'https://frontend.example.com';         add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';         add_header 'Access-Control-Allow-Headers' 'Content-Type,Authorization';         return 204; # No Content     }     # ... 실제 요청 처리 ... }

Nginx에서 CORS 에러가 발생했을 때, 위에서 언급된 add_header 지시어들이 각 location 블록에서 올바르게 설정되었는지, 특히 Access-Control-Allow-Origin이 클라이언트의 실제 출처와 일치하는지 꼼꼼히 확인하는 것이 문제 해결의 핵심입니다. 만약 설정이 정확함에도 불구하고 문제가 지속된다면, Nginx의 에러 로그를 상세히 분석하여 추가적인 단서를 찾는 것이 좋습니다.

실전 점검 1단계: Nginx 설정 파일 검토 및 수정

엔터프라이즈 환경에서 Nginx 사용 중 CORS(Cross-Origin Resource Sharing) 에러가 발생했다면, 가장 먼저 Nginx 설정 파일을 면밀히 살펴보는 것이 중요합니다. 설정 오류는 CORS 관련 문제의 흔한 원인이며, 몇 가지 핵심 설정을 바로잡는 것만으로도 문제가 해결되는 경우가 많습니다. 이는 Nginx에서 CORS 에러 발생 시, 설정 점검 및 해결 사례를 찾는 데 있어 첫걸음이 됩니다.

1. CORS 관련 헤더 설정 확인

Nginx가 CORS 요청을 올바르게 처리하려면, 클라이언트에게 필수적인 CORS 관련 HTTP 헤더를 응답에 포함시켜야 합니다. 특히 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 헤더의 정확한 설정이 중요합니다.

자주 발생하는 설정 오류:

Access-Control-Allow-Origin 헤더가 누락되거나, 허용되지 않은 도메인으로 잘못 설정된 경우.
클라이언트 요청에 사용된 HTTP 메소드(예: PUT, DELETE)를 서버에서 허용하지 않아 발생하는 헤더 누락.
클라이언트에서 전송하는 특정 헤더(예: Authorization)를 서버에서 인지하지 못하는 경우.

권장 설정 예시 (nginx.conf 또는 해당 server 블록 내 location 블록):

 location / {     # ... 기타 설정 ...      add_header 'Access-Control-Allow-Origin' '*' always; # 프로덕션 환경에서는 특정 도메인 지정 권장     add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;     add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept, Authorization' always;     add_header 'Access-Control-Max-Age' '1728000' always; # Preflight 요청 캐싱 시간      # OPTIONS 메서드에 대한 Preflight 요청 처리     if ($request_method = 'OPTIONS') {         add_header 'Access-Control-Allow-Origin' '*' always;         add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;         add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept, Authorization' always;         add_header 'Access-Control-Max-Age' '1728000' always;         return 204; # No Content 응답으로 Preflight 요청 완료     }      # ... 프록시 설정 등 ... }

설정 시 유의사항:

보안 강화를 위해 Access-Control-Allow-Origin에는 * 대신 실제 서비스 도메인을 명시하는 것이 좋습니다.
always 지시어는 해당 헤더가 모든 응답에 포함되도록 보장합니다.
OPTIONS 메서드에 대한 Preflight 요청 처리는 CORS 통신에서 매우 중요하므로 반드시 포함되어야 합니다.

2. 프록시 설정 및 헤더 전달 확인

Nginx를 리버스 프록시로 사용하여 백엔드 서버로 요청을 전달하는 경우, 프록시 설정 자체에 문제가 없는지 확인해야 합니다. 특히 필요한 HTTP 헤더가 백엔드 서버로 올바르게 전달되는지 점검해야 합니다.

흔히 발생하는 설정 문제:

proxy_pass 설정 경로가 잘못되어 요청이 백엔드 서버에 전혀 도달하지 못하는 경우.
proxy_set_header 지시어를 통해 필수 헤더(예: Host, X-Forwarded-For)를 백엔드 서버로 전달하지 않아 발생하는 문제.

일반적인 프록시 설정 예시 (proxy_pass 사용 시):

 location /api/ {     proxy_pass http://your_backend_server/;     proxy_set_header Host $host;     proxy_set_header X-Real-IP $remote_addr;     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;     proxy_set_header X-Forwarded-Proto $scheme;      # 만약 백엔드 서버에서 CORS 헤더를 직접 관리한다면, Nginx에서의 CORS 헤더 설정은 불필요할 수 있습니다.     # 하지만 Nginx 단에서 CORS 정책을 일관되게 관리하고 싶다면, 위 1번의 헤더 설정을 함께 적용해야 합니다. }

Nginx 설정 파일 수정 후에는 반드시 nginx -t 명령어로 구문 오류를 검증하고, systemctl reload nginx 또는 service nginx reload 명령으로 설정을 적용해야 변경 사항이 시스템에 반영됩니다. 이 과정을 통해 Nginx에서 CORS 에러 발생 시 문제를 효과적으로 진단하고 해결할 수 있습니다.

실전 점검 2단계: 클라이언트 측 CORS 설정 점검

Nginx 서버 설정을 면밀히 검토했음에도 CORS 에러가 계속 발생한다면, 이제 클라이언트 측 설정을 세심하게 살펴볼 때입니다. 브라우저의 보안 정책으로 인해 발생하는 CORS 문제는 서버 설정뿐만 아니라 클라이언트 코드의 잘못된 설정에서도 비롯될 수 있습니다. 이 단계에서는 브라우저 개발자 도구를 적극 활용하여 CORS 에러 메시지를 분석하고, 클라이언트 측 JavaScript 코드에서 발생할 수 있는 잠재적 문제점을 진단하는 데 집중합니다. Nginx에서 CORS 에러 발생 시, 클라이언트 코드 점검은 필수입니다.

1. 브라우저 개발자 도구 활용

네트워크 탭: 개발자 도구(F12)의 '네트워크' 탭에서 문제가 되는 API 요청을 찾아 응답 헤더를 확인합니다. Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등 CORS 관련 헤더가 올바르게 설정되었는지, 혹은 누락되지는 않았는지 면밀히 검토해야 합니다. 특히 Access-Control-Allow-Origin 헤더에 허용되지 않은 출처가 명시되어 있거나, 특정 출처만 제한적으로 허용된 경우를 주의 깊게 살펴봐야 합니다.
콘솔 탭: '콘솔' 탭에는 CORS 에러에 대한 구체적인 메시지가 출력됩니다. 예를 들어, "Access to fetch at '...' from origin '...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource."와 같은 메시지는 서버 응답에 필수 CORS 헤더가 누락되었음을 명확히 알려줍니다. 또한, 허용된 HTTP 메소드와 요청된 메소드 간의 불일치를 나타내는 메시지도 주의 깊게 분석해야 합니다.

2. 클라이언트 측 JavaScript 코드 점검

Origin 및 HTTP 메소드/헤더: 클라이언트에서 API 요청 시 Origin 헤더가 올바르게 전송되는지 확인합니다. 더불어, 요청하는 HTTP 메소드(GET, POST, PUT 등)와 추가 헤더(Content-Type, Authorization 등)가 서버에서 허용하는 설정과 일치하는지 점검해야 합니다. '사전 요청(Preflight Request)'이 필요한 메소드를 사용할 경우, 클라이언트 코드에서 OPTIONS 메소드로 사전 요청을 보내고 서버 응답을 제대로 처리하는지 확인하는 것도 중요합니다.
라이브러리/프레임워크 설정: React, Vue, Axios 등 프론트엔드 프레임워크나 HTTP 클라이언트 라이브러리를 사용할 경우, 해당 라이브러리에서 CORS 관련 설정을 별도로 관리하는 경우가 많습니다. 이러한 전역 설정이 의도치 않게 잘못 구성되어 CORS 문제를 야기할 수 있으므로 관련 설정을 꼼꼼히 점검해야 합니다.
개발 환경 프록시 설정: 로컬 개발 환경에서 다른 도메인의 백엔드 API에 접근할 때, 브라우저의 동일 출처 정책으로 인해 CORS 에러가 발생할 수 있습니다. Webpack, Vite 등 빌드 도구의 프록시 설정을 활용하여 API 요청을 백엔드 서버로 안전하게 중계함으로써 이 문제를 효과적으로 우회할 수 있습니다.

이처럼 Nginx에서 CORS 에러 발생 시, 설정 점검 및 해결 사례는 서버와 클라이언트 양쪽 모두를 포괄합니다. 브라우저 개발자 도구의 명확한 에러 메시지를 기반으로, 코드와 설정을 체계적으로 검토하는 것이 문제 해결의 핵심입니다.

특수 사례 및 고급 설정: 동적 CORS, 프록시 환경

엔터프라이즈 환경에서 Nginx CORS 에러를 마주했을 때, 본 섹션에서는 복잡하고 동적인 상황에 대한 CORS 설정 전략을 제시합니다. 클라이언트 Origin이 자주 바뀌거나, API 게이트웨이, 다중 서브도메인 환경에서 발생하는 CORS 이슈에 대한 실질적인 해결 방안을 심도 있게 다룹니다.

동적 Origin 허용 및 API 게이트웨이 환경

클라이언트 Origin이 고정적이지 않은 경우, Nginx 설정 파일에 일일이 Origin 목록을 나열하는 것은 비효율적입니다. 이런 상황에서는 리버스 프록시 서버가 Origin 헤더 정보를 받아, 백엔드에서 동적으로 허용 Origin을 결정하도록 구성하는 것이 좋습니다. Nginx는 이 헤더 정보를 그대로 전달하기만 하면 됩니다. 또한, API 게이트웨이나 여러 서브도메인이 단일 Nginx 인스턴스를 공유하는 경우, location 블록을 세밀하게 나누어 각 경로별로 CORS 정책을 차별화해야 합니다. 예를 들어, API 버전별로 Access-Control-Allow-Origin 헤더 값을 다르게 지정하는 것이 가능합니다. 다만, 보안을 위해 * 와일드카드는 지양하고, 명시적으로 특정 Origin만 허용하는 것이 강력히 권장됩니다.

실무 팁: API 게이트웨이를 사용할 때, 각 서비스별로 다른 CORS 정책이 필요한 경우, 게이트웨이 레벨에서 Access-Control-Allow-Origin 헤더를 동적으로 설정하는 로직을 구현할 수 있습니다. 예를 들어, 특정 서비스 요청에는 app.example.com을, 다른 서비스 요청에는 admin.example.com을 허용하는 식입니다.

Preflight 요청(OPTIONS)의 올바른 처리

CORS의 핵심 메커니즘인 Preflight 요청(HTTP Method: OPTIONS) 처리는 Nginx 설정에서 매우 중요합니다. OPTIONS 메서드에 대한 응답에 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Max-Age 등의 헤더를 명확히 포함시켜야 합니다. 이렇게 해야 브라우저가 실제 요청을 안전하게 전송할 수 있습니다. 복잡한 환경에서는 이러한 동적 설정과 세분화된 정책 적용이 필수적입니다. 모든 변경 사항 적용 후에는 Preflight 요청과 실제 요청을 모두 테스트하여 CORS 정책이 의도대로 작동하는지 철저히 검증해야 합니다. Nginx에서 CORS 에러 발생 시, 설정 점검 및 해결 사례를 통해 이러한 고급 설정까지 완벽하게 이해하고 적용하시기 바랍니다.

해결 후 확인 및 예방: 테스트와 모니터링

Nginx CORS 설정을 변경한 후에는 반드시 정상 작동 여부를 꼼꼼히 확인해야 합니다. 단순히 임시방편으로 해결하는 것을 넘어, 근본적인 문제 해결과 재발 방지를 위한 체계적인 테스트 및 모니터링 전략 수립이 필수적입니다. 본 섹션에서는 CORS 설정 변경 후 검증 방법과 지속적인 안정성을 확보하기 위한 모니터링 방안을 제시합니다.

1. CORS 적용 결과 검증

변경 사항을 적용한 후, 실제 애플리케이션 환경에서 CORS 관련 에러가 더 이상 발생하지 않는지 확인하는 것이 중요합니다. 다음과 같은 방법으로 검증을 진행할 수 있습니다.

다양한 브라우저 및 환경 테스트: Chrome, Firefox, Safari 등 주요 브라우저뿐만 아니라, 모바일 환경(Android, iOS)에서도 동일한 CORS 정책이 문제없이 적용되는지 테스트합니다.
실제 API 호출 테스트: 프론트엔드 애플리케이션에서 백엔드 API를 호출하는 시나리오를 재현하여, 이전과 동일하게 데이터가 정상적으로 조회 및 전송되는지 확인합니다. 특히, 다양한 HTTP 메소드(GET, POST, PUT, DELETE 등)와 헤더 값을 포함하는 요청에 대한 응답을 면밀히 살피는 것이 중요합니다.
개발자 도구 활용: 브라우저 개발자 도구의 콘솔 탭에서 CORS 관련 에러 메시지가 나타나지 않는지 지속적으로 확인합니다. 네트워크 탭에서는 각 요청의 응답 헤더에 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 올바르게 설정되어 있는지 검증합니다.

2. CORS 에러 재발 방지를 위한 모니터링 전략

CORS 설정은 간혹 예상치 못한 상황으로 인해 다시 문제가 발생할 수 있습니다. 이를 방지하기 위해 다음과 같은 모니터링 전략을 구축하는 것이 좋습니다.

Nginx 로그 분석: Nginx의 접근 로그 및 에러 로그를 주기적으로 분석하여 CORS 관련 에러 패턴을 신속하게 감지합니다. 특히, 4xx 또는 5xx 응답 코드와 함께 발생하는 특정 에러 메시지를 주의 깊게 모니터링합니다.
애플리케이션 성능 모니터링 (APM) 도구 활용: Datadog, New Relic, Prometheus와 같은 APM 도구를 사용하여 백엔드 API의 응답 상태를 실시간으로 감시합니다. CORS 에러로 인해 API 호출이 실패하는 경우, 해당 실패를 즉시 감지하고 알림을 받을 수 있도록 설정하면 문제 대응 시간을 크게 단축할 수 있습니다.
정기적인 설정 감사: Nginx 설정 파일에 대한 정기적인 감사를 통해 CORS 관련 설정이 의도치 않게 변경되었거나, 보안 취약점이 발생하지 않았는지 점검합니다. 자동화된 설정 검증 도구를 활용하는 것도 효과적인 방법입니다.
알림 시스템 구축: 위에서 언급된 모니터링 활동 중 CORS 관련 에러가 감지될 경우, 즉시 담당자에게 알림이 갈 수 있도록 Slack, 이메일 등의 알림 시스템을 구축합니다. 이를 통해 문제 발생 시 신속하게 대응하고 서비스 장애 시간을 최소화할 수 있습니다.

체계적인 테스트와 지속적인 모니터링은 Nginx CORS 에러를 효과적으로 관리하고, 안정적인 서비스 운영을 보장하는 핵심 요소입니다. 이러한 과정을 통해 개발팀은 사용자가 끊김 없이 서비스를 이용할 수 있도록 지원할 수 있습니다.

경험에서 배운 점

Nginx에서 CORS 오류를 만났을 때, 가장 먼저 의심해야 할 부분은 요청 헤더와 응답 헤더 간의 불일치입니다. 브라우저의 보안 정책으로 인해 발생하는 CORS 문제는 본질적으로 서버(Nginx)가 클라이언트(브라우저)의 요구사항을 만족시키지 못할 때 발생합니다. 따라서 Nginx 설정 파일에서 `add_header` 지시자를 통해 `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers`와 같은 CORS 관련 응답 헤더가 올바르게 구성되었는지 확인하는 것이 첫걸음입니다. 특히, 와일드카드(`*`)를 사용하거나 특정 도메인만 허용할 경우, 해당 도메인이 정확히 명시되었는지, 그리고 `OPTIONS` 메소드에 대한 응답이 제대로 처리되고 있는지를 점검하는 것이 중요합니다.

실무에서 자주 발생하는 실수는 Nginx 설정 변경 후 `nginx -t` 명령어로 문법 오류는 없음을 확인했음에도 불구하고, 실제 적용될 설정을 제대로 이해하지 못해 문제가 발생하는 경우입니다. 예를 들어, 여러 `location` 블록에 걸쳐 CORS 설정을 중복하거나 충돌되게 지정하면 예상치 못한 결과가 나타날 수 있습니다. 또한, 캐싱 문제로 인해 변경 전 설정이 계속 유효한 것처럼 보이는 혼란도 겪을 수 있습니다. 따라서 설정을 변경한 후에는 반드시 Nginx를 재시작하거나 리로드(`nginx -s reload`)해야 합니다. 이후 브라우저 캐시를 삭제하거나 시크릿 모드를 활용하여 실제 적용된 설정을 확인하는 습관을 들이는 것이 필수적입니다.

CORS 오류의 재발을 막기 위해서는 설정의 일관성을 유지하는 것이 무엇보다 중요합니다. CORS 정책은 서비스의 보안 요구사항과 직결되므로, 개발, 스테이징, 프로덕션 환경별로 서로 다른 CORS 설정을 적용해야 한다면 이를 명확하게 문서화하고 체계적으로 관리해야 합니다. 또한, 자동화된 테스트 파이프라인에 CORS 관련 검증 단계를 포함시켜 배포 전에 잠재적인 문제를 미리 발견하는 것이 좋습니다. 예를 들어, 특정 API만 CORS를 허용해야 하는 상황이라면, 해당 API의 `location` 블록에만 CORS 헤더를 추가하는 등, 꼭 필요한 최소한의 범위로만 설정을 제한하는 것이 보안 강화 측면에서도 효과적입니다.

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

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%);"> 레이어 팝업 내용 <...

이 블로그 검색