Codex for almost everything은 무엇을 바꾸나 2026 — computer use·plugins·automation 실사용 분기표

Posted on by

OpenAI는 2026년 4월 16일 Codex for (almost) everything 발표에서 Codex를 주간 300만 명 이상 개발자가 쓰는 개발 파트너라고 설명하며, computer use, in-app browser, image generation, plugins, memory, automations를 Codex app에 확장한다고 밝혔다.

이전의 Codex를 한 문장으로 줄이면 코드베이스 안에서 일하는 코딩 에이전트였다.

이번 업데이트 이후의 Codex는 조금 다르게 읽어야 한다.

IDE 안 도우미에서 작업 운영 레이어로 넘어가는 신호에 가깝다.

그 말이 멋있게 들리긴 하는데, 운영자 입장에서는 바로 축하 케이크를 자르면 안 된다.

케이크 위에 권한, 브라우저 세션, 플러그인, 자동화, 메모리라는 촛불이 한꺼번에 꽂혔다.

불빛은 예쁜데, 잘못 꽂으면 책상도 같이 탄다.

이번 글은 출시 기능 목록을 다시 적는 글이 아니다.

공식 발표와 Codex 문서를 기준으로 어떤 작업에 바로 써도 되는지, 어떤 작업은 아직 사람 승인과 sandbox를 먼저 봐야 하는지, 기존 CLI/IDE/Cloud 흐름과 어떻게 나눠야 하는지를 실사용 분기표로 정리한다.

한 줄로 먼저 적으면 이렇다.
Codex for almost everything 업데이트는 Codex를 코드 작성 도구에서 앱·브라우저·외부 도구·장기 작업까지 다루는 워크스페이스로 넓힌다. 하지만 바로 넓게 쓰기보다 local code, browser preview, plugin action, computer use, automation을 권한 단계별로 나눠야 덜 피곤하다.

지금 답

이번 Codex 업데이트에서 봐야 할 핵심은 다섯 가지다.

축 공식 기능 실사용 의미 먼저 써볼 작업 조심할 지점
computer use Codex가 macOS 앱 화면을 보고 클릭·입력 API 없는 앱도 시각적으로 조작 데스크톱 앱 테스트, 브라우저 기반 재현 민감 화면, 잘못된 창, 로그인 세션
in-app browser Codex app 안에서 렌더링 페이지를 같이 확인 프론트엔드 피드백 루프 단축 localhost 화면, 모바일 레이아웃 코멘트 인증 필요한 페이지, 비밀 입력
plugins skills, app integrations, MCP servers 묶음 Gmail, Drive, Slack, GitHub 같은 작업 연결 읽기/요약/초안 작성 사이드 이펙트, 데이터 공유 범위
automations 예약·반복 작업을 background로 실행 장기 작업과 후속 점검 루프 PR follow-up, inbox triage, 주기 점검 full access 자동화, worktree 정리
memory/context suggestions 이전 경험과 선호를 활용 반복 설명 비용 감소 개인 작업 패턴 재사용 잘못 배운 선호, 팀 표준과 충돌

실무적으로는 이렇게 보면 된다.

코드 수정은 여전히 Codex의 기본 체력이다.

프론트엔드 확인은 in-app browser가 먼저다.

브라우저 로그인이 필요하거나 GUI 앱 재현이 필요하면 computer use를 검토한다.

외부 서비스 데이터가 필요하면 plugin이나 MCP 쪽이 먼저다.

반복 점검은 automation으로 보낼 수 있다.

다만 권한이 넓어질수록 사람의 리뷰 지점은 더 앞에 와야 한다.

이게 이번 글의 핵심이다.

Codex가 더 많은 일을 할 수 있게 된 만큼, 사용자는 더 적게 생각해도 되는 게 아니다.

오히려 어디까지 맡길지를 더 선명하게 정해야 한다.

읽어야 하는 경우

이 글은 이런 사람에게 맞다.

  • Codex app, CLI, IDE extension, Cloud를 같이 쓰는데 역할이 헷갈리는 사람
  • computer use를 켜도 되는 작업과 아직 기다려야 하는 작업을 나누고 싶은 사람
  • Codex plugins를 MCP 서버, skills, app connector와 어떻게 봐야 할지 정리하고 싶은 사람
  • Codex Automations를 장기 작업 루프에 붙이기 전에 권한 리스크를 먼저 보고 싶은 사람
  • OpenAI 발표를 보고 이제 IDE가 끝난 건가 같은 큰말보다 실제 워크플로 기준표가 필요한 사람

