Nacos GitHub 추천: Spring Boot 팀의 MCP registry와 AI cloud native 운영 체크

 

Nacos GitHub 추천: AI 에이전트 시대의 MCP·스킬 레지스트리 인프라

서비스 디스커버리 도구를 AI Registry 후보로 볼 때 먼저 확인할 것

 

Nacos GitHub 추천: MCP·스킬 레지스트리로 다시 보는 이유

 

Nacos는 서비스 디스커버리와 설정 관리에서 출발한 클라우드 네이티브 인프라입니다. 3.2.x 문서와 릴리스에는 MCP Server, Prompt, Skill, AgentSpec을 관리하는 AI Registry 흐름이 들어왔습니다. Java/Spring 기반 팀이라면 Nacos GitHub MCP registry AI cloud native Spring Boot 조합을 크게 들이기 전에 작은 내부 테스트로 맞는지 확인하는 편이 현실적입니다.

AI 에이전트 도구가 두세 개일 때는 로컬 설정 파일이나 팀 문서로도 버팁니다. MCP 서버, 프롬프트, 스킬 패키지가 늘어나는 순간에는 승인자, 운영 버전, 회수 절차가 먼저 흐려집니다.

Nacos에서 눈에 들어오는 지점은 AI라는 간판보다 운영 목록의 자리입니다. 이 프로젝트의 바탕은 서비스 등록, 설정 관리, 메타데이터 관리입니다. 그 위에 AI 리소스를 등록하고 상태를 바꾸는 관리층이 붙었습니다.

2026-06-13 조회 기준 GitHub API에서 alibaba/nacos는 Java 기반 public repository, Apache-2.0 라이선스, 별 33,019개, fork 13,288개, open issue 236개로 확인됐습니다. 이 숫자는 조회 시점 값이라 나중에 바뀝니다. 활동 신호와 AI Registry 문서가 함께 보이는 저장소라 Nacos GitHub 추천 소재로 따로 볼 만합니다.

 

 

서비스 등록소에서 AI 리소스 등록소로

 

Nacos는 기존 서비스 레지스트리 기능을 유지하면서 MCP 서버, 프롬프트, 스킬 같은 AI 운영 리소스도 등록, 발견, 버전 관리 대상으로 다룹니다.

Nacos README는 지금도 Nacos를 서비스 디스커버리와 설정 관리 도구로 설명합니다. 이 출발점을 빼면 글이 과장됩니다. AI Registry는 기존 운영 인프라가 AI 리소스 목록까지 맡는 변화로 보는 게 맞습니다.

공식 문서의 AI Registry 설명은 MCP Servers, A2A Agents, Prompts, Skills, AgentSpecs와 그 버전을 관리 대상으로 둡니다. Skill Registry 문서는 스킬 저장, 버전 관리, 보안 검토, 게시, 배포를 중앙화하는 private Skill repository 성격을 설명합니다. Prompt Registry 문서는 자주 바뀌고 검토, 버전 관리, 롤백, 감사가 필요한 프롬프트에 맞는 구조를 제시합니다.

검토 대상은 콘솔 화면보다 목록과 상태 관리입니다. 사내 AI 도구가 늘어나는 팀이라면 Nacos를 배포 상태 정리용 레지스트리로 시험해 볼 만합니다. 다만 장기 운영 사례까지 검증됐다고 쓰려면 문서와 릴리스 노트 바깥의 확인이 더 필요합니다.

 

2026년 3월부터 6월까지 남은 흔적

 

Nacos의 2026년 3월과 5월 릴리스는 AI Registry 관련 기능이 정식 릴리스에 들어온 구간입니다. 2026년 6월 커밋에서는 MCP SDK와 AI resource lifecycle 작업이 이어진 흔적이 확인됩니다. 안정 릴리스에 들어간 사실과 develop 브랜치 활동은 분리해서 읽어야 합니다.

2026-03-27에는 Nacos 3.2.0 release가 공개됐고, 릴리스 설명은 plugin architecture, AI Registry expansion, API modernization을 주요 축으로 제시했습니다.

2026-05-29의 Nacos 3.2.2 release는 Config, Naming, MCP, Skill, AI resources, namespace workflows의 콘솔 경험 개선과 AI Registry import, discovery, publishing, subscription, security 개선을 포함한다고 밝혔습니다. 설치 버전을 고를 때는 이 릴리스가 먼저 눈에 들어옵니다.

2026-06-10 커밋 4bec8b0에는 Spring Boot 4 계열 업그레이드와 MCP SDK 0점17점0에서 0점18점2로 올리는 변경이 포함됐습니다. 2026-06-11 커밋 4914209는 AI resource latest label 관리, prompt publish lifecycle 정렬, skill zip descriptor parsing 수정 등을 반영했습니다. 두 커밋은 develop 브랜치의 활동 신호입니다. 운영 적용 여부는 릴리스 노트와 공식 문서에 올라온 내용부터 확인해야 합니다.

 

 

