AI에게 사내 DB를 물려본 MCP 도입기

게시 2026/08/17 업데이트 2026/08/18

By DAN

“AI가 우리 DB를 직접 보게 하면 어떨까?” 하는 궁금증에서 시작한 실전 기록입니다. 사내 시스템 프로젝트에 DB 조회용 MCP 서버를 붙여보고, MCP가 뭔지부터 실제 활용처, 그리고 Oracle 구성 방법까지 정리했습니다.

TL;DR

MCP는 AI에게 DB·파일·API 같은 실제 시스템을 표준 규격으로 열어주는 프로토콜입니다.
계기는 AI 기반 레거시 현대화 프로젝트에서 수행업체가 MCP를 쓰는 걸 보고, 제 프로젝트에도 입혀본 것.
처음엔 단위테스트 시나리오 작성 하나만 떠올랐는데, 쓰다 보니 현대화 작업 곳곳에 쓸 데가 많았습니다.
Oracle에 붙일 땐 접속 방식(thin / thick) 을 먼저 확인하세요. thick(OCI)이면 Oracle Instant Client가 필요합니다.
설정 파일도 직접 짜지 않고 Kiro에게 시켜서 만들었습니다. (에러도 메시지만 그대로 던져서 해결)
결국 조회 전용 서버를 직접 만들었고, thin 접속 실패(구형 verifier) → thick 전환, 접속 문자열 파싱(SID vs service), Kiro 등록 위치(.kiro/settings/mcp.json) 같은 실전 함정을 4장에 정리했습니다.
반드시 read-only 계정 + 별도 인스턴스로. 접속 정보와 실제 스키마는 외부에 노출하지 마세요.

1. 도입 배경

요즘 AI를 활용한 사내 레거시 시스템 현대화 프로젝트를 수행 중입니다. 그 과정에서 수행업체가 현대화 작업에 MCP(Model Context Protocol) 서버를 만들어 쓰는 걸 봤는데, 이게 꽤 인상적이었습니다.

“이거, 제가 관리하는 사내 시스템 프로젝트에도 입혀보면 어떨까?”

그렇게 시작해서 우리 프로젝트에도 MCP 서버를 하나 붙였습니다. 용도는 단순합니다. AI가 사내 DB에 직접 붙어서 스키마와 실제 데이터를 조회할 수 있게 하는 것이죠.

처음엔 “그래서 이걸 어디다 쓰지?” 싶었습니다. 제일 먼저 떠오른 건 단위테스트 시나리오 작성 하나뿐이었는데, 막상 써보니 현대화 프로젝트에서 써먹을 데가 생각보다 많았습니다.

2. MCP란?

MCP는 한마디로 AI에게 외부 도구·데이터 접근 권한을 표준화된 방식으로 열어주는 프로토콜입니다. 2024년 11월 Anthropic이 공개한 뒤로, LLM을 외부 데이터·도구와 연결하는 사실상의 표준으로 빠르게 자리 잡았습니다.

기존에는 AI가 제 코드나 제가 붙여넣은 텍스트만 볼 수 있었다면, MCP 서버를 붙이면 AI가 DB, 파일시스템, 사내 API 같은 실제 시스템과 정해진 규격으로 대화할 수 있게 됩니다.

핵심 개념은 세 가지입니다.

MCP 클라이언트 : AI 에이전트(Claude, Cursor, Copilot 등)
MCP 서버 : 특정 시스템(DB 등)을 도구로 노출해주는 중간 계층
프로토콜 : 이 둘이 대화하는 표준 규격

이번 케이스에서는 “DB 조회용 MCP 서버”를 붙였습니다. 구성은 대략 이런 모양입니다.

[ AI 에이전트 ]  ← MCP 클라이언트
        │  (MCP 프로토콜)
        ▼
[ DB MCP 서버 ]  ── read-only 계정 ──▶ [ 사내 DB (전용 DB / 복제본) ]

