Human at the End of the Loop: 레드불 레이싱, 경주 중 규정 조회는 LLM이 하고 판단은 엔지니어가

Oracle Red Bull Racing은 경주 중 시간에 쫓기는 엔지니어가 규정집과 과거 결정 기록을 뒤지는 일을 LLM 비서에게 맡기고 결정은 끝까지 엔지니어에게 남겼습니다. 같은 구조를 들이려면 모델보다 먼저 조회할 문서와 과거 결정 기록을 정리하고 사람이 출력을 확인하는 단계를 업무 절차에 박아 넣어야 합니다.

요약

AIM Media House의 Deployed 섹션에서 Amit Raja Naik가 2026년 11월 2일 Oracle Red Bull Racing의 기술·성능 파트너십 책임자 Jack Harington을 인터뷰한 기사를 냈습니다. 인터뷰는 라스베이거스 Oracle AI World에서 이뤄졌습니다. 팀과 Oracle은 2026년 2월 타이틀 파트너십을 여러 해 연장했고 범위는 클라우드 인프라, AI, 기업용 애플리케이션까지 넓습니다. Oracle 컨설턴트가 팀 엔지니어 옆에서 일하며 기술이 성능을 끌어올릴 지점을 찾습니다. 기사가 다루는 AI 활용은 셋입니다. 경주 전 전략 시뮬레이션, 경주 중 LLM 비서, 그리고 아직 개발 중인 드라이버 발굴입니다.

경주 전에는 Monte Carlo 시뮬레이션(무작위 변수를 넣어 같은 상황을 수없이 반복 계산하는 방법)을 80억 회 돌려 타이어를 언제 바꿀지 같은 선택지를 미리 따져 둡니다. 경주 중에는 세이프티카 하나로 피트 스톱의 값이 바뀌므로 엔지니어가 전략을 다시 봐야 합니다. 이때 LLM(대규모 언어 모델) 기반 대화형 비서가 경기 규정과 과거 경주 결정을 찾아 줍니다. 팀은 Oracle과 함께 수개월에 걸쳐 환각(그럴듯하지만 틀린 답) 문제를 다뤘고 출력 확인과 최종 결정은 엔지니어가 맡습니다. Harington은 파트너십 뒤 전략 시뮬레이션이 25%, 파워유닛 부문의 CFD(전산 유체 역학) 시뮬레이션이 20% 늘었다고 밝혔습니다. 수치는 모두 팀 측 설명입니다. 아래에서 네 가지 작동 원리와 세 사례를 본 뒤, 이 구조를 다른 업무에 옮길 때 필요한 기술·현업 디테일을 붙입니다.

핵심 메커니즘

Race-time LLM Assistant: 시간 압박 속 규정·과거 결정 조회 비서

경주 중 엔지니어가 대화하듯 질문하면 비서가 경기 규정과 과거 경주에서 내린 결정을 찾아 답하는 도구입니다. 입력은 엔지니어의 자연어 질문이고 조회 범위는 규정과 과거 결정이며 출력은 엔지니어가 판단에 쓸 답변입니다. 이 일을 비서가 맡으니 엔지니어는 문서를 넘기는 대신 경주 자체에 집중할 수 있습니다. 어떤 LLM을 쓰는지, 어떤 Oracle 제품 위에 올렸는지는 기사에서 밝히지 않았습니다. 이 방식은 답이 문서와 기록 안에 있고 찾는 시간이 결정의 질을 떨어뜨리는 업무에 맞습니다. 문서 근거 없이 새 판단을 만들어 내야 하는 질문에는 맞지 않습니다. 가상 예시로, 세이프티카가 나온 랩에 피트인할 때 어떤 규정이 적용되는지, 비슷한 상황에서 팀이 예전에 어떻게 했는지를 한 번에 묻는 식입니다.

Human at the End of the Loop: 출력 확인과 최종 결정은 사람이 한다

