RDB에서 Redis로🪄 인증 토큰 저장소 구조 개선과 73% 저장 공간 절감

 

현재 사내의 다양한 업무 시스템이 3.0 환경에서 5.0 환경으로 점진적으로 발전하고 있습니다. 특히 쇼핑몰 데이터 수집 업무를 고도화하는 과정에서 인증 토큰 관리 방법을 개선할 수 있다는 생각을 했고, 방안을 정리하여 제안서를 작성하게 되었습니다.

이번 글은 당시 제가 팀장님과 본부장님께 드렸던 제안서를 기반으로 재구성한 것입니다. 인증 토큰 저장소를 RDB에서 Redis로 전환하는 과정에서의 배경, Redis를 선택한 이유, 실제 적용 시 고려해야 할 사항, 그리고 무엇보다 중요한 실제 개선 효과를 공유하고자 합니다.

특히 저장 공간 관점에서 Redis 전환은 상당한 성과를 보였습니다. 기존 RDB 방식은 동일한 토큰이 3.0/5.0 테이블에 중복 저장되며 실질적인 데이터 저장 공간 크기가 5.6KB 이상의 공간을 차지했지만, Redis 기반 구조에서는 동일 데이터를 약 1.5KB로 저장할 수 있었습니다. 즉, 통합 쇼핑몰 계정 기준 약 73%의 저장 공간 절감 효과를 달성할 수 있었으며, 이 효과는 계정 수와 토큰 수가 누적될수록 더욱 크게 체감됩니다.

 

 

 

📍배경 상황

쇼핑몰 중 일부는 자체 로그인 방식으로 인증을 처리하지만, 많은 서비스가 OAuth 2.0 기반 인증/인가 방식을 사용합니다.
OAuth 기반 서비스는 액세스 토큰(access token) 과 리프레시 토큰(refresh token) 을 주요 인증 수단으로 사용합니다. 토큰의 상세한 동작 원리나 OAuth 프로토콜 설명은 아래 게시글을 참고하시면 되고, 이번 글에서 따로 다루지 않겠습니다.

 

https://programmer-may.tistory.com/261

OAuth 2.0 이해와 TikTok Shop API 연동하기

 

 

그동안 사내 서비스에서는 인증 토큰을 RDB 기반으로 관리하고 있었습니다.
구체적으로는 3.0 버전으론 MariaDB 테이블에 5.0 버전으로 PostreSQL 테이블에 저장하고 있습니다.

 

저는 이 토큰 정보를 RDB가 아닌 Redis에 캐싱하여 관리하는 방안을 제안드렸습니다.
세션 정보를 저장하기 위해 Redis를 세션 스토리지로 활용하듯, OAuth 토큰 역시 Redis를 토큰 스토어로 사용하는 것이 적절한 방향이라고 생각했기 때문입니다.

 

 

 

🪧제안 근거

 

1️⃣ 데이터 속성이 다릅니다 — 비즈니스 전표 데이터 vs 인증 토큰 데이터

 

PostgreSQL(RDB)에 저장하는 대부분의 데이터는 전표성 데이터입니다.
이 데이터는 강력한 ACID 특성, 트랜잭션 무결성, 이력 관리가 중요합니다.
RDB는 정합성 보장과 엔터프라이즈 데이터의 보존을 위해 적합합니다.

하지만 토큰 데이터의 특성은 완전히 다릅니다.

 

• 토큰은 명확한 만료 기한(expire) 을 갖습니다.
  → 일정 시점이 지나면 그 자체로 무의미한 데이터가 됩니다.
• 다른 데이터와 조인하거나 집계하거나, 복잡한 쿼리로 조회해야 할 상황이 없습니다.
• 심지어 데이터 자체보다 “만료 여부가 더 중요한 데이터” 입니다.

 

즉, 영구 보존과 관계 정합성이 중요한 RDB가 아닌, 휘발성 캐시 저장소(volatile key-value storage) 에 적합한 데이터입니다.

 

 

