From b617eaabe47fc1fc8e5bbbd1650995fa06c1f57a Mon Sep 17 00:00:00 2001 From: jade Date: Fri, 21 Aug 2026 11:26:57 +0900 Subject: [PATCH] docs: update DATMT deployment guide --- README.md | 129 ++++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 91 insertions(+), 38 deletions(-) diff --git a/README.md b/README.md index 5102d7249..f04a713f6 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ 신한라이프 업무 기능을 MCP(Model Context Protocol) Tool로 제공하는 Java 멀티 모듈 프로젝트입니다. 각 업무 모듈은 독립 실행 가능한 Spring Boot 애플리케이션이며, MCP Streamable HTTP와 REST 실행 API를 함께 제공합니다. -이 저장소에는 DAPMS(Gateway) 애플리케이션이 포함되어 있지 않습니다. DATMT는 Gateway로 Tool을 push 등록하지 않으며, 각 Pod가 `GET /tool-manifest`를 제공하면 DAPMS가 이 Manifest를 pull하여 Tool 목록을 구성합니다. Tool 조회와 직접 실행은 각 Pod에서도 자체적으로 처리합니다. +이 저장소에는 DATMS(Gateway) 애플리케이션이 포함되어 있지 않습니다. DATMT는 Gateway로 Tool을 push 등록하지 않으며, 각 Pod가 `GET /tool-manifest`를 제공하면 DATMS가 이 Manifest를 pull하여 Tool 목록을 구성합니다. Tool 조회와 직접 실행은 각 Pod에서도 자체적으로 처리합니다. ## 기술 기준 @@ -23,9 +23,9 @@ | `dat-was-cus` | 고객·CRM·VOC·웹 콘텐츠 관리 Tool | 8084 | 51 | | `dat-was-sal` | 영업·청구·인수·동의·현장지원 Tool | 8082 | 52 | | `dat-was-pro` | 상품·계약·고객·GA 설계사 Tool | 8085 | 50 | -| `dat-was-sys` | IAM·시스템 상태·공지·점검·배포 Tool | 8086 | 50 | +| `dat-was-sys` | IAM·시스템 상태·공지·점검·배포 Tool | 8086 | 51 | -총 203개의 `@McpTool` 선언과 203개의 V17 Tool YAML 정의가 있습니다. +업무 모듈에는 총 204개의 `@McpTool` 선언이 있습니다. 현재 업무 모듈의 `src/main/resources`에는 별도 `tool-definitions` YAML이 없으며, Tool 메타데이터는 어노테이션과 `@GrowToolHint`를 기준으로 생성됩니다. 현재 업무 구현은 개발·연동 검증 단계입니다. `dat-was-sal`의 `cmm_claim_search`와 `cmm_memo_retriever`는 각각 MCI와 HTTP Client 흐름을 사용하며, 나머지 Tool은 외부 시스템을 변경하지 않는 모의 응답을 중심으로 구현되어 있습니다. @@ -44,7 +44,7 @@ Tool Pod │ ├─ Tool 메타데이터 생성 │ └─ tool-definitions YAML 병합 ├─ ToolManifestService - │ └─ DAPMS가 pull할 bundle 단위 Manifest 생성 + │ └─ DATMS가 pull할 bundle 단위 Manifest 생성 ├─ McpToolExecutionService │ ├─ 입력 Schema 검증 │ ├─ 요청 DTO 변환 및 Tool 호출 @@ -54,18 +54,18 @@ Tool Pod 애플리케이션 시작 시 다음 순서로 Tool이 준비됩니다. -1. `ToolDefinitionRepository`가 `classpath*:tool-definitions/**/*.yml`을 읽고 V17 필수 항목을 검증합니다. -2. `ToolRegistryHeartbeatSender`가 `@McpTool` 메서드를 스캔하고 YAML 정의를 병합해 `ToolMetadata`를 생성합니다. +1. `ToolDefinitionRepository`는 `classpath*:tool-definitions/**/*.yml` 경로의 정의가 있을 경우 이를 읽고 V17 필수 항목을 검증합니다. +2. `ToolRegistryHeartbeatSender`가 `@McpTool` 메서드를 스캔하고, 존재하는 YAML 정의가 있으면 병합해 `ToolMetadata`를 생성합니다. 3. `McpToolMethodRegistry`가 실제 호출 가능한 Bean과 메서드를 Tool 이름으로 캐시합니다. 4. `ToolPodMcpToolSynchronizer`가 Tool을 MCP SDK 서버에 등록합니다. 5. REST와 MCP 요청은 공통 `McpToolExecutionService`를 통해 실행됩니다. DATMT 내부에는 `/registry/register`, `/registry/deregister` 호출이나 주기적인 Gateway heartbeat 전송이 없습니다. `ToolRegistryHeartbeatSender`라는 클래스명은 호환성을 위해 남아 있지만 현재 역할은 로컬 Tool 스캔과 메타데이터 생성뿐입니다. -### DAPMS 연동 방식 +### DATMS 연동 방식 ```text -DAPMS +DATMS └─ GET {DATMT Pod URL}/tool-manifest └─ bundleId + revision + tools[] └─ 각 Tool endpoint: {Pod URL}/mcp/{toolName} @@ -73,7 +73,7 @@ DAPMS - `mcp.manifest.bundle-id`는 Manifest를 제공하는 Pod의 고유 식별자이며 필수입니다. - 현재 값은 `was-sal`, `was-cus`, `was-pro`, `was-sys`입니다. -- DAPMS에 설정한 bundle ID와 DATMT가 반환하는 `bundleId`가 일치해야 같은 Tool bundle로 관리됩니다. +- DATMS에 설정한 bundle ID와 DATMT가 반환하는 `bundleId`가 일치해야 같은 Tool bundle로 관리됩니다. - `mcp.manifest.name-prefix`가 비어 있지 않으면 모든 Tool 이름이 해당 prefix로 시작해야 합니다. - Manifest 내용이 바뀌면 `revision`이 증가하며, `If-None-Match`가 일치하면 `304 Not Modified`를 반환합니다. @@ -115,11 +115,11 @@ Invoke-RestMethod ` ### 요청 헤더 계약 -DAPMS가 DATMT Tool Service를 호출할 때 사용하는 헤더는 다음과 같습니다. HTTP 헤더 이름은 대소문자를 구분하지 않지만, 문서와 구현에서는 아래 표기를 기준으로 사용합니다. +DATMS가 DATMT Tool Service를 호출할 때 사용하는 헤더는 다음과 같습니다. HTTP 헤더 이름은 대소문자를 구분하지 않지만, 문서와 구현에서는 아래 표기를 기준으로 사용합니다. | 헤더 | 필수 여부 | 용도 | 전달 동작 | |---|---|---|---| -| `X-Tool-Server-API-Key` | 인증 설정 시 필수 | DAPMS와 DATMT 사이의 Tool Server 인증 | `mcp.security.api-key` 또는 `api-keys`와 비교 | +| `X-Tool-Server-API-Key` | 인증 설정 시 필수 | DATMS와 DATMT 사이의 Tool Server 인증 | `mcp.security.api-key` 또는 `api-keys`와 비교 | | `guid` | 선택 | 업무 호출 상관관계 식별자 | 실행 로그, 성공 응답, 하위 HTTP 호출로 전달 | | `x-request-id` | 선택 | 요청 추적 식별자 | 실행 로그, 성공 응답, 하위 HTTP 호출로 전달 | | `employee-no` | 선택 | 실제 사용자 사번 | 하위 HTTP 호출로 전달 | @@ -165,17 +165,17 @@ SystemStatusResponse getSystemStatus(SystemStatusRequest request); 예: `cmm_claim_search`, `crm_customer_detail`, `iam_system_status` -이름 중복과 형식은 `validateMcpToolNames`, V17 정의는 `validateToolSchemaV17` Gradle 작업으로 검사합니다. 모든 `bootJar` 작업은 두 검증 작업에 의존합니다. +이름 중복과 형식은 `validateMcpToolNames` Gradle 작업으로 검사합니다. 현재 루트 `build.gradle`에는 `validateToolSchemaV17` Gradle 작업이 등록되어 있지 않으며, 모든 `bootJar` 작업은 `validateMcpToolNames`에만 의존합니다. ## Tool YAML 정의 -각 Tool은 업무 모듈의 다음 경로에 YAML 정의를 가집니다. +공통 라이브러리는 Tool 메타데이터를 보강하기 위한 선택적 YAML 정의를 지원합니다. YAML 정의를 추가할 경우 업무 모듈의 다음 경로를 사용합니다. ```text dat-was-*/src/main/resources/tool-definitions/{category}/{tool-name}.yml ``` -V17 정의의 주요 필수 항목은 다음과 같습니다. +현재 업무 모듈에는 이 경로의 YAML 정의가 없습니다. 따라서 실행 시 메타데이터는 `@McpTool`, `@GrowToolHint`, DTO Schema를 기준으로 구성됩니다. YAML 정의를 도입하는 경우 V17 주요 필수 항목은 다음과 같습니다. - `name`, `display_name`, `version`, `category_key` - `description.function`, `when_to_use`, `when_not_to_use`, `io_limits` @@ -185,7 +185,7 @@ V17 정의의 주요 필수 항목은 다음과 같습니다. - `parameters_schema.additionalProperties: false` - 각 입력 property의 `description` -입력·출력 Schema는 `ToolSchemaResolver`가 어노테이션의 Schema 리소스와 인라인 Schema, DTO에서 생성한 Schema를 해석합니다. `ToolRegistryHeartbeatSender`는 여기에 YAML의 `parameters_schema`와 `output_schema`를 병합하여 최종 메타데이터를 만듭니다. +입력·출력 Schema는 `ToolSchemaResolver`가 어노테이션의 Schema 리소스와 인라인 Schema, DTO에서 생성한 Schema를 해석합니다. YAML 정의가 있으면 `ToolRegistryHeartbeatSender`가 `parameters_schema`와 `output_schema`를 병합하여 최종 메타데이터를 만듭니다. 실행 시 Schema 검증은 MCP Java SDK의 `DefaultJsonSchemaValidator`를 사용하며 JSON Schema 2020-12 기준으로 처리합니다. 입력 불일치는 `422 INVALID_PARAM`, 출력 불일치는 `500 INVALID_TOOL_RESPONSE`로 반환됩니다. 단, Schema 해석 또는 검증기 자체에서 예외가 발생하면 현재 구현은 오류를 로그에 기록하고 해당 검증을 건너뜁니다. @@ -204,7 +204,7 @@ $env:SPRING_PROFILES_ACTIVE = 'local' $env:TOOL_SERVER_API_KEY = 'tool-server-key' ``` -`TOOL_SERVER_API_KEY`를 지정하지 않으면 현재 개발 기본값인 `tool-server-key`가 사용됩니다. 운영 환경에서는 기본값을 사용하지 말고 DAPMS의 Tool Server API Key와 동일한 별도 Secret을 주입해야 합니다. +`TOOL_SERVER_API_KEY`를 지정하지 않으면 현재 개발 기본값인 `tool-server-key`가 사용됩니다. 운영 환경에서는 기본값을 사용하지 말고 DATMS의 Tool Server API Key와 동일한 별도 Secret을 주입해야 합니다. 각 Pod는 별도 터미널에서 실행합니다. @@ -240,7 +240,7 @@ http://localhost:8086/swagger-ui/index.html |---|---|---| | `SPRING_PROFILES_ACTIVE` | Spring 활성 프로필 | `local` | | `PORT` | Pod 수신 포트 | 모듈별 기본 포트 | -| `TOOL_SERVER_API_KEY` | DAPMS가 `X-Tool-Server-API-Key`로 전달할 공통 인증 Key | `tool-server-key` | +| `TOOL_SERVER_API_KEY` | DATMS가 `X-Tool-Server-API-Key`로 전달할 공통 인증 Key | `tool-server-key` | | `AXHUB_TOOL_URL` | Manifest의 Tool endpoint 생성에 사용할 Pod 외부 URL | `http://localhost:${server.port}` | | `AXHUB_GATEWAY_URL` | 프로필 및 Compose 호환용 Gateway URL. 현재 DATMT의 push 등록에는 사용하지 않음 | `http://localhost:8081` | | `SPRING_DATA_REDIS_HOST` | Redis 호스트 | `localhost` | @@ -248,7 +248,7 @@ http://localhost:8086/swagger-ui/index.html | `GLOW_COMMUNICATION_MCI_HOST` | MCI 대상 호스트 | 프로필별 설정 | | `GLOW_COMMUNICATION_MCI_PORT` | MCI 대상 포트 | 프로필별 설정 | -`mcp.security.api-key`는 단일 DAPMS 공통 Key를, `mcp.security.api-keys`는 `API Key → tenant ID` 형태의 다중 Key를 지원합니다. 둘 중 하나라도 설정되어 있으면 올바른 `X-Tool-Server-API-Key`가 없는 `/rpc/**`, `/mcp/**` 요청은 `401 Unauthorized`가 됩니다. 두 설정이 모두 비어 있을 때만 익명 요청을 허용합니다. 현재 네 업무 Pod의 기본 `application.yml`은 단일 Key를 설정하므로 API Key 없이 Tool을 호출할 수 없습니다. +`mcp.security.api-key`는 단일 DATMS 공통 Key를, `mcp.security.api-keys`는 `API Key → tenant ID` 형태의 다중 Key를 지원합니다. 둘 중 하나라도 설정되어 있으면 올바른 `X-Tool-Server-API-Key`가 없는 `/rpc/**`, `/mcp/**` 요청은 `401 Unauthorized`가 됩니다. 두 설정이 모두 비어 있을 때만 익명 요청을 허용합니다. 현재 네 업무 Pod의 기본 `application.yml`은 단일 Key를 설정하므로 API Key 없이 Tool을 호출할 수 없습니다. ## Scaffold @@ -278,11 +278,11 @@ mcp: 생성되는 Compose 서비스에도 `TOOL_SERVER_API_KEY=${TOOL_SERVER_API_KEY:-tool-server-key}`가 추가됩니다. 생성 후에는 다음 항목을 반드시 확인해야 합니다. -1. `bundle-id`를 DAPMS에 등록할 bundle ID와 일치시킵니다. -2. 운영 환경의 `TOOL_SERVER_API_KEY`를 DAPMS가 전달하는 Key와 동일한 Secret으로 설정합니다. +1. `bundle-id`를 DATMS에 등록할 bundle ID와 일치시킵니다. +2. 운영 환경의 `TOOL_SERVER_API_KEY`를 DATMS가 전달하는 Key와 동일한 Secret으로 설정합니다. 3. 실제 배포 주소에 맞게 `AXHUB_TOOL_URL`을 설정합니다. 4. MCI·EAI·HTTP 연동 대상과 timeout을 환경별 설정으로 교체합니다. -5. `validateMcpToolNames`, `validateToolSchemaV17`, 전체 테스트를 실행합니다. +5. `validateMcpToolNames`와 모듈·전체 테스트를 실행합니다. YAML 정의를 추가했다면 `ToolSchemaV17ValidationRunner` 또는 관련 테스트로 V17 항목을 별도 검증합니다. ## 테스트와 검증 @@ -303,22 +303,17 @@ mcp: # Tool 이름·중복 검사 .\gradlew.bat validateMcpToolNames -# 203개 Tool V17 정의 검사 -.\gradlew.bat validateToolSchemaV17 - # 검증, 테스트, 패키징 .\gradlew.bat clean build ``` -### 현재 검증 상태 +### 실행 전 확인 -2026-08-18 기준 확인 결과입니다. +테스트 수와 성공 여부는 소스 변경에 따라 달라지므로 고정된 수치를 문서화하지 않습니다. 배포 전 현재 작업 트리에서 다음 명령을 실행해 확인합니다. -- 전체 `test`: 성공 -- 총 94개 테스트 성공, 실패·오류·건너뜀 0개 -- `validateMcpToolNames`: 성공 -- `validateToolSchemaV17`: 203개 Tool 성공 -- 실행 명령: `.\gradlew.bat test validateMcpToolNames validateToolSchemaV17` +```powershell +.\gradlew.bat test validateMcpToolNames +``` ## Docker Compose @@ -343,17 +338,75 @@ Compose 파일의 용도와 현재 주의점은 다음과 같습니다. | 파일 | 용도 | 현재 소스 기준 주의점 | |---|---|---| | `docker-compose.yml` | DATMT 네 Pod 단독 실행 | `gateway` 서비스가 없지만 push 등록이 제거되어 DATMT 시작에는 필요하지 않음 | -| `docker-compose.local.yml` | DAPMS와 DATMT의 로컬 통합 구성 | 두 저장소가 같은 상위 디렉터리에 있는 구조를 가정 | -| `docker-compose.prod.yml` | DAPMS와 DATMT의 개발 프로필 기반 OCI 구성 | 저장소의 runner 등록 토큰을 운영 Secret으로 분리해야 함 | +| `docker-compose.local.yml` | DATMS와 DATMT의 로컬 통합 구성 | 두 저장소가 같은 상위 디렉터리에 있는 구조를 가정 | +| `docker-compose.prod.yml` | DATMS와 DATMT의 개발 프로필 기반 OCI 구성 | 저장소의 runner 등록 토큰을 운영 Secret으로 분리해야 함 | -`docker-compose.local.yml`과 `docker-compose.prod.yml`의 build context는 각각 `./dat-was-dapms`, `./dat-was-datmt`입니다. 현재 파일 위치에서 사용할 때는 context 기준을 두 저장소의 상위 디렉터리로 맞춰야 합니다. +`docker-compose.local.yml`과 `docker-compose.prod.yml`의 build context는 각각 `./dat-was-DATMS`, `./dat-was-datmt`입니다. 현재 파일 위치에서 사용할 때는 context 기준을 두 저장소의 상위 디렉터리로 맞춰야 합니다. ```powershell # DATMT 저장소 디렉터리에서 실행 docker compose --project-directory .. -f docker-compose.local.yml up --build ``` -현재 기존 네 Pod의 Compose 정의에는 `TOOL_SERVER_API_KEY` 환경 변수 전달이 없습니다. 따라서 컨테이너는 애플리케이션 기본값 `tool-server-key`를 사용합니다. 운영 배포 전 각 서비스에 Secret 기반 `TOOL_SERVER_API_KEY` 전달 설정을 추가하고 DAPMS의 Key와 일치시켜야 합니다. DAPMS는 각 Pod의 `AXHUB_TOOL_URL` 또는 배포 URL에 접근해 `/tool-manifest`를 pull할 수 있어야 합니다. +현재 기존 네 Pod의 Compose 정의에는 `TOOL_SERVER_API_KEY` 환경 변수 전달이 없습니다. 따라서 컨테이너는 애플리케이션 기본값 `tool-server-key`를 사용합니다. 운영 배포 전 각 서비스에 Secret 기반 `TOOL_SERVER_API_KEY` 전달 설정을 추가하고 DATMS의 Key와 일치시켜야 합니다. DATMS는 각 Pod의 `AXHUB_TOOL_URL` 또는 배포 URL에 접근해 `/tool-manifest`를 pull할 수 있어야 합니다. + +## OpenShift (Kubernetes) 배포 + +OpenShift 개발 환경용 Kustomize 매니페스트는 [`k8s/`](k8s/)에 있습니다. 대상은 DATMT의 네 Tool Pod뿐이며 DATMS(Gateway)의 Deployment·Service·Route는 이 저장소에서 만들지 않습니다. + +```text +k8s/ +├─ base/ # 네 Pod 공통 ConfigMap, Service, Deployment +└─ overlays/dev/ # 개발 namespace, Registry 이미지 경로와 tag +``` + +### 배포 구조 + +각 Tool Pod는 Deployment 1개와 외부에 노출되지 않는 `ClusterIP` Service 1개를 사용합니다. OpenShift Route와 LoadBalancer Service는 생성하지 않으며, Gateway가 클러스터 내부 DNS로 호출합니다. + +| Service | Pod 포트 | Gateway 호출 주소 | +|---|---:|---| +| `was-sal` | 8082 | `http://was-sal:8082` | +| `was-cus` | 8084 | `http://was-cus:8084` | +| `was-pro` | 8085 | `http://was-pro:8085` | +| `was-sys` | 8086 | `http://was-sys:8086` | + +Gateway가 다른 namespace에 있으면 `was-sal.axhub-datmt-dev.svc`와 같은 FQDN을 사용하고, NetworkPolicy에서 Gateway namespace의 ingress를 별도로 허용해야 합니다. + +### 반영 전 설정 + +다음 값은 실제 신한라이프 개발망 값으로 교체해야 합니다. + +1. [`k8s/overlays/dev/kustomization.yaml`](k8s/overlays/dev/kustomization.yaml)의 namespace, 내부 Container Registry 경로, 배포 image tag +2. [`k8s/base/configmap.yaml`](k8s/base/configmap.yaml)의 `CHANGE_ME` MCI·EXTMCI·EAI 호스트 +3. 실제 Secret 값 + +`datmt-runtime-secrets` Secret은 Git에 저장하지 않고 OpenShift namespace에서 별도로 생성합니다. 최소한 `TOOL_SERVER_API_KEY`는 DATMS가 전달하는 `X-Tool-Server-API-Key`와 같은 값이어야 합니다. DB 계정·비밀번호, API Key, 인증서 비밀번호 등도 이 Secret으로 관리합니다. + +```powershell +# runtime-secrets.env는 저장소 밖에 보관합니다. +oc -n axhub-datmt-dev create secret generic datmt-runtime-secrets ` + --from-env-file=runtime-secrets.env +``` + +Secret이 없으면 각 Deployment의 `envFrom.secretRef`를 해석할 수 없어 Pod가 시작하지 않을 수 있습니다. + +### 이미지 빌드와 배포 + +모듈 Dockerfile은 미리 생성된 Boot JAR를 복사하므로, 이미지를 만들기 전에 네 모듈의 JAR를 빌드합니다. 개발망에서는 JDK/JRE 베이스 이미지와 Gradle/Maven 의존성을 내부 Registry·Nexus에서 사용할 수 있어야 합니다. + +```powershell +.\gradlew.bat :dat-was-sal:bootJar :dat-was-cus:bootJar :dat-was-pro:bootJar :dat-was-sys:bootJar + +# OpenShift 로그인 및 project 선택 후 +oc kustomize k8s/overlays/dev +oc apply -k k8s/overlays/dev +oc get deployment,pod,svc -n axhub-datmt-dev +``` + +적용 전에는 `oc kustomize k8s/overlays/dev | oc apply --dry-run=client -f -`로 서버 측 스키마 검증을 수행합니다. 현재 매니페스트의 readiness/liveness probe는 TCP 포트 확인 방식입니다. Actuator health endpoint를 추가한 뒤에는 HTTP readiness/liveness probe로 변경하는 것을 권장합니다. + +상세한 명령과 Gateway 연결 확인 방법은 [`k8s/README.md`](k8s/README.md)를 참고합니다. ## 보안 및 운영 주의사항 @@ -361,7 +414,7 @@ docker compose --project-directory .. -f docker-compose.local.yml up --build - API Key 인터셉터는 `/rpc/**`, `/mcp/**`에 적용됩니다. 따라서 `/mcp`, `/mcp/{toolName}`, `/mcp/api/v1/tools/local`은 인증 대상입니다. - `/tool-manifest`는 위 인터셉터 경로 밖에 있어 현재 API Key 인증 대상이 아닙니다. 내부망·Ingress 정책 또는 별도 인증이 필요한지 운영 기준을 확인해야 합니다. -- 네 업무 Pod의 기본 Key는 모두 `tool-server-key`입니다. 운영에서는 반드시 별도 Secret으로 교체하고 DAPMS의 `X-Tool-Server-API-Key` 값과 일치시켜야 합니다. +- 네 업무 Pod의 기본 Key는 모두 `tool-server-key`입니다. 운영에서는 반드시 별도 Secret으로 교체하고 DATMS의 `X-Tool-Server-API-Key` 값과 일치시켜야 합니다. - 설정된 단일 Key와 다중 Key가 모두 없을 때만 익명 요청이 허용됩니다. - `mcp.security.tenant-domains`는 설정 객체에 바인딩되지만 Tool별 인가에 사용되지 않습니다. - `requiresApproval`은 메타데이터에만 기록되며 실행 차단이나 승인 확인 로직은 없습니다. @@ -393,8 +446,8 @@ docker compose --project-directory .. -f docker-compose.local.yml up --build 1. Tool 메서드와 요청·응답 DTO를 구현합니다. 2. 동일 이름의 V17 YAML 정의를 `tool-definitions` 아래에 추가합니다. -3. `validateMcpToolNames`와 `validateToolSchemaV17`을 실행합니다. +3. `validateMcpToolNames`와 모듈·전체 테스트를 실행합니다. Tool YAML 정의를 추가한 경우에는 V17 항목을 별도 검증합니다. 4. 모듈 테스트와 전체 테스트를 실행합니다. 5. 로컬 Pod에서 `/mcp/api/v1/tools/local`과 `/tool-manifest`를 확인합니다. -6. DAPMS의 bundle ID, Pod Manifest URL, Tool Server API Key가 DATMT 설정과 일치하는지 확인합니다. +6. DATMS의 bundle ID, Pod Manifest URL, Tool Server API Key가 DATMT 설정과 일치하는지 확인합니다. 7. REST와 MCP 양쪽에서 동일한 Tool 결과·요청 헤더 전달·오류 계약을 확인합니다.