로컬 AI 에이전트 운영법: 클라우드 모델과 Gemma 로컬 모델을 안전하게 나누는 기준

로컬 AI 에이전트를 도입할 때 가장 흔한 실수는 “보안 때문에 전부 로컬로 돌리자”는 결론을 너무 빨리 내리는 것이다. 로컬 모델은 코드 반출과 API 비용 문제를 줄여주지만, 모든 작업에 적합한 것은 아니다. 클라우드 모델은 여전히 계획 수립, 복잡한 추론, 외부 지식 활용에서 강하고, 로컬 모델은 반복 작업, 민감 코드 처리, 테스트 루프에 강하다.

Google Antigravity SDK의 로컬 모델 지원 발표는 이 분업 구조를 잘 보여준다. 클라우드 모델이 파일명과 작업 설명만 보고 전략을 세우고, 로컬 Gemma 4 26B 인스턴스가 코드 감사와 패치, 테스트 반복을 수행하는 패턴이다. 이 글은 개발팀이 비슷한 구조를 설계할 때 쓸 수 있는 운영 기준을 정리한다.

키워드는 “로컬 AI 에이전트”, “오프라인 코딩 에이전트”, “Gemma 로컬 모델”, “AI 코드 보안”이다. 실무자가 필요한 것은 설치 명령보다 어떤 작업을 어디에 배치할지에 대한 기준이다.

작업을 민감도와 추론 난이도로 나눈다

첫 번째 기준은 민감도다. 고객 데이터, 사내 비공개 코드, 보안 취약점, 인프라 구성 파일, API key가 섞인 로그는 외부 API로 보내기 어렵다. 이런 작업은 로컬 모델 후보가 된다.

두 번째 기준은 추론 난이도다. 새 아키텍처 설계, 모호한 요구사항 해석, 대규모 트레이드오프 판단은 큰 클라우드 모델이 더 나을 수 있다. 반대로 정해진 테스트를 반복 실행하고, lint 오류를 고치고, 작은 패치를 여러 번 검증하는 일은 로컬 모델도 충분히 처리할 수 있다.

간단한 매트릭스는 이렇다.

• 민감도 높음 + 반복 작업: 로컬 모델 우선
• 민감도 높음 + 고난도 설계: 클라우드에는 요약·파일명만 제공, 실행은 로컬
• 민감도 낮음 + 고난도 추론: 클라우드 모델 우선
• 민감도 낮음 + 반복 작업: 비용과 속도 기준으로 선택

이 기준을 팀 문서로 남겨야 한다. 그렇지 않으면 개발자마다 다른 판단을 하게 된다.

클라우드 모델에는 원본 코드 대신 작업 지도만 준다

하이브리드 패턴의 핵심은 클라우드 모델에 모든 코드를 주지 않는 것이다. 파일명, 모듈 역할, 테스트 실패 요약, 에러 메시지에서 민감 값을 제거한 정보만 제공한다. 클라우드 모델은 “어떤 순서로 조사할지”, “어떤 테스트를 돌릴지”, “어떤 위험을 봐야 할지”를 계획한다.

로컬 모델은 그 계획을 받아 실제 파일을 읽고 수정한다. 이렇게 하면 클라우드 모델의 강한 계획 능력을 쓰면서도 원본 코드는 로컬에 둘 수 있다.

예시는 다음과 같다.

1. 클라우드 모델에 auth.py, billing.py, database.py라는 파일명과 “환불 취약점 점검”이라는 목표만 준다.
2. 클라우드 모델이 점검 순서와 테스트 전략을 만든다.
3. 로컬 모델이 각 파일을 읽고 취약점 후보를 찾는다.
4. 로컬 모델이 패치를 만들고 테스트를 실행한다.
5. 최종 diff와 테스트 결과만 사람이 리뷰한다.

이 방식은 완전 자동화보다 느릴 수 있지만, 보안팀을 설득하기 쉽다.

로컬 실행 환경은 샌드박스가 필요하다

로컬에서 실행한다고 해서 아무 권한이나 줘도 되는 것은 아니다. 로컬 에이전트는 오히려 개발자 머신의 파일 시스템과 쉘에 가깝다. 잘못 설정하면 홈 디렉터리, SSH key, 환경변수, 브라우저 프로필까지 접근할 수 있다.

