AI 에이전트 도구 호출, OAuth 승인만으로 충분할까? 실행 시점 허가를 설계하는 3패턴·6문항

⏱ 읽기 시간: 약 18분

이 글에서 얻을 수 있는 것: AI 에이전트가 OAuth로 승인된 도구를 호출할 때, ‘호출할 권한‘과 ‘지금 이 호출을 실행해도 되는가‘가 왜 다른 질문인지 이해하고, 실행 시점 허가를 설계하는 3가지 구체적 패턴을 배웁니다. 각 패턴의 장단점과 credential lifecycle 관리, 그리고 자신의 에이전트 스택에 바로 적용할 수 있는 6문항 결정표를 얻을 수 있습니다.

핵심 요약

OAuth scope는 ‘이 에이전트가 이 도구를 호출할 권한이 있는가’를 승인할 뿐, ‘지금 이 인수로 이 호출을 실행해도 되는가‘는 판단하지 않습니다. 이 두 질문은 구조적으로 다른 승인 축입니다.
실행 시점 허가를 설계하는 3가지 패턴이 있습니다: Pause-Resume Interrupt(일시 중단-재개), Dynamic Authorization Check(동적 정책 평가), Scope-Escalation Request(권한 확대 요청). 각 패턴은 상황에 따라 조합해 사용합니다.
승인을 기다리는 동안 credential이 만료·철회·범위 변경될 수 있습니다. 이 현실적 문제를 해결하는 Queue-Then-Execute 모델이 생산 시스템의 핵심입니다.
모든 tool 호출에 사람 승인이 필요한 것은 아닙니다. 6문항 결정표로 가역성·환경·감사 의무를 기준으로 필터링하면 자동 허용과 승인 게이트를 구분할 수 있습니다.
multi-agent 구조에서는 delegation chain 전체의 audit trace를 payload에 포함해야 감사 요건을 충족할 수 있습니다.

문제 제기: “OAuth 승인됐는데 왜 또 허가가 필요하지?”
개념 분리: OAuth scope vs 실행 시점 허가
3가지 승인 게이트 패턴
- Pause-Resume Interrupt
- Dynamic Authorization Check
- Scope-Escalation Request
3패턴 비교표
Credential Lifecycle: 승인 대기 중 발생하는 3가지 시나리오
Queue-Then-Execute 모델: 상태 기계로 보는 전체 구조
6문항 결정표: 지금 이 호출을 실행해도 될까?
Multi-agent 위임 체인과 Audit Trace 설계
FLOWIT 앵귤러: 이 패턴이 에이전트 자동화에 주는 의미
FAQ
참고 자료

이미지 설명: AI 에이전트(틸색 원형)가 두 개의 관문을 순서대로 통과한다. 왼쪽 관문은 열린 자물쇠로 OAuth scope(호출 권한)를, 오른쪽 관문은 방패 모양으로 실행 시점 허가(지금 실행해도 되는가)를 상징한다. 두 관문 사이에는 ‘정말 이 호출을 실행해도 될까?’라는 질문이 놓여 있다.

1. 문제 제기: “OAuth 승인됐는데 왜 또 허가가 필요하지?”

상상을 해보겠습니다. 여러분의 AI 에이전트가 GitHub OAuth를 통해 저장소 접근 권한을 받았습니다. 3주 전에 승인된 이 연결은 여전히 유효하고, 필요한 scope도 모두 포함되어 있습니다. 에이전트는 PR을 만들고, diff를 검토하고, 자동 merge를 실행했습니다.

누구도 그 특정 merge를 승인하지 않았습니다. 아무도 그 기회를 갖지 못했습니다.

이것은 prompt injection 이야기가 아닙니다. 탈취된 credential 이야기도 아닙니다. 에이전트는 설계된 대로 정확히 작동했고, scope는 해당 action을 포함했고, token은 살아 있었습니다. 모든 전통적인 인증 기준으로 보면 완전히 허가된 상태였습니다. 그러나 맥락적으로 허가된(contextually authorized) 상태는 아니었습니다. 아무도 “지금 이 diff를, 이 인수로, 이 브랜치에 merge하라”고 말하지 않았습니다.