AI가 답을 내도 그 답이 맞는지 확인하고 결정하는 사람이 마지막에 서 있는 운영 원칙입니다. Harington은 결정이 맞는지 확인하려면 “human at the end of the loop”가 늘 필요하다고 말했습니다. 팀은 환각을 줄이는 작업을 Oracle과 함께 수개월 동안 했고 그래도 엔지니어가 출력을 확인하고 최종 결정을 내리는 절차를 남겼습니다. 틀린 답 하나가 경주 결과나 규정 위반으로 이어지는 업무라면 이 원칙이 기본값입니다. 반대로 틀려도 되돌리기 쉬운 반복 업무에서 모든 출력을 사람이 보면 비서를 둔 효과가 줄어듭니다.

Pre-race Monte Carlo Strategy: 경주 전에 경주를 수십억 번 돌려 본다

경주가 열리기 전에 가능한 전개를 대량으로 시뮬레이션해 선택지마다 결과 분포를 보는 방법입니다. 입력은 연습 주행 데이터와 경쟁팀이 Red Bull의 선택에 어떻게 반응할지에 대한 가정입니다. 처리 단계에서 몬테카를로 시뮬레이션을 80억 회 돌리고 출력은 피트 스톱 시점 같은 결정의 시나리오별 평가입니다. 모델은 경주 중에도 새 상황에 맞춰 갱신할 수 있습니다. 변수가 많고 상대의 반응이 결과를 바꾸는 결정에 쓰고 변수가 몇 개뿐이라 규칙으로 풀리는 결정에는 과합니다. 연산은 OCI(Oracle Cloud Infrastructure)가 댑니다.

Elastic Compute for a Growing Team: 조직과 함께 늘리는 연산 자원

연산 설비를 먼저 지어 놓고 사람을 뽑는 대신, 채용과 개발 속도에 맞춰 클라우드 연산을 늘려 가는 방식입니다. Red Bull Ford Powertrains(RBFP)는 공장도 시뮬레이션 설비도 없이 2026년용 파워유닛 개발을 시작했습니다. 일정상 대형 데이터센터를 짓기는 현실적이지 않았고 OCI 연산을 조직이 크는 만큼 키웠습니다. 조직은 6년이 안 돼 700명을 넘었습니다. 처음부터 시작하는 조직이나 연산 수요가 빠르게 바뀌는 시기에 맞고 이미 설비가 있고 수요가 고른 조직에는 이점이 작습니다.

통념과 다른 주장

저자가 든 사례

경주 중 LLM 비서: 규정 조회는 비서가, 결정은 엔지니어가

• 상황: 세이프티카처럼 전개가 바뀌면 엔지니어는 짧은 시간 안에 전략을 다시 따져야 하고 그때 규정과 과거 결정을 확인해야 합니다.
• 한 일: Oracle과 함께 LLM 기반 대화형 비서를 수개월에 걸쳐 만들고 환각 문제를 다뤘습니다.
• 결과: 엔지니어가 조회 대신 경주에 집중합니다. 출력 확인과 최종 결정은 엔지니어 몫입니다. 사용 빈도, 정확도, 운영 기간은 기사에서 밝히지 않았습니다.
• 연결: Race-time LLM Assistant, Human at the End of the Loop.

Red Bull Ford Powertrains: 설비 없이 시작한 엔진 조직

• 상황: 그동안 외부 엔진 공급사로 우승해 온 팀이 2026년용 파워유닛을 직접 만들기로 했습니다. 공장도 시뮬레이션 설비도 없었습니다.
• 한 일: 데이터센터를 짓는 대신 OCI 연산을 채용·개발 속도에 맞춰 늘렸습니다. Ford는 내연기관·배터리 전문성, 제어 시스템, 공급망 지원을 맡았습니다.
• 결과: 조직이 6년이 안 돼 700명을 넘었고 RBFP의 CFD 시뮬레이션이 20% 늘었다고 Harington이 밝혔습니다.
• 연결: Elastic Compute for a Growing Team.

드라이버 발굴: 순위 뒤에 숨은 실력 찾기

• 상황: 성능이 떨어지는 차에 탄 드라이버의 실력은 완주 순위에 다 드러나지 않습니다. 비 오는 경주처럼 실력이 더 잘 보이는 조건도 있습니다.
• 한 일: Oracle과 함께 AI로 덜 알려진 레이싱 시리즈까지 살피고 결과 뒤의 상황을 읽는 성과 지표를 찾는 프로젝트를 진행합니다.
• 결과: 아직 개발 중이며 공개된 결과는 없습니다. 목표는 다음 Max Verstappen을 찾는 것입니다.
• 연결: 결과 숫자 뒤의 맥락을 읽는다는 점에서, Pre-race Monte Carlo Strategy의 데이터 기반 판단을 인재 영역으로 넓히는 시도입니다.

