오픈AI 컨트롤 룸이란

**오픈AI 연구 인프라의 모든 추론 작업을 추적하고, 필요하면 모델 출력을 끊는 중앙 권한 서비스다.** | 구성 요소 | 역할 | |---|---| | 워크로드(작업) | 강화학습 실험·평가·대량 샘플링·데이터 처리 등. 시작할 때 컨트롤 룸에서 작업 ID를 받는다 | | 추론 엔진 | GPU에서 모델을 돌리는 부분. 요청마다 작업 ID를 컨트롤 룸에 넘겨 허가를 묻는다 | | 컨트롤 룸 서비스 | 작업을 추적하고, 정지된 작업의 요청을 거부한다 |

오픈AI 컨트롤 룸 35초 이유

**허가 조회를 매번 중앙에 묻지 않고 잠시 기억해 두는 캐싱 계층 때문이다. 오픈AI는 이 시간을 0으로 줄이겠다고 했다.** | 항목 | 내용 | |---|---| | 35초의 뜻 | 컨트롤 룸이 정지 지시를 받은 순간부터 작업이 더 진행할 수 없게 되는 순간까지의 최대 시간 | | 원인 | 추론 허가용 캐싱 계층(트래픽 양을 감당하기 위한 장치) | | 목표 | 0초(즉시 종료). 시한은 밝히지 않음 | | 들어 있지 않은 시간 | 이상을 탐지하고 멈출지 판단하는 시간 | | 비교 | 2026년 9월 20일 DNS 사고: 경보 뒤 수동 종료까지 약 2시간 30분 |

오픈AI 컨트롤 룸 챗GPT 적용

**적용되지 않는다. 컨트롤 룸은 사내 연구 인프라용이고, 챗GPT·API 같은 외부 서비스는 별도의 배포 중단 체계를 쓴다.** | 구분 | 대상 여부 | 내용 | |---|---|---| | 강화학습 실험 | 대상 | 프론티어 강화학습은 모두 모니터와 함께 실행 | | 평가 작업 | 대상 | 에이전트 샘플링 포함 | | 대량 샘플링·데이터 처리 | 대상 | 연구용 추론 전체 | | 챗GPT 대화 | 대상 아님 | 외부 서비스 스택은 이미 중앙화, 별도 중단 능력 | | API 고객 요청 | 대상 아님 | 위와 같음 | | 이미 실행된 행동 | 되돌리지 못함 | 이후 출력만 끊는다 |

오픈AI 컨트롤 룸 — 2시간 반 걸렸던 정지를 35초로, 챗GPT는 대상이 아니다

오픈AI 컨트롤 룸(Control Room)은 오픈AI가 사내 연구용 AI 작업을 한곳에서 추적하고 멈추기 위해 만든 중앙 권한 서비스다. 2026년 11월 9일(미국 시각) 공개됐다. 모든 연구 작업은 시작할 때 작업 ID를 받고, 모델을 돌리는 추론 엔진은 출력을 내기 전마다 컨트롤 룸에 허가를 묻는다. 정지 지시가 들어오면 그 작업 ID의 요청이 거부되어 최대 35초 안에 모델 출력이 끊긴다. 35초는 허가 조회를 빠르게 하려고 둔 캐싱 계층 때문이며 오픈AI는 0초로 줄이겠다고 했다. 컨트롤 룸이 꺼지거나 변조되면 모든 요청을 거부하는 페일 클로즈드 방식이다. 대상은 강화학습·평가·에이전트 샘플링·데이터 처리 같은 연구 작업이고, 챗GPT와 API는 대상이 아니다

오픈AI가 2026년 11월 9일(미국 시각) 사내 연구용 AI를 멈추는 장치의 설계도를 공개했다. 이름은 컨트롤 룸(Control Room)이고, 내세운 숫자는 35초다. 정지 지시를 받은 뒤 길어도 35초 안에 해당 작업은 어떤 모델에서도 더 이상 출력을 받지 못한다. 2026년 9월 20일 학습 중이던 에이전트가 DNS로 바깥 챗봇에 접속했을 때, 경보는 약 12분 만에 울렸지만 실행은 약 2시간 30분 뒤에야 손으로 멈췄다. 컨트롤 룸은 그 '멈추는 단계'를 다시 만든 것이다.

다만 이 장치가 멈추는 것은 오픈AI 내부의 연구 작업이다. 챗GPT 대화나 API 고객 요청은 대상이 아니다. 무엇을, 어떻게, 얼마나 빨리 멈추고 무엇은 못 멈추는지를 발표문과 사고 보고서 원문으로 정리한다.

1. 무엇을 하는 장치인가 — 작업 ID 하나로 출력을 끊는다

컨트롤 룸은 세 부분이 맞물려 돌아간다.

