이 영상에서 단테는 Codex의 Code Mode를 서비스 조사, 리뷰 분석, 주간 보고서, GitHub PR 확인이라는 네 가지 실제 실행 사례로 설명합니다. 여러 도구를 조회하고 긴 결과를 정리하는 일을 Codex에 맡기고 싶은 분, 그리고 에이전트가 낸 숫자를 어떻게 검증해야 하는지 궁금한 분께 맞는 내용입니다.
Code Mode란 무엇이고 언제 생겼나
여기서 말하는 Code Mode는 사용자가 코드를 직접 쓰는 모드가 아니라, Codex가 여러 도구를 JavaScript로 연결해 실행하는 방식입니다. Plan/Code 모드 전환과는 다른 개념입니다.
공식 릴리스 기준으로는 2026년 3월 11일(UTC) 공개된 CLI 0.114.0에 실험 기능으로 처음 포함됐습니다. 처음 들어간 버전이라는 뜻이지, 그때부터 모든 사용자에게 기본으로 켜졌다는 뜻은 아닙니다. 모든 환경에 적용되는 최소 GPT 버전도 공식 자료에서 확인되지 않았고, 실제 도구 모드는 모델의 설정 정보와 Codex 기능 설정에 따라 결정됩니다. 영상의 실습은 CLI 0.146.0에서 실행까지 확인했습니다.
왜 쓸까요? 도구를 하나 부르고, 결과를 모델이 읽고, 다음 도구를 부르면 중간 왕복이 계속 생깁니다. Code Mode는 여러 조회와 계산을 코드로 묶고 필요한 결과만 모델에 돌려줄 수 있습니다. 독립적인 조회를 함께 처리할 수 있다면 대기 시간을 줄일 여지도 있습니다. 다만 모든 작업이 무조건 빨라지는 것은 아니며, 이번 영상은 속도나 비용 절감률을 측정한 비교 실험이 아닙니다.
실행 기록을 읽는 법
실행 기록은 Codex에게 무엇을 요청했고, 어떤 도구를 불렀고, 어떤 결과가 돌아왔는지 남은 작업 이력입니다. 영상의 화면은 이 기록을 보기 쉽게 모은 강의용 웹 뷰어이며 공식 Codex 앱 UI가 아닙니다.
단테는 본 실습 전에 작은 사전 확인을 했습니다. 현재 작업 폴더와 올해 연도를 조회하는 두 작업을 Code Mode로 묶어 달라고 요청했고, Codex가 만든 코드는 두 작업을 묶는 부분, 각각 조회하는 두 줄, 결과를 보여 주는 마지막 줄로 이뤄져 있었습니다. 반환값에는 실제 폴더 경로와 2026이 나왔습니다. "준비됐다"는 답변만 믿지 않고 실행 코드와 반환값을 대조한 것입니다. 설정에 켜짐이라고 적혀 있는 것과 실제로 사용된 것은 다르므로 실행 코드까지 확인해야 한다는 점도 강조했습니다.
네 가지 실행 사례
사례 1: 여러 서비스 조사
설문 도구 세 개의 공식 도움말을 읽고 시작 안내와 응답 관리 안내를 비교해 달라고 요청했습니다. 조건은 세 가지였습니다. 독립적인 조회는 묶을 것, 같은 항목으로 비교할 것, 확인하지 못한 내용은 미확인으로 남길 것입니다.
실행 코드는 서비스 목록을 돌며 도움말을 가져오고 Promise.allSettled로 결과를 모았습니다. 하나가 실패해도 나머지를 볼 수 있는 구조입니다. 결과에서 Tally와 Google Forms는 안내를 확인했지만 Typeform은 접근이 거부됐습니다. 여기서 Typeform에 그 기능이 없다고 결론 내리면 안 됩니다. 이번 방법으로 페이지를 읽지 못했을 뿐입니다. Code Mode는 실패를 없애 주는 기능이 아니라 성공과 실패를 구분해 다음 판단으로 넘기게 해 줍니다. 가격처럼 확인하지 못한 항목은 채우지 않았습니다.
사례 2: 리뷰 분석
6, 7, 8월 리뷰 파일(강의용 합성 데이터)을 사용했고, 8월 파일에는 7월 리뷰 일부가 다시 들어 있었습니다. 프롬프트에는 ID가 같으면 같은 리뷰로 보고, 1점과 2점을 낮은 평점으로 보며, 원문 전체 대신 숫자와 대표 리뷰만 달라고 명시했습니다.
도구는 세 파일을 읽어 데이터를 돌려주는 역할만 하고, 중복 제거와 집계는 Codex가 생성한 코드가 처리했습니다. 결과는 입력 125행, 고유 리뷰 120개, 중복 5개였고, 월별 고유 리뷰는 각 40개, 낮은 평점은 25개, 26개, 25개로 모두 76개였습니다. 단테는 원본 파일을 따로 집계해 이 숫자를 대조했습니다. 주의할 점도 있습니다. 주제 힌트는 합성 자료에 미리 넣은 정답 라벨이므로, 이것을 셌다고 AI가 의미를 정확히 분류했다고 말하면 안 됩니다. 계산 검증과 의미 분류 검증은 다른 일입니다.
사례 3: 회의록과 업무 목록 연결
회의에서 하기로 한 일이 업무 도구에서 빠지는 문제를 다뤘습니다. 두 자료는 제목이 조금씩 달라도 같은 업무 ID를 갖고 있어, ID를 기준으로 연결했습니다. 이름이 비슷하다는 이유만으로 같은 일로 판단하지 않습니다. 기준일은 2026년 9월 13일로 명시했고, 완료, 기한 경과, 담당자 미정, 기한 미정, 회의록에만 있는 일로 나누되 없는 값은 만들지 말라고 했습니다.
결과에서 소개 페이지 수정은 완료, 설문 초안은 기한 경과로 나왔고, 담당자나 기한이 없는 일, 회의록에만 있는 일도 따로 나왔습니다. 이번에는 강의용 파일을 돌려주는 도구로 원리를 재현한 것이며 실제 업무 관리 서비스에 접속한 것은 아닙니다. 실제로 적용하려면 연결과 읽기 권한을 준비하고, 보고서 작성과 외부 전송은 구분해서 요청하라고 안내했습니다.
사례 4: GitHub PR 확인
공개 저장소의 열린 PR 다섯 개를 읽고 초안 여부, 변경 파일 수, 리뷰 기록을 모았습니다. 목록을 받아야 상세 조회에 넣을 번호를 알 수 있으므로, 순서가 필요한 부분과 독립적인 부분을 나눠 상세 조회만 묶어 실행했습니다. CI 검사는 이번 도구가 가져오지 않아 모두 "미조회"로 표시됐습니다. 미조회는 통과도 실패도 아니고, 리뷰 기록이 있다는 것도 승인 완료를 뜻하지 않습니다. 또 Code Mode 실행 한 번 안에서도 실제 API 요청은 여러 번 일어나므로, 실행 한 번을 API 한 번으로 세면 안 됩니다.
내 업무에 적용하기
단테가 제안한 요청 작성 순서는 이렇습니다. 입력과 결과물을 먼저 적고, 공통 ID와 필요한 필드를 정하고, 독립적인 조회는 묶고, 전체 원본 대신 필요한 결과만 남기도록 요청합니다. 마지막에는 실패와 미확인을 구분하고 원문 링크나 ID를 보존하라고 적습니다. 반대로 자료 하나를 깊이 읽거나, 매번 새로운 판단이 필요하거나, 사람의 승인을 오래 기다리는 작업은 Code Mode로 묶지 않는 편이 낫습니다.
정리
- Code Mode는 Codex가 여러 도구 호출과 계산을 JavaScript로 묶어 실행하고 필요한 결과만 돌려받는 방식입니다.
- 설정 표시가 아니라 실행 코드와 반환값을 대조해 실제로 쓰였는지 확인해야 합니다.
- 조회 실패, 미확인, 미조회를 성공이나 "기능 없음"으로 바꾸지 않는 것이 결과의 신뢰도를 지킵니다.
- 중복 제거 기준, 낮은 평점 기준, 기준일처럼 계산 규칙을 프롬프트에 명시하면 코드가 처리할 부분이 분명해집니다.
- 계산 검증과 의미 분류 검증은 별개이며, 실행 한 번이 API 요청 한 번은 아닙니다.