Keeper: Go 바이너리 안에 시크릿을 암호화해서 내장하는 실험적 라이브러리

시크릿 관리, 늘 고민이죠

개발하면서 API 키, DB 비밀번호, 토큰 같은 시크릿(비밀 정보)을 어떻게 관리할지 고민 안 해본 분은 없을 거예요. 환경 변수로 넣자니 서버 설정이 번거롭고, 설정 파일에 넣자니 깃에 올라갈까 무섭고, HashiCorp Vault 같은 전문 도구를 쓰자니 작은 프로젝트에는 배보다 배꼽이 더 크고요. Keeper라는 Go 라이브러리가 새로운 접근법을 제안하고 있어요. 시크릿을 암호화한 뒤 Go 바이너리 자체에 내장(embed)해버리는 방식이에요.

어떻게 동작하나요?

아이디어 자체는 간단해요. Go에는 go:embed라는 기능이 있거든요. 이게 뭐냐면, 빌드할 때 파일을 바이너리 안에 포함시킬 수 있는 Go의 내장 기능이에요. 보통은 HTML 템플릿이나 정적 파일을 바이너리에 넣을 때 쓰는데, Keeper는 이걸 시크릿 저장에 활용해요.

동작 흐름을 단계별로 보면 이래요. 먼저 마스터 키를 생성하고, 이 마스터 키로 시크릿들을 암호화해서 파일로 저장해요. 그러면 빌드 시점에 go:embed를 통해 이 암호화된 파일이 바이너리 안에 들어가요. 런타임에 마스터 키를 환경 변수 등으로 제공하면, Keeper가 바이너리 안의 암호화된 시크릿을 복호화해서 사용할 수 있게 해주는 거예요.

암호화에는 AES-256-GCM을 사용하는데, 이건 현재 가장 널리 쓰이는 대칭 암호화 알고리즘 중 하나예요. AES-256은 256비트 키를 사용하는 암호화 표준이고, GCM은 데이터의 무결성(누가 중간에 데이터를 변조하지 않았는지)까지 보장해주는 운영 모드예요. 쉽게 말해 "잠금도 걸고, 누가 열어봤는지도 확인할 수 있는" 방식이라고 보면 돼요.

추가로 키 로테이션(주기적으로 암호화 키를 교체하는 것) 기능도 지원해요. 마스터 키 하나가 유출되더라도 피해를 최소화할 수 있도록 키를 교체하고 시크릿을 새 키로 다시 암호화하는 기능이에요. 보안에서는 키 로테이션이 기본 중의 기본이라 이 기능이 있다는 건 꽤 중요해요.

장점과 한계를 솔직하게 따져보면

이 접근법의 가장 큰 장점은 운영 복잡도가 낮다는 거예요. Vault 같은 시크릿 관리 서버를 따로 띄울 필요 없이, 바이너리 하나와 마스터 키 하나만 관리하면 되거든요. 소규모 프로젝트나 CLI 도구, 사이드 프로젝트에서 특히 매력적이에요.

하지만 한계도 분명해요. 첫째, 시크릿을 변경하려면 바이너리를 다시 빌드해야 해요. 환경 변수나 Vault 같은 외부 저장소는 앱 재시작만으로 새 시크릿을 반영할 수 있는데, Keeper 방식은 재빌드와 재배포가 필요하죠. 시크릿을 자주 교체해야 하는 환경에서는 부담이 될 수 있어요.

둘째, 마스터 키 관리라는 본질적인 문제는 여전히 남아요. 시크릿들은 바이너리 안에 안전하게 들어가지만, 결국 그걸 풀 수 있는 마스터 키를 어딘가에 보관해야 하잖아요. 마스터 키가 유출되면 바이너리 안의 모든 시크릿이 노출돼요. 이건 "시크릿 관리 문제를 한 단계 위로 올린 것"이지 완전히 해결한 건 아니에요.

셋째, 바이너리 자체가 유출되면 오프라인 공격이 가능해져요. 공격자가 바이너리를 확보하고 마스터 키를 알아내면 시크릿을 추출할 수 있으니까요. 물론 AES-256이 뚫리는 건 현실적으로 불가능에 가깝지만, 마스터 키가 약하거나 유출되면 얘기가 달라지죠.

기존 시크릿 관리 도구들과 비교

시크릿 관리 생태계를 간단히 정리하면 이래요. HashiCorp Vault는 엔터프라이즈급 시크릿 관리의 표준이에요. 동적 시크릿 생성, 세밀한 접근 제어, 감사 로그 등 강력한 기능을 제공하지만 운영 부담이 커요. AWS Secrets Manager, GCP Secret Manager 같은 클라우드 네이티브 서비스들은 각 클라우드 환경에서는 편리하지만, 클라우드 종속성이 생기죠. SOPS나 age 같은 도구는 암호화된 파일 기반으로 Git에 시크릿을 안전하게 저장하는 방식이에요.

Keeper는 이 스펙트럼에서 가장 가벼운 쪽에 위치해요. SOPS가 "암호화된 파일을 Git에 저장"하는 방식이라면, Keeper는 "암호화된 시크릿을 바이너리에 내장"하는 방식이에요. 외부 의존성이 전혀 없다는 점이 가장 큰 차별점이죠.

한국 개발자에게 주는 시사점

Go로 CLI 도구나 마이크로서비스를 만드는 분들 중에서, 시크릿 관리 인프라를 따로 구축하기 부담스러운 경우에 한번 검토해볼 만해요. 특히 사내 도구나 사이드 프로젝트처럼 규모가 작은 경우에 실용적일 수 있어요. 다만 프로덕션 환경에서는 Vault나 클라우드 시크릿 매니저 같은 검증된 도구를 쓰는 게 안전해요. Keeper는 아직 초기 단계이고, 프로젝트 제작자 본인도 "깨뜨려 달라(help me break it)"고 요청하고 있으니까요. 보안 도구는 충분한 검증을 거치기 전까지는 중요한 환경에 쓰지 않는 게 원칙이에요.

정리하자면

시크릿을 바이너리에 암호화해서 내장한다는 독특한 접근법의 Go 라이브러리예요. 운영 복잡도를 극단적으로 낮추는 대신, 시크릿 변경 시 재빌드가 필요하다는 트레이드오프가 있어요. 여러분은 프로젝트에서 시크릿을 어떻게 관리하고 계신가요? 환경 변수? Vault? 아니면 아직 .env 파일을 .gitignore에 넣고 기도하는 중인가요?