백그라운드 에이전트는 왜 긴 HTTP 요청이 아니라 작업 큐일까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 오래 생각하는 에이전트 기능을 만들 때 왜 timeout을 늘리는 대신 작업 큐, 재개 지점, 취소 계약을 먼저 설계해야 할까?
• 핵심 출처:
  • Background mode | OpenAI API - 게시일 미표기, 2026-06-25 확인
  • Responses | OpenAI API Reference - 게시일 미표기, 2026-06-25 확인
  • Agent Background Responses - 2026-03-13, 2026-06-25 확인
  • Use the Azure OpenAI Responses API - 2026-06-11, 2026-06-25 확인

1. 왜 지금 봐야 하나

AI 기능이 “질문 하나, 답 하나”에서 “조사하고, 파일을 읽고, 도구를 호출하고, 결과를 검증하는 작업”으로 바뀌면 가장 먼저 터지는 것은 모델 성능이 아니라 요청 수명이다. 사용자가 버튼을 눌렀는데 모델이 2분 동안 생각한다. 브라우저 탭이 닫힌다. 모바일 네트워크가 바뀐다. 서버리스 함수 제한 시간이 온다. 사용자는 취소를 눌렀는데 백엔드에서는 아직 토큰이 생성되고 비용이 나간다.

이때 흔한 임시 처방은 timeout을 늘리는 것이다. 하지만 오래 실행되는 에이전트는 긴 HTTP 요청으로 다루기 어렵다. 연결이 끊겨도 작업은 계속될 수 있어야 하고, 사용자는 나중에 상태를 확인할 수 있어야 하며, 이미 나온 스트림을 어디까지 봤는지 재개할 수 있어야 한다. 실패했을 때 “처음부터 다시 실행”이 아니라 “어느 단계에서 멈췄는지”가 남아야 한다.

OpenAI의 Background mode 문서는 Responses API에서 background: true로 장기 작업을 비동기로 시작하고, queued 또는 in_progress 상태 동안 GET으로 polling하며, 필요하면 cancel endpoint로 취소할 수 있다고 설명한다. 스트리밍까지 함께 쓰려면 처음부터 background: true, stream: true로 만들고 각 이벤트의 sequence_number를 커서처럼 저장해야 한다. Microsoft Agent Framework의 Background Responses도 같은 문제를 continuation token으로 푼다. 초기 호출이 바로 끝나지 않으면 continuation token을 돌려주고, 이후 호출에서 그 토큰으로 polling 또는 stream resume을 한다.

오늘의 핵심은 이것이다.

오래 실행되는 에이전트는 “느린 응답”이 아니라 상태를 가진 비동기 작업이다. 그래서 API 설계도 HTTP timeout이 아니라 job id, terminal state, resume cursor, cancel, retention 정책으로 시작해야 한다.

2. 핵심 개념

백그라운드 에이전트를 작업 큐로 보면 네 가지 객체가 보인다.

첫째, 작업 식별자다. OpenAI Background mode에서는 응답 ID가 polling, stream 재개, cancel의 기준이 된다. Microsoft Agent Framework에서는 continuation token이 같은 역할을 한다. 사용자의 화면은 “응답 텍스트”만 기다리는 것이 아니라 “작업 ID를 가진 실행”을 추적해야 한다.

둘째, 상태 전이다. 최소 상태는 queued, in_progress, completed, failed, cancelled, requires_input 정도로 나눌 수 있다. 문서마다 이름은 다르지만 원리는 같다. queued와 in_progress는 계속 확인해야 하는 비종료 상태이고, 그 밖의 상태는 더 이상 같은 방식으로 기다리면 안 되는 terminal state다. 이 구분이 없으면 프론트엔드는 무한 로딩을 만들고, 백엔드는 같은 작업을 중복 실행한다.

셋째, 재개 지점이다. non-streaming이면 일정 간격으로 작업 상태를 조회하면 된다. streaming이면 사용자가 마지막으로 받은 이벤트 위치를 알아야 한다. OpenAI 문서는 background streaming에서 sequence_number를 cursor로 저장하고, 재연결 시 starting_after를 넘겨 이어 받을 수 있다고 설명한다. 이것은 채팅 메시지 저장과 다르다. “최종 답변”이 아니라 “이벤트 로그의 어디까지 소비했는가”를 저장하는 문제다.

넷째, 보존과 삭제 정책이다. OpenAI 문서는 background mode가 polling을 위해 응답 데이터를 약 10분 저장하므로 Zero Data Retention과 호환되지 않는다고 명시한다. Azure OpenAI Responses 문서는 기본적으로 response data가 30일 보존된다고 설명한다. 즉 background 기능을 켜는 순간 “편의 기능”이 아니라 데이터 보존, 개인정보, 감사 로그, 삭제 API까지 포함한 운영 결정이 된다.

3. 최신 이슈와 연결

최근 모델 플랫폼들은 오래 걸리는 reasoning 작업을 정상적인 제품 패턴으로 다루기 시작했다. OpenAI Background mode는 Codex나 Deep Research처럼 몇 분 걸리는 작업을 예로 들며, 클라이언트 timeout이나 연결 문제를 애플리케이션이 직접 떠안지 않게 하는 흐름을 제시한다. 같은 OpenAI API Reference에는 Responses 생성 파라미터로 background가 포함되어 있고, response retrieve/delete 같은 리소스 조작도 함께 제공된다.

