"t trust itself to perform. It could be argued that this is closer to truly"

이 문장은 단순한 정보 검색을 넘어, 모델이 자신의 실행 환경을 인식하고 신뢰할 수 없는 논리 연산을 외부 도구로 오프로딩하는 '에이전틱(Agentic)'한 동작의 핵심을 짚는다. 기존의 툴 콜링이 단순히 외부 API에서 데이터를 가져와 답변에 붙이는 수준이었다면, 이제는 모델이 스스로 머신을 조사하고 로컬 파일 시스템과 상호작용하는 단계로 진입하고 있다.

특히 이번 구현에서는 Gemma 4 제품군의 e2b 엣지 변체 모델을 활용해, 로컬 랩톱 환경에서도 안정적으로 동작하는 에이전트 루프를 구축하는 과정을 다룬다. 모델에게 샌드박스화된 로컬 파일 시스템 탐색기와 제한된 파이썬 인터프리터를 제공함으로써, 모델이 언제 주변 환경을 살펴야 하고 언제 계산을 수행해야 하는지를 스스로 결정하게 만든다. 이는 언어 모델이 가진 고질적인 문제인 산술 연산의 부정확성과 논리적 추론의 한계를 결정론적인 코드 실행으로 해결하려는 시도다.

Gemma 4 e2b 모델과 Ollama 기반의 로컬 에이전트 구성

기존의 툴 호출 에이전트가 외부 API에서 날씨나 뉴스 데이터를 가져오는 읽기 전용 챗봇에 머물렀다면, 이번 구성의 핵심은 모델이 자신이 구동되는 시스템 환경을 직접 관찰하고 제어하는 데 있다. 단순한 정보 검색을 넘어 로컬 파일 시스템을 탐색하거나 코드를 실행하는 단계로 진입하면 비로소 실무적인 에이전틱(Agentic) 특성이 나타난다. 이를 위해 로컬 LLM 실행 프레임워크인 Ollama를 통해 gemma4:e2b 모델을 서빙한다. Gemma 4 제품군의 엣지 변체인 gemma4:e2b는 노트북 수준의 로컬 환경에서도 구동 가능할 만큼 가벼우면서도, 도구 호출에 필요한 구조화된 출력 능력을 충분히 갖추고 있어 로컬 에이전트 구축에 적합한 선택지로 관찰된다.

에이전트가 환경과 상호작용하기 위해 부여되는 첫 번째 도구는 list_directory_contents다. 이 도구는 특정 폴더 내의 파일 목록을 확인하는 기능을 수행하며, 모델이 추측이 아닌 실제 파일명을 기반으로 판단하게 만든다. 다만 os.listdir와 같은 함수는 상위 디렉토리 접근을 허용하므로 보안 위험이 존재한다. 이를 방지하기 위해 스크립트 시작 시 안전한 기준 디렉토리를 고정하고, 모델이 요청한 경로가 해당 기준 경로 내에 있는지 절대 경로로 변환하여 검증하는 로직을 적용한다. 결과물은 [DIR] 또는 [FILE] 표시와 함께 바이트 크기를 포함한 문자열 형태로 반환되어 모델이 파일의 성격을 명확히 파악하게 하며, 이는 모델의 호기심이 시스템 핵심 설정 파일이나 API 키가 저장된 경로로 뻗어 나가는 것을 물리적으로 차단하는 안전장치가 된다.

두 번째 도구인 execute_python_code는 소형 모델이 취약한 정밀 연산과 복잡한 분기 로직 문제를 해결하기 위해 도입된다. 언어 모델에게 자연어로 계산을 요청하는 대신 결정론적인 파이썬 코드를 작성하고 실행하게 함으로써 결과의 신뢰도를 높이는 방식이다. 보안을 위해 __builtins__ 네임스페이스를 완전히 교체하여 open, eval, exec와 같은 위험 함수를 제거한 화이트리스트 기반의 제한된 인터프리터를 사용한다. math와 statistics 모듈은 모델이 빈번하게 사용하므로 미리 임포트하여 제공하며, contextlib.redirect_stdout를 통해 실행 결과만 캡처하여 모델에게 전달한다. 단순한 화이트리스트 방식은 단일 사용자 환경에서는 충분하지만, 객체 인트로스펙션을 통한 샌드박스 탈출 가능성이 존재하므로 실제 서비스 환경에서는 컨테이너나 RestrictedPython 같은 더 강력한 격리 계층이 필요하다는 점이 함께 관찰된다.

