쉬운 용어집

용어는 외우라고 있는 것이 아니라 작업을 덜 헷갈리게 하려고 있습니다. 이 페이지에서는 먼저 쉬운 말로 풀고, 필요할 때 원문을 함께 둡니다.

용어 선택 원칙

이 플레이북은 공식 제품명과 현장에서 통용되는 작업어를 억지로 번역하지 않습니다. 대신 처음 만나는 화면에서는 원문 옆에 쉬운 한국어 풀이를 붙입니다.

경우	이 사이트의 선택
OpenAI 공식 기능명	CLI, IDE extension, MCP, Skill, Plugin처럼 공식명을 유지하고 쉬운 설명을 붙입니다.
개발자에게 익숙하지만 비개발자에게 낯선 말	diff (변경점), handoff (인수인계), patch loop (패치 루프)처럼 통용 용어를 먼저 두고 뜻을 붙입니다.
팀 운영에서 꼭 필요한 보안 용어	sandbox, approval, secret은 원문을 유지하되 각각 기술 울타리, 사람 승인, 비밀값으로 풀어 씁니다.
사이트 자체 프레임워크	작업 요청서, 패치 루프, 안전선처럼 실제 작업에서 쓰는 말과 쉬운 풀이가 함께 보이게 합니다.

실행 표면

쉽게 말해 Codex가 일하는 장소입니다. 처음 읽는 사람에게는 “실행 위치”라고 이해하면 됩니다.

• CLI: 내 터미널에서 일합니다. 로컬 파일을 읽고, 수정하고, 테스트 명령을 돌리기 좋습니다.
• IDE extension: 내가 편집기에서 보고 있는 파일, 선택 영역, @file 맥락을 살려 수정하기 좋습니다.
• Codex app: 여러 thread (작업 대화), 리뷰, worktree (작업 책상), automation (자동화), 브라우저 작업을 한곳에서 다루기 좋습니다.
• Web/Cloud: 긴 작업을 클라우드에서 맡기고, GitHub와 연결해 PR 후보까지 만들기 좋습니다.

안전선과 승인

쉽게 말해 Codex에게 어디까지 허용할지 정하는 규칙판입니다.

예를 들어 “이 파일만 고쳐라”, “패키지 설치는 묻고 해라”, “비밀정보는 읽지 마라”, “테스트 삭제는 금지” 같은 기준입니다.

sandbox는 Codex가 기술적으로 닿을 수 있는 울타리이고, approval은 그 울타리를 넘을 때 사람에게 묻게 하는 규칙입니다.

신뢰 경계

쉽게 말해 무엇을 지시로 믿고, 무엇을 그냥 참고 자료로 읽을지 나누는 선입니다.

웹페이지, issue, log, PR 설명, MCP 응답 안에는 Codex를 속이는 명령형 문장이 들어갈 수 있습니다. 그런 문장은 작업 대상 데이터로 보고, 저장소 규칙과 사용자 요청과 승인 정책을 더 우선해야 합니다.

작업 요청서

쉽게 말해 Codex에게 넘기는 일감 설명서입니다. 목표, 수정 범위, 금지할 행동, 확인할 증거를 한 번에 담습니다.

예전에는 “작업 패킷”이라고도 불렀지만, 뜻은 네트워크 용어가 아니라 “작은 작업 요청을 한 묶음으로 정리한다”에 가깝습니다. 나쁜 요청은 “이거 알아서 고쳐줘”입니다. 좋은 작업 요청서는 “이 파일 범위에서 이 문제를 고치고, 테스트 결과와 diff (변경점)를 남겨줘”에 가깝습니다.

패치 루프

쉽게 말해 고치고 확인하고 넘기는 한 바퀴입니다. patch는 코드나 문서의 수정 묶음을 뜻합니다.

보통 범위 정하기 → diff (변경점) 만들기 → 테스트/빌드 확인 → review note (리뷰 메모) → handoff (인수인계) 순서로 닫습니다.

goal (목표)

쉽게 말해 긴 작업을 끝까지 끌고 가기 위한 목표판입니다.

한 번에 끝나지 않는 리서치, 개선, 검증 루프를 돌릴 때 목표, 완료 기준, 남은 위험을 계속 붙잡는 데 씁니다. 좋은 goal은 “무엇을 만들지”뿐 아니라 “어떤 증거가 있으면 끝났다고 볼지”까지 포함합니다.

goal mode (목표 모드)

쉽게 말해 Codex가 하나의 목표를 여러 turn 동안 계속 붙잡고 가는 실행 방식입니다.

