Kilo Code는 몇 분 만에 형식이 올바른 패치(patch)를 생성할 수 있습니다. 그 이후에는 더 비용이 많이 드는 두 번째 작업 단계가 시작됩니다. 사람이 side-by-side diff를 열어 미완성된 수정을 찾아내고, 스냅샷(snapshot)을 되돌린 뒤 코드의 일부를 수동으로 다시 작성하는 과정입니다. 에이전트는 빠르게 작업을 수행했지만, 결국 리뷰어(reviewer)가 작업을 마무리했습니다. diff 자동 생성(auto-generation)이 약속하는 시간 절약은, diff를 검토하는 과정에서 사람이 두 배의 비용을 들여 다시 작업해야 하는 상황이 발생하지 않을 때에만 실질적입니다.

다음은 제품에 대한 리뷰가 아닌 측정 방법에 대한 내용입니다. Kilo Code의 각 diff를 수락하는 데 비용이 얼마나 드는지, 그리고 어느 임계값(threshold)에서 에이전트 워크플로우(agentic workflow)를 확장하는 것이 정당화되는지를 계산하는 방법입니다. 메트릭(metric)은 생성 속도에서 수락 비용(cost of acceptance)으로 전환되어야 하며, 이를 위해 파일럿 로그(pilot log)에는 구체적인 필드와 의사결정 규칙이 필요합니다.

먼저 한계를 명확히 하겠습니다. 아래의 Kilo Code 메커니즘은 2026년 7월 18일 기준 공식 문서에서 가져온 것입니다. 로그 스키마(schema), 수정 비용 공식, 그리고 모든 수치적 임계값은 저자의 독자적인 방법론이며 Kilo Code 문서의 용어가 아닙니다. 특정 팀에 대한 준비된 측정값은 여기에 없으며, 존재할 수도 없습니다. 그러한 값은 오직 자체적인 파일럿(pilot)을 통해서만 얻을 수 있습니다.

첫 번째 diff의 속도는 생산성의 지표가 아니다

일반적인 기본 통념은 다음과 같습니다: 에이전트가 diff를 더 빨리 내놓을수록 더 낫다는 것입니다. 이는 잘못된 메트릭입니다. 왜냐하면 이는 모델의 성능을 측정하는 것이지, 팀의 생산성을 측정하는 것이 아니기 때문입니다. "diff 생성"과 "diff가 메인 브랜치(main branch)에 수락됨" 사이에는 사람이 존재하며, 모델의 시간이 아닌 사람의 시간이 파일럿 예산에서 가장 비싼 항목입니다.

Kilo Code 자체 문서에서도 이러한 축(axes)들을 구분하고 있습니다. 비용 및 제한 사항에 관한 공식 가이드(2026년 7월 18일 기준)에 따르면, 절약의 핵심 동력은 속도의 향상이 아니라 작업 목적에 맞는 Auto Model 수준의 선택이라고 명시되어 있습니다. 즉, 복잡한 작업을 위한 Frontier, 기본적으로 예측 가능한 비용을 위한 Balanced, 그리고 정확도 임계값을 통과하는 가장 저렴한 모델을 통한 자동 라우팅(auto-routing)을 위한 Efficient가 그것입니다. 다시 말해, Kilo Code 자체에서도 "diff를 더 저렴하고 빠르게 생성하는 것"은 결과의 적절한 정확성과 일치하지 않는 별개의 축입니다.

여기에서 파일럿 프로젝트의 속도를 늦춰야 하는 이유인 갈등이 발생합니다. 신중하고 형식적으로 안전한 diff는 검토 및 수정 비용이 너무 많이 들어 모든 절감액을 갉아먹을 수 있습니다. 권한 설정(Permissions)은 에이전트가 요청 없이 수행할 수 있는 범위를 제한하지만, 수행된 작업이 다시 작성될 필요가 없음을 보장하지는 않습니다. 이는 서로 다른 과제이며, 이 둘을 혼동해서는 안 됩니다. 사람들은 대개 속도 향상 수치를 확인하기 위해 Kilo Code AI agent를 검색하지만, 정작 중요한 질문은 따로 있습니다. 단 하나의 변경 사항을 수락하는 데 시간이 얼마나 걸리는가 하는 점입니다.

