인사이트

[강좌] 도구를 부르는 AI, 비용은 어디서 늘어날까

아이티데일리 (IT DAILY) ·

전현상 마이크로소프트 글로벌 블랙 벨트팀 AI 앱 솔루션 엔지니어

✦ AI 요약

전현상은 아이티데일리 연재에서 도구를 호출하는 AI의 비용 증가 지점을 다룬다.

짧은 도구 사용 과제에서는 추론 강도를 높여도 통과 수가 계속 늘지 않았고, GPT-5.2는 '없음' 60건 중 59건, '낮음' 60건 중 60건 통과했다.

이 글은 마지막 답변만으로는 비용을 설명하기 어렵다고 보고, 호출 횟수·결과·종료 지점을 함께 봐야 한다고 말한다.

아이티데일리의 연재 시작 주제는 도구를 호출하는 AI의 비용 증가 지점이다. 필자는 전현상이며, 마이크로소프트 글로벌 블랙 벨트팀 AI 앱 솔루션 엔지니어다.

전현상은 에이전트·지식 검색·AI 평가 체계의 실제 운영 환경 정착을 하고 있다. 그의 경력 출발점은 신호처리 연구다.

전현상은 SK에서 1200만 사용자 규모 서비스 개발에 참여했고, ML 플랫폼 구축 사업에도 참여했다. AWS에서는 15년 이상 기업 AI 도입 지원을 담당했다.

생성형 AI는 시연 중심에서 실제 업무 시스템 도입으로 이동하고 있다. 그러나 도입 현장에서는 기대보다 우려가 더 자주 나오고 있다.

현장에서는 추론 모델 성능 평가와 별개로 비용 예측이 어렵다는 반응이 나온다. 높은 벤치마크 점수에도 실제 자사 업무 수행에는 한계가 있다는 반응도 나온다.

성능 지표와 청구서의 격차, 데모와 실무의 격차는 생성형 AI 도입을 막는 가장 큰 걸림돌로 제시된다. 이런 문제는 생성형 AI가 실제 업무로 들어오는 상황에서도 도입을 지연시키는 요인으로 연결된다.

강좌는 AI 활용의 판단 기준을 직감이 아니라 측정 가능한 지표로 옮기려는 데 목적을 두고 있으며, 간극 파악 방식도 감이 아닌 측정으로 전환하려는 구도다. 이를 위해 필자는 공개 실험 2갈래를 진행했다. 실험 1은 reasoning effort를 단계별로 조정하면서 동일 작업의 품질·비용·응답 시간을 반복 측정하고, 캐시·재시도·요금제 등 운영 변수가 청구서에 미치는 영향을 점검하는 방식으로 이뤄졌으며, 성격상 AI 청구서 분석에 해당한다. 실험 2는 문서 작성·검토 등 실제 업무 과제를 AI에 위임한 뒤 AI 결과물을 채점하는 방식으로 진행됐으며, 성격상 AI 성과 채점에 해당한다. 두 실험은 토큰 사용량이 아니라 성과 1건 획득 비용이라는 핵심 질문으로 수렴한다.

또한 필자는 슬라이드 대신 검증 가능한 근거를 제공하는 것을 목적으로 삼고, 모든 수치를 원자료·분석 코드·수정 이력과 함께 공개 저장소에 게시했다. 누구나 같은 방법으로 재확인할 수 있도록 조치했으며, 실패한 호출 기록과 빗나간 예상 기록도 유지했다. 이러한 구성은 도입 검토 엔지니어·아키텍트·예산 결정 관리자가 도입 판단과 예산 결정의 근거로 삼을 수 있도록 하려는 데 초점이 맞춰져 있다.

연재 주제는 AI를 청구서와 성과 기준으로 평가하는 것이다.

8월호 주제는 추론 모델의 비용 정당화 시점과 다단계 작업의 모델·강도 비교다.

9월호 주제는 GDPVal RealWorks와 벤치마크 성공률과 실제 업무 성공 간 차이다.

10월호 주제는 도구 호출 시 필요한 추론량과 에이전트 반복 루프와 숨은 비용이다.

11월호 주제는 GDPVal RealWorks와 파일 읽기 AI 채점기의 신뢰도와 비용이다.

12월호 주제는 추론 비활성화가 기본값으로 남은 이유와 짧은 사실형 작업과 PAYG·PTU 비용·처리량이다.

2027년 1월호 주제는 샌드박스·멀티모달·장시간 실행 환경 필요성과 두 실험군 종합이다.