기술 디테일: 업무 중 규정·과거 결정 조회 비서를 만든다면

아래 구성, 필드명, 설정값은 기사에 없는 실행 제안이자 가상 예시입니다. 기사가 밝힌 것은 LLM 기반 대화형 비서, 조회 대상(규정과 과거 결정), 수개월의 환각 대응, 사람의 최종 결정까지입니다.

조회 대상을 두 개의 색인으로 나눕니다(Race-time LLM Assistant). 규정 문서는 조항 단위로 자르고 조항 번호, 개정 버전, 시행일을 메타데이터로 붙입니다. 과거 결정 기록은 결정 한 건을 레코드 하나로 만듭니다. 언제, 어떤 상황에서, 무엇을 결정했고 근거 조항이 무엇이었으며 결과가 어땠는지를 필드로 둡니다. 두 색인을 따로 두어야 “규정상 허용되는가”와 “예전에 어떻게 했나”를 섞지 않고 답할 수 있습니다. 검색은 키워드 검색과 임베딩 검색을 함께 쓰고 상위 5~8개 조각만 모델에 넘깁니다.

{
  "decision_id": "D-2025-R14-L32",
  "date": "2025-08-31",
  "situation": "후반 세이프티카, 타이어 수명 12랩 남음",
  "decision": "즉시 피트인, 하드 타이어",
  "rule_refs": ["규정 조항 번호", "규정 버전 v3"],
  "outcome": "순위 유지",
  "recorded_by": "전략 엔지니어"
}

답변은 근거를 붙인 구조화 출력으로 받습니다(Human at the End of the Loop). 사람이 몇 초 안에 확인하려면 답과 근거가 나란히 보여야 합니다. 모델에 아래 형식으로만 답하게 하고 temperature는 0으로 둡니다.

{
  "answer": "한 문장 답",
  "rule_citations": [{"doc": "규정집", "article": "조항 번호", "version": "v3", "quote_span": "근거 문장"}],
  "past_decisions": ["D-2025-R14-L32"],
  "confidence": "high | low",
  "needs_human_check": true,
  "no_source": false
}

환각은 생성 뒤 검증 단계에서 막습니다(Race-time LLM Assistant 사례). 응답의 quote_span이 검색된 원문 조각에 글자 그대로 있는지 코드로 대조합니다. 없으면 답을 버리고 근거 조각만 보여 줍니다. 검색 결과가 비거나 점수가 기준 아래면 no_source를 true로 두고 “근거를 찾지 못함”이라고 답하게 합니다. 규정 버전이 바뀌면 이전 버전 조각은 색인에서 내리거나 version 필터로 걸러 냅니다. 경주처럼 응답 시간이 중요하면 목표 응답 시간(예: 5초)을 정하고 이를 넘기면 근거 조각 목록만 먼저 보여 줍니다.

평가 세트를 먼저 만듭니다. 현장 사용자에게 실제로 물었던 질문 100개와 정답 조항을 받습니다. 매번 모델이나 프롬프트를 바꿀 때 이 세트를 3회 반복 실행해 정답 조항 적중률, 근거 없는 답 비율, 거절률을 봅니다. 같은 질문에 반복 실행 결과가 갈리면 그 질문은 문서 쪽이 모호하다는 신호이므로 문서 담당에게 넘깁니다. 모델은 응답 시간 목표를 먼저 정한 뒤 고릅니다. 검색 조각이 5~8개면 긴 문맥 모델이 필요 없으니 목표 시간 안에 답하는 모델 가운데 평가 세트 적중률이 가장 높은 것을 씁니다. 다른 회사 모델 하나로 같은 세트를 한 번 더 돌려, 두 모델의 답이 갈리는 질문에는 화면에 확인 필요 표시를 붙입니다.

결정 로그를 남깁니다(Human at the End of the Loop). 질문, 비서 답변, 사람이 따랐는지 여부(accepted, edited, rejected), 바꾼 이유를 한 줄로 기록합니다. 이 로그가 다음 시즌의 과거 결정 색인이 됩니다.

