MCP와 A2A 에이전트에게 회사 권한을 줘도 될까 2026 – 감사 로그 체크표

Posted on by

MCP와 A2A 에이전트에게 회사 권한을 줄 수는 있다. 다만 2026년에 이 질문의 답은 “연결되나요?”가 아니라 “무엇을 읽고, 무엇을 실행하고, 누가 승인하고, 어디에 로그가 남나요?”로 바뀌어야 한다. 연결이 쉬워질수록 권한 설계는 더 보수적이어야 한다.

내가 Codex와 Obsidian 볼트에서 에이전트 파이프라인을 굴릴 때도 같은 문제가 반복된다. 파일을 읽는 작업, 초안을 수정하는 작업, 외부 블로그에 발행하는 작업은 전부 위험도가 다르다. 한 번에 쓰기 권한을 모두 열어두면 편하지만, 실패했을 때 원인을 추적하기가 어려워진다.

그래서 이번 업데이트의 핵심은 MCP와 A2A를 멋진 연결 기술로만 보는 것이 아니다. 회사 업무에 붙이기 전에 권한, 승인, 감사 로그, 비용, 데이터 경계를 먼저 고정하는 것이다. 자동화가 빨라질수록 운영표는 더 느리고 꼼꼼해야 한다. 귀찮아 보여도 이게 나중에 야근을 줄여주는 쪽이다.

지금 결론

MCP는 AI 애플리케이션이 외부 도구와 데이터를 일관된 방식으로 쓰게 해주는 표준에 가깝다. 공식 MCP 문서는 MCP를 클라이언트와 서버 생태계가 함께 쓰는 open protocol로 설명하고, 서버가 데이터와 도구를 노출하는 구조를 제시한다. 이 구조 덕분에 에이전트는 문서, API, 개발 도구, 업무 시스템에 더 쉽게 닿을 수 있다.

A2A는 에이전트끼리 협업하고 위임하는 쪽에 가깝다. Google Developers Blog는 Agent2Agent Protocol이 agent interoperability와 agent collaboration을 목표로 한다고 설명한다. MCP가 “에이전트가 어떤 도구를 쓰나”에 가깝다면, A2A는 “에이전트가 다른 에이전트에게 무엇을 넘기나”에 가깝다.

두 흐름이 합쳐지면 자동화의 능력은 커진다. 동시에 권한 면적도 커진다. 에이전트 A가 내부 문서를 읽고, 에이전트 B가 CRM을 수정하고, 에이전트 C가 고객에게 메일을 보내는 구조가 되면 “누가 했는가”를 사람 이름 하나로 설명하기 어려워진다.

그래서 첫 파일럿은 읽기 전용부터 시작하는 편이 좋다. 검색, 요약, 분류, 초안 생성처럼 되돌릴 수 있는 작업을 먼저 붙이고, 외부 발송이나 데이터 변경은 승인 뒤에 열어야 한다. 회사 업무 자동화에서 빠른 연결보다 중요한 것은 멈출 수 있는 연결이다.

권한 3단계로 나누기

첫 단계는 read-only다. 내부 위키 검색, 문서 요약, 코드베이스 질의, 이슈 조회처럼 읽기만 하는 작업을 허용한다. 이 단계에서도 민감정보가 나갈 수 있으므로 서버와 로그 위치는 확인해야 하지만, 최소한 잘못된 쓰기 작업으로 업무 데이터를 바꾸지는 않는다.

두 번째 단계는 draft다. 메일 초안, 이슈 초안, 문서 초안, 리포트 초안을 만들되 최종 저장이나 발송은 사람이 한다. 이 단계는 생산성 체감이 크고 위험도는 비교적 낮다. 대신 초안 내용에 고객 정보, 가격 정보, 내부 전략이 섞이는지 확인하는 검수 루프가 필요하다.

