# IOP 로드맵 현황 및 진행 계획

작성 기준: 2026-06-20

# 1. 월별 로드맵

---

## 5월 ~ 6월 중순: 핵심 실행 기반 구축 완료

| 구분 | 내용 |
| --- | --- |
| 목표 | Control Plane - Edge - Node 구조의 기본 실행 경로를 구축하고, OpenAI-compatible 입력 표면과 CLI Agent/Automation 실행 기반을 실제 운영 가능한 방향으로 정리합니다. |
| 예상 투입인원 | 1명 |
| 현재 구현 상태 | Edge-Node 소켓 실행 경로와 Node adapter execution 기반 완료<br>Ollama provider 기반 OpenAI-compatible chat completions 경로 안정화<br>Control Plane과 Flutter client를 통한 Edge/Node 운영 관찰 기반 구축<br>CLI Automation Runtime, persistent terminal, Codex/App Server 계열 실행 경로 정리<br>Domain Agent registry, bootstrap command, enrollment 경계 정리<br>OpenAI Responses input surface와 `metadata.workspace` 기반 workspace-bound agent execution contract 완료<br>Workspace port/env 표준화로 Control Plane, Edge, Node, Client, OpenAI-compatible, A2A, wire, metrics, DB/cache 포트 기준 정렬<br>Node 단일 연결에서 여러 target/provider/model candidate를 다루는 multi-target serving 기반 완료<br>Provider availability, capacity, admission queue snapshot 기반 완료<br>Lemonade provider의 모델 조회, non-streaming/streaming chat 경로 검증 완료<br>Edge model group queue scheduling과 model route queue 정책 정합화 완료 |
| 완료된 기능 | Edge-Node 실행 기반<br>Ollama 서빙 안정화 기반<br>Control Plane과 Client 운영 기반<br>CLI Automation Runtime 안정화<br>Domain Agent Registry와 Bootstrap Command 발급<br>OpenAI-compatible Responses 입력 표면<br>OpenAI Workspace Agent Execution Contract<br>Workspace port/env 표준화<br>Node multi-target serving 기반<br>Provider availability와 capacity queue 기반<br>Lemonade provider serving 검증<br>Edge model group queue scheduling MVP<br>Model route queue 정책 정합화 |

---

## 6월 중순 ~ 7월: Edge model group queue와 추가 provider 검증

| 구분 | 내용 |
| --- | --- |
| 목표 | 같은 Edge 안에서 동일 `model` 요청을 model group queue로 묶고, 여러 Node 후보에 순차 dispatch하는 구조를 정리합니다. Lemonade 이후 vLLM과 SGLang provider 검증 결과를 반영해 1차 KPI 범위의 속도/디바이스 효율 축을 닫습니다. |
| 예상 투입인원 | 1명 |
| 현재 구현 상태 | Node-local admission/capacity 기반 완료<br>Edge model group queue scheduling과 같은 Edge 내부의 다중 Node 후보 순차 dispatch 기반 완료<br>OpenAI-compatible `model` route queue 정책 정합화 완료<br>vLLM provider serving validation 완료: provider boundary, DGX Spark vLLM container, config contract, 모델 조회/chat, streaming, split-host field smoke 검증 PASS 근거와 코드 레벨 완료 리뷰까지 정리하고 archive함<br>SGLang provider serving validation은 GX10 + Qwen3.6 35B NVFP4 field validation 결과 NVIDIA checkpoint 직접 로딩 실패와 vLLM 대비 낮은 throughput/KV 여유가 확인되어 현 조건에서 provider 채택을 폐기함<br>다음 활성 작업은 운영 관측 Phase의 `Model Alias Provider Pool과 Provider Catalog` 계획 마일스톤으로 전환됨 |
| 주요 작업 | 완료: OpenAI-compatible `model` 값을 queue group key로 사용하는 Edge-owned FIFO 정리<br>완료: Node 후보별 capacity, in-flight, queued snapshot을 기준으로 dispatch 흐름 정리<br>완료: Model route Queue 정책 원천 정합화<br>완료: vLLM OpenAI-compatible provider의 config contract, 모델 조회, chat, streaming, split-host field smoke 검증<br>정리: SGLang provider는 현 field 조건에서 채택하지 않고 Provider Catalog/Qualification 후속 판단 후보로 분리<br>다음: `models[]` 기반 provider pool과 read-only Provider Catalog 계약 구현 계획 |
| 완성 예정 기능 | vLLM provider 최소 serving 검증 완료<br>SGLang provider field 판단 결과 정리<br>Provider별 adapter/config/target/model 매핑 기준을 Provider Catalog 계약으로 승계 |