여기서 중요한 건, AI에게 DB 계정 정보를 직접 쥐여주는 게 아니라 MCP 서버를 사이에 두고 정해진 도구(스키마 조회, 쿼리 실행 등)만 호출하게 한다는 점입니다. 이 중간 계층 덕분에 권한·로깅 같은 안전장치를 걸 수 있습니다.

3. MCP 활용 사례

3-1. 단위테스트 시나리오 작성

가장 체감이 컸던 활용처입니다. 단위테스트를 짤 때 제일 귀찮은 건 로직 자체보다 “이 필드에 실제로 어떤 값이 들어오는가” 를 파악하는 일이었습니다.

이 컬럼은 nullable인가?
코드값은 실제로 어떤 것들이 쓰이나? ('Y'/'N'? '01'/'02'? 대소문자?)
날짜 포맷은? 문자열인가 timestamp인가?
경계값(최댓값, 빈 값, 이상치)은 실제로 존재하나?

여태는 이걸 DB 콘솔 열어서 직접 쿼리 돌려보고, 그 결과를 다시 테스트 코드로 옮기는 수작업이었습니다. MCP를 붙이면 이 과정을 AI가 실제 DB를 조회하면서 대신 해줍니다.

예를 들어 회원 등급 산정 로직을 테스트한다고 하죠. AI에게 이렇게 요청합니다.

member 테이블 스키마를 확인하고, grade 산정에 쓰이는 컬럼들의
실제 값 분포를 조회해서 단위테스트 시나리오를 만들어줘.

그러면 AI는 MCP를 통해 대략 이런 흐름으로 움직입니다.

스키마 조회 — 컬럼 타입/제약조건 확인

  
SELECT column_name, data_type, nullable
FROM user_tab_columns
WHERE table_name = 'MEMBER';

값 분포 조회 — 실제로 어떤 값이 들어있는지 확인
1 SELECT grade_code, COUNT(*) FROM member GROUP BY grade_code;
결과 예시(가상):
grade_code count
NORMAL 12040
VIP 860
DORMANT 315
null 12
경계값/이상치 확인 — null이 12건이나 있다는 걸 발견
시나리오 도출 — 위 정보를 근거로 테스트 케이스를 뽑아줍니다.

grade_code	count
`NORMAL`	12040
`VIP`	860
`DORMANT`	315
`null`	12

나온 결과(예시):

  
@Test
void 등급코드_null_방어() {
    // 실 DB에 grade_code = null 12건 존재 → 반드시 방어 필요
    Member m = memberOf(null, 0, 0);
    assertThrows(InvalidGradeException.class, () -> service.calculate(m));
}

grade_code = null 같은 케이스는 실제 데이터를 보지 않으면 놓치기 쉬운데, AI가 실 DB를 조회했기 때문에 “12건 존재하니 방어 로직이 필요하다”고 근거를 들어 테스트를 만들어줬습니다.

3-2. 레거시 쿼리/프로시저 현대화

현대화의 핵심은 결국 Oracle 프로시저나 거대한 SQL에 박혀 있는 비즈니스 로직을 애플리케이션 계층(Java/Spring 등)으로 걷어내는 것입니다. 제일 위험한 건 “이 프로시저가 실제로 어떤 데이터를 어떻게 다루는가”를 잘못 이해하는 것인데, 코드만 봐서는 안 보입니다.

SP_CALC_SETTLEMENT 프로시저 로직을 분석하고, 참조하는 테이블의 실제 값을
확인해서 Java 서비스 코드로 이관해줘. 이관 전후 결과가 같은지 검증 쿼리도 만들어줘.

AI가 프로시저 로직 + 실제 데이터를 같이 보고, 이관 후 “기존 프로시저 결과 vs 신규 Java 로직 결과”를 대조하는 검증 쿼리까지 만들어줍니다. “코드는 이관했는데 결과가 미묘하게 다른” 사고를 데이터로 막을 수 있습니다.

3-3. 쿼리 성능 튜닝

레거시엔 20초씩 걸리는 악성 쿼리가 꼭 있습니다. 튜닝의 시작인 실행계획 분석을 AI가 직접 돌려보게 할 수 있습니다.

  
EXPLAIN PLAN FOR
SELECT ... FROM orders o JOIN member m ON ...;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

