이것은 중간 과정의 실험 로그입니다

업무에서 사용하고 있는 AI 에이전트 하네스 (AI Agent Harness, 정기 실행 스케줄러)가 있습니다. 애초에 계기가 된 것은 이용 중인 플랜에 토큰 소비 상한선이 있다는 점이었습니다. 에이전트를 정기적으로 실행하다 보면 상한선을 의식해야 했고, 이를 피하기 위해 오랫동안 "작업(job)마다 Opus와 Sonnet을 구분하여 사용하여 토큰을 절약하는 것"을 위해 노력해 왔습니다.

하지만 Opus 4.8의 출시로 인해 그 전제가 바뀌었다고 느끼고 있습니다. 모델을 Opus 4.8로 고정한 채, 전환 대상을 "모델"이 아니라 "effort (추론에 얼마나 공을 들일 것인가)"로 바꾸는 것입니다. 이를 통해 토큰 절감과 정밀도 향상을 동시에 노릴 수 있지 않을까라는 가설을 세우고 검증을 시작했습니다.

본 기사는 그 이행을 시도하고 있는 도중의 로그입니다. 아직 모든 작업을 옮긴 것은 아니며, 결론이라기보다는 관찰 메모에 가까운 내용입니다. 미리 말씀드리자면, 확정된 베스트 프랙티스(Best Practice)를 보여주는 것은 아닙니다. 또한, 모델명이나 effort 설정은 집필 시점(2026-06)의 것입니다.

지금까지: 모델 전환으로 토큰을 절약해 왔다

하네스의 구성

하네스는 여러 작업을 서로 다른 빈도로 실행하고 있습니다. 작업마다 모델을 지정했습니다.

