목록으로
업무 생산성 개선을 위한 AI 활용
"이번 달 지원자 몇 명이에요?" 이제 개발자 대신 AI에게 묻습니다
👤 푸른펭귄683 📅 2026-09-29 👁 조회 419
모든 임직원이 개발자 없이 AI에게 직접 묻고 안전하게 사내 데이터를 조회하게 된 사례입니다.
① 어떤 상황에서 AI를 활용했나요?

"이번 달 지원자 몇 명이에요?" 회사에서 데이터 하나를 보려면 늘 개발자인 저를 거쳐야 했습니다. 질문한 사람은 결과를 기다려야 했고, 저는 그때마다 하던 일을 멈춰야 했습니다.

SQL을 쓸 줄 아는 마케터나 기획자분도 사정은 같았습니다. 문제는 도구가 아니라 맥락이었습니다. "이 컬럼은 이런 뜻이고, 이 데이터는 이런 조건으로 걸러야 한다" 같은 조직 안의 암묵지 때문에 직접 뽑은 숫자가 틀리는 일이 잦았습니다. 조회 도구를 하나 더 들여도 그 도구 역시 우리 회사의 암묵지는 모릅니다.

그래서 AI가 사내 DB를 직접 조회하는 MCP 서버를 만들었습니다. 하지만 만든 것과 조직이 믿고 쓰는 것 사이에는 큰 거리가 있었고, 이 글은 그 거리를 좁혀 간 기록입니다.


② 어떤 AI를 어떻게 활용했나요?

MCP는 Claude 같은 AI가 외부 데이터에 접근하도록 연결하는 표준 규격입니다. MCP SDK로 사내 DB 조회 서버를 만들어, 구성원이 Claude에게 평소 말투로 물으면 AI가 쿼리를 작성해 실행하고 결과를 정리해 답하도록 했습니다.

사내에서는 MySQL과 PostgreSQL을 함께 씁니다. 서로 다른 DB라 한 번에 합쳐 조회할 수 없어서, 조회 방식을 하나로 통일하고 AI가 각각 조회한 뒤 결과를 합치게 했습니다. 두 DB의 연결 방식, 응답 형태, 오류 체계가 모두 달라 이를 하나로 감싸는 작업이 개발의 대부분이었습니다.

더 큰 과제는 AI에게 조직의 맥락을 가르치는 일이었습니다. 우리 회사의 앱스토어 이벤트 캠페인과 CRM 캠페인은 구조가 전혀 다르지만 둘 다 campaign이라는 이름을 씁니다. AI는 이를 구분하지 못하고, 무서운 점은 에러 없이 조용히 틀린 숫자를 낸다는 것입니다.

그래서 오늘 처음 입사한 분께 온보딩하듯, 당연하다고 여겼던 것까지 하나하나 풀어 쓴 도메인 가이드를 만들었습니다. 다만 전부 한 번에 넣으면 AI의 기억 용량(컨텍스트)을 다 써버리기 때문에, 가이드를 대·중·소 목차의 트리 구조로 나누고 AI가 목차를 먼저 읽은 뒤 필요한 부분만 열어보게 했습니다. AI는 조회를 맡고, 저는 AI를 우리 조직에 온보딩시키는 역할을 맡았습니다.


③ 활용 결과 어떤 변화가 있었나요?

★ 전사 도입
지금은 모든 임직원이 씁니다. "개발자에게 요청 → 확인 → 쿼리 작성 → 결과 전달" 네 단계가 "AI에게 질문 1회"로 줄었습니다.

★ 동료들의 반응
"이제 개발자한테 안 물어보고 바로 데이터 뽑을 수 있어서 너무 편해요."
→ 제게 오던 데이터 요청이 사라졌고, 저도 본래 업무에 집중하게 되었습니다.

"이거 왜 익명으로 나와요?"
→ 권한 없는 직원분의 질문입니다. 개인정보가 설계대로 가명 처리된다는 것을 실제 사용자의 질문으로 확인했습니다.

★ 예상 밖의 활용
한 직원분은 이 MCP를 자신의 AI 에이전트에 연결해 매일 보고서를 자동으로 뽑고 있습니다. 질문에 답하는 창구로 만들었는데, 구성원이 업무 자동화의 부품으로 바꿔 쓴 것입니다.

덤으로 미뤄왔던 도메인 문서화가 해결되었고, 요청마다 손으로 하던 가명화 작업도 자동화되었습니다.


④ 나만의 방식 또는 개선 포인트는 무엇인가요?

▶ 하나 · 읽기 전용을 두 겹으로 강제했습니다
서버에서는 SQL 해석기로 조회(SELECT)문만 통과시키고, DB에서는 계정 자체에 조회 권한만 줬습니다. 서버 방어를 우회해도 DB가 한 번 더 막기 때문에, AI가 어떤 쿼리를 만들든 데이터가 바뀔 일은 없습니다.

▶ 둘 · '조용히 틀린 숫자'를 이중으로 막았습니다
DB 구조가 바뀌었는데 가이드가 그대로면 AI는 다시 조용히 틀립니다. 그래서 코드 저장(커밋) 시점에는 Claude Code hooks가 "DB를 바꿨는데 가이드도 고쳤나요?"를 확인하고, 배포 전 자동 테스트(CI)에서는 가이드가 실제 DB 구조와 맞는지 검증합니다. 앞은 고쳤는지를, 뒤는 맞게 고쳤는지를 봅니다.

▶ 셋 · 개인정보는 '권한'이 아니라 '구조'로 지켰습니다
개인정보보호법의 통계 작성, 과학적 연구, 공익적 기록 보존 목적에 맞춰 해시로 가명화했습니다. 관리자만 전체를 보고, 나머지 구성원은 DB 계정 자체가 가명 테이블만 볼 수 있어 SQL 인젝션이 들어와도 가명 데이터에만 닿습니다. 가명 데이터도 개인정보이므로 GDPR에 준해 누가 언제 무엇을 조회했는지 모든 호출을 감사 로그로 남깁니다.


⑤ 다른 사람도 따라 할 수 있나요?

네. MCP SDK는 무료이고 AI는 구독료 수준이면 충분합니다. 순서만 지키면 됩니다.

1) 조회 권한만 가진 DB 계정부터 만든다. 안전장치가 먼저여야 마음 놓고 열 수 있습니다.
2) "이름은 같은데 뜻이 다른 것"부터 찾아 목차형 가이드로 정리한다. 그곳이 AI가 조용히 틀리는 자리입니다.
3) 가이드와 DB가 어긋나지 않게 기계로 검사한다. 사람의 성실함에 맡기면 샙니다.
4) 개인정보는 가명화, 계정 분리, 감사 로그를 처음부터 함께 설계한다.
5) 그리고 진짜로 열어서 쓰게 한다. 쓰기 시작하면 만든 사람이 상상하지 못한 활용이 나옵니다.

▶ 솔직한 한계
AI는 가이드에 없는 것을 모른다고 잘 말하지 않아서, 가이드의 품질이 곧 답의 품질이 됩니다. 서로 다른 DB를 합치는 복잡한 분석은 결과를 한 번 더 확인하는 게 좋습니다.

사내 데이터를 AI에게 열어보려는 분들께, 도구보다 "우리가 이미 아는 것을 정리하는 일"이 먼저였다는 말을 전하고 싶습니다. AI는 우리가 가르쳐 준 만큼만 정확해집니다.
📎 첨부파일 (1)
📄 1788141824941.jpeg
← 목록