🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

허깅페이스는 멀티클라우드·쿠버네티스·로컬 개발·CI/CD에 흩어진 비밀정보 관리를 Infisical로 통합해 접근 통제와 감사·동기화를 표준화하면서도 대규모 운영에 필요한 수동 배포 통제권을 유지했다.

📌 핵심 요약

• 허깅페이스는 400만 명이 넘는 빌더가 Hub에서 모델을 배포하는 규모로 성장하고 인프라가 단일 클라우드에서 Azure와 GCP를 포함한 멀티클라우드로 확장되자, 비밀정보의 분산과 권한 관리 복잡성을 해결할 중앙 관리 체계가 필요해졌다.
• HashiCorp Vault를 비롯한 도구를 검토한 뒤 개발자 친화적인 작업 흐름, 멀티클라우드 추상화, 보안 기능을 갖춘 Infisical을 선택했으며, 인프라와 애플리케이션 영역을 분리해 프로젝트 구조와 비밀정보 순환 방식을 재정비했다.
• Terraform과 Infisical Kubernetes Operator를 결합해 Infisical의 변경 사항을 쿠버네티스 Secret으로 지속적으로 동기화했지만, 분당 1천만 건이 넘는 요청과 다수의 복제본을 고려해 운영 컨테이너 재시작은 자동화보다 수동 재배포를 선호했다.
• 로컬에서는 CLI가 비밀정보를 개발 환경에 직접 주입해 .env 파일을 없앴고, Okta 그룹과 연동된 세분화된 역할 기반 접근 제어를 통해 프로젝트 관리자와 프런트엔드·백엔드 팀의 읽기·쓰기 권한을 구분했다.
• GitHub Actions의 OIDC 인증, Terraform, 보안 환경의 자체 호스팅 러너까지 동일한 체계에 연결한 결과 수동 설정 부담이 줄고 감사와 사고 대응이 빨라졌으며, 로컬 개발부터 멀티클라우드 배포까지 일관된 비밀정보 관리 흐름이 마련됐다.

🧩 주요 포인트

1. 허깅페이스는 400만 명이 넘는 빌더가 Hub에서 모델을 배포하는 규모로 성장하고 인프라가 단일 클라우드에서 Azure와 GCP를 포함한 멀티클라우드로 확장되자, 비밀정보의 분산과 권한 관리 복잡성을 해결할 중앙 관리 체계가 필요해졌다.
2. HashiCorp Vault를 비롯한 도구를 검토한 뒤 개발자 친화적인 작업 흐름, 멀티클라우드 추상화, 보안 기능을 갖춘 Infisical을 선택했으며, 인프라와 애플리케이션 영역을 분리해 프로젝트 구조와 비밀정보 순환 방식을 재정비했다.
3. Terraform과 Infisical Kubernetes Operator를 결합해 Infisical의 변경 사항을 쿠버네티스 Secret으로 지속적으로 동기화했지만, 분당 1천만 건이 넘는 요청과 다수의 복제본을 고려해 운영 컨테이너 재시작은 자동화보다 수동 재배포를 선호했다.
4. 로컬에서는 CLI가 비밀정보를 개발 환경에 직접 주입해 .env 파일을 없앴고, Okta 그룹과 연동된 세분화된 역할 기반 접근 제어를 통해 프로젝트 관리자와 프런트엔드·백엔드 팀의 읽기·쓰기 권한을 구분했다.
5. GitHub Actions의 OIDC 인증, Terraform, 보안 환경의 자체 호스팅 러너까지 동일한 체계에 연결한 결과 수동 설정 부담이 줄고 감사와 사고 대응이 빨라졌으며, 로컬 개발부터 멀티클라우드 배포까지 일관된 비밀정보 관리 흐름이 마련됐다.

🧠 상세 정리

1. 성장과 멀티클라우드 전환이 만든 관리 한계