한국 Spring Cloud 팀에는 어떤 의미가 있나

 

MCP 서버와 프롬프트, 스킬이 늘어나는 팀에서는 검색, 승인, 버전, 회수 관리가 개발보다 먼저 막힙니다. Spring Cloud와 Java 운영 문화가 있는 조직은 Nacos의 서비스 레지스트리 방식을 AI 에이전트 도구 관리에 가져올 여지가 있습니다.

한국 사용자 입장에서는 팀의 현재 운영 지형부터 봐야 합니다. 서비스 디스커버리나 설정 관리에 Nacos를 이미 쓰고 있다면 AI Registry 검증 비용이 낮습니다. 반대로 Nacos 운영 경험이 전혀 없고 MCP 서버도 두세 개뿐이라면 레지스트리 서버를 세우는 일이 먼저 부담으로 옵니다.

MCP auto-register 문서는 Spring AI Alibaba framework 또는 Nacos MCP Wrapper Python으로 만든 MCP Server가 시작 후 Nacos에 동적으로 등록될 수 있다고 설명합니다. 등록된 서비스는 Spring AI Alibaba, Nacos MCP Router, Higress gateway와 연결될 수 있습니다. 호환 도구를 말할 때도 이 문서 범위 안에서 보는 편이 안전합니다.

운영 책임이 갈림길입니다. 팀 내부 MCP 서버가 늘어나고, 보안 검토가 필요하고, 프롬프트나 스킬의 배포 이력을 남겨야 한다면 Nacos GitHub MCP registry AI cloud native Spring Boot 조합은 테스트할 가치가 있습니다. 개인 자동화 수준이라면 로컬 MCP 설정과 Git 저장소가 더 단순합니다.

 

도입 시뮬레이션: 설치부터 첫 검증까지

 

첫 테스트는 운영망이 아니라 로컬 또는 내부 테스트 환경에서 Nacos 3.2.2, JDK 17+, Console 8080, API 8848, Docker 또는 standalone 실행을 확인하는 순서가 적절합니다. 그다음 샘플 MCP 서버 등록과 Nacos MCP Router 연결 범위를 확인합니다.

공식 Quick Start는 production recommended stable version을 3.2.2로 안내하고, Nacos Server와 Console 실행에는 64-bit JDK 17+가 필요하다고 설명합니다. 3.x에서는 Server API 기본 포트 8848과 Console 기본 포트 8080이 분리됩니다. Docker quick start 예시는 8080, 8848, 9848 포트를 publish합니다.

운영망에 바로 붙이기보다 작은 테스트로 좁혀 보는 편이 낫습니다. 첫 검증은 설치 사실, 포트 분리, MCP 등록 가능성을 나눠 확인하는 방식이 적절합니다.

1. JDK 17+가 있는 내부 테스트 머신에서 Nacos 3.2.2 standalone 또는 Docker quick start를 실행합니다.
2. Console 8080 접속과 Server API 8848 응답을 따로 확인합니다.
3. 샘플 MCP Server를 Spring AI Alibaba 또는 Nacos MCP Wrapper Python 경로로 등록할 수 있는지 봅니다.
4. Nacos MCP Router를 `uvx nacos-mcp-router@latest` 또는 Docker로 실행하고 `NACOS_ADDR`, `NACOS_USERNAME`, `NACOS_PASSWORD` 환경 변수를 분리합니다.
5. Claude, Cline, CherryStudio 같은 MCP client는 문서가 말하는 연결 가능성 범위 안에서만 테스트합니다.

콘솔 접속 성공만으로는 부족합니다. 인증을 켜지 않았을 때 어떤 MCP Server가 노출되는지, namespace를 나눴을 때 검색 범위가 어떻게 달라지는지, 잘못 올린 prompt나 skill을 offline으로 내릴 수 있는지를 같이 확인해야 합니다.

 

 

 

운영 모델: 무엇을 레지스트리에 넣고 누가 승인할까

 

운영 모델은 namespace, resource type, resource name, version, status, owner, review state, latest label, rollback path를 기본 필드로 잡는 편이 좋습니다. Prompt와 Skill은 자주 바뀌고 감사가 필요한 리소스라 draft, reviewing, reviewed, online, offline 상태를 운영 규칙으로 연결해야 합니다.

Nacos의 AI Resource Lifecycle 문서는 prompt, skill, AgentSpec 같은 AI resource가 namespace, resource type, resource name으로 식별되고 draft, reviewing, reviewed, online, offline 상태와 latest label을 가진다고 설명합니다. 개발자에게는 입력 칸이 늘어나는 일처럼 보이지만, 운영팀에는 장애 대응과 회수를 위한 공통 언어가 됩니다.

