Infisical 도입기: 환경변수 중앙화와 단일 장애점(SPoF)을 방어하는 CI/CD 아키텍처
프로젝트가 늘어나면서 가장 관리하기 까다로웠던 것은 다름 아닌 환경변수 였습니다. 데이터베이스 접속 정보, SSH 접근 Private/Public Key, 외부 API 토큰 등 회사의 가장 치명적인 자산들이 슬랙을 통해 공유되거나 개인의 로컬 PC에 파편화되어 있었습니다. 이는 보안적으로 매우 위험할 뿐만 아니라, 환경변수 업데이트 누락으로 인한 배포 장애를 끊임없이 유발했습니다.
이를 해결하고 환경변수의 단일 진실 공급원(Single Source of Truth)을 구축하기 위해 오픈소스 시크릿 매니저인 Infisical 을 사내 하네스에 도입하며 겪었던 아키텍처적 고민을 공유합니다.
The Problem: 왜 SaaS가 아닌 Self-Hosted 였는가?
Infisical은 훌륭한 클라우드 버전을 제공하지만, 우리는 굳이 인프라 관리의 수고를 감수하면서까지 사내 인스턴스 구축 을 택했습니다. 가장 큰 이유는 보안 통제권 과 비용 절감 이었습니다. 회사의 모든 핵심 인프라 Key 값들을 외부 클라우드에 온전히 위임하는 것은 보안 컴플라이언스상 부담이 컸습니다. 또한, 프로젝트와 팀원이 늘어날 때마다 발생하는 SaaS 구독 비용을 방어하고 인프라 고정비용을 최적화하기 위한 전략적 선택이었습니다.
DX의 혁신: CLI Wrapper와 자동 매핑
Infisical 도입 후, 팀원들의 로컬 개발 워크플로우는 극적으로 쾌적해졌습니다. 더 이상 슬랙에서 .env 텍스트 블록을 복사해 붙여넣을 필요가 없어졌습니다.
- CLI Wrapper 적용: 팀원들은
infisical run -- npm run dev와 같이 CLI 래퍼(Wrapper) 명령어를 실행하기만 하면 됩니다. .infisical.json기반 브랜치 매핑: Infisical 내부를 디렉터리(Folder)로 구조화하고, 프로젝트 루트의.infisical.json을 통해 로컬의 Git 브랜치와 Infisical의 특정-path를 자동으로 매핑시켰습니다.
결과적으로 개발자가 main 브랜치에 있으면 Production 변수를, dev 브랜치에 있으면 Development 변수를 알아서 주입받아 실행하는 자동화된 DX 환경을 구축했습니다.
The Architectural Dilemma: 단일 장애점과 가용성
환경변수 관리는 완벽해졌지만, 아키텍트로서 시스템 전체의 구조를 바라보았을 때 치명적인 딜레마를 마주했습니다. "만약 사내에 구축한 Infisical 서버가 다운된다면, 실 서비스 중인 프로덕션 서버들도 함께 죽는 것인가?"
만약 실 서비스 서버들이 런타임에 Infisical 서버를 찔러서 환경변수를 가져오는 구조를 택했다면, Infisical 서버 장애 시 실 서비스 인스턴스가 재시작되거나 스케일 아웃될 때 환경변수를 받지 못해 전체 서비스 장애로 이어질 것입니다. 즉, Infisical 서버가 시스템 전체의 단일 장애점 이 되는 것입니다.
The Solution: Build-Time Injection 전략
이러한 시스템적 리스크를 방어하기 위해 런타임 의존성을 완전히 제거 했습니다.
우리의 CI/CD 파이프라인은 배포 과정에서 딱 한 번 Infisical 서버를 호출하여 필요한 환경변수를 가져온 뒤, 물리적인 .env 파일을 직접 생성하여 빌드 산출물과 함께 인스턴스로 배포합니다.
- Infisical 서버가 정상일 때: 파이프라인이 매끄럽게 동작하여 최신 환경변수로 배포됩니다.
- Infisical 서버가 다운되었을 때: CI/CD 파이프라인 단계에서 배포가 실패합니다. 하지만 가장 중요한 실 서비스는 아무런 타격을 받지 않습니다. 기존 인스턴스들은 지난번 배포 때 생성된 물리적
.env파일을 가지고 독립적으로 동작하기 때문입니다.
The Result & Retrospective
"배포 장애를 감수하더라도 실 서비스의 장애는 막는다."
이 명확한 원칙을 바탕으로 환경변수 중앙화와 시스템 고가용성이라는 두 마리 토끼를 모두 잡을 수 있었습니다. 문제가 생기면 배포가 멈춘 시점에서 Infisical 서버를 복구한 뒤 재배포하면 그만입니다. Infisical의 도입은 단순히 툴을 바꾼 것이 아니라, 인프라의 결합도를 낮추고 방어적 아키텍처를 설계하는 법을 깨닫게 해 준 최고의 결정이었습니다.