이 글은 필자의 개인 기술 기고이며, 소속 회사의 공식 입장을 대변하지 않는다. 수치 기준은 공개 저장소 실험 기록·집계 결과다.

짧은 도구 사용 과제에서는 추론 강도를 상향해도 통과 수가 지속 증가하지 않았다.

앞선 호들에서는 비용 차이와 결과물의 실사용 가능성을 살폈고, 이번 호의 초점은 결과 도출까지의 과정을 점검하는 데 있다. 8월호의 점검 대상은 유사한 답변이어도 모델 추론 설정별 비용 차이 가능성이었고, 9월호의 점검 대상은 AI 완료 보고와 실제 사용 가능한 결과물의 일치 여부를 확인하는 일이었다.

사용자에게 보이는 것은 최종 답변 1회이지만, 최종 답변 이전의 실제 진행은 여러 단계의 연속이다. 필자는 답변은 한 번 보이지만 호출은 여러 번 이뤄질 수 있다고 설명했다. 이번에 과정 중 쟁점으로 제시된 것은 AI의 검색·계산·결과 읽기 동안 모델이 몇 번 재호출되는지의 문제다.

에이전트는 목표를 받아 도구를 사용한 뒤 결과를 보고 다음 행동을 선택하는 AI로 정의된다. 이 에이전트는 검색 결과를 읽은 뒤 계산기를 호출할 수 있고, 파일을 수정한 뒤 명령어를 실행해 확인할 수도 있다. 이처럼 에이전트형 AI는 도구를 오가며 여러 단계를 거친다.

이 과정에서는 모델 입력 일부 축소 비율과 전체 작업 비용 감소 비율을 구분해 볼 필요가 있다. 답변이 비슷하게 보이더라도 과정에서 이뤄지는 모델 호출이 누적되면 비용도 함께 누적될 수 있기 때문이다. 또한 채점 전 종료된 실행에도 비용이 발생한다.

따라서 작업 결과와 종료 사유, 사용량을 함께 기록할 필요가 있다. 그래야 결과가 만들어지는 중간 과정을 추적하면서, 최종 답변에 이르기까지 어떤 호출과 비용이 쌓였는지 함께 점검할 수 있다.

도구를 쓰는 AI 작업을 이해하려면 모델 호출과 도구 실행을 구분해서 봐야 한다. 모델 호출은 AI 서비스에 판단·답변을 요청하는 의미이고, 도구 실행은 검색·계산 등 실제 수행 단계의 의미다. 진행 방식은 모델의 도구 선택, 도구 결과 수신, 모델 재호출의 순서로 이뤄지며, 1회 모델 응답 안에서도 복수 도구 실행 지시가 가능하다.

비용을 판단할 때는 마지막 답변만으로는 불충분하다. 그 이유는 모델 재전송 지시와 이전 작업 결과가 입력에 포함되기 때문이다. 토큰은 모델의 텍스트 처리 계수 단위이며, 사용자에게는 짧은 답변이 제시될 수 있어도 최종 답에 도달하는 과정의 입력·출력을 별도로 확인할 필요가 있다.

그림 1은 도구 사용 AI의 1개 작업에서 비용 가산 4개 지점을 보여주는 개념 설명도다. 다만 그림 1은 특정 실행을 관측한 것이 아니며, 압축·캐시가 비용에 미치는 영향은 가능한 설명일 뿐 확정된 것은 아니다.

실험에서는 문항 예시를 제시했다. 문항 내용은 헬리오 로보틱스 연간 매출 조회, 베가 로지스틱스 연간 매출 조회, 두 기업 매출 합계 계산으로 구성됐다. 한국어 번역 문항도 함께 제시됐다. 헬리오 로보틱스와 베가 로지스틱스는 실험용 가상 기업[3]이다.

이 실험은 단순한 덧셈 자체보다 필요한 정보를 찾고 계산 도구를 거쳐 요구한 답을 완성하는 절차를 검증 대상으로 삼았다. 문항 검증 대상은 각 자료 탐색, 계산 도구 전달, 요구 답 산출 과정이었다. 채점 기준을 포함한 절차는 두 기업을 각각 조회하고, 계산기로 합산한 뒤, 정수 하나로 응답하는 방식[3]이었다.

실험에서는 실시간 인터넷 검색을 사용하지 않았다. 대신 정해진 검색 도구 기능을 사용했으며, 이 도구는 각 기업 매출 자료를 반환하도록 설정됐다. 이는 동일 자료 제공을 통해 검색 결과 변동 영향을 축소하기 위한 목적이었다.

