저는 작은 스택을 관리하고 있습니다. 3개의 Linux VM, 1개의 Kubernetes 클러스터, 총 20여 개의 서비스 정도입니다. 규모가 크지는 않습니다. 하지만 문서화가 제대로 되어 있지 않습니다. SSH로 접속해서 내가 실행 중이라는 사실조차 잊고 있었던 것들을 발견하게 되는 그런 환경이죠.

지난주에 저는 두 가지 서로 다른 AI 도구에 동일한 작업을 수행하도록 요청했습니다: "무엇이 실행 중인지, 어떻게 연결되어 있는지, 그리고 무엇이 위험해 보이는지 알려줘." 하나는 범용 LLM (Claude)이고, 다른 하나는 목적에 맞게 구축된(purpose-built) AI SRE 도구입니다. 동일한 환경, 동일한 요청이었습니다. 결과는... 시사하는 바가 컸습니다.

작업 내용

간단한 브리프: 인프라 탐색(infrastructure discovery). 서비스, 의존성(dependencies), 토폴로지(topology), 리스크를 포함한 전체적인 그림을 원합니다. 신입 사원이 2023년 이후로 업데이트되지 않은 위키(wikis)를 뒤져가며 첫 일주일 동안 조각조각 맞춰나가야 할 법한 그런 작업 말입니다.

Claude Code (Opus 모델)

제 프롬프트는 다음과 같습니다:

"나는 작은 인프라를 관리하고 있습니다 — 3개의 Linux VM (172.30.0.41, 172.30.0.42, 172.30.0.43)과 하나의 Kubernetes 클러스터입니다. SSH 접속은 이미 설정되어 있습니다. 이 환경 전체에서 무엇이 실행 중인지 이해하도록 도와주세요 — 내 서비스, 의존성, 그리고 토폴로지의 전체적인 그림을 원합니다."

저는 Claude의 플래그십 티어인 Opus 모델을 사용하여 로컬에서 Claude Code를 실행하고 있습니다. Claude는 질문을 하지 않았습니다. 그냥 바로 SSH 접속을 시작했습니다.

5분 후 Claude는 저에게 보고서를 전달했습니다. 그리고 솔직히 말하자면? 기대했던 것보다 더 나았습니다.

Claude가 제공한 결과물은 다음과 같습니다:

• 세 가지 VM 역할(API Gateway, Order Processing, Data Tier)을 모두 정확하게 식별함
• Nginx가 카나리 가중치(canary weights)를 사용하여 백엔드 서비스로 라우팅하는 모습을 보여주는 ASCII 토폴로지(topology)를 그림
• 호스트, 포트, 기술 스택, 참고 사항을 포함한 전체 서비스 테이블을 구축함
• 폐기된 노드에 있는 오래된 복제본(stale replica)을 포함하여 Redis Sentinel 클러스터를 매핑함
• 모든 K8s 네임스페이스(namespace)와 워크로드(workload)를 열거함
• 관측성 파이프라인(observability pipeline)을 추적함 (node_exporter → Prometheus, OTel → Jaeger, Datadog agents)
• 네 가지 실제 문제점을 식별함: 작동하지 않는 Redis 복제본, aigc-app의 이미지 풀(image pull) 오류, 활성화된 카나리 분할, 여러 버전의 knoxd

5분 소요. 별도의 가이드도 없었음. "여기서 무엇이 실행 중인지 빠르게 훑어봐 줘"라는 요청에 대한 결과물로서는 진정으로 유용함.

한계점

초기의 "와, 정말 빠르다"라는 감탄이 가라앉은 후 발견한 점들은 다음과 같습니다.

출력물은 마크다운(markdown)의 벽과 같습니다. 대부분 정확하지만, 평면적입니다. 모든 정보가 동일한 비중을 가집니다. 즉, 치명적인 단일 장애점(single-point-of-failure)이 단순한 명명 규칙의 불일치와 나란히 놓여 있습니다. 심각도(severity)도, 우선순위(priority)도 없습니다.

더 구체적으로는 다음과 같습니다:

토폴로지 시각화의 부재. ASCII 다이어그램을 받았습니다. 기기가 6대일 때는 읽을 수 있습니다. 60대일 때는 읽기 어렵고, 600대일 때는 불가능합니다.

