[AI 자동화] 클라우드 자동 요약 기능 구현으로 본 Refresh Token 암호화 저장과 Secret Manager 활용법

자동 실행에 Refresh Token이 필요한 이유: 로그인 없이 Access Token 재발급

Refresh Token은 사용자가 다시 로그인하지 않아도 새로운 Access Token을 발급받을 수 있게 하는 인증정보입니다. Google이나 Outlook 계정을 연결하면 데이터 접근에 필요한 토큰이 발급되며, Access Token은 유효기간이 짧아 만료되면 새로 발급받아야 합니다.

자동 실행 기능은 사용자의 현재 로그인 상태를 활용할 수 없습니다. 자동 실행 기능이 필요한 시점에 Access Token을 발급받으려면 백엔드가 Refresh Token을 보관하고 있어야 합니다.

첫 구현에서는 사용자별 Refresh Token을 Firestore에 저장하고, 클라우드의 요약 기능이 실행될 때 해당 값을 불러오도록 구성했습니다. Firestore 저장 방식으로 자동 실행 문제는 해결되었지만, 보안 측면의 확인이 추가로 필요했습니다.

Firestore 저장 방식의 한계: 일반 데이터와 비밀정보의 접근 범위 미분리

Firestore에 Refresh Token을 암호화하지 않고 원래 값 그대로 저장하면, Firestore 열람 권한을 가진 공동작업자도 해당 값을 확인하고 복사할 수 있습니다. 토큰을 로컬 환경에서 클라우드로 옮겨 자동 실행은 가능해졌지만, 일반 데이터와 비밀정보의 접근 범위까지 분리된 것은 아니었습니다.

공동작업자가 업무 데이터를 확인하기 위해 Firestore에 접근할 필요는 있어도, 사용자의 Google이나 Outlook 계정에 접근할 수 있는 Refresh Token까지 확인할 필요는 없습니다. 따라서 일반 데이터의 열람 권한과 비밀정보의 접근 권한을 구분할 방법이 필요했습니다.

Secret Manager 정의: 비밀정보를 일반 데이터와 분리해 관리하는 Google Cloud 서비스

Secret Manager는 API 키, 비밀번호, 인증 토큰, 암호화 키처럼 외부에 공개되면 안 되는 값을 일반 데이터 및 소스코드와 분리해 관리하는 Google Cloud 서비스입니다. Firestore가 서비스에서 사용하는 데이터를 저장하는 곳이라면, Secret Manager는 제한된 프로그램이나 사용자만 접근해야 하는 비밀정보를 관리하는 데 목적이 있습니다.

Refresh Token 관리 방식

이번 프로젝트에서는 사용자별 Refresh Token을 모두 Secret Manager로 옮기지는 않았습니다. Refresh Token은 사용자마다 생성되고 갱신되는 데이터이므로 Firestore에 암호화해 저장하고, 암호화된 토큰을 다시 사용할 때 필요한 키만 Secret Manager에 별도로 보관했습니다.

Google 연동에 먼저 이 구조를 적용했고, 이후 Outlook 토큰을 처리하는 일부 기능에도 같은 구조를 적용해 보완했습니다.

Cloud Scheduler와 Cloud Function으로 실행되는 자동 요약 과정

Cloud Scheduler는 자동 요약을 언제 실행할지 관리하고, Cloud Function은 데이터 조회와 요약 생성 등 실제 작업을 수행합니다. 정해진 시간이 되면 다음 순서로 자동 요약이 진행됩니다.

Cloud Scheduler는 실행 시점만 관리하며 인증정보를 직접 다루지 않습니다. 이 구조를 통해 사용자의 PC가 꺼져 있어도 자동 요약을 실행하면서, Firestore를 열람할 수 있다는 이유만으로 사용자 토큰의 원래 값까지 확인할 수는 없도록 접근 범위를 분리했습니다.

바이브 코딩에서 Secret Manager를 쓰는 장점 4가지

Secret Manager의 장점은 비개발자 입장에서 기술적 기능보다, 바이브 코딩 과정에서 발생할 수 있는 실수를 줄여 준다는 점에 있습니다.

코드와 AI 대화에서 실제 키 제외

API 키를 코드에 직접 입력하면 Git에 함께 올라가거나, 오류 해결을 위해 코드를 AI에게 전달하는 과정에서 실제 값이 노출될 수 있습니다. Secret Manager를 사용하면 코드에는 비밀정보를 불러오는 방식만 남습니다.

실제 값 공유 없이 공동작업

API 키를 메신저나 문서로 공유하면 복사본이 늘어납니다. Secret Manager는 실제 값을 사람에게 전달하지 않고, 해당 기능을 실행하는 프로그램에만 접근 권한을 줄 수 있습니다.

일반 데이터와 비밀정보의 접근 범위 분리

공동작업자가 Firestore의 업무 데이터를 확인할 필요는 있어도, 사용자 토큰이나 암호화 키까지 확인해야 하는 것은 아닙니다. 이번 구조에서도 Firestore에는 암호화된 토큰만 저장하고, 복호화 키는 Secret Manager에서 별도로 관리했습니다.

변경 위치 명확화

API 키가 만료되거나 노출되면 새로운 값을 발급해야 합니다. Secret Manager에서 관리하면 새 값을 등록할 위치가 명확해지며, 실제 서비스 반영에는 재시작이나 재배포가 필요할 수 있습니다.

공동작업 환경에서 인증정보 접근 범위를 구분해야 하는 이유

여러 사람이 하나의 리포지토리에서 공동작업하는 환경에서는 인증정보 설정이 뒤섞여 의도치 않게 다른 사람의 토큰을 사용하는 일이 생길 수 있습니다. 내부 개발 단계에서는 작은 해프닝으로 끝나더라도, 이용자 범위가 넓어진 정식 배포 환경에서는 다른 사용자의 데이터에 접근하는 더 큰 보안 문제로 이어질 수 있습니다.

비밀정보는 코드 밖에 저장하는 데 그치지 않고, 사용자와 프로그램별로 접근 범위를 구분해 안전하게 관리하는 것이 중요합니다. 바이브 코딩으로 기능을 빠르게 구현하는 만큼, 해당 기능이 어떤 인증정보를 사용하고 누구의 정보에 접근하는지도 함께 확인할 필요가 있습니다.

자주 묻는 질문