OpenAI, Responses API에 computer environment 추가… shell·container·compaction으로 agent 실행 고도화

OpenAI의 3월 11일 engineering 글은 Responses API를 단순한 model interface에서 agent execution layer로 확장하는 방향을 보여준다. 핵심은 shell tool과 hosted container를 결합해, 모델이 다음 행동을 제안하고 실행 결과를 확인한 뒤 다시 후속 행동을 선택하는 loop를 API 차원에서 지원하는 것이다. 이 구조는 개발자가 별도 orchestration harness를 직접 만들지 않아도 장기 실행형 workflow를 구성할 수 있게 하는 데 초점을 맞춘다.

source 글이 다루는 문제는 agent를 실제 서비스에 넣을 때 생기는 운영 이슈다. intermediate file을 어디에 둘지, 큰 표를 prompt에 직접 붙이지 않고 어떻게 다룰지, network access를 열면서도 security headache를 피할 수 있을지, timeout과 retry를 어떻게 처리할지 같은 문제를 Responses API와 container runtime이 대신 맡는 구조다. OpenAI에 따르면 모델이 제안한 명령은 filesystem, optional SQLite storage, restricted network access를 갖춘 isolated workspace에서 실행된다. 또한 GPT-5.2 이후 모델은 이런 shell command 제안을 하도록 학습돼 있다.

실행 방식도 구체적이다. Responses API는 shell output을 near real time으로 다시 모델에 전달해 다음 결정을 돕고, 여러 shell session을 병렬로 실행해 검색·검증·데이터 조회를 동시에 처리할 수 있다. 길어진 tool log가 context를 잠식하지 않도록 output cap도 적용한다. 여기에 native compaction까지 더해 long-running task가 context limit에 닿아도 핵심 상태만 token-efficient하게 유지하며 계속 실행할 수 있도록 설계했다.

보안과 운영 포인트

• hosted container는 sidecar egress proxy를 통해 outbound request를 allowlist와 access control 아래에서 처리한다.
• credential은 approved destination 기준으로 egress 시점에 domain-scoped secret injection을 적용해 raw secret이 model-visible context에 남지 않도록 했다.
• OpenAI는 큰 입력을 prompt에 밀어 넣기보다 container file system과 database를 먼저 정리한 뒤 필요한 데이터만 읽게 하는 방식을 권장했다.

이 글의 의미는 OpenAI가 agent 시대의 경쟁력을 모델 성능만으로 보지 않는다는 점에 있다. Responses API는 이제 단순한 text interface가 아니라, state 유지, tool 실행, security control, context management를 묶은 managed runtime 방향으로 진화하고 있다. agent product를 실제 운영 환경에 올리려는 개발팀에게는 상당히 중요한 설계 변화다.