처음부터 필드를 많이 늘리면 레지스트리 자체가 짐이 됩니다. 초기 기준은 아래 정도면 충분합니다.

필드	왜 필요한가
`namespace`	개발, 스테이징, 운영, 고객사별 MCP 노출 범위를 나눕니다.
`resource type`	MCP Server, Prompt, Skill, AgentSpec을 같은 목록에서 구분합니다.
`owner`	장애나 권한 이슈가 생겼을 때 책임 팀을 찾습니다.
`version`과 `latest label`	에이전트가 사용한 버전을 추적하고 롤백 판단에 씁니다.
`review state`	draft, reviewing, reviewed, online, offline 상태를 배포 승인과 연결합니다.
`test command`	Router나 MCP client에서 실제 호출 가능 여부를 반복 검증합니다.

Git 저장소는 코드 리뷰와 변경 이력에 강합니다. Nacos Registry는 실행 중인 도구를 발견하고 상태를 바꾸는 운영 콘솔에 가깝습니다. 소스와 리뷰는 Git에 두고, 등록과 배포 상태는 Nacos에서 보는 구성이 자연스럽습니다.

 

도입하면 안 되는 조건과 주의할 점

 

MCP 서버가 몇 개 없거나 승인·감사 요구가 약한 팀에는 Nacos AI Registry가 무겁습니다. public network 노출, 인증 미설정, develop 브랜치 기능을 stable로 오해하는 상황, 모든 MCP client와 완전 호환된다는 가정도 피해야 합니다.

Nacos Quick Start와 Docker Quick Start는 standalone 모드 테스트를 빠르게 시작하게 해줍니다. production에서는 cluster mode와 authentication enabled 구성을 권장하고 public network 노출을 피하라는 경고가 붙습니다. AI Registry까지 얹으면 이 경고는 더 무겁습니다. MCP 서버 목록은 내부 도구 목록이고, prompt와 skill은 업무 자동화의 실행 재료가 될 수 있기 때문입니다.

아래 상황에서는 운영 적용을 미루는 편이 안전합니다.

• MCP Server가 개인 로컬 설정 몇 개 수준이면 Nacos MCP Registry는 무겁습니다.
• Nacos 3.x 운영 경험이 없고 JDK 17, 8080/8848/9848 포트, 인증, cluster 구성을 관리할 사람이 없다면 먼저 운영 주체부터 정해야 합니다.
• 2026년 6월 develop 브랜치 커밋을 보고 안정 릴리스 기능처럼 배포하면 안 됩니다.
• 프롬프트나 스킬에 고객 데이터, 내부 토큰, 민감한 시스템 명령이 섞인다면 review state와 감사 로그 기준을 먼저 만들어야 합니다.

이 주제를 전사 도입 추천으로 읽으면 곤란합니다. Spring 조직에서 사내 AI 도구가 늘어나고, 누가 어떤 MCP Server와 Prompt를 운영 버전에 올렸는지 이미 헷갈리는 단계라면 그때 Nacos를 테스트 후보로 올리는 정도가 맞습니다.

 

 

 

읽고 남긴 판단

 

Nacos는 개인 개발자의 가벼운 MCP 실험보다 Java/Spring 기반 팀의 내부 AI 도구 등록소에 더 어울립니다. 이미 Nacos나 Spring Cloud 운영 경험이 있는 팀이 MCP 서버, Prompt, Skill의 버전과 승인 상태를 묶고 싶을 때 먼저 테스트할 만합니다.

2026-06-13 기준 별 33,019개도 눈에 띄지만, 이 저장소에서 더 볼 부분은 repository topics와 3.2.x 문서에 AI Registry, MCP Registry, Skill Registry, Prompt Registry가 같이 잡힌다는 점입니다.

Spring Boot 서비스가 많고, 사내 AI 에이전트가 여러 MCP 서버를 호출하고, 프롬프트와 스킬의 승인 이력을 남겨야 하는 팀이라면 Nacos를 테스트 후보에 올려도 됩니다. 개인 자동화, 소규모 PoC, 단일 MCP 서버 운영이라면 Nacos보다 MCP client 설정 파일과 Git 리뷰가 더 빠릅니다.

내 기준으로는 등록, 발견, 권한, 버전, 회수 중 두세 가지가 이미 문제로 올라왔을 때만 서버형 레지스트리를 꺼낼 차례입니다. 아직 그 부담이 없다면 Nacos보다 Git과 로컬 MCP 설정이 덜 번거롭습니다.

 

자주 묻는 질문

 

