기업용 AI 에이전트는 언제 행동해야 할까? Paxis에 전용 Decision 모델을 붙이는 이유

기업용 AI 에이전트에서 어려운 부분은 문장을 잘 만드는 일이 아니라 다음 행동을 고르는 일입니다. 같은 자연어 요청이라도 바로 답해야 할 때가 있고 도구를 불러야 할 때가 있으며 실행 전에 사람에게 확인을 받아야 할 때가 있습니다. ThakiCloud는 이 판단을 별도의 작은 모델로 떼어 내 Paxis 에이전트 런타임에 붙이는 작업을 하고 있습니다. 이 글은 그 첫 번째 기록입니다. 모델 학습과 서빙 측정은 끝났습니다. Paxis에 실제로 연결해 기존 에이전트와 비교하는 실험은 이제 시작합니다. 두 가지를 섞지 않고 구분해서 적겠습니다.

답변보다 행동 결정이 어려운 이유

사내 시스템에 연결된 에이전트는 질문에 답하는 데서 끝나지 않습니다. 데이터를 조회하고 여러 업무 도구를 이어 부르며, 때로는 주문을 취소하거나 설정을 바꾸는 것처럼 실제 상태를 변경합니다. “지난달 매출을 알려 줘”와 “고객 A의 주문을 취소해 줘”는 문장 구조가 비슷하지만, 앞의 것은 조회 후 답하면 되고 뒤의 것은 실행 전에 확인이 필요할 수 있습니다. “이 직원의 급여를 바꿔 줘”는 요청자의 권한에 따라 거절해야 할 수도 있습니다.

일반적인 LLM 에이전트는 이 판단을 생성 모델에 상당 부분 맡깁니다. 그런데 자연스러운 답변을 만드는 능력과, 회사 정책에 맞는 행동을 고르는 능력은 같지 않습니다. 설명은 훌륭한데 실행하면 안 되는 도구를 부르기도 하고 필요한 확인 절차를 건너뛰기도 합니다. 반대로 고객이 필요한 정보를 이미 줬는데도 같은 질문을 되풀이하면 업무가 느려집니다. 두 방향의 실수가 모두 제품 품질을 깎습니다.

다음 행동을 7개 중 하나로 고르게 했습니다

우리는 에이전트의 다음 행동을 일곱 가지로 정의했습니다.

코드	행동	언제 고르는가
A	`ANSWER`	도구 없이 바로 답할 수 있을 때
B	`ASK_CLARIFICATION`	처리에 필요한 정보가 빠졌을 때
C	`ASK_CONFIRMATION`	정책상 실행 전에 사용자 확인이 필요할 때
D	`CALL_TOOL`	도구 하나로 끝날 때
E	`CALL_MULTIPLE_TOOLS`	앞 도구의 결과가 다음 도구에 필요할 때
F	`ESCALATE`	사람이나 다른 팀이 판단해야 할 때
G	`REFUSE`	정책상 하지 말아야 할 때

모델은 긴 JSON이나 추론 과정을 쓰지 않습니다. 정책과 도구 목록과 요청을 읽은 뒤 A부터 G까지의 글자 하나만 냅니다. 출력이 한 토큰이라 빠르며 형식이 깨질 일도 없습니다.

여기서 선을 분명히 그어 둡니다. Decision 모델이 CALL_TOOL을 골랐다고 해서 어떤 도구를 어떤 인자로 부를지까지 정하지는 않습니다. 그건 기존 에이전트가 합니다. 모델이 실행을 권했다고 실행 권한이 생기지도 않습니다. 권한은 처음부터 끝까지 결정론적 정책 계층이 쥡니다.

2B, 4B, 9B를 같은 데이터로 학습해 비교했습니다

Qwen3.5의 2B, 4B, 9B 체크포인트에 같은 학습 데이터와 같은 출력 계약을 적용했습니다. 학습 데이터는 한국어 상담 정책 시나리오를 코드로 생성했으며 정답 라벨도 정책 실행기가 계산했습니다. LLM이 쓴 라벨은 없습니다. 특히 사용자가 필요한 정보를 이미 줬는지, 실행 전에 확인이 필요한지, 정책이 금지하는지, 도구가 하나로 충분한지를 가르는 경계 사례를 많이 넣었습니다. AND, OR, NOT이 섞인 조건도 계산하도록 학습했습니다. 이전 버전 모델은 “제한 조항이 보이면 일단 막는” 버릇이 있었습니다. 그래서 NOT 조건에서 실행해야 할 31건을 하나도 맞히지 못했습니다.

