새 프로젝트를 열거나 다른 개발 도구로 옮길 때마다 GitHub, 문서 도구, 분석 도구 연결을 다시 설정하는 일은 생각보다 오래 남는다. 서버 주소를 추가하고, OAuth 로그인을 완료하고, API 키를 넣고, 프로젝트별 설정을 맞추는 과정이 반복되기 때문이다.
이 문제를 줄이는 방법은 크게 둘이다. 각 서비스의 MCP 서버를 개발 환경이나 프로젝트에 직접 연결하는 방식, 그리고 서비스 인증과 액션 실행을 중간 계층에 모아 여러 에이전트가 공유하게 하는 중앙화 방식이다.
결론부터 말하면, 연결 수가 많고 개발자들이 여러 클라이언트와 환경을 오간다면 중앙화가 운영 비용을 낮출 가능성이 크다. 그러나 중앙화 서버가 인증 정보, 실행 권한, 서비스 연결 상태를 함께 보관한다면 그 서버는 편의 기능이 아니라 권한 관리의 중심점이 된다. 이 중심점을 관리할 책임과 기능이 없다면, 번거롭더라도 직접 연결이 더 안전한 선택일 수 있다.
비교의 출발점은 “서버 수”가 아니라 “권한이 머무는 곳”이다
직접 연결에서는 에이전트 클라이언트나 프로젝트 설정에 서비스별 MCP 서버를 등록한다. 서비스마다 인증 절차도 따로 진행한다. 이 방식은 연결 구성이 분산되는 대신, 특정 프로젝트와 특정 클라이언트에 필요한 권한만 붙이기 쉽다.
반면 중앙화 방식은 원격 MCP 서버 하나를 에이전트에 등록하고, 그 중앙 서버에서 여러 서비스 계정을 연결하는 구조를 취한다. 예를 들어 Liner Actions는 원격 MCP와 OAuth 2.1 연결을 제공하며, 연결한 서비스 계정의 인증 정보는 Liner가 보관하고 에이전트에 전달하지 않는다고 안내한다. 에이전트는 서비스별 도구 목록을 모두 직접 받는 대신 액션 검색, 실행, 계정 연결, 연결 확인 같은 공통 도구를 호출한다.
여기서 중요한 질문은 “토큰이 에이전트에 보이지 않는가”만이 아니다. 다음을 함께 정해야 한다.
- 중앙 서버에 누가 서비스 계정을 연결할 수 있는가
- 연결된 계정이 어느 프로젝트, 어느 에이전트, 어느 구성원에게 사용 가능한가
- 읽기 작업과 쓰기 작업을 같은 수준으로 허용할 것인가
- 퇴사·직무 변경·외부 협업 종료 때 연결을 누가 해제하는가
- 특정 액션이 실행된 사실을 팀이 나중에 확인할 수 있는가
이 질문에 답하지 못한다면 중앙화는 설정 반복을 줄이는 대신 권한의 위치만 더 불명확하게 만들 수 있다.
직접 연결이 더 맞는 팀과 중앙화가 더 맞는 팀
두 방식을 생산성만으로 비교하면 중앙화 쪽이 항상 좋아 보이기 쉽다. 하지만 연결의 수명과 권한의 성격이 다르면 판단도 달라진다.
| 비교 축 | 서비스별 직접 연결 | 인증·액션 중앙화 |
|---|---|---|
| 새 프로젝트 설정 | 서비스별 서버와 인증을 다시 확인해야 할 수 있음 | 중앙 서버를 연결한 뒤 기존 서비스 계정을 재사용하기 쉬움 |
| 다른 에이전트로 이동 | 클라이언트별 설정 차이를 다시 처리할 수 있음 | 원격 MCP와 계정 연결이 공유되면 이동 부담이 줄어듦 |
| 권한 범위 | 프로젝트별로 좁게 나누기 쉬움 | 여러 환경에서 재사용되는 계정 권한이 넓어질 수 있음 |
| 장애·문제 원인 추적 | 서비스와 클라이언트별로 나뉨 | 중앙 서버, 서비스 계정, 에이전트 중 어디에서 막혔는지 구분해야 함 |
| 공급자 의존성 | 서비스별 MCP 또는 클라이언트 지원 여부에 영향받음 | 중앙 서버의 가용성, 지원 서비스, 인증 정책에도 영향받음 |
| 퇴출과 정리 | 프로젝트 설정과 개인 환경을 각각 정리해야 할 수 있음 | 계정 연결 관리 화면에서 일괄 해제가 가능할 수 있으나, 권한 범위를 먼저 확인해야 함 |
직접 연결은 다음 조건에서 더 적합하다. 특정 프로젝트만 민감한 운영 시스템에 접근하고, 팀이 서비스 계정을 공유하지 않으며, 권한을 좁은 범위로 분리하는 일이 설정 편의보다 중요할 때다. 예를 들어 배포 승인, 고객 데이터 수정, 결제 변경처럼 잘못된 실행의 영향이 큰 액션은 공용 연결에 얹기 전에 별도 경로를 유지하는 편이 낫다.
중앙화는 여러 저장소, 여러 기기, 여러 AI 클라이언트를 넘나드는 팀에 더 잘 맞는다. 다만 이 경우에도 “모든 서비스 연결을 한곳으로 옮긴다”보다 “재사용 가치가 큰 읽기 중심 연결부터 묶는다”는 순서가 현실적이다. 이슈 조회, 문서 검색, 분석 지표 조회처럼 결과를 사람이 검토할 수 있는 작업과, 티켓 생성·권한 변경·외부 발송처럼 상태를 바꾸는 작업을 같은 방식으로 열어 두면 안 된다.
중앙화의 실패는 인증보다 권한 모델에서 먼저 드러난다
중앙화 도입 초기에 흔히 보이는 문제는 로그인 실패다. 그러나 운영 단계에서 더 큰 문제는 연결은 성공했지만 누가 무엇을 할 수 있는지 팀이 설명하지 못하는 상태다.
다음 신호가 보이면 중앙화 범위를 넓히기 전에 멈춰야 한다.
첫째, 개인 계정으로 연결한 서비스가 팀 공용 자동화에 쓰이기 시작할 때다. 이 경우 담당자가 바뀌면 연결의 소유권과 해제 책임이 불분명해진다.
둘째, 에이전트가 검색한 액션의 실제 권한 범위를 사람이 알기 어려울 때다. 중앙화 방식은 자연어 요청 뒤에 필요한 액션을 검색하고 실행하는 흐름을 제공할 수 있다. 편리하지만, “문서 요약”처럼 보이는 요청이 어느 문서 공간을 읽는지, “이슈 정리”가 새 이슈 생성까지 포함하는지는 별도로 확인해야 한다.
셋째, 연결 해제 절차가 퇴사·조직 개편 절차에 포함되지 않을 때다. Liner Actions는 연결한 서비스 계정을 Actions Console에서 확인하고 해제할 수 있다고 안내한다. 제품에 관계없이 중앙 연결을 도입한다면, 이런 관리 화면이 있는지보다 누가 정기적으로 연결 목록을 검토할지까지 정해야 한다.
넷째, 인증 만료를 개인의 문제로 취급할 때다. Liner Actions의 안내상 클라이언트 로그인 승인은 30일 뒤 만료될 수 있다. 이런 재인증 요구는 사용자 불편으로만 볼 일이 아니다. 재인증이 필요한 연결, 계속 살아 있는 연결, 이미 불필요한 연결을 구분하는 운영 점검 기회로 삼아야 한다.
읽기와 쓰기를 분리하면 초기 선택이 쉬워진다
CTO나 개발 리드는 중앙화 여부를 한 번에 결정하기보다 액션 유형별로 나누어 판단하는 편이 좋다.
먼저 읽기 작업을 분류한다. 이슈 목록 조회, 문서 검색, 저장소 정보 확인, 분석 데이터 조회처럼 에이전트가 정보를 가져오고 사람이 결과를 검토하는 작업이다. 여러 환경에서 반복해 쓰는 읽기 연결은 중앙화의 이점이 크다. 환경을 바꿔도 같은 서비스 계정을 다시 연결하는 일을 줄일 수 있기 때문이다.
그다음 제한된 쓰기 작업을 고른다. 예를 들어 개인 작업 공간에 초안 이슈를 만들거나, 검토 대기 상태의 문서를 생성하는 작업이다. 이 단계에서는 실행 계정이 누구인지, 생성 위치가 어디인지, 사람이 결과를 되돌릴 수 있는지를 확인해야 한다.
마지막으로 외부 영향이 큰 쓰기 작업을 따로 둔다. 고객 메시지 발송, 운영 데이터 변경, 권한 부여, 배포 관련 작업은 중앙화의 편의와 별개로 승인 절차를 남겨야 한다. 중앙 서버가 자격 증명을 보호한다고 해도, 올바른 사람이 올바른 범위에서 올바른 액션을 실행했다는 문제까지 자동으로 해결하지는 않는다.
제품 검토 회의에서 확인할 질문
중앙화 MCP 제품을 검토할 때는 지원 서비스 수보다 아래 질문에 답할 수 있는지 확인하는 편이 낫다.
- 서비스 계정은 개인 단위, 팀 단위, 프로젝트 단위 중 어떤 단위로 연결되는가?
- 연결한 계정의 권한 범위를 중앙 제품 안에서 확인하거나 줄일 수 있는가?
- 특정 에이전트나 특정 프로젝트만 사용할 수 있게 제한할 수 있는가?
- 읽기와 쓰기 액션을 구분하고, 쓰기 작업에 별도 확인을 요구할 수 있는가?
- 누가 어떤 서비스 연결을 만들고 끊었는지, 어떤 액션이 실행됐는지 확인할 수 있는가?
- 중앙 서버를 사용할 수 없거나 공급자가 지원을 중단할 때, 직접 연결 방식으로 되돌아갈 수 있는가?
- 자연어 검색으로 액션을 찾는 구조라면, 지원 언어와 검색 실패 시 처리 절차는 무엇인가?
Liner Actions의 경우 액션 검색은 영어 질의에서 동작한다고 안내한다. 한국어로 업무를 지시하는 팀이라면 이 제약이 에이전트의 내부 처리에 머무는지, 사용자가 별도 영어 요청을 해야 하는지 사전 검증이 필요하다. 이처럼 작은 제약도 도입 뒤에는 사용성 문제나 운영 문의로 바뀔 수 있다.
중앙화 MCP를 선택한다면 첫 대상은 “여러 환경에서 자주 쓰지만, 잘못 실행돼도 되돌릴 수 있는 읽기 중심 업무”가 적절하다. 그 범위에서 계정 연결, 해제, 재인증, 실행 기록을 팀이 관리할 수 있는지 확인한 뒤에 쓰기 액션을 늘리는 순서가 좋다. 연결을 한 번만 해도 되는 구조보다, 연결을 끊어야 할 때 확실히 끊을 수 있는 구조가 장기 운영에서는 더 중요하다.
