AI 에이전트 거버넌스가 실제로 작동하는 통제점 세 곳

AI 에이전트 거버넌스가 실제로 굴러가는 자리는 세 곳입니다. 에이전트에게 준 권한, 그 권한으로 한 일이 남는 감사 로그, 권한 밖의 일이 필요할 때 여는 예외 승인. 이 세 칸에 담당과 기록과 시점이 들어가면 정책 문서는 그때부터 힘을 갖습니다.

규칙 문서를 이미 한 장 만들어 둔 회사에는 다음 질문이 옵니다. 모회사 실사나 보안 심사 자리에서 “그 규칙이 지켜지고 있다는 것을 무엇으로 보여 주시겠습니까”라는 물음을 받습니다.

문서를 내밀면 상대는 문서를 읽지 않습니다. 언제 누가 무엇을 승인했고 그 뒤에 무슨 일이 있었는지를 묻습니다.

그 물음에 답이 되는 것은 규정의 문장이 아니라 통제가 돌아간 흔적입니다. 세 통제점은 그 흔적이 생기는 자리를 시스템 구조 쪽에서 짚은 것입니다.

정책을 다시 쓰는 일은 여기서 필요하지 않습니다. 이미 있는 규칙이 닿지 못하는 층에 담당과 기록을 붙이는 일이 먼저 옵니다.

AI 에이전트 거버넌스에서 실제로 작동하는 통제점은 어디인가요?

권한, 감사 로그, 예외 승인 세 곳입니다. 에이전트가 사람 손을 거치지 않고 시스템을 건드리는 지점, 거기 걸리는 통제만 남겼습니다. 사용 정책이나 데이터 분류처럼 사람의 행동을 다루는 항목은 이 셋에 들어가지 않습니다.

통제점마다 채울 칸은 셋입니다. 누가 정하는가, 무엇으로 남는가, 언제 되돌아보는가.

세 칸이 다 차야 한 통제점이 섭니다.

통제점	누가 정하나	무엇으로 남나	언제 되돌아보나
권한	범위는 업무 부서장, 구현은 시스템 담당	에이전트 계정별 권한 목록	연동 대상이나 업무 절차가 바뀔 때
감사 로그	읽을 항목을 권한 정한 두 사람이 함께	실행 이력과 그것을 읽은 사람의 판정	정해진 주기, 그리고 이상 신호가 뜬 날
예외 승인	그 권한을 가진 부서의 결재선	사유·범위·기간과 만료 처리 결과	만료일

세 칸의 머리글이 이렇게 정해진 이유가 있습니다. 감사나 실사에서 되풀이되는 질문이 결국 담당과 증빙과 시점을 묻는 형태로 들어오기 때문이죠. 담당이 없으면 답할 사람이 없고, 증빙이 없으면 말만 남고, 시점이 없으면 언제 확인한 상태인지가 흐려집니다.

빈칸을 세는 것만으로도 진단이 됩니다. 아홉 칸 가운데 몇 칸이 이름과 날짜로 채워지는지 세어 보십시오. 그 숫자가 지금의 통제 수준입니다.

후보에 올랐다가 빠진 항목도 있습니다. 모델 버전 관리, 데이터 분류표, 산출물 검토 절차. 거버넌스 논의에서 늘 함께 거론되는 항목들입니다. 셋 다 필요한 일이지만 이 표에는 넣지 않았습니다.

기준은 하나였습니다. 그 통제가 비었을 때 에이전트가 사람 몰래 무언가를 실행할 수 있는가입니다. 모델 버전이 관리되지 않으면 품질이 흔들리고 데이터 분류가 없으면 입력 기준이 흐려지지만, 둘 다 사람이 결과를 보고 되돌릴 수 있는 층에서 벌어지죠. 권한·로그·예외가 비는 경우는 다릅니다. 무슨 일이 있었는지를 사후에도 알 수 없어, 되돌릴 기회 자체가 오지 않습니다.

정책 문서가 있는데도 통제가 서지 않는 자리

사용 규칙은 사람을 대상으로 씁니다. 누가 어떤 도구를 쓰는지, 무엇을 입력하지 않는지가 그 문서의 내용입니다.

에이전트는 그 문장이 닿지 않는 곳에서 움직입니다. 야간 배치로 전표를 만들고, 사람이 결재를 올리기 전에 재고 데이터를 읽고, 담당자가 자리에 없는 시간에도 계속 돕니다. 승인된 도구 목록에 에이전트 이름이 올라 있어도 그 목록에는 이 에이전트가 어느 테이블까지 읽고 어디에 쓰는지가 적히지 않습니다.

