8월 26일 전에 점검하세요: Assistants API 종료, 대화 상태는 어디에 남겨야 할까

읽는 시간 9분 · API 전환 체크리스트

먼저 답하면: Assistants API에서 Responses API로 옮길 때 가장 먼저 정할 것은 호출 문법이 아니라 프롬프트 설정·대화·도구 실행 기록을 누가, 어디에, 언제까지 보관할지입니다. 새 대화부터 전환하고, 과거 Thread는 실제 업무상 필요한 경우에만 선별적으로 옮기는 편이 안전합니다.

Assistants API의 Assistant·Thread·Run에 익숙한 팀이라면 2026년 8월 26일 이전에 한 가지 질문에 답해야 합니다. 기존 대화와 도구 실행 이력을 Responses API에서 어떤 방식으로 이어 가고, 우리 서비스가 직접 책임질 기록은 무엇인가요? 이 글은 그 답을 보존, 비용, 복구, 권한이라는 운영 기준으로 정리합니다.

핵심 요약

Assistants API 종료일은 2026년 8월 26일입니다. 공식 전환 안내는 Assistant→Prompt, Thread→Conversation, Run→Response, Run step→Item의 대응을 제시합니다.
기존 Thread를 자동으로 Conversation으로 옮기는 도구는 제공되지 않습니다. 신규 세션을 먼저 전환하고 필요한 기록만 되돌려 채우는 순서가 현실적입니다.
상태 전달은 previous_response_id, 이전 Item 수동 재생, Conversations API 중에서 고릅니다. 이전 응답을 연결해도 이전 입력 토큰 비용이 사라지는 것은 아닙니다.
기본 저장과 별개로, 서비스의 삭제·접근·감사 요구를 만족할 시스템 오브 레코드는 팀이 직접 정해야 합니다.
도구 호출, 스트리밍, 저장 비활성화 경로까지 포함한 회귀 검증 없이는 “응답이 나온다”만으로 전환을 끝내면 안 됩니다.

Assistants API 구조에서 Responses API 구조로 상태 책임이 분리되는 흐름 — 한 덩어리로 보이던 상태를 각각의 책임으로 나누는 전환입니다.

8월 26일에 꺼지는 것은 엔드포인트만이 아닙니다

OpenAI의 Assistants migration guide는 Assistants API 종료일을 2026년 8월 26일로 안내합니다. 새 구조에서는 Prompt, Conversation, Response, Item이 각기 다른 역할을 맡습니다. 따라서 단순히 기존 호출을 새 요청으로 바꾸면, 이전에는 Thread나 Run에 기대고 있던 설정과 이력을 누가 책임지는지 비어 버릴 수 있습니다.

예를 들어 고객 문의 자동화에서 도구가 주문 정보를 조회했다면, 사용자에게 보인 답변만 남길지, 호출 인자와 도구 결과도 남길지, 누가 열람할 수 있는지까지 정해야 합니다. 이 결정은 비용과 감사 가능성, 장애 후 복구 품질에 함께 영향을 줍니다.

먼저 찾을 것: Assistant·Thread·Run 의존성 인벤토리

코드를 바꾸기 전에 현재 서비스가 어디에 기대고 있는지 목록으로 고정하세요. 특히 숨은 의존성은 도구 결과를 다음 Run에서 다시 쓰는 흐름, 파일·첨부 참조, 스트리밍 소비 코드에서 자주 발견됩니다.

설정: Assistant에 있던 지시문, 모델 선택, 도구 정의, 응답 형식을 분리해 기록합니다.
대화: Thread ID를 사용자·업무 티켓·세션 중 무엇과 연결했는지 확인합니다.
실행: Run, run step, 함수 호출 ID, 도구 출력이 재시도나 후속 응답에서 필요한지 표시합니다.
기록: 운영 로그와 사용자 대화, 감사 목적 기록을 한 저장 규칙으로 뭉치지 않습니다.

실패 조건: Thread ID만 데이터베이스에 남기고 실제로 재생해야 할 도구 출력이나 반환 Item을 남기지 않으면, 저장을 비활성화한 경로에서 이전 맥락을 완전하게 되살리지 못할 수 있습니다.

에이전트 상태별 보존 책임을 나눈 개념 — 대화, 도구 실행, 추론 관련 항목, 감사 기록은 같은 보관함을 쓸 이유가 없습니다.

