오늘의 세 가지 포인트

1. 에이전트 보안의 단위는 대화 화면이 아니라 도구 호출, 비밀값, 권한 경계다.
2. RPA와 에이전트를 함께 돌릴 때는 판단·실행·감사 경로를 분리해 연결해야 한다.
3. MCP 도입의 최소선은 서버 신뢰, 범위 제한, 로그, 반복 가능한 시험이다.

1. 에이전트 보안 점검표: 배포 전에 실행 범위를 그린다

국내 기업 환경에서 에이전트를 배포할 때 첫 질문은 모델이 얼마나 유능한가가 아니다. 에이전트가 연결할 수 있는 도구가 무엇인지, 각 도구가 읽고 쓰고 전송할 수 있는 데이터가 무엇인지부터 확인해야 한다. 도구 호출은 대화의 다음 문장이 아니라 실제 시스템 상태를 바꿀 수 있는 실행 요청이다. 파일 저장소 검색, 고객 정보 조회, 결재 문서 작성, 티켓 갱신, 외부 전송처럼 서로 성격이 다른 작업을 하나의 넓은 권한으로 묶으면 검토의 단위가 사라진다. 운영자는 도구 이름, 목적, 입력 형식, 출력 형식, 필요 권한, 호출 주체, 실패 시 행동을 목록으로 고정할 필요가 있다.

이 목록은 보안팀만을 위한 문서가 아니다. 업무 부서는 어떤 요청이 자동 처리되는지 알고, 개발 부서는 어떤 비밀값이 사용되는지 알고, 운영 부서는 누가 중단할 수 있는지 알아야 한다. 특히 비밀값은 프롬프트나 작업 설명에 섞여 들어가는 정보가 아니라 별도 관리 대상이다. 호출마다 장기 자격증명을 넘기는 관행, 하나의 공유 계정으로 여러 자동화를 실행하는 관행, 테스트용 권한을 운영에 남기는 관행은 모두 추적의 출발점을 흐린다. 배포 전에는 에이전트가 직접 보지 않아도 되는 정보가 무엇인지 먼저 빼고, 업무별로 더 좁은 권한을 부여하고, 만료·교체·폐기 절차를 정해 둔다.

OWASP의 2025년 안내 자료는 LLM 애플리케이션에 특유한 보안 문제를 다룬다. 이 글은 이를 참고해 도구별 접근 범위와 비밀값 취급을 배포 전 점검 항목으로 제안한다.

원문 · OWASPOWASP Top 10 for LLM Applications 2025LLM 애플리케이션의 보안 문제를 다루는 안내 자료다.

NIST의 AI 위험 관리 프레임워크는 AI 위험을 관리하기 위한 참고 틀이다. 아래의 기록·중단·복구 항목은 이를 운영에 적용하기 위한 점검 제안이며, 해당 문서가 일률적으로 요구하는 체크리스트는 아니다.

원문 · NISTAI Risk Management FrameworkAI 위험 관리 체계를 소개하는 자료다.

감사 가능성은 사고가 난 뒤 로그를 모으는 일보다 앞선 설계 문제다. 최소한 요청 식별자, 실행 시각, 호출한 워크플로, 선택된 도구, 권한 확인 결과, 주요 입력의 안전한 참조, 결과 상태, 사람 승인 여부가 같은 흐름으로 연결되어야 한다. 민감한 원문과 비밀값을 로그에 그대로 남기라는 뜻은 아니다. 무엇을 남기지 않을지까지 정하고, 필요하면 식별자·마스킹·접근 통제로 재현 가능한 흔적을 만든다는 뜻이다. 운영 화면에는 성공률만 두지 말고 거부된 호출, 권한 오류, 재시도, 비정상적인 대량 실행도 보이게 한다. 평온한 날의 기록과 확인 체계가 사고 날의 조사 시간을 줄인다.

사고 대응은 에이전트만 끄는 버튼으로 끝나지 않는다. 특정 도구를 중단할 수 있는지, 특정 자격증명을 즉시 폐기할 수 있는지, 이미 시작한 작업을 취소하거나 격리할 수 있는지, 영향을 받은 결과를 되돌릴 수 있는지를 역할별로 연습해야 한다. 대응 절차에는 탐지 신호, 최초 판단자, 업무 소유자 연락 경로, 권한 회수 순서, 증거 보존 위치, 복구 승인 조건을 넣는다. 이 절차를 실제와 다른 문서로 두면 긴급 상황에서 실행 권한을 찾느라 시간이 흐른다. 작은 범위의 모의 호출로 차단과 복구가 작동하는지 확인하고, 변경 뒤에도 같은 시험을 반복하는 편이 낫다.

