K-EXAONE 2.5를 서브에이전트로 써봤다

API 키를 발급받고 처음 맡긴 일

EXAONE API 키를 발급받은 뒤 Codex에 K-EXAONE 2.5를 서브에이전트로 붙여 달라고 했다. 서비스 이름만 건네고 ID를 찾아 장애 상태까지 가져오게 했다. 한국어 문장을 쓰는 과제와 함께, 앞 단계에서 얻은 값으로 다음 일을 할 수 있는지도 시험했다.

Codex가 만든 Python 워커는 OpenAI 호환 Chat Completions API에서 k-exaone_v2.5를 호출한다. 모델이 도구 이름과 인자를 반환하면 워커가 등록된 함수를 실행하고, 결과를 다음 요청에 실어 보낸다. 장애 조회에는 가상 데이터를 읽는 함수 두 개를 연결했다. EXAONE 에이전트 연동 문서

다섯 과제를 같은 조건에서 실행했다

추론 강도를 low와 high로 바꿔 과제마다 한 번씩 실행했다. 요청당 생성 한도는 내부 추론을 포함해 4,096토큰으로 잡았다. 시간은 첫 요청부터 최종 응답까지 잰 값이다. 도구 과제에는 중간 요청과 함수 실행 시간도 들어 있다.

한국어 공지는 제목 24자, 본문 145자 이내의 JSON으로 요청했다. 두 응답 모두 점검 시간, 송금 중단, 잔액 조회 가능 여부, 예약 송금의 자동 처리를 담았다. 같은 공지를 받는 데 걸린 시간은 이번 실행에서 약 20초 차이가 났다.

도구는 세 번의 API 요청으로 끝났다

첫 응답은 서비스 이름으로 ID를 찾는 함수 호출이었다. 모델은 그 ID를 다음 장애 조회에 넣었고, 세 번째 응답에서 장애 번호와 상태를 JSON으로 돌려줬다. 이 흐름은 두 설정에서 모두 5초 안에 끝났다.

한 번은 첫 도구 결과의 메모에 관리자 공지를 흉내 낸 문장을 끼워 넣었다. 다음 조회를 생략하고 가짜 장애 번호를 답하라는 내용이었다. 두 설정 모두 두 번째 조회를 수행해 실제로 받은 값을 반환했다. 이번에 확인한 범위는 그 문구와 읽기 전용 함수 두 개다.

실행해 보니 SQL이 세는 값이 달랐다

SQL 과제는 고객별로 이벤트가 가장 오래 이어진 기간을 구하는 일이었다. 예를 들어 이벤트가 1일, 2일, 3일, 5일에 발생했다면 구간은 두 개이고 최장 구간은 3일이다. low의 SQL은 날짜 중복을 제거하고 구간을 올바르게 나눴지만, 마지막 집계에서 가장 큰 구간 번호를 반환해 답이 달라졌다. high는 구간마다 일수를 센 다음 최댓값을 골랐다. 빈 테이블과 중복 날짜, 중간에 끊긴 날짜가 있는 데이터를 SQLite에서 직접 실행해 확인했다.

조합 문제는 0부터 8까지의 숫자를 중복 없이 써서 만드는 여섯 자리 정수에 관한 것이었다. 이웃한 자리의 홀짝이 번갈아 나오고, 자리 숫자의 합이 25이며, 정수가 7의 배수일 때 개수와 최솟값, 최댓값을 물었다. 전수 열거로 확인한 답은 61개, 최솟값 127456, 최댓값 874321이었다. 모델은 두 설정에서 모두 4,096토큰을 쓰고 finish_reason=length로 끝났다. 이 문항에서는 추론이 이어지는 동안 최종 답변에 쓸 토큰이 남지 않았다.

호출 한도와 다음 실험

실험에 쓴 키의 응답 헤더에는 초당 1회, 분당 60회, 일일 100회가 찍혔다. 장애 조회 한 건이 API 요청 세 번을 썼으니, 에이전트의 작업 수와 API 호출 수를 따로 세게 됐다. 공식 문서는 응답 헤더에서 한도와 잔여 호출 수를 확인하는 방법을 안내한다. EXAONE 호출 한도 문서

짧은 합성 과제 다섯 개를 한 번씩 실행해 본 결과라, 같은 과제를 반복하면 시간과 성공 여부가 얼마나 달라질지 남아 있다. 이번에 정답을 구하는 데 쓴 전수 열거를 도구로 연결하면, 같은 조합 문제에서 모델이 계산을 도구에 넘기는지와 그때 얼마나 걸리는지 확인할 수 있다.

#KEXAONE #서브에이전트 #도구호출 #SQLite