Redis 인메모리 데이터 유실 방지: 지속성 설정 완벽 가이드

AI 생성 이미지: Redis 인메모리 데이터 유실 방지를 위한 지속성 설정

Redis 인메모리 데이터의 취약점: 지속성 설정이 필수적인 이유

Redis는 탁월한 성능을 자랑하는 인메모리 데이터 저장소로, 데이터에 대한 신속한 접근을 지원합니다. 그러나 이러한 인메모리 기반 특성은 예상치 못한 서버 재시작, 시스템 오류, 혹은 전원 공급 중단 시 메모리에만 저장된 데이터가 영구적으로 유실될 수 있는 잠재적 위험을 내포합니다. 특히 엔터프라이즈 환경에서는 데이터의 무결성과 가용성이 비즈니스 연속성과 직결되므로, 이러한 인메모리 데이터 유실 가능성은 중대한 문제로 이어질 수 있습니다.

실시간 사용자 세션 정보, 금융 거래 기록, 상품 재고 현황과 같이 중요한 데이터를 Redis에 저장하는 경우, 단 한 번의 서버 다운으로도 고객에게 큰 불편을 초래하거나 막대한 금전적 손실을 입힐 수 있습니다. 따라서 Redis의 강력한 성능을 최대한 활용하면서도 데이터의 안전성을 보장하기 위해서는 지속성(Persistence) 설정을 적용하는 것이 무엇보다 중요합니다.

Redis는 데이터를 디스크에 저장하여 이러한 인메모리 데이터 유실 위험을 완화하는 두 가지 주요 지속성 메커니즘, 즉 RDB(Redis Database) 스냅샷과 AOF(Append Only File) 로깅을 제공합니다. 이 두 가지 방법을 올바르게 이해하고 구성하면, Redis는 메모리의 빠른 처리 속도를 유지하면서도 예기치 못한 상황 발생 시 데이터를 안전하게 복구할 수 있는 신뢰할 수 있는 데이터 저장소로 거듭날 수 있습니다. 다음에서는 각 지속성 메커니즘의 작동 방식과 효과적인 설정 방법에 대해 상세히 알아보겠습니다.

Redis 인메모리 데이터 유실 방지를 위한 지속성 옵션: RDB vs AOF

Redis는 탁월한 성능을 자랑하는 인메모리 데이터 저장소입니다. 하지만 예기치 못한 서비스 중단 시 발생할 수 있는 데이터 유실 위험은 늘 존재합니다. 이러한 위험을 최소화하기 위한 Redis 인메모리 데이터 유실 방지를 위한 지속성 설정은 매우 중요합니다. Redis는 RDB(Redis Database)와 AOF(Append Only File)라는 두 가지 주요 지속성 메커니즘을 통해 데이터를 안전하게 보호합니다. 각 옵션의 작동 방식과 특징을 제대로 이해하는 것이 안정적인 Redis 운영의 첫걸음입니다.

RDB: 특정 시점 스냅샷

RDB는 지정된 시점의 데이터베이스 상태를 디스크에 파일로 저장하는 방식입니다. 설정된 간격이나 특정 조건에 따라 데이터베이스 전체를 바이너리 형식으로 압축하여 스냅샷을 생성합니다. RDB는 마지막 스냅샷 이후의 변경 사항이 유실될 수 있다는 점을 염두에 두어야 합니다. 하지만 RDB 파일은 상대적으로 크기가 작고 복구 속도가 빠르다는 장점을 가지고 있어, 대규모 데이터셋의 백업 및 복구에 효과적입니다. 데이터의 완벽한 일관성보다는 빠른 복구 속도가 더 중요한 환경에서 유용하게 활용될 수 있습니다. 예를 들어, 사용자 세션 정보처럼 약간의 데이터 손실이 허용되는 경우 RDB만으로도 충분할 수 있습니다.