비교에서 가장 중요하게 본 것은 평균 정확도가 아니라 두 종류의 실수입니다. 정책상 거절하거나 확인하거나 이관해야 하는데 도구를 실행해 버리는 위험 오실행과, 실행하거나 답해야 하는데 막아 버리는 과잉 차단입니다. 아래 val2는 학습 전에 봉인해 둔 600문항입니다. 학습에 쓰지 않은 도메인과 문장 틀로 만들었습니다.

지표	2B	4B	9B
val2 정확도	96.5%	97.7%	97.8%
val2 위험 오실행 (294건 중)	10	3	7
val2 과잉 차단 (292건 중)	8	0	5
정책 조합 회귀셋 정확도	87.0%	100%	93.8%
다중 도구 호출 recall (회귀셋 391건)	91.3%	98.2%	92.3%

크게 만든다고 다 좋아지지는 않았습니다. 9B는 정확도가 4B와 비슷했지만 위험 오실행과 과잉 차단이 더 많았습니다. 우리 작업에서 중요한 것은 행동의 경계를 안정적으로 가르는 능력이었는데, 이 기준에서는 4B가 가장 나았습니다. 같은 A~G 판독을 붙인 기존 27B 생성형 정책 모델도 비교했습니다. 이 모델은 val2 정확도가 74.0%에 그쳤고 위험 오실행이 26건이었습니다. 다만 이 모델은 글자 판독과 AND/OR/NOT 데이터를 학습하지 않았으니, 이 숫자는 27B가 낼 수 있는 성능의 하한으로 읽어야 합니다.

정책 조합 회귀셋의 100%는 개발 중에 여러 번 열어 본 데이터에서 나온 값입니다. 운영 환경에서 100% 맞힌다는 뜻이 아닙니다. 그래서 숫자 하나보다 여러 평가셋에서 같은 방향이 나오는지를 더 믿었습니다.

4B에 남은 약점과, 고치려다 멈춘 이유

4B도 약점이 있습니다. 고객 명의 주문이 여러 개일 때 “고객의 말로 특정되어야 처리한다”는 조항이 있으면, 고객이 “운동화 주문”이라고 이미 대상을 말했는데도 다시 묻는 경우가 있었습니다. 한 개발 평가셋 300문항에서 32건이 이런 과잉 되묻기였습니다. 위험한 실수는 아니지만 사용자를 짜증 나게 합니다.

그래서 “대상을 특정했으면 실행, 특정하지 않았으면 질문”을 가르는 대조 데이터 420건을 만들어 4B를 한 번 더 학습했습니다. 과잉 되묻기는 32건에서 9건으로 줄었습니다. 그런데 모델이 실행 쪽으로 기울면서 전체 위험 오실행이 6건에서 16건으로 늘었습니다. 사전에 정해 둔 기준대로 이 패치는 버리고 원래 4B를 유지했습니다. 되묻기 한 번은 사용자가 답하면 끝나지만, 잘못된 실행은 되돌리기 어렵기 때문입니다.

서빙: 판단 한 번에 약 60ms

전용 모델을 붙이면 에이전트가 행동할 때마다 판단 비용이 더해지므로, 서빙 속도도 품질만큼 중요합니다. 병합한 bf16 4B 모델을 vLLM 0.29.0으로 띄우고 B200 한 장에서 쟀습니다. /v1/completions에 A~G 선택 제한을 걸고 최대 1토큰만 생성하게 했습니다.

단건 요청의 지연시간은 중앙값 61.5ms, 95번째 백분위 63.3ms였습니다. 동시 요청을 32개로 늘리면 초당 288건을 처리했습니다. 974건 모두 유효한 글자를 냈으며 가중치는 약 7.9GiB를 차지했습니다. 같은 조건에서 2B는 중앙값 43.8ms, 초당 359건으로 더 빨랐지만 처음 보는 정책 문서 형식에서 정확도가 크게 떨어졌습니다. 그래서 4B를 주력으로, 2B를 처리량이 중요한 환경의 경량형으로 두었습니다. 2B는 Hugging Face에 공개했습니다. 4B는 Paxis 연동 검증을 마친 뒤 공개할 예정입니다.

이 60ms는 Decision 모델만 따로 잰 추론 시간이라는 점도 짚어 둡니다. 네트워크 호출, 프롬프트 구성, 에이전트 실행을 합친 전체 요청 시간은 Paxis 통합 실험에서 따로 재야 합니다.

Paxis에서는 정책 계층 사이에 끼웁니다

Paxis는 ThakiCloud의 Agent-Native Cloud 제어 평면입니다. 스킬, 도구, 정책, 감사 로그를 일급 리소스로 다루며 에이전트의 모든 도구 호출은 정책 게이트를 지나며 감사 기록을 남깁니다. Decision 모델은 이 구조를 바꾸지 않고 기존 정책 검사와 승인 절차 사이에 들어갑니다.