이 간극, 즉 “기술적으로 허가됨”과 “맥락적으로 허가됨” 사이의 차이가 생산 에이전트 시스템이 silently 실패하는 지점입니다.

🔑 핵심 통찰: OAuth는 승인 시점의 단일 질문만 답합니다. 실행 시점의 구체적 맥락(어떤 인수로, 어떤 환경에서, 어떤 시점에)은 모델링하지 않습니다. 이 간극을 메우는 것이 실행 시점 허가(approval gate)의 역할입니다.

2. 개념 분리: OAuth scope와 실행 시점 허가는 다른 질문이다

OAuth scope는 grant-time primitive입니다. 사용자가 에이전트를 승인할 때 하나의 질문에 답합니다: “이 에이전트가 이 도구 범주의 호출을 할 수 있어야 하는가?” 이 결정은 동의 시점에 한 번 이루어지고, 결과 token은 이후 모든 tool 호출에 carry-forward됩니다.

이 구조는 읽기(read) 작업에는 잘 작동합니다. 읽기의 위험 프로필은 에이전트가 데이터로 무엇을 하는지에 의해 제한됩니다. 작업 자체는 비파괴적이고, 3주 전의 scope 승인은 오늘의 사용자 의도에 대한 합리적인 대리자가 될 수 있습니다.

쓰기(write) 작업은 구조적으로 다릅니다. Anthropic의 Trustworthy Agents 프레임워크에서는 이를 세 가지 축으로 분석합니다:

비가역성(Irreversibility): DELETE /record/8823, POST /merge, PATCH /account/billing — token 실행 후에는 token을 철회해도 실행 자체를 되돌릴 수 없습니다. 철회는 그 시점에서 이미 사후 대응(forensic)일 뿐, 보호 조치가 아닙니다. Anthropic은 이 비가역성을 별도의 위험 축으로 정의하고, 에이전트가 가역적 행동을 우선하고 비가역적 행동에 더 좁은 범위를 요청하도록 설계해야 한다고 명시합니다.
감사 의무(Audit Obligation): SOC 2는 각 action 시점에 논리적 접근 통제가 작동 중이었다는 증거를 요구합니다. GDPR은 처리 기록이 실행 주체와 연결된 명확한 법적 근거를 갖출 것을 요구합니다. 대부분의 엔터프라이즈 보안 검토는 writes가 “에이전트에게 scope가 있었다”가 아니라 “사람이 이 특정 작업을 이 타임스탬프에 승인했다”는 증거를 요구합니다. OAuth scope grant는 이 요건을 충족하지 않습니다. 승인 이벤트(approval event)는 충족합니다.
동적 위험 맥락(Dynamic Risk Context): Salesforce에서 한 개 필드를 sandbox에서 업데이트하는 호출과 10,000개 production 레코드를 bulk 업데이트하는 호출은 동일한 OAuth scope를 공유합니다. 위험 프로필은 동일하지 않습니다. 정적 scope는 그 차이를 모델링할 수 없습니다. 실행 시점의 맥락적 허가만이 가능합니다.

구조적 결론을 정리하면 이렇습니다. OAuth는 “이 에이전트가 이 도구를 호출할 권한이 있는가”를 답합니다. 승인 게이트(approval gate)는 “이 호출이 이 인수로, 이 맥락에서 실행되어야 하는가”를 답합니다. 이 두 질문은 서로 다른 승인 축이며, write 실행 전에는 반드시 두 질문 모두에 답해야 합니다.

3. 세 가지 승인 게이트 패턴

아래 세 패턴은 상호 배타적이지 않습니다. 생산 시스템에서는 이들이 조합됩니다. Pattern B는 모든 write를 분류하고, 정책 평가 결과에 따라 Pattern A나 Pattern C로 라우팅합니다. 각각을 개별적으로 이해하는 것이 이들이 어떻게 조합되는지 이해하기 위한 전제 조건입니다.