2️⃣데이터 TTL 관점 — “갱신되는 정보” vs “누적되는 레코드”

 

현재 토큰 데이터는 회사 코드 + 마켓 코드 기준으로 저장합니다.
갱신 시에는 기존 컬럼 값을 UPDATE하는 방식입니다.

 

예시)

• 갱신 전

회사코드	마켓코드	Access 토큰	Access Token 만료시간	Refresh 토큰	Refresh Token 만료시간
10000	10	AAA	10000	123AAA	50000

 

• 갱신 이후

회사코드	마켓코드	Access 토큰	Access Token 만료시간	Refresh 토큰	Refresh Token 만료시간
10000	10	BBB	10000	456BBB	50000

 

 

이 토큰 데이터를 보관하는 테이블은 회사 탈퇴, 마켓 사용 중지, 토큰 만료 등의 조건이 발생해도 데이터가 그대로 남습니다. 결국, 버려진 토큰 데이터는 자동 폐기되지 않고 영구적으로 누적됩니다.

 

더 나아가 3.0과 5.0 서비스가 동시에 운영되는 현재 구조에서는 동일한 인증 토큰 데이터가 두 개의 테이블에 중복 저장되며 불필요하게 2배로 축적되는 문제까지 발생합니다.

 

이를 해결하려면 스케줄러나 백그라운드 잡을 만들어 정리해야 하는데, 이는 불필요한 운영 부담이 늘어나는 방식입니다.

하지만 Redis는 TTL을 기반으로 키 만료를 스스로 처리합니다.
키에 expireIn을 지정하는 순간, 만료 관리 책임은 개발자가 아닌 Redis가 맡게 됩니다.

이 방식은

• 불필요한 데이터가 자연스럽게 제거되며
• 저장 공간을 낭비하지 않고
• 운영자가 별도로 정리 작업을 하지 않아도 됩니다.

 

3️⃣ 조회 성능 차이

 

핵심 이유는 아니지만, 조회 속도 또한 Redis 방식의 장점입니다. RDB 는 디스크 기반 저장소지만, 레디스는 인메모리 기반 저장소이기 때문입니다.

• RDB 평균 지연: 수 ㎳ ~ 수십 ㎳
• Redis: ㎲(마이크로초) 단위 ~ 수 ㎳

토큰은 요청마다 반복적으로 조회하는 데이터이므로,
더 빠른 응답이 누적되면 전체 시스템 성능 개선으로 이어집니다.

 

 

4️⃣ 인증 토큰 조회 및 삽입 로직 구조 흐름 개선

 

외부 수집처(쇼핑몰) 과 통신하는 서버는 스크래핑 서버이고 사내에선 이를 External 단계라고 부릅니다.

외부 서버와 통신하는 서버는 사내 보안 정책상 RDB 와 통신을 금지하고 있어, 스크래핑 서버 전과 후에 인증 토큰 조회와 삽입하는 로직이 존재해야 합니다.

 

● 기존 방식 흐름도

기존 방식 흐름도

 

기존 방식에서는 인증 정보를 전달하기 위한 로직때문에 분기와 로직이 추가되면서 코드 복잡도가 점점 높아집니다.

3.0과 5.0 환경이 공존하는 현 구조에서는 인증 토큰이 각각의 테이블에 중복 저장해야 하며, 매 요청마다 메시지에 토큰 값을 항상 포함해 전달해야 합니다.

이러한 방식은 인증 데이터가 “항상 함께 움직여야 하는 부속품”이 되어, 데이터 크기가 불필요하게 방대해집니다.

 

특히 통합 쇼핑몰 구조(1개 판매자 계정 / N개 오픈마켓) 에서는 문제는 더욱 복잡해집니다. 

사용자가 재인증을 수행할 경우 기존에 연결했던 일부 오픈마켓을 제외하고 인증을 진행하는 상황이 발생할 수 있습니다. 이런 경우 기존 데이터와 새로 제출된 인증 정보를 비교해, 누락된 오픈마켓에 해당하는 토큰 ROW를 찾아, 제거하는 복잡한 로직이 추가 되어야 합니다. 

