How Ultrafast cut incident investigation from hours to minutes at OpenAI

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

OpenAI의 내부 활용 사례에서 Codex의 고속 모드 Ultrafast는 여러 장애 원인을 동시에 조사하고 업무 집중을 유지하도록 도왔으며, AJ Trbojevic은 보안 조사에 필요한 데이터 정리와 맥락 파악이 기존 1~2시간에서 10~15분으로 줄었다고 설명했다.

📌 핵심 요약

• Ultrafast는 Codex의 고속 모드로, OpenAI 엔지니어들의 기본적인 장애 대응 방식으로 자리 잡았다. Aaron Friel은 장애 대응용 Slack 채널에서 Codex에 모니터링·조사·질의응답을 맡기고 여러 잠재 원인을 동시에 탐색한다.
• AJ Trbojevic에 따르면 보안 문제 조사에서 정형·비정형 데이터를 모으고 정규화해 의사결정에 필요한 맥락을 제공하는 작업은 기존 1~2시간에서 10~15분으로 단축됐으며, 때로는 거의 실시간으로 이뤄진다.
• Adam Perry는 Ultrafast가 충분히 빨라져 Codex에 맡긴 조사를 자신도 동시에 수행할 필요가 줄었다고 설명했다. Sayan Sisodiya는 로그뿐 아니라 Slack에서 의심스러운 변경 사항이나 비슷한 증상에 관한 대화도 찾는다.
• Jeff Niu는 AI 응답이 30초를 넘으면 다른 활동으로 전환하지만, Ultrafast에서는 업무 대부분이 그 기준 안에서 처리된다고 말했다. 그는 코드 재작업 시간이 줄어 대규모 리팩터링과 기술 부채 해소에도 더 적극적으로 나서게 됐다고 설명했다.
• Adam Perry는 지속적인 Codex 대화를 통해 아침 일정과 답장을 놓쳤을 수 있는 메시지를 확인하고 후속 질문을 이어 간다. Sayan Sisodiya는 최신 모델의 컴퓨터 사용 능력 개선과 빨라진 처리 속도 덕분에 브라우저 양식 입력 같은 수작업을 Codex에 맡기는 데 더 편안함을 느낀다.

🧩 주요 포인트

1. 여러 잠재 원인의 병렬 조사와 로그·Slack 탐색 → 장애 원인을 찾는 범위를 넓히면서 보안 조사에 필요한 정보 취합과 맥락 파악 시간을 단축한다.
2. Jeff Niu의 30초 기준과 Adam Perry의 중복 조사 감소 → 응답 속도가 작업 전환과 주의 분산을 줄여 Codex와 같은 흐름에서 업무를 이어 가게 한다.
3. 리팩터링·기술 부채 해소·일정 확인·브라우저 양식 입력으로 활용 확대 → 대기시간 감소가 미뤄 둔 작업에 착수하거나 일상 업무를 위임할 의향까지 바꾼다.

🧠 상세 정리

1. 장애 대응의 기본 도구가 된 Ultrafast

이 글은 OpenAI가 자체 기술과 API를 내부에서 활용하는 사례를 소개하는 연재의 일부로, Codex의 고속 모드인 Ultrafast가 엔지니어들의 기본적인 장애 대응 방식으로 자리 잡았다고 설명한다. 장애가 발생해 문제가 커지는 상황에서는 답변을 받기 위해 몇 분씩 기다리기 어렵기 때문에, 여러 잠재 원인을 동시에 조사하고 주의를 분산하지 않는 능력이 중요하다. 장애 대응을 주도하는 경우가 많은 Aaron Friel은 Slack 채널을 개설한 뒤 Codex에 문제를 제시하고 모니터링과 조사, 들어오는 질문에 대한 답변을 맡긴다. 그는 장애 원인에 이르는 경로에는 잘못됐을 가능성이 있는 지점이 여럿 있으며, 올바른 원인을 찾아내는 것이 대응 인력의 핵심 업무라고 말한다. Ultrafast는 이런 여러 후보 영역을 동시에 탐색할 수 있게 해 장애에 더 빠르게 대응하도록 돕는다는 설명이다.

