AI에 계산을 더 쓰기 전에 정해야 할 것

먼저 다음과 같은 판매 분석 요청을 가정하겠습니다.

2월 판매 증가를 설명해줘. 어떤 상품이 성장을 이끌었고, 판촉 덕분인지도 알려줘.

사용 가능한 표에는 A 상품의 판매량이 1월 100개, 2월 120개로, B 상품은 50개에서 70개로 늘었다고 적혀 있습니다. 이 표로 계산할 수 있는 답은 분명합니다.

B의 증가율이 더 높지만 전체 판매량 증가에 더 많이 기여한 것은 아닙니다. 절대 증가량은 둘 다 20개입니다. ‘성장을 이끌었다’는 모호한 질문에서 상대 증가율과 증가량 기여를 구분해야 답이 정확해집니다.

계산할 수 있는 범위뿐 아니라 자료에 없는 정보도 구분해야 합니다. 이 표는 판매량 자료입니다. 가격이 없으므로 매출액 증가율로 바꿔 말할 수 없습니다. 판촉 여부나 효과를 보여주는 정보도 없습니다. 아무리 계산을 정확히 해도 판촉이 증가의 원인인지까지 나오지는 않습니다.

따라서 이 요청에는 최소한 세 가지 작업이 있습니다. 같은 기간과 단위의 자료를 확보하는 일, 증가량과 비율을 계산하는 일, 근거가 있는 설명과 아직 판단할 수 없는 부분을 나누는 일입니다. 마지막 작업에서 무엇이 부족한지 드러나면 판촉 문서를 더 찾을 수 있습니다. 처음부터 ‘강한 모델이 긴 분석을 쓰게 한다’로 처리 경로를 고정할 필요는 없습니다.

이 요청의 기본 경로를 자료 확인 → 계산 → 근거 대조 → 응답으로 정해 보겠습니다. 각 단계가 다음 단계에 넘기는 결과를 구체적으로 정의하면, 실패했을 때 돌아갈 위치도 정하기 쉬워집니다.

자료 확인 단계는 표의 값만 넘기지 않습니다. 기간, 단위, 자료 식별자와 가져온 시점도 전달합니다. 계산 단계는 26.67이라는 숫자만 반환하지 않고, 어떤 두 합계에서 어떤 식으로 계산했는지 함께 반환합니다. 근거 대조 단계는 ‘판촉 문서 있음’보다 문서가 어느 기간과 상품에 대해 무엇을 말하는지 확인합니다.

판촉 문서를 찾았다고 가정해 보겠습니다. 문서에는 2월 중순에 행사를 시작했다고 적혀 있습니다. 판매가 늘어난 시기와 행사가 겹친다는 사실은 확인할 수 있습니다. 이 기록 하나로 판촉이 판매 증가를 일으켰다고 단정할 수는 없습니다. 다른 요인이나 비교 조건을 확인하지 못했다면 응답도 그 범위에서 멈춰야 합니다.

도구의 결과에는 자료를 찾았는지뿐 아니라, 찾지 못했다면 그 이유도 남아 있어야 합니다. 예를 들어 found, not_found, access_denied, invalid_format 같은 값과 이유를 함께 반환할 수 있습니다. 이 이름은 예시 계약입니다. 실제 도구가 이런 필드를 이미 제공한다고 가정하는 것은 아닙니다.

재시도 정책을 이런 상태에 연결하면 호출을 늘리는 이유가 남습니다. ‘실패했으니 한 번 더’ 대신 ‘기간이 달라 검색 조건을 바꾼다’고 설명할 수 있습니다. 같은 입력과 같은 오류를 반복하는 경로에는 예산을 쓰지 않게 됩니다.

앞에서 확인한 자료와 계산을 바탕으로 하면 최종 응답의 범위도 정할 수 있습니다. 전체 판매량은 26.67% 늘었고 두 상품의 증가량 기여는 같습니다. B는 상대 증가율이 더 높습니다. 확인한 자료만으로 판촉의 인과적 효과는 확정할 수 없습니다. 판촉의 효과까지 설명하는 답보다 짧더라도, 확보한 근거와 계산에 맞는 결과를 전달할 수 있습니다.

