SHIPCHECK: 배포 전 의존성을 점검하는 자율 ReAct 에이전트

AI 요약

SHIPCHECK은 AI 코딩 에이전트가 만든 인프라 변경을 운영 환경에 반영하기 전에 검증하는 ReAct(Reasoning and Acting) 에이전트입니다. 글은 단순한 벡터 검색이나 RAG만으로는 서비스 간 다단계 의존성, 실제 클러스터 버전, 서로 충돌하는 문서를 함께 확인하기 어렵다고 지적합니다. SHIPCHECK은 Sanity Content Lake를 데이터 저장소이자 에이전트의 근거 자료로 사용하고, MCP(Model Context Protocol) 인터페이스로 정보를 조회합니다.

Sanity 문서 모델과 조회 도구

프로젝트는 Sanity에 세 가지 문서 유형을 구성합니다. component 문서에는 마이크로서비스의 클러스터 버전과 상태, 환경을 기록합니다. versionConstraint 문서는 특정 버전이 요구하는 구성 요소와 버전 조건, 중요도를 표현합니다. knowledgeEntry 문서는 사양과 정책, 릴리스 노트를 저장하며, 문서 간 충돌을 나타내는 contradicts, 정책 예외를 연결하는 isExceptionOf, 문서의 우선순위를 정하는 1~10 authorityLevel 필드를 둡니다.

에이전트는 MCP JSON-RPC 2.0 인터페이스에서 네 가지 도구를 호출합니다. query_sanity_component은 서비스의 현재 상태를 가져오고, query_version_constraints는 목표 버전의 제약을 조회합니다. audit_cluster_dependencies는 관련 구성 요소의 운영 버전을 점검하며, query_knowledge_graph는 문서 충돌과 예외를 권한 수준에 따라 확인합니다. 의존성 관계는 GROQ 쿼리로 최대 두 단계까지 탐색한다고 설명합니다.

결제 서비스 업그레이드 사례

예시 요청은 결제 서비스를 v2에서 v4로 올려도 되는지 묻습니다. 에이전트는 운영 서비스가 v2.0.0임을 확인한 뒤, v4가 Payment SDK v3.0.0 이상을 요구한다는 제약을 찾습니다. 실제 클러스터는 SDK v2.4.1을 실행하고 있어 조건을 충족하지 못합니다. 이어 내부 위키는 XML 페이로드를 전제로 하지만 공식 v4 릴리스 노트는 JSON v2를 요구하는 문서 충돌을 발견합니다. authorityLevel 10인 릴리스 노트가 4인 위키보다 우선한다고 판정하고, 배포를 보류하라는 결과를 냅니다.

글에 따르면 Payment SDK를 v3.1.0으로 올리는 상황을 메모리 안에서 시뮬레이션하면 의존성 충돌이 해소되고 판정이 ‘SAFE TO SHIP’으로 바뀝니다. 또 네 단계 복구 계획과 kubectl 롤아웃 명령, 마이그레이션 스키마, 롤백 스크립트를 생성하며, Web Speech API를 이용한 음성 브리핑도 제공합니다.

구현과 검증 범위

작성자는 구조화되지 않은 텍스트만으로 LLM이 의존성 충돌을 추측할 때 약 30%의 환각이 발생하지만, Sanity의 타입 지정 GROQ 쿼리로 근거를 제공하면 환각이 0%로 낮아진다고 주장합니다. 다만 글에서 공개한 데이터는 서로 연결된 18개 문서이며, 이 수치는 더 큰 운영 환경에서 검증한 결과로 제시되지는 않습니다. 따라서 소개된 사례는 시스템의 설계와 동작 방식을 보여주는 데 초점을 둡니다.

dev.to 반응

• @latrisha_5a24fb5a824484b3 — AI를 운영 안전성에 활용하는 접근이 정말 인상적입니다. ReAct, 다단계 의존성 검사, 권한 점수를 반영한 문서 처리를 결합한 점이 특히 마음에 듭니다. 실제 운영 환경을 바꾸기 전에 수정안을 시험할 수 있는 반사실적 시뮬레이션도 좋습니다. 꼭 확인해 볼 프로젝트이며, codecan.net에서 더 많은 AI 및 개발자 프로젝트도 계속 살펴보겠습니다.

원문: dev.to / 번역·요약: Trawling