[LLM Server 구축기] 폐쇄망 환경에서 로컬 코딩 에이전트 파일럿 만들기

(26.04.04 기준)

1. Why?

최근 Claude Code 유출 이슈가 화제가 됐다. Claude Code 측에서 npm 배포 과정 중 ignore 설정 실수로 src 파일이 통째로 포함되면서 내부 구현이 외부에 노출된 사건이었다. 이 일을 보면서 “코딩 에이전트는 실제로 어떤 구조로 동작하는가”에 대한 관심이 생겼다.

하지만 이 글의 출발점은 단순한 호기심만은 아니었다. 내가 일하는 회사는 폐쇄망 환경이라 외부 SaaS 기반 AI 도구를 도입하는 데 제약이 있었다. 그 와중에 PM님이 “AI 시대에 맞춰 사내에도 AI를 도입해 개발 생산성을 높여보자”는 제안을 주셨고, 그에 따라 폐쇄망에서 실제로 굴릴 수 있는 AI 코딩 에이전트 파일럿 프로젝트를 해보기로 했다.

이 글은 그 과정에서 시도한 인프라 구성, 시행착오, 그리고 목표를 어떻게 수정했는지를 정리한 기록이다.

2. 처음 목표와 수정된 목표

처음에는 Claude Code처럼 잘 동작하는 로컬 코딩 에이전트를 만들고 싶었다. 실제로 Claude Code와 Ollama를 연결해보기도 했다. Ollama 공식 문서도 Claude Code 연결을 안내하고 있기 때문에, “로컬 모델만 준비되면 비슷한 개발 경험을 만들 수 있지 않을까”라고 생각했다.

하지만 진행하면서 현실적인 제약이 분명히 보였다.

현재 내가 사용한 서버 환경은 다음과 같다. 집에 있던 데스크탑이라 사양이 낮다.

• GTX 1070 8GB
• Ollama
• qwen2.5-coder:7b

이 조합은 “가벼운 로컬 코딩 보조” 정도는 가능했지만, Claude Code가 기대하는 수준의 에이전트 워크플로를 안정적으로 수행하기에는 부족했다. Claude Code는 긴 system prompt, tool use, permission, session state를 전제로 움직이는데, Ollama 문서 기준으로도 Claude Code 사용 시 최소 64K context를 권장한다. 반면 내 환경에서 실제로 확인된 context는 4K 수준이었다.

CONTEXT를 보면 알 수 있다.

즉 문제는 단순히 “모델이 연결되느냐”가 아니라, “에이전트가 기대하는 long context와 tool protocol을 현재 하드웨어가 감당할 수 있느냐”였다.

그래서 목표를 다음과 같이 수정했다.

수정된 목표: 폐쇄망 환경에서 동작하는 로컬 코딩 에이전트 파일럿

이 목표에서는 Claude Code와의 완전한 parity는 포기하고, 대신 아래를 더 중요하게 보기로 했다.

• 폐쇄망에서 실제로 설치/운영 가능한가
• 내부 LLM 서버와 연결 가능한가
• 파일 읽기/쓰기/수정, 명령 실행이 가능한가
• 권한 통제와 세션 유지가 가능한가
• 실제 개발 저장소에서 생산성 향상이 있는가

참고:

• Claude Code - Ollama

Claude Code - Ollama

 

3. 최종 인프라 구성

이번 파일럿의 최종 인프라 구성은 다음과 같다.

• Ubuntu Server 24.04.4 LTS
• NVIDIA Driver 580.126.20
• Ollama
• qwen2.5-coder:7b
• GPU: GTX 1070 8GB
• 로컬 클라이언트: macOS
• 내부망에서 Ollama endpoint 호출

구조를 단순하게 그리면 아래와 같다.

• macOS에서 CLI 실행
• 내부망으로 Ubuntu 서버의 Ollama 호출
• Ubuntu 서버가 qwen2.5-coder:7b 모델 추론 수행

즉, 클라이언트와 모델 서버를 분리한 구조다.

4. 서버 구축 절차

4.1 기본 패키지 설치

먼저 기본 패키지를 설치했다.

sudo apt update
sudo apt install -y curl ca-certificates git ufw

이 단계는 설치 스크립트 실행과 API 확인용 curl 같은 기본 도구를 준비하기 위한 것이다.

4.2 NVIDIA 드라이버 설치

이후 NVIDIA 드라이버를 설치했다.

sudo apt install -y ubuntu-drivers-common
sudo ubuntu-drivers list --gpgpu
sudo ubuntu-drivers install --gpgpu
sudo reboot

재부팅 후에는 반드시 아래 명령으로 GPU가 정상 인식되는지 확인해야 한다.

nvidia-smi

여기서 GPU가 정상적으로 보이지 않으면 다음 단계로 넘어가지 않는 것이 맞다.

4.3 Ollama 설치

Ollama는 Ubuntu 서버에 직접 설치했다.

curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl enable --now ollama
sudo systemctl status ollama
ollama -v

4.4 외부 바인딩 및 모델 저장 경로 설정

로컬 macOS에서 dev-agent 같은 클라이언트가 원격 서버의 Ollama에 붙을 수 있도록 서비스 override를 설정했다.

sudo mkdir -p /srv/llm-project/models/ollama
sudo chown -R ollama:ollama /srv/llm-project/models/ollama
sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo tee /etc/systemd/system/ollama.service.d/override.conf >/dev/null <<'EOF'
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/srv/llm-project/models/ollama"
EOF
sudo systemctl daemon-reload
sudo systemctl restart ollama

이 단계가 중요한 이유는 Ollama가 기본적으로 127.0.0.1:11434에만 바인드되기 때문이다.

