설계 제안과 권고
비전을 현실의 작은 성공으로 연결하는 제안.
제안 01 · 첫 성공 기준을 작게 정합니다
Codex 의견: 승인된 2~3대의 PC에서 공개된 시험 입력으로 독립 작업을 처리하는 것을 첫 연산 목표로 권고합니다. 작업 제출 → 배정 → 결과 수신 → 한 NODE 중단 → 재배정 → 중복 결과 거부까지 실제로 재현하면 분산 작업의 핵심 흐름을 검증 할 수 있다. 이 규모는 시험 제안이며 현재 연결된 장비 수가 아닙니다.
제안 02 · 자원 크기보다 업무 적합성을 봅니다
Codex 의견: 초기 업무는 공개 문서 요약·임베딩·허용된 배치 처리처럼 나누기 쉬운 작업에서 선정하는 편이 좋습니다. 먼저 단일 PC의 결과와 지연·메모리·전력·전송량을 측정하면 분산 실행이 실제로 이득인지 검증 할 수 있다. 작은 작업은 전송 비용 때문에 오히려 느릴 수도 있습니다.
제안 03 · 데이터가 있는 곳으로 작업을 보냅니다
Codex 의견: 민감한 원문을 불특정 참여자에게 보내는 기본 설계는 피하고, 초기에는 소유자 PC 또는 승인된 신뢰 영역 안에서 처리하는 방식을 권고합니다. 소유권과 목적별 접근 정책을 먼저 정하면 어떤 NODE에 어떤 데이터를 보낼 수 있는지 검증 할 수 있다. 암호화 저장만으로 AI 처리 중 비밀성이 해결되지는 않습니다.
제안 04 · 느린 NODE와 나쁜 NODE를 구분합니다
Codex 의견: 상태 만료, 작업 lease, 시도별 ID, 취소와 재시도 상한을 먼저 설계해야 합니다. 장애 주입 시험으로 오래된 결과·이중 실행·과도한 재배정 처리를 검증 할 수 있다. 외부 부작용이 있는 작업은 재실행해도 중복 변경이 생기지 않는 멱등성 정책이 필요합니다.
제안 05 · Agent보다 허용된 도구를 먼저 만듭니다
Codex 의견: 임의 명령 실행보다 소유권을 검사하는 조회 API와 제한된 변경 API부터 정리하는 편이 좋습니다. 자연어 없이도 도구의 입력·권한·한도·결과를 시험하면 Agent를 붙인 뒤에도 실행 경계를 검증 할 수 있다.
제안 06 · 합산 수치보다 사용자 경험을 측정합니다
Codex 의견: 총 VRAM이나 NODE 수보다 작업 대기 시간, p50/p95 완료 지연, 검증 통과율, 재시도율, 가용 시간과 실제 복구 성공을 우선 지표로 권고합니다. 모델·버전·입력·장비·컨텍스트 조건을 고정하면 단계별 개선을 검증 할 수 있다. 현재 포털의 수치는 모두 예시입니다.
제안 07 · 보상은 계측 이후에 설계합니다
Codex 의견: 기여도 장부를 먼저 만들고 실제 사용량과 중복·허위 요청의 영향을 관찰한 뒤 포인트를 정하는 순서가 좋습니다. 정상·실패·자전 작업의 시험 기록을 비교하면 보상 산식이 악용될 수 있는지 검증 할 수 있다. 지급 규모나 경제적 가치는 이번에 확정하지 않습니다.
제안 08 · 저장 기반의 운영 증거를 먼저 보강합니다
Codex 의견: 암호화 캐시 복원 격리 테스트 통과는 좋은 출발점입니다. 다음에는 승인된 실제 PC에서 파일을 업로드하고 원본과 분리된 복제본으로 복원한 뒤 파일 열기까지 확인해야 사용자 관점의 복구를 검증 할 수 있다. 키 분실·네트워크 중단·디스크 손상 시나리오도 함께 다루는 편이 좋습니다.
제안 09 · 사양과 실적을 함께 보상합니다
Codex 의견: 승인된 가용 자원 유지 기여와 실제 작업 수행 기여를 별도 예산으로 나누는 안을 권고합니다. 자원이 필요하지 않은데 무제한 대기 보상을 지급하거나 느린 장비가 오래 실행했다는 이유로 더 받는 설계를 피해야 합니다. 저장·CPU·GPU별 기준 업무와 정책 버전, 제공 허용량·정산 기간을 고정하면 장비 사양이 달라도 같은 원칙으로 보상을 검증 할 수 있다.
주요 설계 결정
- 이 페이지는 Codex의 설계 의견이며 사용자 확정 요구사항과 구분합니다.
함께 검토할 과제
- 첫 시험 업무와 공개 시험 데이터 선정
- 시험 NODE·측정 기준·완료 조건 합의