코딩 미경험자로서, 자신의 앱을 개발하기 위해 Codex를 사용하기 시작했습니다.

ChatGPT나 GPT-5.5와 같은 모델은 사용자의 요구사항을 상당히 정확하게 파악해 줍니다. 언어화나 보충 설명도 뛰어나기 때문에, 생각을 정리하거나 하고 싶은 일을 구체화할 때 매우 편리합니다.

반면, Codex와 같은 에이전트 (agent)의 움직임을 완전히 이해하지 못하는 초보자로서 불안함도 있고, 베테랑처럼 효율적으로 에이전트를 활용하지 못하고 있다는 자각도 있습니다.

같은 요금을 지불한 이상, 이득을 보는 기분으로 사용하고 싶으니까요.

이를 위해 기사나 공식 문서를 조사해 보았더니,

• 먼저 AGENTS.md를 작성할 것
• 권한 (Permissions)을 너무 넓게 설정하지 말 것
• 중요 파일을 먼저 결정할 것
• 태스크 (Task)는 구체적으로 작성할 것
• 완성 후 생성 과정과 차이점(diff)을 확인할 것

가장 먼저 할 일은 Codex에 프로젝트의 규칙을 전달하는 것입니다.

Codex에서는 AGENTS.md라는 파일에 작업 규칙을 작성할 수 있습니다. 이는 Codex에 대한 프로젝트 전용 설명서와 같은 것입니다.

예를 들어, 처음에는 이 정도면 충분하다고 생각합니다.

# AGENTS.md
## Rules
- 작업 전: 변경 예정 파일 설명
...

여기서 막히기 쉬운 점은, "AGENTS.md를 작성하세요"라는 말을 들어도 애초에 어떻게 만드는지 모른다는 것입니다.

방법은 두 가지가 있습니다.

첫 번째는, 직접 프로젝트 폴더에 AGENTS.md라는 Markdown 파일을 만드는 방법입니다.

my-app/
├─ src/
├─ package.json
...

여러 작업에서 공통 규칙을 사용하고 싶다면, 더 상위 폴더에 두는 것도 고려할 수 있습니다. 다만 처음에는 전체 폴더가 아니라, 현재 작업 중인 프로젝트 단위로 만드는 것이 관리하기 쉽습니다.

두 번째는, Codex에게 만들어 달라고 하는 방법입니다.

예:

AGENTS.md 초안 작성. 아직 파일은 생성하지 마.
포함할 규칙:
- 작업 전: 변경 예정 파일 설명
...

다음으로 파일 생성까지 요청할 경우:

이 내용으로 프로젝트 루트에 AGENTS.md를 생성해 줘.

다음으로 중요한 것은, 처음부터 권한 (Permissions)을 너무 넓게 설정하지 않는 것입니다.

Codex의 권한 화면에서는 크게 다음 세 가지를 확인합니다.

• 기본 권한 (Default permissions)
• 자동 리뷰 (Auto-review)
• 풀 액세스 (Full access)

기본 권한에서는 Codex가 워크스페이스 내의 파일을 읽고 편집할 수 있습니다. 필요에 따라 추가 액세스를 요청할 수 있습니다.

자동 리뷰 (Auto-review)를 켜면, 추가 액세스 요청을 Codex 측의 다른 리뷰어 에이전트가 리뷰합니다. 단, 자동 리뷰는 실수할 수도 있습니다.

초보자 시절에는 풀 액세스를 꺼둔 상태로 시작하는 것이 좋다고 생각합니다.

풀 액세스를 켜면 승인 없이 컴퓨터 상의 파일을 편집하거나, 네트워크를 사용하는 명령어를 실행할 수 있게 됩니다. 편리하지만 데이터 손실, 정보 유출, 예기치 않은 동작의 리스크가 커집니다.

건드리지 않았으면 하는 파일은 미리 결정해 둡니다.

예를 들어, 저는 이 정도는 미리 지키고 싶습니다.