---

## 7월 ~ 8월: 운영 관측, 사용량 추적, Provider Catalog 정리

| 구분 | 내용 |
| --- | --- |
| 목표 | IOP를 여러 Edge, Node, CLI Agent, local inference provider와 함께 운영하기 위해 필요한 사용자/토큰/사용량/로그/provider 상태 관찰 기준을 1차 feature MVP 단위로 정리합니다. |
| 예상 투입인원 | 1명 |
| 현재 구현 상태 | Edge, Node, Control Plane, Client의 기본 상태 관찰 경로 구축<br>Provider availability와 capacity snapshot 기반 완료<br>`Model Alias Provider Pool과 Provider Catalog`가 현재 활성 계획 마일스톤이며 SDD는 승인됨/잠금 해제 상태<br>사용자/토큰/사용량/로그 추적과 Provider-Device-Model Qualification 리포트는 후속 스케치 상태 |
| 주요 작업 | `models[]`를 OpenAI-compatible model key이자 provider pool canonical routing key로 정리<br>`nodes[].providers[]` 기반 provider 정의와 provider별 served model list 계약 정리<br>Edge-owned target rewrite와 `in_flight / capacity` load-ratio provider 선택 정책 구현 계획<br>API, CLI, local inference provider를 구분하는 read-only Provider Catalog 기준 정리<br>사용자 단위 API/CLI/local inference 사용량, token, request, execution 로그의 최소 수집 항목은 후속 MVP로 구체화 |
| 완성 예정 기능 | Model Alias Provider Pool과 Provider Catalog MVP<br>Provider Catalog와 로컬 디바이스 상태 관리 MVP<br>사용량, 토큰, 로그 운영 추적 MVP<br>운영자가 확인할 수 있는 provider/status/usage 최소 화면 또는 명령 표면 |

---

## 8월 ~ 9월: CLI Agent 알림, 원격 작업 환경, Update Plane, 단계 호출 검증 MVP

| 구분 | 내용 |
| --- | --- |
| 목표 | CLI Agent 사용량 limit 감지와 알림, 작업 자동 이어받기, workspace-bound execution 기반 원격 작업 환경을 feature MVP로 정리합니다. 동시에 Edge/Node 자체 업데이트 기반과 planner/generator/verifier 형태의 단계 호출/runtime schema 검증은 최소 실행 모드로 스케치합니다. |
| 예상 투입인원 | 1명 |
| 현재 구현 상태 | CLI runtime과 usage checker 계열 기반 마련<br>OpenAI Workspace Agent Execution Contract 완료<br>알림 자체는 `nexo`의 messaging/notification 기반을 활용할 수 있는 상태<br>socket/protocol 기반은 `proto-socket`의 안정화 결과를 활용할 수 있는 상태<br>CLI Agent 알림/자동 이어받기, 원격 작업 환경, Update Plane, 단계 호출 검증 MVP는 스케치/계획 상태이며 사용자 검토 후 구체화 |
| 주요 작업 | CLI Agent limit 도달 이벤트와 사용자 알림 trigger 기준 정리<br>자동 이어받기 허용 조건, 중단 조건, 사용자 승인 경계 정리<br>workspace-bound execution을 이용한 원격 코딩/유지보수 작업 환경의 최소 운영 흐름 정리<br>Control Plane release view, Edge/Node update protocol, host-local manager, rollout/recovery 정책 스케치<br>요청 의도 분석, 실제 작업, 검증/schema 강제, 오류 시 retry/fallback의 최소 단계 실행 흐름 정리<br>Nexo 알림 기반과 IOP 실행 이벤트의 연동 경계 정리 |
| 완성 예정 기능 | CLI Agent 사용량 알림 MVP<br>CLI Agent 자동 이어받기 MVP<br>원격 코딩/유지보수 작업 환경 MVP<br>Update Plane 안정 프로토콜과 자체 업데이트 기반 스케치<br>단계 호출과 runtime schema 검증 MVP |