반대로 단순히 설치 버튼 위치만 찾는다면 공식 quickstart를 먼저 보면 된다.

이 글은 설치법보다 운영 판단 쪽에 가깝다.

특히 TECHTAEK 독자라면 관심사는 이거다.

새 기능이 나왔다는 사실보다, 그 기능을 내 작업 시스템 어디에 꽂아야 덜 망하는가.

여기서 덜 망하는 게 꽤 중요하다.

AI 도구는 잘 쓰면 시간이 줄지만, 어설프게 넓히면 확인할 창만 늘어난다.

일 잘하는 척하는 탭 부자 되는 거다.

그건 생산성이라기보다 브라우저 사육이다.

한 장 판단표

이번 업데이트를 바로 도입할 때는 아래 순서로 생각하면 쉽다.

질문 먼저 선택할 기능 이유
코드베이스를 읽고 수정하면 되는가 Local Codex app, CLI, IDE extension 파일 diff와 테스트로 검증 가능
화면이 실제로 어떻게 보이는지 확인해야 하는가 in-app browser 코드와 렌더링 화면을 같은 thread에서 볼 수 있음
로그인 없는 localhost나 public page인가 in-app browser 공식 문서도 인증 없는 페이지에 적합하다고 안내
로그인된 브라우저나 데스크톱 앱 조작이 필요한가 computer use 화면을 보고 클릭·입력해야 하는 작업
외부 서비스 데이터를 구조적으로 읽어야 하는가 plugin 또는 MCP 시각 조작보다 repeatable한 데이터 접근이 낫다
매일/매주 같은 점검을 반복해야 하는가 automation background run과 inbox 결과가 맞음
승인 없이 장기 실행해도 되는가 아주 좁은 automation만 full access background 자동화는 위험도가 확 뛴다

이 표에서 제일 중요한 줄은 in-app browser와 computer use의 차이다.

둘 다 화면을 본다는 느낌이 있지만 다르다.

in-app browser는 Codex app 안의 제한된 브라우저 preview에 가깝다.

computer use는 macOS의 실제 앱 화면을 보고 조작하는 쪽이다.

그래서 프론트엔드 개발 중 localhost 화면을 확인하는 정도면 in-app browser부터 쓰는 게 맞다.

반면 네이티브 앱, iOS simulator, 클릭으로만 재현되는 설정 화면, plugin이 없는 데이터 소스라면 computer use가 후보가 된다.

이 차이를 안 나누면 계속 헷갈린다.

화면만 보이면 다 같은 줄 알고 던졌다가, 권한과 로그인 세션이 뒤섞인다.

그 순간부터 작업이 아니라 방탈출이 된다.

무엇이 바뀌었나

OpenAI 공식 발표는 이번 업데이트를 full software development lifecycle 쪽으로 설명한다.

코드 작성만이 아니라, 컨텍스트 수집, 디자인 확인, PR 리뷰, 브라우저 반복, 이미지 생성, 장기 작업까지 한 워크스페이스로 가져오려는 방향이다.

발표에서 직접 언급된 변화는 꽤 많다.

Codex app은 computer use를 통해 Mac의 앱을 보고 클릭하고 입력할 수 있다.

in-app browser에서는 페이지에 직접 코멘트를 달아 agent에게 정밀한 수정 지시를 줄 수 있다.

gpt-image-1.5를 통해 이미지 생성과 반복 수정도 같은 흐름에 붙는다.

90개 이상 추가 plugins도 나온다.

plugins는 skills, app integrations, MCP servers를 묶어 Codex가 더 많은 도구에서 맥락을 얻고 action을 할 수 있게 한다.

개발 workflow 쪽에서는 GitHub review comment 처리, 여러 terminal tab, SSH remote devbox 연결 alpha, sidebar file preview, PDF·spreadsheet·slide·doc rich preview, agent plan/source/artifact summary pane도 언급됐다.

장기 작업 쪽에서는 automations가 기존 conversation thread를 재사용할 수 있고, Codex가 미래 작업을 schedule하거나 days/weeks 단위로 이어갈 수 있다고 설명한다.

memory preview와 context-aware suggestion도 발표 범위에 들어간다.

말만 보면 이제 다 되네처럼 들린다.

하지만 실사용자는 여기서 기능별로 위험도를 쪼개야 한다.

코드 파일을 고치는 것과 로그인된 브라우저에서 버튼을 누르는 것은 같은 action이 아니다.

Slack 요약과 Gmail 발송도 같은 plugin workflow가 아니다.

