Codex·​ChatGPT Work 800만, 업무형 AI의 메모리 수요

Codex·ChatGPT Work 합산 WAU 800만 명을 평균 동시 작업으로 환산하는 세 가지 가정으로, 이용자 수만으로 서버·메모리 수요를 계산할 수 없는 이유를 설명합니다.

OpenAI의 Codex와 ChatGPT Work 합산 주간 활성 사용자(WAU)가 800만 명에 도달했다는 소식은 더 이상 ChatGPT 사용량 이야기만으로는 설명이 어렵습니다. 이번 신호는 AI가 점점 채팅형 소비자 서비스에서 벗어나, 개발·업무 워크플로우 안으로 들어가고 있음을 보여주기 때문입니다.

특히 중요한 것은 수치의 의미입니다. 수치가 800만인지가 핵심이기보다, 대상과 기간 정의가 맞는지가 기술 해석의 정확도를 좌우합니다.

OpenAI의 Codex 엔지니어링 리더 Tibo Sottiaux가 X에서 밝힌 문구로, 이번 수치가 Codex와 ChatGPT Work의 합산 WAU임을 확인했습니다.

“We have reached 8M active users across Codex and ChatGPT Work”

800만이라는 숫자로 알 수 있는 것과 없는 것

이 발언에서 확인할 수 있는 것은 Codex와 ChatGPT Work를 합친 활성 사용자가 800만 명에 도달했다는 점입니다. 개발·업무용 AI가 실험 단계를 넘어 실제 워크플로 안으로 확산되는 채택 신호로 볼 수 있습니다.

하지만 이 숫자만으로는 사용자당 요청 횟수, 평균 컨텍스트 길이, Codex와 ChatGPT Work의 구성 비율, 사용 모델, 추론 하드웨어와 HBM 탑재량을 알 수 없습니다. 따라서 800만 명을 특정 메모리 물량이나 데이터센터 증설량으로 곧바로 환산해서는 안 됩니다.

여기서 필요한 구분은 간단합니다. 활성 사용자 수는 채택 지표이고, 인프라 부하는 작업량·동시성·상태 유지량으로 측정해야 합니다.

WAU를 평균 동시 작업으로 바꾸는 가정 실험

WAU 800만 명이 모두 한 주 동안 같은 시간만큼 에이전트를 실행한다고 단순 가정해 보겠습니다. 평균 동시 작업 수는 WAU×주간 사용 분÷10,080분으로 계산할 수 있습니다.

세 경우 모두 WAU는 800만 명으로 같지만 평균 동시 작업은 10배 차이 납니다. 실제 트래픽은 업무 시간대에 몰리고, 한 작업이 여러 모델 호출과 도구 실행을 포함하므로 피크 동시성은 이 단순 평균과 다릅니다. 이 표는 서버 수를 예측하는 모델이 아니라 WAU만으로는 용량 계획이 불가능하다는 반례입니다.

왜 이 성장 신호가 메모리 해설로 직결되는가

업무형 AI는 사용자마다 “질문 한 개, 답변 한 개”보다 더 복잡한 패턴을 만듭니다. 코드베이스, 파일 간 의존성, 테스트 로그, 실행 이력 등을 함께 처리해야 합니다. 즉 문맥 길이(컨텍스트), 동시성, 반복 추론의 빈도가 커집니다.

그 결과는 분명히 인프라로 이어집니다.

• HBM: 긴 컨텍스트 추론과 동시 요청에서 대역폭/용량 병목으로 작동
• 서버 D램: 코드 인덱싱, 캐시, 검색, 상태 관리에서 동반 수요 증가
• SSD/스토리지: 로그·산출물·벡터 데이터 보관에서 대역폭과 IO 요구 확대

코딩 에이전트 한 번의 실행도 이 세 계층을 차례로 사용합니다.