AI가 실행계획에서 Full Scan 구간, 잘못 타는 인덱스, 실제 row 수를 보고 인덱스 추가나 쿼리 재작성을 제안합니다. 추측이 아니라 실제 통계 기반이라 훨씬 신뢰가 갑니다.

3-4. 데이터 마이그레이션 / 정합성 검증

이기종 DB 전환(예: Oracle → 오픈소스 DB)에서는 원천과 타겟 데이터가 진짜 같은가를 검증하는 게 일입니다. MCP로 양쪽 DB를 붙이면 AI가 건수·합계·체크섬 비교, 타입 변환 과정에서 깨진 값(날짜 포맷, 인코딩, 소수점) 탐지, 스키마 매핑표 초안 작성을 자동화해줍니다.

3-5. 테스트/개발용 시드 데이터 생성

AI가 실 DB의 값 분포(코드값 비율, 길이, null 비율)를 조회한 뒤 그 분포를 닮은 가짜 데이터 INSERT 스크립트를 만들어줍니다. 물론 개인정보는 마스킹/합성값으로요.

3-6. 스키마 문서화와 온보딩

레거시의 가장 큰 벽은 “이 테이블이 뭐 하는 건지 아무도 모른다”는 것입니다. AI가 실제 스키마 + 데이터 + 참조 관계를 훑어서 테이블 명세서, ERD 초안, 컬럼 설명을 만들어줍니다. 신규 인원 온보딩이나 현행화 문서 작업에 특히 유용했습니다.

3-7. 운영 이슈 재현과 원인 분석

“특정 고객만 정산이 틀리게 나온다” 같은 이슈가 들어오면 결국 해당 데이터를 조회해서 케이스를 재현해야 합니다. AI에게 증상을 설명하면 관련 데이터를 조회해 의심 케이스(경계값, 예외 코드값)를 좁혀주고, 재현용 테스트 케이스까지 이어서 만들 수 있습니다.

정리하면, MCP + DB는 “AI가 코드를 잘 짠다”를 넘어 AI가 우리 시스템의 실제 상태를 근거로 판단한다는 게 핵심입니다.

4. Oracle MCP 서버, 이렇게 붙였습니다

여기서부터는 제가 실제로 붙이면서 겪은 걸 시간순으로 풉니다. 결론부터 말하면, 범용 서버를 그대로 쓰는 대신 조회(SELECT) 전용을 확실히 보장하는 작은 MCP 서버를 직접 만들었고, 그 과정에서 접속 방식(thin/thick), 접속 문자열 파싱, Kiro 등록 위치 같은 함정을 줄줄이 밟았습니다.

그리고 이 서버, 제가 직접 손으로 다 짠 건 아닙니다. 개발 툴로 쓰는 Kiro에게 “이렇게 붙여줘”라고 시켜서 만들었어요. 그래서 중간중간 제가 실제로 던진 프롬프트도 같이 적어뒀는데, 보시면 알겠지만 딱히 정제된 문장이 아닙니다. 안 되면 툭 던지고, 에러가 나면 메시지만 그대로 붙여넣는 수준이었어요.

⚠️ 접속 정보나 비밀번호는 AI 채팅창에 붙여넣지 마세요. 그리고 아래 내용도 실제 접속 정보(호스트/포트/SID/계정)는 전부 빼고 재사용 가능한 교훈만 남겼습니다. 접속 정보는 환경변수나 시크릿 저장소에 두고, 프롬프트에는 “환경변수로 받게 해줘” 정도로만 말하면 됩니다.

4-1. 사전 조사와 스택 결정

무작정 붙이기 전에 프로젝트부터 뒤졌습니다.