그래서 문서와 현실 사이에 층이 하나 빕니다. 규칙은 사람의 입력을 다루는데, 위험은 에이전트의 실행 쪽에서 자랍니다.

이 층이 비어 있으면 사고의 모양도 달라집니다. 사람의 잘못된 입력은 대개 한 건에서 끝나지만, 에이전트에 잘못 열린 권한은 같은 처리를 계속 반복하다 뒤늦게 발견되니까요.

발견이 늦어지는 이유도 같은 데서 나옵니다. 사람이 실수하면 실수한 사람이 알고 있어서 되돌릴 계기가 생기는데, 자동으로 도는 처리는 결과가 다음 단계로 넘어간 뒤에야 이상하다는 말이 나오죠. 마감 자료가 어긋나거나 거래처 쪽에서 연락이 오는 시점이 대개 그 자리입니다.

이 빈 층을 메우는 방법이 통제점을 시스템 쪽에 거는 것입니다. 규칙 문서를 두껍게 만드는 대신, 에이전트가 실제로 지나가는 길목 세 곳에 담당과 기록을 붙입니다. 거버넌스 문서 자체를 네 요소로 처음 세우는 순서는 사용 정책부터 점검 주기까지 한 장으로 세우는 최소 프레임에서 따로 다뤘습니다.

권한 목록은 누가 어디까지 정하나요?

범위는 그 데이터를 책임지는 업무 부서장이, 구현은 시스템 담당이 정합니다. 둘을 한 사람에게 몰면 결과가 한쪽으로 기웁니다.

시스템 담당이 혼자 정하면 업무가 막힙니다. 무엇이 필요한지 모르니 좁게 열고, 현장에서 안 된다는 말이 나오면 그때마다 조금씩 넓히게 되거든요. 반대로 업무 부서가 혼자 정하면 “일단 다 열어 달라”로 끝납니다.

ERP 연동 설계에 들어가면 권한 범위를 확정하는 데 며칠이 걸리는 일이 흔합니다. 이 에이전트가 무엇까지 할 수 있어야 하는가에 부서가 답을 갖고 있지 않기 때문이죠. 저는 이 질문에 회사가 답하는 데 걸리는 시간을 통제 상태의 지표로 봅니다. 하루 만에 답이 나오는 곳은 이미 업무 단위로 데이터 책임이 나뉘어 있고, 답이 미뤄지는 곳은 그 경계 자체가 흐린 상태였습니다.

기록으로 남을 것은 에이전트 계정별 권한 목록 한 장입니다. 한 줄에 무엇을 적는지는 아래로 정리됩니다.

에이전트 이름과 담당 업무
그 에이전트가 쓰는 전용 계정
닿는 시스템과 대상 범위(테이블·모듈 단위)
읽기인지 쓰기인지의 구분
승인자 이름과 승인일

구축을 서두른 연동에서 비어 있는 자리가 두 번째 줄입니다. 담당자 계정을 그대로 물려주는 경로가 생기거든요. 붙이기는 빨라지지만 그 순간 권한 목록이 만들어지지 않고, 뒤에 오는 두 통제점이 함께 흔들립니다.

세 번째 줄의 단위를 무엇으로 잡을지도 실무에서 걸립니다. 데이터베이스에 직접 붙는 구성이라면 테이블과 컬럼으로 적힙니다. 표준 연동 규격을 쓰는 시스템에는 그런 이름이 아예 없습니다.

그럴 때는 그 시스템이 제공하는 단위를 그대로 씁니다. 업무 모듈로 권한이 갈리는 전사 시스템이라면 모듈 이름으로, 규격화된 호출로 붙는 서비스라면 호출 목록으로 적으면 되죠. 우리가 쓰는 말로 번역해 옮기면 나중에 로그와 대조할 때 두 이름이 어긋나 대조가 성립하지 않습니다.

에이전트가 여럿으로 늘면 목록이 길어지는 문제가 뒤따릅니다. 한 장에 담기기는 해도 한눈에 들어오지 않는 길이가 됩니다. 이때는 에이전트마다 한 줄을 유지하는 대신 업무 단위로 묶어 접습니다. 같은 업무를 나눠 처리하는 에이전트들은 대상 범위가 겹치므로, 묶어 두면 그 업무의 권한 폭이 한눈에 들어옵니다.