또한 이 실험에서는 반복 측정 방식을 적용했다. 새 문항 20개를 준비했으며, 문항 주제는 도구 필요 여부 판단과 사용 순서 판단이었다. 이 가운데 도구 불필요 문항은 6개, 도구 1회 필요 문항은 8개, 도구 여러 번 필요 문항은 6개였다.

실험은 응답이 도구 필요성과 사용 순서를 올바르게 판단하는지도 함께 반복 측정했다. 아울러 불필요한 도구 호출 회피 판단도 관찰 대상[3]에 포함됐다.

실험은 같은 조건에서 반복 실행해 비교 가능성을 맞추는 방식으로 설계됐다. 각 문항당 동일 모델·설정 기준 3회 실행했고, GPT-5.2 추론 강도 5단계 조정을 적용했으며, GPT-4o 별도 비교 기준을 설정했다. 여러 모델을 동일 방식으로 호출·평가했고, 사용 플랫폼은 Microsoft Foundry였다.

전체 기록 규모는 360건이었다. 이는 20개 문항×3회×6조합 실행으로 산출됐다. 이전 글과 실행 수는 동일했지만, 이전 글과 입력 문항은 상이했고, 이전 글과 도구 사용 절차도 상이했다. 표 1의 주제는 측정 조건 1 - 짧은 도구 사용 실험이었다.

그림 2는 두 기업 매출 조회·합산 문항 처리 절차를 설명하는 도식이었다. 그림 2는 모델 판단과 검색·계산 도구 실행을 구분해 구성됐고, 도구 결과를 수신한 뒤 모델의 다음 행동 선택 관계를 설명했다. 다만 그림 2는 특정 실행의 호출 횟수를 측정한 차트는 아니었다.

실험 전에는 여러 도구 연결 문항에서 추론 강도가 상승하면 통과 수가 증가할 것으로 예상했다. 그 근거로는 자료 탐색 후 필요한 계산 계획이 필요하다는 점이 제시됐다. 이에 따라 추론 미사용 설정에 불리할 것으로 봤고, 높은 단계에 도달하면 품질의 추가 이득은 작지만 비용은 증가할 것으로 예상했다.

먼저 전체 결과를 확인한 결과, GPT-5.2는 '없음'에서 60건 중 59건 통과했고 '낮음'에서 60건 중 60건 통과했다. 추론 미사용 설정도 높은 통과 수를 보였다. 강도 단계를 순차적으로 높여도 결과가 순차적으로 개선되지는 않았다. GPT-4o를 포함한 6개 조합의 전체 결과는 그림 3에 수록됐다.

초기 가설의 대상은 여러 도구 연결 문항이었다. 사전 선정 문항 수는 6개였고, 각 문항은 3회 실행됐다. 이에 따라 해당 문항군의 분석 대상은 18건이었다.

이 문항군에서도 GPT-5.2는 '없음'에서 17건 통과했고 '낮음'에서 18건 통과했다. 해당 문항군에서 '없음'과 '낮음'의 격차는 1건이었다. 해당 문항군에서도 강도를 추가로 높인다고 통과 수가 증가하지는 않았다.

앞선 예고 문구에서 해당 실험의 처음 값 기록 주체를 '없음'이 아니라 '낮음'으로 적는 것이 맞지만, 그 문구를 전체 결과에 그대로 일반화해서는 안 되므로 해석 범위를 축소할 필요가 있다. 이번 표본에서 '낮음'은 모든 응답을 통과한 최저 추론 강도였고, '없음'은 거의 모든 응답을 통과했다. 다만 1건 차이만으로 낮은 추론 강도가 모든 도구 작업에서 더 정확하거나 더 경제적이라는 결론을 내릴 수는 없다.

비용은 실제 청구액이 아니라 모델 서비스가 보고한 입력·출력 사용량에 고정 가격표를 곱해 산정한 계산값으로 정의했다. 여기서 'API 계산 비용'은 위 계산값을 뜻하며, API는 프로그램이 모델 서비스를 호출하는 인터페이스다. 따라서 계산 비용은 실제 청구서 대조 금액과는 별개다.

각 설정의 총비용은 통과 여부와 무관하게 실행한 60건으로 나눠 계산했고, 이 평균 비용을 과제 1000회 실행 기준으로 환산했다. 이 1000회 기준 수치는 실제 1000회 실행값이 아니라 동일 단위 비교를 위한 환산값이다. 그 기준에서 GPT-5.2 '없음'은 약 2.76달러, GPT-5.2 '낮음'은 약 2.84달러, GPT-5.2 '매우 높음'은 약 3.50달러였다. 이번 채점에서 '낮음'과 '매우 높음'은 모두 통과했고, 두 설정 사이에는 비용 차이가 있었다.

