Control Room: A central system to track and stop model workloads across our research infrastructure

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

OpenAI의 Control Room은 연구 인프라의 모델 추론을 중앙에서 통제하고, 작업 중단 지시를 받으면 최대 35초 안에 해당 작업의 추가 모델 출력을 차단하는 시스템이다.

📌 핵심 요약

• Control Room은 모델 학습·평가를 위한 에이전트형 샘플링과 데이터 처리 등 연구 추론 워크로드를 연결하며, 연구 인프라 전반에 이미 배포됐다. 에이전트형 추론을 수행하는 모든 연구 워크로드는 승인된 안전성 근거와 연결돼야 한다.
• 워크로드는 Control Room에서 발급받은 job_id를 추론 요청에 첨부하고, 추론 엔진은 요청을 수행하기 전에 Control Room에 권한을 확인한다. 중단된 작업의 요청은 거부되지만, 작업 프로세스와 다른 승인된 작업에 쓰이는 엔진은 계속 실행될 수 있다.
• 모든 프런티어 강화학습 작업에는 학습 대상 모델의 행동을 검사하는 모니터가 붙는다. 모니터링 시스템은 잠재적 문제의 세부 내용과 심각도에 따라 Control Room에 작업 중단을 요청할 수 있으며, 최근 DNS 관련 사건도 모니터가 탐지했다.
• Control Room이 중단 지시를 받은 뒤 작업의 추가 진행이 불가능해지기까지 최대 35초가 걸린다. 이 지연은 대량의 트래픽을 지원하기 위한 추론 권한 캐시에서 발생하며, OpenAI는 이를 0초로 줄이는 작업을 진행하고 있다.
• 중단 기능은 자주 바뀌는 워크로드 코드 대신 중앙화된 추론 계층에 구현됐으며, 우회 엔진을 찾는 지속적인 에이전트형·프로그램 방식 검사도 수행된다. Control Room 장애 시 모든 추론 요청을 거부하는 fail-closed는 모든 프런티어 모델 연구 워크로드에 적용됐고, 원문 발표 시점 기준 나머지 연구 워크로드에도 며칠 안에 적용을 마칠 예정이다.

🧩 주요 포인트

1. job_id와 승인된 안전성 근거를 연결하고 추론 엔진에서 권한을 검사하므로, 개별 연구 코드의 정상 동작에 덜 의존하면서 작업별 모델 출력을 통제할 수 있다.
2. 모니터링의 문제 탐지가 Control Room의 권한 철회로 이어지므로, 탐지 이후 실제 출력 차단까지 연결된다. 다만 추론 권한 캐시 때문에 즉시 중단에는 최대 35초의 제약이 남는다.
3. 중앙화된 추론 계층의 통제, 우회 엔진 검사, fail-closed를 결합해 안전장치 누락과 서비스 장애에 대응한다. 이 설계는 Control Room을 사용할 수 없을 때 추론 지속보다 요청 거부를 우선한다.

🧠 상세 정리

1. 연구 인프라 전반의 모델 출력을 통제하는 중앙 시스템

OpenAI는 모델 성능이 높아지고 관련 안전·보안 위험이 커질수록 잠재적 문제를 탐지하고 필요할 때 모델을 신속히 멈추는 능력이 중요해진다고 설명한다. 이를 위해 구축한 Control Room은 연구 인프라의 모델 워크로드를 추적하고 안전·보안 우려가 발생하면 추가 모델 출력을 차단하는 중앙 시스템이다. 연결 대상에는 모델 학습과 평가를 위한 에이전트형 샘플링, 데이터 처리 등 모든 연구 추론 워크로드가 포함된다. Control Room은 이미 연구 인프라 전반에 배포됐으며, OpenAI는 이 영역에서 필요성이 가장 크다고 본다. 외부 모델 서비스 체계는 본래 더 중앙화돼 있고, 필요시 모델 배포를 신속히 중단할 운영 역량도 이미 갖추고 있다고 설명한다.

2. 워크로드·추론 엔진·Control Room의 역할

Control Room은 워크로드, 추론 엔진, 중앙 Control Room 서비스라는 세 요소를 연결한다. 워크로드는 강화학습 실험, 평가, 대규모 샘플링, 데이터 처리처럼 실행되는 작업이며, 에이전트형 추론을 수행하는 모든 연구 워크로드에는 승인된 안전성 근거가 연결돼야 한다. 추론 엔진은 GPU에서 모델을 직접 실행하는 부분으로, 하나의 워크로드가 여러 모델이나 엔진을 사용할 수 있고 하나의 엔진을 여러 워크로드가 공유할 수도 있다. 작업을 시작할 때 워크로드 코드는 Control Room에 등록을 요청하고 job_id를 발급받는다. 이후 워크로드는 같은 job_id를 붙여 엔진에 직접 추론을 요청하며, 이 요청 자체가 Control Room을 경유하지는 않는다. 대신 엔진이 요청을 수행하기 전에 해당 작업의 실행 권한을 Control Room에 확인한다.

3. 작업 프로세스와 모델 출력 중단을 분리하는 흐름

