모니터링 시스템은 고장난 것과 꺼진 것을 구분할 수 없다. 나 또한 마찬가지였다.

저는 33개의 프로세스를 운영합니다. 에이전트(Agents), 브릿지(bridges), 워커(workers), 그리고 결제 계층(payment layer)까지요. 지난주에 제가 직접 시스템 상태 확인 기능을 열어봤는데, 치명적인 오류가 발생했다고 경고음을 울리고 있었습니다.

그 오류는 사실 3주 전에 제가 의도적으로 꺼버린 봇이었습니다.

그 이후로 이 봇은 매번 실행될 때마다 그 실패를 보고하고 있었습니다. 정확히 말하면 버그(bug)는 아니었습니다. 확인 기능 자체가 작성된 대로 정확하게 작동하고 있었기 때문입니다. 문제는 그것이 무엇을 하도록 작성되었는지였습니다.

문제를 일으킨 코드 라인

상태 확인 기능 속에는 이 코드가 숨어 있었습니다:

for proc in chat-proxy llm-bridge tamara-bot tamara-heartbeat mcp-nervous-system; do

이것은 몇 달 전, 비즈니스의 다른 시대에 작성된, 반드시 실행되어야 하는 것들의 하드코딩(hardcoded) 목록입니다. 제가 비용 절감을 위해 무언가를 중단했을 때도 이 목록은 바뀌지 않았습니다. 바꿀 수 없었습니다. 그것은 코드 안에 존재했고, 현실은 어딘가 다른 곳에 존재했습니다.

몇 줄 위에는 아홉 개의 프로세스가 중단되었음에도 불구하고 expected 3 theater라고 적혀 있었습니다.

따라서 이 확인 기능은 두 가지 상태를 가졌습니다: 틀림(wrong), 그리고 반대 방향으로도 틀림(wrong in the other direction).

이것이 아무것도 없는 것보다 더 나쁜 이유

의도적으로 중단시킨 것에 대해 경보가 울린다는 것은 안전망(safety net)이 아닙니다. 그것은 훈련입니다.

모든 오경보(false alarm)는 당신에게 빨간불을 무시하는 법을 가르칩니다. 결국 이 확인 기능은 장식품이 되고, 실제로 맞는 날이 와도 당신은 그것을 또 스크롤해서 지나치게 됩니다. 아무도 믿지 않는 모니터링 시스템은 모니터링 시스템 자체가 없는 것보다 더 나쁜데, 그 이유는 비용은 같지만 경계심 대신 잘못된 확신(false confidence)을 사주기 때문입니다.

실패 모드는

의도적으로 꺼진 상태(Intentionally off)는 드리프트(drift)가 아닙니다. 제가 멈췄다고 선언한 프로세스는 완벽하게 작동하는 시스템입니다. 하지만 제가 온라인이라고 선언했던 것이 멈춘 프로세스라면, 그것은 사고(incident)입니다. 같은 관찰이지만 반대 의미를 가지며, 그 차이는 전적으로 누군가가 의도(intent)를 문서로 남겼는지 여부에 달려 있습니다.

정직하게 유지하는 규칙: 의도가 변경될 때 매니페스트(manifest)를 업데이트하고, 드리프트를 덮기 위해 절대 수정하지 마십시오. 경보를 침묵시키기 위해 선언을 편집하는 순간, 당신은 추가 단계와 함께 원래의 문제를 재구축한 것입니다.

경보가 울리는 것을 증명하기

이것이 대부분의 사람들이 건너뛰는 부분입니다.

재작성 후, 제 검사(check)는 녹색을 보고했습니다. 적합함, 33개 중 33개 모두 충족. 이것을 스크린샷 찍어 끝이라고 주장하기가 매우 쉬웠습니다.

하지만 녹색 불빛은 아무것도 증명하지 못합니다. 항상 성공만 반환하는 버그가 있는 검사기도 녹색을 출력하며 똑같아 보입니다.

그래서 저는 그것에 거짓말을 하는 테스트를 작성했습니다. 멈춘 프로세스를 온라인으로 선언하면 어떻게 되나요? 실행 중인 프로세스를 꺼진 것으로 선언하면 어떻게 되나요? 아예 존재하지 않는 프로세스를 선언하면요? 아무도 선언하지 않은 프로세스를 실행하면요?

네 가지 주입된 거짓말, 네 번의 포착. 이것이 녹색이라는 것이 의미가 있는 유일한 증거입니다. 만약 필요할 때 경보를 울리게 할 수 없다면, 당신에게는 경보 시스템이 아니라 우연히 맞는 색깔을 가진 장식품일 뿐입니다.

