AI-GRACE, 에이전트를 도입한다는 말을 실행 계획으로 바꾸는 법

오늘 다룰 논문은 AI-GRACE: A Use-Case Operationalization Framework for Agentic AI: From Organizational Objectives and Obligations to Deployment Capabilities and Architecture라는 제목의 arXiv 프리프린트이며, 식별자는 arXiv 2609.21192입니다. 이 연구는 에이전틱 AI 도입에서 조직의 목표와 의무를 출발점으로 삼아 배포 역량과 아키텍처 결정까지 연결하는 사용례 운영화 프레임워크를 제안합니다. 원문은 제목 아래 연결된 링크에서 확인할 수 있습니다.

제가 이 논문을 고른 이유는 거창한 선언 때문이 아니라 순서 때문입니다. 많은 에이전트 논의가 모델 성능에서 시작해서 거버넌스를 나중에 덧붙이는데, 여기서는 순서를 뒤집어 조직이 무엇을 이루고 무엇을 지켜야 하는지부터 묻고 나서 기술 결정을 끌어냅니다.

왜 이 논문을 굳이 꺼내 읽었을까

안녕하세요, 패트릭입니다. 저는 평소에 에이전트 데모를 보면 두 가지 화면을 번갈아 떠올립니다. 하나는 시연 영상에서 매끄럽게 돌아가는 화면이고, 다른 하나는 새벽에 울리는 장애 알림 화면입니다. 시연에서는 에이전트가 주문을 정리하고 문서를 요약하고 고객에게 답을 보내는데, 운영 화면에서는 같은 에이전트가 왜 그 결제를 승인했는지 아무도 바로 설명하지 못합니다.

그렇다면 둘 사이의 간극은 어디에서 생길까요. 제 생각에는 모델이 똑똑해져서가 아니라, 도입을 결정할 때 썼던 언어와 배포할 때 쓰는 언어가 달라서입니다. 경영진은 목표와 의무의 언어로 말하고, 엔지니어는 권한과 로그와 롤백의 언어로 말합니다. 그 사이를 번역해주는 문서가 빈약하면 에이전트는 결국 누군가의 재량에 기대어 움직입니다.

제가 이 논문에서 가장 흥미롭게 본 부분은 바로 그 번역 장치를 정면으로 설계했다는 점입니다. AI-GRACE라는 이름은 Agentic Intelligence의 Governance, Risk, Assurance, Controls, Evidence를 묶은 것으로, 사용례를 실제로 운영 가능한 상태로 만드는 과정을 정리한 프레임워크입니다. 읽으면서 저는 계속 이런 질문을 던졌습니다. 이 틀이 있다면 다음 배포 회의에서 무엇이 달라질까. 그 이야기는 뒤쪽 은행 예시에서 다시 꺼내겠습니다.

모델이 믿을 만한지와 쓸 수 있는지는 다른 질문이다

에이전트 이야기를 하다 보면 신뢰할 수 있는 모델인지부터 묻는 경우가 많습니다. 벤치마크 점수가 올랐는지, 유해한 답변을 거르는지, 평가에서 안전한지 같은 것들이죠. 물론 이런 검증은 필요합니다. 그런데 배포 책임자 입장에서 보면 질문이 하나 빠져 있습니다. 그래서 이 모델을 우리 업무에 어디까지 믿고 맡길 수 있는가라는 질문입니다.

논문이 짚는 출발점도 여기에 가깝습니다. 조직이 에이전틱 AI를 들여올 때 판단해야 할 것은 모델이 일반적인 의미에서 신뢰할 만한지가 아니라, 특정 사용례가 의도한 결과를 내기 위해 무엇을 검증하고 무엇을 통제하고 무엇을 관찰할지라는 것입니다. 모델 점수는 배경이고, 사용례가 전경이라는 말이죠. 같은 모델이라도 고객 문의를 요약하는 일과 환불을 직접 실행하는 일은 요구되는 확증의 깊이가 전혀 다릅니다.

생각해보면 사람 조직도 비슷하게 움직입니다. 신입사원이 성실하다는 평가와 그 신입에게 법인카드를 맡길 수 있다는 판단은 다른 층위의 결정입니다. 후자에는 한도와 결재선과 증빙이라는 장치가 따라붙습니다. 에이전트에게도 같은 층위의 장치가 필요한데, 지금까지는 그 장치를 매번 현장에서 급조하는 경우가 많았습니다. 논문은 그 급조를 줄이자고 제안합니다.

