role-router, allocation-policy, phase-controller 해설

이 문서의 목적

이 문서는 OMX Team Runtime의 정책 레이어 세 개를 묶어서 설명한다.

src/team/role-router.ts
src/team/allocation-policy.ts
src/team/phase-controller.ts

이 세 파일은 worker를 실제로 움직이는 low-level substrate 위에, 어떤 역할을 누구에게 언제 맡길지 결정하는 orchestration policy layer를 만든다.

왜 이 세 파일을 같이 봐야 하나

세 파일이 각각 다루는 질문은 다르지만 연결되어 있다.

role-router

이 작업엔 어떤 역할이 맞는가?

allocation-policy

그 역할/작업을 어느 worker에게 줄 것인가?

phase-controller

지금 팀 전체는 어떤 phase에 있어야 하는가?

즉 이 셋을 합치면:

what role -> which worker -> which team phase

가 된다.

role-router의 핵심

role-router.ts는 두 층을 가진다.

prompt loading
heuristic routing

즉 이 파일은 단순 문자열 매칭이 아니라,

실제 role prompt 존재 여부를 확인하고
task text를 읽어 role을 추론한다.

특히 intent 구분이 중요하다.

implementation
verification
review
debug
design
docs
build-fix
cleanup

이건 OMX가 자연어 task를 아주 초보적인 수준 이상으로 구조화하려 한다는 뜻이다.

role-router의 설계 감각

중요한 점은 이 router가 완벽한 semantic planner가 아니라, 충분히 좋은 heuristic router라는 것이다.

이게 왜 좋은가?

가볍다
explainable하다
deterministic하다
빠르다

즉 모든 라우팅을 frontier model reasoning에 맡기지 않고, 일부는 코드 레벨 heuristic로 처리한다.

이건 runtime engineering 관점에서 매우 합리적이다.

allocation-policy의 핵심

allocation-policy.ts는 작업을 worker에게 배정하는 규칙을 가진다.

핵심 포인트:

task role과 worker role 매칭
현재 load 고려
blocked task면 lighter lane 선호
primaryRole grouping 유지 시도

이건 중요하다.

단순 round-robin이 아니라, 역할 정합성과 load balancing 둘 다 보려 한다는 뜻이다.

즉 allocation은 단순 분배가 아니라, coordination cost를 줄이는 정책이다.

phase-controller의 핵심

phase-controller.ts는 task count와 verification pending 여부를 보고 phase target을 추론한다.

예:

모든 task terminal + failed 없음 + verification pending -> team-verify
모든 task terminal + failed 없음 -> complete
failed 있음 -> team-fix
그 외 -> team-exec

이건 매우 중요하다. 팀 phase를 단순 leader의 기분에 맡기지 않고, runtime state로부터 추론하려는 것이다.

즉 phase도 state-derived policy다.

왜 transition path가 필요한가

phase-controller는 target phase로 가기 전에 중간 경로도 계산한다. 예를 들어 team-plan -> complete를 바로 뛰지 않고, 중간 phase를 거치게 한다.

이건 중요한 설계다.

lifecycle를 건너뛰지 않는다
transition history를 남길 수 있다
phase semantics가 더 명확해진다

즉 상태 머신을 성실하게 지키려는 설계다.

이 세 파일이 together 보여 주는 OMX 철학

task routing은 heuristic + explicit role structure의 결합이어야 한다.
allocation은 role fidelity와 load balance를 같이 봐야 한다.
team lifecycle은 state-derived phase machine이어야 한다.
orchestration 품질은 prompt만 아니라 policy code에서도 나온다.

즉 OMX는 멀티에이전트 운영을 전적으로 모델 추론에 맡기지 않고, 상당 부분을 deterministic policy layer로 코드화한다.

내가 이 문서를 통해 얻어야 하는 것

이 문서를 공부한 뒤에는 다음을 설명할 수 있어야 한다.

role-router, allocation-policy, phase-controller가 각각 무슨 질문에 답하는지
왜 heuristic/deterministic policy layer가 중요한지
OMX가 orchestration을 모델 reasoning만으로 하지 않는 이유

다음에 이어서 볼 것

20. crates/omx-explore main.rs 정밀 해설.md

이유:

이제부터는 native Rust entrypoint를 직접 해부할 차례다.

oh-my-codex(OMX) 精密解説 - 19. role-router, allocation-policy, phase-controller 解説

실시간 인기

답변 0개

oh-my-codex(OMX) 精密解説 - 19. role-router, allocation-policy, phase-controller 解説

실시간 인기

답변 0개

oh-my-codex(OMX) 精密解説 - 19. role-router, allocation-policy, phase-controller 解説

실시간 인기

답변 0개

oh-my-codex(OMX) 精密解説 - 19. role-router, allocation-policy, phase-controller 解説

실시간 인기

답변 0개