장시간 AI 에이전트를 위한 OpenAI Responses API 업데이트 총정리
최근 OpenAI가 Responses API를 “오래 일하는 AI 에이전트”에 맞춰 업그레이드했습니다. 핵심은 세 가지예요. 대화가 길어져도 안 잊어버리게 만들고(서버 사이드 컴팩션), 에이전트가 쓸 수 있는 안전한 터미널을 제공하고(호스티드 셸 컨테이너), 반복 업무 레시피를 재사용 가능한 꾸러미로 표준화(스킬)한 겁니다.1 이 글에서는 “왜 이게 중요한지”와 “개발자가 무엇을 바꿔야 하는지”를 Responses API 관점에서 정리해볼게요.
Server-side Compaction: ‘기억력’이 아니라 ‘정리정돈’의 문제
장시간 에이전트의 실패 패턴은 단순합니다. 일을 시킬수록 로그(대화/도구 호출/결과)가 쌓이고, 어느 순간 토큰 한도에 걸려 중요한 맥락부터 잘립니다. 그러면 모델은 빈칸을 상상으로 메우고, 그게 우리가 흔히 말하는 환각으로 보이죠.
이번 업데이트의 서버 사이드 컴팩션은 “중요한 것만 남기는 요약 상태”를 서버가 유지해, 세션을 계속 이어갈 수 있게 하는 접근입니다.2 단순 삭제가 아니라, 이전 행동과 중간 결론을 압축해 남겨두는 느낌에 가깝습니다. 실제 사례로 한 에이전트가 500만 토큰과 150번의 도구 호출을 버텼다는 언급도 나왔는데2, 포인트는 숫자보다 “장시간 실행을 전제로 한 상태 관리가 API 레벨로 내려왔다”는 변화입니다. 이제 개발자가 매번 대화 히스토리를 쪼개 들고 뛰지 않아도 됩니다.
Hosted Shell Containers: 에이전트에게 ‘안전한 작업실’을 주는 방법
에이전트가 진짜 일을 하려면 결국 무언가를 실행해야 합니다. 데이터 변환을 하든, 스크립트를 돌리든, 파일을 만들든요. 기존에는 팀이 별도 샌드박스를 구축하고 보안과 운영을 떠안는 경우가 많았습니다.
Responses API의 셸 도구는 선택적으로 OpenAI 호스팅 Debian 12 컨테이너를 붙여줍니다. Python, Node, Java, Go, Ruby 같은 실행 환경이 준비돼 있고, /mnt/data에 작업 결과를 저장해 산출물을 남길 수도 있습니다.2 게다가 컨테이너에서 제한된 인터넷 접근을 통해 라이브러리를 설치하거나 외부 API와 통신하는 흐름도 열렸습니다.1 요약하면 “코드 인터프리터”를 넘어 “에이전트 전용 작업실”을 API로 빌려주는 방향이에요.
이 변화가 특히 큰 팀은 데이터/백오피스 자동화 쪽입니다. 예전엔 작은 PoC도 ETL 파이프라인, 권한, 실행 환경 때문에 일이 커졌는데, 이제는 에이전트가 컨테이너 안에서 처리하고 결과물을 남기는 구조가 쉬워졌습니다.
Agent Skills: 프롬프트를 ‘레시피 카드’로 분리해 재사용하기
많은 팀이 이미 겪었을 겁니다. “이 업무 흐름은 늘 똑같아”라면서도, 실제 구현은 시스템 프롬프트에 길게 붙여 넣고, 버전 관리도 애매하고, 조금만 바뀌면 전체가 흔들리죠.
스킬(Skills)은 그 긴 절차를 “필요할 때만 불러 쓰는 꾸러미”로 만드는 개념입니다.1 지침, 스크립트, 파일을 묶어서 버전 관리하고, 프로덕션에서는 특정 버전을 고정(pin)해서 재현성을 확보하라는 가이드도 나왔습니다.1 흥미로운 지점은 이게 OpenAI만의 섬이 아니라는 점입니다. 업계는 SKILL.md 같은 매니페스트 기반의 공개 표준으로 수렴 중이고, 다른 플랫폼/에이전트에서도 옮겨 다닐 수 있는 “이식 가능한 자산”이 되는 흐름이 보입니다.2
즉, 스킬은 “프롬프트 엔지니어링”을 팀의 운영 자산으로 바꿉니다. 문장 예쁘게 쓰는 기술이 아니라, 작은 CLI 프로그램처럼 쪼개고 테스트하고 배포하는 방식으로요.
시사점: Responses API는 이제 ‘뇌’가 아니라 ‘사무실’까지 판다
Responses API는 Chat Completions 시절의 “요청마다 대화 전체를 업로드”하는 방식에서 벗어나, previous_response_id 같은 체이닝으로 상태를 서버가 이어받는 방향으로 설계가 바뀌었습니다.3 여기에 컴팩션(기억 유지), 호스티드 셸(실행 환경), 스킬(업무 레시피)까지 붙으면서, 장시간 에이전트를 만들 때 가장 귀찮고 위험했던 인프라 조각들이 한 덩어리로 내려왔습니다.
실무 팁도 간단히 정리하면 좋습니다. 첫째, 장시간 작업은 컴팩션을 전제로 “중간 산출물”을 /mnt/data에 남기게 설계하세요. 둘째, 스킬은 작은 단위로 쪼개고 버전을 고정해 운영 리스크를 줄이세요.1 셋째, 셸과 네트워크가 열리는 순간 보안이 일이 됩니다. 어떤 스킬이 어떤 사용자/조직에서 실행 가능한지, 산출물과 로그를 어떻게 감사(audit)할지부터 먼저 정해두는 편이 안전합니다.2
이제 질문은 “에이전트를 만들 수 있나?”가 아니라, “오래 일하게 만들면, 어디까지 권한을 줄 것인가?”로 바뀌고 있습니다. Responses API 업데이트는 그 전환을 꽤 현실로 끌어당긴 사건입니다.
참고
1OpenAI upgrades Responses API with features built specifically for long-running AI agents
2OpenAI upgrades its Responses API to support agent skills and a complete terminal shell
3OpenAI Responses API in an LLM Gateway: What Changed and Why It Matters - DEV Community