로컬 코딩 에이전트 전환, 토큰 속도 대신 멈춤 시간과 복구 비용으로 비교하는 법

코딩 에이전트의 API 호출을 로컬 모델로 바꾸려 할 때, 팀은 대개 모델 벤치마크부터 확인한다. 노트북에서 초당 몇 토큰을 생성하는지 보고 “이 정도면 쓸 수 있겠다”고 판단하기 쉽다. 그러나 개발자가 체감하는 시간은 생성 속도만으로 정해지지 않는다.

에이전트는 답을 쓰기 전에 시스템 지시문, 도구 정의, 대화 이력, 저장소 정보 등을 읽는다. 로컬 환경에서는 이 입력을 읽는 시간, 즉 프리필(prefill)이 무시하기 어렵다. 도구 호출이 겹치거나 컨텍스트가 자주 초기화되면, 모델이 답을 생성하는 동안이 아니라 준비하는 동안 개발자가 기다리게 된다.

따라서 로컬 코딩 에이전트 전환 여부는 “로컬 모델이 클라우드 모델보다 빠른가”가 아니라 “우리 팀의 반복 작업을 중단 없이 끝낼 수 있는가”로 판단해야 한다. 초기 도입 대상도 전체 개발 업무가 아니라, 입력 범위와 검증 방법이 분명한 작업부터 잡는 편이 안전하다.

토큰 생성 속도와 작업 완료 시간은 다른 지표다

생성 속도는 모델이 답변을 쓰기 시작한 뒤의 처리량을 보여준다. 반면 개발자가 기다리는 시간에는 다음 과정이 함께 들어간다.

• 첫 요청 전에 시스템 프롬프트와 도구 스키마를 읽는 시간
• 각 도구 호출 뒤 변경된 파일, 명령 실행 결과, 대화 이력을 다시 읽는 시간
• 자동 요약, 세션 제목 생성, 상태 갱신처럼 본 작업과 직접 관련 없는 백그라운드 요청의 대기 시간
• 실패한 명령이나 잘못된 수정 뒤에 사람이 개입해 방향을 바로잡는 시간
• 컨텍스트 부족으로 세션을 나누거나 이전 내용을 다시 설명하는 시간

예를 들어 로컬 모델이 입력을 초당 90토큰가량 읽는 조건이라면, 에이전트의 초기 프롬프트가 1,000토큰 늘어날 때마다 첫 응답 전 대기가 약 11초 늘어날 수 있다. 데이터센터 GPU에서는 거의 느껴지지 않던 프롬프트 차이가 노트북 환경에서는 1분 이상의 차이로 커질 수 있다는 뜻이다.

공개 비교 실험에서도 같은 로컬 모델과 같은 서버를 공유한 환경에서, 첫 요청 프롬프트가 약 2,000토큰인 하니스와 약 18,000토큰인 하니스 사이에 첫 응답 대기가 약 20초대와 220초대까지 벌어졌다. 이 결과를 모든 장비와 모델에 일반화할 수는 없다. 다만 하니스의 프롬프트 설계와 도구 수가 로컬 사용 경험을 좌우한다는 점은 평가 항목으로 삼을 만하다.

로컬 전환 검토표에는 초당 생성 토큰 대신 아래 세 시간을 우선 넣는 편이 낫다.

비교 항목	확인할 질문	로컬 환경에서 중요한 이유
첫 응답 대기	지시 후 첫 텍스트나 첫 도구 호출까지 몇 초가 걸리는가	짧은 수정도 시작이 늦으면 개발자가 흐름을 잃는다
후속 턴 대기	파일 확인과 명령 실행 뒤 다시 답하기까지 얼마나 멈추는가	에이전트 작업은 한 번의 답변보다 여러 번의 왕복으로 끝난다
작업 총 소요 시간	요청부터 테스트 통과, 검토 가능한 패치 제출까지 얼마나 걸리는가	생성 속도가 빨라도 도구 충돌과 재시도가 많으면 이득이 사라진다
사람 개입 시간	개발자가 프롬프트를 보정하거나 실패를 복구한 시간이 얼마인가	자동화 시간이 아니라 개발자 집중 시간을 줄여야 한다

하니스의 설계가 로컬 모델의 체감 성능을 바꾼다

