[AI Frontier] Codex와 Ona가 보여준 클라우드 작업공간 전환

[AI Frontier]

Codex의 변화는 “코드를 더 잘 짜는 AI”에서 끝나지 않습니다. 긴 작업을 맡기는 순간, 실무자가 봐야 할 것은 작업공간·권한·감사 로그입니다.

Image generated by OpenAI

AI 에이전트가 몇 줄의 코드를 고쳐주는 단계라면, 모델 성능 비교가 먼저일 수 있습니다. 어떤 모델이 더 정확한지, 어느 도구가 더 빠른지, 어떤 서비스가 더 긴 맥락을 처리하는지 따져볼 수 있습니다.

하지만 몇 시간, 며칠짜리 작업을 맡기기 시작하면 질문이 달라집니다. 에이전트가 어디서 일하는지, 무엇에 접근하는지, 누가 승인하는지, 무엇이 기록되는지를 먼저 봐야 합니다.

OpenAI가 Ona 인수 계획을 발표한 것도 이 흐름 안에서 읽을 필요가 있습니다. 겉으로는 기업 인수 뉴스처럼 보이지만, 실제로는 Codex를 로컬 도구 너머의 클라우드 작업공간으로 확장하려는 신호에 가깝습니다. 무엇이 연결됐는지부터 끊어서 보겠습니다.

SUMMARY

이번 신호의 핵심은 Codex가 단순한 코드 생성 도구에서 장시간 작업을 수행하는 AI 에이전트 워크플로로 넓어지고 있다는 점입니다. Ona는 그 에이전트가 일할 클라우드 작업공간, 권한 통제, 실행 환경, 감사 로그를 제공하는 인프라 쪽에 가깝습니다. 기업은 도입 전에 모델 성능보다 작업공간, 접근 권한, 승인 절차, 사람 리뷰 기준을 먼저 정해야 합니다.

먼저 Ona는 어떤 회사일까요?

Ona를 이해하려면, 이 회사를 모델 회사로 보면 어렵습니다. Ona는 AI 모델을 직접 만드는 회사라기보다, AI 에이전트가 실제로 일할 수 있는 클라우드 작업공간을 만드는 회사에 가깝습니다. 코드 저장소, 실행 환경, 도구, 네트워크 접근, 권한, 작업 기록을 한곳에서 다루는 인프라 회사로 보는 편이 더 정확합니다.

Ona는 Gitpod에서 출발했습니다. Gitpod은 원래 브라우저 기반 클라우드 개발 환경으로 알려져 있었습니다. 개발자가 각자 노트북에 개발 환경을 설치하는 대신, 미리 구성된 클라우드 환경에서 바로 코드를 열고 작업할 수 있게 해주는 방식이었습니다.

이후 회사는 Ona로 리브랜딩하며 방향을 넓혔습니다. 단순한 클라우드 개발 환경을 넘어, AI 소프트웨어 엔지니어링 에이전트를 운영하는 플랫폼으로 이동한 것입니다. Ona 공식 사이트도 자사를 “클라우드에서 AI 소프트웨어 엔지니어 팀을 실행하는 플랫폼”으로 설명합니다.

ONA IN CONTEXT

출발점: 로컬 개발 환경을 클라우드로 옮기는 Gitpod 계열의 개발 환경 기술
현재 방향: 개발자가 직접 하던 작업 일부를 AI 에이전트에게 맡기는 백그라운드 작업 플랫폼
핵심 기능: 클라우드 실행 환경, 저장소 접근, 명령 실행, 풀 리퀘스트 생성, 권한 통제, 감사 로그
기업 관점의 의미: 에이전트가 회사 코드와 시스템 안에서 일할 수 있도록 보안 경계와 운영 규칙을 제공

사건 개요: Codex와 Ona, 무엇이 연결됐을까요?

OpenAI는 2026년 6월 11일 Ona 인수 계획을 발표했습니다. 발표의 표현을 보면 방향이 비교적 분명합니다. OpenAI는 Ona의 보안 클라우드 실행 및 오케스트레이션 기술을 Codex 생태계에 더하겠다고 설명했습니다.

Codex는 이미 클라우드 기반 소프트웨어 엔지니어링 에이전트로 소개된 바 있습니다. OpenAI의 2025년 발표에 따르면 Codex는 저장소가 미리 로드된 별도 클라우드 샌드박스에서 작업을 실행하고, 기능 작성, 버그 수정, 코드베이스 질문 답변, 풀 리퀘스트 제안 같은 일을 맡을 수 있습니다.

Ona가 여기에 붙으면 의미가 달라집니다. Codex가 단순히 답변을 생성하는 도구가 아니라, 고객이 통제하는 클라우드 환경 안에서 오래 일하는 에이전트로 확장될 수 있기 때문입니다. OpenAI도 Ona가 에이전트에게 필요한 도구, 시스템, 맥락에 접근할 수 있는 보안 지속형 환경을 제공한다고 설명했습니다.