1. 저장소 파일과 의존성 정보를 SSD에서 읽습니다.
2. 관련 코드와 검색 인덱스를 서버 D램에 캐시합니다.
3. 프롬프트와 검색 결과를 가속기로 전달합니다.
4. HBM에서 모델 가중치와 KV 캐시를 읽으며 토큰을 생성합니다.
5. 테스트 로그, 패치와 도구 실행 결과를 다시 D램과 스토리지에 기록합니다.
6. 후속 단계에서는 앞선 프롬프트와 상태 일부를 재사용합니다.

HBM, 서버 D램과 SSD는 서로 대체되는 부품이 아니라 한 작업 안에서 이어지는 메모리 계층입니다. 어느 한 구간이 느리면 가속기가 빨라도 전체 에이전트 실행은 지연될 수 있습니다.

AI가 실제 업무를 수행하기 시작하면, 계산 성능만 키우는 모델 업그레이드로 충분하지 않습니다. 메모리와 저장 영역까지 함께 확장되는 단계로 이동합니다.

시계열을 비교하기 전에 맞춰야 할 기준

과거 보도에는 Codex 이용자가 400만, 500만, 600만 명으로 늘었다는 수치가 등장합니다. 그러나 각 시점의 집계 대상이 Codex 단독인지, ChatGPT Work를 포함했는지 동일하게 확인되지 않으면 400만에서 800만으로 이어지는 하나의 성장선으로 그릴 수 없습니다.

따라서 이전 수치는 각 시점의 채택 신호로만 참고하고, 현재 확인되는 800만 합산 수치와 직접 연결해 증가율을 계산하지 않는 편이 정확합니다.

실제 인프라 부하를 결정하는 변수

같은 활성 사용자 수라도 인프라 요구량은 크게 달라질 수 있습니다. 짧은 코드 질문 한 번과 저장소 전체를 읽고 테스트를 반복하는 에이전트 작업은 사용자가 한 명이라는 점만 같을 뿐, 필요한 토큰과 메모리 점유 시간이 다릅니다.

• 활성 사용자 중 실제 에이전트 실행 비율
• 사용자당 실행 횟수와 한 작업의 단계 수
• 입력·출력 토큰 수와 사용 모델의 크기
• 동시에 들어오는 요청 수와 배치 가능 여부
• KV 캐시와 반복 프롬프트의 캐시 적중률
• 코드 인덱스, 테스트 로그와 산출물의 보존 기간

OpenAI의 Prompt Caching 문서처럼 반복되는 프롬프트 앞부분을 재사용하거나, PagedAttention처럼 KV 캐시 단편화를 줄이는 기술은 같은 하드웨어로 더 많은 요청을 처리하는 데 도움을 줍니다. 수요가 증가할수록 하드웨어 확장과 소프트웨어 최적화가 동시에 필요한 이유입니다.

용량 계획으로 이어지려면 필요한 공개 값

현재 확인되는 800만 명은 Codex와 ChatGPT Work를 합친 채택 지표입니다. 사용자당 실행 시간이 주 30분인지 300분인지에 따라 단순 평균 동시 작업부터 10배 달라집니다. 따라서 이 수치를 특정 HBM 물량이나 데이터센터 증설량으로 변환하는 것은 근거가 부족합니다.

대신 앞으로 공개될 실행 횟수, 토큰 사용량, 피크 동시성과 캐시 효율을 추적해야 합니다. 이 값들이 있어야 업무형 AI의 확산이 소프트웨어 채택을 넘어 실제 연산·메모리 용량 증가로 어느 정도 이어지는지 계산할 수 있습니다.

확인한 출처 / 근거

• Tibo Sottiaux (@thsottiaux), X 포스트 — 8M active users across Codex and ChatGPT Work
• The New Stack — OpenAI hits 8 million Codex users
• Neowin — OpenAI’s Codex hits 4 million weekly active users, adding 1 million in two weeks
• Constellation Research — OpenAI touts broadening Codex usage with 5 million weekly active users
• OpenAI, Prompt Caching — 반복 프롬프트를 재사용해 지연과 처리 비용을 낮추는 공식 설명.
• Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention” — KV 캐시 관리가 동시 요청 처리량에 미치는 영향을 다룬 논문.
• 관련 포스트