여기어때 Secret 플랫폼 구축기 Part 1: 왜 시크릿 저장소를 만들었는가

안녕하세요, 여기어때컴퍼니 DevOps팀 셀린입니다.

여기어때 DevOps팀은 Secret 중앙 관리 플랫폼, Secrethub 를 구축했습니다.

어떤 배경과 문제의식에서 시작했는지, 그리고 그 과정 속에서 어떤 선택과 개선을 거쳐 발전해왔는지를 총 3편에 걸쳐 이야기해보려 합니다.

들어가며,

최근 몇 년 사이 “민감 정보 관리”는 더 이상 선택이 아닌 기본 전제가 되었습니다.

DB 비밀번호, API Key, 외부 연동 토큰 같은 민감 정보는 모든 서비스의 출발점이자 동시에 가장 큰 리스크이기도 합니다.

“민감 정보는 어떻게 관리하는 게 가장 안전하고 효율적일까?”

아마 대부분의 개발자라면 한 번쯤은 이런 고민을 해봤을 것입니다.

저희도 같은 고민에서 출발했습니다.

그리고 그 질문에 대한 답으로, 민감 정보를 플랫폼 차원에서 관리하는 방식을 선택했습니다.

Secrethub는 데이터베이스 접속 정보, API Key와 같이 애플리케이션에서 사용하는 민감한 정보를 중앙에서 안전하게 관리하기 위해 만든 내부 플랫폼입니다.

도입 이후 가장 크게 달라진 점은 단순히 “저장 위치”가 바뀐 것이 아니었습니다. 크리덴셜(Credential)은 더 이상 각 서비스에 흩어져 있는 값이 아니라, 정책과 권한을 기준으로 플랫폼이 관리하는 자산이 되었습니다.

이 글에서는 그 변화가 왜 필요했는지,

그리고 왜 외부 솔루션이 아닌 자체 플랫폼을 선택했는지를 차근차근 풀어보겠습니다.

왜 Secret 관리 시스템이 필요했을까

AI 생성 이미지 (자체 제작)

서비스와 프로젝트 수가 늘어나면서, 민감 정보 관리에 대해 보다 체계적인 구조의 필요성을 느끼게 되었습니다.

1. 접근 통제와 감사의 필요성

서비스가 많아질수록 이런 질문에 명확히 답할 수 있어야 한다고 느꼈습니다.

• 누가 어떤 민감 정보를 조회했는가
• 민감 정보가 언제 변경되었는가
• 현재 어떤 서비스에서 사용 중인가

기존 구조에서는 이 정보를 체계적으로 추적하기가 쉽지 않았습니다.

민감 정보가 많아질수록, 이력과 감사 가능성은 보안과 운영 양쪽에서 점점 중요해졌습니다.

2. 권한 관리의 일원화

조직이 커지면서 자연스럽게 이런 상황이 반복되었습니다.

• 신규 입사자 온보딩
• 프로젝트 추가
• 팀 이동
• 퇴사자 권한 회수

각 프로젝트 단위로 권한을 관리하다 보니, 민감 정보 접근 권한도 분산되어 관리되고 있었습니다.

따라서 권한 정책을 한곳에서 통제할 수 있는 구조가 필요하다고 판단했습니다.

3. 개발자의 인지 부담 최소화

또 하나 중요하게 생각했던 부분은 “개발자가 어디까지 알아야 하는가”였습니다.

Secret 값은 애플리케이션이 필요로 하는 자원이지, 개발자가 기억하거나 직접 관리해야 할 정보는 아닙니다.

애플리케이션 개발에 집중하는 과정에서 민감 정보를 직접 인지해야 하는 구조는 불필요한 인지 부담을 만들 수 있다고 판단했습니다.

따라서 저희는 개발자가 민감 정보를 몰라도 개발할 수 있는 구조를 만들고 싶었습니다.

그래서 우리가 선택한 방향

AI 생성 이미지 (자체 제작)

