Deep Setup Guide
Codex 하네스를 설계합니다
이 페이지는 짧은 인문서가 아니라, 다른 사람이 그대로 따라 해서 설정을 복구할 수 있는 운영 문서입니다. 서비스 도메인 세부 구현은 빼고, 메모리·설정·skills·subagents·rules·hooks·MCP 같은 하네스 레이어만 깊게 다룹니다.
현재 확인 기준으로는 starter 복사 + 프롬프트 붙여넣기 순서가 가장 현실적입니다
Claude Code 쪽은 `revfactory/harness`처럼 하네스 자체를 생성하는 검증된 플러그인이 확인됩니다. 반면 Codex 쪽은 이번 검토 범위에서 그와 동급으로 검증된 하네스 생성 플러그인은 확인하지 못했습니다. 그래서 Codex는 지금 단계에서 설치형 생성 플러그인보다, tracked starter files를 먼저 복사하고 그 다음 프롬프트로 보강하는 방식 이 더 정확합니다.
Step 1
starter 파일 먼저 복사
아래 명령을 복사해서 실행하면 최소 Codex 하네스 표면이 먼저 생깁니다.
bash scripts/setup-codex-harness.sh /path/to/your-projectStep 2
CLI에 프롬프트 붙여넣기
starter가 생긴 뒤에는 아래 프롬프트를 그대로 붙여넣어 프로젝트 주제에 맞게 보강을 요청합니다.
이 프로젝트 주제에 맞춰서 Codex 하네스를 구성해줘.
현재 있는 AGENTS.md, .codex/, .agents/skills/ 를 기준으로
이 프로젝트에 꼭 필요한 rules, hooks, skills, subagents 를 보강해줘.
과장 없이 최소한의 구조부터 맞추고, 변경 후 검증 명령까지 정리해줘.현재 공식 Codex 기준 문서
이 가이드는 2026년 4월 기준 공개 문서를 기준으로 정리했습니다. “예전 블로그에서 보던 Codex”가 아니라, 현재 공식 문서의 설정 표면과 모델 문서에 맞춰 읽으시면 됩니다.
이 저장소에서 함께 보는 기획 문서
좋은 하네스는 설정 파일만으로 유지되지 않습니다. 목표 문서, 실행계획, UI 구조, 작업 분할 기준이 같이 있어야 Codex가 “무엇을 왜 이렇게 세팅해야 하는가”를 제대로 이해합니다.
2026 AIOps/MLOps 플랫폼 기술기획
역할 분리, 납품 전략, 라이선스 검토, 학습 이력·승인·배포 화면, 멀티테넌트 전략까지 묶어 보는 상위 전략 문서입니다.
AIOps/MLOps 포털 UI 정보구조
좌측 사이드바형 포털 IA, 메뉴 구조, 화면별 컴포넌트 매핑을 정리한 문서입니다.
AIOps/MLOps 플랫폼 개발 실행계획
전략 문서를 실제 구현 순서로 풀어낸 실행 문서로, 단계별 산출물과 완료 기준을 포함합니다.
반자동 개발 작업 분할
랄프 루프에 맡길 반복 구현과 사람 확인이 필요한 승인·운영 영역을 분리한 기준 문서입니다.
회사 UI 컴포넌트 가이드
Next.js, Tailwind, 공통 레이아웃·테이블·모달·차트 패턴과 디자인 토큰을 정리한 UI 기준 문서입니다.
하네스는 어떤 파일로 나뉘어야 하나요
좋은 Codex 하네스는 한 파일에 몰아넣지 않습니다. 프로젝트 메모리, 런타임 설정, 재사용 워크플로, 역할 분리, 안전 규칙, 자동 훅을 각각 독립된 표면으로 나눠야 나중에 유지보수가 됩니다.
| 기능 | 권장 표면 | 의도 |
|---|---|---|
| 프로젝트 메모리 | AGENTS.md | 세션 시작 전 자동으로 읽히는 저장소 기본 규칙 |
| 런타임 설정 | .codex/config.toml | 모델, sandbox, approval, profile, MCP, subagent 등록 |
| Skills | .codex/skills/ 또는 기존 호환 .agents/skills/ | 반복되는 워크플로를 문서화해서 재사용 |
| Subagents | .codex/agents/*.toml | 리뷰·검증·문서 확인처럼 좁은 역할 분리 |
| Rules | .codex/rules/*.rules | 파괴적 명령과 승인 경계를 선언형으로 정의 |
| Hooks | .codex/hooks.json + .codex/hooks/ | SessionStart, PreToolUse, PostToolUse 자동화 |
| 검증 명령 | README / AGENTS.md / scripts/ | 모든 표면이 같은 검증 흐름을 가리키도록 유지 |
project-root/
├── AGENTS.md
├── .codex/
│ ├── config.toml
│ ├── hooks.json
│ ├── hooks/
│ │ ├── session_start_context.py
│ │ ├── pre_bash_guard.py
│ │ └── post_kt_lint.sh
│ ├── rules/
│ │ └── default.rules
│ ├── agents/
│ │ ├── reviewer.toml
│ │ ├── gradle-verifier.toml
│ │ └── docs-researcher.toml
│ └── skills/
│ ├── gradle-codex/SKILL.md
│ ├── kotlin-review/SKILL.md
│ └── platform-safety/SKILL.md
├── scripts/
│ └── verify_codex_harness.sh
└── docs/
├── handoffs/
├── runbooks/
└── architecture/AGENTS.md 는 작업 계약서처럼 씁니다
AGENTS.md 는 “이 프로젝트에서 Codex가 어떻게 행동해야 하는가”를 고정하는 문서입니다. 도메인 설명을 길게 적기보다 검증 명령, 금지 명령, 디렉터리 구조, 완료 기준 같은 오래 살아남는 규칙만 두는 편이 낫습니다.
# AGENTS.md
- 이 저장소는 여러 계층이 함께 있는 애플리케이션/문서 저장소입니다.
- 작업 전 우선 문서: README, docs/handoffs/current-state.md, docs/architecture/module-map.md
- Gradle 검증은 항상 저장소 로컬 캐시를 사용합니다.
- Python 검증은 PYTHONPATH를 명시합니다.
- 운영 파괴 명령은 사용자가 명시적으로 요청한 경우만 승인 대상으로 다룹니다.
- 하네스 변경 후에는 scripts/verify_codex_harness.sh 를 우선 실행합니다.
- 반복 워크플로는 skills로 승격하고, 역할이 좁은 검토 작업만 subagent로 분리합니다.
## 표준 검증
- Kotlin: source ~/.zshrc >/dev/null 2>&1 && export GRADLE_USER_HOME="$PWD/.gradle-user" && ./gradlew ktlintCheck test --no-daemon
- Python: PYTHONPATH=python-mlops python3 -m unittest discover python-mlops/tests -v
- Frontend: cd frontend && npm run build
## 완료 기준
- 관련 변경의 빌드/린트/테스트 결과를 읽고 요약할 것
- 위험 명령, 배포 명령, 외부 쓰기 작업은 승인 경계를 지킬 것
- 최종 답변에 변경 요약, 검증 결과, 남은 리스크를 적을 것config.toml 이 런타임의 중심입니다
.codex/config.toml 은 모델, reasoning, sandbox, approval, profiles, MCP, subagent 등록을 한 번에 고정합니다. 특히 빌드 도구나 런타임 환경이 사용자 셸 프로필에 의존하는 저장소에서는 shell policy 와 profile 분리가 중요합니다.
# 기본 모델은 이해력과 설명 품질을 우선합니다.
model = "gpt-5.4"
model_reasoning_effort = "high"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
# 저장소 안에서는 쓰기 가능, 네트워크는 필요한 순간만 다룹니다.
[sandbox_workspace_write]
network_access = false
[features]
# hooks 는 아직 실험 기능이므로 명시적으로 켭니다.
codex_hooks = true
multi_agent = true
# 원격 MCP(HTTP/OAuth) 서버를 함께 쓸 때 필요할 수 있습니다.
experimental_use_rmcp_client = true
[profiles.review]
model = "gpt-5.4-mini"
sandbox_mode = "read-only"
approval_policy = "on-request"
[profiles.verify]
model = "gpt-5.4-mini"
model_reasoning_effort = "medium"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
[profiles.codex]
model = "gpt-5-codex"
model_reasoning_effort = "high"
[agents]
max_threads = 4
max_depth = 1
job_max_runtime_seconds = 1800
[agents.reviewer]
config_file = "agents/reviewer.toml"
[agents.gradle_verifier]
config_file = "agents/gradle-verifier.toml"
[agents.docs_researcher]
config_file = "agents/docs-researcher.toml"
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest", "--headless"]
[mcp_servers.context7]
url = "https://mcp.context7.com/mcp"
[mcp_servers.linear]
url = "https://mcp.linear.app/mcp"
[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
[mcp_servers.atlassian]
url = "https://mcp.atlassian.com/v1/mcp"Rules 와 Hooks 는 서로 대체재가 아닙니다
안전 장치는 한 층으로 끝내지 않는 편이 좋습니다. Rules 는 선언형 보호막이고, Hooks 는 동적 가드레일입니다. 일반적으로 두 층을 같이 써야 위험 명령 차단과 수정 직후 자동 검증이 동시에 살아납니다.
# 파괴적 명령은 금지합니다.
prefix_rule(["git", "reset", "--hard"], "forbidden")
prefix_rule(["rm", "-rf"], "forbidden")
prefix_rule(["terraform", "destroy"], "forbidden")
prefix_rule(["kubectl", "delete"], "forbidden")
prefix_rule(["helm", "uninstall"], "forbidden")
prefix_rule(["mlflow", "models", "delete"], "forbidden")
# 외부 반영이나 실행 환경 변이는 prompt 로 둡니다.
prefix_rule(["git", "push"], "prompt")
prefix_rule(["gh", "pr", "create"], "prompt")
prefix_rule(["kubectl", "apply"], "prompt")
prefix_rule(["helm", "upgrade"], "prompt")
prefix_rule(["brew", "install"], "prompt"){
"hooks": {
"SessionStart": [
{
"command": "/usr/bin/python3 $(git rev-parse --show-toplevel)/.codex/hooks/session_start_context.py"
}
],
"PreToolUse": [
{
"matcher": "Bash",
"command": "/usr/bin/python3 $(git rev-parse --show-toplevel)/.codex/hooks/pre_bash_guard.py"
}
],
"PostToolUse": [
{
"matcher": "Write|Edit|MultiEdit|ApplyPatch",
"command": "bash $(git rev-parse --show-toplevel)/.codex/hooks/post_kt_lint.sh"
}
]
}
}#!/usr/bin/env bash
set -euo pipefail
# Codex PostToolUse payload는 stdin JSON 입니다.
PAYLOAD="$(cat)"
ROOT="$(git rev-parse --show-toplevel)"
# Kotlin 파일이 아니면 아무 일도 하지 않습니다.
FILE_PATH="$(printf '%s' "$PAYLOAD" | jq -r '.tool_input.file_path // .tool_input.path // empty')"
if [[ -z "$FILE_PATH" || "$FILE_PATH" != *.kt ]]; then
exit 0
fi
# Gradle/JDK 셸 환경을 맞춘 뒤 저장소 로컬 캐시로 ktlint를 실행합니다.
source ~/.zshrc >/dev/null 2>&1 || true
export GRADLE_USER_HOME="$ROOT/.gradle-user"
cd "$ROOT"
./gradlew ktlintCheck --no-daemonSkills 와 Subagents 는 좁게 나눕니다
skill은 반복 워크플로, subagent는 좁은 역할입니다. 무엇이든 다 하는 agent 를 늘리는 것보다 reviewer, gradle_verifier, docs_researcher 같이 역할이 분명한 단위로 쪼개는 편이 유지보수와 병렬화 모두에 유리합니다.
name = "reviewer"
description = "Read-only reviewer for Kotlin and Gradle regressions."
model = "gpt-5.4-mini"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
변경사항을 읽기 전용으로 검토합니다.
행동 회귀, 누락 테스트, Gradle 오용, JDK 가정, 위험한 파일 수정 여부를 우선 확인합니다.
요약보다 findings 를 먼저 적습니다.
"""# Gradle Codex
이 스킬은 Gradle 명령을 안전하게 실행하기 위한 워크플로입니다.
## 규칙
- 항상 `source ~/.zshrc >/dev/null 2>&1` 를 먼저 고려합니다.
- 항상 `GRADLE_USER_HOME="$PWD/.gradle-user"` 를 저장소 안으로 고정합니다.
- 가능하면 `./gradlew` 와 `--no-daemon` 을 사용합니다.
- 결과를 요약할 때는 실패한 task, 에러 타입, 다음 수정 포인트를 함께 적습니다.
## 대표 명령
- 포맷 검사: `./gradlew ktlintCheck --no-daemon`
- 전체 검증: `./gradlew ktlintCheck test --no-daemon`
- 모듈 단위 검증: `./gradlew :module:test --no-daemon`모델 벤치마크와 현실적인 코딩 / 아키텍처 레벨
모델은 3개월 단위로 더 가벼워지고 더 빨라지고 있습니다. 중요한 것은 “점수가 높다”가 아니라 어떤 종류의 코딩과 설계 판단까지 신뢰할 수 있는가 입니다. 아래 표는 공식 모델 카드와 공식 발표 자료를 기준으로, 벤치마크 수치를 실무 능력으로 번역한 요약입니다.
| 모델 | 구간 | 공식 자료 요약 | 실무 해석 |
|---|---|---|---|
| GPT-5-Codex | 프런티어 폐쇄형 | 공식 모델 페이지 기준 agentic coding 최적화, 400K context, tool use / structured outputs / function calling 지원 | 저장소 전역 맥락 이해, 긴 리팩터, 다단계 디버깅, 아키텍처 트레이드오프 정리에 적합합니다. |
| GPT-5.4 mini | 프런티어 mini | 공식 문서 기준 coding, computer use, subagents 용 강한 mini 라인 | 메인 아키텍트보다는 reviewer, verifier, docs researcher 같은 좁은 역할에 가장 효율적입니다. |
| Gemma 4 31B | 강한 오픈 30B | LiveCodeBench v6 80.0, Codeforces 2150, MMLU-Pro 85.2, GPQA Diamond 84.3, context 256K | 중형 서비스 설계, 코드베이스 리팩터, 테스트 보강, 명확한 요구사항 기반의 아키텍처 분해까지 실전에 쓸 수 있는 수준입니다. |
| Gemma 4 26B A4B | 고효율 오픈 MoE | LiveCodeBench v6 77.1, Codeforces 1718, MMLU-Pro 82.6, active params 3.8B, context 256K | 속도와 비용을 아끼면서도 꽤 강한 코딩 에이전트 루프를 돌릴 수 있는 실용 구간입니다. |
| Qwen3-Coder-30B-A3B-Instruct | 강한 오픈 coder | 공식 카드 기준 30.5B total / 3.3B activated, 256K native context, agentic coding · browser-use 강점 | 명확한 계약 아래에서 기능 구현, 도구 호출, repo-scale 코드 탐색에 강하고, 사람 주도 아키텍처 아래서 생산성이 높습니다. |
| Qwen3-Coder-480B-A35B-Instruct | 최상위 오픈 coder | 공식 블로그 기준 SWE-Bench Verified open-source SOTA, Claude Sonnet 4 급 비교 언급, context 256K | 로컬 개인 장비 대상은 아니지만, 강한 오픈 모델로 장기 계획·도구 사용·실제 소프트웨어 엔지니어링 태스크까지 겨냥한 레벨입니다. |
Level 1
빠른 구현 보조
파일 단위 수정, 테스트 생성, 리팩터 제안, 반복 명령 자동화에 강합니다. 다만 아키텍처의 최종 결정권을 맡기면 흔들릴 수 있습니다.
Level 2
강한 구현자 / 공동 설계자
명확한 계약이 있을 때는 기능 구현, 모듈 경계 정리, API 분해, 테스트 루프까지 실전 투입이 가능합니다. 현재 강한 30B 오픈 모델이 이 구간에 들어옵니다.
Level 3
장기 계획형 아키텍트 보조
애매한 요구사항 정리, 장기 리팩터, 여러 하위 시스템 간 트레이드오프 설명까지 가능합니다. 그래도 운영 책임과 최종 아키텍처 서명은 여전히 사람이 가져가야 합니다.
vibe agentic coding 을 위한 외부 확장 Top 10
요즘 잘 되는 에이전트 코딩 환경은 모델 하나로 끝나지 않습니다. 최신 문서, 브라우저 실행, 디자인 맥락, 이슈 트래킹, 팀 대화, 운영 관측성까지 바깥 시스템을 붙여야 “그럴듯한 코드 생성”이 아니라 “실제로 일을 끝내는 흐름”으로 올라갑니다.
01 · 문서 grounding
Context7 MCP
버전 민감 라이브러리 문서를 최신 상태로 끌어와 API hallucination을 줄입니다.
원격 MCP: https://mcp.context7.com/mcp
공식 문서 ↗02 · 브라우저 자동화
Playwright MCP
UI 점검, 시나리오 확인, 접근성 snapshot 기반 검증에 가장 실용적입니다.
stdio: npx @playwright/mcp@latest --headless
공식 문서 ↗03 · skill형 브라우저 도구
Playwright CLI
토큰 효율이 중요한 코딩 에이전트 루프에서는 MCP보다 더 가볍게 브라우저를 다룰 수 있습니다.
npx playwright-cli 또는 editor-integrated skill
공식 문서 ↗04 · 저장소·PR·이슈
GitHub MCP
리포지토리, 이슈, PR, 리뷰 맥락을 에이전트 세션 안으로 직접 가져옵니다.
공식 GitHub MCP 서버 문서 기준으로 추가
공식 문서 ↗05 · 디자인→코드
Figma MCP
디자인 토큰, 컴포넌트, 선택 프레임 맥락을 코드 생성에 직접 연결합니다.
원격 MCP: https://mcp.figma.com/mcp
공식 문서 ↗06 · 이슈·프로젝트
Linear MCP
요구사항과 구현 상태를 같은 세션에서 읽고 갱신할 수 있어 작업 분할이 쉬워집니다.
원격 MCP: https://mcp.linear.app/mcp
공식 문서 ↗07 · 팀 대화 맥락
Slack MCP
메시지, 스레드, 캔버스를 직접 읽고 전송해 결정 맥락을 코드 작업에 붙일 수 있습니다.
원격 MCP: https://mcp.slack.com/mcp
공식 문서 ↗08 · Jira·Confluence
Atlassian Rovo MCP
기획서, 티켓, 위키를 에이전트 세션에 연결해 구현과 문서가 분리되지 않게 합니다.
원격 MCP: https://mcp.atlassian.com/v1/mcp
공식 문서 ↗09 · 관측성 / skill
Sentry AI Agent Monitoring
토큰 사용량, tool latency, agent 오류를 추적해 '잘 되는 척' 하는 상태를 줄입니다.
Sentry skill 또는 SDK instrumentation 추가
공식 문서 ↗10 · MCP 디버깅 / 확장
MCP Inspector + 공식 MCP Servers
직접 붙인 MCP 서버의 툴 스키마를 검증하고, Postgres·검색·파일 시스템 같은 범용 서버를 빠르게 실험할 수 있습니다.
npx @modelcontextprotocol/inspector + registry/servers 참고
공식 문서 ↗[features]
codex_hooks = true
multi_agent = true
experimental_use_rmcp_client = true
# 최신 라이브러리 문서를 바로 가져옵니다.
[mcp_servers.context7]
url = "https://mcp.context7.com/mcp"
# UI 동작과 브라우저 검증을 에이전트가 직접 확인합니다.
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest", "--headless"]
# 디자인 맥락을 코드 생성에 직접 연결합니다.
[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
# 작업 관리 이슈/프로젝트 맥락을 붙입니다.
[mcp_servers.linear]
url = "https://mcp.linear.app/mcp"
# Jira/Confluence 같은 팀 문서와 티켓을 붙입니다.
[mcp_servers.atlassian]
url = "https://mcp.atlassian.com/v1/mcp"# 1) 로컬 stdio MCP 먼저 붙입니다.
codex mcp add playwright --stdio "npx @playwright/mcp@latest --headless"
# 2) 원격 MCP는 config.toml 또는 서비스 문서 방식으로 추가합니다.
codex mcp add linear --url https://mcp.linear.app/mcp
# 3) OAuth 서버는 로그인 단계를 완료합니다.
codex mcp login linear바로 따라 하는 체크리스트
- 루트에 AGENTS.md 를 만들고 표준 검증 명령과 완료 기준을 먼저 적습니다.
- .codex/config.toml 에 모델, sandbox, approval, profiles, agents 를 고정합니다.
- .codex/rules/default.rules 에 금지 명령과 prompt 경계를 먼저 적습니다.
- .codex/hooks.json 과 SessionStart / PreToolUse / PostToolUse 세 개만 먼저 붙입니다.
- reviewer, gradle_verifier, docs_researcher 같이 좁은 subagent 부터 시작합니다.
- skills 는 review, verify, gradle 같이 반복되는 워크플로만 남깁니다.
- 외부 확장은 Context7 + Playwright 를 먼저 붙이고, 팀 맥락 서버는 순차적으로 추가합니다.
- 하네스 변경 후에는 검증 스크립트와 README 설명을 함께 업데이트합니다.