프로젝트 설정에서 접속 정보를 찾아 개발(dev) 프로파일 기준으로 붙이기로 했습니다.
접속 URL을 보니 앞에 SQL 로깅용 래퍼 접두어(log4jdbc:)가 붙어 있었습니다. 실제 접속 URL만 남기려면 이 접두어부터 떼야 했어요.
URL 끝이 콜론(...:이름)이면 SID, 슬래시(.../이름)면 service name입니다. 이 구분에 따라 DSN을 Easy Connect가 아니라 커넥트 디스크립터 (CONNECT_DATA=(SID=...)) 형태로 짜야 접속됩니다. 이걸 몰라서 한참 헤맸습니다.
런타임은 Node.js와 Python이 둘 다 깔려 있었습니다. (프로젝트 자체는 Java/Maven)

스택은 Node.js로 정했습니다. 이유는 단순합니다.

oracledb가 기본이 thin 모드라 처음엔 Instant Client 없이 될 줄 알았고,
공식 @modelcontextprotocol/sdk + oracledb 딱 두 패키지만 설치하면 끝나서 개발자별 배포가 간단했거든요.

(뒤에 나오지만, “thin이라 클라이언트 필요 없겠지”라는 이 판단은 보기 좋게 빗나갑니다.)

4-2. 조회 전용 서버 직접 구현

목표가 명확했습니다. 조회(SELECT)만 되게 하고, 데이터 변경은 원천 차단, 크리덴셜은 코드에 하드코딩 금지, 각 개발자가 자기 로컬에서 stdio 방식으로 실행. 그래서 패키지 두 개(oracledb + 공식 @modelcontextprotocol/sdk)만 쓰는 작은 서버를 만들고, 도구는 딱 세 개만 노출했습니다.

run_query(sql) — SELECT/WITH 단일문만 허용, 결과를 텍스트 표로 반환
list_tables(owner?) — owner가 없으면 현재 스키마, 있으면 해당 스키마의 테이블 목록
describe_table(table_name, owner?) — 컬럼명 / 타입 / 길이 / NULL 여부

SDK도 zod 같은 의존성을 줄이려고 low-level Server API + JSON Schema로 짰고, 검증 함수는 export하고 main()은 직접 실행할 때만 뜨도록 가드해서 단위 테스트가 가능하게 했습니다.

4-3. “읽기 전용”을 계정 권한에만 맡기지 않았다

계정 자체도 read-only지만, 서버 코드에서도 다층으로 막았습니다. 계정 권한 하나만 믿기엔 불안했거든요.

SELECT / WITH로 시작하는 단일 문장만 허용
주석(--, /* */)을 먼저 제거한 뒤 금지 키워드 차단 (INSERT / UPDATE / DELETE / MERGE / DROP / ALTER / CREATE / TRUNCATE / GRANT / REVOKE / COMMIT / ROLLBACK / CALL / BEGIN / DECLARE 등)
세미콜론 다중문 차단 (맨 끝 세미콜론 1개만 허용)
결과 100행 상한, 초과 시 잘림 안내 / 쿼리 타임아웃 30초
로그는 전부 stderr로. stdio MCP에서 stdout은 JSON-RPC 채널이라 거기에 로그를 찍으면 프로토콜이 깨집니다. (초보자가 자주 밟는 지뢰)

주석을 먼저 없애는 게 포인트입니다. /* update */ SELECT ...처럼 주석으로 키워드 검사를 속이는 걸 막으려고요.

4-4. 진짜 복병: thin 접속 실패 → thick 전환

여기서 이 글의 최대 걸림돌을 만났습니다. Oracle은 크게 두 방식으로 붙습니다.

thin 모드: 순수 드라이버가 TCP로 DB에 직접 접속. Oracle 클라이언트 설치 불필요.
thick 모드(OCI): Oracle 네이티브 라이브러리(OCI)를 거쳐 접속. Oracle Instant Client 필요.

node-oracledb는 6.x부터 thin이 기본이라 “Instant Client 없이 바로 되겠지” 했는데, 로그인 단계에서 막혔습니다.

NJS-116: password verifier type 0x... is not supported by
node-oracledb in Thin mode

원인은 코드가 아니라 DB 계정 설정이었습니다. 이 계정의 비밀번호 verifier가 구형이라, 순수 JS(thin) 드라이버가 로그인을 아예 거부한 거죠.