• 예시) 1개 계정 / 5개 오픈마켓  → 1개 계정 3개 오픈마켓 (이 때 빠진 2개의 오픈마켓 인증 토큰 ROW를 삭제해줘야함)

 

 

● Redis 인증 토큰 저장소로 전환 후 흐름도

개선 후 흐름도

 

 

하지만 Redis를 중심으로 인증을 구조화하면, 저장 위치와 TTL 정책이 고정되면서 전체 흐름이 단순해지고 유지보수성이 훨씬 좋아집니다.
토큰이 “각 서비스와 함께 이리저리 들고 다녀야 하는 데이터”가 아니라, 항상 Redis에만 존재하는 중앙 집중형 자원이 되게됩니다.

애플리케이션 레벨에서는 더 이상 매 요청마다 토큰 값을 메시지에 태워 보내지 않아도 됩니다.
요청 메세지에는 회사 코드, 통합 쇼핑몰 계정 식별자, 오픈마켓 코드 정도의 최소 식별 정보만 담고, 실제 토큰 조회는 각 서비스가 Redis에서 직접 가져오는 형태로 바뀝니다.

 

또한 RDB 를 사용하지 않게 되면서 토큰의 실질적인 저장 위치는 항상 Redis 한 곳으로 고정됩니다.
중복 저장(두 테이블에 같은 토큰을 넣는 문제)도 사라지고, “토큰이 어디에, 어떤 스키마로 저장되어 있는지”를 알 필요가 없습니다.

 

 

앞선 통합 쇼핑몰의 경우(1개 판매자 계정 / N개 오픈마켓)도 Redis를 사용하면 훨씬 단순하게 정리할 수 있습니다.
기존 방식에서는 재인증 시, “이번에는 어떤 오픈마켓이 빠졌는지”를 일일이 비교해서 누락된 오픈마켓에 해당하는 ROW를 찾아 삭제하는 분기 로직이 필요했습니다.

반면 Redis를 토큰 저장소로 사용하면, 해당 통합 쇼핑몰 계정에 대한 Redis 키(또는 키 패턴)를 한 번에 삭제하거나 초기화하고 새로 인증된 3개의 오픈마켓에 대해서만 토큰을 다시 세팅합니다.

“기존 상태를 부분적으로 정리하는” 복잡한 분기 대신 “현재 상태를 그대로 덮어쓰는” 방식이 더욱 코드가 간결해지고 유지보수성이 높아집니다.

여기에 TTL까지 더해지면, 사용자가 더 이상 사용하지 않는 오픈마켓은 시간이 지나면 토큰 키 자체가 자동으로 만료·삭제됩니다.
별도의 정리 스케줄러 없이도 “사용하지 않는 인증 정보는 알아서 사라지는 구조”를 만들 수 있습니다.

 

 

정리하자면, Redis 기반 토큰 저장소를 사용하면

1. 인증 정보 전달 로직이 단순해지고 (토큰을 들고 다니지 않음)
2. 3.0 / 5.0 공존 구조에서도 저장소가 하나로 일원화되며
3. 통합 쇼핑몰 구조에서도 재인증 시 복잡한 분기/삭제 로직 없이 “상태 스냅샷 갱신” 패턴으로 처리할 수 있고
4. TTL 덕분에 사용되지 않는 토큰 데이터는 자연스럽게 정리됩니다.

이런 점에서 Redis는 단순한 캐시를 넘어, 인증 토큰을 관리하기에 더 데이터 특성에 잘 맞는 저장소라고 볼 수 있습니다.

 

 

 

🤔 Redis 인증 토큰 저장소 도입을 위해 고민한 점

 

Redis 기반 토큰 관리는 데이터 특성에 맞는 접근 방식이지만, 실제 사내 인프라 구조와 결합해 운영할 경우 몇 가지 중요한 고려 지점이 존재합니다.