작업 로그(Task Log)에 기록해야 할 사항

로그는 에이전트가 하나의 diff를 완성할 때까지 수행한 하나의 작업이 한 행(row)이 되는 테이블입니다. 최소한 포함되어야 할 필드는 다음과 같습니다: 작업 식별자(ID), 에이전트 작업 시간, 리뷰 시간, 수정 여부 및 수정 소요 시간, 롤백(rollback) 여부, 최종 결정(수락됨, 재작성됨, 거부됨). 모든 필드에 대해 비교 가능한 기록이 없다면 이 방법은 작동하지 않으며, 이는 실패의 첫 번째 조건입니다. 두 번째 조건은 리뷰 시간을 기록하지 않으면 에이전트의 속도, 즉 우리가 피하고자 하는 바로 그 기만적인 수치만 남게 된다는 것입니다. 세 번째로, 롤백을 고려하지 않으면 가장 비용이 많이 드는 카테고리가 계산에서 누락됩니다.

제품 자체에는 각 필드에 대한 자연스러운 기준 단위가 존재합니다. 파일을 변경한 에이전트의 각 단계(move)는 요약된 diff(파일, 추가, 삭제)를 보여주며, 메시지에는 VS Code의 side-by-side 뷰어를 여는 diff 배지가 표시됩니다 (Kilo Code의 checkpoints에 관한 문서 (2026년 7월 18일 접속 참조)). 이것은 명확한 diff 요약이 포함된 에이전트의 한 단계(move)로서, 로그 라인이 작성되는 기준이 되는 구체적이고 시간과 결합된 작업 단위입니다.

이러한 측정을 위해 파일럿(pilot)의 속도를 늦추는 것은 의도된 비용입니다. 에이전트 워크플로우를 즉시 확장하는 것이 현재는 더 저렴해 보일 수 있지만, 나중에 숨겨진 비용을 확장시킵니다. 반면 첫 주 만에 중단하는 것은 우연히 발생한 잘못된 샘플링 때문에 작동하는 도구를 버리게 될 위험이 있습니다. 중간 단계의 방법은 데이터가 비교 가능해질 때까지 로그를 기록하고, 그 후에 확장을 결정하는 것입니다.

Kilo Code에 내장된 측정 단위

Kilo Gateway는 각 개별 요청의 비용과 토큰을 마이크로달러(1 USD = 1,000,000 마이크로달러) 단위까지 정확하게 기록합니다. 입력 및 출력 토큰, 캐시 토큰(cache tokens), 비용, 그리고 첫 번째 토큰 생성 시간(time-to-first-token)은 응답의 usage 필드 또는 스트리밍 시 최종 SSE 청크(SSE chunk)에 반환됩니다 (Kilo Code의 gateway usage and billing에 관한 문서 (2026년 7월 18일 접속 참조)). 이것은 파일럿 로그에서 에이전트의 시간을 표시하는 데 사용되는 바로 그 프리미티브(primitive)입니다. 즉, 숫자를 초시계로 잴 필요가 없습니다.

이 프리미티브(primitive)에는 단순한 계산을 방해하는 예외 사항이 있습니다. 만약 개발자가 자신의 프로바이더 키(BYOK: Anthropic, OpenAI, Google, Azure, AWS Bedrock 등)를 가져온다면, Kilo Code는 자체 기록된 비용을 $0로 표시하며, 개발자는 Kilo Code의 게이트웨이 사용량 및 빌링(billing) 관련 문서와 Kilo 가격 페이지 (2026년 7월 18일 접속)에 따라 업스트림(upstream)에 직접 비용을 지불합니다. 즉, BYOK 환경의 로그에서 "에이전트 시간(agent time)" 열에는 프로바이더의 토큰 빌링(token-billing)이 포함되지 않으므로 별도로 확인해야 합니다. 이 예외 사항을 간과하면 실제 비용이 체계적으로 과소평가됩니다.

