주제 및 배경
본 시리즈에서는 Envoy Proxy를 Redis 프록시로 활용할 때 필요한 기능 구현 과정을 상세히 다룹니다. 실제 운영 환경에서의 설정부터 Envoy 프로젝트에 기여하기까지의 전체 여정을 공유하고자 합니다.
이 시리즈를 작성하게 된 배경은 보안 과제 수행 중 발생한 Redis 연결 문제를 Envoy Proxy로 해결하면서 시작되었습니다. 그 과정에서 CNCF Ambassador 프로그램을 알게 되었고, Envoy Proxy에 부족한 기능을 직접 구현하여 기여하게 되었습니다.
앞으로 더 많은 분들이 Envoy Proxy에 기여할 수 있기를 바라며, 저도 이 과정을 통해 CNCF Ambassador가 될 수 있으면 좋겠습니다 🚀
Envoy Proxy란?
Envoy Proxy는 CNCF의 3번째 Graduated Project로, 2026년 5월 기준 GitHub에서 27,912개의 스타를 받은 대규모 프록시 프로젝트입니다. 특히 Kubernetes 환경에서 Service Mesh의 핵심 컴포넌트로 널리 사용되고 있으며, 높은 성능과 안정성을 갖춘 성숙한 오픈소스 프로젝트입니다.
주요 특징:
- 마이크로서비스 환경에서 트래픽 라우팅 및 제어
- TLS/SSL 터미네이션 지원
- Redis, MySQL, PostgreSQL 등 다양한 프로토콜 프록시 기능
- 실시간 모니터링 및 로깅 기능
마주했던 기술적 과제
배경: 보안 강화를 위한 아키텍처 변경
기존 시스템에서는 애플리케이션이 AWS ElastiCache(Redis)에 직접 접근하는 구조였습니다. 이를 보안 강화하기 위해 Teleport를 활용한 Zero Trust 아키텍처로 변경하려 했습니다 (EKS + Istio 환경).
문제 상황
Teleport를 통해 AWS ElastiCache에 안전하게 연결하려면 TLS(전송 중 암호화)를 반드시 활성화해야 합니다. 하지만:
- ❌ TLS를 활성화하면 Redis 성능 저하가 발생함
- ❌ Teleport의 GUI 도구들이 TLS 기반 연결을 지원하지 않음
- ❌ 기존 모니터링 및 관리 도구 호환성 문제
해결책: Envoy Proxy 도입
Envoy Proxy를 Redis 프록시로 배치하여 위 문제들을 해결했습니다:
- TLS 터미네이션을 Envoy에서 처리 → 애플리케이션은 평문 통신
- 성능 최적화 + 보안 강화 달성
- 다양한 모니터링 및 제어 기능 추가 가능
새로운 과제: 기능 부족
Envoy의 Redis 프록시 기능이 당시 레디스 명령어 지원이 미흡했습니다. 이로 인해:
- 일부 최신 Redis 기능 미지원
- GUI 기반 클라이언트 도구 사용 불가
- 디버깅 시 제약사항 발생
기여로 나아가기
이 상황에서 **“Envoy에 부족한 기능을 직접 구현하면 어떨까?”**라는 생각으로 Envoy Proxy 프로젝트에 기여하게 되었습니다. 실제로 필요한 기능을 구현하여 PR을 제출하고 승인받는 데 성공했습니다.
이 시리즈에서 다룰 주제들
이 시리즈는 실제 Envoy 기여 경험을 단계별로 다룹니다:
- 개발 환경 구축 - Envoy 빌드 환경 설정 및 필수 도구 설치
- 코드 분석 및 설계 - Redis 프록시 기능 분석, 구현 계획 수립
- 기능 구현 - RESP3 프로토콜 지원 추가, 테스트 코드 작성
- 로컬 테스트 - ElastiCache와의 연결 테스트, 성능 검증
- PR 제출 및 리뷰 대응 - GitHub를 통한 코드 리뷰 과정, 피드백 반영
- 커뮤니티 상호작용 - 유지보수자와의 소통, 승인 과정
- 릴리즈 및 배포 - 메인 브랜치 병합, 공식 릴리즈 탑재
각 단계에서 마주한 문제들과 해결 방법, 배운 점들을 상세히 공유합니다.