이 흐름을 매번 사람이 정할 수도 있고, 규칙으로 구현할 수도 있으며, 다음 도구를 고르는 모델을 둘 수도 있습니다. 어느 경우든 조율하는 역할과 실제 검색·계산·추론을 수행하는 역할을 분리해서 봐야 합니다.

ToolOrchestra는 여러 도구와 모델을 조율하는 모델을 학습하는 연구입니다. HLE 텍스트 하위 집합에서 Orchestrator-8B는 37.1, 기본 도구를 사용하는 GPT-5 비교 구성은 35.1을 기록했습니다. 여기서 8B는 조율하는 모델의 크기이며, 사용할 수 있는 도구에 GPT-5 같은 더 큰 모델도 포함됐습니다. 8B 모델 단독의 성능이나 폐쇄망 구성의 결과로 읽으면 비교 대상을 잘못 이해하게 됩니다. ToolOrchestra v1, §4·Table 1

이 연구를 업무에 적용하려면 모델 크기와 성능 수치뿐 아니라 각 모델이 맡은 역할을 살펴봐야 합니다. 작은 모델이 모든 답을 알아야만 비용을 줄일 수 있는 것은 아닙니다. 어떤 단계에서 어떤 도구가 필요한지 판단하고, 돌아온 결과를 점검하며, 불필요한 다음 호출을 멈추는 방식으로도 시스템을 바꿀 수 있습니다.

다만 우리 판매 예제의 계산 규칙은 이미 명확합니다. 저라면 먼저 고정한 검색·계산 경로로 기준선을 만들겠습니다. 입력에 따라 실제로 여러 경로가 필요해졌을 때 조율 모델을 추가하고, 그 모델이 선택하는 것이 단순 규칙보다 유리한지 비교합니다. 도구가 많다는 이유만으로 모든 선택을 모델에게 맡기면 조율 비용과 실패 지점도 함께 늘어납니다.

‘작은 모델 먼저, 어려우면 큰 모델’이라는 경로를 비용으로 풀어 보겠습니다. 두 경로에서 똑같이 수행하는 자료 검색과 계산 비용은 공통항으로 빼고, 모델 선택 이후의 차이만 비교합니다.

항상 큰 모델을 사용하는 경로의 비용을 요청당 10단위라고 정하겠습니다. 다른 경로는 가벼운 모델과 라우팅·검사 비용을 합쳐 먼저 1.5단위를 사용합니다. 그중 r만큼의 요청은 검사를 통과하지 못해 큰 모델에 추가로 보냅니다. 큰 모델의 추가 호출은 이 예제에서 동일하게 10단위입니다.

항상 큰 모델 = 10
단계적으로 처리 = 1.5 + 10r

단계적 처리가 더 저렴할 조건:
1.5 + 10r < 10  →  r < 0.85

작은 모델의 단가가 저렴해도 대부분의 요청을 다시 큰 모델로 보내면 절감이 사라집니다. 첫 모델의 답을 큰 모델에 함께 전달해 입력이 길어지거나, 검사기를 여러 번 호출하면 실제 비용 항도 바뀝니다. 그러므로 여기서 85%는 일반적인 기준이 아닙니다. 이 예제의 비용 가정에서 계산한 손익분기점입니다.

비용이 줄어든다는 계산만으로 이 경로를 선택할 수는 없습니다. 저렴하게 끝난 요청 중 잘못된 답이 그대로 통과한 비율도 확인해야 합니다.

전체의 80%를 첫 경로에서 끝내고 20%를 큰 모델로 보낸다고 하겠습니다. 첫 경로에서 끝낸 요청의 정답률을 98%, 추가 전달된 요청의 최종 정답률을 80%로 가정하면 전체는 다음과 같습니다.

최종 정답률 = 0.8 × 0.98 + 0.2 × 0.80 = 94.4%

항상 큰 모델의 정답률을 96%, 서비스가 정한 하한을 95%라고 가정하면 단계적 처리는 저렴하지만 현재 조건으로 채택할 수 없습니다. 특히 98%는 ‘검사기가 통과시킨 집합’의 정확도입니다. 모델 전체의 평균 정답률이나 스스로 보고한 자신감을 여기에 대신 넣을 수 없습니다.