비용과 통과 수 비교는 모두 표본 내부 평균과 판정값을 바탕으로 제시됐다. 비용 비교 기준은 실행당 평균이었고, 통과 기준은 GPT-4o 채점기의 2점 판정이었다. 이번 표본 결과에서는 '없음' 비용이 더 낮았고, 이번 표본 결과에서는 '낮음' 통과 응답이 1건 더 많았다. 그림 3은 짧은 도구 사용 실험의 통과 수·API 계산 비용을 담았고, 비용 산식은 전체 문항의 과제 1,000회 실행 환산 평균이었다. 비용 집계에는 '낮음'의 특이 실행 1건도 포함됐다.

재집계 기준은 여섯 조합별 60건씩으로 전체 360건이었다. 다중 도구 문항군은 미리 분류한 6개 문항으로 구성됐고, 다중 도구 문항군 실행 방식은 각 문항 3회씩 실행하는 방식이었다. 조합별 다중 도구 문항군 건수는 18건이었다. 이번 표본에서는 '없음'이 더 저렴했고 '낮음'이 통과 1건을 더 얻었지만, 결과 활용 기준은 승패보다 추가 비용 대비 업무상 필요성을 점검하는 데 있었다.

또 통과 수의 판정 주체는 GPT-4o 채점기였다. 공개 자료 상태로는 사람 채점과의 일치도 확인 점수가 없었다. 이에 따라 결과 해석 범위는 해당 문항·채점 기준 내부로 한정됐다. 통과 수의 의미 한계도 표본 밖 성공 확률을 뜻하는 것은 아니라는 점에 있었다.

앞선 실험은 짧은 길이와 도구 상호작용 횟수 제한이라는 특성을 지녔다. 이에 파일 수정과 명령어 실행처럼 과정이 장기화하는 사례를 제시하며, 다음 판단을 위해 재전송하는 내용을 줄일 수 있는지와 이를 축소한 뒤에도 과업을 정상적으로 완료할 수 있는지가 추가 질문으로 제기됐다.

이 질문은 별도 입력 압축 실험을 통해 검토됐다. 여기서 프롬프트는 모델에 전달하는 지시·자료를 뜻하고, 프롬프트 압축은 프롬프트 일부를 단축 처리하는 것을 의미한다. 압축 후보 범위는 도구 반환 출력 중 파일 목록, 설치 기록 등으로 설정됐고, 후보는 미리 정한 규칙을 통과한 구간을 기준으로 선정됐다. 반면 작업 지시와 코드, 구조화된 데이터, 코드·설명 혼합 구간, 경계가 불분명한 구간은 비압축 대상으로 뒀다.

다만 후보로 분류된 출력이라고 해서 내부 정보 폐기의 안전성이 보장되는 것은 아니라는 주의점도 함께 제시됐다 [7][14].

과제는 Terminal-Bench 2.1 공개 평가 세트에서 가져왔으며, Terminal-Bench 2.1은 명령어 기반 컴퓨터 작업 수행·결과 검사 성격의 평가 세트다. 비교는 추가 압축 없이 풀이한 방식과 squeez 적용 방식, Headroom 적용 방식, LLMLingua-2 적용 방식으로 나뉘어 이뤄졌다. LLMLingua-2는 마이크로소프트·칭화대 연구진이 공개한 압축 모델이다. 이때 각 방식은 동일 과제의 새 작업공간에서 시작했고, Headroom에는 반복 파일 경로 묶기 중심의 제한된 설정이 쓰였다.

이어 파일 목록을 근거로 무엇이 줄어드는지 파악하기 위해, 104건 실행과는 별개인 검사 자료에서 저장된 도구 출력에 압축기를 적용한 별도 검사가 제시됐다. 이 공개 예시는 실제 검사 사례를 기반으로 했으며, 공개를 위해 비공개 경로는 <LOG_DIR>로 대체됐다. 별도 검사 결과, Headroom은 동일 폴더 경로를 1회만 유지했다.

예시에서는 공통 경로를 덜어내고 파일명만 남겨도 원래 위치를 되살릴 수 있는지를 확인했다.

압축 전 도구 출력 항목 3개는 <LOG_DIR>/2025-07-03_api.log, <LOG_DIR>/2025-07-03_app.log, <LOG_DIR>/2025-07-03_auth.log였다.

압축 후 문자열 항목 3개는 2025-07-03_api.log, 2025-07-03_app.log, 2025-07-03_auth.log였다.

이번 축약 대상은 반복 경로였고, 유지한 정보는 각 파일 이름과 위치 복원 정보였다.

