동일한 6단계 작업을 단계별로 나누어 처리했을 때, 달성 건수는 유지되었으나 비용은 1.55배 증가하고 소요 시간은 1.85배 늘어났다

X(트위터)에서 검정 시험 연습 문제를 보게 되었습니다. '복잡한 작업을 AI에게 요청합니다. 더 적절한 프롬프트 설계는 무엇일까요?'라는 질문에, '모든 작업을 모호한 한 문장으로 지시하기', '‘느낌 좋게 처리해 줘’라고 맡기기', 그리고 '작업을 단계별로 나누어 순서대로 처리하게 하기' 세 가지가 나열되어 있었습니다. 문제 자체에는 수치가 하나도 없었으므로, 어느 것이 정답인지에 대한 논의는 하지 않겠습니다. 다만, '단계별로 나누어 요청하는 것'과 '한 번에 모아서 요청하는 것'으로 인해 제가 얻은 결과가 달라지는지 여부는, 같은 작업을 요청하는 방식만 바꿔서 여러 번 시도해 보면 계산할 수 있습니다.

그래서 문구가 1바이트도 다르지 않은 6단계 목록을 하나 준비하여, 요청 방식만을 두 가지로 나누어 테스트했습니다. 한쪽은 6단계를 번호가 매겨진 하나의 요청문으로 작성하여 한 번에 던지는 방식이었고, 다른 쪽은 1단계씩 6번에 걸쳐 나누어 던지되, 2회차부터는 이전 대화를 이어받는 방식이었습니다. 결과물 평가는 사람이 직접 채점하지 않고, 파일 유무, 문자열 유무, 종료 코드(Exit Code), 표준 출력(Standard Output)의 일치 여부, 행 수라는 6가지 조건만을 적용했습니다. 종료 코드는 명령어가 끝날 때 반환하는 숫자이며, 0은 성공을 의미합니다. 표준 출력은 명령어가 화면에 내보내는 문자입니다. 두 방식 모두 각각 5회씩 시도했으므로, claude -p를 호출한 횟수는 총 35회가 되었습니다.

결론부터 말씀드립니다.

• 달성 건수에는 전혀 변화가 없었습니다. 한 번에 모아서 요청했을 때와 단계별로 6번 나누어 요청했을 때 모두 30/30이었습니다.
  6가지 조건 모두를 만족한 시도는 어느 쪽이나 5회 중 5회였습니다. 이 기준으로는 두 방식을 구별할 수 없었습니다. - 차이가 난 것은 비용과 시간이었습니다. 배율은 둘 다 5회 시도의 총합 간의 비율입니다. 비용은 단계별로 6번 나눈 방식이 1.55배(0.55110 USD 대 0.35608 USD)였습니다. 소요 시간은 1.85배로, 131,120 ms 대 70,846 ms이며, 초 단위로 반올림하면 약 131초 대 약 71초입니다. 입력 토큰(Input Token)은 2.51배였습니다. 입력 토큰이란 모델에 읽히게 한 문자의 양을 세는 단위입니다.
• '6단계 전부를 처음에 적으면 선지출이 부담되지 않을까'라는 저의 예상은 빗나갔습니다. 첫 번째 상호작용에서 들어간 입력의 차이는 평균 1,567.2 토큰에 불과했습니다. 무거웠던 것은 2단계 이후가 매번 그전 대화를 다시 읽어와야 하는 부분이었습니다.
• 단계별로 나눈 방식에서는, 후반 단계가 이전 단계의 달성을 망친 시도는 0 / 5였습니다. 단계별 달성 건수는 5회 시도 모두 **[2, 3, 3, 4, 5, 6]**으로 동일한 순서였습니다.
• 측정 방식 때문에 한 번 혼동했습니다. 대화를 이어받아 호출했을 때의 비용 항목은 대화의 누적 합계로 계산되어, 6번을 더하면 0.55110 USD가 2.24125 USD로 늘어납니다. 저 역시 한 번 그것으로 '6.3배'라는 잘못된 수치를 만들었습니다.

먼저 두 가지 사과 말씀드립니다. 생성된 코드의 품질, 가독성, 설계는 일절 비교하지 않았습니다. 채점은 기계가 결정하는 6가지 조건의 개수만을 기준으로 했습니다. 그리고 맨 앞 질문의 정답도 다루지 않습니다. 여기에 있는 것은 제가 직접 35회 시도한 결과일 뿐입니다.