아래는 Redis를 토큰 저장소로 활용할 때 제가 검토했던 내용입니다.

 

 

1️⃣ 단일 장애 지점(SPOF)을 극복하기 위한 이원화 구성(Replication)과 서버 선정

Redis로 토큰을 관리하는 가장 큰 장점은 TTL 기반 자동 만료, 저지연 조회, Key-value 기반 저장 구조의 단순성입니다.

인증 토큰은 조회 빈도가 높고, TTL을 갖는 휘발성 데이터이기 때문에 기본적으로는 Redis 서버에 토큰을 캐싱해서 사용하는 것만으로도 충분히 목적을 달성할 수 있습니다.
(단, 이를 위해서는 Redis 서버에 대한 커넥션 보안 허용이 선행되어야 합니다.)

하지만, 단일 Redis 서버에만 의존할 경우, 장애 발생 시 토큰 저장소 전체가 함께 영향을 받기 때문에,
반드시 Failover와 백업 저장소(Secondary Store) 를 함께 고려해야 합니다.

현재 사내 DB는 Zone 단위로 분리되어 운영되지만, Redis는 Zone 그룹 단위로 공유되는 특성을 가지고 있습니다.
따라서 Redis 캐시 서버 장애가 발생하면 해당 Zone 그룹 전체가 인증을 처리하지 못하는 단일 장애 지점(SPOF) 으로 이어질 수 있습니다.
이를 최소화하기 위해 토큰 저장소를 이원화(소스 – 레플리카 구조)하여 운영하는 방안을 검토했습니다.

 

RDB를 제외하고, 현재 사내에서 사용 중인 데이터 저장소로는 LevelDB, SSDB, Redis가 있습니다.
각각은 모두 Key-Value 형태의 데이터를 다루지만, 저장 매체와 사용 방식이 다릅니다.

 

• Redis: 메모리 기반 Key-Value 저장소로, 빠른 읽기·쓰기가 강점입니다.
• LevelDB: 서버 로컬 디스크에 파일 형태로 저장하는 내장형 Key-Value 엔진입니다.
• SSDB: Redis 프로토콜을 사용하지만, 디스크 기반인 Key-Value 저장소입니다.

토큰 저장을 위한 주 저장소와 부 저장소 조합을 다음 세 가지 안으로 압축했습니다.

 

1. 주 저장소: Global Redis 서버
    부 저장소: Local Redis 서버

2. 주 저장소: 각 존(Zone)의 Redis 서버
    부 저장소: 각 스크래핑 서버의 LevelDB

3. 주 저장소: 각 존(Zone)의 Redis 서버
    부 저장소: X존(COMMON 그룹)의 SSDB

 

각 안에 대해서는 아래 표와 같이 통신 방식, 저장 매체, 동기화 방식, 추가 작업 필요 여부 관점에서 장단점을 정리했습니다.

구분	1. Global Redis – Local Redis	2. Redis – LevelDB	3. Redis – SSDB
통신	네트워크 통신	X  (로컬 디스크 file I/O)	네트워크 통신
저장 장소	메모리	디스크	디스크
동기화 유무	자동 동기화	각 스크래핑 서버의 LevelDB에 동기화 필요	각각 저장
추가 작업		LVDB 저장 백엔드 동기화 로직 필요	X존 SSDB 생성 필요

 

 

정리된 내용을 토대로 인프라 부문장님, 본부장님, 팀장님과 논의한 결과, 읽기와 쓰기 모두 가능한 Redis 서버를 주 저장소로 사용하는 것으로 최종 결정되었습니다.

해당 서버는 내부적으로 동기화 구조를 갖추고 있어 별도의 레플리카 설계를 추가하지 않아도 운영이 가능하다는 점도 결정의 중요한 근거였습니다.

 