거버넌스에서 배포까지 한 줄로 잇는다는 발상

AI-GRACE가 하려는 일은 말 그대로 한 줄로 잇는 것입니다. 왼쪽 끝에는 조직의 목표와 의무가 있고, 오른쪽 끝에는 배포 역량과 아키텍처가 있습니다. 중간에는 위험 평가와 요구사항 도출과 역량 점검이 들어갑니다. 그래서 목표가 바뀌면 중간 단계가 함께 움직이고, 기술 제약이 드러나면 다시 왼쪽으로 피드백이 갑니다.

이 흐름이 낯설게 느껴질 수도 있습니다. 보통은 거버넌스 문서와 아키텍처 문서가 따로 놀기 때문입니다. 거버넌스 쪽에서는 원칙과 정책과 심의 절차를 다루고, 엔지니어링 쪽에서는 에이전트 루프와 도구 호출과 타임아웃을 다룹니다. 문제는 원칙이 코드로 번역되지 않으면 선언에 그치고, 코드가 원칙과 연결되지 않으면 나중에 감사할 때 설명이 비어버린다는 점입니다.

저는 이 연결 방식을 보고 체크리스트가 아니라 배선도 같다고 느꼈습니다. 체크리스트는 항목을 하나씩 지워나가는 데 유용하지만 항목 사이의 관계는 보여주지 않습니다. 반면 배선도는 어느 결정이 어느 장치를 요구하는지 드러냅니다. 예를 들어 환불 실행 권한을 주기로 했다면 사전 확증 항목이 늘어나고, 실행 중 통제와 증거 수집 방식도 함께 바뀝니다. 권한 하나가 문서 여러 장에 파장을 일으키는 구조인 셈입니다.

그렇다면 이런 배선도가 왜 지금 필요할까요. 에이전트가 도구를 직접 호출하기 시작하면서 결정과 실행 사이의 거리가 짧아졌기 때문입니다. 사람이 화면에서 확인 버튼을 누르던 시절에는 그 버튼이 일종의 완충 지대였는데, 에이전트가 스스로 다음 단계를 이어가면 완충 지대를 명시적으로 다시 설계해야 합니다.

이 프레임워크가 기대하는 것과 아닌 것

이름에 거버넌스와 위험 같은 단어가 들어가면 오해하기 쉽습니다. 이 논문이 새로운 규제를 만들려는 것처럼 보이기도 하고, 특정 산업에만 쓰는 심의 절차처럼 보이기도 합니다. 그래서 미리 선을 긋는 편이 좋습니다. AI-GRACE는 법령 해설서도 아니고 심사대를 통과하기 위한 서류 묶음도 아닙니다.

이 틀이 하려는 일은 사용례 단위로 무엇을 검증하고 통제하고 남길지를 정하는 것입니다. 규제 준수는 그 과정에서 자연스럽게 다루어지지만 전체를 규정 준수 점검으로 축소하면 논문이 말하려는 절반을 놓치게 됩니다. 실제로 위험 영역에는 임무와 가치 실현 같은 항목이 포함되어 있어서, 안전과 준수를 넘어서 이 일이 조직에 어떤 이득을 주는지까지 함께 봅니다.

반대로 이 틀을 만능 자동화 도구로 보면 실망할 수도 있습니다. 버튼을 누르면 아키텍처가 뚝딱 나오는 생성기가 아니라, 조직의 맥락에 맞게 다듬어 쓰는 방법론에 가깝기 때문입니다. 논문도 이런 성격을 설명하기 위해 설계 과학(design science)과 상황별 방법 공학(situational method engineering)이라는 개념을 가져옵니다. 쉽게 풀면, 뼈대는 공유하되 살은 각 조직의 사용례에 맞게 붙이라는 뜻입니다. 저는 이 대목에서 고개를 끄덕였습니다. 은행과 병원과 물류창고가 같은 점검표를 쓸 수는 없기 때문입니다.

