Codex를 '에이전트’로 쓰는 법 (코드 생성이 아니라 일을 맡기는 방법) — 바이브 코딩 시즌1 #2

🤖 바이브 코딩 시리즈 · 2편

← 1편: Vibe Loop 기초

Codex를 '에이전트'로 쓰는 법
코드 요청이 아닌, 일을 맡기는 방법

코드를 잘 짜는 사람이 이기는 시대는 끝났습니다.
일을 잘 나누는 사람이 Codex를 제대로 씁니다.

📅 2026년 5월 ⏱ 읽기 약 10분 🎯 Vibe Loop 경험자 · 레벨업 준비 완료

1편

"이거 되네?"
Vibe Loop 기초

▶ 2편 (현재)

"이건 사람 대신
일한다"

3편

한계 + 유지보수
진짜 개발로

📋 목차

1. 생각이 바뀌는 순간 — 충격 전환
2. 1편 이후 막히는 3가지 패턴
3. Codex 에이전트란 무엇인가
4. 에이전트 워크플로 구조 (핵심)
5. 실전 예시 — 멀티파일 SaaS 만들기
6. 실패 사례 + 해결 방법
7. 바로 쓰는 실전 프롬프트 템플릿
8. 실전 체크리스트
9. 핵심 요약
10. 자주 묻는 질문 (FAQ)

💡 생각이 바뀌는 순간

코드를 잘 짜는 사람이 Codex를 잘 쓴다

일을 잘 나누는 사람이 Codex를 잘 쓴다

📖 이런 경험, 있지 않으신가요?

1편에서 배운 대로 React UI를 만들었다.

잘 됐다. 그런데 API를 붙이려는 순간부터 무너지기 시작했다.

UI에서 보낸 데이터가 API에 안 넘어간다

콘솔에 CORS 에러가 터진다

어디서 문제인지, 프론트인지 백인지 모른다

결국 다시 처음부터 만들었다.
문제는 코드가 아니었다. 구조가 없었던 것이다.

이게 1편에서 2편으로 넘어오는 사람들이 공통적으로 겪는 벽입니다. Vibe Loop는 알겠는데, 기능이 두 개 이상 얽히는 순간 전부 무너집니다. 이제 그 벽을 넘습니다.

❌ 구조 없이 작업

3시간

기능 하나 만들고 디버깅, 처음부터 재시작

✅ 에이전트 방식

30분

역할 단위 설계 후 순서대로 위임

이 글의 핵심 메시지:
"코드를 요청하지 말고, 일을 맡겨라."

구조 없는 개발 3시간 vs Codex 에이전트 방식 30분 비교

⚠️ 1편 이후 막히는 3가지 패턴

1편을 보고 실제로 해봤다면 거의 모든 사람이 같은 벽을 만납니다. 이건 실력 문제가 아닙니다. 구조 문제입니다.

1

파일 하나에 모든 코드가 몰린다

App.js 하나에 로그인, 상태 관리, API 호출, UI가 전부 들어간다. 수정할수록 더 꼬이고, 어디를 건드려야 할지 모른다.

2

기능이 늘어날수록 디버깅 지옥

로그인 기능 추가하면 기존 코드가 깨진다. API 연결하면 상태 관리가 꼬인다. 구조 없이 쌓인 코드는 손댈 수 없게 된다.

3

매번 처음부터 다시 설명해야 한다

새 대화를 열 때마다 프로젝트 구조, 사용 기술, 제약 조건을 반복해서 설명한다. 이건 비효율이 아니라 구조 부재의 신호다.

문제는 코딩이 아니라, 구조다.

🤖 Codex 에이전트란 무엇인가

많은 사람들이 Codex를 '매우 똑똑한 자동완성'으로 씁니다. 그게 1편 수준입니다. 에이전트 방식은 다릅니다.

❌ 코드 생성기로 쓰는 방식

코드 조각 요청

결과 복사

직접 붙여넣기

오류 나면 다시 요청

✅ 에이전트로 쓰는 방식

작업 단위 정의

실행 위임 (파일 읽기·쓰기·실행)

결과 검증

다음 작업으로 연결

⚡ "그냥 ChatGPT랑 뭐가 달라요?" — 3가지 차이

