그만 물어봐! 사내 MCP로 "데이터 민주화" 하기

"이번 달 지원자 몇 명이에요?" 데이터를 보려면 늘 개발자인 저를 거쳐야 했습니다.

마케터나 기획자분이 SQL을 쓸 줄 알아도 마찬가지였습니다. 조직 내 암묵지들 때문에 제대로 된 데이터를 뽑기 어려운 경우가 빈번하게 일어났습니다.
그래서 사내 DB를 AI가 직접 조회하는 MCP 서버를 만들었지만, 조직이 실제로 쓰는 MCP가 되기까지는 생각보다 멀었습니다.
MCP 배포 이후 2주동안 그 거리를 좁히면서 배운 3가지를 공유합니다.

1. MCP 구현

MCP SDK로 만들었습니다. 읽기 전용을 두 겹으로 강제했습니다.

• 앱단: SQL 파서로 단일 SELECT만 통과
• DB단: 계정 자체가 SELECT 권한만 보유

앱 가드를 우회해도 DB가 거부합니다.
다만 서로 다른 RDBMS라 직접적인 크로스 DB 조인은 불가능합니다. 대신 인터페이스를 통일해서 LLM이 두 번 쿼리해 직접 합치도록 했습니다.
MySQL과 PostgreSQL은 생각보다 많이 다릅니다.
커넥션 풀, 드라이버별 응답 형태, 타임아웃과 오류 체계가 전부 달라서 이걸 하나로 추상화하는 게 실제 작업의 대부분이었습니다.

2. 암묵지의 형식지화

조직과 서비스가 커지면 암묵지가 쌓입니다. AI에게는 이걸 초등학생에게 설명하듯 자세히 알려줘야 합니다.
예를 들어 앱스토어 이벤트용 캠페인과 CRM 캠페인은 데이터 구조가 전혀 다른데 둘 다 campaign이라는 이름을 씁니다.
AI는 이걸 구분할 능력이 없습니다. 그래서 데이터를 요청하면 심심찮게 의도하지 않은 결과가 나옵니다.
문제는 에러가 안 난다는 것입니다. 조용히 틀린 숫자가 나옵니다.

• 커밋 시점: Claude Code hooks가 "스키마 바꿨는데 가이드도 고쳤냐"를 확인
• CI 시점: 테스트 가드가 "그 내용이 실제 스키마와 맞냐"를 검증
• 두 층이 짝입니다. 훅은 고쳤는지만, 테스트는 맞는지를 봅니다

도메인 지식을 통째로 주면 컨텍스트를 다 먹습니다. 그래서 맥락을 크기에 따라 대-중-소 목차의 트리 구조로 나눴습니다.
AI가 목차를 먼저 읽고 필요한 절만 골라 열도록 해서, 판별력은 살리고 컨텍스트는 아끼는 구조입니다.

3. 권한 관리

데이터를 여는 일과 개인정보를 지키는 일은 같이 가야 합니다. 개인정보보호법의 통계 작성, 과학적 연구, 기록 보존 목적에 맞춰 해시를 통한 가명화 처리를 했습니다.

• 기본적으로 우리 조직 계정만 허용하고, 그중 admin만 전체를 볼 수 있습니다
• 나머지 구성원은 가명화된 테이블만 조회됩니다
• DB 계정 자체를 분리해서, 앱단에 SQL 인젝션이 들어와도 가명화된 것만 접근 가능합니다

가명 데이터도 개인정보라 GDPR을 준하기 위해 감사 로그를 남깁니다.
모든 호출을 누가 언제 어떻게 어떤 결과를 받았는지 구조화 로그에 기록해 사후 추적이 가능하도록 했습니다.

이제 개발자가 아니어도 직접 묻습니다. 저를 거치지 않아도 됩니다.
만들고 보니 그동안 흐린 눈 했던 도메인 문서화도 함께 해결됐고, 직접 처리하던 가명화도 자동화되었습니다.

사내 데이터를 AI에게 열어보려는 분들께 권합니다. 도구보다 "우리가 아는 것을 정리하는 일"이 먼저였습니다. 궁금하신 분들은 편하게 링크드인 DM 주세요!