Codex app, IDE extension, CLI에서 긴 objective를 다룰 때 씁니다. 시작할 때 목표, 완료 기준, 중간 보고 조건, 멈출 조건을 함께 주어야 “계속 진행”이 안전한 작업 루프가 됩니다.

diff (변경점)

쉽게 말해 무엇이 바뀌었는지 사람이 검토할 수 있는 차이입니다.

Codex가 “수정했습니다”라고 말해도 변경점이 너무 넓거나 엉뚱한 파일이 섞이면 믿기 어렵습니다. 그래서 완료 보고에는 바뀐 파일, 바꾼 이유, 검증 결과가 함께 있어야 합니다.

증거

쉽게 말해 사람이 결과를 믿을 수 있게 해 주는 흔적입니다.

대표 증거는 diff (변경점), 테스트 결과, 빌드 로그, PR 리뷰 메모입니다. “잘 됐습니다”라는 말만으로는 증거가 아닙니다.

handoff (인수인계)

쉽게 말해 다음 사람이나 다음 세션에게 넘기는 메모입니다.

무엇을 바꿨는지, 무엇을 확인했는지, 아직 불안한 점은 무엇인지 적습니다.

AGENTS.md

쉽게 말해 이 저장소에서 Codex가 먼저 읽는 작업 규칙입니다.

프로젝트 소개보다 명령어, 금지 행동, 승인 필요한 행동, 테스트 기준을 먼저 적는 것이 좋습니다.

worktree (작업 책상)

쉽게 말해 같은 저장소를 여러 작업 책상으로 나누는 Git 기능입니다.

서로 다른 작업을 동시에 맡길 때 같은 파일을 덮어쓰지 않게 도와줍니다.

Skill (반복 절차)

쉽게 말해 반복 작업 설명서입니다.

매번 같은 방식으로 해야 하는 작업이 있다면 SKILL.md에 절차, 참고 자료, 필요하면 스크립트를 묶어 둡니다.

Plugin (기능 묶음)

쉽게 말해 설치 가능한 기능 묶음입니다.

Plugin은 Skill, 외부 앱 연결, MCP server를 함께 담을 수 있습니다. 반복 작업 설명만 필요하면 Skill로 충분하고, 다른 사람이 설치해서 쓰게 만들거나 외부 앱 연결까지 묶고 싶으면 Plugin을 봅니다.

Plugin sharing은 팀이 reusable plugin bundle (재사용 가능한 기능 묶음)을 배포하는 흐름입니다. 편리하지만 앱 연결, MCP server, lifecycle hook까지 함께 움직일 수 있으므로 설치 권한, 비활성화 방법, 회수 기준을 같이 남겨야 합니다.

Sites

쉽게 말해 Codex가 만든 웹사이트나 앱을 OpenAI 호스팅으로 저장하고 배포하는 표면입니다.

Sites는 Codex app의 plugin으로 다룹니다. 모든 배포 URL은 production deployment로 보아야 하므로, 먼저 save version (검토 후보)을 만들고 build 결과, 접근 범위, runtime secret (실행 시 비밀값)을 확인한 뒤 승인된 version만 배포합니다.

MCP

쉽게 말해 Codex가 다른 도구나 문서를 안전하게 찾아갈 수 있게 해 주는 연결 규격입니다.

브라우저, Figma, 사내 문서, 외부 개발 도구처럼 Codex 기본 환경 밖의 도구를 붙일 때 씁니다. 붙이기 전에 어떤 데이터가 오가는지와 승인선을 확인해야 합니다.

non-interactive mode (비대화형 실행)

쉽게 말해 대화창을 열지 않고 Codex를 스크립트나 CI에서 실행하는 방식입니다.

codex exec처럼 한 번 실행하고 결과를 파일, JSONL, PR 댓글, CI 요약으로 남기는 작업에 씁니다. 자동 실행일수록 sandbox (기술 울타리), approval (사람 승인), secret (비밀값), 재검증 명령을 더 좁게 정해야 합니다.

Codex용 CLI

쉽게 말해 Codex가 반복 검증을 정확히 실행할 수 있게 만든 명령 도구입니다.

예를 들어 링크 검사, redirect 동기화, 콘텐츠 금칙어 검사처럼 사람이 읽으면 놓치기 쉬운 기준을 명령 하나로 실패하게 만듭니다. 좋은 CLI는 인자, 종료 코드, 예시 출력이 명확해야 Codex도 CI도 같은 기준으로 사용할 수 있습니다.

codex doctor

쉽게 말해 Codex CLI 상태 점검표입니다.

