01문제
이 고객사는 사내 데이터를 외부 사업자 서버로 전송할 수 없다는 보안 요건을 갖고 있었고, 그 요건은 협상 대상에서 빠져 있었습니다. 상용 LLM API는 검토 단계에서 이미 배제됐습니다. 대표의 방향은 경영 보고부터 코딩까지 회사 장비 안에서 도는 로컬 AI였고, Mac Studio는 용량 검증보다 먼저 수십 대 단위로 들어와 있었습니다.
문제는 모델이 아니라 운영이었습니다. 노트북에 로컬 모델을 하나 띄워 시연하는 것은 누구나 합니다. 시연이 증명하지 못하는 것은 셋입니다. 여러 사람이 같은 창구로 쓸 수 있는가, 담당자가 자리에 없어도 계속 도는가, 정전이나 재부팅 뒤에 사람이 손대지 않아도 스스로 돌아오는가.
그래서 과제의 목표를 사람의 개입 없이 유지되는 사내 서빙 인프라, 그리고 이 장비로 가능한 최대치를 정직하게 적은 배정표로 정의했습니다.
02제약
- 외부 반출 금지. 추론 요청과 응답이 사내망을 벗어나면 안 됩니다. 클라우드 GPU 임대, 외부 API 프록시, 외부 벡터 DB 모두 후보에서 제외됩니다.
- 장비는 정해져 있습니다. Mac Studio 15대가 이미 들어와 있습니다. 성능 격차는 배정 설계로 풉니다.
- 전담 운영 인력 없음. 상시로 클러스터를 돌볼 사람이 없습니다. 사람이 매일 확인해야 유지되는 구조는 실패로 간주합니다.
- 사용자는 비개발자입니다. 터미널이나 API 키를 다루지 않는 구성원이 씁니다. 진입점이 하나여야 하고, 그 하나가 이미 쓰고 있는 도구여야 합니다.
- 모델 라이선스. 상용 이용 조건이 불명확한 가중치는 쓰지 않습니다. 조건을 확인할 수 있는 계열만 남깁니다.
03접근
1) 장비를 역할로 배정했습니다
장비마다 담당 역할을 정한 뒤 그 역할에 맞는 모델을 배정했습니다. 배정 근거는 네 가지 정량 값입니다. 상용 이용 조건, 장비 실 RAM, 양자화 형식(GGUF/MLX), 그리고 컨텍스트를 길게 쓸 때 필요한 KV cache 헤드룸. 헤드룸을 계산에 넣지 않으면 짧은 프롬프트에서는 잘 돌다가 실제 업무 길이에서 죽습니다. GLM·Qwen 계열로 좁혔습니다.
2) 가장 큰 모델을 가장 좋은 장비에 넣는 안을 기각했습니다
첫 배정은 그렇게 잡았고 검증에서 제가 기각했습니다. 극단적으로 압축해도 장비가 실제로 쓸 수 있는 메모리 한도를 넘었고, 그 압축은 품질을 깎습니다. 배정은 세 번 고쳤습니다. 최종 배정표에는 장비마다 남는 메모리와 권장 컨텍스트 상한까지 적었습니다. 못 하는 것을 적은 것이 그 표의 값입니다.
3) 장비 전력표를 믿지 않고 전수 대조했습니다
사내 장비 전력표를 제조사 공식 측정값과 전수 대조했습니다. 두 행의 값이 서로 바뀌어 있었고, 섀시에 적힌 정격 전력과 실부하 측정값이 한 표에 섞여 있었습니다. 둘 다 정정한 뒤 배정표를 다시 계산했습니다. 잘못된 입력으로 만든 설계는 검토를 통과해도 운영에서 깨집니다.
4) 망을 열지 않고 묶었습니다
장비들을 Tailscale 독립망으로 묶어 서로 통신하게 하고, 공개 인터넷에는 어떤 포트도 노출하지 않았습니다. 포트 포워딩이나 리버스 프록시로 밖에서 접근 가능한 구멍을 만드는 대신, 사내 구성원 단말이 같은 사설망에 들어오는 방향으로 뒤집었습니다.
5) 진입점을 하나로 줄였습니다
이미 업무에 쓰던 디스코드 봇을 단일 진입점으로 삼았습니다. 구성원은 새 도구를 배우지 않고 평소 채널에 질문을 쓰면 됩니다. 인프라 쪽에서는 인증·라우팅·로깅이 한 곳에 모입니다.
6) 재기동을 설계에 포함했습니다
서비스 등록과 부팅 시 자동 기동을 처음부터 넣었습니다. 데모에서는 사람이 프로세스를 띄우지만, 운영에서는 정전과 업데이트 재부팅이 반드시 옵니다. 그때 사람이 손대야 하면 그 인프라는 사람의 근무시간만큼만 살아 있습니다.
04결과
| 항목 | 실측 |
|---|---|
| 사내 서빙에 편성한 장비 | 15대 |
| 공개 인터넷에 노출한 추론 엔드포인트 | 0건 |
| 재부팅 후 복구에 필요한 수동 개입 | 0건 |
| 전력표 전수 대조로 정정한 항목 | 행 뒤바뀜 1 · 정격/실부하 혼용 1 |
| 모델 배정 수정 횟수 | 3회 (최대 모델 우선안 기각 포함) |
| 배정표에 명시한 값 | 장비별 남는 메모리 · 권장 컨텍스트 상한 |
| 구성원이 배워야 하는 새 도구 | 0건 (기존 디스코드 채널 유지) |
이 스택 위에 팀 메모리와 에이전트 시스템이 올라갔습니다. 6주 시점 계약 종료 때 배정표와 구성 절차는 인수인계 문서(202파일)에 그대로 들어갔습니다.
05재현 가능한 부분
같은 요건을 가진 조직이라면 다음 산출물은 그대로 이식할 수 있습니다. 고객사 고유 정보가 들어 있지 않은 부분입니다.
- 장비 배정 산정표. 상용 이용 조건 · 실 RAM · 양자화 형식 · KV cache 헤드룸 4열로 모델을 장비에 배정하고, 남는 메모리와 권장 컨텍스트 상한을 같이 적는 계산 방식.
- 전력표 대조 절차. 사내 장비 시트를 제조사 공식 측정값과 전수 대조하고 정격/실부하를 분리하는 검사 항목.
- 독립망 구성 절차. 사설 오버레이 네트워크로 장비를 묶고 공개 포트를 0으로 유지하는 구성과 그 검증 항목.
- 부팅 자동 기동·복구 유닛. 재부팅 후 사람 개입 없이 서비스가 돌아오게 만드는 등록 방식과 실패 시 재시도 규칙.
- 단일 진입점 봇 골격. 이미 쓰는 메신저를 창구로 삼아 인증·라우팅·로깅을 한 지점에 모으는 구성.
- 컷오버 체크리스트 템플릿. 야간 장비 교체 전에 쓰는 사전 설정·수행·검증 3단 체크리스트입니다. 리스크 레지스터(확률·영향·대응), 롤백 트리거와 15분 롤백 절차, 통합 검증표, 당일 금지 항목(펌웨어 업데이트·UPnP 활성화)을 한 문서에 넣어 인쇄해 들고 작업합니다. 이 고객사의 라우터·스위치 교체(3.5시간, 검증 30건, 리스크 16건 중 발생 0)에서 그대로 썼고, 못 잰 측정값은 못 잰 것으로 남기는 칸이 있습니다.
반대로 재현되지 않는 것도 분명히 적어 둡니다. 고객사의 장비 구성, 조직도, 업무 데이터, 내부 채널 규칙은 이관하지 않습니다. 같은 결과를 원한다면 요건을 다시 측정해서 배정표를 새로 계산하는 편이 빠릅니다.
같은 제약을 가진 환경을 검토 중이라면
bk@bkan.dev 문의 폼은 두지 않습니다. 메일 한 통이면 됩니다.