세 번째 단계는 action이다. CRM 업데이트, 티켓 상태 변경, 배포 트리거, 외부 메일 발송, 결제, 삭제 같은 작업이 여기에 들어간다. 이 단계는 자동화 효과가 크지만 사고 비용도 커진다. 처음부터 action 권한을 열면 데모는 멋있고 운영은 무서워진다.

단계 허용 작업 승인 기준 로그 필드
L1 read-only 검색, 조회, 요약 자동 가능 run_id, user_id, tool_name, data_scope
L2 draft 초안 생성, 내부 제안 사후 검토 run_id, draft_id, source_refs, reviewer
L3 action 수정, 발송, 삭제, 배포 사전 승인 run_id, tool_args, approved_by, result_status

이렇게 나누면 MCP 서버를 고를 때도 판단이 쉬워진다. 서버가 제공하는 도구가 L1인지 L2인지 L3인지 표시하고, L3 도구는 기본 비활성화로 둔다. “나중에 필요하면 열자”는 운영 문장으로 꽤 훌륭하다. 과감한 척하면서 사고 치는 것보다 훨씬 프로답다.

allowed tools와 승인 흐름

Microsoft Learn의 Foundry MCP 문서는 remote MCP server를 agent tool로 연결할 수 있다고 설명하면서, best practices로 allowed_tools allow list, high-risk operation approval, tool name과 argument 검토, approval과 tool call logging을 제시한다. 이 네 가지는 회사 파일럿에서 거의 기본값으로 봐야 한다.

OpenAI의 MCP and Connectors 문서도 같은 방향을 말한다. 원격 MCP 서버와 connector는 외부 서비스에 접근하고 데이터를 보내거나 받을 수 있으므로, prompt injection과 민감 작업 approval을 신중히 봐야 한다. 특히 require_approval과 allowed_tools 같은 설정으로 민감한 액션에는 승인 흐름을 걸어야 한다.

실무적으로는 모든 MCP 도구를 자동 노출하지 않는 것이 출발점이다. 서버가 30개 도구를 제공해도 실제 파일럿에는 3개만 열 수 있다. 처음에는 search, fetch, summarize 같은 읽기 도구만 열고, create, update, delete, send, deploy는 숨기거나 승인 필수로 둔다.

승인 화면에는 도구 이름만 보여주면 부족하다. 어떤 인자가 들어가는지, 어떤 레코드나 파일을 건드리는지, 외부로 어떤 데이터가 나가는지 보여줘야 한다. “승인하시겠습니까?” 한 줄짜리 버튼은 사용자에게 판단을 맡기는 척하지만, 실제로는 판단 재료를 숨기는 버튼이 될 수 있다.

감사 로그는 성공할 때부터 남겨야 한다

에이전트 운영에서 로그는 실패했을 때만 필요한 것이 아니다. 성공한 작업도 왜 성공했는지, 어떤 도구를 썼는지, 어떤 승인으로 실행됐는지 남겨야 한다. 그래야 결과가 이상할 때 “모델이 그랬어요”라는 말 대신 재현 가능한 설명을 할 수 있다.

내가 블로그 파이프라인에서 쓰는 no-focus 운영도 같은 이유다. 먼저 파일을 직접 수정하고, preflight를 돌리고, dry-run으로 발행 요청을 확인한 뒤, update-url로 기존 글을 갱신한다. 이 순서가 조금 느려 보여도 어떤 단계에서 문제가 생겼는지 나눠 볼 수 있다.

감사 로그의 기본 필드는 단순하게 시작해도 된다. run_id, user_id, agent_id, tool_name, permission_level, approved_by, input_ref, output_ref, result_status, cost_estimate, created_at 정도면 첫 파일럿에는 충분하다. 원문 전체를 무조건 저장하기보다, 재현과 감사에 필요한 최소 필드를 먼저 정해야 한다.

민감정보 마스킹도 처음부터 같이 들어가야 한다. 고객 이메일, 전화번호, API 키, 토큰, 계좌번호, 내부 URL이 로그에 그대로 남으면 로그가 또 다른 유출 지점이 된다. 로그는 방패가 되어야지, 새로운 약점이 되면 곤란하다.