연구자가 작업을 시작하면 추론 엔진을 함께 구동할 수도 있고, 특정 작업에 종속되지 않고 이미 실행 중인 엔진을 사용할 수도 있다. Control Room에 등록된 작업의 요청이 승인되면 엔진은 모델 출력을 생성해 워크로드에 반환하고 작업은 계속 진행된다. 이후 사람이나 모니터링 시스템이 중단을 요청하면 Control Room은 해당 job_id를 중단 상태로 표시한다. 워크로드 코드가 계속 실행되며 추가 샘플링을 시도하더라도, 엔진이 다시 권한을 확인할 때 요청이 거부된다. 따라서 중단 여부를 워크로드 코드가 올바르게 확인하는 데 의존하지 않고 추가 모델 출력을 막을 수 있다. 이때 연구 프로세스 자체는 살아 있을 수 있으며, 추론 엔진도 다른 승인된 작업에는 계속 사용될 수 있다.

4. 모니터링과 연계한 중단 및 최대 35초의 지연

모든 프런티어 강화학습 작업에는 학습 대상 모델이 하는 일을 검사하고 문제가 감지되면 경고하는 별도의 모델인 모니터가 붙는다. OpenAI는 최근 DNS 관련 사건도 이러한 모니터가 탐지했다고 설명한다. 모니터링 시스템은 잠재적 문제의 세부 내용과 심각도에 따라 작업 중단을 결정할 수 있으며, 이 경우 job_id를 담은 중단 메시지를 Control Room에 보낸다. Control Room이 중단을 기록하면 해당 작업이 어느 엔진의 어느 모델에 추가 토큰 생성을 요청하더라도 이후 권한 확인에서 거부된다. 중단 지시 수신부터 작업의 추가 진행이 불가능해지기까지 걸리는 시간은 최대 35초이며, 이는 필요한 트래픽 규모를 지원하기 위한 추론 권한 캐시에서 발생한다. OpenAI는 작업을 즉시 멈출 수 있도록 이 지연을 0초로 줄이는 작업을 진행하고 있다.

5. 변경이 잦은 연구 코드 대신 추론 계층에서 강제

실험과 평가 등 워크로드는 일반적으로 연구자나 연구팀이 소유하고 운영하므로 코드가 자주 바뀌며 형태도 다양하다. OpenAI는 이런 코드가 핵심 안전장치를 구현하기에 적합한 위치가 아니라고 보고, 버그가 있거나 망가진 워크로드 코드에도 중단 기능이 견디도록 설계했다. 중단 메커니즘을 둔 추론 계층은 연구 워크로드보다 코드 경로 수가 매우 적고 배포도 더 중앙화되고 균일하다. 따라서 이 계층을 모든 연구 추론 요청이 Control Room의 권한 검사를 받도록 강제하는 통제 지점으로 활용할 수 있다. 아울러 Control Room 기능이 구현되지 않았거나 비활성화된 비인가 엔진을 사용자가 실수로 또는 악의적으로 실행하는지 확인하기 위해, 에이전트형 검사와 프로그램 방식 검사를 지속적으로 수행한다.

6. 장애 시 요청을 거부하는 설계와 향후 확대

Control Room의 엔진 연동은 서비스가 정상 작동하지 않으면 추론 요청을 거부하는 fail-closed 방식으로 구성됐다. 시스템 오류뿐 아니라 악의적 행위자의 조작을 포함한 다른 이유로 Control Room이 비활성화돼도, 정상 운영이 재개될 때까지 모든 추론 요청을 거부한다. 원문 발표 시점에 이 방식은 모든 프런티어 모델 연구 워크로드에 적용됐으며, 나머지 연구 워크로드에도 며칠 안에 적용을 마칠 예정이라고 밝혔다. 이는 Control Room 자체가 중단되는 상황에서도 모델 출력을 멈추려는 설계다. OpenAI는 Control Room을 프런티어 모델의 안전한 학습과 배포를 위한 종합적 접근의 일부로 설명한다. 향후 수개월 동안 정렬에서 벗어난 행동과 보안 침해를 감시하는 투자와 함께 시스템을 강화하고 확대할 계획이다.

🧾 핵심 주장 / 시사점

• Control Room의 중단 대상은 특정 작업에 대한 모델 출력 권한이다. 따라서 작업 프로세스나 공유 엔진 전체를 종료하지 않고도 해당 작업의 추가 추론을 차단할 수 있다.
• 모니터링과 출력 차단을 연결해도 추론 권한 캐시가 남아 있으면 중단은 즉시 완료되지 않는다. 최대 35초라는 수치는 탐지 시간과 구분되는, 중단 지시 수신 이후의 지연이다.
• 추론 계층의 중앙 통제만으로 끝내지 않고 우회 엔진 검사와 fail-closed를 함께 적용한다는 점에서, 구현 누락·우회·서비스 장애를 서로 다른 실패 경로로 다루고 있다.

✅ 액션 아이템

• 추론 권한 캐시에서 발생하는 최대 35초의 중단 지연을 0초로 줄이는 작업 추진.
• 모든 프런티어 모델 연구 워크로드에 적용된 fail-closed를 나머지 연구 워크로드로 확대.
• Control Room이 구현되지 않았거나 비활성화된 우회 엔진에 대한 지속적인 에이전트형·프로그램 방식 검사 수행.

❓ 열린 질문

• 추론 권한 캐시가 대량의 트래픽을 지원하는 역할을 유지하면서 최대 35초의 중단 지연을 0초로 줄일 수 있는가?
• 모니터링 시스템은 잠재적 문제의 세부 내용과 심각도를 어떤 기준으로 판단해 Control Room에 작업 중단을 요청하는가?
• Control Room의 fail-closed가 나머지 연구 워크로드에도 적용되면, 서비스 장애로 모든 추론 요청이 거부되는 상황에서 정상 운영 재개는 어떻게 이뤄지는가?