기본 원칙은 좁은 workspace다. 에이전트가 읽고 쓸 수 있는 경로를 작업 디렉터리로 제한한다. 테스트 실행 명령도 allowlist로 시작한다. 네트워크 접근은 기본 차단하고, 패키지 설치나 문서 조회가 필요할 때만 열어야 한다.

권장 설정은 다음과 같다.

• 작업별 임시 workspace 생성
• secrets가 포함된 .env, credential 파일 제외
• rm, curl, ssh, git push 같은 명령은 기본 차단
• 테스트 명령은 pytest, npm test, go test처럼 명시적으로 허용
• 생성 파일과 수정 파일 목록을 매 단계 기록
• diff가 생기면 사람 승인 전에는 커밋하지 않음

로컬 모델의 장점은 데이터가 외부로 나가지 않는 것이다. 하지만 로컬 내부에서 사고가 나지 않게 막는 장치는 별도로 필요하다.

성능 평가는 토큰이 아니라 처리 시간으로 한다

클라우드 LLM에서는 토큰 비용이 주요 지표다. 로컬 모델에서는 GPU 점유, 메모리, 대기 시간이 중요하다. 토큰 비용이 0원이어도 개발자가 20분을 기다리면 생산성은 떨어진다.

파일럿에서는 같은 작업을 클라우드, 로컬, 하이브리드로 나눠 측정해야 한다. 예를 들어 작은 버그 수정 10건, 테스트 실패 복구 10건, 보안 점검 5건을 선정한다. 각 방식에 대해 다음을 기록한다.

• 첫 응답까지 걸린 시간
• 전체 완료 시간
• 사람이 수정한 후처리 시간
• 테스트 통과율
• 잘못 수정한 파일 수
• 외부로 전송된 민감 정보 여부
• GPU 메모리 사용량

이 수치가 있어야 “로컬이 안전해서 좋다”를 넘어 운영 판단을 할 수 있다.

팀 도입 체크리스트

• 작업을 민감도와 추론 난이도로 분류했는가
• 클라우드 모델에 보낼 수 있는 정보와 보낼 수 없는 정보를 문서화했는가
• 로컬 모델용 workspace를 작업별로 격리하는가
• secrets 파일과 홈 디렉터리 접근을 차단했는가
• 허용 명령 allowlist를 만들었는가
• 로컬 모델 로그에 민감 데이터가 남지 않는지 확인했는가
• 클라우드, 로컬, 하이브리드 방식의 완료 시간을 비교했는가
• 사람 리뷰 전 자동 커밋·푸시를 막았는가
• GPU 장비를 개인 장비로 둘지 팀 공용 노드로 둘지 결정했는가
• 실패 시 클라우드 모델로 fallback할 기준을 정했는가

로컬 AI 에이전트의 목표는 클라우드를 없애는 것이 아니다. 민감하고 반복적인 실행을 로컬로 옮기고, 큰 모델은 필요한 곳에만 쓰는 것이다. 이 기준이 있어야 비용, 보안, 속도를 동시에 관리할 수 있다.

작은 파일럿부터 시작하는 순서

첫 실험은 큰 리팩터링보다 작고 반복 가능한 작업이 좋다. 예를 들어 실패한 테스트 하나를 고치거나, 의존성 업데이트 후 깨진 타입 오류를 수정하거나, 보안 스캐너가 지적한 단일 파일 취약점을 고치는 식이다. 작업 전에는 입력 파일, 허용 명령, 종료 조건을 명확히 정한다. 작업 후에는 로컬 모델이 만든 diff, 실행한 명령, 실패 로그를 사람이 리뷰한다.

이 과정을 10회 정도 반복하면 팀에 맞는 기준이 보인다. 어떤 작업은 로컬 모델이 충분하고, 어떤 작업은 클라우드 모델의 설계가 필요하며, 어떤 작업은 아직 사람이 직접 해야 한다. 도입 성공 여부는 모델 이름보다 이 분류표를 빨리 만드는 데 달려 있다.