https://preview.redd.it/uifzxhxf6ngh1.png?width=998&format=png&auto=webp&s=a54caa7ad1f2bbd93529376bc12debe50816d8bf 저는 이런 수치를 만들어내려고 시작한 것이 아니었습니다. 처음에는 평소보다 조금 더 빠른 반복 (iteration), 더 긴밀한 피드백 루프 (feedback loops), 그리고 더 공격적인 자동화 (automation)가 결합된 일반적인 작업처럼 느껴졌습니다. 하지만 어느 시점부터 그 규모는 단순히 "AI 도구를 사용하는 것"을 넘어, 자체적인 실행 압력 하에 지속적으로 확장되는 분산 컴퓨팅 시스템 (distributed compute system)을 조종하는 것처럼 느껴지기 시작했습니다. 흥미로운 점은 사후에야 그 규모를 깨달았다는 것입니다. 이것은 Codex 사용량만을 나타냅니다. 스크린샷은 총 88억 개의 생애 토큰 (lifetime tokens)을 보여주며, 하루 최대 피크치는 8억 2,890만 토큰입니다. 그 총량 중 약 66억 개의 토큰은 지난 몇 주 동안 실행된 12개의 소프트웨어 엔지니어링 (software-engineering) 작업에서 발생했으며, 그중 4~5개의 작업이 대부분의 작업 부하를 차지했습니다. 이 66억 개의 수치에는 ChatGPT 대화나 일반적인 채팅 사용량은 포함되지 않았습니다. 저의 가장 높았던 날들은 다음과 같습니다: 7월 15일: 2억 6,380만, 7월 16일: 4억 2,350만, 7월 17일: 8억 2,890만, 7월 19일: 8억 1,680만, 7월 27일: 5억 7,580만, 7월 29일: 3억 2,780만, 7월 30일: 6억 6,790만. 이 7일 동안의 합계만 약 39억 토큰에 달합니다. 시스템 범위 (실제로 다룬 내용) 작업은 다섯 가지 주요 시스템에 분산되어 있었습니다: BTAI: 영업 인텔리전스 (sales intelligence) 및 엔지니어링, Skrikx: 통제된 인지 (governed cognition), 메모리, 음성 및 시스템 아키텍처 (system architecture), SROS: 기업 거버넌스 (enterprise governance), 에이전트 실행 (agent execution), 법률 및 재무 시스템, InfraScope: 시스템 진단 (system diagnostics), 인프라 점검 (infrastructure inspection) 및 환경 분석, Cosmic Mind: 물리 시뮬레이션 (physics simulation), 모델링, 컴퓨팅 아키텍처 (computational architecture) 및 비디오 생성 엔진. 실행 모델의 핵심 부분은 모든 시스템에 걸쳐 오케스트레이션 레이어 (orchestration layer) 역할을 하는 SRX ACE였습니다. SRX ACE는 독립적인 프로젝트로 기능한 것이 아니라, 도메인 전반에 걸친 작업 라우팅 (task routing), 컨텍스트 지속성 (context persistence) 및 에이전트 위임 (agent delegation)을 위한 조정 엔진 (coordination engine)으로 작동했습니다.

언어, 도메인 및 실행 구성 요소의 범위
이러한 시스템 전반에서 Codex는 다음과 같은 다중 패러다임(multi-paradigm), 다중 스택(multi-stack) 환경에서 작동했습니다:

언어 및 런타임 (Languages & runtimes)

• Python (핵심 오케스트레이션 (core orchestration), ML 파이프라인 (ML pipelines), 자동화 (automation))
• TypeScript / JavaScript (프론트엔드 (frontend) + 에이전트 도구 (agent tooling) + 대시보드 (dashboards))
• Go (시스템 서비스 (systems services), 동시성 중심 구성 요소 (concurrency-heavy components))
• Rust (성능 중심 모듈 (performance-critical modules), 안전 계층 (safety layers))
• SQL (분석 (analytics), 감사 (audit), 금융 및 거버넌스 쿼리 (financial and governance queries))
• Bash / shell (CI, 배포 (deployment), 시스템 실행 접착제 (system execution glue))
• YAML / JSON (스키마 (schemas), 오케스트레이션 사양 (orchestration specs), 설정 그래프 (config graphs))
• SRX ACE 및 Skrikx 실행 그래프 내부에서 사용되는 도메인 특화 DSL (Domain-specific DSLs)

도메인 (Domains)

• 엔터프라이즈 소프트웨어 시스템 (Enterprise software systems)
• 분산 에이전트 오케스트레이션 (Distributed agent orchestration)
• 금융 + 거버넌스 자동화 (SROS)
• 보안 + 시스템 인프라 분석 (InfraScope)
• 인지 아키텍처 + 메모리 시스템 (Skrikx)
• 영업 인텔리전스 파이프라인 (BTAI)
• 과학 시뮬레이션 + 물리 모델링 (Cosmic Mind)

실행 구성 요소 (Execution components)