별도 검사도 수행했다.

이 검사에서는 복원 문자열과 원문 일치 여부를 확인했고, 바이트 단위 확인도 했다.

그러나 다른 압축 설정 사례에서는 설치 출력 후반부 소실이 있었고, 오류·거부 의미 단어 소실도 있었다.

이 때문에 입력 단축만으로 필요 정보 보존을 판단할 수는 없었다.

이번 검사 범위는 문자열 변화 확인이었고, 미측정 항목은 해당 입력이 모델 과제 수행을 더 잘하게 했는지 여부[14]였다.

저자는 26개 과제를 대상으로 4개 방식별 1회 실행을 진행해 4개 조건 모두 실행·검수 완료 자료 104건을 수집했다고 밝혔다. 이어 104건 중 과제 내장 검사 통과 40건이 나왔으며, 내장 검사는 과제에 포함된 검사 프로그램의 판정이라고 설명했다. 또한 내장 검사와 모델 자가 점수는 별개이며, 작업공간 복원 후 재검사를 거쳐 동일 판정 여부를 확인했다고 밝혔다.

다만 저자는 이 자료의 성격이 압축 도구를 순위화하기 위한 것이 아니라고 밝혔다. 대신 자료의 성격은 재검증이 필요한 지점을 탐색하기 위한 예비 관측이라고 설명했다. 과제 선정 기준은 과거 기록상 압축 가능 출력의 존재 여부와 사전 확정 과제 목록 순서였으며, 표본의 성격도 전체 업무를 대표하는 무작위 표본이 아니라고 덧붙였다. 아울러 각 과제·조건별 실행 횟수는 1회였다고 설명했다.

또한 앞선 별도 검사에서는 압축 없이 동일 과제를 반복 실행했는데, 이 압축 없는 반복 실행에서도 통과 판정이 변동했다고 밝혔다. 반복 측정 전반부·후반부의 결과 범위는 사전 설정 안정 조건을 충족하지 못했고, 이에 따라 압축 전후 비교 기준 자체가 불안정하다고 설명했다. 저자는 아래 제시 차이에서 압축 영향만 분리해 판단하려면 반복 측정이 필요하고, 추가 통제도 필요하다고 밝혔다.

표 2의 주제는 측정 조건 2의 입력 압축 예비실험이다. 여기서는 줄어든 입력과 줄어든 비용이 서로 다른 수치라는 점을 구분한다. 입력을 단축하면 비용도 동일 비율로 감소한다고 추정할 수 있지만, 이는 검증이 필요하다. 따라서 확인 대상은 감소 위치와 감소량이다.

이에 따라 먼저 실제로 바뀐 부분만 따로 집계했다. 추가 압축 적용은 78건이었고, 실제 문자열 변화는 23건이었다. 전후 원문 확인이 가능한 변경 구간은 209개였다. 토큰 계산 기준은 앞서 밝힌 같은 토큰 계산기였다. 이 변경 구간의 토큰 수는 약 48% 감소했다. 약 48% 감소 비율의 설명 대상은 변경 구간이다.

반면 전체 작업의 모델 입력과 비용은 변경 구간 외 요소를 포함하므로 별도 계산이 필요하다. 별도 계산에 포함되는 요소는 지시·이력·출력이다. 따라서 변경 구간에서 확인한 감소율과 전체 작업의 모델 입력·비용은 같은 항목으로 볼 수 없다.

실제 기록 결과의 제시 대상은 네 조건이다. 아래 비용 집계 대상은 각 조건에서 채점까지 마친 26건의 합계다. 이 집계에는 통과하지 못한 실행의 비용도 포함했다.

이 관측은 과제·조건별 1회의 예비 관측이라는 성격을 가진다. 따라서 이는 압축 도구 순위표가 아니다.

검토 대상은 입력 계산 단가다. 프롬프트 캐시 기능은 이전 처리 입력의 동일한 앞부분을 재활용하는 방식이다. 각 조건 26건 기준 입력 토큰 합산으로 보면 캐시 입력 비중은 추가 압축 없음이 약 64.5%, Headroom이 약 46.7%였다. 그러나 캐시 입력 비중이 하락했음에도 API 계산 비용은 5.62달러에서 5.36달러로 하락했다. 따라서 해당 사례를 캐시 비중 하락으로 비용이 증가한 경우로 해석할 수는 없다.