점검표는 출시 승인 한 번을 위한 체크 상자가 아니라 변경 관리의 기준선이다. 새 도구를 붙이거나 프롬프트에 새 업무 지시를 넣거나, 데이터 원천을 바꾸거나, 담당 조직을 바꾸는 순간에도 같은 질문을 다시 적용한다. 이번 변경으로 새로 읽는 정보는 무엇인가, 새로 실행할 수 있는 행동은 무엇인가, 기존 승인자는 여전히 적절한가, 로그만으로 변경 전후를 구분할 수 있는가를 확인한다. 답을 남기면 배포 속도를 늦추기보다 어떤 변경이 가벼운지 어떤 변경이 추가 검토를 부르는지 구별할 수 있다. 보안 검토를 마지막 관문으로만 두지 않고 설계와 운영 변경에 붙이는 방식이다.

2. 업무 자동화의 연결과 조정: 판단, 실행, 감사를 한 줄로 잇는다

RPA와 에이전트는 경쟁하는 두 선택지가 아니다. 반복적이고 규칙이 분명한 화면 입력, 정형 데이터 이동, 정해진 순서의 처리에는 RPA가 잘 맞을 수 있다. 반면 문서를 읽어 분류 후보를 만들거나, 여러 정보를 비교해 다음 작업을 제안하거나, 예외를 설명하는 일에는 에이전트 방식이 쓰일 수 있다. 문제는 둘을 연결할 때 에이전트의 제안이 곧바로 광범위한 실행으로 넘어가는 구조다. 업무 흐름은 판단 단계, 실행 단계, 확인 단계로 나누고, 각 단계의 입력·출력·책임자를 명시해야 한다. 에이전트가 판단한 내용은 근거와 함께 전달하고, 실행기는 허용된 명령만 받아야 하며, 확인자는 결과와 원래 요청을 비교할 수 있어야 한다.

업무 흐름 조정의 핵심은 많은 에이전트를 배치하는 데 있지 않다. 어떤 조건에서 다음 단계로 넘어가는지, 언제 사람에게 넘기는지, 실패한 작업을 재시도할지 중단할지 같은 단계 전환 규칙을 드러내는 데 있다. 예를 들어 문서 분류의 확신이 낮거나 필요한 정보가 없으면 자동 실행 대신 검토 대기열로 보낸다. 금액, 외부 발송, 고객 데이터 변경처럼 되돌리기 어려운 작업은 별도 승인 지점을 둔다. 이렇게 하면 속도가 줄어드는 것처럼 보일 수 있으나, 예외가 조용히 누적되어 나중에 전부 다시 처리하는 비용을 줄일 수 있다. 자동화의 목표는 모든 단계를 무인화하는 일이 아니라 반복 가능한 경로에만 자동 실행을 허용하는 일이다.

Anthropic의 글은 미리 정한 경로를 따르는 워크플로와 모델이 작업 진행 및 도구 사용을 결정하는 에이전트를 구분한다. 이 구분을 바탕으로 여기서는 판단과 실행의 책임을 나눠 연결하는 방식을 제안한다.

원문 · Anthropic EngineeringBuilding Effective AI Agents워크플로와 에이전트의 구성 방식을 설명한다.

NIST의 AI 위험 관리 프레임워크는 자동화의 위험을 함께 검토할 때 참고할 수 있다. 여기서 제시하는 승인 지점과 운영 지표는 업무에 맞춰 정할 점검 항목이며, 특정 비용 절감이나 성과 수치를 보장하지 않는다.

원문 · NISTAI Risk Management FrameworkAI 위험 관리 체계를 소개하는 자료다.

운영자가 만들 수 있는 가장 실용적인 산출물은 흐름도 한 장과 실행 계약 한 장이다. 흐름도에는 시작 이벤트, 데이터 원천, 판단 단계, 자동 실행 단계, 사람 검토 단계, 종료 상태를 넣는다. 실행 계약에는 작업의 목적, 입력 검증 규칙, 허용된 도구, 최대 실행 횟수, 시간 제한, 승인 필요 조건, 실패 처리, 기록 항목을 넣는다. 두 문서가 있으면 현업은 자동화가 어디까지 처리하는지 설명할 수 있고, 기술팀은 변경이 어느 경계를 건드리는지 판단할 수 있다. 문서가 없을 때는 작은 수정도 숨은 의존성을 건드릴 수 있고, 책임의 공백도 발견하기 어렵다.