그렇다면 무엇을 기대해야 할까요. 저는 회의실에서 쓰는 공통 언어에 가깝다고 봅니다. 목표를 말하는 사람과 위험을 말하는 사람과 시스템을 만드는 사람이 같은 그림을 보고 각자의 결정을 적어 넣는 판이랄까요.

설계 과학과 상황별 맞춤이라는 말을 풀어보면

방법론 논문에서 설계 과학이나 상황별 방법 공학 같은 말이 나오면 눈이 먼저 피로해집니다. 저도 처음에는 그랬습니다. 그런데 여기서는 이 두 개념이 장식이 아니라 뼈대라서 조금 풀어볼 가치가 있습니다.

설계 과학 쪽은 이렇게 이해하면 됩니다. 이 논문은 세상 돌아가는 현상을 설명하는 데서 멈추지 않고, 쓸 수 있는 인공물을 만드는 것을 목표로 합니다. 인공물이라는 말이 거창하게 들리지만 실제로는 절차와 양식과 결정 흐름 같은 것들입니다. 그래서 논문을 읽을 때는 이론이 맞는지만 볼 것이 아니라, 이 절차를 우리 팀에 가져가면 바로 쓸 수 있는지가 판단 기준이 됩니다.

상황별 방법 공학은 그 다음 질문에 답합니다. 조직마다 상황이 다른데 하나의 틀을 어떻게 재사용할까라는 질문이죠. 논문의 답은 부품을 나눠서 조립하자는 것입니다. 위험 영역이나 확증 항목이나 통제 수단을 모듈처럼 나누어 두고, 사용례의 민감도와 자율성 수준에 따라 조합을 바꾸는 방식입니다. 옷을 맞출 때 기성복을 그대로 입지 않고 소매와 기장을 줄이는 것과 비슷합니다.

여기서 재미있는 질문이 생깁니다. 재사용과 맞춤은 서로 반대 방향 아닌가라는 질문입니다. 실제로 현업에서는 표준화하자는 쪽과 현장 사정이 다르다는 쪽이 자주 부딪힙니다. 이 틀이 제안하는 절충은 뼈대 표준화입니다. 위험을 나누는 눈금과 요구를 도출하는 순서는 공유하되, 각 칸에 들어가는 구체적인 기준과 증거 수준은 사용례마다 다르게 정합니다. 저는 이 절충이 현실적이라고 봅니다. 완전히 같은 점검표는 현장에서 외면받고, 완전히 제각각인 점검표는 조직이 학습을 쌓지 못하기 때문입니다.

(참고로 저는 방법론 용어가 많아질수록 오히려 구체적인 예시를 먼저 찾는 편인데요. 이 논문도 뒤쪽에 은행 예시를 두어서 그 부분까지 읽고 나면 앞부분의 추상적인 말이 훨씬 잘 들어옵니다.)

일곱 가지 위험 영역을 나누어 보는 이유

AI-GRACE는 위험을 일곱 가지 영역으로 나누어 평가하자고 제안합니다. 정확한 영역 명칭 하나하나를 외우는 것보다 중요한 것은 왜 나누는지입니다. 에이전트의 실패는 한 가지 색이 아니라 여러 층위에서 동시에 일어나기 때문입니다. 모델이 틀린 답을 내는 문제와, 맞게 움직였는데 조직의 목표와 어긋나는 문제는 서로 다른 층위입니다.

예를 들어 고객 응대 에이전트를 생각해보겠습니다. 답변이 매끄럽지 못한 것은 품질 문제입니다. 그런데 답변이 매끄러운 나머지 고객에게 지키지 못할 약속을 하고, 그 약속이 나중에 환불 분쟁으로 번지면 이제는 임무와 가치 실현의 문제로 번집니다. 같은 대화 로그에서 시작했지만 조직이 입는 피해의 성격은 다릅니다. 위험을 나누지 않으면 이런 파급이 한데 뭉뚱그려져서 대책도 뭉뚱그려집니다.