캐시를 함께 검토하는 근거는 가격 구조에 있다. 이 실험의 고정 가격표 기준으로 100만 토큰당 일반 입력은 2.50달러, 캐시 입력은 0.25달러다. 캐시 입력 단가는 일반 입력의 10분의 1이다. 이런 단가 차이 때문에 입력 토큰 중 캐시 입력의 비중과 실제 API 비용을 함께 비교해야 하며, 비중 변화만으로 비용을 단정할 수는 없다.

가능한 설명으로는 압축으로 입력이 감소할 때 재사용되는 앞부분이 달라지면서 캐시 할인이 축소될 수 있다는 점이 제시된다. 이 경우 캐시 할인 감소가 함께 생기면 토큰 감소분만큼 비용이 내려가지 않을 수 있다. 할인 상실액이 더 크면 비용이 증가할 가능성도 있다. 다만 이는 가능한 비용 변화 설명일 뿐이며, Headroom 결과의 원인을 확인한 것은 아니다.

이번 관측에서는 조건별 요청 수 차이와 모델 작업 경로 차이, 캐시 영향 미통제, 동시 실행 영향 미통제 때문에 영향 분리 측정이 불가했다. 관측 결과에는 비용 차이가 있었지만, Headroom 비용 저하만으로 압축의 비용 절감 효과를 단정할 수는 없었다. 이에 따라 '입력을 줄이면 작업 비용도 줄어드는가'라는 질문에 답하려면 조건별 품질·사용량·비용을 동시에 확인할 필요가 있었고, 반복 실행에서 차이 유지 여부도 확인할 필요가 있었다.

채점 완료 104건 전체 기준으로 모델 API 호출 시도는 1027회였고, API 계산 비용은 약 22.33달러였다. 이 수치는 검사 통과 40건 비용과 미통과 64건 비용의 합산값이었다. 해당 합계의 의미는 기록된 실행 규모를 제시하는 데 있었다.

또한 채점 전 종료된 실행에도 비용이 발생했다. 채점 완료 결과 표 외에 별도 검토 대상 실행도 존재했다. 따라서 표에 담긴 결과만이 아니라 그 바깥의 실행도 함께 살펴봐야 하는 흐름이었다.

아울러 실험용 과제 선정에는 예상보다 긴 시간이 소요됐다. 원인은 선별 기준을 충족하는 항목이 부족했기 때문이었다. 이 과정에서 선별·평가를 진행할 목적으로 호출·시간·비용 제한을 해제했다.

추가로 분리 기록한 5건은 별도 기록 대상 시도 5건으로, 각각 약 10시간 경과 후에도 첫 채점에 도달하지 못했다. 이 5건은 관찰 기준에 따라 기록됐으며, 애초부터 10시간 고정 설계는 아니었다. 실행 상태를 확인한 뒤 운영자가 종료했고, 5건의 출처는 서로 다른 과제 4개였다. 5건 모두 채점 전에 종료돼 품질은 미확정 상태로 남았고, 추가 대기 시 해결 여부도 불명이었다. 결과물 검사 통과 여부 역시 불명이었다.

종료 분류를 보면 운영자 중도 종료가 4건이었고, 응답 대기 정체가 1건이었다. 이처럼 종료 원인은 운영자 판단에 따른 중단과 응답 대기 정체로 갈렸다.

이 5건의 모델 API 호출 시도는 2783회였고, 사용량이 확인된 응답 기준 API 계산 비용은 약 87.77달러였다. 사용량 미확인 요청 1회의 추정 비용은 합계에서 제외됐고, 비용 계산 기준은 앞의 22.33달러와 동일한 단가·산식이었다. 다만 해당 87.77달러 집단은 과제·실행 조건이 다른 별도 집단이어서, 22.33달러와 87.77달러로는 성능 비교가 불가하고 압축 효과 비교도 불가하다.

사용량 확인은 완료됐지만 품질은 아직 미확인인 상태로, 비용과 품질은 서로 별도 상태를 유지하고 있다. 이 상태를 오답으로 처리하면 품질 통계가 변경된다. 반대로 완료 결과만 수집하고 기록을 제외하면 비용이 소실된다. 따라서 비용 보존이 필요하며, 비용과 채점 결과는 구분할 필요가 있다.

그림 4는 채점 완료 104건 기록과 채점 전 종료 별도 5시도 기록을 제시한다. 다만 두 영역은 서로 다른 과제를 포함하고 서로 다른 실행 조건을 포함한다. 이에 따라 두 영역 간 성능 비교는 실시하지 않았고, 두 영역 간 압축 효과 비교도 실시하지 않았다. 또한 API 계산 비용에는 압축기 컴퓨터 비용과 검사 프로그램 컴퓨터 비용이 포함되지 않으며, 실제 청구서 대사액도 아니다. 장기 5시도 중 사용량 미확인 요청 1회는 비용 합계에서 제외했다. 근거 표기는 [8][10][12]다.