어려운 요청만 추가 전달됐다면 큰 모델도 그 집합에서는 전체 평균보다 낮은 성능을 보일 수 있습니다. 그래서 비교 실험에서는 라우터가 통과시킨 요청과 추가 전달한 요청을 나누어 정답률을 측정해야 합니다. 라우터가 잡아야 할 어려운 요청을 놓쳤는지, 쉬운 요청까지 과하게 올렸는지도 함께 볼 수 있습니다.

품질까지 비교하면 비용을 줄일 수 있는 범위가 분명해집니다. 최종 품질 조건을 만족하는 경로들 사이에서 요청당 비용을 줄이는 것이 목표이며, 작은 모델의 사용 비중을 높이는 것만으로는 충분하지 않습니다.

비용과 품질 조건을 확인한 뒤에는 사용자가 기다리는 시간도 비교해야 합니다. 같은 예제로 두 경로의 지연 시간을 살펴보겠습니다. 항상 큰 모델에 맡기면 10초가 걸린다고 가정합니다. 단계적 처리는 첫 생성과 검사에 3초가 걸리고, 추가 전달된 요청에는 큰 모델의 10초가 순서대로 붙습니다. 앞과 같이 80%는 3초, 20%는 13초에 끝납니다.

평균은 0.8×3+0.2×13=5초입니다. 평균만 보면 절반으로 줄었습니다. 그러나 이 단순한 두 경로 분포의 p95는 13초입니다. 요청의 95%가 끝나는 시점이 느린 경로에 놓이기 때문입니다. ‘p95 12초 이내’라는 조건이 있었다면 평균 개선과 별개로 그 조건을 넘깁니다.

실제 지연 시간에는 도구 응답과 네트워크, 큐 대기, 캐시 상태도 들어갑니다. 동시에 실행한 작업들의 시간은 전부 더하는 대신 다음 단계가 기다려야 하는 경로를 봐야 합니다. 반대로 순차 재시도에서는 앞에서 쓴 시간이 사라지지 않습니다.

온프레미스에서는 호출 가격표보다 자원 점유가 먼저 보일 수 있습니다. 후보 생성을 네 배로 늘렸을 때 GPU의 생성 작업이 늘고, 같은 자원을 공유하는 다른 요청이 기다릴 수 있습니다. 요청 하나의 개선을 확인한 뒤에도 동시 요청이 들어오는 조건에서 처리량과 지연 분포를 다시 봐야 하는 이유입니다. 어느 GPU에서 몇 배까지 가능한지는 모델과 실행 환경의 측정으로 정할 값입니다.

도식에 표시한 이동 속도는 실제 지연 시간을 측정한 결과가 아닙니다. 화면에 비용과 시간을 넣는다면 지금처럼 가정을 노출한 계산 예제이거나, 조건이 함께 적힌 측정값이어야 합니다.

온라인 요청은 기다리는 사람이 있습니다. 반면 자주 실행하는 집계 프로그램 하나를 개선하는 작업은 더 긴 탐색을 허용할 수 있습니다. 한 번 좋은 프로그램을 찾으면 이후 실행에서 반복해서 이득을 얻기 때문입니다.

이 경우 추가 계산의 쓰임새를 세 가지로 구분할 수 있습니다.

첫 번째는 좋은 후보가 나올 때까지 더 생성하는 방식입니다. 두 번째는 ‘결측값을 0으로 처리해 결과가 달라졌다’ 같은 실패 정보를 다음 입력에 넣어 탐색 방향을 바꿉니다. 여기까지는 프롬프트와 외부 기록이 변하며 모델 가중치는 그대로일 수 있습니다.

세 번째에서는 평가 결과를 학습 신호로 사용해 모델 자체도 갱신합니다. TTT-Discover는 하나의 문제를 푸는 과정에서 강화학습을 이어가며, 좋은 후보 재사용과 높은 보상의 해를 찾기 위한 목표를 결합합니다. 여러 요청에서 평균적으로 좋은 정책을 배포하는 문제와, 한 번이라도 뛰어난 해를 발견하는 문제의 목적이 다름을 전제로 합니다. TTT-Discover v2, §3