{
"harness_jobs": [
{"id": "discover", "role": "검출", "model": "Sonnet", "frequency": "5분 간격"},
...

모델 선택을 어떻게 결정했는가

판단의 축은 여러 가지가 있어 단순하게 결정할 수 없었습니다.

토큰 소비만 생각하면, Opus는 Sonnet보다 명확하게 무거우며 상한선을 빨리 소모합니다.

이 비교라면 Sonnet으로 통일하는 것이 상한선 관리에 유리해 보입니다. 반면 품질만 생각하면, Opus는 추론 능력이 높기 때문에 Opus로 통일하는 것이 좋아 보입니다. 실제로는 양측의 균형이 문제였습니다. 하지만 "무엇을 측정해야 판단할 수 있는지" 모르는 채로 운용해 왔던 것입니다.

측정해 보았다: "수정 루프 수"라는 지표

그래서 무엇을 측정해야 하는지에 대한 가설로 "수정 루프 수"를 설정했습니다. 하네스의 작업은 "초회 실행에서 완성되는가" 아니면 "다시 실행할 필요가 있는가" 중 하나를 반복합니다.

• 루프 1 … 초회 실행에서 성공함
• 루프 2 이후 … 실패·에러·품질 부족으로 인해 수정하여 재실행함

Sonnet에서 수정 루프가 늘어나면, 여러 번 시도하는 만큼 토큰이 늘어납니다. 반대로 Opus에서 수정 루프가 줄어든다면, 1회당 소비가 무겁더라도 초회 정밀도로 만회할 가능성이 있습니다. 이를 확인하고 싶어서 실제 운용 로그를 집계했습니다.

측정 대상 작업

측정 방법

• Bash 실행 로그로서, 각 작업의 실행 결과를 JSON으로 기록합니다.
• 세션 로그를 분석하여, 수정 사이클의 척도가 되는 Agent 호출 수를 셉니다.
• 수정 루프는 앞서 언급한 정의(루프 1 = 초회 성공, 루프 2 이후 = 재실행이 필요했던 사이클)에 따라 셉니다.

측정 기간은 2026년 5월 중 약 3주간이며, 대상은 세션 로그 1,000건 이상입니다.

작업별 수정 루프 수 (실측)

단순한 폴링(Polling)이나 게시 계열(discover, run-reviews, daily-report)은 초회에 거의 통과합니다. 반면, 창의성이나 복잡한 판단을 포함하는 작업(rule-mining 등)은 루프가 늘어나는 경향이 있었습니다.

Agent 호출 수의 분포

태스크 처리에서는 여러 Agent를 돌려 자기 검토(Self-review)와 수정을 하고 있습니다. 그 Agent 호출 수(수정 사이클의 척도)는 대상 세션 1,000건 이상에서 다음과 같았습니다.

평균: 5.8 회/세션
중앙값: 3 회
표준 편차: 4.2 회

이 임계값(12회라면 첫 시도 성공, 34회라면 수정 1 사이클, 5회 이상이라면 복수 사이클)은 제가 운영 로그를 살펴보며 설정한 주관적인 구분입니다. 1회의 수정 사이클에 여러 번의 Agent 호출이 포함되므로, 평균 5.8회라도 수정 루프 자체는 대체로 12 사이클 정도(Job별 실측치로는 1.01.4)로 수렴한다고 해석하고 있습니다. 엄밀한 변환식이 있는 것은 아니며, 대략적인 견해입니다.

토큰 소비는 어떤 Job에 편중되는가

지금까지 복잡한 Job일수록 수정 루프가 길어진다는 것을 확인했습니다. 다음으로, 그것이 토큰 소비(=상한 프레임의 점유)에 어떻게 영향을 미치는지 살펴보겠습니다.

소비량의 절대치는 모호하게 처리하겠지만, 어떤 Job이 상한을 차지하는지는 명확했습니다. 요컨대, 빈도가 높은 Job에 거의 집중됩니다.

지배적인 것은 고빈도 Job(discover, run-all)이며, 이 두 가지만으로 전체 소비의 대부분을 차지했습니다. 반대로 rule-mining이나 weekly-reflect와 같은 저빈도 Job은 모델을 높여도 전체에 미치는 영향은 극히 미미합니다. 그렇기 때문에 다음에 시도할 effort 전환도 우선 비중이 큰 고빈도 Job부터 다루고 싶다고 생각하고 있습니다.

전환점: Opus 4.8과 effort 전환

지금까지가 '모델 전환' 시대에 보였던 모습입니다. 그리고 Opus 4.8이 출시되면서 다른 방식을 시도해보고 싶어졌습니다.

모델을 Opus 4.8로 고정한 채, Job마다 전환하는 대상을 effort로 삼는다는 아이디어입니다. effort는 추론의 정밀도를 조정하는 설정입니다. 낮추면 사고 토큰 (reasoning tokens)을 줄일 수 있는 경향이 있습니다 (제 관측 범위 내에서의 이해이며, 동작의 상세 내용은 공식 사양을 확인해 주세요).

• 단순한 Job은 effort를 낮춤 … 사고 토큰이 줄어들어 상한 프레임에 여유가 생길 것으로 기대할 수 있습니다.
• 복잡한 Job은 effort를 높임 … 첫 시도 정밀도가 올라가 수정 루프의 감소를 기대할 수 있습니다.

매력은 단순함에 있습니다. '어떤 Job에 어떤 모델을 할당할 것인가'라는 2단계의 판단을 'Opus 4.8 상태에서 effort를 어디에 둘 것인가'라는 1단계의 다이얼로 압축할 수 있지 않을까 생각합니다.

그리고 앞서 언급한 수정 루프 수는 그 effort의 초기값을 결정하는 단서로 사용할 수 있을 것 같습니다. 루프가 길었던 Job은 effort를 높게 설정하여 시작하고, 첫 시도에서 통과했던 Job은 낮게 설정하여 시작하는 출발점이 됩니다.

아직 진행 중: 전환된 것은 일부뿐

솔직히 말해서, effort 전환으로의 이행은 아직 일부만 진행되었습니다. 고빈도이며 비중이 큰 discover나 run-all을 effort를 낮게 설정하여 검증하는 것은 이제부터이며, 현시점에서는 저빈도 Job으로 동작을 살펴보고 있는 단계입니다.

고민되는 지점은 effort를 낮췄을 때 수정 루프가 늘어나 토큰이 오히려 증가하지 않을까 하는 점입니다. 'effort를 낮춰도 루프 1에서 통과하는가'를 측정하지 않으면 절약이 되고 있는지 판단할 수 없습니다. 이 부분은 아직 데이터가 부족합니다.

현재의 잠정적인 견해

• 수정 루프가 많았던 Job(rule-mining 등)은 effort를 높게 설정하여, 첫 시도 정밀도로 수정 루프를 줄이는 방향을 시도한다.
• 첫 시도에서 거의 통과했던 Job(discover, run-reviews, daily-report)은 effort를 낮게 설정하여 토큰이 줄어드는지 측정한다.
• 둘 다 'effort를 변경한 후에 루프 수가 증감했는가'를 계측하여 판단한다.

이 루프 수를 측정하는 부분은 지금까지와 같은 방식을 사용할 수 있습니다.

#!/bin/bash
# job_measurement.sh
JOB_ID=$1
...

집계 스크립트 (Python)

import json
with open("results.jsonl") as f:
    data = [json.loads(line) for line in f]
...

effort를 변경하기 전과 후로, 이 평균 루프가 어떻게 움직이는지를 나란히 보는 것이 현재로서는 가장 솔직한 검증이라고 생각합니다.

마치며

지금까지의 내용을 정리하면 다음과 같습니다.

• 원래는 모델 전환 (Sonnet/Opus)을 통해 토큰을 절약하고 있었다
• 수정 루프 (correction loop) 횟수를 측정해 보니, 작업이 복잡할수록 여러 번 다시 수행하고 있다는 것을 알게 되었다
• Opus 4.8을 기점으로, 모델 고정 + effort 전환 방식으로 옮기려 하고 있다
• 다만 전환은 아직 일부에만 적용되었으며, effort를 낮췄을 때 루프가 늘어나지 않는지 검증 중이다

effort 전환을 통해 정말로 토큰이 줄어드는지, 혹은 정밀도 (accuracy)가 올라가는지는 앞으로 측정하여 다시 기록하겠습니다. 저와 비슷하게 자신만의 하네스 (harness)를 운용하고 계신 분들께 참고가 된다면 기쁘겠습니다.

Discussion