이 질문이 나오는 건 당연합니다. Codex의 강점은 단순 코드 생성이 아니라, 여러 파일을 동시에 다루고, 작업 흐름을 유지하며, 이전 결과를 기반으로 수정할 수 있다는 점입니다.

📂

멀티파일 동시 처리

ChatGPT는 코드를 텍스트로 출력합니다. Codex는 실제 파일을 읽고, 여러 파일을 동시에 수정하고, 변경 내역을 git diff로 확인할 수 있습니다.

예: "Login.tsx와 api.ts를 함께 수정해서 연결해줘"

🔄

작업 흐름 유지 (AGENTS.md)

ChatGPT는 새 대화를 열면 모든 맥락이 초기화됩니다. Codex는 AGENTS.md를 통해 프로젝트 규칙을 세션마다 자동으로 불러옵니다.

예: 어제 정한 코딩 규칙을 오늘도 그대로 적용

▶️

코드 직접 실행 + 자동 수정

ChatGPT는 코드를 생성만 합니다. Codex는 샌드박스 환경에서 코드를 직접 실행하고, 실행 결과에 오류가 있으면 스스로 원인을 파악해 수정합니다.

예: 테스트 실행 → 실패 → 원인 분석 → 수정까지 자동

이 세 가지 차이가 "코드 생성기"와 "작업 수행 에이전트"를 가르는 기준입니다. 단순히 더 똑똑한 자동완성이 아니라, 개발 워크플로 전체를 처리하는 시스템입니다.

📄 AGENTS.md — Codex의 프로젝트 기억 장치

프로젝트 루트에 두면 Codex가 매 세션 시작 시 자동으로 읽습니다. 한 번 설정해두면 같은 맥락을 반복 설명할 필요가 없습니다.

AGENTS.md 예시

# 프로젝트 개요
이 프로젝트는 React(프론트) + Node.js API + PostgreSQL 구조입니다.

# 코딩 규칙
- TypeScript 필수, any 타입 금지
- CSS-in-JS 사용 안 함 (Tailwind만 사용)
- 함수형 컴포넌트만 사용

# 폴더 구조
/frontend  - React 앱
/backend   - Express API
/shared    - 공통 타입 정의

에이전트 = 작업을 이해하고 스스로 실행하는 단위
코드를 요청하지 말고, 일을 맡겨라

🧠 에이전트 워크플로 구조

Codex를 제대로 쓰는 사람들은 항상 같은 5단계 구조를 사용합니다. 이게 에이전트 방식의 기본 틀입니다.

Codex 에이전트 워크플로

01

작업 정의

→

02

실행 위임

→

03

결과 생성

→

04

검증

→

05

다음 연결

작업 단위의 확장 — 이 흐름을 스케일업하면

작업 단위

→

파일 단위

→

프로젝트 단위

→

서비스 단위

📌 Codex를 쓸 때 반드시 지켜야 할 3가지 규칙

규칙 1

한 번에 하나의 작업만 요청한다

두 가지를 한 번에 요청하면 Codex는 둘 다 어설프게 처리합니다. "UI 만들고 API도 연결해줘"는 금지. 반드시 분리하세요.

규칙 2

결과를 반드시 실행해본 뒤 다음 단계로 넘어간다

실행 확인 없이 다음 작업으로 넘어가면 나중에 어디서 문제가 생겼는지 찾을 수 없습니다. 각 단계마다 눈으로 확인이 필수입니다.

규칙 3

문제가 생기면 원인을 설명하지 말고 현상을 그대로 전달한다

"뭔가 API가 안 되는 것 같아"가 아니라 "콘솔에 이 에러가 뜨고, 버튼 클릭 시 네트워크 탭에서 404가 보임"이 올바른 전달입니다.

핵심은 작업 큐 개념입니다. 아침에 오늘 할 작업 3~5개를 미리 정의해두고, 순서대로 Codex에게 위임합니다. 각 작업이 완료될 때마다 검증 후 다음 작업으로 연결합니다.

📋 작업 큐 예시 — 오늘의 개발 작업

# 오전 작업 큐

✅ 1. 사용자 로그인 컴포넌트 UI 구현

✅ 2. 로그인 API 엔드포인트 연결

🔄 3. JWT 토큰 저장 및 갱신 로직