해결은 thick 모드 전환. 시스템에 있던 Oracle Instant Client를 찾아 붙이니 접속됐습니다. Windows 기준으로 제가 밟은 준비 과정은 이랬어요.

Oracle Instant Client의 Windows x64 Basic 패키지를 받아 압축 해제
그 경로를 서버 설정(ORACLE_CLIENT_LIB_DIR)이나 시스템 PATH에 지정
Microsoft Visual C++ 재배포 패키지 설치 — 이게 없으면 DLL 로드에 실패합니다

이 과정에서 DPI-1047: Cannot locate a 64-bit Oracle Client library도 만났는데, 저는 뜻을 몰라서 그냥 에러 메시지만 Kiro에게 그대로 던졌습니다.

mcp 붙였는데 이 에러가 나. DPI-1047: Cannot locate a 64-bit Oracle Client library

Kiro가 “Instant Client를 못 찾는 것”이라며 위 (1)~(3)을 순서대로 짚어줬고, 그대로 하니 붙었습니다. (경로가 PATH에 없거나, VC++ 재배포 패키지가 없거나, 32/64비트가 안 맞을 때 주로 납니다.)

정리하면 두 에러는 층위가 다릅니다.

NJS-116 — thin으론 이 계정에 로그인 자체가 안 되는 근본 문제 (→ thick 필수)
DPI-1047 — thick으로 가려는데 클라이언트를 못 찾는 문제 (→ 경로/재배포팩)

결론: 구형 verifier를 쓰는 DB는 로컬에서 붙이려면 Instant Client(thick)가 사실상 필수입니다. 그게 싫으면 DBA가 계정 비밀번호를 재설정해 thin 호환 verifier로 바꿔야 하는데, 이건 별도 협의가 필요합니다. Instant Client 경로는 환경변수로 넘겼고, 개발자마다 경로가 다르므로 특정 폴더를 팀 공유 설정에 박아넣지 않았습니다.

4-5. Kiro에 등록하기

설정 파일(mcpServers 형태의 JSON)도 직접 편집하는 대신 Kiro에게 말로 시켰습니다.

Node 기반 Oracle MCP 서버를 우리 프로젝트에 붙이고 싶어.
Windows 환경이고, 접속 정보는 코드에 박지 말고 환경변수로 받게 mcp 설정 만들어줘.

그러면 대략 이런 형태를 만들어줍니다. (접속 정보와 Instant Client 경로를 환경변수로 넘김)

  
{
  "mcpServers": {
    "oracle-readonly": {
      "command": "node",
      "args": ["./.kiro/mcp/oracle-readonly/server.js"],
      "env": {
        "ORACLE_USER": "readonly_user",
        "ORACLE_PASSWORD": "${DB_PW}",
        "ORACLE_DSN": "${DB_DSN}",
        "ORACLE_CLIENT_LIB_DIR": "${IC_DIR}"
      },
      "autoApprove": ["list_tables", "describe_table"]
    }
  }
}

Windows 경로는 JSON에서 역슬래시를 \\ 로 이스케이프해야 합니다.
크리덴셜은 값을 박지 말고 환경변수(${...})로 참조하게 두세요.

그런데 서버는 다 만들었는데, 정작 Kiro에 등록하는 데서 또 걸렸습니다.

파일 위치와 이름: 루트의 .mcp.json이 아니라 .kiro/settings/mcp.json을 읽습니다. 파일명도 점 없는 mcp.json이어야 하고, .mcp.json은 인식되지 않았습니다.
쓰기 권한: .kiro/settings/는 워크스페이스 보안 규칙상 에이전트가 직접 쓰지 못합니다. 그래서 가드를 우회하지 않고, 크리덴셜과 경로를 뺀 템플릿(.mcp.json.example)만 만들어두고 사용자가 직접 배치하게 했습니다.
autoApprove 설계: 부담이 적은 list_tables, describe_table만 자동 승인하고, run_query는 매 호출마다 사용자 승인을 받도록 의도적으로 제외했습니다.