또 하나 짚을 점은 안전이나 준수만 보지 않는다는 것입니다. 많은 AI 위험 논의가 유해 콘텐츠나 개인정보 같은 눈에 잘 띄는 위험에 머무는데, 현장에서 더 자주 아픈 지점은 따로 있습니다. 기대한 효과를 못 내는 경우, 운영 비용이 조용히 새는 경우, 사람이 에이전트를 믿고 확인을 게을리하면서 생기는 빈틈 같은 것들입니다. 논문이 미션과 가치 실현을 위험 영역에 포함한 것은 그래서 의미가 있습니다. 에이전트가 사고를 내지 않는 것을 넘어서, 하기로 한 일을 실제로 해내는지까지 묻기 때문입니다.

그렇다면 일곱 개라는 숫자는 많을까요, 적을까요. 저는 적당한 출발점이라고 봅니다. 세 개로 줄이면 논의가 편해지지만 현장의 뉘앙스가 사라지고, 스무 개로 늘리면 정밀해지지만 아무도 끝까지 쓰지 않습니다. 중요한 것은 일곱 개를 고정된 정답으로 보지 않고, 우리 조직의 사용례에 맞게 다듬을 수 있는 눈금으로 보는 태도입니다. 논문이 상황별 맞춤을 강조한 것도 같은 맥락으로 읽힙니다.

배포 전 확증과 실행 중 통제는 어떻게 갈라질까

위험을 나눴다면 다음 순서는 요구사항입니다. 논문은 크게 세 갈래로 요구를 끌어냅니다. 배포 전에 미리 확보해야 하는 확증(assurance), 운영 중에 계속 작동해야 하는 통제(controls), 그리고 나중에 판단과 감사를 위해 남겨야 하는 증거(evidence)입니다. 세 단어가 비슷하게 들리지만 역할은 분명히 다릅니다.

배포 전 확증은 출발 전 점검에 가깝습니다. 이 에이전트가 맡은 일을 할 자격이 있는지, 경계 조건에서 어떻게 행동하는지, 사람이 개입해야 하는 지점을 아는지 미리 확인합니다. 테스트 결과와 평가 기록과 승인 문서가 여기에 들어갑니다. 반면 실행 중 통제는 운항 중 계기에 가깝습니다. 권한 제한과 승인선, 입력과 출력에 대한 가드레일, 이상 징후를 감지했을 때 멈추거나 에스컬레이션하는 장치가 여기에 속합니다.

증거는 이 둘을 묶는 실밥입니다. 배포 전에 무엇을 확인했는지, 운영 중에 어떤 통제가 실제로 작동했는지, 에이전트가 어떤 도구를 어떤 순서로 호출했는지를 남깁니다. 나중에 문제가 생겼을 때 원인을 따지려면 이 기록이 있어야 하고, 다음 배포를 더 잘하려면 이 기록을 다시 읽어야 합니다. 저희가 새로운 AI 아키텍처를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고 그 변화가 운영에서 어떤 기록과 비용을 남기는지를 함께 봅니다. 같은 눈으로 보면 확증과 통제와 증거는 따로 떨어진 서류가 아니라 하나의 순환입니다.

여기서 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 그래서 무엇을 어디까지 남길 것인가라는 질문입니다. 모든 도구 호출을 전부 저장하면 나중에 든든할 것 같지만 저장 비용과 검토 비용이 같이 불어납니다. 반대로 요약만 남기면 가볍지만 분쟁이 생겼을 때 재구성이 어렵습니다. 논문이 역량 자격 부여(capability qualification)와 간극 평가(gap assessment)를 말하는 대목이 바로 이 고민과 연결됩니다. 지금 가진 역량으로 요구를 감당할 수 있는지, 모자란 부분은 무엇인지 먼저 따져보자는 것입니다.

운영 외피와 독립 수준은 어떻게 결정을 남길까

이 논문에서 제가 자꾸 밑줄을 친 부분은 두 가지 장치입니다. 하나는 Agent Operating Envelope이고, 다른 하나는 Risk-Aligned Independence Levels, 줄여서 RAIL입니다. 이름이 길어서 부담스럽지만 하는 일은 직관적입니다.

운영 외피(Operating Envelope)는 에이전트가 이 사용례에서 해도 되는 일과 사람에게 넘겨야 하는 일의 경계를 적은 문서입니다. 허용된 행동과 에스컬레이션 조건을 명시합니다. 비행 용어에서 가져온 비유로 보면 비행 가능 영역을 그려두는 것과 비슷합니다. 이 영역 안에서는 에이전트가 스스로 판단해도 되고, 영역을 벗어나면 반드시 멈추거나 보고하게 만드는 것이죠. 말로만 자율성을 논하지 않고 경계를 글로 남긴다는 점이 중요합니다.

