규정을 아는 AI도 주문 승인권자는 알아야 한다

직원이 노트북을 교체해도 되는지 묻습니다. AI 도우미는 구매 규정을 찾아 그럴듯한 답변을 줍니다. 실제 결정에는 여전히 예산, 공급자, 직원의 부서, 해당 주문을 승인할 수 있는 사람이 필요합니다.

2026년 10월 23일 Sakana AI는 조직의 데이터와 규칙을 바탕으로 에이전트를 만들고 실행하며 통제하는 플랫폼 Sakana Aquarium을 발표했습니다. 일본 AI 기업인 Sakana AI는 정보의 의미와 관계를 연결하는 온톨로지, 관리형 에이전트 실행 환경, 접근·승인·실행 기록을 다루는 거버넌스를 설명합니다. 공식 발표.

유용한 질문은 답변과 권한 있는 행동 사이에서 무슨 일이 일어나는지입니다. Aquarium은 이 간극에 공통 구조를 두자는 제안입니다. 새 에이전트마다 회사에서 말하는 고객, 구매, 승인의 의미를 처음부터 다시 파악하지 않도록 하는 것입니다.

Sakana AI가 모델을 제품으로 연결해 온 배경을 보여주는 이전 TinySwallow 브라우저 채팅 인터페이스입니다. Aquarium 화면이 아닙니다. 이미지: Sakana AI, Apache License 2.0. 잘라내지 않고 크기를 조정했습니다.

같은 단어도 시스템마다 뜻이 다를 수 있다

대부분의 조직에는 에이전트가 필요한 정보가 이미 어딘가에 있습니다. 스프레드시트에 예산이 있고, 문서에 구매 규정이 있으며, 앱에 주문 상태가 기록됩니다. 어려운 점은 어느 정보들이 같은 대상을 가리키고, 결정 시점에 무엇을 기준으로 삼아야 하는지 아는 것입니다.

예를 들어 “승인됨”은 관리자가 이메일로 동의했다는 뜻일 수도, 재무 검토를 통과했다는 뜻일 수도, 공급자가 주문을 접수했다는 뜻일 수도 있습니다. 관련된 상태지만 서로 대체할 수는 없습니다. 동의어처럼 취급하는 에이전트는 맞는 듯한 답변을 하면서 잘못된 다음 단계를 밟을 수 있습니다.

온톨로지는 이런 의미와 관계를 구조화한 체계입니다. Aquarium 설명에 따르면 조직의 지식, 규칙, 데이터를 연결해 에이전트가 맥락 속에서 사용하도록 합니다. 제품 페이지는 대상 데이터 소스에 맞춰 연결과 동기화 방식을 설계한다고도 설명합니다. 플랫폼 설명.

저희 해석으로는 어려운 작업이 더 잘 보이는 곳으로 이동한 셈입니다. 상태의 의미, 그 상태를 관리하는 원본, 변경 시점을 누군가는 여전히 정해야 합니다. 이를 명시하면 다른 작업 흐름이 프롬프트마다 조금씩 다른 정의를 넣는 대신 재사용할 수 있습니다.

챗봇에 더 큰 서류함을 주기보다는 공통 지도에 합의하는 일에 가깝습니다. 지도가 현실을 대체하지는 않습니다. 질문이 어떤 기록과 규칙, 담당자를 가리키는지 파악하기 쉽게 해줍니다.

제품이 제시한 방향을 설명한 자체 도식입니다. 공통 정의로 정보를 통제 가능한 작업 흐름과 연결합니다.

구매 요청을 보면 검색만으로 부족한 이유가 드러난다

노트북 교체 요청을 예로 들어 보겠습니다. 유용한 흐름은 직원, 해당 예산, 승인된 공급자, 현재 구매 상태를 확인합니다. 일반 규정 문단을 구매 허가로 받아들이지 않고 필요한 승인 경로를 판단해야 합니다.

요청이 시작된 뒤 예산 기록이 달라졌다면 새 값을 적용할 규칙이 필요합니다. 관리자가 부재중이라면 다른 사람이 승인할 수 있는지도 알아야 합니다. 공급자 견적이 만료됐다면 과거 승인이 현재 주문까지 포괄하지 않을 수 있습니다.

이 문제의 중심은 언어 생성보다 정보의 책임 주체, 시간, 권한에 있습니다. 모델은 요청 해석을 도울 수 있지만 앱이 그 해석을 올바른 기록과 허용된 작업에 연결해야 합니다.