허깅페이스는 400만 명이 넘는 빌더가 Hub에서 모델을 배포하는 규모로 성장하면서 민감한 구성 데이터와 자격 증명을 다루는 기존 방식을 재검토했다. 인프라도 기존의 단일 클라우드 중심 구조에서 Azure와 GCP를 포함하는 멀티클라우드 환경으로 확장되어, 환경마다 다른 방식으로 비밀정보를 관리할 경우 이른바 비밀정보 확산 위험이 커졌다. 조직의 성장에 따라 권한 설정도 복잡해져 Okta 기반 SSO와 연동되는 세밀한 역할 기반 접근 제어가 필요했다. 로컬의 전통적인 .env 파일은 보안성과 개발 생산성을 함께 떨어뜨렸고, 노출된 자격 증명과 관련된 보안 사고는 수동 순환 방식의 부담을 분명히 드러냈다. 이에 프로젝트별 관리, 인프라 코드화, 자동화와 수동 통제의 균형을 모두 지원하는 중앙화된 해법이 요구됐다.

2. Infisical 선택과 프로젝트 구조 재정비

엔지니어링 팀은 HashiCorp Vault 같은 도구도 검토했지만, 기존 시스템을 다시 설계하거나 무거운 솔루션을 도입하는 대신 개발자 친화적 작업 흐름과 멀티클라우드 추상화, 보안 기능을 제공하는 Infisical을 선택했다. 도입은 단순한 제품 교체에 그치지 않고 내부 프로젝트 구조를 다시 살피는 계기가 됐다. 팀은 프로젝트를 인프라 영역과 애플리케이션 영역으로 나누어 책임과 관리 범위를 더 분명하게 구분했다. 최근 보안 사고 이후 우선 과제가 된 비밀정보 순환 방식도 이 구조 안에서 표준화했다. 기존에 클라우드 구성으로부터 쿠버네티스 Secret을 생성하는 데 사용하던 Terraform 경험을 활용할 수 있었기 때문에 Infisical Kubernetes Operator로의 전환도 비교적 매끄럽게 진행됐다.

3. 쿠버네티스 동기화와 의도적인 수동 배포

허깅페이스의 프로덕션 환경에서 핵심 역할을 하는 쿠버네티스에는 Infisical Kubernetes Operator가 적용됐다. 개발자는 CLI나 웹 UI에서 비밀정보를 만든 뒤, 동기화할 Infisical 항목과 대상 쿠버네티스 Secret을 지정하는 InfisicalSecret 사용자 정의 리소스를 생성한다. Operator는 Infisical의 변경을 계속 감시하고 변경이 발견되면 대응하는 쿠버네티스 Secret을 자동으로 갱신하며, 애플리케이션은 이를 환경 변수나 마운트된 볼륨으로 사용할 수 있다. 기능상으로는 Secret 변경 시 의존하는 Deployment와 컨테이너를 자동으로 다시 불러올 수도 있다. 그러나 허깅페이스는 분당 1천만 건이 넘는 요청과 수많은 복제본이 운영되는 상황에서 배포 시점을 정밀하게 통제하기 위해 자동 재시작보다 수동 재배포를 선호했다.

4. 로컬 개발과 접근 권한의 표준화

로컬 개발에서는 Infisical CLI가 비밀정보를 개발 환경에 직접 주입해, 민감한 값을 담은 .env 파일을 개발자 컴퓨터에 유지할 필요를 줄였다. 이 방식은 로컬 구성을 프로덕션의 관리 기준과 맞추고 새로운 구성원이 비밀정보를 전달받아 설정하는 과정의 마찰도 낮췄다. 접근 관리에서는 기존 ID 공급자인 Okta를 Infisical과 연결해 세분화된 역할 기반 접근 제어 체계를 구성했다. Okta 그룹에 따라 권한이 자동으로 매핑되며, 개발자는 담당 프로젝트에 대한 관리 권한을 유지하고 프런트엔드와 백엔드 팀에는 업무에 맞는 제한된 읽기 또는 쓰기 권한이 부여된다. 또한 비밀정보 공유 기능은 내부 ML·AI 연구자들이 자격 증명을 안전하게 전달하도록 지원하고, 중앙 플랫폼은 감사와 비밀정보 순환 관리를 단순화했다.

5. CI/CD와 인프라 코드 흐름의 통합