비즈니스 그룹화의 부재. Claude는 모든 서비스를 나열했지만, 어떤 서비스가 이커머스 흐름인지, 물류 흐름인지, 아니면 플랫폼 레이어인지 구분하지 못했습니다. 이를 위해서는 Claude가 가지고 있지 않은 도메인 컨텍스트(domain context)가 필요합니다.

리스크 평가의 부재. 네 가지 문제를 찾아냈지만, 심각도 분류는 없었습니다. 작동하지 않는 Redis 복제본과 사소한 knoxd 명명 문제는 동일한 비중으로 제시됩니다.

품질 게이트(quality gate)의 부재. Claude의 토폴로지가 실제로 정확한지 검증하는 과정이 없습니다. Claude는 자신 있게 요소들을 연결했지만, 카나리 가중치가 정말 90/10이었을까요? 직접 확인하러 가야 합니다.

지속성의 부재. 채팅 창을 닫으면 보고서는 사라집니다. 내일 다시 실행하면 약간 다른 탐색 경로와 약간 다른 결과물을 얻게 될 것입니다.

깊이 제어의 부재. "저 비즈니스 영역(Business Island)이 위험해 보이니 더 깊이 파고들어 봐"라고 말할 수 없습니다. 전부 아니면 전무(all-or-nothing) 방식입니다.

이는 제가 여러 산업 분야에서 계속해서 목격하고 있는 패턴과 일치합니다. 리걸 테크 (Legal tech) 분야에서도 사람들은 동일한 점을 발견했습니다. 일반적인 LLM (Large Language Models)은 계약서를 요약하는 데는 뛰어나지만, 정밀한 조항 검증 (clause verification)은 수행할 수 없습니다. 금융 분야에서는 ChatGPT가 분개 (journal entry)를 어떻게 입력하는지 설명할 수는 있지만, 실제로 입력할 수는 없습니다. 그 경계선은 일관적입니다. 일반 AI는 사고 도구 (thinking tool)이고, 특화된 AI는 실행 도구 (acting tool)입니다.

작업이 "이 데이터를 추론하고 나에게 설명해 줘"라면 일반적인 도구들이 훌륭하게 수행합니다. 하지만 작업이 "내 환경에 대한 구조화되고, 지속적이며, 검증 가능한 모델을 구축해 줘"로 전환되면, 당신은 그들이 설계되지 않은 영역으로 넘어선 것입니다.

동일한 작업, 목적에 맞게 제작된 도구

비교를 위해, 제가 Knox(저희의 목적에 맞게 제작된 AI SRE 도구입니다. 네, 이것은 저희 제품이며 미리 밝혀둡니다)에 한 줄의 명령을 보냈을 때 어떤 일이 일어나는지 보여드리겠습니다.

"우리 운영 환경에 대해 전체 인프라 디스커버리 (infrastructure discovery)를 실행해 줘."

더 짧은 프롬프트입니다. 환경을 설명할 필요가 없습니다. 이미 커넥터 (connectors)가 구성되어 있기 때문입니다.

20분 후:

중요한 차이점들은 다음과 같습니다:

주요 차이점들은 다음과 같습니다:

• 시각적 토폴로지 (Visual topology): ASCII 아트를 넘어선 상호작용하는 서비스 관계 그래프
• 비즈니스 아일랜드 (Business Islands): 중요도 레이블과 함께 비즈니스 기능별로 자동 그룹화된 서비스들
• 위험 분류 (Risk Triage): 심각도에 따라 순위를 매기고 분포 차트를 제공하는 발견 사항들
• 지속성 (Persistence): 결과를 그래프 데이터베이스에 저장하여 나중에 쿼리할 수 있음
• 필요 시 깊이 분석 (Depth on demand): 모든 비즈니스 아일랜드에 대해

이것은 Claude를 비판하는 것이 아닙니다. 맥가이버 칼(Swiss Army knife)은 매우 훌륭합니다. 하지만 수술이 필요할 때는 메스(scalpel)를 집어 들게 마련입니다.

여러분의 환경은 어떤 모습인가요? 운영(Ops) 작업에서 범용 AI 도구들이 한계에 부딪히는 지점은 어느 정도의 규모인가요?

목적에 맞게 제작된(purpose-built) 접근 방식을 시도해보고 싶다면: knoxops.app