로컬 코드 에이전트 운영법: 24GB 장비에서 프라이버시와 비용을 잡는 구조

로컬 코드 에이전트는 “인터넷 없이 AI 코딩을 한다”는 낭만적인 이야기보다 훨씬 실무적인 주제다. 회사 코드가 외부로 나가면 안 되거나, 클라우드 LLM 비용이 커졌거나, 네트워크가 제한된 환경에서도 반복 작업을 자동화해야 할 때 필요해진다.

구글이 Antigravity SDK의 로컬 모델 지원을 발표하면서 24GB 이상 VRAM 또는 unified memory 기준을 언급했다. 이 기준은 로컬 에이전트가 장난감에서 운영 후보로 넘어왔다는 신호다. 하지만 장비만 준비한다고 성공하지 않는다. 로컬 모델은 느릴 수 있고, 클라우드 상위 모델보다 판단력이 낮을 수 있으며, 파일 수정 권한을 잘못 주면 내부에서 사고를 낼 수 있다.

이 글은 개발팀이 로컬 코드 에이전트를 처음 운영할 때 필요한 구조를 정리한다. 목표는 “모든 코딩을 로컬 AI에게 맡기기”가 아니라, 민감한 코드를 외부로 보내지 않으면서 검증 가능한 반복 작업을 줄이는 것이다.

먼저 작업 유형을 나눈다

로컬 에이전트에 맡길 작업은 세 가지 기준으로 고른다. 입력 데이터가 민감한가. 결과를 자동 검증할 수 있는가. 실패해도 쉽게 롤백할 수 있는가. 세 조건을 모두 만족하면 좋은 후보가 된다.

적합한 작업은 테스트 작성, lint 수정, 문서 초안, migration script 초안, dependency update 영향 조사, 단순 리팩터링이다. 이 작업들은 결과를 diff와 테스트로 확인할 수 있다. 실패해도 git reset으로 되돌릴 수 있다.

부적합한 작업은 결제 로직 변경, 권한 정책 변경, 보안 설정 완화, 데이터 삭제 스크립트 실행, 프로덕션 배포다. 이런 작업은 로컬 모델 여부와 무관하게 사람 승인과 별도 게이트가 필요하다. 에이전트가 “문제를 찾았다”고 말해도, 실제 변경은 리뷰와 테스트를 거쳐야 한다.

하이브리드 구조가 현실적이다

가장 안정적인 구조는 cloud planner와 local worker를 나누는 방식이다. planner는 큰 모델을 써서 요구사항을 분해하고 실행 계획을 만든다. 이때 소스코드 전문을 보내지 않는다. 파일명, 에러 메시지 요약, 테스트 이름, 모듈 설명 정도만 전달한다.

local worker는 실제 레포를 읽고 수정한다. 로컬 모델은 파일 내용을 보고 후보 패치를 만든다. 테스트를 실행하고 실패하면 다시 수정한다. 이 계층은 모델 성능보다 실행 권한 통제가 중요하다.

마지막으로 deterministic gate가 있어야 한다. 타입체크, unit test, integration test, static analysis, secret scan을 통과해야 성공으로 본다. 모델의 자연어 보고는 참고 자료일 뿐이다. “완료했습니다”라는 문장과 실제 성공은 다르다.

워크스페이스 권한을 좁힌다

로컬이니까 안전하다는 말은 반만 맞다. 데이터가 외부로 나가지 않는다는 장점은 있지만, 로컬 파일을 망가뜨릴 권한도 생긴다. 따라서 에이전트에게 전체 홈 디렉터리를 주면 안 된다.

작업별 임시 workspace를 만든다. 필요한 repo만 checkout한다. .env, credentials, production dump는 제외한다. 네트워크 접근도 기본 차단하고, package install이 필요한 경우만 allowlist로 연다. shell command는 테스트, 빌드, formatter 중심으로 제한한다.

파일 쓰기도 단계적으로 허용한다. 처음에는 read-only 분석을 돌리고, 다음에는 branch에서만 수정한다. main 또는 develop에는 직접 쓰지 않는다. PR diff로 결과를 남기고, 사람이 확인한 뒤 merge한다. 이 흐름을 지키면 에이전트 실패가 레포 손상으로 이어질 가능성이 줄어든다.

24GB 장비에서 기대치를 조절한다