측정도 결과 숫자 하나로 끝내지 않는다. 완료된 작업 수와 함께 사람에게 이관된 비율, 재시도 횟수, 취소된 실행, 승인 대기 시간, 되돌림 발생, 입력 품질 문제를 본다. 이 수치는 특정 목표치를 약속하는 근거가 아니라 흐름이 어디에서 막히는지 찾기 위한 신호다. 주 단위 운영 검토에서는 실패 사례 몇 개를 실제 흐름에 다시 놓고, 판단이 틀렸는지 실행이 과했는지 승인 규칙이 모호했는지 나눠 본다. 그 결과는 프롬프트 수정만이 아니라 권한 축소, 입력 양식 변경, RPA 단계 분리, 검토 대기열 조정으로 이어질 수 있다. 좋은 업무 흐름 조정은 단일 모델의 판단을 숭배하지 않고 수정 가능한 업무 경로를 유지한다.

예외 처리는 실패의 뒷정리가 아니라 흐름의 정상 상태로 설계할 필요가 있다. 입력이 비어 있거나 서로 모순될 때, 외부 시스템의 응답이 늦을 때, 사람이 승인하지 않을 때, 같은 요청이 다시 들어올 때의 길을 미리 정한다. 각 경우에 자동화가 멈출지, 보류할지, 제한된 재시도를 할지, 담당자에게 어떤 정보와 함께 넘길지 기록한다. 사람 검토 화면에는 에이전트의 결론만 보이지 않게 하고 원래 요청, 사용한 입력, 제안된 행동, 실행 전후 차이를 함께 보여 준다. 그래야 검토자가 추측으로 승인하지 않고 업무 맥락 안에서 수정하거나 반려할 수 있다. 업무 흐름 조정은 빠른 흐름뿐 아니라 안전하게 느려지는 흐름도 품어야 한다.

3. MCP 보안과 권한 관리: 연결의 편의보다 신뢰 경계를 먼저 둔다

MCP를 기업 환경에 연결할 때도 출발점은 편리한 연결이 아니라 신뢰할 서버를 구분하는 일이다. 서버 이름이 익숙하다는 이유만으로 연결을 허용하거나, 개발용 주소를 운영 흐름에 그대로 넣으면 연결 주체와 데이터 경로를 설명하기 어려워진다. 운영 목록에는 서버의 소유자, 서비스 목적, 연결 주소, 배포 환경, 사용할 도구와 데이터 범위, 변경 책임자를 기록한다. 새 서버를 추가하는 요청은 업무 목적과 필요한 최소 기능을 함께 검토하고, 더 넓은 접근이 필요한 이유를 분명히 남긴다. 연결은 한 번 설정하고 잊는 항목이 아니라 변경과 검토가 계속 필요한 외부 연결의 경계다.

권한은 사용자가 로그인했다는 사실만으로 충분하지 않다. 어떤 클라이언트가 어떤 서버에 접근하는지, 어떤 작업 범위를 요청하는지, 그 권한이 언제까지 유효한지 분리해 생각해야 한다. 범위는 가능한 한 업무 동사와 데이터 영역에 맞춰 좁힌다. 읽기와 쓰기, 내부 검색과 외부 전송, 초안 생성과 최종 게시를 같은 권한으로 합치지 않는 편이 좋다. 권한 요청 화면이나 운영 절차에는 요청 주체, 대상 서버, 요청 범위, 만료, 철회 방법이 이해 가능한 형태로 보여야 한다. 사용자는 자신이 승인한 연결을 확인하고 필요 없어진 연결을 제거할 수 있어야 하며, 운영자는 그 변경의 흔적을 확인할 수 있어야 한다.

인용한 MCP 문서는 2025년 6월 18일 버전이며 HTTP 기반 연결의 인가 흐름을 정의한다. 모든 MCP 연결에 같은 절차를 요구하는 문서는 아니며, 표준 입출력 방식의 연결에는 별도의 자격증명 취급 지침을 둔다. 아래 운영 점검은 각 연결 방식에 맞춰 적용할 제안이다.

원문 · Model Context ProtocolAuthorization - Model Context Protocol2025년 6월 18일 버전의 HTTP 연결 인가 사양이다.

OWASP의 자료는 LLM 애플리케이션 보안을 검토할 때 함께 볼 수 있는 참고 자료다. MCP 연결만을 위한 인증서나 도입 승인 기준은 아니므로, 서버별 신뢰와 업무별 권한은 조직이 따로 확인해야 한다.

원문 · OWASPOWASP Top 10 for LLM Applications 2025LLM 애플리케이션의 보안 문제를 다루는 안내 자료다.

