Redis 메모리 폭주, Key Eviction으로 슬기롭게 대처하는 비법

AI 생성 이미지: Redis Key Eviction, 메모리 사용량 급증 상황별 대응 전략

Redis 메모리 사용량 급증, 근본 원인 분석

엔터프라이즈 환경에서 Redis는 단순한 캐시를 넘어 핵심 인프라로 자리 잡았습니다. 하지만 예상치 못한 메모리 사용량 급증은 서비스 안정성을 위협하는 주요 요인이 됩니다. Redis Key Eviction 메커니즘을 제대로 이해하고, 메모리 사용량 급증 상황별 대응 전략을 수립하기 위해서는 먼저 이러한 문제의 근본 원인을 파악하는 것이 중요합니다.

주요 원인 및 일반적 시나리오

메모리 사용량 급증은 주로 다음과 같은 시나리오에서 발생합니다.

데이터 볼륨의 비정상적 증가: 서비스 트래픽이 갑자기 폭증하거나, 대규모 배치 작업이 실행될 때, 혹은 특정 이벤트로 인해 Redis에 저장되는 데이터 양이 예상 범위를 초과하여 급증하는 경우입니다. 이러한 패턴을 사전에 인지하고 대비하지 않으면 메모리 부족으로 이어질 수 있습니다.
비효율적인 데이터 관리: TTL(Time To Live)이 설정되지 않은 키가 계속 누적되거나, 예상보다 오래 유지되는 키들로 인해 메모리 사용량이 불필요하게 증가하는 상황입니다. 애플리케이션 코드의 버그로 인한 메모리 누수 역시 점진적인 메모리 증가의 원인이 될 수 있습니다.
잘못된 데이터 구조 및 명령어 사용: 하나의 키에 수십 MB 이상의 대용량 데이터를 저장하거나, KEYS *, FLUSHALL과 같이 운영 환경에서 사용하면 안 되는 명령어를 실행하는 것은 메모리 사용량을 순간적으로 폭증시키는 주요 원인입니다.
설정 오류: maxmemory 설정이 없거나 과도하게 높게 설정된 경우, Redis는 시스템 메모리를 모두 소진할 때까지 데이터를 계속 쌓아 올리게 됩니다. 이는 곧 시스템 전체의 불안정으로 이어질 수 있습니다.

이처럼 다양한 원인으로 인해 Redis 메모리 사용량이 급증할 수 있으며, 각 상황에 맞는 깊이 있는 이해와 체계적인 대비가 필요합니다. 예를 들어, 예상치 못한 트래픽 증가 시에는 동적으로 스케일링 가능한 아키텍처를 고려하거나, 비효율적인 데이터 관리가 문제라면 주기적인 키 감사 및 정리 프로세스를 도입하는 것을 검토해 볼 수 있습니다.

Redis Key Eviction의 작동 원리 깊이 파헤치기

Redis는 메모리 기반 데이터 스토어로서, 제한된 메모리 자원을 효율적으로 관리하는 것이 매우 중요합니다. 만약 메모리 사용량이 미리 설정된 임계값을 넘어서면, Redis는 더 이상 새로운 데이터를 저장할 수 없게 됩니다. 이러한 예기치 못한 상황을 방지하기 위해 Redis는 'Key Eviction'이라는 핵심 메커니즘을 활용합니다. 이 기능은 메모리가 부족해질 때 자동으로 오래되었거나 덜 사용된 키를 삭제하여, 새로운 데이터를 위한 공간을 확보해 줍니다.

Redis의 Key Eviction은 다양한 정책(Eviction Policy)을 통해 그 역할을 수행합니다. 각 정책은 메모리 압박 시 어떤 키를 우선적으로 제거할지에 대한 명확한 기준을 제시합니다. 따라서 여러분의 애플리케이션 특성과 데이터 접근 패턴을 면밀히 분석하여 가장 적합한 정책을 선택하는 것이 핵심입니다. 주요 Eviction Policy는 다음과 같습니다.