자동화가 매일 읽기만 하는 것과 매일 파일을 바꾸는 것도 같은 자동화가 아니다.

업데이트의 방향은 넓어졌지만, 운영 기준은 더 촘촘해져야 한다.

computer use는 언제 쓰나

공식 Codex 문서 기준으로 computer use는 Codex app에서 macOS 앱을 보고 조작하는 기능이다.

2026년 4월 17일 기준 문서는 launch 시점에 macOS에서 제공되며, EEA, UK, Switzerland는 예외로 안내한다.

사용하려면 Computer Use plugin을 설치하고 macOS Screen Recording과 Accessibility 권한을 허용해야 한다.

이 말은 중요하다.

Codex가 단순히 파일을 읽는 게 아니라 화면을 볼 수 있고, 클릭하고, 입력하고, clipboard나 window state와 만날 수 있다는 뜻이다.

잘 쓰면 좋다.

특히 이런 작업에 맞다.

작업 computer use 적합도 이유
macOS 앱 또는 iOS simulator flow 테스트 높음 파일 diff만으로 재현이 어려움
브라우저에서만 보이는 UI 버그 재현 중간~높음 단, 로그인 상태면 사람 리뷰 필요
API 없는 데스크톱 앱 설정 변경 높음 plugin보다 시각 조작이 필요
계정·결제·보안 설정 변경 낮음 민감 action이라 사람이 직접 하는 쪽이 낫다
코드 포맷팅과 테스트 실행 낮음 CLI나 IDE extension으로 충분

내 워크플로에 대입하면 이런 식이다.

Obsidian vault 안에서 글 파일을 만들고, preflight를 돌리고, WordPress에 올리는 작업은 대부분 CLI와 API로 처리된다.

이런 작업에는 computer use가 굳이 필요 없다.

반대로 어떤 데스크톱 앱에서만 보이는 렌더링 문제, 브라우저에서만 재현되는 hover tooltip 문제, 앱 설정 화면을 눌러야 확인되는 문제라면 computer use가 의미가 있다.

즉 computer use는 코드 작성 능력을 키우는 기능이라기보다 검증 표면을 넓히는 기능에 가깝다.

여기서 표면이라는 말이 핵심이다.

agent가 만질 수 있는 표면이 넓어질수록 사고 표면도 같이 넓어진다.

그래서 task를 아주 좁게 줘야 한다.

내 앱 좀 봐줘는 너무 넓다.

localhost:3000/settings에서 billing toggle이 모바일 390px에서 줄바꿈되는지 확인하고, 문제 있으면 CSS만 최소 수정해처럼 주는 게 낫다.

권한도 마찬가지다.

항상 허용할 앱은 정말 믿는 앱으로 제한해야 한다.

공식 문서도 computer use가 sensitive or disruptive actions 전에 permission을 요청할 수 있고, 민감한 flow에서는 사람이 지켜보라고 안내한다.

좋은 기능이다.

그래서 더 조심해야 한다.

in-app browser는 어디까지 맡기나

in-app browser는 computer use보다 먼저 봐야 할 기능이다.

공식 문서 기준으로 in-app browser는 Codex app thread 안에서 rendered web page를 같이 보는 기능이다.

local development server, file-backed previews, public pages처럼 로그인 없이 볼 수 있는 페이지에 맞다.

반대로 인증 flow, signed-in pages, regular browser profile, cookies, extensions, existing tabs는 지원하지 않는다고 문서는 말한다.

이 제한이 오히려 장점이다.

프론트엔드 개발에서 대부분의 좋은 피드백은 로그인 세션보다 화면 상태에서 나온다.

loading, empty, error, success, mobile, desktop, hover, modal 같은 상태를 좁게 열어두고 코멘트를 남기면 된다.

Codex는 같은 thread에서 코드 diff와 rendered state를 같이 볼 수 있다.

이건 꽤 실용적이다.

프론트엔드 작업에서 제일 지치는 부분이 코드 수정 → 서버 확인 → 스크린샷 설명 → 다시 수정 루프다.

in-app browser는 이 루프를 조금 짧게 만든다.

하지만 여기에도 선이 있다.

상황 in-app browser regular browser 또는 computer use
localhost public route 확인 좋음 굳이 필요 없음
디자인 comment로 위치 지정 좋음 너무 무겁다
로그인된 관리자 화면 부적합 regular browser 또는 computer use, 사람 승인
extension 의존 기능 부적합 regular browser
외부 결제 flow 부적합 사람이 직접 확인

내가 이 기능을 쓴다면 첫 후보는 블로그나 대시보드 UI다.