상태 소유권과 보존 기간을 나누는 표

아래 표는 특정 제품의 필수 설정이 아니라, 전환 전에 팀이 합의할 원본 운영 문서의 뼈대입니다. “권장 시스템”은 서비스가 통제할 수 있는 저장소를 뜻하며, 실제 보존 기간은 조직의 정책과 사용자 약속에 맞춰 정해야 합니다.

데이터 유형	권장 시스템 오브 레코드	보존 기준	접근자	삭제·재생 경로
프롬프트 설정	버전 관리 저장소 또는 설정 저장소	배포 버전과 함께 관리	승인된 개발·운영자	버전 롤백, 변경 이력 조회
사용자 대화	업무용 대화 저장소 또는 Conversation	서비스 약관·정책 기준	사용자 권한을 가진 서비스	요청 시 삭제, 필요한 범위 재연결
도구 호출·출력	업무 이벤트 저장소	재시도·분쟁 처리 기준	최소 권한 운영자	call_id 기준 연결·재실행 여부 판단
reasoning item	필요 시 암호화된 상태 저장소	맥락 재생 필요 기간	자동 처리 경로 우선	반환된 output Item 전체 재생
감사 로그	변조 방지 로그 저장소	조직 감사 기준	감사 권한 보유자	사건 단위 조회, 별도 삭제 절차

OpenAI의 Conversation state 안내에 따르면 Response 객체는 기본적으로 30일 저장되며 store:false로 비활성화할 수 있습니다. 반면 Conversation 객체와 Item은 30일 TTL의 대상이 아닙니다. 이 차이는 “어디에 남길지”를 결정할 때만 유용한 정보입니다. Conversation을 고른다고 자체 보존·삭제·접근 통제가 자동으로 끝나는 것은 아닙니다.

세 가지 상태 전달 방식, 어느 흐름에 무엇을 쓸까요

Responses API 전환 안내는 이전 응답 연결, 이전 Item 재생, Conversations API라는 세 가지 상태 전달 방식을 설명합니다. 아래처럼 업무 흐름을 기준으로 선택하면 혼선을 줄일 수 있습니다.

방식	적합한 흐름	보존·비용 영향	복구 시 주의점
`previous_response_id`	짧고 연속적인 단일 세션	연결은 간단하지만 이전 입력 토큰은 과금될 수 있음	연결 ID와 세션 종료 기준을 별도로 관리
이전 Item 수동 재생	자체 저장소 중심, 세밀한 맥락 선택	필요한 항목만 재구성 가능, 저장 품질이 중요	stateless reasoning에서는 반환된 output Item 전체가 필요
Conversations API	여러 응답이 공유하는 지속 대화	대화 단위 관리가 쉬워짐	자체 권한·삭제·감사 정책은 별도 설계

Responses API의 세 가지 상태 전달 방식 비교 — 연결 방식보다 중요한 것은 각 경로의 보존·복구 책임입니다.

Thread에서 Conversation으로: 신규 세션 우선, 필요한 기록만 되돌려 채우기

공식 이관 안내는 Thread에서 Conversation으로의 자동 이관 도구를 제공하지 않으며, 신규 대화부터 전환하고 기존 Thread는 필요할 때 backfill하는 방향을 제안합니다. 따라서 전량 복사 작업을 기본값으로 두기보다 아래 순서로 위험을 줄이세요.

새로 시작되는 세션은 Responses 경로로 보냅니다.
열린 고객 건, 법적 보존 대상, 장기 업무 맥락처럼 실제 필요 기준을 정합니다.
기존 Thread에서 다시 써야 할 메시지·도구 결과만 추출하고, 원본 참조와 이관 시점을 기록합니다.
새 Conversation 또는 자체 저장소에서 재생한 뒤, 답변 품질과 도구 호출이 같은지 확인합니다.
실패하면 기존 경로로 되돌릴 조건과 담당자를 배포 문서에 적습니다.

구체 예시: 주문 변경을 처리하는 봇이 최근 7일의 대화와 마지막 주문 조회 결과만 있으면 업무를 재개할 수 있다면, 모든 과거 Thread를 복사하지 말고 그 범위만 검증된 형식으로 재생합니다. 반대로 재생 데이터에 도구 출력의 일부가 빠지면 같은 질문에서도 다른 주문 상태를 안내할 수 있으므로, 도구 결과의 재사용 여부를 먼저 판정해야 합니다.