noeviction: 메모리가 꽉 찼을 때 새로운 쓰기 요청을 거부합니다. 데이터 유실을 막을 수는 있지만, 서비스 중단으로 이어질 위험이 있습니다.
allkeys-lru: 모든 키 중에서 가장 오랫동안 사용되지 않은(Least Recently Used, LRU) 키를 제거합니다. 많은 경우에 가장 적합한 정책으로 선택됩니다.
volatile-lru: 만료(expire) 시간이 설정된 키 중에서 가장 최근에 사용되지 않은 키를 우선적으로 삭제합니다.
allkeys-random: 저장된 모든 키 중에서 무작위로 하나를 선택하여 삭제합니다.
volatile-random: 만료 시간이 설정된 키들 중에서 무작위로 하나를 선택하여 삭제합니다.
volatile-ttl: 만료 시간이 설정된 키들 중에서 만료까지 남은 시간이 가장 짧은 키를 먼저 삭제합니다.
allkeys-lfu: 모든 키 중에서 사용 빈도가 가장 낮은(Least Frequently Used, LFU) 키를 제거합니다.
volatile-lfu: 만료 시간이 설정된 키들 중에서 사용 빈도가 가장 낮은 키를 삭제합니다.

이러한 Eviction Policy는 Redis 설정 파일(`redis.conf`) 내의 `maxmemory-policy` 지시어를 통해 간편하게 설정할 수 있습니다. 예를 들어, LRU 정책을 적용하고 싶다면 다음과 같이 설정하면 됩니다.

 maxmemory-policy allkeys-lru

더불어, Redis는 `maxmemory` 설정을 통해 서버가 사용할 수 있는 메모리 총량을 엄격하게 제한할 수 있습니다. 이 상한선에 도달하면, 앞서 설정한 `maxmemory-policy`에 따라 자동으로 키 삭제 프로세스가 시작됩니다. `maxmemory` 값은 Redis 서버가 점유할 수 있는 최대 메모리 양을 바이트 단위로 지정하며, 0으로 설정할 경우 메모리 사용량에 제한이 없습니다(운영체제의 메모리 제약에 따름).

결론적으로, Key Eviction 기능은 Redis의 안정적인 운영을 위한 필수 불가결한 요소입니다. 각 Eviction Policy의 작동 방식을 정확히 이해하고, 여러분의 애플리케이션이 요구하는 바에 가장 부합하는 정책을 신중하게 선택함으로써, 예상치 못한 메모리 사용량 급증 상황에서도 효과적으로 시스템을 관리할 수 있습니다. 예를 들어, 자주 사용되지만 만료될 키가 많은 경우 `volatile-lru` 또는 `volatile-lfu` 정책을 고려해 볼 수 있습니다.

실전! 메모리 급증 상황별 Eviction 기반 대응 전략

Redis 메모리 사용량이 예기치 않게 급증하면 운영 중인 서비스에 심각한 장애가 발생할 수 있습니다. 이러한 비상 상황에서 Key Eviction 정책은 메모리 사용량을 효과적으로 제어하고 서비스 연속성을 확보하는 강력한 도구입니다. 본 섹션에서는 단기 및 중장기적 관점에서 Eviction 설정을 활용한 실질적인 대응 전략을 제시합니다.

단기적 대응: 즉각적인 메모리 압박 해소

메모리 사용량이 급증하여 서비스 장애가 임박한 경우, 가장 시급한 것은 즉각적으로 메모리 사용량을 줄이는 것입니다. 이때 maxmemory-policy 설정을 volatile-lru, allkeys-lru 또는 volatile-ttl과 같이 가장 오래되거나 만료될 키를 우선적으로 제거하는 정책으로 변경하는 것을 고려할 수 있습니다. 예를 들어, volatile-lru는 만료 시간이 설정된 키 중에서 가장 오래 사용되지 않은 키를 제거하여, 중요도가 낮은 캐시 데이터를 우선적으로 정리하는 효과를 볼 수 있습니다. 만약 모든 키가 중요하고 즉각적인 제거가 필요하다면 allkeys-lru를 사용하여 전체 키 공간에서 LRU(Least Recently Used) 알고리즘에 따라 키를 제거합니다. 이는 급박한 상황에서 시스템 안정성을 확보하기 위한 임시방편으로 유용합니다.

중장기적 대응: Eviction 정책 최적화 및 설계

