OpenAI Agents API 컴퓨터 사용: DevDay 이후 에이전트 개발이 바뀌는 지점

OpenAI DevDay 2026에서 개발자들이 가장 먼저 확인해야 할 변화는 모델 이름보다 에이전트 실행 환경입니다. 이번 발표에는 GPT-6.1 Sol, Codex 클라우드 환경, Decisions API, ChatGPT 플러그인 확장처럼 눈에 띄는 항목이 많았지만, 실무 영향만 놓고 보면 Agents API의 computer use 지원과 Codex의 원격 실행이 더 큽니다. 이제 에이전트는 텍스트 답변을 만드는 수준을 넘어, 그래픽 인터페이스를 조작하고, 원격 개발 환경에서 작업을 이어가고, 여러 도구를 조합해 실제 변경을 만들 수 있습니다.

핵심은 “더 똑똑한 모델이 나왔다”가 아닙니다. 개발팀 입장에서는 에이전트가 어디까지 실행해도 되는지, 어떤 권한을 줘야 하는지, 실패했을 때 어떤 로그로 되돌릴 수 있는지가 더 중요해졌습니다. OpenAI 공식 DevDay 요약은 20개 이상의 주요 발표를 언급했고, InfoQ와 TechCrunch 보도도 Codex 클라우드 환경, Agents API computer use, Decisions API를 개발자용 핵심 업데이트로 정리했습니다.

무엇이 새로워졌나

이번 업데이트에서 Agents API는 computer use를 지원합니다. 애플리케이션이 에이전트에게 브라우저나 데스크톱형 화면을 조작하게 만들 수 있다는 뜻입니다. 과거에는 함수 호출이나 API 호출처럼 구조화된 도구가 중심이었다면, 이제는 UI 자체가 도구가 됩니다. 사내 관리자 페이지, 오래된 백오피스, API가 없는 SaaS 화면처럼 자동화하기 애매했던 영역이 대상이 됩니다.

Codex 쪽 변화도 연결해서 봐야 합니다. OpenAI는 Codex를 로컬 컴퓨터뿐 아니라 클라우드 환경에서도 실행할 수 있게 했고, 재사용 가능한 개발 환경을 제공한다고 설명했습니다. 팀이 승인한 설정과 권한을 공유 환경으로 만들면, 매번 새 샌드박스를 구성하지 않아도 작업을 빠르게 시작할 수 있습니다. TechCrunch는 이를 “각 작업을 고립된 원격 샌드박스로 다루던 방식에서 더 지속적이고 설정 가능한 환경으로 이동하는 변화”라고 정리했습니다.

또 하나는 코드 리뷰와 보안 스캔입니다. Codex는 GitHub PR이나 GitLab MR의 diff를 보고 문제를 설명하거나 수정안을 준비할 수 있고, Codex Security Cloud는 저장소를 스캔해 취약점을 찾고 중복을 제거한 뒤 수정까지 준비합니다. 여기서 중요한 점은 AI가 개발자의 IDE 옆에만 붙어 있는 것이 아니라, 리뷰와 보안 파이프라인 안으로 들어온다는 것입니다.

왜 개발자에게 중요한가

첫 번째 변화는 자동화 대상의 폭입니다. 기존 LLM 자동화는 “입력 텍스트를 보고 JSON을 반환한다”에 가까웠습니다. 이 방식은 API가 잘 정의된 시스템에서는 충분하지만, 실제 회사 업무는 그렇지 않은 경우가 많습니다. 결제 관리자 화면, 광고 콘솔, CRM, 오래된 내부 도구처럼 API가 제한적이거나 권한 체계가 복잡한 화면이 많습니다. computer use가 실용화되면 이런 영역도 에이전트 워크플로우에 들어옵니다.

두 번째 변화는 작업 지속성입니다. 클라우드 Codex 환경은 개발자가 노트북을 닫아도 리뷰, 수정, 스캔 작업을 이어갈 수 있게 만듭니다. 물론 이것이 곧 “AI가 알아서 개발한다”는 뜻은 아닙니다. 오히려 반대입니다. 작업이 지속되기 때문에 승인 지점, 브랜치 전략, 로그 보관, 롤백 기준을 더 명확히 해야 합니다.