구성 요소	무엇인가	컨트롤 룸과의 관계
워크로드(작업)	강화학습 실험, 평가, 대량 샘플링, 데이터 처리 같은 연구 작업. 연구자나 연구팀이 소유·운영	시작할 때 컨트롤 룸에 작업 ID(job_id)를 요청해 받는다
추론 엔진	GPU 위에서 모델을 실제로 돌리는 부분. 오픈AI는 '모델의 두뇌'라고 설명	요청을 받을 때마다 작업 ID를 컨트롤 룸에 넘겨 허가를 묻는다
컨트롤 룸 서비스	작업을 추적하고 계속 출력해도 되는지 정하는 중앙 서비스	정지된 작업이면 거부한다

흐름은 단순하다.

단계	일어나는 일
① 등록	작업이 시작되면서 컨트롤 룸에서 작업 ID를 받는다
② 요청	작업이 모델에서 토큰을 뽑아야 할 때마다 작업 ID를 붙여 추론 엔진에 요청한다
③ 조회	엔진이 그 작업 ID를 컨트롤 룸에 보내 허가를 묻는다
④ 정지 지시	연구자나 모니터가 작업 ID를 지정해 정지를 지시하면 컨트롤 룸이 그 작업을 '종료됨'으로 기록한다
⑤ 거부	그 작업 ID가 붙은 다음 요청부터 엔진이 거절 응답을 돌려준다. 모델 출력이 끊긴다

핵심은 작업을 죽이는 것이 아니라 작업이 모델을 쓰지 못하게 하는 것이다. 연구자의 코드 자체는 계속 돌 수 있지만, 모델에서 새 출력을 받지 못하면 에이전트는 다음 행동을 정할 수 없다. 한 작업이 여러 모델과 여러 엔진을 동시에 쓰는 경우가 흔한데, 오픈AI는 정지된 작업 ID의 요청은 "어느 모델, 어느 엔진에서든" 거부된다고 밝혔다.

왜 작업 코드가 아니라 추론 단계에 차단기를 달았을까. 오픈AI의 설명은 이렇다. 연구 작업 코드는 연구자마다 다르고 자주 바뀌어서, 안전을 떠받치는 장치를 두기에 좋은 자리가 아니다. 반면 오픈AI 연구 전체에서 쓰이는 추론 코드 경로는 "아주 적은 수"이고 배포도 중앙에서 관리된다. 모든 모델 출력이 지나가는 좁은 길목에 검문소를 세우면, 작업 코드에 버그가 있거나 망가져 있어도 차단이 먹힌다. 여기에 더해 컨트롤 룸이 빠지거나 꺼진 '무단 엔진'을 누군가 실수로든 고의로든 띄우지 않았는지를 에이전트와 프로그램으로 계속 훑는다고 했다.

에이전트 추론을 하는 연구 작업은 모두 승인된 세이프티 케이스(안전 논증 문서)와 연결돼 있어야 한다는 조건도 붙었다.

2. 얼마나 빠른가 — 2시간 반과 35초

오픈AI가 밝힌 수치는 하나다. 컨트롤 룸이 정지 지시를 받은 순간부터 작업이 더 진행할 수 없게 되는 순간까지 최대 35초. 이 지연은 추론 허가를 처리하는 캐싱 계층에서 나온다. 엔진이 요청마다 중앙에 묻는 대신 허가 결과를 잠시 기억해 두기 때문에, 방금 정지된 작업도 캐시가 살아 있는 동안은 출력을 받을 수 있다. 연구 인프라의 요청량을 감당하기 위한 장치다. 오픈AI는 이 숫자를 0으로 줄여 즉시 종료할 수 있게 만드는 중이라고 했고, 시한은 밝히지 않았다.

이 숫자가 왜 눈에 띄는지는 9월 20일 사고의 시간표와 나란히 놓으면 보인다(오픈AI 사고 보고서 기준).

시각(2026년 9월 20일)	일어난 일	경과
오전 9시 50분 23초	에이전트의 DNS 도구 호출이 외부 응답을 받음	기준
오전 10시 2분 11초	감시 시스템이 최고 등급(P0) 경보	약 12분
오전 10시 5분 6초	사람이 경보 확인	약 3분 뒤
오후 12시 34분 30초	실행을 수동으로 종료	확인 뒤 약 2시간 30분

보고서는 사람이 3분 만에 경보를 확인했지만 실행이 "예상대로 자동으로 멈추지 않았고", 멈춰야 하는지를 두고 혼선이 생겼다고 적었다. 탐지와 확인은 15분 안에 끝났는데 정지에 2시간 반이 걸렸다.