이러한 고민 끝에 민감 정보를 각 프로젝트에서 분산 관리하는 대신, 플랫폼 레벨에서 중앙 관리하는 구조가 필요하다고 판단했습니다.

목표는 단순히 보안을 강화하는 것이 아니었습니다.

• 민감 정보를 코드와 분리하고
• 변경 시 운영 부담을 줄이며
• 접근을 통제하고 감사 가능하게 만들고
• 애플리케이션과 자연스럽게 연동되는 구조

를 만드는 것이 목표였습니다.

그렇게 Secrethub 도입을 본격적으로 고민하게 되었습니다.

그럼 왜 외부 솔루션이 아닌 자체 개발을 선택했을까

AWS Secrets Manager나 HashiCorp Vault와 같은 검증된 외부 솔루션 도입도 고려했었지만 다음과 같은 이유로 저희 개발 환경의 요구사항을 가장 잘 충족시키는 자체 개발을 택했습니다.

1. 계정 관리의 복잡성

외부 크리덴셜(Credential) 관리 솔루션을 도입할 경우 별도의 계정 체계를 추가로 운영해야 하는 부담이 있을 수 있습니다.

• 개발자 계정 발급
• 프로젝트별 접근 권한 설정
• 신규 입사자 온보딩 시 권한 추가 및 퇴사자 권한 회수

이미 내부 계정 시스템이 존재하는 상황에서 또 하나의 인증·권한 체계를 추가하는 것은 운영 부담으로 이어질 수 있습니다.

Secrethub는 기존 내부 계정 체계와 자연스럽게 연동되도록 설계했습니다.

이를 통해 접근 통제는 강화하면서도, 계정 관리 복잡성은 최소화하고자 했습니다.

2. 다양한 실행 환경과 프레임워크 버전 대응

저희 서비스는 EKS, EC2, 로컬 개발 환경 등 다양한 환경에서 운영되고 있습니다.

Spring Boot 버전도 2.x부터 3.x까지 혼재되어 있습니다.

외부 솔루션을 도입할 경우, 각 환경마다 인증 방식과 연동 설정이 달라지기 때문에, 환경별로 일관된 경험을 제공하기 어렵습니다.

저희는 특정 프레임워크나 버전에 의존하지 않는 구조가 필요했습니다.

이를 위해 Secrethub Loader 라이브러리는 순수 Java 기반으로 구현하여, 의존성 충돌 없이 어떤 프로젝트에서든 동일하게 동작하도록 설계했습니다.

(Secrethub Loader 라이브러리는 다음 편에서 자세히 풀어보겠습니다. 다음 글도 함께 읽어주시면 흐름이 훨씬 선명해질 거예요!)

무엇이 달라졌는가

Secrethub 도입 이후 가장 크게 달라진 점은, 민감 정보 관리의 책임 이 프로젝트에서 플랫폼으로 이동했다는 점입니다.

기존에는 각 개발팀이 민감 정보의 변경과 통제를 직접 담당했다면, 이제는 플랫폼에서 이를 중앙 관리합니다. 개발자는 민감 정보를 몰라도 되고, 애플리케이션은 기존 방식 그대로 사용합니다.

Secrethub를 도입하면서 가장 크게 느낀 점은,

민감 정보 관리는 특정 기능이 아니라 서비스 설계의 기본 전제라는 것이었습니다.

또한 이번 경험을 통해 DevOps의 역할에 대해서도 다시 생각해보게 되었습니다. DevOps는 새로운 도구를 만드는 팀이 아니라, 불필요한 고민을 하지 않아도 되는 구조를 만드는 팀이라고 느꼈습니다.

Secret을 “직접 관리해야 하는 값”에서 “필요할 때 안전하게 주입되는 자원”으로 바꾼 것이 이번 Secrethub 도입의 가장 큰 변화라고 생각합니다.

다음으로,

Secrethub를 실제로 개발 환경에 어떻게 적용했는지,

그리고 External Secrets Operator(ESO) 와 Secrethub Loader 라이브러리를 어떻게 설계했는지 자세히 풀어보겠습니다.

읽어주셔서 감사합니다. 🤗