SAP나 더존처럼 전사 규모의 시스템이 대상이면, 저는 읽기 권한과 쓰기 권한의 결재선을 처음부터 갈라 둡니다. 조회는 부서장 승인으로 충분하지만 전표를 생성하거나 마스터 데이터를 고치는 권한이 같은 선에서 결재되면, 승인한 쪽도 무엇을 승인했는지 나중에 설명하기 어려워지죠.

되돌아보는 시점은 달력이 아니라 사건입니다. 연동 대상이 하나 늘거나 업무 절차가 바뀌면 권한 목록을 엽니다. 분기마다 정기적으로 훑는 방식은 그 사이에 늘어난 권한을 몇 달간 방치하게 됩니다.

권한을 기술적으로 얼마나 좁힐지, 로그를 어떤 형식으로 보존할지는 층이 다른 이야기입니다. 설정 기준 쪽은 감사가 반복해 묻는 접근 통제·보존 설정 목록에서 다뤘습니다.

감사 로그는 남기는 것으로 끝나나요?

남기는 것은 절반입니다. 읽는 사람이 정해져 있을 때 로그가 통제가 되죠.

“로그는 다 남고 있습니다”는 답이 감사 자리에서 약한 이유가 여기 있습니다. 남아 있다는 사실은 저장 설정의 문제이고, 통제는 그 기록으로 누가 무엇을 판정했느냐의 문제니까요.

읽을 항목은 권한 목록에서 그대로 파생됩니다. 목록이 정상의 정의를 쥐고 있으니, 찾을 것은 그 정의를 벗어난 흔적뿐입니다. 실무에서 뽑아 두면 쓸모 있는 신호는 셋입니다.

권한 목록에 없는 대상에 접근이 일어난 기록
읽기만 허용된 대상에 쓰기가 일어난 기록
예외 기간이 끝난 뒤에도 이어진 접근

이 셋이 정해지면 로그 읽기가 짧게 끝납니다. 전체를 훑는 대신 세 가지 조건에 걸리는 줄만 뽑아 보면 되거든요. 읽을 것을 정하지 않으면 양이 부담이 되고, 부담이 되면 아무도 열지 않습니다.

신호를 뽑기 전에 확인할 것이 하나 있습니다. 로그의 행위자 칸에 무엇이 찍히느냐죠.

에이전트 전용 계정으로 붙어 있으면 그 계정 이름이 그대로 남습니다. 반면 사람의 세션을 빌려 호출하는 구성에서는 실행 주체가 사람으로 기록되어, 담당자가 직접 한 조회와 에이전트가 자동으로 돈 조회가 같은 줄로 보이죠. 이 상태에서는 세 신호 가운데 어느 것도 판정이 되지 않습니다.

설정 화면에서 계정이 갈라져 있어도 실제 기록에는 연동용 계정 하나로만 남는 경우가 있습니다. 그래서 저는 온프레미스로 사내에 둔 구성에서 로그를 한 줄 뽑아 행위자 칸을 눈으로 확인하는 일을 착수 체크리스트에 넣습니다. 판정의 근거가 되는 것은 화면이 아니라 남은 줄입니다.

읽은 사람의 판정도 기록에 함께 남겨야 합니다. 걸린 줄이 정상 업무였는지 확인이 필요한 건이었는지를 한 줄로 남겨 두지 않으면, 다음 사람이 같은 줄을 처음부터 다시 봅니다. 판정이 쌓이면 그것 자체가 이 회사에서 무엇이 정상인지의 사례집이 되고요.

판정 한 줄의 형식은 간단해도 됩니다. 날짜와 읽은 사람, 걸린 건수, 그중 확인이 필요했던 건과 그 처리 결과. 이 정도면 됩니다. 형식이 길어지면 읽는 일보다 적는 일이 부담이 되어 주기가 밀립니다.

주기를 정하는 기준은 되돌릴 수 있는 시간입니다. 잘못 생성된 전표를 마감 전에 잡을 수 있다면 주기는 마감보다 짧아야 하고, 되돌릴 수 없는 처리라면 주기가 아니라 실행 직전 확인 쪽으로 통제가 옮겨 가야 하죠. 한 달에 한 번이라는 답이 회사마다 맞을 수도 틀릴 수도 있는 것은 이 때문입니다.

