MCP 를 사내 업무에 붙여본 후기

요즘 사내 업무에 MCP 를 하나씩 붙여 쓰고 있다. 거창한 플랫폼을 깐 건 아니다. 평소 하던 일 — 이슈 처리, 빌드와 배포, 문서 정리 — 을 Claude Code 안에서 그대로 끝낼 수 있게, 사내 서비스 몇 개를 MCP 로 감싼 정도다. 한동안 써 보니 생각보다 손에 붙어서, 적용 과정을 가볍게 남겨 둔다.

이슈 처리부터 붙였다

가장 먼저 붙인 건 이슈 관리다. 사내 이슈 관리 시스템의 API 를 MCP 도구로 올렸다. 이슈 번호만 주면 상세와 코멘트를 가져오는 도구다. 여기서 한 걸음 더 가서, 이 도구를 호출만 하는 게 아니라 이슈를 가져와 내용을 분석하고 처리까지 하는 흐름을 스킬에 심었다. 이슈를 읽고, 무엇을 고쳐야 하는지 추려서, 코드를 손보는 데까지 한 번에 이어진다.

빌드하고 테스트하고 배포까지

고쳤으면 내보내야 한다. 빌드해서 개발 서버에 올리고 사용자 테스트를 거친 뒤 배포하는데, 이 배포 준비를 파일 서버(웹하드) MCP 로 처리했다. 산출물을 웹하드에 올리는 도구다.

여기서 신경 쓴 건 권한이다. MCP 는 결국 AI 가 도구를 직접 쥐고 움직이는 구조다. 그러니 기존 배포 시스템을 통째로 만지게 둘 수는 없었다. 그래서 경로별로 권한을 갈랐다. 정식 릴리즈 배포 경로에는 읽기 권한만 줬다 — AI 가 들여다볼 수는 있어도 쓰지는 못한다. 쓰기는 테스트용 QA 전달 경로에만 열어 뒀다. AI 가 파일을 올릴 수 있는 곳은 그 한 곳뿐이다.

이 파일 서버 MCP 는 뜻밖에 재활용됐다. 나중에 다른 서버 라이브러리를 쓴 테스트 서비스를 구축할 때, 같은 MCP 를 그대로 가져다 썼다. 한 번 만들어 둔 도구가 다른 일에서도 쓰이니, 모듈로 둔 보람이 있었다.

배포가 끝나면 이슈에 자동으로 코멘트

배포가 끝나면 이번에 고친 이슈들에 처리 내용과 배포 경로를 남겨야 한다. 손으로 하면 꼭 한둘은 빠뜨린다. 그래서 배포가 완료되는 시점에, 수정한 이슈마다 처리 항목과 배포 경로를 자동으로 코멘트로 달게 했다.

여기서 좋았던 건 코멘트의 재료를 따로 만들지 않아도 된다는 점이다. 작업하는 동안 git 커밋에 과정을 잘게 쪼개 남겨 두니, 무엇을 어떻게 고쳤는지가 커밋 로그에 이미 상세하게 적혀 있다. 처리 내역을 손으로 요약할 필요가 없다. MCP 는 커밋 로그에서 그 내용을 끌어와 이슈에 맞는 말로 옮겨 줄 뿐이다.

그리고 이 점이 예상 밖의 쓸모로 이어졌다. 커밋에서 작업 내역을 뽑아내는 같은 MCP 를, 나중에 스프린트 보고서나 주간 보고서를 쓸 때 그대로 다시 썼다. 한 주 동안 무엇을 했는지는 이미 커밋에 다 남아 있으니, 보고서도 결국 같은 원천에서 자라난다. 한 번 만들어 둔 연결이 보고 업무까지 덜어 준 셈이다.

문서는 위키로

수정 사항은 코드로만 끝나지 않는다. 개발 노트로도 남겨야 다음 사람이 본다. 그래서 사내 위키 MCP 도 하나 만들어, 이번 수정에 대한 개발 노트를 위키에 바로 올리도록 했다.

개발을 하다 보면 늘 같은 데서 막힌다. 코드는 계속 바뀌는데 문서는 그 속도를 못 따라간다. 기능을 손볼 때마다 매뉴얼을 고치고, 개발 노트를 남기고, 릴리즈 노트를 쓰는 일은 언제나 뒤로 밀린다. 코드와 문서가 어긋나는 그 간극이 개발자가 오래 안고 사는 고통이다.

위키 MCP 를 붙이고 나서 그 고통이 대부분 사라졌다. 방금 고친 내용은 커밋과 처리 기록에 이미 다 있으니, 그것을 매뉴얼이나 개발 노트, 릴리즈 노트 형태로 정리해 위키에 올리는 비용이 거의 0 에 수렴했다. 문서를 새로 쓰는 일이 아니라, 이미 한 일을 한 번 더 내보내는 일이 된 것이다. 개발과 문서화가 따로 도는 게 아니라 한 줄기로 이어졌다.

하나로 묶고, 셋으로 나눠 쓴다

정리하면 사내 MCP 서버는 하나의 모듈로 묶여 있다. 그 안에서 이슈 관리, 파일 서버, 위키 세 서비스가 각각 켜고 끌 수 있게 따로 운영된다. 그때그때 필요한 것만 켜서 쓴다.

그리고 이걸 사용자 스코프에 셋업해 두니, 특정 프로젝트가 아니라 모든 프로젝트에서 공통으로 잡힌다. 프로젝트마다 다시 설정할 필요가 없다. 한 번 깔아 두면 어디서든 쓰이니, 앞으로 쓸수록 활용도가 더 커질 것 같다.

다음은 테스트 자동화

여기까지 해 보니 MCP 사용법과 세팅이 어느 정도 손에 익었다. 그러자 다음 욕심이 생긴다. 사내 솔루션의 단위 테스트는 물론, 유저 테스트 영역까지 자동화를 시도해 볼 수 있을 것 같다. 그 이야기는 다음 글에서 따로 풀어 볼 생각이다.