막히는 경우	증상	대응
규정 개정 반영 누락	옛 조항으로 답함	색인에 버전·시행일 필수, 개정 시 재색인 체크리스트
과거 결정 기록이 메모 수준	비슷한 사례를 못 찾음	결정 기록 양식을 먼저 정하고 최근 기록부터 구조화
근거 없이 그럴듯한 답	인용 문장이 원문에 없음	인용 대조 실패 시 답 폐기, 근거 조각만 표시
응답이 느림	결정 시점을 놓침	검색 조각 수 축소, 시간 초과 시 근거 목록 우선 표시
사용자가 확인 없이 따름	거절·수정 기록이 0에 가까움	화면에서 근거 확인을 거쳐야 수락 버튼이 열리게 설계

현업 실행 디테일: 누가, 언제, 무엇을

기사가 전한 역할은 엔지니어가 묻고 확인하고 결정한다는 것까지입니다. 아래 역할, 일정, 판정 기준은 이를 다른 업무에 옮기기 위해 새로 짠 가상 예시입니다.

역할	맡는 일
업무 책임자(현업 리더)	시범 업무와 질문 범위 확정, 진행 판정, 현장 스폰서
현장 사용자 3~5명	실제 질문 수집, 정답 검수, 병행 사용과 수락·거절 기록
규정·문서 담당	규정·매뉴얼 최신본과 버전 관리, 과거 결정 기록 구조화
AI·IT 담당	색인과 검색, 구조화 출력, 인용 검증, 로그와 평가
법무·컴플라이언스	틀린 답이 위반으로 이어질 수 있는 질문 유형 지정

준비물. 현행 규정·매뉴얼 전체와 개정 이력, 최근 1~2년치 결정 기록(회의록, 판정서, 교대 일지), 현장 사용자가 지난 한 달 동안 찾아본 질문 목록, 질문마다 찾는 데 걸린 시간이 필요합니다. 결정 기록이 흩어져 있는 경우가 많으므로 첫 2주를 기록 양식 정리에 씁니다.

기간	할 일	산출물
1~2주	질문 100개 수집, 정답 조항 표시, 문서 버전 정리, 조회 시간 실측	평가 세트, 문서 목록, 조회 시간 기준선
3~4주	두 색인 구축, 구조화 출력과 인용 검증 연결, 평가 세트 3회 실행	시범 비서, 적중률·거절률 첫 결과
5~7주	현장 병행 사용, 수락·수정·거절 기록, 주 1회 오답 검토	결정 로그, 오답 유형 목록
8주	판정 회의, 확대 범위 결정	진행·보완·중단 결정서

현장에 물을 것.

1. 일하다가 규정이나 매뉴얼을 찾아보는 순간은 하루에 몇 번이고 한 번에 몇 분 걸리나요?
2. 지난달 찾다가 결정이 늦어졌거나 틀린 조항을 본 적이 있나요? 그때 무엇을 봤나요?
3. 예전 결정을 참고할 때 어디를 뒤지나요? 회의록, 메신저, 기억 중 어느 쪽인가요?
4. AI 답을 확인할 때 무엇이 함께 보이면 믿고 쓸 수 있나요?
5. 틀리면 큰일 나는 질문은 무엇이고 그 질문은 누가 최종 확인해야 하나요?

진행 판정 기준(예시). 평가 세트에서 정답 조항 적중률이 90% 이상이고 근거 없는 답이 2% 아래이며 병행 사용에서 조회 시간이 기준선보다 절반 이하로 줄면 다음 업무로 넓힙니다. 적중률이 80~90%면 문서 정리와 검색을 고쳐 3주 더 봅니다. 근거 없는 답이 5%를 넘으면 사용을 멈추고 인용 검증부터 다시 짭니다.