그래서 주기를 정할 때는 달력보다 업무 일정표를 먼저 폅니다. 대상 업무의 마감일과 승인 절차가 언제 걸리는지를 보면 로그를 열어야 하는 날이 자연히 짚이죠. 마감 이틀 전, 정산 전날처럼 되돌릴 여지가 남아 있는 지점이 그 자리입니다.

이상 신호가 뜬 날은 주기와 상관없이 로그를 여는 날이죠. 자동 경보를 걸어 두었다면 경보가 뜬 날이 곧 읽는 날이고, 그날의 판정도 같은 자리에 남깁니다.

예외 승인은 어떻게 열고 무엇으로 닫나요?

사유와 기간을 적어 열고, 만료 처리 결과로 닫습니다. 연동 착수 자리에서 마주치는 상태는 여는 절차만 있고 닫는 기록은 없는 쪽입니다.

예외가 필요한 자리는 실제로 생깁니다. 월말 마감에 평소 쓰지 않던 데이터가 필요해지고, 장애를 복구하느라 임시로 범위를 넓혀야 하고, 대량 이관 작업에 일시적인 쓰기 권한이 붙습니다.

이 절차가 없으면 우회가 생깁니다. 급한 일이 생겼을 때 승인을 거칠 자리가 없으니 권한 목록 자체를 넓히게 되고, 한번 넓힌 권한은 좀처럼 다시 좁아지지 않죠. 예외 승인은 권한 목록을 원래 크기로 지키기 위한 장치에 가깝습니다.

승인은 그 권한을 가진 부서의 결재선에서 나야 합니다. 시스템 담당이 단독으로 열고 닫으면 절차가 빨라지는 대신 통제가 아니라 편의가 되죠. 기술적으로 열 수 있는 사람과 열어도 된다고 판단하는 사람은 갈라 두는 편이 안전합니다.

남길 것은 네 가지입니다.

항목	적는 내용
사유	어떤 업무 때문에 필요한가
범위	어느 대상에 어떤 조작을 여는가
기간	언제부터 언제까지인가
만료 처리	기간이 끝난 뒤 실제로 회수했는가, 연장했다면 그 근거는 무엇인가

예외를 두 종류로 나눠 두면 결재 부담이 줄어듭니다. 기간형과 건별형입니다.

기간형은 마감 주간처럼 정해진 구간 동안 범위를 넓히는 형태이고, 건별형은 특정 작업 한 번에만 열어 주고 그 작업이 끝나면 닫는 형태입니다. 앞의 것은 만료일이 통제 수단이고, 뒤의 것은 작업 완료 보고가 그 몫을 맡습니다. 둘을 구분하지 않으면 한 번 쓰고 끝날 권한이 한 달짜리 기간 승인으로 나가는 일이 생깁니다.

기본 만료를 짧게 잡고 필요하면 다시 신청하게 하는 방식이 값이 쌉니다. 길게 열어 두고 나중에 회수하려면 그때 가서 누가 무엇을 쓰고 있는지부터 확인해야 하는데, 그 확인이 열 때보다 몇 배 오래 걸리거든요.

회수 자체를 예약해 두는 방법도 있습니다. 권한을 열 때 되돌리는 작업을 같은 날 일정으로 함께 잡아 두면, 닫는 일이 별도의 기억에 기대지 않게 되죠. 여는 사람과 닫는 사람이 다를 때 특히 값이 큽니다.

저는 전사 시스템에서 임시 권한을 열 때 계정이 아니라 그 작업에 걸린 역할을 대상으로 삼습니다. 계정에 얹어 둔 권한은 회수 단계에서 어느 것이 임시로 준 것인지 구분되지 않아, 만료일이 지나고도 그대로 남는 일이 생깁니다.

같은 예외가 반복되면 그것은 예외가 아닙니다. 월말마다 같은 신청이 세 번 올라왔다면 권한 정의가 업무의 실제 주기와 어긋나 있다는 뜻이죠. 이때 할 일은 승인을 자동화하는 쪽이 아니라 권한 목록을 고쳐 그 업무를 정상 범위에 넣는 쪽입니다.

세 칸 중 하나가 비면 어느 쪽이 먼저 못 쓰게 되나요?

권한 칸입니다. 그 칸이 비면 나머지 둘이 함께 못 쓰게 되고, 예외 승인이 비었을 때는 앞의 두 칸이 계속 일하죠.

