폐쇄망 사내 코딩 어시스턴트 도입 – Claude Code부터 OpenCode까지 8종 정리

외부 인터넷 송신이 차단된 폐쇄망에서 일하는 개발팀에게 “GitHub Copilot 쓰면 되잖아요”는 통하지 않는 말이에요. 코드를 외부 API로 보내는 게 원천적으로 불가능한 환경이기 때문이죠. 그래서 금융권, 공공기관, 방산, 일부 대기업 R&D 조직은 사내 LLM 인프라를 따로 구축하고 그 위에 코딩 어시스턴트를 얹는 방향으로 갑니다.

최근 사내 코딩 어시스턴트를 기본 IDE 확장(자동완성+채팅) 수준에서 본격 에이전틱 도구로 업그레이드하는 흐름이 확산되고 있어요. Claude Code의 등장 이후 “코드를 직접 편집하고 명령을 실행하는 AI 에이전트”가 표준이 되어가고 있는데, 폐쇄망 환경에서도 적용 가능한 옵션이 생각보다 많습니다.

이 글에서는 후보가 되는 주요 8종 도구를 사내 도입 의사결정 관점에서 정리했습니다.

왜 “라이선스가 무료”만으로는 부족한가

처음에 도구를 찾을 때 보통 “오픈소스인가, 무료인가”부터 보게 되는데요. 폐쇄망에선 그것만으로 충분하지 않아요. 정작 중요한 건 세 가지입니다.

이 세 축을 기준으로 도구별 평가가 달라집니다. 실제로 어떤 회사는 Claude Code가 상용이라서 후보에서 빼고, 어떤 회사는 OSI 비표준 라이선스(Crush의 FSL 같은)를 빼는 식이죠.

주요 8종 한 줄 정리

먼저 큰 그림으로 8종을 보겠습니다.

도구별 상세 정리

1Claude Code — 상용이지만 무시할 수 없는 선택지

“폐쇄망에서 무료로”를 검색하면 보통 오픈소스 도구만 나오는데, Claude Code는 사실 라이선스 면에서 약간 다른 위치에 있어요. 도구 자체는 @anthropic-ai/claude-code라는 npm 패키지로 누구나 무료로 받을 수 있어요. 다만 사용 약관은 Anthropic의 상용 약관(Commercial Terms of Service)이 적용됩니다.

중요한 건 Anthropic이 LLM 게이트웨이 사용을 공식적으로 지원한다는 점이에요. ANTHROPIC_BASE_URL 환경변수만 사내 LiteLLM 주소로 바꾸면 됩니다. 게이트웨이가 Anthropic Messages API 형식(/v1/messages)을 노출하면 그대로 동작하고, 게이트웨이 뒤에 사내 vLLM + 로컬 모델(Qwen, Llama 등)을 두는 구조도 가능합니다.

2OpenCode — Claude Code의 오픈소스 대안

OpenCode는 SST(현 Anomaly Innovations) 팀이 만든 MIT 라이선스 도구예요. 사실상 Claude Code의 오픈소스 대안으로 자리 잡았습니다. Go 기반 단일 바이너리 또는 npm 패키지로 배포되어서 폐쇄망 설치가 비교적 단순해요.

클라이언트/서버 분리 구조라 서버를 사내 어딘가에 띄우고 개발자들이 자기 터미널에서 붙는 형태로도 운영 가능합니다. 특히 공식 문서에 “air-gapped 모드”를 명시적으로 지원한다고 적혀 있고, 코드와 컨텍스트 데이터를 자체 저장하지 않는다는 점도 강조하고 있어서 보안 검토 통과 가능성이 높은 편입니다.

3Aider — 가장 성숙한 선택지

Aider는 2023년부터 개발된 가장 오래된 에이전틱 코딩 도구 중 하나예요. pip install aider-chat 한 줄로 설치되고, Git 자동 커밋 기능이 가장 강력합니다. AI가 코드를 수정할 때마다 의미 있는 커밋 메시지를 자동으로 작성해서 atomic commit으로 기록해줘요. 코드 리뷰나 롤백이 쉬워지는 큰 장점이죠.

내부적으로 LiteLLM을 사용하기 때문에 100여 개 모델과 즉시 호환됩니다. 사내 LiteLLM 게이트웨이와의 궁합이 가장 자연스러운 도구라고 볼 수 있어요. 다만 순수 터미널 CLI라 IDE에서 작업하던 개발자에겐 익숙해지는 데 시간이 좀 필요합니다.

4Cline — VS Code 사용자를 위한 선택

Cline은 원래 “Claude Dev”라는 이름으로 시작한 VS Code 확장이에요. 지금은 JetBrains, Cursor, Windsurf, Zed, Neovim까지 지원 범위가 확장됐고 CLI 프리뷰도 나왔습니다.