4-6. 검증: 가드 단위 테스트 + stdio end-to-end

“읽기 전용”을 말로만 주장하지 않으려고 테스트를 붙였습니다.

가드 / URL 파서 단위 테스트: 허용(SELECT/WITH)과 차단(UPDATE/DELETE/DROP/ 다중문/PL-SQL) 케이스를 전부 통과하는지 확인
--test-connection CLI 모드: DB 왕복과 표 포맷 확인
MCP 프로토콜(stdio) end-to-end: 서버를 실제로 띄워 도구 목록 조회, list_tables 실데이터, run_query, 그리고 UPDATE가 isError로 막히는지까지 확인

4-7. 배운 점 요약

접속 문자열: 로깅 래퍼 제거 + SID(콜론) vs service(슬래시) 구분이 DSN 구성을 가른다
oracledb는 thin이 기본이지만, 구형 verifier DB는 thick(Instant Client)이 사실상 필수
stdio MCP는 stdout 오염 금지 (로그는 stderr로)
Kiro 등록은 .kiro/settings/mcp.json의 위치와 파일명이 정확해야 한다
안전장치는 “주석 제거 후 검사 + 단일문 강제 + 행 상한”의 다층 방어로
보안 가드가 막은 경로는 우회하지 않고 사용자 안내로 처리한다

5. 안전하게 쓰기 위한 원칙

편하다고 아무 DB나 물리면 안 됩니다. 실제로 지킨 원칙들입니다.

운영 DB 직결 금지 — 전용 분석 DB나 복제본, 마스킹된 스테이징 DB에만 연결했습니다.
read-only 계정만 사용 — MCP 계정에 INSERT/UPDATE/DELETE 권한을 아예 주지 않았습니다.
개인정보/민감정보 마스킹 — 이름, 연락처 등은 마스킹된 뷰로만 노출했습니다.
접속 정보는 환경변수/시크릿 저장소로 — 설정 JSON이나 채팅창에 평문으로 남기지 않았습니다.
쿼리 로깅 — AI가 어떤 쿼리를 날렸는지 감사 로그로 추적 가능하게 했습니다.
외부 유출 주의 — 조회 결과나 실제 스키마를 외부(블로그 포함!)로 흘리지 않도록 경계했습니다.

특히 마지막 항목이 중요합니다. 이런 내용을 블로그처럼 외부에 공유할 때는 실제 테이블명·컬럼명·데이터가 새어나가지 않는지 반드시 확인해야 합니다. 그래서 이 글의 예시도 전부 가상으로 바꿔서 썼습니다.

6. DB 말고 또 어디에 쓸까

DB에 붙여보고 나니 한 가지 패턴이 보였습니다. “사람이 콘솔이나 대시보드를 열어서 조회하고, 그 결과를 다시 AI에게 복붙하던 왕복”이 있는 곳이면 전부 MCP 후보라는 것이죠. 앞의 DB 사례에서 “DB 콘솔과 에디터 사이 왕복을 없앴다”고 한 것과 똑같은 논리가, 아래 도구들에도 그대로 적용됩니다. 제가 다음으로 붙여보려고 정리해 둔 목록입니다.

개발 워크플로우

GitHub / GitLab — 이슈·PR 조회 및 생성, 코드리뷰, 커밋 히스토리 분석
- 예: “이 버그와 관련된 최근 PR을 찾아서 뭐가 바뀌었는지 요약해줘”
파일시스템(Filesystem) — 로컬/서버 파일 대량 조회·정리
- 예: “logs 폴더에서 어제자 ERROR 로그만 모아 원인별로 분류해줘”
Git — 커밋 로그, diff, blame 분석
- 예: “이 함수를 마지막으로 바꾼 커밋과 그 이유(커밋 메시지)를 알려줘”

인프라 / DevOps

제 주 관심사이기도 한 영역인데, 여기서 특히 강력했습니다.