AX 적용 제언. 이 구조는 레이싱보다 제조·물류·금융 현장에 더 자주 들어맞습니다. 교대 중 설비 이상이 났을 때 안전 규정과 과거 조치 기록을 찾는 정비 엔지니어, 품질 판정 기준과 과거 판정을 맞춰 보는 품질 담당, 약관과 과거 처리 사례를 확인하는 보상 담당이 같은 일을 합니다. 순서는 결정 기록 양식 정리, 조회 비서, 결정 로그 축적입니다. 처음부터 AI에게 결정을 맡기지 말고 시간에 쫓기는 조회부터 덜어 주면서 사람이 확인하는 단계를 화면 설계에 넣습니다. 쌓인 결정 로그는 나중에 시뮬레이션이나 추천으로 넘어갈 때 학습 자료가 됩니다. 현장 스폰서는 그 업무의 최종 결정권자가 맡아야 확인 절차가 형식에 그치지 않습니다.

원문 사례

항목	내용
원문	AIM Media House Deployed 섹션, 2026.11.2 게재, Amit Raja Naik 작성, 오피니언 표시
화자	Jack Harington, Oracle Red Bull Racing 기술·성능 파트너십 책임자. Oracle AI World(라스베이거스)에서 인터뷰
파트너십	2026년 2월 Oracle과 타이틀 파트너십 다년 연장. 클라우드 인프라, AI, 기업용 애플리케이션. RBFP, Red Bull Advanced Technologies까지 포함
경주 중 비서	LLM 기반 대화형 비서, 규정과 과거 경주 결정 조회, Oracle과 수개월 개발, 환각 대응, 엔지니어가 확인·최종 결정
경주 전 전략	몬테카를로 시뮬레이션 80억 회, 연습 주행 데이터와 경쟁팀 반응 반영, 경주 중 갱신 가능
증가 수치	전략 시뮬레이션 25% 증가, RBFP CFD 시뮬레이션 20% 증가(팀 측 설명, 기준 기간 미표기)
RBFP	공장·시뮬레이션 설비 없이 시작, 6년이 안 돼 700명 넘는 조직, OCI로 연산 확장, Ford가 내연기관·배터리·제어·공급망 지원
경영 지원	Milton Keynes 캠퍼스에서 Fusion Cloud HCM(생성형 AI 내장)으로 직원 성장 계획, Fusion Cloud EPM으로 비용 상한 안 예산 시나리오
드라이버 발굴	AI로 덜 알려진 시리즈와 성과 지표 탐색, 열세인 차·빗길 경주 같은 맥락 반영, 개발 중
배경	2005년 Jaguar 팀 인수로 F1 진입, 컨스트럭터 챔피언십 6회

핵심 개념

Safety Car

사고나 위험 상황에서 코스에 들어와 경주 차량의 속도를 묶는 차량입니다. 이때 피트 스톱의 손해가 줄어 전략 계산이 바뀝니다.

Pit Stop

경주 중 차량이 정비 구역에 들어와 타이어 교체 등을 하는 것입니다. 언제 들어오느냐가 순위를 크게 바꿉니다.

CFD

Computational Fluid Dynamics. 공기나 유체의 흐름을 컴퓨터로 계산하는 방법으로, 차체와 엔진 설계에 씁니다.

Cost Cap

F1 팀이 한 시즌에 쓸 수 있는 비용의 상한입니다. 그 안에서 어디에 돈을 쓸지가 경쟁력이 됩니다.

OCI

Oracle Cloud Infrastructure. Oracle의 클라우드 연산·저장 서비스로, 여기서는 시뮬레이션과 엔진 개발 연산을 댑니다.

Hallucination

LLM이 근거 없이 그럴듯한 답을 만들어 내는 현상입니다. 규정 조회처럼 정답이 문서에 있는 업무에서 특히 위험합니다.

내 메모

TODO: 내 생각 추가

원문은 AIM Media House Deployed 섹션의 「Red Bull wants AI agents to help find the next Max Verstappen」(Amit Raja Naik, 2026.11.2)입니다. Jack Harington 인터뷰와 Oracle AI World 세션을 바탕으로 한 오피니언 기사이며 80억 회, 25%, 20%, 700명 같은 수치는 팀과 Oracle 측 설명입니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 핵심 개념의 뜻풀이와 언제 쓰고 언제 안 쓰는지에 대한 설명은 일반적인 정의로 보탰습니다. 색인 구성, JSON 예시, 인용 검증, 평가 세트, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽은 기사에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 내용은 원문 페이지에서 볼 수 있습니다.