Codex로 갈아탈까 고민하는 팀이라면, 병목이 UI인지 검토인지부터

에이전틱 코딩 도구를 하나 더 들이거나 갈아타려는 팀이 먼저 물어야 할 건 기능 표가 아니에요. 지금 우리 팀에서 에이전트가 만든 결과물이 머지되기까지 가장 오래 걸리는 구간이 어디냐는 거예요. 작업을 시키는 데 오래 걸리면 도구 문제고, 시킨 결과를 검토하는 데 오래 걸리면 도구를 바꿔도 안 풀려요. 채널팀이 8월 14일 사내 데브 세션에 OpenAI의 정재원 AI Deployment Manager와 이재원 Applied AI Engineer를 초빙해 들은 Codex 활용법 정리를 읽으면서, 저는 이 질문을 계속 옆에 두고 읽었어요. 만든 회사가 직접 하는 설명이라 해상도는 높은데, 그만큼 판매자의 세션이기도 하니까요.

세션이 파는 것과 그 안에서 건질 것

세션의 뼈대는 이래요. 개발자의 AI 코딩 경험은 코드 자동 완성에서 페어 프로그래밍을 거쳐 에이전틱 프로그래밍으로 왔고, 사람이 개입하는 지점이 타이핑 매 순간에서 함수 구현 레벨로, 다시 작업 단위로 올라왔다는 것. 그래서 에이전틱에서는 작업을 위임하고, 관찰하고, 개입하고, 검토한다는 것. 여기까지는 어느 벤더가 말해도 같아요. 그다음이 판매 지점이에요. 단일 위임 단위에서는 CLI와 IDE가 효율적이지만 그 이상을 통합한 작업에서는 병목이 되고, Codex 앱은 skills, worktree, 예약 작업 같은 확장된 워크플로를 구조화해 준다는 것.

저는 이 프레이밍의 절반만 받아들여요. 여러 작업을 백그라운드에서 동시에 돌리고 worktree와 diff와 브라우저를 한 화면에서 보는 건 분명 편해요. 하지만 워크스페이스를 다섯 개 띄우면 검토할 결과물도 다섯 개예요. 세션이 말하는 병목은 위임과 관찰 구간이고, 제가 아는 팀들의 병목은 검토 구간이에요. 사람이 diff를 읽고 테스트 결과와 실제 화면을 확인하고 승인하는 시간은 앱이 줄여주지 않아요. 그러니 앱을 바꾸기 전에 우리 병목이 어느 구간인지부터 재야 합니다.

그래도 세션에서 건질 게 세 가지 있어요. 도구 이름을 지워도 남는 것들이에요.

위임에는 완료 기준이 있어야 한다

세션이 제시한 효과적인 위임의 네 기준은 목표, 참고할 코드와 자료, 제약조건, 완료 기준이에요. 목표는 원하는 결과와 변경 대상과 중요한 이유, 참고 자료는 관련 파일과 오류와 기존 패턴, 제약은 해야 할 일과 금지 사항과 팀 규칙, 완료 기준은 통과해야 할 테스트와 실행할 명령과 확인할 동작. 지시에 공백이 있으면 에이전트가 사용자의 의도를 스스로 예상해서 채우고, 그게 기대와 어긋난다는 게 세션의 설명이고요.

네 개 중에 제가 제일 무겁게 보는 건 완료 기준이에요. 목표와 제약은 다들 쓰는데, "이 테스트가 통과하면 끝"이라는 완료 기준을 적는 팀은 드물어요. 완료 기준이 없으면 에이전트는 자기가 끝났다고 생각하는 지점에서 멈추고, 그 지점이 사람의 기준과 다를 때 재시도와 되돌리기가 생겨요. 재시도가 줄어든다는 세션의 주장은 정확히 여기서 나옵니다. 그리고 이건 Codex에 한정된 원칙이 아니에요. 어느 에이전트든 같아요. 반복해서 쓰는 위임 내용은 프로젝트 규칙으로 올리라는 조언까지 포함해서요.

스킬은 검증이 끝난 반복 절차만