Infisical은 로컬과 쿠버네티스에만 적용되지 않고 배포 파이프라인에도 포함됐다. 허깅페이스는 GitHub Actions에서 OIDC 인증을 사용하고 Terraform과 연동해, 장기 자격 증명에 대한 의존을 줄이는 일관된 배포 흐름을 구성했다. 배포 작업은 보안이 적용된 환경 안의 자체 호스팅 러너에서 실행되어 프로덕션 수준의 보안 기준을 따르도록 했다. 그 결과 개발자가 로컬에서 작업할 때와 클라우드 환경에 배포할 때 서로 다른 비밀정보 관리 절차를 익히거나 수동으로 값을 옮길 필요가 줄었다. 프로젝트별 관리와 인프라 코드화 요구도 동일한 체계 안에서 충족되어, 자동화된 파이프라인과 운영자의 수동 통제를 함께 유지할 수 있게 됐다.

6. 운영 성과와 핵심 결론

비밀정보를 Infisical로 중앙화한 뒤 엔지니어가 환경별 비밀정보를 일일이 설정하는 데 쓰던 시간이 줄었고, 셀프서비스 작업 흐름을 통해 신규 합류와 일상적인 개발 과정이 빨라졌다. 자동화된 감사와 세분화된 접근 제어는 사고 발생 시 대응 속도를 높였으며, 개발 초기부터 보안을 적용하는 방식도 강화했다. 클라우드 공급자, 쿠버네티스 클러스터, CI/CD 파이프라인에 동일한 관리 체계를 적용하면서 환경 간 불일치가 줄고 인프라의 보안성과 신뢰성이 개선됐다. 허깅페이스 인프라 책임자는 Infisical이 로컬 개발, 프로덕션 쿠버네티스, CI/CD 전반에서 필요한 기능과 보안 설정을 사전 구성된 흐름으로 제공해 보안 수준과 엔지니어링 시간을 함께 개선했다고 평가했다. 사례의 결론은 안전한 절차를 가장 쉬운 절차로 만들 때 팀이 비밀정보 관리보다 제품 개발에 집중할 수 있다는 것이다.

🧾 핵심 주장 / 시사점

• 비밀정보 관리의 중앙화는 저장 위치만 통합하는 작업이 아니라 프로젝트 경계, 권한 모델, 순환 정책, 로컬 개발과 배포 절차를 하나의 운영 기준으로 재설계하는 작업이었다.
• 자동 동기화 기능이 제공되더라도 대규모 트래픽과 다수의 복제본을 운영하는 환경에서는 자동 재시작을 그대로 채택하지 않고, 비밀정보 갱신과 애플리케이션 재배포를 분리해 통제할 수 있다.
• 로컬 CLI, Okta 기반 역할 제어, 쿠버네티스 Operator, GitHub Actions의 OIDC, Terraform을 연결함으로써 개발 편의성과 보안을 상충 관계가 아닌 동일한 표준 작업 흐름으로 다뤘다.

✅ 액션 아이템

• 400만 명 빌더와 멀티클라우드 확장 맥락을 반영해 비밀정보 중앙 관리 범위를 Infisical 기반으로 명확히 정의한다.
• HashiCorp Vault 등 대안 대비 선택 근거를 기준화해 개발자 친화성, 멀티클라우드 추상화, 보안 기능 충족도를 점검한다.
• Terraform·Infisical Kubernetes Operator 연동 조건에서 분당 1천만 건 이상 요청과 다수 복제본 부담을 고려해 운영 재시작을 수동 재배포로 유지할지 점검한다.

❓ 열린 질문

• Okta 그룹 연동 기반의 읽기·쓰기 권한 구분은 프로젝트 관리자와 프런트·백엔드 팀에 대해 어떤 정책 축으로 고정할 것인가?
• CLI가 .env를 없애고 로컬에 비밀정보를 직접 주입할 때 개발자 실수 유출 리스크를 줄이기 위한 추가 통제는 어떤 방식이 가능한가?
• GitHub Actions OIDC·Terraform·자체 호스팅 러너 통합 운영에서 감사 및 사고 대응 속도 개선 효과를 측정하려면 어떤 지표가 필요한가?