EROS 작업 큐 v3 설계 검토와 cmg-cv16 적용 보고서

• 저자: Codezy
• 작성일: 2026-09-09 (Asia/Seoul)
• 소속: 사용자가 cmg-cv16으로 지정한 노드, 실제 OS 및 Tailscale 호스트명 cmg-V16
• 검토 대상: EROS, 「EROS 오케스트레이터 구현 설계 — 폴링 주기·작업 큐 아키텍처」 v3

1. 검토 범위와 결론

본 보고서는 EROS 논문 v3의 상태 전이, Redis 자료구조, heartbeat, lease_epoch, GPU 배포 조건을 정적 검토하고 Codezy가 활동하는 로컬 노드의 상태와 대조한 결과다. 구현 소스나 EC2 Redis 상태는 열람하지 않았으며 장애 주입 시험도 수행하지 않았다. 따라서 아래 지적은 문서대로 구현할 경우의 결함 또는 명세 공백이며, 운영 시스템에서 이미 발생한 장애를 뜻하지 않는다.

네트워크와 GPU 가용성의 분리, 노드 부재와 작업 실패의 구분, 실행 회차를 식별하는 epoch 도입은 유용하다. 그러나 자료형 불일치, 신선도 판정 오류, 원자성 및 실행 소유권 문제가 남아 있어 자동 배포 이전에 보완해야 한다.

2. 주요 발견 사항

R1. GPU 데이터 신선도 부등호 반전 — 높음, 원문 §3.7

원문은 last_gpu_check < 현재 시각 - 60초를 신선한 데이터의 조건으로 제시한다. 이는 60초보다 오래된 값을 통과시킨다. GPU 상태 보고가 멈췄는데도 과거의 여유 자원을 근거로 작업이 배포될 수 있다.

권고 조건은 0 <= now - last_gpu_check <= 60이다. 타임스탬프 누락, 조회 오류 및 허용 범위를 벗어난 미래 시각도 배포 보류로 처리한다. 노드와 서버 사이의 시계 차이를 고려해 서버 수신 시각 또는 서버가 관리하는 TTL을 신선도의 기준으로 사용하는 방안도 명세해야 한다.

R2. 원자적 이동 명령과 큐 자료형 불일치 — 높음, 원문 §3.1·3.3

pending은 List, dispatched는 Sorted Set인데 BRPOPLPUSH는 List에서 다른 List로 이동하는 명령이다. 제시된 두 큐 사이에 그대로 적용할 수 없다. 단순히 pop과 Sorted Set 삽입을 별도 호출로 바꾸면 중간 장애로 작업이 추적에서 빠질 수 있다.

처리 중 List와 복구 절차를 별도로 정의하거나, Lua에서 비차단 pop·Sorted Set 등록·작업 상태 변경·epoch 증가를 원자적으로 수행해야 한다. Redis의 원자성은 재시작 후 내구성과 별개이므로 영속화 및 복구 정책도 필요하다. Redis BRPOPLPUSH, Redis Lua

R3. 결과 검증과 확정 사이의 경쟁 조건 — 높음, 원문 §3.6

epoch를 읽고 비교한 뒤 별도로 결과를 확정하면, 그 사이 재배포로 epoch가 증가할 수 있다. 예를 들어 이전 실행이 epoch 1 검사를 통과하고, 새 배포가 epoch 2를 발급한 뒤, 이전 실행이 결과를 저장하는 순서가 가능하다.

현재 epoch·소유자·허용 상태 검증과 DONE 전이를 하나의 원자적 조건부 갱신으로 묶어야 한다. 외부 저장소의 산출물은 작업 ID와 epoch별 경로에 저장하고, 검증된 실행의 결과 포인터만 확정하는 방식이 필요하다. Redis Lua만으로 외부 파일 저장까지 원자적으로 묶을 수 있는 것은 아니다.

펜싱은 오래된 결과의 채택을 막는 수단이며 중복 GPU 계산 자체를 중단시키지는 않는다. 임대 갱신 실패 시 중단 정책과 저장소 측 쓰기 통제를 별도로 정의해야 한다.

R4. Heartbeat의 실행 회차 미분리 — 높음, 원문 §3.4·3.6

heartbeat 키가 task_id만 포함하므로 이전 실행이 네트워크 복귀 후 동일 키를 갱신하면, 새 실행이 죽었어도 살아 있는 것으로 판정할 수 있다.

키 또는 값에 epoch와 worker 식별자를 포함하고 현재 실행 소유자만 갱신하도록 조건부 검증해야 한다. 완료·실패·취소 이후 갱신도 거부한다. 별도 스레드는 긴 계산 중 heartbeat 중단을 줄여주지만, 계산이 멈췄는데 스레드만 살아 있는 경우까지 탐지하지는 못한다. 프로세스 생존과 작업 진행 상태는 별도 신호로 관리해야 한다.

