Docker 없이 Redis를? Encore가 런타임 안에 Redis 서버를 통째로 넣은 이유

백엔드 프로젝트를 새로 클론받아서 로컬에 세팅하던 순간을 떠올려 보세요. 코드 받고, Docker 켜고, docker-compose로 Postgres에 Redis까지 띄우고, 환경변수 맞추고... 그러다 포트가 충돌하고, 동료 컴퓨터의 Redis 버전이 달라서 미묘하게 동작이 다르고, CI 환경에서는 Docker를 못 쓰게 되어 있어서 또 다른 우회로를 찾아야 했던 경험, 다들 있으시죠. 백엔드 프레임워크를 만드는 Encore 팀이 이 문제를 꽤 과감한 방식으로 풀었는데요. 아예 Redis 호환 서버를 자기네 런타임 안에 통째로 집어넣어 버렸어요. encore run 한 줄이면 Docker도, 별도 설치도 없이 캐시가 그냥 딸려오는 거죠.

Encore가 어떤 프레임워크냐면

먼저 배경 설명이 필요한데요. Encore는 Go와 TypeScript용 백엔드 프레임워크인데, 특이한 점은 데이터베이스, 캐시, pub/sub 같은 인프라를 애플리케이션 코드 안에서 선언한다는 거예요. “이 서비스에서 캐시 하나 쓸게”라고 코드에 적으면 프레임워크가 환경에 맞게 실제 인프라를 알아서 붙여주는 방식이거든요. 그런데 로컬 개발이나 프리뷰 환경(PR마다 임시로 띄우는 환경)에서는 개발자마다 Redis를 직접 설치하거나 Docker로 띄워야 했고, 이게 계속 마찰을 만들었대요. 버전 불일치, 포트 충돌, Docker가 안 되는 샌드박스 CI, 그리고 임시 환경을 만들 때마다 컨테이너가 뜨길 기다리는 시간까지요.

런타임 안의 Redis, 어떻게 만들었냐면

핵심은 RESP 프로토콜이에요. 이게 뭐냐면 Redis 클라이언트와 서버가 대화할 때 쓰는 통신 규약인데요. 이 규약만 똑같이 구현하면 진짜 Redis가 아니어도 기존 Redis 클라이언트 라이브러리들이 전혀 눈치채지 못하고 그대로 동작해요. Encore 팀은 이 RESP 호환 서버를 Go로 직접 구현해서, 별도 프로세스가 아니라 Encore 데몬 안의 고루틴(Go의 경량 스레드)으로 돌게 했어요. 로컬 포트로 리슨하거나, 클라이언트와 서버가 같은 프로세스 안에 있으면 아예 메모리 안에서 직접 통신하기도 하고요.

물론 Redis의 모든 명령어를 다 만든 건 아니에요. 자기네 캐시 API가 쓰는 범위, 그러니까 문자열, 해시, 리스트, 셋, 정렬된 셋(sorted set), TTL 만료, INCR 같은 원자 연산, 그리고 pub/sub 정도를 지원해요. 키 만료는 실제 Redis처럼 접근할 때 게으르게(lazy) 지우는 방식과 주기적으로 쓸어내는 방식을 같이 써서 의미론을 맞췄고요. Lua 스크립팅, 클러스터, RDB/AOF 같은 영속성 기능은 과감히 뺐어요. 대신 진짜 Redis를 상대로 적합성 테스트(conformance test)를 돌려서 동작이 어긋나지 않는지 계속 검증한다고 해요.

효과는 확실해요. 테스트나 임시 환경 기동이 컨테이너를 띄우는 몇 초 대신 밀리초 단위로 끝나고, 테스트마다 완전히 독립된 인스턴스를 새로 만들 수 있어서 키가 겹칠 걱정 없이 병렬 테스트가 가능해졌어요. 그리고 중요한 건, 프로덕션에서는 클라우드의 진짜 매니지드 Redis가 붙는다는 거예요. 애플리케이션 코드는 한 줄도 안 바뀌고, 런타임이 뒤에서 구현체만 바꿔 끼우는 구조죠.

사실 이런 흐름, 처음은 아니에요

비슷한 접근은 이미 있었어요. Go 진영에는 테스트용 인메모리 Redis 구현체인 miniredis가 있고, Python에는 fakeredis가 있죠. 반대편에는 진짜 컨테이너를 코드로 띄워주는 Testcontainers 같은 접근도 있고요. Testcontainers는 진짜 Redis라서 충실도가 높지만 Docker가 필수고 느린 반면, 인메모리 구현은 빠르고 의존성이 없지만 미묘한 동작 차이의 위험을 안고 가요. Encore의 선택이 흥미로운 건 이걸 라이브러리가 아니라 프레임워크 런타임 차원의 기본값으로 만들었다는 점이에요. SQLite가 “데이터베이스는 서버가 아니라 파일일 수도 있다”는 걸 보여줬듯, 개발 환경의 인프라는 임베딩될 수 있다는 철학인 거죠.

우리가 가져갈 수 있는 것

Encore를 안 쓰더라도 아이디어는 충분히 훔칠 만해요. 지금 테스트에서 Redis 하나 때문에 Docker를 띄우고 있다면, miniredis나 fakeredis 같은 인메모리 구현으로 바꿔서 테스트 속도를 확 올려볼 수 있어요. 다만 개발 환경과 프로덕션의 동작 차이(dev/prod parity)는 늘 조심해야 해요. 만료 타이밍 같은 에지 케이스는 미묘하게 다를 수 있으니, Encore처럼 진짜 인프라를 상대로 한 검증 테스트를 한 겹 두는 게 좋은 안전장치가 되고요.

정리하면, “개발 환경의 인프라는 설치하는 게 아니라 내장되어야 한다”는 실험이에요. 여러분 팀은 로컬 개발 환경에서 Redis 같은 인프라를 어떻게 관리하고 계세요? Docker Compose파, Testcontainers파, 아니면 인메모리파인가요?