2. 보안 조사에 필요한 정보 정리 시간의 단축

OpenAI의 기술 직원이자 데이터센터 보안 아키텍트인 AJ Trbojevic은 보안 문제 조사에서 정보 준비에 걸리는 시간이 크게 줄었다고 설명한다. 이전에는 정형 데이터와 비정형 데이터를 한데 모으고, 이를 정규화한 다음, 의사결정에 필요한 맥락을 제공하는 데 1~2시간이 걸렸다. 그의 설명에 따르면 이제 같은 작업이 10~15분 안에 이뤄지며, 때로는 거의 실시간으로 진행되기도 한다. 여기서 제시된 시간 단축은 보안 조사에 필요한 데이터 취합·정규화·맥락 제공 과정에 관한 것으로, 정보가 판단에 쓰일 수 있는 상태가 되기까지의 변화다. 이 사례는 앞서 Aaron Friel이 설명한 여러 잠재 원인의 동시 탐색과 함께, Ultrafast가 장애 대응 과정의 조사 속도를 어떻게 바꾸는지 보여 준다.

3. 중복 조사 대신 집중을 유지하는 방식

Adam Perry와 Sayan Sisodiya는 Codex가 행동하고 명령을 실행하며 도구를 사용할 수 있도록 하는 코드를 만드는 핵심 에이전트 팀에서 일한다. Adam Perry는 과거에는 Codex에 조사를 요청해도 기다릴 만큼 빠르지 않다고 생각해, 자신도 같은 문제를 동시에 살펴봤다고 말한다. Ultrafast를 사용한 뒤에는 Codex의 속도가 충분히 빨라져 주의를 나누지 않고 현재 업무에 집중할 수 있게 됐다는 설명이다. Sayan Sisodiya는 여러 데이터 출처에서 즉시 답을 얻을 수 있다는 점을 높이 평가하며, 장애 조사 중 로그를 확인하는 데서 그치지 않고 Slack 대화도 탐색한다. 구체적으로는 의심스러울 수 있는 변경 사항의 언급이나 다른 곳에서 비슷한 증상을 이야기한 사람이 있는지 찾아, 조사에 필요한 단서를 확보한다.

4. 30초 응답 기준과 리팩터링에 대한 태도 변화

Jeff Niu는 AI로 답을 찾는 데 30초가 넘게 걸리면 Slack을 확인하거나 동료와 이야기하게 된다고 말하지만, Ultrafast에서는 자신의 업무 대부분이 그 기준 안에서 처리된다고 설명한다. 과거에는 Codex에 질문한 뒤 생각하는 동안 다른 일을 하러 갔다가, 돌아왔을 때 원래의 사고 흐름을 잃곤 했다. 이제는 대화가 실시간으로 이어져 당면한 작업에 집중하기 쉬워졌다는 것이다. 속도 향상은 기존 코드를 고치는 시간도 줄여, 그가 대규모 리팩터링에 더 적극적으로 나서도록 했다. 그는 기술 부채를 해소하기가 이전보다 훨씬 쉬워졌으며, 과거에는 비용이 많이 들던 리팩터링이 거의 즉시 이뤄진다고 표현한다. 이 부분은 빠른 응답이 질문에 대한 대기시간뿐 아니라 엔지니어가 어떤 작업을 감수할지에도 영향을 준다는 경험을 담고 있다.

5. 맥락을 이어 가는 일상 업무 보조