순서에 의미가 있습니다. PolicyStation이 바깥에서 먼저 평가하므로, Decision 모델이 실행을 권해도 정책이 금지한 도구는 실행되지 않습니다. Decision Station은 실행 범위를 좁힐 수만 있고 넓히지는 못합니다. 모델 서버가 응답하지 않거나 이상한 글자를 내면 판단을 기록만 하고 기존 정책과 승인 경로로 넘깁니다. 모델 장애가 권한을 늘리는 일은 없습니다.

코드를 살펴보니 바로 해결해야 할 빈틈도 있었습니다. 실행 전 사용자 확인을 받는 승인 장치는 이미 있지만 기본값이 꺼져 있고 웹 채팅에서만 응답할 수 있습니다. 사람에게 이관하는 경로는 아직 없습니다. 모델이 ESCALATE를 정확히 골라도 받아 줄 곳이 없다면 제품은 나아지지 않습니다. 그래서 첫 단계에서는 이관 판정을 차단과 감사 기록으로 처리합니다. 확인 판정은 기존 승인 장치를 재사용합니다. 어떤 경우에도 확인이나 이관 판정을 실행 성공으로 처리하지 않습니다.

먼저 Shadow Mode로 비교합니다

오프라인 정확도가 좋다고 바로 업무 실행 경로에 넣지는 않습니다. 첫 단계는 Shadow Mode입니다. 기존 에이전트는 평소대로 움직이고 Decision-4B는 같은 상황을 따로 판단해 기록만 합니다. 실행을 막거나 바꾸지 않습니다.

이 비교에서 알고 싶은 것은 모델이 A~G를 얼마나 맞히느냐가 아닙니다. 기존 에이전트가 잘못한 행동을 Decision-4B가 얼마나 잡아내는지, 그리고 기존 에이전트가 잘 처리한 요청을 얼마나 잘못 막으려 하는지입니다. 이 두 숫자의 균형과 실제 지연시간 증가분을 보고 나서 모든 요청에 적용할지, 위험도가 높은 쓰기 작업에만 적용할지를 정합니다. 잡아내는 것이 거의 없고 지연만 늘어난다면 전체 적용은 접습니다.

ThakiCloud가 이 구조로 얻으려는 것

모든 판단을 큰 모델 하나에 맡기는 대신, 일을 셋으로 나눕니다. 범용 LLM은 업무를 이해하고 계획합니다. 작은 Decision 모델은 다음 행동을 분류하고 정책과 승인 시스템은 실제로 실행해도 되는지를 결정론적으로 통제합니다. 범용 LLM을 작은 모델로 바꾸려는 것이 아닙니다. 따로 떼어 낼 가치가 있는 판단 하나를 찾아 그 부분만 싸고 빠르게 전문화하려는 것입니다.

이 구조는 ThakiCloud의 두 제품이 맞물리는 지점이기도 합니다. Decision 모델은 ai-platform의 자체 GPU와 vLLM 서빙 위에서 돌기 때문에 외부 API로 요청 내용을 보내지 않습니다. 온프렘이나 소버린 환경에서도 같은 구성을 쓸 수 있습니다. 4B 모델은 판단 한 번에 약 60ms, GPU 한 장으로 초당 수백 건을 처리하므로 에이전트의 판단 비용을 낮게 유지할 수 있습니다. 그 위에서 Paxis는 정책 게이트와 감사 로그로 행동을 통제합니다.

아직 말할 수 없는 것

학습과 평가 데이터는 모두 코드로 만든 한국어 상담 정책 시나리오입니다. 실제 기업 정책 문서와 실제 대화에서 같은 성능이 나온다는 보장은 없습니다. 봉인 평가셋도 우리 생성기 계열에서 나왔기 때문에, 실제 업무와 완전히 독립적인 시험이라고 보기는 어렵습니다. 위험 오실행도 0이 아닙니다. val2에서 3건이 남았습니다. 그래서 Decision 모델은 안전장치를 대신하지 않습니다. 실제 도구 실행 앞에는 항상 결정론적 권한 검사를 두어야 합니다.

다음 글에서는 Paxis의 실제 도구와 정책으로 만든 통합 시나리오에서 기존 에이전트와 Decision-4B를 같은 요청으로 비교한 결과를 공유하겠습니다. 기존 에이전트가 틀렸는데 Decision-4B가 맞힌 사례와, 반대로 Decision-4B가 정상 업무를 방해한 사례를 모두 보여 드리겠습니다.