에이전트에게 도구를 하나씩 붙이다 보면 어느 순간 이런 착각이 생깁니다. 연결이 많을수록 똑똑한 작업 환경이 된다는 생각입니다. Gmail도, 드라이브도, 검색 서버도, 파일 시스템도 붙으면 처음에는 분명히 시원합니다. 그런데 그다음부터는 질문이 바뀝니다. “이 에이전트가 어디까지 읽어도 되는가?”, “이 버튼을 누르면 무엇이 실제로 바뀌는가?”
지난 글에서 적어 둔 도구 경계와 감사 가능성을, 오늘은 MCP·워크스페이스·비밀정보의 경계선으로 더 구체화해 보겠습니다. 도구를 덜 쓰자는 말이 아닙니다. 많이 연결할수록, 멈춰야 할 선도 먼저 그려 두자는 이야기입니다.
1. 워크스페이스는 폴더가 아니라 권한의 울타리다
예전에는 프로젝트 폴더를 그저 파일을 모아 둔 서랍 정도로 생각했습니다. 하지만 에이전트가 들어오면 워크스페이스는 곧 컨텍스트의 출입구가 됩니다. 어떤 폴더를 열었는지에 따라 에이전트가 읽는 규칙, 검색하는 자료, 수정할 수 있는 파일의 범위가 달라지기 때문입니다.
그래서 저는 루트와 개별 프로젝트를 같은 방으로 보지 않습니다.
| 구역 | 담아야 할 것 | 에이전트의 기본 권한 |
|---|---|---|
| 작업 공간 루트 | 공통 안내서, 편집기 설정, 프로젝트 지도 | 읽기·설정 검토 |
| 개별 프로젝트 | 코드, 콘텐츠, 테스트, 배포 설정 | 해당 프로젝트 안에서만 수정 |
| 외부 지식 저장소 | 참고 메모, 리서치, 장기 기록 | 원칙적으로 읽기 전용 |
| 비밀정보 구역 | 키, 토큰, 인증서, 실계정 설정 | 읽기·출력·커밋 모두 차단 |
중요한 것은 폴더 이름이 아니라 기본값입니다. 처음에는 닫아 두고 필요한 통로만 여는 편이 안전합니다.
아키텍처 교훈 ① 워크스페이스 경계는 파일 정리 규칙이 아니라, 에이전트가 볼 수 있는 세계의 크기를 정하는 권한 설계다.
2. MCP는 플러그인이 아니라 ‘업무 위임장’이다
MCP 서버를 연결할 때 흔히 “무슨 기능이 있지?”부터 봅니다. 물론 필요합니다. 그러나 한 단계 더 중요한 질문은 “이 도구가 무엇을 할 수 있지?”입니다. 검색 도구와 메일 발송 도구는 같은 ‘연결’이지만 위험도는 전혀 다릅니다.
저는 도구를 대략 세 층으로 나눠 봅니다.
- 조회 도구: 문서 검색, 목차 조회, 파일 목록 확인처럼 원본을 바꾸지 않는 도구
- 준비 도구: 초안 생성, 로컬 파일 편집, 테스트 실행처럼 되돌릴 수 있는 작업을 하는 도구
- 실행 도구: 메일 발송, 외부 게시, 결제, 배포처럼 외부 상태를 바꾸는 도구
조회 도구는 비교적 넓게, 준비 도구는 프로젝트 경계 안에서, 실행 도구는 사용자 승인 뒤에만 열어 두는 편이 좋습니다. 승인 없는 완료가 가장 비싼 실수가 될 수 있으니까요.
3. 비밀정보는 숨기는 것만으로 끝나지 않는다
.env 파일을 Git에서 제외했다고 해서 경계가 완성되지는 않습니다. 토큰이 로그에 섞일 수 있고, 에이전트가 읽은 값을 답변에 다시 적을 수 있으며, 절대경로·계정명·내부 문서 제목도 쌓이면 의도치 않은 단서가 됩니다.
그래서 실무에서는 세 가지를 함께 확인해야 합니다.
- 저장 위치: 키와 토큰은 프로젝트 코드나 일반 문서가 아닌 별도 환경 설정에 있는가
- 주입 경로: 필요한 실행 시점에만 환경 변수나 호스팅 설정으로 전달되는가
- 노출 경로: 채팅, 로그, 오류 화면, 커밋 메시지에 값이나 식별자가 남지 않는가
이 세 질문을 해 두면 “이 자료를 보내도 되나?”가 “이 자료는 어느 경계를 넘는가?”라는 설계 질문으로 바뀝니다.
아키텍처 교훈 ② 비밀정보 보호는 파일을 숨기는 기술이 아니라, 정보가 이동하는 모든 길을 줄이는 작업이다.
4. 좋은 경계선은 일을 멈추게 하지 않는다
경계를 이야기하면 업무가 답답해질 것 같지만, 잘 만든 경계는 오히려 일을 빠르게 합니다. 에이전트에게 미리 알려 줄 것이 명확해지기 때문입니다.
예를 들어 “블로그 글을 다듬어 줘”라는 요청은 게시물 파일을 읽고 수정하는 데까지는 진행해도 됩니다. 하지만 “발행해 줘”가 빠진 이상, 원격 푸시나 외부 배포까지 넘어가면 안 됩니다. 반대로 “문헌을 찾아 요약해 줘”는 검색과 초안은 자동화하되, 법적 결론이나 고객 전달본은 사람 검토 단계에 남겨 두는 편이 자연스럽습니다.
이렇게 쓰면 됩니다.
읽기 → 초안 → 검토 → 승인 → 외부 실행
거창한 프로세스 문서가 아니라 AGENTS.md 한 문장이나 배포 전 체크박스 하나로도 됩니다. 다음 사람이나 에이전트가 같은 선을 다시 추측하지 않게 하는 것이 중요합니다.
마치며
에이전트 시대의 보안은 “접속을 막는 일”만으로 설명하기 어렵습니다. 좋은 작업 환경은 필요한 도구를 잘 연결하면서도, 그 도구가 지나갈 수 없는 길을 더 분명하게 보여 줍니다.
저는 앞으로 새 MCP를 붙일 때 기능표보다 먼저 이 다섯 가지를 적어 보려 합니다. 어디서 실행되는가, 무엇을 읽는가, 무엇을 바꾸는가, 비밀정보를 만나는가, 마지막 행동은 누가 승인하는가. 이 질문에 답할 수 있다면, 그 연결은 편리한 데모를 넘어 운영 가능한 디지털 아키텍처에 가까워질 겁니다.