Adam Perry는 장애 조사 외에도 지속적으로 이어 가는 Codex 대화를 활용하며, 이를 자신의 비서실장이라고 부른다. 이 대화는 매일 아침 그날 어떤 회의가 있는지와 답장을 잊었을 수 있는 메시지가 무엇인지 알려 준다. 그는 Codex가 해당 요약을 작성하기 위해 이미 관련 데이터를 살펴본 상태이므로, 후속 질문을 할 때 추가 정보를 가져오느라 기다리는 과정이 필요하지 않다고 설명한다. 덕분에 같은 대화 안에서 실제 비서실장에게 묻듯 질문을 계속 이어 갈 수 있다는 것이다. 이 사례는 한 번의 요약으로 업무가 끝나는 방식보다, 앞서 확보한 맥락을 바탕으로 질문과 답변을 연속해서 주고받는 활용 모습을 보여 준다. 장애 대응에서 강조된 빠른 후속 응답과 사고 흐름의 유지가 일상적인 일정 및 메시지 확인에서도 나타난다.

6. 브라우저 작업 위임과 활용 범위의 확대

Sayan Sisodiya는 브라우저에서 양식을 입력하는 것처럼 번거로운 수작업에도 Codex를 사용하지만, 예전에는 처리 속도가 느려 이런 활용을 피했다고 말한다. 당시에는 브라우저를 열고 5초 동안 생각한 뒤 클릭하고 다시 멈추는 식으로 작업이 진행됐다는 설명이다. 최신 모델의 컴퓨터 사용 능력이 개선된 뒤에는 Codex가 브라우저를 조작하도록 맡기는 데 더 편안함을 느끼며, 직접 하지 않아 시간을 잃는다고 느끼지 않을 만큼 빨라졌다고 평가한다. 글은 장애 대응과 일상 계획, 리팩터링 전반에서 Ultrafast가 질문의 속도에 맞춰 Codex와 일할 수 있게 한다고 정리한다. 답변에 후속 질문을 하거나 다른 접근을 시도하면서도 사고 흐름을 유지할 수 있고, 짧아진 대기시간은 미뤄 둔 리팩터링이나 이제 위임할 만해진 일상 작업에 착수하려는 의향까지 바꾼다는 것이다.

🧾 핵심 주장 / 시사점

• 응답 속도의 가치는 시간 절약과 주의력 유지가 함께 나타나는 데 있다. Adam Perry의 중복 조사 감소와 Jeff Niu의 작업 전환 감소는 기다리는 방식 자체가 달라졌음을 보여 준다.
• 장애 조사는 로그 분석에만 한정되지 않는다. Aaron Friel의 여러 원인 동시 탐색과 Sayan Sisodiya의 Slack 검색은 조사 대상과 정보 출처를 함께 넓히는 활용 방식이다.
• 처리 속도는 위임 여부를 결정하는 조건으로 작용한다. 리팩터링과 브라우저 작업 사례에서는 이전에 부담스럽거나 느리다고 여겼던 업무도 Codex에 맡길 만한 대상으로 바뀌었다.

✅ 액션 아이템

• Ultrafast를 활용한 장애 대응에서 여러 잠재 원인의 병렬 조사와 로그·Slack 탐색 적용을 검토한다.
• AJ Trbojevic의 1~2시간에서 10~15분으로의 단축 사례와 Jeff Niu의 30초 기준을 참고해 조사 소요시간과 작업 전환 감소 효과를 살핀다.
• Codex의 응답 속도를 고려해 리팩터링·기술 부채 해소와 브라우저 양식 입력의 위임 가능성을 검토한다.

❓ 열린 질문

• AJ Trbojevic이 설명한 10~15분의 보안 조사 작업이 거의 실시간으로 이뤄지는 경우에는 어떤 조건이 작용하는가?
• Jeff Niu의 30초 기준을 넘는 업무에서는 작업 전환과 주의 분산이 어떻게 달라지는가?
• 리팩터링과 브라우저 양식 입력을 Codex에 맡길 만하다고 판단하는 데 응답 속도는 어느 정도 영향을 미치는가?