4.5 방화벽 설정

보안상 가장 좋은 방법은 특정 개발 PC의 IP만 허용하는 방식이지만, 나는 같은 공유기 내부망에서 우선 빠르게 테스트하는 것이 목적이었기 때문에 임시로 아래처럼 포트를 열었다.

sudo ufw allow 11434/tcp

상태 확인:

sudo ufw status

4.6 모델 다운로드

내 데스크탑 서버는 GTX 1070 8GB이기 때문에 현실적으로 7B 모델을 선택했다.

ollama pull qwen2.5-coder:7b

모델 정보:

• qwen2.5-coder

qwen2.5-coder

 

qwen2.5-coder는 코드 생성, 코드 reasoning, 코드 수정에 특화된 Qwen 계열 모델이다.

4.7 서버 로컬 확인

설치 후 서버 내부에서 Ollama가 정상 동작하는지 확인했다.

curl http://127.0.0.1:11434/api/tags
curl http://127.0.0.1:11434/api/generate -d '{
  "model": "qwen2.5-coder:7b",
  "prompt": "say ok",
  "stream": false
}'
ollama ps

여기서 ollama ps를 보면 모델이 GPU로 올라갔는지, 그리고 실제 context가 얼마인지 확인할 수 있다.

간단한 테스트만 할 거라면 CPU fallback이어도 일단 동작은 가능하다. 하지만 본격적으로 사용할 경우 속도 차이가 크기 때문에 GPU 사용 여부는 꼭 확인하는 것이 좋다.

5. 실제로 부딪힌 문제

5.1 NVML mismatch

처음에는 GPU가 전혀 잡히지 않았다.

nvidia-smi

출력은 다음과 같았다.

Failed to initialize NVML: Driver/library version mismatch
NVML library version: 595.58

알고 보니 NVIDIA 드라이버 버전과 유저 공간 라이브러리 버전이 서로 맞지 않아 GPU를 정상적으로 사용할 수 없는 상태였다.

5.2 NVIDIA 드라이버 커널 모듈 문제

이후에는 다음과 같은 오류도 만났다.

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver.
Make sure that the latest NVIDIA driver is installed and running.

즉, NVIDIA 드라이버 커널 모듈 자체가 정상적으로 올라오지 않는 상태였다.

5.3 apt dependency broken

드라이버를 다시 설치하려고 했을 때는 apt 상태도 깨져 있었다.

sudo apt install -y ubuntu-drivers-common mokutil

실행 결과:

E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

결국 드라이버 문제를 해결하기 전에 패키지 의존성부터 복구해야 했다.

복구 절차는 다음과 같았다.

sudo apt --fix-broken install
sudo apt autoremove -y
sudo apt update
sudo ubuntu-drivers list --gpgpu
sudo ubuntu-drivers install --gpgpu
sudo reboot
nvidia-smi

5.4 GTX 1070과 최신 드라이버의 함정

추가로 확인해보니, GTX 1070은 최신 595 계열 드라이버보다 580 계열 legacy 쪽이 더 맞는 조합이었다. 최종적으로 정상 동작한 버전은 580.126.20이었다.

이 과정을 통해 단순히 “드라이버를 설치한다”가 아니라, GPU 세대에 맞는 드라이버 브랜치를 선택하는 것이 중요하다는 걸 배웠다.

6. 왜 Claude Code를 그대로 목표로 하지 않았는가

설치와 연결 자체는 가능했다. 실제로 로컬에 설치된 Claude Code CLI를 Ollama endpoint에 연결하는 것까지는 성공했다.

문제는 품질이었다.

qwen2.5-coder:7b 같은 작은 모델은 Claude Code가 기대하는 tool protocol과 long context를 안정적으로 처리하지 못했다. 단순한 프롬프트에는 반응했지만, 실제 파일 읽기/skill/tool 선택이 들어가면 엉뚱한 structured output이나 잘못된 skill 호출이 튀어나왔다.

이건 Claude Code 자체의 문제라기보다는, 현재 하드웨어와 모델 조합의 한계에 가까웠다.

결국 여기서 얻은 결론은 이랬다.

• Claude Code와 비슷한 UX를 만드는 것보다
• 폐쇄망에서 실제로 쓸 수 있는 에이전트를 만드는 것이 더 중요하다

그래서 나는 Claude Code 복제를 목표로 삼는 대신, 현재 인프라에서 돌아가는 로컬 코딩 에이전트 파일럿으로 방향을 바꿨다.

7. 배운 점

이번 파일럿을 하면서 얻은 핵심 교훈은 아래와 같다.

• 에이전트는 단순 채팅 모델과 다르다
• tool use, permission, session, long context가 핵심이다
• 작은 모델은 연결 자체보다 “에이전트형 동작”에서 한계를 드러낸다
• 폐쇄망에서는 최고 성능보다 운영 가능성과 통제 가능성이 더 중요하다
• 목표를 이상적으로 잡는 것보다, 현재 인프라에서 가능한 범위로 조정하는 것이 더 중요하다

8. 다음 단계

다음 단계는 Claude Code 복제가 아니라, 폐쇄망에서 실제로 사용할 수 있는 코딩 에이전트 파일럿을 더 구체화하는 것이다.

예를 들면 아래 기능들이 우선순위가 될 수 있다.

• 파일 읽기/쓰기/수정
• 쉘 명령 실행
• 권한 승인
• 세션 저장/복구
• 간단한 감사 로그
• 실제 백엔드 저장소 대상 파일럿 검증

이제 목표는 “Claude Code처럼 보이는 도구”가 아니라, “사내 폐쇄망에서 실제로 개발 생산성을 올릴 수 있는 도구”다.