⏳ 4. 로그아웃 기능 + 상태 초기화

⏳ 5. 전체 인증 흐름 통합 테스트

이 방식으로 Codex를 쓰는 팀에서는 아침에 작업 큐를 설정한 뒤 코드 리뷰나 기획 미팅을 하는 동안 Codex가 병렬로 작업을 처리합니다. 돌아왔을 때 검토할 결과가 쌓여있는 구조입니다.

Codex 에이전트 워크플로 5단계 + 3가지 핵심 규칙

🏗 실전 예시 — 멀티파일 SaaS 4단계로 만들기

가장 흔한 실수부터 확인합니다. 그래야 올바른 방식이 명확해집니다.

❌ 이렇게 하면 망합니다

"전체 SaaS 만들어줘.
로그인, 대시보드, API,
DB까지 전부 포함해서."

결과: 길고 연결 안 된 코드 덩어리. 실행 불가. 디버깅 지옥.

✅ 이렇게 하면 됩니다

단계 1: UI 컴포넌트
단계 2: API 연결
단계 3: DB 구조
단계 4: 전체 통합

역할 단위로 나눠 순서대로. 각 단계마다 동작 확인 후 다음으로.

목표 프로젝트 구조

📂 SaaS 프로젝트 파일 트리

my-saas/

  frontend/

    src/components/Dashboard.tsx 1단계

    src/components/Login.tsx 1단계

    src/services/api.ts 2단계

  backend/

    routes/auth.ts 2단계

    models/user.ts 3단계

  shared/

    types/index.ts

  AGENTS.md 필수

4단계 실전 프롬프트 흐름

1

UI 컴포넌트 구현

frontend

React + TypeScript로 대시보드 UI를 만들어줘.
사용자 이름 표시, 로그아웃 버튼 포함.
Tailwind CSS 사용. 아직 API는 연결하지 마.

2

API 엔드포인트 연결

backend + frontend

1단계에서 만든 UI에 연결되는 인증 API를 만들어줘.
Node.js + Express, JWT 토큰 방식.
POST /auth/login, POST /auth/logout 엔드포인트 포함.

⚠️ 2단계 완료 후 — 이 상태가 정상입니다

UI는 잘 나오는데 로그인 버튼 클릭 시 아무 반응 없음

브라우저 콘솔: Network Error: Failed to fetch

프론트에서 보내는 API 주소와 백엔드 포트가 다름

✅ 이건 실패가 아닙니다. 연결 단계에서 반드시 나오는 과정입니다.

→ 그대로 복사해서 전달: "로그인 버튼 클릭 시 Network Error가 뜨고 콘솔에 Failed to fetch 에러가 있어. 백엔드는 3001 포트, 프론트는 3000 포트야. 수정해줘."

3

데이터 구조 설계

database

이 프로젝트에 필요한 PostgreSQL 스키마를 설계해줘.
users 테이블: id, email, password_hash, created_at.
Prisma ORM 사용. migration 파일도 생성.

4

전체 통합 + 동작 확인

통합

앞에서 만든 frontend, backend, DB를 연결해줘.
로그인 → JWT 발급 → 대시보드 진입 흐름이 동작해야 함.
연결 오류가 있으면 원인과 수정 방법도 알려줘.

이 구조의 핵심은 역할 단위로 분리하고, 각 단계가 독립적으로 동작함을 확인한 뒤 연결하는 것입니다. 한 번에 전체를 만들려고 하지 않습니다.

멀티파일 SaaS 프로젝트 구조 — 단계별 파일 분리 트리

❌ 실패 사례 + 해결 방법

에이전트 방식에서도 실패 패턴은 있습니다. 이걸 미리 알아두면 대부분의 막힘을 피할 수 있습니다.

⚠️ 실패 패턴 1 — 전체를 한 번에 요청한다

요청: "전체 SaaS 만들어줘" → 300줄짜리 파일 하나 생성

결과: 연결 안 된 코드, import 오류 5개, 실행 불가

왜 틀렸나: AI는 큰 문제보다 작은 문제를 잘 푼다

✅ 해결

→UI / API / DB / 통합을 별도 요청으로 분리

→각 단계가 독립 실행 가능한지 확인 후 다음 단계