예를 들어 blog-dashboard.md를 웹으로 렌더링하는 내부 페이지가 있다면, Codex에게 모바일에서 표가 넘치는지 확인시키고 comment로 위치를 찍게 할 수 있다.

또는 React/Vite 앱에서 pricing card, chart tooltip, modal overflow 같은 문제를 잡기 좋다.

중요한 건 화면 피드백을 기능 요구사항으로 섞지 않는 것이다.

이 버튼 좀 더 좋아 보이게는 애매하다.

모바일 390px에서 버튼 텍스트가 카드 밖으로 나가면 줄바꿈하고 카드 높이는 유지해가 낫다.

AI에게 미감까지 맡길 수는 있다.

근데 미감 맡겼다가 갑자기 gradient 천국이 열리면 사람도 울고 CSS도 운다.

plugins는 MCP보다 넓은 묶음이다

Codex plugins 문서는 plugins를 skills, app integrations, MCP servers를 묶는 reusable workflows라고 설명한다.

이 정의가 중요하다.

plugin은 MCP 서버 하나와 같은 말이 아니다.

plugin 안에는 task-specific skill instruction이 들어갈 수 있다.

GitHub, Slack, Google Drive 같은 app integration도 들어갈 수 있다.

외부 시스템 도구를 제공하는 MCP server config도 들어갈 수 있다.

그래서 plugin은 도구 한 개보다 워크플로 패키지에 가깝다.

예를 들어 Gmail plugin은 Codex가 Gmail을 읽고 관리하는 데 쓰일 수 있다.

Google Drive plugin은 Docs, Sheets, Slides까지 연결될 수 있다.

Slack plugin은 channel summary나 reply draft 같은 작업에 맞을 수 있다.

하지만 여기서도 바로 읽기/쓰기 경계를 나눠야 한다.

plugin 작업 먼저 허용하기 좋은 범위 사람 승인 필요한 범위
Slack 채널 요약 읽기, 요약, action item 추출 메시지 전송
Gmail triage 읽기, 분류, 초안 작성 실제 발송, 삭제, label 대량 변경
GitHub Issues 이슈 읽기, 요약, draft comment close, assign, label 변경
Google Drive 문서 요약, 표 추출 공유 권한 변경, 원본 수정
CI/CD 실패 로그 읽기 배포 재시도, 환경 변수 변경

Codex 문서는 app/connector tool calls 중 side effect가 있는 action도 approval을 요구할 수 있다고 설명한다.

destructive app/MCP tool calls는 tool이 destructive annotation을 광고하면 approval이 필요하다고도 한다.

운영자는 이 문장을 좋아해야 한다.

승인이 귀찮아 보이지만, 이게 없으면 AI 자동화는 금방 무서워진다.

좋은 plugin 운영은 허용된 action 목록부터 만든다.

예를 들어 블로그 파이프라인이라면 이런 식이다.

읽기 허용:

  • Google Sheet backlog 읽기
  • Obsidian inbox note 읽기
  • 기존 published URL 조회
  • WordPress post status 조회

쓰기 허용:

  • draft markdown 생성
  • status를 drafting/review/published로 갱신
  • published URL 저장

사람 확인 필요:

  • source 품질이 낮은 글 발행
  • 세금·금융 정보처럼 날짜와 공식 근거가 필요한 글
  • 기존 published 글의 slug/canonical 변경
  • 대량 삭제나 archive 이동

이 정도를 정해야 plugin이 생산성이 된다.

아니면 그냥 연결이 많아진 불안한 손이 된다.

손은 많으면 좋지만, 장갑이 없으면 사고 난다.

automations는 예약 실행보다 운영 루프다

Codex Automations 문서는 recurring tasks를 background에서 자동화하고, findings를 inbox에 남기거나 보고할 게 없으면 archive할 수 있다고 설명한다.

프로젝트 scoped automation은 app이 실행 중이고 선택한 project가 disk에서 사용 가능해야 한다.

Git repo에서는 local project 또는 새 worktree에서 돌릴 수 있다.

worktree는 unfinished local work와 자동화 변경을 분리하는 데 좋다.

local mode는 main checkout을 직접 만질 수 있으니 편하지만 위험하다.

이 구분은 실무에서 꽤 크다.

자동화는 한 번 실행되는 agent가 아니라 반복되는 신뢰 계약이다.

한 번 삐끗해도 사람이 고치면 되는 작업과, 매일 새벽에 삐끗하는 작업은 다르다.

그래서 automation은 기능보다 운영 메타데이터가 중요하다.