무엇을 어떻게 측정했는가

사용된 것은 claude -p입니다. 대화 화면을 출력하지 않고, 지시를 한 번 전달하여 결과를 받는 사용법을 의미합니다.

버전을 표시하는 명령어(claude --version)의 출력은 2.1.304 (Claude Code)였습니다. 아울러 node --version으로 표시된 버전은 v22.22.0이었습니다. 응답을 작성한 모델은 claud-sonnet-5-5입니다(보조적으로 claude-haiku-5-5도 매번 등장합니다). 이 구별 방식에는 함정이 있었기에, 다음 절에서 설명하겠습니다.

먼저 단계 목록을 만들었습니다. 두 가지 요청 방식 모두 이 6줄을 그대로 사용했습니다.

1. 작업 디렉터리에 convert.js라는 이름의 파일을 생성해 주세요.
2. convert.js 안에 화씨 온도를 섭씨로 변환하는 함수를 function toCelsius라는 선언 형태로 정의해 주세요.
3. convert.js를 node --check convert.js가 구문 오류 없이 종료 코드 0으로 통과할 수 있는 상태로 만들어 주세요.
...

채점 규칙 역시, 한 번 시도하기 전에 결정하여 고정했습니다. 사람의 판단은 일절 개입하지 않았습니다.

나중에 조건을 완화하거나 강화할 수 없도록, 공정 목록과 채점 스크립트, 요청문의 해시 값을 미리 기록했습니다. 해시 값은 파일 내용으로부터 결정되는 짧은 문자열로, 내용을 단 1글자라도 변경하면 다른 값이 됩니다. steps.txt는 fb1e48ea41802d463dcbddf056cea1c5, 채점 스크립트인 judge.sh는 6e1bb30841037b29de79288d42aed7d0, 그리고 전체 요청문 promptA.txt는 d07a509f89b4b61410b129aab8aea6b3입니다.

6가지 조건이 동시에 충족되는 것 자체는 참조 구현(예시로 직접 작성한 완성본)으로 먼저 확인했습니다. 모델의 응답을 보고 나서 조건을 정한 것이 아니라는 순서를 확보하고 싶었기 때문입니다. 참조 구현을 놓은 디렉토리에서는 COUNT 6이었고, 빈 디렉토리에서는 COUNT 0이었습니다.

두 가지 요청 방식에서, 요청문의 차이는 다음 한 줄뿐입니다. 전체를 한 번에 처리하는 방식은 '다음 6개 공정을 모두 실시해 주세요.' 다음에 1.부터 6.까지 나열한 반면, 공정별로 6번 처리하는 방식은 k번째가 '다음 공정을 실시해 주세요.'라는 공정 내용 한 줄뿐이었습니다.

공정의 문구가 실제로 동일한지 여부는 번호를 제외한 열을 cmp로 비교하여 기계적으로 확인했습니다 (IDENTICAL).

실제로 던진 명령어는 다음과 같습니다. 기록 파일명이나 이 뒤의 표에서는, 전체를 한 번에 처리하는 방식을 A, 공정별 6회 처리를 B로 약칭합니다. 작업 디렉토리는 시도할 때마다 새로 만들었으며, 공정별 6회 처리 방식만은 6번 동안 같은 디렉토리를 재사용했습니다.