또한, 제가 장애 가능성에 대해 우려했으나, 사내에서는 Redis 를 세션 스토리지의 기반 인프라로 활용하고 있어 가장 높은 가용성을 보장받는 인프라 자원으로 관리하고 있다는 설명을 들었습니다. 이러한 운영 체계 덕분에 Redis 서버 장애 리스크는 실질적으로 매우 낮다는 점을 확인할 수 있었고, 결과적으로 토큰 저장소로 활용하는 데 무리가 없다는 결론에 도달했습니다.

 

 

 

2️⃣ 이원화 환경에서의 쓰기 연산과 트랜잭션처리

 

위 회의를 하기 전, 이원화 환경이 도입된다면 트랜잭션 처리를 어떻게 해야할 지 고민했습니다.
토큰은 TTL 기반으로 소멸하는 특성이 있어 지속적 강한 일관성은 필수 요구사항이 아닙니다. 그러나 소스 – 레플리카 간 정합성은 결국 운영 안정성과 직접 연결됩니다.

일반 적인 Replication은 복제 스트림 기반으로 소스에 데이터가 저장되면  자동으로 레플리카에도 동기화 됩니다. 그러나 현재 구조가 이 자동 동기화 형태인지, 혹은 독립적인 Redis 인스턴스로서 동기화 처리가 안되어 있는지 확인이 필요했습니다.

 

 

후자라면 두 저장소 모두 직접 SET 해야 합니다. 문제는 이 시점부터 쓰기 단위가 원자성을 잃는 것입니다.

예를 들어 소스 저장소에는 저장이 성공했지만 레플리카 저장소 업데이트가 실패하는 경우, 혹은 그 반대의 경우가 발생할 수 있습니다. 

 

 

이 상황을 방치하면 서로 다른 저장소 간 토큰 값 불일치를 초래하고, 서비스 단에서는 “어떤 노드가 최신 값인지” 판단할 수 없게 됩니다. 이 경우 보상 트랜잭션(Compensating Transaction) 을 적용하거나, 별도의 정합성 복구 로직을 설계해야 합니다.

 

보상 트랜잭션의 예시는 다음과 같습니다.

• 소스 저장 성공 / 레플리카 저장 실패
  → 소스 저장을 롤백하거나, 실패한 레플리카 저장을 재시도
  
  
• 레플리카 저장 성공 / 소스 저장 실패
  → 레플리카 저장을 제거하거나, 소스 저장을 다시 시도

이러한 복구 절차는 단순히 “실패 시 재시도” 수준의 로직이 아니라, 최소 2개의 저장소가 동일한 상태를 가질 때까지 재시도를 보장하는 단위 작업이 되어야 합니다.
그렇지 않을 경우 특정 시점의 요청 처리 흐름에서 다른 Redis 인스턴스가 서로 다른 토큰 상태를 반환하는 문제가 발생합니다.

 

이는 단순한 캐시 저장소로 접근했던 Redis를, “두 저장소 간 정합성을 유지해야 하는 DB 유사 스토리지” 로 격상시키는 설계입니다.
이러한 접근은 기술적 난이도뿐만 아니라 유지보수 비용도 크게 증가시킵니다. 

 

 

위 회의를 통해 토큰 저장소를 이원화하지 않기로 결정되었기 때문에, 앞서 언급했던 복잡한 고려 사항들(멀티 저장소 동기화, 분산 트랜잭션, 보상 처리 로직)은 신경 쓰지 않아도 되었습니다.

 

다만, 이원화를 채택하지 않는다는 것은 곧 하나의 Redis 서버가 단일 진실 원본(SSOT, Single Source of Truth) 역할을 수행하게 된다는 의미이기 때문에, 그만큼 해당 Redis 서버의 안정성과 가용성 확보가 매우 중요해집니다.

내부적으로 이미 Redis는 세션 스토리지 기반 인프라로 운영되며 가장 높은 가용성을 보장받는 리소스이지만, 토큰 역시 인증 체계의 일부이기 때문에 동일한 수준의 운용 안정성을 기대할 수 있어야 합니다.

 

 