⚠️ 실패 패턴 2 — 맥락 없이 새 대화를 시작한다

새 대화: "어제 만든 로그인 기능에 이어서 대시보드 추가해줘"

결과: 어떤 로그인인지 모름 → 기존과 다른 구조로 새로 생성

왜 틀렸나: Codex는 세션 간 기억이 없다 (Memory 기능 제외)

✅ 해결

→AGENTS.md에 프로젝트 구조와 현재 진행 상태를 기록

→새 대화 시작 시 "AGENTS.md를 읽고 대시보드 컴포넌트 추가해줘"

⚠️ 실패 패턴 3 — 서브에이전트를 모든 상황에 쓴다

상황: 단순 순차 작업(A 후 B)을 서브에이전트 병렬로 실행

결과: 토큰 소비 2~3배, 작업 간 충돌, 오히려 느림

왜 틀렸나: 서브에이전트는 병렬화 가능한 작업에만 유효

✅ 해결

→순차 의존성이 있으면 단일 에이전트 순서대로

→서브에이전트는 "30개 컴포넌트 동시 리뷰" 같은 명확한 병렬 작업에만

AI는 큰 문제보다 작은 문제를 잘 푼다.
나누는 능력이 곧 Codex를 잘 쓰는 능력이다.

🧰 바로 쓰는 실전 프롬프트 템플릿

아래 템플릿은 복사해서 바로 사용할 수 있습니다. 상황에 맞게 [ ] 안의 내용만 채우세요.

1

기능 구현 템플릿

가장 자주 쓰임

[목표]
[기능 이름]을 구현해줘.

[조건]
- 기술 스택: [React / Node.js / etc.]
- 제약: [기존 파일과 충돌하지 않게, 타입 명시 등]
- 참고: AGENTS.md의 프로젝트 규칙 준수

[출력]
- 코드 + 각 부분 간단한 설명
- 연결이 필요한 파일 목록

2

디버깅 요청 템플릿

오류 발생 시

아래 오류가 발생했어.

[오류 메시지 전체 붙여넣기]

발생 상황: [어떤 동작을 했을 때]
관련 파일: [파일명]

원인 분석하고, 해결 방법 3가지 제시해줘.
가장 안전한 방법부터 순서대로.

3

구조 설계 요청 템플릿

새 기능 시작 전

[기능 이름] 기능을 추가하려고 해.
현재 프로젝트 구조: [간단히 설명 또는 AGENTS.md 참조]

이 기능을 위한 파일 구조와
각 파일의 역할을 먼저 설계해줘.
코드는 아직 생성하지 말고, 구조만.

4

작업 큐 설정 템플릿

하루 시작 시

오늘 이 작업들을 순서대로 진행할 거야:

1. [작업 1 — 예: 로그인 UI 완성]
2. [작업 2 — 예: API 연결]
3. [작업 3 — 예: 에러 핸들링 추가]

먼저 1번부터 시작해줘.
각 작업 완료 후 내가 확인하면 다음 단계로 진행.

✅ 실전 체크리스트

에이전트 방식으로 전환하기 전, 이 항목들을 확인하세요.

• AGENTS.md를 만들고 프로젝트 구조, 기술 스택, 코딩 규칙을 적었는가
• 오늘 할 작업을 3~5개 단위로 쪼개 작업 큐를 만들었는가
• 각 작업은 독립적으로 동작 가능한 단위인가 (다른 작업에 직접 의존하지 않는가)
• UI / API / DB 구조를 별도 요청으로 분리할 계획인가
• 각 단계 완료 후 실행 확인 없이 다음 단계로 넘어가지 않겠다고 결심했는가
• 새 대화 시작 시 AGENTS.md를 참조하도록 첫 요청에 명시하는가

📌 핵심 요약

• 🔑코드를 잘 짜는 것보다 일을 잘 나누는 능력이 Codex 활용의 핵심입니다.
• 🤖에이전트 방식 = 작업 정의 → 실행 위임 → 검증 → 다음 연결의 반복 구조입니다.
• 📄AGENTS.md로 프로젝트 규칙을 기억시키면 매 대화마다 반복 설명이 필요 없습니다.
• 🏗멀티파일 프로젝트는 UI → API → DB → 통합 순으로 역할 단위 분리가 필수입니다.
• 📋작업 큐 방식으로 아침에 3~5개 작업을 설계하고 순서대로 위임하면 생산성이 폭발합니다.
• ⚠️전체를 한 번에 요청하는 건 가장 흔한 실수 — AI는 큰 문제보다 작은 문제를 잘 풉니다.