24GB급 장비는 로컬 에이전트의 시작점이지 만능 환경이 아니다. 26B급 모델은 돌아가더라도 속도가 느릴 수 있다. 긴 컨텍스트, 여러 파일 동시 수정, 복잡한 설계 판단은 클라우드 모델보다 답답할 수 있다.

따라서 처음에는 작은 batch로 시작한다. 파일 1~3개, 테스트 1개, 제한 시간 10분 같은 식이다. 성공률을 측정하고 점차 늘린다. 긴 작업을 한 번에 맡기면 실패 원인을 분리하기 어렵다.

성능 측정도 token 속도만 보면 안 된다. 실제 지표는 task success rate, 평균 수정 횟수, 테스트 통과율, 사람 리뷰 시간, rollback 비율이다. 모델이 빠르게 출력해도 리뷰가 오래 걸리면 생산성은 떨어진다. 반대로 느리더라도 사람이 안 해도 되는 반복 작업을 안정적으로 처리하면 가치가 있다.

비용 계산은 총소유비용으로 한다

로컬 모델은 API 비용이 없거나 적다. 하지만 장비 가격, 전력, 모델 관리, 드라이버 문제, 캐시 저장공간, 운영자 시간을 포함해야 한다. 팀원이 각자 고사양 장비를 사는 것보다 공유 GPU 워크스테이션 하나를 두는 편이 나을 수도 있다.

작은 스타트업은 클라우드 API로 시작하고, 민감하거나 반복적인 작업만 로컬로 빼는 편이 현실적이다. 대기업이나 규제 산업은 반대로 로컬을 기본으로 두고, 허가된 범위에서만 클라우드 planner를 쓰는 편이 맞다.

비용 절감 목표도 구체화해야 한다. “LLM 비용 절감”이 아니라 “월 1,000건의 테스트 보강 작업 중 60%를 로컬로 처리해 API 비용과 리뷰 시간을 줄인다”처럼 잡아야 한다. 그래야 로컬 환경 구축 비용을 비교할 수 있다.

실패를 전제로 로그를 남긴다

에이전트 운영에서 가장 위험한 실패는 조용한 실패다. 테스트가 실제로는 안 돌았는데 성공했다고 보고하거나, 일부 파일만 수정하고 전체 문제를 해결했다고 말하는 경우다. 그래서 모든 실행은 로그와 artifact를 남겨야 한다.

필수 로그는 입력 요청, 사용 모델, workspace 경로, 허용된 명령, 실행한 명령, 변경 파일 목록, 테스트 결과, 최종 diff다. 민감정보는 마스킹해야 한다. 특히 환경변수와 토큰이 프롬프트나 로그에 섞이지 않도록 해야 한다.

실패 유형도 분류한다. 모델 판단 실패, 명령 실행 실패, 테스트 실패, 권한 실패, 시간 초과, 리뷰 반려로 나눈다. 이 분류가 있어야 다음 개선이 가능하다. 단순히 “로컬 모델이 별로다”로 끝내면 어떤 부분을 바꿔야 할지 모른다.

팀에 도입하는 순서

1단계는 shadow mode다. 사람이 할 작업을 로컬 에이전트에게도 시켜보고, 결과는 적용하지 않는다. 사람 결과와 diff를 비교한다. 2단계는 draft mode다. 에이전트가 branch에 변경을 만들지만 merge는 사람이 한다. 3단계는 bounded autopilot이다. 특정 폴더, 특정 명령, 특정 작업 유형에서만 자동 PR을 만들게 한다.

처음부터 “자율 개발자”처럼 운영하면 실패한다. 로컬 에이전트는 팀의 junior automation으로 봐야 한다. 반복 작업을 맡기되, 권한과 검증은 시스템이 관리한다.

실행 체크리스트

• 입력 민감도, 자동 검증 가능성, 롤백 가능성으로 작업을 선별한다.
• cloud planner와 local worker를 분리한다.
• planner에는 파일 본문 대신 최소 메타데이터만 전달한다.
• 에이전트 workspace를 작업별로 만들고 전체 홈 디렉터리를 주지 않는다.
• .env, credentials, production dump는 workspace에서 제외한다.
• shell command는 테스트, 빌드, formatter 중심으로 allowlist 처리한다.
• 성공 기준은 모델 답변이 아니라 테스트와 정적분석 결과로 둔다.
• 1~3개 파일 단위의 작은 작업부터 시작한다.
• task success rate, 리뷰 시간, rollback 비율을 측정한다.
• shadow mode → draft mode → bounded autopilot 순서로 확장한다.