삼태연구소
SAMTAELABS삼태연구소
트렌드2026년 7월 12일·6분 읽기

클라우드 API 없이 LLM 돌리기 — Mesh LLM의 분산 추론 구조 (iroh.computer)

분산 LLM 추론외주 개발앱 개발 외주웹 개발 업체LLM 자체 호스팅AI 인프라개발 외주irohMesh LLM오픈소스 AI
클라우드 API 없이 LLM 돌리기 — Mesh LLM의 분산 추론 구조
목차(4)

한줄 요약

보유한 GPU 여러 대를 묶어 하나의 OpenAI 호환 API로 만드는 분산 LLM 추론 플랫폼, Mesh LLM이 등장했다.

무엇이 달라지나?

LLM을 실제 서비스에 붙이는 방법은 지금까지 거의 고정돼 있었다. OpenAI나 Anthropic 같은 대형 공급사의 API 키를 받아서, 프롬프트를 보내고, 응답을 받아 쓰는 구조다. 편리하지만 그만큼 대가가 따른다. 모델이 언제 바뀌는지, 내 데이터가 어디서 처리되는지, 가격이 언제 올라가는지 — 전부 공급사 마음이다.

Mesh LLM은 이 구조를 뒤집는다. 사무실 구석의 워크스테이션, 개발자 책상 아래 미니 PC, 클라우드 인스턴스까지 — 팀이 이미 보유한 GPU 머신들을 묶어 하나의 추론 클러스터처럼 동작시킨다. 외부 API를 호출하는 클라이언트 코드는 바꿀 필요가 없다. 엔드포인트만 http://localhost:9337/v1으로 바꾸면 기존 OpenAI SDK가 그대로 작동한다.

추론 요청이 들어오면 세 가지 방식 중 하나로 처리된다. 해당 노드에 GPU와 모델이 있으면 로컬에서 직접 실행하고, 모델을 이미 로드한 다른 피어가 있으면 그쪽으로 라우팅한다. 모델 자체가 너무 커서 어느 한 머신에도 올라가지 않는다면, "Skippy"라고 부르는 파이프라인 분할 방식으로 여러 노드에 레이어를 나눠 적재하고 활성화 값을 순차적으로 넘겨가며 추론을 완성한다. 235B 규모의 MoE 모델도 이 방식으로 소화할 수 있다고 알려졌다.

네트워크 계층에는 iroh가 깔린다. iroh는 공개키를 노드 식별자로 쓰는 QUIC 기반 P2P 라이브러리로, NAT 환경에서도 두 노드 사이에 직접 암호화 연결을 뚫어준다. 중앙 서버가 없고, 연결이 안 될 경우를 대비해 두 개 리전에 릴레이 서버를 운영한다. 프로토콜은 QUIC의 ALPN 협상 위에 세 가지 채널로 분리돼 있다. 일반 메시 트래픽(mesh-llm/1), 오너 제어 플레인(mesh-llm-control/1), 분할 모델의 활성화 전송(skippy-stage/2)이다. 하나의 QUIC 연결 안에서 첫 바이트 하나로 스트림 유형을 구분하는 방식이라 오버헤드가 낮다.

카탈로그에는 노트북에서 돌아가는 수억 파라미터급 모델부터 235B MoE 모델까지 40개 이상이 포함돼 있다. 소프트웨어 설치 용량은 약 18MB다.

실무에서 어떤 의미인가?

이 프로젝트가 흥미로운 이유는 기술보다 포지셔닝에 있다. LLM을 제품에 붙이는 팀 입장에서 클라우드 API 의존은 두 가지 위험을 동시에 안고 간다. 비용 예측 불가와 데이터 통제권 상실이다. 사용량이 늘수록 청구서가 올라가고, 정책이 바뀌면 대응할 레버가 없다.

반면 로컬 또는 프라이빗 클러스터 기반 추론은 제어권을 되찾는 대신 운영 복잡도가 올라가는 트레이드오프가 있었다. Mesh LLM이 노리는 지점이 여기다. 기존 OpenAI 클라이언트 코드를 그대로 두면서, 추론이 실제로 어디서 일어나는지를 팀 내부에서 결정할 수 있게 해준다.

