Shippy가 보여준 고위험 AI 에이전트 설계 원칙

들어가며

Ai2가 Hugging Face Blog에 공개한 Shippy 기술 글은 AI 에이전트를 실제 운영 환경에 투입할 때 무엇이 중요한지 보여주는 사례다. Shippy는 Skylight의 해양 상황 인식 플랫폼에서 선박 활동, 배타적 경제수역, 해양보호구역, 선박 이동 경로, 지도 링크 등을 분석가가 질의할 수 있도록 돕는다.

이 영역에서는 잘못된 답변이 단순한 품질 문제가 아니다. 순찰 선박을 엉뚱한 위치로 보내 제한된 단속 자원을 낭비하게 만들 수 있고, 경우에 따라 인력 안전에도 영향을 줄 수 있다. 그래서 Shippy의 핵심은 더 강력한 언어모델을 고르는 일이 아니라, 비결정적인 에이전트를 어떻게 신뢰 가능한 시스템으로 감싸느냐에 있다.

핵심 포인트

• 에이전트를 soul, skills, config로 분리: soul은 역할과 행동 경계를 정하는 시스템 프롬프트다. skills는 특정 요청을 처리하는 절차이고, config는 실행 프레임워크, 모델, 런타임 설정을 담당한다. 모델이나 하네스 교체는 재빌드가 아니라 설정 변경으로 처리된다.
• 스킬은 Markdown으로 버전 관리: Shippy의 스킬은 구조화된 frontmatter가 있는 Markdown 파일이다. Skylight API 질의, EEZ와 MPA 경계 조회, 선박 트랙 해석, Skylight 지도 딥링크 생성 등이 여기에 포함된다.
• 비결정적 모델을 결정적 도구로 제한: 초기에는 에이전트가 직접 API 호출을 구성했지만, 페이지네이션 누락, 지오메트리 인코딩 오류, 필터 오해 같은 문제가 생겼다. 이후 전용 Skylight CLI를 만들어 인증, 페이지 처리, 구조화 출력을 도구 계층에서 처리하게 했다.
• 세션 단위 격리: Shippy는 Mothership이라는 호스팅 플랫폼에서 실행된다. 대화가 열릴 때마다 사용자별 Kubernetes 배포가 생성되고, 사용자의 Skylight JWT가 주입된다. 파일과 대화 기록은 해당 세션 안에만 남고, 네트워크 접근도 필요한 서비스로 제한된다.
• 평가는 모델이 아니라 전체 에이전트 대상: 정적 벤치마크는 에이전트가 도구를 선택하고, 실시간 데이터를 조회하며, 어디서 멈춰야 하는지까지 평가하지 못한다. Ai2는 모델, 스킬, 샌드박스를 묶은 전체 시스템을 평가 대상으로 삼는다.

의미와 영향

Shippy의 사례는 기업용 AI 에이전트의 신뢰성이 모델 성능만으로 결정되지 않는다는 점을 분명히 한다. 타입이 정의된 API, 안정적인 CLI, 명시적 행동 경계, 사용자별 격리, 실제 업무에 맞춘 평가가 함께 필요하다.

특히 Shippy는 선박이 법을 위반했는지 같은 법적 판단을 내리지 않으며, 데이터가 뒷받침하지 않는 추측도 하지 않도록 설계됐다. 고위험 업무에서 유용한 에이전트란 많이 말하는 시스템이 아니라, 말하지 말아야 할 범위를 아는 시스템이다.

다른 산업에서도 적용 가능한 교훈은 분명하다. 복잡한 API를 예측 가능한 도구로 감싸고, 스킬을 감사 가능하게 관리하며, 사용자 데이터와 실행 환경을 분리하고, 실제 워크플로로 검증해야 한다. 그래야 에이전트는 데모를 넘어 책임 있는 운영 인프라가 될 수 있다.

Source: Hugging Face Blog