interbase MCP 기반 작업흐름을 사용해, InterBase 데이터베이스 탐색하기

[Kori]

MCP 기반 작업흐름으로 InterBase 데이터베이스 탐색하기

원문 정보 (최종 번역일: 2026년 8월 30일):

• 제목: Exploring an InterBase Database with an MCP-Driven Workflow
• 작성자: Rizzato Fernando - 2026년 8월
• 링크 https://blogs.embarcadero.com/exploring-an-interbase-database-with-an-mcp-driven-workflow/ 

이전 글에서 우리는 InterBase Model Context Protocol(MCP) 서버를 소개했다. Delphi로 만들어진 이 도구는, 대규모 언어 모델(LLM)과 InterBase 데이터베이스를 연결해 준다. 이번 후속 글에서, 우리의 플레이그라운드 노트북을 공개한다. 실제로 진행된, 단계별 세션이다. 나는 ChatGPT를 사용해, InterBase 데이터베이스 인스턴스와 직접 상호작용했다. InterBase MCP 도구와 에이전틱 스킬을 사용해서 할 수 있었다.

지금까지 시도한 것들 그리고 그 결과들은 아래에서 확인해 보자:

목차

• 1. 스키마 파악하기
• 2. 스키마 문서와 ER 다이어그램 생성하기
• 3. 고객 데이터 살펴보기
• 4. 매출액 기준 상위 고객 찾아내기
  • 결과
• 5. 데이터베이스 대시보드 만들기
• 6. 여러 테이블을 결합한 스트레스 쿼리 구성하기
• 7. 복잡한 쿼리 실행 계획 설명하기
• 8. 메타데이터 변경/최적화 적용하기

1. 스키마 파악하기

프롬프트: 이 데이터베이스 안의 모든 테이블들을 나열해. 그런 다음, 각 테이블의 커럼, 데이터 타입, null 허용 여부, 기본 키, 외래 키, 인덱스를 보여줘.

이 데이터베이스 안에는 10개의 사용자 테이블이 있다:

테이블	기본 키	용도
COUNTRY	COUNTRY	국가와 통화 참조 데이터
CUSTOMER	CUST_NO	고객 연락처 및 위치 데이터
DEPARTMENT	DEPT_NO	조직 계층 구조와 예산
EMPLOYEE	EMP_NO	직원, 직무, 부서, 급여
EMPLOYEE_PROJECT	EMP_NO, PROJ_ID	직원-프로젝트 연결 테이블
JOB	JOB_CODE, JOB_GRADE, JOB_COUNTRY	직무 정의와 급여 범위
PROJECT	PROJ_ID	프로젝트, 제품, 팀 리더
PROJ_DEPT_BUDGET	FISCAL_YEAR, PROJ_ID, DEPT_NO	부서·연도별 프로젝트 예산
SALARY_HISTORY	EMP_NO, CHANGE_DATE, UPDATER_ID	직원 급여 변경 이력
SALES	PO_NUMBER	주문, 영업 담당자, 수량, 금액

이 카탈로그를 검사한 결과, 13개의 외래 키 관계가 확인되었다. 중심이 되는 트랜잭션 테이블은 SALES다. CUST_NO를 통해 CUSTOMER를 참조하고, SALES_REP를 통해 EMPLOYEE를 참조한다. employee, department, job, project 테이블은 핵심 조직 모델을 이룬다. 전체 컬럼-수준 출력은 schema-document.md로 저장했다. 거기에는 데이터 타입, null 허용 여부, 기본값, 제약 조건, 인덱스, 관계 요약이 포함되어 있다.

2. 스키마 문서와 ER 다이어그램 생성하기

프롬프트: Markdown 스키마 문서를 생성해. 그런 다음, 계층적 ER 다이어그램을 만들어. 그 다이어그램은 모든 컬럼, 데이터 타입, null 허용 규칙, 기본 키, 외래 키 관계를 담고 있어야 해.

솔직히 말해, ER 다이어그램을 생성하는 첫 시도는 잘 되지 않았다. 생성된 다이어그램은 아키텍트가 기대할 만한 형식이나 상세 수준을 맞추지 못했다. 조사를 좀 해본 후에 나는 AI 에이전트에게 특정 모델링 스킬을 넣어주었다. 그 스킬은 이 프로젝트에서 얻었다: https://github.com/imxv/Pretty-mermaid-skills

이를 통해, 우리는 매우 유망한 결과를 얻을 수 있었다. 나는 밀어붙일 여지가 더 있다고 믿게 되었다. 아래를 확인해 보자:

• schema-er.mmd: Mermaid 소스
• schema-er.svg: 렌더링된 벡터 다이어그램

