사내에 코딩 에이전트를 붙이려고 하면 "Claude Code 같은 루프를 직접 짤까, 정해진 단계로 돌릴까, 그냥 한 번 물어볼까"부터 막혀요. 결론부터 말하면 비용을 가르는 건 모델 단가보다 단계 수와 도구가 돌려주는 관찰의 크기이고, 루프를 쓴다면 프롬프트 캐시를 켜는 것만으로 과제당 비용이 4~5분의 1로 줄어요. 단, 오래된 관찰을 매 단계 조금씩 지우면 캐시가 깨져서 그 이득이 절반 넘게 날아가요.
이 글은 에이전트 내부 동작보다 도입할 때 돌아오는 숫자를 다뤄요. 2026년 10월 28일 기준 Claude API 공식 가격표의 단가로 과제 하나를 시뮬레이션해 직접 계산했고, 품질 수치는 각 논문·공식 글에 실린 값만 옮겼어요. 루프가 메시지 배열을 어떻게 키우는지 궁금하면 tool_use·tool_result 응답을 JSON 정렬 도구에 붙여 단계별로 펼쳐 보면 감이 빨리 와요.
코딩 에이전트 방식 판단표 — 세 갈래 중 어디서 시작할까
코딩 작업을 LLM 에 맡기는 구조는 크게 셋이에요. 프롬프트에 파일을 넣고 한 번에 패치를 받는 한 번 생성, 위치 찾기·수리·검증처럼 단계를 코드로 박아 둔 고정 파이프라인, 모델이 다음 도구를 스스로 고르는 도구 호출 루프예요. Anthropic 의 Building effective agents 글은 앞의 둘을 워크플로, 마지막을 에이전트로 나누고, 단순한 쪽으로 풀리면 굳이 에이전트를 쓰지 말라고 권해요.
| 구조 | 순차 호출 | 비용을 정하는 것 | 1차 자료의 수치 (서로 직접 비교 금지) |
|---|---|---|---|
| 한 번 생성 | 1회 | 넣는 파일 크기 | SWE-agent 논문 RAG 기준선, GPT-4 Turbo, SWE-bench Lite 2.67%, 평균 0.13달러 |
| 고정 파이프라인 | 단계 수로 고정, 샘플은 병렬 | 샘플 개수 | Agentless, GPT-4o, Lite 32.00%(300개 중 96개), 평균 0.70달러·78,166토큰 |
| 도구 호출 루프 | 모델이 끝낼 때까지 | 단계 수 × 누적 대화 | SWE-agent, GPT-4 Turbo, Lite 18.00%, 해결한 과제 평균 1.67달러 |
| 도구 호출 루프(최소 하네스) | 모델이 끝낼 때까지 | 단계 수 × 누적 대화 | Claude 3.5 Sonnet(업그레이드판), SWE-bench Verified 49% |
출처는 SWE-agent 논문, Agentless 논문, Anthropic 의 SWE-bench Verified 글이에요. 모델·벤치마크 판본이 달라 점수끼리 비교하면 안 되고, 가져갈 것은 비용 구조예요. 한 번 생성은 입력 크기에 정비례하고, 파이프라인은 샘플 수로 상한이 미리 정해지고, 루프만 실행해 봐야 비용이 정해져요. Agentless 는 수정 위치 후보 4벌마다 패치를 10개씩, 모두 40개를 만들어 고르는 구조라 샘플을 동시에 보낼 수 있어요.
비교 조건 — 과제 하나를 이렇게 가정했어요
루프 비용은 실행 궤적에 따라 달라서, 공개된 숫자로 뼈대를 잡고 나머지를 가정으로 채웠어요. 우리 저장소 숫자로 바꿔 넣으면 같은 식으로 다시 계산돼요.
- 고정 앞부분 P = 3,000토큰. 가격표상 Claude 5.5 계열은 도구가 하나라도 있으면 도구용 시스템 프롬프트 286토큰, bash 도구 정의 325토큰, 텍스트 편집 도구 974토큰이 붙어요. 합 1,585토큰에 시스템 지시와 이슈 설명을 더해 3,000으로 잡았어요.
- 단계당 모델 출력 o = 300토큰, 도구 관찰 c = 1,500토큰. 관찰은 100줄 파일 창이나 잘라 낸 테스트 로그 정도의 크기예요.
- 단계 수 n = 12 / 21 / 40. SWE-agent 논문에서 해결한 과제의 단계 중앙값이 12, 못 푼 과제의 평균이 21이었어요. 40은 상한을 넉넉히 준 경우예요.
- 캐시는 5분 자동 캐시. 새로 붙는 부분은 쓰기(입력 단가의 1.25배), 이미 캐시된 앞부분은 읽기(Opus 5.5·Sonnet 5.5 는 0.05배, Haiku 5.5 는 0.1배)로 계산했어요.
단계 k 에서 보내는 입력은 P + (k−1)·(o+c) 이에요. n 단계 동안 보낸 입력 합은 n·P + (o+c)·n(n−1)/2 라서 단계 수가 두 배면 입력은 네 배 가까이 늘어요. 21단계 예시는 입력 합이 44만 1천 토큰인데 마지막 요청은 3만 9천 토큰이에요. 대부분이 재전송이고, 캐시가 노리는 곳이 여기예요.
숫자로 보는 비용 ① 단계 수와 프롬프트 캐시
Sonnet 5.5(입력 100만 토큰당 2달러, 출력 10달러)로 위 조건을 돌린 결과예요.
캐시 없이 12단계에서 40단계로 가면 비용이 9.2배가 돼요. 캐시를 켜면 4.2배로 줄어요. 단계가 길수록 캐시 효과가 커져서 40단계에서는 7분의 1이에요. 다만 5분 캐시는 다음 요청이 5분 안에 와야 살아 있어요. 테스트 한 번이 5분을 넘는 저장소라면 1시간 캐시(쓰기 2배)를 쓰거나 테스트를 쪼개야 해요. 캐시 TTL 고르는 기준은 프롬프트 캐싱 비용 계산 글에 따로 정리했어요.
세 번째 계열이 이 글에서 가장 강조하고 싶은 숫자예요. SWE-agent 는 최근 관찰 5개만 남기고 나머지를 한 줄로 접었는데, 이렇게 하면 매 단계 접히는 위치가 하나씩 뒤로 밀려요. 그 지점부터 뒤쪽은 캐시와 내용이 달라져 모두 다시 써야 해서, 캐시를 켜도 전부 유지할 때보다 2.0~2.2배 비싸요.
숫자로 보는 비용 ② 도구 관찰을 어디서 자를까
관찰 크기를 바꿔 21단계 비용을 다시 계산했어요.
관찰 6,000토큰이면 마지막 요청이 12만 9천 토큰까지 커져요
표로 보기
| 구분 | 캐시 없음 | 자동 캐시 |
|---|---|---|
| 500토큰 | 0.525 | 0.132 |
| 1500토큰 | 0.945 | 0.201 |
| 3000토큰 | 1.6 | 0.304 |
| 6000토큰 | 2.8 | 0.511 |
관찰을 1,500에서 6,000토큰으로 늘리면 캐시를 켜도 2.5배예요. 새로 붙는 관찰은 매번 1.25배로 써야 하기 때문이에요. 품질 쪽 근거도 같은 방향이에요. SWE-agent 절제 실험(GPT-4 Turbo, Lite)에서 파일을 통째로 보여 주면 12.7%, 100줄 창으로 보여 주면 18.0%였어요. 관찰 자르기는 비용과 품질을 함께 챙기는 드문 선택이에요.
자를 곳은 도구 쪽이에요. 파일 읽기는 줄 범위를 받게 하고, 검색 결과는 건수 상한을 두고, 테스트 로그는 실패 요약과 끝부분만 돌려줘요. 에이전트가 만든 패치를 사람이 검토할 때도 diff 만 보는 편이 빠른데, 원본과 수정본을 텍스트 비교 도구에 붙이면 바뀐 줄만 색으로 볼 수 있어요.
컨텍스트 정리 방식 비교 — 캐시를 살리는 쪽으로
긴 과제는 결국 컨텍스트 창을 채워요. Claude API 는 서버 쪽에서 오래된 도구 결과를 비우는 컨텍스트 편집 기능(clear_tool_uses_20250919)을 제공해요. 문서는 비울 때 캐시된 앞부분이 무효가 된다고 적고, 그래서 clear_at_least 로 한 번에 충분히 많이 비우라고 권해요. 문서 예시는 입력이 3만 토큰을 넘으면 비우고 최근 도구 사용 3개를 남기는 설정이에요.
| 정리 방식 (Sonnet 5.5, 캐시 켬) | 21단계·관찰 1,500 | 40단계·관찰 1,500 | 40단계·관찰 6,000 | 가장 큰 요청 (40단계·6,000) |
|---|---|---|---|---|
| 전부 유지 | 0.201달러 | 0.448달러 | 1.220달러 | 24만 8,700토큰 |
| 최근 관찰 5개만 | 0.445달러 | 0.955달러 | 2.928달러 | 4만 6,740토큰 |
| 문턱 3만에서 비우고 3개 남김 | 0.209달러 | 0.422달러 | 1.826달러 | 3만 3,420토큰 |
| 문턱 6만에서 비우고 3개 남김 | — | — | 1.078달러 | 5만 9,700토큰 |
접힌 관찰은 20토큰짜리 자리표시로 가정했어요. 같은 시뮬레이션으로 직접 계산했어요.
관찰이 작을 때는 문턱 3만 설정이 전부 유지와 비용이 거의 같으면서 창을 3만 토큰 안에 묶어요. 관찰이 6,000토큰으로 크면 3만 문턱은 거의 매 단계 다시 넘어서, 40단계 동안 33번 비우고 비용이 오히려 1.5배가 돼요. 문턱을 6만으로 올리면 6번만 비우고 전부 유지보다도 싸요. 문턱은 관찰 크기의 열 배 이상으로 잡는 게 안전해요.
품질은 따로 재야 해요. SWE-agent 실험에서는 최근 5개 유지가 18.0%, 전체 유지가 15.0%로 접는 쪽이 나았지만, 2024년 GPT-4 Turbo 기준이에요. 최근 모델로 같은 비교를 한 공개 수치는 찾지 못했어요. 반대로 mini-swe-agent 는 README에서 bash 하나와 덧붙이기만 하는 선형 이력으로 SWE-bench Verified 74% 이상이라고 밝혀요. 지금 모델에서는 "전부 유지 + 캐시"로 시작하고, 창이 차는 과제가 생길 때 큰 문턱의 정리를 붙이는 순서를 권해요.
모델 단가와 실패 비용 — 과제당 말고 해결당으로
같은 조건(21단계, 관찰 1,500, 전부 유지)을 모델만 바꿔 계산했어요.
| 모델 (입력/출력 100만 토큰당) | 캐시 없음 | 자동 캐시 |
|---|---|---|
| Claude Opus 5.5 (4달러/20달러) | 1.890달러 | 0.401달러 |
| Claude Sonnet 5.5 (2달러/10달러) | 0.945달러 | 0.201달러 |
| Claude Haiku 5.5 (0.10달러/0.50달러, 10만 이하) | 0.047달러 | 0.012달러 |
Haiku 5.5 는 요청 하나의 프롬프트가 10만 토큰을 넘으면 그 요청 전체가 입력 0.50달러·출력 2.50달러로 비싸져요. 캐시 읽기분도 길이에 포함돼요. 관찰 6,000토큰 조건에서는 17단계부터 이 선을 넘어서, 21단계 비용이 캐시 없이 0.378달러로 1,500토큰 조건의 8배가 돼요. 싼 모델일수록 관찰 자르기와 컨텍스트 정리가 비용을 더 크게 바꿔요.
비교할 단위는 과제당이 아니라 해결당이에요. SWE-agent 논문에서 GPT-4 Turbo 가 해결한 과제는 중앙값 12단계·1.21달러로 끝났고, 못 푼 과제는 평균 21단계·2.52달러를 썼어요. 실패가 더 길고 비싸요. 해결당 비용은 (성공률 × 성공 비용 + 실패율 × 실패 비용) ÷ 성공률이에요. Sonnet 5.5 캐시 조건에서 성공 12단계(0.106달러), 실패 21단계(0.201달러), 성공률 50%면 해결당 0.307달러예요. 실패를 40단계까지 끌게 두면 0.554달러로 1.8배가 돼요. 성공률이 70%로 오르면 각각 0.192달러, 0.298달러예요. 비싼 모델이 성공률을 충분히 올리면 해결당으로는 더 쌀 수 있어요. 추론 모델의 사고 토큰까지 따지려면 추론 모델 effort 비용 글의 계산을 더하면 돼요.
지연 계산 — 순차 왕복 수로 어림하기
가격표에는 지연 수치가 없어서 구조별로 순차 왕복 수를 세고, 한 번의 시간은 우리 환경에서 재야 해요. 루프의 지연은 대략 n × (모델 응답 시간 + 도구 실행 시간)이에요. 예를 들어 응답 6초, 도구 3초라고 가정하면 12단계는 1분 48초, 21단계는 3분 9초, 40단계는 6분이에요. 이 가정값은 예시일 뿐이니 실제 p50·p95 로 바꿔 넣으세요.
- 한 번 생성은 왕복 1회라 IDE 자동완성이나 PR 리뷰 코멘트처럼 사람이 기다리는 자리에 맞아요.
- 고정 파이프라인은 단계 수만큼 순차이지만 단계 안의 샘플은 동시에 보낼 수 있어요. 기다리지 않아도 되는 배치라면 Batch API로 입력·출력 50% 할인을 받을 수 있어요.
- 도구 호출 루프는 다음 단계가 앞 단계 결과에 달려 있어서 병렬화가 거의 안 되고 Batch API 도 맞지 않아요. 지연을 줄이는 손잡이는 단계 수와 도구 실행 시간이에요. 테스트 전체 대신 관련 테스트 파일만 돌리게 하면 단계마다 도구 시간이 줄어요.
상황별 추천
| 상황 | 추천 구조 | 이유 |
|---|---|---|
| 에러 위치가 스택 트레이스로 정해진 한 줄 수정 | 한 번 생성 | 왕복 1회, 과제당 수 센트 |
| 같은 종류 작업 수백 건 (의존성 올리기, 린트 일괄 수정) | 고정 파이프라인 + Batch API | 비용 상한이 미리 정해지고 할인 가능 |
| 원인을 모르는 버그, 여러 파일 수정 | 도구 호출 루프 | 재현·수정·재확인을 모델이 반복 |
| 테스트가 없거나 실행 환경을 격리 못 함 | 루프 보류, 환경부터 | 검증 없는 루프는 비용만 늘어요 |
| 외부 이슈·PR 본문을 읽는 에이전트 | 루프 + 권한 축소 | 인젝션 대응은 프롬프트 인젝션 방어 비교 글 참고 |
코딩 에이전트 도입 체크리스트
- 실행 환경 격리 — 컨테이너나 VM 안에서 돌리고, 비밀값·네트워크는 꼭 필요한 것만 열었나요?
- 검증 수단 — 실패를 재현할 테스트가 있고, 에이전트가 테스트 파일을 고치지 못하게 막았나요?
- 단계 상한·예산 — 과제당 최대 단계와 달러 상한을 정하고, 넘으면 사람에게 넘기나요?
- 관찰 상한 — 파일 읽기 줄 수, 검색 결과 건수, 로그 길이를 도구가 자르나요?
- 캐시 — 자동 캐시를 켜고, 응답의
cache_read_input_tokens가 단계마다 늘어나는지 확인했나요? - 컨텍스트 정리 — 쓴다면 문턱을 관찰 크기의 10배 이상으로, 한 번에 크게 비우나요?
- 해결당 비용 측정 — 우리 저장소 과제 20~30개로 성공률·평균 단계·비용을 쟀나요?
- 로그 보존 — 메시지 배열 전체를 저장해 실패한 궤적을 다시 볼 수 있나요?
자주 묻는 질문
코딩 에이전트 과제 하나에 보통 얼마가 드나요?
이 글의 예시 조건(Sonnet 5.5, 21단계, 관찰 1,500토큰)에서 캐시를 켜면 약 0.2달러, 끄면 약 0.95달러예요. 단계 수와 관찰 크기에 따라 몇 배씩 달라지니 실제 과제로 평균을 재서 같은 식에 넣으세요.
프롬프트 캐시만 켜면 따로 할 일이 없나요?
캐시는 앞부분이 그대로일 때만 맞아요. 대화 중간의 관찰을 매 단계 지우거나 요약하면 그 지점부터 다시 써야 해서, 이 글의 예시에서는 비용이 2배 넘게 올랐어요. 테스트가 5분 넘게 걸려 캐시가 만료되는 경우도 확인하세요.
오래된 도구 결과는 지우는 게 좋나요, 남기는 게 좋나요?
비용만 보면 캐시를 켠 채 전부 남기는 쪽이 싸고, 창이 커지는 게 문제예요. 창이 차는 과제가 있다면 문턱을 넘을 때 크게 한 번 비우는 방식이 비용을 거의 늘리지 않아요. 품질 영향은 모델마다 달라서 우리 과제로 비교해야 해요.
싼 모델로 여러 번 돌리는 게 비싼 모델 한 번보다 나은가요?
해결당 비용으로 비교해야 답이 나와요. 싼 모델이 실패할 때 단계 상한까지 길게 헤매면 실패 비용이 커지고, Haiku 5.5 는 프롬프트가 10만 토큰을 넘으면 단가가 다섯 배가 돼요. 성공률·평균 단계를 재서 해결당 비용 식에 넣어 보세요.
SWE-bench 점수로 에이전트를 고르면 되나요?
참고는 되지만 그대로 고르면 안 돼요. 판본마다 과제 집합이 다르고, 같은 하네스도 모델에 따라 점수가 크게 달라져요. Anthropic 글에서 같은 하네스로 Claude 3 Opus 는 22%, 업그레이드한 Claude 3.5 Sonnet 은 49%였어요. 우리 저장소 과제로 잰 해결률과 비용이 더 믿을 만해요.
정리
- 구조는 고칠 위치를 아는지, 단계가 늘 같은지, 검증 환경이 있는지 순서로 골라요. 셋 다 아니면 도구 호출 루프예요.
- 루프 비용은 단계 수의 제곱으로 커져서 프롬프트 캐시가 첫 번째 절감이고(예시 0.945→0.201달러), 도구 관찰 자르기가 두 번째예요.
- 컨텍스트 정리는 문턱에서 크게 한 번. 매 단계 조금씩 지우면 캐시가 깨져 비용이 2배를 넘어요.
- 비교 단위는 해결당 비용이고, 실패가 길게 끌수록 비싸니 단계 상한과 사람 이관 규칙을 먼저 정해요.
도구 정의를 MCP 서버로 돌릴지 함수 호출로 직접 붙일지는 MCP 도입 판단표 글에서 이어서 볼 수 있어요.
더 깊이 읽기
이 글은 실무에서 판단할 때 필요한 것 위주로 정리했어요. 같은 주제의 내부 동작 원리는 devboi 기술 블로그의 AI 코딩 에이전트 원리 — 도구 호출 루프와 SWE-agent에서 도식과 코드로 단계별로 풀었어요.