우리는 Kubernetes 대시보드를 만들었습니다. 그래서 잠시 동안 제 자신의 제품에 반대되는 논리를 펼쳐보려 합니다. 만약 이 논리가 타당하다면, 경쟁사로부터 듣기보다는 저에게 직접 듣는 편이 나을 것이기 때문입니다.

논리는 이렇습니다. 수년 동안 여러분이 대시보드를 열었던 이유는 클러스터의 상태(state)가 머릿속에 담아두기에는 너무 방대하여, 눈으로 확인할 수 있도록 그려줄 무언가가 필요했기 때문입니다. 하지만 에이전트(agent)는 눈으로 보지 않습니다. 에이전트는 구조화된 데이터(structured data)를 읽고, 이를 바탕으로 추론하며, 점점 더 그 데이터에 따라 행동합니다. 만약 에이전트가 운영(operating)을 수행한다면, 대시보드는 1910년의 말(horse)과 같습니다. 여전히 유용할 수는 있지만, 명백히 트렌드의 잘못된 편에 서 있는 것이죠. 운영 업무 중 에이전트에게 넘어가는 매 시간은, 아무도 우리의 UI를 사용하지 않는 시간이 됩니다.

제 생각에 이 논리는 절반은 맞고, 틀린 나머지 절반이 흥미로운 부분입니다. 이것은 우리가 [6월에 작성했던 에이전트 vs UI vs CLI 질문]에 관한 것이 아닙니다. 당시 글은 오늘날 여러분이 어떤 인터페이스를 선택하느냐에 관한 것이었습니다. 이것은 더 어려운 버전의 질문입니다. 만약 에이전트가 자율성 사다리(autonomy ladder)를 계속 올라간다면, 3년 뒤에 대시보드의 용도는 무엇이 될까요?

요약(TL;DR). 비관적인 전망(bear case)은 실재하며, 이는 특정 유형의 대시보드, 즉 클러스터를 수동으로 실행하기 위해 클릭하며 돌아다니는 대시보드를 소멸시킬 것입니다. 하지만 에이전트가 운영을 맡게 됨에 따라, 성장하는 역할은 '감독(supervising)'입니다. 즉, 검증하고, 승인하고, 감사하며, 에이전트가 이상한 것을 전달했을 때 새벽 3시에 상황을 파악하고 재정비하는 일입니다. 그 업무는 비행이 그러했듯, 목적에 맞게 제작된 시각적 인터페이스(visual surface)를 필요로 합니다. 대시보드는 죽지 않습니다. 다만 직접 조종하는 콕핏(cockpit)에서, 관찰하는 관제탑(tower)으로 역할이 전환될 뿐입니다.

솔직하게 밝히는 비관적 전망

저는 이 논리를 허수아비 때리기(strawman) 식으로 다루지 않겠습니다. 왜냐하면 이 논리를 펼치는 사람들은 진지하며, 그 증거 중 일부는 우리 자신의 것이기도 하기 때문입니다.

Satya Nadella는 2024년 말에 비즈니스 애플리케이션들이 "에이전트 시대(Agent Era)에 모두 붕괴할 것"이라고 말했습니다. 대부분의 애플리케이션이 그 위에 약간의 비즈니스 로직이 얹혀 있는 데이터베이스에 불과하며, 그 로직이 에이전트 계층(agent tier)으로 이동하고 있기 때문입니다. Andrej Karpathy는 제가 실제로 추천하는 강연에서 에이전트를 인간 및 다른 프로그램과 함께 소프트웨어의 세 번째 소비자(consumer)로 정의했습니다. 에이전트는 여러분의 GUI(그래픽 사용자 인터페이스)를 원하지 않는데, 눈을 위해 만들어진 화면은 모델에 데이터를 공급하기에 나쁜 방식이기 때문입니다. 그리고 저는 우리 자신의 수치를 외면할 수 없습니다. 우리가 52개의 클러스터 결함에 대해 에이전트와 가공되지 않은 kubectl을 벤치마크했을 때, 구조화된 클러스터 데이터를 바탕으로 추론하는 에이전트가 4분의 1 수준의 도구 호출(tool calls)만으로 더 나은 진단을 내렸습니다. 에이전트는 클러스터를 이해하기 위해 진정으로 픽셀(pixels)을 필요로 하지 않습니다. 그들에게 필요한 것은 구조화된 상태(structured state)이며, 이는 그래프를 그리지 않고도 전달할 수 있습니다. 우리는 우리 블로그에서 이를 증명했습니다.