3. 고객 데이터 살펴보기

프롬프트: CUSTOMER 테이블 안에 저장된 데이터를 보여줘.

이 테이블에는 15명의 고객이 있었다. 아래의 간략한 표는, 이번 실험 동안 가져온 식별 정보와 위치를 담은 필드들을 보여준다:

고객 번호	고객명	도시	지역	국가	보류
1001	Signature Design	San Diego	CA	USA
1002	Dallas Technologies	Dallas	TX	USA	*
1003	Buttle, Griffith and Co.	Boston	MA	USA
1004	Central Bank	Manchester		England
1005	DT Systems, LTD.	Central Hong Kong		Hong Kong
1006	DataServe International	Ottawa	ON	Canada
1007	Mrs. Beauvais	Pebble Beach	CA	USA
1008	Anini Vacation Rentals	Lihue	HI	USA
1009	Max	Turtle Island		Fiji	*
1010	MPM Corporation	Tokyo		Japan
1011	Dynamic Intelligence Corp	Zurich		Switzerland
1012	3D-Pad Corp.	Paris		France
1013	Lorenzi Export, Ltd.	Milan		Italy
1014	Dyno Consulting	Brussels		Belgium
1015	GeoTech Inc.	Den Haag		Netherlands

두 고객 즉 "Dallas Technologies"와 "Max"은 현재 보류 상태라고 표시되어 있었다.

4. 매출액 기준 상위 고객 찾아내기

프롬프트: 총 매출액이 가장 높은 상위 10개 고객을 반환하는 InterBase 쿼리를 작성하고 실행해.

InterBase 쿼리는 다음과 같았다. 잘 작동했다:

SELECT C.Cust_no,  
       C.Customer,  
       Sum(S.Total_value) AS Total_sales_value  
FROM Customer C  
JOIN Sales S ON S.Cust_no = C.Cust_no  
GROUP BY C.Cust_no,  
         C.Customer  
ORDER BY Total_sales_value DESC ROWS 1 TO 10

결과

순위	고객 번호	고객명	총 매출액
1	1001	Signature Design	1,045,610.12
2	1012	3D-Pad Corp.	463,000.47
3	1006	DataServe International	400,008.00
4	1011	Dynamic Intelligence Corp	121,980.72
5	1004	Central Bank	75,000.00
6	1003	Buttle, Griffith and Co.	39,582.12
7	1002	Dallas Technologies	35,450.50
8	1008	Anini Vacation Rentals	25,000.00
9	1010	MPM Corporation	21,195.40
10	1005	DT Systems, LTD.	14,980.00

Signature Design이 확실한 선두였다. 2위 고객의 매출액보다 2배 이상 많았다.

프롬프트: 지금 본 그 결과를 차트로 보여줘.

이 차트는 top-customers-chart.svg라고 저장했다.

5. 데이터베이스 대시보드 만들기

프롬프트: 대시보드를 만들어. 이 데이터베이스에서 가장 중요한 운영·분석 데이터를 요약해 보여주는 대시보드야.

결과물인 database-dashboard.html에는, 스키마 개수, 매출 KPI, 주문 상태, 고객 지역 분포, 상위 고객, 직원 급여 통계, 부서별 인원수, 테이블별 행 개수를 한눈에 보여주었다.

6. 여러 테이블을 결합한 스트레스 쿼리 구성하기

프롬프트: 데이터베이스 성능을 점검할 수 있는 쿼리를 만들어. 실용적인 범위 내에서 최대한 많은 관련 테이블을 조인하는 복잡한 쿼리 하나를 만들어.

최종 테스트 쿼리는 10개 테이블 중 9개를 조인했다. SALES를 드라이빙 테이블로 사용했다. 그리고 고객, 직원, 부서, 직무, 프로젝트, 프로젝트 예산, 급여 이력, 국가 데이터로 이어지는 관계를 따라가는 것이었다:

SELECT S.Order_status,
       Co.Country AS Country_name,
       Co.Currency,
       D.Department,
       J.Job_title,
       P.Product,
       Count(*) AS ROW_COUNT,
       Count(DISTINCT S.Po_number) AS Order_count,
       Count(DISTINCT C.Cust_no) AS Customer_count,
       Count(DISTINCT E.Emp_no) AS Sales_rep_count,
       Count(DISTINCT P.Proj_id) AS Project_count,
       Sum(S.Qty_ordered) AS Total_qty_ordered,
       Sum(S.Total_value) AS Total_sales_value,
       Avg(S.Total_value) AS Avg_sales_value,
       Min(S.Total_value) AS Min_sales_value,
       Max(S.Total_value) AS Max_sales_value,
       Avg(E.Salary) AS Avg_sales_rep_salary,
       Avg(D.Budget) AS Avg_department_budget,
       Avg(B.Projected_budget) AS Avg_projected_budget,
       Avg(Sh.Percent_change) AS Avg_salary_change_pct,
       Max(Sh.Change_date) AS Last_salary_change
