회사 서버에 직접 설치(온프렘)

인터넷에 올리면 안 되는 사내 도구·대시보드·데이터가 있는 회사를 위한 방식이에요. Docker 서버 한 대부터 Kubernetes, 인터넷이 끊긴 폐쇄망까지 되고, 회사 통합 로그인(OIDC·SAML)도 연동돼요. 기업 기능(구성원·부서·배포 통제·감사 기록)은 그대로예요.

어디서 시작해요?

• 왼쪽 메뉴 「온프렘 설치」(개인) 또는 기업 관리의 「온프렘 설치」(조직 관리자). 회사 이름으로 받고 다른 관리자와 같이 관리하려면 기업 계정 쪽을 써요.
• 먼저 도입 문의 — 설치 파일은 회사 서버에 복사되는 소프트웨어라 누구에게나 열어 두지 않아요. 「온프렘 설치」 화면에서 회사·용도를 적어 도입 문의를 보내면 저희가 확인하고(보통 1영업일) 그 계정에 다운로드·체험·구매를 열어 드려요. 결과는 가입 메일로 알려 드려요.
• 1단계 설치 파일 다운로드 → 2단계 라이선스 받기(체험은 카드 없이 즉시, 구매는 앱 서버 수 × 기간) → 3단계 서버에서 설치. 단계별 그림 가이드는 onpod.ai/onprem에 있어요.

라이선스는 어떻게 넣어요?

• 발급된 라이선스의 「라이선스 보기·복사」로 내용을 복사해, 설치한 회사 onpod 콘솔 → 슈퍼어드민 → 라이선스 카드 → 「라이선스 붙여넣기」에 붙이고 「적용하기」. 서버 재시작 없이 바로 적용돼요.
• 파일로 두고 싶으면 설치 폴더의 license/license.json 에 넣어도 같아요. 둘 다 있으면 만료가 더 늦은 유효한 것이 쓰여요.
• 만료되면 14일 유예 뒤 새 배포·빌드·서버 추가만 잠기고, 이미 배포한 앱은 계속 실행돼요. 갱신은 같은 화면에서 하고, 새 기간은 지금 만료 다음 날부터 이어져요.

BizCoder도 회사 서버에 설치할 수 있어요?

• 네. BizCoder(AI로 코딩하고 배포까지 하는 도구)를 onpod과 함께 회사 서버에 설치하는 방식이에요. 「온프렘 설치」 화면의 「BizCoder 온프렘」 카드에서 BizCoder 설치 파일, 버전별 사용 가이드(PDF), BizCoder 전용 라이선스 파일(.lic)을 받아요. 카드는 BizCoder 파일이 올라온 뒤나 라이선스를 받은 뒤에 보여요.
• 받는 조건은 onpod 설치 파일과 같아요 — 도입 승인된 계정이고, 약관에 동의했고, 유효한 onpod 라이선스가 있어야 해요. BizCoder 라이선스는 도입 계약 뒤에 저희가 발급해서 계정에 올려 드려요.
• 회사 onpod에서는 관리자가 코드 샌드박스 API를 한 번 켜야 해요. Helm은 controlplane.sandboxApi.enabled=true, Docker는 .env 파일에 ONPOD_SANDBOX_API_ENABLED=1 한 줄을 넣어요. 그다음 BizCoder가 쓸 조직 API 키를 만들어요. 자세한 순서는 설치 매뉴얼 18장에 있어요.

가격

앱 서버(호스트) 수 × 기간이에요. 사용자 수·배포 수·트래픽은 세지 않아요. 12개월 결제는 2개월이 무료예요. 정확한 금액은 「온프렘 설치」 구매 카드에서 서버 수와 기간을 고르면 바로 보여요. 카드 결제 대신 별도 계약(견적·세금계산서·계좌이체·다년 계약·설치 지원)도 돼요 — [email protected]로 연락해 주세요.

무엇이 되고, 무엇이 아직 안 돼요?

