LangChain 빌더 여러분: 권한 부여 로직은 어디에 두고 계신가요?
LangChain builders: where does your authorization logic actually live?
핵심 요약
AI 에이전트의 고위험 작업 수행 시 권한 부여 로직을 개별 툴에 둘지, 중앙 정책 엔진을 사용할지 아키텍처를 논의합니다.
- 권한 부여 아키텍처 — 에이전트의 툴 실행 전 정책 평가를 통한 중앙 집중식 관리 방안
- 툴 수준 로직 — 개별 툴마다 권한 검사를 구현할 경우 발생하는 코드 중복 문제
- 정책 엔진 활용 — OPA, Cedar, Casbin 등을 활용한 권한 검증 아키텍처 실험
- 실무 경험 공유 — 에이전트 시스템 구축 시 프로덕션 환경에서 검증된 권한 관리 방식 탐색
우리는 AI 에이전트를 위한 인프라를 만들고 있는데, 아키텍처와 관련해서 계속 머릿속을 떠나지 않는 질문이 하나 있어.
프롬프팅도 아니고.
메모리도 아니고.
툴 호출도 아니야.
바로 권한 부여(Authorization) 문제지.
LangChain 에이전트가 다음과 같은 일을 할 수 있다고 가정해 보자.
• Stripe 환불 처리
• Gmail 이메일 발송
• Salesforce 업데이트
• GitHub 풀 리퀘스트 생성
• n8n 워크플로우 트리거
• 클라우드 리소스 프로비저닝
에이전트한테 이런 툴들에 대한 접근 권한을 주는 건 일도 아니야.
진짜 골치 아픈 건 특정 동작을 실제로 실행할지 말지 결정하는 거지.
예를 들면 이런 식이야.
- 10,000달러가 넘는 환불은 재무팀 승인이 필요함.
- 프로덕션 배포는 엔지니어 승인이 필요함.
- 대량의 고객 데이터 내보내기는 보안팀 승인이 필요함.
- AI가 관리자 계정을 자동으로 생성하면 안 됨.
- 고객 데이터가 포함된 이메일은 회사 밖으로 나가면 안 됨.
지금까지 내가 본 대부분의 구현 방식은 이런 로직을 각 툴 주변에 직접 박아 넣는 거였어.
대충 이런 식이지.
if refund_amount > 10000:
interrupt()
아니면
if production:
require_human()
처음엔 이게 잘 돌아가.
근데 여러 에이전트, 애플리케이션, 워크플로우가 똑같은 비즈니스 규칙을 따라야 하는 상황이 오면, 이런 체크 로직이 사방팔방에서 중복되기 시작해.
그래서 우리는 모든 고위험 동작을 실행하기 전에 먼저 평가하는 다른 아키텍처를 실험 중이야.
대충 이런 구조지.
┌────────────────────────┐
│ LangChain Agent │
└────────────────────────┘
│
▼
┌────────────────────────┐
│ Proposed Tool Action │
└────────────────────────┘
│
▼
┌────────────────────────┐
│ Policy Evaluation │
└────────────────────────┘
│ │ │
▼ ▼ ▼
Allow Block Approval
│
▼
┌────────────────────────┐
│ Execute Tool │
└────────────────────────┘
여기 있는 다른 개발자들은 이 문제를 어떻게 해결하고 있는지 궁금해.
구체적으로 물어볼게.
• 툴마다 일일이 래핑하고 있어?
• LangGraph 인터럽트를 쓰고 있어?
• OPA, Cedar, Casbin 같은 정책 엔진을 쓰고 있어?