전체적인 오케스트레이션 루프는 파이썬 함수를 정의하고 이를 JSON 스키마로 노출하여 Ollama에 전달하는 방식으로 작동한다. 사용자의 질문이 들어오면 모델은 tool_calls 블록을 통해 필요한 도구를 요청하고, 시스템은 이를 로컬에서 실행한 뒤 그 결과를 다시 모델에게 전달해 최종 답변을 합성한다. 예를 들어 사용자가 현재 폴더의 CSV 처리 스크립트를 물으면, 모델은 list_directory_contents를 호출해 실제 파일 목록을 확인한 뒤 가장 적합한 파일을 추천한다. 이는 가중치에 의존한 환각이 아니라 실제 관찰에 기반한 추론이라는 점에서 실무적 가치가 크다. 모델을 설치하려면 bash

ollama pull gemma4:e2b

명령어를 사용한다.

경로 탐색 제한과 __builtins__ 화이트리스트 기반의 보안 설계

os.listdir 함수는 입력된 문자열을 그대로 받아들여 디렉터리 목록을 반환하는 단순한 구조를 가진다. 하지만 이 동작이 /나 ~, 혹은 ../../ 같은 경로 조작 문자열과 결합하면 모델의 호기심이 시스템 전체의 민감한 파일이나 API 키가 저장된 경로로 이어지는 경로 탈출 문제가 발생한다. 이를 방지하기 위해 설계 단계에서 안전한 기준 디렉터리를 고정하고 모델이 요청한 모든 경로를 이 기준점과 대조하는 검증 절차를 도입한다. 우선 os.path.abspath를 통해 입력된 경로를 절대 경로로 정규화하여 ..와 같은 상위 경로 이동 시도를 물리적으로 제거한다. 이후 정규화된 최종 경로가 사전에 정의한 기준 디렉터리의 접두사로 시작하는지 확인하는 prefix 체크를 수행한다. 이러한 과정을 거치면 /etc/passwd나 상위 폴더로의 무단 접근 시도는 os.listdir가 호출되기 전 단계에서 모두 거부된다.

소형 언어 모델이 정밀한 산술 연산이나 다단계 분기 로직을 처리할 때 발생하는 신뢰성 문제는 결정론적인 코드 실행 도구를 통해 해결할 수 있다. 다만 exec() 함수를 직접 사용하는 것은 모델에게 시스템 제어권을 부여하는 위험한 작업이므로 네임스페이스의 엄격한 제한이 요구된다. 보안 설계의 핵심은 개별 위험 함수를 하나씩 차단하는 블랙리스트 방식이 아니라, __builtins__ 네임스페이스를 화이트리스트로 완전히 교체하여 허용된 기능 외에는 아무것도 존재하지 않게 만드는 것이다. 이 방식을 적용하면 open, eval, compile, __import__와 같은 치명적인 함수들이 실행 환경에서 완전히 제거된다. 동시에 모델이 계산 작업에 필수적으로 사용하는 math와 statistics 모듈은 globals 영역에 미리 임포트하여 제공함으로써, 모델이 __import__ 제한에 부딪혀 작업을 포기하지 않도록 환경을 구성한다.

exec(code, {'__builtins__': {}}, globals)

코드 실행의 결과물을 모델이 정확히 인지하게 하려면 표준 출력의 캡처와 피드백 루프가 정교하게 맞물려야 한다. contextlib.redirect_stdout을 사용하여 코드 스니펫이 출력하는 모든 표준 출력 내용을 가로채어 모델의 다음 컨텍스트로 전달하는 구조를 취한다. 실제 운용 과정에서 소형 모델은 x = sum(range(101))과 같이 계산은 수행하지만 정작 결과를 출력하는 print(x)를 누락하는 패턴이 빈번하게 관찰된다. 만약 이 상태에서 빈 문자열을 그대로 반환하면 모델은 실행 결과가 없다는 사실을 인지하지 못하고 자신의 내부 가중치에 의존해 정답을 지어내는 환각 현상을 일으킨다. 이를 막기 위해 출력값이 비어 있을 경우 print() 함수를 사용하라는 구체적인 에러 메시지를 반환하도록 설계한다. 이는 오케스트레이션 루프가 모델에게 재시도 기회를 부여하게 하여, 모델이 스스로 코드를 수정하고 정확한 결과값을 도출하게 만드는 안전장치로 작동한다.

단순 API 호출(RAG)과 시스템 상호작용(Agency)의 결정적 차이

기존의 툴 호출 방식은 대부분 읽기 전용 웹 API(Application Programming Interface, 응용 프로그램 인터페이스)에 의존하는 구조를 가진다. 모델이 사용자 프롬프트를 분석해 적절한 API를 선택하고, 반환된 JSON 응답을 자연어 문단으로 합성하여 전달하는 과정이 핵심이다. 이러한 흐름은 정보의 최신성을 확보한다는 점에서 RAG(Retrieval Augmented Generation, 검색 증강 생성)와 매우 유사한 패턴으로 관찰된다. 하지만 이는 결국 더 많은 정보를 가진 챗봇의 확장일 뿐, 모델이 처한 환경을 인식하거나 그 상태를 변경하는 능력을 갖춘 것은 아니다. 시스템의 상태를 검사할 수 있는 수단이 없기에 모델은 주어진 텍스트 데이터 내에서만 답을 찾을 수밖에 없다.