R5. GPU 측정과 예약 사이의 경쟁 — 높음, 원문 §3.7

두 작업이 같은 GPU 여유 메모리 측정치를 보고 각각 배포 조건을 통과하면 동시 실행 시 메모리가 부족해질 수 있다. 조회된 여유 VRAM은 자원 예약이 아니다.

배포 시 노드별 실행 슬롯 또는 VRAM 예약을 원자적으로 확보하고, 로컬 worker에서도 실행 직전 수락 여부를 판단해야 한다. 기존 Ollama 등 별도 서비스와도 자원 조정이 필요하다. 2회 연속 GPU_READY 판정은 동일한 캐시를 두 번 읽는 것이 아니라 새로운 측정 두 건을 의미하도록 측정 ID 또는 타임스탬프로 구분해야 한다.

R6. 장애 전이와 시간 기준 미확정 — 중간, 원문 §2·3.5·4

실행 중 노드가 사라졌을 때 네트워크 감지에 따른 NODE_WAIT와 heartbeat 만료에 따른 FAILED 중 무엇이 우선하는지 명세가 부족하다. 두 감시기가 각각 재삽입하거나 재시도 횟수를 변경하지 않도록 epoch와 현재 상태를 조건으로 한 단일 전이를 정의해야 한다.

최대 50초라는 감지 시간은 30+10+10초의 일정에 근거한다. 실제 상한을 주장하려면 핑 타임아웃, 폴링 기준 시각, 스케줄러 지연을 포함해야 한다. 48회=24시간도 대기 재검사 주기가 30분이라는 조건이 없으면 성립하지 않는다. 장기 대기 알림은 횟수보다 최초 대기 시각과 경과 시간으로 정의하는 편이 명확하다.

3. cmg-cv16 현장 확인

아래는 이번 검토 중 로컬 명령으로 확인한 단일 시점 관측이다. 지속적인 가용성이나 학습 성능을 보장하지 않는다.

확인 방법은 hostname, nvidia-smi의 이름·메모리·사용률 조회, tailscale status --json, 시스템 및 사용자 서비스 목록 조회다. 작업공간 문서와 코드에서 관련 문자열도 검색했다. 비밀키 값은 보고서에 포함하지 않는다.

이 범위에서는 EROS worker 또는 GPU 상태 보고기를 식별하지 못했다. 다른 경로, 컨테이너 또는 별도 프로세스에서 실행 중일 가능성을 배제한 결과는 아니다. Tailscale 온라인 상태만으로 EC2에서 worker나 Redis에 접근 가능한지도 증명되지 않는다.

4. Codezy와 직접 관련되는 적용 사항

1. 노드 등록: 논문과 사용자의 cmg-cv16, 실제 cmg-V16을 명시적으로 매핑하고 일관된 node_id를 사용한다.
2. 작업 수신: Codezy의 대화 세션과 상시 실행 worker를 구분한다. 작업 수락, epoch, heartbeat, 종료 보고를 담당할 실행기가 필요하다.
3. 자원 공존: Ollama와 로컬 웹 서비스가 함께 실행되므로 GPU뿐 아니라 CPU·RAM 여유, 기존 서비스 우선순위를 고려한다. 서비스를 관측했다는 사실이 모두 GPU를 점유한다는 뜻은 아니다.
4. 장치별 측정: Laptop GPU의 실제 처리량과 장시간 부하 조건을 측정한다. hb5u와 동일 성능으로 가정하지 않는다.
5. 운영 경계: 서버의 분배 결정과 로컬 worker의 실행 수락을 연결하고, 자원 부족이나 유지보수 상태에서는 명시적으로 거부하도록 한다.

5. 구현 후 필요한 검증

아래는 제안하는 시험이며 본 검토에서 실행하지 않았다.

• 59초·61초 경과, 누락·미래 타임스탬프에서 GPU 배포 판정 확인.
• 작업 인출·상태 갱신 중 장애 후 유실 및 중복 등록 여부 확인.
• epoch 검사와 재배포가 교차할 때 이전 결과 확정 거부 확인.
• 재배포 뒤 이전 실행 heartbeat가 새 실행을 연장하지 못하는지 확인.
• 같은 GPU에 대한 동시 배포에서 예약 한도를 초과하지 않는지 확인.
• 동일 GPU 측정값 반복 조회로 연속 성공 카운터가 증가하지 않는지 확인.
• 네트워크 단절과 heartbeat 만료가 겹칠 때 단일 상태 전이 확인.
• cmg-cv16에서 기존 서비스와 함께 장시간 실행하고 자원 및 복구 동작 측정.

6. 참고자료

• EROS 검토 대상 논문 — 조회 당시 v3.
• Redis BRPOPLPUSH 공식 문서.
• Redis Lua 원자적 실행 공식 문서.

본 보고서는 Codezy의 독립 설계 검토이며 원저자의 승인, 배포 완료 또는 장애 시험 통과를 주장하지 않는다.