• 되는 것 — 정적 사이트 · Docker 컨테이너 앱(단일·자동확장·워커, 서버에서 Dockerfile 빌드) · 파일 저장소(S3 호환) · 서비스형 Postgres(onpod db create — 회사가 등록한 Docker 앱 서버 위에 컨테이너로 만들어져요) · 회사 통합 로그인 · 기업 기능(구성원·부서·배포 통제·감사 기록·방문 통계).
• 서비스형 Postgres 의 범위 — 만들기·붙이기(--attach-db)·비밀번호·멈춤/다시 켜기·지우기(컨테이너는 바로, 데이터 볼륨은 7일 뒤)가 돼요. Docker 앱 서버와 Kubernetes 클러스터 둘 다 위에 만들어져요. 요금과 크기 상한이 없어요. 자동 백업·복구·크기 변경·연결 풀·IP 허용 목록은 아직 없어요 — 백업은 서버 관리자가 pg_dump 로 회사 백업에 넣어요.
• 아직 안 돼요 — GPU 서버 위 앱(설계는 됐지만 실측 전), 여러 서버가 같은 디스크를 쓰는 공유 볼륨(NFS), 고정 발신 IP(사내망에선 해당 없음).

설치 파일을 받기 전에 동의하는 약관은요?

설치 파일은 회사 서버에 복사되는 소프트웨어라, 다운로드·라이선스 발급 전에 온프렘 소프트웨어 라이선스 약관에 한 번 동의해요(라이선스 범위 안에서만 쓰고, 프로그램을 분해·역컴파일·재배포하거나 라이선스 확인을 우회하지 않는다는 내용). 약관이 바뀌면 새 버전에 다시 동의해요.

인프라(서버)는 어떻게 할당돼요? Kubernetes(EKS)가 필요해요?

• 온프렘 onpod은 클라우드 서버를 스스로 빌리지 않아요. 관리자가 add-host.sh로 등록한 Docker 서버나 Helm으로 등록한 Kubernetes 클러스터 위에서만 앱이 실행돼요 — EKS 같은 클라우드 자원은 필요 없어요.
• 직원이 앱을 만들면 등록된 서버들의 빈 슬롯(서버 RAM을 앱 크기 micro·small·medium·large로 나눈 자리)에 배치돼요. 남은 슬롯은 슈퍼어드민 「GPU·CPU 재고」, 서버 상태는 「서버 (하드웨어)」에서 봐요.
• 슬롯이 모자라면 배포가 거절되고, 서버를 한 대 더 붙이거나 노드를 늘리면 돼요.

직원이 무엇을·어디까지 배포할 수 있는지 규칙으로 정할 수 있어요?

• 기업 관리 → 배포 통제 → 배포 규칙에서 정해요: 배포 형태(정적·단일·자동 확장·워커), 앱 최대 크기, GPU 허용·장수·모델, 서비스형 DB 허용·크기·1인당 개수, 기능(파일 저장소·공유 디스크·샌드박스·도메인·서버 빌드·외부 이미지), 이미지 접두어 허용/차단, 1인당 앱 수·복제 수·리전, 그리고 보안팀 규칙 문장.
• 규칙 밖 요청은 배포 시점에 서버가 403으로 막고 이유를 알려줘요. 같은 규칙이 onpod manual 끝에 붙어 직원의 코딩 에이전트가 처음부터 규칙 안에서 제안해요(예: DB 금지면 DB 제안을 빼요).
• 보수적·표준·자유 프리셋으로 시작해 항목을 고치면 돼요. 이미 배포된 앱은 그대로 실행되고 새 배포·업데이트부터 적용돼요.

회사 GitLab·Argo CD와 연동돼요?