자율성 사다리(autonomy ladder)를 상단에 놓으면 침식(erosion) 현상은 구체화됩니다. 팀이 에이전트에게 감독 없이 처리하도록 허용하는 동사(verb) 하나하나가 대시보드를 열어야 할 이유를 하나씩 줄여나갑니다. 그리고 충분히 많은 작업이 이동하게 되면, 포드(pods) 확인, 이벤트(events) 스캔, 멈춘 포드 재시작과 같은 일상적인 클릭 경로(click-path)는 그냥 증발해 버립니다. 이 이야기의 가장 강력한 버전은 이미 뉴스 사이클을 탔습니다. Klarna가 AI가 자신들을 대체할 것이기 때문에 Salesforce와 Workday를 중단한다고 발표했을 때 말입니다. 이는 모든 헤드라인을 장식했습니다. 하지만 조용한 후속 상황은 주목받지 못했습니다. 제품은 사라졌지만, 그 제품들이 담고 있던 업무는 채팅창 속으로 녹아든 것이 아니라 내부 시스템 전반에 걸쳐 재구축되었습니다. 그리고 CEO는 그다음 1년 동안 회사의 어느 정도까지를 AI가 실제로 스스로 운영할 수 있는지에 대해 말을 번복하며 다녔습니다. 이 점을 명심하십시오. 왜냐하면 그 '번복' 과정 속에 진짜 답이 들어있기 때문입니다.

실제로 죽는 것

대시보드의 일부는 실제로 사라지고 있으며, 저는 우리의 모든 인터페이스가 안전하다고 가장하기보다는 차라리 이름을 명시하고 싶습니다.

일일 워크플로우로서의 리소스 브라우저 (resource browser)는 죽어가고 있습니다. 끝없는 리스트 페이지들은 어쨌든 결코 좋은 부분이 아니었습니다. 그것들은 더 나은 질문을 던질 방법이 없었기에 지불해야 했던 대가였습니다. Deployment를 재시작하기 위해 네 개의 화면을 탐색하는 근육 기억인 클릭-옵스 (Click-ops)는 죽어가고 있으며, 대부분 그럴 만한 가치가 있습니다. 그리고 대시보드의 가장 최악의 형태, 즉 무언가를 놓칠까 봐 계속 열어두게 되는 대시보드가 가장 빠르게 사라지고 있습니다. 관측성 (observability) 회사를 공동 창업한 Charity Majors는 2021년에 이를 지적한 바 있습니다: 모든 대시보드는 당신이 이미 잊어버린 어떤 질문에 대한 답변이며, 문제가 생기기를 기다리며 대시보드를 응시하는 것은 디버깅 (debugging)이 아니라 패턴 매칭 (pattern-matching)일 뿐이라고 말입니다. 하지만 그녀는 공격 대상을 신중하게 정했습니다. 즉, 질문을 던질 수 있는 인터페이스가 아닌, 고정된 형태의 정적 대시보드 (static dashboards)를 대상으로 삼았으며, 이 차이점은 잠시 후에 중요해질 것입니다. 정적인 형태에 대해서라면 그녀의 말이 맞았으며, 실제로 당신을 대신해 클러스터 (cluster)를 감시하는 에이전트 (agent)가 있다면 직접 감시하는 방식의 대시보드는 방어 불가능해집니다. 만약 대시보드의 전체적인 셀링 포인트가 "에이전트가 곧 당신을 위해 수행할 일들을 수동으로 하기 위한 더 나은 장소"라면, 최악의 시나리오 (bear case)가 이를 집어삼킬 것이며, 마땅히 그래야 합니다. 우리의 대시보드도 그것이 차지하는 비중만큼은 예외가 아닙니다.

하지만 에이전트 기업들이 실제로 무엇을 출시하는지 보십시오

여기에 핵심적인 단서가 있습니다. 운영 AI 에이전트 (operational AI agents) 분야에서 가장 앞서 나가는 팀들은 단순히 채팅창 하나를 출시하고 거기서 멈추지 않습니다. 그들의 에이전트가 무엇을 만들어내는지 보십시오. Datadog의 인시던트 에이전트 (incident agent) — 그들이 처음으로 일반 공개(generally available)한 에이전트 — 는 조사 페이지 (investigation page)를 생성함으로써 인시던트를 해결합니다. 각 가설은 검증되었거나 배제된 것으로 표시되고, 근거와 함께 근본 원인 (root cause)이 나열되며, 신뢰하기 전에 추론 과정을 확인할 수 있는 클릭 가능한 인용문 (citations)이 제공됩니다. 그것은 대화 기록 (transcript)이 아닙니다. 인간이 에이전트를 한눈에 검증할 수 있도록 구축된 대시보드 (dashboard)입니다. 또한, 앱이 붕괴될 것이라고 주장하는 리더십을 보유한 OpenAI는 에이전트가 채팅 내부에서 상호작용 가능한 인터페이스 (interactive interfaces)를 그릴 수 있도록 Model Context Protocol을 특별히 확장했습니다. 에이전트를 만드는 사람들이 에이전트 위에 놓일 시각적 표면 (visual surfaces)을 계속해서 구축하고 있다면, 이는 단순히 설명하고 넘길 수 있는 우연이 아닙니다. 그렇다고 해서 에이전트가 작동하기 위해 픽셀 (pixels)이 필요하다는 증거도 아닙니다. 왜냐로는 그렇지 않기 때문입니다. 이것은 루프 (loop)의 반대편에 대한 증거입니다. 즉, 아직 아무도 결과물을 보여주지 않고 인간이 에이전트의 작업을 신뢰하게 만드는 방법을 알아내지 못했다는 것입니다.