결국, 장애 복구 / 백업 정책 / 모니터링 기준은 레플리카 구성 대신 “단일 저장소를 안정적으로 운영하는 방향”으로 초점이 옮겨가게 됩니다. Redis 자체의 레플리카 구성, 장애 자동 전환, 내부 Sync 메커니즘은 인프라 레벨에서 관리되므로 애플리케이션 레벨에서 중복 저장, 보상 트랜잭션, 멀티 커넥션 트랜잭션을 구현할 필요가 없다는 점은 오히려 장점입니다.

 

 

3️⃣ 데이터 캐싱시 동시성 문제

Redis 캐시가 만료되는 순간, 동시에 여러 클라이언트가 캐시 미스 → 신규 토큰 발행 요청을 보내면 중복 쓰기(Duplicate Write)가 발생할 수 있습니다.

 

• 예시 시퀀스다이어그램

 

두 사용자가 동시 요청하여 토큰 갱신이 겹치면, 한쪽 사용자에게는 “잘못된 인증 정보”라는 에러가 발생할 수 있습니다.

 

 

Grace Period 갖기 때문에 토큰을 재발급해도 기존 액세스 토큰이 즉시 폐기되지 않긴 하지만 빡빡하게 인증토큰을 관리하는 서비스라면 위 같은 문제가 발생할 수 있습니다.

 

 

하지만 이런 동시성 이슈는 Redis뿐만 아니라 RDB를 사용하더라도 충분히 발생할 수 있는 문제입니다. 위 회의에서도 실제로 이런 상황이 발생할 확률은 낮고, 설령 발생하더라도 두 요청을 모두 억지로 성공시키기보다는 한쪽 요청만 정상 처리되고 다른 한쪽은 401 에러를 반환하는 쪽이 더 안전하다는 결론을 내렸습니다.

 

어차피 401 에러를 받은 사용자는 다시 한 번 인증 과정을 거치게 되고, 이 과정에서 정상적인 토큰이 재발급·재캐싱되므로 서비스 전체적인 관점에서는 허용 가능한 수준의 리스크로 보기로 했습니다.

 

 

 

🔑 Redis 인증 토큰 저장소 Key 설계

 

처음에는 Redis에 인증 토큰을 저장할 때 Access Token과 Refresh Token을 하나의 키로 묶어 HASH 자료구조를 사용할까 고민했습니다.
아래와 같은 형태입니다.

key: {tenant CODE}:{openmarket CODE}
fields:
  access_token = AAA
  refresh_token = BBB

 

해당 방식은 데이터 조회가 단일 키 조회로 단순해지고, 여러 필드를 한 번에 읽어올 수 있다는 점에서 이상적으로 보일 수 있습니다.

 

하지만, 실제 OAuth 환경에서 토큰을 운영해보면 HASH 구조가 생각보다 큰 제약을 만듭니다.
핵심은 TTL(만료 시간)을 토큰별로 독립적으로 관리할 수 없다는 점입니다.

Access Token과 Refresh Token은 본질적으로 유효기간이 다릅니다.

• Access Token: 수십 분 ~ 수 시간
• Refresh Token: 며칠 ~ 몇 달

이때 HASH 자료구조에선 key 단위 TTL만 제공하고, field별 TTL을 설정할 수 없습니다.

Refresh Token의 만료 기한으로 HASH key 의 TTL 을 걸면 이미 만료된 Access Token 을 토큰을 불필요하게 레디스에 저장할 수 있고, Access Token 의 만료 기한으로 HASH key 의 TTL 을 걸면 리프레시 토큰의 만료기한이 아직 남았지만, 액세스 토큰과 같이 만료되어 사용자는 시스템 내부에서 토큰 갱신을 통한 인증인가가 아닌 빈번하게 재인증해야하는 번거로움이 생깁니다.

 

실 서비스에서는 Access Token이 매우 자주 바뀝니다. 반대로 Refresh Token은 극히 드물게 교체됩니다.