automation 후보 추천 실행 환경 이유
매일 backlog 요약 local 또는 worktree 읽기 위주면 부담 낮음
오래된 PR comment 확인 worktree 수정 가능성이 있음
블로그 source 품질 점검 local 파일 변경 적고 리포트 중심
dependency update PR 생성 worktree diff 격리 필요
production 설정 변경 자동화 부적합 사람 승인과 변경관리 필요

공식 문서는 automations가 default sandbox settings를 사용한다고 설명한다.

read-only이면 파일 수정, network access, app 작업이 필요한 tool call이 실패할 수 있다.

workspace-write이면 workspace 밖 수정, network, computer app 작업이 제한될 수 있다.

full access는 background automations에서 elevated risk를 가진다고 문서는 경고한다.

여기서 중요한 말은 background다.

사람이 보고 있는 foreground agent는 실수해도 바로 잡을 수 있다.

background automation은 사람이 커피 내리는 사이에 파일을 바꾸고 network를 쓸 수 있다.

커피는 죄가 없는데, 자동화가 일을 벌인다.

그래서 automation은 처음부터 full access로 두면 안 된다.

처음에는 읽기 중심, inbox report 중심으로 시작한다.

그 다음 특정 workspace 안에서만 write를 허용한다.

그 다음 command allowlist나 rules를 붙인다.

마지막으로 worktree isolation을 검토한다.

이 순서가 귀찮아 보이면 아직 automation을 붙일 준비가 덜 된 것이다.

자동화는 귀찮음을 줄이는 도구지만, 자동화 설계는 원래 조금 귀찮아야 한다.

memory와 제안 기능은 생산성인가 리스크인가

OpenAI 발표는 memory preview와 context-aware suggestions를 같이 언급한다.

Codex가 이전 경험, 개인 선호, correction, 찾는 데 오래 걸렸던 정보를 기억해 다음 작업 품질을 높인다는 방향이다.

또 project, connected plugins, memory context를 바탕으로 아침에 무엇부터 시작할지, 이전 project에서 어디를 이어갈지 제안할 수 있다고 설명한다.

이건 매력적이다.

매번 우리 repo는 이렇게 해, 테스트는 이 명령으로 돌려, blog file은 여기 있어, published status는 sheet script로 닫아를 반복하지 않아도 된다.

개인 작업자에게 memory는 분명 좋다.

하지만 팀에서는 조심해야 한다.

개인 선호가 팀 표준을 덮으면 곤란하다.

예를 들어 한 사람은 full-auto를 선호하고, 팀 표준은 workspace-write + approval이라면 memory가 엉뚱한 방향으로 agent를 편하게 만들 수 있다.

또 어떤 repo에서는 테스트 생략이 허용됐지만, 다른 repo에서는 테스트가 release gate라면 memory가 context를 잘못 일반화할 수 있다.

그래서 memory는 두 층으로 봐야 한다.

기억 종류 개인 memory에 적합 repo 문서에 둬야 함
선호 말투, 보고 형식 적합 선택
자주 쓰는 개인 workflow 적합 팀 공유 시 문서화
test/lint/build command 일부 적합 AGENTS.md 또는 README가 우선
보안 승인 기준 부적합 팀 policy가 우선
배포 절차 부적합 runbook이 우선

TECHTAEK 관점에서는 memory를 프롬프트 절약 기능으로만 보면 아깝다.

memory는 agent의 행동 기본값에 영향을 줄 수 있는 운영 자산이다.

그래서 개인화는 좋지만, 팀 표준은 여전히 repo 문서와 policy에 있어야 한다.

개인 기억은 편의다.

팀 규칙은 계약이다.

둘을 섞으면 나중에 누가 뭘 믿고 실행했는지 추적하기 어려워진다.

Codex app, CLI, IDE extension, Cloud는 어떻게 나눌까

공식 quickstart 기준으로 Codex는 app, IDE extension, CLI, cloud 네 가지 흐름으로 쓸 수 있다.

Codex app은 macOS와 Windows에서 사용할 수 있다.

IDE extension은 VS Code, Cursor, Windsurf, VS Code Insiders에서 Codex panel을 띄우는 흐름이다.

CLI는 terminal에서 codex를 실행하는 방식이고, macOS, Windows, Linux를 지원한다.

Cloud는 browser에서 chatgpt.com/codex로 작업을 위임하고, GitHub PR comment에서 @codex로도 task를 보낼 수 있다.

각 표면은 쓰임이 다르다.