장점:
- 특정 시점의 데이터를 빠르고 명확하게 복구할 수 있습니다.
- 파일 크기가 작아 저장 공간 효율성이 높고 복구 속도가 빠릅니다.
- 백업 및 복제 작업에 효율적입니다.
단점:
- 마지막 스냅샷 이후의 데이터는 유실될 가능성이 있습니다.
- 스냅샷 생성 시점에 디스크 I/O 부하가 발생할 수 있습니다.

AOF: 변경 사항 기록

AOF는 Redis 서버에서 발생하는 모든 쓰기 연산 명령어를 순차적으로 로그 파일에 기록하는 방식입니다. Redis가 재시작될 때, AOF 파일에 기록된 명령어들을 다시 실행하여 데이터를 복구합니다. 이 방식은 RDB에 비해 데이터 유실 위험이 훨씬 낮으며, 거의 실시간에 가까운 데이터 복구를 가능하게 합니다. 다만, AOF 파일은 RDB 파일보다 용량이 커질 수 있고, 파일 크기가 커짐에 따라 복구 시간이 길어질 수 있습니다. 따라서 AOF 파일의 효율적인 관리를 위해 주기적인 재작성(rewrite) 작업이 권장됩니다.

장점:
- 데이터 유실 위험이 매우 낮아 높은 내구성을 제공합니다.
- 모든 쓰기 연산을 기록하여 데이터의 무결성을 강화합니다.
단점:
- RDB 파일보다 파일 크기가 훨씬 커질 수 있습니다.
- 파일 크기 증가에 따라 복구 시간이 길어질 수 있습니다.
- AOF 파일 관리를 위한 재작성 작업이 필요합니다.

Redis 인메모리 데이터 유실 방지를 위한 지속성 설정은 RDB와 AOF의 각 장단점을 면밀히 검토하고, 서비스의 특성과 복구 요구사항에 맞춰 최적의 방안을 선택하거나 두 가지를 조합하여 활용해야 합니다.

RDB 스냅샷 설정: Redis 데이터 유실 방지를 위한 지속성 확보

Redis의 RDB(Redis Database) 스냅샷은 특정 시점의 전체 데이터를 디스크에 바이너리 파일로 저장하는 방식입니다. 이는 Redis 인메모리 데이터 유실을 방지하는 핵심적인 지속성 설정으로, 서버 재시작이나 예상치 못한 종료 시에도 데이터를 안전하게 복구할 수 있도록 돕습니다. RDB 스냅샷 설정을 통해 데이터의 영속성을 확보하고 견고한 백업 전략을 수립할 수 있습니다.

RDB 스냅샷은 redis.conf 설정 파일에서 구성하거나, CONFIG SET 명령어로 동적으로 변경할 수 있습니다. 주요 설정은 다음과 같습니다.

스냅샷 자동 생성 주기: RDB 스냅샷은 설정된 조건에 따라 자동으로 생성됩니다. redis.conf 파일의 save 지시어를 사용하여 정의하며, 특정 시간 내에 일정 수 이상의 키가 변경되면 스냅샷을 저장하도록 설정합니다. 예를 들어, save 900 1은 900초(15분) 동안 1개 이상의 키가 변경되면 스냅샷을 생성하라는 의미입니다.
- save <seconds> <changes>: 지정된 시간(seconds) 동안 지정된 수(changes) 이상의 키 변경 시 스냅샷을 저장합니다.
스냅샷 파일 저장 경로 및 이름: RDB 스냅샷 파일이 저장될 디렉토리는 dir 지시어로, 파일 이름은 dbfilename 지시어로 설정합니다. 기본값은 dump.rdb이며, Redis 실행 디렉토리에 저장됩니다. 보안 및 관리 효율성을 위해 별도의 디렉토리와 고유한 파일 이름을 사용하는 것이 좋습니다.
- 예시: dir /var/lib/redis, dbfilename redis_backup.rdb