논문 v2의 기본 구현은 gpt-oss-120b, rank 32 LoRA, 50스텝과 스텝당 512 rollout을 사용합니다. 곱하면 25,600개의 후보 생성 예산입니다. 이를 단순히 ‘채팅을 몇 번 더 한다’는 수준으로 읽기는 어렵습니다. 후보 수를 맞춘 비교라도 학습 갱신 비용까지 같다는 뜻은 아닙니다. TTT-Discover v2, §3.3

집계 프로그램에 이 방식을 적용하려면 먼저 결과가 맞는지 검사할 기준이 필요합니다. 같은 입력에서 기준 프로그램과 결과가 일치하는지, 결측값·중복·단위 변환을 같은 규칙으로 처리하는지 확인합니다. 이 조건을 만족한 후보 사이에서 실행 시간과 자원 사용을 비교할 수 있어야 합니다.

속도만 보상하면 어려운 행을 건너뛰어 빠르게 끝나는 후보가 유리해질 수 있습니다. 모델이 검사기를 반복해서 보며 적응하므로, 탐색 중 사용하는 검사 외에 최종 확인용 입력도 남겨두겠습니다. 학습을 추가했다면 최종 코드와 함께 어떤 모델 상태에서 만들었는지도 보존하되, 그 모델이 다른 과제에서도 좋아졌다고 자동으로 결론 내리지는 않습니다.

경제성도 요청당 비용과 다른 방식으로 계산합니다. 탐색·학습·검증에 드는 일회 비용을 F, 개선한 프로그램을 실행할 때마다 절약하는 비용을 d, 앞으로 유효하게 재사용할 횟수를 N이라고 하겠습니다. 같은 단위로 비용을 정의했을 때 N×d>F가 반복 사용으로 비용을 회수할 조건입니다. 실행 환경이 바뀌어 다시 최적화해야 한다면 그 작업도 F에 들어갑니다.

한 번의 응답을 위해 지출하기 어려운 계산도, 반복해서 쓰는 산출물을 개선한다면 검토할 수 있습니다. 그래서 test-time learning을 모든 요청의 다음 단계로 놓기보다, 검증 가능하고 충분히 재사용할 가치가 있는 과제를 따로 고르는 편이 이 예제에는 맞습니다.

앞에서 비교한 경로와 계산 조건을 나중에도 확인하려면, 모델과 함께 사용한 구성도 기록해 두어야 합니다. 이전 버전으로 돌아갈 때 어떤 항목을 함께 살펴봐야 하는지 예제로 확인하겠습니다.

모델을 이전 버전으로 되돌렸는데 예전 동작이 복원되지 않았다고 하겠습니다. 검색 인덱스에는 새 문서가 남아 있고 프롬프트도 바뀐 상태라면, 생성기가 받는 입력부터 이전과 다를 수 있습니다. 모델 버전 하나로 서비스 전체의 버전을 설명하기 어려운 이유입니다.

저라면 평가할 구성에 모델·프롬프트·검색 자료와 인덱스·도구 계약·권한 정책·평가기를 함께 기록하겠습니다. 모든 항목을 항상 동시에 되돌리겠다는 뜻은 아닙니다. 어떤 조합이 호환되고 어떤 조합을 평가했는지 확인할 수 있게 만드는 것입니다. 이미 처리한 외부 작업이나 수정한 데이터까지 모델 교체로 취소되는 것도 아닙니다. 그런 상태 변경은 별도의 복구 절차를 필요로 합니다.

이 차이를 확인하는 작은 코드를 직접 실행했습니다. 모델 호출 없이 가상의 자료와 구성 ID만으로 입력 문맥을 조립합니다. 기준 자료는 예제 절차의 관찰 시간을 5분으로, 새 자료는 10분으로 정의했습니다. 실제 운영 권고 시간은 아닙니다. 모델 ID는 메타데이터이며 실제 가중치 파일을 올리지 않습니다.

