원격 MCP는 편리하지만, 권한의 선을 어디까지 그어야 할까?
Remote MCP is convenient, but where do you draw the permission line
핵심 요약
코딩 에이전트의 MCP 권한 설정 시 보안과 편의성 사이의 균형점을 고민하는 글.
- MCP 권한 설정 — 에이전트의 쓰기 권한 부여에 따른 보안 위험을 우려함.
- 읽기 전용 도구 — 문서 검색이나 로그 조회 등은 안전하다고 판단함.
- 위험한 작업 — DNS 변경, 결제 정보 수정 등은 에이전트에게 맡기기 꺼려함.
- 인간의 개입 — 자동화된 작업이라도 중요한 결정에는 여전히 인간의 승인이 필요하다고 주장함.
MCP는 코딩 에이전트를 훨씬 유용하게 만들어 주지만, 실제 쓰기 권한을 연결하기 전에는 주춤하게 만든다.
읽기 전용 도구는 정당화하기 쉽다. 에이전트가 문서를 검색하고, 이슈를 확인하고, 로그를 쿼리하고, 데이터베이스 스키마를 읽게 하는 식이다. 시간은 절약되고 피해 범위는 제한적이다. 하지만 도구가 무언가를 변경할 수 있는 순간, 나는 훨씬 신중해진다. 이메일 발송, 프로덕션 데이터 수정, DNS 변경, GitHub 이슈 닫기, 결제 정보 건드리기, 로컬 네트워크 설정 수정. 이런 것들은 더 이상 "그냥 코딩"이 아니다.
GitHub가 나에게는 가장 명확한 예시였다. 에이전트가 이슈, PR diff, CI 로그를 읽게 하는 건 당연히 가치 있다고 느꼈지만, 내가 diff를 한 줄 한 줄 다시 확인하지 않고는 머지, 푸시, 이슈 닫기 권한을 주지 않을 것이다.
승인 프롬프트가 도움이 된다는 건 알지만, 완전히 안심되지는 않는다. 에이전트가 긴 작업을 수행 중이고 내가 피곤할 때, 명령을 너무 빨리 승인해 버릴 수도 있다. 그리고 원격 MCP의 경우, 서버, 권한, 로그, 그리고 내가 지난주에 무엇을 연결했는지에 대한 내 기억까지도 신뢰해야 한다.
다들 이 선을 어떻게 긋고 있나? MCP 도구를 기본적으로 읽기 전용으로 설정하나? 어떤 작업이 매번 인간의 승인을 필요로 하나? 에이전트에게 노출하기를 거부하는 도구가 있나? 그리고 개인 프로젝트의 경우, 권한이 아주 적은 별도의 토큰을 사용하나, 아니면 그게 너무 번거로운가?
내가 너무 신중한 걸 수도 있지만, 잘못된 것을 조용히 수정해 버리는 에이전트보다는 차라리 조금 느린 에이전트가 낫다.