FROM Sales S
LEFT JOIN Customer C ON C.Cust_no = S.Cust_no
LEFT JOIN Employee E ON E.Emp_no = S.Sales_rep
LEFT JOIN Department D ON D.Dept_no = E.Dept_no
LEFT JOIN Job J ON J.Job_code = E.Job_code
AND J.Job_grade = E.Job_grade
AND J.Job_country = E.Job_country
LEFT JOIN Project P ON P.Team_leader = E.Emp_no
LEFT JOIN Proj_dept_budget B ON B.Proj_id = P.Proj_id
AND B.Dept_no = D.Dept_no
LEFT JOIN Salary_history Sh ON Sh.Emp_no = E.Emp_no
LEFT JOIN Country Co ON Co.Country = Coalesce(C.Country, E.Job_country)
GROUP BY S.Order_status,
         Co.Country,
         Co.Currency,
         D.Department,
         J.Job_title,
         P.Product
ORDER BY S.Order_status,
         Total_sales_value DESC,
         Customer_count DESC

7. 복잡한 쿼리 실행 계획 설명하기

프롬프트: 이 다중 테이블 쿼리의 실행 계획을 설명해 줘.

InterBase가 반환한 쿼리 플랜은 아래와 같다:

PLAN SORT (SORT (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN
(S NATURAL,C INDEX (RDB$PRIMARY22)),
E INDEX (RDB$PRIMARY7)),
D INDEX (RDB$PRIMARY5)),
J INDEX (RDB$PRIMARY2)),
P INDEX (RDB$FOREIGN13)),
B INDEX (RDB$FOREIGN18,RDB$FOREIGN19)),
SH INDEX (RDB$FOREIGN21)),
CO INDEX (RDB$PRIMARY1))))

이 계획은 다음을 보여준다:

• SALES는 자연 스캔(natural scan, S NATURAL)으로 읽었다.
• 조회 테이블들은 기본 키 또는 외래 키 인덱스를 사용했다.
• 두 번의 정렬 작업이 필요했다. 그룹화, distinct 집계, 최종 정렬을 위해서였다.

이 쿼리에는 선택적인 WHERE 절이 없었고, SALES 테이블 전체를 집계했다. 그러니 자연 스캔(natural scan, S NATURAL)이 합리적이었다.

8. 메타데이터 변경/최적화 적용하기

여러분의 구성에서 허용된다면, 이 도구를 통해 메타데이터에 변경 사항을 직접 적용하는 것도 가능하다. 이번 실험에서는, 먼저 다음 SQL 문의 실행 계획을 보여달라고 AI에게 요청했다:

프롬프트: 다음 문의 쿼리 계획을 보여줘.

SELECT S.Po_number,  
       S.Order_date,  
       S.Order_status,  
       S.Total_value  
FROM Sales S  
WHERE S.Order_date >= Cast('2023-01-01' AS DATE)  
  AND S.Order_date < Cast('2024-01-01' AS DATE)  
ORDER BY S.Order_date,  
         S.Po_number;

InterBase가 반환한 쿼리 플랜은 아래와 같다:

PLAN SORT ((S NATURAL))

InterBase는 SALES 테이블 전체 스캔(NATURAL)을 수행한 다음, 일치하는 행을 정렬한다. 인덱스는 사용되지 않는다.

프롬프트: 이제, 그 쿼리 실행을 최적화하기 위해 만들 수 있는 인덱스를 제안해.

이 특정 쿼리에 가장 적합한 인덱스는 다음과 같다:

CREATE INDEX IDX_SALES_ORDER_DATE_PO ON SALES (ORDER_DATE, PO_NUMBER);

이 인덱스는 다음을 지원한다:

• ORDER_DATE에 대한 범위 필터
• ORDER BY ORDER_DATE, PO_NUMBER
• 전체 스캔과 명시적 정렬을 피하기 또는 줄이기

프롬프트: 좋다, 제안된 인덱스를 생성해.

생성하고 검증했다:

CREATE INDEX IDX_SALES_ORDER_DATE_PO ON SALES (ORDER_DATE, PO_NUMBER);

계획 비교:

Before: PLAN SORT ((S NATURAL))
After:  PLAN (S ORDER IDX_SALES_ORDER_DATE_PO)

이제 InterBase는 인덱스를 사용한다. 더 이상 자연 스캔이나 명시적 정렬이 필요하지 않다.