운영 중인 시스템이 스스로 나아지려면, 먼저 그 시스템이 제대로 읽혀 있어야 한다.

추천 흐름, 검색 순서, 알림 발송 같은 시스템은 서비스를 시작하는 순간 어정쩡한 상태에 들어간다. 모두 중요하다고 말하지만 어떻게 도는지는 설명하는 사람이 거의 없다. 지표 하나를 바꾸려면 몇 달을 기다려야 하고, 바꾼 뒤에도 실제 흐름으로 확인해야 한다. Pavo 가 하려는 일은 시스템을 읽고, 변경을 찾고, 효과를 증명하는 이 세 동작을 몇 번이고 돌릴 수 있는 흐름으로 만드는 것이다.

최종 사용자를 위한 조수가 아니라 개발과 제품 팀 뒤에 놓는 플랫폼이다. 고객 자신의 클라우드 계정에서 돌고, 코드 저장소와 데이터 저장소, 화면판, 실험 플랫폼에 읽기 전용으로 연결하며, 기본으로 밖에 내보내지 않고, 목표는 지표 하나를 실제로 움직이는 것이다.

움직이지 않는 것은 모델이 아니라, 시스템이 어떻게 도는지 아무도 설명하지 못하는 쪽인 경우가 많다

추천 흐름이 삼 년을 돌았고 코드는 여러 번 갈렸고 화면판은 두 번 새로 만들어졌으며, 처음에 왜 어떤 특징의 무게를 올렸는지에 대한 답은 오래된 동료 몇 사람의 기억에 흩어져 있다. 새로 맡은 사람이든 대리인이 맡든 첫 번째 벽은 코드를 어떻게 쓰는가가 아니라 이 시스템이 어떻게 도는가다. 더 곤란한 것은 지표를 바꾸는 일이 원래 비싸다는 점이다. 한 번 잘못 짚으면 운영 사고가 되니 팀은 확실한 작은 변경만 하고, 지표를 정말 움직일 큰 변경은 할 일 목록 맨 아래에 누워 있게 된다.

첫 단계, 흩어진 경험을 출처가 붙은 한 권으로 읽어 낸다

첫 모듈은 System Knowledge 라고 한다. 연결된 출처의 정보를 사실 하나하나로 뽑아 내고, 각각에 종류와 출처를 붙인다. 이 문장이 어느 파일의 몇 번째 줄에서 왔는지, 어느 질의에서 왔는지, 어느 실험에서 왔는지. 뽑는 것으로 끝나지 않는다. 사실을 장마다 검토할 수 있는 지침서로 정리하며, 그것이 System Book 이다.

이 지침서는 모델이 혼자 떠드는 것에 기대지 않는다. Pavo 는 Knowledge Bench 라는 확인 장치를 함께 두어 팀이 직접 문제를 내고 점수를 매기게 한다. 점수가 모자라면 지식이 아직 제대로 이해되지 않았다는 뜻이고, 대충 비슷해 보인다는 뜻이 아니다. 파는 쪽은 이 원칙을 한 줄로 적었다. 지식은 가정되는 것이 아니라 검증되는 것이다.

둘째 단계, 문제를 작은 몫을 나눠 맡은 대리인 한 팀에 넘긴다

둘째 모듈은 Agent Studio 이고, 쌓아 둔 이해를 쓰는 역할을 맡는다. 진짜 문제를 넣으면 먼저 계획으로 나눈다. 학문의 틀, 모듈 나누기, 근거 규칙을 모두 탁자 위에 올려 놓고 승인을 기다린다. 고개를 끄덕이지 않으면 움직이지 않는다.

승인되면 일은 대리인 팀으로 나뉜다. 각 대리인은 확인할 수 있는 작은 일 하나만 맡고, 그 위에 조정을 맡는 Director 가 앉아 일을 나누고 다른 대리인의 진행을 지켜보며 각자의 발견을 맞추고 문제가 생기면 직접 들어간다.

이 구조의 값은 확인할 수 있다는 데 있다. 결과는 모두 종류와 인용과 판을 가진 답이며, 무엇을 증명했는지 분명히 적고 증명하지 않은 것도 똑같이 분명히 적는다. 파는 쪽의 설명은 곧다. 몇 주짜리 연구 질문을 대리인 하나에 던지면 몇 시간을 돌면서 아무도 보지 못한 작은 결정을 백 번쯤 하고 마지막에 자신 있게 틀린 답을 돌려준다. 해법은 더 똑똑한 대리인으로 바꾸는 것이 아니라 지금의 대리인 둘레에 구조를 주는 것이다.

