코딩 AI의 계획 기능: 정확도와 비용의 차이

AI에게 먼저 계획을 세우라고 하면 결과가 더 좋아질까. 계획을 켠 뒤 성공률이 오를 수도 있고, 성공률은 조금 낮아지면서 비용이 줄 수도 있다. 어떤 쪽을 개선이라고 볼지는 맡긴 작업의 실패 비용에 달려 있다.

9월 17일 공개된 「An Empirical Study of Harness Design for Coding Agents」는 네 모델에서 계획·도구·문맥 관리 방식을 나누어 비교했다. 이 글에서 살펴볼 것은 계획 기능의 효과다. 성공한 작업이 늘었는지와, 작업을 더 싸게 끝냈는지를 분리해서 읽어야 한다. 논문과 공개 이력

한 번 쓰는 계획문과 계속 보이는 진행표

이 논문의 계획 기능은 처음에 생각을 길게 적는 방식과 다르다. AI가 도구로 계획을 갱신하고, 실행 과정에서 그 계획을 매번 다시 입력받는다. 계획을 끈 조건에서는 계획용 지시·알림·도구와 반복 입력을 함께 제거했다. 따라서 결과는 이렇게 구현한 지속적인 계획 기능에 관한 비교다. 특정 제품의 계획 모드나 “차근차근 생각해”라는 문구의 효과와 같다고 보면 안 된다. 계획 기능의 구현

작업 진행표에 비유하면 이해하기 쉽다. 처음 회의에서 할 일을 읽고 끝내는 것과, 매번 다음 행동을 정하기 전에 완료·진행·미완료 항목을 다시 보는 것은 다르다. 후자는 무엇을 빼먹었고 언제 끝내야 하는지 판단하는 데 영향을 줄 수 있다. 이 비유는 기능 차이를 설명하는 것이며, 진행표를 넣으면 반드시 성과가 좋아진다는 뜻은 아니다.

같은 조건에서 계획만 바꾼 수치

아래는 SWE-Bench Verified의 소프트웨어 오류 수정 과제에서 계획을 끄고 켰을 때다. 문맥 한도 128k, 논문의 T4 문맥 관리 방식과 정해진 도구 구성을 유지한 비교다. T4는 오래된 도구 출력을 먼저 줄이고 필요하면 요약하며, 생략한 기록을 다시 꺼낼 수 있게 보관하는 방식이다.

모델	성공률: 끔 → 켬	변화	과제당 평균 비용: 끔 → 켬
Nemotron-3 30B	13.6% → 25.2%	+11.6%p	$0.02 → $0.09
Nemotron-3 120B	46.6% → 44.0%	−2.6%p	$0.25 → $0.34
Nemotron-3 550B	67.8% → 65.8%	−2.0%p	$3.31 → $2.33
Mistral Medium 3.5	69.0% → 68.6%	−0.4%p	$4.65 → $3.14

원문 표 3의 수치를 옮겼다. 비용은 연구진이 토큰 사용량에 정한 요금을 적용한 값으로, 이 글에서 API를 호출해 측정한 지출이 아니다. %p는 두 성공률을 뺀 퍼센트포인트다. 표의 작은 차이를 모두 통계적으로 확정된 개선이나 악화로 해석하지 않는다.

30B는 더 많이 성공했지만 비용도 늘었다. 120B는 이 조건에서 성공률과 비용이 모두 유리해지지 않았다. 550B와 Mistral은 성공률 상승 없이 비용이 줄었다. 네 결과를 “계획을 켜면 정확하고 저렴해진다”로 묶을 수 없는 이유다.

같은 기능이 다른 일을 줄인 이유

연구진은 최종 점수와 함께 실행 기록을 분석했다. 가장 작은 모델에서는 계획이 코드를 고치기도 전에 작업을 끝내는 경우를 줄였고, 더 큰 두 모델에서는 수정 후 검증 단계가 주로 짧아졌다고 해석했다. 실행 과정 분석

첫 경우에는 더 오래 진행할 필요가 있었다. 해야 할 수정을 시작하지도 못한 채 끝냈다면, 비용이 적게 들었다는 사실만으로 효율적이라고 하기 어렵다. 두 번째 경우에는 언제 검사가 충분한지 판단하는 일이 중요해진다.

다만 검증이 짧아졌다는 관측만으로 줄어든 검사 전부가 불필요했다고 판단할 수는 없다. 이번 표에서도 성공률이 그대로 오른 것은 아니다. 내 작업에 적용하려면 같은 검사를 반복한 횟수와 서로 다른 실패를 찾는 검사 수를 구별해야 한다.