Codex에서 정확도를 높이는 장치는 AGENTS.md, Skills, Plugin, MCP예요. AGENTS.md는 에이전트가 작업 전에 읽는 규칙 파일이고, /init으로 초안을 뽑은 뒤 팀이 암묵적으로 지키는 규칙과 검증 방법을 얹으라는 안내예요. Skills는 PR 작성, 이슈 분석, 테스트 실행 같은 절차를 재사용하는 단위고, Plugin과 MCP는 Jira나 Linear 같은 외부 시스템을 연결합니다.

이 대목에서 판매자가 한 말 중에 제일 값진 문장이 있어요. 팀에 공유되는 skill은 검증이 끝나고 반복해서 발생하는 절차만 만드는 편이 안전하다는 것. 도구를 파는 쪽에서 "기능을 아껴 쓰라"고 말한 셈인데, 저는 이게 세션 전체에서 가장 정직한 대목이라고 봐요. 스킬 카탈로그를 수십 개 만들어 놓고 아무도 안 쓰는 팀, 검증 안 된 절차를 스킬로 굳혀서 잘못된 방식이 반복되는 팀을 막는 유일한 규칙이거든요. 스킬의 수가 아니라 스킬 하나가 몇 번 반복됐고 그 결과가 검증됐는지가 기준이에요.

녹화로 가르치는 건 두 조건에서만

말로 지시하기 어려운 작업은 record and replay로 가르쳐요. 사람이 하는 과정을 녹화하면 Codex가 그걸 이해해서 다시 수행할 수 있는 skill을 쓰고, 그 skill을 팀에 공유하면 다른 사람도 같은 작업을 시킬 수 있어요. 세션이 든 사례는 유튜브 영상 업로드, 세일즈포스 CRM 데이터 작업, 이슈 티켓과 문서 관리. 프롬프트로 풀기 어렵고 API나 MCP로도 어려운 고수준 워크플로에 쓰라는 거예요.

후기를 쓴 채널팀 엔지니어도 이 기능이 제일 기억에 남는다고 했는데, 저는 세션이 붙인 단서 쪽에 눈이 가요. 적합한 작업의 조건은 둘이에요. 절차가 고정되어 있을 것, 결과를 검증할 수 있을 것. 그리고 화면 구조가 바뀌면 기록된 절차와 어긋나니 실행 결과는 사람이 점검하라는 것. 이건 RPA가 오래 겪어온 함정과 같은 자리예요. 화면을 보고 클릭하는 자동화는 화면이 바뀌는 날 조용히 틀린 일을 하고, 그걸 잡는 건 결국 사람의 검토예요. 녹화가 쉬워졌다고 그 함정이 사라진 건 아니에요.

갈아타기는 마지막 문제다

세션은 "나는 이미 클로드 코드를 쓰고 있는데 새로 세팅해야 하냐"는 질문을 예상하고 두 가지 길을 준비해뒀어요. 프로젝트 안에 .claude 같은 설정 폴더가 있으면 Codex 설정으로 import하는 것, 그리고 클로드 코드 안에서 플러그인으로 Codex를 호출해 익숙한 UI를 유지한 채 결과를 비교하는 것. 전환 마찰을 없애는 장치이고, 벤더 입장에서 당연히 준비할 물건이에요. 작은 실제 과제로 두 시스템의 결과물과 검증 과정을 비교해서 결정하라는 조언은 좋은데, 비교 기준이 빠져 있어요.

기준은 하나 넣으면 돼요. 같은 과제에서 사람이 검토에 쓴 시간. 결과물의 품질이 비슷하면 검토 시간이 짧은 쪽이 이기는 거고, 검토 시간이 같으면 앱을 바꿔서 얻는 건 편의뿐이에요.

그러니 조건을 나눠 말할게요. 위임에 완료 기준이 없는 팀, 스킬이 열 개 넘게 쌓였는데 반복되는 건 두세 개뿐인 팀, 화면 자동화를 사람 점검 없이 돌리는 팀은 도구를 바꾸기 전에 이 세 원칙부터 챙기면 돼요. 그건 지금 쓰는 도구에서 오늘 할 수 있어요. 그리고 병목이 정말 위임과 관찰 구간에 있는 팀, 동시에 굴리는 작업이 늘어서 한 화면에 모아 볼 필요가 생긴 팀이라면 그때 세션이 안내한 대로 작은 과제 하나로 비교해 보세요. 검토 시간을 재면서요.