코덱스 툴 사용법 12: 매번 다시 설명하지 않는 설정 스택 만들기 | DAKER 커뮤니티
코덱스 툴 사용법 12: 매번 다시 설명하지 않는 설정 스택 만들기
Codex를 오래 쓰다 보면 같은 말을 반복하게 됩니다. “테스트 먼저 봐”, “새 패키지는 추가하지 마”, “이 저장소는 pnpm이야”, “완료 전에 타입체크를 돌려”. 이 반복을 프롬프트에 계속 쓰는 것은 바이브코딩 속도를 갉아먹습니다.
이번 편의 목표는 단순합니다. 한 번 잘 통했던 지시를 다음 세션에서도 자동으로 작동하게 만드는 것입니다. Codex 공식 문서가 설명하는 AGENTS.md, .codex/config.toml, skills, MCP, automations를 한 덩어리의 설정 스택으로 정리해 보겠습니다.
한 줄 요약
Codex에게 매번 설명하는 문장이 있다면, 그 문장은 프롬프트가 아니라 더 오래 사는 표면으로 내려보낼 후보입니다.
프롬프트는 작업 지시, AGENTS.md는 작업 방식
프롬프트에는 오늘 끝낼 일을 씁니다. 반대로 AGENTS.md에는 이 저장소에서 항상 지켜야 할 작업 방식을 씁니다. OpenAI Codex 문서는 AGENTS.md를 저장소 안내, 실행 명령, 검증 기준, 리뷰 기대치를 담는 durable guidance로 설명합니다.
예를 들어 아래 문장은 프롬프트에 남기는 편이 좋습니다.
> 오늘은 결제 페이지의 쿠폰 입력 버그만 고쳐줘.
하지만 아래 문장은 AGENTS.md로 옮기는 편이 좋습니다.
> 결제 관련 파일을 수정하면 npm run test:payments와 npm run typecheck를 실행하고, 실패 로그를 요약한다.
차이는 수명입니다. 오늘만 필요한 것은 프롬프트, 다음 작업에도 필요한 것은 AGENTS.md입니다.
어디에 무엇을 둘지 정하는 기준
넣을 내용 | 적합한 위치 | 판단 기준 |
|---|---|---|
오늘의 목표, 특정 버그, 특정 파일 | 프롬프트 | 이번 작업이 끝나면 사라져도 됨 |
저장소 구조, 테스트 명령, 리뷰 규칙 |
| 이 repo의 모든 작업에 반복 적용 |
모델, reasoning, sandbox, 승인 정책 |
| Codex 실행 기본값을 바꿈 |
반복 워크플로우, 검사 절차, 문서 생성법 | skill | 이름을 붙여 재사용하고 싶음 |
GitHub, Slack, Drive, DB 같은 외부 맥락 | MCP/connector | Codex가 live context를 읽어야 함 |
반복 점검, 정기 리포트, follow-up | automation | 시간표에 따라 다시 실행되어야 함 |
이 표의 핵심은 “멋있어 보이는 도구를 쓰자”가 아닙니다. 지시의 수명과 범위에 맞는 가장 작은 표면을 고르는 것입니다.
설정 스택 의사결정 흐름
이 흐름대로 정리하면 프롬프트가 짧아집니다. 짧아진 프롬프트는 대충 쓰라는 뜻이 아니라, 이미 합의된 규칙을 다시 설명하지 않아도 된다는 뜻입니다.
AGENTS.md에 넣기 좋은 문장
좋은 AGENTS.md는 길이가 아니라 구체성으로 판단합니다. 아래처럼 “언제, 무엇을, 어떻게 검증할지”가 들어가야 합니다.
## Verification
- TypeScript 파일을 수정하면 `npm run typecheck`를 실행한다.
- UI 컴포넌트를 수정하면 관련 스토리나 화면을 Playwright로 확인한다.
- 실행하지 못한 검증은 마지막 보고서의 `Not tested`에 적는다.반대로 이런 문장은 효과가 약합니다.
- 좋은 코드를 작성한다.
- 꼼꼼하게 확인한다.
- 필요하면 테스트한다.Codex는 추상적인 의지를 실행할 수 없습니다. 실행 가능한 명령, 금지 사항, 완료 기준을 줘야 합니다.
config.toml은 성격이 아니라 기본값이다
.codex/config.toml은 Codex의 실행 기본값을 다루는 표면입니다. 공식 문서는 사용자 config와 프로젝트 config를 구분하고, 프로젝트 config는 신뢰된 프로젝트에서만 로드된다고 설명합니다.
예를 들어 저장소에서 항상 쓰는 MCP나 기본 reasoning 수준, sandbox 설정은 config 후보입니다. 하지만 “이번 버그는 결제 모듈만 봐” 같은 일회성 지시는 config가 아니라 프롬프트에 둬야 합니다.
실무 기준은 이렇습니다.
매번 같은 실행 환경을 원하면 config
매번 같은 작업 절차를 원하면
AGENTS.md매번 같은 전문 워크플로우를 원하면 skill
매번 같은 외부 데이터를 읽어야 하면 MCP
skill은 긴 프롬프트를 제품화하는 방법
Codex 공식 문서에서 skill은 SKILL.md와 선택적 scripts/assets/references로 구성된 재사용 워크플로우입니다. 반복되는 프롬프트가 길어지고, 예시 파일이나 검증 스크립트까지 필요해지면 skill로 분리할 타이밍입니다.
예를 들어 “릴리즈 노트 작성”을 매번 이렇게 설명하고 있다면:
지난 태그 이후 커밋을 읽고, 사용자 영향 중심으로 정리하고,
breaking change와 migration note를 분리하고,
마지막에 검증하지 못한 항목을 알려줘.이것은 skill 후보입니다. release-notes/SKILL.md로 만들면 다음부터는 $release-notes처럼 호출하거나, Codex가 작업 설명과 skill description을 보고 자동으로 고를 수 있습니다.
오늘 바로 적용하는 20분 정리법
최근 Codex에게 세 번 이상 반복한 문장을 적는다.
그 문장이 이번 작업용인지, repo 규칙인지, 실행 기본값인지 분류한다.
repo 규칙이면
AGENTS.md에 한 문장으로 추가한다.실행 기본값이면
.codex/config.toml후보로 둔다.절차가 길고 반복된다면 skill 후보로 이름을 붙인다.
마지막으로 새 세션에서 “현재 지시를 요약해줘”라고 물어 로드 여부를 확인한다.
마무리
Codex를 잘 쓰는 팀은 프롬프트를 길게 쓰는 팀이 아닙니다. 한 번 배운 작업 방식을 다음 실행 환경으로 옮기는 팀입니다.
오늘 할 일은 작습니다. 다음 Codex 작업이 끝난 뒤, 마지막 보고서에서 반복하고 싶은 규칙 하나만 골라 AGENTS.md에 추가해 보세요. 그 한 줄이 다음 바이브코딩 세션의 기본 속도가 됩니다.
참고: OpenAI Codex manual의 Best practices, AGENTS.md guidance, Customization, Configuration, Agent Skills 섹션을 기준으로 작성했습니다. Codex는 프롬프트, AGENTS.md, config, skills, MCP, automations를 서로 다른 수명과 범위의 지시 표면으로 다룹니다.