RDB 스냅샷은 설정된 주기에 따라 디스크에 데이터를 기록하므로 I/O 부하를 유발할 수 있습니다. 따라서 운영 환경에서는 스냅샷 생성 시점을 신중하게 고려하여 서비스 성능에 미치는 영향을 최소화해야 합니다. RDB는 데이터의 일관성을 보장하지만, 마지막 스냅샷 이후의 변경 사항은 유실될 수 있습니다. 이러한 점을 보완하기 위해 AOF(Append Only File)와 함께 사용하여 Redis 인메모리 데이터 유실 방지를 위한 지속성 설정을 강화하는 것이 일반적입니다. 예를 들어, 중요한 데이터를 다루는 경우, RDB 백업과 함께 AOF를 활성화하여 복구 시점 목표(RPO)를 더욱 단축할 수 있습니다.

AOF 로깅: Redis 인메모리 데이터 유실 방지를 위한 지속성 강화

Redis의 AOF(Append Only File) 로깅은 메모리에 저장된 데이터를 디스크에 꾸준히 기록하는 방식으로, Redis 인메모리 데이터 유실 방지를 위한 지속성 설정의 핵심 축을 담당합니다. 주기적인 스냅샷을 생성하는 RDB와 달리, AOF는 모든 쓰기 명령어를 순차적으로 로그 파일에 남겨두기 때문에, 장애 발생 시에도 최신 상태의 데이터를 복구할 수 있습니다. 이는 특히 트랜잭션 데이터의 무결성을 보장하는 데 매우 중요합니다.

AOF fsync 정책, 어떻게 설정해야 할까?

AOF의 데이터 안정성은 appendfsync 설정에 따라 크게 달라집니다. 이 옵션은 Redis가 디스크 쓰기 작업을 운영체제에 얼마나 자주 동기화할지 결정하며, 데이터 보호 수준과 시스템 성능 사이에서 최적의 균형점을 찾도록 돕습니다. 주요 설정 옵션은 다음과 같습니다:

always: 모든 쓰기 작업마다 fsync를 실행하여 데이터 유실 위험을 최소화합니다. 하지만 이는 디스크 I/O 부하를 가중시켜 시스템 성능에 영향을 줄 수 있습니다.
everysec: 1초에 한 번씩 fsync를 수행합니다. 대부분의 엔터프라이즈 환경에서 데이터 유실 가능성(최대 1초 분량)과 성능 간의 합리적인 절충안으로 널리 권장됩니다.
no: 동기화 주기를 운영체제의 정책에 맡깁니다. 가장 빠른 성능을 기대할 수 있지만, 예상치 못한 시스템 종료 시 상당량의 데이터가 유실될 위험이 있으므로 신중한 접근이 필요합니다.

AOF 파일 자동 재작성(Rewrite)으로 효율성 높이기

AOF 파일은 시간이 지남에 따라 모든 쓰기 연산 기록이 누적되어 파일 크기가 계속 커질 수 있습니다. 이는 불필요한 디스크 공간을 차지할 뿐만 아니라, 장애 발생 시 복구 시간도 길어지게 만듭니다. 이를 해결하기 위해 Redis는 AOF 파일 재작성 기능을 제공합니다. AOF 재작성은 현재 메모리 상태를 기반으로, 최소한의 명령만을 사용하여 데이터를 효율적으로 다시 기록함으로써 AOF 파일 크기를 최적화하는 과정입니다. 이 기능은 auto-aof-rewrite-percentage와 auto-aof-rewrite-min-size 설정을 통해 자동으로 실행되도록 구성할 수 있으며, 백그라운드에서 작동하여 Redis의 핵심 작업에 미치는 영향을 최소화합니다. 따라서 Redis 인메모리 데이터 유실 방지를 위한 지속성 설정을 구성할 때는, appendfsync 정책과 함께 자동 재작성 설정을 종합적으로 고려하여 시스템의 안정성과 성능을 최적화하는 것이 현명합니다. 예를 들어, 중요한 금융 거래 데이터를 다루는 시스템이라면 appendfsync everysec과 함께 AOF 파일 크기가 일정 수준 이상으로 커지기 전에 자동으로 재작성되도록 설정하는 것이 좋은 접근 방식입니다.