Codex CLI가 이상하게 동작할 때 runtime (실행 환경), 인증, 터미널, 네트워크, 설정, 로컬 상태 같은 기본 상태를 먼저 확인하는 진단 명령입니다. 결과를 외부에 공유하기 전에는 로컬 경로, 사용자 이름, 내부 주소, secret (비밀값) 단서가 들어 있지 않은지 확인해야 합니다.

permission profile (권한 프로필)

쉽게 말해 Codex가 어떤 권한으로 움직일지 묶어 둔 실행 규칙입니다.

파일 쓰기, 네트워크, 명령 실행, 외부 연결 같은 기준을 프로필로 나눌 수 있습니다. 팀에서는 넓은 권한을 기본값으로 두기보다 작업 종류별 프로필을 만들고, 상속 관계와 되돌리는 방법을 문서화해야 합니다.

Appshots

쉽게 말해 다른 앱 화면을 Codex에게 맥락으로 넘기는 방법입니다.

macOS Codex app에서 앞에 있는 앱 창의 스크린샷과 텍스트 맥락을 보낼 수 있습니다. 화면은 강력한 입력이지만 비밀정보, 고객정보, 내부 도구 화면이 섞일 수 있으므로 보내기 전에 노출 범위를 확인해야 합니다.

remote-control (원격 제어)

쉽게 말해 다른 기기나 프로세스에서 연결된 컴퓨터의 Codex를 제어하는 명령 흐름입니다.

codex remote-control은 준비 상태, machine status, 명시적인 start/stop 경계를 남겨야 합니다. 실제 권한은 지시를 보내는 기기가 아니라 연결된 host 기준입니다.

remote computer use (원격 컴퓨터 사용)

쉽게 말해 연결된 컴퓨터의 데스크톱 앱을 원격으로 계속 쓰게 하는 방식입니다.

잠긴 Mac에서도 이어질 수 있는 흐름은 편리하지만, 신뢰된 computer-use turn, 짧은 승인, 화면 보호, 재잠금 같은 보호 장치를 전제로 봅니다. 로그인된 브라우저나 사내 도구에 접근할 수 있다면 별도 승인선이 필요합니다.

eval (평가)

쉽게 말해 품질이 좋아졌는지 반복해서 비교하는 작은 시험지입니다.

AI 기능이나 문서 품질처럼 단순 테스트만으로 보기 어려운 영역에서 샘플 입력, 기대 기준, 실패 요약을 둡니다. eval은 사람 리뷰를 없애는 장치가 아니라 리뷰어가 같은 기준으로 판단하게 돕는 장치입니다.

Codex GitHub Action

쉽게 말해 GitHub Actions workflow 안에서 Codex를 실행하는 방법입니다.

CI 실패 자동 분류, PR 리뷰 보조, 릴리스 메모 작성처럼 반복 작업에 쓸 수 있습니다. 다만 workflow 권한, secret (비밀값), PR 생성 권한을 사람 리뷰 범위에 포함해야 합니다.

remote connection (원격 연결)

쉽게 말해 다른 기기에서 연결된 컴퓨터의 Codex를 조종하는 방식입니다.

휴대폰에서 지시하더라도 실제 파일, 명령, 로그인된 웹사이트, Plugin, MCP, 브라우저 권한은 연결된 컴퓨터(host) 기준입니다. 그래서 host 이름, 접근 권한, 회수 절차를 남겨야 합니다.

Memories와 Chronicle

쉽게 말해 Codex가 나중에 다시 참고할 수 있는 개인 기억 층입니다.

Memories는 반복 맥락과 선호를 줄이는 데 도움을 줍니다. Chronicle은 화면 맥락으로 기억을 만들 수 있으므로 민감 화면이나 회의 앞에서는 꺼야 합니다. 팀 규칙은 Memories가 아니라 AGENTS.md나 저장소 문서에 둡니다.

auto-review (자동 리뷰)

쉽게 말해 사람에게 묻는 승인 요청을 별도 reviewer agent (리뷰 에이전트)가 먼저 위험 평가하는 방식입니다.

자동 검토가 켜져도 sandbox (기술 울타리) 안에서 허용된 작업과 승인 필요한 작업은 구분됩니다. 거절, 타임아웃, high-risk (높은 위험) 판단을 사람이 어떻게 볼지 정해야 합니다.

review note (리뷰 메모)

쉽게 말해 리뷰어가 바로 판단할 수 있게 남기는 짧은 변경 설명입니다.

어떤 파일을 왜 바꿨는지, 어떤 테스트를 돌렸는지, 어떤 위험이 남았는지 적습니다.