로그는 MCP 연결이 실제로 어떻게 쓰였는지 판단하는 운영 기반이다. 연결 성공 여부만 남기지 말고 요청한 클라이언트, 선택한 서버, 적용된 범위, 호출한 도구, 실행 결과, 거부 이유, 권한 변경을 시간 순서로 엮는다. 민감한 값은 노출하지 않는 방식으로 보관하고, 로그 접근 권한도 별도로 제한한다. 정기 검토에서는 오래 사용되지 않은 연결, 예상과 다른 범위 요청, 반복된 거부, 비정상 시간대의 호출을 확인한다. 이 관찰은 누군가를 감시하기 위한 장치가 아니라 최소 권한이 시간이 지나며 넓어지는지를 찾아내는 장치다. 사용하지 않는 연결을 닫는 일은 새 기능을 여는 일만큼 중요한 운영 작업이다.

마지막 최소 통제는 시험이다. 새 서버, 새 도구, 새 범위, 새 클라이언트 조합마다 정상 흐름만 확인하지 말고 거부되어야 할 흐름도 확인한다. 만료된 권한으로 호출했을 때, 다른 범위의 작업을 요청했을 때, 승인되지 않은 서버를 선택했을 때, 네트워크나 도구가 실패했을 때 어떤 기록과 중단이 남는지 본다. 시험 결과는 담당자 개인의 기억이 아니라 재실행 가능한 사례로 보관한다. 운영 전환 뒤에도 변경이 생기면 같은 사례를 다시 돌린다. 신뢰는 연결을 허용한 순간에 완성되는 성질이 아니라 제한·관찰·시험을 반복하며 유지하는 운영 결과다.

권한 관리의 운영 주기는 발급에서 끝나지 않는다. 인사 이동, 프로젝트 종료, 서버 이전, 공급자 변경, 업무 범위 축소가 생기면 연결과 범위도 다시 살핀다. 이를 위해 연결 목록의 소유자에게 정기 확인을 요청하고, 확인되지 않은 연결은 추가 검토 대상으로 둔다. 긴급한 업무 요구가 있을 때도 임시 범위의 만료 시각과 후속 검토자를 함께 정하면 예외가 영구 권한으로 굳는 일을 줄일 수 있다. 클라이언트와 서버의 변화 기록, 승인 기록, 시험 기록을 서로 참조할 수 있게 두면 담당자가 바뀌어도 왜 그 연결이 존재하는지 설명할 수 있다. 최소 통제는 복잡한 장벽이 아니라 연결을 계속 이해하기 위한 공통 언어다.

운영자 메모

오늘 바로 시작할 일은 거대한 정책을 쓰는 일이 아니다. 현재 운영 중인 에이전트, RPA 흐름, MCP 연결을 한 표에 놓고 소유자와 실행 권한을 적는 일이다. 그 표에서 소유자가 없거나, 권한 범위를 설명할 수 없거나, 중단 방법을 모르는 항목을 표시한다. 다음으로 가장 영향이 큰 흐름 하나를 골라 판단·실행·감사·복구의 네 칸을 채운다. 빈칸이 발견되면 기능 확대보다 그 빈칸을 메우는 순서를 앞세운다. 이 작은 점검은 보안을 별도 심사로 밀어내지 않고 일상 운영의 언어로 바꾸는 출발점이 된다.

점검 회의에는 보안, 개발, 현업, 운영의 대표가 각자 한 명씩 참여하는 편이 좋다. 보안 담당자는 권한과 기록의 빈틈을, 개발 담당자는 구현과 변경의 영향을, 현업 담당자는 실제 업무의 예외와 되돌림 비용을, 운영 담당자는 감시와 중단의 현실성을 본다. 한 직군만으로 만든 흐름은 다른 사람이 쓰는 순간 예상 밖의 우회로를 만들 수 있다. 회의의 결과는 장황한 결재 문서보다 다음 행동이 분명한 목록이어야 한다. 없앨 권한, 추가할 승인, 확인할 로그, 시험할 실패 경로, 다음 검토 날짜를 적고 소유자를 지정한다. 이 목록이 쌓이면 조직은 특정 도구의 유행과 무관하게 반복 가능한 운영 습관을 갖게 된다.

우선순위는 기술의 새로움보다 영향과 되돌릴 수 없음으로 정한다. 단순 조회처럼 결과가 내부에 머무는 흐름은 작은 범위에서 시험할 수 있다. 반대로 외부 전송, 대량 수정, 고객과의 약속, 재무나 인사 관련 처리는 더 좁은 권한과 사람 확인을 먼저 둔다. 이 구분은 어떤 업무가 중요하지 않다는 뜻이 아니라 오류의 비용과 복구의 가능성을 함께 본다는 뜻이다. 작은 실험에서 기록과 승인 경로를 익힌 뒤 범위를 넓히면, 통제를 나중에 덧붙이는 방식보다 운영 부담을 낮출 수 있다. 빠르게 시작하되 되돌릴 수 있는 경로에서 시작하는 원칙이다.