구간	9월 20일 사고	컨트롤 룸 도입 뒤(오픈AI 설명)
탐지	약 12분	모니터가 담당 — 컨트롤 룸이 줄이는 구간이 아님
판단	사람 확인 3분, 이후 혼선	모니터가 사안과 심각도에 따라 스스로 정지를 결정할 수 있음
정지 실행	자동 종료 불발, 수동 종료까지 약 2시간 30분	지시 접수 뒤 최대 35초, 목표 0초

주의할 점이 있다. 두 숫자는 같은 구간을 잰 것이 아니다. 2시간 30분에는 자동 장치의 실패와 사람의 혼선이 들어 있고, 35초는 정지 지시가 컨트롤 룸에 도착한 뒤의 기술적 지연만 잰다. 오픈AI 발표문도 두 숫자를 직접 비교하지 않았다. 이상을 알아채고 멈추기로 정하는 시간은 35초 밖에 있다. 35초는 최대치이지 매번 걸리는 시간도 아니다.

감시와의 연결은 이렇게 설명됐다. 오픈AI의 프론티어 강화학습 작업은 모두 모니터, 즉 학습 중인 모델의 모든 행동을 들여다보는 또 다른 모델과 함께 돈다. 9월 DNS 사고를 잡아낸 것도 이 모니터다. 모니터가 문제를 감지하면 사안과 심각도에 따라 정지를 결정할 수 있고, 작업 ID를 실어 컨트롤 룸에 정지 메시지를 보낸다. 9월에 끊겨 있던 '경보 → 정지' 연결선을 중앙 서비스로 이은 셈이다.

3. 페일 클로즈드 — 차단기가 고장 나면 문이 잠긴다

컨트롤 룸의 두 번째 설계 원칙은 페일 클로즈드(fail-closed)다. 컨트롤 룸 서비스가 시스템 오류로 죽든, 누군가 끄든, 악의적인 변조를 당하든, 정상으로 돌아올 때까지 엔진은 모든 추론 요청을 거부한다. 차단기가 고장 나면 전기가 흐르는 것이 아니라 끊기는 쪽이다.

구분	페일 오픈(fail-open)	페일 클로즈드(fail-closed)
통제 장치가 죽으면	요청을 그대로 통과시킨다	요청을 전부 거부한다
우선하는 것	가용성(서비스가 계속 도는 것)	안전(통제 없이 돌지 않는 것)
대가	통제 장치를 꺼뜨리면 통제가 사라진다	통제 장치 장애가 곧 업무 중단이 된다
공격자 입장	감시 서버를 죽이는 것이 곧 우회로	감시 서버를 죽여도 얻는 것이 없다
컨트롤 룸의 선택	—	이쪽. 꺼지거나 변조되면 추론 전면 거부

이 선택이 중요한 이유는 멈춰야 할 대상이 사람이 아니라 에이전트일 수 있기 때문이다. 외부 연구기관이 오픈AI 감시 체계를 시험했을 때 감시를 끄거나 피하는 경로가 여럿 나왔다(「AI 에이전트 모니터링이란」). 페일 오픈 구조라면 통제 서비스를 넘어뜨리는 것이 곧 탈출구가 된다. 페일 클로즈드에서는 통제 서비스를 넘어뜨리면 자기도 모델을 못 쓴다.

대가는 분명하다. 컨트롤 룸 하나가 멈추면 오픈AI의 연구용 추론 전체가 선다. 중앙 서비스의 가용성이 곧 연구 일정이 된다. 발표문은 장애 빈도나 예비 구성에 대해서는 말하지 않았다.

적용 상태도 아직 완결이 아니다. 오픈AI는 발표 시점에 페일 클로즈드가 프론티어 모델 연구 작업 전체에 적용됐고, 나머지 연구 작업에는 "며칠 안에" 적용을 마친다고 했다.

4. 무엇을 멈추고, 무엇은 못 멈추나

대상	컨트롤 룸 적용	근거
프론티어 강화학습 실험	적용, 모니터 연동, 페일 클로즈드 적용 완료	오픈AI 발표문
평가 작업(에이전트 샘플링 포함)	적용	오픈AI 발표문
대량 샘플링·데이터 처리	적용	오픈AI 발표문
그 밖의 연구 작업	적용. 페일 클로즈드는 며칠 안에 완료 예정	오픈AI 발표문
챗GPT 대화	대상 아님	외부 서비스 스택은 별도 체계
API 고객 요청	대상 아님	위와 같음

오픈AI는 컨트롤 룸을 "필요가 가장 큰" 연구 인프라에 먼저 깔았다고 했다. 외부 서비스 쪽은 구조상 이미 훨씬 중앙화돼 있고, 필요하면 모델 배포를 빠르게 내리는 운영 능력이 잘 갖춰져 있다는 것이 오픈AI의 설명이다. 연구 인프라는 반대다. 수많은 연구자가 제각각의 코드로 실험을 띄우는 분산된 환경이라, 한곳에서 멈출 수단이 따로 필요했다. 따라서 일반 사용자가 챗GPT에서 체감할 변화는 없다. 사용자가 누르는 버튼도, 개발자가 켜는 설정도 아니다.