같은 모델을 쓰더라도 에이전트 하니스, 즉 모델에 도구를 제공하고 대화를 관리하며 명령을 실행하는 프로그램의 설계에 따라 결과가 크게 달라질 수 있다.

첫 번째 비교 축은 초기 프롬프트와 도구 정의의 크기다. 많은 도구를 제공하면 에이전트가 할 수 있는 일은 늘어난다. 브라우저, 원격 저장소, 이슈 트래커, 배포 시스템까지 연결하는 하니스라면 풍부한 도구가 필요할 수도 있다. 하지만 도구마다 설명과 인자 형식이 프롬프트에 들어가면, 로컬 모델은 매 작업 시작 때 그 비용을 읽어야 한다.

두 번째는 프리픽스 캐시 재사용률이다. 프리픽스 캐시는 이전 턴에서 이미 읽은 시스템 프롬프트와 대화 앞부분을 다시 계산하지 않도록 보관하는 기능이다. 시스템 지시문에 매번 바뀌는 시간값, 세션 정보, 동적 상태를 넣으면 앞부분이 달라져 캐시를 재사용하기 어렵다. 반대로 초기 지시문과 도구 정의가 안정적으로 유지되면 후속 턴의 대기 시간을 줄일 여지가 생긴다.

세 번째는 동시 요청 정책이다. 클라우드 API는 여러 요청을 병렬로 보내도 서버 자원이 처리할 수 있다. 노트북 한 대에서 모델 추론과 에이전트 실행을 함께 돌릴 때는 상황이 다르다. 작업 도중 세션 요약, 제목 생성, 추가 분석 요청이 동시에 들어오면 단일 GPU 또는 통합 메모리 자원을 서로 기다릴 수 있다. 사용자는 모델이 멈춘 것으로 느끼지만, 원인은 모델 품질이 아니라 요청 큐일 수 있다.

네 번째는 모델 서버와 하니스의 결합 방식이다. 일반적인 클라이언트와 서버 분리 구조는 운영과 교체에 유리하다. 반면 로컬 전용 환경에서는 하니스가 캐시와 추론 순서를 더 직접 관리하는 방식이 대기 시간을 줄일 가능성이 있다. 다만 이 선택은 특정 하니스와 런타임에 의존할 수 있으므로, 속도만 보고 표준 구조를 포기해서는 안 된다. 디버깅, 업데이트, 보안 패치, 팀 배포 난이도까지 같이 비교해야 한다.

처음부터 대형 기능 개발에 투입하지 말아야 하는 이유

로컬 에이전트는 모든 업무에 같은 가치를 내지 않는다. 특히 탐색 범위가 넓고 외부 시스템을 많이 호출하며 긴 맥락을 유지해야 하는 작업은 작은 컨텍스트 창과 느린 프리필의 영향을 크게 받는다.

첫 검증 대상으로는 다음 조건을 갖춘 작업이 적합하다.

• 수정할 저장소와 모듈 범위가 비교적 명확하다.
• 테스트, 린트, 정적 분석처럼 완료 여부를 기계적으로 확인할 수 있다.
• 외부 SaaS나 운영 데이터에 접근하지 않아도 된다.
• 실패해도 사람이 짧은 시간 안에 되돌릴 수 있다.
• 반복 빈도가 있어 같은 조건에서 여러 번 비교할 수 있다.

예를 들면 테스트 실패 원인 정리, 제한된 모듈의 타입 오류 수정, 문서와 코드의 불일치 탐지, 정해진 규칙에 따른 테스트 코드 초안 작성 등이 후보가 될 수 있다. 반면 여러 서비스에 걸친 장애 대응, 제품 요구사항이 아직 흔들리는 기능 설계, 권한이 필요한 운영 변경은 초기 검증 과제로 적합하지 않을 수 있다. 이 작업들은 모델의 응답 품질뿐 아니라 최신 정보 접근, 협업 맥락, 승인 절차가 결과를 좌우한다.

평가할 때는 에이전트에게 한 문장 지시만 주고 끝내지 말고, 팀이 실제로 받는 티켓 또는 PR 유형을 익명화해 사용해야 한다. 공개 코딩 문제의 통과율은 기본 능력을 확인하는 데는 도움이 되지만, 사내 코드베이스에서의 탐색 비용과 빌드 시간, 규칙 준수 여부까지 대신 보여주지는 못한다.