RAIL은 그 경계에 붙는 요약 딱지 같은 것입니다. 해당 에이전틱 시스템에 부여된 독립 수준을 위험에 맞추어 정리합니다. 전부 자동인지, 사람이 승인하면 진행하는지, 사람이 지켜보는 가운데 움직이는지를 사용례의 위험에 맞게 적습니다. 저는 이 요약이 회의에서 꽤 유용하겠다고 느꼈습니다. 기술 문서 수십 장을 다 읽지 않아도 이 사용례의 자율성이 어느 수준으로 합의되었는지 한눈에 볼 수 있기 때문입니다.

문제는 그다음입니다. 이런 문서를 만들어두고 실제로 지키게 하려면 어떻게 해야 할까요. 문서와 실행이 따로 놀면 외피는 장식이 됩니다. 그래서 외피에 적힌 허용 행동은 도구 권한과 승인 워크플로와 로그 정책으로 그대로 이어져야 합니다. RAIL에서 정한 독립 수준도 프롬프트 한 줄이 아니라 시스템 설정과 모니터링 규칙으로 구현되어야 하죠. 논문의 흐름이 거버넌스에서 아키텍처까지 이어진다고 말할 때, 저는 이 대목을 떠올립니다. 결정이 설정으로 번역되는 지점이 바로 외피와 RAIL이기 때문입니다.

가상의 은행 창구에서 프레임워크 돌려보기

논문은 이 방법을 가상의 소매은행 응용으로 예시합니다. 실제 은행의 운영 기록이 아니라, 프레임워크가 어떻게 돌아가는지 보여주기 위한 가상의 장면입니다. 저는 이런 가상의 예시가 오히려 읽기 편했습니다. 숫자의 정확성을 따지기보다 순서의 타당성을 따라가면 되기 때문입니다.

장면을 구체적으로 그려보겠습니다. 어느 은행이 여신 상담 보조 에이전트를 들이려 한다고 해보죠. 아침에 고객이 대출 조건을 묻고, 에이전트는 약관을 찾아주고 서류를 안내하고 다음 예약을 잡아줍니다. 여기까지는 평온합니다. 그런데 고객이 한도를 올려달라고 하면서 예외 승인을 요청하면 공기가 달라집니다. 이 요청을 에이전트가 바로 처리해도 될까요, 아니면 심사 담당자에게 넘겨야 할까요.

AI-GRACE의 순서대로라면 먼저 조직의 목표와 의무부터 적습니다. 상담 대기 시간을 줄이겠다는 목표와 함께, 금융 설명 의무와 개인정보 보호와 기록 보관 같은 의무가 나옵니다. 그다음 일곱 가지 위험 눈금으로 들여다봅니다. 잘못된 조건 안내로 생기는 고객 피해, 약관 해석 오류로 생기는 분쟁, 상담 기록이 부실해서 감사에서 지적받는 경우까지 함께 봅니다. 위험이 보이면 요구가 따라옵니다. 배포 전에는 약관 근거를 대조하는 평가를 거치게 하고, 운영 중에는 한도 변경 같은 민감한 행동은 승인선을 넘지 못하게 막고, 상담 근거와 도구 호출 기록은 증거로 남깁니다.

그리고 이 결정들을 외피와 RAIL에 옮겨 적습니다. 일반 안내는 에이전트가 직접 답할 수 있지만 한도나 금리 같은 조건 변경은 사람 승인 없이는 실행하지 못한다고 적는 것이죠. 독립 수준도 한 줄로 정리합니다. 이 사용례에서는 조회와 안내는 자율, 실행과 예외는 사람 승인이라는 식입니다. 이렇게 적어두면 나중에 누군가 왜 이렇게 느리냐고 물어도 답이 있습니다. 느린 것이 아니라 정한 경계 안에서 움직이는 중이라고 말할 수 있기 때문입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 이 예시는 방법이 돌아가는 모습을 보여줄 뿐, 은행에 바로 붙이면 된다는 처방이 아닙니다. 실제 은행이라면 상품 구조와 내부 통제와 감독 기준이 훨씬 촘촘해서 같은 틀이라도 칸마다 들어가는 기준이 달라집니다. 논문이 실증 평가가 남았다고 말한 대목도 그래서 정직하게 읽힙니다. 틀이 좋아 보이는 것과 현장에서 결정을 빠르게 하고 재사용을 늘리는 것은 다른 문제이기 때문입니다.

