iop/agent-ops/roadmap/ROADMAP.md

6.9 KiB

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 목록

상태 값은 계획, 진행 중, 완료, 보류, 폐기 중 하나만 사용한다. 진행 순서는 아래 목록의 위에서 아래 흐름으로 해석한다.

Edge-Node 실행 기반

  • Edge-Node 실행 스켈레톤 - 상태: 완료; 목표: Node 등록, 설정 전달, adapter execution, run event streaming, command request/response, field smoke 기준을 한 흐름으로 검증한다.
  • Edge 입력 표면 - 상태: 완료; 목표: OpenAI-compatible API와 A2A JSON-RPC API를 내부 adapter + target 실행 경로로 수렴시킨다.

Automation Runtime과 Bridge 확장

  • CLI Automation Runtime 안정화 - 상태: 완료; 목표: one-shot, persistent terminal, opencode SSE, codex exec 같은 CLI 실행 모드를 같은 adapter execution 모델 안에서 안정화한다.
  • 원격 터미널 브리지 POC - 상태: 계획; 목표: Agent를 설치하기 어려운 host/device를 위해 Edge broker와 Node terminal transport 기반 원격 터미널 브리지 POC를 만든다.
  • Specialized Agent proto-socket 연결 기반 - 상태: 계획; 목표: generic Node와 OTO 같은 specialized domain agent가 Edge와 proto-socket으로 직접 통신하기 위한 transport/handshake 책임 경계를 정리한다.
  • Agent Bootstrap과 OTO 등록 - 상태: 계획; 목표: specialized domain agent의 bootstrap command 발급, 설치, 등록, 장기 credential 흐름을 설계한다.

서빙 라우팅과 최적화 기반

  • 모델 서빙과 부하 라우팅 - 상태: 계획; 목표: Responses API를 포함한 OpenAI-compatible 모델 호출 표면, 로컬/클라우드 모델 runtime profile, 모델 선택, 부하 라우팅, 호출 로그와 품질 평가 기준을 IOP 책임으로 정리한다.
  • 지식, 도구 정책, 검증 최적화 - 상태: 계획; 목표: 기본 서빙과 부하 라우팅 이후 RAG, context 구성/압축, web search, MCP/tool policy, output validation, retry/fallback을 IOP 최적화 계층으로 확장한다.

Control Plane과 Portal 운영

  • Control Plane과 Portal - 상태: 계획; 목표: 여러 Edge를 연결하고 관찰하며 Edge 설정 변경, 명령 전달, 이벤트 수신을 담당하는 중앙 제어면과 Web Portal 운영면을 구축한다.
  • 정책, 이력, 감사 - 상태: 계획; 목표: 권한, 정책, 실행 이력, 감사 로그를 제품 운영에 필요한 수준으로 확장한다.
  • Multi-Edge 운영 - 상태: 계획; 목표: 여러 Edge group을 관찰하고 운영하는 fleet-level 기능을 구축한다.

로딩 정책

  • 일반 작업에서는 agent-ops/roadmap/ROADMAP.md를 매번 읽지 않는다.
  • 기능 추가, 구조 변경, 스킬 추가/수정, 문서 구조 변경 작업을 수행할 때는 agent-ops/roadmap/current.md를 먼저 읽는다.
  • current.md는 현재 작업 위치가 아니라 활성 Milestone 후보 목록이다.
  • current.md에는 개인별 현재 작업 위치나 완료 상태를 기록하지 않는다.
  • 요청 내용, 현재 브랜치, 변경 파일, 관련 코드 경로를 보고 가장 관련 있는 활성 Milestone 문서를 같은 세션에서 1회 읽는다.
  • 활성 Milestone 둘 이상에 걸치면 필요한 Milestone 문서를 모두 읽고 작업 범위를 좁힌다.
  • 활성 Milestone 밖의 작업이면 이 문서의 Milestone 목록을 확인하고 사용자에게 진행 또는 전환 여부를 확인한다.
  • 이 문서는 로드맵 생성/갱신, Phase 전환, Milestone 추가/수정 요청이 있을 때만 읽는다.
  • 상세 작업과 완료 기준은 각 Milestone 문서의 체크리스트로 관리한다.
  • 선택된 Milestone의 구현 잠금 섹션이 없거나 상태가 잠금이면 코드 구현, agent-task 구현 계획 생성, 세부 API/파일 구조 확정을 시작하지 않는다.
  • 구현 잠금이 없거나 잠긴 Milestone은 사용자가 "진행"을 요청해도 우회하지 않고, 먼저 Milestone 문서의 구현 구체화와 잠금 해제를 사용자에게 요청한다.