기록 이후에는 다음 유료 실행 시작 조건이 변경됐다. 한 시도의 모델 API 호출 한도는 재시도를 포함해 최대 60회로 설정됐다. 준비·작업·채점을 포함한 실행 시간 한도는 최대 40분으로 정했다. 시도별 비용 상한은 사전 설정·승인했고, 전체 실행 비용 상한도 사전 설정·승인했다.

종료 시각도 사전 설정·승인했다. 필요 값이 공란이면 모델 호출 전에 중단하도록 했다. 이와 같은 기준은 근거 표기 [13]으로 제시됐다.

실행이 한계에 도달하면 기록을 분리해야 한다. 이때 호출 수·비용 한도 도달 여부와 시간·기타 실행 제한 도달 여부를 중단 사유로 기록해야 한다. 채점 전에 중단된 경우에는 품질 상태를 미확정으로 처리해야 한다. 또한 마지막 호출 위치와 확인된 사용량, 확인된 비용, 미확인 비용을 보존해야 한다.

이번 실행기의 정책값은 60회와 40분이다. 다만 업무별 정책값의 적정성 판단은 별도로 필요하다. 현재 확인 범위는 새 정책과 구현이다. 같은 과제의 새 기준 반복 시 비용 변화와 필요한 결과 획득 지장 여부는 아직 검증하지 않았다.

운영자는 완료 기준 정의와 결과 대기 중 허용 시간·호출 수, 경계 도달 시 보존 대상, 경계 도달 후 후속 확인 담당자를 함께 검토해야 한다. 아울러 추론 강도 선택과 압축 도구 선택과 함께 실행 조건을 결정할 필요가 있다.

앞선 세 사례는 도구 사용 AI의 비용을 볼 때 마지막 답변이나 설정 하나만으로는 설명하기 어렵다는 점을 보여준다. 짧은 도구 사용 실험에서는 추론 강도와 결과를 동시에 확인했다. 입력 압축 예비실험에서는 줄어든 구간 크기와 전체 사용량에서 서로 다른 수치를 확인했다. 채점 전 종료 실행에서는 결과가 없는 상태에서도 비용을 기록할 필요가 있음을 확인했다.

이 때문에 비용을 판단할 때는 작업을 시작한 뒤의 호출 횟수와 남긴 결과, 종료 지점을 함께 봐야 한다. 또 완료 결과와 채점 전 종료를 구분할 필요가 있다. 이 구분을 적용하면 완료 결과와 채점 전 종료를 나눠 볼 때 필요한 추가 측정 항목도 구체화할 수 있다. 그 다음 확인 대상은 판정 자체다.

이번 글에서 말하는 통과의 의미는 GPT-4o 채점기 또는 과제 내장 검사 기준을 충족하는 것이다. 이어서 판정 기준의 의미를 점검할 때는 동일한 검사 결과가 반복 가능한지의 문제와, 그 검사가 실제 업무 품질을 정확히 가려내는지의 문제를 구분할 필요가 있다. 두 문제는 같은 문제가 아니다.

압축 실험의 별도 기준선에서는 동등한 표현을 내장 검사가 거부한 사례도 확인됐다. 이 사례는 내장 검사 결과를 해석할 때 추가 확인이 필요하다는 점으로 이어진다. 관련 근거 표기는 [9][15]다.

다음 호에서는 파일을 읽고 결과물을 평가하는 AI 채점기를 주제로 다룰 예정이다.

이 글은 다음 회차에서 던질 질문을 결과물 통과 이유의 신뢰 가능성과 판단 확인 비용으로 좁힌다.

참고문헌 번호는 초고의 근거를 연결하는 용도로 쓴다.

저장소 자료의 고정 기준은 작성 시점을 확인한 커밋이다.

[1]은 전현상, 아이티데일리, '추론 모델은 언제 제값을 할까', 2026-07-29를 가리킨다.

[1]의 본문 예고 문장 출처는 필자 확인 제공 게재본 문구이며, [2]는 아이티데일리, 연재 2회차 게재본을 가리킨다.

[3]은 When Reasoning Pays Off의 도구 사용 실험 문항·구성·문항 원문을, [4]는 When Reasoning Pays Off의 실험 설정·실행 보고·당시 가격표를 가리킨다.

[5]는 When Reasoning Pays Off의 실행별 분석 데이터·사용량 원기록·채점 기록을 가리키며, [5]의 본문 360건 비용 산출 방식은 제외 전 실행별 사용량에 [4] 가격표를 적용해 재계산한 것이다.

