삼성전자 박수홍 그룹장님이 공유한 글을 공유합니다.
" 실제 Agent 를 Discovery 하기 위해 인터넷의 DNS 를 활용하여 DNS-AID 를 오픈소스로 공개"
이에 대해서, 저희 클라우드브로 AI와 대화한 내용을 아래 정리해서 공유드립니다.
AI 에이전트와 MCP 서버가 늘어날수록 “어디에 무엇이 있는지”를 찾고 검증하는 문제가 커집니다. 이 글에서는 Linux Foundation의 DNS-AID가 제안하는 해법을 정리하고, 제가 대화에서 고민했던 운영 복잡도(거버넌스·DNS 변경관리) vs 보안/정책 트레이드오프를 “DNS는 최소 발견” 관점에서 풀어봅니다.
DNS-AID가 풀려는 문제: 에이전트 발견의 분절과 중앙집중 병목
에이전트 생태계가 커지면 팀/벤더별로 서로 다른 방식의 디스커버리(레지스트리, 하드코딩된 통합, 사내 위키…)가 난립하기 쉽습니다. 이 상태에서는 다음 문제가 반복됩니다.
- 상호운용성 저하: 어떤 에이전트가 어떤 프로토콜(MCP 등)로 어디에 있는지 표준적으로 알기 어렵습니다.
- 신뢰의 단절: “진짜 그 에이전트가 맞는가?”를 검증하는 방식이 제각각입니다.
- 중앙 레지스트리 의존: 편하긴 하지만 단일 장애점(SPOF), 벤더 락인, 정책/검열 지점이 생기기 쉽습니다.
DNS-AID는 이 지점을 “웹-네이티브한 인프라”인 DNS로 풀어보자는 제안입니다. Linux Foundation이 오픈소스 프로젝트로 발표했고, 중앙 레지스트리 없이도 AI 에이전트/MCP 서버를 게시·발견·검증할 수 있는 벤더 중립 프레임워크를 지향합니다. 또한 Python SDK, CLI, MCP 서버 등 레퍼런스 구현을 제공해 다양한 DNS 제공자 환경에서 동작하도록 설계되었습니다.
핵심 아이디어: DNS를 ‘디렉터리 + 신뢰 앵커’로 확장
DNS-AID의 메시지를 한 문장으로 줄이면 이렇습니다.
- “에이전트를 찾기 위한 최소 단서를 DNS에 두고, 표준 방식으로 검증 가능하게 만들자.”
여기서 중요한 포인트는 “DNS에 무엇까지 넣을 것인가”입니다. 저는 운영 관점에서 다음 두 전략이 갈린다고 봤습니다.
전략 A) DNS에 메타데이터를 최대한 싣는다
- - 장점: DNS만 조회하면 필요한 정보를 많이 얻을 수 있어 단순해 보입니다.
- - 단점: 레코드 변경 빈도 증가, TTL/캐시로 인한 롤백 지연, 레코드 설계 복잡도 증가, 권한/승인 체계가 꼬이기 쉽습니다.
전략 B) DNS는 ‘최소 발견(minimal discovery)’만 담당한다
- - 장점: DNS 변경을 “드물고 신중하게” 만들 수 있어 운영 리스크가 줄어듭니다.
- - 단점: DNS가 가리키는 다음 계층(메타데이터/검증/정책) 과의 정합성(버전, 폐기, 키 회전)을 별도로 설계해야 합니다.
대화 속 제 결론은 전략 B에 더 가깝습니다.
즉, “DNS에 대한 체계(거버넌스/변경관리)가 잘 만들어진다면, DNS는 최소한의 발견 역할만 해도 충분하다”는 쪽입니다.
운영의 본질: 보안은 DNS만으로 완결되지 않고, ‘거버넌스’가 난이도를 만든다
DNS 기반 발견이 확산되면 보안(검증·정책)이 강화될 것 같지만, 현실에서는 운영 복잡도가 함께 커집니다. 제가 특히 크게 보는 트레이드오프는 다음입니다.
- 보안 측면의 요구: 악성 에이전트 등록 방지, 키 회전, 인증서 만료, 긴급 차단, 감사 로그
- 운영 측면의 현실: “누가 어떤 레코드를 바꿀 수 있나?”, 승인 절차는?, TTL 때문에 차단/롤백이 늦어지지 않나?, 멀티테넌트 환경에서 네임스페이스는 어떻게 나누나?
여기서 DNS는 강력하지만, 동시에 조직의 변경관리 프로세스 위에 올라타야 합니다. 그래서 DNS-AID 도입 시에는 기술보다도 아래 항목을 먼저 합의해야 합니다.
- 권한 모델: 어떤 팀이 어떤 zone/subdomain을 소유하는가?
- 레코드 범위: DNS에는 “포인터(최소 정보)”만 둘 것인가, 아니면 능력/정책까지 넣을 것인가?
- 변경 빈도/TTL 정책: 긴급 차단이 필요할 때 TTL 전략은?
- 검증 체계: 서명/검증, 감사, 롤백을 어떤 도구와 프로세스로 묶을 것인가?
“IPv6로 확장성 해결?”이 바로 답이 아닌 이유
대화 중에 저는 “에이전트가 많아지면 IPv6 도입이 답 아닐까?”라는 생각도 했습니다. 그런데 정리해보면 DNS-AID의 병목은 보통 IP 주소 부족이 아니라 다음에 가깝습니다.
- 이름 → 엔드포인트 매핑의 변경관리
- 어떤 주체를 신뢰할지에 대한 검증/키 관리
- 누가 바꿀 수 있는지에 대한 거버넌스
- 장애 시 얼마나 빨리 차단/전환할지에 대한 운영 민첩성(TTL/캐시)
게다가 IPv6는 듀얼스택, 방화벽/ACL, 관측성(로그/추적), 역방향 DNS 등 새 운영 표면적을 늘릴 수 있습니다. 즉 “주소공간 확장”만 보고 들어가면, 발견/신뢰 문제를 직접 해결하지 못한 채 복잡도만 커질 수도 있습니다.
모든 트래픽이 중앙 관문(gateway)을 통과한다면: DNS는 더 ‘가벼워져야’ 합니다
대화에서 제 사용 시나리오는 “모든 트래픽은 중앙 관문을 통해서”라는 전제였습니다. 이 구조에서는 중요한 결론이 하나 나옵니다.
- 외부에서 보이는 엔드포인트는 에이전트 각각이 아니라 관문입니다.
- 따라서 DNS-AID에 담아야 할 DNS 레코드도 “에이전트의 실제 주소”보다는 관문으로의 라우팅 단서가 됩니다.
- 실질적인 보안/정책/관측 복잡도는 DNS가 아니라 관문 설정(인증/인가, 레이트리밋, 테넌시 라우팅, 키/인증서 회전, 감사)에 모입니다.
즉, “DNS는 최소 발견”으로 두고, 다음은 관문 계층에서 책임지는 설계가 자연스럽습니다.
예시 설계(개념)
- DNS:
agent.example.com→gateway.example.com(또는 특정 지역 게이트웨이) - 게이트웨이: 요청의 토큰/서명/조직/정책에 따라 내부의 실제 에이전트로 라우팅
- 메타데이터: HTTPS well-known 엔드포인트나 서명된 문서로 제공(버전/폐기/키회전 관리)
코드는 DNS-AID 레퍼런스 구현(Python SDK/CLI/MCP 서버)을 활용하게 되겠지만, 설계상 포인트는 “DNS를 많이 똑똑하게 만들기”가 아니라 DNS 변경을 최소화하고, 런타임 정책집행을 게이트웨이로 모으는 것입니다.
제가 얻은 인사이트: “DNS는 신뢰의 시작점, 운영의 끝판왕”
DNS-AID의 방향성은 꽤 설득력이 있습니다. 중앙 레지스트리 없이도 표준 기반으로 발견/검증을 하려면, 이미 전 세계가 쓰는 DNS를 신뢰/디렉터리 계층으로 끌어오는 건 자연스럽습니다.
다만 도입 난이도는 기술보다 운영에서 터질 가능성이 큽니다. 제가 지금 시점에서 내린 결론은 이렇습니다.
- DNS는 최소 발견으로 제한하는 편이 운영에 유리합니다.
- 대신 신뢰/정책/긴급차단은 게이트웨이/메타데이터 계층에서 완결해야 합니다.
- 결국 가장 큰 트레이드오프는
“검증·정책 강화를 위해 DNS를 자주/많이 바꿀수록 운영 복잡도가 폭증한다” 는 점입니다.
마무리
DNS-AID는 “에이전트 웹”을 만들기 위한 발견/신뢰의 공통 기반을 DNS 위에 올리려는 시도입니다. 제 경험상 성공의 관건은 DNS를 만능으로 만들기보다, DNS는 최소 발견 + 나머지는 게이트웨이/서명된 메타데이터로 분리해 운영 가능성을 확보하는 데 있다고 봅니다.