에이전트의 인증 설계 ─ 여러 서비스에 연결할 때의 사고방식

지난 기사에서는 에이전트에게 전용 계정(신원)을 부여하는 것에 대해 이야기했습니다.

전용 계정이 생겼다고 가정하면, 다음 질문이 생깁니다.

에이전트는 어떻게 각 서비스에 접속하는가?

메일을 보내려면 Gmail에, 파일을 두려면 Drive에, 회의를 만들려면 캘린더에 각각 인증이 필요합니다. 게다가 서비스마다 인증 방식이 다르며, "누구의 권한으로 액세스할 것인가"라는 판단도 매번 필요합니다.

이번에는 여러 서비스에 접속하는 에이전트의 인증 설계에 대해 정리합니다.

접속하는 서비스와 용도에 따라 인증 패턴은 크게 2가지로 나뉩니다.

패턴	설명	주요 용도
A. 에이전트 자신의 권한	에이전트의 계정으로 접속한다	메일 전송·회의 생성·공유 폴더 조작 등
B. 의뢰자의 권한을 빌린다	의뢰자가 인가한 권한으로 액세스한다	의뢰자 본인의 메일·캘린더·파일을 참조할 때

판단 기준은 심플합니다.

"누구의 데이터에 액세스하는가?"
공유 리소스(팀의 공유 폴더·회의실·전송 메일 등)
→ 패턴 A
...

에이전트 전용 계정으로 OAuth 인증을 수행하고, 취득한 토큰을 서버 상에 보관합니다.

최초 셋업
↓
에이전트 계정으로 OAuth 인가 플로우를 실행
...

실운용에서는 액세스 토큰(Access Token)이 몇 시간 만에 만료됩니다. 리프레시 토큰(Refresh Token)을 사용하여 자동으로 갱신하는 메커니즘을 구축해 두지 않으면, 밤중에 토큰이 끊겨 에이전트가 멈추게 됩니다.

agent/
└── credentials/
└── {service}/
...

토큰 파일은 .gitignore로 리포지토리(Repository)에서 제외하고, 백업은 암호화하여 별도 경로로 관리합니다.

의뢰자가 "내 캘린더를 보여줘", "내 메일을 확인해줘"라고 의뢰하는 경우, 에이전트 자신의 권한으로는 액세스할 수 없습니다.

이 경우, 의뢰자에게 단 한 번 인가를 받고, 사용자별로 토큰을 분리하여 보관합니다.

의뢰자에 대한 인가 플로우
↓
에이전트가 인가 URL을 발행
...

보관 장소는 사용자별로 분리합니다.

agent/
└── credentials/
└── {service}/
...

중요한 설계 원칙으로서, 특정 사용자의 토큰을 다른 의뢰자의 요청에 유용하지 않습니다. 설령 관리자가 "대신 액세스해 달라"고 부탁하더라도, 해당 사용자 본인이 인가하지 않는 한 그 사용자의 리소스에는 액세스하지 않습니다.

접속하는 서비스마다 인증 방식이 다릅니다. 대표적인 것을 정리하면 다음과 같습니다.

서비스	방식	주의점
Google Workspace	OAuth 2.0	스코프(Scope, 허가 범위)를 최소한으로 좁힐 것
...

특히 레거시 시스템의 Cookie 인증은 유효 기간이 몇 시간~1일 정도인 경우가 많아, 만료를 감지하여 자동으로 재인증하는 메커니즘이 필요합니다.

인증에 관해서는, "할 수 없다면 멈춘다"를 원칙으로 하고 있습니다.

Skill 실행 전
↓
토큰의 유효성을 확인
...

"토큰이 만료되었지만 일단 실행해 보았다"라는 상태는 만들지 않습니다. 인증되지 않은 상태에서 처리가 진행되어 버리면, 에러가 후단에서 발생하여 원인을 특정하기 어려워집니다.

의뢰자에 대한 통지도 잊지 않고 넣습니다. "왜인지 답장이 오지 않는다"가 아니라 "인증 기간이 만료되었으므로 재인가를 부탁드립니다"라고 전달할 수 있는 상태로 만듭니다.

인증 정보는 모두 리포지토리에 포함하지 않습니다.

관리 규칙
─ 토큰 파일은 .gitignore로 제외
─ 백업은 암호화하여 별도 경로로 보관
...

에이전트가 서버로서 상시 가동되는 경우, 인증 정보는 에이전트의 "신분 증명서"입니다. 분실·유출 시의 영향이 크기 때문에 백업과 실효(만료) 절차를 사전에 준비해 둡니다.

에이전트의 인증 설계를 정리하면 다음과 같습니다.

┌─────────────────────────────────────────┐
│ 패턴 A: 에이전트 자신의 권한 │
│ ─ 공유 리소스에 대한 액세스 │
...

• ✅ 여러 서비스로의 연결을 패턴 A / B의 두 축으로 정리할 수 있음
• ✅ 요청자별로 권한을 분리함으로써 보안을 보장할 수 있음
• ✅ fail-closed (실패 시 차단)를 통해 인증 실패가 후속 단계로 파급되지 않음

인증은 눈에 띄지 않는 영역이지만, 에이전트가 "누구의 권한으로 무엇에 액세스하고 있는가"가 항상 명확한 것이 자율적으로 동작하는 에이전트에 대한 신뢰의 기반이 됩니다.