Kubernetes — 클러스터 리소스, Pod 상태·로그, 이벤트 진단
- 예: “결제 서비스 Pod가 재시작을 반복하는데, 최근 이벤트와 로그를 보고 원인을 짚어줘”
AWS / 클라우드 — 리소스 조회, IaC 검증
- 예: “이 보안그룹에서 0.0.0.0/0으로 열린 포트가 있는지 확인해줘”
Docker — 컨테이너·이미지 상태 조회
- 예: “지금 떠 있는 컨테이너 중 메모리 제한 없이 도는 게 있는지 알려줘”
모니터링(Grafana / Prometheus / Sentry) — 메트릭·알럿·에러 트레이스 분석
- 예: “어젯밤 10시에 응답시간이 튄 구간과 그때 발생한 에러 트레이스를 연결해줘”

협업 / 문서

Slack — 메시지 검색, 알림 전송
- 예: “배포 관련해서 지난주 논의된 스레드를 찾아 결정사항만 정리해줘”
Jira / Confluence — 티켓 관리, 문서 조회·작성
- 예: “이번 스프린트 미완료 티켓을 담당자별로 묶어서 요약해줘”
Notion / Google Drive — 문서 검색·정리
- 예: “회의록 폴더에서 ‘MCP’ 언급된 문서만 찾아 핵심만 뽑아줘”

외부 데이터 / 자동화

웹 검색 / Fetch — 최신 문서·자료 수집 (이 글 쓸 때도 유용했습니다)
- 예: “이 라이브러리 최신 버전과 주요 breaking change를 정리해줘”
브라우저 자동화(Playwright 등) — 화면 조작, 반복 확인 작업
- 예: “로그인 페이지를 열어서 이 테스트 계정으로 로그인되는지 확인해줘”

💡 정리하면, MCP는 “DB 커넥터”가 아니라 AI를 아무 외부 시스템에나 연결해주는 범용 프로토콜입니다. 그러니 “이 반복 조회, 꼭 내가 손으로 해야 하나?” 싶은 작업이 있다면 거기가 다음 MCP를 붙일 자리입니다.

7. 마치며

수행업체가 현대화 프로젝트에 MCP를 쓰는 걸 보고 “우리도 해볼까?”로 시작했는데, 막상 붙여보니 단위테스트 하나로 끝날 물건이 아니었습니다.

MCP + DB 연동은 특히 레거시 현대화처럼 “코드는 있는데 아무도 실제 동작을 확신 못 하는” 상황에서 데이터를 근거로 판단하게 해준다는 게 컸습니다.

혹시 비슷하게 도입을 고민 중이시라면, 기능보다 권한과 데이터 경계 설계를 먼저 잡고 시작하시길 권합니다.

(이 글은 개인 도입 경험을 정리한 것으로, 사용한 도구의 구성 방식이나 API는 버전에 따라 바뀔 수 있습니다. 실제 적용 시 각 도구의 공식 문서를 확인하세요.)

AI, DevOps

AI에게 사내 DB를 물려본 MCP 도입기

TL;DR

목차

1. 도입 배경

2. MCP란?

3. MCP 활용 사례

3-1. 단위테스트 시나리오 작성

3-2. 레거시 쿼리/프로시저 현대화

3-3. 쿼리 성능 튜닝

3-4. 데이터 마이그레이션 / 정합성 검증

3-5. 테스트/개발용 시드 데이터 생성

3-6. 스키마 문서화와 온보딩

3-7. 운영 이슈 재현과 원인 분석

4. Oracle MCP 서버, 이렇게 붙였습니다

4-1. 사전 조사와 스택 결정

4-2. 조회 전용 서버 직접 구현

4-3. “읽기 전용”을 계정 권한에만 맡기지 않았다

4-4. 진짜 복병: thin 접속 실패 → thick 전환

4-5. Kiro에 등록하기

4-6. 검증: 가드 단위 테스트 + stdio end-to-end

4-7. 배운 점 요약

5. 안전하게 쓰기 위한 원칙

6. DB 말고 또 어디에 쓸까

개발 워크플로우

인프라 / DevOps

협업 / 문서

외부 데이터 / 자동화

7. 마치며

인기 태그