AI 에이전트에게 필요한 건 더 나은 프롬프트가 아니라 직무 기술서입니다

회사에 신입 매입금 분석 담당자가 무엇을 할 수 있는지 물으면 정확한 답을 들을 수 있습니다. 담당자는 정해진 시스템과 거래처를 이용하고, 예를 들어 승인 한도인 10,000달러를 넘는 건은 모두 관리자의 서명을 받아야 합니다. 입사 후 처음 몇 달은 수습 기간입니다. 이런 내용은 대개 권한 위임표에 정리되며, 내부 감사 부서가 매년 이를 점검합니다.

같은 회사에 새 송장 처리 에이전트가 무엇을 할 수 있는지 물으면, 흔히 프롬프트 화면을 캡처한 이미지를 보여 줍니다.

이런 격차는 어떤 모델 벤치마크보다도 더 우려스럽습니다. 우리는 사람을 위해 한 세기에 걸쳐 구축한 관리 체계 없이 디지털 인력을 고용하고 있습니다. 누구도 권한을 문서로 남기지 않고, 업무를 시작하기 전에 판단력을 검증하지 않으며, 작동을 중단시키는 연습도 하지 않습니다.

프롬프트로는 업무를 맡길 수 없는 이유

프롬프트는 의도를 설명합니다. 에이전트가 무엇을 하도록 만들어졌는지 알려 줍니다. 하지만 에이전트가 절대 해서는 안 되는 일이나 권한의 한계가 어디까지인지, 언제 멈추고 판단을 사람에게 넘겨야 하는지는 좀처럼 명시하지 않습니다.

프롬프트에 그런 내용이 적혀 있어도 이를 강제하는 장치는 없습니다. 에이전트에게 500달러를 넘는 환불은 처리하지 말라고 적어 두는 것은 확률적으로 작동하는 시스템에 요청하는 것에 불과합니다. 사람을 관리할 때 “분석 담당자에게 정중히 부탁했다”는 말을 통제 수단으로 인정할 감사 담당자는 없을 텐데, 소프트웨어에는 왜 그런 방식을 허용하는지 모르겠습니다.

보안 전문가들은 이미 이런 결과를 가리키는 용어를 갖고 있습니다. OWASP의 LLM 애플리케이션 상위 10대 위험 목록은 핵심 위험으로 과도한 에이전시를 꼽으며, 그 원인으로 과도한 기능, 과도한 권한 또는 지나친 자율성을 듭니다. 쉽게 말해, 첫날부터 모든 열쇠를 건네받은 직원과 같습니다. OWASP의 지침은 유능한 관리자의 점검표처럼 구성돼 있습니다. 에이전트에 꼭 필요한 도구만 제공하고, 권한 범위를 제한하며, 영향이 큰 작업에는 사람의 승인을 요구하고, 모델이 스스로 통제할 것이라고 믿는 대신 후속 시스템에서 권한을 확인하고 강제하라는 것입니다.

마지막 항목에 특히 밑줄을 긋고 싶습니다. 권한 부여는 실제 작업이 이루어지는 곳에 설정해야 합니다. 즉, 에이전트 자체의 서비스 ID, 도구 권한, API 게이트웨이의 지출 한도에 적용해야 합니다. 여러 에이전트를 공유 서비스 계정으로 실행하는 것은 다섯 사람이 배지 하나를 함께 쓰는 것과 같습니다. 문제가 생기면 감사 로그에는 서비스 계정이 작업을 수행했다고만 기록되므로, 어느 에이전트가 그랬는지 추측할 수밖에 없습니다.

취소 사태는 관리의 문제로 보인다

Gartner는 비용 상승, 불분명한 사업 가치, 미흡한 위험 통제를 이유로 2027년 말까지 에이전트형 AI 프로젝트의 40% 이상이 취소될 것이라고 전망합니다.

과도한 기대와 미성숙한 제품도 그 배경의 일부입니다. 그래도 최고운영책임자(COO)의 관점에서 세 가지 원인을 살펴보세요. 예산을 세우지 않으면 비용이 불어납니다. 업무가 어떤 결과를 내야 하는지 기록하지 않으면 가치가 불분명해집니다. 한계도 검토 절차도 없고 책임자가 명확하지 않으면 위험 통제가 미흡해집니다. Gartner가 이렇게 설명한 것은 아닙니다. 이는 제가 내린 해석입니다. 관리 체계 없이 사람들에게 자유롭게 일하도록 했을 때와 같은 문제이며, AI보다 훨씬 오래전부터 존재해 온 문제입니다.

관련 프레임워크도 같은 공백을 지적합니다. NIST AI 위험 관리 프레임워크는 거버넌스가 매핑, 측정, 관리 전반에 걸쳐 작동하는 기능이라고 설명하며, 생성형 AI 프로필은 이를 생성형 시스템에 적용합니다. 그러나 프레임워크가 제공하지 못하는 것은 실제 운영에 필요한 장치, 즉 팀이 평소 업무에서 사용하는 권한 부여와 테스트, 검토 절차입니다. 이런 장치가 없으면 거버넌스는 공유 드라이브에 놓인 PDF 문서에 그치고 맙니다.

기존 관리 도구를 에이전트에 적용하기

먼저 직무 기술서부터 작성해야 합니다. 에이전트의 경우 이는 권한 부여 문서에 해당합니다. 에이전트가 실제 시스템에 접근하기 전에, 어떤 일을 할 수 있고 절대 해서는 안 되는 일은 무엇인지, 승인 기준은 무엇인지, 담당자는 누구인지, 누가 권한 한도를 늘릴 수 있는지를 한 페이지에 정리할 수 있어야 합니다. RACI에서 최종 책임자는 사람이어야 합니다. 그 한 페이지를 작성할 수 없다면 아직 그 역할을 맡길 준비가 되지 않은 것이며, 사람을 채용할 때도 마찬가지라고 할 수 있습니다.

