이번 주 AI가 망가뜨린 것 #1: 아무것도 아니다. 세 번이나 나였다

이번 주 에이전트는 아무것도 고장 내지 않았다. 내가 세 가지를 망가뜨렸고, 에이전트는 일주일 동안 그것을 공손하게 증명해 보였다.

설정 환경: 구석에 Proxmox가 설치된 미니 PC 하나와, 쌓여있는 사이드 프로젝트들, 그리고 페어(pair)로 Claude Code를 사용했다.

DNS 문제 발생 (DNS는 정상이었다)

토요일 밤 자정 반 무렵. 집에서 아무것도 해석되지 않자, 나는 당연한 질문을 타이핑했다: "서버의 DNS에 문제가 있는 것 같은데, 확인해 줄 수 있나요?"

3분 후, 판정이 내려졌다. DNS는 정상이었다. 단지 하나의 이름만 열리지 않았는데, 그것은 새로 추가된 모니터링 대시보드였다. 리버스 프록시(reverse proxy)에는 11개의 호스트가 있었고, 그중 이 하나만 빠져 있었다. 그래서 TLS가 unrecognized name 오류와 함께 작동하지 않았다. 설정 계획서에는 5단계로 "UI에서 프록시 호스트 추가"라는 항목이 있었다. 누군가 그것을 건너뛴 것이다. (나였다.)

에이전트 역시 그것을 추가하지 않았다. 프록시에 대한 로그인 권한이 없었기 때문에 설정 파일을 수동으로 수정하는 것을 거부했다. 왜냐하면 프록시가 자체 데이터베이스에서 해당 파일을 재작성하기 때문이다. 정확하고, 약간 짜증 나는 지점이었는데, 그 정도의 자극은 적절했다.

그리고 진짜 장애는 발생했다. 아무것도 해석되지 않던 5분 동안이었다. 로그를 보니:

04:31     서버에서 Tailscale이 외부 주소를 변경함
04:35:09  Mac에서 51개의 DNS 연결이 같은 초에 끊김
          AdGuard: 4일 작동, 재시작 0회, 24시간 동안 업스트림 타임아웃 1회

내 Mac에는 "Tailscale DNS 사용" 기능이 켜져 있었다. 그래서 모든 조회 요청은 노트북을 떠나 다른 국가의 중계기(relay)를 거쳐 터널로 이동하고, 서브넷 라우터(subnet router)를 통해 돌아와 내 의자에서 3미터 떨어진 AdGuard 박스에 도달했다. 중계기가 잠시 불안정해지자 DNS도 함께 문제가 생겼다. 집의 다른 모든 장치들은 AdGuard와 직접 통신했기 때문에 아무것도 눈치채지 못했다.

다른 엔지니어에게 해주고 싶은 말: DNS 서버를 탓하기 전에, 실제로 쿼리가 거치는 경로를 그려보세요. 제 경우엔 경유지가 있었습니다.

메모리 부족 (16 GB가 있었는데)

월요일 저녁이었습니다. "서버에 RAM이 거의 남지 않았어. 뭘 먹고 있는지 찾아서 중단시킬 수 있는 걸 찾아봐."

에이전트는 아무것도 멈추지 않았습니다. 호스트는 31 GB 중 25 GB가 사용되었으며, 메모리 압력은 0이고 5.5 GB가 여유 있었습니다. 이 숫자는 설정 파일 때문에 부풀려진 것이었고, 그 설정 파일은 제가 만든 것이었습니다.

VM            allocated   held on host   guest actually uses
side-project  8 GB        8.3 GB         1.7 GB
render box    6 GB        6.2 GB         0.5 GB   (idle since 2 Oct)
...

모든 VM에 balloon: 0이었습니다. 게스트가 렌더링이나 빌드를 한 후 페이지 캐시를 채우고, 메모리를 다시 반환하지 않아 호스트가 영원히 전체 할당량을 청구하는 식입니다. 그 6 GB 박스는 사이드 프로젝트의 비디오를 렌더링했고, 마지막으로 작동한 건 사흘 전이었습니다.