가장 큰 특징은 모든 액션마다 사람의 승인을 받는 워크플로우(human-in-the-loop)예요. AI가 파일을 수정하거나 명령을 실행하기 전에 사용자에게 확인을 받기 때문에 사내 도입 시 안전성 측면에서 어필 포인트가 됩니다. Plan 모드(읽기 전용 분석)와 Act 모드(실행)를 분리한 점도 운영 정책 수립에 유리하고요.

5Continue.dev — 이미 검증된 자체 호스팅 표준

Continue.dev는 이미 많은 폐쇄망 조직에서 사내 코딩 어시스턴트로 도입한 도구예요. VS Code, JetBrains 확장 형태로 자동완성, 채팅, 편집, 에이전트 모드를 모두 지원합니다.

설정 파일(config.yaml)에서 provider별로 base URL과 API 키를 자유롭게 지정할 수 있어서, 사내 LiteLLM 엔드포인트 등록이 가장 직관적인 도구 중 하나예요. 다만 에이전틱 측면에서는 Claude Code나 OpenCode 같은 터미널 전용 도구에 비해 자율성이 약간 낮은 편이에요. IDE 통합과 트레이드오프죠.

6Goose — 거버넌스 안정성이 강점

Goose는 원래 Block(블록, 구 Square)이 사내 도구로 개발했다가 오픈소스로 공개한 도구입니다. 2025년 12월 Linux Foundation 산하 Agentic AI Foundation(AAIF)으로 거버넌스가 이관됐어요.

이 점이 사내 도입 시 의외로 큰 장점이 됩니다. 단일 기업에 종속된 오픈소스는 회사 정책 변경으로 라이선스가 바뀌거나 개발이 중단될 위험이 있는데, Linux Foundation 산하 프로젝트는 그런 리스크가 상대적으로 낮아요. Desktop App, CLI, API 세 가지 형태로 제공되고 MCP를 네이티브로 지원합니다.

7Codex CLI — OpenAI 종속이 변수

OpenAI가 직접 만든 터미널 코딩 에이전트예요. Apache 2.0 오픈소스이고 Rust로 만들어졌습니다. 다만 공식 빌드는 OpenAI 모델(o4-mini, GPT-4o 등)과 ChatGPT 계정 인증에 종속되어 있어서, 폐쇄망에서 사내 모델을 쓰려면 커뮤니티 포크인 open-codex를 사용해야 합니다. 이 포크는 Chat Completion API로 변경해 Ollama 등 OpenAI 호환 provider를 지원하지만, 본가 업데이트와 동기화가 느릴 수 있다는 점이 단점입니다.

8Crush — 라이선스 검토가 핵심

Crush는 Charm이라는 회사가 만든 터미널 도구예요. Charm은 Bubble Tea라는 유명한 TUI 프레임워크를 만든 곳이어서 UI 완성도가 매우 높습니다.

중요한 건 라이선스가 FSL-1.1-MIT(Functional Source License)라는 점이에요. 소스는 공개되어 있지만 OSI 정의 오픈소스는 아니고, 2년 뒤 MIT로 자동 전환되는 구조입니다. 이 라이선스를 사내에서 어떻게 분류할지가 도입 가능성을 좌우합니다.

도입 우선순위 가이드

회사 상황별로 후보를 좁히면 이렇게 정리됩니다.

PoC 진행 시 실무 팁

도구 비교는 한 번에 8개 다 보지 말고 두세 개씩 단계적으로 진행하는 게 좋아요. 평가 기준을 미리 정하고 동일한 시나리오로 비교해야 결론을 내릴 수 있습니다.

실제로 PoC를 해보면 “도구 차이”보다 “도구-모델 궁합 차이”가 더 크게 나오는 경우가 많아요. 14B 미만의 작은 코딩 모델은 복잡한 멀티스텝 도구 호출에서 실패율이 눈에 띄게 높습니다. 모델 업그레이드 로드맵과 도구 PoC를 함께 검토하시는 걸 권장해요.

마무리

폐쇄망 에이전틱 코딩 도구 도입의 핵심은 “어떤 도구가 가장 좋은가”가 아니라 “사내 LLM 게이트웨이 표준을 어떻게 잡을 것인가”입니다. LiteLLM 같은 OpenAI 호환 게이트웨이를 표준으로 정해두면 위에서 다룬 도구 대부분을 큰 변경 없이 시험해볼 수 있어요.

도구 선택은 라이선스 정책 → 백엔드 자유도 → 운영 안정성 순서로 좁혀가시고, 최종 결정은 실제 PoC 결과를 보고 내리시는 게 맞습니다. 일반 IT 회사라면 OpenCode와 Continue.dev 조합, 보안이 엄격한 금융·공공이라면 Claude Code 라이선스 검토 통과 시 그쪽을 1순위로 두는 게 현실적인 출발점이 될 것 같아요.

혹시 사내에서 이미 도입해본 도구가 있다면 어떤 부분이 잘 됐고 어떤 부분이 막혔는지 댓글로 공유해주세요. 같은 고민을 하는 분들에게 큰 도움이 될 거예요.