예를 들어 계산 결과 확인과 새로고침 후 저장 확인은 둘 다 브라우저를 사용하지만 다른 오류를 찾는다. 반면 코드도 입력도 바뀌지 않았는데 같은 화면을 여러 번 캡처하는 것은 새 근거를 주지 않을 수 있다. 앱 재구현과 동작 검사의 예제에서는 첫 화면 검사만으로 계산·저장 오류를 찾지 못했다.

성공 한 건에 들어간 비용으로 다시 보기

시도 한 번이 싸도 많이 실패하면 맡긴 일을 끝내는 비용은 달라진다. 공개된 평균값으로 다음 비율을 계산할 수 있다.

성공 한 건당 배분 비용
= 전체 시도 비용 / 성공 건수
= 과제당 평균 비용 / 성공률

표의 반올림된 값으로 계산하면 30B는 약 0.15달러에서 0.36달러로, 550B는 약 4.88달러에서 3.54달러로 바뀐다. 이는 실패한 시도의 비용까지 성공한 결과 수에 나누어 배분한 값이다. 같은 작업을 재시도하면 얼마에 성공한다는 예측은 아니다.

30B에서 이 비율이 커졌다고 계획을 무조건 끌 수도 없다. 비용이 더 들어도 해결한 작업 수를 늘리는 것이 목적일 수 있다. 반대로 550B의 비율이 낮아졌다고 바로 채택할 수도 없다. 실패한 작업이 무엇인지, 사람이 다시 확인할 시간이 늘었는지가 빠져 있다.

이 계산에서 얻을 기준은 모델 순위가 아니다. 시도 비용, 성공한 결과 수, 실패 뒤의 복구 비용을 함께 기록해야 한다는 것이다. 보고서의 총 토큰이 줄었다는 이유만으로 작업 전체가 싸졌다고 쓰지 않겠다.

계획·문맥·도구를 한꺼번에 바꾸지 않기

논문에서 말하는 harness는 AI에게 제공하는 도구, 작업 기록, 실행 순서 등을 연결하는 프로그램이다. 같은 모델이라도 이 주변 구성이 바뀌면 다른 방식으로 일한다.

계획을 켜는 동시에 기록을 요약하고 도구도 줄이면, 결과가 달라진 이유를 특정하기 어렵다. 그래서 내 작업에서 비교한다면 우선 같은 모델과 같은 과제 복사본으로 시작하고 계획 조건만 바꾸겠다. 이것은 이번 조사에서 정리한 비교안이며, 아직 모델을 호출해 실행한 실험은 아니다.

고정할 것	기록할 것
모델 버전·초기 파일·요청·도구	성공 여부와 실패한 검사
입력 한도·최대 실행 예산	토큰과 과제당 비용
사전에 정한 최종 검사	수정 전 종료·검사 전 종료 여부
외부 서비스와 데이터 상태	사람 개입·추가 수정·재실행 시간

계획을 켠 실행의 대화를 다음 실행에 넘기면 조건이 달라진다. 같은 과제의 초기 상태를 따로 복사해야 한다. 한 번의 성공·실패로 결론 내리지 않고, 작업 종류와 반복 실행에 따라 결과가 유지되는지도 봐야 한다.

계획에 넣을 완료 근거

실무에서 계획을 요청한다면 ‘분석 → 구현 → 테스트’라는 이름만 적게 하지 않겠다. 각 단계가 끝났다고 판단할 근거까지 붙이는 쪽으로 요청하겠다. 아래는 이번 논문을 읽고 구성한 예시다.

할 일과 함께 완료로 판단할 조건을 적는다.
구현 항목마다 확인할 입력과 기대 결과를 연결한다.
실패한 검사는 지우지 말고 수정 후 다시 확인한다.
같은 검사를 반복할 때는 코드·입력·환경 중 무엇이 바뀌었는지 적는다.
최종 수정 뒤 필요한 검사까지 통과하면 종료한다.
실행하지 못한 검사가 있으면 완료 항목과 분리해 남긴다.

이 기준에서는 계획이 길다고 좋은 것이 아니다. 작업을 시작하지 못하고 끝나는 문제와, 확인이 끝났는데 같은 행동을 반복하는 문제를 각각 줄일 수 있어야 한다. 필요한 검사를 생략해 비용을 낮추는 것도 피해야 한다.

이번 연구는 공개된 미심사 원고이고, 네 모델과 두 평가 환경을 다룬다. 결과를 모든 코딩 AI에 적용할 수는 없다. 이 글에서 가져갈 판단은 더 좁다. 계획 기능의 효과를 평가하려면 얼마나 생각했는지보다 어디서 멈췄고 무엇을 확인했는지를 봐야 한다.

자료 확인·공개 수치 검산: 2026년 9월 21일. 논문 v1의 표와 분석을 사용했다. 모델 실행이나 성능 재측정은 하지 않았으며, 비용 비율은 공개된 반올림 수치로 계산했다.