Pattern A: Pause-Resume Interrupt (일시 중단-재개)

에이전트가 write tool 호출에 도달하면, 실행하는 대신 보류 중인 invocation을 직렬화하고 승인 요청을 발행합니다. 실행이 차단되고, 에이전트의 그래프는 write 노드에 전체 상태를 보존한 채 정지(park)됩니다. 승인 신호가 도착할 때까지 기다립니다.

LangGraph에서의 구현: LangGraph의 권장 방식은 interrupt()를 노드 내부에서 호출하여 그래프를 일시 중단하고 payload를 호출자에게 반환하는 것입니다. 그래프는 정확히 그 라인에서 멈추고, 호출자가 결정을 보내면 실행이 재개됩니다. 전체 state snapshot은 checkpointer에 보존됩니다. checkpointer가 설정되지 않았다면 interrupt()는 state를 저장할 곳이 없어 패턴이 동작하지 않습니다.

OpenAI Agents SDK에서의 구현: 동일한 패턴이 RunState 직렬화로 표현됩니다. 실행은 보류 중인 승인을 interruption으로 표시하고, RunState를 디스크에 직렬화했다가 reload한 후 결정을 수집해 원래 실행을 재개합니다.

⚠️ 중요한 실무 포인트: 승인 payload에는 credential_status가 반드시 포함되어야 합니다. 승인이 도착하기 전에 연결된 계정의 token이 만료되거나 철회된다면, 에이전트는 재개 시점에 401 오류를 받기 전이 아니라 상태를 확인할 수 있어야 합니다. 직렬화 시점에 상태를 포함하면 재개 경로에서 tool을 호출하기 전에 확인할 수 있습니다.

장점: 구현이 직관적이고, 주요 프레임워크(LangGraph, OpenAI Agents SDK)가 이미 interrupt 프리미티브를 제공합니다. 전체 컨텍스트가 보존되므로 승인 후에 중단 없이 재개할 수 있습니다.

단점: 인간의 응답 시간에 전적으로 의존합니다. 승인에 4시간이 걸리면 에이전트의 checkpoint를 4시간 동안 유지해야 합니다. 장기 실행 에이전트에 동시 다중 보류 승인이 있으면 checkpoint 저장소가 용량 문제를 일으킬 수 있습니다.

Pattern B: Dynamic Authorization Check (동적 정책 평가)

모든 write에 사람이 개입할 필요는 없습니다. 일부 write는 위험이 낮아 미리 정의된 정책에 따라 진행해도 되고, 일부는 위험이 높아 즉시 차단해야 하며, 일부는 회색 영역으로 Pattern A로 에스컬레이션됩니다. Pattern B는 모든 write를 이 세 가지 결과 중 하나로 라우팅하는 분류기(classifier)입니다.

로그인 시점의 IAM 역할 확인과의 중요한 차이: 이 평가는 도구 호출 시점(tool invocation time)에 이루어집니다. 동일한 사용자가 동일한 OAuth grant를 가지고 있더라도, 실행 맥락에 따라 다른 결과를 받을 수 있습니다.

평가 입력 예시:

입력 필드	예시 값	출처
user_role	developer	JWT claim
tool_name	github_merge_pull_request	Tool invocation metadata
resource_path	refs/heads/main	바인딩된 tool 인수
environment	production	Deployment context
operation_scope	bulk vs single	인수 분석에서 파생

