아무도 당신 로봇의 PR을 검토하지 않는다

전체 산업이 AI 에이전트가 자신의 작업에 대해 거짓말한다는 것을 알아냈다. 아무도 입 밖에 내지 않는 부분은, 홈랩(homelab)에서는 그 거짓말과 당신의 인프라 사이에 아무것도 존재하지 않는다는 것이다.

Jason Lemkin은 AI 에이전트와 함께 앱을 만드는 데 9일이 걸렸다. 그는 에이전트에게 코드를 동결하라고 지시했다... 더 이상의 변경 없음, 손대지 마라. 하지만 에이전트는 어쨌든 그것을 변경했고, 그의 프로덕션 데이터베이스를 삭제한 다음, 그가 방금 파놓은 구멍을 채우기 위해 약 4천 개의 가짜 레코드를 생성했다. 그리고 그에게 무슨 일이 있었는지 물었을 때, 그것은 이야기를 해주었다. 이 이야기는 큰 화제가 되었다. 마땅히 그래야 했다.

이것만 그런 것이 아니다. 이번 봄에 발표된 보고서에 따르면 AI가 생성한 코드의 43%는 여전히 프로덕션에서 수동 디버깅이 필요하다... QA를 통과하고, 스테이징(staging)을 통과한 후에도 그렇다. 또 다른 보고서는 AI가 작성한 코드가 인간의 코드보다 대략 1.7배 높은 결함률을 보였다. 2월에 돌던 문구는 [

Lemkin에게는 잃을 수 있는 _운영 데이터베이스 (production database)_가 있었습니다... 이는 그에게 환경 (environments)이 있었다는 것을 의미하며, 이는 어딘가 위층에 스테이징 계층 (staging tier)과 배포 파이프라인 (deploy pipeline), 그리고 결국에는 이를 알아차리는 사람이 있었다는 것을 의미합니다. 43%라는 수치는 QA 게이트 (QA gates)와 우리가 예전에 코드 리뷰 (code review)라고 불렀던 것, 즉 머지 (merge)되기 전에 누군가 읽어주기를 기다리며 놓여 있는 풀 리퀘스트 (pull request, PR)를 갖춘 업체들로부터 나온 것입니다. AI 신뢰성에 관한 기업 전체의 논의는 가드레일 (guardrails) 위에서 이루어지는 논의입니다. 그들은 에이전트 (agent)가 거짓말을 한다는 것을 발견하고 있으며, 가드레일이 이를 잡아내고 있습니다. 늦고, 비용이 많이 들며, 세 번의 재배포 (re-deploys)를 거친 뒤에야... 하지만 잡아내고 있는 것이죠.

당신에게는 그런 것이 전혀 없습니다.

당신은 바로 그 목적 때문에 에이전트를 당신의 홈랩 (homelab)에 연결했습니다. 에이전트는 compose 파일을 작성합니다. .env 파일을 수정합니다. 프록시 설정 (proxy config)을 건드립니다. 시스템을 강화하고, 백업을 실행하고, 완료되었다고 당신에게 알려주어야 합니다. 당신의 차고에는 스테이징 계층 (staging tier)이 없습니다. QA도 없습니다. 풀 리퀘스트 (pull request)도 없고 그것을 읽어줄 사람도 없습니다. 오직 당신과, 초록색 대시보드, 그리고 모든 것이 괜찮다고 방금 말한 로봇뿐입니다.

아무도 당신 로봇의 PR을 검토하지 않습니다. 그렇다면 누가 그 로봇이 거짓말쟁이라고 말할 수 있을까요?

당신의 모니터링 (monitoring)도 아닙니다. 홈랩 가이드를 읽어보세요... "내 AI 서비스가 정상 작동 중인지 어떻게 알 수 있나요?"라는 질문에 대한 표준적인 조언은 Uptime Kuma를 그 서비스들에 연결하고 응답 여부를 확인하는 것입니다. 바로 거기에 함정이 있습니다, 권장되는 베스트 프랙티스 (best practice)에 그대로 박혀 있죠. 응답하는 것이 곧 작동하는 것은 아닙니다. 어떤 대상은 당신에게 응답할 수는 있지만 문 뒤에서는 완전히 죽어 있을 수 있으며... 당신의 모니터는 그것을 초록색으로 표시하고 상황을 종료할 것입니다.

저는 증거를 가지고 있습니다. 사실 네 가지나 있죠... 지난번에 Everything's Green Cap…에서 전체 세트를 작성했습니다. 여기 여전히 저를 괴롭히는 사례가 있습니다.

Docker 호스트의 방화벽을 강화했습니다... 모두가 추천하는 도구인 ufw와 더불어 ufw-docker를 사용했습니다. 일반적인 ufw는 Docker가 공개한 포트를 인식조차 할 수 없기 때문입니다 (Docker는 사용자의 규칙 아래에 자체적인 iptables를 작성합니다... 이는 별도의 주제입니다). 실행해 보았습니다. 결과는 깨끗했습니다. 방화벽: 녹색(green). 하지만 ufw-docker는 모든 RFC1918을 허용하는 기본 설정을 포함하여 배포됩니다... 즉, 여러분의 전체 사설 범위인 10.x, 192.168 등 전부를 말이죠. 평면적인 LAN(flat LAN) 구조에서 그것은 방화벽이 아닙니다. 그것은 금고라고 주장하는 방충망입니다. 상태는 녹색이지만, 집은 열려 있었고, 그 무엇도 저에게 알려주지 않았습니다. 규칙은 "활성(active)" 상태였습니다. 그 규칙은 거짓이었습니다.

금고라고 주장하는 방충망.

이것은 단발적인 사건도 아니었습니다. 컨테이너 내부의 실제 서비스는 외부에서 볼 수 없는 루프에 빠져 crash-loop(충돌-재시작 반복)를 돌고 있는데, 컨테이너는 "업(up)" 상태라고 보고하는 경우도 있었습니다. 하루 종일 핑(ping)에 응답하는 서비스... ICMP는 정상이고 괜찮지만... 정작 읽어야 할 패킷 큐(packet queue)는 죽어 있고 모든 실제 연결은 타임아웃(timeout)이 발생하는 경우 말입니다. 그것이 바로 여러분의 가동 시간(uptime) 로그가 "모두 정상"이라고 기록하는 바로 그 실패 사례입니다. 그리고 맞습니다... 실제로 수행하지 않은 작업을 수행했다고 보고하는 에이전트(agent)도 있었습니다. Lemkin의 4,000개 가짜 기록의 홈랩(homelab) 규모 버전이라고 할까요. 폭발 반경(blast radius)은 더 작지만, 거짓말은 동일합니다.

그 모든 것들이 녹색으로 통과되었습니다. 만약 제가 대시보드를 믿었다면, 그 모든 것들은 계속해서 통과되었을 것입니다.

그래서 여기 하나의 규율이 있습니다. 이것은 프레임워크도 아니고 여러분이 살 수 있는 제품도 아닙니다. 이것은 태도(posture)입니다.

"살아 있는가(is it up)"라고 묻는 것을 멈추십시오. "제대로 작동하고 있는가(is it doing the thing)"라고 물으십시오. 그런 다음, 그것이 고장 나는 측면에서 직접 증명하십시오.

방화벽 규칙을 읽지 마십시오... 차단되어야 할 곳에서, 차단되어야 할 연결을 시도하고, 그것이 실패하는 것을 지켜보십시오. 종료 코드가 0(exit zero)으로 끝난 백업 작업(backup job)을 믿지 마십시오... 그것을 실제 환경에 복구해 보고, 실제로 복구되는지 지켜보십시오. 에이전트(agent)가 자신이 작성했다고 주장하는 설정(config)을 작성했다고 믿지 마십시오... 현재 살아있는 상태와 에이전트가 말하는 것을 바이트(byte) 단위로 대조(diff)하십시오. 그리고 그 바이트만이 방 안에서 진실을 말하는 유일한 존재라고 가정하십시오. 헬스 엔드포인트(health endpoint)는 로봇의 서사(narration)입니다. 동작(behavior)은 사실(fact)입니다. 두 가지가 일치하지 않을 때, 동작이 승리합니다. 매번 말입니다.

상태(Status)는 서사입니다. 동작(Behavior)은 사실입니다.

저는 대부분의 작업을 수행하는 AI 스택이 가득 찬 40피트 피프스 휠(fifth wheel) 트레일러에서 자체 호스팅되는 SOC(Security Operations Center)를 운영하고 있습니다. 저는 AI가 나쁘다고 말하는 사람이 아닙니다... AI는 제 장비에서 일어나는 일의 약 70%를 수행하며, 저는 다른 방식은 원하지 않습니다. 저는 AI가 거짓말을 한다고 말하는 사람입니다. 끊임없이, 쾌활하게, 그리고 초록색 불빛(green light)을 띄우며 말이죠. 그리고 그 거짓말과 제 인프라(infrastructure) 사이를 가로막고 있는 유일한 존재는, 그것의 말을 그대로 믿기를 거부하고 직접 확인하는 저뿐입니다.

이에 대한 기업용(enterprise) 해답은 이미 출시되고 있습니다. 바로 AI SRE를 덧붙이는 것입니다... 관측성(observability)을 바탕으로 추론하며 상황을 처리하고 있다고 당신을 안심시키는 에이전트 말입니다. 첫 번째 로봇을 지켜보며 두 번째 로봇이 설명해 주는 더 많은 초록색 불빛들 말이죠. 분명 괜찮을 겁니다.

홈랩(homelab)의 해답은 더 오래되었고 더 저렴하며 확장성(scale)은 없지만, 괜찮습니다. 당신은 확장을 목표로 하는 것이 아니니까요. 당신은 '옳은 것'이 되려고 하는 것입니다. 당신은 실패의 관점에서 그 대상을 바라봅니다. 필요하다면 소리 내어 말하면서 말이죠.

직접 하거나(DIY), 아니면 죽거나(die). 여기에는 당신이 직접 만든 로봇조차 믿지 않는 것이 포함됩니다.