구성 드리프트 문제
한 명의 개발자가 MCP 서버를 설정하면, 그 분이 좋아하시는 방식대로 정확히 구성하셨기 때문에 모든 것이 동작합니다. 열 명의 개발자가 같은 서버를 설정하면 약간씩 다른 열 가지 구성이 생깁니다. 다른 데이터베이스 자격 증명, 다른 파일 접근 경로, 다른 환경 변수가 됩니다. 그리고 무언가 깨질 때 "내 머신에서는 동작하는데"가 새로운 차원으로 다가옵니다.
저희는 이것을 어렵게 배웠습니다. 한 팀원의 데이터베이스 MCP 서버가 테스트 데이터베이스를 가리키고 있는데 다른 모든 사람의 서버는 스테이징을 가리키고 있었습니다. 그분이 Claude로 생성하던 보고서는 옳아 보였지만 완전히 다른 숫자였습니다. 분석이 계속 서로 모순되는 이유를 알아내는 데 이틀이 걸렸습니다.
구성 표준화하기
해결책은 공유 구성 템플릿을 만드는 것이었습니다. 저희는 팀이 사용해야 할 모든 서버, 환경 변수 자리표시자, 각 설정을 설명하는 주석이 담긴 claude_desktop_config.example.json을 프로젝트 저장소에 두었습니다. 신규 팀원은 이 템플릿을 복사하시고 자격 증명을 채우십니다.
이것이 드리프트를 완전히 없애지는 못합니다(사람들은 여전히 커스터마이즈하십니다). 그러나 모두에게 같은 출발점을 줍니다. 무언가 잘못되면, 템플릿과 비교하는 것이 첫 디버깅 단계가 됩니다.
보안 조율 도전
팀원마다 다른 접근 수준을 갖습니다. 주니어 개발자가 시니어 엔지니어와 같은 데이터베이스 권한을 가져서는 안 됩니다. 그러나 모두가 같은 MCP 서버 구성을 사용하면, 모두가 같은 접근을 받습니다. 저희는 별도의 구성 프로파일을 만드는 데 이르렀고(대부분에게는 읽기 전용, 필요한 분께는 읽기-쓰기), 각 등급마다 다른 데이터베이스 자격 증명을 사용했습니다.
API key 관리도 팀에서는 지저분해집니다. 공유 API key는 공유된 속도 제한을 의미하고 누가 어떤 요청을 했는지에 대한 감사 추적이 없음을 의미합니다. 개별 키는 책임 추적에는 더 좋지만, 사람이 합류하고 떠날 때 관리가 더 어렵습니다. 저희는 각자의 로컬 환경에 저장되고 절대 저장소에 커밋되지 않는 개별 키로 정착했습니다.
잘 동작한 것
조율 부담에도 불구하고, 팀 전체의 MCP 도입은 가치가 있었습니다. 가장 큰 이점은 공유된 어휘였습니다. 모두가 Claude에게 같은 데이터베이스를 쿼리하고 같은 코드베이스를 읽으라고 요청하실 수 있으면, 지식 공유가 문서가 아니라 대화로 이루어집니다. "Claude에게 사용자 인증 흐름을 보여 달라고 요청하세요"가 정당한 온보딩 지시가 되었습니다.
코드 리뷰도 좋아졌습니다. 리뷰어는 Claude에게 변경된 파일을 읽고 수정 사항을 설명해 달라고 요청하실 수 있었고, 개발자가 코드를 작성하면서 사용한 같은 파일 시스템 MCP 서버를 사용하셨습니다. 이 공유된 도구 컨텍스트는 리뷰를 더 빠르고 일관되게 만들었습니다.