구체적으로 세 가지 사항은 변하지 않습니다.

하나: 눈은 병렬적이고, 대화 기록은 직렬적입니다

훌륭한 시각화 (visualization)가 수행하는 많은 일은 당신이 그것을 보고 있다는 것을 의식하기도 전에 일어납니다. 녹색 필드 안의 빨간색 셀 (cell)은 주변에 얼마나 많은 녹색 셀이 있든 상관없이 0.25초도 안 되어 눈에 띕니다. 당신의 시각 시스템이 항목을 하나씩 훑는 대신 전체 필드를 한꺼번에 확인하기 때문입니다. 잘 그려진 상태 벽 (wall of state)이 제공하는 가치는 바로 이것입니다. 수백 개의 신호가 병렬로 스캔되며, 당신이 찾아보겠다고 결정하기도 전에 이상 징후 (anomaly)가 당신에게 전달됩니다. 채팅 대화 기록 (chat transcript)은 그 반대입니다. 토큰 (token)이 하나씩 줄을 지어 순차적으로 나타나며, 그림은 당신이 직접 조립해야 하는 몫으로 남겨집니다.

한편, 거대한 컨텍스트 윈도우 (context window)가 그 안에 담긴 모든 것을 신뢰성 있게 사용한다는 것과 동일한 의미는 아닙니다. 이에 대한 연구 결과는 매우 일관적이어서 굳이 인용 목록을 나열하지 않더라도 알 수 있습니다. 모델은 컨텍스트 윈도우가 가득 차기 훨씬 전부터 긴 입력값 속에 파묻힌 내용을 놓치거나 과소평가할 수 있습니다. 이것이 바로 잘 설계된 에이전트 (agent)들이 클러스터 (cluster) 전체를 통째로 삼키지 않고, 관련 있는 부분만을 쿼리 (query)하는 이유입니다. 하지만 이러한 우회책이 무엇을 인정하고 있는지 주목하십시오. 에이전트의 약점을 보완하는 해결책은 구조화 (structure)와 선택 (selection)이며, 토큰 (token)이 아닌 인간의 눈을 겨냥한 구조화와 선택은 바로 대시보드 (dashboard)라고 불립니다. 저희의 자체 벤치마크 (benchmark)에 따르면, 에이전트는 가공되지 않은 데이터 덤프 (raw dumps)보다 구조화된 데이터 (structured data) 위에서 더 잘 추론합니다. 대시보드는 바로 그 동일한 구조화 작업이며, 방 안에 있는 또 다른 추론 엔진, 즉 에이전트를 감독하는 사람을 겨냥한 것입니다.

둘: 새벽 3시에 당신이 차갑게 도착했을 때

자율성 사다리 (autonomy-ladder) 포스트에서 빌려오고 싶은 논점이 하나 있습니다. 일단 에이전트가 일상적인 케이스들을 스스로 처리하게 되면, 여전히 인간을 호출(page)하게 만드는 사고들은 정의상 에이전트가 처리할 수 없었던 것들, 즉 기이한(weird) 것들뿐이라는 점입니다. 그리고 당신은 평소의 일반적인 상황들에 대한 최근의 연습량이 그 어느 때보다 부족한 상태로 그 기이한 상황에 맞닥뜨리게 됩니다.

그 순간 당신에게 필요한 것은 에이전트가 무엇을 시도했는지에 대한 로그 (log)가 아닙니다. 상황을 빠르게 파악하는 것, 즉 무엇이 있는지, 그것이 무엇을 의미하는지, 어디로 향하고 있는지를 알아야 합니다. 인간 요인 (human-factors) 전문가들은 이를 상황 인식 (situational awareness)이라고 부릅니다. 여기서 이것이 중요한 이유는, 트랜스크립트 (transcript, 기록)는 당신에게 가공되지 않은 인지 정보만을 제공하며, 압박감이 심한 최악의 순간에 당신 스스로 의미와 궤적을 조립하게 만들기 때문입니다. 영향 범위 (blast radius)가 표시된 토폴로지 그래프 (topology graph), 무엇이 언제 변경되었는지 보여주는 타임라인 (timeline), 전체 플릿 (fleet)에 걸친 상태 요약 — 이것들이 바로 이해를 빠르게 재구축하기 위한 도구입니다. 이 도구의 유일한 목적은 90초 전까지 잠들어 있던 사람을 상황에 적응하게 만드는 것이며, 그 어떤 문단도 적절한 그림만큼 빠르게 그 일을 해낼 수는 없습니다.

