68 lines
8 KiB
Markdown
68 lines
8 KiB
Markdown
# IOP 로드맵
|
|
|
|
## 전체 목표
|
|
|
|
IOP(Inference Operations Platform)는 Control Plane - Edge - Node 계층 구조를 기반으로 모델 서빙과 CLI Agent/Automation 실행을 함께 운영하는 실행 오케스트레이션 플랫폼을 만든다.
|
|
내부 실행 모델은 `adapter + target`을 기준으로 하며, Edge가 로컬 실행 그룹의 상태와 라우팅을 소유하고 Control Plane은 Edge를 통해 시스템을 관찰하고 제어한다.
|
|
|
|
IOP는 NomadCode에 종속된 Agent Shell이 아니라, NomadCode와 외부 agent, 운영 CLI, Portal, 자동화 도구가 함께 소비할 수 있는 범용 추론/자동화 운영 엔진이다.
|
|
로드맵 전반에서 OpenAI-compatible API는 외부 클라이언트의 모델 기반 호출 표면으로, A2A API는 외부 agent의 agent-to-agent 작업 위임 표면으로, IOP native protocol은 운영 제어, logical session, background run, command, lifecycle event, remote terminal session 같은 IOP 고유 기능의 기준으로 둔다.
|
|
OpenAI-compatible API는 현재 chat completions baseline을 넘어 Responses API 호환 표면까지 지원해야 한다.
|
|
IOP native protocol은 proto-socket을 기본으로 하며, HTTP는 OpenAI-compatible/A2A/health/bootstrap처럼 필요한 경계에서만 사용한다.
|
|
A2A는 표면으로 유지하되, NomadCode가 A2A를 도입하는 시점은 현재 확정하지 않는다.
|
|
|
|
모델 선택, 로컬/클라우드 라우팅, 모델별 profile, token/속도/품질 최적화, 모델 호출 로그와 품질 평가는 IOP 책임으로 둔다.
|
|
특히 로컬 모델을 우선 활용하되, cloud fallback과 품질 평가를 결합해 엔터프라이즈 모델 서비스에 가까운 운영 품질을 목표로 한다.
|
|
RAG, context 구성/압축, web search, MCP 정책, tool policy, output validation, retry/fallback은 기본 모델 서빙과 부하 라우팅이 가능해진 뒤 확장한다.
|
|
|
|
## Phase 흐름
|
|
|
|
- Edge-Node 실행 기반: Edge-Node 소켓 실행 경로, Node adapter execution, CLI session, 최소 외부 입력 표면을 안정화한다.
|
|
- Automation Runtime과 Bridge 확장: Runtime과 Automation 실행 흐름을 공통화하고, agent 설치형/비설치형 대상 제어 경로를 분리해 확장한다.
|
|
- 서빙 라우팅과 최적화 기반: 로컬/클라우드 모델 서빙, 모델 profile, 부하 라우팅, 품질 평가 기준을 먼저 정리하고, 이후 RAG/web search/MCP/tool policy/검증 최적화로 확장한다.
|
|
- Control Plane과 Portal 운영: 여러 Edge를 관찰하고 운영하는 중앙 제어면과 Portal을 구축한다.
|
|
|
|
## Milestone 목록
|
|
|
|
상태 값은 `계획`, `진행 중`, `완료`, `보류`, `폐기` 중 하나만 사용한다. 진행 순서는 아래 목록의 위에서 아래 흐름으로 해석한다.
|
|
|
|
### Automation Runtime과 Bridge 확장
|
|
|
|
- [원격 터미널 브리지 POC](milestones/remote-terminal-bridge-poc.md) - 상태: 계획; 목표: Agent를 설치하기 어려운 host/device를 위해 Edge broker와 Node terminal transport 기반 원격 터미널 브리지 POC를 만든다.
|
|
- [Specialized Agent proto-socket 연결 기반](milestones/specialized-agent-proto-socket-foundation.md) - 상태: 계획; 목표: generic Node와 OTO 같은 specialized domain agent가 Edge와 proto-socket으로 직접 통신하기 위한 transport/handshake 책임 경계를 정리한다.
|
|
- [Agent Bootstrap과 OTO 등록](milestones/agent-bootstrap-oto-enrollment.md) - 상태: 계획; 목표: specialized domain agent의 bootstrap command 발급, 설치, 등록, 장기 credential 흐름을 설계한다.
|
|
|
|
### 서빙 라우팅과 최적화 기반
|
|
|
|
- [모델 서빙과 부하 라우팅](milestones/model-serving-load-routing.md) - 상태: 계획; 목표: Responses API를 포함한 OpenAI-compatible 모델 호출 표면, 로컬/클라우드 모델 runtime profile, 모델 선택, 부하 라우팅, 호출 로그와 품질 평가 기준을 IOP 책임으로 정리한다.
|
|
- [지식, 도구 정책, 검증 최적화](milestones/knowledge-tool-validation-optimization.md) - 상태: 계획; 목표: 기본 서빙과 부하 라우팅 이후 RAG, context 구성/압축, web search, MCP/tool policy, output validation, retry/fallback을 IOP 최적화 계층으로 확장한다.
|
|
|
|
### Control Plane과 Portal 운영
|
|
|
|
- [Control Plane과 Portal](milestones/control-plane-portal.md) - 상태: 계획; 목표: 여러 Edge를 연결하고 관찰하며 Edge 설정 변경, 명령 전달, 이벤트 수신을 담당하는 중앙 제어면과 Web Portal 운영면을 구축한다.
|
|
- [정책, 이력, 감사](milestones/policy-history-audit.md) - 상태: 계획; 목표: 권한, 정책, 실행 이력, 감사 로그를 제품 운영에 필요한 수준으로 확장한다.
|
|
- [Multi-Edge 운영](milestones/multi-edge-operations.md) - 상태: 계획; 목표: 여러 Edge group을 관찰하고 운영하는 fleet-level 기능을 구축한다.
|
|
|
|
## 아카이브 Milestone 요약
|
|
|
|
- Edge-Node 실행 스켈레톤 - 상태: 완료; 아카이브일: 2026-05-24; 요약: Edge와 Node 사이의 등록, 설정 전달, adapter execution, event streaming, command 응답을 한 실행 흐름으로 검증했다.; 핵심 산출물/근거: `go test ./...`, `make test-e2e`, field smoke 기준 통과.; 후속 영향: Edge 입력 표면과 CLI Automation Runtime 안정화의 기반이 됐다.
|
|
- Edge 입력 표면 - 상태: 완료; 아카이브일: 2026-05-24; 요약: OpenAI-compatible API와 A2A JSON-RPC API를 Edge 내부 `adapter + target` 실행 경로로 수렴시켰다.; 핵심 산출물/근거: OpenAI-compatible/A2A baseline과 `make test-e2e`의 Ollama 보조 smoke 통과.; 후속 영향: Responses API 확장은 모델 서빙과 부하 라우팅 Milestone에서 다룬다.
|
|
- CLI Automation Runtime 안정화 - 상태: 완료; 아카이브일: 2026-05-24; 요약: one-shot, persistent terminal, opencode SSE, codex exec 계열 CLI 실행 모드를 같은 adapter execution 모델 안에서 안정화했다.; 핵심 산출물/근거: `go test ./...`, mock smoke, `codex|opencode|antigravity|claude|claude-tui` profile smoke 통과.; 후속 영향: 원격 터미널 브리지 POC로 이어진다.
|
|
|
|
## 로딩 정책
|
|
|
|
- 일반 작업에서는 `agent-ops/roadmap/ROADMAP.md`를 매번 읽지 않는다.
|
|
- 기능 추가, 구조 변경, 스킬 추가/수정, 문서 구조 변경 작업을 수행할 때는 `agent-ops/roadmap/current.md`를 먼저 읽는다.
|
|
- `current.md`는 현재 작업 위치가 아니라 활성 Milestone 후보 목록이다.
|
|
- `current.md`에는 개인별 현재 작업 위치나 완료 상태를 기록하지 않는다.
|
|
- `current.md`의 활성 Milestone은 `agent-ops/roadmap/milestones/` 하위 문서만 가리키며, `agent-ops/roadmap/archive/**`는 포함하지 않는다.
|
|
- 요청 내용, 현재 브랜치, 변경 파일, 관련 코드 경로를 보고 가장 관련 있는 활성 Milestone 문서를 같은 세션에서 1회 읽는다.
|
|
- 활성 Milestone 둘 이상에 걸치면 필요한 Milestone 문서를 모두 읽고 작업 범위를 좁힌다.
|
|
- 활성 Milestone 밖의 작업이면 이 문서의 Milestone 목록을 확인하고 사용자에게 진행 또는 전환 여부를 확인한다.
|
|
- 이 문서는 로드맵 생성/갱신, Phase 전환, Milestone 추가/수정 요청이 있을 때만 읽는다.
|
|
- 상세 작업과 완료 기준은 각 Milestone 문서의 체크리스트로 관리한다.
|
|
- 완료 또는 폐기되어 아카이브된 Milestone은 이 문서의 `아카이브 Milestone 요약`에 당시 요약만 남기고, 아카이브 문서 링크나 상세 경로는 남기지 않는다.
|
|
- 상세 문서가 있는 `agent-ops/roadmap/archive/**`는 사용자가 명시적으로 요청한 경우에만 읽는다.
|
|
- 아카이브된 Milestone 문서는 최신 템플릿이나 스킬 규약에 맞춰 재포맷하지 않는다.
|
|
- 선택된 Milestone의 `구현 잠금` 섹션이 없거나 상태가 `잠금`이면 코드 구현, `agent-task` 구현 계획 생성, 세부 API/파일 구조 확정을 시작하지 않는다.
|
|
- `구현 잠금`이 없거나 잠긴 Milestone은 사용자가 "진행"을 요청해도 우회하지 않고, 먼저 Milestone 문서의 구현 구체화와 잠금 해제를 사용자에게 요청한다.
|