시점	신호	실무자가 볼 점
2025년 5월	Codex가 클라우드 기반 소프트웨어 엔지니어링 에이전트로 공개됐습니다.	코드 제안 도구에서 작업 위임형 에이전트로 범위가 넓어졌습니다.
2025년 9월	Gitpod이 Ona로 리브랜딩하며 AI 소프트웨어 엔지니어링 에이전트 플랫폼을 지향했습니다.	개발 환경이 사람만을 위한 공간에서 에이전트가 일하는 공간으로 바뀌기 시작했습니다.
2026년 6월	OpenAI가 Ona 인수 계획을 발표했습니다.	Codex의 경쟁축이 모델 성능뿐 아니라 실행 환경과 통제 구조로 이동하고 있습니다.

다만 이 단계에서 구분해야 할 점도 있습니다. Ona 인수는 발표된 계획이지, 본문 작성 시점 기준으로 완료됐다고 단정할 사안은 아닙니다. OpenAI도 인수 완료 전까지 양사가 별도 독립 회사로 남는다고 밝혔습니다.

왜 ‘클라우드 작업공간’이 중요해졌을까요?

예전의 코딩 AI는 대체로 옆자리 보조자에 가까웠습니다. 사용자가 편집기나 터미널 안에서 질문하면, AI가 코드를 제안하고 사람이 적용했습니다. 이 방식에서는 작업의 경계가 비교적 분명합니다.

하지만 긴 작업은 다릅니다. 에이전트가 저장소를 읽고, 테스트를 돌리고, 의존성을 확인하고, 실패한 부분을 다시 고치고, 변경 사항을 정리해야 합니다. 사용자가 계속 화면 앞에 앉아 있지 않아도 작업이 이어질 수 있어야 합니다.

그래서 클라우드 작업공간이 중요해집니다. 이 공간은 단순히 AI가 머무는 서버가 아닙니다. 코드, 도구, 실행 환경, 작업 기록, 승인 흐름이 함께 놓이는 운영 장소입니다. 말하자면 AI 에이전트의 사무실에 가깝습니다.

NOTE

여기서 중요한 표현은 “계속 실행된다”가 아니라 “통제된 환경에서 계속 실행된다”입니다. 장시간 작업을 맡길수록 실행 공간의 경계가 제품의 신뢰성과 직결됩니다.

관전 포인트 1: 모델 성능보다 권한선이 먼저입니다

AI 에이전트를 볼 때 가장 먼저 떠오르는 질문은 보통 성능입니다. 어느 모델이 더 긴 코드를 잘 이해하는지, 어느 쪽이 더 정확히 수정하는지, 어떤 도구가 더 빠른지 비교하게 됩니다. 물론 이 질문은 필요합니다.

그런데 기업 환경에서는 성능만으로 부족합니다. 에이전트가 파일을 읽고, 명령을 실행하고, 외부 도구에 접근하고, 변경 사항을 만들 수 있다면 이미 단순한 추천 도구가 아닙니다. 제한된 실행 주체가 됩니다.

따라서 먼저 정해야 할 것은 “얼마나 잘하느냐”가 아니라 “어디까지 하게 할 것이냐”입니다. 읽기만 가능한 작업, 제한된 쓰기가 가능한 작업, 사람 승인이 필요한 작업, 아예 금지해야 할 작업을 나눠야 합니다. 이 구분이 없으면 좋은 모델일수록 더 빠르게 잘못된 범위까지 들어갈 수 있습니다.

구분	흔한 질문	다시 물어야 할 질문
작업공간	오래 실행할 수 있나요?	어느 환경에서, 어떤 데이터 경계 안에서 실행되나요?
권한	자동으로 명령을 실행할 수 있나요?	읽기, 쓰기, 설치, 배포, 외부 접속 권한이 어떻게 나뉘나요?
자격 증명	토큰이나 키를 쓸 수 있나요?	자격 증명이 작업 범위별로 제한되고 기록되나요?
검토	풀 리퀘스트를 만들 수 있나요?	어떤 변경은 반드시 사람 리뷰를 거쳐야 하나요?

관전 포인트 2: 감사 로그는 선택 기능이 아닙니다

AI 에이전트의 결과물은 겉으로 보면 그럴듯할 수 있습니다. 테스트가 통과했고, 풀 리퀘스트 설명도 깔끔할 수 있습니다. 하지만 기업에서는 결과만으로 충분하지 않습니다.

누가 어떤 지시를 했는지, 에이전트가 어떤 파일을 읽었는지, 어떤 명령을 실행했는지, 어디에서 실패했고 어떻게 수정했는지 확인할 수 있어야 합니다. 이 기록이 없으면 리뷰는 코드만 보고 추정하는 일이 됩니다.

OpenAI의 Codex 거버넌스 문서도 이 지점을 강조합니다. 기업 팀이 채택 현황과 영향을 추적하고, 보안과 규정 준수 프로그램에 필요한 감사 가능성을 확보할 수 있도록 분석 대시보드, Analytics API, Compliance API를 제공한다는 설명입니다. 결국 감사 로그는 사후 확인용 부속 기능이 아니라 운영 신뢰의 기본 장치입니다.