아직 증명되지 않은 것과 앞으로 확인할 일

논문은 스스로 한계를 비교적 분명히 밝힙니다. 이 틀이 배포 결정과 효율과 재사용에 실제로 어떤 효과를 내는지는 실증 평가로 확인해야 한다는 것입니다. 저는 이 문장을 건성으로 넘기지 않았습니다. 프레임워크 논문에서 가장 어려운 부분이 바로 여기이기 때문입니다. 그림은 그럴듯한데 현장에서 살아남는지는 다른 이야기이기 때문입니다.

실제 시스템 관점에서 보면 궁금한 것이 한둘이 아닙니다. 일곱 가지 위험 영역이 서로 겹칠 때 우선순위는 어떻게 정할까요. 확증 항목이 늘어날수록 배포는 느려지는데, 어디에서 멈춰야 과도한 문서 작업이 되지 않을까요. RAIL을 정해두었는데 모델이 바뀌거나 도구가 추가되면 독립 수준은 언제 다시 심의할까요. 이런 질문에 답이 없으면 틀은 서랍에 들어갑니다.

저는 특히 재사용이라는 말이 계속 마음에 걸리는 지점인데요. 한 은행의 상담 창구에서 만든 외피가 다른 상품이나 다른 채널에서도 쓸 수 있어야 이 틀이 힘을 받습니다. 그런데 사용례마다 의무와 위험이 다르면 재사용은 말처럼 쉽지 않습니다. 어떤 부분은 그대로 가져가고 어떤 부분은 새로 써야 하는지, 그 경계를 나누는 경험이 쌓여야 합니다. 논문이 상황별 맞춤을 말한 것도 결국 이 경험을 쌓기 위한 출발선으로 보입니다.

그렇다면 이 흐름은 어디에서 더 단단해질 수 있을까요. 저는 현장의 기록에서 답을 찾을 것 같습니다. 배포 회의에서 어떤 위험이 실제로 논의되었고, 어떤 통제가 오탐을 냈고, 어떤 증거가 분쟁에서 도움이 되었는지를 모아 틀을 다듬는 것입니다. 이론이 현장을 가르치는 데서 멈추지 않고 현장이 이론을 고쳐주는 순환이 생기면, 그때부터는 문서가 아니라 업무 방식이 됩니다.

그래서 도입 회의에서 무엇을 바꿀 수 있을까

처음으로 돌아가 보겠습니다. 모델이 믿을 만한지와 쓸 수 있는지는 다른 질문이었습니다. AI-GRACE는 그 둘 사이를 잇는 작업대 같은 논문입니다. 왼쪽에는 조직의 목표와 의무를 놓고, 오른쪽에는 배포 역량과 아키텍처를 놓고, 가운데에서 위험과 요구와 증거를 엮습니다.

제가 앞으로 보고 싶은 것은 거창한 성공 사례보다 작은 운영 기록입니다. 외피를 도입한 팀이 에스컬레이션 기준을 몇 번 고쳤는지, RAIL을 정한 뒤 승인 병목이 어떻게 달라졌는지, 증거 기록이 실제 장애 분석 시간을 얼마나 줄였는지 같은 것들입니다. 이런 기록이 쌓이면 프레임워크는 구호에서 손에 잡히는 절차로 내려옵니다.

에이전트를 들인다는 말은 이제 흔해졌습니다. 그 말을 실행 계획으로 바꾸는 일은 아직 흔하지 않습니다. 무엇을 맡기고 어디에서 멈추고 무엇을 남길지를 미리 글로 적어두는 것, 저는 그 사소해 보이는 약속이야말로 이 논문이 남기는 가장 실제적인 제안이라고 봅니다. 다음에 에이전트 도입 회의에 들어가시면 한 가지 질문부터 꺼내보셔도 좋겠습니다. 우리의 외피는 지금 어디에 적혀 있나요라는 질문 말입니다.