답이 그렇게 갈리는 까닭은 표의 세 번째 열을 세로로 읽으면 드러납니다. 권한 목록은 정상의 정의이고, 로그는 실제로 일어난 일이고, 예외 기록은 정상을 잠깐 벗어난 구간의 표시입니다. 셋이 같은 대상을 서로 다른 각도에서 적습니다.

한 칸이 비었을 때 남은 칸에서 벌어지는 일은 다음과 같이 갈립니다.

비는 칸	남은 칸에서 벌어지는 일
권한	로그의 행위자가 사람 계정으로 찍혀 에이전트가 한 일을 가려낼 수 없다. 열려 있지 않은 대상이 없으니 예외를 신청할 일도 사라진다
감사 로그	권한은 시스템이 그대로 강제한다. 예외는 만료일만 지나가고, 그 예외가 실제로 쓰였는지 다시 필요한지 판단할 근거가 남지 않는다
예외 승인	앞의 두 칸은 각자 일한다. 대신 급한 일이 생길 때마다 권한 목록이 넓어지는 압력을 받는다

여기서 나오는 판정이 하나 있습니다. 무력화가 권한에서 로그로, 로그에서 예외 승인으로 한 방향으로만 번진다는 것이죠. 반대 방향은 무력화로 나타나지 않고 압력으로 나타납니다.

정밀하게 적으면 이렇습니다. 권한 칸이 비어도 로그가 사라지지는 않습니다. 사라지는 것은 그 로그로 정상과 이상을 가르는 기준이죠. 기록은 계속 쌓이는데 그것을 읽어 무엇이라고 판정할 근거가 없는 상태가 됩니다.

로그 칸이 비었을 때도 예외 승인이 형식으로는 돌아갑니다. 달력 알림으로 만료일을 닫을 수는 있으니까요. 다만 그 예외가 실제로 쓰였는지, 다음 달에 또 필요할지를 확인할 자리가 없어 갱신 판단 없는 만료 반복이 됩니다.

이 방향에 반례가 없는지도 표에서 다시 봅니다. 예외 승인이 비었을 때 권한 목록이 넓어진다면 뒤에서 앞으로 영향이 간 것 아니냐는 반문이 가능하니까요.

같은 종류의 일은 아닙니다. 예외가 없어도 권한 목록은 여전히 값을 갖고 로그도 여전히 판정 근거가 되니까요. 로그 쪽 근거는 신호 셋에서 나옵니다. 예외 기록이 없으면 세 번째 신호가 잡을 대상이 사라질 뿐, 앞의 두 신호는 권한 목록만으로 그대로 판정됩니다. 넓어진 목록은 목록으로서 계속 일하고, 다만 그 폭이 업무가 필요로 하는 것보다 커질 뿐입니다. 앞 칸이 빌 때처럼 뒤 칸의 쓰임 자체가 사라지지는 않죠.

그래서 셋을 동시에 세울 여력이 없으면 순서는 이미 정해져 있습니다. 권한 목록 먼저, 그 위에 로그, 그 위에 예외 승인입니다. 순서를 거꾸로 잡아 예외 결재선부터 만든 회사는 무엇이 예외인지 정의하지 못한 채 결재만 도는 상태에 놓이곤 하죠.

시계가 서로 다르다는 점도 표에서 읽힙니다. 권한은 사건이 오면 열고, 로그는 정해진 주기로 읽고, 예외는 만료일에 닫습니다. 세 통제를 분기 점검 한 자리로 몰면 이 시계 셋이 하나로 눌려, 가장 짧은 시계를 가진 예외의 만료가 먼저 밀립니다.

세 시계를 분리해 두는 방법은 단순합니다. 예외는 승인할 때 만료일을 함께 일정에 넣고, 로그는 업무 마감 일정에 붙여 두고, 권한은 연동 작업 절차의 마지막 단계로 넣습니다.

그러면 정기 점검 자리에서는 세 칸의 상태를 확인만 하면 됩니다. 점검 회의는 통제를 실행하는 자리에서 실행된 것을 모아 보는 자리로 바뀝니다. 회의 시간이 줄어드는 것은 부수 효과이고, 본래 값은 통제가 회의 일정에 매이지 않는다는 쪽에서 나옵니다.

분기 점검을 없애자는 말은 아닙니다. 세 통제가 각자의 시계로 돌고 있을 때, 그 자리는 통제가 밀린 곳을 찾는 데 쓰이면 되죠.