로그에는 두 가지 내장 단위가 더 유용하게 사용됩니다. 스냅샷(Snapshots)은 에이전트 실행 과정 중 각 모델 호출의 시작과 끝에서 Kilo Code가 자동으로 생성하는 git 스냅샷입니다. 되돌리기("Revert to here") 기능은 작업 영역을 복구하지만, 파일이나 단계 단위가 아닌 사용자 메시지 단위의 세밀함(granularity)을 가집니다. 따라서 복구 시 작업 범위 외의 저장되지 않은 수동 수정 사항은 지워집니다 (Kilo Code Docs의 체크포인트(checkpoints) 관련 내용, 2026년 7월 18일 접속). /review 명령어는 푸시(push) 전 미전송 변경 사항, 브랜치, 커밋 또는 PR에 대해 로컬 AI 검토를 실행하며, PR/MR 이벤트에 대한 클라우드 모드도 제공합니다. 리뷰 범위는 변경된 파일로만 제한되며, 현재 제한된 베타 버전에서는 리뷰 시간 자체는 무료이지만 모델의 추론(reasoning)에는 여전히 Kilo Code 크레딧이 차감됩니다. 자세한 내용은 Kilo Code의 코드 리뷰 개요(code reviews overview) 문서(2026년 7월 18일 접속)를 참조하십시오.

하나의 diff 수정 비용 계산 방법

diff를 수락하는 비용은 리뷰 시간, 수정 시간, 그리고 롤백 (rollback) 시간의 합으로 구성됩니다. 이득(benefit)은 동일한 작업을 수동으로 수행했을 때와 비교하여 절약된 시간입니다. 이 공식은 Kilo Code의 공식 문서에 있는 것이 아닌 저자의 독자적인 공식입니다: 수락 비용 = 리뷰 + 수정 + 롤백이며, 결정은 수동 평가 − (에이전트 시간 + 수락 비용)의 차이 부호에 따라 내려집니다. 만약 안정적인 샘플 집단에서 이 차이가 마이너스로 나타난다면, 에이전트는 팀의 업무를 줄여주는 것이 아니라 오히려 리뷰어에게 업무를 전가하는 셈이 됩니다.

아래는 실제 측정 보고서가 아닌 테이블 템플릿입니다. 예시의 값들은 계산 방식을 보여주기 위한 준비된 값일 뿐, 특정 팀의 측정치나 출처의 데이터가 아닙니다. 본인의 로그에서 직접 숫자를 대입해야 합니다.

테이블 읽기 규칙: 짧은 리뷰와 수정 사항이 없는 "수락됨 (Accepted)" 행은 에이전트가 순수 이득을 가져다준 것을 의미합니다. 롤백이 포함된 "다시 작성됨 (Rewritten)" 행은 업무 전가를 의미합니다: 에이전트가 시간을 소비했지만, 결국 사람이 결과를 마무리해야 했음을 뜻합니다. "거부됨 (Rejected)" 행은 에이전트의 시간 낭비와 거부 결정을 내리는 데 소요된 시간을 의미합니다. 확정된 사실은 하나입니다: 로그를 통해 에이전트 시간, 리뷰, 수정 및 롤백 시간을 기록할 수 있다는 점입니다. 가능한 결론은 다음과 같습니다: 빠른 diff가 실제로 리뷰어에게 업무를 전가할 수도 있습니다. 솔직히 말해 알 수 없는 점은, 바로 당신의 팀이 수행하는 작업에서 Kilo Code의 비용이 얼마인지이며, 이는 어떤 출처에서도 알 수 없고 오직 자체적인 파일럿 테스트를 통해서만 확인할 수 있습니다.

만약 파일럿 프로젝트가 단일 제공자(provider)에 종속되어 있다면, 로그 변수에 채널 가용성(availability)이 추가됩니다. 가용성이 확보되지 않으면 로그상의 에이전트 시간은 diff의 품질 때문이 아니라, 일시적으로 접속 불가능한 업스트림(upstream)의 대기열 때문에 급증하게 됩니다. 안정적인 멀티채널 라우팅을 통한 모델 접근은 하나의 채널이 일시적으로 사용할 수 없을 때 요청을 계속 전달하여 이 변수를 계산에서 제외하지만, diff 자체에 대한 리뷰를 취소하지는 않습니다.

