feat: roadmap update - add new phases and milestones
- Add operational-observability-provider-management phase with milestones - Add new milestones for automation-runtime-bridge (CLI agent usage notification, OTO automation scheduler, remote workspace operations) - Add new milestones for knowledge-tool-optimization-extension (advisor context hook second wave, long-term memory RAG second wave) - Update existing milestones and phase documents - Add IOP_ROADMAP_STATUS.md for tracking
This commit is contained in:
parent
aca988db51
commit
274ed27375
16 changed files with 747 additions and 64 deletions
113
IOP_ROADMAP_STATUS.md
Normal file
113
IOP_ROADMAP_STATUS.md
Normal file
|
|
@ -0,0 +1,113 @@
|
|||
# IOP 로드맵 현황 및 진행 계획
|
||||
|
||||
작성 기준: 2026-06-15
|
||||
|
||||
# 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 경로 검증 완료 |
|
||||
| 완료된 기능 | 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 검증 |
|
||||
|
||||
---
|
||||
|
||||
## 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 전환 진행 중<br>vLLM provider serving validation 진행 중<br>SGLang provider serving validation 계획 상태 |
|
||||
| 주요 작업 | OpenAI-compatible `model` 값을 queue group key로 사용하는 Edge-owned FIFO 정리<br>Node 후보별 capacity, in-flight, queued snapshot을 기준으로 dispatch 흐름 정리<br>vLLM OpenAI-compatible provider의 모델 조회와 chat 경로 검증<br>SGLang provider의 최소 serving 경로 검증<br>Provider별 adapter/config/target/model 매핑 기준 정리 |
|
||||
| 완성 예정 기능 | Edge model group queue scheduling MVP<br>같은 Edge 내부의 다중 Node 후보 순차 dispatch<br>vLLM provider 최소 serving 검증<br>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의 기본 상태 관찰 경로 구축<br>Provider availability와 capacity snapshot 기반 완료<br>사용자/토큰/사용량/로그 추적과 Provider Catalog는 스케치 상태이며, 사용자 검토 후 계획으로 승격 |
|
||||
| 주요 작업 | 사용자 단위 API/CLI/local inference 사용량 집계 범위 정리<br>Token, request, execution, provider usage 로그의 최소 수집 항목 정의<br>Control Plane/Client 또는 CLI에서 확인할 운영 상태 항목 정리<br>API, CLI, local inference provider를 구분하는 Provider Catalog 기준 정리<br>vLLM, vLLM-MLX, Lemonade, SGLang 등 로컬 디바이스 provider 상태 표현 정리 |
|
||||
| 완성 예정 기능 | 사용량, 토큰, 로그 운영 추적 MVP<br>Provider Catalog와 로컬 디바이스 상태 관리 MVP<br>운영자가 확인할 수 있는 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 계열 기반 마련<br>알림 자체는 `nexo`의 messaging/notification 기반을 활용할 수 있는 상태<br>socket/protocol 기반은 `proto-socket`의 안정화 결과를 활용할 수 있는 상태<br>CLI Agent 알림/자동 이어받기, 원격 작업 환경, 단계 호출 검증 MVP는 스케치 상태이며 사용자 검토 후 계획으로 승격 |
|
||||
| 주요 작업 | CLI Agent limit 도달 이벤트와 사용자 알림 trigger 기준 정리<br>자동 이어받기 허용 조건, 중단 조건, 사용자 승인 경계 정리<br>workspace-bound execution을 이용한 원격 코딩/유지보수 작업 환경의 최소 운영 흐름 정리<br>요청 의도 분석, 실제 작업, 검증/schema 강제, 오류 시 retry/fallback의 최소 단계 실행 흐름 정리<br>Nexo 알림 기반과 IOP 실행 이벤트의 연동 경계 정리 |
|
||||
| 완성 예정 기능 | CLI Agent 사용량 알림 MVP<br>CLI Agent 자동 이어받기 MVP<br>원격 코딩/유지보수 작업 환경 MVP<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 결과, 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차 고도화 후보를 별도로 검토합니다.
|
||||
|
|
@ -17,11 +17,17 @@ A2A는 표면으로 유지하되, NomadCode가 A2A를 도입하는 시점은 현
|
|||
특히 로컬 모델을 우선 활용하되, cloud fallback과 품질 평가를 결합해 엔터프라이즈 모델 서비스에 가까운 운영 품질을 목표로 한다.
|
||||
RAG, context 구성/압축, web search, MCP 정책, tool policy, output validation, retry/fallback은 기본 모델 서빙과 부하 라우팅이 가능해진 뒤 확장한다.
|
||||
|
||||
## MVP 경계
|
||||
|
||||
1차 MVP는 다중 Node/디바이스의 model group queue와 추가 provider 검증, 운영을 위한 CLI Agent 사용량/알림, 사용자/토큰/사용량/로그 추적, provider catalog와 로컬 디바이스 상태 관찰, 단계 호출과 runtime schema 검증의 최소 실행 모드를 기준으로 둔다.
|
||||
`(2차)`로 분류한 장기 기억/RAG update loop, advisor, context compression hook, 특정 Node CLI agent의 원격 터널링, oto 기반 자동화 scheduler/CI-CD, cross-Edge/cloud fallback 고도화는 MVP 이후 스케치로 잠근다.
|
||||
새로 추가되는 MVP/2차 Milestone은 모두 사용자 검토 전까지 `구현 잠금: 잠금` 상태를 유지하고, 구현 계획이나 세부 API 확정은 별도 구체화 요청에서 다룬다.
|
||||
|
||||
## Phase 흐름
|
||||
|
||||
위에서 아래로 진행된 순서와 예정 흐름을 나타낸다.
|
||||
완료된 Phase도 로드맵에서 제거하지 않고, archive의 Phase 문서로 연결한다.
|
||||
완료, 검토중, 진행중, 계획 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
|
||||
완료, 검토중, 진행중, 계획, 스케치 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
|
||||
|
||||
- [완료] Edge-Node 실행 기반
|
||||
- 경로: `agent-roadmap/archive/phase/edge-node-execution-foundation/PHASE.md`
|
||||
|
|
@ -37,15 +43,19 @@ RAG, context 구성/압축, web search, MCP 정책, tool policy, output validati
|
|||
|
||||
- [진행중] 추론 서버 provider 확장
|
||||
- 경로: `agent-roadmap/phase/inference-provider-extension/PHASE.md`
|
||||
- 요약: NomadCode workspace 실행 계약이 닫힌 뒤 Ollama 경로 안정화 결과와 Node 단일 통로 멀티 타겟 서빙 기반을 기준선으로 삼아, provider 공통 상태 확인과 capacity queue 기반을 먼저 정리한 뒤 Lemonade를 우선 provider로 올리고 이후 vLLM/SGLang 같은 추가 provider의 adapter/config/target/model 매핑 표준선을 정리하는 단계다.
|
||||
- 요약: 1차 MVP의 속도 향상 축으로, 같은 Edge 안의 model group queue와 여러 Node 후보 순차 dispatch를 기준으로 다중 디바이스 효율을 높이고 Lemonade/vLLM/SGLang 같은 provider 검증을 이어가는 단계다.
|
||||
|
||||
- [계획] 운영 관측과 Provider 관리
|
||||
- 경로: `agent-roadmap/phase/operational-observability-provider-management/PHASE.md`
|
||||
- 요약: 사용자/토큰/사용량/로그 추적과 API/CLI/local inference provider catalog, 로컬 디바이스 provider 상태 관리를 MVP 운영 축으로 스케치한다.
|
||||
|
||||
- [계획] Automation Runtime과 Bridge 확장
|
||||
- 경로: `agent-roadmap/phase/automation-runtime-bridge/PHASE.md`
|
||||
- 요약: Runtime과 Automation 실행 흐름을 공통화하고, NomadCode 지원을 위한 OpenAI-compatible workspace agent 실행 계약을 닫았다. Agentless remote terminal bridge는 현재 활성 작업에서 제외하고 후순위 보류로 둔다.
|
||||
- 요약: CLI Agent 실행과 운영 자동화의 MVP 표면을 정리하고, 사용량 limit 알림/자동 이어받기를 우선 스케치하되 원격 터널링과 oto scheduler/CI-CD는 2차로 잠근다.
|
||||
|
||||
- [계획] 지식과 도구 최적화 확장
|
||||
- 경로: `agent-roadmap/phase/knowledge-tool-optimization-extension/PHASE.md`
|
||||
- 요약: Ollama serving 경로, 추가 provider 경로, 운영 기반이 안정화된 뒤 RAG, context 구성/압축, web search, MCP/tool policy, output validation, retry/fallback을 IOP 추론 최적화 계층으로 확장하는 단계다.
|
||||
- 요약: 로컬 모델 성능 향상 축으로 단계 호출, tool/schema 강제, 검증/retry/fallback의 MVP 실행 모드를 먼저 스케치하고, RAG 장기 기억, advisor, context hook은 2차로 분리한다.
|
||||
|
||||
## 로딩 정책
|
||||
|
||||
|
|
|
|||
|
|
@ -8,12 +8,13 @@
|
|||
|
||||
Runtime과 Automation 실행 흐름을 공통화하고, agent 설치형 대상과 비설치형 대상의 제어 경로를 분리해 확장한다.
|
||||
CLI 실행, specialized agent 등록, bootstrap/enrollment, OpenAI-compatible workspace agent 실행 계약을 서로 충돌하지 않는 운영 경로로 정리했다.
|
||||
NomadCode가 IOP를 실행 백엔드로 사용할 수 있도록 하는 Responses 기반 workspace agent 실행 계약은 완료되었고, 원격 터미널 브리지는 현재 활성 작업에서 제외해 후순위 보류로 둔다.
|
||||
NomadCode가 IOP를 실행 백엔드로 사용할 수 있도록 하는 Responses 기반 workspace agent 실행 계약은 완료되었고, 다음 MVP 후보는 CLI Agent 사용량 limit 알림과 자동 이어받기 같은 운영 기능이다.
|
||||
원격 터미널/CLI 터널링과 oto scheduler/CI-CD 자동화는 2차 스케치로 잠그고, 현재 활성 구현 범위로 끌어오지 않는다.
|
||||
|
||||
## Milestone 흐름
|
||||
|
||||
완료된 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획 또는 보류 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다.
|
||||
완료, 검토중, 진행중, 계획 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
|
||||
완료된 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획, 스케치 또는 보류 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다.
|
||||
완료, 검토중, 진행중, 계획, 스케치, 보류 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
|
||||
|
||||
- [완료] CLI Automation Runtime 안정화
|
||||
- 경로: `agent-roadmap/archive/phase/automation-runtime-bridge/milestones/cli-automation-runtime-stabilization.md`
|
||||
|
|
@ -75,9 +76,21 @@ NomadCode가 IOP를 실행 백엔드로 사용할 수 있도록 하는 Responses
|
|||
- 경로: `agent-roadmap/archive/phase/automation-runtime-bridge/milestones/openai-workspace-agent-execution-contract.md`
|
||||
- 요약: NomadCode가 IOP CLI를 직접 실행하지 않고 IOP Edge OpenAI-compatible HTTP 호출의 `metadata.workspace`와 task/source metadata만으로 내부 workspace-bound agent target이 해당 checkout에서 산출물을 만들 수 있게 하는 최우선 contract/serving hardening 작업이다.
|
||||
|
||||
- [보류] 원격 터미널 브리지 POC
|
||||
- [스케치] CLI Agent 사용량 알림과 자동 이어받기 MVP
|
||||
- 경로: `agent-roadmap/phase/automation-runtime-bridge/milestones/cli-agent-usage-notification-continuation.md`
|
||||
- 요약: CLI Agent limit 도달 감지, 사용자 알림, 작업 자동 이어받기의 MVP 경계를 스케치한다.
|
||||
|
||||
- [스케치] 원격 코딩/유지보수 작업 환경
|
||||
- 경로: `agent-roadmap/phase/automation-runtime-bridge/milestones/remote-workspace-operations-environment.md`
|
||||
- 요약: CLI Agent와 workspace-bound execution을 이용한 원격 코딩/유지보수 환경의 운영 경계를 스케치한다.
|
||||
|
||||
- [스케치] oto 자동화 스케줄러와 CI-CD 연동 (2차)
|
||||
- 경로: `agent-roadmap/phase/automation-runtime-bridge/milestones/oto-automation-scheduler-second-wave.md`
|
||||
- 요약: oto를 이용한 자동화, scheduler, CI-CD 연동은 MVP 이후 2차 후보로 스케치한다.
|
||||
|
||||
- [보류] 원격 터미널/CLI 터널링 POC (2차)
|
||||
- 경로: `agent-roadmap/phase/automation-runtime-bridge/milestones/remote-terminal-bridge-poc.md`
|
||||
- 요약: Agent를 설치하기 어려운 host/device를 위한 Edge broker와 Node terminal transport 기반 원격 터미널 브리지 POC는 provider/capacity 등 운영 품질 확장 뒤의 후순위 작업으로 보류한다.
|
||||
- 요약: Agent를 설치하기 어려운 host/device 또는 특정 Node의 CLI agent를 Socket 경유로 다른 원격지에 연결하는 터널링 POC는 MVP 이후 2차로 보류한다.
|
||||
|
||||
## Phase 경계
|
||||
|
||||
|
|
@ -86,4 +99,5 @@ NomadCode가 IOP를 실행 백엔드로 사용할 수 있도록 하는 Responses
|
|||
- 설치 가능한 대상은 bootstrap/enrollment 경로로, 설치가 어렵거나 일회성 유지보수 대상은 remote terminal bridge 경로로 구분한다.
|
||||
- OpenAI-compatible Responses 표면은 외부 모델 호출 호환을 위한 입력 표면이며, IOP 고유 운영 제어는 native protocol이나 명시 운영 API로 분리한다.
|
||||
- NomadCode 지원을 위한 `metadata.workspace` 실행 계약은 provider 확장, Lemonade 추가, remote terminal bridge보다 먼저 닫는다.
|
||||
- 원격 터미널 브리지 POC는 현재 활성 작업에서 제외하고, provider 상태/capacity queue와 추가 provider 검증 이후 재개 후보로 둔다.
|
||||
- CLI Agent 사용량 알림과 자동 이어받기는 기존 CLI usage checker와 runtime command 경계를 기준으로 스케치하되, 사용자 검토 전에는 세부 자동화 정책을 확정하지 않는다.
|
||||
- 원격 터미널/CLI 터널링 POC와 oto scheduler/CI-CD 연동은 현재 활성 작업에서 제외하고, provider 상태/capacity queue와 운영 관측 MVP 이후 재개 후보로 둔다.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
# Milestone: CLI Agent 사용량 알림과 자동 이어받기 MVP
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-roadmap/ROADMAP.md`
|
||||
- Phase: `agent-roadmap/phase/automation-runtime-bridge/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
CLI Agent가 limit에 도달했을 때 운영자가 인지하고, 필요한 경우 작업을 안전하게 이어받을 수 있는 MVP 경계를 스케치한다.
|
||||
기존 CLI usage checker와 runtime command/status 경로를 기준으로 삼되, 자동 이어받기의 정책과 사용자 승인 방식은 후속 구체화에서 결정한다.
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- [ ] limit 도달 알림을 지원할 CLI target 범위를 결정한다.
|
||||
- [ ] 자동 이어받기의 기본 정책과 사용자 승인 필요 여부를 결정한다.
|
||||
- [ ] 알림 표면을 Client, Control Plane, Edge CLI, 외부 webhook 중 어디까지 포함할지 결정한다.
|
||||
- [ ] 이어받기 실패, 중복 실행, 비용/limit 소진에 대한 MVP 안전장치를 정리한다.
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 결정 필요: 아래 체크리스트
|
||||
- [ ] limit 도달 시 자동 이어받기를 기본 on으로 둘지, 명시 승인 후 실행할지 결정한다.
|
||||
- [ ] 작업 이어받기 대상 CLI/provider 우선순위를 어떻게 정할지 결정한다.
|
||||
- [ ] 알림 채널과 사용자 확인 UX의 MVP 범위를 결정한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- CLI Agent usage/limit 상태 감지와 운영 알림 경계
|
||||
- limit 도달 시 작업 이어받기 후보 선정과 중복 실행 방지 기준
|
||||
- Client/Control Plane/Edge CLI/외부 webhook 알림 후보 정리
|
||||
- 자동 이어받기 정책을 세부 구현 전 검토 가능한 수준으로 분리
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [cli-ops] CLI Agent Operations
|
||||
|
||||
CLI Agent limit 상태와 작업 이어받기를 운영자가 이해하고 제어하기 위한 최소 capability를 묶는다.
|
||||
|
||||
- [ ] [limit-signal] CLI target별 usage/limit 신호와 MVP 지원 범위가 정리되어 있다.
|
||||
- [ ] [notify-surface] limit 도달 알림 표면 후보와 제외 범위가 정리되어 있다.
|
||||
- [ ] [continue-policy] 자동 이어받기 정책, 승인 방식, 안전장치 후보가 정리되어 있다.
|
||||
- [ ] [ops-review] 사용자가 알림/이어받기 MVP 범위와 2차 후보를 검토했다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 스케치 Milestone이며 기능 Task가 아직 충족되지 않았다.
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- 모든 CLI Agent의 limit parser 완성
|
||||
- 비용 최적화, 계정 회전, provider credential 자동 전환
|
||||
- oto scheduler/CI-CD 자동화
|
||||
- 원격 터미널/CLI 터널링
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `apps/node/internal/adapters/cli/status`, `apps/edge`, `apps/control-plane`, `apps/client`, `proto/iop/runtime.proto`
|
||||
- 표준선(선택): 자동화는 runtime command/status 경계를 재사용하고, 사용자가 검토해야 할 정책은 Milestone 잠금으로 유지한다.
|
||||
- 선행 작업: CLI Automation Runtime 안정화, OpenAI Workspace Agent Execution Contract
|
||||
- 후속 작업: 운영 관측과 Provider 관리, oto scheduler/CI-CD 연동
|
||||
- 확인 필요: limit 신호 범위, 알림 채널, 자동 이어받기 정책
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
# Milestone: oto 자동화 스케줄러와 CI-CD 연동 (2차)
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-roadmap/ROADMAP.md`
|
||||
- Phase: `agent-roadmap/phase/automation-runtime-bridge/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
oto를 이용한 자동화, scheduler, CI-CD 연동을 MVP 이후 2차 후보로 스케치한다.
|
||||
이 Milestone은 반복 작업 자동 실행과 운영 workflow 연결의 방향만 잡고, job schema, trigger, runner, secret policy는 후속 검토 전까지 확정하지 않는다.
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- [ ] oto가 IOP에서 맡을 책임과 외부 자동화 도구와의 경계를 결정한다.
|
||||
- [ ] scheduler trigger와 CI-CD 연동의 MVP 이후 우선순위를 결정한다.
|
||||
- [ ] secret, approval, audit, retry 정책의 최소 기준을 정리한다.
|
||||
- [ ] 기존 jobs/worker 구조와의 연결 방식을 결정한다.
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 결정 필요: 아래 체크리스트
|
||||
- [ ] oto를 IOP 내부 automation engine으로 둘지 외부 orchestrator 연동으로 둘지 결정한다.
|
||||
- [ ] scheduler와 CI-CD 중 2차에서 먼저 다룰 축을 결정한다.
|
||||
- [ ] 자동 실행에 필요한 approval/secret/audit 기본값을 결정한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- oto 기반 자동화와 scheduler/CI-CD 연동의 2차 후보 정리
|
||||
- trigger, approval, retry, secret, audit 경계의 초안
|
||||
- 기존 `packages/go/jobs`와 서비스 내부 worker 구조와의 연결 후보
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [oto-scheduler] Oto Scheduler
|
||||
|
||||
MVP 이후 자동화 scheduler와 CI-CD 연동 방향을 검토하기 위한 최소 산출물을 묶는다.
|
||||
|
||||
- [ ] [boundary] oto의 책임과 IOP runtime/automation 경계가 정리되어 있다.
|
||||
- [ ] [trigger-model] scheduler trigger와 CI-CD 연동 후보가 정리되어 있다.
|
||||
- [ ] [safety] secret, approval, audit, retry의 최소 정책 후보가 정리되어 있다.
|
||||
- [ ] [second-review] 사용자가 2차 자동화 범위와 우선순위를 검토했다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 스케치 Milestone이며 기능 Task가 아직 충족되지 않았다.
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- 1차 MVP 구현
|
||||
- CI/CD provider별 직접 integration 구현
|
||||
- secret store, audit retention, scheduler runtime 상세 schema 확정
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `packages/go/jobs`, `apps/control-plane`, `apps/edge`, `apps/worker`
|
||||
- 표준선(선택): 현재 Worker 구조는 각 Go 서비스 내부 공통 모듈을 우선하고, `apps/worker`는 placeholder 상태이므로 본격 구현 전 별도 domain rule 또는 구체화가 필요하다.
|
||||
- 선행 작업: CLI Agent 사용량 알림과 자동 이어받기 MVP, 운영 관측과 Provider 관리
|
||||
- 후속 작업: CI-CD provider integration, scheduler runtime, approval/audit 제품화
|
||||
- 확인 필요: oto 책임 경계, trigger 우선순위, safety 기본값
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Milestone: 원격 터미널 브리지 POC
|
||||
# Milestone: 원격 터미널/CLI 터널링 POC (2차)
|
||||
|
||||
## 위치
|
||||
|
||||
|
|
@ -9,6 +9,7 @@
|
|||
|
||||
Agent를 설치하기 어려운 host/device를 위해 원격 터미널 브리지 POC를 만든다.
|
||||
Edge는 terminal session broker가 되고, 대상에 도달 가능한 Node가 SSH/WinRM/serial/local shell 같은 terminal transport를 실행해 relay한다.
|
||||
특정 Node의 CLI agent를 Socket 경유로 다른 원격지에 연결하는 터널링 제어는 MVP 이후 2차 후보로 함께 검토한다.
|
||||
|
||||
## 상태
|
||||
|
||||
|
|
@ -25,6 +26,7 @@ Edge는 terminal session broker가 되고, 대상에 도달 가능한 Node가 SS
|
|||
## 범위
|
||||
|
||||
- CLI persistent terminal profile 기반 remote shell POC
|
||||
- 특정 Node의 CLI agent를 Socket 기반으로 다른 원격지에 연결하는 터널링 후보
|
||||
- terminal session open/input/output/resize/signal/close event 모델 초안
|
||||
- Edge가 session broker, Node가 terminal transport 실행자라는 책임 경계 검증
|
||||
- 대상 접근 경로와 credential이 있는 경우만 제어할 수 있다는 전제 명시
|
||||
|
|
@ -65,4 +67,5 @@ Edge는 terminal session broker가 되고, 대상에 도달 가능한 Node가 SS
|
|||
- 선행 작업: Edge-Node 실행 스켈레톤, CLI Automation Runtime 안정화
|
||||
- 후속 작업: 정책, 이력, 감사; Control Plane과 Client의 terminal session 운영 표면
|
||||
- 보류 사유: 2026-06-14 사용자 지시에 따라 원격 터미널 지원은 현재 활성 작업에서 제외하고 로드맵 후순위로 미룬다. provider 상태/capacity queue와 추가 provider 검증 등 운영 품질 확장을 먼저 진행한다.
|
||||
- 2차 표기: Outline의 특정 Node CLI agent 원격 터널링 요구를 이 Milestone의 후속 후보로 묶되, MVP 구현 범위에서는 제외한다.
|
||||
- 확인 필요: bootstrap/enrollment 대상과 remote terminal bridge 대상의 구분. 설치 가능한 대상은 bootstrap/enrollment 경로로, 설치가 어렵거나 일회성 유지보수 대상은 remote terminal bridge 경로로 구분한다.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,72 @@
|
|||
# Milestone: 원격 코딩/유지보수 작업 환경
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-roadmap/ROADMAP.md`
|
||||
- Phase: `agent-roadmap/phase/automation-runtime-bridge/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
CLI Agent와 workspace-bound execution을 이용해 원격 코딩 환경과 원격 유지보수 환경을 운영할 수 있는 경계를 스케치한다.
|
||||
이미 완료된 OpenAI-compatible workspace agent 계약을 기준으로 삼되, 실제 제품 UX와 보안/권한 정책은 별도 검토 전까지 확정하지 않는다.
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- [ ] 원격 코딩과 원격 유지보수 중 1차 MVP에서 우선할 사용 사례를 결정한다.
|
||||
- [ ] workspace 접근, artifact, 승인, 취소, 결과 회수의 최소 운영 흐름을 정리한다.
|
||||
- [ ] Control Plane/Client/Edge CLI 중 어떤 표면을 MVP에 포함할지 결정한다.
|
||||
- [ ] 원격 터미널/CLI 터널링 POC와의 경계를 정리한다.
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 결정 필요: 아래 체크리스트
|
||||
- [ ] 원격 코딩과 원격 유지보수 중 우선순위를 결정한다.
|
||||
- [ ] workspace 접근 권한과 승인 정책의 MVP 기준을 결정한다.
|
||||
- [ ] 결과 확인과 artifact 회수 표면을 어디에 둘지 결정한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- workspace-bound CLI Agent 실행 기반 원격 작업 환경
|
||||
- 원격 코딩, 유지보수, 결과 확인, artifact 회수의 MVP 흐름 후보
|
||||
- OpenAI-compatible `metadata.workspace` 계약과 IOP native 운영 표면의 책임 분리
|
||||
- 원격 터미널/CLI 터널링과 겹치지 않는 작업 위임 방식 정리
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [remote-workspace] Remote Workspace Operations
|
||||
|
||||
원격 작업을 세션과 workspace 중심으로 운영하기 위한 최소 산출물을 묶는다.
|
||||
|
||||
- [ ] [use-case] 원격 코딩/유지보수 MVP 사용 사례와 제외 범위가 정리되어 있다.
|
||||
- [ ] [workspace-flow] workspace 접근, 승인, 취소, artifact 회수 흐름 후보가 정리되어 있다.
|
||||
- [ ] [surface-boundary] OpenAI-compatible 호출 표면과 IOP native 운영 표면의 책임 경계가 정리되어 있다.
|
||||
- [ ] [ops-review] 사용자가 원격 작업 환경 MVP 범위와 2차 후보를 검토했다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 스케치 Milestone이며 기능 Task가 아직 충족되지 않았다.
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- Agent를 설치할 수 없는 host/device의 terminal tunneling
|
||||
- 모든 IDE/SCM/CI 시스템 통합
|
||||
- 상세 권한/audit schema 구현
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `apps/edge`, `apps/node`, `apps/control-plane`, `apps/client`, `agent-contract/provided/openai-compatible-api.md`
|
||||
- 표준선(선택): 외부 실행 호출은 OpenAI-compatible shape와 `metadata.workspace`를 유지하고, lifecycle/artifact/approval은 IOP native 운영 표면에서 다룬다.
|
||||
- 선행 작업: OpenAI Workspace Agent Execution Contract
|
||||
- 후속 작업: 원격 터미널/CLI 터널링 POC, 정책/이력/감사
|
||||
- 확인 필요: 우선 사용 사례, 권한/승인 기준, 결과 회수 표면
|
||||
|
|
@ -7,7 +7,7 @@
|
|||
## 목표
|
||||
|
||||
Ollama 경로가 안정화된 뒤, 그 결과를 기준선으로 삼아 Lemonade를 우선 provider로 올리고 이후 vLLM, SGLang 같은 추가 추론 서버 provider를 붙인다.
|
||||
이 Phase는 하나의 Node transport 위에서 여러 CLI profile, terminal gateway, 추론 엔진, model target을 함께 쓰는 구조를 기준선으로 삼고, provider별 adapter/config/target/model 매핑을 단계적으로 검증한다.
|
||||
이 Phase는 1차 MVP의 속도 향상 축으로, 하나의 Node transport 위에서 여러 CLI profile, terminal gateway, 추론 엔진, model target을 함께 쓰는 구조를 기준선으로 삼고, provider별 adapter/config/target/model 매핑을 단계적으로 검증한다.
|
||||
추가 provider를 붙이기 전에 Node가 Ollama/Lemonade/vLLM/SGLang 같은 provider의 최소 가용 상태를 공통 형태로 Edge에 제공하고, Edge가 OpenAI-compatible `model` 값을 group key로 삼아 capacity/queue/admission 상태를 소유하는 기준선을 선행한다.
|
||||
다만 현재 제품 우선순위에서는 NomadCode가 IOP Edge OpenAI-compatible Responses를 workspace agent 실행 백엔드로 사용할 수 있는 계약 하드닝이 먼저이며, 이 Phase의 provider/capacity 작업은 그 뒤의 운영 품질 확장으로 둔다.
|
||||
|
||||
|
|
@ -48,4 +48,4 @@ Ollama 경로가 안정화된 뒤, 그 결과를 기준선으로 삼아 Lemonade
|
|||
- 여러 추론 서버 provider 표준화는 Ollama 경로가 안정화된 결과와 Node 단일 통로 멀티 타겟 기준선을 함께 기준으로 삼아 진행한다.
|
||||
- provider 공통 상태 확인과 Edge-owned model-group capacity/FIFO queue는 추가 provider 검증 전에 필요한 기반으로 이 Phase에서 다룬다.
|
||||
- NomadCode `metadata.workspace` 기반 실행 계약과 `/v1/responses` workspace smoke가 충족되기 전에는 이 Phase를 제품 최우선 작업으로 끌어올리지 않는다.
|
||||
- model group alias, 여러 Node/Edge 후보 간 자동 부하 라우팅, cloud fallback, 품질 평가 feedback과 후속 최적화 계층은 이 Phase에서 다루지 않는다.
|
||||
- OpenAI-compatible `model` 값 기반의 같은 Edge 내부 후보 Node 순차 dispatch는 이 Phase에서 다루되, 별도 model group alias, cross-Edge 자동 부하 라우팅, cloud fallback, 품질 평가 feedback과 후속 최적화 계층은 이 Phase에서 다루지 않는다.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Node는 Edge가 dispatch한 실행을 수행하고 현재 실행 상태를 보
|
|||
- 같은 model group에 연결된 여러 Node 후보가 있어도 queue는 Edge에 하나만 두고, runnable slot이 생긴 Node로 순차 dispatch한다.
|
||||
- Node의 provider/adapter admission queue는 제거하거나 Edge dispatch 이후의 실행 안전장치 수준으로 축소한다.
|
||||
- Node command/capability snapshot의 queued/in-flight 의미를 Edge-owned runtime snapshot과 충돌하지 않게 정리한다.
|
||||
- OpenAI Chat Completions/Responses, A2A/console 경로가 같은 Edge-owned dispatch 경계로 수렴하는지 확인한다.
|
||||
- OpenAI Chat Completions/Responses 경로가 `model` 값 기반 Edge-owned queue를 우회하지 않게 하고, A2A/console은 별도 model group key를 만들지 않으면서 같은 Edge dispatch primitive를 공유할 수 있는 경계를 확인한다.
|
||||
|
||||
## 기능
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ Node는 Edge가 dispatch한 실행을 수행하고 현재 실행 상태를 보
|
|||
- [ ] [node-dispatch] Edge가 Node별 실행 가능 slot과 terminal run event를 기준으로 queue head를 다음 Node에 순차 dispatch한다.
|
||||
- [ ] [node-simplify] Node-local provider FIFO queue가 제거되거나 Edge dispatch 이후의 실행 안전장치로 축소되어, 각 Node가 queue owner가 되지 않는다.
|
||||
- [ ] [snapshot-contract] Edge-visible capacity/in-flight/queued snapshot이 Edge-owned model group 상태를 기준으로 표현되고 Node capability snapshot과 충돌하지 않는다.
|
||||
- [ ] [surface-coverage] OpenAI Chat Completions/Responses와 A2A/console 실행 경로가 Edge-owned queue 경계를 우회하지 않는다.
|
||||
- [ ] [surface-coverage] OpenAI Chat Completions/Responses 실행 경로가 `model` 값 기반 Edge-owned queue를 우회하지 않고, A2A/console 경로는 별도 model group key 없이 같은 Edge dispatch primitive와 충돌하지 않는다.
|
||||
- [ ] [verification] Edge-owned queue의 FIFO 순서, queue overflow/timeout, run terminal release, node disconnect release, multi-node dispatch가 테스트로 검증되어 있다. 검증: 대상 Go 패키지 테스트와 queue 관련 regression test가 통과한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
|
|
|||
|
|
@ -6,22 +6,31 @@
|
|||
|
||||
## 목표
|
||||
|
||||
Ollama serving 경로와 운영 기반이 안정화된 뒤, RAG, context 구성/압축, web search, MCP 정책, tool policy, output validation, retry/fallback을 IOP의 추론 최적화 계층으로 확장한다.
|
||||
Ollama serving 경로와 운영 기반이 안정화된 뒤, 단계 호출, tool/schema 강제, output validation, retry/fallback을 IOP의 추론 최적화 계층으로 확장한다.
|
||||
1차 MVP는 planner/generator/verifier 같은 단계 호출과 runtime schema 검증의 최소 실행 모드를 스케치하는 데 집중하고, RAG 장기 기억, advisor, context compression hook은 2차로 분리한다.
|
||||
이 Phase는 특정 Agent Shell에 종속되지 않고 OpenAI-compatible, A2A, IOP native protocol 중 맞는 표면에서 공통 최적화 책임을 제공하는 방향을 다룬다.
|
||||
|
||||
## Milestone 흐름
|
||||
|
||||
완료된 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획 또는 보류 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다.
|
||||
완료, 검토중, 진행중, 계획 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
|
||||
완료된 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획, 스케치 또는 보류 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다.
|
||||
완료, 검토중, 진행중, 계획, 스케치 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
|
||||
|
||||
- [계획] 지식, 도구 정책, 검증 최적화
|
||||
- [스케치] 단계 호출과 검증 최적화 MVP
|
||||
- 경로: `agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/knowledge-tool-validation-optimization.md`
|
||||
- 요약: RAG, context 구성/압축, web search, MCP/tool policy, output validation, retry/fallback을 IOP 최적화 계층으로 확장한다.
|
||||
- 요약: 요청 의도 분석, 실제 작업, 검증/schema 강제, 오류 시 회귀를 단계 호출 실행 모드의 MVP 후보로 스케치한다.
|
||||
|
||||
- [스케치] 장기 기억과 RAG 업데이트 사이클 (2차)
|
||||
- 경로: `agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/long-term-memory-rag-second-wave.md`
|
||||
- 요약: 특정 repo 장기 기억, RAG 저장소, update cycle, MCP 기반 context 절약은 MVP 이후 2차 후보로 스케치한다.
|
||||
|
||||
- [스케치] Advisor와 Context Hook 최적화 (2차)
|
||||
- 경로: `agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/advisor-context-hook-second-wave.md`
|
||||
- 요약: advisor 역할과 로컬 LLM hook 기반 context compression 최적화는 MVP 이후 2차 후보로 스케치한다.
|
||||
|
||||
## Phase 경계
|
||||
|
||||
- 이 Phase는 Ollama 경로가 안정적인 serving 경로로 검증된 뒤 시작한다.
|
||||
- 이 Phase는 Control Plane/Client 운영 기반 없이 현재 Ollama 안정화 Phase 안으로 당겨 구현하지 않는다.
|
||||
- 이 Phase는 Ollama 경로와 Edge model group queue가 안정적인 serving 경로로 검증된 뒤 시작한다.
|
||||
- 이 Phase는 Control Plane/Client 운영 기반과 운영 관측 MVP 없이 현재 provider 확장 Phase 안으로 당겨 구현하지 않는다.
|
||||
- 기본 `/v1/models`, `/v1/chat/completions`, Edge-Node relay, Ollama option/API passthrough 안정화는 `Ollama 서빙 안정화 기반` Phase 책임이다.
|
||||
- 추가 추론 서버 provider의 adapter/config/target/model 매핑 표준화는 `추론 서버 provider 확장` Phase 책임이다.
|
||||
- cloud fallback, 품질 평가 feedback, RAG, web search, MCP/tool policy, validation/fallback은 이 Phase 또는 그 이후의 확장 책임으로 둔다.
|
||||
- 단계 호출, schema 강제, validation/fallback은 1차 MVP 후보로 검토하되, 장기 기억/RAG, advisor, context hook, cloud fallback, 품질 평가 feedback은 2차 또는 그 이후의 확장 책임으로 둔다.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
# Milestone: Advisor와 Context Hook 최적화 (2차)
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-roadmap/ROADMAP.md`
|
||||
- Phase: `agent-roadmap/phase/knowledge-tool-optimization-extension/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
advisor 역할과 로컬 LLM hook 기반 context compression 최적화를 MVP 이후 2차 후보로 스케치한다.
|
||||
이 Milestone은 별도 조언자 모델, 작업 전후 hook, context 압축 정책의 방향만 잡고, 실제 hook runtime과 UI/UX는 후속 검토 전까지 확정하지 않는다.
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- [ ] advisor가 planner/verifier와 다른 책임을 갖는지 결정한다.
|
||||
- [ ] context compression hook을 어느 실행 지점에 붙일지 결정한다.
|
||||
- [ ] local LLM을 hook에 사용할 때의 비용, 지연, 품질 기준을 정리한다.
|
||||
- [ ] 사용자에게 advisor/context hook 결과를 노출할지 내부 정책으로 둘지 결정한다.
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 결정 필요: 아래 체크리스트
|
||||
- [ ] advisor를 별도 사용자 기능으로 노출할지 내부 최적화 역할로 둘지 결정한다.
|
||||
- [ ] context compression hook을 prompt 구성 전, 단계 전환, stream 종료 후 중 어디에 둘지 결정한다.
|
||||
- [ ] hook 실행에 local LLM을 우선할지 provider 선택 정책을 따르게 할지 결정한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- Claude advisor류 기능을 IOP 실행 모드와 분리해서 검토
|
||||
- local LLM hook 기반 context compression 최적화 후보
|
||||
- advisor/context hook의 결과 노출과 운영 관측 후보
|
||||
- 장기 기억/RAG와 충돌하지 않는 context 처리 경계
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [advisor-hook] Advisor and Context Hooks
|
||||
|
||||
MVP 이후 advisor/context hook 라인을 검토하기 위한 최소 산출물을 묶는다.
|
||||
|
||||
- [ ] [advisor-role] advisor와 planner/verifier의 책임 차이가 정리되어 있다.
|
||||
- [ ] [hook-points] context compression hook 후보 지점과 제외 범위가 정리되어 있다.
|
||||
- [ ] [quality-cost] hook 실행 비용, 지연, 품질 기준 후보가 정리되어 있다.
|
||||
- [ ] [second-review] 사용자가 2차 advisor/context hook 범위와 우선순위를 검토했다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 스케치 Milestone이며 기능 Task가 아직 충족되지 않았다.
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- 1차 MVP 구현
|
||||
- 특정 Agent Shell 전용 advisor UX
|
||||
- hook runtime 상세 구현
|
||||
- 장기 기억/RAG 저장소 구현
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `apps/edge`, `apps/node`, `packages/go/policy`, `packages/go/jobs`, `proto/iop`
|
||||
- 표준선(선택): advisor/context hook은 단계 호출 MVP와 RAG 장기 기억 라인 뒤에서 별도 2차 최적화로 검토한다.
|
||||
- 선행 작업: 단계 호출과 검증 최적화 MVP, 장기 기억과 RAG 업데이트 사이클 (2차)
|
||||
- 후속 작업: 품질 평가 feedback, context/policy 운영 관측
|
||||
- 확인 필요: advisor 노출 방식, hook 지점, local LLM/provider 선택 기준
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Milestone: 지식, 도구 정책, 검증 최적화
|
||||
# Milestone: 단계 호출과 검증 최적화 MVP
|
||||
|
||||
## 위치
|
||||
|
||||
|
|
@ -7,52 +7,52 @@
|
|||
|
||||
## 목표
|
||||
|
||||
기본 모델 서빙과 부하 라우팅이 가능해진 뒤, RAG, context 구성/압축, web search, MCP 정책, tool policy, output validation, retry/fallback을 IOP의 추론 최적화 계층으로 확장한다.
|
||||
NomadCode는 이 계층의 소비자 중 하나이며, 이 Milestone은 특정 Agent Shell에 종속되지 않는 공통 IOP 책임을 정의한다.
|
||||
RAG에는 대규모 프로젝트의 문서/코드 변경을 따라가는 knowledge ingestion/update loop, chunking, embedding 생성, vector index 갱신, 권한 metadata 동기화 같은 비동기 작업 라인을 포함한다.
|
||||
검증 최적화에는 단순 부하 라우팅 이후의 실행 방식으로, Edge API 하네스 기반 검증/재시도 루프와 모델별 역할을 분리한 단계적 호출을 포함한다.
|
||||
로컬 모델 성능 향상을 위해 요청 의도 분석, 실제 작업, 검증과 runtime schema 강제를 나누는 단계 호출 실행 모드를 스케치한다.
|
||||
검증 실패 시 어느 단계로 되돌릴지, tool/schema 강제를 어느 경계에서 적용할지, 외부 소비자가 어떤 모드로 선택할지를 정하되, 세부 API와 구현은 사용자 검토 뒤 구체화한다.
|
||||
|
||||
## 상태
|
||||
|
||||
[계획]
|
||||
[스케치]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- [ ] 단계 호출의 MVP 역할 분리를 확정한다.
|
||||
- [ ] tool call/schema 강제와 output validation의 최소 책임 경계를 결정한다.
|
||||
- [ ] 검증 실패 시 회귀 정책과 사용자 노출 방식을 결정한다.
|
||||
- [ ] OpenAI-compatible metadata, A2A, IOP native 중 어떤 표면에서 실행 모드를 선택할지 결정한다.
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 결정 필요: 아래 체크리스트
|
||||
- [ ] 첫 최적화 범위를 RAG, web search, MCP/tool policy, validation/fallback 중 어디까지로 둘지 결정한다.
|
||||
- [ ] MCP/tool policy와 web search의 보안 기본값을 허용 중심으로 둘지 차단/승인 중심으로 둘지 결정한다.
|
||||
- [ ] validation/fallback의 품질 기준을 어떤 신호와 임계값으로 시작할지 결정한다.
|
||||
- [ ] RAG ingestion/update loop를 담당할 worker/background job 경계, index 저장소, 변경 감지 기준을 결정한다.
|
||||
- [ ] IOP 실행 모드 중 단순 부하 라우팅, 하네스 기반 검증/재시도 루프, 모델별 역할 분리 단계 호출의 우선순위와 최소 계약을 결정한다.
|
||||
- [ ] 1차 모델, 2차 모델, 3차 모델의 역할을 planner/generator/verifier로 나눌지 다른 이름과 경계로 둘지 결정한다.
|
||||
- [ ] runtime schema 강제를 Edge API, Node adapter, 별도 validation worker 중 어디에서 시작할지 결정한다.
|
||||
- [ ] 검증 실패 시 자동 retry/rollback을 기본으로 할지, 사용자 승인 뒤 재시도할지 결정한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- RAG 검색과 context 구성/압축 책임 경계
|
||||
- RAG/MCP 확장을 위한 knowledge ingestion/update loop, chunking, embedding 생성, vector index 갱신, incremental reindex, 권한 metadata 동기화 기준
|
||||
- web search를 IOP 지식 소스로 통합하는 기준
|
||||
- MCP allow/block/injection 정책과 tool policy 기준
|
||||
- output validation, retry/fallback, token/속도/품질 최적화 기준
|
||||
- Edge API 하네스 기반 검증/재시도 루프와 모델별 역할 분리 단계 호출을 IOP 실행 모드로 제공하는 기준
|
||||
- 모델 호출 로그와 품질 평가 결과를 후속 routing 판단에 연결하는 방향
|
||||
- 요청 의도 분석, tool call 계획, 실제 작업, 검증/schema 강제의 단계 호출 MVP 경계
|
||||
- validation 실패 시 planner/generator/verifier 중 어느 단계로 회귀할지에 대한 정책 후보
|
||||
- 단순 부하 라우팅과 하네스 기반 검증/재시도 모드의 책임 분리
|
||||
- 외부 소비자가 선택 가능한 실행 모드 후보
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [knowledge-policy] Knowledge and Tool Policy
|
||||
### Epic: [stage-validate] Staged Validation Mode
|
||||
|
||||
- [ ] [knowledge-policy] 지식 소스, context 구성/압축, MCP/tool policy, validation/fallback 책임 경계가 IOP 책임으로 문서화되어 있다.
|
||||
- [ ] [rag-index-loop] 대규모 프로젝트 RAG를 위한 ingestion/update loop, chunking, embedding 생성, vector index 갱신, incremental reindex, 권한 metadata 동기화, worker/background job 경계가 RAG/MCP 하위 라인으로 정리되어 있다.
|
||||
- [ ] [web-search-context] web search는 RAG/context 최적화 후보에 포함되어 IOP 지식 소스 경계에서 다룬다.
|
||||
- [ ] [client-surface] NomadCode와 다른 외부 agent는 OpenAI-compatible API를 기본 호출 표면으로 사용하고, IOP 전용 workspace/session/agent/policy 문맥은 별도 `iop` wrapper field가 아니라 `metadata` 확장 또는 IOP native endpoint의 명시 필드로 전달한다.
|
||||
- [ ] [shell-boundary] 특정 Agent Shell이나 Project Workspace UI 요구가 IOP 최적화 책임을 오염시키지 않도록 범위를 분리한다.
|
||||
- [ ] [validation-policy] 검증과 fallback은 모델 선택/라우팅 결과를 보완하는 IOP 내부 정책으로 정의하고, Edge API 하네스 기반 검증/재시도 루프를 그 실행 모드 중 하나로 정리한다.
|
||||
- [ ] [orchestration-modes] 단순 부하 라우팅, 하네스 기반 검증/재시도 루프, 모델별 역할 분리 단계 호출을 Cline 등 외부 소비자가 선택할 수 있는 IOP 실행 모드로 정리한다.
|
||||
단계 호출과 검증 모드를 구현 계획 전 검토 가능한 수준으로 나누는 산출물을 묶는다.
|
||||
|
||||
- [ ] [role-split] 의도 분석, 실제 작업, 검증/schema 강제의 MVP 역할 경계가 정리되어 있다.
|
||||
- [ ] [schema-policy] tool call과 runtime schema 강제의 최소 적용 지점 후보가 정리되어 있다.
|
||||
- [ ] [retry-route] 검증 실패 시 회귀와 retry/fallback 정책 후보가 정리되어 있다.
|
||||
- [ ] [mode-surface] 외부 소비자가 단계 호출 모드를 선택할 표면 후보가 정리되어 있다.
|
||||
- [ ] [mvp-review] 사용자가 단계 호출 MVP 범위와 2차 후보를 검토했다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 모든 기능 Task가 아직 충족되지 않았다.
|
||||
- 완료 근거: 스케치 Milestone이며 기능 Task가 아직 충족되지 않았다.
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
|
|
@ -60,20 +60,17 @@ RAG에는 대규모 프로젝트의 문서/코드 변경을 따라가는 knowled
|
|||
|
||||
## 범위 제외
|
||||
|
||||
- 기본 모델 serving/load routing 없이 RAG/MCP/validation부터 구현
|
||||
- RAG ingestion/update loop의 배치 형태와 저장소 계약 없이 embedding/indexing worker 구현부터 시작
|
||||
- NomadCode Agent Shell 자체 구현
|
||||
- NomadCode 전용 Project Workspace, diff/PR/branch/commit UX
|
||||
- OpenCode, Aider, Claude Code, Gemini CLI, Codex CLI adapter 직접 추가 구현
|
||||
- 장기 기억/RAG update loop 구현
|
||||
- Claude advisor류 별도 조언자 UX
|
||||
- 로컬 LLM hook 기반 context compression
|
||||
- cloud fallback과 품질 평가 feedback 제품화
|
||||
- 세부 API/schema 구현 확정
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `apps/edge`, `apps/node`, `apps/control-plane`, `apps/worker`, `packages/go/jobs`, `packages/go/policy`, `packages/go/observability`, `proto/iop`, `README.md`, `agent-roadmap/archive/phase/serving-routing-optimization/milestones/model-serving-load-routing.md`
|
||||
- 표준선(선택): 기본 모델 serving/load routing이 먼저 안정화된 뒤 최적화 계층을 붙인다.
|
||||
- 표준선(선택): 외부 실행 호출 계약은 OpenAI-compatible shape를 우선 유지하고, IOP 고유 문맥은 `metadata`로 확장한다. 완전 신규 프로토콜은 OpenAI-compatible 표면으로 lifecycle, artifact, cancel, approval, streaming 요구를 감당하기 어렵다는 근거가 생길 때 재검토한다.
|
||||
- 표준선(선택): 임베딩 생성/인덱싱 worker는 별도 불일치 항목이 아니라 RAG/MCP 확장을 운영 가능한 수준으로 만들기 위한 knowledge ingestion/update loop 하위 라인으로 본다. 배치 형태는 서비스 내부 worker 모듈과 별도 `apps/worker` 앱 후보를 함께 열어둔다.
|
||||
- 표준선(선택): Edge API 검증 재시도 루프는 단순 provider 라우팅과 충돌하는 책임이 아니라, IOP가 제공할 여러 실행 방식 중 하나인 하네스 기반 검증/재시도 모드로 본다.
|
||||
- 표준선(선택): 모델별 역할 분리 단계 호출은 planner/generator/verifier 같은 역할을 필요에 따라 나누고, 최종 응답은 Edge API 사용자가 선택한 모드의 결과로 반환하는 방향에서 검토한다.
|
||||
- 선행 작업: Ollama 서빙 안정화, Control Plane과 Client 운영
|
||||
- 후속 작업: 정책/이력/감사와 품질 기반 routing/fallback 고도화
|
||||
- 확인 필요: 첫 최적화 범위, tool/web 보안 기본값, validation/fallback 품질 기준, RAG update loop worker 배치 경계, IOP 실행 모드 우선순위와 최소 계약
|
||||
- 관련 경로: `apps/edge`, `apps/node`, `apps/control-plane`, `packages/go/policy`, `packages/go/jobs`, `proto/iop`, `agent-contract/provided/openai-compatible-api.md`
|
||||
- 표준선(선택): 외부 실행 호출 계약은 OpenAI-compatible shape를 우선 유지하고, IOP 고유 문맥은 `metadata`나 IOP native endpoint의 명시 필드로 전달한다.
|
||||
- 표준선(선택): 단계 호출은 단순 provider 라우팅과 충돌하는 책임이 아니라, 사용자가 선택할 수 있는 IOP 실행 모드 후보로 본다.
|
||||
- 선행 작업: Edge 모델 그룹 Queue 스케줄링 전환, 운영 관측과 Provider 관리
|
||||
- 후속 작업: 장기 기억과 RAG 업데이트 사이클 (2차), Advisor와 Context Hook 최적화 (2차)
|
||||
- 확인 필요: 역할 분리, schema 강제 지점, 회귀/retry 정책, 실행 모드 선택 표면
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
# Milestone: 장기 기억과 RAG 업데이트 사이클 (2차)
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-roadmap/ROADMAP.md`
|
||||
- Phase: `agent-roadmap/phase/knowledge-tool-optimization-extension/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
특정 repo에 대한 장기 기억 저장소, RAG 검색, update cycle, MCP 기반 context 절약을 MVP 이후 2차 후보로 스케치한다.
|
||||
이 Milestone은 knowledge ingestion/update loop의 필요성과 책임 경계만 잡고, embedding/index 저장소나 worker 배치 구현은 후속 검토 전까지 확정하지 않는다.
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- [ ] 장기 기억을 repo 단위, workspace 단위, organization 단위 중 어디서 시작할지 결정한다.
|
||||
- [ ] RAG update cycle의 trigger와 freshness 기준을 결정한다.
|
||||
- [ ] MCP를 context 절약 경계로 사용할지, IOP native knowledge endpoint를 우선할지 결정한다.
|
||||
- [ ] worker/background job 경계와 저장소 후보를 결정한다.
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 결정 필요: 아래 체크리스트
|
||||
- [ ] 장기 기억의 첫 저장 단위를 결정한다.
|
||||
- [ ] RAG update cycle을 수동, watcher, scheduler 중 어디서 시작할지 결정한다.
|
||||
- [ ] embedding/index 저장소와 권한 metadata 동기화 기준을 결정한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- 특정 repo 장기 기억 저장소의 2차 후보 정리
|
||||
- RAG ingestion/update loop, chunking, embedding, vector index, incremental reindex의 경계 초안
|
||||
- MCP를 통한 context size 절약 또는 IOP native knowledge endpoint 후보
|
||||
- 권한 metadata와 freshness 관리의 검토 항목
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [rag-memory] Long-Term Memory
|
||||
|
||||
MVP 이후 장기 기억/RAG 라인을 구체화하기 위한 최소 산출물을 묶는다.
|
||||
|
||||
- [ ] [memory-scope] 장기 기억 저장 단위와 제외 범위가 정리되어 있다.
|
||||
- [ ] [update-loop] RAG update cycle과 freshness 기준 후보가 정리되어 있다.
|
||||
- [ ] [mcp-context] MCP context 절약과 IOP native knowledge endpoint 후보가 비교되어 있다.
|
||||
- [ ] [second-review] 사용자가 2차 RAG/장기 기억 범위와 우선순위를 검토했다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 스케치 Milestone이며 기능 Task가 아직 충족되지 않았다.
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- 1차 MVP 구현
|
||||
- embedding/index 저장소 확정
|
||||
- worker/background job 구현
|
||||
- 모든 repo 권한 모델 확정
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `apps/worker`, `packages/go/jobs`, `packages/go/metadata`, `packages/go/policy`, `apps/edge`, `apps/control-plane`
|
||||
- 표준선(선택): 기본 모델 serving/load routing과 단계 호출 MVP가 먼저 안정화된 뒤 RAG/장기 기억을 붙인다.
|
||||
- 선행 작업: 단계 호출과 검증 최적화 MVP, 운영 관측과 Provider 관리
|
||||
- 후속 작업: context compression hook, 품질 기반 routing/fallback
|
||||
- 확인 필요: 저장 단위, update trigger, MCP/native 경계, storage/worker 후보
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# Phase: 운영 관측과 Provider 관리
|
||||
|
||||
## 상태
|
||||
|
||||
[계획]
|
||||
|
||||
## 목표
|
||||
|
||||
IOP가 여러 Edge, Node, CLI Agent, local inference provider를 운영할 때 필요한 사용자/토큰/사용량/로그/provider 상태 관찰 기준을 정리한다.
|
||||
이 Phase는 완성된 billing, enterprise IAM, provider marketplace를 바로 구현하지 않고, 1차 MVP에서 어떤 운영 데이터를 모으고 어떤 화면/명령으로 검토할지 스케치한다.
|
||||
|
||||
## Milestone 흐름
|
||||
|
||||
완료된 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획, 스케치 또는 보류 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다.
|
||||
완료, 검토중, 진행중, 계획, 스케치 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
|
||||
스케치 Milestone은 아직 구현 가능한 계획이 아니므로 사용자 검토와 구체화 후 `[계획]`으로 승격한다.
|
||||
|
||||
- [스케치] 사용량, 토큰, 로그 운영 추적 MVP
|
||||
- 경로: `agent-roadmap/phase/operational-observability-provider-management/milestones/usage-token-log-ops-mvp.md`
|
||||
- 요약: 사용자 관리, token 관리, API/CLI/local inference 사용량 집계, 로그 관리의 1차 운영 경계를 스케치한다.
|
||||
|
||||
- [스케치] Provider Catalog와 로컬 디바이스 상태 관리
|
||||
- 경로: `agent-roadmap/phase/operational-observability-provider-management/milestones/provider-catalog-device-status.md`
|
||||
- 요약: API, CLI, local inference provider를 같은 운영 catalog에서 보고 vLLM, vLLM-MLX, Lemonade, SGLang 같은 로컬 디바이스 provider 상태를 추적하는 경계를 스케치한다.
|
||||
|
||||
## Phase 경계
|
||||
|
||||
- Control Plane은 Edge/Node 상태를 보기 쉽게 연결하지만 Edge 내부 상태의 canonical store가 되지 않는다.
|
||||
- provider adapter 구현과 endpoint별 serving 검증은 `추론 서버 provider 확장` Phase 책임으로 둔다.
|
||||
- 이 Phase는 운영 데이터와 제어 표면의 MVP 경계를 다루며, billing/chargeback, 조직 IAM, 상세 audit schema, 장기 retention 정책은 후속 구체화에서 결정한다.
|
||||
- RAG, advisor, context compression hook, output validation 실행 모드는 `지식과 도구 최적화 확장` Phase 책임으로 둔다.
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
# Milestone: Provider Catalog와 로컬 디바이스 상태 관리
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-roadmap/ROADMAP.md`
|
||||
- Phase: `agent-roadmap/phase/operational-observability-provider-management/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
API provider, CLI provider, local inference provider를 운영자가 같은 catalog에서 볼 수 있는 MVP 경계를 스케치한다.
|
||||
vLLM, vLLM-MLX, Lemonade, SGLang 같은 로컬 디바이스 provider는 adapter 구현 자체가 아니라 상태, capability, 가용성, 운영 표시 기준을 우선 정리한다.
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- [ ] provider catalog가 다룰 provider category와 표시 필드를 결정한다.
|
||||
- [ ] local inference provider의 상태 추적 기준을 결정한다.
|
||||
- [ ] 기존 provider validation Milestone과 중복되지 않는 운영 책임 경계를 정리한다.
|
||||
- [ ] Control Plane/Client/CLI 중 provider 관리 MVP 표면을 결정한다.
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 결정 필요: 아래 체크리스트
|
||||
- [ ] provider category를 API, CLI, local inference 외에 어디까지 포함할지 결정한다.
|
||||
- [ ] local device/provider 상태를 health, capacity, model list, queue, runtime process 중 어디까지 추적할지 결정한다.
|
||||
- [ ] provider catalog를 읽기 전용 관찰로 시작할지, enable/disable 같은 제어까지 포함할지 결정한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- API, CLI, local inference provider category와 catalog 표시 기준
|
||||
- local device/provider 상태 추적 기준
|
||||
- vLLM, vLLM-MLX, Lemonade, SGLang 같은 provider의 운영 표시 후보
|
||||
- provider validation과 운영 catalog의 책임 분리
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [provider-catalog] Provider Operations Catalog
|
||||
|
||||
운영자가 provider 상태와 category를 같은 기준으로 비교하기 위한 최소 산출물을 묶는다.
|
||||
|
||||
- [ ] [category-map] API, CLI, local inference provider category와 MVP 표시 필드가 정리되어 있다.
|
||||
- [ ] [device-status] 로컬 디바이스 provider의 health, capacity, model, queue 상태 후보가 정리되어 있다.
|
||||
- [ ] [boundary] provider adapter 구현과 운영 catalog의 책임 경계가 정리되어 있다.
|
||||
- [ ] [ops-review] 사용자가 provider catalog MVP 범위와 2차 후보를 검토했다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 스케치 Milestone이며 기능 Task가 아직 충족되지 않았다.
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- vLLM, vLLM-MLX, Lemonade, SGLang provider adapter 구현 자체
|
||||
- provider marketplace, 자동 설치, 자동 benchmark, cross-Edge provider balancing
|
||||
- cloud fallback과 품질 평가 feedback 구현
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `apps/edge`, `apps/node`, `apps/control-plane`, `apps/client`, `packages/go/config`, `proto/iop/runtime.proto`
|
||||
- 표준선(선택): provider 실행 구현은 `adapter + target` 기준을 유지하고, catalog는 운영 관찰과 제어 경계를 별도로 정의한다.
|
||||
- 선행 작업: Node provider 상태와 Capacity Queue 기반, Edge 모델 그룹 Queue 스케줄링 전환
|
||||
- 후속 작업: provider 운영 리포트, provider enable/disable, benchmark/품질 평가
|
||||
- 확인 필요: provider category, 상태 추적 필드, 읽기 전용/제어 포함 여부
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
# Milestone: 사용량, 토큰, 로그 운영 추적 MVP
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-roadmap/ROADMAP.md`
|
||||
- Phase: `agent-roadmap/phase/operational-observability-provider-management/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
사용자 관리, token 관리, API/CLI/local inference 사용량 집계, 로그 관리를 1차 MVP 운영 축으로 스케치한다.
|
||||
이미 존재하는 runtime usage, CLI usage status, audit/observability 패키지와 Control Plane/Client 운영 표면을 기준으로 삼되, 구체 schema와 저장소 구현은 후속 구체화 전까지 확정하지 않는다.
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- [ ] 1차 MVP에서 관리할 사용자/token 범위와 운영 주체를 결정한다.
|
||||
- [ ] API, CLI, local inference 사용량을 어떤 단위로 집계할지 결정한다.
|
||||
- [ ] 로그 관리의 최소 범위와 보관/조회 책임 경계를 결정한다.
|
||||
- [ ] Control Plane, Edge-local CLI, Client 중 어떤 표면을 MVP에 포함할지 결정한다.
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 결정 필요: 아래 체크리스트
|
||||
- [ ] 사용자와 token을 개인/Edge/조직 중 어떤 단위로 시작할지 결정한다.
|
||||
- [ ] 사용량 집계의 MVP 단위를 요청, token, runtime duration, CLI limit status 중 어디까지로 둘지 결정한다.
|
||||
- [ ] 로그 조회와 export의 MVP 표면을 Control Plane/Client/CLI 중 어디에 둘지 결정한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- 사용자 관리와 token 관리의 1차 운영 경계
|
||||
- API, CLI, local inference 사용량 집계의 MVP 산출물 정의
|
||||
- Edge/Node/Control Plane 로그 관리의 최소 조회 경계
|
||||
- 기존 `Usage`, CLI usage status, audit/observability 패키지와 연결 가능한 표준선 정리
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [ops-usage] Usage and Log Operations
|
||||
|
||||
운영자가 사용량과 로그를 한 곳에서 이해하기 위한 최소 capability를 묶는다.
|
||||
|
||||
- [ ] [identity-scope] 사용자와 token 관리의 MVP 책임 경계가 정리되어 있다.
|
||||
- [ ] [usage-rollup] API, CLI, local inference 사용량 집계 후보와 제외 범위가 정리되어 있다.
|
||||
- [ ] [log-surface] Edge/Node/Control Plane 로그 조회와 export의 최소 표면 후보가 정리되어 있다.
|
||||
- [ ] [ops-review] 사용자가 MVP 운영 범위와 후속 구체화 우선순위를 검토했다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 스케치 Milestone이며 기능 Task가 아직 충족되지 않았다.
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- 결제, chargeback, 조직 IAM, 장기 retention 정책의 상세 구현
|
||||
- 모든 로그 schema와 audit schema 확정
|
||||
- provider routing 또는 inference adapter 구현
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `apps/control-plane`, `apps/client`, `apps/edge`, `apps/node`, `packages/go/audit`, `packages/go/observability`, `proto/iop/runtime.proto`
|
||||
- 표준선(선택): Edge는 로컬 runtime 상태의 원본을 유지하고, Control Plane은 연결 view와 운영 기록을 보기 쉽게 제공한다.
|
||||
- 선행 작업: Control Plane과 Client 운영, OpenAI-compatible usage 응답, CLI usage checker
|
||||
- 후속 작업: 운영 리포트, audit retention, 품질 기반 routing/fallback 고도화
|
||||
- 확인 필요: 사용자/token 단위, 사용량 집계 단위, 로그 관리 표면
|
||||
Loading…
Reference in a new issue