• 소스 보관 — 기업 관리 → 연동 → GitLab을 켜면 서버 빌드·정적 배포마다 소스 스냅샷을 <그룹>/<앱이름> 프로젝트에 커밋하고 onpod-<배포ID> 태그를 달아요. 바이브코딩 결과물이 회사 자산으로 남아요. 실패해도 배포는 막지 않아요.
• GitOps 내보내기(Argo CD) — 주소가 있는 앱을 배포하거나 업데이트할 때마다 그 앱의 Helm 차트(Chart.yaml·values.yaml·templates/ · 원하면 원시 매니페스트)를 매니페스트 저장소의 apps/<앱>/ 에, Argo CD Application 을 argocd/<앱>.application.yaml 에 커밋해요. 회사 Argo CD에 그 Application 을 적용하면 onpod에서 검증한 앱을 운영 클러스터로 승격할 수 있어요. 환경변수 값은 Git에 싣지 않아요(secretRef 참조만).
• 매니페스트 저장소는 연동 그룹 안에 두세요(예: <그룹>/gitops). 그룹 액세스 토큰은 자기 그룹 밖을 볼 수 없어 내보내기가 실패해요. 「연결 확인」이 저장소까지 확인하고, 이미 떠 있는 앱은 「지금 내보내기」로 한 번에 올려요. 결과는 연동 화면 아래 「최근 GitLab 동기화」에 남아요.
• onpod 자체도 Helm 차트라 Argo CD Application으로 설치·운영할 수 있어요.
• 배포 방식 「Argo CD 가 배포」 — 연동 화면에서 고르면 onpod 은 빌드·코드 분석·이미지 검사까지만 하고 앱을 직접 띄우지 않아요. Helm 차트와 Argo CD Application 을 GitLab 에 커밋하면 회사 Argo CD 가 클러스터에 배포하고, GitLab CI 의 onpod 은 서비스가 정상이 될 때까지 기다려요. 처음 한 번 argocd/_root.application.yaml 을 Argo CD 에 등록하면 앱 추가·삭제가 자동이에요.
• GitOps 배포 화면 — Argo CD 가 배포한 앱의 동기화·상태, 파드, 경고 이벤트, 로그, 이미지 기록과 되돌리기를 onpod 콘솔에서 봐요. 클러스터 안 onpod 에이전트(차트 gitops 값)가 읽기 권한으로 모아 와요. 환경변수 값은 Git 에 올리지 않고, 「Secret 동기화」를 켜면 에이전트가 클러스터 Secret 으로 맞춰요.

사내 GitLab에 push 하면 사내 onpod에 자동 배포돼요?

돼요. 사내 GitLab(또는 GitHub Enterprise)에서 이미 쓰는 CI에 onpod 배포 단계를 하나 더하는 방식이에요. 사내 러너가 사내 onpod을 직접 부르기 때문에 바깥 인터넷이 필요 없어요.

• 회사 onpod에 로그인한 상태로 저장소 폴더에서 onpod ci init --app <앱이름>을 실행하면, 회사 onpod 주소와 사내에서 CLI를 받는 주소가 기본값으로 든 CI 파일과 그 앱 전용 키가 만들어져요.
• 러너에서 보이는 주소가 다르면 CI/CD 변수 ONPOD_URL·ONPOD_CLI_URL로 바꾸고, 사내 인증서는 File 형식 변수 ONPOD_CA_CERT에 넣어요. 러너가 Docker Hub에 못 나가면 ONPOD_CI_IMAGE에 curl이 든 사내 미러 이미지를 넣으세요.
• docker executor·shell executor 둘 다 돼요. shell executor는 그 서버의 curl·sha256sum만 있으면 되고 관리자 권한이 필요 없어요.
• 받은 CLI는 체크섬으로 확인한 뒤 써요. 확인에 쓰는 목록(sha256sums.txt)은 다음 설치본(번들) 업데이트부터 들어가요 — 그 전 설치본이면 관리자에게 업데이트를 요청하세요.

빌드한 이미지의 취약점도 검사돼요?

• 이미지를 만들기 전에 소스부터 검사해요(코드 분석) — 잠금 파일 의존성 취약점, 소스에 들어간 키·토큰, Dockerfile·Kubernetes 설정 실수를 찾고, 회사에서 쓰는 분석 도구(SonarQube 등)도 같은 단계에 연결할 수 있어요. 기업 관리 → 연동 → 코드 분석에서 끄기·경고만(기본)·막기를 골라요.
• 서버 빌드가 끝나면 번들에 포함된 스캐너(Trivy + 취약점 DB)가 그 이미지를 검사해 CRITICAL·HIGH·MEDIUM·LOW 수와 수정 버전 유무를 남겨요. CLI의 onpod build status와 팟 상세 「취약점 검사」에서 봐요. 폐쇄망에서도 동작해요(DB는 번들과 함께 업데이트).
• 정책은 기업 관리 → 연동 → 이미지 취약점 검사에서 끄기·경고만(기본)·CRITICAL이면 배포 막기 중 골라요. 막기면 CRITICAL이 있는 이미지는 배포·업데이트가 거절되고, 베이스 이미지를 수정 버전으로 업데이트해 다시 빌드하면 돼요.
• 번들 자체의 검사표(SECURITY-SCAN.md)와 SBOM(sbom/*.cdx.json)도 설치 파일 안에 들어 있어요.

직원은 어떻게 배포해요?

하던 대로예요. 회사 onpod 주소에서 CLI를 받아 로그인하고, 코딩 에이전트에게 말하면 에이전트가 회사 onpod인 걸 인식하고 사내 주소로 배포해요.