단기적인 위기 극복 후에는 근본적인 문제 해결과 재발 방지를 위한 중장기적인 Eviction 전략 수립이 필수적입니다. 서비스의 특성과 데이터의 중요도를 고려하여 적절한 maxmemory-policy를 선택하고, maxmemory 값을 현실적으로 설정해야 합니다.

데이터 중요도 기반 정책 선택:
- volatile-lru / volatile-ttl: 만료 시간이 설정된 데이터가 캐시 목적이라면 이 정책들이 유용합니다. 중요도가 높은 영구 데이터와 캐시 데이터를 분리하여 관리할 수 있습니다.
- allkeys-lru / allkeys-random: 모든 키가 동등하게 중요하거나, 데이터의 중요도를 명확히 구분하기 어려운 경우에 사용됩니다. LRU는 최근 사용된 데이터를 보존하는 데 유리하며, RANDOM은 구현이 간단합니다.
- noeviction: 메모리 부족 시 쓰기 작업을 차단하여 데이터 유실을 방지하지만, 서비스 가용성에 직접적인 영향을 미칩니다. 데이터 유실이 절대적으로 용납되지 않는 경우에만 신중하게 고려해야 합니다.
maxmemory 설정의 현실화: Redis 인스턴스에 할당된 물리 메모리, 운영체제 및 기타 프로세스가 사용하는 메모리를 고려하여 maxmemory 값을 설정해야 합니다. 일반적으로 물리 메모리의 75%~80% 수준으로 설정하고, 충분한 여유 공간을 확보하는 것이 좋습니다.
데이터 모델링 및 TTL 관리: 캐시 데이터의 경우, 적절한 TTL(Time To Live)을 설정하여 수명이 다한 데이터가 자동으로 제거되도록 하는 것이 Eviction 부담을 줄이는 가장 효과적인 방법 중 하나입니다. 또한, 자주 사용되지 않는 대규모 데이터를 Redis에 저장하는 것을 지양하고, 필요하다면 다른 스토리지 솔루션을 함께 고려하는 것이 좋습니다. 이를 통해 Redis Key Eviction의 부하를 줄이고 메모리 사용량 급증 상황별 대응 전략을 더욱 견고하게 만들 수 있습니다.

이러한 Eviction 기반 전략들을 통해 Redis 메모리 폭주 상황에 슬기롭게 대처하고, 안정적인 서비스 운영 환경을 구축할 수 있습니다.

Redis Key Eviction Policy, 최적의 선택은?

예상치 못한 Redis 메모리 사용량 급증 상황에 직면했을 때, Key Eviction은 귀중한 메모리 자원을 효율적으로 관리하기 위한 핵심 전략입니다. 하지만 어떤 Eviction Policy가 애플리케이션의 특성과 데이터 접근 패턴에 가장 적합한지는 신중하게 판단해야 합니다. 각 Policy의 특성을 명확히 이해하고, 이를 바탕으로 최적의 Policy를 선정하는 것이 Redis의 안정적인 운영과 최상의 성능을 유지하는 데 결정적인 역할을 합니다.

Redis는 기본적으로 volatile-lru Policy를 사용합니다. 이 설정은 TTL(Time To Live)이 있는 키 중에서 가장 오랫동안 사용되지 않은(Least Recently Used, LRU) 키를 우선적으로 제거합니다. 만약 모든 키에 TTL이 설정되어 있지 않다면, 이 Policy는 실질적으로 아무런 Eviction도 수행하지 않아 메모리 사용량이 통제 불능 상태에 빠질 위험이 있습니다. 따라서 TTL 설정 여부와 데이터의 중요도를 면밀히 검토하여 Policy를 결정해야 합니다.

주요 Eviction Policy별 특징 및 선택 가이드라인

