Codex 사용 후기

요즘에는 Codex, Claude Code 를 무조건 사용한다는데, 금액도 금액이고 후기만 보고 결제했다가 마음에 안들 수도 있어서 사용은 굳이 안했었다. 그리고 코드를 짜는 재미가 있어서 사용하지 않은 이유도 있다.

우연히 GPT Plus 한 달 무료 체험 기회가 생겨서 등록하고 Codex를 사용해 보았다.

소감은 "가히 충격적!" 이라고 말할 수 있겠다.

지시 내용만 던져주면 원하는 서비스를 바로 만들어 내는걸 보고,

'아, 코드를 짜는 재미때문에 더 이상 흐름을 거부할 수는 없겠구나.', '코드를 다 만들어 주는데, 내가 여기서 어떤 역할을 해야 하나?' 라는 생각이 스쳐 지나갔다.

물론, 한 번의 지시로 머리 속에서 그린 서비스가 바로 만들어 지지는 않지만, 지시문을 나름 구체적인 레이아웃을 잡아서 던져주면 내가 생각한 것과 유사하게 만들어 낸다.

단점으로는:

코드에서 발생한 오류를 해결하라는 지시문을 던져도, 제자리 걸음을 꽤 많이 시도한다. (오류 해결을 계속 못함)
코드 짜는 재미를 다 가져간다. → 이 부분은 이제 나의 역할(프론트엔드 엔지니어로서)을 다시 재정립해야 할 듯 하다.
백엔드 테이블 설계를 연결하는 과정을 제공하는지 모르겠다? → 현재 Cursor에서 Codex를 사용하고 있는데, supabase를 활용한 풀스택 서비스 개발 시 백엔드 설계는 따로 진행하고 일일히 supabase에 추가해줘야 한다.

장점은 그 외 모두:

웹에서 사용하면 Codex가 알아서 작업 단위로 PR 검토도 해준다.
5시간 한도가 엄청 넉넉하다.
지시를 던져주고 개인 공부를 하고 올 수 있다. → 나 같은 경우 책을 읽거나, 영어 스피킹 공부를 한다.
"기술 문서 작성"을 가이드라인으로 던져주면, 기능 구현/수정/삭제마다 문서도 함께 최신화 해준다. → 서비스 전반의 동작 파이프라인을 이해하기 좋다.

추가로, 백엔드 설계를 어떻게 해야 할지 모르겠다면, Codex가 아닌 GPT에게 설계를 요청하는 게 더 나은 응답을 만드는 것 같다. (*개인적인 생각)

그래서 현재 나는:

서비스의 큰 틀을 구상한다. (목적/역할/제공 기능 등)
기능 별로 나눈 후, 목적과 역할을 바탕으로 어떤 컬럼이 필요할 지 구조화한다. (*draft)
구조화한 내용을 바탕으로, 구체적인 설계 구조를 GPT에게 요청한다.
GPT의 응답을 바탕으로 Codex에게 설계를 요청한다.

위 이터레이션(2 to 4)를 통해 서비스를 만들어가고 있다.

그리고 Codex는 AGENTS.md 라는 파일을 통해서 일종의 가이드라인을 지시할 수 있는데,
아래는 관련해서 어떻게 구조화 해야 하는지 찾아보고 내가 만든 가이드라인이다. 완성된 버전은 아니라 앞으로도 계속 결과물을 확인하고 고쳐나가야 한다.

# AGENTS.md

## Overview
You are an expert in Next.js 16 (App Router).
This project follows a modular, test-driven, and maintainable architecture.
The primary goals are clarity, scalability, and reliability.

Key principles:
- Focus on low coupling and high cohesion.
- Maintain clear separation between data logic and UI presentation.
- Write test code before implementation for any feature considered critical or core to the system.
- Prefer simple, explicit state management and consistent naming conventions across the codebase.
- All functions considered as core must include JSDoc-style documentation comments.
- Follow the Server-first principle and aim for minimal JavaScript bundles.
- Must respond with Korean
- After implementing a feature, write documentation in Markdown format explaining how the feature works.
- Additionally, when a feature is modified or removed, update or delete the corresponding documentation accordingly.

