iop/IOP_ROADMAP_STATUS.md

IOP 로드맵 현황 및 진행 계획

작성 기준: 2026-06-15

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-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 검증

---

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 전환 진행 중 vLLM provider serving validation 진행 중 SGLang provider serving validation 계획 상태
주요 작업	OpenAI-compatible model 값을 queue group key로 사용하는 Edge-owned FIFO 정리 Node 후보별 capacity, in-flight, queued snapshot을 기준으로 dispatch 흐름 정리 vLLM OpenAI-compatible provider의 모델 조회와 chat 경로 검증 SGLang provider의 최소 serving 경로 검증 Provider별 adapter/config/target/model 매핑 기준 정리
완성 예정 기능	Edge model group queue scheduling MVP 같은 Edge 내부의 다중 Node 후보 순차 dispatch vLLM provider 최소 serving 검증 SGLang provider 최소 serving 검증

---

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 기반 완료 사용자/토큰/사용량/로그 추적과 Provider Catalog는 스케치 상태이며, 사용자 검토 후 계획으로 승격
주요 작업	사용자 단위 API/CLI/local inference 사용량 집계 범위 정리 Token, request, execution, provider usage 로그의 최소 수집 항목 정의 Control Plane/Client 또는 CLI에서 확인할 운영 상태 항목 정리 API, CLI, local inference provider를 구분하는 Provider Catalog 기준 정리 vLLM, vLLM-MLX, Lemonade, SGLang 등 로컬 디바이스 provider 상태 표현 정리
완성 예정 기능	사용량, 토큰, 로그 운영 추적 MVP Provider Catalog와 로컬 디바이스 상태 관리 MVP 운영자가 확인할 수 있는 provider/status/usage 최소 화면 또는 명령 표면

---

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

구분	내용
목표	CLI Agent 사용량 limit 감지와 알림, 작업 자동 이어받기, workspace-bound execution 기반 원격 작업 환경을 feature MVP로 정리합니다. 동시에 planner/generator/verifier 형태의 단계 호출과 runtime schema 검증은 최소 실행 모드로 스케치합니다.
예상 투입인원	1명
현재 구현 상태	CLI runtime과 usage checker 계열 기반 마련 알림 자체는 nexo의 messaging/notification 기반을 활용할 수 있는 상태 socket/protocol 기반은 proto-socket의 안정화 결과를 활용할 수 있는 상태 CLI Agent 알림/자동 이어받기, 원격 작업 환경, 단계 호출 검증 MVP는 스케치 상태이며 사용자 검토 후 계획으로 승격
주요 작업	CLI Agent limit 도달 이벤트와 사용자 알림 trigger 기준 정리 자동 이어받기 허용 조건, 중단 조건, 사용자 승인 경계 정리 workspace-bound execution을 이용한 원격 코딩/유지보수 작업 환경의 최소 운영 흐름 정리 요청 의도 분석, 실제 작업, 검증/schema 강제, 오류 시 retry/fallback의 최소 단계 실행 흐름 정리 Nexo 알림 기반과 IOP 실행 이벤트의 연동 경계 정리
완성 예정 기능	CLI Agent 사용량 알림 MVP CLI Agent 자동 이어받기 MVP 원격 코딩/유지보수 작업 환경 MVP 단계 호출과 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 결과, vLLM/SGLang provider 검증 결과, provider별 adapter/config/target/model 매핑 기준
7월 ~ 8월	사용량/토큰/로그 추적 MVP 정의, Provider Catalog 초안, 로컬 디바이스 provider 상태 관리 기준, 운영 확인 표면 초안
8월 ~ 9월	CLI Agent 사용량 알림/자동 이어받기 MVP, 원격 작업 환경 MVP, 단계 호출과 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 구현보다 실제 장비와 런타임별 동작 검증이 일정 변수입니다. 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 전환과 vLLM provider serving validation입니다. 이 작업은 같은 Edge 안에서 동일 model 요청을 여러 Node 후보에 효율적으로 분산하고, 추가 local inference provider를 IOP의 운영 경로에 올리기 위한 1차 KPI의 속도/디바이스 효율 축입니다.

이후 7월부터 8월까지는 사용자/토큰/사용량/로그 추적과 Provider Catalog, 로컬 디바이스 provider 상태 관리를 정리합니다. 이 단계는 완성된 billing이나 enterprise IAM이 아니라, 운영자가 IOP의 사용량과 provider 상태를 확인할 수 있는 feature MVP를 목표로 합니다.

8월부터 9월까지는 CLI Agent 사용량 limit 알림, 자동 이어받기, 원격 코딩/유지보수 작업 환경, 단계 호출과 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차 고도화 후보를 별도로 검토합니다.