Q. Nacos는 원래 서비스 디스커버리 도구인데 MCP registry 후보로 볼 근거가 있습니까?
A. 공식 README의 출발점은 service discovery, configuration, DNS, metadata management입니다. 다만 최신 문서와 topics가 MCP Servers, Prompts, Skills, AgentSpecs 관리로 확장되고 있어 기존 서비스 레지스트리 사고방식을 AI 리소스 레지스트리에 적용하는 후보로 읽힙니다.

Q. Nacos 현재 안정 버전 기준 먼저 확인해야 할 기능은 무엇입니까?
A. JDK 17+에서 Nacos Server와 Console을 실행하고 Console 8080, API 8848 분리를 먼저 확인하는 것이 좋습니다. 그다음 MCP, Skill, AI resources 관련 콘솔 경험과 AI Registry import, discovery, publishing, subscription, security 개선을 3.2.2 릴리스 노트 기준으로 점검합니다.

Q. Spring Cloud 팀의 가장 작은 첫 테스트는 무엇입니까?
A. 내부 테스트 환경에서 Nacos 3.2.2 standalone 또는 Docker quick start를 띄운 뒤, 샘플 MCP Server를 Spring AI Alibaba 또는 Nacos MCP Wrapper Python 경로로 등록합니다. 이어서 Nacos MCP Router가 해당 서버를 찾는지 확인하면 됩니다.

Q. Skill Registry와 Prompt Registry는 Git 저장소와 어떤 차이가 있습니까?
A. Git은 소스 변경과 리뷰 이력을 남기기에 좋습니다. Nacos의 Skill Registry와 Prompt Registry는 namespace, version, review state, online/offline, latest label 같은 운영 상태를 붙여 실행 리소스의 배포와 회수를 관리하는 쪽에 가깝습니다.

Q. Nacos AI Registry 도입을 미뤄야 하는 경우는 언제입니까?
A. MCP 서버가 몇 개 없고 승인·감사 요구가 약하다면 미루는 편이 낫습니다. 인증, cluster, internal network, namespace, review workflow를 운영할 준비가 없거나 develop 브랜치 커밋을 안정 기능처럼 쓰려는 상황도 도입 보류 조건입니다.

함께 읽으면 좋은 글

 

• MinerU GitHub 추천: PDF·DOCX를 RAG·Agent용 데이터로 바꾸는 문서 파서 — GITHUB 추천
• LLaMA Factory GitHub 추천: 최신 오픈 LLM을 파인튜닝하는 실무형 도구 — GITHUB 추천
• Goose GitHub 추천: AI 코딩 에이전트의 프롬프트 인젝션 방어까지 살펴보기 — GITHUB 추천
• rtk-ai/rtk GitHub 추천: AI 코딩 도구 토큰 비용을 줄이는 CLI 프록시 실험 — GITHUB 추천
• repowise GitHub 추천: AI 코딩 에이전트에 코드베이스 지식그래프와 건강도 붙이기 — GITHUB 추천

참조 링크

 

• alibaba/nacos GitHub repository — 공식 저장소, README 목적, owner/repo, topics, 기본 프로젝트 성격 확인
• GitHub REST API metadata for alibaba/nacos — 2026-06-13 기준 stars, forks, issues, pushed_at, license, topics 확인
• Nacos 3.2.0 release notes — AI Registry expansion 흐름의 초기 릴리스 근거
• Nacos 3.2.2 release notes — 추천 안정 버전, AI Registry 개선, Java 요구 조건 확인
• Latest Nacos commit 4bec8b0 — MCP SDK 0.17.0에서 0.18.2로 올리는 develop 브랜치 활동 신호
• Nacos AI resource lifecycle commit 4914209 — AI resource latest label, prompt publish lifecycle, skill zip descriptor parsing 관련 후속 작업
• Nacos Quick Start — 3.2.2 안정 버전 안내, JDK 17+, standalone 테스트와 production 권고 확인
• Nacos Docker Quick Start — Docker 테스트 경로와 포트 publish 예시 확인
• Nacos System Configurations — Nacos 3.x Console 8080과 Server API 8848 분리 확인
• MCP Server auto-registers and Discovery Manual — Nacos를 MCP Registry로 쓰는 등록·발견·연동 경로 확인
• Skill Registry — Nacos 3.2.0 이후 Skill Registry 범위와 역할 확인
• Prompt Registry — 프롬프트 버전 관리, 롤백, 감사 필요성 확인
• AI Resource Lifecycle — namespace, resource type, status, latest label 기반 운영 모델 확인
• Nacos MCP Router User Guide — uvx, Docker, NACOS_ADDR, NACOS_USERNAME, NACOS_PASSWORD 기반 Router 테스트 확인
• Nacos 3.2 Skill Registry article — Skill Registry를 기업용 AI capability governance 관점에서 설명한 보조 자료