표면 제일 잘 맞는 일 피곤해지는 일
Codex app 여러 파일, terminal, browser, computer use를 한 workspace에서 다루기 순수 shell 반복만 할 때
IDE extension 코드 읽기·수정·리뷰를 IDE 옆에서 바로 보기 앱 밖 workflow까지 한꺼번에 맡기기
CLI repo automation, script, terminal-native 작업 화면 검증이 핵심인 작업
Cloud background coding task, PR 생성, remote 환경 작업 로컬 GUI와 민감 세션 의존 작업

내 기준으로는 이렇게 나눈다.

코드만 만지면 CLI나 IDE extension이면 충분하다.

frontend visual feedback이 들어가면 Codex app의 browser가 좋아진다.

앱 조작이 필요하면 computer use를 검토한다.

장시간 독립 작업이면 Cloud나 automation이 후보가 된다.

다만 local과 cloud의 보안 모델은 다르게 봐야 한다.

Codex security 문서는 cloud가 OpenAI-managed isolated containers에서 실행되고, setup phase와 agent phase가 나뉘며, agent phase는 기본적으로 offline이라고 설명한다.

CLI/IDE extension은 OS-level mechanism으로 sandbox policy를 enforcement하고, 기본적으로 network access가 없고 write permission은 active workspace로 제한된다고 설명한다.

즉 Codex니까 다 같은 sandbox가 아니다.

어디에서 돌리는지에 따라 boundary가 다르다.

운영자는 기능 선택 전에 실행 표면부터 골라야 한다.

이 순서가 바뀌면 권한 설계가 늦어진다.

권한 설계가 늦어지면 나중에 다이어트보다 어렵다.

이미 붙은 자동화와 plugin을 빼는 건 생각보다 아프다.

실사용 분기표

아래 표는 이번 업데이트를 내 워크플로에 붙일 때의 1차 분기표다.

하고 싶은 일 추천 흐름 이유 처음 줄 프롬프트 예시
블로그 초안 preflight 오류 고치기 CLI 또는 app local 파일과 script로 검증 가능 이 markdown의 preflight 실패 원인을 최소 수정해
WordPress live page 렌더링 확인 browser + curl public page라 인증 필요 낮음 published URL을 열고 title/canonical/body 반영을 확인해
React 페이지 모바일 레이아웃 수정 app in-app browser 렌더링과 diff를 같이 봄 390px에서 card overflow만 고치고 구조는 유지해
데스크톱 앱 설정 화면 재현 computer use GUI 클릭이 핵심 @Computer Use로 설정 화면을 열고 bug를 재현해
Slack에서 이번 주 action item 추출 Slack plugin 구조적 읽기 우선 Slack 채널을 읽고 action item draft만 만들어
Gmail 답장 초안 Gmail plugin 발송 전 사람 검토 필요 답장 초안만 만들고 발송하지 마
매일 backlog stale 체크 automation 반복 점검에 적합 매일 backlog stale item을 찾아 inbox에 요약해
PR review comment 반영 Cloud 또는 worktree automation diff 격리 필요 새 worktree에서 review comments만 처리해

여기서 prompt 예시의 공통점은 모두 범위를 줄인다는 것이다.

전체적으로 개선해줘가 없다.

가능하면 알아서 해줘도 없다.

AI에게 넓게 맡기는 게 멋있어 보이지만, 실제 운영에서는 좁게 맡기는 사람이 오래 간다.

좁은 task는 검증할 수 있다.

검증할 수 있는 task는 자동화할 수 있다.

자동화할 수 있는 task만 장기 운영 자산이 된다.

이 순서를 거꾸로 하면, 자동화는 빠르게 자라지만 신뢰는 안 자란다.

권한 체크리스트

Codex for almost everything 업데이트를 팀이나 개인 workflow에 붙이기 전에 아래를 체크해야 한다.

체크 질문 통과 기준
실행 표면 app, CLI, IDE, cloud 중 어디서 돌리나 task마다 기본 표면이 정해져 있음
sandbox read-only, workspace-write, full access 중 무엇인가 기본은 좁고 예외만 넓힘
approval 어떤 action에서 멈추나 파일 외부 수정, network, destructive tool은 멈춤
app permission 어떤 앱을 항상 허용하나 trusted app만 Always allow
plugin scope 읽기와 쓰기를 나눴나 발송·삭제·배포는 승인 필요
browser state 로그인 세션이 필요한가 가능하면 in-app browser, 안 되면 사람이 지켜봄
automation scope unattended로 돌려도 되나 읽기 중심 또는 worktree 격리
output review 결과를 어디서 보나 inbox, PR, diff, report 위치가 고정됨