개발 외주나 사내 AI 툴 개발을 검토 중인 팀이라면, 초기부터 "어떤 모델을 어디서 돌릴 것인가"를 기술 스택 결정에 포함시킬 필요가 있다. 클라우드 API가 항상 최선이 아닐 수 있고, 그 선택은 나중에 바꾸기가 생각보다 어렵다.

도입 전 체크포인트

Mesh LLM의 구조가 매력적으로 보여도, 실제 도입 전에 몇 가지를 짚어야 한다.

GPU 자산이 실제로 있는가. 이 구조는 이미 보유한 하드웨어가 있을 때 유리하다. 도입을 위해 새로 장비를 구매한다면 투자 회수 계산이 달라진다.

레이턴시 허용치는 어느 수준인가. 피어 라우팅이나 파이프라인 분할은 단일 GPU 로컬 추론보다 레이턴시가 높을 수 있다. 실시간 대화형 UX와 배치 처리는 요구사항이 다르다.

보안 정책과 충돌하지 않는가. 퍼블릭 메시에 참여할 경우 내부 데이터 흐름에 대한 보안 검토가 필요하다. 프라이빗 배포 구성이 가능하지만, 그에 맞는 운영 체계도 별도로 갖춰야 한다.

운영 인력이 준비돼 있는가. 클라우드 API는 공급사가 모델 버전과 인프라를 관리해준다. 자체 메시를 운영하면 그 책임이 팀 내부로 들어온다. 소프트웨어가 경량이더라도 운영 복잡도는 0이 아니다.

자주 묻는 질문

Q.기존 OpenAI API를 사용하는 코드를 그대로 쓸 수 있나?

그렇다. Mesh LLM은 OpenAI 호환 API를 `localhost:9337/v1`로 노출하기 때문에, 엔드포인트 주소만 바꾸면 기존 SDK와 클라이언트 코드가 그대로 작동한다. 애플리케이션 코드 자체를 수정할 필요가 없다는 점이 이 프로젝트의 핵심 설계 목표 중 하나다. 단, 사용 중인 모델이 카탈로그에 포함돼 있어야 하고, 해당 모델을 돌릴 수 있는 하드웨어가 메시 안에 있어야 한다.

Q.단일 머신에 올라가지 않는 대형 모델은 어떻게 처리하나?

"Skippy"라고 불리는 파이프라인 분할 방식을 사용한다. 모델의 레이어를 범위별로 나눠 여러 노드에 분산 적재하고, 각 노드가 자신의 레이어 구간을 처리한 뒤 활성화 값을 다음 노드로 넘기는 방식이다. 이 과정은 클라이언트에게 완전히 투명하게 처리된다. 별도의 ALPN 채널(`skippy-stage/2`)이 활성화 전송에 쓰여 레이턴시를 최소화하는 구조로 보인다.

Q.퍼블릭 메시와 프라이빗 배포 중 어떤 걸 선택해야 하나?

내부 데이터나 기밀 프롬프트를 다루는 팀이라면 프라이빗 배포가 적합하다. 퍼블릭 메시는 자체 GPU가 부족할 때 다른 참여자의 자원을 활용할 수 있다는 장점이 있지만, 데이터가 외부 노드를 경유할 가능성이 생긴다. 어떤 구성이든 iroh의 공개키 기반 인증과 QUIC 암호화가 적용되지만, 보안 정책이 엄격한 환경에서는 프라이빗 배포를 기준으로 검토하는 것이 안전하다. 📌 원문: [iroh.computer/blog/mesh-llm](https://www.iroh.computer/blog/mesh-llm) 🔗 새로운 기술 도입이나 기술 검토가 필요하다면 → [삼태연구소에 문의하기](/contact)

이 기술을 우리 서비스에 도입하려면? 24시간 내 답변드립니다

누적 매출 20억 / 1인 에이전시. 중간 과정 없이 의도 그대로.

관련 아티클

관련 사례

이 글의 키워드와 맞닿은 실제 개발 사례를 함께 보세요.