CHECKLIST

프롬프트와 응답이 추적되나요?
읽은 파일과 수정한 파일을 구분해 볼 수 있나요?
실행한 명령, 테스트 결과, 실패 기록이 남나요?
승인이 필요한 작업과 자동 실행된 작업을 나눠 볼 수 있나요?
보안팀이나 감사 담당자가 별도 흐름으로 로그를 확인할 수 있나요?

기업은 무엇부터 정해야 할까요?

첫 번째는 작업 분류입니다. 버그 재현, 테스트 작성, 문서 정리, 리팩터링, 의존성 업데이트, 보안 취약점 수정은 모두 “코드 작업”처럼 보이지만 위험도는 다릅니다. 같은 권한으로 묶으면 안 됩니다.

두 번째는 권한표입니다. 읽기만 가능한 작업, 제한된 쓰기가 가능한 작업, 승인 후 실행할 수 있는 작업, 금지해야 할 작업을 나눠야 합니다. 특히 배포, 비밀키, 고객 데이터, 외부 API 호출이 걸린 영역은 별도 기준이 필요합니다.

세 번째는 리뷰 책임입니다. 에이전트가 만든 변경을 누가 보고, 어떤 기준으로 승인하며, 문제가 생기면 어떤 절차로 되돌릴지 정해야 합니다. 로그가 있어도 아무도 보지 않으면 통제 장치가 아닙니다.

PRACTICAL MOVE

AI 에이전트에게 맡길 작업을 위험도별로 나눕니다.
작업 유형별로 읽기, 쓰기, 실행, 외부 접속 권한을 분리합니다.
민감 데이터, 비밀키, 배포 파이프라인 접근은 별도 승인 대상으로 둡니다.
감사 로그를 누가, 얼마나 자주, 어떤 기준으로 볼지 정합니다.
AI 에이전트가 만든 변경을 되돌리는 절차를 미리 마련합니다.

모든 기업이 당장 복잡한 에이전트 운영 체계를 만들 필요는 없습니다. 코드베이스가 작고 보안 요구가 낮은 팀이라면 기존 보조 도구만으로도 충분할 수 있습니다. 다만 여러 저장소, 민감 데이터, 외부 시스템, 배포 파이프라인이 함께 걸려 있다면 이야기가 달라집니다.

Ona 인수 계획은 Codex가 더 긴 작업을 맡는 쪽으로 이동하고 있다는 신호입니다. 그리고 긴 작업에는 단순한 프롬프트보다 더 많은 것이 필요합니다. 에이전트가 일할 장소, 접근할 수 있는 범위, 멈춰야 하는 조건, 남겨야 하는 기록이 필요합니다.

결국 내부 질문은 하나로 좁혀집니다. “우리는 AI 에이전트에게 긴 작업을 맡길 준비가 되어 있나요?” 답은 구독 중인 모델 이름이 아니라 작업공간, 권한표, 감사 로그, 리뷰 책임에서 나옵니다.

AEO QUICK ANSWER

AI 에이전트 도입에서 먼저 확인할 것은 모델 성능만이 아닙니다. 장시간 작업을 맡기려면 에이전트가 실행되는 작업공간, 접근 권한, 승인 절차, 감사 로그, 사람 리뷰 기준을 먼저 정해야 합니다. Ona는 바로 이 실행 환경과 통제 계층을 제공하는 회사로 볼 수 있습니다.

FAQ

Ona는 어떤 회사인가요?

Ona는 AI 모델 회사라기보다 AI 에이전트가 일할 클라우드 작업공간을 제공하는 회사에 가깝습니다. Gitpod에서 출발해 클라우드 개발 환경, 백그라운드 에이전트, 권한 통제, 감사 로그를 제공하는 플랫폼으로 방향을 넓혔습니다.

OpenAI는 왜 Ona를 인수하려 하나요?

Codex가 짧은 코드 제안 도구를 넘어 장시간 작업을 수행하는 에이전트로 확장되려면, 안전한 실행 환경과 권한 통제, 감사 가능한 기록이 필요합니다. Ona는 이 실행 기반을 제공하는 회사이기 때문에 Codex의 기업형 배포와 연결됩니다.

AI 에이전트는 왜 클라우드 작업공간이 필요한가요?

긴 작업은 사용자의 현재 세션 안에서 끝나지 않을 수 있습니다. 클라우드 작업공간은 에이전트가 코드, 도구, 테스트 환경, 작업 맥락을 유지한 채 계속 일할 수 있게 해줍니다.

기업은 AI 에이전트 권한을 어떻게 나눠야 하나요?

작업 유형별로 읽기, 쓰기, 명령 실행, 외부 네트워크 접근, 배포 관련 권한을 나눠야 합니다. 특히 의존성 설치, 민감 데이터 접근, 배포 파이프라인 변경은 별도 승인 기준을 두는 편이 안전합니다.

이 블로그 검색