- Add provider catalog device status milestone tracking - Implement catalog status HTTP endpoints - Add client catalog view implementation - Update control-plane HTTP views and tests - Update edge cmd nodes and tests - Update roadmap and phase documentation
16 KiB
IOP 로드맵 현황 및 진행 계획
작성 기준: 2026-06-20
1. 월별 로드맵
5월 ~ 6월 중순: 핵심 실행 기반 구축 완료
| 구분 | 내용 |
|---|---|
| 목표 | Control Plane - Edge - Node 구조의 기본 실행 경로를 구축하고, OpenAI-compatible 입력 표면과 CLI Agent/Automation 실행 기반을 실제 운영 가능한 방향으로 정리합니다. |
| 예상 투입인원 | 1명 |
| 현재 구현 상태 | Edge-Node 소켓 실행 경로와 Node adapter execution 기반 완료 Ollama provider 기반 OpenAI-compatible chat completions 경로 안정화 Control Plane과 Flutter client를 통한 Edge/Node 운영 관찰 기반 구축 CLI Automation Runtime, persistent terminal, Codex/App Server 계열 실행 경로 정리 Domain Agent registry, bootstrap command, enrollment 경계 정리 OpenAI Responses input surface와 metadata.workspace 기반 workspace-bound agent execution contract 완료Workspace port/env 표준화로 Control Plane, Edge, Node, Client, OpenAI-compatible, A2A, wire, metrics, DB/cache 포트 기준 정렬 Node 단일 연결에서 여러 target/provider/model candidate를 다루는 multi-target serving 기반 완료 Provider availability, capacity, admission queue snapshot 기반 완료 Lemonade provider의 모델 조회, non-streaming/streaming chat 경로 검증 완료 Edge model group queue scheduling과 model route queue 정책 정합화 완료 |
| 완료된 기능 | Edge-Node 실행 기반 Ollama 서빙 안정화 기반 Control Plane과 Client 운영 기반 CLI Automation Runtime 안정화 Domain Agent Registry와 Bootstrap Command 발급 OpenAI-compatible Responses 입력 표면 OpenAI Workspace Agent Execution Contract Workspace port/env 표준화 Node multi-target serving 기반 Provider availability와 capacity queue 기반 Lemonade provider serving 검증 Edge model group queue scheduling MVP 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 기반 완료 Edge model group queue scheduling과 같은 Edge 내부의 다중 Node 후보 순차 dispatch 기반 완료 OpenAI-compatible model route queue 정책 정합화 완료vLLM provider serving validation 완료: provider boundary, DGX Spark vLLM container, config contract, 모델 조회/chat, streaming, split-host field smoke 검증 PASS 근거와 코드 레벨 완료 리뷰까지 정리하고 archive함 SGLang provider serving validation은 GX10 + Qwen3.6 35B NVFP4 field validation 결과 NVIDIA checkpoint 직접 로딩 실패와 vLLM 대비 낮은 throughput/KV 여유가 확인되어 현 조건에서 provider 채택을 폐기함 다음 활성 작업은 운영 관측 Phase의 Model Alias Provider Pool과 Provider Catalog 계획 마일스톤으로 전환됨 |
| 주요 작업 | 완료: OpenAI-compatible model 값을 queue group key로 사용하는 Edge-owned FIFO 정리완료: Node 후보별 capacity, in-flight, queued snapshot을 기준으로 dispatch 흐름 정리 완료: Model route Queue 정책 원천 정합화 완료: vLLM OpenAI-compatible provider의 config contract, 모델 조회, chat, streaming, split-host field smoke 검증 정리: SGLang provider는 현 field 조건에서 채택하지 않고 Provider Catalog/Qualification 후속 판단 후보로 분리 다음: models[] 기반 provider pool과 read-only Provider Catalog 계약 구현 계획 |
| 완성 예정 기능 | vLLM provider 최소 serving 검증 완료 SGLang provider field 판단 결과 정리 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의 기본 상태 관찰 경로 구축 Provider availability와 capacity snapshot 기반 완료 Model Alias Provider Pool과 Provider Catalog가 현재 활성 계획 마일스톤이며 SDD는 승인됨/잠금 해제 상태사용자/토큰/사용량/로그 추적과 Provider-Device-Model Qualification 리포트는 후속 스케치 상태 |
| 주요 작업 | models[]를 OpenAI-compatible model key이자 provider pool canonical routing key로 정리nodes[].providers[] 기반 provider 정의와 provider별 served model list 계약 정리Edge-owned target rewrite와 in_flight / capacity load-ratio provider 선택 정책 구현 계획API, CLI, local inference provider를 구분하는 read-only Provider Catalog 기준 정리 사용자 단위 API/CLI/local inference 사용량, token, request, execution 로그의 최소 수집 항목은 후속 MVP로 구체화 |
| 완성 예정 기능 | Model Alias Provider Pool과 Provider Catalog MVP Provider Catalog와 로컬 디바이스 상태 관리 MVP 사용량, 토큰, 로그 운영 추적 MVP 운영자가 확인할 수 있는 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 계열 기반 마련 OpenAI Workspace Agent Execution Contract 완료 알림 자체는 nexo의 messaging/notification 기반을 활용할 수 있는 상태socket/protocol 기반은 proto-socket의 안정화 결과를 활용할 수 있는 상태CLI Agent 알림/자동 이어받기, 원격 작업 환경, Update Plane, 단계 호출 검증 MVP는 스케치/계획 상태이며 사용자 검토 후 구체화 |
| 주요 작업 | CLI Agent limit 도달 이벤트와 사용자 알림 trigger 기준 정리 자동 이어받기 허용 조건, 중단 조건, 사용자 승인 경계 정리 workspace-bound execution을 이용한 원격 코딩/유지보수 작업 환경의 최소 운영 흐름 정리 Control Plane release view, Edge/Node update protocol, host-local manager, rollout/recovery 정책 스케치 요청 의도 분석, 실제 작업, 검증/schema 강제, 오류 시 retry/fallback의 최소 단계 실행 흐름 정리 Nexo 알림 기반과 IOP 실행 이벤트의 연동 경계 정리 |
| 완성 예정 기능 | CLI Agent 사용량 알림 MVP CLI Agent 자동 이어받기 MVP 원격 코딩/유지보수 작업 환경 MVP Update Plane 안정 프로토콜과 자체 업데이트 기반 스케치 단계 호출과 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 정리 Usage/log/provider status/CLI notification 흐름의 통합 검증 Control Plane/Client 운영 표면에서 확인해야 할 최소 상태 정리 실패/재시도/중단/복구 시나리오 점검 1차 범위와 2차 보류 범위의 문서 경계 정리 운영 전환 전 known limitation과 후속 보완 항목 정리 |
| 완성 예정 기능 | 1차 KPI 범위 feature MVP 통합 검증 결과 운영자 확인용 usage/provider/queue/agent 상태 기준 E2E smoke와 회귀 확인 기준 10월 이후 고도화 후보와 2차 범위 분리 결과 |
10월 이후: 2차 고도화 후보
| 구분 | 내용 |
|---|---|
| 목표 | 1차 KPI 범위의 feature MVP를 완료한 뒤, 장기 기억/RAG, advisor, context hook, 원격 터널링, oto scheduler/CI-CD 같은 고도화 항목을 별도 검토합니다. |
| 예상 투입인원 | 미정 |
| 주요 작업 | 장기 기억과 RAG update cycle 검토 Advisor와 local LLM context compression hook 검토 특정 Node CLI Agent 원격 터널링 POC 검토 oto 자동화 scheduler와 CI-CD 연동 검토 Cross-Edge/cloud fallback, 품질 평가 feedback 고도화 검토 |
| 완성 예정 기능 | 2차 고도화 후보별 검토 결과 1차 운영 결과를 반영한 우선순위 재정렬 구체화 가능한 항목의 별도 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차 고도화 후보를 별도로 검토합니다.