수정하는 데 5분이 걸렸습니다: 더 작은 할당량에 ballooning을 활성화하고, ARC를 2 GB로 제한하며, 7.8 GB zram 스왑을 추가했습니다. 호스트 사용량이 25 GB에서 14 GB로 줄었고, 16 GB가 여유 공간으로 확보되었습니다. 그러고 나서 제가 말했습니다: "better commit and apply." (더 잘 커밋하고 적용해.)

이 계획은 이미 실행 중인 VM을 만들려고 했습니다. 사이드 프로젝트 VM은 Terraform 상태(state)에 전혀 없었기 때문에, 전체 apply를 하면 현재 작동하는 것 위에 두 번째 사본을 구축했을 것이고, 5개의 LXC 컨테이너를 가져오고(import), 터널 설정을 다시 작성하고, 경로상에서 4개의 DNS 레코드를 추가했을 것입니다. 에이전트는 import 블록을 추가하고, 계정할 수 있는 두 VM에 -target으로 적용한 후 다음 plan에서는 "No changes"가 나왔습니다. 나머지 드리프트(drift)는 여전히 남아있으며, 좀 더 차분한 저녁을 기다리고 있습니다.

다른 엔지니어에게 해주고 싶은 말: 상태(state)는 리포지토리가 스스로에게 들려주는 이야기입니다. 마치 거짓말하는 것처럼 plan을 읽으세요.

문제는 네트워크였습니다 (업타임 때문이었습니다)

어떤 Claude Code 세션은 작동했다. 다른 것들은 매번 재시도할 때마다 ECONNRESET 오류로 죽었다. 나는 작동하는 세션에게 고장 난 세션을 디버깅해 달라고 요청했는데, 이건 내가 쓰게 될 거라고 예상하지 못했던 문장이다.

죽은 세션들에는 스크린샷이 잔뜩 들어 있었다. 정말 많았다. 하나는 28장의 이미지, 약 17MB의 base64 데이터를 포함했고, Claude Code는 매 턴마다 이 모든 것을 다시 전송했다. 정상적으로 작동한 채팅들은 2~9장의 이미지를 담았고, 약 3MB 정도였다. curl 테스트를 해보니: 1MB는 괜찮았고, 20MB도 괜찮았지만, 8MB는 스트림 중간에 HTTP/2 오류로 죽었고, 35MB는 413 오류와 함께 거부되었다. 네트워크 자체에는 문제가 없었다. 다만 수 메가바이트 단위의 업로드가 때때로 실패하는 경우였다.

나는 Anthropic에 이 문제를 보고하고 혹시 보상을 받을 수 있는지 물어봤다. 에이전트는 친절하게도, 해당 바운티(bounty)는 보안 버그를 다루며 이것은 네트워크상의 불편함이라고 설명했다. 그러더니 같은 사진(46장)을 가진 열린 이슈를 찾아내고, 우리의 데이터를 담은 댓글 초안을 작성한 뒤 내가

점심시간 무렵에는 더 큰 세션이 죽었고, 50만 토큰의 컨텍스트가 사라졌으며, /compact 기능도 함께 작동하지 않았습니다. 왜냐하면 압축(compaction) 과정 자체가 동일한 거대한 요청을 보내기 때문입니다. 또 다른 문제로 맥 사용자들의 스레드가 생겼고, 이를 해결한 것은 재부팅이었습니다. 한 사용자는 52일 동안 시스템 가동 시간을 유지했지만, 재시작하자 죽었던 모든 세션 여덟 개가 돌아왔는데, 그중 하나는 826k 토큰에 달했습니다.

그 다음 에이전트가 제 것을 확인했습니다. 102일. 저는 이 숫자에 조용히 자부심을 느끼고 있었습니다.

다른 엔지니어에게 해주고 싶은 말은 이렇습니다: 에이전트는 네트워크가 무죄임을 열 가지 다른 방식으로 증명할 수 있습니다. 하지만 여전히 '껐다가 다시 켜보라'고는 하지 않을 겁니다. 왜냐하면 당신이 에이전트에게 예의 바르지 않은 행동을 하도록 가르치지 않았기 때문입니다.

여러분 차례입니다

이번 주에 당신의 AI 페어링 파트너가 무엇이 자신의 잘못이 아님을 증명하느라 시간을 보냈고, 그게 맞았는지 아닌지 알려주세요.