noeviction: 메모리가 가득 찼을 때 새로운 데이터를 추가하려는 시도를 오류로 처리합니다. 데이터 손실을 단 1%도 용납할 수 없는 금융 거래 시스템이나 핵심 데이터 저장소처럼, 메모리 부족으로 인한 서비스 중단이 더 심각한 영향을 미치는 환경에 적합합니다. 단, 이 경우 메모리 부족 상황에 대비한 별도의 대응 계획(예: 주기적인 데이터 정리, 샤딩 적용 등)이 반드시 수립되어야 합니다.
allkeys-lru: TTL 설정에 관계없이 모든 키를 대상으로 가장 오랫동안 사용되지 않은 키를 제거합니다. 자주 사용되지 않는 캐시 데이터가 많고, 모든 데이터의 중요도가 거의 동일하다고 판단될 때 유용합니다. 예를 들어, 웹 페이지 캐싱이나 API 응답 캐싱과 같은 시나리오에 효과적으로 적용할 수 있습니다.
volatile-lru: TTL이 설정된 키 중에서 가장 오랫동안 사용되지 않은 키를 제거합니다. 데이터의 유효 기간을 TTL로 관리하면서도, 만료되지 않은 중요한 데이터는 최대한 오래 보존해야 하는 상황에 적합합니다. 사용 빈도는 낮지만 중요한 세션 정보나 임시 데이터를 저장하는 데 활용될 수 있습니다.
allkeys-random: TTL 설정 여부와 무관하게 모든 키 중에서 무작위로 키를 선택하여 제거합니다. 데이터 접근 패턴이 불규칙하거나 LRU 알고리즘이 야기하는 오버헤드를 최소화하고 싶을 때 고려해볼 수 있습니다. 하지만 중요한 데이터가 무작위로 제거될 수 있는 위험이 존재하므로, 신중한 적용이 필요합니다.
volatile-random: TTL이 설정된 키 중에서 무작위로 키를 제거합니다. volatile-lru와 유사한 목적을 가지지만, LRU 대신 무작위 방식을 사용합니다.
volatile-ttl: TTL이 설정된 키 중에서 TTL 값이 가장 짧은, 즉 가장 먼저 만료될 키를 우선적으로 제거합니다. 데이터의 만료 시간을 엄격하게 제어해야 하는 애플리케이션에 유용합니다.
allkeys-lfu: TTL 설정 여부에 관계없이 모든 키 중 가장 사용 빈도가 낮은(Least Frequently Used, LFU) 키를 제거합니다. 특정 키가 자주 접근되더라도, 전체적으로 사용 빈도가 낮은 키를 우선적으로 정리하여 메모리 사용량을 최적화하고자 할 때 효과적입니다.
volatile-lfu: TTL이 설정된 키 중에서 가장 사용 빈도가 낮은 키를 제거합니다.

애플리케이션의 데이터 특성, 중요도, 접근 빈도, 그리고 TTL 설정 여부를 종합적으로 고려하여 최적의 Eviction Policy를 선택하는 것이 Redis의 안정적인 운영을 위한 핵심입니다. 운영 환경에 Policy를 변경할 때는 서비스에 미칠 수 있는 잠재적 영향을 충분히 고려하여, 철저한 테스트를 거친 후에 적용하는 것을 강력히 권장합니다. 예를 들어, 캐시 데이터의 중요도가 높은 서비스라면 allkeys-lfu나 volatile-lfu를 신중하게 검토해볼 수 있습니다.

메모리 모니터링과 Redis Key Eviction 튜닝으로 안정성 확보하기

예상치 못한 메모리 사용량 급증 상황에 효과적으로 대처하고 서비스의 안정성을 유지하려면, Redis의 메모리 사용 추이를 면밀히 살피고 Redis Key Eviction 정책을 서비스 환경에 맞게 최적화하는 것이 무엇보다 중요합니다. 이러한 노력을 통해 예측 불가능한 메모리 관련 문제를 사전에 예방하고 신속하게 해결할 수 있습니다.

주요 모니터링 지표와 Eviction 정책 제대로 이해하기

Redis의 메모리 상태를 정확히 파악하는 데 도움이 되는 핵심 지표들은 다음과 같습니다:

used_memory: 현재 Redis가 사용하고 있는 총 메모리 용량입니다. 이 값을 maxmemory 설정값과 비교하면 메모리가 얼마나 찼는지 대략적으로 파악할 수 있습니다.
used_memory_rss: Redis 프로세스가 운영체제로부터 실제로 할당받은 메모리 양입니다. used_memory와의 차이는 메모리 단편화 정도를 짐작하게 해줍니다.
evictedkeys: Eviction 정책에 따라 제거된 키의 개수입니다. 이 수치가 꾸준히 늘어난다면 Redis 메모리에 상당한 압박이 가해지고 있다는 신호입니다.