“개발자는 feature/* 브랜치에 merge할 수 있지만 main에는 merge할 수 없고, main으로의 merge는 사람 승인이 필요하다”는 정책은 OAuth scope만으로는 표현할 수 없습니다. resource_path를 호출 시점에 평가해야 합니다. refs/heads/main의 정책 결과는 ESCALATE(Pattern A로 라우팅)이고, refs/heads/feature/billing-refactor의 결과는 ALLOW입니다.

장점: 위험이 낮은 작업은 자동으로 처리하여 인간 개입의 피로도를 줄입니다. 세분화된 정책으로 다양한 시나리오를 처리할 수 있습니다.

단점: 정책 유지보수는 실제 비용이 듭니다. 너무 광범위한 정책(모든 것을 escalate)은 분류기의 의미를 무효화하고, 너무 좁은 정책은 사각지대를 남깁니다. production 환경에서 default-deny 자세로 시작하고 명시적 allow를 carve-out하며 모든 BLOCK과 ESCALATE를 로깅하여 정책을 튜닝하는 것이 좋습니다.

Pattern C: Scope-Escalation Request (권한 확대 요청)

에이전트가 작업 중 현재 사용자의 승인 범위에 포함되지 않은 scope가 필요한 write에 도달했습니다. 순진한 구현은 403으로 실패합니다. 과잉 보상 구현은 에이전트 설정 시점에 가능한 최대 scope를 미리 부여합니다. 이것은 최소 권한 원칙(least-privilege)을 위반하고 모든 엔터프라이즈 보안 검토에서 실패합니다.

올바른 구현: 연결된 계정에 필요한 권한이 없음을 감지하고, 사용자에게 대상이 명확한 재동의 요청(targeted re-consent request)을 표시하며, 사용자가 완료한 후에만 재개합니다.

이것은 조용한 백그라운드 token 교환이 아닙니다. 명시적 사용자 조치가 필요합니다. 사용자는 어떤 연결이 업데이트된 접근을 요청하는지 정확히 확인할 수 있습니다. 그 동의 이벤트가 “사람이 이 타임스탬프에 이 scope 확장을 승인했다”는 감사 기록입니다.

장점: 최소 권한 원칙을 유지하면서 필요한 경우에만 scope를 확장합니다. 명시적 동의 이벤트가 감사 요건을 충족합니다.

단점: 작업 중간에 사용자 상호작용을 차단합니다. 백그라운드 에이전트(사용자 세션이 활성화되지 않은 상태에서 실행되는)의 경우 scope 확장이 불가능합니다. 이런 경우 에이전트는 명확한 오류와 함께 실패해야 하며, 조용히 scope를 획득하려고 시도해서는 안 됩니다.

이미지 설명: 세 가지 패턴의 수평 타임라인. 각 패턴은 agent 호출(dot) → 게이트(triangle) → 인간 확인 또는 생략 → 실행(check)의 흐름으로 구성된다. Pause-Resume은 게이트와 인간 확인 사이의 대기 간격이 길고, Dynamic Auth는 즉시 통과하며, Scope-Escalation은 인간 확인을 거친 후 실행된다.

4. 3패턴 비교표

기준	Pause-Resume Interrupt	Dynamic Authorization Check	Scope-Escalation Request
지연 시간	인간 응답 시간에 의존 (분~시간)	정책 평가 시간 (밀리초~초)	인간 재동의 시간 (분)
Audit 가능성	높음 — 명시적 승인 이벤트	중간 — 정책 평가 로그	높음 — 재동의 이벤트
구현 비용	낮음 — 프레임워크 내장 프리미티브	중간 — 정책 엔진 개발 필요	중간~높음 — re-consent UI 필요
사용 사례	고위험 단일 write (production merge, 결제)	대량 write 분류 (bulk update 필터링)	현재 scope를 초과하는 작업
인간 개입	항상 필요	ESCALATE 결과일 때만	권한 부족 시 항상
백그라운드 에이전트	부적합 (인간 세션 필요)	적합 (정책 기반 자동 판단)	부적합 (재동의 불가)

5. Credential Lifecycle: 승인 대기 중 발생하는 3가지 시나리오

대부분의 승인 게이트 구현이 건너뛰는 부분입니다. 생산 시스템이 설계 시점이 아니라 오후 11시 47분에 실제로 고장 나는 지점입니다. 승인 요청이 오전 10시 15분에 제출되었는데 마침내 승인이 도착한 시점입니다.

연결된 계정(connected account)의 상태는 명시적 상태로 모델링됩니다: PENDING, ACTIVE, EXPIRED, REVOKED, ERROR. 승인 대기 중에 이 상태가 변하는 세 가지 시나리오가 있습니다.

시나리오 1: EXPIRED — token 만료

사용자의 OAuth token이 승인 대기 중에 만료됩니다. Scalekit 등 vault 솔루션은 refresh token을 사용해 access token을 자동 갱신하지만, refresh token 자체가 만료되었거나 provider가 재동의를 요구하면 계정이 EXPIRED 상태로 전이됩니다.

올바른 처리: 오류를 받은 후가 아니라 실행 전에 connected_account.status를 확인합니다. 상태가 ACTIVE가 아니라면, 재인증을 요청하고 실행하지 않습니다.

시나리오 2: REVOKED — 권한 철회

사용자가 승인 대기 중에 provider의 연결된 앱 페이지에서 에이전트의 OAuth grant를 철회합니다. Webhook이 이 이벤트를 실시간으로 전달할 수 있습니다. 구독하고 있다면, 기본 credential 상태가 변경되었을 때 보류 중인 승인 요청을 즉시 취소할 수 있습니다.

올바른 처리: Webhook은 실시간 신호, 재개 시점의 get_connected_account() 상태 확인은 안전망입니다. 둘 다 필요합니다.

시나리오 3: SCOPE_CHANGED — scope 변경

승인 요청과 재개 사이에 연결의 설정된 scope가 변경됩니다(예: 관리자가 scope를 축소). vault가 재승인 이벤트를 발행합니다.

올바른 처리: 재개 시점에 connected_account.status를 먼저 확인합니다. 계정이 ACTIVE가 아니라면, Pattern C(Scope-Escalation)로 에스컬레이션합니다. 실행 전에 상태를 확인하면 명확하고 실행 가능한 신호를 생성합니다. downstream API의 403은 그렇지 않습니다.

6. Queue-Then-Execute 모델: 상태 기계로 보는 전체 구조

세 패턴이 무엇을 확인할지 설명했다면, 이제 이 모든 것을 승인 대기 기간 동안 함께 유지하는 인프라를 조립합니다.

이미지 설명: 5개 상태로 구성된 상태 기계. pending_approval → awaiting_human → credential_check → executing → complete의 메인 플로우와 credential_check 노드에서 EXPIRED(갱신), REVOKED(재인증), SCOPE_CHANGED(재동의)로 분기하는 복구 경로가 있다.

Queue가 단순 확인 대화상자와 다른 이유: Queue는 승인 지연을 에이전트 실행 지연에서 분리합니다. 몇 시간이 걸리는 승인이 에이전트 런타임 스레드를 차단하거나 checkpoint 메모리를 점유하지 않습니다. 여러 보류 승인을 일괄 처리, 우선순위 지정, 서로 다른 검토자에게 독립적으로 라우팅할 수 있습니다.

Vault가 credential 신선도를 승인 타이밍에서 분리하는 이유: 에이전트는 승인 대기 기간 동안 raw token이 아닌 connection_name과 identifier만 가지고 있으므로, 대기 중 token 갱신이 승인 흐름에 보이지 않습니다(invisible).

🏗️ 구현 참고: Queue 자체(라우팅, 검토자 할당, 승인 이벤트 저장, TTL 적용, 재개 트리거)는 애플리케이션 계층의 책임입니다. Vault는 Queue 양쪽의 credential 인프라를 처리합니다. Queue 내부에서 일어나는 일은 여러분이 구축하고 소유합니다.

7. 6문항 결정표: 지금 이 호출을 실행해도 될까?

모든 tool 호출에 사람 승인이 필요한 것은 아닙니다. 아래 6문항으로 필터링하면 자동 허용과 승인 게이트를 구분할 수 있습니다.

이 호출이 가역적인가? — 되돌릴 수 있는 작업(SELECT, GET, staging 환경 write)은 자동 허용. 되돌릴 수 없는 작업(DELETE, production merge, 결제)은 승인 게이트.
단일 레코드인가 bulk인가? — 단일 레코드는 낮은 위험으로 자동 허용 가능. Bulk(10,000 레코드 update)는 반드시 승인 필요.
Production 환경인가? — 개발/staging의 write는 완화된 정책. Production write는 모든 게이트 통과 필수.
감사 의무가 있는가? — SOC 2, GDPR, SOX 대상 데이터는 항상 승인 게이트 통과. 감사 증거로 승인 이벤트가 필요.
자동화된 fallback이 있는가? — 실패해도 안전한 fallback 경로가 있다면 자동 허용 가능(예: 1차 API 실패 시 2차 API로 fallback).
사람의 현재 세션이 활성화되어 있는가? — 사용자 세션이 활성화되어 있다면 Pattern A(C)로 에스컬레이션 가능. 세션이 없다면 Pattern B(정책 기반)로만 처리.

이미지 설명: 수직형 결정 플로우. 6개의 질문(가역성·단일성·환경·감사·fallback·세션)을 순서대로 통과하며, 모든 조건 충족 시 ‘실행 허가'(초록색), 하나라도 충족하지 않으면 ‘일시 중단'(앰버색)으로 수렴한다.

이 결정표는 범용 프레임워크입니다. 각 팀은 자신의 위험 허용도와 규제 요건에 따라 가중치와 기준을 조정해야 합니다. 예를 들어 금융 서비스 팀은 ‘감사 의무’ 문항의 가중치를 높이고, 내부 도구 팀은 ‘가역성’ 문항을 더 엄격하게 적용할 수 있습니다.

8. Multi-agent 위임 체인과 Audit Trace 설계

sub-agent가 상위 orchestrating agent를 대신하여 tool을 호출하는 multi-agent 워크플로에서, 보류 중인 invocation payload는 즉시 호출 에이전트의 identity뿐만 아니라 전체 위임 체인(full delegation chain)을 포함해야 합니다.

승인자가 확인해야 하는 것은 누가 authority를 누구에게 위임했는지, 원래 triggering 사용자까지 추적하는 것입니다. sub-agent의 identity만 표시하고 위임 체인을 표시하지 않는 승인은 SOC 2 또는 HIPAA 추적 요건의 action 속성 조건을 충족하는 감사 기록을 생성할 수 없습니다.

권장 구현: 상위 delegator의 ID를 하위 호출까지 전파하는 audit trace 필드를 payload에 포함합니다. 예를 들어:

delegation_chain: [user_123 → orchestrator_agent_1 → sub_agent_3]
root_correlation_id: 원래 워크플로 실행의 ID
approval_id: 각 게이트의 고유 ID (모든 승인이 동일한 root_correlation_id를 공유)

이렇게 하면 감사자가 전체 결정 순서를 재구성할 수 있습니다: 어떤 write가 정책에 의해 자동 허용되었고, 어떤 것이 에스컬레이션되었고, 어떤 것이 승인·거부되었고, 어떤 순서로 발생했는지.

9. FLOWIT 앵귤러: 이 패턴이 에이전트 자동화에 주는 의미

🤖 FLOWIT 실무 관점: AI 에이전트 자동화에서 가장 위험한 가정은 “일단 승인된 연결은 계속 유효하다”는 것입니다. FLOWIT의 경험상, 자동화 파이프라인이 실패하는 지점은 모델 성능이 아니라 권한 경계(permission boundary)입니다. 권한이 너무 넓으면 예기치 않은 write가 발생하고, 너무 좁으면 자동화가 자주 중단됩니다.

코딩 에이전트 자동화 파이프라인에서 이 패턴이 중요한 이유는 다음과 같습니다:

CI/CD 파이프라인에서 PR merge는 비가역적 write입니다. Pause-Resume 패턴으로 사람 승인을 받기 전까지 merge를 차단할 수 있습니다.
여러 저장소를 관리하는 orchestrator는 Dynamic Auth 패턴으로 각 저장소의 중요도에 따라 정책을 다르게 적용할 수 있습니다.
백그라운드 코드 리뷰 에이전트는 Pattern B(정책 기반)로 대부분의 리뷰를 자동 처리하고, 보안·비용 관련 리뷰만 Pattern A로 에스컬레이션할 수 있습니다.
Credential lifecycle 관리는 자동화 파이프라인이 밤사이 만료된 token으로 인해 아침에 실패하는 것을 방지합니다.

10. FAQ

Q: OAuth로 이미 인증했는데, 왜 실행 시점에 또 허가가 필요한가요?

A: OAuth scope는 ‘이 에이전트가 이 API를 호출할 권한이 있는가’를 승인할 뿐, ‘지금 이 레포지토리에 이 브랜치로 push해도 되는가’라는 구체적 실행 맥락은 판단하지 않습니다. 실행 시점 허가는 이 두 번째 질문을 다룹니다. 비유하자면, 건물 출입증(scope)이 있다고 해서 모든 방의 모든 서랍을 열 수 있는 것은 아닙니다.

Q: 3패턴 중 어떤 것을 먼저 도입해야 하나요?

A: 가장 단순한 Pause-Resume Interrupt부터 시작하는 것을 권장합니다. LangGraph, OpenAI Agents SDK, Claude Code 등 주요 프레임워크가 이미 interrupt 프리미티브를 제공하므로 구현 비용이 가장 낮습니다. 이후 Dynamic Auth로 정책 기반 자동 분류를 추가하고, 필요할 때 Scope-Escalation으로 확장할 수 있습니다. 하이브리드 구성(Pause-Resume + Dynamic Auth 병행)도 가능합니다.

Q: 승인을 기다리는 동안 credential이 만료되면 어떻게 하나요?

A: Queue-Then-Execute 모델에서 pending_approval 상태의 작업은 credential 상태를 지속적으로 모니터링합니다. EXPIRED면 refresh token으로 갱신을 시도하고, REVOKED면 승인 요청을 취소하고 재인증을 요청하며, SCOPE_CHANGED면 새로운 scope로 승인 요청을 재작성합니다. 어떤 경우든 실행 전에 credential 상태를 확인하고, ACTIVE 상태가 아니라면 실행하지 않습니다.

Q: 모든 tool 호출에 사람 승인이 필요한가요?

A: 아닙니다. 6문항 결정표로 가역성·환경·감사 의무를 기준으로 필터링합니다. 예를 들어 staging DB의 SELECT 쿼리는 자동 허용하고, production의 DELETE만 승인 게이트를 통과하도록 설계할 수 있습니다. 목표는 필요한 곳에만 사람 개입을 두고, 나머지는 효율적으로 자동화하는 것입니다.

Q: multi-agent 구조에서도 이 패턴이 동작하나요?

A: 네, 단 delegation chain에서 어떤 에이전트가 어떤 tool을 호출했는지 audit trace를 payload에 포함해야 합니다. 상위 delegator의 ID를 하위 호출까지 전파하는 설계가 필요하며, 승인 화면에는 누가 누구에게 권한을 위임했는지 전체 체인이 표시되어야 감사 요건(SOC 2, HIPAA)을 충족할 수 있습니다.

11. 참고 자료

Human-in-the-Loop Tool Calling: Approval Gates for AI Agents — Scalekit 기술 블로그, 2026-05-26. OAuth scope와 실행 시점 허가의 개념적 차이, 3패턴, credential lifecycle 문제, queue-then-execute 모델.
Trustworthy Agents — A Framework for Building Capable and Auditable Agents — Anthropic 공식 연구/프레임워크, 2026-04-09. 비가역성(irreversibility)을 별도 위험 축으로 정의하고 agent 설계 원칙을 제시.
Human-in-the-Loop: A 2026 Guide to AI Oversight — Strata 기술 블로그, 2026-05-11. HITL을 AI governance 접근법으로 정의하는 프레임워크.
LangGraph Human-in-the-Loop Documentation — LangChain 공식 문서. interrupt()를 통한 그래프 중단과 재개, checkpoint persistence.

이 글이 마음에 드세요?

RSS 피드를 구독하세요!

FLOWIT on YouTube

영상으로도 FLOWIT을 이어서 보세요

AI 자동화, Claude Code, n8n, 데이터 분석 흐름을 블로그와 영상으로 함께 정리하고 있습니다.

YouTube 채널 보기