osFoundry / Platform
앱별 KV 스토어
TTL이 있는 Redis 호환 KV. 세션, 캐시, 카운터를 앱 크기에 맞춰 사용하세요.
개요
앱별 KV 스토어는 osFoundry 안에서 만드는 모든 앱에 각자의 Redis 호환 키-값 백엔드를 제공합니다. Redis를 이미 알고 있다면 이것도 이미 아는 셈입니다. 키를 설정하고, 다시 읽어 오고, 카운터를 증가시키고, TTL(수명)을 붙여 항목이 스스로 만료되게 하면 됩니다. 각 앱은 격리된 네임스페이스를 갖기 때문에 한 앱의 세션 키가 다른 앱의 캐시 항목과 충돌하는 일이 없습니다. 프로비저닝하거나 보안을 설정하거나 계속 살려 둘 별도의 Redis 서버가 없으며, 스토어는 앱 런타임의 일부로서 그것을 사용하는 앱에 맞는 크기로 동작합니다.
TTL은 KV 스토어의 핵심이며, 기대하는 그대로 동작합니다. 만료 30분짜리 세션 토큰을 쓰면 그 시간이 지나면 사라지고, 비용이 큰 API 응답을 5분간 캐시해 스스로 갱신되게 할 수 있으며, 자동으로 비워지는 단기 락이나 레이트 리밋 윈도를 유지할 수 있습니다. 키가 정리 작업 없이 만료되므로 쓰레기를 쌓지 않고도 일시적인 상태를 저장할 수 있습니다. 카운터도 일급 기능입니다. 원자적 증가와 감소를 통해 조회 수, 쿼터 추적, 단순 시퀀스 번호를 read-modify-write 경합 없이 다룰 수 있습니다.
이는 채팅, 에이전트, 앱, 코드, 지식, 데이터가 한곳에 모이는 BYOK 데스크톱 워크스페이스라는 osFoundry의 형태에 잘 맞습니다. KV 스토어는 앱의 다른 데이터와 나란히 놓이는 빠르고 휘발적인 계층입니다. 뜨겁고 작고 수명이 짧은 것은 여기에 두고, 오래 보존할 기록은 다른 곳에 두세요. Redis 호환이라는 것은 여러분이 이전에 만든 무엇에서든 사고 모델과 명령 어휘가 그대로 이어진다는 뜻이며, 따라서 세션과 캐시를 돌리기 위해 새 API를 배울 필요가 없습니다.
주요 기능
- Redis 호환 키-값 API. GET, SET, INCR, EXPIRE 등 이미 아는 명령을 그대로 쓰며, 새 클라이언트를 배울 필요가 없습니다
- 키별 TTL로 세션, 캐시 항목, 락이 스스로 만료되며, 실행할 정리 작업이 필요 없습니다
- 앱별 격리 네임스페이스. 각 앱의 키는 그 앱에 한정되어 다른 앱의 키와 충돌하지 않습니다
- 증가/감소를 통한 원자적 카운터로 조회 수, 쿼터, 레이트 리밋 윈도를 경합 없이 다룹니다
- osFoundry 안에서 앱의 일부로 동작합니다. 프로비저닝할 것이 없고, 스토어는 사용하는 앱에 맞는 크기가 됩니다
활용 사례
- 앱 개발자: 슬라이딩 TTL로 로그인 세션을 저장해 사용자가 로그인 상태를 유지하고 오래된 토큰은 스스로 지워지게 합니다
- 백엔드 구축자: 느린 서드파티 API 응답을 몇 분간 캐시해 지연과 반복 호출을 줄입니다
- 에이전트 툴링 작성자: 만료되는 키를 통해 자동으로 리셋되는 분당 레이트 리밋 카운터를 유지합니다
자주 묻는 질문
진짜 Redis인가요, 아니면 Redis 비슷한 것인가요?
Redis 호환입니다. 즉 여러분이 이미 쓰는 것과 같은 키-값 명령과 의미 체계를 씁니다. 만료가 붙은 SET, GET, INCR, DEL이 그대로 통하므로 기존 습관과 코드 패턴이 이어집니다. 장점은 osFoundry의 앱 런타임에 내장되어 있어, 이를 쓰기 위해 별도의 Redis 서버를 세우거나 보안을 설정할 필요가 없다는 점입니다.
KV 스토어와 진짜 데이터베이스 중 어디에 무엇을 둬야 하나요?
KV는 뜨겁고 작고 수명이 짧은 상태에 쓰세요. 세션, 캐시, 카운터, 레이트 리밋 윈도, 락처럼 만료되어도 괜찮은 것들입니다. 살아남아 조회되어야 하는 오래가는 기록은 제대로 된 데이터베이스에 두세요. KV 스토어는 빠르고 휘발적인 계층이지, 기록의 원본이 아닙니다.
TTL은 키를 자동으로 만료시키나요?
네. 키에 수명을 설정하면 그 시간이 지나는 즉시 제거되며, 여러분 쪽에서 정리 작업을 돌릴 필요가 없습니다. 바로 이 점이 세션과 캐시에 잘 맞는 이유입니다. 임시여야 할 데이터가 쌓이지 않고 스스로 지워집니다.