OpenMakeOpenMake는 무엇인가
데이터와 모델과 에이전트를 스스로 통제해야 하는 조직을 위한 오픈웨이트 AI 인프라입니다. 기업이 자체 모델을 선택하고, 자체 데이터를 연결하고, 직원들이 AI를 사용하고, Agent에게 실제 업무를 시키면서, 권한·외부통신·비용·실행·감사를 기업 스스로 통제합니다.
온프레미스는 제품이 아닙니다. 고객 VPC, 프라이빗 클라우드, 사내 GPU 클러스터, 폐쇄망과 나란히 놓이는 배포 옵션 중 하나일 뿐입니다. 제품은 그 모든 환경에서 동일하게 남는 플랫폼이고, 그래서 판매 문장도 “저희가 서버 구축해드립니다”가 아니라 “귀사의 보안 경계 안에 귀사 전용 AI Platform을 구축합니다”가 됩니다.
- Open-weight: Qwen, EXAONE, Llama, Mistral, OpenAI 호환 엔드포인트를 언제든 교체할 수 있어, 특정 상용 공급자가 기업의 AI를 소유하지 않습니다
- Private: 어느 환경에서 돌든 데이터 경계는 기업이 소유합니다
- Agentic: 질문과 답으로 끝나지 않고 문서 조회, 분석, 내부 DB 조회, 웹 조사, 파일 작성, 검증, 승인, 결과 저장까지 수행합니다
- 오픈소스: 런타임이 MIT 라이선스로 공개되어, 운영자가 실행되는 코드를 직접 검증하고 고치고 사설 포크로 운영할 수 있습니다
OpenMake가 서야 할 자리
셀프호스팅 기업 시장은 이미 존재하고, 이미 돈이 오갑니다. Dify Enterprise는 VPC·온프레미스·폐쇄망 배포를 전면에 내세우고 SSO, RBAC, 감사로그, 데이터 주권을 판매합니다. Open WebUI도 셀프호스팅·온프레미스·에어갭 구조에서 SSO, LDAP, RBAC, Audit, Data Residency를 엔터프라이즈 핵심 가치로 제시합니다. OpenHands는 2026년 엔터프라이즈 제품을 아예 Agent Control Plane으로 재정의했습니다. 가치의 중심이 “AI가 잘 대답하게 하는 것”에서 “기업이 AI를 안전하게 운영하고 통제하는 것”으로 이동했습니다.
좋은 신호지만, 그대로 따라가는 것은 계획이 아닙니다. 프라이빗 ChatGPT는 Open WebUI와, 에이전트 워크플로 빌더는 Dify와, 코딩 에이전트는 OpenHands·Claude Code·Codex와 정면으로 부딪힙니다. OpenMake는 축을 달리 잡습니다. 기업이 소유한 오픈웨이트 모델 위에서 돌아가는, 일반 기업의 지식업무입니다.
Open WebUI
셀프호스팅 AI 인터페이스.
Dify
AI 앱·워크플로 빌더.
OpenHands
소프트웨어 개발에 집중한 에이전트 Control Plane.
Ollama / vLLM
모델 런타임.
OpenMake
오픈웨이트 기반 Private AI와 범용 Agent Runtime. 평범한 조직이 실제로 하는 지식업무를 대상으로 합니다.
다섯 개 운영 계층
이 계층이 없다면 기업이 운영할 수 있는 플랫폼이라기보다 멀티에이전트 프레임워크에 가깝습니다. 그래서 로드맵은 전문가 프로필 수가 아니라 운영 책임 단위로 정리합니다.
Agent Runtime
에이전트 작업을 지속 가능한 상태 머신으로 실행, 중단, 재개, 취소, 재시도, 복구합니다.
Control Plane
Identity, RBAC, 정책, 승인, 예산, 시크릿, 조직 설정, 감사 규칙을 담당합니다.
Execution Plane
모델, 도구, 브라우저, 코드, 파일, API, MCP, 샌드박스 실행이 실제로 일어나는 계층입니다.
State & Memory
작업 상태, 체크포인트, 세션, 산출물, RAG, 범위가 있는 장기 메모리를 저장합니다.
Observability
실행 타임라인, 로그, 추적, 비용, 실패 이유, 평가 점수, 감사 보고서를 남깁니다.
왜 이 방향이 맞는가
이 방향은 OpenMake가 이미 가진 장점을 더 강하게 만듭니다. 오픈소스, 로컬 기반, 운영자 소유, 오픈웨이트 친화, 도구 실행, 투명한 실행 기록이 OpenMake의 차별점입니다. 에이전트 수로 경쟁하는 것은 금방 복제됩니다. 남의 경계 안에서 신뢰할 수 있게, 통제된 채로 실행되는 것으로 경쟁하는 것은 훨씬 어렵고 가치가 큽니다.
새 모델의 등장도 위협이 아니라 기회가 됩니다. 기업이 돈을 내는 이유는 Qwen 때문이 아니라 Qwen을 기업 시스템으로 만드는 관리·실행 계층 때문이어야 합니다. 더 좋은 오픈웨이트 모델이 나올수록 그 계층의 가치는 떨어지는 게 아니라 올라갑니다.
로컬 장점을 지킵니다
OpenMake는 로컬 모델 경로, 로컬 워크스페이스 브리지, Docker 샌드박스, 운영자가 통제하는 외부 공급자 경계를 직접 가질 수 있습니다.
진짜 병목을 해결합니다
이제 어려운 것은 모델 호출 자체가 아닙니다. 상태를 보존하고, 권한을 강제하고, 안전하게 재시도하고, 무슨 일이 있었는지 증명하는 것입니다.
Skill이 생태계 단위가 됩니다
외부 기여자는 workflow, tool, prompt, policy, evaluator, schema, test를 패키지로 추가할 수 있고, 모든 기능이 core 코드 변경이 되지 않아도 됩니다. 이 기여 순환을 가능하게 하는 전제가 MIT 라이선스입니다.
A2A의 역할이 선명해집니다
멀티에이전트 토론은 모든 요청에 붙는 비용이 아니라, 고위험 작업의 검증자와 리뷰어 계층이 됩니다.
openmake_llm은 어디까지 왔나
채팅과 로컬 LLM 플랫폼으로 보면 OpenMake는 이미 상당히 진행되어 있습니다. 통제되는 에이전트 런타임 관점에서도 durable execution core는 더 이상 빈칸이 아닙니다. 1.52.1 기준으로 에이전트 작업은 7개 상태 머신 위의 영속 row이고, 턴이 끝날 때마다 체크포인트를 남기고, 승인 대기로 멈추고, 프로세스가 재시작돼도 자동으로 재개되며, 자기 토큰 사용량을 기록합니다.
다만 두 가지 단서가 함께 붙습니다. 이 런타임의 대부분은 기본값이 꺼진 플래그 뒤에 있습니다. task sandbox, 동시성 큐, local executor, 자동 배정은 모두 opt-in이라 새로 설치한 환경은 우리가 운영하는 배포와 같지 않습니다. 그리고 내구성의 입도는 턴 단위입니다. 턴 중간에 프로세스가 죽으면 그 턴은 도구 부작용까지 포함해 다시 실행됩니다. 도구 호출 단위 저널이 아직 없기 때문입니다.
남은 공백은 더 좁고 구체적입니다. 턴 이하의 내구성, 실행 그래프, 범위가 있는 메모리, 조직용 Control Plane입니다.
Model Gateway와 로컬 라우팅: 높음
로컬 우선 게이트웨이, 역할별 모델 라우팅, 외부 공급자 어댑터, 토큰 계산, fallback은 플랫폼이 필요로 하는 model-runtime 계층에 꽤 가까이 와 있습니다. 사용자별 quota는 조회 실패 시 통과(fail-open)라, 지금은 강제 지점이 아니라 계측에 가깝습니다.
Durable Task Runtime: 높음
작업 row, queued와 paused를 포함한 7개 상태 머신, 턴 종료 시점 체크포인트, 체크포인트가 유효한 작업을 자동 재개하는 부팅 복구, 단계별 이벤트 로그, 스케줄, sandbox 또는 local executor 선택이 모두 동작합니다. 동시성 큐는 opt-in이며 단일 API 인스턴스의 프로세스 메모리에 있습니다. 영속되는 것은 queued 상태뿐입니다.
로컬 실행 표면: 높음
사용자 머신에서 도구를 실행하는 브리지는 이제 packages/local-bridge-core 하나의 구현이고, 그 위에 데스크톱 컴패니언·openmake-code CLI·SwiftUI 메뉴바 앱 세 클라이언트가 붙습니다. 경로 스코프, 실행 denylist, 우회 불가 사용자 확인, OS 샌드박스 프로파일이 모두 이 코어에 있으며, 로컬 작업 생성은 감사 로그로 남습니다.
Tool, Sandbox, Approval: 중간
MCP 도구, Docker 격리 외부 서버, task sandbox 도구, 파일과 브라우저 실행, 사람 승인 게이트, 브라우저 컨테이너의 네트워크 레벨 egress allowlist가 있습니다. 다만 아직 완전한 정책 강제 Tool Runtime은 아닙니다. 승인 대기는 메모리 상의 Promise이고, 재시작을 넘겨 살아남는 것은 paused 상태뿐입니다.
Execution Graph: 초기
저장되는 계획은 상태와 메모를 가진 평면 단계 목록이고, 실행 단계는 인덱스로 그 계획에 귀속됩니다. 각 노드가 의존성, 권한, 비용 한도, 재시도 정책, 출력, 완료 기준을 갖는 durable DAG는 아직 아닙니다.
Memory: 일부 구현
Procedural Memory는 실제로 동작합니다. 성공한 작업의 브라우저·스크립트 절차를 절차 스킬로 저장하고, 유사한 목표에서 모델에 다시 묻지 않고 재생합니다. Episodic은 저장이 아니라 파생입니다. 과거 유사 작업을 작업·단계 row에서 재구성해 압축 블록으로 주입합니다. 진짜 공백은 Semantic Memory입니다. 벡터 저장소가 없고, 사용자 메모리는 trigram 매칭으로 검색합니다.
Observability: 중간
OpenTelemetry 트레이싱, 단계별 이벤트 로그, audit log, metrics, 그리고 measure-first 게이트의 판정 근거를 렌더하는 주간 게이트 리포트가 있습니다. 골든 데이터셋 기반 라우팅·응답 평가는 CI 게이트로 돌고, 측정이 뒷받침하지 못한 라우팅 게이트 하나는 이미 반려했습니다. 아직 없는 것은 조직이 감사자에게 그대로 건넬 수 있는 1급 감사 보고서입니다.
기업용 Control Plane: 초기
JWT, 3종 role, bridge·chat 스코프를 갖는 API key, usage, admin 화면, 운영자 설정은 있습니다. 멀티테넌시는 시작 전입니다. 스키마에 tenant·project·workspace 컬럼 자체가 없고, 예산 정책, 데이터 반출 통제, 배포 승인도 이후 작업입니다.
개발 리소스를 어디에 쓰는가
개발 역량의 약 70%는 엔터프라이즈 기반에 속합니다. 소프트웨어 프로젝트와 팔 수 있는 제품 사이의 격차는 기능 하나가 아니라, 바로 앞 절에서 “초기”라고 적은 Control Plane입니다. 아래 네 구간이 그 격차를 메우는 순서입니다.
P0 — 반드시 필요
Organization/Tenant, RBAC, Project, Model Policy, Data Egress Policy, Audit, Secret Management, Usage/Budget.
P1
Execution Graph, Agent Policy, Sandbox Policy, Approval Workflow, Observability, 범위가 있는 Memory.
P2
SSO(OIDC·SAML), LDAP, SIEM 연동, Backup/Restore, HA, Kubernetes 배포.
P3
폐쇄망 설치, 오프라인 모델 레지스트리, 오프라인 스킬 레지스트리, 엔터프라이즈 업데이트 채널.
하나의 코드베이스, Community와 Enterprise
OpenMake는 오픈코어 구조로 갑니다. 강한 커뮤니티 에디션은 엔터프라이즈 사업과 경쟁하는 것이 아니라 그것을 가능하게 만드는 조건이기 때문입니다. 생태계 단위는 Skill입니다. 기여자가 런타임 전체를 이해하지 않고도 워크플로 하나를 패키지로 만들 수 있어야 합니다.
OpenMake Community — MIT, 무료
단일 조직, 로컬 모델, Agent Runtime, MCP, Skills, 기본 RAG, 기본 샌드박스. 사람들이 설치해서 계속 쓸 만큼은 강해야 합니다.
OpenMake Enterprise — 유료
Organizations, 고급 RBAC, SSO·LDAP, Policy Engine, Model Governance, Data Egress Control, Audit, Budget, 엔터프라이즈 배포, HA, 폐쇄망, 지원. 이 목록은 아직 하나도 구현되지 않았습니다. 스키마에 tenant·project 컬럼 자체가 없고, 지금은 모든 설치가 단일 조직입니다.
실행 노드가 되는 OpenMake Code
별도 프로젝트가 아니라, 같은 Control Plane 아래에서 사내 PC의 로컬 파일·소스·터미널·내부망 작업을 수행하는 Execution Node가 됩니다. 이 정리는 이미 시작됐습니다. 브리지가 공용 코어로 옮겨간 뒤 Electron 셸은 저장소에서 내려갔고, 실행 노드는 네이티브 컴패니언과 CLI, 그리고 그 둘을 움직이는 웹으로 남았습니다.
그대로 가져갈 것
OpenMake 1.52.1에는 이미 로컬 우선 라우팅, 역할별 모델 배정, 에이전트 작업, 스킬, 내장 MCP 도구 22개, 도구 근거를 쓰는 딥 리서치, NotebookLM 그라운딩, 아티팩트, 운영자 제어가 있습니다. 데스크톱 컴패니언·openmake-code CLI·네이티브 메뉴바 앱이 함께 쓰는 하나의 로컬 작업 브리지 역시 버릴 것이 아니라 Control Plane 아래의 실행 노드로 재배치할 자산입니다.
- LLM Gateway는 게이트웨이로 유지합니다. 공급자 인증, 스트리밍, 토큰 계산, timeout, fallback, 모델별 파라미터 정규화가 책임입니다
- message pipeline은 요청 처리를 그대로 맡고, 계획은 재사용 가능한 실행 그래프, 필요 권한, 승인 지점, 비용 추정, 완료 기준을 만드는 저장형 Planner로 분리합니다
- A2A 토론은 기본 실행 경로가 아니라 고위험 계획, 코드 리뷰, 사실 교차검증, 결과 검수, 복합 의사결정 계층으로 옮깁니다
- RAG는 지식 검색 계층으로 두고, Working, Episodic, Semantic, Procedural, Artifact Memory는 별도 런타임 책임으로 나눕니다
새로 만들어야 할 코어
부족한 것은 또 하나의 전문가 프로필이 아닙니다. 서버 재시작 후에도 살아 있고, 턴이 끝날 때마다 체크포인트를 남기고, 승인 대기와 재개가 가능한 지속 실행 기반은 이제 제품에 들어와 있습니다. 아직 없는 것은 그 위층입니다. 런타임이 실행할 수 있는 그래프, 프롬프트가 아닌 곳에 사는 정책 계층, 범위가 있는 메모리입니다.
Durable Task Runtime — 구현됨
Task 모델, 상태 머신, 워커, 이벤트 로그, 체크포인트, 취소, 중단, 재개, 재시도. 나머지 계층이 딛고 설 기반입니다. 아직 열려 있는 것은 두 가지입니다. 멱등 재실행 — 턴 중간에 죽으면 그 턴의 도구 호출이 다시 실행됩니다 — 그리고 프로세스보다 오래 사는 큐입니다. 지금 큐는 opt-in이고 단일 프로세스 메모리에 있습니다.
Execution Graph — 계획
입력, 출력, 담당 에이전트, 모델, 도구, 권한, 제한시간, 재시도, 성공 기준, 비용 한도, 승인 여부를 가진 DAG 노드입니다. 지금 저장되는 계획은 평면 단계 목록입니다.
Policy and Approval — 일부 구현
읽기 전용 작업부터 외부 영향, 배포, 결제, 보안, 법률, 재무 작업까지 서버 코드에서 권한을 강제합니다. 지금은 승인 게이트가 그 일부를 대신하고, 뒤에 있어야 할 선언형 정책 엔진은 아직 없습니다.
Tool Runtime — 일부 구현
스키마, 권한 메타데이터, 실행 모드, timeout, 재시도, telemetry, 표준 결과 envelope을 가진 도구 레지스트리입니다. 도구 자체는 이미 돕니다. 내장 22종과 외부 MCP가 있지만, 이런 레지스트리 뒤에서 도는 것은 아닙니다.
Workspace Sandbox — 구현됨
작업별 워크스페이스, 허용 폴더 mount, 프로세스 또는 컨테이너 격리, 리소스 제한, 네트워크 allowlist, 결과 보존입니다. 이것은 이미 돌고 있습니다. 여기 적어 둔 이유는, 위 계층이 아직 정책이 아니라 개별 호출로 이곳에 닿기 때문입니다.
Memory and Audit — 일부 구현
출처, 신뢰도, 민감도, 만료가 있는 범위별 메모리와 계획, 모델 선택, 도구 호출, 비용, 승인, 실패, 재시도, 산출물 추적입니다. 절차 메모리와 추적은 이미 있고, 범위 메타데이터와 의미 저장소가 없습니다.
개발 순서
앞의 두 단계는 대체로 구현됐습니다. 그래서 다음으로 방어할 지점은 Execution Graph입니다. 작업 상태는 이제 신뢰할 수 있고, 아직 없는 것은 선형 턴 흐름 대신 노드마다 의존성, 권한, 완료 기준을 명시하는 계획입니다.
- 01
Durable Task Runtime — 구현 완료
Task 데이터 모델, 상태 머신, Job Queue, Worker, 저장된 실행계획, 체크포인트, 취소, 중단, 재개, 이벤트 로그가 제품에 들어가 있고, 작업별 토큰 사용량은 종료 전이 시점에 집계됩니다. 남은 것은 턴 이하의 내구성입니다. 죽은 턴이 부작용을 다시 실행하지 않도록 하는 도구 호출 단위 저널, 그리고 프로세스보다 오래 사는 큐입니다.
- 02
Tool, Approval, Sandbox — 대부분 완료
Tool Registry, MCP Gateway, 승인함, 작업별 Workspace, Docker Sandbox, Secrets, 파일 diff, 브라우저 egress allowlist가 있습니다. 남은 것은 서버에서 권한 등급을 강제하는 선언형 정책 엔진, 그리고 프로세스 메모리에만 있지 않고 재시작을 넘겨 살아남는 승인 대기입니다.
- 03
Execution Graph — 다음 단계
의존성, 필요 권한, 비용 한도, 재시도 정책, 출력, 완료 기준을 각 노드가 직접 갖는 DAG로, 선형 턴 루프를 대체하는 계획 단위입니다.
- 04
Agent와 Skill manifest — 진행 중
Supervisor, Planner, Worker, Researcher, Reviewer, Recovery 역할을 표준화하고, Skill을 workflow, prompt, policy, tool, evaluator, schema, test의 패키지 단위로 만듭니다. manifest 기반 스킬 주입과 절차 스킬 추출은 이미 시작됐습니다.
- 05
범위 메모리와 조직용 Control Plane
출처와 만료를 갖는 Working, Episodic, Semantic, Procedural, Artifact Memory. 이어서 멀티테넌시, 조직, 프로젝트, RBAC, 토큰과 비용 예산, 외부 모델 정책, 배포 승인, 운영 대시보드.
앞으로 12개월
아래 일정은 기능을 더 내놓는 계획이 아니라 실제 조직에서 제품을 증명하는 계획입니다. OpenMake를 업무망에 설치하고 매일 쓰는 기업 한 곳이 GitHub 스타 수천 개보다 가치가 큽니다.
기준이 되는 0개월은 이 로드맵을 확정한 2026년 8월입니다. 그래서 첫 구간은 앞으로 할 일이 아니라 지금 지나고 있는 구간이고, 그 안에서 이미 끝난 것은 아래에 표시했습니다.
- 0~3개월
제품 정체성 확정 — 지나는 중
끝난 것: Private AI 포지셔닝과 엔터프라이즈 아키텍처는 지금 이 페이지가 말하고 있는 내용이고, 대표 Use Case 3개는 바로 앞 절에 적혀 있으며, Audit 로그는 이미 한참 전부터 돌고 있습니다. 아직인 것: Organization과 Project는 스키마에 개념 자체가 없고, RBAC은 tenant·project 범위 없이 3종 역할에서 멈춰 있으며, Model Policy는 시작 전입니다. 다만 그 정책의 근거가 될 모델 측정은 OpenMake Bench에서 먼저 시작했습니다.
- 3~6개월
실제 기업에 적용
Design Partner 3곳, 프라이빗 VPC 배포, 온프레미스 배포, SSO, Data Policy, Skill 패키징.
- 6~9개월
구축이 아니라 제품으로
엔터프라이즈 인스톨러, 업그레이드와 백업, 모니터링, 관리자 대시보드, Kubernetes, 엔터프라이즈 가격 체계.
- 9~12개월
반복 판매 검증
실제 운영 고객, 케이스 스터디, 파트너, SI 협력, 엔터프라이즈 지원.
첫 Use Case는 일부러 좁게
첫 기업 데모는 사내 리서치·문서 에이전트 하나입니다. 대상은 외부 생성형 AI에 내부 자료를 넣기 어려운 30~500명 규모의 지식집약 조직입니다. 협회·단체, 연구기관, 공공 유관기관, 제조업 R&D 부서, 중견기업, 컨설팅사, 회계·법무 조직이 먼저이고, 대기업 금융권이나 국방은 뒤입니다. 그쪽은 제품보다 인증·조달·보안·SI 역량을 먼저 요구하기 때문입니다.
직원이 “지난 3년 계약서와 관련 규정을 분석해서 문제가 될 수 있는 조항을 찾아 보고서로 만들어줘”라고 요청합니다. 실행은 사내 문서 검색, RAG, 오픈웨이트 LLM 응답, 외부 검색 여부에 대한 Policy 확인, 추가 조사, 근거 검증, 보고서 작성, 담당자 승인, PDF·DOCX·엑셀 산출, Audit Log 저장 순으로 이어집니다. 내부 문서는 회사 통제 영역 밖으로 나가지 않습니다.
- 문서 분석: 업로드, 구조 분석, 데이터 추출, 교차검증, 보고서, 산출물 저장
- 리서치 작업: 검색 계획, 자료 수집, 출처 평가, 상충 정보 검증, 보고서
- 반복 업무 자동화: 정기 실행, 데이터 수집, 기준 비교, 이상 탐지, 보고, 승인 후 후속 작업
- 개발 작업은 계속 지원하지만 진입 지점으로 삼지 않습니다. 전용 코딩 에이전트들이 이미 겨루고 있는 시장이기 때문입니다
- 전문가 에이전트 수부터 늘리기, 모든 요청을 A2A로 처리하기, 프롬프트로 권한 통제하기, ChatService 계속 키우기, 통제 가능한 반자동 실행 전에 완전 자율을 약속하기는 하지 않습니다