제시된 항목들은 각 참고자료에서 어떤 부분을 사용했는지와 계산·인용의 적용 범위를 정리한 것이다.

[6]에서는 When Reasoning Pays Off의 보조 통계와 사람 채점이 부재한 범위를 사용한다.

[7]에서는 Prompt Compression Billing Bench의 예비실험 개요와 측정 조건을 사용하고, [8]에서는 Prompt Compression Billing Bench의 예비실험 집계 JSON을 사용한다.

특히 캐시 비중은 [8]의 provider_usage.by_condition에 있는 캐시 입력 토큰을 전체 입력 토큰으로 나눈 기준으로 산출한다.

[9]에서는 Prompt Compression Billing Bench의 실험 설계 검토와 판정자 한계를 사용하며, [10]에서는 Prompt Compression Billing Bench의 비용 산식과 집계 범위를 사용한다.

프롬프트 캐시 관련 설명은 [11]의 Microsoft Learn, Prompt caching을 출처로 하고 확인일은 2026-09-21이며, 입력 앞부분 일치와 프롬프트 캐시 재사용 설명만 제한적으로 사용한다. 또한 실험의 고정 단가 준거는 [10]을 따른다.

[12]부터 [15]까지는 Prompt Compression Billing Bench에서 운영 종료 이후 처리, 유료 실행 정책, 저장 출력 검사, 반복 실행 안정성까지 이어지는 점검·기록 항목들이다. [12]에는 Prompt Compression Billing Bench의 기술 근거 관련 절에 사후 운영자 종료한 장기 꼬리 내용이 포함됐고, Prompt Compression Billing Bench의 제한 해제 기록과 Prompt Compression Billing Bench의 후속 결정 기록도 담겼다.

[13]에는 Prompt Compression Billing Bench의 다음 유료 실행의 종료 정책과 Prompt Compression Billing Bench의 다음 유료 실행의 비용 정책이 기록됐으며, Prompt Compression Billing Bench의 정책 검사 구현도 포함됐다.

[14]에는 Prompt Compression Billing Bench의 저장된 출력 대상 압축기 적용 별도 검사와 Prompt Compression Billing Bench의 공개 전후 예시 제시, Prompt Compression Billing Bench의 압축 후보와 보호 대상 구분이 담겼다. [14]는 예시와 경로의 성격, 정적 검사 기반 출처, 104건 실행 결과의 비원문 표기를 함께 밝혀 공개 범위와 자료 성격을 구분한다.

또한 [14]에는 경로 예시가 원자료의 가공 공개본이라는 점과 [14]의 경로 예시 출처가 모델 호출 없는 정적 검사라는 점이 제시됐다. 아울러 [14]의 104건 과제 실행은 원문으로 표기하지 않았다.

[16]은 LLMLingua-2 관련 외부 근거로서 Microsoft Research의 Research Focus: Week of April 15, 2024의 LLMLingua-2 절을 제시한 항목이다. [16]에는 LLMLingua-2가 마이크로소프트와 칭화대 연구진의 공동 연구라는 점, 모델·코드 공개 참고처가 Microsoft의 LLMLingua 저장소라는 점, 확인일이 2026-09-21이라는 점이 덧붙었다.

도구 사용 실험의 실행일은 2026년 5월 24일이었고, 입력 압축 과제 비교의 실행 시점은 2026년 9월 16~17일(UTC)이었으며, 모델 호출용 배포는 Microsoft Foundry의 Azure였고, 사용 모델은 GPT-5.4였으며, 제공자 보고 버전은 gpt-5.4-2026-03-05였고, 생성 설정은 temperature=0과 reasoning_effort=none이었으며, 사용 압축기는 squeez 1.48.4와 Headroom 0.36.5의 파일 경로 전용 설정, LLMLingua-2 0.2.2였고, 변경 구간 계산 기준은 tiktoken 0.14.0의 o200k_base였으며, 이런 설정값만으로는 출력의 결정론이 보장되지 않고 대표성도 보장되지 않는다.

출처: 아이티데일리 (IT DAILY) · 전현상
원문: https://www.itdaily.kr/news/articleView.html?idxno=241904

참고자료

이 기사는 자동생성 알고리즘의 도움을 받아 작성되었습니다.


출처 아이티데일리 (IT DAILY)

원문 확인

이 기사는 아이티데일리 (IT DAILY) 원문을 바탕으로 비즈크러시가 요약 정리했습니다. 정확한 인용과 세부 내용은 원문을 확인해 주세요.