LLM은 절대 프로덕션에 직접 연결되면 안 됨. 우리는 그 사이에 4단계 경계를 둠

최근에 클라이언트 프로젝트 몇 개 보면서 우리 팀이 뭘 깨달았는지 아냐? 아직도 에이전트 아키텍처를 대충 이런 식으로 시작하는 곳이 꽤 많더라고.

user → LLM → tool call → production API

데모용으로는 돌아갈지 몰라도, 돈이 오가거나 고객 데이터 건드리고, 메시지 보내고, 코드 배포하고, 되돌릴 수 없는 작업 트리거하는 시스템에서 이런 식으로 짜는 건 진짜 위험한 짓이야.

모델한테는 추론할 권한만 줘야지, 지 정체성이나 권한, 페이로드, 실행 경로까지 직접 정하게 놔두면 안 된다고.

우리가 써보니까 제일 확실했던 건 경계선을 네 개로 나누는 거였어.

1. 정체성 경계 (Identity boundary)

요청이 LLM에 닿기 전에 사용자 인증부터 끝내야 해.

user_id, tenant_id, role, session, correlation ID 같은 건 전부 신뢰할 수 있는 애플리케이션 코드에서 붙여야지, 모델이 이걸 생성하거나 덮어쓰게 두면 절대 안 돼.

이 단계에서 사용자나 테넌트별로 레이트 리밋도 걸어놔야 함. 그냥 전체 토큰 제한 거는 건 별 도움 안 돼. 특정 사용자가 비싸거나 위험한 툴을 계속 호출해대면 답도 없거든.

2. 의도 경계 (Intent boundary)

오케스트레이션 레이어 안에서 에이전트가 요청을 분류하고, 컨텍스트 가져오고, 단계별로 계획 짜고, 툴 호출 제안까지는 할 수 있어. 근데 그건 어디까지나 '제안'일 뿐이야. 엄격한 스키마랑 위험 수준이 정해진 이름 있는 작업이어야지. read, prepare, write, irreversible 같은 식으로 말이야.

프롬프트에다가 권한 설정 쑤셔 넣지 마라. "~할 때까지는 절대 하지 마" 같은 지시문은 유용하긴 한데, 그건 제대로 된 접근 제어 메커니즘이 아니야.

3. 정책 및 실행 경계 (Policy and execution boundary)

여기가 제일 중요한 부분이야. 여기서 다음 항목들을 체크해야 해.

• identity 및 tenant 범위
• 역할 또는 속성 기반 권한 (RBAC/ABAC)
• 입력 및 출력 스키마
• 비즈니스 규칙 및 작업별 제한 사항
• 승인 절차
• 멱등성(idempotency) 및 재시도 규칙
• 해당 작업이 현재 활성화되어 있는지 여부

이 레이어에서 스코프가 지정된 자격 증명, 멱등성, 재시도, 킬 스위치, 서킷 브레이커까지 다 관리하는 거야.

하나 놓치기 쉬운 게 있는데, 승인은 반드시 '정확한 페이로드'에 대해서만 이루어져야 해. 금액, 수신자, 환경, 대상 리소스가 조금이라도 바뀌면 기존 승인은 무효 처리해야지.

거부된 시도들도 다 로그 남겨놔. 나중에 에이전트가 도대체 뭘 하려고 했는지 파악할 때는 성공한 호출보다 거부된 로그가 훨씬 도움 되거든.

4. 시스템 기록 경계 (System-of-record boundary)

애플리케이션이나 시스템은 자기만의 불변성(invariant)을 다시 한번 검증하고, 작업을 실행한 뒤에 확실한 결과를 반환해야 해.

에이전트가 "완료"라고 말했다고 해서 송금이나 배포, 이메일 발송, 업데이트가 실제로 일어났다는 증거는 아니잖아.

에이전트한테 쓰기 권한 주기 전에 복구 방법부터 고민해봐. 트랜잭션, 스테이징 작업, 체크포인트, 멱등성 키, 보상 작업(compensating operations) 같은 것들이 다 도움이 될 거야. 물론 아예 되돌릴 수 없는 작업도 있겠지. 그런 건 그냥 감사 로그(audit log) 하나로 퉁치지 말고, 별도의 승인 단계를 무조건 추가하는 게 속 편해.

결국 전체 흐름은 이래:

LLM이 제안한다 → 정책이 결정한다 → 결정론적 코드가 검증한다 → 필요하면 사람이 승인한다 → 핵심 시스템이 실행한다 → 감사 로그에 결과를 기록한다.

---