결정이 필요한 곳에서 멈추게 한다

Pavo 는 결정 지점과 진행 소식을 나눈다. 사람이 판단해야 하는 경계에서만 멈추고, 무엇이 바뀌었는지, 왜 당신이 정해야 하는지, 어떤 선택이 어느 길을 여는지를 알린다. 나머지 시간에는 이 팀이 스스로 돈다.

개선 한 바퀴는 어떻게 도는가

두 단계를 이으면 하나의 순환이 된다. 기술 더미를 연결하고, 시스템 지식을 세우고, Agent Studio 에서 사업을 돌리고, 지표를 움직이는 변경을 내놓는다. 찾은 것은 지침서로 되돌아가 다음 바퀴의 출발점이 된다.

기업용 형태에서는 이 순환이 여덟 주로 압축된다. 첫 주에 지표와 성공 기준을 정하고, 둘째 주에 시스템을 연결하고, 셋째와 넷째 주에 여러 후보를 병렬로 평가해 먼저 망 밖 환경에서 이길 안을 고른다. 다섯째와 여섯째 주에 그 안을 실제 실험으로 내보내고, 일곱째와 여덟째 주에 늘어난 몫을 재고 다음 문제로 옮긴다. 파는 쪽은 이해가 깊어질수록 같은 팀이 더 어려운 연구 질문에 답하는 데 걸리는 시간이 몇 주에서 며칠로 줄어든다고 적었다.

무엇을 당신 환경 안에 남기는가

이런 플랫폼이 기업에 들어갈 수 있는지는 대개 데이터 문제에서 막힌다. Pavo 는 세 가지 배치 형태를 준다. 자기 클라우드에 맡기는 형태로 여러 조직이 쓰지만 조직별로 나눈다. 고객 자신의 클라우드 계정에 두는 형태로 단일 조직, 고객의 열쇠로 암호화, 기본으로 망에 내보내지 않는다. 그리고 규제가 강한 업종을 위한 단단한 판으로, 모든 서비스를 고객 망 안에서 직접 돌리고 제삼자 연결은 두지 않는다.

세 가지 원칙이 모든 형태에 흐른다. 연결은 읽기 전용이고 연결 도구는 당신의 출처에서 끌어오기만 하며 당신의 시스템에 절대 쓰지 않는다. 고객 데이터는 모델 학습에 쓰지 않는다. 외부 언어 모델은 남기지 않는 조건으로 돌린다. 플랫폼은 SOC 2 Type II 와 ISO/IEC 27001 인증을 갖추었고 해마다 독립 침투 시험도 받는다.

시작 전에 알아 둘 것

값은 공개되지 않는다. 비용은 두 부분이다. 시스템 규모로 정해지는 플랫폼 요금과, 쓴 만큼 내는 연구 작업량이며 단위는 ASU 라 하고 "응용 과학 대리인이 한 자리에서 일한 몫"으로 정의된다. 파는 쪽은 자리당 과금을 하지 않고, 출처를 얼마든 연결해도 따로 값을 받지 않으며, 플랫폼 요금은 연 단위 계약으로 가고 구십 일의 그만둘 수 있는 기간을 준다고 분명히 적었다.

개인용 판은 없고, 처음 접촉에서 순환이 돌기까지는 영업 절차를 거친다. 순환을 직접 돌리고 싶은 팀은 스스로 쓰는 방식을 고른다. 지표를 한 번 증명한 뒤 들어가고 싶으면 과학자가 상주하는 방식을 고를 수 있다. 응용 과학 담당이 팀에 들어가 지표 하나를 두고 약 여덟 주에 한 바퀴를 돌린 뒤 순환을 팀에 돌려준다. 이미 대리인 시스템이 호출 사슬 기록을 내고 있다면 연결에 기술 더미를 옮길 필요가 없고 있는 기록에서 시작할 수 있다. 반대로 진짜 운영 데이터와 충분한 맥락이 있어야 하며 없으면 값어치가 다 나오지 않는다.

풀려는 것은 인공지능이 코드를 대신 쓰게 하는 일이 결코 아니다. 아무도 설명하지 못하는 운영 시스템을 검토할 수 있고 검증할 수 있고 몇 번이고 나아질 수 있는 공개 지식으로 바꾸는 일이다.