❓ 자주 묻는 질문 (FAQ)

Codex 에이전트와 일반 Codex 사용의 차이는 무엇인가요?

일반 사용은 '코드를 요청하고 결과를 받는' 방식입니다. 에이전트 방식은 '작업을 정의하고 위임하고 결과를 검증하는' 반복 구조입니다. 핵심 차이는 Codex가 단일 코드 조각이 아니라 파일 읽기·쓰기·실행·수정을 자율적으로 수행한다는 점입니다. 2026년 Codex는 서브에이전트, AGENTS.md 지시 파일, 스킬 시스템을 통해 역할을 분리한 팀처럼 작동합니다.

AGENTS.md는 어떻게 만들고 어디에 두나요?

AGENTS.md는 프로젝트 루트 디렉터리에 두는 마크다운 파일입니다. Codex는 세션 시작 시마다 이 파일을 자동으로 읽고 프로젝트 구조, 코딩 규칙, 금지 사항을 파악합니다. '이 프로젝트는 TypeScript + React이고, CSS-in-JS는 사용하지 않는다' 같은 규칙을 한 번 적어두면 매 요청마다 같은 맥락을 반복 설명할 필요가 없습니다. 팀 레포에 체크인하면 신규 팀원 온보딩에도 활용됩니다.

멀티파일 프로젝트를 Codex에게 맡길 때 가장 흔한 실수는?

가장 흔한 실수는 '전체 시스템을 한 번에 요청하는 것'입니다. '전체 SaaS 만들어줘' 같은 요청은 길고 연결이 안 된 코드 덩어리를 만듭니다. 올바른 방식은 UI → API → 데이터 구조 → 연결 순서로 역할 단위로 분리해 단계별로 요청하는 것입니다. 각 단계마다 동작을 확인하고 다음 단계로 넘어가야 디버깅 지옥을 피할 수 있습니다.

Codex 서브에이전트는 어떤 상황에서 쓰면 좋나요?

서브에이전트는 병렬 처리가 필요한 복잡한 작업에 유효합니다. 예를 들어 여러 컴포넌트를 동시에 리뷰하거나, 다수의 파일에 같은 리팩터를 적용해야 할 때 사용합니다. 2026년 Codex는 서브에이전트에게 독립된 Git worktree를 할당해 병렬 작업 간 충돌을 방지합니다. 단, 서브에이전트는 토큰 소비가 많으므로 단순 순차 작업보다는 명확히 병렬화 가능한 경우에만 사용하는 것이 효율적입니다.

← 이전 편

✓ 바이브 코딩 시작 — Codex로 AI와 함께 개발하는 법

바이브 코딩 1편 — Vibe Loop 기초

▶ 다음 편 예고

✓ 바이브 코딩의 한계 — 유지보수, 진짜 개발로 넘어가는 법

Codex가 못하는 것, 그리고 그 다음 단계

오늘 딱 3가지만 해보세요 🤖

UI / API / 연결… 아직 부담스럽다면 더 작게 시작해도 됩니다.
아래 순서대로 하면 오늘 안에 "에이전트 방식"을 체감할 수 있습니다.

1

버튼 하나 만들기 — "클릭하면 텍스트가 바뀌는 버튼 만들어줘. React."

2

클릭 이벤트 추가 — "클릭할 때마다 카운트가 1씩 올라가게 수정해줘."

3

콘솔 출력 연결 — "클릭 시 현재 카운트 값을 콘솔에도 출력해줘."

이 3개가 바로 에이전트 워크플로의 최소 단위입니다.
완벽할 필요 없어요. 3단계를 완주하면, 그게 이미 에이전트 방식입니다.

📌 관련 태그

#바이브코딩2편 #Codex에이전트 #멀티파일프로젝트 #AI작업위임 #CodexWorkflow #AGENTS.md #에이전트코딩 #바이브코딩실전 #SaaS개발Codex #프롬프트템플릿