비용과 지연 시간도 권한 문제다

MCP 서버를 많이 붙이면 모델이 사용할 수 있는 도구가 늘어난다. 이 자체는 좋지만, 도구 정의와 호출 결과가 컨텍스트에 들어가면서 토큰 비용과 지연 시간이 늘 수 있다. 업무 자동화에서는 한 번의 호출 비용보다 “성공해서 많이 쓰일 때”의 비용이 더 중요하다.

예를 들어 영업팀 리포트 요약 에이전트가 하루 한 번 쓰일 때는 비용이 작아 보인다. 하지만 50명이 하루 20번씩 쓰고, 매번 긴 문서와 도구 결과를 읽으면 숫자가 달라진다. 자동화는 잘되면 사용량이 늘기 때문에, 성공 뒤 비용이 커지는 구조를 미리 계산해야 한다.

지연 시간도 운영 품질에 영향을 준다. Microsoft Learn 문서는 긴 MCP 작업의 경우 background mode와 polling 구조를 설명하고, 일반 non-streaming MCP tool call timeout도 언급한다. 긴 작업을 동기 호출 하나로 붙이면 사용자 화면은 멈추고, 사용자는 다시 클릭하고, 시스템은 같은 일을 여러 번 할 수 있다.

그래서 비용과 지연 시간은 단순 성능 문제가 아니다. 어떤 작업을 자동 승인할지, 어떤 작업을 background로 돌릴지, 어떤 작업을 사람에게 넘길지 결정하는 권한 설계의 일부다. 느리고 비싼 작업은 더 명확한 승인과 상태 표시가 필요하다.

프롬프트 인젝션과 과도한 자율성

OWASP Top 10 for LLM Applications는 Prompt Injection, Sensitive Information Disclosure, Insecure Plugin Design, Excessive Agency 같은 위험을 제시한다. 회사 에이전트에서 MCP와 A2A를 붙이면 이 위험들이 추상적인 보안 용어가 아니라 실제 운영 이슈가 된다. 외부 문서나 고객 티켓 안의 악성 지시문이 도구 호출로 이어질 수 있기 때문이다.

OpenAI의 MCP 문서도 prompt injection을 중요한 보안 고려사항으로 다룬다. 특히 MCP 서버와 connector가 민감 데이터에 접근하거나 action을 수행할 수 있을 때는 주의와 완화책이 필요하다. 이 말은 “모델이 알아서 거를 것이다”가 아니라 “도구 권한과 승인 흐름으로 피해 면적을 줄여야 한다”에 가깝다.

A2A까지 들어오면 위험은 한 단계 더 복잡해진다. 에이전트 A가 읽은 내용을 에이전트 B에게 넘기고, B가 다시 MCP 도구를 실행하면 원래 사용자 요청과 최종 action 사이의 거리가 길어진다. 이때 handoff 로그와 책임자를 남기지 않으면 문제가 생겼을 때 경로를 따라가기 어렵다.

그래서 프롬프트 인젝션 대응은 필터 하나로 끝나지 않는다. trusted source 분리, 외부 콘텐츠 격리, 도구별 권한 제한, 민감 작업 승인, 출력 검증, 로그 리뷰가 함께 가야 한다. 보안은 한 방에 끝나는 마법 주문이 아니라 체크박스가 많은 현실 문서다. 재미는 없지만 돈값은 한다.

도입 전 체크표

항목 확인 질문 첫 설정 추천
서버 신뢰 공식 서버인가, 프록시인가, 내부 운영인가? 공식 또는 내부 서버 우선
권한 읽기와 쓰기가 분리되어 있는가? read-only부터 시작
allowed tools 필요한 도구만 노출했는가? search/fetch 중심 최소화
승인 쓰기, 발송, 삭제, 배포에 사람이 들어가는가? L3 action은 사전 승인
로그 tool name, args, approval, result가 남는가? 표준 필드 고정
데이터 경계 제3자 서버, 리전, 보관 정책을 봤는가? 민감 데이터 외부 전송 차단
비용 사용자 수와 호출 빈도 기준으로 계산했는가? 파일럿 사용량부터 측정
실패 처리 서버 장애와 토큰 만료 때 멈추는가? 중단, 재시도, 알림 분리
A2A 위임 에이전트 간 전달 데이터와 책임자가 남는가? handoff_id와 owner 저장

