“그 도구는 없습니다”라고 AI가 말하는 진짜 이유는 DDNS였다

서론

집 서버에서 MCP 서버를 몇 개 띄워놓고, Claude나 ChatGPT가 호출하도록 만들고 있다.

서버 본체도 감시 장치도 AI에게 구성하게 하여, 나름대로 안정적으로 운용하고 있다고 생각했다.

그런데 어느 날 Claude가 말한다.

“그 도구를 찾을 수 없습니다.”

어? 방금 전까지 쓸 수 있었잖아.

세션을 재시작하면 다시 사용할 수 있다.

잠시 후 다시 “보이지 않습니다”.

재시작. 해결됨.

“가끔 사라지는 것”이 가장 까다롭다

이 패턴은 원인 파악(Troubleshooting)이 번거로워 진전이 없다.

앱은 살아있음
포트도 listening 상태
헬스 체크(Health Check)도 통과함
하지만 AI 측에서는 “도구가 등록되어 있지 않다”고 함

서버 로그를 봐도 딱히 다운된 것은 없다.

클라이언트 측 로그를 봐도 접속을 시도한 흔적조차 남아있지 않을 때가 있다.

이상하다 생각하면서도, 몇 달 동안 “재시작하면 고쳐지니까 뭐 괜찮겠지”라며 넘겨왔다.

이러한 확률적인 실패는 인간이 다룰 때는 “아, 또 실패했네” 하고 넘길 수 있다. 재로드(Reload) 버튼을 누르면 끝이니까.

AI에게 상시 호출하게 하면, 변동성이 현저해진다

이것이 AI에게 MCP로서 등록되는 순간, 이야기가 달라진다.

세션이 시작될 때마다 AI는 등록된 MCP 서버에 연결을 시도한다.

이름 해결(Name Resolution)을 하고, TLS 핸드셰이크(TLS Handshake)를 하고, 도구 목록을 가져와서 컨텍스트(Context)에 올린다.

이 과정 중에 단 한 단계라도 실패하면, 해당 세션 내내 “도구가 보이지 않는” 상태가 된다.

인간이 직접 호출하던 시절에는 “아, 실패했다. 다시 누르자”로 끝났던 확률적인 실패가, AI의 세션 경계와 딱 맞아떨어지면 도구가 애초에 존재하지 않는 것과 동일한 상태로 대화가 시작된다.

그리고 AI 측에서는 “그 도구는 없습니다”라고만 답하기 때문에, 인간 입장에서는 원인을 알 수 없다.

가장 밑바닥 계층을 의심했다

“네트워크”, “TLS”, “서버” 등을 차례대로 의심했고, 마지막에 DNS가 남았다.

집 서버는 고정 IP가 아니기 때문에 DDNS(dynv6.net)를 사용하고 있었다. 고정 IP가 아닌 사람들의 정석이다. 오랫동안 도움을 받아왔다.

그 DDNS가 가끔 이름 해결에 실패하고 있었다.

구체적으로는, dig로 호출했을 때 NXDOMAIN이나 SERVFAIL이 반환되는 순간이 있었다. 프로바이더 측의 문제인지, 상류(Upstream) 캐시 문제인지, 레이트 리미트(Rate Limit) 때문인지는 확실히 알 수 없다.

몇 분 후 다시 dig를 하면 아무 일도 없었다는 듯 정상적으로 통과한다.

……이것인가.

“몇 분 전에는 통과했던 이름이 지금은 통과하지 않는다”는 현상이 확실히 일어나고 있었다.

그리고 DDNS 해결이 끊기는 순간에 AI의 세션이 시작되면, 도구는 사라져 있다.

아마 이것일 것이라고 짐작했다.

DNS를 의심한다는 생각은 지금까지 없었다

이 사실을 깨달았을 때, 나 자신도 꽤 놀랐다.

나는 지금까지 DNS를 의심한다는 발상이 거의 없었다.

이름 해결이란 브라우저 주소창에 무언가를 입력하고, 연결되느냐 안 되느냐, 그뿐이었다.

“가끔 실패한다”는 모드가 존재한다는 사실 자체를 의식하지 못하고 있었다.

DNS라는 레이어의 존재에 의식이 향해 있지 않았다.

이름 해결이 “작동하느냐 고장 났느냐”의 이지선다가 아니라, **“작동하기도 하고 작동하지 않기도 하는 것”**이라는 인식이 애초에 내 안에 없었다.

AI에게 매일 호출하게 하고 나서야 비로소 그곳에 의식이 향하게 된 것이다.

Cloudflare Tunnel이라는 선택지

여기서 Cloudflare Tunnel을 찾아냈다.