사람의 AI 사용 규칙과 에이전트 통제는 같은 문서에 담기나요?

한 문서에 담아도 되지만 두 절로 나누는 편이 낫습니다. 갱신되는 계기가 서로 다르기 때문이죠.

사용 규칙은 도구가 늘거나 약관이 바뀔 때 손봅니다. 새 챗봇이 들어오거나 기존 도구의 데이터 처리 방침이 바뀐 날이 그 문서를 고치는 날입니다. 통제점은 연동이 늘거나 업무 절차가 바뀔 때 손보고요.

두 층을 한 절에 뭉쳐 두면 갱신할 때마다 관계없는 부분까지 다시 읽게 됩니다. 그리고 실무에서는 사용 규칙 쪽만 자주 고쳐지고 통제점 쪽은 처음 만든 상태로 남는 일이 생기죠.

두 층이 만나는 자리도 있습니다. 직원이 쓰는 도구가 사내 시스템에 연결되는 순간입니다.

업무 자동화 도구에 회사 계정을 연결해 메일함이나 일정표를 읽게 하는 구성이 그 예입니다. 도구를 고른 것은 사람의 선택이니 사용 규칙의 대상이지만, 연결된 뒤에 벌어지는 조회는 에이전트의 실행이라 통제점 쪽으로 넘어오죠. 이런 도구가 늘고 있어 두 절 사이에 “연결 시점에 권한 목록에 등재한다”는 한 줄을 넣어 두면 경계가 흐려지지 않습니다.

읽을 사람도 갈립니다. 사용 규칙은 전 직원이 첫날 읽을 문서이고, 통제점 표는 승인 권한을 가진 몇 사람이 계속 들여다볼 문서입니다. 도입 결정 단계에서 계약서로 확인할 항목들은 기능과 가격 다음에 점검하는 운영·출구 조항 목록에 별도로 정리했습니다.

이미 에이전트를 돌리고 있다면 어디부터 손대나요?

에이전트가 어느 계정으로 붙어 있는지부터 봅니다. 그 한 가지가 뒤에 오는 네 단계의 난이도를 전부 바꾸거든요.

지금 도는 에이전트가 어느 계정으로 붙어 있는지 확인합니다. 전용 계정인지 담당자 계정인지가 첫 갈림입니다.
계정마다 닿는 시스템과 대상을 적고 읽기와 쓰기를 나눕니다.
그 목록을 기준으로 로그에서 찾을 신호를 세 가지만 뽑습니다.
예외의 기본 만료 기간과 결재선을 정합니다.
첫 로그 읽는 날을 달력에 잡고, 그날 판정을 한 줄 남깁니다.

1번에서 담당자 계정이 확인되면 순서를 하나 앞에 붙입니다. 전용 계정을 발급해 옮기는 일이 먼저입니다. 이 한 단계로 로그의 행위자 칸이 살아나 뒤의 두 통제점이 설 자리가 생기고요.

각 단계에 드는 시간은 대체로 갈립니다. 1번은 시스템 담당에게 물으면 그날 안에 나옵니다. 3번과 4번은 밖에서 올 회신이 없어 앉아서 정하면 그 자리에서 끝납니다. 2번만 부서 회신을 기다리는 단계라 며칠이 걸립니다.

2번의 답이 며칠씩 미뤄지는 것은 그 자체로 정보입니다. 지연이 길수록 1번에서 담당자 계정이 나왔을 가능성이 높죠.

그래서 2번의 답을 기다리는 동안 3번과 4번을 먼저 정해 두는 편이 낫습니다. 신호와 결재선은 권한 목록이 확정되기 전에도 형식을 잡을 수 있고, 목록이 나오면 그 형식에 값만 넣으면 되니까요.

완성도는 첫 판에 맞추지 않아도 됩니다. 아홉 칸 가운데 권한 행 세 칸만 채워도 남은 여섯 칸이 무엇을 물어야 하는지가 드러나니까요.

외부에서 오는 요구는 이 세 칸과 어디서 만나나요?

표준과 법이 요구하는 것은 대개 세 번째 열, 즉 남는 기록 쪽에서 만납니다. 정책 문장은 회사 안에서만 확인되지만 기록은 밖에서도 확인되기 때문이죠.

