긴 추론 작업을 서비스에 붙여 보면 결국 같은 문제를 만납니다. 30초 안에 끝나는 요청은 대충 처리해도 되지만, 3분, 5분, 10분이 넘어가는 순간 HTTP 연결, 프론트엔드 타임아웃, 재시도 중복 실행, 사용자 이탈, 상태 복구 문제가 한꺼번에 터집니다. OpenAI의 background mode 문서는 이 문제를 꽤 현실적으로 다룹니다. 핵심은 긴 작업을 동기 응답으로 우겨 넣지 말고, 백그라운드 작업 객체로 전환해 상태를 조회 가능한 단위로 운영하라는 것입니다.
실무에서는 이 패턴이 특히 중요합니다. 에이전트가 리포트를 쓰거나, 코드베이스를 읽거나, 여러 도구를 차례로 호출하거나, 대용량 문서를 분석하는 작업은 중간에 끊겨도 계속 이어질 수 있어야 합니다. background mode는 바로 그 지점을 위한 운영 기능입니다. 발표 문서를 보면 background=true로 응답을 시작하고, 이후에는 queued, in_progress, completed 같은 상태를 폴링해 결과를 가져오는 구조입니다.
원칙은 단순합니다. 사용자가 결과를 즉시 받아야 하는가, 아니면 작업이 끝날 때까지 기다릴 필요가 없는가입니다. 예를 들어 채팅 한 줄 답변, 짧은 분류, 간단한 요약은 동기 요청이 낫습니다. 반대로 아래 작업은 background mode 후보입니다.
많은 팀이 처음에는 타임아웃 숫자만 늘립니다. 하지만 그 방식은 운영 비용을 숨길 뿐 해결하지 못합니다. 연결이 끊기면 사용자는 실패로 느끼고, 서버는 같은 요청을 다시 보내고, 모델은 중복 계산을 합니다. background mode의 장점은 결과 생성과 사용자 연결을 분리한다는 데 있습니다.
단순히 background=true를 넣는다고 운영이 좋아지지는 않습니다. 실제로는 애플리케이션 레벨에서 작업 상태를 어떻게 보여주고 복구할지가 더 중요합니다. 최소한 아래 필드는 별도로 저장하는 편이 좋습니다.
이 구조가 있으면 프론트엔드가 새로고침돼도 작업을 이어서 보여줄 수 있습니다. 반대로 상태 저장 없이 백엔드에서만 폴링하면, 사용자가 창을 닫는 순간 경험이 끊깁니다.
실서비스에서 background mode를 붙일 때 제일 많이 보는 실수가 두 가지입니다. 첫째는 사용자가 버튼을 두 번 눌렀을 때 같은 작업이 중복 생성되는 문제입니다. 둘째는 1초마다 상태를 조회해서 오히려 API 낭비와 서버 부하를 키우는 문제입니다.
중복 실행은 idempotency 키 또는 애플리케이션 job dedupe로 막는 편이 좋습니다. 같은 사용자, 같은 입력, 같은 시점의 요청이면 기존 작업을 재사용하도록 설계해야 합니다. 과도한 폴링은 보통 지수 백오프나 상태 기반 간격 조절로 해결합니다. 예를 들어 queued 단계는 5초, in_progress는 10초, 3분 이상 장기 작업은 15초 이상으로 늘리는 식입니다.
문서에서 눈여겨볼 부분은 background=true와 stream=true를 함께 사용할 수 있다는 점입니다. 이 조합은 “지금 바로 일부 진행 상황을 보여주고 싶지만, 연결이 끊겨도 작업은 계속되게 하고 싶다”는 요구에 맞습니다. 예를 들어 긴 문서 분석을 시작한 뒤 첫 몇 초 내에 “문서 구조 파악 중”, “표 데이터 검토 중” 같은 이벤트를 보여줄 수 있습니다.
다만 주의할 점도 있습니다. OpenAI 문서에 따르면 background response의 첫 토큰 지연은 동기 응답보다 더 길 수 있습니다. 따라서 실시간 체감이 중요한 서비스에서는 무조건 이 조합이 정답이 아닙니다. 실전에서는 보통 두 가지로 나눕니다. 사용자가 결과를 기다리며 보는 UI면 스트리밍+백그라운드, 알림 중심 비동기 워크플로면 순수 백그라운드가 더 깔끔합니다.
background mode는 응답 데이터를 약 10분 정도 저장해 폴링을 가능하게 하므로 ZDR(Zero Data Retention) 보장과는 맞지 않는다고 문서에 명시돼 있습니다. 이 부분은 엔터프라이즈 팀에게 중요합니다. 보안팀이 ZDR을 전제로 설계를 끝냈다면, background mode는 별도 예외 검토가 필요합니다.
또한 긴 작업일수록 결과보다 중간 로그가 민감할 수 있습니다. 리서치 질의, 코드 경로, 내부 문서 이름, 부분 생성 텍스트가 상태 메시지에 섞이기 쉽기 때문입니다. 따라서 사용자에게 노출하는 진행 메시지와 내부 로그를 분리하는 것이 안전합니다.
가장 무난한 UX는 요청 직후 “작업을 시작했습니다”라는 즉시 응답을 주고, job id 또는 결과 페이지 링크를 함께 반환하는 것입니다. 이후 사용자는 같은 화면에서 진행률을 확인하거나, 완료 시 알림을 받습니다. 이 패턴은 사용자가 네트워크 문제와 작업 실패를 구분하기 쉽게 해 줍니다.
개발팀 관점에서도 이 방식이 좋습니다. 프론트, 백엔드, 모델 호출을 느슨하게 결합할 수 있고, 실패 재처리와 취소 처리도 별도 워커에서 다룰 수 있습니다. 장기적으로는 background mode가 단일 API 기능이 아니라 잡 큐 설계의 일부라고 보는 편이 정확합니다.