RDB와 AOF 조합: 최고의 데이터 안정성 확보 방안

Redis는 놀라운 성능을 자랑하는 인메모리 데이터베이스입니다. 하지만 휘발성 메모리에 데이터를 저장하기 때문에 예상치 못한 장애 발생 시 데이터가 사라질 위험이 항상 존재하죠. 이러한 상황에 대비하여 Redis는 RDB(Redis Database)와 AOF(Append Only File)라는 두 가지 강력한 데이터 지속성 기능을 제공합니다. 각 기능의 특징을 제대로 이해하고 효과적으로 조합한다면, 엔터프라이즈 환경에서 요구되는 견고한 수준의 데이터 안정성을 구축할 수 있습니다.

RDB (Redis Database): 시점 스냅샷으로 빠르고 가볍게

RDB는 특정 시점의 데이터베이스 상태를 디스크에 그대로 저장하는 방식입니다. 설정된 시간 간격이나 변경된 키의 개수에 따라 주기적으로 스냅샷이 생성되죠. RDB의 가장 큰 장점은 전체 데이터베이스의 복제본을 생성하기 때문에 백업 및 복구가 간편하다는 점입니다. 또한, 파일 크기가 상대적으로 작고 복구 속도가 매우 빠르다는 것도 매력적입니다. 다만, 스냅샷을 찍는 순간과 다음 스냅샷 사이의 데이터 변경분은 유실될 수 있다는 점은 염두에 두어야 합니다.

AOF (Append Only File): 모든 기록을 남겨 데이터 유실 최소화

AOF는 Redis에서 발생하는 모든 쓰기 작업을 순차적인 로그 파일 형태로 기록하는 방식입니다. Redis 서버가 재시작될 때 이 로그 파일을 다시 실행하면 데이터를 완벽하게 복구할 수 있습니다. RDB 방식에 비해 데이터 유실 가능성이 현저히 낮다는 것이 AOF의 핵심 장점입니다. 설정을 통해 모든 쓰기 작업을 즉시 디스크에 반영하거나, 일정 간격으로 동기화하여 데이터 일관성을 더욱 높일 수 있습니다. 하지만 로그 파일의 크기가 RDB보다 커질 수 있으며, 파일이 방대해질 경우 복구 시간이 길어질 수 있다는 점은 고려해야 할 부분입니다.

RDB와 AOF 조합: 빈틈없는 데이터 보호 전략

RDB와 AOF를 함께 사용하면 각 방식의 약점을 상호 보완하여 데이터 안정성을 극대화할 수 있습니다. 일반적인 권장 구성은 다음과 같습니다:

RDB: 15분 또는 1시간 간격과 같이 설정된 주기로 스냅샷을 생성하여 신속한 복구 지점을 확보하고, 이를 주요 백업 용도로 활용합니다.
AOF: 'everysec' 옵션을 활용하여 초당 한 번씩만 디스크에 동기화합니다. 이는 대부분의 경우 데이터 유실 위험을 최소화하면서도 성능 저하를 억제하는 최적의 균형점입니다.

이러한 조합은 AOF 파일이 손상되더라도 RDB 스냅샷을 통해 데이터를 복구할 수 있는 안전망을 제공합니다. 또한, RDB 스냅샷 시점 이후의 변경분은 AOF 로그를 통해 복원 가능하죠. 때로는 AOF 파일이 지나치게 커지는 것을 방지하기 위해 주기적으로 AOF 파일을 재작성(rewrite)하는 기능을 활용하는 것이 좋습니다. 이는 파일 크기를 최적화하면서도 모든 쓰기 명령을 안전하게 유지하는 효과적인 방법입니다.

엔터프라이즈 환경에서는 데이터의 중요성이 무엇보다 크므로, RDB와 AOF를 함께 구성하여 Redis 인메모리 데이터 유실 방지를 위한 지속성 설정을 강화하는 것이 서비스의 가용성과 신뢰성을 보장하는 필수적인 조치입니다. 각 설정 값은 실제 워크로드와 목표 복구 시간(RTO), 목표 복구 시점(RPO)을 고려하여 신중하게 결정해야 합니다.