셋: 신뢰는 어딘가에 렌더링되어야 한다

이것은 비관론(bear case)이 가장 크게 놓치고 있는 부분입니다. 왜냐하면 비관론은 어려운 부분이 '작업을 수행하는 것'이라고 가정하기 때문입니다. 진짜 어려운 부분은 '작업이 제대로 수행되었는지 신뢰하는 것'입니다.

여기서 요구되는 신호는 매우 강력합니다. 올해의 관측성(observability) 설문조사에서 Grafana가 실무자들에게 운영 분야의 AI에 대해 물었을 때, 응답자들이 가장 일치된 의견을 보였던 것(약 20명 중 19명꼴)은 AI가 자신의 추론 과정(reasoning)을 보여주는 것이 중요하다는 점이었습니다. 대부분의 응답자는 AI가 자율적으로 행동하는 것에서도 가치를 발견했지만, 이는 질문받은 다른 어떤 항목보다도 가장 많은 회의론을 불러일으켰습니다. 사람들은 도움을 원하면서도, 그것을 믿기 전에 작업 내용을 확인하고 싶어 합니다. 그리고 그 작업을 확인하는 것은 UI(사용자 인터페이스)의 문제입니다. 승인 게이트(approval gate)는 무엇이 변경될지를 문장으로 설명하는 것이 아니라, 디프(diff, 차이점) 형태로 정확히 보여주어야 합니다. 디프는 몇 초 만에 확인할 수 있지만, 한 단락의 글은 제대로 확인하기 어렵기 때문입니다. 밤사이 생성된 보고서는 훑어보기(scannable) 쉬워야 합니다. 한눈에 검증하는 것이야말로 시각적 인터페이스가 존재하는 정확한 이유이며, 에이전트(agent)가 더 적게가 아니라 더 많은 일을 수행할수록 이는 더욱 중요해집니다.

역전 (The inversion)

따라서 대시보드는 사라지지 않습니다. 다만 그 역할이 뒤바뀔 뿐입니다.

수년 동안 대시보드는 클러스터를 운영하는 곳이었습니다. 즉, 조종간을 잡고 계기판을 읽으며 비행하는 조종석(cockpit)이었습니다. 에이전트가 비행을 맡게 됨에 따라, 당신에게 필요한 인터페이스는 감독하는 곳, 즉 관제탑(control tower)이 됩니다. 당신은 조종간을 잡고 있지 않습니다. 당신은 대부분 스스로 비행하는 시스템을 지켜보고 있으며, 언제 개입해야 할지를 화면을 통해 즉각적이고 완전한 신뢰를 가지고 파악해야 합니다.

이는 Kubernetes UI를 구성하는 요소 자체를 변화시킵니다. 가치 있는 인터페이스(surfaces)는 더 이상 리소스 목록이 아니라, 에이전트가 무엇을 왜 하려고 하는지 확인하고 이를 승인하거나 중단하는 승인 대기열(approval queue)이 됩니다. 에이전트가 무엇을 수행했는지, 그리고 누구의 이름으로 수행했는지를 보여주는 작업 감사 추적(action audit trail), 에이전트를 차단할 수 있는 버튼이 포함된 에이전트 인벤토리(agent inventory), 에이전트가 무엇을 보았고 어떤 경로를 거쳤는지에 대한 재생(replay), 그리고 맹목적으로 믿는 대신 직접 확인할 수 있도록 근본 원인(root cause)을 제시하는 증거 뷰(evidence view) 등이 포함됩니다. 2020년의 대시보드에는 이 중 어느 것도 없었습니다. 왜냐하면 2020년에는 당신이 직접 작업을 수행했기 때문입니다.

이를 구체적인 사례로 들어보겠습니다. 에이전트가 롤아웃(rollout)으로 인해 에러율이 상승한 것을 감지하고 이를 되돌릴(reverting) 것을 제안합니다. 그 순간 당신이 원하는 인터페이스는 토폴로지(topology) 상에서 영향을 받은 서비스들을 강조하여 보여주고, 배포(deploy)와 에러 곡선을 동일한 타임라인 상에 표시하며, 데이터베이스 문제를 배제한 증거, 되돌리기가 적용할 정확한 차이점(diff), 그리고 실행될 신원(identity)을 보여줍니다. 당신은 몇 초 만에 이를 승인하거나, 잘못되어 보이는 단 하나의 가정을 잡아낼 수 있습니다. 반면 "문제를 발견했으며 수정할 수 있습니다"라고 말하는 채팅 메시지는, 검증 가능성(checkability)은 전혀 제공하지 않으면서 똑같은 클릭만을 요구합니다.