Aquarium 발표는 접근 제어, 실행 전 승인, 판단 근거와 결과를 잇는 기록을 설명합니다. 데이터와 온톨로지 정의를 여러 에이전트에서 재사용하는 기능도 소개합니다. 시범 도입에서 평가할 만한 약속이며, 모든 조직의 구매 과정이 이미 지원된다고 가정할 근거는 아닙니다. 거버넌스와 관리형 에이전트.

작은 첫 프로젝트는 이런 결정 경로 하나를 처음부터 끝까지 이해할 수 있게 만들어야 합니다. 회사 문서를 모두 연결해 광범위한 질문을 던지는 것보다 많은 것을 알려줍니다. 입력, 담당자, 결과를 확인할 수 있는 구체적인 작업을 목표로 삼아야 합니다.

고객 예외 처리에는 규정과 사유가 함께 필요하다

두 번째 예는 기업 고객의 예외 요청 처리입니다. 계약에는 표준 갱신일이 있지만 영업 담당자가 다른 조건을 약속했다고 가정해 보겠습니다. 최신 이메일만 읽은 에이전트는 계약을 놓치고, 계약만 읽은 에이전트는 승인된 예외를 놓칠 수 있습니다.

유용한 시스템은 제안과 승인된 변경을 구분해야 합니다. 결정할 사람에게 뒷받침 자료도 보여줘야 합니다. 단순히 가장 최신 문장을 고르는 것이 아니라 관련 기록을 상태 및 권한과 함께 연결하는 것이 목표입니다.

여기서 공통 정의를 재사용할 수 있습니다. 한 작업 흐름이 고객 계약 상태를, 다른 흐름이 청구를 이해한다면 같은 갱신의 의미를 서로 다르게 만들어서는 안 됩니다. 공유 기반은 에이전트가 늘어날 때 불일치를 줄일 수 있습니다.

이점은 기반의 품질에 달려 있습니다. 잘못된 관계도 올바른 관계만큼 효율적으로 재사용됩니다. 따라서 시연에서 에이전트가 내놓은 답변뿐 아니라 정의와 갱신 경로도 검토해야 합니다.

비슷한 플랫폼을 검토한다면 구체적으로 물어보세요. 관련 의미와 상태, 권한을 연결했을 때 어떤 결정이 좋아질까요? 아무도 그 결정을 말할 수 없다면 명확한 운영 목적 없이 정보를 모으는 프로젝트가 될 수 있습니다.

세상이 바뀌면 재사용하는 흐름에도 책임자가 필요하다

Aquarium 제품 페이지는 정보 참조, AI 판단, 함수 실행, 사람 승인을 포함하는 YAML 작업 흐름을 설명합니다. 연결된 정보의 갱신이 온톨로지에 반영되는 방식도 소개합니다. 작업 흐름과 동기화.

절차를 결정과 행동의 연속으로 검토할 수 있다는 점에서 유용한 방향입니다. 사람은 어디에 승인을 넣고, 어떤 함수가 실행하며, 정보가 빠졌을 때 어떻게 되는지 물을 수 있습니다. 생성한 모델만 이해하는 흐름이어서는 안 됩니다.

다만 갱신이 시스템에 도착하는 것과 조직이 그 의미에 동의하는 것은 다릅니다. 새 규정이 특정 날짜 이후 요청에만 적용될 수 있습니다. 고객 기록이 바뀌어도 민감한 행동에 반영하기 전에 검토가 필요할 수 있습니다. 답은 주변 업무 규칙에서 정해집니다.

책임은 두 수준에서 명확해야 합니다. 데이터 연결을 유지하고 실패를 감지하는 사람이 필요합니다. 업무 정의를 관리하고 규칙 변경 시점을 결정하는 사람도 필요합니다. 작은 팀에서는 같은 사람이 맡을 수 있습니다. 이런 책임이 없으면 동기화가 낡은 가정을 더 빨리 퍼뜨릴 수 있습니다.

특정 고객 구축 사례에 대한 주장이 아니라 평가 질문입니다. 플랫폼의 개념을 기업이 알아볼 수 있는 실제 작업과 연결하기 위한 것입니다.

실수를 이해할 수 있는 업무 하나부터 시작한다

현재 Aquarium 공식 사이트는 소개와 상담 경로를 제공합니다. 공개된 셀프서비스 가격이나 모든 고객에게 적용되는 활성화 날짜를 제시하지는 않습니다. 회사 전체를 에이전트로 전환한다는 약속보다 구체적인 업무를 중심으로 첫 상담을 준비하는 편이 유용합니다. 소개와 문의.