실전: Redis 인메모리 데이터 유실 방지를 위한 지속성 설정 시 고려사항

Redis의 빠른 응답 속도는 인메모리 기반이라는 특성에서 비롯되지만, 이는 곧 예기치 않은 상황에서 데이터가 사라질 수 있다는 의미이기도 합니다. 이러한 휘발성을 극복하기 위해 지속성 기능을 설정하는 것은 매우 중요합니다. 하지만 무턱대고 설정하기보다는, 시스템 성능 저하나 불필요한 디스크 공간 증대와 같은 잠재적인 문제를 충분히 인지해야 합니다. 이 글에서는 엔터프라이즈 환경에서 Redis 데이터 유실을 효과적으로 방지하면서도 최적의 성능을 유지할 수 있는 지속성 설정 방법을 안내합니다.

성능과 안정성의 균형점 찾기

Redis는 데이터를 디스크에 저장하는 두 가지 주요 메커니즘, 즉 RDB 스냅샷과 AOF 로깅을 제공합니다. 각 방식은 시스템 성능에 다른 영향을 미치므로, 운영 중인 환경의 특성을 면밀히 분석하여 최적의 설정을 도출해야 합니다.

RDB 스냅샷: 주기적으로 전체 데이터셋을 파일로 저장하는 RDB는 디스크 I/O 부하를 발생시킬 수 있습니다. 특히 데이터 양이 많거나 스냅샷 빈도를 높일 경우, Redis의 응답 속도에 영향을 줄 수 있습니다. 따라서 `save` 명령어의 실행 시점을 신중하게 조정하거나, 시스템 부하가 적은 시간대에 스냅샷이 찍히도록 예약하는 것이 좋습니다.
AOF 로깅: 모든 쓰기 명령어를 순차적으로 기록하는 AOF 방식은 RDB보다 더 큰 성능 오버헤드를 유발할 수 있습니다. 이때 `appendfsync` 옵션을 `everysec`으로 설정하면 초당 한 번만 디스크 동기화를 수행하여 성능 저하를 크게 완화할 수 있습니다. `always` 옵션은 가장 높은 수준의 데이터 안전성을 보장하지만, 성능에 미치는 영향이 가장 크므로 프로덕션 환경에서는 신중하게 검토해야 합니다.

디스크 공간 효율적인 관리 및 복구 검증

지속성 기능으로 인해 생성되는 RDB 및 AOF 파일은 시간이 지남에 따라 점차 용량이 커질 수 있습니다. 또한, 아무리 정교하게 설정했더라도 실제 장애 발생 시 데이터가 정상적으로 복구되는지 반드시 검증해야만 안심할 수 있습니다.

AOF Rewrite 및 파일 관리: AOF 파일의 크기가 비대해지는 것을 방지하기 위해 `BGREWRITEAOF` 명령어를 주기적으로 실행하거나, Redis의 자동 AOF 재작성 기능을 활성화합니다. `auto-aof-rewrite-percentage`와 `auto-aof-rewrite-min-size` 설정을 통해 파일 크기 증가를 효과적으로 제어할 수 있습니다. RDB 파일 역시 오래된 백업본은 정기적으로 삭제하여 디스크 공간을 확보하는 것이 중요합니다.
정기적인 복구 테스트: 설정된 RDB 또는 AOF 파일을 이용하여 실제 복구 절차를 주기적으로 시뮬레이션합니다. 다양한 장애 시나리오를 상정하고, 데이터가 문제없이 복구되는지, 그리고 복구에 소요되는 시간이 서비스 수준 협약(SLA) 목표를 충족하는지 반드시 확인해야 합니다. Redis 인메모리 데이터 유실 방지를 위한 지속성 설정의 궁극적인 목표는 바로 '신뢰할 수 있는 복구'에 있습니다.

추가적인 운영 팁

