MCP를 붙이면 자동화가 갑자기 똑똑해질 것처럼 보인다. 실제로는 반대 상황이 더 자주 나온다. 연결 자체는 쉬워졌는데, 운영 기준이 없어서 멈춘다. 어떤 MCP 서버를 믿어도 되는지, Codex 같은 코딩 에이전트에 어디까지 권한을 줄지, 로컬 앱 자동화를 열 때 실패 복구를 어떻게 설계할지, n8n이 만든 워크플로 초안을 어떤 기준으로 검증할지가 한꺼번에 밀려오기 때문이다.
이번 글의 핵심은 단순하다. 지금의 병목은 모델 성능보다 연결 순서에 있다. 툴을 더 많이 붙이기 전에 샌드박스, 툴 노출 범위, 제어 토폴로지, 실행 진단 루프를 먼저 정해야 한다. OpenAI MCP 문서가 서드파티 서버 위험과 OAuth 구성을 강조하고, Codex Windows sandbox 글이 승인 모델과 권한 경계를 전면에 둔 것도 같은 맥락이다. n8n 역시 워크플로 생성과 제어 패턴을 이야기할 때 “얼마나 쉽게 만들 수 있는가”보다 “어떤 구조로 안전하게 굴릴 것인가”를 더 크게 다루고 있다.
왜 지금 MCP 보안 체크리스트가 먼저일까
초기 MCP 도입 단계에서는 연결 가능성이 가장 흥미로운 주제였다. 이제는 관점이 달라졌다. 연결이 쉬워질수록 서드파티 서버의 운영 주체, 인증 방식, 툴 설명 품질, 권한 범위 같은 요소가 실제 리스크를 결정한다. 특히 한국 팀이 여러 SaaS와 내부 도구를 함께 쓰는 환경에서는 “이 MCP 서버가 뭘 할 수 있는가”보다 “이 서버가 어떤 데이터를 보게 되는가”가 먼저 질문이 돼야 한다.
문제는 이 검토가 대개 가장 늦게 온다는 점이다. 먼저 붙여 보고, 동작하면 계속 확장하고, 나중에 승인 구조를 붙이려다 보니 이미 쓰기 권한과 읽기 권한이 한데 섞여 있는 경우가 많다. 이렇게 되면 보안 이슈가 생겼을 때 개별 도구를 끄는 수준으로는 해결되지 않는다. 에이전트가 어떤 경계 안에서 움직이게 할지부터 다시 설계해야 한다.
체크리스트 1: 서드파티 MCP 서버는 기능보다 운영 주체를 먼저 본다
MCP 서버를 평가할 때 많은 팀이 먼저 보는 것은 제공 기능 목록이다. 검색, 파일 읽기, 브라우저 제어, 배포, 데이터 쓰기 같은 기능은 분명 중요하다. 하지만 운영 관점에서는 아래 질문이 더 앞에 와야 한다.
- 이 서버를 누가 운영하는가.
- 어떤 인증 방식을 쓰는가.
- 최소 권한 구성이 가능한가.
- 로그와 감사 흔적을 남길 수 있는가.
- 중단하거나 교체할 때 영향 범위를 빠르게 줄일 수 있는가.
이 다섯 가지에 답이 흐리면, 기능이 좋아도 운영 리스크는 높다. 특히 커뮤니티 예제나 개인 프로젝트 성격의 MCP 서버를 팀 환경에 바로 붙일 때는 “잘 된다”보다 “문제가 생겼을 때 누가 책임지고 고칠 수 있는가”를 먼저 확인해야 한다. MCP는 연결 표준이지 신뢰 보증 장치가 아니다.
체크리스트 2: 툴 노출은 연결 수가 아니라 작업 단계 기준으로 줄인다
MCP를 도입하면 연결 수를 늘리기 쉽다. 그러나 에이전트 입장에서는 도구가 많을수록 더 똑똑해지는 것이 아니라 선택 비용이 커진다. 읽기, 수정, 발행, 배포가 모두 같은 목록에 노출되면 경로가 흔들리고 승인 이유도 불분명해진다. 이미 다뤘던 MCP 도구 노출 최소화 가이드가 중요한 이유도 여기에 있다.
실무에서는 도구를 세 묶음으로 나누는 방식이 가장 단순하고 효과적이다.
- 읽기 도구: 검색, 문서 조회, 로그 확인
- 생성 도구: 초안 작성, 제한적 편집, 워크플로 생성
- 승인형 쓰기 도구: 배포, 발행, 권한 변경, 외부 메시지 전송
핵심은 연결 자체를 끊는 것이 아니라 노출 타이밍을 제한하는 것이다. 같은 MCP 서버라도 모든 에이전트에게 항상 열어 두지 말고, 작업 단계에 따라 필요한 도구만 보이게 해야 한다. 그래야 승인 모델도 선명해진다.
체크리스트 3: n8n MCP 워크플로 빌드는 초안 생성기로 보고 검증 단계를 남긴다
n8n MCP의 강점은 워크플로를 실행하는 수준을 넘어, 생성과 업데이트까지 자연어 흐름으로 줄여 준다는 점이다. 이것만 보면 자동화 설계가 거의 해결된 것처럼 느껴진다. 하지만 실제 운영에서는 초안 생성이 끝이 아니라 시작이다. 어떤 노드를 선택했는지, 입력 스키마가 맞는지, 실패 시 어디서 멈추는지, 재시도 시 중복 실행이 없는지 확인해야 한다.
이 지점에서 기존 글 n8n MCP 워크플로 생성 가이드와 오늘 주제를 구분해서 볼 필요가 있다. 생성 가이드는 자연어에서 초안까지의 간격을 줄이는 데 초점을 뒀다. 오늘의 체크리스트는 그 초안을 운영 가능한 구조로 바꾸는 조건을 묻는다. 즉 “만들 수 있는가”가 아니라 “믿고 반복 실행해도 되는가”의 문제다.
검증 기준은 복잡할 필요가 없다. 시작 이벤트, 입력 필드, 외부 쓰기 권한, 실패 처리, 승인 지점 다섯 가지만 고정해도 품질 차이가 크게 난다. 에이전트가 잘 만든 초안이라도 이 다섯 요소가 비어 있으면 결국 사람 손으로 다시 수습하게 된다.
체크리스트 4: Codex 같은 코딩 에이전트에는 샌드박스와 승인 정책을 같이 설계한다
코딩 에이전트 운영에서는 두 가지 극단이 자주 나타난다. 첫째는 매 단계마다 승인을 눌러야 해서 자동화가 사실상 멈추는 경우다. 둘째는 귀찮아서 곧바로 풀액세스를 열어 두는 경우다. OpenAI가 Windows sandbox를 설명하며 보여 준 포인트는 이 둘 사이에 실무적인 설계 공간이 있다는 점이다.
중요한 것은 “승인을 많이 할 것인가 적게 할 것인가”가 아니다. 어떤 액션이 어느 경계 밖으로 나갈 때만 승인을 요구할지 미리 정하는 일이다. 예를 들어 로컬 파일 읽기, 제한된 디렉터리 쓰기, 테스트 실행, 외부 네트워크 접근, 배포성 액션을 동일한 위험도로 다루면 운영이 비효율적이 된다. 반대로 모두 같은 수준으로 허용하면 사고 범위가 너무 커진다.
이 주제는 아래 후속 글에서 더 자세히 다룬다.
체크리스트 5: Computer Use나 로컬 앱 자동화는 가치와 복구 경로를 같이 설계한다
컴퓨터 유즈 MCP는 강력하다. 웹이 아니라 데스크톱 앱까지 에이전트 작업 범위에 넣어 주기 때문이다. 하지만 이 강력함은 곧바로 복구 난도로 이어진다. 브라우저 API처럼 구조화된 응답이 있는 것이 아니라, 화면 상태, 포커스, 권한 팝업, 지연, 예상 밖의 UI 변화가 끼어들 수 있다.
그래서 로컬 앱 자동화에서는 성공 경로만 설계하면 거의 반드시 문제가 난다. 실패 시 사람이 어디서 다시 이어받는지, 에이전트가 어느 시점에서 멈춰야 하는지, 중요한 액션 전후에 어떤 로그나 스크린샷을 남길지까지 묶어서 설계해야 한다. 특히 파일 삭제, 메시지 발송, 권한 설정 변경처럼 되돌리기 어려운 작업은 Computer Use에 전부 맡기기보다 사전 준비와 사후 확인을 나눠 두는 편이 안전하다.
체크리스트 6: 제어 토폴로지를 잘못 고르면 프롬프트를 고쳐도 오래 못 간다
자동화가 자주 흔들릴 때 사람들은 먼저 프롬프트를 손본다. 하지만 n8n이 강조한 것처럼 제어 토폴로지를 잘못 고르면 프롬프트 품질로는 해결되지 않는 문제가 남는다. 예를 들어 모든 작업을 하나의 오토노머스 루프에 넣으면 초기 데모는 화려할 수 있지만, 승인 지점과 실패 경계가 흐려진다. 반대로 단계형 플로우로 나누면 유연성은 다소 줄어도 복기와 재개가 쉬워진다.
실무에서는 아래 세 가지를 먼저 구분하는 편이 좋다.
- 완전 자율 루프: 탐색과 초안 생성에는 유용하지만 외부 쓰기까지 맡기면 위험하다.
- 단계형 플로우: 반복 운영과 디버깅에 가장 적합하다.
- 사람 승인 포함 플로우: 대외 발신, 배포, 데이터 변경처럼 비용이 큰 액션에 적합하다.
이미 공개한 AI 에이전트 제어 흐름 설계 가이드를 함께 보면, 왜 승인을 별도 이벤트가 아니라 상태 전이의 일부로 둬야 하는지도 더 선명해진다.
체크리스트 7: 린팅과 실행 진단이 없는 자동 생성은 금방 조용히 망가진다
운영에서 더 무서운 것은 큰 장애보다 silent failure다. 워크플로는 실행된 것처럼 보이는데, 실제로는 입력 스키마가 어긋나거나 분기 조건이 비어 있거나 로그가 충분하지 않아 결과를 믿기 어려운 상태가 되는 것이다. n8n-mcp 커뮤니티가 linting과 execution diagnosis를 같이 강조한 것도 그래서다.
자동 생성 기능이 좋아질수록 후속 진단 루프는 더 중요해진다. 생성 속도가 빨라지면 잘못된 초안도 더 빨리 쌓이기 때문이다. 운영형 자동화에서는 “초안이 나왔다”보다 “문제가 생겼을 때 어디서 원인을 좁힐 수 있는가”가 더 큰 비용 절감 포인트가 된다.
이 부분은 아래 후속 글에서 구체적인 운영 루프 형태로 정리했다.
소규모 팀이 오늘 바로 적용할 최소 기준
MCP, n8n, Codex, Computer Use를 한 번에 도입하는 팀이라면 거창한 거버넌스 문서보다 아래 최소 기준부터 고정하는 편이 낫다.
- 서드파티 MCP 서버는 운영 주체와 인증 방식부터 검토한다.
- 읽기 도구와 쓰기 도구를 같은 기본 노출 목록에 두지 않는다.
- 자동 생성 워크플로에는 시작 이벤트, 실패 처리, 승인 지점을 반드시 적는다.
- 코딩 에이전트는 샌드박스 범위와 승인 조건을 한 세트로 정의한다.
- 로컬 앱 자동화는 실패 복구 경로와 감사 흔적을 같이 설계한다.
- linting과 execution diagnosis가 없는 초안은 운영으로 바로 넘기지 않는다.
이 여섯 가지를 먼저 지키면, 이후에 더 많은 MCP 서버를 붙이거나 더 자율적인 에이전트 구조로 확장하더라도 흔들림이 훨씬 적다. 연결 기술은 계속 쉬워질 것이다. 그래서 앞으로 더 중요한 경쟁력은 도구를 얼마나 많이 붙였는지가 아니라, 어떤 경계 안에서 반복 가능하게 굴리느냐다.