AI 관리 체계를 심사하는 인증기관이 무엇을 갖춰야 하는지를 정한 문서가 2025년에 나왔습니다. 번호는 ISO/IEC 42006으로 붙었고, 그 심사가 대상으로 삼는 표준은 2023년 발행된 ISO/IEC 42001입니다. 인증을 당장 받을 계획이 없더라도 이 순서가 알려 주는 것은 하나입니다. AI를 어떻게 관리하는지를 외부가 확인하는 절차가 만들어지고 있습니다.

외부가 확인할 수 있는 형태는 규정집이 아니라 통제가 돌아간 기록입니다. 인증서를 받았다는 사실이 특정한 성과를 보장해 주지도 않고요. 심사든 실사든 결국 승인 기록과 판정 이력이 있는지를 묻는 자리로 수렴합니다.

법 쪽에서는 인공지능 기본법이 2026년 1월 시행에 들어갔습니다. 다만 우리 회사가 하는 일 가운데 어디까지가 그 법이 말하는 대상인지는 무엇을 어떤 형태로 제공하느냐에 따라 달라지고, 하위 법령과 세부 기준이 이어지는 영역도 남아 있습니다. 개별 사안은 법무 검토를 함께 받으시는 편이 안전합니다.

적용 여부와 무관하게 자리를 잡아 두면 좋은 것이 있습니다. 확인 요구가 왔을 때 답이 되는 것은 세 번째 열입니다. 조문이 늘어난다고 통제점이 늘어나지는 않고, 세 칸에 확인할 열이 하나 붙는 방식으로 자랍니다.

거래처에서 오는 요구도 형태는 같습니다. 대기업이나 공공기관에 납품하는 회사라면 상대의 보안 심사 문항에 AI 관련 항목이 붙는 것을 보게 되고, 그 문항들도 대개 담당자 이름과 기록 제출을 묻습니다.

문항이 올 때마다 새 문서를 만드는 방식은 오래가지 않습니다. 세 칸을 유지하고 있으면 상대의 양식에 맞춰 옮겨 적는 일만 남고, 그 일은 문서를 새로 쓰는 것과 드는 품이 다르거든요. 답변마다 근거가 달라지지 않는다는 점도 이 방식의 이점입니다.

통제점이 살아 있는지 무엇으로 확인하나요?

세 가지를 물어보면 됩니다. 지난달 로그를 누가 읽었고 무엇을 판정했는가, 지금 열려 있는 예외가 몇 건이고 각각의 만료일이 언제인가, 마지막으로 권한 목록을 고친 것이 언제이고 그 계기가 무엇이었는가.

셋 다 이름과 날짜로 답이 나오면 통제가 돌고 있는 것입니다. 답이 “정하기는 했는데 최근에는 확인을 못 했다” 쪽으로 나오면, 규칙만 있고 통제는 서지 않은 것입니다.

이 질문들은 감사관이나 원청 담당자가 실제로 던지는 형태와 거의 같습니다. 미리 물어 보는 쪽이 심사 자리에서 처음 듣는 것보다 낫고요.

답이 막히는 자리가 곧 다음에 손댈 칸입니다.

로그를 읽은 사람이 나오지 않으면 주기가 너무 길게 잡혀 있지 않은지 보십시오. 예외 건수를 세지 못하면 승인 기록이 결재 시스템과 메신저로 흩어져 있다는 뜻이고요. 권한 목록을 고친 시점이 기억나지 않는다면, 그 사이에 늘어난 연동이 목록에 반영되지 않았을 가능성을 먼저 확인해 보시길 권합니다.

위 세 질문 가운데 답이 멈추는 것이 하나라도 있다면 그 자리가 출발점입니다. 어느 질문에서 멈췄는지, 그리고 지금 도는 에이전트의 계정 현황을 거버넌스 상담으로 알려 주십시오. 그 두 가지면 어느 칸부터 세울지 순서를 잡습니다.

자주 묻는 질문

에이전트가 하나뿐인데도 전용 계정을 따로 만들어야 하나요?

하나일 때 만들어 두는 편이 훨씬 쉽습니다. 담당자 계정으로 붙여 놓고 나중에 분리하려면 그 계정으로 처리된 이력을 사람 몫과 에이전트 몫으로 갈라야 하는데, 이미 섞인 기록은 되돌려 나누기 어렵거든요. 계정 발급 자체는 대개 반나절 작업이라 초기 비용이 가장 싼 통제입니다.

로그를 읽을 사람이 없는데 자동 경보로 대신할 수 있나요?