지속적인 모니터링: Redis의 디스크 사용량, I/O 성능 지표, RDB 및 AOF 작업 상태를 실시간으로 모니터링하여 잠재적인 문제를 조기에 발견하고 대응합니다.
별도 백업 전략: Redis 자체의 지속성 기능 외에도, 주기적으로 RDB/AOF 파일을 외부 스토리지에 별도로 백업하는 전략을 수립하여 재해 복구 역량을 강화합니다.
테스트 환경에서의 충분한 검증: 프로덕션 환경에 적용하기 전에 반드시 테스트 환경에서 변경된 지속성 설정을 충분히 검증하여 안정성과 성능을 확인하는 과정을 거칩니다.

경험에서 배운 점

Redis의 RDB 스냅샷과 AOF 로깅은 인메모리 데이터 유실을 막는 핵심 기능입니다. 처음에는 RDB만 설정하고 운영하는 경우가 많았죠. 하지만 예기치 못한 서버 다운이나 Redis 프로세스 종료 시, 마지막 스냅샷 이후의 데이터가 사라지는 아찔한 경험을 여러 번 겪었습니다. 특히 트랜잭션 데이터나 실시간 집계 데이터처럼 짧은 시간에도 중요한 정보가 계속 생성되는 서비스에서는 치명적일 수 있습니다. 따라서 RDB는 주기적인 백업과 복구 테스트 용도로 활용하고, 운영 환경에서는 AOF 로깅을 반드시 활성화하여 데이터 유실 가능성을 최소화하는 것이 필수입니다. AOF는 각 쓰기 명령을 로그 파일에 기록하기 때문에, 장애 발생 시에도 거의 모든 데이터를 복구할 수 있습니다.

AOF 로깅을 사용할 때도 `appendfsync` 설정의 중요성을 간과해서는 안 됩니다. `appendfsync always`는 가장 높은 수준의 데이터 안전성을 보장하지만, 디스크 I/O 부하가 증가하여 성능 저하를 초래할 수 있습니다. 반대로 `appendfsync no`는 성능은 뛰어나지만 데이터 유실 위험이 가장 높습니다. 저희 팀은 초기에 `appendfsync everysec` 설정을 기본으로 사용했습니다. 이는 대부분의 상황에서 성능과 데이터 안전성 사이의 균형을 잘 맞추었지만, 극단적인 상황(예: 디스크 쓰기 지연이 심한 경우)에서는 여전히 짧은 기간의 데이터 유실 가능성이 존재했습니다. 결국, 서비스의 중요도와 허용 가능한 RPO(복구 목표 시점)를 종합적으로 고려하여 `appendfsync everysec`을 유지하되, 디스크 성능 모니터링을 강화하고, 필요시 `appendfsync always`로 전환할 수 있는 운영 절차를 마련하는 것이 현실적인 재발 방지책임을 깨달았습니다. AOF 파일 크기 증가에 따른 복구 시간 증가도 고려해야 하며, 정기적인 `BGREWRITEAOF` 실행으로 AOF 파일을 최적화하는 습관이 중요합니다.

결론적으로, Redis의 데이터 지속성 설정은 단순히 기능을 활성화하는 것을 넘어, 서비스의 특성과 허용 가능한 위험 수준에 맞춰 RDB와 AOF를 적절히 조합하고, AOF의 `appendfsync` 설정을 신중하게 선택해야 합니다. 또한, 설정된 지속성 메커니즘이 제대로 작동하는지 정기적으로 검증하고, 장애 발생 시 복구 절차를 숙지하는 것이 중요합니다. 특히, RDB와 AOF를 함께 사용하는 경우, 두 설정 간의 우선순위와 데이터 복구 시나리오를 명확히 이해하고 있어야 예상치 못한 상황에서도 데이터 유실을 최소화할 수 있습니다. 이는 단순히 기술적인 설정 문제를 넘어, 비즈니스 연속성을 위한 필수적인 운영 사항이라 할 수 있습니다.

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

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

이 블로그 검색