이 체크표를 통과하지 못한다고 해서 MCP를 쓰면 안 된다는 뜻은 아니다. 오히려 통과하지 못한 항목이 파일럿 범위다. 부족한 항목을 줄이고 나서 권한을 조금씩 열면, 팀은 자동화 속도와 운영 안정성을 같이 얻을 수 있다.

7월 업데이트 실행 순서

첫 주에는 내부 위키 검색이나 정책 문서 요약처럼 L1 read-only 작업만 붙인다. 이때 run_id, tool_name, data_scope, result_status를 남기고, MCP 서버가 어떤 데이터를 받는지 확인한다. 성공률보다 중요한 것은 로그가 재현 가능한지다.

둘째 주에는 초안 생성으로 넓힌다. 문서 초안, 이슈 초안, 회의록 정리, 리포트 초안을 만들되 최종 저장은 사람이 한다. 이 단계에서 reviewer와 source_refs를 남기면 나중에 초안 품질을 개선하기 쉽다.

셋째 주에만 제한적인 action을 연다. 내부 티켓 상태 변경이나 낮은 위험도의 태그 수정처럼 되돌릴 수 있는 작업부터 시작한다. 외부 발송, 고객 데이터 변경, 삭제, 결제, 배포는 별도 승인과 알림을 붙인 뒤에야 열어야 한다.

마지막으로 월 1회 권한 리뷰를 둔다. 실제로 쓰지 않는 도구는 닫고, 실패율이 높은 도구는 파일럿으로 되돌리고, 비용이 튄 작업은 캐싱이나 배치 처리로 바꾼다. 자동화는 한 번 열면 끝이 아니라, 계속 가지치기해야 덜 무서운 도구가 된다.

FAQ

MCP를 쓰면 기존 API 연동이 필요 없어질까?

아니다. MCP는 모델과 도구 사이의 연결 방식을 표준화하는 데 도움을 주지만, 실제 인증, 권한, API 안정성, 장애 처리, 데이터 정책은 여전히 직접 설계해야 한다. MCP를 붙인다고 운영 책임이 사라지는 것은 아니다.

회사 업무에 MCP를 붙일 때 첫 파일럿은 무엇이 좋을까?

읽기 전용 내부 문서 검색이나 반복 리포트 요약이 무난하다. 데이터 변경이나 외부 발송이 없는 영역부터 시작하면 권한과 로그 구조를 안전하게 검증할 수 있다. 파일럿에서 호출량, 실패율, 응답 시간, 사용자 만족도를 같이 기록하는 것이 좋다.

외부 MCP 서버를 바로 써도 될까?

테스트는 가능하지만 업무 데이터가 들어가는 순간 신중해야 한다. 공식 서버인지, 제3자 서버인지, 데이터 보관 정책이 무엇인지 확인해야 한다. 민감 데이터가 포함된다면 내부 MCP 서버 또는 보안 검토를 거친 연결 방식을 우선 보는 편이 안전하다.

A2A는 MCP보다 더 위험한가?

둘의 위험이 다르다. MCP는 도구와 데이터 접근 면적을 넓히고, A2A는 에이전트 간 위임과 책임 경로를 길게 만든다. 함께 쓰면 강력해지지만 handoff 로그, owner, 승인 기준이 없으면 추적이 어려워진다.

최소 로그 필드는 무엇부터 잡으면 될까?

첫 파일럿에서는 run_id, agent_id, user_id, tool_name, permission_level, approved_by, result_status, created_at부터 잡으면 된다. 원문 전체 저장보다 재현 가능한 참조와 민감정보 마스킹이 더 중요하다.

공식 출처

관련 글