회사가 생성형 AI 도입을 추진하면서 각 조직의 활용 담당자가 참여하는 AI Masters 모임을 구성했다. 몇 달간 참여하며 통합 MCP 서버를 소개하고, 다른 조직의 활용 사례와 전사 확산 과정에서 확인한 과제를 정리했다.

AI Masters 모임은 이렇게 진행됐다

여덟 명 남짓이 매주 모였다. 처음 몇 번은 각자 무슨 일을 하고 어떤 고민을 하는지 공유하는 자리였다. 곧 각자 10분 내외로 자기 주제를 발표하는 형식으로 자리를 잡았다.

초기에는 모든 구성원에게 같은 수준의 교육을 제공하기보다, 먼저 활용 중인 구성원의 사례를 정리해 확산하기로 했다. 복잡한 자동화보다는 MCP로 위키 내용을 요약하고 페이지로 등록하는 방법처럼 바로 적용할 수 있는 사례부터 공유했다.

모임 바깥으로는 전사 세미나, AI 자료실(프롬프트 라이브러리·추천 학습자료), 조직별·업무유형별 사례 모음, Q&A 게시판 같은 공간을 만들어 갔다. "AI 활용의 시작" 전사 세미나에는 신청 댓글이 수십 건씩 달릴 만큼 관심이 높았다.

담당한 일 — 통합 MCP 서버 구축과 확산

내가 모임에서 맡은 주제는 사내 통합 MCP 서버 구축·운영 사례였다. CTO 조직의 요구에서 시작해 LLM 코딩 도구를 구현·테스트·문서화 보조에 활용했다. 아키텍처와 권한 모델은 직접 설계하고 운영 책임을 맡았다. 위키·Jira·Bitbucket·Outlook·Teams까지 다섯 개 서비스를 하나의 MCP로 통합했고, 전사 구성원이 사용하는 포털과 실제 기능을 제공하는 MCP API로 구조를 나눴다.

개별 MCP를 각자 붙여 쓰면 보안 문제와 "이걸 누가 운영하느냐"는 모호함이 생기는데, 통합 서버로 그 지점을 정리하려 했다. (권한을 사용자별로 지키는 설계가 이 작업의 가장 어려운 부분이었는데, 그 이야기는 따로 정리했다.)

전사 공지 후 약 90명이 등록했지만 실제 사용자는 그 절반 정도였다. 초기 사용 과정에서 받은 피드백을 반영해 Gemini·ChatGPT 등 클라이언트별 연동 가이드를 작성하고, 마스터 채널로 접수된 기능을 추가했다. 검색과 업데이트 요청이 늘면서 DB 사용량도 증가해 자원 사용량을 지속적으로 확인하고 있다.

남은 과제는 전사 오픈 이후의 운영 주체와 지원 범위를 정하는 일이었다. 기존 업무와 함께 운영을 담당하고 있어 장애 대응, 기능 요청과 사용자 지원을 지속 가능한 형태로 분담할 필요가 있었다.

전사 공개 이후의 기능 요청

공개 이후 마스터 채널과 헬프데스크를 통해 기능 요청과 사용 문의가 이어졌다.

대표적인 사례는 Teams 메시지 기능이었다. 초기 버전은 평문만 지원해 멘션과 링크 정보를 보존하지 못했다. 사용자 요청을 반영해 멘션, 링크, HTML 형식과 Adaptive Card 지원을 순차적으로 추가했다. QA 후 운영 환경에 배포했으며, 이후에는 '모든 사용자'와 같은 특수 멘션 지원 요청도 접수됐다. 사용 범위가 넓어질수록 클라이언트별 예외와 추가 요구사항도 함께 증가했다.

동일한 클라이언트가 macOS에서는 URL과 키만으로 연결됐지만 Windows에서는 실패하는 문제도 있었다. 확인 결과 애플리케이션이 공백이 포함된 실행 경로를 인용 부호 없이 처리하는 것이 원인이었다. 공백이 없는 경로에 wrapper script를 두어 우회했고, 이후 배포 전 Windows 환경 검증을 별도 항목으로 추가했다. 사업 부서의 주요 사용 환경이 Windows였기 때문이다.

동료들에게 배운 것

모임에서는 다른 조직의 활용 사례를 함께 확인할 수 있었다. 같은 회사 안에서도 업무에 따라 AI를 적용하는 방식이 달랐다.

  • 컨텍스트 엔지니어링 — 컨텍스트에 어떤 정보를 포함하고 어떤 순서로 제공하는지가 결과 품질을 좌우한다는 사례가 공유됐다. 생성형 AI 활용을 개별 프롬프트가 아니라 입력 구조 설계의 문제로 이해하는 데 도움이 됐다.
  • 토큰 최적화와 서브 에이전트 — 저가 모델은 지시를 곧잘 잊어버린다. 그래서 플랜은 상위 모델로, 코드 생성은 저가 모델로 나누는 서브 에이전트 구조로 푸는 시도가 오갔다. 요청당 과금 체계에서 "한 번에 최대한 상세히, 원하는 결과가 나올 때까지 멈추지 말라"고 지시해 토큰을 아끼는 노하우도 공유됐다.
  • 업무별 적용 — QA 쪽에서는 기획서(이슈) 기반 테스트 케이스 자동 생성과 테스트 코드 자동화를, 데이터 쪽에서는 분석용 MCP를 붙여 데이터 드리븐 의사결정을 자동화하는 시도가 있었다. 보안 쪽에서는 개인 계정과 사내 도구 사용을 어떻게 구분할지, 폐쇄망에서 어떻게 안전하게 쓸지를 고민했다.

업무 영역은 달랐지만 공통 과제는 토큰 비용, 저가 모델의 성능 한계, 권한·보안 경계와 등록 이후의 실제 사용률이었다.

일부 구성원은 MCP를 이용해 Teams 메시지에 자동 응답하는 봇을 만들었다. 초기에는 봇 메시지에 식별 표식을 붙였지만, 표식이 없는 메시지가 테스트 채널에 게시되면서 작성 주체를 구분하기 어려운 경우가 있었다. 이 사례를 통해 자동 생성 메시지의 표시 기준과 운영 정책도 필요하다는 점을 확인했다.

돌아보며

도구를 구축하는 일과 실제 사용을 확산하는 일은 별개의 과제였다. 약 90명이 등록했지만 실제 사용자는 절반 수준이었고, 기능 추가만으로 사용률이 높아지지는 않았다. 초기 사용자가 바로 적용할 수 있는 사례와 클라이언트별 연동 가이드를 제공하는 방식으로 확산 활동을 진행했다.

기존 업무와 병행해야 했기 때문에 운영 주체와 지원 범위를 정하는 과제가 남았다. 동시에 다른 조직의 적용 사례와 실제 사용자 피드백을 확인하면서, 생성형 AI 활용에는 프롬프트 작성뿐 아니라 요구사항 정의, 입력 정보 구성과 운영 절차가 함께 필요하다는 점을 확인했다.

참고