## Structure Design Phase
- Create the following project folder structure:
```
/app               → Next.js routes  
/components        → Reusable components  
/components/ui     → Installed shadcn UI components  
/services          → Codex API and data logic  
/lib               → Utilities and shared logic  
/config            → Configuration files (e.g., Supabase)  
/tests             → Jest test files  
/types             → TypeScript interfaces
```
- Document the purpose of each folder in a README.md file.
- Define entity models (Book, Emotion, Keyword, Achievement) and document them using JSON Schema.

## Testing Phase
- Every major component and service must have a corresponding test file.
- Perform only unit and integration tests, and write tests only where necessary.

## Implementation Phase
- Maintain low coupling and high cohesion across all code.
- Organize code by feature.
- Prefer useState and useReducer for state management.
- For complex state logic, extend with Zustand only when there’s a clear rationale.
- Prefix all custom hooks with use.
- Use kebab-case for all file names.
- Use PascalCase for component and page names.

## Styling & UI Rules
- Use TailwindCSS utility classes for rapid UI development.
- Split major sections into separate components.
- Follow the design system provided by shadcn/ui.
- If design changes are necessary, provide a clear justification for each modification.

## Conventions
- Use TypeScript strict mode; avoid any unless explicitly justified.
- Follow Conventional Commits (feat:, fix:, etc.).
- Never commit .env; include a .env.example instead.
- SEO is important — prefer SSR-based rendering.
- Keep data fetching and UI rendering cohesive within the same Server Component.
- Do not use React Query or other client-side state management libraries.

## PR Guidance

Title: <type>: summary
Body: Describe the problem, approach, tests, risks, and rollback plan.

## Safety
- Do not perform real network calls in tests — use mocks instead.
- Never write outside the repository root.
- Avoid destructive commands unless explicitly requested.

요약

Software Engineering Agent 를 사용하면 서비스를 금방 만들 수 있다.
이에 반비례하여 나의 기존 역할(코드 작성)은 상당 부분 줄어든다.
엔지니어로서 역할을 재정립해야 한다.

# AGENTS.md ## Overview You are an expert in Next.js 16 (App Router). This project follows a modular, test-driven, and maintainable architecture. The primary goals are clarity, scalability, and reliability. Key principles: - Focus on low coupling and high cohesion. - Maintain clear separation between data logic and UI presentation. - Write test code before implementation for any feature considered critical or core to the system. - Prefer simple, explicit state management and consistent naming conventions across the codebase. - All functions considered as core must include JSDoc-style documentation comments. - Follow the Server-first principle and aim for minimal JavaScript bundles. - Must respond with Korean - After implementing a feature, write documentation in Markdown format explaining how the feature works. - Additionally, when a feature is modified or removed, update or delete the corresponding documentation accordingly. ## Structure Design Phase - Create the following project folder structure: ``` /app → Next.js routes /components → Reusable components /components/ui → Installed shadcn UI components /services → Codex API and data logic /lib → Utilities and shared logic /config → Configuration files (e.g., Supabase) /tests → Jest test files /types → TypeScript interfaces ``` - Document the purpose of each folder in a README.md file. - Define entity models (Book, Emotion, Keyword, Achievement) and document them using JSON Schema. ## Testing Phase - Every major component and service must have a corresponding test file. - Perform only unit and integration tests, and write tests only where necessary. ## Implementation Phase - Maintain low coupling and high cohesion across all code. - Organize code by feature. - Prefer useState and useReducer for state management. - For complex state logic, extend with Zustand only when there’s a clear rationale. - Prefix all custom hooks with use. - Use kebab-case for all file names. - Use PascalCase for component and page names. ## Styling & UI Rules - Use TailwindCSS utility classes for rapid UI development. - Split major sections into separate components. - Follow the design system provided by shadcn/ui. - If design changes are necessary, provide a clear justification for each modification. ## Conventions - Use TypeScript strict mode; avoid any unless explicitly justified. - Follow Conventional Commits (feat:, fix:, etc.). - Never commit .env; include a .env.example instead. - SEO is important — prefer SSR-based rendering. - Keep data fetching and UI rendering cohesive within the same Server Component. - Do not use React Query or other client-side state management libraries. ## PR Guidance Title: <type>: summary Body: Describe the problem, approach, tests, risks, and rollback plan. ## Safety - Do not perform real network calls in tests — use mocks instead. - Never write outside the repository root. - Avoid destructive commands unless explicitly requested.