---

## 9월 ~ 10월: 1차 KPI 범위 통합 검증 및 안정화

| 구분 | 내용 |
| --- | --- |
| 목표 | 1차 KPI 범위에 포함된 feature MVP들을 통합하고, Control Plane - Edge - Node - Client - CLI Agent - provider 경로를 운영자가 확인 가능한 수준으로 안정화합니다. |
| 예상 투입인원 | 1명 |
| 주요 작업 | Edge model group queue와 provider serving 경로의 E2E smoke 정리<br>Usage/log/provider status/CLI notification 흐름의 통합 검증<br>Control Plane/Client 운영 표면에서 확인해야 할 최소 상태 정리<br>실패/재시도/중단/복구 시나리오 점검<br>1차 범위와 2차 보류 범위의 문서 경계 정리<br>운영 전환 전 known limitation과 후속 보완 항목 정리 |
| 완성 예정 기능 | 1차 KPI 범위 feature MVP 통합 검증 결과<br>운영자 확인용 usage/provider/queue/agent 상태 기준<br>E2E smoke와 회귀 확인 기준<br>10월 이후 고도화 후보와 2차 범위 분리 결과 |

---

## 10월 이후: 2차 고도화 후보

| 구분 | 내용 |
| --- | --- |
| 목표 | 1차 KPI 범위의 feature MVP를 완료한 뒤, 장기 기억/RAG, advisor, context hook, 원격 터널링, oto scheduler/CI-CD 같은 고도화 항목을 별도 검토합니다. |
| 예상 투입인원 | 미정 |
| 주요 작업 | 장기 기억과 RAG update cycle 검토<br>Advisor와 local LLM context compression hook 검토<br>특정 Node CLI Agent 원격 터널링 POC 검토<br>oto 자동화 scheduler와 CI-CD 연동 검토<br>Cross-Edge/cloud fallback, 품질 평가 feedback 고도화 검토 |
| 완성 예정 기능 | 2차 고도화 후보별 검토 결과<br>1차 운영 결과를 반영한 우선순위 재정렬<br>구체화 가능한 항목의 별도 milestone 승격 |

---

# 2. 단계별 산출물

| 구분　　　　　 | 주요 산출물　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 |
| ----------------| -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 5월 ~ 6월 중순 | Edge-Node 실행 기반, Ollama serving 안정화, Control Plane/Client 운영 기반, CLI Automation Runtime, Domain Agent registry/bootstrap, OpenAI Responses input surface, Workspace Agent Execution Contract, Workspace port/env 표준화, Lemonade provider 검증 결과 |
| 6월 중순 ~ 7월 | Edge model group queue scheduling과 model route queue 정책 정합화 결과, vLLM provider 검증 결과, SGLang provider field 판단 결과, provider별 adapter/config/target/model 매핑 기준　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　|
| 7월 ~ 8월　　　| Model Alias Provider Pool과 Provider Catalog MVP, 사용량/토큰/로그 추적 MVP 정의, 로컬 디바이스 provider 상태 관리 기준, 운영 확인 표면 초안　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 |
| 8월 ~ 9월　　　| CLI Agent 사용량 알림/자동 이어받기 MVP, 원격 작업 환경 MVP, Update Plane 안정 프로토콜/자체 업데이트 기반, 단계 호출과 runtime schema 검증 MVP, Nexo 알림 연동 경계　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 |
| 9월 ~ 10월　　 | 1차 KPI 범위 feature MVP 통합 검증 결과, E2E smoke 기준, 운영 전환 체크리스트, known limitation, 2차 범위 분리 결과　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 |
| 10월 이후　　　| 장기 기억/RAG, advisor/context hook, 원격 터널링, oto scheduler/CI-CD, cloud fallback/품질 평가 고도화 검토 결과　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　|

---

# 3. 주요 리스크 및 고려사항

