Category
OpenAI Codex와 Agents SDK는 코드 생성을 넘어 도구 호출·파일 편집·작업 실행을 자율로 수행하는 코딩 에이전트 계층이다. 한국 개발자에게는 CLI와 IDE에 에이전트를 직접 붙여 반복 작업을 위임하는 실무 진입점이며, MCP·서브에이전트 구성과 권한 설계가 도입 성패를 가른다.
Codex 류 장시간 작업을 프로덕션에 붙일 때 가장 먼저 깨지는 건 HTTP 타임아웃이다. Responses API의 background 실행과 store=true 상태 저장을 묶으면, 작업을 던진 뒤 response_id로 폴링하거나 웹훅으로 완료를 받는 패턴이 표준화된다. 에이전트가 코드 실행·테스트를 수십 턴 돌리는 동안 연결을 잡고 있을 필요가 없어진다. 핵심 함정은 두 가지다. 첫째, background 응답은 중간 reasoning 항목이 잘려 보일 수 있어 재개 시 previous_response_id 체이닝을 정확히 이어야 한다. 둘째, 실패한 실행도 토큰이 과금되므로 max_tool_calls와 타임박스를 SDK 레벨에서 강제하지 않으면 폭주한 에이전트가 비용을 태운다. Vercel류 fire-and-forget 서버리스에선 폴러를 별도 워커로 빼야 한다.
두 에이전트 SDK는 같은 일을 다른 축으로 푼다. Claude Agent SDK는 로컬 파일시스템과 임의 bash를 1급 도구로 보고 에이전트가 작업 디렉터리에서 직접 돌아가는 'host-native' 모델이다. Codex SDK는 실행을 OpenAI 컨테이너로 밀어넣고 Responses API의 상태 저장 대화에 묶는 'service-native' 모델에 가깝다. 결과적으로 Claude 쪽은 권한·sandbox 설정을 개발자가 책임지고 MCP로 도구를 확장하는 자유도가 높고, Codex 쪽은 환경이 표준화돼 재현성이 좋지만 커스텀 런타임 주입이 막혀 있다. 멀티 파일 리팩터의 정확도는 비등하나, long-horizon 작업에서 Claude는 컨텍스트 압축, Codex는 reasoning 토큰 비용이 각각의 약점으로 드러난다.
OpenAI가 Codex를 단순 CLI 도구에서 임베드 가능한 SDK로 끌어올렸다. 핵심은 Responses API의 server-side tool로 들어간 코드 실행 컨테이너다. 모델이 패치를 생성하면 격리된 샌드박스에서 직접 apply·테스트·재시도하고, 실패한 diff를 다음 턴 컨텍스트로 되먹이는 루프가 SDK 레벨에서 돌아간다. 개발자는 exec_tool 하나만 붙이면 된다. 기존 Assistants API 시절 직접 짜던 '생성→로컬 적용→stderr 수집→재프롬프트' 보일러플레이트가 사라진 대신, 실행 환경이 OpenAI 호스팅 컨테이너로 고정돼 의존성·네트워크 정책을 세밀히 못 건드린다. gpt-5.1-codex가 기본 백엔드이며 reasoning effort를 high로 올리면 토큰이 빠르게 불어난다.