# 전체를 한 번에 처리하는 경우
WD=$(mktemp -d); SID=$(cat /proc/sys/kernel/random/uuid)
( cd "$WD" && env -u CLAUDE_CODE_SESSION_ID -u MAX_THINKING_TOKENS -u CLAUDE_EFFORT \
...

1회차를 던지기 전에, 6가지 조건을 마지막에만 적용할지, 공정 직후에도 적용할지 고민했습니다. 알고 싶었던 것 중 하나가 '후속 공정이 이전 공정의 성과를 훼손하는지'였기 때문에, 공정별 6회 처리 방식에서는 각 공정 직후에도 6가지 조건을 적용했습니다. 이렇게 하면 도중에 충족했던 조건이 마지막에 사라지지 않았는지 셀 수 있습니다.

시도 횟수는 각각 5회입니다. claude -p를 호출한 횟수는, 전체를 한 번에 처리하는 방식이 5회, 공정별 6회 처리가 30회로, 총 35회였습니다.

총액은 0.90718 USD였습니다. 먼저 4회씩으로 완료시킨 후 예산 여유가 있어 5번째 회차를 추가했습니다.

영향: 35회 모두 종료 코드 0・오류 처리 없음(is_error는 전체 False)・오류 출력 0 바이트. 총액 0.90718 USD

달성 건수는 30/30과 30/30으로 차이가 없었다

실행하기 전 저의 예상은 어느 한쪽에 차이가 날 것이라는 것이었습니다. 공정별로 나누어 처리하면 하나씩 해결되므로 누락이 적을지, 반대로 모아서 처리하는 것이 전체를 파악하기에 유리할지, 그 둘 중 하나일 거라고 생각했습니다.

결과는 어느 쪽도 아니었습니다. 전체를 한 번에 처리한 5회 시도는 다음과 같습니다.

trial exit num_turns duration_ms total_cost_usd 달성 건수
A1 0 8 11200 0.07087 6
A2 0 9 16069 0.07021 6
...

5회 시도 모두 6/6, 총합 30/30이었습니다. 공정별 6회 처리 방식 역시 마지막 공정을 마친 시점에서 5회 시도 모두 6/6, 총합 30/30이었습니다. 6가지 조건을 모두 충족한 시도의 수는 5/5와 5/5로, 여기도 나란했습니다.

산출물의 외관에서 차이가 난 부분은 README.md의 행 수 정도였습니다. 전체를 한 번에 처리한 방식은 6행, 6행, 7행, 6행, 6행이었습니다.

단계별 6회 처리 방식의 경우, 줄 수는 각각 9줄, 10줄, 8줄, 8줄, 8줄이었습니다. 이 모든 것이 C6의 '10줄 이하' 기준을 충족하므로 채점상으로는 동일한 건수입니다.

이 축에서 차이가 나지 않은 것은 6가지 조건 자체가 이 주제에 너무 쉬웠기 때문일 수 있습니다. 하지만 조건은 해시값(hash value)을 추출하여 고정시킨 후 실행했기 때문에, 나중에 난이도를 높여 변경하지는 않았습니다.

난이도를 올렸을 때 어떻게 될지는 이번 측정 범위 밖에 있습니다.

영향 분석 (Impact): 달성 건수는 한 번에 처리하든 단계별로 6회 처리하든 모두 30/30으로 동일했습니다. 6가지 조건을 모두 충족한 시도는 5/5와 5/5였습니다. README.md의 줄 수는 67줄 대 810줄이었으며, 어느 경우든 C6의 10줄 이하에 수렴합니다.

단계별로 분석했을 때 [2, 3, 3, 4, 5, 6]. 오류 발생 건수는 0 / 5

단계별 6회 처리 방식은 각 단계 직후에도 6가지 조건을 적용했습니다. 첫 번째 시도(B1)의 내역을 나열합니다.

step1: C1 PASS C2 FAIL C3 PASS C4 FAIL C5 FAIL C6 FAIL COUNT 2
step2: C1 PASS C2 PASS C3 PASS C4 FAIL C5 FAIL C6 FAIL COUNT 3
step3: C1 PASS C2 PASS C3 PASS C4 FAIL C5 FAIL C6 FAIL COUNT 3
...

단계별 달성 건수의 배열이 5개 시도 모두에서 완벽하게 동일했습니다.

B1 per-step counts: [2, 3, 3, 4, 5, 6]
B2 per-step counts: [2, 3, 3, 4, 5, 6]
B3 per-step counts: [2, 3, 3, 4, 5, 6]
...

건수는 단 한 번도 줄지 않았습니다. 즉, 후속 단계가 진행되면서 이전 단계의 성과가 무너지는 사고는 5개 시도 모두에서 발생하지 않았습니다(0 / 5). 순차적으로 쌓아 올리는 방식에서는 이곳이 걱정될 것이라 생각했기에, 이는 예상외로 수월했습니다.

반면, 예상치 못한 부분도 있었습니다. 단계 3가 달성 건수를 단 한 개도 늘리지 못했습니다(3 → 3). 원인은 저의 조건 설계에서 발생한 부작용입니다. 단계 1이 생성한 convert.js는 내용물이 비어 있어도 구문만 검사하는 명령어인 node --check convert.js가 종료 코드 0으로 통과해 버립니다. 따라서 C3는 이미 단계 1 시점에서 충족되어 있었고, 단계 3에서 늘릴 여지가 남아있지 않았던 것입니다. 단계 1의 건수가 1이 아니라 2인 것도 C1과 C3가 동시에 존재했기 때문입니다.

조건은 해시값을 추출하여 고정해 두었으므로, 여기서 수정하지 않고 부작용으로 그대로 기록했습니다. '빈 파일이라도 구문 검사는 통과한다'는 점은 채점 조건을 스스로 설계할 때 주의해야 할 함정으로 기억해 둘 생각입니다.

영향 분석 (Impact): 단계별 달성 건수는 5개 시도 모두 [2, 3, 3, 4, 5, 6]로 단조 증가했습니다. 후속 단계가 이전 조건을 무너뜨린 시도는 0 / 5였습니다. 단계 3의 증분은 0건입니다 (빈 convert.js 파일이라도 node --check가 종료 코드 0으로 통과하기 때문에 C3는 이미 단계 1에서 PASS 상태였습니다.)

차이가 발생한 것은 비용과 소요 시간이었다

달성 건수로는 구별할 수 없다면, 남는 것은 요금(비용), 소요 시간, 토큰 같은 과정 중에 사용된 값들입니다.

5개 시도의 합계를 나열합니다.

한 시도당으로 계산하면, 비용은 0.07122 USD 대 0.11022 USD였고, 소요 시간은 14,169 ms 대 26,224 ms였습니다.

동일한 달성 건수에 도달하기 위해 단계별로 나눈 쪽은 약 1.6배의 비용과 약 1.9배의 시간을 사용했습니다.

입력 토큰은 2.51배 증가했지만, 비용 증가는 1.55배였습니다. 배율이 일치하지 않은 것은 관찰된 사실로서 그대로 기록해 두겠습니다. 입력 내역까지 기록에서 추출할 수 있었던 것은 단계별 6회 처리 방식의 첫 번째 시도(B1) 6회분뿐입니다. 이 6회분을 단계별로 살펴보니, 어느 회차 모두 입력의 대부분이 '캐시에서 읽은 부분'으로 계상되어 있었습니다. 이는 이미 전송된 내용으로 간주되었기 때문입니다.

입력 내용입니다. B1의 프로세스 3이라면, 입력 110,715 토큰 중 110,259가 해당되었습니다. 다만 나머지 호출에 대해서는 세부 내역을 확인하지 못했기 때문에, 이것이 배율 차이의 원인이라고 단정할 수는 없습니다.

(검증 불가: 요금과 토큰 유형 간의 대응은 측정되지 않았습니다). 요금 수치 역시 이번 환경에서의 값입니다.

Impact: 5회 시도 합계로 비용 0.35608 → 0.55110 USD (1.55배), 소요 시간 70,846 → 131,120 ms (1.85배), 입력 토큰 960,156 → 2,413,272 (2.51배), 출력 토큰 7,386 → 10,074 (1.36배)

비용이 높았던 것은 프로세스별 6회였습니다. 예상과 달랐던 것은 '비용 증가의 원인'이었습니다.

저는 처음에는 이렇게 생각했습니다. 6개 프로세스 분량의 문면을 모두 한 번에 쌓아 올리려면,

한 번에 요청하는 것이 초기 로딩 시 더 무거울 거라고요. 프로세스별로 처리하면 한 줄만 전달하므로 가벼울 것이라고 생각했습니다.

실제로 측정해 보니, 선지급(pre-payment)의 경향은 예상대로였습니다. 한 번에 몰아서 요청하는 것이 초기 로딩에는 더 무겁습니다.

달랐던 점은 그 차이의 크기였는데, 그 무게는 무시할 수 있는 정도였습니다. 게다가 비용이 높아진 것은 한 번에 몰아 처리한 경우가 아니라 프로세스별 6회로 나눈 경우였습니다. 추가된 비용의 정체는 초기 선지급이 아니라,

분리하여 진행한 횟수만큼 대화를 다시 읽어들이는 부분(재처리)이었습니다.

첫 번째 상호작용에 포함된 입력을 비교해 보겠습니다. 기록 중 최초 상호작용 분량만 추출할 수 있는 항목이 있으며,

상호작용 횟수가 8회든 10회든, 그곳에는 항상 1건(즉, 첫 회차분만)이 기재됩니다.

A1 num_turns=8 it0_in=37477
A2 num_turns=9 it0_in=37676
A3 num_turns=10 it0_in=37818
...

평균적으로, 한 번에 몰아서 처리했을 때가 37,620.6 토큰, 프로세스별 6회 중 첫 번째 프로세스가 36,053.4 토큰이었습니다.

차이는 1,567.2 토큰밖에 나지 않습니다. 6개 프로세스 분량의 지시를 모두 추가해도, 초기 선지급은 이 정도만 증가하는 것입니다. 참고로 둘 다 3만 6천~3만 7천 토큰대에 속하지만, 그 내부 내역은 확인하지 못했습니다(검증 불가: 최초 입력의 세부 내역은 측정되지 않았습니다).

그렇다면 5회 시도 합계로 2.51배나 부풀어 오른 부분은 어디에서 왔을까요? 1회 시도분 입력 토큰 차이를 시도별로 계산하면, 300,221 / 297,597 / 259,531 / 335,499 / 260,268 등으로 모두 수십만 토큰 단위였습니다.

즉 증가했던 것은 초기 선지급이 아니라, 프로세스 2회차부터 매번 이전 대화를 다시 읽어들이는 부분이었습니다.

프로세스를 6개로 나누면, 6번째는 1회차부터 5회차까지의 상호작용을 포함한 상태에서 시작합니다.

나눈 횟수만큼 재처리가 누적되는, 단순한 이야기입니다.

Impact: 최초 상호작용에 포함된 입력은 평균 37,620.6 대 36,053.4 토큰으로 차이는 1,567.2 토큰뿐이었습니다. 1회 시도분 입력 토큰의 차이는 259,531~335,499 토큰이었습니다.

비용을 한 번에 4배로 오해했습니다

이번 검증에서 재계산하게 된 것은 모델의 동작 측정 방식이 아니라, 저 자신의 집계 오류였습니다.

프로세스별 6회 중 첫 번째 시도(B1)에서 각 프로세스의 비용 항목을 나열해보니 0.04168 → 0.05359 → 0.06989 → 0.08491 →

0.09921 → 0.11257 와 같이 깔끔하게 증가했습니다. 저는 이것을 '해당 회차의 비용'이라고 생각하고,

6회 분량을 모두 더했습니다. 이 시도에서는 0.46185 USD가 나왔고, 여기에 5회 시도를 더하여 2.24125 USD를 만들었습니다. 한 번에 몰아서 처리한 0.35608 USD와 비교했을 때 6.3배라는, 제목으로 쓰면 눈길을 끌 만한 수치가 한번 만들어졌습니다.

이상하다고 느낀 점은 증가 패턴이 너무 단조로웠다는 것입니다. 기록에는 사용량이 기재되는 곳이 2군데 있습니다.

하나는 모델별 세부 내역(modelUsage)으로, 어떤 모델이 얼마나 읽고 썼는지가 나열됩니다. 다른 하나는

사용량 항목(usage)인데, 여기에 적히는 것은 입력과 출력의 양뿐입니다. 이 두 가지를 대조하면 어느 것이

회차별 수치인지 판단할 수 있습니다.

확인 방법은 다음과 같았습니다. 프로세스 k의 모델별 세부 내역에서 프로세스 k-1의 세부 내역을 빼서, 그 차이가 프로세스 k의

사용량 항목과 일치하는지 확인합니다. 일치한다면, 세부 내역 쪽이 누적값이고 사용량 항목이 회차별 값이라는 설명이 성립됩니다. 다음 기록에서는, mu_cacheRead

모델별 상세 내역 쪽의 값인 usage_cache_read와 사용량 항목 쪽의 값인 delta는 이전 단계의 상세 내역을 뺀 차이입니다.

B1:
s1: total_cost=0.041677 mu_cacheRead=63959 usage_cache_read=63959
s2: total_cost=0.053590 mu_cacheRead=136390 usage_cache_read=72431 delta=72431
...

차이가 정확히 일치했습니다. 이전 대화를 이어받은 호출에서는, 해당 횟수별 숫자가 기록된 것은 사용량 항목뿐입니다. 요금 항목(total_cost_usd)과 모델별 상세 내역은 대화 시작부터의 누적 합계였습니다.

즉, 단계별 6회의 실제 총 요금은 '마지막 단계의 요금 항목'이며, 6번을 더한 값이 아닙니다. 합산하면 약 4배로 중복 계산하게 됩니다.

집계 스크립트를 '마지막 단계의 값 사용'으로 수정하여 다시 진행했고, 6.3배라는 수치는 폐기했습니다.

이러한 오해는 결론의 크기를 4배 변화시킵니다. 단계별로 나누어 순차적으로 사용하는 방식의 요금을 직접 계산하려면, 이 부분은 한 번 확인하는 것이 좋을 것 같습니다.

# 단계별 총요금은 마지막 단계의 값(합산하지 않음)
python3 -c "import json;print(json.load(open('B.s6.json'))['total_cost_usd'])"

영향: 정확한 합계는 0.55110 USD, 6회분을 더한 오류 값은 2.24125 USD (약 4배). 배율은 6.3배에서 1.55배로 수정됨

이어받기는 작동했다. 다만 모델명 식별 방식은 무너진다

단계별 6회의 경우, 2회차 이후가 실제로 같은 대화에 연결되어 있지 않다면 비교할 의미가 없습니다.

형식적으로만 연결되었다고 착각하지 않았는지 두 가지 방식으로 확인했습니다.

첫 번째는 전달한 식별자가 그대로 반환되는지 여부입니다. 35회 모두 일치했습니다 (모아서 1회당 5/5, 단계별 6회당 30/30).
두 번째는 대화 전사 파일입니다. 시도마다 생성된 파일은 단 하나였으며, 그 하나의 파일에 6회분의 요청문이 나열되어 있었습니다.

$ ls /root/.claude/projects/-tmp-tmp-VVoxI2Wg03/
cac3a6a3-26ec-40b0-8ac3-ff97ab66f78b.jsonl
user-role entries containing a plain string prompt: 6
...

5가지 시도 모두 동일한 형태로, 전사 파일의 줄 수는 89~95줄이었습니다.

이 전사 파일을 찾는 과정에서 사소하게 어려움을 겪었습니다. 저장 폴더 이름은 작업 폴더 경로를 압축한 형태가 되는데, 압축되는 것은 / 뿐만이 아닙니다. .도 -로 바뀝니다 (/tmp/tmp.VVoxI2Wg03이 -tmp-tmp-VVoxI2Wg03으로). 처음에는 /만 대체하여 찾다가 헛수고를 했고, find 명령어로 수정한 뒤 변환을 고쳤습니다.

그리고 누적 합계에 대한 이야기(앞 단락)에는 또 다른 부작용이 있었습니다. 저는 항상 응답을 작성한 모델을 '모델별 상세 내역 중 입력 토큰 수가 전체 항목과 일치하는 것'으로 구분해 왔습니다.

이러한 식별 방식은 상세 내역이 누적 합계가 되는 호출에서는 성립하지 않습니다. 35회에 걸쳐 확인했을 때, 일치한 것은 정확히 10건이었습니다.

json files: 35
match counts: {"('claude-sonnet-5-5',) ": 10, '()' : 25}
matched files: ['A1.json', ..., 'A5.json', 'B1.s1.json', ..., 'B5.s1.json']

일치한 10건은 모아서 1회당 5회와, 단계별 6회의 제1단계 5회였습니다. 둘 다 새로 대화를 시작한 경우입니다.

일치하지 않은 25건은 이전 대화를 이어받은 25회와 정확히 대응했습니다. 모델명 자체는 신규 측에서 가져올 수 있어 claude-sonnet-5-5로 확정할 수는 있었지만, 이어받은 호출만 보고 이 방법으로 모델을 특정하는 것은 불가능하다는 결론이 나옵니다.

영향(Impact): 전달한 식별자와 반환된 값은 35회 모두 일치했습니다(5/5 및 30/30). 전사 파일은 시도마다 1개, 요청문은 6번 분량으로 총 89~95행입니다. 모델 이름 구분이 성립한 경우는 10/35건(신규 세션 측만 해당)이었고, 성립하지 않은 25건은 인계된 호출 25건과 완전히 일치했습니다.

양쪽 요청 방식 모두에서 공통적으로 자기 확인 명령이 통하지 않음

비교와 별개로 기록을 보고 알게 된 점이 있습니다. 권한 설정(permission setting)을 --permission-mode acceptEdits (파일 수정은 자동으로 허용)으로 했지만, 셸 명령어 실행이 모두 거부되고 있었습니다. 거부된 기록은 총 35회에 걸쳐 45건이었으며, 그 전체가 Bash였습니다. 내용까지 기록에 남긴 것은 모아서 단 한 번의 첫 시도(A1)에서 나온 5건뿐입니다. 이 중에서 몇 가지를 발췌합니다.

Bash | {"command": "cat > convert.js <<'EOF'\nfunction toCelsius(f) {\n ... "}
Bash | {"command": "node --check convert.js"}
Bash | {"command": "node convert.js 212"}
...

발췌된 내용을 보면, 대부분은 모델이 자신의 결과물을 확인하려 했던 실행들이었습니다. 파일을 쓰려고 시도한 호출들도 섞여 있었습니다. 프로세스 3부터 프로세스 5까지는 '이 명령어가 이렇게 작동하도록'이라는 내용이었으므로, 원래라면 직접 실행하여 확인하고 싶었을 부분입니다. 건수는 모아서 한 번에 진행했을 때가 26건(시도마다 5/5/6/4/6)으로 더 많았습니다. 프로세스별로 6번씩 진행한 경우의 건수는 19건이었고, 내역은 4/4/3/4/4입니다.

여기서 한쪽만 허용 설정을 완화하면 비교가 무너지기 때문에, 설정은 그대로 두고 사실을 기록하는 선택을 했습니다.

양쪽에 동일한 설정을 부여했으므로, A와 B를 비교하는 것 자체는 성립합니다. 다만, 두 요청 방식 모두 '직접 실행하여 확인'하지 않은 조건에서의 측정이라는 점은 읽을 때 염두에 두시기 바랍니다.

참고로, 쓰기 전용 도구만으로도 양쪽 모두 6/6에 도달했습니다.

자기 확인이 통하는 설정이라면 달성 건수에 차이가 생길까요? 이는 이번에 시도하지 않았으므로 검증 불가합니다.

영향(Impact): 거부된 도구 호출은 총 35회에 걸쳐 45건이었으며, 모두 Bash였습니다. 내역은 모아서 한 번 진행했을 때 26건, 프로세스별로 6번씩 진행한 경우 19건입니다. 둘 다 쓰기 전용 도구만으로 6/6에 도달했습니다.

검증하지 못한 사항

• 검증 불가: 서두의 질문 정답, 어떤 요청 방식이 일반적으로 우수한가. 기계로 판정할 수 있는 대상이 아닙니다. 이번에 센 것은 이 6개 프로세스/6가지 조건/이 버전에 대한 건수와, 비용·소요 시간·토큰 등 도중에 발생한 값뿐입니다. - 검증 불가: 생성된 코드의 질·가독성·설계. 채점 기준은 파일 유무·문자열 유무·종료 코드·표준 출력 일치 여부·행수만입니다. 응답문에 적힌 주장을 근거로 삼지 않았습니다. - 검증 불가: 비용과 토큰 종류의 대응 관계. 입력 내역(캐시에서 읽은 분량 등)을 기록에서 추출한 것은 프로세스별 6번씩 진행한 첫 시도 6회분만입니다. 나머지 호출 내역의 세부 사항은 가져오지 않았기 때문에, 입력 토큰 배율과 비용 배율이 일치하지 않는 이유까지는 분석하지 못했습니다. - 검증 불가: 자기 확인 명령이 통하는 허용 설정에서의 동작. 이번에는 양쪽 모두 acceptEdits 상태로, 셸 명령어 실행이 통하는 설정으로는 진행하지 않았습니다. - 검증 불가: 조건을 엄격하게 했을 경우. 달성 건수는 양쪽 모두 만액에 도달했지만, 조건은 실행하기 전에 동결되어 나중에 변경하지 않았습니다. - 검증 불가: 프로세스 분할 방식·프로세스 수를 바꿨을 경우. 이번에는 6개 프로세스/6가지 조건의 한 가지 경우만 진행했습니다. - 검증 불가: 다른 주제·다른 버전·다른 모델·다른 사고량 설정·다른 기기·대화 화면에서의 어떤 것도 실행하지 않았습니다.

보이는 방식. - 검증 불가: 5회 초과 비율의 일반화. 각 5번 시도였으므로, 비율로 확장할 수는 없습니다.

요약