| 리스크 및 고려사항 | 내용 |
| --- | --- |
| Provider 실장비 검증 | vLLM, SGLang, vLLM-MLX 등 local inference provider는 adapter 구현보다 실제 장비와 런타임별 동작 검증이 일정 변수입니다. SGLang은 현 field 조건에서 채택하지 않기로 정리했으며, 1차 범위에서는 provider별 전체 최적화보다 최소 serving 경로와 상태 표현을 우선합니다. |
| 사용량/토큰/로그 정책 결정 | 사용자 단위 usage, token, log 추적은 구현보다 보존 범위, 노출 범위, 제한 정책 결정이 중요합니다. Billing, chargeback, 조직 IAM, 장기 retention은 1차 범위에서 완성하지 않고 후속 구체화로 둡니다. |
| CLI Agent 자동 이어받기 안전 경계 | 자동 이어받기는 편의성이 크지만, 무제한 재시도나 의도하지 않은 실행 지속으로 이어지면 위험합니다. 1차에서는 limit 감지, 알림, 명시된 조건에서의 이어받기만 MVP로 다룹니다. |
| Nexo와 Proto Socket 기반 활용 | 알림 기반은 `nexo`, socket/protocol 기반은 `proto-socket`의 거의 완료된 기반을 활용하는 전제로 봅니다. IOP에서는 새 인프라를 다시 만들기보다 실행 이벤트, 알림 trigger, protocol compatibility, 운영 표면 고정에 집중합니다. |
| 2차 범위 유입 방지 | 장기 기억/RAG, advisor, context compression hook, 원격 터널링, oto scheduler/CI-CD는 1차 KPI 범위 밖으로 분리합니다. 1차 기간에는 스케치와 잠금 상태로 유지하고, 실제 구현 계획은 별도 검토 후 승격합니다. |

---

# 4. 보고용 요약

IOP는 현재 Control Plane - Edge - Node 기반의 실행 오케스트레이션 구조와 OpenAI-compatible 실행 표면을 상당 부분 구축한 상태입니다. Edge-Node 실행 경로, Ollama serving, Control Plane/Client 운영 기반, CLI Automation Runtime, Domain Agent registry/bootstrap, OpenAI Responses input surface, workspace-bound agent execution contract, Workspace port/env 표준화, Node multi-target serving, provider availability/capacity queue, Lemonade provider 검증, Edge model group queue scheduling, model route queue 정책 정합화까지 완료되었습니다.

현재 vLLM provider serving validation은 완료 및 archive 처리되었습니다. SGLang provider serving validation은 field validation 결과를 반영해 현 조건에서는 provider 채택을 폐기했습니다. Edge model group queue scheduling과 model route queue 정책 정합화는 완료된 기반으로 보고, 다음 활성 마일스톤은 운영 관측 Phase의 `Model Alias Provider Pool과 Provider Catalog`입니다.

이후 7월부터 8월까지는 `models[]` 기반 provider pool, Edge-owned target rewrite, load-ratio provider 선택, read-only Provider Catalog, 로컬 디바이스 provider 상태 관리를 정리합니다. 이 단계는 완성된 billing이나 enterprise IAM이 아니라, 운영자가 IOP의 사용량과 provider 상태를 확인할 수 있는 feature MVP를 목표로 합니다. 사용자/토큰/사용량/로그 추적과 Provider-Device-Model Qualification 리포트는 후속 마일스톤으로 이어집니다.

8월부터 9월까지는 CLI Agent 사용량 limit 알림, 자동 이어받기, 원격 코딩/유지보수 작업 환경, Update Plane 자체 업데이트 기반, 단계 호출과 runtime schema 검증 MVP를 구체화합니다. 알림 기반은 `nexo`, socket/protocol 기반은 `proto-socket`의 거의 완료된 기반을 활용하고, IOP는 실행 이벤트와 운영 정책, 업데이트 수렴, E2E 흐름 고정에 집중합니다.

9월부터 10월까지는 1차 KPI 범위에 포함된 feature MVP를 통합 검증하고 안정화합니다. 10월 이후에는 장기 기억/RAG, advisor, context hook, 원격 터널링, oto scheduler/CI-CD, cross-Edge/cloud fallback 같은 2차 고도화 후보를 별도로 검토합니다.