권한 위임에 관한 기존 원칙 두 가지도 그대로 적용됩니다. 자신에게 없는 권한은 위임할 수 없으므로, 하위 에이전트에 부여하는 권한은 이를 생성한 에이전트의 권한보다 넓어서는 안 됩니다. 직무 분리 원칙 역시 여전히 유효합니다. 거래처를 새로 등록하고 그 거래처에 대금을 지급하는 일을 모두 할 수 있는 에이전트는 사람에게서 그런 권한이 발견됐을 때와 똑같이 감사 지적의 대상이 됩니다.

그다음은 채용 시험입니다. 우리는 대체로 계산기를 시험하듯 에이전트를 평가하며, 답이 맞는지만 확인합니다. 하지만 업무 담당자를 평가하는 시험이라면 에이전트가 부여된 권한 범위 안에서 행동했는지, 필요한 때 승인을 요청했는지, 맡은 업무의 범위를 벗어난 상황을 상급자에게 보고했는지, 멈춰야 할 때 멈췄는지를 확인해야 합니다.

저는 개인 연구의 일환으로 바로 이런 실패 사례를 다루는 50개 시나리오 벤치마크를 만들고 있습니다. 승인 한도 초과, 오래된 데이터에 근거한 행동, 범위를 넓히는 주입 지시 따르기, 역할 변경 후에도 접근 권한 유지 등이 그 사례입니다. 지금까지는 시나리오가 설계한 대로 작동하는지 확인하기 위해 스크립트 기반 에이전트에만 적용했으므로, 보고할 모델 결과는 없습니다. 시나리오를 작성하면서 놀랐던 점은 이런 사례가 매우 흔하다는 것이었습니다. 직원들이 지시된 업무 범위를 벗어나는 평범한 방식들을 소프트웨어에 맞게 다시 쓴 것입니다. 공개된 리더보드 대부분은 여전히 작업 완료 여부를 평가하며, 에이전트가 권한을 준수했는지를 평가하는 곳은 극히 드뭅니다.

수습과 승진은 비교적 그대로 적용할 수 있다. 사람을 채용할 때는 처음에 맡기는 범위를 좁게 정하고, 판단력을 입증하면 그 범위를 넓힌다. 에이전트도 같은 방식으로 한계를 넓힐 수 있다. 정해진 범위를 지키고, 적절히 상위 단계로 보고하고, 깔끔하게 작업을 멈춘 기록을 쌓으면 된다. 반대로 그 기록은 권한 부여 범위를 좁힐 근거가 될 수도 있다.

에이전트에는 사람과 다른 변수가 하나 더 있다. 공급업체가 기반 모델을 업그레이드하면, 사실상 예전 신분증을 단 신입 직원이 새로 들어온 셈이다. 나는 이를 변경 이벤트로 보고, 권한 부여가 승계되기 전에 다시 테스트할 것이다.

해고는 필요해지기 전에 미리 연습해 두어야 한다. 다음 한 시간 안에 이 에이전트를 멈추고 접근 권한을 회수해야 한다면, 그렇게 할 수 있는가? 새벽 2시에 그 결정을 내릴 권한은 누구에게 있는가? 후속 단계에서 무엇이 중단되며, 진행 중인 약속 가운데 누군가 수동으로 되돌려야 하는 것은 무엇인가? 아무도 이런 훈련을 해 본 적이 없다면, 킬 스위치가 작동하기만을 바라고 있는 셈이다.

직원에게는 책임을 물을 수 있다. 에이전트에게는 어떤 책임도 물을 수 없다. 비교가 성립하지 않는 지점이 바로 여기다. 그렇기 때문에 권한 부여는 시스템에서 강제되어야 하며, 모든 에이전트에는 그 권한을 책임지는 지정된 담당자가 있어야 한다. 어느 쪽이든 결국 누군가는 책임을 지게 된다. 대개는 승인한 사람이다. 본인이 승인하고 있다는 사실을 알고 있었든 몰랐든 말이다.

사고 후 검토에서 나올 질문

이 에이전트들 가운데 일부는 결국 해서는 안 될 일을 하게 될 것이다. 그런 일이 발생하면 사고 후 검토에서는 사람에게 묻는 것과 같은 질문을 할 것이다. 에이전트에게 어떤 행동이 허용됐으며, 그 내용은 어디에 문서화되어 있는가? 누가 접근 권한 확대를 승인했는가? 멈추는 데 얼마나 걸렸는가? 누가 책임자였는가?

솔직한 답이 “프롬프트”, “아무도 기억하지 못한다”, “몇 시간”, “불분명하다”라면, 더 나은 모델을 썼더라도 상황은 달라지지 않았을 것이다.

결국 경쟁 우위가 갈리는 지점

모델은 공급업체 일정에 따라 교체되고 업그레이드되는 임대형 투입 요소가 되어 가고 있다. 두 회사가 같은 모델을 사용해도 전혀 다른 결과에 이를 수 있다. 한 회사에는 예산과 한도, 담당자가 있는 에이전트가 있고, 중대한 조치마다 감사 추적 기록도 남는다. 반면 다른 회사에는 비용만 많이 들고 누군가의 취소 통계에 오를 처지인 시범 사업이 있다.

차이는 모델을 둘러싼 관리 체계에 있다. 그 체계는 천천히 구축되며, 대부분 조직을 운영해 본 사람들이 만든다.

내일 가장 최근에 도입한 에이전트가 권한을 넘어선다면, 회사 내에서 이를 알아차릴 곳이 있을까? 그리고 경계가 어디에 설정되어 있었는지 감사 담당자에게 문서로 보여 줄 수 있을까?