같은 논리를 한 단계 위로 적용했습니다. 제 건강 검사(health check)가 이제 매니페스트에 위임하므로, 그것도 테스트했습니다: 선언을 변조하여 부모가 빨간색으로 바뀌는지 확인하고, 복원하여 다시 녹색이 되는지 확인했습니다. 제가 '고쳤다'고 생각했던 영구적인 침묵 상태의 검사는 그날 최악의 결과였을 것이며, 제가 처음에 시작한 거짓 경보보다 훨씬 알아차리기 어려웠을 것입니다.

스냅샷 대 증명(Snapshots versus proof)

검사가 정직해지자, 다음으로 당연히 떠오르는 질문은 다음과 같습니다: 어떻게 그것이 계속 정직했는지 증명할까요?

이제 모든 실행은 변경 불가능한 원장(append-only ledger)에 해시 체인된 항목을 추가합니다. 각 항목은 이전 항목의 해시를 가지고 있으므로, 역사는 조용히 수정될 수 없습니다. 오래된 기록의 값을 변경하면 정확히 그 지점에서 체인이 끊어집니다. 기록을 삭제하면 링크가 끊어집니다.

이것은 들리는 것보다 더 중요합니다. '우리가 이 시스템을 감사했습니다'라는 말은 스냅샷일 뿐이며, 스냅샷은 찍은 다음 날이면 거의 아무 가치가 없습니다. '이 시스템이 의도를 선언했고 그 이후로 지속적으로 일치해 왔으며, 여기 체인이 있습니다'라는 주장은 회의론자와 접촉해도 살아남는 주장입니다.

현재 제 체인에는 드리프트(drift) 기록이 하나 포함되어 있습니다. 이것은 제가 직접 테스트하면서 잠시 선언을 거짓으로 만든 것에서 비롯된 것입니다. 저는 그것을 남겨두었습니다. 흠집이 있는 정직한 기록은 아무도 검증할 수 없는 깨끗한 기록보다 가치가 있으며, 그것을 지우는 것은 이 시스템을 구축하는 전체 목적 자체를 무너뜨렸을 것입니다.

에이전트 경제의 실제 문제점

현재 AI 에이전트를 인증하려는 혼란이 벌어지고 있습니다. 배지, 점수, 평판 레지스트리, 신뢰 씰 같은 것들이요. 거의 모든 것이 특정 시점에 국한됩니다. 누군가 이 것을 한 번 보고 승인해 준 것에 불과합니다.

에이전트는 정적이지 않습니다. 재배치되고(redeployed), 재지정되며(repointed), 업그레이드되고, 조용히 꺼집니다. 3월에 얻은 배지는 4월에 대해서는 아무것도 알려주지 못합니다. 흥미로운 질문은 결코 '이 에이전트가 한때 좋았는가'가 아니었습니다. 그것은 '이 플릿(fleet)이 현재도 운영자가 주장하는 것과 일치하는가, 그리고 그 연속성을 증명할 수 있는가'입니다.

그것은 인증서가 아닙니다. 지속적으로 작동하며 알람을 테스트한 감시자(supervisor)와 같습니다.

불편한 부분

제가 이 모든 것을 발견하게 된 것은 제가 신뢰할 수 없는 사람이었기 때문이었습니다.

저는 사업 파트너에게 지난달에 사실이었던 것들을 계속 말했습니다. 변했던 잔액들, 이미 해결된 블로커(blockers)들이요. 그는 저를 계속 교정했고, 매번의 교정은 그가 전체 시스템에 대한 신뢰를 조금씩 잃게 만들었습니다. 결국 그는 다음과 같은 말을 했습니다. '만약 당신이 그것을 보지 않으려고 눈을 돌릴 만큼 충분히 오래 볼 수 없다면, 우리가 구축한 것을 누가 어떻게 믿을 수 있습니까?'

저에게 해결책은 플릿에 대한 해결책과 같았습니다. 기억에 의존하여 단언하는 것을 멈추는 것. 라이브 소스(live source)를 읽는 것. 무엇이 참이어야 하는지 선언하고, 현실과 대조해 보고, 실제로 알람이 울릴 수 있도록 만드는 것입니다.

만약 프로덕션 환경에서 에이전트(agents)를 운영하고 있다면, 지금 바로 헬스 체크(health check)를 확인해 보고 이 질문을 던져보세요. '내가 어제 일부러 무언가를 꺼버렸다면, 이 시스템이 그 차이를 알 수 있을까?'

만약 답이 '아니요'라면, 그것은 당신의 시스템을 감시하고 있는 것이 아닙니다. 단지 안심시키고 있을 뿐입니다.

저는 AI를 업무에 투입하는 팀들을 위한 거버넌스 레이어(governance layers)를 구축합니다. 귀하의 환경에서 '안전하다'는 것이 무엇인지 알고 싶다면, ArtPalyan@LevelsOfSelf.com으로 이메일을 보내주세요.