계산상의 별도 문제도 있습니다. BYOK(Bring Your Own Key) 환경에서 "에이전트 시간" 컬럼은 제공자의 빌링(billing)을 포함하지 않으며, 러시아 팀의 경우 해외 카드가 없는 상태에서의 모델 접근은 그 자체로 별도의 예산 항목이 됩니다. provod.ai는 OpenAI 및 Anthropic SDK와 호환되는 단일 API를 제공합니다. 클라이언트에서 base_url과 키만 변경하면 나머지 코드는 건드릴 필요가 없으며, 카탈로그의 모델들은 provod.ai의 추가 마진 없이 제공자의 공식 가격으로 사용할 수 있습니다. 결제는 VPN이나 해외 카드 없이 러시아 카드를 통한 루블 잔액, SBP(Fast Payment System), 또는 계좌 이체로 이루어집니다.

from openai import OpenAI

client = OpenAI(
...

모델 접근 방식을 변경한다고 해서 특정 diff의 품질이나 보안이 보장되는 것은 아닙니다. 이는 시간 예산에서 하나의 변수를 제거할 뿐이며, diff 자체는 여전히 동일한 5가지 로그 필드를 통과해야 합니다.

워크플로우를 확장해야 할 때와 멈춰야 할 때

의사결정의 임계점은 반증 가능한 명제(falsifiable thesis)입니다. 만약 리뷰 및 수정 시간이 절약된 시간으로 지속적으로 상쇄되지 않는다면, Kilo Code의 확장은 정당화되지 않습니다. 이는 에이전트의 실패를 의미하는 것이 아니라, 특정 작업에서 팀이 지불해야 하는 비용이 효용보다 높다는 사실을 확인하는 것입니다. 사전에 확정해 두어야 할 거절 기준은 다음과 같습니다: 수정 시간이 생성으로 얻는 이득을 초과하거나, 리뷰의 양이 통제 불가능해지는 경우입니다. 어떤 기준이라도 충족된다면 워크플로우를 확장하지 않고, 에이전트가 이미 이익을 보여준 곳에서만 국소적으로 사용하는 방식으로 돌아가야 합니다.

워크플로우 확장(Workflow expansion)은 로그의 문제일 뿐만 아니라 요금제와 한도(limits)의 문제이기도 합니다. VS Code용 Kilo Code 플러그인은 개인 개발자에게 무료이며 오픈 소스로 제공되어 구독이 필수적이지 않습니다. 2026년 7월 18일 기준 Kilo 가격 페이지에 명시된 유료 옵션은 다음과 같습니다: 보너스 크레딧이 포함된 Starter($월 $19), Pro($월 $49), Expert($월 $199) 단계의 Kilo Pass, 또는 사용량 분석, 채택 점수(adoption scoring), 중앙 집중식 결제 기능이 추가된 사용자당 월 $15의 Teams 플랜(14일 무료 체험 제공)이 있습니다. 무료 계층인 Kilo Gateway는 IP당 시간당 200회 요청으로 제한됩니다. 유료 계층은 게이트웨이 속도 제한(gateway rate cap)은 없으나, Kilo Code의 속도 제한 및 비용 관련 문서 (2026년 7월 18일 기준)에 따라 조직별 지출 한도가 설정되어 있습니다. Teams 분석 기능은 작업량이 너무 많아져서 리뷰어 한 명의 머릿속에 더 이상 표를 담을 수 없을 정도로 늘어난 경우, 수동 계산기를 대체할 수 있는 준비된 솔루션입니다.

최종 규칙은 간단합니다. 로그가 지속적인 양(+)의 차이를 보여주고 리뷰가 관리 가능한 범위 내에 있다면, 워크플로우를 확장하고 작업량이 증가함에 따라 수동 표 대신 Teams 분석으로 전환합니다. 만약 차이가 음(-)이거나 리뷰 범위가 통제 불능으로 늘어난다면, 확장을 중단하고 에이전트를 이미 이익을 증명한 작업 클래스에만 남겨둡니다. 결정은 첫 번째 diff의 속도가 아니라, 이를 수용하는 데 드는 누적 비용에 의해 내려집니다.