Tabby는 '코드를 내부망 밖으로 내지 않는' 프로그래밍 조수를 찾는 팀이 먼저 보는 이름 중 하나입니다. 자체 호스팅 AI 프로그래밍 조수로, 코드 완성을 주축으로 질의응답과 채팅도 갖추고 있으며, GitHub Copilot의 로컬 배포 대안으로 자주 거론됩니다. 매력은 직접적입니다. 서비스를 자기 서버에 올려 추론을 내부망 안에서 끝내고, 오프라인에서도 돌리며, 원격 측정도 밖으로 보내지 않습니다. 규정 요구가 엄격한 팀에게는 이 전제가 완성이 조금 더 똑똑한 것보다 더 중요합니다.
공식 저장소 정보
플랫폼은 GitHub, 조직은 TabbyML, 프로젝트 이름은 tabby이며, GitHub에서 3.3만이 넘는 스타를 모았습니다. VS Code와 JetBrains 계열을 포함한 주요 편집기 플러그인을 제공하고, 연결한 저장소를 색인할 수 있어 완성이 단일 파일 추측이 아니라 현재 프로젝트의 맥락을 참고합니다.
왜 선택하는가
클라우드 도구는 시작이 빠르지만 코드를 외부 서비스로 보내야 하고, 금융, 공공, 대규모 제조 같은 장면에서는 내부 심사를 통과하지 못하는 경우가 적지 않습니다. Tabby는 그 선을 내부망 안에 긋습니다. 공식 형태는 Docker 명령 하나로 뜨는 자체 완결 서비스로, 외부 데이터베이스나 클라우드 후단에 의존하지 않습니다. 그래픽카드가 있는 장비 한 대로 시작할 수 있고, 소비자용 카드도 지원하며, 완전히 오프라인으로 돌릴 수 있습니다. 공용 서비스 한 벌을 두면 관리자도 접근을 한곳으로 모으기 쉽고, 사람마다 외부 서비스를 따로 구독하는 형태가 되지 않습니다.
배포와 운영, 두 가지 계산
첫째는 그래픽카드 계산입니다. 후단 코드 모델은 직접 고릅니다. 같은 부류에서 흔히 거론되는 선택으로는 StarCoder, CodeLlama, DeepSeek-Coder, Qwen 계열 코드 모델 등이 있고, 완성 품질의 상한은 고른 모델이 정합니다. 모델이 클수록 보통 결과는 좋아지지만 비디오 메모리도 더 먹습니다. 팀이 함께 쓰면 동시 사용자 수만큼 여유를 둬야 하고, 항상 켜 두는 GPU 장비는 전기와 냉각까지 장기 비용입니다. 둘째는 운영 계산입니다. 컨테이너를 띄우는 것은 시작일 뿐이고, 저장소 색인은 직접 유지해야 하며, 모델 교체, 버전 올리기, 메모리 부족 원인 찾기도 자기 몫으로 남습니다. 배포 전에 경계 확인도 필요합니다. 팀 단위 사용자 관리와 더 세밀한 분석 같은 능력은 기업용 범위이므로, 오픈소스 자체 호스팅 부분으로 되는 것과 따로 판단할 것을 먼저 나누고, 도입한 뒤에야 빈틈을 발견하는 일을 피하세요.
진짜 함정과 한계
가장 눈에 띄는 차이는 완성 품질입니다. 클라우드의 최전선 프로그래밍 도구와 비교하면, 로컬 작은 모델은 짧은 코드와 정형 조각은 괜찮게 처리하지만 파일을 넘나드는 복잡한 추론에는 힘이 부치고, 제안에도 사람 확인이 더 필요합니다. 가장 강한 클라우드 경험을 그대로 대체하려는 팀은 낙차를 분명히 느낍니다. 편하게 쓰려는 경우에도 맞지 않습니다. 색인, 모델, 플러그인 호환을 계속 따라가야 하고, 클라우드처럼 열면 바로 쓰는 편리함은 없습니다. '코드를 내부망 밖으로 낼 수 없다'는 조건이 실제로 성립하고, 그 대가로 장비와 운영 비용을 감당할 마음이 있을 때만 그 가치가 커집니다. 그 밖의 이유로 자체 호스팅을 하면 계산이 맞지 않는 경우가 많습니다.
맞는 사람, 맞지 않는 사람
규정이나 내부망 요구가 있는 소규모 팀, 오프라인 환경, 완성 서비스를 하나로 모아 관리하려는 팀에 맞습니다. 이런 팀은 완성이 조금 약해도 코드를 내부에 두는 쪽을 택합니다. 가장 강한 완성 품질을 좇는 개인 개발자에게는 맞지 않습니다. 개인이 맛보려면 클라우드 도구를 직접 쓰는 편이 보통 더 값이 납니다. GPU 서버가 없는 팀, 운영을 맡을 사람이 없는 팀에도 맞지 않습니다. 결정하기 전에 실제 저장소로 일주일 돌려 보고, 완성 적중, 응답 속도, 메모리 사용량을 받아들일 수 있는지 본 뒤 상시 도입을 생각하세요.