위 문제를 해결하기 위해 STRING 자료구조를 사용하여 Access Token과 Refresh Token을 각각 별도의 키로 저장하는 방식을 선택했습니다.
예시

{tenant}:{openmarket}:at
access_token  →  TTL = 7200s

{tenant}:{openmarket}:rt
refresh_token →  TTL = 604800s

 

또한 통합 쇼핑몰의 경우(1개 판매자 계정 / N개 오픈마켓)에는 하나의 키에 여러 오픈마켓 인증 정보를 함께 보관해야 합니다. 이를 위해 데이터를 JSON 구조로 설계하고 문자열로 변환해 저장했지만, 단일 오픈마켓 토큰에 비해 데이터 크기가 커지는 문제가 발생했습니다. 이러한 이유로 통합 쇼핑몰 토큰은 JSON 데이터를 Deflate로 압축한 뒤 Base64로 인코딩하는 방식을 사용해 저장했습니다.

 

 

압축 후엔 데이터 크기가 절반으로 줄었습니다. (1481 bytes → 764 bytes 약 50% 감소)

변경 전

 

변경 후

 

 

 

🚀성과

Redis 기반 토큰 저장소 도입 이후 가장 큰 변화는 토큰 관리의 복잡도가 크게 줄었다는 점입니다. 기존에는 토큰을 DB에 저장한 뒤 조회, 만료 판단, 갱신 처리 후 저장을 애플리케이션이 직접 수행해야 했지만, TTL 구조로 전환되면서 만료 관리 책임이 Redis로 이동했습니다.

 

3.0/5.0 공존 환경에서 토큰이 여러 테이블에 중복 저장되던 문제도 해소되었고, 토큰을 요청 메시지에 태워 전달할 필요도 사라졌습니다.

 

조회 성능 역시 즉시 개선되어, 반복적인 인증 요청에서 μs~ms 단위의 빠른 조회가 가능해졌습니다. 인증 토큰이 더 이상 서비스 로직의 부담이 아니라 인프라 레벨에서 안정적으로 관리되는 자원이 되었다는 점이 가장 큰 성과였습니다.

 

그 중 가장 큰 성과는 저장 공간의 획기적인 단축입니다. Redis에 저장된 개별 인증 토큰의 크기는 평균적으로 약 200B 내외에 불과해, 불필요한 저장 공간을 크게 줄였습니다.

 

특히 통합 쇼핑몰(1개 판매자 계정 / 9개 오픈마켓)의 경우를 예시로 보면 그 차이는 더욱 극명합니다.

 

RDB 저장시

 

 

동일 데이터를 RDB에 저장할 경우, 한 레코드의 실제 데이터 자체(Heap)는 약 2.8KB이고, 여기에 컬럼 저장 오버헤드·TOAST 영역·인덱스·페이지 단위 저장 등 RDBMS 특성상 발생하는 추가 비용까지 포함하면 약 4.1KB의 저장 공간을 차지합니다.

 

게다가 3.0/5.0 서비스가 공존하는 기간 동안 동일한 토큰이 두 개의 테이블에 중복 저장되므로, 실질적으로는 최소 5.6KB가 필요합니다.

 

Redis 저장시

 

 

 

반면 Redis에서 동일한 통합 쇼핑몰 토큰을 조회해 보면, 여러 오픈마켓 정보를 포함한 하나의 문자열임에도 실제 저장 크기가 약 768B 수준입니다. 여기에 리프레시 토큰을 동일 구조로 저장하더라도 총 사용 공간은 약 1.5KB에 불과합니다.

 

즉, 1개의 통합 계정 토큰 저장 공간 기준으로 5.6KB → 1.5KB, 약 73%의 저장 공간 절감 효과를 달성했습니다.

 

이 수치는 단순히 “RDB 대신 Redis가 빠르다”는 수준을 넘어, 인증 시스템이 장기간 누적될수록 비용·성능·유지보수 측면에서 구조적으로 유리한 모델이라는 점을 보여줍니다.