세 번째 변화는 비용 구조입니다. 모델 호출을 매번 가장 큰 모델에 맡기면 속도와 비용이 모두 나빠집니다. OpenAI가 Decisions API처럼 미리 정해진 답변 중 선택하는 API를 함께 발표한 것도 이 맥락입니다. 모든 판단을 범용 LLM에게 맡기기보다, 분류와 라우팅은 작은 의사결정 모델로 처리하고, 복잡한 코드 변경이나 추론만 큰 모델로 넘기는 구조가 현실적입니다.

바로 도입하면 위험한 부분

가장 큰 위험은 권한 과다 부여입니다. 에이전트가 화면을 조작할 수 있다는 말은 실수로 삭제 버튼을 누를 수도 있다는 뜻입니다. 특히 관리자 콘솔, 결제 화면, 배포 도구는 human approval 없이 열어두면 안 됩니다. 개발자는 “에이전트가 무엇을 할 수 있는가”보다 “무엇을 절대 못 하게 할 것인가”를 먼저 정해야 합니다.

두 번째는 관측성 부족입니다. computer use는 API 호출보다 재현이 어렵습니다. API 요청은 파라미터와 응답을 남기면 되지만, 화면 조작은 클릭 좌표, DOM 상태, 스크린샷, 세션 권한, 중간 판단을 같이 남겨야 합니다. 로그가 없으면 성공했을 때도 신뢰하기 어렵고, 실패했을 때 원인을 찾기 어렵습니다.

세 번째는 테스트 환경 부재입니다. 에이전트가 실제 운영 관리자 화면에서 처음 실행되면 위험합니다. 최소한 staging 계정, 읽기 전용 권한, 더미 데이터, 승인 모드부터 시작해야 합니다. 자동화가 유용하다고 바로 운영 권한을 주는 순간, 작은 프롬프트 오류가 큰 장애로 이어질 수 있습니다.

권장 아키텍처

실무에서는 4단계로 나누는 것이 안전합니다. 1단계는 읽기 전용 에이전트입니다. 화면을 탐색하고 상태를 요약하지만 변경은 하지 않습니다. 2단계는 제안형 에이전트입니다. 변경 계획과 예상 diff를 만들지만 적용은 사람이 합니다. 3단계는 제한 실행입니다. 특정 화면, 특정 버튼, 특정 데이터 범위에서만 실행하고 매 단계 승인합니다. 4단계가 완전 자동화입니다. 이 단계는 실패 비용이 낮고 롤백이 쉬운 업무에만 적용해야 합니다.

기술적으로는 세 가지 레이어가 필요합니다. 첫째, 정책 레이어입니다. 허용 URL, 금지 액션, 승인 필요 액션을 코드로 관리합니다. 둘째, 실행 레이어입니다. 브라우저 세션, 도구 호출, 파일 변경을 격리된 환경에서 실행합니다. 셋째, 감사 레이어입니다. 스크린샷, 입력값, 모델 판단, 최종 결과를 작업 ID 단위로 묶어 저장합니다.

이 구조를 만들지 않고 모델만 붙이면 데모는 빨리 나오지만 운영은 늦어집니다. DevDay 발표가 보여준 방향은 명확합니다. 에이전트는 점점 더 많은 일을 할 수 있게 됩니다. 따라서 경쟁력은 모델 접근 권한이 아니라, 권한 설계와 실행 통제에서 갈립니다.

개발팀 실행 체크리스트

• API가 없는 반복 업무 3개를 고르고, 그중 실패 비용이 가장 낮은 하나만 PoC 대상으로 정합니다.
• 운영 계정이 아니라 staging 계정과 더미 데이터로 computer use 테스트를 시작합니다.
• 에이전트 권한을 읽기 전용, 제안형, 승인형, 자동 실행형으로 나눕니다.
• 클릭, 입력, 스크린샷, 모델 판단, 최종 결과를 작업 ID 기준으로 기록합니다.
• 삭제, 결제, 배포, 권한 변경은 반드시 human approval 액션으로 분리합니다.
• Codex 클라우드 환경을 쓴다면 브랜치, PR, 리뷰어, 롤백 기준을 먼저 문서화합니다.
• 모든 판단을 큰 모델에 맡기지 말고, 단순 분류는 Decisions API나 별도 decision model로 분리합니다.

이번 발표를 “OpenAI가 또 기능을 많이 냈다”로 넘기면 놓치는 게 많습니다. 실무 개발자가 봐야 할 포인트는 하나입니다. AI 에이전트가 실제 시스템을 조작하는 시대가 왔고, 이제 좋은 팀은 프롬프트보다 실행 안전장치를 먼저 설계합니다.