• 멀티 에이전트 오케스트레이션 트리 (Multi-agent orchestration trees)
• 재귀적 작업 분해 엔진 (Recursive task decomposition engines)
• 빌드/테스트/CI 파이프라인 (Build/test/CI pipelines)
• 로그 수집 + 분석 루프 (Log ingestion + analysis loops)
• 코드 합성 + 리팩터링 패스 (Code synthesis + refactoring passes)
• 도구 호출 체인 (Tool-calling chains) (파일 시스템 (filesystem), 검색 (search), 실행 (execution), 검증 (validation))
• 상태 지속성 (State persistence) + 메모리 검색 계층 (memory retrieval layers)
• 교차 리포지토리 의존성 해결 (Cross-repository dependency resolution)
• 지속적 통합 피드백 루프 (Continuous integration feedback loops)

12개의 모든 작업은 단일 기본 입력 (single-primary-input) 패러다임 하에 실행되었습니다. 각 작업은 하나의 구조화된 입력(사양 (spec), 프롬프트 (prompt), 또는 시스템 지시 사항 (system directive))에서 시작되었으며, 그 외의 모든 것은 해당 시드(seed)로부터 파생되었습니다. 거기에서 Codex는 반복적인 분해를 통해 작업을 확장했습니다: 서브 에이전트 (subagents) 생성, 중간 산출물 (intermediate artifacts) 생성, 테스트 실행, 출력 분석, 그리고 구현의 재귀적 정교화 (recursively refining implementations)를 수행했습니다. 어떤 작업도 여러 개의 독립적인 시작 프롬프트를 필요로 하지 않았습니다. 각 작업은 전체 실행 트리로 확장되는 단일 입력 시스템이었습니다. 정확히 말하자면, 저는 Codex가 66억 개의 고유 소스 코드를 작성했다고 주장하는 것이 아닙니다.

이 총합에는 저장소 읽기(repository reads), 추론(reasoning), 캐시되거나 반복된 컨텍스트(cached or repeated context), 명령 출력(command output), 차이점(diffs), 로그(logs), 테스트 결과(test results), 서브 에이전트 트래픽(subagent traffic), 그리고 생성된 코드(generated code)가 포함됩니다. 이는 Codex가 처리한 완전한 소프트웨어 엔지니어링 워크로드(software-engineering workload)를 나타냅니다. 또한 저는 할 일이 없어서 멈춘 것이 아닙니다. 사용량(usage)이 다 되어서 멈춘 것입니다. 따라서 66억 개는 저의 운영 한계치(operating ceiling)가 아니었습니다. 그것은 할당량(quota)이 병목 현상(bottleneck)이 되기 전까지 구독(subscription)에서 허용된 양이었습니다. 다른 사용량 보고서들을 확인해 보았는데, 이것이 전례 없는 일은 아닌 것으로 보입니다. 분명히 하루에 수십억 개의 토큰을 사용하거나 수십억 개의 토큰을 사용하는 주간을 보내는 다른 극단적인 사용자(extreme users)들이 존재합니다. 그럼에도 불구하고, 서로 관련 없는 프로젝트들에 걸쳐 반복적으로 하루 5억~8억 개의 토큰을 사용하는 것은 일반적인 사용 범위를 확실히 벗어난 것으로 보입니다. 가장 눈에 띄는 점은 일별 분포가 아니라, 단일 연속 사용 범위 내에서의 압도적인 계산 밀도(density of computation)입니다. 66억 개의 토큰은 일시적인 급증(spikes)의 연속이 아닙니다. 그 시점에서는 각 작업이 거대한 내부 실행 트리(internal execution trees)로 확장되고, 그 트리 자체가 다시 컨텍스트(context), 도구 호출(tooling calls), 검증 루프(verification loops)의 추가 계층을 생성하는 지속적이고 복리적인(compounding) 워크로드입니다. 실제로 이는 단일 구독 기간 동안 전통적으로 여러 번의 대규모 엔지니어링 사이클(engineering cycles)에 해당할 컴퓨팅과 반복(iteration) 작업이 하나의 연속적인 Codex 기반 워크플로(workflow)로 압축되어 흡수되었음을 의미합니다. 이 부분이 일반적인 소프트웨어 개발 규모와 직관적으로 매칭하기 여전히 혼란스럽게 느껴지는 대목입니다. 사용 기록을 비교해보고 싶습니다: 여러분의 Codex 단일 최고 일일 사용량은 얼마인가요? 최고 주간 사용량은요? 얼마나 많은 병렬 에이전트(parallel agents)나 작업이 실행 중이었나요? 유용한 배포 코드(shipped code)가 토큰 소비량에 따라 확장되었나요? 새로운 추론(fresh inference)과 반복되는 컨텍스트 소모(repeated context churn)를 측정할 수 있는 신뢰할 만한 방법을 찾은 분이 계신가요? [IMG:1]은 누적 88억 개의 Codex 토큰, 최고치인 8억 2,890만 개의 일일 사용량, 그리고 11일간의 최장 연속 기록을 보여주는 스크린샷입니다. 위에서 논의한 66억 개는 12개의 작업에 걸친 최근 워크로드의 하위 집합입니다.

submitted by /u/Low-Tip-7984 to r/OpenAI [link] [comments]