[Architecture] 키를 한곳에 모았는데, 읽는 코드는 제각각이었다 — 단일 금고 후속기

Об этом предложении

API 키를 한곳에 모았는데, 읽기 코드를 확인하니 공용 파일을 읽는 경로와 프로젝트의 옛 파일을 먼저 찾는 경로가 섞여 있었다. 저장 위치를 하나로 정해도 각 프로그램이 그곳을 읽도록 바꾸는 작업은 따로 남았다. 이전 글 에서는 흩어진 키를 공용 금고로 모으는 방향을 정리했다. 이번에는 그 구조를 실제 읽기 코드에 연결하고, 현재 실행 환경에 들어온 값을 덮어쓰지 않는지 확인한 뒤 옛 파일을 정리했다. 앞선 글의 ‘각 프로젝트의 파일을 전부 지운다’는 표현도 실제 작업을 설명하기에는 거칠었다. 지워야 할 것은 중복 비밀값이었다. 실행 설정과 공개 식별자까지 없애는 일은 아니었다. 파일을 옮기기 전에 읽는 코드를 찾았다 각 프로젝트에서 비밀값을 가져오는 코드를 확인했다. Node.js의 환경변수 로더, Python 설정 클래스, 실행 스크립트가 같은 방식으로 값을 읽지는 않았다. 백업 파일을 뒤지는 경로와, 암호화 파일을 읽지 못하면 평문 파일로 돌아가는 경로도 정리 대상에 들어갔다. 이런 우회 경로가 남으면 공용 금고를 바꿔도 프로그램은 옛 값을 계속 가져올 수 있다. 그래서 파일 이동보다 먼저 로딩 순서를 맞췄다. 상황 이번 이관에서 정한 처리 실행 환경에 값이 명시적으로 들어온 경우 그 값을 유지한다 실행 환경에 값이 없는 경우 공용 금고에서 해당 값을 읽는다 프로젝트마다 같은 변수 이름을 쓰는 경우 금고에서는 프로젝트별 이름을 구분하고, 실행할 때 기존 이름으로 연결한다 금고를 읽지 못하는 경우 옛 평문 파일을 몰래 읽지 않고 오류를 낸다 마지막 줄이 중요했다. 실패할 때 예전 방식으로 돌아가는 코드는 이관 중에는 편해 보여도, 이후에는 어느 파일이 정본인지 흐리게 만든다. 공용 로더를 연결한 뒤에는 남아 있던 평문 우회 경로도 제거했다. 같은 이름이 같은 계정은 아니었다 여러 프로젝트가 같은 서비스의 토큰을 쓰더라도 계정과 용도가 같다는 보장은 없었다. 변수 이름만 보고 합치면 다른 계정의 값으로 실행될 수 있었다. 금고 안에서는 프로젝트별 이름을 구분했다. 각 프로그램이 기존에 사용하던 변수 이름은 유지하고, 실행 과정에서 필요한 값만 연결했다. 호출자가 명시적으로 넣은 값도 그대로 두었다. 이렇게 해야 로컬 작업용 값과 외부 실행 환경에서 주입한 값이 서로 덮어쓰지 않는다. 이 과정에서 작은 수정도 다시 확인했다. 한 실행 래퍼에서 불필요한 환경변수를 제거하려고 빈 값을 넣었는데, 자식 Node.js 프로세스에서는 변수가 여전히 존재하는 것으로 보였다. 변수를 실제로 제거하도록 바꾸고, 자식 프로세스에 남지 않는지 재검사했다. ‘값이 비어 있다’와 ‘변수가 없다’는 실행 코드에서 다르게 취급될 수 있었다. 수정한 줄만 보는 것으로는 부족했다. 인증 JSON도 파일 경로에 묶여 있었다 일부 Google 연동은 환경변수 대신 서비스 계정 JSON 파일을 직접 읽었다. 일반 API 키만 암호화하면 이 파일은 평문으로 남는 셈이었다. JSON도 금고에 암호화해 보관하고, 필요한 인증 코드에서 메모리로 읽도록 바꿨다. 원래의 파일 경로에 의존하던 세 곳을 먼저 전환한 뒤, 실제 SDK의 인증 객체를 구성하는 코드가 같은 자격증명을 받는지 확인했다. 원본 파일을 지운 뒤에도 같은 검사를 반복했다. 여기서 확인한 것은 인증 코드가 올바른 값을 전달받는다는 사실이다. Google에서 토큰을 발급받거나 데이터를 조회하고 수정하는 작업까지 실행한 것은 아니다. 로더 검사와 실제 서비스 인증은 별도의 확인이다. 삭제 전보다 삭제 후 검사가 더 중요했다 옛 파일이 남아 있는 상태에서 검사가 통과해도 새 로더만 사용했다고 단정할 수는 없다. 아직 남은 우회 경로가 값을 공급했을 수도 있기 때문이다. 그래서 값의 일치 여부와 복구본을 확인하고, 기존 코드의 읽기 경로를 검사한 뒤 중복값을 제거했다. 제거 후에도 같은 검사를 다시 실행했다. 이 순서로 로컬 파일 아홉 곳에서 중복된 비밀값 할당 22개를 정리했다. 파일에 함께 들어 있던 일반 설정은 남겼다. MCP 서버도 새 프로세스로 시작해 초기 연결과 도구 목록 응답을 확인했다. 다만 이미 켜져 있던 프로세스가 새 설정을 반영했다고 보지는 않았다. 오래 실행 중인 프로세스는 이전 환경값을 들고 있을 수 있다. 금고 내용이 바뀌면 최신 암호문 복구본을 갱신했다. 복호화 키가 든 기존 암호화 복구본은 유지했고, 갱신할 때마다 키를 다시 내보내지는 않았다. 암호문만 백업하고 키를 잃으면 복구할 수 없고, 둘을 함께 노출하면 암호화의 의미가 줄어든다. 마지막에는 빈 설정 파일과 일회성 이관 스크립트도 사용처를 확인해 정리했다. 계속 쓰는 로더와 회귀 검사는 남겼다. 이관 당시 필요했던 도구가 앞으로도 상시 필요한 것은 아니었다. 어디까지 끝났다고 말할 것인가 로컬 비밀값을 모으고, 확인한 읽기 경로를 전환한 뒤 중복값을 제거했다. 의존성이 빠져 시작하지 못하는 도구도 남아 있어 모든 프로그램이 정상 운영된다고 말할 수는 없다. 암호화도 같은 사용자 권한으로 실행되는 모든 프로세스를 서로 격리해 주지는 않는다. 금고에서 값을 꺼내는 래퍼가 곧 최소 권한 보장 장치가 되는 것은 아니었다. 필요한 값만 받는 코드와 전체 환경을 전달하는 실행 경로를 구분해 둬야 했다. 다음 프로젝트를 붙일 때는 금고에 키를 추가한 뒤 실제 실행 명령이 그 값을 어디서 읽는지 확인할 것이다. 복구본과 읽기 경로를 확인해 옛 중복값을 정리한 다음에도 같은 검사를 반복해야 한다. 이번에 오래 걸린 것은 키를 옮기는 일보다 각 프로그램이 그곳을 제대로 읽게 만드는 일이었다. 이 글은 2026년 10월 4일의 로컬 이관·정리 기록을 바탕으로 작성했다. 서비스 계정, 키 이름과 개인 경로는 일반화했다.