전환 실험에서는 성공률보다 중단 패턴을 기록한다

파일을 수정하고 테스트를 통과한 비율은 중요한 결과다. 그러나 로컬 도입의 초기 실험에서 더 먼저 봐야 할 것은 어디서 작업이 멈췄는지다. 실패 위치를 분류하면 모델을 바꿔야 하는지, 하니스를 바꿔야 하는지, 작업 범위를 줄여야 하는지 구분할 수 있다.

다음 신호가 반복되면 전환 범위나 구성부터 다시 점검하는 편이 좋다.

조기 신호	가능한 원인	다음 조치
첫 응답 전 대기가 길다	긴 시스템 프롬프트, 과도한 도구 스키마, 느린 입력 처리	도구 수가 적은 구성과 비교하고 초기 프롬프트 크기를 측정한다
초반에는 빠르지만 중간부터 멈춘다	컨텍스트 증가, 캐시 미사용, 백그라운드 요청 경합	턴별 대기 시간과 캐시 재사용 여부를 기록한다
모델이 작업을 자주 잊는다	남은 컨텍스트 부족, 요약 품질 저하	작업 단위를 줄이고 세션 분할 기준을 정한다
테스트는 통과하지만 검토 시간이 길다	변경 범위 과다, 프로젝트 규칙 미반영	허용 파일 범위와 수정 금지 영역을 프롬프트와 정책으로 제한한다
로컬 장비가 개발 환경을 방해한다	모델 추론, IDE, 빌드가 메모리와 연산 자원을 경쟁	에이전트 실행 시간대, 전용 장비, 원격 개발 환경을 비교한다

여기서 중요한 것은 실패를 숨기지 않고 로그로 남기는 일이다. 요청 시각, 첫 토큰 또는 첫 도구 호출 시각, 각 도구 실행 시간, 재시도 횟수, 테스트 결과, 사람의 개입 내용을 한 작업 단위로 기록하면 병목을 찾을 수 있다. 모델 출력만 저장하면 “품질이 낮았다”는 결론밖에 남지 않는다.

로컬 전환은 모델 교체가 아니라 운영 경로를 바꾸는 일이다

CTO나 개발 리드는 먼저 로컬 전환의 목표를 한 가지로 좁혀야 한다. 코드와 프롬프트를 외부로 보내지 않으려는 것인지, API 사용량을 낮추려는 것인지, 네트워크 연결 없이도 개발 보조를 쓰려는 것인지에 따라 허용할 수 있는 지연과 운영 비용이 달라진다.

그다음에는 같은 작업 세트를 클라우드 구성과 로컬 구성에서 실행하고, 다음 기준으로 비교할 수 있다.

1. 개발자가 첫 결과를 보고 방향을 판단할 때까지 걸린 시간
2. 한 작업을 완료하거나 중단할 때까지의 총 경과 시간
3. 테스트 통과와 코드 검토 가능 상태에 도달한 비율
4. 개발자가 개입한 횟수와 개입 사유
5. 모델 실행이 IDE, 빌드, 컨테이너 등 기존 개발 환경에 준 영향
6. 장비 구매, 전력, 관리, 업데이트를 포함해 팀이 감당할 운영 부담

이 비교에서 로컬 구성이 모든 항목에서 클라우드보다 좋아야 할 필요는 없다. 민감한 저장소에서는 로컬을 우선 사용하고, 긴 맥락과 폭넓은 도구 사용이 필요한 작업은 원격 모델을 쓰는 식의 분리가 더 현실적일 수 있다. 중요한 것은 “로컬 모델을 쓸 수 있는가”가 아니라, 어떤 작업에서 대기와 복구 비용을 감수할 만한 이점이 생기는지 확인하는 일이다.

전환 실험의 첫 산출물도 모델 선정표가 아니라 작업 라우팅 규칙이어야 한다. 어떤 티켓은 로컬 에이전트에 맡기고, 어떤 티켓은 클라우드 모델 또는 사람에게 바로 넘길지 정해 두면, 팀은 속도 수치가 아니라 개발 흐름을 기준으로 도입 범위를 넓힐 수 있다.