자, 이것은 진정으로 유용한 학습 경험이 되었으며, 여러분 중 일부는 여기서 얻어갈 만한 가치가 있는 것을 발견할 수 있을 것이라고 생각합니다. 이것을 보세요: "위험은 커넥터(connector)의 개수 그 자체에 있는 것이 아닙니다. 문제는 어떤 것들이 동일한 세션에서 동시에 활성화되어 있는가입니다." 도구의 수가 20개를 넘어서자, 답변에서 환각 (hallucination) 현상이 나타나고 보고서에서 데이터가 뒤섞이는 것을 발견하기 시작했습니다. 각각의 새로운 Claude 모델은 (제 관점에서는 물론) 프로세스를 더 빠르고 똑똑하게 만들었지만, 여러 MCP에 걸쳐 데이터를 라우팅 (routing)하는 내부 로직은 커스텀 오케스트레이션 레이어 (custom orchestration layer)를 제공할 때만 유지됩니다. 즉, 동일한 영역을 다루는 데이터베이스 간의 중복되는 데이터를 필터링하고 제거하는 무언가가 필요합니다. 많은 수의 MCP를 실행할 때의 위험성에 대한 Claude 자체의 몇 가지 포인트가 눈에 띄었습니다 (이 포인트들은 채팅에서 직접 가져왔습니다): 도구 충돌 (Tool collisions). "당신은 SE Ranking의 운영(prod), 스테이징(staging), 그리고 두 개의 웹사이트 테스트 서버를 병렬로 연결해 두었습니다. 모델이 잘못된 것을 선택할 수 있습니다. 즉, 쓰레기 데이터를 얻거나 잘못된 워크스페이스에 데이터를 쓰게 될 수 있습니다." 따라서 인접한 데이터를 수집하는 소스들을 병렬로 실행하는 것은 조용히 시스템을 망가뜨릴 수 있습니다. 핵심은 이것입니다: 개별 MCP (단독으로는) 자신의 데이터를 아름답게 오케스트레이션 (orchestrate)합니다. 제가 AI 가시성 (AI Visibility) 데이터를 위해 SE Ranking API를 호출하면, 데이터베이스의 기초가 되고 나중에 통찰력과 보고서로 이어지는 깨끗한 수치를 얻게 됩니다. 맞죠? 하지만 제가 다른 MCP에서 유사한 작업을 수행하는 두 번째 (테스트) 프로젝트를 가동하는 순간, 동일한 목표를 향한 두 번째 데이터셋이 생기게 됩니다. 만약 제가 Claude에게 해당 데이터셋들에 적절한 레이블과 태그를 미리 달라고 말하지 않으면, 분석을 적극적으로 방해하는 데이터 수프 (data soup) 상태가 되어버립니다. 제가 깨달은 것은 이렇습니다: 각 MCP는 자신의 일을 잘 수행할 수 있지만, 결과적으로 생성된 데이터베이스에는 너무 많은 지저분한 데이터가 쌓이게 되어 결국 당신이 AI에게 이를 설명해야 하는 상황이 발생할 것입니다. 과도한 범위의 토큰 (Over-scoped tokens). "각 OAuth 권한 부여는 보통 작업에 필요한 것보다 더 광범위합니다 (Drive 전체, Gmail 전체)."

과도한 권한을 가진 커넥터(Over-permissioned connectors)는 데이터 유출의 주요 원인 중 하나입니다." 이 점은 더욱 중요합니다. 왜냐하면 정보와 기능에 대한 무분별한 접근이 어떻게 당신의 파이프라인을 혼돈 상태로 만드는지 설명해주기 때문입니다. 데이터와 동작을 오케스트레이션(Orchestrating)하는 것이 가드레일(guardrails)을 설정하는 핵심입니다. 이는 모델이 채팅을 시작한 본래의 목적에서 벗어나 관련 없는 영역을 탐색하거나 실제 작업을 흐리게 만드는 대신, 주어진 작업에만 집중하도록 유지해 줍니다. 폭발 반경(Blast radius). "탈취된 Claude 계정 하나가 50개의 시스템으로 침투하는 교두보(pivot)가 됩니다." 이 세 가지 중 가장 인용하기 좋은 문구입니다. 오용된 데이터와 잘못 실행된 동작은 여러 플랫폼과 시스템 전반에 걸쳐 영향을 미칩니다. 실수는 프로젝트 내부에만 머물지 않습니다. 일단 복잡한 파이프라인을 실행하게 되면, 연쇄 반응(chain reactions)은 영구적인 위험 요소가 됩니다. 그래서 시간이 흐르며 저는 제가 지키려고 노력하는 몇 가지 규칙을 정립했습니다: 커넥터는 기본적으로 꺼두고, 각 채팅별로 작업에 필요한 것만 활성화할 것. 외부 콘텐츠를 읽어오는 리서치(research) 채팅은 운영 데이터(production data)를 다루는 채팅과 분리할 것. 이 세 가지 요소(trifecta)를 한 세션에 모두 넣지 말 것. 이것이 압도적으로 저렴하고 효과적인 통제 방법입니다. 선택 가능한 경우 어디에서든 읽기 전용 키(read-only keys)를 사용할 것. 되돌릴 수 없거나 외부로 나가는(outbound) 모든 작업에는 수동 승인 게이트(manual approval gate)를 유지할 것. 읽기(reads)를 자동화하는 것은 괜찮지만, 보내기(sends)를 자동화하는 것은 안 됩니다. 분기별 검토: 단순히 Claude에서 토글을 끄는 것에 그치지 말고, 제공자(provider) 측에서 사용하지 않는 권한 부여를 취소할 것. 스테이징(staging) 및 테스트(test) 서버의 이름을 운영(prod) 서버와 혼동되지 않도록 변경할 것 (예: tool-STAGING-do-not-use). 여러분은 이에 대해 어떻게 생각하시는지 궁금합니다. /u/robertgoldenowl 제출 [link] [comments]