Microsoft Agent Framework 문서는 이 패턴을 agent SDK 레벨로 올린다. C#과 Python 에이전트 실행에서 background response를 허용하면, 작업이 바로 끝날 수도 있고 continuation token을 반환할 수도 있다. streaming에서는 각 update에 continuation token이 포함되어 중단된 스트림을 이어갈 수 있다. Azure OpenAI Responses API 문서도 background tasks, context compaction, function calling, remote MCP servers, encrypted reasoning items를 하나의 Responses 흐름 안에서 다룬다.

개발자에게 중요한 점은 “어떤 벤더 기능이 더 편한가”가 아니다. 공통 패턴이 보인다는 점이다.

• 장기 작업은 동기 응답보다 비동기 상태 조회가 필요하다.
• 스트리밍은 UX 기능이면서 동시에 resume protocol이다.
• 취소는 버튼 UI가 아니라 서버 측 비용과 도구 실행을 멈추는 계약이다.
• background 실행은 데이터 보존과 보안 정책을 바꾼다.

4. 개발자 관점 해석

에이전트 기능을 직접 붙일 때는 다음 질문부터 해야 한다.

1. 이 작업은 동기 API인가, 비동기 job인가?

사용자가 3~10초 안에 결과를 기대하는 자동완성, 짧은 분류, 간단한 변환은 동기 API가 맞다. 반면 리포트 생성, 코드베이스 조사, 다단계 RAG, 여러 도구 호출, 긴 reasoning이 필요한 작업은 job으로 보는 편이 안전하다. 작업 시간이 길수록 HTTP 연결은 신뢰할 수 있는 상태 저장소가 아니다.

2. 사용자가 무엇을 볼 수 있어야 하나?

백그라운드 작업도 “기다리세요”만 보여주면 제품 품질이 낮아진다. 최소한 현재 상태, 마지막 업데이트 시각, 취소 가능 여부, 부분 결과, 실패 이유를 보여줘야 한다. 스트리밍을 쓴다면 이벤트별 sequence_number 또는 continuation token을 저장해 재연결 후 중복 출력 없이 이어 붙여야 한다.

3. 취소가 어디까지 전파되는가?

UI에서 취소 버튼을 누르는 것과 모델 실행을 취소하는 것은 다르다. 더 나아가 모델이 이미 외부 도구를 호출했다면 그 도구 실행도 멈출 수 있는지, 아니면 보상 작업이 필요한지 결정해야 한다. “취소됨” 상태는 단순히 화면을 닫았다는 뜻이 아니라 비용, 파일 변경, 외부 API 호출의 종료 의미를 가져야 한다.

4. 데이터를 얼마나 보관하는가?

background polling을 위해 서버가 응답 데이터를 저장하면 보안 요구사항이 달라진다. OpenAI Background mode의 약 10분 보존과 ZDR 비호환 주의, Azure Responses의 기본 30일 보존 설명은 모두 같은 교훈을 준다. 민감 데이터가 들어가는 에이전트라면 background mode를 켜기 전에 보존 기간, 삭제 API, 로그 마스킹, 조직의 데이터 처리 정책을 확인해야 한다.

5. 내 프로젝트에 적용할 체크포인트

• 작업 테이블을 먼저 설계한다. id, user_id, status, provider_response_id, resume_cursor, started_at, updated_at, completed_at, cancelled_at, error_code를 둔다.
• 상태 전이를 명시한다. queued -> in_progress -> completed만 가정하지 말고 failed, cancelled, requires_input, expired를 포함한다.
• polling 간격을 고정하지 않는다. 처음에는 짧게, 오래 걸릴수록 길게 backoff한다. 사용자가 화면을 떠나면 서버 비용이 아니라 알림/재조회 흐름으로 전환한다.
• stream cursor를 저장한다. 토큰 텍스트만 append하지 말고 이벤트 번호 또는 continuation token을 저장해 중복 재생과 누락을 막는다.
• 취소를 idempotent하게 만든다. 같은 작업에 cancel을 두 번 눌러도 안전해야 한다. OpenAI 문서도 background response cancel을 반복 호출하면 final Response 객체를 반환하는 idempotent 동작으로 설명한다.
• retention을 제품 요구사항으로 적는다. “응답을 며칠 저장할지”, “사용자가 삭제하면 provider response도 삭제할지”, “ZDR 또는 개인정보 요구와 충돌하는지”를 배포 전 체크한다.

6. 오늘 10분 액션

지금 만들고 있는 AI 기능 하나를 고르고 아래 표를 채워보자.

질문	내 답
이 작업의 P95 예상 시간은 몇 초인가?
브라우저가 닫혀도 계속 실행되어야 하나?
사용자가 중간에 봐야 할 상태는 무엇인가?
취소하면 모델, 도구, DB 변경 중 무엇까지 멈춰야 하나?
스트리밍 재개를 위해 저장할 cursor/token은 무엇인가?
provider 또는 내 서버가 결과를 얼마나 보관하는가?

이 표에서 두 칸 이상 답이 비어 있으면, 아직 “에이전트 API”가 아니라 “긴 요청”만 만든 상태일 가능성이 높다.

7. 더 볼 자료

• Background mode | OpenAI API
• Responses | OpenAI API Reference
• Agent Background Responses
• Use the Azure OpenAI Responses API

중복 회피 메모

최근 ai_dev 글은 장기 실행 에이전트의 context/memory/checkpoint 분리, 실시간 Live API의 상태 머신, prefix cache-aware LLM 라우팅, MCP Elicitation, guardrail checkpoint를 다뤘다. 이번 글은 컨텍스트 관리나 실시간 음성 세션이 아니라, 몇 분 걸리는 reasoning/agent 작업을 제품 API로 운영할 때 필요한 background job, polling, stream resume, cancel, data retention 계약에 집중한다.