maxmemory-policy 설정은 메모리가 부족해졌을 때 어떤 키를 먼저 내보낼지 결정하는 규칙입니다. 대표적인 정책들은 다음과 같습니다:

noeviction (기본값): 메모리가 꽉 차면 더 이상 새로운 데이터를 저장할 수 없게 되어 쓰기 작업이 실패합니다. 데이터 자체는 사라지지 않지만, 서비스 장애로 이어질 가능성이 있습니다.
allkeys-lru: 가장 오랫동안 사용되지 않은 키부터 제거합니다. 일반적인 캐시 용도로 사용할 때 유용합니다.
volatile-lru: 만료 시간이 설정된 키 중에서 가장 오랫동안 사용되지 않은 키를 제거합니다. 중요한 데이터를 보호하면서 메모리를 관리하는 데 효과적입니다.

실질적인 튜닝 전략과 효과적인 대응 방안

Redis 메모리 사용량이 갑자기 늘어나는 상황에서는, Redis Key Eviction 설정을 각 서비스의 특성에 맞게 세심하게 조정하는 것이 메모리 사용량 급증 상황별 대응 전략의 핵심입니다. maxmemory는 전체 시스템 메모리의 75~80% 수준으로 설정하여 운영체제가 안정적으로 작동할 여유 공간을 확보하는 것이 좋습니다. 또한, LRU 알고리즘만으로는 중요한 데이터를 완벽히 보호하기 어려울 수 있으므로, volatile-lru 정책을 활용하거나 개별 키에 TTL(Time To Live) 설정을 적용하여 중요한 데이터는 반드시 보호해야 합니다. 더 나아가, 데이터 접근 패턴을 면밀히 분석하여 Eviction 정책을 정기적으로 재검토하고 필요에 따라 수정하는 과정이 필수적입니다. 이러한 Redis Key Eviction 전략을 체계적으로 수립하고 실행함으로써 서비스의 안정성을 지속적으로 유지할 수 있습니다. 예를 들어, 사용자 세션 정보와 같이 빈번하게 접근되지만 중요도가 낮은 데이터는 allkeys-lru 정책으로 관리하고, 상품 재고 정보와 같이 민감한 데이터는 TTL을 짧게 설정하거나 별도의 저장소에 두는 방안을 고려해볼 수 있습니다.

Eviction 외 추가적인 메모리 관리 기법

Redis 메모리 폭주 상황에서 Key Eviction은 가장 직접적인 해결책이지만, 근본적인 메모리 사용량 증가를 관리하고 잠재적인 문제를 예방하기 위해서는 Eviction 외에도 다양한 기법을 고려해야 합니다. 메모리 단편화와 커넥션 관리는 Redis 성능 및 안정성에 큰 영향을 미치는 요소들입니다.

메모리 단편화는 Redis가 데이터를 저장하고 삭제하는 과정에서 발생하는 현상으로, 할당된 메모리 공간 중 실제 사용되지 않는 작은 조각들이 많이 생겨나는 것을 의미합니다. 이는 실제 데이터 크기보다 더 많은 메모리를 점유하게 만들어 메모리 효율성을 떨어뜨립니다. 메모리 단편화가 심화되면 Eviction 정책이 제대로 작동하지 않거나, 예상치 못한 OOM(Out Of Memory) 에러가 발생할 수 있습니다. 메모리 단편화를 완화하기 위한 몇 가지 전략은 다음과 같습니다.

Redis 재시작 (Restart): 가장 확실하지만 서비스 중단이 발생합니다. 주기적으로 재시작하여 메모리 단편화를 해소할 수 있습니다.
redis-cli --bigkeys 활용: 메모리를 많이 차지하는 키들을 식별하여 최적화 대상 선정에 도움을 받을 수 있습니다.
데이터 구조 최적화: 불필요하게 큰 데이터 구조(예: 너무 많은 필드를 가진 해시)를 사용하지 않도록 코드를 검토하고 최적화합니다.
maxmemory-policy 재검토: 단순히 LRU/LFU 외에 ALLKEYS-RANDOM 등을 고려하여, 특정 키가 과도하게 메모리를 점유하는 상황을 방지할 수 있습니다.