코드는 입력 문자열과 구성의 SHA-256을 계산해 동등성을 검사합니다. 모델 ID만 복원한 경우에는 기준 입력과 달랐고, 전체 구성을 복원한 경우에는 입력과 구성 모두 기준과 같았습니다. 실행 코드와 실행 결과 JSON을 함께 제공합니다. 코드를 저장한 뒤 node release-replay.mjs로 재현할 수 있으며 외부 API나 추가 패키지가 필요하지 않습니다.

이 실행이 입증한 범위는 입력 조립과 구성 식별자의 복원입니다. 실제 모델의 응답 재현성이나 배포 성공을 입증한 것은 아닙니다. 같은 입력과 같은 모델을 사용해도 생성 설정과 실행 조건을 함께 확인해야 합니다. 특히 답변까지 복원됐다고 주장하려면 실제 요청 결과를 별도로 측정해야 합니다.

이 정도의 작은 재현만으로도 배포 기록에서 빠진 항목을 구체적으로 볼 수 있습니다. 새 모델을 평가할 때 어떤 프롬프트와 인덱스를 사용했는지, 롤백 후 그 조합이 유지되는지, 어느 검사를 다시 실행해야 하는지를 정할 수 있습니다. 모델 파일의 교체가 끝났다는 이벤트와 서비스 동작이 복원됐다는 증거를 나누어 남기겠습니다.

관찰 시간과 해당 자료의 식별자를 함께 설명한다.
질문: 예제 절차의 관찰 시간은?
자료: example-observation-v2
관찰 시간: 10분

모델이 도구와 다른 모델을 고르는 시스템에서는 권한도 경로의 조건이 됩니다. 내부 자료만 사용하도록 정한 요청이라면 외부 모델 호출은 비용이 저렴하더라도 후보 경로에 넣을 수 없습니다. 입력이 허용되지 않는 도구로 전달됐다면 최종 답이 맞아도 요청의 조건을 어긴 것입니다.

이 경계는 모델이 작성한 설명과 실행 단계의 검사로 나누어 설계하겠습니다. 모델은 다음 호출을 제안할 수 있지만, 실행기는 사용 가능한 도구와 전달 가능한 데이터 범위를 확인합니다. 검색 문서에 적힌 호출 지시를 실행 권한으로 취급하지 않습니다. 이는 이 글의 설계 원칙이며 특정 제품에서 이미 구현됐다는 주장이 아닙니다.

같은 이유로 관측 기록도 최종 응답 텍스트만으로는 부족합니다. 어떤 자료 버전과 모델로 시작했는지, 어떤 호출이 어떤 이유로 선택됐는지, 각 단계가 얼마나 걸렸는지, 검사에서 무엇을 통과하거나 놓쳤는지가 필요합니다. OPS는 이 경로의 비용·지연·실패를 추적하는 데, SEC는 그 경로가 허용된 행동 안에 있는지 확인하는 데 연결됩니다. AI는 그 안에서 답을 생성하고 다음 행동을 제안합니다.

처음의 판매 분석 요청에 적용한다면, 저는 필요한 역할을 나누어 작은 구성부터 시작하겠습니다. 기간과 단위를 확인하는 자료 입력, 재현할 수 있는 계산, 주장과 근거를 맞추는 검사, 부족한 내용을 그대로 전달하는 응답입니다. 그 기준선에서 발견한 실패에 따라 검색, 추가 모델, 후보 탐색을 붙이겠습니다. 긴 탐색과 모델 갱신은 결과를 별도로 검증하고 반복해서 사용할 수 있는 작업에 적용할지 검토하겠습니다.

추가 계산의 가치는 호출 횟수보다 최종 결과로 판단할 수 있습니다. 무엇을 보완하려고 계산을 썼는지, 필요한 품질과 시간 안에서 그 부족함이 실제로 줄었는지를 함께 확인해야 합니다. 그 결과를 설명할 수 있다면 모델을 더 쓰는 결정에도, 여기서 멈추는 결정에도 근거가 생깁니다.

---

관련 원고: 모델이 좋아졌다는 말에는 빠진 조건이 있다는 후보 생성과 최종 답 선택을 구분하고, 모델이 배울 만한 데이터를 만드는 과정은 반복해서 드러나는 약점을 학습 과제로 바꾸는 방법을 다룹니다.