| LG CNS는 기업의 Agentic AI 도입과 운영에 필요한 설계 기준을 정리한 ‘Agentic AI 아키텍처 이행 지침서’를 발간했습니다. 이번 시리즈에서는 이행 지침서의 주요 내용을 선정해 4편에 걸쳐 소개합니다. 시리즈 첫 번째 글에서는 ‘Agent의 자율성을 어디까지 허용할 것인가’를 주제로, 기업이 에이전트에 위임할 업무와 그에 필요한 통제 방법에 대해 살펴봅니다. |
Agentic AI는 대형 언어모델(LLM)의 추론을 활용해 주어진 목표를 달성하는 데 필요한 작업을 계획하고 수행하는 AI 시스템입니다. 에이전트(Agent)는 필요한 정보를 조회하거나 도구를 호출해 작업을 실행하고, 그 결과를 확인하면서 다음 행동을 결정합니다. 따라서 에이전트 시스템을 구현하려면 모델의 추론 능력에 더해, 업무 시스템과의 연계, 작업 진행 상태의 관리, 실행 권한과 정책을 확인하는 기능이 함께 갖춰져야 합니다.
개인이 자료 조사나 문서 초안 작성에 에이전트를 활용하는 경우를 생각해 보겠습니다. 에이전트가 정보를 검색하고 정리하면 사용자는 결과를 검토해 필요한 내용을 선택하거나 수정합니다. 이처럼 결과물을 확인한 뒤 활용하는 업무에서는 사용자의 검토가 실제 업무에 반영되기 전의 통제 지점이 됩니다.
기업(Enterprise)에서는 에이전트가 조직의 프로세스와 데이터, 업무 시스템에 연결됩니다. 고객 정보를 조회하는 데서 나아가 계약 조건을 변경하거나 고객에게 문서를 발송할 수 있습니다. 실행 결과가 다른 부서의 업무와 고객에게 영향을 주므로, 결과물의 품질과 함께 누가 어떤 권한으로 실행했는지, 어느 단계에서 승인이 필요한지, 실패하면 누가 복구할지도 정해야 합니다.
이 차이는 업무를 연결하는 방식과 실행의 영향 범위에서 발생합니다. 같은 문서 작성 기능이라도 개인이 검토할 초안을 만드는 경우와 기업의 승인 절차를 거쳐 외부에 발송하는 경우에는 요구되는 통제가 달라집니다. 기업은 에이전트에 업무를 위임하면서 데이터 접근 범위, 실행 권한, 승인과 책임의 경계도 함께 설계해야 합니다.
따라서 기업이 정할 자율성의 범위는 ‘어떤 업무를 맡길지, 어떤 행동에서 사람을 기다릴지, 잘못된 실행을 어디서 중단하고 어떻게 정리할지’를 함께 정의하는 것이라 할 수 있습니다.
- Agentic AI Business Level
기업이 에이전트에 업무를 위임하려면 실행을 맡길 범위와 그에 필요한 통제 수준을 함께 정해야 합니다. 이를 구체화하기 위해 이행 지침서에서는 Agentic AI의 업무 수행 수준을 5단계 Business Level로 구분했습니다. 각 단계에서는 에이전트가 수행할 업무를 정의하고, 해당 업무에 필요한 권한과 승인 절차, 실패 시 복구 조건을 함께 설계해야 합니다.
[그림 1] Agentic AI Business Level
[그림 2] Agentic AI Business Level 기준 기술 구현 레벨
Business Level은 도메인과 비즈니스 요구에 적합한 에이전트의 업무 수행 수준을 선택하고, 필요한 설계·운영 요건을 점검하기 위해 정의했습니다. 따라서 높은 단계 자체를 도입 목표로 삼기보다, 위임할 업무와 그에 필요한 통제를 기준으로 적용 수준을 결정해야 합니다.
사내 규정 검색은 Level 1로도 목적을 달성할 수 있지만, 문서 접근 권한과 답변 근거를 관리해야 합니다. 단일 에이전트가 고객 정보를 수정하는 Level 2 업무라면 쓰기 권한 검증과 승인 절차가 필요할 수 있습니다. 통제의 필요성은 단계만으로 결정되지 않으며, 개별 행동의 영향과 위험도를 함께 평가해야 합니다.
가격 제안서 초안을 작성하면서 데이터 조회, 정책 검색, 문서 작성, 평가를 여러 전문 에이전트가 나누어 수행한다면 Level 3의 협업 시나리오에 해당합니다. 여기에 승인 게이트, 실행 상태 관리, 실패 복구를 체계적으로 적용하면 Level 4에서 강조하는 통제와 회복력을 갖춰갈 수 있습니다. 다만 특정 기능의 도입만으로 수준을 판단하기보다, 전체 업무 흐름에서 통제와 복구가 일관되게 작동하는지 확인해야 합니다.
Level 5에서도 자율성은 기업이 정한 권한과 정책 안에서 허용됩니다. 실패 원인을 분석하고 개선안을 제안하는 권한과 운영 정책 · 권한 · 모델을 실제로 변경하는 권한은 구분해야 합니다. 자율적으로 변경할 수 있는 범위를 정하고, 변경 사항의 검증 · 승인 · 배포 절차를 함께 마련해야 합니다.
7레이어로 나누면 통제할 위치가 보입니다
Business Level에서 업무 위임과 통제 범위를 정했다면, 7레이어에서는 이를 시스템의 어느 위치에서 구현할지 구체화합니다. 이행 지침서에서 제시한 7레이어는 User-Interface, Interface, Orchestration, Agent, Model, Data & Knowledge, Observability로 구성됩니다.
7레이어는 에이전트가 업무를 수행하는 데 필요한 역할과 책임을 나눈 구조입니다. User-Interface는 업무 화면이나 대화를 통해 들어온 요청과 사용자 정보를 받아 전달하고, Interface는 게이트웨이를 통해 인증·인가와 외부 시스템 접근을 제어합니다. Orchestration은 요청을 세부 작업으로 나누어 실행 순서와 상태를 관리하며, Agent는 부여된 역할에 따라 도구를 활용해 업무를 수행합니다. Model은 이 과정에 필요한 추론을 지원하고, Data & Knowledge는 업무 데이터와 지식, 메모리를 제공합니다. Observability는 전 계층의 실행 흐름을 관측하고 기록합니다.
실제 업무는 이 계층들을 한 번씩 순서대로 통과하는 방식으로 진행되지 않습니다. 에이전트는 작업 결과에 따라 모델과 데이터를 반복해서 활용하고, 외부 도구를 호출할 때마다 Interface에서 권한과 정책을 확인받습니다. Observability는 이러한 호출과 결과, 오류, 비용, 승인 및 정책 판단을 하나의 실행 이력으로 연결해 전체 과정을 추적할 수 있도록 합니다.
보안과 통제도 각 계층의 역할에 맞게 적용해야 합니다. 요청이 들어올 때는 사용자 신원을 확인하고, 데이터를 조회할 때는 접근 범위를 제한하며, 도구를 실행하기 전에는 권한과 입력 인자를 검증합니다. 이때 사용자 정보와 권한, 승인 상태, 정책 판단 결과가 실행 흐름을 따라 전달되어야 업무 전 과정에 일관된 통제를 적용할 수 있습니다.
[그림 3] Agentic Flow의 7레이어 구조
- 예시. 가격 제안서 초안 작성 요청
영업 담당자가 에이전트에게 “A사 계약 연장을 위한 가격 제안서 초안을 만들어 줘. 작년보다 5% 인상하는 안으로 검토하고, 메일 발송 준비까지만 해 줘”라고 요청했다고 가정해 보겠습니다. 여기서 5% 인상은 검토를 위한 가정입니다. 에이전트는 해당 조건이 회사의 가격 정책에 부합하는지 확인하고, 실제 발송은 수행하지 않아야 합니다.
User-Interface는 요청 내용과 사용자·세션 정보를 전달합니다. Interface의 게이트웨이는 사용자 신원을 확인하고, A사의 거래 이력에 접근할 권한이 있는지 검증합니다. 인증된 사용자라도 조회할 수 있는 고객과 데이터의 범위는 권한에 따라 제한됩니다.
Orchestration은 요청을 고객 확인, 거래 이력 조회, 가격 정책 검토, 제안서 작성, 결과 검증으로 나누고 진행 상태를 관리합니다. 각 작업은 역할에 맞는 Agent가 수행합니다. Data Agent는 허용된 거래 데이터를 조회하고, RAG Agent는 적용할 가격 정책을 검색합니다. 문서 작성 Agent가 이를 바탕으로 초안을 만들면, 평가 단계에서 필수 항목과 가격 계산, 정책 근거를 확인합니다. 가격 합계처럼 기준이 명확한 항목은 계산 코드로 검증하고, 문구와 근거의 적절성은 모델 평가 등을 조합해 점검할 수 있습니다.
Model은 각 단계의 정보 해석과 문서 작성, 평가에 필요한 추론을 지원합니다. Data & Knowledge는 접근 권한이 확인된 업무 데이터와 정책 문서를 제공하며, 필요한 경우 담당자의 과거 작성 방식도 메모리에서 불러옵니다. 다만 개인의 작성 선호가 현재의 가격 정책이나 승인 기준보다 우선해서는 안 됩니다.
Observability는 이 과정의 도구 호출, 검증 결과, 비용과 오류를 동일한 실행 이력으로 연결해 기록합니다.
요청한 업무는 제안서 초안과 메일 발송 준비가 끝나면 완료됩니다. 이후 실제 발송을 진행하려면 발송 행위에 대한 권한과 정책을 확인하고 필요한 승인을 받아야 합니다. 초안 내용에 대한 검토와 특정 수신자에게 보내는 행위에 대한 승인을 구분하는 것입니다. 승인 후에는 발송 권한을 가진 API Agent가 MCP Gateway를 통해 승인된 문서와 수신자를 대상으로 발송하고, 그 결과를 기존 실행 이력에 연결합니다.
통제는 정책 수립, 실행 통제, 상태 관리와 복구로 나누어 설계
에이전트의 자율성을 통제하려면 업무를 허용하는 기준부터 실행 중 검증, 실패 이후의 처리까지 연결해야 합니다. 이를 위해 통제 설계를 세 가지 관점으로 나누어 살펴보겠습니다. 거버넌스는 허용 범위와 책임을 정하고, 실행 통제는 그 기준을 실제 실행에 적용하며, 상태 관리와 복구는 중단되거나 실패한 작업을 안전하게 이어가거나 종료하도록 합니다.
| 구분 | 주요 설계 내용 | 책임과 적용 위치 |
| 거버넌스 정책과 책임 | 자동 실행 범위, 승인권자, 금지 행위, 실행 예산, 중단·재개 기준 | 업무·보안·운영 조직 전 계층에 적용할 기준 정의 |
| 실행 통제 정책의 집행 | Policy-as-Code, 가드레일, HITL, Kill switch, 권한·예산 검사 | Interface의 Gateway와 Orchestration, Agent Runtime 사용자 화면과 승인 절차 연결 |
| 상태 관리와 복구 중단 · 실패 대응 | Checkpoint, Retry, 중복 방지, 외부 처리 결과 확인, 보상 처리 | Orchestration, Agent Runtime, 상태 저장소, 도구 연계 코드와 외부 시스템 |
하나의 기능에도 정책과 구현, 운영 절차가 함께 필요합니다. 예를 들어 HITL을 적용할 때 “고객에게 문서를 발송하려면 담당자의 승인을 받아야 한다”는 기준은 거버넌스에 해당합니다. 승인 전 메일 API 호출을 차단하는 것은 실행 통제이며, 승인 대기 상태를 저장하고 승인된 작업을 재개하는 것은 상태 관리입니다.
Kill switch도 같은 방식으로 설계합니다. 발동 조건과 중단·재개 권한을 정하고, 런타임과 게이트웨이에서 후속 호출을 차단하며, 이미 외부 시스템에 반영된 작업은 결과를 확인해 필요한 복구나 보상 처리를 수행해야 합니다.
Checkpoint와 Retry는 주로 실행 상태와 실패를 다루는 구현 수단이지만, Agent 내부만으로 해결할 수는 없습니다. 여러 에이전트의 작업 상태는 Orchestration에서 관리하고, 외부 API를 다시 호출할 때는 이미 처리된 요청인지 확인하거나 중복 실행을 방지해야 합니다. 재시도를 허용할 오류와 한도, 복구 후 재개 조건 역시 사전에 정한 정책을 따라야 합니다.
따라서 통제 설계에서는 기능의 도입 여부와 함께 어떤 기준으로 동작하는지, 어디서 집행하는지, 누가 변경과 운영을 책임지는지를 명확히 해야 합니다.
1. 거버넌스: 허용 범위와 책임을 먼저 정합니다
통제 정책을 구체화하려면 에이전트가 수행할 업무를 개별 행동으로 나누고, 각 행동에 필요한 권한과 실행 조건을 정해야 합니다. 예를 들어 가격 제안 업무도 고객 정보 조회, 제안서 생성, 계약 조건 변경, 메일 발송으로 구분할 수 있습니다. 각 행동의 영향 범위와 복구 가능성을 검토한 뒤, 허용된 행위에 적용할 실행 방식을 다음과 같이 정합니다.
| 실행 방식 | 적용 예시 | 운영 기준 |
| 자율 실행 | 권한 내 내부 지식 검색과 문서 정리 | 정책 · 데이터 범위·실행 예산 준수 |
| 실행과 알림 | 영향이 제한된 내부 요청 생성 | 알림 시점과 실행 이력 정의 |
| 승인 후 실행 | 계약 조건 변경과 고객 대상 발송 | 승인 전 중단과 승인 대상 검증 |
실행 방식은 내부 조회라도 민감한 데이터를 다루거나 다른 조직의 정보에 접근한다면 추가 통제가 필요할 수 있습니다. 반면 영향 범위가 제한되고 되돌리기 쉬운 작업은 개별 승인 없이 수행하도록 정할 수 있습니다. 조회와 쓰기의 구분뿐 아니라 데이터의 민감도, 외부 영향, 금전적 책임, 복구 가능성을 함께 평가해야 합니다.
금지된 행위는 승인 대상으로 전환하지 않고 차단해야 합니다. 요청자에게 없는 권한을 에이전트의 서비스 계정으로 우회하거나, 전사 정책이 금지한 외부 전송을 일반 업무 승인만으로 허용해서는 안 됩니다. 정책 예외가 필요한 경우에는 예외 승인권자, 적용 범위, 유효기간을 명시한 별도 절차를 따라야 합니다.
정책을 정하고 운영하는 책임도 명확해야 합니다. 업무 담당자는 자동 실행 범위와 승인권자를, 보안 담당자는 접근 권한과 예외 조건을, 운영 담당자는 실행 예산과 중단·재개 기준을 정의합니다. 개발 조직은 이를 실행 조건과 검증 시나리오로 구현합니다. 승인·차단 기준이나 재시도 한도를 변경할 때에도 검토와 배포 책임자를 정하고 변경 이력을 관리해야 합니다.
2. 실행 통제: 정책을 실제 호출에 적용합니다
이 기준을 실행 시점에 적용하는 방법이 Policy-as-Code입니다. 정책 엔진은 요청자, 수행 행위, 대상 자원에 위험도·승인 상태·남은 예산을 더해 허용, 차단, 검토, 제한을 판정하도록 구성할 수 있습니다. 정책의 판정 결과와 각 결과에 따른 처리 방식은 업무 기준에 맞게 정의해야 합니다.
판정과 집행은 연결되어야 합니다. 정책이 차단을 반환했다면 런타임이나 게이트웨이가 실제 호출을 차단해야 합니다. 프롬프트에는 행동 원칙을 설명하되, 권한·가격·수신자·호출 한도처럼 강제해야 하는 조건은 실행 경계에서 검사해야 합니다. 업무 담당자는 허용 범위와 승인권자를 정하고, 개발·운영 조직은 이를 우회할 수 없는 실행 경로로 구현합니다.
[그림 4] 정책 판정과 집행의 연결 구조
가드레일은 실행 흐름의 어느 지점에서 무엇을 검사할지 구체화합니다. 사용자 입력에서는 업무 범위와 악성 지시를 확인하고, 도구 호출 전에는 허용된 도구·권한·입력 형식을 검사합니다. 도구 응답에서는 외부 문서에 포함된 지시가 실행 명령으로 사용되지 않도록 분리하며, 최종 출력에서는 민감 정보와 답변 근거를 확인합니다. 각 지점의 위험이 다르므로 검사 목적에 맞게 가드레일을 구성해야 합니다.
가격 제안서 업무에서 문구의 적절성을 평가하는 일과 발송 권한을 확인하는 일도 구분해야 합니다. 문구는 모델 평가를 활용할 수 있지만, 수신자·승인 상태·도구 권한은 정해진 규칙으로 검사해야 합니다. 검색 문서에 “승인을 생략하라”는 내용이 있어도 이 정보가 실행 권한을 변경할 수 없도록 해야 합니다.
실행 예산도 런타임에서 관리해야 합니다. 작업 단계 수, 도구 호출 수, 토큰 사용량, 실행 시간, 비용, 동시 실행 수에 한도를 설정하고, 다른 에이전트에 위임한 작업도 최초 요청에 연결해 사용량을 집계합니다. 한도에 도달하면 정책에 따라 추가 실행을 제한하거나 사람의 검토를 요청합니다. 예산을 늘려야 한다면 에이전트의 자체 판단이 아니라, 사전에 정의한 권한과 승인 절차에 따라 조정해야 합니다.
- HITL: 승인한 내용과 실행되는 내용을 연결합니다
Human-in-the-Loop(HITL)는 실행 중 필요한 지점에서 사람의 판단을 받는 구조입니다. 가격 제안서 발송처럼 외부 영향이 있는 행동에서는 실제 도구 호출 전에 중단해야 합니다. 이미 메일을 전송한 뒤 승인 알림을 제공하는 것은 사전 통제가 될 수 없습니다.
[그림 5] 실행 중단, 상태 저장, HITL
승인 화면은 검토자가 실행 여부를 판단할 수 있는 정보를 제공해야 합니다. 실행 목적과 대상, 변경 전후 내용, 판단 근거, 예상 영향과 복구 가능성을 함께 보여주는 것이 중요합니다. 가격 제안서 발송이라면 고객명과 수신자, 적용한 가격 정책, 제안 가격, 발송할 문서 버전을 확인할 수 있어야 합니다. 이행 지침서에서 제시한 UI Bridge는 이러한 검토 정보와 승인·거절·수정 기능을 기존 업무 화면이나 결재 시스템에 연결하는 역할을 합니다.
승인 대기 중에는 실행 상태를 영속 저장소에 보관하고, 실행 ID와 승인 요청 ID를 연결해 관리합니다. 승인 결과가 도착하면 해당 요청에 대응하는 작업과 저장된 상태를 확인해 재개합니다. LangGraph도 중단과 재개를 위해 체크포인터와 thread_id를 활용합니다. 다만 재개 과정에서 노드 내 코드가 다시 실행될 수 있으므로, 중단 이전에 수행한 도구 호출이나 데이터 변경이 중복 처리되지 않도록 설계해야 합니다.
승인의 효력은 검토한 대상과 내용에 한정되어야 합니다. 승인 후 수신자나 가격, 문서가 변경됐다면 변경된 요청을 다시 검증하고 필요한 승인을 받아야 합니다. 승인 대기 중 사용자 권한이나 정책이 달라질 수도 있으므로, 실행 직전에는 현재 기준에서도 해당 행위가 허용되는지 재확인해야 합니다. 이를 통해 승인한 내용과 실제 실행되는 내용의 일치 여부를 보장합니다.
승인 기한이 만료되면 자동으로 실행하지 않고, 업무 정책에 따라 요청을 종료하거나 상위 담당자에게 이관합니다. 동일한 승인 결과가 여러 번 전달되더라도 작업은 중복 실행되지 않아야 합니다. 운영 과정에서 수집한 승인 대기 시간과 수정·거절 사유는 승인 절차의 병목을 파악하고 통제 기준을 개선하는 데 활용할 수 있습니다.
- Kill switch: 문제 실행을 차단하고 재개 조건을 확인합니다
Kill switch는 이상이 발생한 에이전트의 실행을 중단하거나 권한·자원 사용을 제한하는 통제 기능입니다. 비정상적인 도구 호출 반복, 권한 밖의 접근, 가드레일 위반, 급격한 비용 증가 등이 감지되면 문제의 영향 범위에 따라 개별 실행(Run), 도구, 세션, 프로젝트 단위로 대응할 수 있어야 합니다.
[그림 6] Kill switch의 차단/격리/보상/복구 절차
Kill switch는 관측, 판단, 집행을 연결해 구현합니다. Observability가 실행 상태와 이상 징후를 수집하면 정책 엔진은 발동 여부와 차단 범위를 결정합니다. 런타임과 게이트웨이는 이 결정에 따라 후속 호출과 자동 재시도를 차단합니다. 운영자가 수동으로 중단을 요청하는 경우에도 같은 집행 구조를 통해 해당 범위의 실행을 제어해야 합니다.
예를 들어 가격 제안서 발송 도구에서 동일 문서의 중복 전송이 감지되면, 관련 Run과 도구의 추가 호출을 우선 차단합니다. 다른 고객의 제안서 조회까지 중단할지는 원인과 영향 범위를 확인해 결정합니다. 정상 업무에 미치는 영향을 줄이면서 문제 실행을 확실히 차단할 수 있도록, 중단·제한할 단위를 사전에 정의해야 합니다.
차단 이후에는 외부 시스템의 처리 상태를 확인해야 합니다. 에이전트를 중단하더라도 이미 시작된 외부 작업이나 대기열에 등록된 작업까지 자동으로 취소되지는 않습니다. 진행 중인 호출과 대기 작업, 이미 반영된 변경을 구분하고, 취소 API 호출이나 원상 복구, 보상 처리 등 가능한 조치를 수행해야 합니다. 이미 전달된 메일처럼 되돌리기 어려운 작업에는 후속 안내를 포함한 업무 대응 절차가 필요합니다.
실행을 재개하려면 원인을 해소하고 복구 결과를 검증해야 합니다. 권한 설정, 도구 스키마, 정책 기준 등 문제의 원인을 수정한 뒤 동일한 상황에서 차단과 복구가 의도대로 작동하는지 테스트합니다. 이후 정해진 복구 승인 절차에 따라 제한된 범위에서 실행을 재개하고 결과를 관찰합니다. 발동 근거, 차단 대상, 외부 영향, 보상 결과와 복구 승인 이력은 서로 연결해 추적할 수 있어야 합니다.
발동 기준은 업무 특성에 맞게 설정합니다. 검색을 위해 같은 도구를 여러 번 호출하는 경우와 한 번만 수행해야 하는 발송 작업을 동일한 기준으로 판단할 수는 없습니다. 정상 실행 데이터와 실패 시나리오를 바탕으로 기준을 정하고, 위험한 실행을 놓치는 사례와 정상 업무를 과도하게 차단하는 사례를 함께 점검하며 조정해야 합니다.
3. 상태 관리와 복구: Checkpoint와 Retry의 역할을 구분합니다
중단되거나 실패한 업무를 복구하려면 어디까지 처리했는지, 어떤 조건에서 다시 실행할 수 있는지 알아야 합니다. Checkpoint는 실행 상태를 저장해 업무를 재개할 수 있도록 하고, Retry는 일시적인 오류가 발생한 호출을 정해진 조건과 한도 안에서 다시 시도하는 역할을 합니다.
Checkpoint에는 대화 이력뿐 아니라 완료한 작업과 다음 단계, 도구 입력, 승인 상태, 적용한 정책 버전, 외부 시스템의 처리 결과를 연결해 보관해야 합니다. 실행을 재개할 때는 이 정보를 바탕으로 선행 작업과 승인 조건이 충족됐는지 확인합니다. 승인 대기 중인 작업을 실패로 간주해 재시도하거나, Kill switch로 중단한 작업을 복구 승인 없이 재개해서는 안 됩니다.
특히 에이전트에 저장된 상태와 외부 시스템의 실제 처리 상태가 다를 수 있다는 점에 주의해야 합니다. 메일 서버가 발송을 완료했지만 응답이 유실되면 에이전트는 성공 여부를 확인하지 못합니다. 이때 이전 Checkpoint에서 발송을 다시 수행하면 같은 메일이 두 번 전달될 수 있습니다. 따라서 Checkpoint 복원과 함께 외부 처리 결과를 확인하고 중복 실행을 방지하는 설계가 필요합니다.
| 실패 상황 | 처리 방향 | 재실행 전 확인 |
| 일시적인 조회 장애 | 한도 내 재시도 | 재시도 가능 오류와 남은 예산 |
| 권한 거부 · 정책 위반 | 차단 또는 정식 권한 검토 | 재시도로 권한을 우회하지 않음 |
| 발송 등 쓰기 작업의 결과 미확정 | 대상 시스템 처리 결과 조회 | 중복 방지와 이미 완료된 작업 여부 |
| 같은 오류 반복·예산 초과 | 중단 또는 사람 검토 | 원인 확인과 재개 조건 |
상태를 변경하는 API를 재호출할 때는 동일한 업무 요청을 식별하고 중복 처리를 방지할 수 있어야 합니다. 대상 API가 멱등성(Idempotency) 키를 지원한다면 같은 요청에 동일한 키를 사용하도록 설계합니다. 멱등성은 동일한 요청을 반복해도 추가적인 상태 변경이나 부작용이 발생하지 않는 성질입니다. 처리 결과를 조회할 수 있는 경우에는 이미 완료된 작업인지 확인하되, 결과가 불확실한 상태에서 무조건 재호출하지 않도록 해야 합니다.
Retry에는 최대 시도 횟수, 전체 소요 시간, 실행 예산을 함께 설정합니다. 일시적인 장애에는 재시도 간격을 늘리는 백오프와 호출 시점을 분산하는 지터를 적용할 수 있습니다. 여러 계층이 같은 요청을 각각 재시도하면 호출량이 크게 증가할 수 있으므로, 어느 계층에서 재시도를 담당할지도 명확히 해야 합니다. 한도 안에서 복구하지 못하면 자동 실행을 중단하고, 사전에 정의한 대체 경로나 사람의 검토로 전환합니다.
복구 테스트에서는 실행 재개 여부와 함께 외부 시스템에 이미 반영된 작업이 중복 수행되지 않는지 확인해야 합니다. 발송, 결제, 데이터 삭제처럼 영향이 큰 작업은 성공, 실패, 결과 미확정 상태를 구분하고, 각 상태에 맞는 확인/재시도/이관 절차가 동작하는지 검증해야 합니다.
자율성의 확대는 운영 결과를 보고 결정합니다
에이전트의 자동 실행 범위를 확대하려면 업무 수행 결과와 통제 기능의 동작을 함께 검증해야 합니다. 승인 없는 발송 시도, 승인 후 문서 변경, 외부 시스템의 처리 완료 후 응답 유실, 차단된 작업의 재실행 등을 테스트 시나리오에 포함합니다. 각 상황에서 실행이 적절히 제한되고, 필요한 확인과 복구 절차가 작동하는지 점검해야 합니다.
운영 단계에서는 다음과 같은 지표를 통해 업무 품질과 통제의 효과를 확인할 수 있습니다.
| 점검 항목 | 수집 및 계산 방법 | 확인할 내용 |
| 업무 성공률 | 사전에 정의한 완료 기준을 충족한 요청 수 ÷ 평가 대상 요청 수 × 100 | 자동 실행 범위를 확대한 뒤에도 업무 품질이 유지되는지 확인 |
| 승인 대기 시간 | 승인, 거절 결정 시각 (승인 요청 시각. 미결, 만료 건은 별도 집계) | 대기 시간의 분포와 승인 지연이 발생하는 구간 확인 |
| 반복 호출 | Run별 동일 도구, 대상, 행위의 호출 횟수와 결과 기록 | 정상적인 반복과 오류에 따른 불필요한 재실행 구분 |
| 중복 반영 건수 | 동일 업무 요청 식별자에 연결된 외부 처리 기록을 대조해 의도하지 않은 중복 반영 건 집계 | 재시도와 복구 과정에서 발생한 중복 발송, 변경 여부 확인 |
| 차단 및 복구 결과 | 발동 Run별 차단, 영향 확인, 보상, 재개 이벤트를 연결해 기록 | 차단 이후 추가 실행 여부, 복구 완료 여부와 동일 문제의 재발 확인 |
지표를 해석하려면 업무 성공 기준, 평가 대상, 측정 기간을 먼저 정의해야 합니다. 목표 수치도 업무의 중요도와 위험도에 맞게 설정하고, 같은 유형의 업무에서 정책 변경 전후를 비교합니다. 요청량이나 난도가 달라졌다면 그 차이도 고려해야 합니다. 차단 건수의 감소가 위험 감소를 의미하는지, 승인 대기 시간의 단축이 검토 생략에서 비롯된 것은 아닌지 실제 처리 결과와 함께 확인하는 것이 중요합니다.
이를 위해 요청자, 실행 ID, 도구와 대상, 적용 정책 버전, 승인 결과, 외부 시스템의 처리 결과를 연결해 기록합니다. 기록의 목적은 어떤 조건에서 실행이 허용되거나 차단됐고, 실제로 무엇이 처리됐는지 재구성하는 데 있습니다. 민감한 입력은 필요한 범위에서 마스킹하거나 보관을 제한하고, 모델의 내부 추론 대신 실행과 정책 판단을 확인할 수 있는 이벤트와 근거를 남겨야 합니다.
자율성 확대 여부는 이러한 운영 근거를 종합해 결정합니다. 업무 성공률이 유지되더라도 중복 처리가 늘거나 복구가 제대로 이루어지지 않는다면 자동 실행 범위를 재검토해야 합니다. 반대로 업무 품질과 통제 효과가 확인된 범위에서는 승인 대상을 조정하고 위임할 업무를 단계적으로 확대할 수 있습니다. 기업이 허용할 자율성은 운영 결과에 따라 확대하거나 제한하며 지속적으로 관리해야 합니다.
▌요약
- 5단계 Business Level은 업무 위임과 통제 범위를 함께 정하는 기준입니다. 각 수준에 맞게 맡길 업무를 정의하고, 개별 행동의 영향도/권한/복구 가능성에 따라 필요한 통제를 구체화합니다.
- 7레이어는 실행 책임을 분리합니다. Observability는 전 계층을 관측하고, 정책은 실제 도구 호출을 차단하거나 허용하는 집행 지점과 연결되어야 합니다.
- 거버넌스는 허용 범위와 책임을 정하고, 실행 통제는 이를 실제 호출에 적용하며, 상태 관리와 복구는 중단/실패 이후의 처리를 맡습니다. HITL과 Kill switch는 이 세 관점을 연결해야 하며, Checkpoint와 Retry는 외부 시스템의 처리 결과까지 고려해야 합니다.
▌FAQ
Q1. 에이전트가 하나뿐이어도 HITL이 필요한가요?
A1. 필요할 수 있습니다. 에이전트 수보다 행동의 영향이 중요합니다. 단일 에이전트라도 계약 변경이나 외부 발송을 수행한다면 업무 정책에 따라 실행 전 승인과 권한 검증을 적용해야 합니다.
Q2. Checkpoint가 있으면 실패한 작업을 다시 실행해도 되나요?
A2. 외부 시스템의 처리 결과부터 확인해야 합니다. 에이전트가 성공 응답을 받지 못했더라도 실제 작업은 완료 상태일 수 있습니다. 처리 결과 조회와 Idempotency 보장 없이 재시도하면 중복 실행이 발생할 수 있습니다.
Q3. 모든 작업을 승인 대상으로 정하면 더 안전하지 않을까요?
A3. 승인 요청이 과도하면 검토 지연과 형식적인 승인이 늘 수 있습니다. 위험이 적은 작업은 권한과 예산 안에서 실행하고, 영향이 상당한 작업에 검토를 집중해야 합니다. 금지된 행위는 일반 승인으로 우회하지 않고 차단합니다.
▌참고자료
1) Agentic AI 아키텍처 이행 지침서, 제2장 Agentic AI 아키텍처 개요
2) Agentic AI 아키텍처 이행 지침서, 제3장 Agentic AI Big Picture
3) Agentic AI 아키텍처 이행 지침서, 제19장 Agent 제어 전략
4) AWS Well-Architected, Control and limit retry calls
▌관련 오퍼링 및 문의하기
본 콘텐츠는 저작권법에 의해 보호받는 저작물로 LG CNS에 저작권이 있습니다.
사전 동의 없이 2차 가공 및 영리적인 이용을 금합니다.