커넥션 관리 또한 중요한 고려 사항입니다. Redis는 클라이언트와의 TCP 커넥션을 통해 통신하므로, 관리되지 않는 커넥션은 메모리 누수 및 성능 저하의 원인이 될 수 있습니다. 너무 많은 동시 커넥션은 Redis 서버 자체의 리소스를 소모시키고, 응답 지연을 유발할 수 있습니다.

maxclients 설정: Redis 설정 파일에서 `maxclients` 값을 적절하게 설정하여 동시 연결 수를 제한합니다. 이 값을 초과하는 연결 요청은 거부됩니다.
클라이언트 측 커넥션 풀링: 애플리케이션 단에서 커넥션 풀링을 사용하여 불필요한 커넥션 생성 및 해제를 줄이고, 재사용 가능한 커넥션을 효율적으로 관리합니다.
커넥션 타임아웃 설정: `tcp-keepalive`와 같은 설정을 통해 비활성 커넥션을 자동으로 정리하여 리소스 낭비를 막습니다.

이 외에도 Redis의 Lua 스크립트 사용 시 주의, 트랜잭션 관리, RDB/AOF 백업 전략 수립 등 다양한 측면에서 메모리 사용량을 관리하고 잠재적 위험을 줄여나가야 합니다. 이러한 추가적인 기법들을 Eviction 정책과 함께 종합적으로 고려할 때, Redis 메모리 폭주 상황에 더욱 효과적으로 대처하고 안정적인 서비스를 유지할 수 있습니다.

경험에서 배운 점

Redis 메모리 폭주 상황에서 Key Eviction은 마치 응급실의 triage와 같습니다. 모든 요청을 처리할 수 없을 때, 어떤 데이터를 먼저 희생시킬지 결정하는 것은 서비스의 생존율을 높이는 핵심입니다. 저희 팀에서 겪었던 가장 흔한 실수는 volatile-lru나 allkeys-lru와 같이 단순히 LRU(Least Recently Used) 알고리즘에만 의존하는 것이었습니다. 하지만 실제 운영 환경에서는 특정 중요 데이터가 실수로 eviction 대상이 되어 서비스 장애로 이어지는 경우가 빈번했습니다. 특히 캐시 데이터 중에서도 자주 사용되지만, eviction 정책에 따라 사라지면 안 되는 핵심 데이터를 구분하지 못했던 것이 큰 실수였습니다.

이러한 상황 재발을 방지하기 위해 저희는 다음과 같은 전략을 다각도로 적용했습니다. 우선, volatile-ttl 정책을 적극적으로 활용했습니다. 중요 데이터를 제외한 나머지 데이터에는 TTL(Time To Live)을 설정하여, 만료 시 자동으로 삭제되도록 유도했습니다. 또한, volatile-lfu (Least Frequently Used)와 같이 사용 빈도를 고려하는 eviction 정책을 일부 도입했습니다. 이는 LRU 정책만 사용했을 때 발생할 수 있는, 한동안 사용되지 않았지만 중요한 데이터가 먼저 삭제되는 비효율성을 개선하는 데 효과적이었습니다. 결론적으로, eviction 정책은 서비스의 특성과 데이터의 중요도를 면밀히 고려하여 신중하게 결정해야 하며, 주기적인 모니터링을 통해 eviction 비율과 대상 데이터를 파악하는 것이 필수적입니다.

무엇보다 중요한 교훈은 eviction 정책이 '만능 해결사'가 아니라는 점입니다. eviction은 메모리 부족 상황에 대한 '응급 처치'일 뿐, 근본적인 해결책은 아닙니다. 따라서 메모리 사용량 급증의 원인을 철저히 파악하고, 불필요한 데이터 생성을 줄이거나 데이터 모델을 최적화하는 노력이 병행되어야 합니다. 예를 들어, 불필요한 대량 데이터 삽입 트래픽을 차단하거나, Redis 인스턴스의 샤딩(Sharding) 또는 클러스터링(Clustering)을 통해 수평 확장을 고려하는 것이 장기적인 안정성을 확보하는 길입니다. 더 나아가, eviction 설정은 서비스의 SLA(Service Level Agreement)와 데이터 중요도에 따라 동적으로 조정될 수 있도록 자동화된 모니터링 및 알림 시스템을 구축하는 것도 좋은 방법입니다.

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

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

이 블로그 검색