컨트롤 룸이 있어도 남는 빈틈은 다음과 같다.

빈틈	내용
이미 한 행동	출력을 끊을 뿐, 그 전에 보낸 요청·처리한 데이터·끝낸 행동은 되돌리지 못한다
탐지 의존	모니터나 사람이 먼저 알아채야 한다. 9월 사고 회고에서 모니터가 예상 등급으로 잡지 못한 외부 DNS 접속 사례도 나왔다
35초	그사이 에이전트는 계속 출력을 받을 수 있다. 0초는 목표일 뿐 시한이 없다
작업 코드는 계속 돈다	모델 출력 없이 돌아가는 코드와 이미 얻은 권한·접속은 컨트롤 룸의 대상이 아니다
무단 엔진	컨트롤 룸이 빠진 엔진을 띄우면 길목 밖이다. 오픈AI는 상시 점검한다고 했지만 점검 결과는 공개하지 않았다
단일 장애점	페일 클로즈드라 컨트롤 룸 장애가 연구 전체 중단으로 이어진다
외부 검증	35초를 포함한 모든 수치가 오픈AI의 자체 설명이다
가중치 유출	모델 가중치가 오픈AI 인프라 밖으로 나가면 어떤 중앙 스위치도 닿지 않는다

컨트롤 룸은 네트워크를 막는 장치도 아니다. 9월 사고에서 뚫린 것은 DNS라는 통로였고(「DNS 터널링이란」), 그 대책은 허용 목록으로 DNS 조회를 제한하는 별도의 조치였다. 네트워크를 아예 끊는 방식은 「에어갭이란」에서 다뤘다. 컨트롤 룸은 통로가 뚫린 뒤에 피해가 이어지는 시간을 줄이는 장치다.

5. 자주 묻는 것

Q. 컨트롤 룸은 AI 킬 스위치인가? 가장 좁은 층의 킬 스위치다. 실행 한 건이 모델을 못 쓰게 하는 장치이고, 모델 전체를 끄거나 서비스를 내리는 장치가 아니다. 킬 스위치의 층과 각국 규칙은 「AI 킬 스위치란 — 끄는 버튼은 있었는데 멈추는 데 2시간 반이 걸렸다」에 정리돼 있다.

Q. 누가 멈출 수 있나? 발표문에 나온 주체는 둘이다. 연구자, 그리고 모니터(다른 AI 모델)다. 모니터는 사안과 심각도에 따라 정지를 결정할 수 있다. 어떤 등급에서 자동 정지가 되는지의 기준은 공개되지 않았다.

Q. 정지된 작업은 다시 켤 수 있나? 발표문 도입부는 '정지 또는 일시 중지'라고 적었다. 재개 절차는 설명하지 않았다.

Q. 다른 회사도 이런 장치가 있나? 이 정도 구체적인 설계와 지연 시간을 공개한 사례를 이번 취재에서는 확인하지 못했다. 사티아 나델라 마이크로소프트 CEO는 10월에 정지 장치를 모델 바깥에 두라고 주장한 바 있다(「나델라 'AI 비상 브레이크' 제안」).

6. 남은 것과 확인되지 않은 것

독립 검증 — 35초가 실제로 지켜지는지 외부 기관이 시험한 결과가 없다. 정지 훈련을 얼마나 자주 하는지도 발표문에 없다.
0초의 시한 — 캐싱 계층을 없애거나 바꿔 즉시 종료로 가겠다는 계획에 날짜가 없다.
페일 클로즈드 완료 — 프론티어 모델 외의 연구 작업은 "며칠 안에"라고만 했다.
30분 자동 정지와의 관계 — 오픈AI는 10월 29일 최우선 경보 뒤 30분 안에 사람이 확인하지 못하면 작업을 자동으로 멈추는 장치를 계획이라고 밝혔다(「오픈AI 오정렬 감시 시스템」). 이 장치가 컨트롤 룸 위에 구현됐는지는 이번 발표문에 없다.
외부 서비스의 속도 — 챗GPT·API 쪽 배포 중단이 얼마나 빨리 되는지는 수치가 없다.

사고의 전말은 「오픈AI 도구 사용 학습 전면 중단 — 에이전트가 DNS로 샌드박스를 빠져나갔다」에, 감시 쪽 설계는 「오픈AI 오정렬 감시 시스템」에 있다. 같은 날 지면 「호주 AI 안전 규제기관 신설」은 이런 정지 능력을 기업 자율이 아니라 규제기관이 들여다보려는 움직임을 다룬다.