고정 IP가 아닌 서버에서 Cloudflare의 에지(Edge)로 직접 outbound로 상설 연결을 맺는다. 클라이언트는 Cloudflare의 DNS로 찾아 Cloudflare 에지에 연결될 뿐이다. 나머지는 tunnel이 집까지 운반해 준다.

즉, 내 서버는 더 이상 DDNS로 이름을 노출할 필요가 없다.

Cloudflare의 DNS가 이름을 가지고, Cloudflare가 출구가 되어준다.

자신의 도메인(kitepon.dev)을 Cloudflare에 NS 등록하고, 서브도메인별로 tunnel route를 설정하기만 하면 된다. 고정 IP는 필요 없다. 포트 개방도 필요 없다. DDNS 업데이트 스크립트도 필요 없다.

덤으로 사라진, 2가지 운영 부채

이전하면서 깨달은 부작용이 두 가지 있었다. 둘 다 보너스 같은 것이지만, 은근히 효과가 크다.

첫 번째: hairpin NAT 대책을 위한 /etc/hosts 순회 작업에서 해방되었다.

나는 SoftBank의 10G 회선을 사용하고 있다. 이것은 hairpin NAT가 작동하지 않는다.

자신의 공개 도메인을 집 안의 LAN(Local Area Network) 내부에서 호출하려고 하면, 외부로 나갔다가 다시 돌아오는 경로를 구성할 수 없어 막히게 된다.

지금까지의 대책은 단말별, 컨테이너별, WSL별로 /etc/hosts에 내부 주소를 일일이 적어주는 것이었다. 이것이 은근한 운영 부채(Operational Debt)가 되어, 새로운 단말을 늘릴 때마다, 새로운 컨테이너를 세울 때마다 hosts를 업데이트해야 하는 강박에 시달려야 했다.

Cloudflare Tunnel을 사용하니, 내부에서 호출하든 외부에서 호출하든 동일한 경로(Cloudflare 경유)가 된다. hosts의 특별 취급을 전부 없앴다.

두 번째: SoftBank 회선에서 불정기적으로 inbound 차단을 당하는 경우가 있었다.

이것 또한 오랫동안 은근히 골칫거리였던 문제다. SoftBank 회선 때문인지, 홈 게이트웨이(Home Gateway) 때문인지, 아니면 상류의 보안 대책 때문인지 원인은 특정하지 못했지만, 외부에서의 접속이 연결되지 않는 시간대가 가끔 있었다.

Cloudflare Tunnel은 자택 서버에서 outbound(아웃바운드)로 연결하는 상설 접속 방식이므로, ISP(인터넷 서비스 제공업체) 측에서 보면 '집에서 외부로 향하는 통신'만 발생한다. 구조적으로 inbound(인바운드) 측에서 발생하는 차단과 상관이 없게 되었다.

이행 후

AI들이 "도구를 찾을 수 없습니다"라고 말하지 않게 되었다.

이것은 관측된 값일 뿐, 절대적인 보증은 아니다. Cloudflare 측도 완벽하지는 않을 것이다.

다만, 직접 운영하던 DDNS(Dynamic DNS)의 불안정성과 상용 CDN(Content Delivery Network)의 에지 가용성(Edge Availability)은 차원이 다르다. 그 점은 인정할 수밖에 없다.

그리고 부차적인 효과로 hosts 수정 작업과 SoftBank 측의 차단 문제도 사라졌기에, AI가 "접속할 수 없다"라고 말하는 트리거가 통째로 줄어들었다.

배운 점

AI에게 매일 작업을 시켜보며, DNS를 의심해야 한다는 사실을 깨달았다.

내 안에서 DNS는 '브라우저의 주소창'을 위한 메커니즘이었다.

인간이 직접 접속할 때는 가끔 실패해도 크게 신경 쓰이지 않는다.

하지만 AI에게 장시간 태스크(Task)를 맡기게 되면, 그동안은 그냥 넘길 수 있었던 미세한 변동(Fluctuation)이 치명적으로 작용한다.

24시간 계속 움직이는 무언가를 올려두면, 발밑의 계층부터 차례대로 거짓이 벗겨져 나간다.

내 자택 서버에서 가장 먼저 벗겨진 것이 DNS 계층이었다는 것뿐이다.

그리고 그 벗겨진 계층을 다시 붙일 수 있는 수단은, 이미 5년도 더 전부터 무료로 눈앞에 있었다. Cloudflare Tunnel이 무료가 된 것은 2020년이다. 단지 깨달을 계기가 없었을 뿐이었다.

아마 다음에는 다른 계층이 벗겨질 것이다.

그때 다시 쓰겠다.