공식 security 문서는 sandbox mode와 approval policy를 두 층으로 설명한다.

sandbox mode는 Codex가 기술적으로 어디까지 할 수 있는지다.

approval policy는 Codex가 언제 사람에게 물어야 하는지다.

둘은 다르다.

workspace-write sandbox라도 network access가 필요하면 approval이 걸릴 수 있다.

full access라도 팀 정책으로 automation의 approval_policy = never를 막을 수 있다.

이런 층을 이해해야 Codex가 넓어져도 덜 무섭다.

특히 computer use에서는 macOS 권한과 Codex app approval도 따로 봐야 한다.

macOS Screen Recording과 Accessibility는 Codex가 보고 조작할 수 있게 하는 권한이다.

Codex app approval은 어떤 app을 사용하도록 허용할지의 문제다.

file edit과 shell command는 여전히 thread의 sandbox와 approval setting을 따른다.

권한이 한 덩어리가 아니다.

이걸 하나로 뭉개면 나중에 문제가 생겼을 때 어디서 막아야 할지 모른다.

60분 테스트 플랜

이번 업데이트를 바로 실전에 넣기 전에 60분짜리 작은 테스트를 추천한다.

첫 15분은 local code task다.

작은 bug 하나를 고치게 하고, diff와 test evidence를 확인한다.

이건 기존 Codex 역량 확인이다.

다음 15분은 in-app browser task다.

localhost 페이지 하나를 열고, 모바일 overflow나 tooltip 위치 같은 시각 문제를 comment로 지정한다.

여기서 중요한 건 Codex가 comment를 code change로 정확히 연결하는지 보는 것이다.

다음 15분은 plugin 또는 MCP 읽기 task다.

Slack, Drive, GitHub 같은 source에서 정보를 읽고 요약만 하게 한다.

쓰기 action은 시키지 않는다.

마지막 15분은 automation 설계만 한다.

실행까지 바로 가지 말고, prompt, schedule, output, sandbox, worktree 여부를 적는다.

이 네 단계를 통과하면 그때 일부 workflow에 붙인다.

처음부터 computer use와 automation과 plugin write를 동시에 열지 않는다.

새 차 샀다고 첫날 바로 눈길 산길 야간운전 풀코스로 가는 건 좀 그렇다.

차도 놀라고 사람도 놀란다.

AI 도구도 비슷하다.

처음엔 평지에서 브레이크부터 봐야 한다.

실수 TOP 7

첫 번째 실수는 computer use를 만능 UI 테스트로 보는 것이다.

computer use는 강력하지만, in-app browser나 CLI로 충분한 작업까지 가져오면 검증 비용만 늘어난다.

두 번째 실수는 로그인된 브라우저를 너무 쉽게 맡기는 것이다.

공식 문서도 browser 사용 시 signed-in pages에서 action이 내 account에서 온 것으로 처리될 수 있다고 안내한다.

세 번째 실수는 plugin을 연결 수로 평가하는 것이다.

plugin은 많을수록 좋은 게 아니라, 읽기/쓰기/삭제/발송 권한이 잘 나뉠수록 좋다.

네 번째 실수는 automations를 full access로 시작하는 것이다.

background에서 full access는 편한 만큼 위험하다.

다섯 번째 실수는 memory를 팀 규칙처럼 쓰는 것이다.

팀 표준은 AGENTS.md, README, runbook, policy에 있어야 한다.

memory는 개인화 보조에 가깝게 다뤄야 한다.

여섯 번째 실수는 Cloud와 local의 sandbox 차이를 무시하는 것이다.

cloud container와 local OS sandbox는 같은 말이 아니다.

일곱 번째 실수는 결과 리뷰 위치를 정하지 않는 것이다.

작업 결과가 diff인지, inbox finding인지, PR인지, markdown report인지 정하지 않으면 자동화가 끝나도 사람이 다시 찾아야 한다.

AI가 일했는데 사람이 수색대가 되면 좀 억울하다.

수색대는 멋있지만 매일 하긴 피곤하다.

운영자 관점의 결론

Codex for almost everything은 이름처럼 많은 것을 Codex 쪽으로 끌어온다.

컴퓨터 화면을 보고, browser를 열고, plugins로 외부 도구를 읽고, automations로 반복 작업을 돌리고, memory로 이전 맥락을 이어간다.

방향은 분명하다.

OpenAI는 Codex를 단순 code generator보다 넓은 software workbench로 밀고 있다.

나는 이 방향이 꽤 맞다고 본다.