실무적 관점에서의 에이전시(Agency, 자율적 수행 능력)는 모델이 자신이 실행되고 있는 시스템과 직접적으로 상호작용하기 시작할 때 비로소 구현된다. 단순히 원격 서버에서 정제된 문자열을 받아오는 수준을 넘어, 로컬 파일 시스템을 읽거나 파이썬 코드를 직접 실행하고, 파일을 수정하거나 외부 프로세스를 호출하는 행위가 이에 해당한다. 모델은 이제 어떤 파일이 존재하는지, 특정 변수의 값이 실제로 무엇인지, 폴더 내부에 어떤 구조가 형성되어 있는지와 같은 환경 상태(State)를 능동적으로 검사할 수 있게 된다. 이는 모델이 외부 환경의 상태를 관찰하고 그 결과에 따라 다음 논리적 단계를 결정하는 폐쇄 루프(Closed-loop) 제어 구조로 진입함을 의미한다.

이러한 제어권의 확보는 결과물의 신뢰도 측면에서 결정적인 차이를 만든다. 기존의 읽기 전용 방식은 모델이 학습된 가중치에 기반해 가장 확률이 높은 답변을 생성하는 추측(Hallucination, 환각)의 영역에 머물러 있었다. 반면 시스템 상호작용 방식은 실제 데이터에 기반한 관찰(Observation)의 영역으로 전환된다. 예를 들어 특정 폴더 내의 CSV 처리 스크립트를 찾는 작업에서, 모델은 파일명을 추측하는 대신 파일 시스템 탐색 도구를 호출해 실제 파일 목록을 확인하고 이를 근거로 판단을 내린다. 가중치에 의한 확률적 생성에서 실제 환경의 팩트에 기반한 추론으로 중심축이 이동하는 것이다. 이러한 관찰 기반의 접근은 LLM(Large Language Model, 거대언어모델)이 단순한 텍스트 생성기를 넘어 실질적인 시스템 운영자로 기능하게 하는 핵심적인 기술적 토대가 된다.

소형 모델의 추론 한계를 극복하는 결정론적 코드 실행의 실익

소형 모델이 정밀한 산술 연산이나 복잡한 문자열 조작, 다단계 분기 로직을 수행할 때 발생하는 오차는 확률적 생성 모델의 고질적인 한계로 관찰된다. 특히 토큰 단위로 텍스트를 처리하는 언어 모델의 특성상 숫자의 자릿수 계산이나 정확한 문자열 슬라이싱에서 논리적 붕괴가 일어나기 쉽다. 이를 해결하기 위해 자연어 추론에 의존하는 대신 결정론적(Deterministic)인 파이썬 코드 스니펫을 생성하고 실행하는 방식을 제안한다. 모델이 직접 계산하는 것이 아니라 계산을 수행할 코드를 작성하게 함으로써 논리적 오류를 원천적으로 제거하는 구조다. 이는 모델의 가중치에 의존하는 추론을 외부 실행 환경의 확정적 결과로 대체하는 전략이며, 특히 리소스 제약이 큰 엣지 디바이스용 소형 모델에서 정확도를 극대화하는 실무적인 해법이 된다.

실제 구현 과정에서 소형 모델은 변수에 값을 할당한 뒤 `print()` 함수를 누락하여 결과를 출력하지 않는 실수를 빈번하게 범한다. 예를 들어 `x = sum(range(101))`과 같은 식을 작성하고 정작 `x`를 출력하는 코드를 빠뜨리는 식이다. 출력값이 없는 빈 문자열이 반환될 경우 모델은 이를 근거로 잘못된 값을 확신하며 생성하는 환각 현상을 보일 가능성이 크다. 따라서 실행 결과가 없을 때 단순한 빈 값 대신 `print()` 사용을 권고하는 구체적인 에러 메시지를 반환하는 오류 처리 루프를 구성한다. 모델은 이 피드백을 통해 자신의 코드를 수정하고 재시도하며, 결과적으로 정답에 도달할 때까지의 자가 수정 과정을 거치게 된다. 이러한 루프 설계는 모델의 지능 자체를 높이는 것이 아니라 시스템적 제어권을 통해 결과의 신뢰성을 확보하는 접근이며, 이는 실제 프로덕션 코드에서 에이전트의 안정성을 결정짓는 핵심 로직이 된다.