실용적인 준비 순서는 다음과 같습니다.

1. 승인자에게 보내기 전 구매 요청을 점검하는 일처럼 반복 업무 하나를 고릅니다.
2. 원본 기록, 각 값을 관리하는 시스템, 업무 규칙의 책임자를 확인합니다.
3. 정보 누락, 예외, 중단해야 하는 요청까지 중요한 상태를 적습니다.
4. 에이전트가 준비할 수 있는 행동, 실행할 수 있는 행동, 그 사이에 필요한 승인을 정합니다.
5. 현재 업무 담당자들과 정상 사례와 어려운 사례를 평가합니다.
6. 다른 업무로 넓히기 전에 실행 기록과 갱신 경로를 확인합니다.

이렇게 하면 시범 도입을 판단하기 쉬워집니다. 모은 정보의 완결성, 제안한 경로의 정확성, 검토자 부담을 비교할 수 있습니다. 기다려야 할 요청을 시스템이 자신 있게 진행하는 경우도 발견할 수 있습니다.

첫 유용한 결과는 자동 실행보다 준비 개선일 수 있습니다. 관련 정보를 모으고 올바른 검토자를 찾는 것만으로도 실제 병목을 없앨 수 있습니다. 이후 자율성을 늘려도 될지 판단할 더 명확한 기반도 됩니다.

권장 평가 순서입니다. 에이전트 수 확대는 작동하는 결정 경로를 확보한 다음에 해야 하며, 그 경로를 대신할 수는 없습니다.

Sakana의 기업 경험은 방향을 설명하지만 성과를 증명하지는 않는다

Sakana AI는 발표에서 금융처럼 정확성과 설명 책임이 필요한 분야의 AI 구축 경험과 Aquarium을 연결합니다. 데이터 연결, 용어 정리, 판단 기준 정리에 반복적으로 노력이 들어갔다고 설명합니다. 프로젝트마다 다시 만들던 작업을 위한 공통 기반으로 Aquarium을 제시한 것입니다. 제품 배경.

이 배경은 어떤 문제를 제품으로 만들었는지 설명하므로 유용합니다. 다만 공개된 Aquarium 성과 측정과는 구분해야 합니다. Sakana AI의 과거 협력이 자동으로 Aquarium 고객 사례가 되는 것은 아니며, 좁은 구축 사례의 성공이 모든 업무에 쉽게 옮겨진다는 증거도 아닙니다.

다음으로 볼 근거는 운영 내용입니다. 어떤 작업을 골랐고, 어떤 정보가 필요했으며, 사람에게 얼마나 많은 일이 남았을까요? 틀리거나 불완전한 사례는 어떻게 처리했을까요? 이런 내용이 있어야 에이전트가 생산성을 높였다는 일반적 주장보다 사례 연구가 유용해집니다.

제품의 향후 방향에는 운영 중 교정과 판단을 지속적 갱신에 반영하는 방식, 에이전트 구축 지원이 포함됩니다. 이때 제안된 개선과 회사 규칙에 승인된 변경을 어떻게 구분할지가 중요해집니다. 작업 흐름을 빨리 생성하는 능력만큼 중요한 설계 질문입니다.

에이전트를 도입하는 기업에는 규칙을 안전하게 바꾸고 영향을 설명하는 능력이 가장 강한 성숙도의 신호일 수 있습니다. 시연 당일에만 이해할 수 있는 기반은 규정, 사람, 시스템이 달라지면 유지하기 어려워집니다.

기업 에이전트는 자기 답변이 어떤 행동을 허용하는지 알아야 한다

Aquarium은 조직의 의미와 통제를 에이전트 플랫폼의 일부로 다룬다는 점에서 지켜볼 만합니다. 그럴듯한 문단을 찾는 것보다 까다로운 목표지만 기업이 실제로 해야 하는 일에 가깝습니다.

시범 도입의 질문은 에이전트가 규정을 잘 아는 듯 말하는지가 아닙니다. 올바른 정보가 올바른 결정에 도달하고, 권한 있는 사람이 다음 단계를 승인하며, 이후 조직이 무슨 일이 있었는지 설명할 수 있는지입니다.

출처

• Sakana AI: Aquarium 발표, 2026년 10월 23일.
• Sakana Aquarium 플랫폼 개요, 2026년 10월 26일 확인.

결정의 근거 자료를 남겨두세요

보관 권한이 있는 원본 자료와 검토한 노트를 함께 두는 방법으로 Telli.sh를 활용할 수 있습니다. 노트 작업 공간을 만들어 보세요.