경보는 찾는 일을 대신하지 판정을 대신하지 못합니다. 조건에 걸린 줄을 띄워 주는 데까지가 자동화의 몫이고, 그것이 정상 업무였는지 확인이 필요한 건이었는지는 업무를 아는 사람이 봐야 갈립니다. 다만 경보를 걸어 두면 읽는 시간이 크게 줄어, 사람이 한 명뿐인 조직일수록 먼저 붙일 만합니다.

예외 신청이 잦아 결재가 밀리면 어떻게 하나요?

빈도를 신호로 읽으시길 권합니다. 같은 성격의 신청이 반복된다면 승인을 간소화하기보다 권한 목록을 고쳐 그 업무를 정상 범위에 넣는 편이 맞고, 신청 성격이 매번 다르다면 결재선이 너무 위에 걸려 있는지 확인해 보세요. 결재선을 낮추더라도 기술적으로 여는 사람과 판단하는 사람은 갈라 두시고요.

외부 서비스형 에이전트를 쓰면 로그를 우리가 볼 수 없는데 어떻게 하나요?

우리 시스템 쪽에 남는 기록으로 대신합니다. 에이전트가 우리 데이터베이스나 업무 시스템을 호출하는 지점의 접근 기록은 공급사 로그와 무관하게 우리 쪽에 남으니까요. 계약 단계라면 제공되는 로그의 항목과 조회 방법, 보관 기간을 문서로 받아 두시면 확인 경로가 둘로 늘어납니다.

통제점을 세우면 에이전트 도입 속도가 느려지지 않나요?

첫 연동에서는 며칠이 더 듭니다. 두 번째부터는 오히려 빨라지는데, 권한 범위를 정하는 논의가 첫 연동에서 한 번 끝나 있어 다음 에이전트는 같은 틀에 값만 채우면 되기 때문입니다. 느려지는 구간은 초기에 몰리고, 되돌리는 작업이 줄어드는 효과는 그 뒤로 계속 남습니다.

기존 계정 관리 체계가 있으면 권한 칸은 이미 채워진 것 아닌가요?

절반은 채워진 상태입니다. 계정 발급과 회수 절차가 이미 돌고 있다면 그 위에 에이전트 계정을 얹기만 하면 되니까요. 다만 사람 계정 체계는 입·퇴사를 계기로 움직이는데 에이전트 계정은 연동 추가를 계기로 움직여, 되돌아보는 시점을 별도로 잡아 두지 않으면 그 칸이 비어 있게 됩니다.

참고 자료

ISO/IEC 42001:2023(인공지능 경영시스템 표준) — 조직이 AI를 관리하는 체계를 대상으로 삼는 국제표준. 확인 2026-08-27: https://www.iso.org/standard/42001
「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」 — 2026년 1월 22일 시행. 적용 범위와 세부 기준은 하위 법령이 이어지는 영역이 남아 있습니다. 확인 2026-08-27: https://www.law.go.kr/법령/인공지능발전과신뢰기반조성등에관한기본법
ISO/IEC 42006:2025 — 위 표준의 심사를 맡는 인증기관 쪽 요구사항을 담아 2025년 발행. 확인 2026-08-27: https://www.iso.org/standard/44546.html
하마다랩스 이득기 CTO의 연동 착수·운영 단계 관찰(2026년) — 자사 1차 자료입니다. 건수를 집계하지 않은 익명 관찰이며 범위는 넷입니다. 권한 범위 질문에 부서가 답하는 데 걸리는 시간이 업무별 데이터 책임 구분 상태와 함께 움직인다는 것, 구축을 서두른 연동에서 담당자 계정이 그대로 쓰이는 경로, 온프레미스 구성에서 로그의 행위자 칸에 남는 이름이 설정 화면과 어긋나는 경우, 전사 시스템의 임시 권한을 계정이 아니라 역할 단위로 열어 온 방식입니다. 개별 고객사를 가리키지 않습니다.

작성자

하마다랩스 CTO 이득기입니다. 회사를 공동 창업했고, 발명의 날 대통령 표창 수상자이며 9년 차 AI 개발자입니다. 쓰던 ERP·CRM을 그대로 둔 채 AI 에이전트를 붙이는 연동 설계와 SAP·더존을 비롯한 전사 시스템 통합을 맡고 있고, 사내 밖으로 데이터가 나가지 않는 온프레미스 구조를 설계합니다. 회사 소개: https://www.hamadalabs.com/