다만 파이썬의 `exec()` 함수를 활용한 코드 실행은 심각한 보안 취약점을 내포하고 있으며 이는 실무 도입 시 가장 주의해야 할 지점이다. 단순한 화이트리스트 기반의 빌트인 함수 제한만으로는 `().__class__.__mro__`와 같은 객체 introspection(내성) 기법을 이용한 샌드박스 탈출 공격을 완전히 막을 수 없다. 공격자가 파이썬 객체 계층 구조를 탐색하여 제한된 환경 외부의 함수나 모듈에 접근할 수 있기 때문이다. 따라서 개인용 로컬 환경을 넘어선 서비스 수준의 구현에서는 더욱 강력한 격리 계층이 요구된다. 리눅스 커널 수준에서 시스템 콜을 제한하는 seccomp 적용 서브프로세스를 운용하거나, 독립된 컨테이너 환경을 구축하거나, 혹은 파이썬 코드 실행을 엄격히 제한하는 RestrictedPython 라이브러리를 도입하는 방안이 권장된다. 보안 격리 수준이 곧 에이전트의 실행 권한 범위와 직결되므로, 인프라 설계 단계에서부터 실행 환경의 격리 수준을 정의하는 것이 필수적이다.

온디바이스 AI 에이전트의 기업 내 실무 적용 가능성

국내 기업의 보안 담당자가 가장 우려하는 지점은 내부 데이터가 외부 API 서버로 전송되는 순간의 제어권 상실이다. 기존의 클라우드 기반 LLM 서비스는 편리하지만 기업 기밀이나 개인정보가 포함된 데이터를 처리할 때 데이터 거버넌스 확보가 어렵다는 한계가 관찰된다. 여기서 로컬 에이전틱 패턴(Local-agentic pattern)은 데이터의 외부 전송 없이 로컬 환경 내에서 모든 데이터 처리와 도구 실행을 완결 짓는 강력한 대안을 제시한다. 이는 단순히 챗봇을 사용하는 수준을 넘어 모델이 로컬 시스템의 자원을 직접 제어하고 현재 상태를 점검하는 구조로의 실질적인 전환을 의미한다.

실무적 관점에서 가장 주목할 부분은 샌드박스 내에서 이루어지는 로컬 파일 처리 방식이다. 모델이 파일 시스템에 접근할 때 특정 베이스 디렉토리를 지정하고 그 외부로의 접근을 엄격히 차단하는 제어 로직을 구현함으로써 데이터 유출 가능성을 원천적으로 낮출 수 있다. 이러한 구조는 기업 내에서 엄격하게 관리되어야 하는 서버 로그 분석이나 민감한 고객 정보가 포함된 CSV 데이터의 전처리 자동화 작업에 즉각적으로 적용 가능하다. 사람이 일일이 파일을 열어 확인하고 파이썬 스크립트를 작성하던 반복적인 업무를 로컬 에이전트가 수행하게 함으로써 보안성과 업무 생산성을 동시에 확보하는 실무적 경로가 열린다.

내부 시스템 설정 변경이나 인프라 관리 에이전트로의 확장 가능성 또한 매우 높게 평가된다. 제한된 파이썬 인터프리터를 통해 결정론적인 연산을 수행하고 시스템 상태를 점검하는 도구를 연결하면 모델의 환각 현상을 억제하면서도 정확한 시스템 제어가 가능해진다. 특히 랩톱 수준의 하드웨어에서도 원활하게 구동되는 gemma4:e2b 모델의 효율성은 이러한 에이전트를 거대 서버실이 아닌 개별 개발자나 운영자의 단말기에 직접 배포할 수 있게 한다. 이는 엣지 컴퓨팅 환경에서 AI가 단순한 텍스트 생성 도구를 넘어 실질적인 시스템 운영 주체로 작동할 수 있음을 구체적으로 보여준다.

결과적으로 로컬 LLM 기반의 자동화 도구는 폐쇄망 환경이 필수적인 국내 금융권이나 제조 공정 관리 시스템에서 강력한 실무적 가치를 가진다. 외부 네트워크 연결 없이도 로컬 파일 탐색과 코드 실행 능력을 갖춘 에이전트는 기존의 정적인 스크립트 자동화를 대체하는 유연한 인터페이스가 된다. 개발자가 체감하는 변화는 단순히 응답 속도의 개선이 아니라 데이터 주권을 완전히 유지한 채 시스템 제어권을 AI에게 위임할 수 있다는 기술적 신뢰의 확보에서 온다. 이러한 흐름은 향후 기업 내 AI 도입의 기준이 클라우드 성능 중심에서 로컬 제어 가능성 중심으로 이동하는 중요한 전환점이 될 것으로 관찰된다.