MCP가 뜨거운 이유는 더 많은 도구를 붙일 수 있어서가 아니다. 2026년 5월 흐름을 보면 관심사는 이미 다음 단계로 넘어갔다. Notion은 2026년 5월 13일 Developer Platform과 MCP 개선을 묶어 워크스페이스 범위 제어를 전면에 세웠고, OpenAI는 2026년 5월 14일 이후 Codex 운영 메시지에서 승인 경계, 로그, 네트워크 정책을 반복해서 강조했다. n8n 역시 MCP 기반 워크플로 생성, 툴콜링, 승인 패턴을 연달아 설명하면서 “연결”보다 “운영”이 핵심이라는 신호를 보냈다.
한국어 실무 독자 입장에서 질문은 더 직설적이다. “MCP를 붙였는데 왜 자동화가 자꾸 불안정할까?” 이유는 대개 모델 성능이 아니라 운영 레이어 공백이다. 어떤 컨텍스트를 실시간으로 넣을지, 어떤 액션에서 사람 승인을 받을지, 실패했을 때 어떤 로그를 남길지, 문서 허브와 실행 허브를 어디서 다시 연결할지를 먼저 정하지 않으면 에이전트는 데모는 되지만 반복 운영은 어렵다.
왜 지금 MCP보다 운영 레이어가 먼저인가
도구 연결 자체는 점점 쉬워지고 있다. 그래서 차별점은 “무엇을 연결했는가”보다 “연결된 도구를 어떤 정책 아래 실행시키는가”로 이동했다. 같은 MCP 서버를 붙여도 한 팀은 안심하고 반복 실행하고, 다른 팀은 매번 결과를 다시 검토하느라 자동화 이득을 못 본다. 이 차이를 만드는 것이 운영 레이어다.
운영 레이어를 먼저 본다는 말은 거창한 플랫폼을 먼저 사라는 뜻이 아니다. 최소한 다음 네 가지는 분리해서 생각하자는 뜻에 가깝다.
- 컨텍스트 레이어: 에이전트가 어떤 업무 상태와 문서를 읽는가
- 승인 레이어: 어떤 순간에 사람을 호출하는가
- 관측성 레이어: 실패 원인과 도구 호출 흔적을 어디에 남기는가
- 거버넌스 레이어: 어떤 워크스페이스 범위와 권한으로 쓰기 액션을 허용하는가
이 네 가지를 분리하면 도구 수가 늘어나도 운영 기준은 덜 흔들린다. 반대로 이를 한 덩어리로 두면 작은 변경이 곧바로 보안, 품질, 승인 비용 문제로 번진다.
1. 워크플로 생성 레이어는 실행 전에 구조를 고정한다
n8n이 2026년 4월 29일 MCP 서버를 통해 워크플로 실행뿐 아니라 생성과 수정까지 연결한다고 설명한 대목은 중요하다. 이 신호는 “자연어로 초안을 만드는 것”과 “실제 자동화를 배포 가능한 구조로 만드는 것”의 간격을 줄여 준다. 하지만 여기서 흔히 생기는 오해가 있다. 자연어로 만들 수 있다고 해서 곧바로 운영 가능한 것은 아니라는 점이다.
실무에서는 초안 생성 단계에서 세 가지를 먼저 고정하는 편이 낫다.
- 트리거: 이 자동화는 어떤 이벤트에서 시작되는가
- 입력: 어떤 문서, 필드, 외부 도구를 읽는가
- 종료 조건: 성공과 실패를 무엇으로 판단하는가
이 셋이 없는 상태에서 MCP로 워크플로를 계속 생성하면, 표면상으로는 빨라 보여도 운영 중 재시도 횟수와 승인 대기 시간이 늘어난다. 자동화가 잘 만들어졌는지는 프롬프트가 그럴듯한지가 아니라, 생성된 구조를 사람이 짧게 검토할 수 있는지로 판단하는 편이 낫다.
2. 컨텍스트 레이어는 프롬프트가 아니라 상태 관리 문제다
에이전트가 자꾸 엉뚱한 도구를 고르거나 같은 질문을 반복하는 경우, 문제는 종종 모델보다 컨텍스트 주입 방식에 있다. Weavable과 Hugging Face Agents 문서가 보여 준 방향도 비슷하다. 중요한 것은 컨텍스트를 “많이” 넣는 것이 아니라 “현재 작업에 맞게 살아 있는 상태”로 넣는 것이다.
여기서 실무적으로 도움이 되는 기준은 단순하다. 반복 실행에 필요한 상태를 프롬프트 본문에 누적하지 말고 별도 레이어로 관리하는 것이다. 예를 들면 다음과 같다.
- 워크스페이스 정책: 어떤 문서와 데이터베이스를 읽고 쓸 수 있는가
- 작업 이력: 방금 어떤 도구 호출이 실패했고 어디서 재개할 것인가
- 승인 상태: 어느 단계가 사람 확인을 기다리고 있는가
- 재진입 지점: 장기 실행 작업이 중단되면 어디서부터 다시 시작할 것인가
이 구조를 만들면 에이전트는 더 짧은 지시로도 안정적으로 움직인다. 반대로 모든 상태를 대화 문맥에만 기대면, 실행 길이가 길어질수록 도구 선택이 흐려지고 사람 검토 부담이 커진다.
3. 워크스페이스 거버넌스는 문서 저장이 아니라 범위 제어다
Notion이 이번 달에 워크스페이스형 에이전트 허브 방향을 강조한 이유도 여기에 있다. MCP가 연결된다는 사실 자체보다, 어느 팀 공간을 읽고 어떤 데이터베이스에 쓸 수 있으며 어떤 범위를 금지할지를 워크스페이스 단위에서 정할 수 있다는 점이 운영상 더 중요하다.
실무에서는 특히 다음 질문이 먼저 나와야 한다.
- 초안 작성 에이전트가 쓸 수 있는 쓰기 범위는 어디까지인가
- 업무 문서와 발행 문서를 같은 권한 세트로 묶어도 되는가
- 승인 전에는 읽기 전용으로 두고, 승인 후에만 쓰기 권한을 열 것인가
- 사람 검토가 끝난 결과를 어떤 허브 문서에 남길 것인가
문서 허브와 실행 허브를 따로 두되, 서로 재진입 지점으로 연결하는 방식이 대체로 안정적이다. 에이전트는 문서에서 맥락을 가져오고, 실행 시스템은 결과와 로그를 남기며, 사람은 두 레이어를 넘나들며 승인한다. 이 흐름이 있어야 “왜 이 결과가 나왔는지”를 나중에도 설명할 수 있다.
4. 툴콜링 관측성은 비용 문제가 아니라 복구 문제다
n8n이 툴콜링의 난점을 JSON 생성보다 실패 처리, 자격증명 주입, 실행 추적으로 설명한 배경도 분명하다. 실제 운영에서 문제를 만드는 것은 모델이 한 번 틀리는 순간보다, 그 틀림을 재현하고 복구할 수 없다는 점이다. OpenAI가 Codex 운영에서 로그와 네트워크 경계를 함께 다룬 것도 같은 맥락이다.
관측성 레이어에서는 최소한 아래 항목이 남아야 한다.
- 어떤 입력으로 어떤 도구를 호출했는가
- 어떤 권한 경계 안에서 실행했는가
- 실패가 모델 판단 때문인지 도구 오류 때문인지
- 재시도는 몇 번 있었고 어디서 중단되었는가
첫 운영 지표를 토큰 사용량으로 잡기보다 재시도 횟수, 승인 대기 시간, 오류 복구 시간으로 잡으라는 이유도 여기 있다. 한국 팀 실무에서는 “이번 주에 얼마나 많이 썼는가”보다 “어디서 조용히 망가졌는가”를 더 빨리 알아야 한다.
5. 승인 레이어는 HITL과 HOTL을 섞어 써야 한다
모든 단계에 사람 승인을 넣으면 자동화 이득이 사라지고, 아무 데도 승인을 두지 않으면 신뢰가 무너진다. 그래서 운영형 에이전트에서는 HITL과 HOTL을 구분해 설계하는 편이 낫다.
- HITL: 외부 발신, 배포, 데이터 변경처럼 고위험 액션 직전에 멈춘다.
- HOTL: 리서치 수집, 초안 생성, 내부 분류처럼 저위험 단계를 사후 모니터링한다.
이 기준을 정해 두면 승인 설계가 훨씬 가벼워진다. 사람은 정말 위험한 순간에만 개입하고, 저위험 작업은 관측성 레이어를 통해 나중에 검토하면 된다. 결국 좋은 승인 체계는 “항상 멈추게 하는 체계”가 아니라 “필요한 순간에만 정확히 멈추는 체계”다.
바로 적용할 운영 체크리스트
- MCP 서버를 늘리기 전에 어떤 도구를 누구에게 노출할지 정한다.
- 라이브 컨텍스트는 프롬프트 덧붙이기보다 별도 상태 레이어로 관리한다.
- 실패 로그와 도구 호출 흔적을 남기지 않는 자동화는 운영하지 않는다.
- 승인 게이트는 고위험 액션과 저신뢰 출력에 우선 배치한다.
- 문서 허브와 자동화 허브를 분리하되, 승인 후 재진입 지점을 명확히 연결한다.
- 첫 성과 지표는 토큰이 아니라 재시도 횟수, 승인 대기 시간, 복구 시간을 본다.
MCP는 시작점일 뿐이다. 실제로 덜 깨지고 덜 불안한 자동화를 만들고 싶다면 연결 이후의 레이어를 먼저 설계해야 한다. 컨텍스트, 승인, 관측성, 워크스페이스 거버넌스를 분리해서 보면 에이전트는 데모 도구에서 운영 가능한 시스템으로 넘어간다.