[2026.01.02 주간 개발 트렌드] Kubernetes의 Pod 복구와 클라우드 경로 동기화

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# 데이터베이스에도 Agent를 연결하는 인터페이스가 들어왔다

Agent가 데이터베이스의 정보를 사용하게 만들려면 중간 연결을 직접 구성하는 경우가 많다. 조회용 API를 만들고 MCP 도구로 감싼 다음 인증과 배포까지 준비하는 방식이다.

이번주 12월 23일에 Oracle이 [Autonomous AI Database의 내장 MCP 서버](https://docs.oracle.com/en-us/iaas/releasenotes/autonomous-database-serverless/2025-12-mcp-server-for-autonomous-ai-database.htm)를 발표했다. Serverless Exadata Infrastructure의 26ai와 19c를 대상으로 데이터베이스별 관리형 MCP 서버를 제공한다.

이번주에는 DB가 Agent용 인터페이스를 직접 제공할때 줄어드는 작업과 여전히 설계해야하는 부분을 정리해보려고 한다.

# 1. 우선 연결 구조가 어떻게 달라지나

Agent가 사용할 도구를 직접 운영한다면 다음과 같은 구성을 생각할 수 있다.

```text
Agent
  ↓
직접 만든 MCP 서버
  ↓
백엔드 API 또는 DB 접근 코드
  ↓
Database
```

이번 기능은 별도의 MCP 서버 인프라를 고객이 운영하지 않아도 Select AI Agent 도구를 MCP로 호출할 수 있게 하는 방향이다.

```text
MCP를 지원하는 Agent
        ↓
DB별 관리형 MCP 서버
        ↓
등록된 Select AI Agent 도구
        ↓
허용된 데이터와 작업
```

여기서 중요한건 등록된 도구다. 데이터베이스를 인터넷에 열고 Agent에게 모든 SQL을 자유롭게 실행하게 한다는 의미로 이해하면 안된다.

직접 운영하던 연결 계층의 일부를 서비스가 맡을 수 있다는것과 어떤 기능을 공개할지 정하는것은 별개의 일이다.

# 2. MCP가 있으면 백엔드가 필요없어질까

MCP는 모델과 외부 도구를 연결하는 공통 인터페이스다. 연결 방법을 맞추는것과 서비스의 업무 규칙을 구현하는것은 다르다.

예를 들어 주문 취소를 생각해보자. 주문 테이블의 상태값 하나를 바꾸는것만으로 취소가 끝나지는 않을 수 있다. 결제 환불이나 재고 복원, 외부 알림까지 연결될 수 있다.

```text
주문 취소
├── 취소 가능한 상태인지 확인
├── 요청자의 권한 확인
├── 결제와 재고 처리
└── 결과 기록과 후속 작업
```

이 규칙을 이미 백엔드 서비스에서 관리하고있다면 DB 도구로 우회하지 않도록 설계해야한다. 직접 연결이 짧아보인다는 이유로 같은 업무를 두곳에서 다르게 구현하면 관리하기 어렵다.

반면 정해진 범위의 조회나 DB 가까이에 있는 계산은 도구로 제공할 후보가 될 수 있다. 어떤 책임을 DB에 두고 어떤 책임을 서비스에 둘지부터 정하면 좋겠다.

# 3. 도구는 목적이 드러나게 나눠보자

모든 SQL을 문자열로 받는 도구 하나와 필요한 작업을 구분한 도구들은 사용하는 방식이 다르다. Agent가 무엇을 할 수 있는지와 결과를 어떻게 해석할지에 영향을 준다.

아래는 실제 Oracle API 이름이 아닌, 서비스의 도구를 설계하기 위한 예시다.

```text
findMyOrders(period, cursor)
getOrderSummary(orderId)
getDailySalesSummary(date)
```

이름과 입력에서 목적이 드러나면 허용할 조건과 반환 형식을 정하기 쉽다. 조회 기간과 결과 수를 제한하거나 주문이 없을때의 응답도 명확하게 만들 수 있다.

결과에는 모델이 다음 행동을 정할 수 있는 정보가 필요하다. 데이터가 없는것과 권한이 없는것, 실행이 실패한것을 전부 빈 배열로 반환하면 원인을 구분하기 어렵다.

[관리형 MCP 서버 문서](https://docs.oracle.com/en-us/iaas/autonomous-database-serverless/doc/mcp-server.html)에서도 도구 생성과 등록, 인증과 권한 등의 준비를 구분해서 안내한다. 서버를 직접 배포하는 일이 줄어도 도구의 계약은 만들어야한다.

한번에 큰 기능을 공개하기보다 읽기 전용 도구 하나에서 입력과 결과를 확인해보면 좋겠다. 실제 질문에서 필요한 정보가 충분한지와 불필요한 정보가 포함되는지를 같이 볼 수 있다.

# 4. 누구의 권한으로 조회하는지 알아야한다

Agent가 연결됐다는 사실과 그 Agent가 어떤 사용자를 대신하는지는 다른 문제다. 공통 DB 계정으로 연결했다면 사용자별 접근 범위를 어디서 확인하는지 명확해야한다.

예를 들어 도구 입력에 memberId가 있다고 해보자. 모델이 전달한 숫자를 그대로 신뢰하면 다른 회원의 주문까지 조회할 수 있는 구조가 될 수 있다.

```text
사용자 요청
    ↓
실제 사용자와 접근 범위 확인
    ↓
도구의 입력 검증
    ↓
허용된 데이터 조회
```

조회 도구에서도 필요한 컬럼과 행만 반환하도록 생각해보자. 모델이 모든 데이터를 받은 뒤 답변에서만 숨기는 방식은 데이터 전달 자체를 제한하지 못한다.

쓰기 도구는 더 구체적인 조건이 필요하다. 어떤 상태에서 실행할 수 있는지, 중복 호출이 들어오면 어떻게 처리할지, 중요한 변경은 어떤 절차로 확정할지 정해야한다.

프롬프트에 다른 사람의 데이터를 보지 말라고 적는것과 실제 접근 제어는 역할이 다르다. 권한은 도구와 데이터 접근 경계에서 확인할 수 있어야한다.

# 5. 운영 비용과 실행 흔적도 확인하자

Agent가 질문 하나에 도구를 여러번 호출할 수 있다. 사람이 화면에서 한번 누르는 조회를 기준으로만 부하를 예상하면 실제 호출량과 차이가 날 수 있다.

```text
운영에서 볼 지표
호출 횟수 / 쿼리 시간 / 반환 행 수 / 오류
사용자와 도구 / 실행 식별자 / 변경 결과
```

조회 기간이 넓거나 결과가 크다면 DB 비용뿐 아니라 모델에 전달하는 문맥도 늘어난다. 필요한 요약과 페이지 단위 결과를 제공할 수 있는지 생각해보면 좋겠다.

문제가 생겼을때는 어떤 사용자 요청에서 어떤 도구가 어떤 인자로 호출됐는지 연결할 수 있어야한다. 단, 로그에 민감한 값까지 전부 복사하는 방식은 피하고 필요한 식별 정보와 결과를 정해서 남기면 된다.

권한이 없는 요청과 데이터가 없는 요청, 제한 시간을 넘긴 요청도 테스트해보자. 정상적으로 조회되는 예시만으로는 Agent가 실패를 어떻게 이해하는지 알기 어렵다.

기존 서비스와 같은 DB를 사용한다면 일반 사용자 요청의 지연에도 영향을 주는지 확인해야한다. MCP 연결이 간단해졌다는 이유로 쿼리 비용까지 작아지는것은 아니다.

# 마무리

이번 Oracle 소식은 MCP가 별도 연결 서버의 영역을 넘어 데이터베이스 제품 안으로 들어오고있다는 변화로 보인다.

개인적으로는 연결 인프라를 줄일 수 있는것만큼 DB와 백엔드, Agent 사이의 책임을 정하는 작업이 중요해질것 같다. 중간 단계가 줄어도 업무 규칙과 접근 범위는 사라지지 않기 때문이다.

우선 제한된 조회 도구부터 실제 질문으로 확인해보면 좋겠다. Agent가 DB에 연결됐다는것에서 끝내지 말고 허용한 작업을 예상한 범위로 수행하는지 확인해야겠다..


[2025.12.26 주간 개발 트렌드] 데이터베이스 MCP 정리 (Oracle, Agent 도구, 접근 권한)

독자의 메모