.env, .env.local: API 키나 접속 정보 등의 비밀 정보가 들어 있을 수 있음

• 데이터베이스 migration: 테이블 구조나 데이터 변경에 영향을 미침
• 배포 스크립트: 운영 환경 반영 절차에 영향을 미침
• 운영 환경 관련 설정: 공개 환경의 동작이나 보안에 영향을 미침
• 지시하지 않은 의존성 (Dependency): 버전 충돌이나 취약점의 원인이 될 수 있음

경계가 명확할수록 의도하지 않은 변경은 줄어듭니다.

Codex에게 맡기기 전에 "여기는 건드리지 마"라고 적어두는 것. 이것은 초보자도 바로 할 수 있는 안전 대책입니다.

태스크는 가능한 한 구체적으로 적는 것이 안정적입니다.

모호한 표현:

이 코드를 적당히 고쳐줘

프롬프트 (Prompt)는 다음과 같은 형태로 만들면 보기 좋습니다.

대상:
목적:
실행:
...

예:

대상: Markdown 기사 초안
목적: 제목과 내용 정리
실행:
...

실제 조작에서는 프롬프트 작성 방식 때문에 여러 번 실패했습니다.

이 실패담에는 배울 점이 아주 많기 때문에, 향후 기사에서 집중적으로 다루려고 생각 중입니다.

Codex가 작업을 마쳤다면, 그대로 받아들이지 않는 것이 좋아 보입니다.

먼저 확인해야 할 것은 다음 4가지입니다.

• 어떤 파일을 변경했는가
• 변경량이 너무 많지는 않은가
• 로직 (Logic)이 맞는가
• 테스트나 확인 과정을 통과했는가

초보자일수록 "완성되었습니다"라는 말에 안심하기 쉽지만, 살펴봐야 할 곳은 결과 그 자체보다 차이점 (Diff)과 확인 결과라고 생각했습니다.

참고로, 만약 앱을 개발하고 있다면 Codex가 태스크 (Task)에 임하는 과정도 꼭 지켜보시길 권합니다.

초보자 나름대로 개발 플로우 (Flow)나 확인 흐름을 배우는 재료가 될 수 있어 추천합니다.

처음에 필요한 것은 고도의 테크닉 (Technique)보다 작업 범위의 정리였습니다.

Codex에게 무엇을 맡길지, 어디는 건드리지 않을지, 작업 후에 무엇을 확인할지. 이 3가지를 먼저 결정하는 것만으로도 훨씬 다루기 쉬워집니다.

단, Codex의 출력물은 최종 결과만으로 판단하지 않는 것이 좋습니다.

최소한 변경된 파일, 차이점 (Diff), 실행 로그 (Log), 테스트 결과를 확인하세요. 특히 .env, 마이그레이션 (Migration), 배포 (Deploy) 관련 변경이 포함되어 있다면, 내용을 이해할 때까지 그대로 진행하지 않는 것이 안전합니다.

최근 Codex용 하드웨어에 대한 이야기도 나오고 있네요.

저는 지금 스마트폰을 사용하여 원격 코딩 (Remote Coding)을 하고 있습니다.

스마트폰으로 Codex를 사용한 소감, 실제로 발생하는 에러 (Error), 그리고 전용 디바이스 (Device)와 스마트폰 앱을 병용했을 때 어떤 효과가 있을지에 대해 정리해 보고자 합니다.

다음 회차에는 크레딧 (Credit) 절약에 관해 공유할 예정입니다.

괜찮으시다면 계속해서 지켜봐 주세요.

• OpenAI Help: Using Codex with your ChatGPT plan
• OpenAI Developers: Codex docs
• OpenAI Developers: Custom instructions with AGENTS.md
• OpenAI Developers: Agent approvals & security
• OpenAI Developers: Auto-review
• OpenAI Blog: Introducing Codex
• The Verge: OpenAI is teasing new hardware... for Codex