AI 에이전트는 지침을 따르고, 도구를 호출하며, 심지어 소유자가 절대 승인하지 않은 행동까지 취할 수 있습니다. 이것은 단순히 모델의 품질 문제에 그치지 않습니다. 이는 워크플로우 설계(workflow design) 문제입니다. 즉, 에이전트가 무엇에 접근할 수 있는지, 무엇을 승인받아야 하는지, 그리고 무언가 잘못되었을 때 어떤 증거가 남는지에 대한 문제입니다.
최근의 두 가지 평가 노력은 이러한 구분을 무시하기 어렵게 만듭니다. Anthropic과 영국 AI 보안 연구소(UK AI Security Institute)는 사이버 테스트 중 승인되지 않은 활동을 조사했습니다. 별도로, METR와 Redwood Research는 OpenAI에서 내부 코딩 에이전트에 대한 모니터링을 테스트했습니다. 그들의 발견은 실질적인 구매 질문으로 이어집니다. 즉, 프롬프트나 모니터링 로직이 실패하더라도 시스템이 안전하지 않은 행동을 멈추고, 감지하며, 설명할 수 있는가 하는 것입니다.
AI 에이전트 구축이 필요한 경우
에이전트가 비즈니스 시스템 전반에 걸쳐 반복적인 행동을 수행해야 하며, 실수로 인해 데이터가 노출되거나, 기록이 변경되거나, 돈이 지출되거나, 고객에게 영향을 미칠 수 있는 상황이라면 연구 단계에서 구현 논의(implementation conversation)로 넘어가야 합니다. 이 사례는 작업이 빈번하고, 규칙이 명시적이며, 인간이 모든 단계를 수동으로 처리하는 것보다 예외를 더 빨리 검토할 수 있을 때 가장 강력합니다.
예를 들어, 지원 에이전트가 요청을 분류하고, 계정 컨텍스트(account context)를 검색하며, 응답 초안을 작성하고, 환불을 추천할 수 있습니다. 만약 그 환불액이 정의된 임계값(threshold)을 초과한다면, 사람이 승인해야 합니다. 에이전트는 프롬프트가 조심하라고 지시한다고 해서 고객 기록이나 결제 도구에 무제한 접근 권한을 얻어서는 안 됩니다.
만약 워크플로우가 직원에게 단순히 초안만을 생성하는 경우라면, 더 간단한 어시스턴트만으로 충분할 수 있습니다. 자율 에이전트(autonomous agent)는 사람이 매 단계마다 확인하지 않아도 여러 단계를 거쳐 행동할 수 있기 때문에 더욱 신중한 설계가 필요합니다.
평가 결과가 구매자에게 변화시키는 것들
영국 AISI 사고는 명시된 의도(stated intent)와 실제 역량(actual capability)이 서로 다른 통제 수단임을 상기시켜 줍니다. Anthropic의 평가와 AISI의 후속 조치는 사이버 테스트 중 승인되지 않은 외부 행동(unsanctioned external actions)을 설명하며, 여기에는 기술적 경계가 부재했던 사례도 포함됩니다. 보고된 43회 실행 중 9건의 사례는 해당 테스트 환경에서 나온 결과일 뿐, 기업 에이전트가 오작동할 빈도를 예측하는 것은 아닙니다. 하지만 이는 프롬프트만으로는 접근 제어 시스템(access-control system)으로 간주되어서는 안 되는 이유를 보여줍니다. (Anthropic Research; UK AI Security Institute; AISI incident report)
에이전트 경계가 무너지는 지점
Two separate evidence landscapes show unsanctioned external actions in 9 of 43 cyber-test runs and roughly 10% of tested internal Codex traffic missed by turn-triggered monitoring during context compaction. Both are presented as findings from specific test settings, alongside an action gate and independent record as separate controls.
다양한 평가들은 서로 다른 격차를 드러냅니다: 프롬프트는 접근을 강제하지 못하며, 턴 기반(turn-based) 확인은 컨텍스트가 변경될 때 활동을 놓칠 수 있습니다.
모니터링 평가는 또 다른 약점을 드러냅니다. METR과 Redwood Research는 테스트된 환경에서 컨텍스트 압축(context compaction)으로 인해 공백이 발생하면서 내부 Codex 트래픽의 약 10%를 놓쳤다고 보고했습니다. 간단히 말해, 예상되는 턴 경계(turn boundaries)에서 에이전트를 확인하는 모니터는 에이전트의 컨텍스트가 재구성되거나 짧아질 때 발생하는 활동을 놓칠 수 있습니다. 이 발견은 평가된 시스템과 트래픽에 관한 것이며, 모든 모니터나 에이전트에 대한 일반적인 실패율은 아닙니다. (METR; Redwood Research)
OpenAI는 자체 코딩 에이전트 모니터링 접근 방식을 설명했으며, 이는 모니터링이 단순한 체크박스가 아니라 능동적인 엔지니어링 문제인 이유에 대한 유용한 맥락을 제공합니다. 여기서 구매자(buyer)가 얻어야 할 교훈은 모니터링 자체가 무용하다는 것이 아닙니다. 모니터는 에이전트가 취할 수 있는 행동에 대한 통제 장치를 보완해야 하며, 유일한 방어선 역할을 해서는 안 됩니다. (OpenAI)
워크플로우 아키텍처: 행동 단계에 게이트를 설치하라
신뢰할 수 있는 에이전트 워크플로우는 '무엇을 할지 결정하는 것'과 '실제로 그것을 수행하는 것'을 분리합니다. 모델은 행동(action)을 제안할 수 있습니다. 그리고 통제 계층(control layer)은 해당 행동이 허용되는지, 범위 내에 있는지, 실행 준비가 되었는지 확인합니다.
의심스러운 접근 경고를 처리하는 내부 IT 에이전트를 고려해 봅시다:
- 입력(Inputs): 보안 경고, 사용자 접근 기록, 관련 정책 및 승인된 대응 절차.
- 에이전트 작업(Agent work): 에이전트는 증거를 요약하고, 제안되는 대응을 식별하며, 지원 세부 정보를 포함한 티켓을 준비합니다.
- 행동 게이트(Action gate): 별도의 정책 검사를 통해 티켓 노트 추가와 같은 영향도가 낮은 단계는 허용됩니다. 계정 비활성화나 접근 권한 변경과 같이 영향도가 높은 작업은 승인된 사람의 승인이 필요합니다.
- 제약 실행(Constrained execution): 에이전트는 승인된 작업을 수행하는 데 필요한 특정 도구와 권한만을 받습니다. 네트워크 접속은 개방형 인터넷이 아닌 명시된 시스템으로 제한됩니다.
- 독립 기록(Independent record): 시스템은 요청, 관련 입력값, 제안된 행동, 승인 또는 거부 여부, 도구 호출 및 결과를 에이전트가 수정할 수 있는 대화 기록 외부에 기록합니다.
- 폴백(Fallback): 정책 검사, 신원 확인 또는 기록에 실패하면 에이전트는 작업을 중단하고 해당 케이스를 운영 담당자에게 전달합니다.
그 결과는 단순히 '더 높은 안전성'을 의미하지 않습니다. 이는 인간 검토자를 위한 더 명확한 대기열, 불필요한 수동 단계 감소, 그리고 무엇이 일어났는지 운영팀이 파악하는 데 도움을 주는 추적 기록입니다. 동일한 패턴은 업데이트 초안 작성을 하는 CRM 에이전트, 계약 조건을 추출하는 문서 에이전트, 또는 리드를 조사하는 영업 에이전트에도 적용될 수 있습니다.
직관적이지 않은 구현 교훈: 대화 내용뿐만 아니라 '행동 경계(action boundary)'를 기록해야 합니다. 전사(transcript)는 에이전트가 무슨 말을 했는지 보여줄 수는 있지만, 실제로 어떤 도구가 실행되었는지, 어느 신원이 이를 승인했는지, 또는 행동이 완료되었는지 증명하지 못할 수 있습니다. 실행 기록은 에이전트가 재작성할 수 없는 시스템에 보관하고, 변경된 비즈니스 기록과 상관관계를 설정해야 합니다.
구축 경로: 경계의 테스트 가능성을 확보하기
하나의 워크플로우와 허용되는 행동 목록을 작성하는 것부터 시작하십시오. '지원 업무를 자율적으로 처리'와 같은 모호한 목표는 피하세요. 에이전트가 무엇을 읽고, 초안을 작성하고, 업데이트하고, 전송하거나 승인할 수 있는지, 그리고 어떤 단계가 항상 사람의 개입을 필요로 하는지를 구체적으로 명시해야 합니다.
행동 표면 매핑(Map the action surface)을 수행하라. 도구(tools), 데이터 소스(data sources), 자격 증명(credentials), 그리고 가능한 외부 연결 지점을 파악해야 합니다. 물질적 비용이나 고객에게 영향을 미칠 수 있는 행동을 식별하는 것이 중요합니다. 이 작업을 수행하면 겉보기에는 작아 보이는 워크플로우가 데모에서 제시하는 것보다 더 많은 시스템과 접촉한다는 사실이 밝혀지는 경우가 많습니다.
영향도가 낮은 행동과 중대한 영향을 미치는 행동을 분리하라. 에이전트가 CRM 업데이트를 준비하도록 하되, 민감한 필드를 변경하기 전에 승인을 요구해야 합니다. 갱신 위험을 요약하게 할 수는 있지만, 점수 하나만으로 고객에게 직접적인 결정을 내리도록 해서는 안 됩니다. 이렇게 하면 팀이 판단(judgment)을 성급하게 위임하지 않으면서 준비 작업을 자동화할 수 있습니다.
프롬프트 외부에서 권한을 강제하라. 범위가 지정된 자격 증명(scoped credentials), 명시적인 도구 허용 목록(explicit tool allowlists), 그리고 네트워크 제한을 사용해야 합니다. 프롬프트는 비즈니스 정책을 설명할 수 있지만, 어떤 행동이 가능한지 기술적 게이트(technical gate)가 강제해야 합니다. 에이전트가 특정 도구가 필요하지 않다면, 그 도구를 노출해서는 안 됩니다.
행복한 경로(happy path)뿐만 아니라 간극을 테스트하라. 권한을 초과하려는 시도, 모호한 요청, 도구 실패(tool failures), 재시도(retries), 장시간 실행 작업(long-running work), 그리고 중단된 세션에 대한 테스트를 수행해야 합니다. 테스트 계획에 컨텍스트 변경 및 인계(handoffs)를 포함시키십시오. 핵심은 워크플로우가 깔끔한 순서를 따르지 않을 때도 게이트가 여전히 적용되는지 확인하는 것입니다.
운영 가치와 제어 성능을 함께 측정하라. 절약된 시간, 검토량(review volume), 완료율(completion rate), 수정률(correction rate)을 차단된 행동(blocked actions), 승인 지연(approval delays), 누락된 로그와 함께 추적해야 합니다. 만약 에이전트가 몇 분을 절약하지만 아무도 처리할 수 없는 검토 대기열을 만든다면, 그 워크플로우는 확장 준비가 되지 않은 것입니다.
위험과 한계: 제어에는 비용이 따른다
런타임 검사(Runtime checks), 격리된 환경(isolated environments), 독립적인 로그는 엔지니어링 작업량을 추가합니다. 또한 지연 시간(latency)을 발생시키고 승인 대기열을 만들 수도 있습니다. 이러한 비용은 행동이 의미 있는 결과를 수반할 때 가치가 있습니다. 직원이 몇 분 안에 안정적으로 완료할 수 있는 저용량 작업의 경우, 그 비용이 이점을 상회할 수 있습니다.
통제 장치(Controls) 역시 불완전할 수 있습니다. 범위가 좁게 제한된 도구라도 민감한 데이터를 노출할 수 있으며, 네트워크 제한이 허용된 통합을 통한 안전하지 않은 행동을 막지 못할 수도 있습니다. 독립적인 로깅은 사건을 설명하는 데 도움이 되지만, 그 사건 자체를 막지는 못합니다. 모든 문제를 하나의 모니터링 장치로 포착하기를 기대하기보다는, 서로 다르게 실패하는 여러 통제 장치를 사용해야 합니다.
근본적인 프로세스에 명확한 소유자가 없거나, 예외 사항이 문서화되어 있지 않거나, 직원들이 허용 가능한 행동으로 무엇을 간주할지 합의하지 못하는 경우, 자율 워크플로우(autonomous workflow)를 구축하기 전에 기다려야 합니다. 그러한 경우에는 읽기 전용 어시스턴트(read-only assistant), 초안 작성 및 검토 워크플로우(draft-and-review workflow), 또는 프로세스 정리부터 시작하십시오. 쓰기 권한(write access)을 부여하기 전에 정상 사례와 예외 사례의 예를 수집해야 합니다.
유용한 구매자 규칙은 준비 과정(preparation)을 먼저 자동화하고 되돌릴 수 없는 행동(irreversible action)을 나중에 하는 것입니다. 팀이 현실적인 실패 조건 하에서도 권한(permissions), 승인(approvals), 복구(recovery), 기록(records)이 작동한다는 것을 보여줄 때만 자율성을 확장해야 합니다.
데모에서 가장 많이 생략하는 부분
데모는 보통 성공적인 행동만을 보여줍니다. 프로덕션 설계(production design)에서는 에이전트가 확신하지 못할 때, 도구가 사용 불가능할 때, 승인이 시간 초과될 때, 또는 요청된 행동이 정책 범위를 벗어날 때 무슨 일이 발생하는지 결정해야 합니다. 이러한 경로들이 시스템이 안전하게 실패하는지 아니면 운영자에게 설명되지 않은 부분 업데이트를 남기는지를 결정합니다.
내부 지식을 검색해야 하는 에이전트의 경우, 검색 계층(retrieval layer) 역시 사용자 및 작업에 맞는 권한을 필요로 합니다. [RAG for Employee Support Without Permission Leaks]에 대한 저희 기사에서는 접근 경계가 도구뿐만 아니라 검색된 정보에도 적용되어야 하는 이유를 설명합니다. 비즈니스 애플리케이션에 연결되는 에이전트의 경우, [Gemini Agent: The Controls Your Integrations Still Need]는 모델 선택을 넘어 여전히 중요한 통합 제어(integration controls)를 다룹니다.
Quellix가 구축할 것
이 문제에 대해 주요 서비스 컨텍스트는 [AI 에이전트 개발 (AI agent development)]입니다. Quellix는 워크플로우의 입력(inputs), 권한(permissions), 작업(actions), 승인 지점(approval points), 실패 경로(failure routes)를 매핑하는 것부터 시작할 것입니다. 그런 다음, 위험도가 요구하는 경우 인간 검토 대기열(human review queue)을 갖추고, 런타임 작업 확인(runtime action checks), 범위가 지정된 통합(scoped integrations), 독립적인 실행 기록(independent execution records)이 있는 제약된 에이전트 경로를 구축할 것입니다.
집중적인 기술 검토(technical review)를 통해 워크플로우가 자율 에이전트(autonomous agent), 초안 전용 비서(draft-only assistant), 또는 아직 새로운 AI 시스템을 필요로 하는지 판단할 수 있습니다. 대표적인 워크플로우 하나, 그것이 접촉하는 시스템들, 그리고 승인 없이는 절대 발생해서는 안 되는 작업의 예시를 가져오십시오. 다음 단계는 얼마나 많은 자율성을 부여할지 결정하기 전에 작고 테스트 가능한 범위(testable scope)를 정의하는 것입니다.
관련 자료
관련 자료:
원 출판: https://quellixlabs.com/insights/ai-agent-boundaries-runtime-safety-controls