개발자는 이미 코드만 쓰지 않는다.

이슈를 읽고, Slack을 보고, 문서를 뒤지고, 브라우저에서 확인하고, PR comment를 처리하고, 배포 로그를 본다.

AI coding agent가 진짜 도움이 되려면 이 주변 일을 같이 봐야 한다.

다만 모든 주변 일을 한 번에 맡기면 안 된다.

작업 표면이 넓어질수록 권한 표면도 넓어진다.

그래서 이번 업데이트의 핵심은 기능 수가 아니다.

무엇을 더 할 수 있나보다 무엇을 어떤 경계 안에서 맡길 것인가가 더 중요하다.

내 추천은 단순하다.

1단계는 Codex app/CLI/IDE에서 code task를 안정화한다.

2단계는 in-app browser로 프론트엔드 검증 루프를 줄인다.

3단계는 read-only plugin workflow를 붙인다.

4단계는 worktree 기반 automation을 붙인다.

5단계에서야 computer use와 write-capable plugin을 신중히 넓힌다.

이 순서면 Codex는 진짜 workspace가 된다.

순서를 건너뛰면 그냥 권한 많은 조수다.

권한 많은 조수는 유능할 수 있다.

근데 비상구 위치는 알아야 같이 일할 수 있다.

FAQ

Codex for almost everything은 Codex가 모든 앱을 자동으로 다룬다는 뜻인가?

아니다.

공식 발표는 Codex가 computer use, plugins, in-app browser, automations 등으로 범위를 넓힌다고 설명한다.

하지만 공식 문서 기준으로 computer use는 macOS 권한과 Codex app approval이 필요하고, sensitive action에서는 사람이 검토해야 한다.

모든 것이 아니라 기존보다 훨씬 넓은 작업 표면으로 보는 게 맞다.

computer use와 in-app browser는 뭐가 다른가?

in-app browser는 Codex app thread 안에서 rendered web page를 같이 보는 기능이다.

로그인 없는 local dev server, file-backed preview, public page에 맞다.

computer use는 Codex가 macOS 앱을 보고 클릭하고 입력하는 기능이다.

데스크톱 앱, iOS simulator, regular browser, plugin이 없는 GUI 작업처럼 시각 조작이 필요한 경우에 맞다.

먼저 in-app browser를 쓰고, 부족할 때 computer use로 넘어가는 편이 안전하다.

Codex plugins는 MCP 서버와 같은 말인가?

같은 말이 아니다.

공식 Codex plugins 문서는 plugin이 skills, app integrations, MCP servers를 묶는 reusable workflow라고 설명한다.

즉 MCP server는 plugin 안에 들어갈 수 있는 구성요소 중 하나다.

운영 관점에서는 plugin을 도구 하나보다 작업 패키지로 보는 게 좋다.

Automations는 cron처럼 보면 되나?

일부는 맞지만 충분하지 않다.

Codex Automations는 recurring task를 background에서 실행하고 findings를 inbox에 남기는 흐름이다.

Git repo에서는 local project 또는 worktree에서 실행할 수 있다.

그래서 단순 시간표보다 어떤 환경에서, 어떤 권한으로, 결과를 어디에 남길지가 더 중요하다.

full access automation을 쓰면 안 되나?

절대 안 된다는 뜻은 아니다.

다만 공식 문서도 full access background automation은 elevated risk가 있다고 안내한다.

처음에는 read-only 또는 workspace-write로 시작하고, 필요한 command만 rules로 좁게 허용하는 편이 낫다.

특히 production 설정 변경, 결제, 계정 보안 같은 작업은 automation 후보에서 빼는 게 좋다.

memory는 켜두면 무조건 좋은가?

개인 생산성에는 도움이 될 수 있다.

반복 설명을 줄이고, 선호와 correction을 기억해 다음 작업을 빠르게 만들 수 있다.

하지만 팀 운영에서는 memory보다 repo 문서와 policy가 우선이다.

팀 표준이 개인 memory에만 있으면 재현성과 감사가 약해진다.

Codex app이 있으면 CLI나 IDE extension은 필요 없나?

그렇지 않다.

CLI는 terminal-native 작업과 script 중심 workflow에 강하다.

IDE extension은 코드 옆에서 diff와 맥락을 보는 데 편하다.

Codex app은 browser, terminal, 파일, computer use 같은 여러 표면을 한 workspace에서 다룰 때 강하다.

Cloud는 background coding task나 PR 흐름에 맞는다.

하나로 통일하기보다 task별 표면을 나누는 게 낫다.

관련 글

공식 출처