배포 전에 통과시킬 5경로 회귀·롤백 시트

전환 검증은 모델 답변이 한 번 정상이라는 확인으로 충분하지 않습니다. 아래 다섯 경로는 기능·비용·보존 책임을 함께 확인하는 최소 단위입니다.

경로	확인할 결과	실패 신호	롤백 판단
단일 응답	프롬프트·형식·오류 처리 일치	응답 형식 또는 지시문 누락	신규 요청 차단 후 설정 복원
다회 대화	선택한 상태 전달 방식으로 맥락 유지	이전 정보 누락·예상 밖 비용	세션 경로를 기존 방식으로 전환
함수 호출	call_id와 도구 출력의 연결	중복 실행·출력 불일치	실행 권한 중지, 이벤트 기록 조사
스트리밍	부분 이벤트 소비와 종료 처리	중간 연결 해제 후 이중 처리	재시도 정책과 멱등성 키 확인
`store:false` 경로	필요한 output Item 전체 재생	reasoning·도구 맥락 일부 누락	해당 경로 중지 후 저장 계약 보완

특히 함수 호출에서는 호출 식별자와 결과를 정확히 연결해야 합니다. 스트리밍에서는 소비 코드와 종료·재시도 처리를 함께 바꿔야 합니다. 이 두 부분은 공식 전환 안내에서도 함께 확인할 항목으로 다뤄집니다.

전환 결정을 위한 마지막 체크리스트

상태 유형마다 소유자, 접근자, 삭제 경로를 문서화했나요?
각 세션 경로에서 필요한 맥락과 예상 비용을 측정했나요?
신규 세션 우선 전환과 기존 기록 선별 이관 기준을 정했나요?
도구 호출·스트리밍·저장 비활성화 경로의 실패 시나리오를 검증했나요?
되돌릴 기준, 담당자, 관측할 로그를 배포 전에 합의했나요?

전환의 목표는 새 API를 호출하는 데 있지 않습니다. 장애가 났을 때 어떤 대화와 실행 기록을 믿고 복구할지, 누가 그 기록을 열람하고 지울 수 있는지까지 명확히 만드는 데 있습니다.

자주 묻는 질문

Assistants API는 언제 종료되나요?

OpenAI 공식 이관 안내 기준으로 2026년 8월 26일입니다. 실제 전환 일정은 현재 서비스의 의존성 목록과 회귀 검증 결과를 기준으로 역산해 잡는 편이 좋습니다.

기존 Thread를 모두 Conversation으로 옮겨야 하나요?

아닙니다. 공식 문서는 자동 이관 도구를 제공하지 않으며 신규 대화 우선 전환과 필요한 Thread의 backfill을 안내합니다. 업무 재개에 필요한 기록부터 선별하세요.

`previous_response_id`를 쓰면 이전 맥락 비용은 없어지나요?

아닙니다. 공식 전환 안내는 이전 응답을 연결해도 이전 입력 토큰이 과금될 수 있다고 설명합니다. 긴 세션은 실제 사용량을 측정해 판단하세요.

`store:false`만 설정하면 상태 관리가 끝나나요?

아닙니다. stateless reasoning 요청에서 맥락을 이어 가려면 반환된 output Item 전체를 보존하고 재생해야 합니다. 필요한 항목의 정의와 보호 방법을 함께 정해야 합니다.

Conversations API를 쓰면 보존과 삭제 요구도 자동으로 해결되나요?

아닙니다. Conversation과 Item의 특성을 이해하는 것은 시작점일 뿐입니다. 서비스가 약속한 접근 통제와 삭제 절차는 별도의 운영 책임으로 남습니다.

참고 자료

OpenAI Assistants migration guide — 종료일, 객체 대응 관계, 신규 대화 우선 전환과 backfill 원칙을 확인했습니다.
OpenAI Migrate to the Responses API — 상태 전달 방식, 이전 입력 토큰 비용, 함수 호출과 스트리밍 전환 항목을 확인했습니다.
OpenAI Conversation state — Response 기본 저장, store:false, Conversation·Item의 상태 특성을 확인했습니다.

영상으로도 FLOWIT을 이어서 보세요

AI 자동화, Claude Code, n8n, 데이터 분석 흐름을 블로그와 영상으로 함께 정리하고 있습니다.

YouTube 채널 보기